Subject: [6tisch] SCHEDULE - ALLOCATE - RESERVE - USE : terminology related to time slot allocation & OTF

From: Maria Rita PALATTELLA <[email-masked]>
Date: Tue, 10 Dec 2013 15:32:35 +0000

Dear all,

following the trend on the ML about the "time slot allocation" and the OTF draft, I think we need to discuss about the terminology to adopt when we talk about cells within a bundle,  or chunk, their reservation and actual allocation for a transmission.

Right now, the terms "schedule", "reserve", "allocate" are often used in different contexts.

So far we have defined cell and bundle as follow:

Cell: A single element in the TSCH sloframe, identified by a slotOffset value, a channelOffset value, a slotframe_ID   and Hopping_Sequence_ID.  A cell can be scheduled or  unscheduled.  During an unscheduled cell, the node does  not communicate. When a cell is scheduled, it is  assigned a MAC-layer slotframe identifier, a neighbor MAC  address (which can be the broadcast address), and one or  more of the following flags: TX, RX, shared, timeskeeping, hard.  A broadcast cell is an alias for "a  scheduled cell with neighbor address the broadcast  address".

Bundle:  A group of equivalent scheduled cells, i.e. cells identified by different [slotOffset, channelOffset], which are scheduled for a same purpose, with the same neighbor, with the same flags, and the same slotframe. The size of the bundle refers to the number of cells it  contains.  Given the length of the slotframe, the size of the bundle translates directly into bandwidth, either logical, or physical.

According to this, a cell within a bundle is scheduled, i.e., assigned (or reserved) to a specific couple of nodes. But this doesn't imply that it is actually used for an on-going transmission. Right?

Thus, we need another term for expressing that a cell is really used, (i.e., there is a pkt transmission during that time slot). What about "allocation for pkt transmission"?
In this way, a cell within a bundle is scheduled according to a scheduling algorithm, but it is  allocated afterward, according to the network conditions (e.g., current traffic, queue congestion level, nextMoreBits, etc), using specific policies.
Obviously, a cell can be allocated only if it is scheduled. An unscheduled cell cannot be allocated.

If we agree to use this terminology:
Cell/bundle scheduled: assigned/reserved to a specific couple of nodes
Cell/Bundle allocated/used for a specific pkt transmission

then expressions like "cells allocated but not used within the bundle...' are not allowed, and  the terms "reserve" and "allocate" cannot be interchanged.

I don't know if you prefer to use the term "allocate" as synonymous of  "schedule" (meaning allocated for a specific couple of nodes, but not necessarily for a packet transmission!!!) and then the term "use" for specifying when  a cell is really used for a packet transmission.

In any case, we will need to agree on the terminology to use, in order to keep in writing the OTF draft and discussing on the time slot allocation, without getting lost!

Hoping it is not me to have done confusion, I look forward to receiving your feedback!
Thank you!

Maria Rita

---

From: Qin Wang <[email-masked]>
Date: Thu, 12 Dec 2013 10:01:48 +0800

Hi Maria Rita,

I completely agree to clarify those terms.

According to my understanding, the feature of the cells in a bundle is
different from the cells in a chunk. The cells in a bundle will be used by
TSCH directly, but the cells in a chunk are managed in 6top and TSCH can
not see the pool. Therefore,

(1) Regarding to the cells in a bundle, "schedule" and "allocate" refers to
same operation, i.e. binding a (slotFrame,(slotOffset,channelOffset)) to a
(neighborAddr, Tx/Rx). Just picking one of them is fine. And, whether the
cell is actually used at a specific slotFrame is determined by TSCH based
on if there is a pkt needed to be send (if it is a Tx cell). Thus, I think
it is unnecessary for 6top to define the operation of using a cell for
specific pkt transmission.

(2) Regarding to the size of bundle, I prefer "reserve" and "remove". The
requirement will come from upper layer like OTF to 6top, and be implemented
by calling 6top commands.

(3) Regarding to the cells in a chunk, we can say "reserve/remove X cells
for chunk Y". The requirement will come from upper layer. We need to add
some more 6top commands to support its implementation.

What do you think?

Qin

On Tue, Dec 10, 2013 at 11:32 PM, Maria Rita PALATTELLA <
[email-masked]> wrote:

>  Dear all,
>
>
>
> following the trend on the ML about the “time slot allocation” and the OTF
> draft, I think we need to discuss about the terminology to adopt when we
> talk about cells within a bundle,  or chunk, their reservation and actual
> allocation for a transmission.
>
>
>
> Right now, the terms “schedule”, “reserve”, “allocate” are often used in
> different contexts.
>
>
>
> Cell: A single element in the TSCH sloframe, identified by a slotOffset
> value, a channelOffset value, a slotframe_ID   and Hopping_Sequence_ID.  A
> cell can be scheduled or  unscheduled.  During an unscheduled cell, the
> node does  not communicate. When a cell is scheduled, it is  assigned a
> MAC-layer slotframe identifier, a neighbor MAC  address (which can be the
> broadcast address), and one or  more of the following flags: TX, RX,
> shared, timeskeeping, hard.  A broadcast cell is an alias for "a  scheduled
> cell with neighbor address the broadcast  address".
>
>
>
> Bundle:  A group of equivalent scheduled cells, i.e. cells identified by
> different [slotOffset, channelOffset], which are scheduled for a same
> purpose, with the same neighbor, with the same flags, and the same
> slotframe. The size of the bundle refers to the number of cells it
>  contains.  Given the length of the slotframe, the size of the bundle
> translates directly into bandwidth, either logical, or physical.
>
>
>
>
>
> According to this, a *cell within a bundle is scheduled, i.e., assigned
> (or reserved) to a specific couple of nodes*. But this doesn’t imply that
> it is actually used for an on-going transmission. Right?
>
>
>
> Thus, we need another term for expressing that a cell is really used,
> (i.e., there is a pkt transmission during that time slot). What about “*allocation
> for pkt transmission*”?
>
> In this way, a cell within a bundle is scheduled according to a scheduling
> algorithm, but it is  allocated afterward, according to the network
> conditions (e.g., current traffic, queue congestion level, nextMoreBits,
> etc), using specific policies.
> *Cell/bundle scheduled: assigned/reserved to a specific couple of nodes*
>
> *Cell/Bundle allocated/used for a specific pkt transmission*
>
>
>
> then expressions like “cells allocated but not used within the bundle…’
> are not allowed, and  the terms “reserve” and “allocate” cannot be
> interchanged.
>
>
>
> *I don’t know if you prefer to use the term “allocate” as synonymous of
>  “schedule” (meaning allocated for a specific couple of nodes, but not
> necessarily for a packet transmission!!!) and then the term “use” for
> specifying when  a cell is really used for a packet transmission.*
>
>
>
> In any case, we will need to agree on the terminology to use, in order to
> keep in writing the OTF draft and discussing on the time slot allocation,
> without getting lost!
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 11 Dec 2013 19:06:43 -0800

I tend to agree with Qin that we don't have to differentiate a cell that
has been scheduled, from a cell that is actually used. This depends
entirely on the presence of packets to transmit when the scheduled cell
shows up. Maria Rita, do you agree?

As for terminology, I would vote for the verb "to schedule" to refer to the
action of associating a slotframe ID, neighbor MAC, etc. to a cell, and the
qualifiers "scheduled" and "unscheduled" to refer to cells.

The TSCH schedule, i.e. the union of all scheduled and unscheduled cells
live in the IEEE802.15.4e TSCH PIB (see Table 52d of the 4e standard).

Recent discussions have introduced the concepts of chunks and reserved
cells. I'm afraid I'm still not 100% clear on their definition. @Pascal,
would you have one? The question I have is whether this is part of the TSCH
PIB, or the 6top MIB. AFAICT, the latter is true. If this is the case, then
cells which are "reserved" as part of a chunk do not actually appear in the
TSCH schedule, and the terms "scheduled/unschedule" and "reserved" are
orthogonal.

My 2 cents...

Thomas

On Wed, Dec 11, 2013 at 6:01 PM, Qin Wang <[email-masked]> wrote:

> (1) Regarding to the cells in a bundle, "schedule" and "allocate" refers
> to same operation, i.e. binding a (slotFrame,(slotOffset,channelOffset)) to
> a (neighborAddr, Tx/Rx). Just picking one of them is fine. And, whether the
>> following the trend on the ML about the “time slot allocation” and the
>> OTF draft, I think we need to discuss about the terminology to adopt when
>> we talk about cells within a bundle,  or chunk, their reservation and
>> actual allocation for a transmission.
>>
>>
>>
>> (or reserved) to a specific couple of nodes*. But this doesn’t imply
>> that it is actually used for an on-going transmission. Right?
>>
>>
>>
>> In this way, a cell within a bundle is scheduled according to a
>> scheduling algorithm, but it is  allocated afterward, according to the
>> network conditions (e.g., current traffic, queue congestion level,
>> nextMoreBits, etc), using specific policies.

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 13 Dec 2013 15:23:40 +0000

Thanks Thomas and Qin for your comments! Please read inline and let's keep in discussing during the call.
Maria Rita

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Thursday, December 12, 2013 4:07 AM
To: Qin Wang
Cc: Maria Rita PALATTELLA; [email-masked]
Subject: Re: [6tisch] SCHEDULE - ALLOCATE - RESERVE - USE : terminology related to time slot allocation & OTF

I tend to agree with Qin that we don't have to differentiate a cell that has been scheduled, from a cell that is actually used. This depends entirely on the presence of packets to transmit when the scheduled cell shows up. Maria Rita, do you agree?
[MR]I do agree

As for terminology, I would vote for the verb "to schedule" to refer to the action of associating a slotframe ID, neighbor MAC, etc. to a cell, and the qualifiers "scheduled" and "unscheduled" to refer to cells.
[MR] +1

The TSCH schedule, i.e. the union of all scheduled and unscheduled cells live in the IEEE802.15.4e TSCH PIB (see Table 52d of the 4e standard).

Recent discussions have introduced the concepts of chunks and reserved cells. I'm afraid I'm still not 100% clear on their definition. @Pascal, would you have one? The question I have is whether this is part of the TSCH PIB, or the 6top MIB. AFAICT, the latter is true. If this is the case, then cells which are "reserved" as part of a chunk do not actually appear in the TSCH schedule, and the terms "scheduled/unschedule" and "reserved" are orthogonal.

My 2 cents...

Thomas

On Wed, Dec 11, 2013 at 6:01 PM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi Maria Rita,

According to my understanding, the feature of the cells in a bundle is different from the cells in a chunk. The cells in a bundle will be used by TSCH directly, but the cells in a chunk are managed in 6top and TSCH can not see the pool. Therefore,

(1) Regarding to the cells in a bundle, "schedule" and "allocate" refers to same operation, i.e. binding a (slotFrame,(slotOffset,channelOffset)) to a (neighborAddr, Tx/Rx). Just picking one of them is fine. And, whether the cell is actually used at a specific slotFrame is determined by TSCH based on if there is a pkt needed to be send (if it is a Tx cell). Thus, I think it is unnecessary for 6top to define the operation of using a cell for specific pkt transmission.

[MR] +1 when referring to cells and bundles, "schedule" and "allocate" are synonymous.

(2) Regarding to the size of bundle, I prefer "reserve" and "remove". The requirement will come from upper layer like OTF to 6top, and be implemented by calling 6top commands.

[MR] When increasing or decreasing the size of a bundle, I would still talk of "schedule/allocate" cells within the bundle.

(3) Regarding to the cells in a chunk, we can say "reserve/remove X cells for chunk Y". The requirement will come from upper layer. We need to add some more 6top commands to support its implementation.

[MR] Right, I would use the term "reserve" cells within a chunk for a specific parent-child bundle.

What do you think?

Qin

On Tue, Dec 10, 2013 at 11:32 PM, Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,

Maria Rita

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch