[6tsch] blacklisting (was "report flow contents")

[Thomas Watteyne <[e-mail]>]

*[changed thread subject from 'report flow contents' to 'blacklisting (was
"report flow contents")']*

All,

Great discussion!

Allow me to sum up.

Problem statement:

   - At 2.4GHz, 16 orthogonal frequencies are available.
   - "blind" channel hopping exploits frequencies diversity by hopping on
   all 16 frequencies
   - because of interference and multi-path fading, some frequencies
   exhibit a worse Packet Delivery Ratio (PFD) than others
      - if because of interference, it is possible that same set of
      frequencies are "bad" in the whole network
      - if because of multi-path fading, the set of "bad" frequencies is
      different for every pair of neighbor nodes

Network-wide blacklisting:

   - goal: prevent all nodes in the network to use a given frequency
   - decision can be made by PCE after receiving statistics, or
   administratively by operator configuration
   - different mechanisms to blacklist a channel:
      - modify the hopping pattern to include the same frequency twice and
      remove another one. Can be done on-the-fly.
      - consider there are only 15 frequencies, and build a schedule with
      15 channel offsets. Needs to be done before network starts (or
long process
      of "freeing-up" one channel offset)
   - efficiency is limited since:
      - because of multi-path fading, a "bad" channel might not be bad for
      all bundles
      - limits frequency diversity

Per-link blacklisting:

   - goal: prevent a bundle (i.e. two neighbors scheduled to communicate)
   to use a given frequency
   - decision can be made based on the per-frequency statistics gathered
   (packet counters and/or RSSI/LQI)
   - problem:
      - changing the hopping pattern for a single bundle can create
      interference with other bundles since collisions are possible if
hopping on
      different sets of frequencies.
   - solution (used by ISA100):
      - cancel a scheduled communication if that communication happens on
      the blacklisted channel
      - note that this will reduce the bandwidth of that bundle by 1/16, so
      needs possibly to be combined with adding 1/16 more cells to that bundle.

Did I miss something?

Thomas


On Mon, Sep 16, 2013 at 9:35 AM, <[e-mail]> wrote:

>  Hi Qin,
>
>  "Link-by-link" adaptive channel hopping in ISA is used by a node to
> select the best frequencies for its further communication with its
> particular neighbor.
> And, cell over-provision (i.e. the combination of "channel offset" and
> "slot" info used for communication with a particular neighbor), might be
> used for evaluating the internal interference and BW requirements between
> two neighbors. Am I right?
>
> Best wishes,
> Pouria Zand
>
> On Sep 16, 2013, at 4:34 PM, "Qin Wang" <[e-mail]> wrote:
>
>   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, <[e-mail]> 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: [e-mail] [mailto:[e-mail]] 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 <[e-mail]>:
>> > 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
>> > <[e-mail]> 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 <[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
>> >
>> >
>>
>>
>>
>> --
>> 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
>>
>
>