Re: [6tsch] report flow contents

Qin Wang <qinwang@berkeley.edu> Fri, 13 September 2013 15:04 UTC

Return-Path: <qinwang@berkeley.edu>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1418521E8098 for <6tsch@ietfa.amsl.com>; Fri, 13 Sep 2013 08:04:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.325
X-Spam-Level:
X-Spam-Status: No, score=-1.325 tagged_above=-999 required=5 tests=[AWL=-0.949, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNP3bmZNFAyH for <6tsch@ietfa.amsl.com>; Fri, 13 Sep 2013 08:04:15 -0700 (PDT)
Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id B674921E8055 for <6tsch@ietf.org>; Fri, 13 Sep 2013 08:04:15 -0700 (PDT)
Received: by mail-ie0-f174.google.com with SMTP id u16so2753450iet.33 for <6tsch@ietf.org>; Fri, 13 Sep 2013 08:04:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=q+TdwJbYO3AE+kKoQTnWkX6QvFmvpvDgtP+Wuayheuw=; b=TzJAP6h47Ani1tpVudzko7UHcymL8AVh+9yRcPM5nnQ1W5uM/JsyiMaoe9k/lm8wE6 rGKXVXPofTCpKSexfXRzwXu8QFtGWwfv9cbXvCrPah9wJGpLmu/Rp9yPFzoyNU27NgK5 8L32UozpwqoQWIW9DHf5vXwJoPWsm1Y65wboCXBJ/vQb0xcqLrbxuZWQMk302/VjAH0O aV09yJu/0D9qNWqDAI8fg7ok/VTbbgeGvQlFzde4DxYB+cTMwBaRqKMEO3rycDMQyGDd K0yDPD34/z08IHZOQe84/QH88ytVkE1oLD51Tuk0in+gCqUMf+1tR3/GmdTe11Ob4LMt htXw==
X-Gm-Message-State: ALoCoQk94XX4E8Y/NZZqMt8pS80Q7EoNzhpB31SsTAe23Trn27NNkxD2TFR+A+ptBt+r5au0Tt/s
MIME-Version: 1.0
X-Received: by 10.50.61.137 with SMTP id p9mr1495145igr.45.1379084654831; Fri, 13 Sep 2013 08:04:14 -0700 (PDT)
Received: by 10.64.139.234 with HTTP; Fri, 13 Sep 2013 08:04:14 -0700 (PDT)
In-Reply-To: <CADJ9OA-0-dvU+urhYwaT4u5827sykQMj3Km_ytWPvgL6TF193A@mail.gmail.com>
References: <CADJ9OA_XeC7Z5hFxyHhFGqD0aFMcBn=iHzDfRq34sL9qPi2P4A@mail.gmail.com> <CALEMV4YN3rA2OXeAV1akOZhdQrMOQvhN0A+t6vsL9RPVV=VMnQ@mail.gmail.com> <CADJ9OA8Cx3ingeiMdr60zUfMMENiay-Nftv0nMFOTD7=YcKgwg@mail.gmail.com> <CALEMV4ZdgWAFMyA=FtRik96evup-qJPQfTcDQEu99sfC0xFwuQ@mail.gmail.com> <E045AECD98228444A58C61C200AE1BD84145CB61@xmb-rcd-x01.cisco.com> <CALEMV4a=azY5MU00jNmcoek022gS=pUeXK1xVnucG+Zy6NTBOA@mail.gmail.com> <CALEMV4a=DCXV9ra832-5zEtiD7moUmj6GYu7tiosDYsD5v4ObA@mail.gmail.com> <CADJ9OA9OpGRvB1A4j-Byho_m8Zp3z1A5krCVi08U7xWP1Ohk+Q@mail.gmail.com> <76EA352C3C95BB42A2C4F2EE6493AD6E4DA7B88C@EXMBX23.ad.utwente.nl> <CADJ9OA9qb6aqyqonEmfZpqt3NHqm5EWPK-p2BAQf9C9sw8Cp3A@mail.gmail.com> <CALEMV4b4rfoLBWSOW8=wWR2xWy32V_uCXEzJ=5vaebL6g+LpbQ@mail.gmail.com> <76EA352C3C95BB42A2C4F2EE6493AD6E4DA7BC47@EXMBX23.ad.utwente.nl> <52316e72.c7380f0a.73cf.ffffc7a5@mx.google.com> <CADJ9OA9p2jihyn_o2XtLi7X7EBRQFMEADFjW8upKzgD70h3WOg@mail.gmail.com> <CAAzoce4Up5ar80n-1zr-Opq10QOBVDcvNApBBgPKr+g6UjDENw@mail.gmail.com> <CAH7SZV9-KaAiWOGxstDX3j5exL2EUC=4O_-pfm6tJMwe3kYOhA@mail.gmail.com> <CADJ9OA-0-dvU+urhYwaT4u5827sykQMj3Km_ytWPvgL6TF193A@mail.gmail.com>
Date: Fri, 13 Sep 2013 23:04:14 +0800
Message-ID: <CAAzoce6MkLRwyoBihmYhaeKXxaxzCqrGuCqYz7ShoquMuRA2uQ@mail.gmail.com>
From: Qin Wang <qinwang@berkeley.edu>
To: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Content-Type: multipart/alternative; boundary="047d7bdca5dcf7942404e6452a25"
Cc: 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] report flow contents
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2013 15:04:20 -0000

Thomas,

I agree with you that it is not clear what is the advantage and
disadvantage of adaptive channel hopping in reality.

In mind, based on the per-frequency report, PCE can do two things: (1)
update channel hopping sequence is a frequency is really bad network wide;
(2) avoid use some bad channel when it runs cell allocation algorithm.  The
two things happen in PCE, so, will not make negative impact on the network.
Thought?

Thanks

Qin




On Fri, Sep 13, 2013 at 10:46 PM, Thomas Watteyne <
watteyne@eecs.berkeley.edu> wrote:

> Qin, Diego,
>
> My 2 cents. I agree with you that it would be nice for the PCE to be able
> to get some per-channel information. Although adaptive channel hopping
> (i.e. selectively blacklisting frequencies for a specific bundle) is
> appealing in principle, it's unclear (at least to me) whether the gains
> clearly outweigh the overhead (complexity, signalign traffic) one has to
> pay to coordinate this [1-5].
>
> My opinion is that we should enable both metrics averages over all
> channels, and per-channel metrics. In some configurations, one can imagine
> gathering the former by default, and querying for the latter on specific
> occasions. Having the option of gathering per-channel information does
> enable us to be future-proof against future adaptive channel hopping
> algorithm.
>
> For sure, this makes for a great question: how do a pair of motes and the
> PCE have to communicate to enable adaptive channel hopping on that link?
> The answer to that might directly impact the application payload formats we
> have are talking about. Is this something you be interested in looking
> further into?
>
> Thomas
>
> [1] A Decentralized Scheduling Algorithm for Time Synchronized Channel
> Hopping. Andrew Tinka, Thomas Watteyne, Kris Pister, Alexandre M. Bayen.
> ICST Transactions on Mobile Communications and Applications, 11(7-9).
> European Union Digital Library link. doi:10.4108/icst.trans.mca.2011.e5.
> September 2011.
> [2] A Decentralized Scheduling Algorithm for Time Synchronized Channel
> Hopping. Andrew Tinka, Thomas Watteyne, Kris Pister. International
> Conference on Ad Hoc Networks (ADHOCNETS), Victoria, BC, Canada, 18-20
> August 2010.
> [3] Mitigating Multipath Fading Through Channel Hopping in Wireless Sensor
> Networks. Thomas Watteyne, Steven Lanzisera, Ankur Mehta, Kris Pister. IEEE
> International Conference on Communications (ICC), Cape Town, South Africa,
> 23-27 May, 2010.
> [4] Feasibility Analysis of Controller Design for Adaptive Channel
> Hopping. Branko Kerkez, Thomas Watteyne, Mario Magliocco, Steven Glaser,
> Kris Pister. First International Workshop on Performance Methodologies and
> Tools for Wireless Sensor Networks (WSNPerf), Pisa, Italy, 23 October 2009.
> [5] Reliability Through Frequency Diversity: Why Channel Hopping Makes
> Sense. Thomas Watteyne, Ankur Mehta, Kris Pister. Sixth ACM International
> Symposium on Performance Evaluation of Wireless Ad Hoc, Sensor, and
> Ubiquitous Networks (PE-WASUN), Tenerife, Canary Islands, Spain, 26-30
> October 2009.
>
> On Fri, Sep 13, 2013 at 7:23 AM, Prof. Diego Dujovne <
> diego.dujovne@mail.udp.cl> wrote:
>
>> Hello Qin,
>>               I think that a per-frequency report will help the PCE
>> to decide which frequency to use, and maybe temporarily
>> black-list them. For example, a dynamic scheme may include
>> sampling the blacklisted frequencies every X minutes to re-enable
>> them once the interference has disappeared.
>>              This will require the node to refresh the RSSI
>> and LQI values in a opportunistic way (every time the a cell
>> uses that frequency) to save energy.
>>
>> Any thoughts?
>>
>>                             Diego
>>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>
>