Re: [6tsch] report flow contents

<P.Zand@utwente.nl> Mon, 16 September 2013 00:57 UTC

Return-Path: <P.Zand@utwente.nl>
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 BE1D611E8176 for <6tsch@ietfa.amsl.com>; Sun, 15 Sep 2013 17:57:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.446
X-Spam-Level: *
X-Spam-Status: No, score=1.446 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
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 HBFUJZTZA6mq for <6tsch@ietfa.amsl.com>; Sun, 15 Sep 2013 17:57:18 -0700 (PDT)
Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id E667811E80FF for <6tsch@ietf.org>; Sun, 15 Sep 2013 17:57:16 -0700 (PDT)
Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 16 Sep 2013 02:57:15 +0200
Received: from EXMBX23.ad.utwente.nl ([169.254.3.13]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.02.0328.009; Mon, 16 Sep 2013 02:56:21 +0200
From: <P.Zand@utwente.nl>
To: <diego.dujovne@mail.udp.cl>, <qinwang@berkeley.edu>
Thread-Topic: [6tsch] report flow contents
Thread-Index: AQHOqmeRdn+u8+L3JUGYWl1pnrYuVpm3azMAgAA2pACAAAP1gIABFasAgAAfWwCAAGmlgIABKJyAgAYvvkCAAA0/AIAAIEEAgAA8AMCAALlWkIABAAeAgADZmoCAAAnjAIAABn2AgAAFBgCAAAbNAIAALW+AgAAPi4CAA6eBIA==
Date: Mon, 16 Sep 2013 00:56:18 +0000
Message-ID: <76EA352C3C95BB42A2C4F2EE6493AD6E4DA7DCCD@EXMBX23.ad.utwente.nl>
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> <CAAzoce6MkLRwyoBihmYhaeKXxaxzCqrGuCqYz7ShoquMuRA2uQ@mail.gmail.com> <CAH7SZV94cUTD8ioUw_=qdPNR1N-bO2qz8iAvwJ70M07L6vCT3w@mail.gmail.com> <CAAzoce7ZHfx=m07m9rkB9rgrDAV0TrRMvoLdM_WF9TOb8aPNMw@mail.gmail.com> <CAH7SZV8qww1FSomhZDt72AEh7NcRojEyAsxfWY+L1u74333N=w@mail.gmail.com>
In-Reply-To: <CAH7SZV8qww1FSomhZDt72AEh7NcRojEyAsxfWY+L1u74333N=w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.89.12.149]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: watteyne@eecs.berkeley.edu, 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: Mon, 16 Sep 2013 00:57:23 -0000

Hi Diego,

ISA100.11a considers the adaptive channel hopping on a link-by-link basis, in addition to traditional blacklisting on the whole network. This mechanism is described as following:

"Additionally, a device may autonomously treat transmit links on problematic channels as idle, thus reducing unnecessary interference and wasted energy on channels with a history of poor connectivity. A device skipping links in this manner should periodically test the links to verify that they remain problematic. Such selective channel utilization can be disabled by the system manager on a link-by-link basis, through the attribute dlmo.Link[].Type.SelectiveAllowed. [1]"

In this scheme, the sender/receiver consider the poor channel as idle. The sender and receiver (on the poor edge) will still follow the defined hopping pattern and they will not conflict with the rest of the network. 
Potential Drawbacks: 1/16 of the resources might be wasted on that edge, but the poor channel of that edge will be skipped, locally. 
Important Strength: The overhead of this scheme is low.

Best wishes,
puoria

1. IEC 62734: Industrial communication networks - Fieldbus specifications - Wireless systems for industrial automation: process control and related applications - ISA100.11a.

-----Original Message-----
From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Prof. Diego Dujovne
Sent: Friday, September 13, 2013 9:07 PM
To: Qin Wang
Cc: Thomas Watteyne; 6TSCH
Subject: Re: [6tsch] report flow contents

Hi Qin,
          On the centralized case, changing the channel hopping sequence (and thus blacklisting the channels with interference) on the whole network, and not in a peer basis is not efficient in terms of channel usage. Let me explain this with an
example:

Let's say there is are 4 nodes: A, B, C and D. A and B are interfered only on channel 4 by an external source, while C and D listen interference only on channel 8. If I disable channel 4 and 8 by blacklisting both channels from the hopping sequence, A and B won't be able to use channel 8 and C and D won't be able to use channel 4, both interference free between them.

On the distributed case, if two nodes are already connected and if both detect a interfered channel they will (someway) agree to blacklist that channel from the hopping sequence. But we have not arrived to this case yet on 6TiSCH.

On the other side, if we blacklist by changing the hopping sequence, a node talking to different neighbours will have different channel hopping sequences. And this increases complexity too.

I don't have an answer (just questions) on how to reduce the probability of using an interfered channel, but it seems that the current tsch scheme does not allow a simple way to blacklist channels unless it is done network-wide. To sum up, I'm worrying about reducing channel diversity.

Thoughts?

                                                         Diego






2013/9/13 Qin Wang <qinwang@berkeley.edu>du>:
> Hi Diego,
>
> I understand, theoretically, dynamic allocation may have some 
> advantages in terms of increasing reliability. But, in the channel 
> hopping network, it is challenge for a node to catch up the channel 
> hopping sequence change in its neighbors. Thus, I think, if updating 
> channel hopping sequence, it could be better to do it in network wide. What do you think?
>
> Thanks
> Qin
>
>
> On Fri, Sep 13, 2013 at 11:28 PM, Prof. Diego Dujovne 
> <diego.dujovne@mail.udp.cl> wrote:
>>
>> Qin,
>>       I think frequency blacklisting on a node-pair basis (either 
>> centralized or distributed) would break the schedule matrix 
>> structure, which overrides narrowband interference by channel 
>> hopping.
>> If frequencies are blacklisted on all slots, that would waste 
>> resources. Narrowband interference can harm the link locally, but the 
>> same frequency may be interference-free in other parts of the net.
>>       The dynamic allocation I propose was only an example. If you 
>> have 16 frequencies and 2 of them have interference, and the channel 
>> offset is sequential, you may loose 2 packets every 16. Am I right on 
>> this?
>>
>> Thoughts?
>>
>>                                                       Diego
>>
>>
>> 2013/9/13 Qin Wang <qinwang@berkeley.edu>du>:
>> > 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
>> >>
>> >
>> >
>> > _______________________________________________
>> > 6tsch mailing list
>> > 6tsch@ietf.org
>> > https://www.ietf.org/mailman/listinfo/6tsch
>> >
>>
>>
>>
>> --
>> DIEGO DUJOVNE
>> Académico Escuela de Ingeniería en Informática y Telecomunicaciones 
>> Facultad de Ingeniería UDP www.ingenieria.udp.cl
>> (56 2) 676 8125
>
>



-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125
_______________________________________________
6tsch mailing list
6tsch@ietf.org
https://www.ietf.org/mailman/listinfo/6tsch