Subject: [6tsch] Scheduling broadcast links

From: <[email-masked]>
Date: Tue, 4 Jun 2013 09:24:28 +0000

Dear All,

Based on the last discussion on "DIOs/DAOs and broadcast channels on TSCH", I found that we agreed to have two separate scheduled broadcast links: (i) to broadcast ADV, (ii) to broadcast DIOs as well as the upper layers' traffic as regular TSCH data.
My question are:

(1)    How to schedule these collision-free broadcast links for (i) and (ii) in a distributed manner with no central PCE (soft broadcast cells)? Or in this phase we will just consider the centralized approach, in which the PCE schedules hard cells for broadcasting links.

(2)    What is your opinion to consider the specific timeslots (e.g. the first timeslots) in order to schedule broadcast links for ADVs (either in a distributed or centralized approach) in a specific slotframe (e.g. consist 100 or 200 slots) by different channel table (with limited number of physical channels in 2.4 GHz). In those timeslot no more communication can be scheduled, unless the other links also follow the same hopping list/pattern.

Pros:

*         The network formation and network synchronization can be easier because the new nodes know to scan just those physical channels .

*         In a distributed approach, scheduling collision-free broadcast links can be easier.
Cons:

*         Limiting to the potential wrong physical channels in 2.4 GHz that might not work everywhere.

*         Wasting communication resources in those timeslots that is considered for ADVs. Because no further communication can be scheduled in those timeslots, unless with the same hopping list/pattern.

Best Wishes,

Pouria Zand
PhD Candidate
Pervasive Systems Group
Dept. of Computer Science
University of Twente
P.O. Box 217
7500AE Enschede
The Netherlands

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 10 Jun 2013 17:47:03 -0700

Pouria,

If I understand correctly, you are suggesting to limit the number of
channels to send the EBs on, but not the data?

I understand that this will speed joining up, since EBs will be sent more
often in the remaining channels. But I would argue that this is a dangerous
game to play, since your mote might not discover all its neighbors using
the EBs since some might just be at the "wrong place and the wrong
frequency". What do you think?

Of course, if you're worried about the speed of joining (which might be
problematic during an interop event), nothing prevents you from switching
the whole network on this subset of channels.

Thomas

On Tue, Jun 4, 2013 at 2:24 AM, <[email-masked]> wrote:

>  Dear All,****
>
> ** **
>
> Based on the last discussion on “DIOs/DAOs and broadcast channels on
> TSCH”, I found that we agreed to have two separate scheduled broadcast
> links: (i) to broadcast ADV, (ii) to broadcast DIOs as well as the upper
> layers’ traffic as regular TSCH data. ****
>
> My question are:  ****
>
> ** **
>
> **(1)    **How to schedule these collision-free broadcast links for (i)
> and (ii) in a distributed manner with no central PCE (soft broadcast
> cells)? Or in this phase we will just consider the centralized approach, in
> which the PCE schedules hard cells for broadcasting links. ****
>
> ** **
>
> **(2)    **What is your opinion to consider the specific timeslots (e.g.
> the first timeslots) in order to schedule broadcast links for ADVs (either
> in a distributed or centralized approach) in a specific slotframe (e.g.
> consist 100 or 200 slots) by different channel table (with limited number
> of physical channels in 2.4 GHz). In those timeslot no more communication
> can be scheduled, unless the other links also follow the same hopping
> list/pattern. ****
>
> ** **
>
> Pros: ****
>
> **·         **The network formation and network synchronization can be
> easier because the new nodes know to scan just those physical channels . *
> ***
>
> **·         **In a distributed approach, scheduling collision-free
> broadcast links can be easier.****
>
> Cons:      ****
>
> **·         **Limiting to the potential wrong physical channels in 2.4
> GHz that might not work everywhere.****
>
> **·         **Wasting communication resources in those timeslots that is
> considered for ADVs. Because no further communication can be scheduled in
> those timeslots, unless with the same hopping list/pattern. ****
>
>   ****
>
> Best Wishes,****
>
> ** **
>
> *Pouria Zand*****
>
> *PhD Candidate*****
>
> *Pervasive Systems Group*****
>
> *Dept. of Computer Science*****
>
> *University of Twente*****
>
> *P.O. Box 217*****
>
> *7500AE Enschede*****
>
> *The Netherlands*****
>
> ** **
>
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>