Re: [6tsch] report flow contents

Qin Wang <qinwang@berkeley.edu> Fri, 13 September 2013 18:11 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 762A521E811C for <6tsch@ietfa.amsl.com>; Fri, 13 Sep 2013 11:11:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.489
X-Spam-Level:
X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599, 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 sF64bD8D93Zy for <6tsch@ietfa.amsl.com>; Fri, 13 Sep 2013 11:11:12 -0700 (PDT)
Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEFB11E8166 for <6tsch@ietf.org>; Fri, 13 Sep 2013 11:11:12 -0700 (PDT)
Received: by mail-ie0-f178.google.com with SMTP id to1so3416712ieb.9 for <6tsch@ietf.org>; Fri, 13 Sep 2013 11:11:11 -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=bhnNtBzx9NFgqCgdAasOIxyFMez1NcZojhtt/IXQoUA=; b=FwcgtjkyLv/mW6qmbP8TcwYc+IzQ6CxxyxRsK1bseVOoevokoVOLua4nsi6KOTBkqA gVNryCCP1dw1YwioDPlk7QSLbf0IDs6TJfVsLJCoA3HKWAx6q1Z1SjaxaNLqbfRfFgpt 05OZ7RV+H7wvmIeQhw26Mh9kaqbVBHULu0cyyZa0tAuAcNXN6Q/nSXCmQbX8VF9CwZ+v PmgPQGrrn/aMv0EoSf+Huecmf/WNXw0reU7z2dawoQDb+ZVlrclcDVMjhR21w7e8v86q GmLjPUnwNDEGKA/DBRzspSoD2hWs892XCUwx9GzOGCgoAMQJBr2HvAJxHglAEWe10yOO lY4Q==
X-Gm-Message-State: ALoCoQnGOgIjkdRL45pPzxy5qGBYDE3GOoerxgZ74cml1gE5T/l+lTsqqQ/xSjOu6QMn8/rOxqLd
MIME-Version: 1.0
X-Received: by 10.50.61.137 with SMTP id p9mr1800507igr.45.1379095871762; Fri, 13 Sep 2013 11:11:11 -0700 (PDT)
Received: by 10.64.139.234 with HTTP; Fri, 13 Sep 2013 11:11:11 -0700 (PDT)
In-Reply-To: <CAH7SZV94cUTD8ioUw_=qdPNR1N-bO2qz8iAvwJ70M07L6vCT3w@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>
Date: Sat, 14 Sep 2013 02:11:11 +0800
Message-ID: <CAAzoce7ZHfx=m07m9rkB9rgrDAV0TrRMvoLdM_WF9TOb8aPNMw@mail.gmail.com>
From: Qin Wang <qinwang@berkeley.edu>
To: "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>
Content-Type: multipart/alternative; boundary=047d7bdca5dc8c452004e647c76c
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 18:11:16 -0000

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
>