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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 1 Mar 2013 08:24:45 +0000

I agree Qin,

Fact is, we need a name for what you call a logical channel. A name that is not already overloaded 4 times. I'd suggest something like a bundle.

A bundle would be an aggregation of time slots of equal properties. A link (what IPv6 sees) becomes a set of bundles. Depending on priority, flow, multicast etc... when IP pushes a pack to a link, 6TUS will have to find which bundle within a link maps the criteria for that packet.

The question becomes what (opaque) info the IP layer needs to pass to 6TUS. And whether that information comes all form the packet or if for instance the incoming bundle for a packet is already informative enough.

On the side:
- the physical size of a bundle can be dynamic as you suggested earlier, unless we are talking to hard reservation.
- but then we have to define a fallback bundle for an dynamic bundle that is temporarily overflowing.

Cheers,

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: jeudi 28 février 2013 19:40
To: Alfredo Grieco
Cc: [email-masked]; 'Xavier Vilajosana'
Subject: 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

> 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)..
>
> I would like to know what is your opinion on that.
>
> cheers!
> Xavi
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>

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

---

From: "Qin Wang" <[email-masked]>
Date: Fri, 1 Mar 2013 08:54:00 -0800

Pascal,

Thank you for your comments. Very good point. Right now, I have not very
good answer for it. But I think it should be answered in the 6tus draft.

Qin

> I agree Qin,
>
> Fact is, we need a name for what you call a logical channel. A name that
> is not already overloaded 4 times. I'd suggest something like a bundle.
>
> A bundle would be an aggregation of time slots of equal properties. A link
> (what IPv6 sees) becomes a set of bundles. Depending on priority, flow,
> multicast etc... when IP pushes a pack to a link, 6TUS will have to find
> which bundle within a link maps the criteria for that packet.
>
> The question becomes what (opaque) info the IP layer needs to pass to
> 6TUS. And whether that information comes all form the packet or if for
> instance the incoming bundle for a packet is already informative enough.
>
> On the side:
> - the physical size of a bundle can be dynamic as you suggested earlier,
> unless we are talking to hard reservation.
> 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
>
>
>> Hi Xavi and all,
>>

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 1 Mar 2013 08:56:59 -0800

Pascal, Qin,

Quick clarifying question: what would the difference be between a bundle
and a path? The latter is defined as the set of links between
two neighbors. I guess one major difference is QoS. In that case, would a
bundle be equivalent to "path between A and B on slotframe 5"?

Thomas

On Fri, Mar 1, 2013 at 8:54 AM, Qin Wang <[email-masked]> wrote:

> > From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> > Qin Wang

---

From: "Qin Wang" <[email-masked]>
Date: Fri, 1 Mar 2013 10:46:05 -0800

Thomas,

In the discussion, "broadcast channel" is used, which is not defined very
clear. In the context of TSCH, "Channel" already has specific meaning, no
matter "physical channel" or "logic channel". So, we need some word to
denote "broadcast channel", i.e. a set of links, on which one node is in
Tx mode, neighbors are in Rx mode.

So, for me, "a bundle" is same as "a path with broadcast feature".

How do you think?

Qin

>> > - but then we have to define a fallback bundle for an dynamic bundle
>> that
>> > is temporarily overflowing.
>> >
>> > Cheers,
>> >
>> > Pascal
>> >

---

From: "Qin Wang" <[email-masked]>
Date: Fri, 1 Mar 2013 10:46:03 -0800

Thomas,

How do you think?

Qin

---

From: Michael Richardson <[email-masked]>
Date: Fri, 01 Mar 2013 14:18:42 -0500

>>>>> "pthubert" == pthubert  <Pascal> writes:
    pthubert> Fact is, we need a name for what you call a logical
    pthubert> channel. A name that is not already overloaded 4
    pthubert> times. I'd suggest something like a bundle.

    pthubert> A bundle would be an aggregation of time slots of equal
    pthubert> properties. A link (what IPv6 sees) becomes a set of
    pthubert> bundles. Depending on priority, flow, multicast
    pthubert> etc... when IP pushes a pack to a link, 6TUS will have to
    pthubert> find which bundle within a link maps the criteria for that
    pthubert> packet.

Basically this is kinda an inverse mux.
Generally, the bigger thing is called an aggregate.

It's also a construction term:
     http://en.wikipedia.org/wiki/Construction_aggregate

so, if it's an unloaded word you want, why not pick one of: sand,
gravel, stone, slag, ....  I note that it says:

  "aggregates are used as a stable foundation or road/rail base with
  predictable, uniform properties"

which seems exactly what we are trying to get...

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: "Qin Wang" <[email-masked]>
Date: Fri, 1 Mar 2013 12:09:05 -0800

"inverse mux" is a good word to describe 6tus. I would like to connect a
Mux with the inverse mux. They together work as follows.

(1)Upper layer (e.g. RPL) push message to 6tus, as input of Inverse Mux,
with information like DestAddr, Priority,....

(2)"Inverse Mux" Function, according to some rule, push the message into
corresponding Queue/Bundle/..., i.e. input of Mux.

(3)"Mux" Funtion, according to some rule, feed the packets in different
Queues/Bundles into TSCH. The reason for using Mux is that there is only
one communication action in one slot at most.

Does it make sense?

Qin

---

From: Pascal Thubert <[email-masked]>
Date: Sun, 3 Mar 2013 17:06:06 +0100

Hi Qin and Thomas:

A path in my mind denotes a set of consecutive hops that a packet may
take to go from A to B. Seems similar to route though the route is a
particular selection of candidate paths.
I think you're using path as a one hop thing. So we'll have to agree
but let us make sure that we select words that are specific and
reflect the image we want to give.

By link I want to stay close to what RPL and AUTOCONF agreed upon,
which is whatever my radio can reach. It is a one hop thing. What a
link really represents is still open. We could decide to divide the
radio in multiple subinterfaces, each one being a different link for
IP. But it seems that we are not taking that direction so far, and
that the radio interface is one link that connects to some parents and
some children, and has unicast and broadcast capabilities.

Behind the IP scene, the link is divided in time slots of different
properties. I suggested to group time slots of an exact same set of
properties as a bundle (of time slots). There would be receive bundles
from parents and children, and unicast transmission bundles to the
parents and children. And there would be at least one multicast
transmission bundle which is the one Qin is discussing.

This is what I had in mind...

Pascal

-- 
Pascal

---

From: Michael Richardson <[email-masked]>
Date: Sun, 03 Mar 2013 17:00:06 -0500

>>>>> "Qin" == Qin Wang <[email-masked]> writes:
    Qin> "inverse mux" is a good word to describe 6tus. I would like to
    Qin> connect a Mux with the inverse mux. They together work as
    Qin> follows.

    Qin> (1)Upper layer (e.g. RPL) push message to 6tus, as input of
    Qin> Inverse Mux, with information like DestAddr, Priority,....

    Qin> (2)"Inverse Mux" Function, according to some rule, push the
    Qin> message into corresponding Queue/Bundle/..., i.e. input of Mux.

    Qin> (3)"Mux" Funtion, according to some rule, feed the packets in
    Qin> different Queues/Bundles into TSCH. The reason for using Mux is
    Qin> that there is only one communication action in one slot at
    Qin> most.

    Qin> Does it make sense?

Do you put the inverse MUX above or below the 6lowpan fragmentation
layer?  Can different 6lowpan fragments travel on different slots?

---

From: "Qin Wang" <[email-masked]>
Date: Sun, 3 Mar 2013 22:48:11 -0800

Michael,

I think both inverse_mux and mux are below the 6lowpan fragmentation, i.e.
a IP packet is divided into several MAC-payloads (i.e. fragments), and the
MAC-payloads will be transmitted in several links, i.e. (slotOffset,
channelOffset).

How do you think?

Qin

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Mar 2013 10:11:23 -0500

>>>>> "Qin" == Qin Wang <[email-masked]> writes:
    Qin> I think both inverse_mux and mux are below the 6lowpan
    Qin> fragmentation, i.e.  a IP packet is divided into several
    Qin> MAC-payloads (i.e. fragments), and the MAC-payloads will be
    Qin> transmitted in several links, i.e. (slotOffset, channelOffset).

    Qin> How do you think?

I know that when you fragment, you very poor ETX or high congestion if
the fragments get lost.  Multipathing the fragments seems to guarantee
that different fragments might get lost.  How do we know what paths are
broken (and avoid them at layer 3) if no packets are assembled because a
fragment was always lost. 

I think therefore that while it might be acceptable for application
layer data to be multi-pathed, I think that RPL packets need to stick to
a single path at a time.

---

From: "Qin Wang" <[email-masked]>
Date: Mon, 4 Mar 2013 08:52:44 -0800

Michael,

By my understanding, selecting next hop neighbor is the responsibility of
L3, e.g. RPL, instead of 6tus. Thus, all of the fragments from one packet
should go to one neighbor. But, 6tus will provide statistics to tell upper
layer the link quality with each neighbor. In 6tus and TSCH, the way to
improve link quality is channel hopping.

I think the interface between 6tus and upper layer is something like
following.
- SendData.request (DestAddr, Priority, MessageLen, Message, ....)
- SendData.confirm (..., Status)

The Status in SendData.confirm will tell upper layer if the sending is
successful or not, and then upper layer can do Retry, assemble, or other
operation.

How do you think?

Qin

---

From: Tom Phinney <[email-masked]>
Date: Mon, 04 Mar 2013 10:45:09 -0700

L3 specifies the next L3 neighbor. Because of the
information hiding that occurs due to layering, L3 cannot be aware
of the detailed substructure within and internal organization of
L2. Thus it is an L2 responsibility to determine and specify the
next L2 neighbor in the route to that next L3 neighbor, as well as
the ultimate L2 address that corresponds to that next L3 neighbor
(which often is the L2 address of either a backbone router, for
transmissions out of the wireless subnet, or of the addressed
endpoint device, for transmissions from the backbone into the
wireless subnet).

The history of networking shows pretty conclusively that proper
layering leads to longevity and reuse of components, whereas
hybridization of layers leads to short-lived solutions that are
difficult or impossible to maintain as the individual employed
technologies evolve.

It is worth noting that it is possible for intermediary L2 nodes
to obtain L3 information from a conveyed L3 PDU without violating
layering (by invoking a local L3 method that legitimately looks
into the conveyed L3 PDU at the relaying L2 node), but that
approach does not work when the L2 PDU that is being relayed
contains a non-initial fragment of the L3 PDU. In that case the
originating L2 node needs to use a local L3 method to extract the
L3 information from the L3 PDU, or obtain it as interface control
information when the L3 SDU is passed to L2, and then prepend it
as an additional header to the conveyed L3 fragment within the L2
PDU so that the intermediate L2 relays have access to that
information. The types of information where such "hinting" or
duplicate conveyance is appropriate might be priority, flow
labeling, or other aspects that would affect the forwarding
behavior of those intermediary L2 relays.

===

On 2013.03.04 09:52, Qin Wang wrote:

Michael,

How do you think?

Qin

Qin> How do you think?

---

From: Robert Assimiti <[email-masked]>
Date: Tue, 5 Mar 2013 02:27:10 +0000

Pascal,

I have a suggestion. Rather than defining the priorities and traffic flows associated with them, we should provide a framework and mechanism that support various priorities.

In order to support prioritized traffic flows one would have to come up with a priority based media access scheme.

This could be accomplished by:

1. Using prioritized links 
2. Using prioritized slotframes
3. ??? other schemes

All of these require 802.15.4e-TSCH enhancements/additions. 

Robert Assimiti

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, February 26, 2013 6:07 AM
To: Maria Rita PALATTELLA; Xavier Vilajosana; [email-masked]
Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH

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,
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

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 4 Mar 2013 22:59:00 -0800

+1

What is your opinion on Qin's suggestion to have a priority translating
into queues/bundles? (Qin, please correct me if I'm wrong).

TSCH assigns a priority to slotframes, and leaves the rest for us to figure
out. I have a hard time deciding whether our discussions suggest that:
1. slotframe priority is much too coarse and what we need is really
bundle-based priorities, OR
2. what we are inventing for bundles can really be achieved by using
good-old slotframes, and that all we are discussing (including queuing) is
actually already present in TSCH. That is, we can apply everything we are
discussing in the context of a bundle to a slotframe: we would end up
having a slotframe per type of traffic, i.e. a final destination and a QoS
level. Slotframes could also encompass label switching (i.e. packet I
receive on RX links of slotframe 3 need to be sent on TX links of the same
slotframe). The only thing missing is that you need to write the slotframe
ID in the packet in case you have two TX cells in the same slot.

Again, while this is a very open-ended question, it has a big impact of our
next steps, and I'd like to get the list's opinion.

I'd like to avoid as much as possible to reinvent concepts that are already
present. Looking forward to being proven wrong.

Thomas

On Mon, Mar 4, 2013 at 6:27 PM, Robert Assimiti
<[email-masked]>wrote:

> Pascal,
>
> I have a suggestion. Rather than defining the priorities and traffic flows
> associated with them, we should provide a framework and mechanism that
> support various priorities.
>
> In order to support prioritized traffic flows one would have to come up
> with a priority based media access scheme.
>
> 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
>
>
> >>>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).
>
> 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.
>
> 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)
>
> 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?
> 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)..
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 5 Mar 2013 08:21:21 +0000

Hello Robert:

Yes, certainly. 

The only priority we want to define is that of the flow we control, that is, RPL, and management (PCE commands), and that much will be easy since it is network priority.

I have to learn more on the MAC to be helpful, but I can see that:
- we start up with enough QoS-ruled bundles to boot the network. In those bundles, QoS determines priority and network priority is the highest.
- we build hard reserved tracks for critical flows, and the mapping to bundles and then cells is plain. 
- we also build lazy tracks where cells on the way may need to be allocated to cope to extra traffic. In that case, packets may be degraded to QoS-ruled bundles, or dropped.
- and then we have all the traffic of lesser criticality that plays with traditional QoS in QoS-ruled bundles.
 
For all those, we'll need to define DSCPs and per hop behavior. Shitanshu (cc'ed) is helping us on that.

Cheers,

Pascal

-----Original Message-----
From: Robert Assimiti [mailto:[email-masked]] 
Sent: mardi 5 mars 2013 03:27
To: Pascal Thubert (pthubert); Maria Rita PALATTELLA; Xavier Vilajosana; [email-masked]
Subject: RE: [6tsch] DIOs/DAOs and broadcast channels on TSCH

Pascal,

Robert Assimiti

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, February 26, 2013 6:07 AM
To: Maria Rita PALATTELLA; Xavier Vilajosana; [email-masked]
Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH

Hi Xavi and Maria-Rita:

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, 5 Mar 2013 09:19:58 -0800

Thomas,

Here is example to explain what my problem is.

Assume: there are two slotframes: slotframe-1, length=16; slotframe-2,
length=64. By the current definition of slotframe priority, slotframe-1
has higher priority. The two slotframes start from ASN=0.

Assume: for nodeA to nodeB, there are 1 Tx slot in slotframe-1, saying
slot 7; there are 2 Tx slots in slotframe-2, saying slot-16 and slot-48.

Assume: when ASN=47, there are two packets in the queue, with priority Low
and High, respectively.

Then, the question is: in slot-48, which packet will be transmitted? If
thinking packet priority should be associated with slotframe priority,
then, the packet with Low priority should be sent out. But, if thinking
the QoS of data flow, the packet with High priority should be sent out.

That is the problem in my mind. Do I miss something?

Qin

>> Pascal Thubert (pthubert)
>> For all 3, transmission is statistical, and all 3 will be governed by
>> QoS
>> as opposed to reservation.
>>
>> Maria Rita PALATTELLA
>> from my point of view, having a TSCH broadcast channel could be useful
>> in
>> several situations:
>>
>> the
>> use
>> Xavier Vilajosana
>> need
>> schedule

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 5 Mar 2013 19:58:44 -0800

Qin,

What I mean is that slotframe identifiers could be chosen according to the
priority of the data they carry. If you assign identifiers 1 and 2 to the
slotframes in your example, it's because you consider the traffic sent on
slotframe 1 to be more important that slotframe 2. When sending a packet, a
higher layer indicates the priority of the packet, here 1 or 2. That packet
will then be transmitted on the corresponding slotframe. Of course, if at a
particular slot two packets can be transmitted, the one with highest
priority wins.

What I'm trying to get at it that we don't have to consider that there is
one slotframe, in which slots are assigned one of n priorities, but rather
n slotframes, each of a given priority.

Thomas

---

From: Kris Pister <[email-masked]>
Date: Tue, 05 Mar 2013 20:37:17 -0800

+1

On 3/5/2013 7:58 PM, Thomas Watteyne wrote:
> Qin,
>
> What I mean is that slotframe identifiers could be chosen according to 
> the priority of the data they carry. If you assign identifiers 1 and 2 
> to the slotframes in your example, it's because you consider the 
> traffic sent on slotframe 1 to be more important that slotframe 2. 
> When sending a packet, a higher layer indicates the priority of the 
> packet, here 1 or 2. That packet will then be transmitted on the 
> corresponding slotframe. Of course, if at a particular slot two 
> packets can be transmitted, the one with highest priority wins.
>
> What I'm trying to get at it that we don't have to consider that there 
> is one slotframe, in which slots are assigned one of n priorities, but 
> rather n slotframes, each of a given priority.
>
> Thomas
>
> On Tue, Mar 5, 2013 at 9:19 AM, Qin Wang <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Thomas,
>
>     > Again, while this is a very open-ended question, it has a big
>     impact of
>     > our
>     > <[email-masked] <mailto:[email-masked]>>wrote:
>     >
>     >> Pascal,
>     >>
>     >> I have a suggestion. Rather than defining the priorities and
>     traffic
>     >> flows
>     >> From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf
>     >> Of
>     <mailto:[email-masked]>
>     >> given packet may be unicast) or any child to parent (shared
>     emission
>     >> with
>     >> contention) traffic.
>     >>
>     >> Is that doable?
>     >>
>     >> Pascal
>     >>
>     >>
>     >> From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf
>     >> Of
>     >> Maria Rita PALATTELLA
>     >> To: Xavier Vilajosana; [email-masked] <mailto:[email-masked]>
>     >> independent of the broadcast channel set for ADV? can it be the
>     same? Or
>     >> in
>     >>  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
>     >> synchronization, having a broadcast channel dedicated to the
>     signaling
>     >> will
>     >> Maybe, because there are 16 available channels in
>      IEEE802.15.4/15.4e
>     >> PHY,
>     >> cross-layer info/set up of the schedule wouldn't  be a big
>     problem. In
>     >> many
>     >> From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf
>     >> Of
>     >> Xavier Vilajosana
>     >> To: [email-masked] <mailto:[email-masked]>
>     >> independent of the broadcast channel set for ADV? can it be the
>     same? Or
>     >> in
>     >> [email-masked] <mailto:[email-masked]>
>     >> [email-masked] <mailto:[email-masked]>
>     >> [email-masked] <mailto:[email-masked]>
>     >> [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 08 Mar 2013 21:19:44 -0500

>>>>> "Maria" == Maria Rita PALATTELLA <[email-masked]> writes:
    Maria> 3) transmission of signaling messages for setting up the
    Maria> schedule. Let's assume there is a scheduler that builds the
    Maria> schedule for the network. In order to assign some links to
    Maria> each of them, it will need to broadcast the information
    Maria> related to ( timeOffset, ChannelOffset). As for the
    Maria> synchronization, having a broadcast channel dedicated to the
    Maria> signaling will allow to set up the schedule in shorter time.

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

Are there multicasts that need to go out other than RPL DIOs?
Those will go out based upon trickle... in a stable network, the DIOs
will be rare compared to actual traffic... if the network data is also
so light as to be able to easily allocate many channels, then... why
doesd not need 6tsch at all... the LLN should have lots of bandwidth to
get the controls through.

So it seems to me that really taking any channels up for broadcast would
be a bad idea if there are other options.

-- 
Michael Richardson
-on the road-

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Mon, 11 Mar 2013 08:48:50 +0000

Michael, thanks for your feedbacks.
Right, I see your point, and I do agree. 
What about setting a broadcast channel  periodically,   when on-average there is need to exchange multi-cast traffic?
Maria Rita

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Saturday, March 09, 2013 3:20 AM
To: [email-masked]
Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH

Are there multicasts that need to go out other than RPL DIOs?
Those will go out based upon trickle... in a stable network, the DIOs will be rare compared to actual traffic... if the network data is also so light as to be able to easily allocate many channels, then... why doesd not need 6tsch at all... the LLN should have lots of bandwidth to get the controls through.

So it seems to me that really taking any channels up for broadcast would be a bad idea if there are other options.

--
Michael Richardson
-on the road-

---

From: Kris Pister <[email-masked]>
Date: Mon, 11 Mar 2013 09:20:46 -0700

Maria Rita -
  Does a single Aloha slot plus a trickle timer provide what we need for 
broadcast?  It seems like it should.

I was assuming that a DODAG root (PAN coordinator) would pick a frame 
length and slot parameters and start advertising a single Aloha slot in 
that frame.  Depending on the type of network, most traffic would 
quickly move off of this fixed, shared resource into dedicated 
appropriately-scheduled cells, leaving it free for "random" traffic, 
such as broadcast.

If I were (hypothetically) sending signaling messages from a PCE, I 
would not use a broadcast channel in most networks.  Rather, I would set 
up a dedicated "downstream" slotframe with one non-colliding multicast 
cell from each parent to its children.  That also creates a 
broadcast-capable MAC graph, but allows much faster propagation. In any 
case, whether it's Aloha or a non-colliding tree that provides the 
connectivity, I'd source route as far down as possible to minimize 
overhead traffic on all of the other nodes.

Also, I agree that using fewer than 16 channels is acceptable for 
building reliable schedules.  Somewhere around 3--5 channels gets you 
most of the multi-path resilience that you'll get with 16.  This is 
important for those who must blacklist due to customer constraints 
(typically irrational constraints, but...).  I just wanted to clarify 
that when you suggested "using some of them as broadcast channels" that 
you meant using dedicated channel offsets, not actual radio channels.  
In terms of available cell bandwidth, the impact is the same, but in 
terms of reliability the difference is huge.

ksjp

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Tue, 12 Mar 2013 07:40:49 +0000

Kris, I see your points, and I think we are aligned.
Thanks for clarifying what I meant for broadcast channels, I was actually talking about channel offsets.
Maria Rita

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kris Pister
Sent: Monday, March 11, 2013 5:21 PM
To: [email-masked]
Subject: Re: [6tsch] DIOs/DAOs and broadcast channels on TSCH

Maria Rita -
  Does a single Aloha slot plus a trickle timer provide what we need for broadcast?  It seems like it should.

I was assuming that a DODAG root (PAN coordinator) would pick a frame length and slot parameters and start advertising a single Aloha slot in that frame.  Depending on the type of network, most traffic would quickly move off of this fixed, shared resource into dedicated appropriately-scheduled cells, leaving it free for "random" traffic, such as broadcast.

If I were (hypothetically) sending signaling messages from a PCE, I would not use a broadcast channel in most networks.  Rather, I would set up a dedicated "downstream" slotframe with one non-colliding multicast cell from each parent to its children.  That also creates a broadcast-capable MAC graph, but allows much faster propagation. In any case, whether it's Aloha or a non-colliding tree that provides the connectivity, I'd source route as far down as possible to minimize overhead traffic on all of the other nodes.

Also, I agree that using fewer than 16 channels is acceptable for building reliable schedules.  Somewhere around 3--5 channels gets you most of the multi-path resilience that you'll get with 16.  This is important for those who must blacklist due to customer constraints (typically irrational constraints, but...).  I just wanted to clarify that when you suggested "using some of them as broadcast channels" that you meant using dedicated channel offsets, not actual radio channels.  
In terms of available cell bandwidth, the impact is the same, but in terms of reliability the difference is huge.

ksjp

On 2/25/2013 11:55 PM, Maria Rita PALATTELLA wrote:
> Of Xavier Vilajosana