Subject: [6tsch] 6tsch definitions

From: Thomas Watteyne <[email-masked]>
Date: Sun, 3 Mar 2013 15:56:50 -0800

All,

>From the discussions in the "DIOs/DAOs and broadcast channels on TSCH"
thread, it appears apparent that the IEEE802.15.4e standard uses terms
which are confusing, especially when taken into a broader context.

For example:
- "link"
   . in IEEE802.15.4e: "single slot scheduled from A to B"
   . general definition: generic term for single-hop connection, often
related to broadcast domain
- "path"
   . IEEE802.15.4e: "group of links between A and B"
   . general definition: multi-hop route between source and destination.

We are often confused ourselves at those "colliding" definitions, so I
believe there is a need to provide some definitions. This can be done as
part of a next revision of
http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01, or
some other draft if considered appropriate by the group.

What follows is a number of terms, and tentative definitions. Let's
edit/circulate this e-mail for a couple of days, then decide what makes it
into the official definitions list.

- slot:
   - A timeslot in the TSCH schedule. A slot can be scheduled or
unscheduled. During an *unscheduled* slot, the node does not communicate.
When a slot is *scheduled*, it is assigned a slotframe, it is assigned a
neighbor address (which can be the broadcast address), and one of more of
the following flags: TX, RX, shared, timeskeeping, hard. A *broadcast *slot
is an alias for "a scheduled slot with neighbor address the broadcast
address".
   - note: this term would replace the term "link" in the IEEE802.15.4e
standard.
- bundle:
   - A group of equivalent scheduled slots, i.e. slots which are scheduled,
on the same slotframe, with the same neighbor and with the same flags. The *
size* of the bundle refers to the number of slots it contains. Given the
length of the slotframe, the size of the bundle translates directly into
reserved bandwidth.
- (inversed) mux:
   - *Qin*, would you mind giving a tentative definition here?

Thomas

---

From: Pascal Thubert <[email-masked]>
Date: Mon, 4 Mar 2013 07:29:26 +0100

Thomas:

I agree with the problem and like your definitions. This tells me that
we need to start our own terminology document.
I'd suggest it includes ROLL's which is going to IESG review, as well
as AUTOCONF, both by reference so that it stays strictly consistent.

cheers,

Pascal

2013/3/4 Thomas Watteyne <[email-masked]>:
> thread, it appears apparent that the IEEE802.15.4e standard uses terms which
> are confusing, especially when taken into a broader context.
>
> For example:
> - "link"
> http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01, or some
> other draft if considered appropriate by the group.
>
> unscheduled. During an unscheduled slot, the node does not communicate. When
> a slot is scheduled, it is assigned a slotframe, it is assigned a neighbor
> address (which can be the broadcast address), and one of more of the
> following flags: TX, RX, shared, timeskeeping, hard. A broadcast slot is an
> alias for "a scheduled slot with neighbor address the broadcast address".
> on the same slotframe, with the same neighbor and with the same flags. The
> size of the bundle refers to the number of slots it contains. Given the
>    - Qin, would you mind giving a tentative definition here?
>
> Thomas
>
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>

-- 
Pascal

---

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

Thomas,

In my mind, there is a picture described as follows.

IP packet => 6LowPan.Fragment => (inverse_mux => mux) => TSCH

Where inverse_mux and mux are two modules of 6tus.

(1)inverse_mux: input includes DestAddr, Priority, MAC_payload, and
others; output is a group of bundles (or queues). The function of
inverse_mux is pushing the MAC_payload into one bundle according to the
DestAddr and Priority.

(2)mux: input parallel all of the bundles; and corresponding to each
active link in TSCH schedule, mux will output a packet which is selected
from the first elements of each bundle, according to the feature of the
active link and QoS policy of selection run by the mux. The packet will be
transmitted in the active link by TSCH.

Is it clear?

Qin

> *

---

From: Pascal Thubert <[email-masked]>
Date: Mon, 4 Mar 2013 07:41:11 +0100

Hello Qin,

I understand the concepts and the need for mux and i-mux.
What I do not see in your definition is the abstract concept of flow
which maps a particular track (which I would define as a particular -
reserved - sequence of bundles along a path).
Probably everything is in the packet (flow label?) but maybe not.
maybe the track is identified by the incoming bundle that must match
teh outgoing bundle along the track so there is an track-ID somewhere
in your parameters...

Cheers,

Pascal

-- 
Pascal

---

From: "Qin Wang" <[email-masked]>
Date: Sun, 3 Mar 2013 23:06:30 -0800

Pascal,

Let me give a example. Assume, there is two broadcast bundles, with
priority High and Low; There are three unicast bundles, with priority
High, Mid, and Low. The interface to upper layer is as follows.

SendData.request (DestAddr, Priority, MesseageLen, Message,SecurityLevel,..)

The inverse_mux receive the request, and push the message into
corresponding bundle according to the DestAddr (broadcast/unicast) and
Priority.

If the next active link in TSCH schedule is featured as broadcast link,
mux will choose one packet from the two broadcast bundles according to QoS
policy, e.g. packet in high priority bundle should be transmitted first.

similarly, if the next active link is featured as unicast link, mux will
choose one packet, which has matched DestAddr, from higher priority
bundle.

The selected packet will be transmitted in the link by TSCH.

Does I answer your question?

Qin

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Mon, 4 Mar 2013 07:44:55 +0000

Thomas,

I totally agree with you and Pascal about the need of  introducing  ad-hoc definitions for 6tus, in order to avoid any kind of confusion when integrating IEEE802.15.4e with 6LoWPAN, RPL and other standards.

Maybe it is the case to have a specific draft, including all the definitions we may need,  and keep the other draft as a general overview of problems and goals. What do you think?

Even though I like your definition of "slot" scheduled/unscheduled/broadcast, I have a "little" concern. In our discussion we are not taking in account that the link definition in IEEE802.15.4e includes also the channel offset value.  In fact, a node A needs to know not only the time slot, but also the channel offset (and thus, the frequency) on which it will be allowed to transmit to a its parent node B.

Shall we then use another type of definition, like RESERVED/UNRESERVED CELL  or Scheduled/Unscheduled cell, where a CELL within the slotframe's grid  is given by   (time slot, channel offset) .

The same concern comes when we define the path. We have somehow to specify that each equivalent slot may be scheduled  on different channel offset.  So, according to your definition,  they are  "slots which are scheduled, on the same slotframe, with the same neighbor and with the same flags, on the same and/or different channel offsets".

Maria Rita

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Monday, March 04, 2013 12:57 AM
To: IETF 6TSCH
Subject: [6tsch] 6tsch definitions

All,

>From the discussions in the "DIOs/DAOs and broadcast channels on TSCH" thread, it appears apparent that the IEEE802.15.4e standard uses terms which are confusing, especially when taken into a broader context.

For example:
- "link"
   . in IEEE802.15.4e: "single slot scheduled from A to B"
   . general definition: generic term for single-hop connection, often related to broadcast domain
- "path"
   . IEEE802.15.4e: "group of links between A and B"
   . general definition: multi-hop route between source and destination.

We are often confused ourselves at those "colliding" definitions, so I believe there is a need to provide some definitions. This can be done as part of a next revision of http://tools.ietf.org/html/draft-watteyne-6tsch-tsch-lln-context-01, or some other draft if considered appropriate by the group.

What follows is a number of terms, and tentative definitions. Let's edit/circulate this e-mail for a couple of days, then decide what makes it into the official definitions list.

- slot:
   - A timeslot in the TSCH schedule. A slot can be scheduled or unscheduled. During an unscheduled slot, the node does not communicate. When a slot is scheduled, it is assigned a slotframe, it is assigned a neighbor address (which can be the broadcast address), and one of more of the following flags: TX, RX, shared, timeskeeping, hard. A broadcast slot is an alias for "a scheduled slot with neighbor address the broadcast address".
   - note: this term would replace the term "link" in the IEEE802.15.4e standard.
- bundle:
   - A group of equivalent scheduled slots, i.e. slots which are scheduled, on the same slotframe, with the same neighbor and with the same flags. The size of the bundle refers to the number of slots it contains. Given the length of the slotframe, the size of the bundle translates directly into reserved bandwidth.
- (inversed) mux:
   - Qin, would you mind giving a tentative definition here?

Thomas

---

From: Xavier Vilajosana <[email-masked]>
Date: Mon, 04 Mar 2013 14:48:39 -0800

Hi,

as regard to a path, IMHO is the upper layer (above 6tus) who might take 
care of building the paths and maintaining them (or at least use 6tus to 
maintain them). If we look at a path node by node we can see a bundle at 
each node pointing to  its parent (the node's parent in the path). 6tus 
can be in charge of monitoring that the bandwidth requirement is being 
met (i.e whether the bundle needs more slots or not). The use of a flow 
label depends on the path reservation protocol (i.e RSVP or an extension 
to RPL) and the use of a mapping between "input bundle id and output 
bundle id" can be embedded in the packet (as a label) or keep it locally 
in each node as a switching table (i.e in node A all the packets that 
arrive at bundle X leave the node at bundle Y) .

with respect to the mux - i-mux function, If I don't understand 
incorrectly the role of the mux is to act as a selector of which packet 
needs to be sent at a particular timeslot (according to certain 
priority, and other options, etc..). i-mux feeds 6tus with packets and 
according to a configuration, mux determines the packet that needs to be 
sent in the upcoming slot.

Qin am I wrong?
X

---

From: "Qin Wang" <[email-masked]>
Date: Mon, 4 Mar 2013 15:28:32 -0800

Xavi,

Regarding the function of mux, you are right. For i-mux, I want to clarify
my thought. i-mux is also part of 6tus, which function is to shape data
flow, i.e. push incoming packets into proper bundle queue. I call it
bundle queue, because the element in the queue have same properties, like
broadcast/unicast, priority.

Regarding to the definition of "Path", there is some difference between
your thought and Thomas's definition. In Thomas's document:

**The union of all links between two neighbors, A and B, is called a
"path".**

My understanding is Thomas use "Path" refer to one hop connection, instead
of multi-hop route. But because the one hop connection is part of
end-to-end route, its bandwidth is also required by the protocols like
RSVP.

Make sense?

Qin

---

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

Thomas,

Before I can add some about mux, we need to discuss more about the
definition of "bundle". We have two different angle to use the word of
bundle now.

(1) One angle is to describe the communication resource of TSCH, i.e. like
your defined, bundle is a set of links (or slots, BTW, I prefer "Link"),
which have some common features, like same slotframe, same flag, same
neighbors.

(2) Another angle is to describe the incoming data flow in order to shape
data flow and meet QoS requirements, which is the meaning of bundle in
i-mux -mux.

The two kinds of bundle may be mapping to each other one by one, may be
not. IMHO, we need the two angles, because the first one is useful in
building and maintaining schedule; and the second one is useful in data
convey from upper layer to TSCH after the communication schedule has be
established.

So, maybe we need two terms for the two purpose, respectively? How do you
think?

Qin

---

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

Pascal,
I second that, adding ROLL and.AUTOCONF makes perfect sense.
Thomas

On Sun, Mar 3, 2013 at 10:29 PM, Pascal Thubert <[email-masked]>wrote:

> which
> some

---

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

Maria Rita,

I agree that a cell (or whatever we end up calling it) is assigned a
channel offset, and that in a network, multiple cells can occur at the same
time, yielding simultaneous communication between different pairs of motes
at difference frequencies.

Yet, a single mote can only do one thing at a time, and so at a given
timeslot, it will have to pick which cell to execute if it has multiple in
its schedule at that timeslot (does this make sense?). My idea was simply
to call it slot (which is rather common in TDMA), but I'm perfectly happy
calling it cell if people agree that it's not confusing.

What do others think: slot or cell?

Thomas

On Sun, Mar 3, 2013 at 11:44 PM, Maria Rita PALATTELLA <
[email-masked]> wrote:

>  Thomas,****
>
> ** **
>
> I totally agree with you and Pascal about the need of  introducing  ad-hoc
> definitions for 6tus, in order to avoid any kind of confusion when
> integrating IEEE802.15.4e with 6LoWPAN, RPL and other standards. ****
>
> ** **
>
> Maybe it is the case to have a specific draft, including all the
> definitions we may need,  and keep the other draft as a general overview of
> problems and goals. What do you think?****
>
> ** **
>
> Even though I like your definition of “slot”
> scheduled/unscheduled/broadcast, I have a “little” concern. In our
> discussion we are not taking in account that the link definition in
> IEEE802.15.4e includes also the *channel offset* value.  In fact, a node
> A needs to know not only the time slot, but also the channel offset (and
> thus, the frequency) on which it will be allowed to transmit to a its
> parent node B.****
>
> ** **
>
> Shall we then use another type of definition, like RESERVED/UNRESERVED
> CELL  or Scheduled/Unscheduled cell, where a CELL within the slotframe’s
> grid  is given by   (time slot, channel offset) .****
>
> ** **
>
> The same concern comes when we define the path. We have somehow to specify
> that each equivalent slot may be scheduled  on different channel offset.
>  So, according to your definition,  they are  “slots which are scheduled,
> on the same slotframe, with the same neighbor and with the same flags, on
> the same and/or different channel offsets”.****
>
> ** **
>
> Maria Rita****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Thomas Watteyne
> *Sent:* Monday, March 04, 2013 12:57 AM
> *To:* IETF 6TSCH
> *Subject:* [6tsch] 6tsch definitions****
>
> ** **
>
> All,****
>
> ** **
>
> which are confusing, especially when taken into a broader context.****
>
> ** **
>
> For example:****
>
> - "link"****
>
>    . in IEEE802.15.4e: "single slot scheduled from A to B"****
>
> related to broadcast domain****
>
> - "path"****
>
>    . IEEE802.15.4e: "group of links between A and B"****
>
>    . general definition: multi-hop route between source and destination.**
> **
>
> ** **
>
> some other draft if considered appropriate by the group.****
>
> ** **
>
> into the official definitions list.****
>
> ** **
>
> - slot:****
>
> address".****
> standard.****
> - bundle:****
>    - A group of equivalent scheduled slots, i.e. slots which are
> scheduled, on the same slotframe, with the same neighbor and with the same
> flags. The *size* of the bundle refers to the number of slots it
> contains. Given the length of the slotframe, the size of the bundle
> translates directly into reserved bandwidth.****
>
> - (inversed) mux:****
>
>    - *Qin*, would you mind giving a tentative definition here?****
>
> ** **
>
> Thomas****
>

---

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

Qin,

[Quick questions about definition: do you mean that you prefer the term
link over slot or cell? Are you not afraid that people will mistake a TSCH
link with, say a broadcast domain? I believe this is what started this
thread. If you do not agree, please speak up.]

In my mind, a bundle is a group of slots which are entirely equivalent.
That is, once a packet has made it into some queue, it can go out on any
slot of the bundle. That is, there can be multiple bundles from mote A to
mote B. Does this definition work for you? I can absolutely be convinced
otherwise, but, if possible, I'd like to keep the number of new definitions
are concepts to a minimum, so if possible keep a single term.

Thoughts?

Thomas

On Mon, Mar 4, 2013 at 3:52 PM, Qin Wang <[email-masked]> wrote:

> > scheduled,

---

From: "Alfredo Grieco" <[email-masked]>
Date: Tue, 5 Mar 2013 10:47:09 +0100

Hi All,
 
Why not speaking about Resource Block (as in cellular systems) to identify a
time slot-channel pair ?
 
Cheers
 
Alfredo
 
Da: [email-masked] [mailto:[email-masked]] Per conto di
Thomas Watteyne
Inviato: Tuesday, March 05, 2013 7:40 AM
A: IETF 6TSCH
Oggetto: Re: [6tsch] 6tsch definitions
 
Qin,
 
[Quick questions about definition: do you mean that you prefer the term link
over slot or cell? Are you not afraid that people will mistake a TSCH link
with, say a broadcast domain? I believe this is what started this thread. If
you do not agree, please speak up.]
 
In my mind, a bundle is a group of slots which are entirely equivalent. That
is, once a packet has made it into some queue, it can go out on any slot of
the bundle. That is, there can be multiple bundles from mote A to mote B.
Does this definition work for you? I can absolutely be convinced otherwise,
but, if possible, I'd like to keep the number of new definitions are
concepts to a minimum, so if possible keep a single term.
 
Thoughts?
 
Thomas

Qin

---

From: "Qin Wang" <[email-masked]>
Date: Tue, 5 Mar 2013 08:32:41 -0800

Thomas,

I think, comparing with "slot", "link" carries more information like
channelOffset; comparing with "cell", "link" has more sense about
communication. But, indeed, "link" may cause some confuse. So, if everyone
prefers "slot" or "cell" or other term, I have no problem.

I agree with you that we should limit definition in minimum. With the
following definition of bundle, I just have one problem, i.e. whether the
priority is part of the bundle features or not? If yes, how to give a
bundle a priority and how to use the priority? If not, how to feed the
packets with different priorities in the queue to the bundle(s), FIFO, or
something else?

Thanks

Qin

>> > edit/circulate this e-mail for a couple of days, then decide what
>> makes
>> it