Subject: [6tsch] DIOs/DAOs and broadcast channels on TSCH

From: Xavier Vilajosana <[email-masked]>
Date: Mon, 25 Feb 2013 20:15:48 -0800

Hi,

I have a question that i want to discuss, the question is whether we 
need a broadcast channel in TSCH or not and what kind of support 6tus 
should provide. (the answer can be depends... but lets see some cases)

a) ADV need broadcast channels in case they are used to synchronize the 
network. IEEE 802.15.4e provides the timekeeping flag to set that 
channels as used for synchronization and shared flag can make them 
broadcast.
b) Those networks that do not need ADV for synchronization then can use 
any TX link for ADV, this means that if it is not shared only the node 
listening on that link will get the ADV. However as this periodically 
occurs the ADV might eventually be listened in all channels.
c)Some DAOs and all DIOs require a broadcast channel. Should the 
schedule provide that? in case of a), can the same link be used? How 
this link should be installed in the nodes?
d)Is the scheduler of the network who should setup a broadcast channel 
independent of the broadcast channel set for ADV? can it be the same? Or 
in contrast, 6tus can configure the EB so it indicates a broadcast 
channel..
e)..

I would like to know what is your opinion on that.

cheers!
Xavi

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Tue, 26 Feb 2013 07:55:28 +0000

Hello Xavi,
from my point of view, having a TSCH broadcast channel could be useful in several situations:

>>>a) ADV need broadcast channels in case they are used to synchronize the network. IEEE 802.15.4e provides the timekeeping flag to set that channels as used for synchronization and shared flag can make them broadcast.
>>>b) Those networks that do not need ADV for synchronization then can use any TX link for ADV, this means that if it is not shared only the node listening on that link will get the ADV. However as this periodically occurs the ADV might eventually be listened  >>>in all channels.

1) synchronization (as you said in [a]): it will allow to have a faster set-up phase for synchronizing all the motes in the network. While, using  any TX link ([b]), even though this will hop from one channel to another, it will imply a longer set-up phase, because each mote will be able to synchronize at a different time (when it is in listen mode on the "right" channel).
 
>>>c)Some DAOs and all DIOs require a broadcast channel. Should the schedule provide that? in case of a), can the same link be used? How this link should be installed in the nodes?

2) transmission of RPL messages (DAOs and DIOs). If we want TSCH works with RPL, then we should reserve some slots of the schedule for exchanging information between L3 and L2. I am not sure we should use the same link used for synchronization, maybe it could be better to have 2 different ones, dedicated to different purposes. Anyway, this is something to check. 

>>>d)Is the scheduler of the network who should setup a broadcast channel independent of the broadcast channel set for ADV? can it be the same? Or in contrast, 6tus can configure the EB so it indicates a broadcast channel..

3) transmission of signaling messages for setting up the schedule. Let's  assume there is a scheduler that builds the schedule for the network. In order to assign some links to each of them, it  will need to broadcast the information related to ( timeOffset, ChannelOffset). As for the synchronization, having a broadcast channel dedicated to the signaling will allow to set up the schedule in shorter time. 

Maybe, because there are 16 available channels in  IEEE802.15.4/15.4e PHY, using some of them as broadcast channels for synchronization/exchange of cross-layer info/set up of the schedule wouldn't  be a big problem. In many applications, a smaller set of channels (< 16) will be enough for building a reliable schedule. 

6tus, as adaptation layer, may have a key role in the configuration of such broadcast channels, but we will need to think  "how/when" it should take care of that.

For now, let's see what other 6tus members think about!

Maria Rita

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: Tuesday, February 26, 2013 5:16 AM
To: [email-masked]
Subject: [6tsch] DIOs/DAOs and broadcast channels on TSCH

Hi,

I have a question that i want to discuss, the question is whether we need a broadcast channel in TSCH or not and what kind of support 6tus should provide. (the answer can be depends... but lets see some cases)

a) ADV need broadcast channels in case they are used to synchronize the network. IEEE 802.15.4e provides the timekeeping flag to set that channels as used for synchronization and shared flag can make them broadcast.
b) Those networks that do not need ADV for synchronization then can use any TX link for ADV, this means that if it is not shared only the node listening on that link will get the ADV. However as this periodically occurs the ADV might eventually be listened in all channels.
c)Some DAOs and all DIOs require a broadcast channel. Should the schedule provide that? in case of a), can the same link be used? How this link should be installed in the nodes?
d)Is the scheduler of the network who should setup a broadcast channel independent of the broadcast channel set for ADV? can it be the same? Or in contrast, 6tus can configure the EB so it indicates a broadcast channel..
e)..

cheers!
Xavi
_______________________________________________
6tsch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6tsch

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 26 Feb 2013 11:06:40 +0000

Hi Xavi and Maria-Rita:

We may find a number of asynchronous types. I can see:

1) RPL signaling, highest priority
2) best effort traffic, lowest priority and with no reservation at all, for lesser importance sensors like corrosion.
3) lazy reservation overflow, when a small jitter is acceptable. Virtual bandwidth was reserved but physical slots are only allocated upon observed use. 

For all 3, transmission is statistical, and all 3 will be governed by QoS as opposed to reservation.

So basically we'll probably need some time slots with priority to accommodate either parent to any child (shared reception slot though a given packet may be unicast) or any child to parent (shared emission with contention) traffic. 

Is that doable?

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Maria Rita PALATTELLA
Sent: mardi 26 février 2013 08:55
To: Xavier Vilajosana; [email-masked]
Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH

Hello Xavi,

 

Maria Rita

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: Tuesday, February 26, 2013 5:16 AM
To: [email-masked]
Subject: [6tsch] DIOs/DAOs and broadcast channels on TSCH

Hi,

cheers!
Xavi

---

From: "Qin Wang" <[email-masked]>
Date: Tue, 26 Feb 2013 09:50:29 -0800

Hi All,

Firstly, I want to clarify that the "broadcast channel" mentioned here is
not a physical channel or logic channel in the channel set, e.g. one of 16
channels in 2.4GHz band. My understanding is the "broadcast channel"
refers to a set of links, on which one node is in TX mode and its
neighbors are in RX mode.

In TSCH, EB has a broadcast channel, i.e. one or more links in one or more
slotframes. But it is unnecessary for a advertiser to occupy the whole
bandwidth to broadcast EB. For example, slotframe consists 32 slots, slot
duration is 10ms. There is one link in the slotframe used as broadcast
link. EB is triggered by a timer every one second. Then, only about 1/3 of
the broadcast channel bandwidth is used for EB.

Then, for broadcasting all of DIO and some of DAO, we can have different
approaches. For example,

(1) Put DIO into EB payload when it is triggered by the Trickle Timer of
RPL. But, I'm not sure how to broadcast DAO in this approach.

(2) Put DIO or DAO (which needs to broadcast) into the payload of Data
packet of TSCH, and take advantage of the remained bandwidth of the
broadcast channel established for EB in TSCH.

(3) Still put DIO or DAO (which needs to broadcast) into the payload of
Data packet of TSCH, but instead of sharing the broadcast channel with EB,
6tus establishes more bandwidth for broadcasting DIO/DAO.

Regarding to establishing broadcast channel, TSCH provides a way, which is
originally for EB, i.e. for synchronization. It is very simple, just play
the LinkType in MIB and LinkOption in the synchronization IE, which has
been described in Xavi's email. We can use same way to establish broadcast
channel for DIO/DAO if they need.

Looking forward to your comments.

Thanks
Qin

> 2) best effort traffic, lowest priority and with no reservation at all,
> for lesser importance sensors like corrosion.
> 3) lazy reservation overflow, when a small jitter is acceptable. Virtual
> bandwidth was reserved but physical slots are only allocated upon observed
> use.
>
> So basically we'll probably need some time slots with priority to
> accommodate either parent to any child (shared reception slot though a
> given packet may be unicast) or any child to parent (shared emission with
> contention) traffic.
>
> Is that doable?
>
> Pascal
>
>
>>>> occurs the ADV might eventually be listened  >>>in all channels.
>
> 1) synchronization (as you said in [a]): it will allow to have a faster
> set-up phase for synchronizing all the motes in the network. While, using
> any TX link ([b]), even though this will hop from one channel to another,
> it will imply a longer set-up phase, because each mote will be able to
> synchronize at a different time (when it is in listen mode on the "right"
> channel).
>
> 2) transmission of RPL messages (DAOs and DIOs). If we want TSCH works
> with RPL, then we should reserve some slots of the schedule for exchanging
> information between L3 and L2. I am not sure we should use the same link
> used for synchronization, maybe it could be better to have 2 different
> ones, dedicated to different purposes. Anyway, this is something to check.
>
>>>> independent of the broadcast channel set for ADV? can it be the same?
>>>> Or in contrast, 6tus can configure the EB so it indicates a broadcast
>>>> channel..
>
> 3) transmission of signaling messages for setting up the schedule. Let's
> assume there is a scheduler that builds the schedule for the network. In
> order to assign some links to each of them, it  will need to broadcast the
> information related to ( timeOffset, ChannelOffset). As for the
> synchronization, having a broadcast channel dedicated to the signaling
> will allow to set up the schedule in shorter time.
>
> Maybe, because there are 16 available channels in  IEEE802.15.4/15.4e PHY,
> using some of them as broadcast channels for synchronization/exchange of
> cross-layer info/set up of the schedule wouldn't  be a big problem. In
> many applications, a smaller set of channels (< 16) will be enough for
> building a reliable schedule.
>
> 6tus, as adaptation layer, may have a key role in the configuration of
> such broadcast channels, but we will need to think  "how/when" it should
> take care of that.
>
> I have a question that i want to discuss, the question is whether we need
> a broadcast channel in TSCH or not and what kind of support 6tus should
> provide. (the answer can be depends... but lets see some cases)
>
> network. IEEE 802.15.4e provides the timekeeping flag to set that channels
> as used for synchronization and shared flag can make them broadcast.
> c)Some DAOs and all DIOs require a broadcast channel. Should the schedule
> provide that? in case of a), can the same link be used? How this link
> should be installed in the nodes?

---

From: "Qin Wang" <[email-masked]>
Date: Tue, 26 Feb 2013 10:25:48 -0800

Hi Pascal,

Just some idea popping out. I think we can use queue with priority in 6tus
to provide support to QoS. The following is some related detail.

(1)The communication schedule in TSCH can be abstracted as 2-D array, some
of its elements are marked as TX, RX. My understanding is the array could
be a result of overlapping multiple slotframes. Therefore, I think it is
not easy to associate slots, i.e. the elements in the array, with
priority.

(2)But, 6tus can provide support to QoS in this way: 6tus maintains some
queues with different priority, and put control/data packets with priority
from upper layer into corresponding queues, and feeds those packets into
TSCH according to some QoS policy. TSCH works just like before,
transmitting packet in Tx slot without knowing its priority.

Does it make sense?

Qin

---

From: Tom Phinney <[email-masked]>
Date: Tue, 26 Feb 2013 23:58:21 -0700

The model of a schedule as a 2-D array indexed by
superframe and slot-position makes sense.

Conceptually, superframe schedules are stored in devices (i.e.,
motes and non-motes) as sparse vectors (i.e., with a large
percentage of unpopulated elements), each of a fixed total number
of (allocated and unallocated) slots that repeat cyclically.
Different superframes may have different periods. Selection occurs
by logically-advancing pointers into these superframe schedules
that each select either an unallocated (null) element in the
sparse vector or the allocated element.

If one looks at the generalized case, individual allocated entries
in the vector will indicate those aspects of the slot use that
have been predetermined, including the appropriate template(s) for
the transaction, where each template specifies one of the
following actions and an associated transmit or receive queue:

a) transaction initiator, or

b) transaction respondent, or

c) non-responding transaction listener.

Note that the schedule for a single slot could include one or more
type-a) elements, where selection occurs only when the associated
transmit queue is non-empty, and one type-b) or type-c) element,
which becomes the default activity when there is nothing to
transmit.

Other slot-use aspects in the device superframe schedule may
commit the slot to a particular association (e.g., a periodic
automation-system report of a process measurement and its status)
or a particular class of use. In the case of such dedicated-use
slots, the transmit workload queue tends to be single-priority
serving a specific need.

However, other slots can be allocated to more generic use, whether
uni-sourced from a single device or shared (within the RF region)
by many source devices. Each device's transmit queue that feeds
those slots will often be a multilevel priority queue, whether
using static message priorities or priorities that escalate with
increasing time in queue.

In general the use allocation of the slot can be managed simply by
associating a specific transmit or receive queue to the slot,
paired with a specific slot-use transaction template of type a),
b) or c).

I agree that the selection of the highest-priority item from the
queue should not be influenced by TSCH, but it could be reasonable
to convey some aspect of that priority information to TSCH to
influence the choice of duration of the CSMA observation interval
that precedes transmission in a shared RF timeslot, provided that
the priority assessments used by different devices are shared
(i.e., globally agreed). In other words, with five devices trying
to transmit in the same timeslot, where one has a high global globally-agreed message,
one has a medium globally-agreed priority message, and three have low globally-agreed priority
messages, it is reasonable to let those globally-agreed priorities
influence the CSMA sampling interval durations so that the sender
with the highest globally-agreed priority message has the highest probability of not
deferring access to the logical channel.

Such use of message priority to inform the TSCH prioritization
makes sense on multi-sender channels such as broadcast channels.
It has no obvious impact for other channels where contention is
either not expected or not observed.

-Tom Phinney

====

On 2013.02.26 11:25, Qin Wang wrote:

Hi Pascal,

Does it make sense?

Qin

Hi Xavi and Maria-Rita:

For all 3, transmission is statistical, and all 3 will be governed by QoS
as opposed to reservation.

Is that doable?

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Maria Rita PALATTELLA
Sent: mardi 26 février 2013 08:55
To: Xavier Vilajosana; [email-masked]
Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH

Hello Xavi,
from my point of view, having a TSCH broadcast channel could be useful in
several situations:

Maria Rita

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Xavier Vilajosana
Sent: Tuesday, February 26, 2013 5:16 AM
To: [email-masked]
Subject: [6tsch] DIOs/DAOs and broadcast channels on TSCH

Hi,

cheers!
Xavi

---

From: "Alfredo Grieco" <[email-masked]>
Date: Thu, 28 Feb 2013 10:57:45 +0100

Hi Xavi and all,

Sorry for the delayed reply.

I agree that I broadcast channel is required. I was wondering that if we set
up a broadcast channel, its bandwidth should scale with the size of the
network. The more node the more the signaling to be sent in broadcast.

Should we imagine a primary broadcast channel that convey also the
information to signal the presence of further additional broadcast channels
?

Cheers

Alfredo

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di
Xavier Vilajosana
Inviato: Tuesday, February 26, 2013 5:16 AM
A: [email-masked]
Oggetto: [6tsch] DIOs/DAOs and broadcast channels on TSCH

Hi,

I have a question that i want to discuss, the question is whether we need a
broadcast channel in TSCH or not and what kind of support 6tus should
provide. (the answer can be depends... but lets see some cases)

a) ADV need broadcast channels in case they are used to synchronize the
network. IEEE 802.15.4e provides the timekeeping flag to set that channels
as used for synchronization and shared flag can make them broadcast.
b) Those networks that do not need ADV for synchronization then can use any
TX link for ADV, this means that if it is not shared only the node listening
on that link will get the ADV. However as this periodically occurs the ADV
might eventually be listened in all channels.
c)Some DAOs and all DIOs require a broadcast channel. Should the schedule
provide that? in case of a), can the same link be used? How this link should
be installed in the nodes?
d)Is the scheduler of the network who should setup a broadcast channel
independent of the broadcast channel set for ADV? can it be the same? Or in
contrast, 6tus can configure the EB so it indicates a broadcast channel..
e)..

cheers!
Xavi

---

From: "Qin Wang" <[email-masked]>
Date: Thu, 28 Feb 2013 10:39:32 -0800

Hi Alfredo,

When you say "primary broadcast channel", you mean a physical or logical
channel, for example one of the 16 channels in 2.4GHz band, or a set of
links among neighbors?

I think using a set of links as broadcast channel, instead of a fixed
physical or logic channel, is more flexible and bandwidth efficient. How
do you think?

Qin

> a
> any
> in

---

From: "Alfredo Grieco" <[email-masked]>
Date: Thu, 28 Feb 2013 20:15:20 +0100

Hi Qin,

The "primary broadcast channel" could be logical otherwise it could suffer selective EM noise.

Using a set of links for me it is ok but it requires we answer to the question: how many links in the set ? This answer cannot be provided once for all because the amount of signaling is related to the scale of the network, right ?

This is the reason why I was proposing a narrow primary broadcast channel that could be "enlarged" (if required) on a dynamical basis.

Thanks a lot for your valuable considerations

Cheers

Alfredo

-----Messaggio originale-----
Da: Qin Wang [mailto:[email-masked]] 
Inviato: Thursday, February 28, 2013 7:40 PM
A: Alfredo Grieco
Cc: 'Xavier Vilajosana'; [email-masked]
Oggetto: Re: [6tsch] R: DIOs/DAOs and broadcast channels on TSCH

Hi Alfredo,

When you say "primary broadcast channel", you mean a physical or logical channel, for example one of the 16 channels in 2.4GHz band, or a set of links among neighbors?

I think using a set of links as broadcast channel, instead of a fixed physical or logic channel, is more flexible and bandwidth efficient. How do you think?

Qin

> I agree that I broadcast channel is required. I was wondering that if 
> we set up a broadcast channel, its bandwidth should scale with the 
> size of the network. The more node the more the signaling to be sent 
> in broadcast.
>
> information to signal the presence of further additional broadcast 
> channels ?
>
> Cheers
>
> Alfredo
>
> Da: [email-masked] [mailto:[email-masked]] Per conto 
> di Xavier Vilajosana
> a) ADV need broadcast channels in case they are used to synchronize 
> the network. IEEE 802.15.4e provides the timekeeping flag to set that 
> channels as used for synchronization and shared flag can make them broadcast.
> b) Those networks that do not need ADV for synchronization then can 
> use any TX link for ADV, this means that if it is not shared only the 
> node listening on that link will get the ADV. However as this 
> periodically occurs the ADV might eventually be listened in all 
> channels.

---

From: "Qin Wang" <[email-masked]>
Date: Thu, 28 Feb 2013 12:51:20 -0800

Hi Alfredo,

I agree with you that it is almost impossible to answer how many links
should be in the set in the context of dynamic network. I also agree with
the idea of some primary broadcast channel that could be "enlarged" on
dynamical basis. We can make it happen in the following way.

TSCH Pan coordinator (i.e. the first node in a TSCH network) has a set of
links to broadcast, which is configured by someone else, and propagated in
FrameAndLinkIE of EB periodically. Thus, from the FrameAndLinkIE, joining
nodes know the set of Links and use them as primary broadcast channel.
When upper layer needs more broadcast bandwidth according to traffic load,
upper layer can let 6tus add links marked as broadcast into schedule, and
also add the links into FrameAndLinkIE to notify neighbors. By propagation
of the information in FrameAndLinkIE, a "enlarged" broadcast channel is
established.

Does it make sense?

Qin

> Using a set of links for me it is ok but it requires we answer to the
> question: how many links in the set ? This answer cannot be provided once
> for all because the amount of signaling is related to the scale of the
> network, right ?
>
> This is the reason why I was proposing a narrow primary broadcast channel
> that could be "enlarged" (if required) on a dynamical basis.
>

---

From: Grieco <[email-masked]>
Date: Thu, 28 Feb 2013 23:15:00 +0100

Dear Qin,

From my point of view what you are proposing is ok.

Just to provide another opportunity of exchange of ideas, It could be also possible that application protocols ask 6tus to autonomously set up new broadcast channels when the load on the currently used channel excheed some threshold.

In other terms, why high level protocols should care about adding and striping broadcast channels ? Let 6tus do it for them.

What do you think about ?

Thanks a lot for your previous answer

Cheers

Alfredo

--
Luigi Alfredo Grieco, PhD
Assistant Professor
Department of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy
+39 080 5963 911
telematics.poliba.it/grieco
Skype id: l.alfredo.grieco
Mobile: +39 3346715672

---

From: "Qin Wang" <[email-masked]>
Date: Thu, 28 Feb 2013 20:53:38 -0800

Alfredo,

It's a good idea.

But, I think we should design the basic and mandatory functionality first,
make sure it works. And then, we can design advanced feature/functions,
making 6tus more flexible and powerful.

How do you think?

Qin

> Just to provide another opportunity of exchange of ideas, It could be also
> possible that application protocols ask 6tus to autonomously set up new
> broadcast channels when the load on the currently used channel excheed
> some threshold.
>
> In other terms, why high level protocols should care about adding and
> striping broadcast channels ? Let 6tus do it for them.
>
>>> The "primary broadcast channel" could be logical otherwise it could
>>> suffer
>>> selective EM noise.
>>>

---

From: Grieco <[email-masked]>
Date: Fri, 1 Mar 2013 08:53:27 +0100

Ok Qin, so let's add to the protocol some flexibility in order to accomodate optional fields and functionalities in the future.

Is it ok for you ?

Cheers

Alfredo