Re: [6tsch] report flow contents

Thomas Watteyne <watteyne@eecs.berkeley.edu> Fri, 13 September 2013 14:46 UTC

Return-Path: <twatteyne@gmail.com>
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 2FF5321E80AA for <6tsch@ietfa.amsl.com>; Fri, 13 Sep 2013 07:46:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.205
X-Spam-Level:
X-Spam-Status: No, score=-0.205 tagged_above=-999 required=5 tests=[AWL=-0.828, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 PZk8Q5Iz8-V8 for <6tsch@ietfa.amsl.com>; Fri, 13 Sep 2013 07:46:37 -0700 (PDT)
Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 58A8D11E8113 for <6tsch@ietf.org>; Fri, 13 Sep 2013 07:46:37 -0700 (PDT)
Received: by mail-pa0-f46.google.com with SMTP id fa1so2624834pad.33 for <6tsch@ietf.org>; Fri, 13 Sep 2013 07:46:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=/MGF5GZm2lFYBPaoU8lHmdPViGpRIa81J/73U2xb7mk=; b=j1Y1HUhjTGhbTpR6yHGLuq/+u3AxiZ0jaI672YFbrdgQtTZ4l+Q8vsLgl7UZRHnDan U1VESGG5Y6U0kyEgH2r5YHs2lNEMS7jXRv95hawaol0zCGofF/Zl/iVEBquX8vfZVQCv 94enxdaMg8rMc6X/SP6hK5zHvIBLiqSjFb9UxXtteBTjIYOJCD4rvhp8lw7SJgmbWcI5 Gv6ppyXzF2Lkc/W1IX7i0fDzTRQvI8+2vF/VwjgqRjrsZDrKM7+BGdWDawuqm4ayE6TO xGZZ239cptieU5LsNZSvmZ4K7msqP/MwzZMFIgpS0aAm2UsehR6pjLu/89OXuFMYftpt IH7w==
X-Received: by 10.68.232.134 with SMTP id to6mr9231718pbc.163.1379083596743; Fri, 13 Sep 2013 07:46:36 -0700 (PDT)
MIME-Version: 1.0
Sender: twatteyne@gmail.com
Received: by 10.66.147.193 with HTTP; Fri, 13 Sep 2013 07:46:15 -0700 (PDT)
In-Reply-To: <CAH7SZV9-KaAiWOGxstDX3j5exL2EUC=4O_-pfm6tJMwe3kYOhA@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>
From: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Date: Fri, 13 Sep 2013 07:46:15 -0700
X-Google-Sender-Auth: BS-Bfd_SkWewhq65NfAJVXlHptU
Message-ID: <CADJ9OA-0-dvU+urhYwaT4u5827sykQMj3Km_ytWPvgL6TF193A@mail.gmail.com>
To: 6TSCH <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary="047d7b33cbeee64bc604e644ebdf"
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 14:46:38 -0000

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
>