Re: [6tsch] report flow contents

[<[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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 <[e-mail]>:
> 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 
> <[e-mail]> 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 
>> <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>
>
> _______________________________________________
> 6tsch mailing list
> [e-mail]
> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/6tsch