Re: [6tsch] report flow contents
Qin Wang <qinwang@berkeley.edu> Fri, 13 September 2013 18:22 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 B2EA911E81CC for <6tsch@ietfa.amsl.com>; Fri, 13 Sep 2013 11:22:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level:
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.426, 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 VJtGvBc9iiu3 for <6tsch@ietfa.amsl.com>; Fri, 13 Sep 2013 11:22:31 -0700 (PDT)
Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by ietfa.amsl.com (Postfix) with ESMTP id 649AA11E81C0 for <6tsch@ietf.org>; Fri, 13 Sep 2013 11:22:28 -0700 (PDT)
Received: by mail-ie0-f177.google.com with SMTP id qd12so3134725ieb.8 for <6tsch@ietf.org>; Fri, 13 Sep 2013 11:22:28 -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=MDyL/pMlV7rmiVr4MEzuyOa83c/tOShhXKWAl38Ai9A=; b=ElJuMuxY477+i/RdGYy7MILCpQSl9lQdvlJgRZ9S1GPP3+1Ftfi2HVF6E4OnLqsriY p7cXrLOmMYIcoWSiQZhub4dH1LcIcDdKqKPqEEmW52D8gLb2bJlxurekKM6swkAVyFuW 9jvkR2hoDse7ununybmH0aInZBYqOP21fIZwpnvqfy5CS1VeZESSKc0TBqSjoYiNClzI DbaZXcj35AvOSEqkl4u351Vx+/XiuD7kKR2EM53cHMXGWf4M+rxxNixBGpBD7+zzUDOx cKpF2p9RB3IkwFFDaYyIptMH7cG2556h3Fck/cCr0y3qaByezwCo3qTx4VAZ57ryj4Xo 2XJg==
X-Gm-Message-State: ALoCoQmkh1RpuI07PCTRIQHcVcMtL6CjC1m9RBeIgYbfOhOpLhyTdIw41K9YMKNgoe38e8/8dDWG
MIME-Version: 1.0
X-Received: by 10.50.66.101 with SMTP id e5mr1852251igt.26.1379096547901; Fri, 13 Sep 2013 11:22:27 -0700 (PDT)
Received: by 10.64.139.234 with HTTP; Fri, 13 Sep 2013 11:22:27 -0700 (PDT)
In-Reply-To: <76EA352C3C95BB42A2C4F2EE6493AD6E4DA7C9AE@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> <76EA352C3C95BB42A2C4F2EE6493AD6E4DA7C9AE@EXMBX23.ad.utwente.nl>
Date: Sat, 14 Sep 2013 02:22:27 +0800
Message-ID: <CAAzoce64PP7q5eot0-3AiXbMjcGxj43rfp68w91wkUn5zpQLcQ@mail.gmail.com>
From: Qin Wang <qinwang@berkeley.edu>
To: "P.Zand@utwente.nl" <P.Zand@utwente.nl>
Content-Type: multipart/alternative; boundary="001a1135ec0cd9789a04e647ef1e"
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: Fri, 13 Sep 2013 18:22:46 -0000
Hi Pouria, In the centralized case, I believe PCE will take care everything you mentioned. That means internal-interference caused by other neighboring communication should not be the contributor to low link quality of a cell. Thus, I think PCE will use per-cell report to adjust over-provision of cells. For example, when PCE found a bundle of cells can not achieve required BW, PCE may assign more cells. Make sense? Qin On Sat, Sep 14, 2013 at 12:45 AM, <P.Zand@utwente.nl> wrote: > Dear All, > Regarding to the Xavi's report list, I found "per-cell" reports for each > node (in addition to potential "per-frequency" and "per-neighbor" reports) > in the list. I have the following concerns, > (1) In the centralized management approach, what is the gain of reporting > the statistics "per-cell"? Per-cell information will be used to evaluate > the potential internal-interference caused by other neighboring > communication. Am I right? Shouldn't the PCE, take care of allocation of > cells (either dedicated or shared cells)? I mean, shouldn't the PCE take > care of not allocating (re-using) the dedicated cell to two different > pairs? Shouldn't the PCE take care of allocating the shared cell to the > limited number of transmitters? > (2) For sure, in the "per-frequency" and "per-neighbor" reports, each node > has a limited number of frequencies (i.e. 11-26 in 2.4GHz) and a maximum > number of linked-neighbors to report. However, in reporting "per-cell", > what is the maximum number of cells defined for a node? (We might also > consider the dense traffic scenarios). > Am I missing anything? > Best Wishes, > Pouria > > -----Original Message----- > From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of > Prof. Diego Dujovne > Sent: Friday, September 13, 2013 5:29 PM > To: Qin Wang > Cc: Thomas Watteyne; 6TSCH > Subject: Re: [6tsch] report flow contents > > 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 > _______________________________________________ > 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