Re: [6tsch] report flow contents

"Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl> Fri, 13 September 2013 19:07 UTC

Return-Path: <diego.dujovne@mail.udp.cl>
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 7225A11E816D for <6tsch@ietfa.amsl.com>; Fri, 13 Sep 2013 12:07:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 YqZ7pTlEZx77 for <6tsch@ietfa.amsl.com>; Fri, 13 Sep 2013 12:07:11 -0700 (PDT)
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 8290A21F9E9F for <6tsch@ietf.org>; Fri, 13 Sep 2013 12:06:50 -0700 (PDT)
Received: by mail-wi0-f176.google.com with SMTP id cb5so1224187wib.3 for <6tsch@ietf.org>; Fri, 13 Sep 2013 12:06: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 :content-transfer-encoding; bh=D4eCzlTgn4BwoOjZv2puDLtixUHGrvVqKZ21t29tFxQ=; b=WNtpt7uakxcV+fynOCrOyNqKivK2PALytF1mP4ll/aqSMFyvotRZcW4a+PEfz1yJUH 7GdyM+VDi919o/wP+lMDb+3tuESzRj3CBOADq1X/ngikW5RNGcKWGGfYP2Z8NrAHLUD7 hc3Qcs0ZYi7Lf03xCveHxvBcLsz/XRNFnwzA8uKKv6Mf8ej5LlEbwN9fv2kvM2We03q2 gOBh2fVE9MEIMMBL7ijk6UznUAD+IuM3j6KgPXOvUCcJ9vPZThjfaVV06DfHlcMAVG/v 24oFXpYCRKhZaHwkKF0ixX0ed3CaPyNylVNg+tueE8TssYBHgfo5uT0WxlY072PpR08h njWA==
X-Gm-Message-State: ALoCoQlNXhsnWUk7ULv9yWFhWYkD6VO5913OjB8Qujs3xWSREPyjRoqPK6y6FtLIHs7G3OVNNBdM
MIME-Version: 1.0
X-Received: by 10.180.206.5 with SMTP id lk5mr3860860wic.10.1379099209292; Fri, 13 Sep 2013 12:06:49 -0700 (PDT)
Received: by 10.194.122.103 with HTTP; Fri, 13 Sep 2013 12:06:49 -0700 (PDT)
In-Reply-To: <CAAzoce7ZHfx=m07m9rkB9rgrDAV0TrRMvoLdM_WF9TOb8aPNMw@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> <CAAzoce6MkLRwyoBihmYhaeKXxaxzCqrGuCqYz7ShoquMuRA2uQ@mail.gmail.com> <CAH7SZV94cUTD8ioUw_=qdPNR1N-bO2qz8iAvwJ70M07L6vCT3w@mail.gmail.com> <CAAzoce7ZHfx=m07m9rkB9rgrDAV0TrRMvoLdM_WF9TOb8aPNMw@mail.gmail.com>
Date: Fri, 13 Sep 2013 16:06:49 -0300
Message-ID: <CAH7SZV8qww1FSomhZDt72AEh7NcRojEyAsxfWY+L1u74333N=w@mail.gmail.com>
From: "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>
To: Qin Wang <qinwang@berkeley.edu>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Thomas Watteyne <watteyne@eecs.berkeley.edu>, 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 19:07:26 -0000

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