Re: [6tsch] report flow contents
Qin Wang <qinwang@berkeley.edu> Mon, 16 September 2013 14:34 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 0E58111E8273 for <6tsch@ietfa.amsl.com>; Mon, 16 Sep 2013 07:34:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.297
X-Spam-Level:
X-Spam-Status: No, score=-1.297 tagged_above=-999 required=5 tests=[AWL=-0.921, 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 iWHm9a8yXMTm for <6tsch@ietfa.amsl.com>; Mon, 16 Sep 2013 07:34:49 -0700 (PDT)
Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by ietfa.amsl.com (Postfix) with ESMTP id B5ABB11E827C for <6tsch@ietf.org>; Mon, 16 Sep 2013 07:34:49 -0700 (PDT)
Received: by mail-ie0-f179.google.com with SMTP id e14so7487538iej.38 for <6tsch@ietf.org>; Mon, 16 Sep 2013 07:34:49 -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=ZhcdnIRDE+umhljultL2qcafGBzUDO9Y7o/oitcKpb0=; b=RZ1bZts/4Ny/8cz9vi4HKz5kYa+Grb6pOwDK7+Fx3ujfr9a7nQBzJqovVUi165QMtv Kzn8Lz09ASBm/VdpO8QU+eUAKK366AAJPWGB34VkV2iIiBtx7BevkAwi5Tkt7LNZkvZy GncYAx9fVafbimakpi0ymEiOkHDf7SSUdALtTtNRL95d7GrrfCTjhPx+lOp/jlf9k3UV 6I58tlPXsMVvujBMuTBpQ2J/v93sL0lvuuRxXbHYt7jd1TaBzwNWFoflCYiPZ3i3KQrc 8W/FL/G0E2fIgo+gQBMDw0qrQWitPBAfl8wLrDDsw3QgshYR/weXj2hGDTXZliLPLbzi N7Tg==
X-Gm-Message-State: ALoCoQkEz9eramLFYecpk+3ScYSjK6Vl3TcfSdOjC/woGlBl4z/o0EgXmYjv1xImxMLVBEsIGOZf
MIME-Version: 1.0
X-Received: by 10.50.43.170 with SMTP id x10mr6410736igl.45.1379342088204; Mon, 16 Sep 2013 07:34:48 -0700 (PDT)
Received: by 10.64.139.234 with HTTP; Mon, 16 Sep 2013 07:34:47 -0700 (PDT)
In-Reply-To: <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> <76EA352C3C95BB42A2C4F2EE6493AD6E4DA7DCCD@EXMBX23.ad.utwente.nl>
Date: Mon, 16 Sep 2013 22:34:47 +0800
Message-ID: <CAAzoce4iXwjKMcxPjc3m0WweAMuKdPaX-iXmeSQHRwSuo4BmDg@mail.gmail.com>
From: Qin Wang <qinwang@berkeley.edu>
To: "P.Zand@utwente.nl" <P.Zand@utwente.nl>
Content-Type: multipart/alternative; boundary="089e01176cad310fb504e6811bb4"
Cc: Thomas Watteyne <watteyne@eecs.berkeley.edu>, "6tsch@ietf.org" <6tsch@ietf.org>, "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>
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 14:34:54 -0000
Hi Pouria and Diego, I think the "link-by-link" adaptive channel hopping mechanism of ISA100.11a AND cell over-provision mechanism of 6top can be used together. Make sense? Thanks Qin On Mon, Sep 16, 2013 at 8:56 AM, <P.Zand@utwente.nl> wrote: > 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>: > > 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>: > >> > 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 >
- [6tsch] report flow contents Thomas Watteyne
- Re: [6tsch] report flow contents Xavier Vilajosana Guillen
- Re: [6tsch] report flow contents Thomas Watteyne
- Re: [6tsch] report flow contents Xavier Vilajosana Guillen
- Re: [6tsch] report flow contents Thomas Watteyne
- Re: [6tsch] report flow contents Qin Wang
- Re: [6tsch] report flow contents Prof. Diego Dujovne
- Re: [6tsch] report flow contents Pascal Thubert (pthubert)
- Re: [6tsch] report flow contents Thomas Watteyne
- Re: [6tsch] report flow contents Xavier Vilajosana Guillen
- Re: [6tsch] report flow contents Xavier Vilajosana Guillen
- Re: [6tsch] report flow contents Thomas Watteyne
- Re: [6tsch] report flow contents P.Zand
- Re: [6tsch] report flow contents Thomas Watteyne
- Re: [6tsch] report flow contents Xavier Vilajosana Guillen
- Re: [6tsch] report flow contents P.Zand
- [6tsch] R: report flow contents Alfredo Grieco
- Re: [6tsch] report flow contents Thomas Watteyne
- Re: [6tsch] report flow contents Qin Wang
- Re: [6tsch] report flow contents Prof. Diego Dujovne
- Re: [6tsch] report flow contents Thomas Watteyne
- Re: [6tsch] report flow contents Qin Wang
- Re: [6tsch] report flow contents Qin Wang
- Re: [6tsch] report flow contents Prof. Diego Dujovne
- Re: [6tsch] report flow contents P.Zand
- Re: [6tsch] report flow contents Qin Wang
- Re: [6tsch] report flow contents Qin Wang
- Re: [6tsch] report flow contents Prof. Diego Dujovne
- Re: [6tsch] report flow contents P.Zand
- Re: [6tsch] report flow contents Qin Wang
- Re: [6tsch] report flow contents P.Zand