Subject: [6tisch] time slot allocation

From: Maria Rita PALATTELLA <[email-masked]>
Date: Wed, 20 Nov 2013 10:02:35 +0000

Dear all,

Let's keep our interesting discussion on the time slot allocation alive.

I will try to sum up our last ideas, mainly the open issues on which we still need to discuss:

*        1) Different Approaches for allocating a time slot within the schedule

*        centralized (PCE-like): not-scalable

*         fully distributed (e.g., OTF): risk of collision - need of monitoring the cells usage and the collision occurrence (using 6top?)

*         hybrid (semi-distributed, parent-based allocation) : more-scalable, based on bulk allocation and redistribution
Each approach has pros and cons, and it can be suitable in different scenarios/applications.
For each of them we need to specify HOW to allocate cells, or group of cells with the same neighbor (bundle) or with different neighbors (chunk).
Centralized solutions will mainly use HARD cells, while distributed or hybrid algorithms  are more lucky to use soft cells.

*        2) CHUNK - a new concept different from bundle!
*        It could be useful to allocate for a given node a chunk, i.e., a collection of cells in the schedule that can be used by that node to talk to any other neighbor, when needed.
*        Note that a chunk is different from a bundle. As defined in the 6tisch-terminology-draft:
*        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.
*        Q1: How to select the specific cells in a chunk? Or the number of cells in a chunk?
*        Q2: How 6top can support the chunk allocation? New commands/functionalities should be added

3) Next-Slot-Used indication
When a group of cells (chunk) is reserved for a given node, a single bit could be used for indicating that the next time slot is actually needed and thus, used by that nod.
Q: how 6top should deal with this?

4) Multiply allocated time slots
When a chunk is reserved for a given node, it does not mean that it will use all the cells. Thus, the same time slots could be allocated to different nodes. If several nodes will need the same cell at the same time, a collision could occur.
Q: How can we multiply allocated time slots, while avoiding collision?
Maybe allocating them to nodes that will not interfere, because they are far away, one from the other.

*        5) Take into account the ETSI recommendations (e.g., ETSI restrictions on percentage of channel usage), and the ISA100.11a specification, when building the scheduling. (this point was raised up by Don Sturek at IETF88)

Please, do not hesitate to jump into the discussion and add anything else that is missing.
Thnak you!
Maria Rita

---

From: Qin Wang <[email-masked]>
Date: Wed, 20 Nov 2013 23:07:14 +0800

Hi Maria Rita,

Thanks you for your summary.

Regarding to item 2), I think new 6top commands are needed to support Chunk
operations. It is easy to CREATE a chunk, because it is invoked by PCE and
will not affect neighbors. But, it may not be that easy to DELETE a chunk
after it has been used, because it will affect neighbors and trigger some
DELETE.hardcell operations. Right?

Regarding to item 3), my understanding is the Next-Slot-Used will be
carried in data packet to indicate next slot will be used or not, so as
receiver will know if it should listen to or not in the next slot. If it is
the case, the Next-Slot-Used indicator should be associated with Bundle,
instead of Chunk, right? In addition, does it make sense to add more than
one bit to indicate next N slots will not be used? For example, adding
2bits to indicate next 0-3 slots will not be used.

What do you think?

Qin

On Wed, Nov 20, 2013 at 6:02 PM, Maria Rita PALATTELLA <
[email-masked]> wrote:

>  Dear all,
>
>
>
> Let’s keep our interesting discussion on the *time slot allocation* alive.
>
>
>
> ·        1) *Different Approaches for allocating a time slot within the
> schedule*
>
> ·        centralized (PCE-like): not-scalable
>
> ·         fully distributed (e.g., OTF): risk of collision – need of
> monitoring the cells usage and the collision occurrence (using 6top?)
>
> ·         hybrid (semi-distributed, parent-based allocation) :
> more-scalable, based on bulk allocation and redistribution
>
> For each of them we need to specify HOW to allocate cells, or group of
> cells with the same neighbor (bundle) or with different neighbors (chunk).
>
> Centralized solutions will mainly use HARD cells, while distributed or
> hybrid algorithms  are more lucky to use soft cells.
>
>
>
> *·        *2) *CHUNK – a new concept different from bundle!*
>
> ·        It could be useful to allocate for a given node a chunk, i.e., a collection
> of cells in the schedule that can be used by that *node to talk to any
> other neighbor, *when needed.
>
> ·        Note that a chunk is different from a bundle. As defined in the
> 6tisch-terminology-draft:
>
> ·        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.
>
> ·        Q1: How to select the specific cells in a chunk? Or the number
> of cells in a chunk?
>
> ·        Q2: How 6top can support the chunk allocation? New
> commands/functionalities should be added
>
>
>
> 3) *Next-Slot-Used indication*
>
> When a group of cells (chunk) is reserved for a given node, a single bit
> could be used for indicating that the next time slot is actually needed
> and thus, used by that nod.
>
> 4) *Multiply allocated time slots *
>
> When a chunk is reserved for a given node, it does not mean that it will
> use all the cells. Thus, the same time slots could be allocated to
> different nodes. If several nodes will need the same cell at the same time,
> a collision could occur.
>
> ·        5) Take into account the *ETSI recommendations* (e.g., ETSI
> restrictions on percentage of channel usage), and the *ISA100.11a
> specification*, when building the scheduling. (this point was raised up
> by Don Sturek at IETF88)
>
>
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 20 Nov 2013 20:49:10 -0800

Maria Rita,

Great summary. I also agree with Qin's comments.

I'd like in particular to focus on you question "How can we multiply
allocated time slots, while avoiding collision?".

My take is: not :) The IETF defines building blocks, that people can
combine to build a final solutions. We are tasked with defining the
mechanisms a mote/PCE/neighbor to allocate these time slots (the "how"),
but not the "why".

Does this make sense?

Thomas

On Wed, Nov 20, 2013 at 7:07 AM, Qin Wang <[email-masked]> wrote:

> Regarding to item 2), I think new 6top commands are needed to support
> Chunk operations. It is easy to CREATE a chunk, because it is invoked by
> PCE and will not affect neighbors. But, it may not be that easy to DELETE a
> chunk after it has been used, because it will affect neighbors and trigger
> some DELETE.hardcell operations. Right?
>
>> Let’s keep our interesting discussion on the *time slot allocation*alive.
>>
>>
>>
>> ·        It could be useful to allocate for a given node a chunk, i.e.,
>> a collection of cells in the schedule that can be used by that *node to
>> talk to any other neighbor, *when needed.
>>

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 22 Nov 2013 11:07:04 +0000

Hello Qin,

Thanks for your comments.

1)      About 6top <-> chunk commands,  the CREATE.chunk command should be invoked by a PCE, and  involve a given node (the one receiving the set of cells to be used with any neighbor).  But then, when the node will use a specific cell within the chunk  with a specific neighbor, shouldn't a CREATE.hardcell be  triggered?  About the DELETE.chunk command, as you are suggesting, it should trigger a set of DELETE.hardcell.

2)      About Next-Slot-Used, yes, it should be associated to a Bundle. IMHO, it doesn't make sense to add more than 1 bit for indicating that the next N slots will not be used. With  the next-slot-used 1 bit,  you will know, step by step, if the next one is used or not. I think the other bits indicating the not-used N slots will bring redundant information.  What do you think?

Maria Rita

From: Qin Wang [mailto:[email-masked]]
Sent: Wednesday, November 20, 2013 4:07 PM
To: Maria Rita PALATTELLA
Cc: [email-masked]
Subject: Re: [6tisch] time slot allocation

Hi Maria Rita,

Regarding to item 2), I think new 6top commands are needed to support Chunk operations. It is easy to CREATE a chunk, because it is invoked by PCE and will not affect neighbors. But, it may not be that easy to DELETE a chunk after it has been used, because it will affect neighbors and trigger some DELETE.hardcell operations. Right?

Regarding to item 3), my understanding is the Next-Slot-Used will be carried in data packet to indicate next slot will be used or not, so as receiver will know if it should listen to or not in the next slot. If it is the case, the Next-Slot-Used indicator should be associated with Bundle, instead of Chunk, right? In addition, does it make sense to add more than one bit to indicate next N slots will not be used? For example, adding 2bits to indicate next 0-3 slots will not be used.

What do you think?

Qin

On Wed, Nov 20, 2013 at 6:02 PM, Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,

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

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 22 Nov 2013 13:06:57 +0000

Thomas,
I am afraid I did not get what you meant with your "not"  :) and with your "why"...
Sure, we will define the scheduling mechanisms, either for a PCE or a mote/neighbor.
With my question: "How can we multiply allocated time slots, while avoiding collision?"
I meant taking into account the possibility of allocating the same cells for different couple of nodes, while avoiding collision.
This could be something to consider while defining the scheduling algorithms.
Do you think it is out of our scope?
Thanks
Maria Rita

From: 6tisch [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Thursday, November 21, 2013 5:49 AM
To: [email-masked]
Subject: Re: [6tisch] time slot allocation

Maria Rita,

I'd like in particular to focus on you question "How can we multiply allocated time slots, while avoiding collision?".

My take is: not :) The IETF defines building blocks, that people can combine to build a final solutions. We are tasked with defining the mechanisms a mote/PCE/neighbor to allocate these time slots (the "how"), but not the "why".

Does this make sense?

Thomas

On Wed, Nov 20, 2013 at 7:07 AM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi Maria Rita,

What do you think?

Qin

---

From: Qin Wang <[email-masked]>
Date: Fri, 22 Nov 2013 22:46:24 +0800

Hi Maria Rita,

Regarding to 1), you are right, when a node use a specific cell within a
chunck, a CREATE.hardcell will be triggered.

Regarding to 2), for example, assume there are 4 cells in a bundle, nodeA
only wants to use cell-1 to send data to nodeB. If next_slot_used is only 1
bit, one possible approach is that nodeA sends data to nodeB on cell-1 and
tell nodeB cell-2 will not be used, and sends data with empty payload on
cell-3 and tells nodeB cell-4 will not be used; another possible approach
is nodeA only sends data on cell-1, then nodeB can sleep on cell-2, but has
to idle-listen on cell-3 and cell-4. No matter which approach, some energy
will be wasted. With more than one bits next_slot_used, nodeB can sleep on
cell-2, cell-3,and cell-4 based on the indicator obtained on cell-1. Right?
However, as you said, many bits of next_slot_used may bring redundant and
waste bandwidth. Thus, I think 2 or 3 bits may be a value of trade-off.
What do you think?

Thanks
Qin

On Fri, Nov 22, 2013 at 7:07 PM, Maria Rita PALATTELLA <
[email-masked]> wrote:

> 1)      About 6top <-> chunk commands,  the CREATE.chunk command should
> be invoked by a PCE, and  involve a given node (the one receiving the set
> of cells to be used with any neighbor).  But then, when the node will use a
> specific cell within the chunk  with a specific neighbor, shouldn’t a
> CREATE.hardcell be  triggered?  About the DELETE.chunk command, as you are
> suggesting, it should trigger a set of DELETE.hardcell.
>
>
>
> 2)      About Next-Slot-Used, yes, it should be associated to a Bundle.
> IMHO, it doesn’t make sense to add more than 1 bit for indicating that the
> next N slots will not be used. With  the next-slot-used 1 bit,  you will
> know, step by step, if the next one is used or not. I think the other bits
> indicating the not-used N slots will bring redundant information.  What do
> you think?
>
>
>
> Maria Rita
>
>
>
>
>
> *From:* Qin Wang [mailto:[email-masked]]
> *Sent:* Wednesday, November 20, 2013 4:07 PM
> *To:* Maria Rita PALATTELLA
> *Cc:* [email-masked]
> *Subject:* Re: [6tisch] time slot allocation
>
>
>
> Hi Maria Rita,
>
>
>
> *·*        2) *CHUNK – a new concept different from bundle!*
>

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 22 Nov 2013 15:01:27 +0000

Qin, I see your point about the next-slot-used and its number of bits.
Keeping in mind that each bundle can have a different size, what about using the next-slot-used bit for specifying only the active cells? Meaning that, following your example, if only cell-1 is used, by saying that cell 1 is used, we will implicitly say that all the others will not be used. If, instead, cell-1 and cell-3 are used, then we will specify cell-1 and cell-3 are active, instead of saying: cell-1 is active, cell-2 is not active, cell-3 is active, cell-4 is not active.
What do you think?
Maria Rita

From: Qin Wang [mailto:[email-masked]]
Sent: Friday, November 22, 2013 3:46 PM
To: Maria Rita PALATTELLA
Cc: [email-masked]
Subject: Re: [6tisch] time slot allocation

Hi Maria Rita,

Regarding to 1), you are right, when a node use a specific cell within a chunck, a CREATE.hardcell will be triggered.

Regarding to 2), for example, assume there are 4 cells in a bundle, nodeA only wants to use cell-1 to send data to nodeB. If next_slot_used is only 1 bit, one possible approach is that nodeA sends data to nodeB on cell-1 and tell nodeB cell-2 will not be used, and sends data with empty payload on cell-3 and tells nodeB cell-4 will not be used; another possible approach is nodeA only sends data on cell-1, then nodeB can sleep on cell-2, but has to idle-listen on cell-3 and cell-4. No matter which approach, some energy will be wasted. With more than one bits next_slot_used, nodeB can sleep on cell-2, cell-3,and cell-4 based on the indicator obtained on cell-1. Right? However, as you said, many bits of next_slot_used may bring redundant and waste bandwidth. Thus, I think 2 or 3 bits may be a value of trade-off. What do you think?

Thanks
Qin

On Fri, Nov 22, 2013 at 7:07 PM, Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>> wrote:
Hello Qin,

Maria Rita

From: Qin Wang [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, November 20, 2013 4:07 PM
To: Maria Rita PALATTELLA
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] time slot allocation

Hi Maria Rita,

What do you think?

Qin

---

From: Qin Wang <[email-masked]>
Date: Fri, 22 Nov 2013 23:09:51 +0800

Maria Rita,

That is a great idea. I agree to it.

Thanks
Qin

On Fri, Nov 22, 2013 at 11:01 PM, Maria Rita PALATTELLA <
[email-masked]> wrote:

> Keeping in mind that each bundle can have a different size, what about
> using the next-slot-used bit for specifying only the active cells? Meaning
> that, following your example, if only cell-1 is used, by saying that cell 1
> is used, we will implicitly say that all the others will not be used. If,
> instead, cell-1 and cell-3 are used, then we will specify cell-1 and cell-3
> are active, instead of saying: cell-1 is active, cell-2 is not active,
> cell-3 is active, cell-4 is not active.
>
> What do you think?
>
> Maria Rita
>
>
>
>
>
> *Sent:* Friday, November 22, 2013 3:46 PM
>

---

From: Qin Wang <[email-masked]>
Date: Fri, 22 Nov 2013 23:15:36 +0800

Maria Rita,

Just after I sent out my previous email, a question pops out. If we assume
the default status of each cell is "not used", how nodeB knows that nodeA
will send data on some cell?

Qin

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Fri, 22 Nov 2013 13:17:33 -0200

Maria Rita, Qin:
                      An active-cell list within a Bundle would require to
maintain a shared
table between nodes, which can be less power-hungry than a relative jump to
the next
cell. On the other side, a relative jump may limit the maximum number of
cells inside
a Bundle, thinking about the longest jump between cells.
                      Another possibility may be a bare linked-list of
cells within the
Bundle, using more bits, but with an absolute index number to identify the
cell,
again limiting the Bundle size.
                      Altogether, the next-cell approach, although less
efficient, may
keep things simple if cells are consecutive.
                     My question is, which is the purpose of jumping
between cells
inside a Bundle?
                      Any thoughts?
                      Thank you,

                                                   Diego Dujovne

2013/11/22 Maria Rita PALATTELLA <[email-masked]>

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: Qin Wang <[email-masked]>
Date: Fri, 22 Nov 2013 23:34:37 +0800

Hi Deigo,

First of all, when we say "next cell", we refer to the next active cell in
a bundle, instead of slotOffset+1.

Then, regarding to the motivation to have next_slot_used, I think it is
because over-provision and dynamic traffic may happen. With next_slot_used
indicator, we can save energy in those situations. Thought?

Thanks
Qin

On Fri, Nov 22, 2013 at 11:17 PM, Prof. Diego Dujovne <
[email-masked]> wrote:

> table between nodes, which can be less power-hungry than a relative jump
> to the next

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 22 Nov 2013 15:39:51 +0000

Dear all:

The idea with a single bit expects that we negotiate initially a number of cells in a bundle and which are always listened to.
Say we have 8 cells and always listen to cells 1 and 5. The idea would be that ideally the always-listened-to slots are equally separated in time over the slotframe.

In run time, if there are queued packets for a given bundle when sending on slot 1, then the bit is set.
In that case, the device can send a new packet on slot 2 and again, if there are still packets queued it will set the bit again.
It results that there is no need to indicate in the first cell the list of all the cells that the device will be using in the whole slot frame; instead, it is really a 'more' bit that is usef in each of the cells as long as there is more to be sent over that bundle.

Note that if no packet is sent on cell 1 or the bit is not set in the packet that is sent, then the device cannot send anything till slot 5.

The harder question is what if there is no ack.  Could be that the packet is lost or the packet was received and the ack is lost.
We'd like to use cell2 for a retry but then we do not know whether the recipient will be listening.

We have a matrix like this

                      No packet sent      Packet is lost     Ack is lost
More bit set          N/A                 case 1             case 2
More bit not set      case 3              case 4             case 5

Case 3 looks like a oximoron but in fact the recipient may not be able to differentiate from case 4.
In case 3 there is no retry to be made but in case 4 there is. Should the recipient be expecting a retry in cell 2?

So, should we retry in cell 2, or in cell 5? In which of the cases above does that mlake sense? Would an ack-ack aligned to the cell end help?

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: vendredi 22 novembre 2013 16:10
To: Maria Rita PALATTELLA
Cc: [email-masked]
Subject: Re: [6tisch] time slot allocation

Maria Rita,

Thanks
Qin

On Fri, Nov 22, 2013 at 11:01 PM, Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>> wrote:
Qin, I see your point about the next-slot-used and its number of bits.
Keeping in mind that each bundle can have a different size, what about using the next-slot-used bit for specifying only the active cells? Meaning that, following your example, if only cell-1 is used, by saying that cell 1 is used, we will implicitly say that all the others will not be used. If, instead, cell-1 and cell-3 are used, then we will specify cell-1 and cell-3 are active, instead of saying: cell-1 is active, cell-2 is not active, cell-3 is active, cell-4 is not active.
What do you think?
Maria Rita

Hi Maria Rita,

Thanks
Qin

Maria Rita

Hi Maria Rita,

What do you think?

Qin

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 22 Nov 2013 15:42:51 +0000

Hello Qin:

If the parent knows that the next cell in a bundle is not used (child did not set the more bit) then the parent may reaffect the particular cell to another child opportunistically.
This means that we introduce a 'want-more' bit in the frame from a child and the parent answers with the slot offset of the freecell.

Let's chat at the call...

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: vendredi 22 novembre 2013 16:35
To: Prof. Diego Dujovne
Cc: Maria Rita PALATTELLA; [email-masked]
Subject: Re: [6tisch] time slot allocation

Hi Deigo,

First of all, when we say "next cell", we refer to the next active cell in a bundle, instead of slotOffset+1.

Then, regarding to the motivation to have next_slot_used, I think it is because over-provision and dynamic traffic may happen. With next_slot_used indicator, we can save energy in those situations. Thought?

Thanks
Qin

On Fri, Nov 22, 2013 at 11:17 PM, Prof. Diego Dujovne <[email-masked]<mailto:[email-masked]>> wrote:
Maria Rita, Qin:
                      An active-cell list within a Bundle would require to maintain a shared
table between nodes, which can be less power-hungry than a relative jump to the next
cell. On the other side, a relative jump may limit the maximum number of cells inside
a Bundle, thinking about the longest jump between cells.
                      Another possibility may be a bare linked-list of cells within the
Bundle, using more bits, but with an absolute index number to identify the cell,
again limiting the Bundle size.
                      Altogether, the next-cell approach, although less efficient, may
keep things simple if cells are consecutive.
                     My question is, which is the purpose of jumping between cells
inside a Bundle?
                      Any thoughts?
                      Thank you,
                                                   Diego Dujovne

2013/11/22 Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>>
Qin, I see your point about the next-slot-used and its number of bits.
Keeping in mind that each bundle can have a different size, what about using the next-slot-used bit for specifying only the active cells? Meaning that, following your example, if only cell-1 is used, by saying that cell 1 is used, we will implicitly say that all the others will not be used. If, instead, cell-1 and cell-3 are used, then we will specify cell-1 and cell-3 are active, instead of saying: cell-1 is active, cell-2 is not active, cell-3 is active, cell-4 is not active.
What do you think?
Maria Rita

Hi Maria Rita,

Thanks
Qin

Maria Rita

Hi Maria Rita,

What do you think?

Qin

--
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl<http://www.ingenieria.udp.cl>
(56 2) 676 8125

---

From: Qin Wang <[email-masked]>
Date: Sat, 23 Nov 2013 02:35:26 +0800

Hi Pascal,

I think the concept of co-next can address my problem.

I would like clarify what it means to 6top furthermore. I think it means
besides Shared and Dedicated, there is a new cell type, i.e. Co-next cell.
A Co-next cell is a Hard cell, belongs to a chunk of  a parent, and will be
assigned by parent to its children statically or dynamically. There are
many ways for a parent to assign a co-next cell to a child, e.g.
pre-assignment (i.e. what Maria Rita and I discussed), "want-more" oriented
assignment.

What do you think?

Thanks
Qin

On Fri, Nov 22, 2013 at 11:42 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Hello Qin:
>
>
>
> If the parent knows that the next cell in a bundle is not used (child did
> not set the more bit) then the parent may reaffect the particular cell to
> another child opportunistically.
>
> This means that we introduce a ‘want-more’ bit in the frame from a child
> and the parent answers with the slot offset of the freecell.
>
>
>
> Let’s chat at the call…
>
>
>
> Pascal
>
>
>
> *From:* 6tisch [mailto:[email-masked]] *On Behalf Of *Qin Wang
> *Sent:* vendredi 22 novembre 2013 16:35
> *To:* Prof. Diego Dujovne
> *Cc:* Maria Rita PALATTELLA; [email-masked]
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 22 Nov 2013 20:21:19 +0000

I certainly agree, Qin, but for the term hard cell.

I think the co-next cell inherits its properties form the root cell, and when used for RPL bundles links, I think that probably means soft.
What do you think?

Pascal

From: Qin Wang [mailto:[email-masked]]
Sent: vendredi 22 novembre 2013 19:35
To: Pascal Thubert (pthubert)
Cc: Prof. Diego Dujovne; Maria Rita PALATTELLA; [email-masked]
Subject: Re: [6tisch] time slot allocation

Hi Pascal,

I would like clarify what it means to 6top furthermore. I think it means besides Shared and Dedicated, there is a new cell type, i.e. Co-next cell. A Co-next cell is a Hard cell, belongs to a chunk of  a parent, and will be assigned by parent to its children statically or dynamically. There are many ways for a parent to assign a co-next cell to a child, e.g. pre-assignment (i.e. what Maria Rita and I discussed), "want-more" oriented assignment.

What do you think?

Thanks
Qin

On Fri, Nov 22, 2013 at 11:42 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Qin:

Pascal

From: 6tisch [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Qin Wang
Sent: vendredi 22 novembre 2013 16:35
To: Prof. Diego Dujovne
Cc: Maria Rita PALATTELLA; [email-masked]<mailto:[email-masked]>

Hi Deigo,

Thanks
Qin

Hi Maria Rita,

Thanks
Qin

Maria Rita

Hi Maria Rita,

What do you think?

Qin

---

From: Qin Wang <[email-masked]>
Date: Sat, 23 Nov 2013 06:44:07 +0800

Pascal,

I'm not sure. The main difference between hard cell and soft cell is if
6top can reallocate it or not. My understanding is that chunk is created by
PCE to ensure there is no conflict among the chunks owned by those parents
who are in the same radio area. If a cell selected from such kind of chunk
is re-allocated by 6top locally, the new cell may conflict with some cell
in other chunk, unless the cell is only moved in the chunk. Right? Is it
what you want?

Maybe, the "soft" here means the binding between a hard cell and its owner
is soft, instead of that the binding between bandwidth and (slotOffset,
channelOffset) is soft. What do you think?

Thanks
Qin

Thanks
Qin

On Sat, Nov 23, 2013 at 4:21 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> I think the co-next cell inherits its properties form the root cell, and
> when used for RPL bundles links, I think that probably means soft.
>
> What do you think?
>
>
>
> Pascal
>
>
>
> *Sent:* vendredi 22 novembre 2013 19:35
> *To:* Pascal Thubert (pthubert)
> *Cc:* Prof. Diego Dujovne; Maria Rita PALATTELLA; [email-masked]
>

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Fri, 22 Nov 2013 22:36:56 -0800

Hi,

have some questions about chunk management vs not using chunks. As far as I
understand a chunk is a block of the schedule that is allocated to a node
by some management entity, the chunk is uniquely assigned to a node. Chunks
can be of different sizes and the management of chunks is similar to the
management of memory in linux systems (can be allocated/deallocated, have
different sizes, etc..). A buddy algorithm can be used for that purpose,
but requires communication.

The questions are:

1)how do we plan to deal with fragmentation of the schedule? fragmentation
can cause inefficiencies or even having nodes that are not able to allocate
their desired bw because cells are taken by others.
2)who will manage chunks and what messages are required (coordination?)
3)what is the advantage of allocating a cell in a chunk vs allocating a
cell in the whole schedule? Can we quantify it? In order to avoid
collisions when allocating cells a node needs to know if there are others
using the same cell and they are in the collision range, using chunks
requires that other nodes in the neighborhood know that the particular
chunk is being used (implies messaging), not using a chunk and allocating a
cell directly to the schedule requires the same knowledge.

I think that the concept of chunk might be useful but we need to understand
very well the implications/requirements because a partition on the schedule
is only a logical organization. I understand that some assumptions can be
made but we have to make sure that this implicit knowledge is general
enough so the mechanism is useful in most of the cases.

my 5 cents :-)
X

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 25 Nov 2013 17:39:52 -0800

Xavi,

I would not worry too much those policy decisions at this point, and focus
on the mechanisms, if we envision that they will be useful to some policy
using them.
Thoughts?

I have a number of clarifying questions about chunks (not sure who to ask
them to)
- Can there be multiple chunks in a node?
- If yes, are chunks associated with some identifier?
- how does a packet know which chunk to be sent on?

Once we have a clear answer to those questions, it will be easy to add
primitive to manipulate chunks to 6top.

Thomas

On Fri, Nov 22, 2013 at 10:36 PM, Xavier Vilajosana Guillen <
[email-masked]> wrote:

> Hi,
>
> have some questions about chunk management vs not using chunks. As far as
> I understand a chunk is a block of the schedule that is allocated to a node
> I think that the concept of chunk might be useful but we need to
> understand very well the implications/requirements because a partition on
> the schedule is only a logical organization. I understand that some
> assumptions can be made but we have to make sure that this implicit
> knowledge is general enough so the mechanism is useful in most of the cases.
>
> my 5 cents :-)
> X
>
>
>> Maybe, the "soft" here means the binding between a hard cell and its
>> owner is soft, instead of that the binding between bandwidth and
>> (slotOffset, channelOffset) is soft. What do you think?
>>
>> Thanks
>> Qin
>>
>> Thanks
>> Qin
>>
>>
>>> If the parent knows that the next cell in a bundle is not used (child
>>> did not set the more bit) then the parent may reaffect the particular cell
>>> to another child opportunistically.
>>>
>>> Regarding to 2), for example, assume there are 4 cells in a bundle,
>>> nodeA only wants to use cell-1 to send data to nodeB. If next_slot_used is
>>> only 1 bit, one possible approach is that nodeA sends data to nodeB on
>>> cell-1 and tell nodeB cell-2 will not be used, and sends data with empty
>>> payload on cell-3 and tells nodeB cell-4 will not be used; another possible
>>> approach is nodeA only sends data on cell-1, then nodeB can sleep on
>>> cell-2, but has to idle-listen on cell-3 and cell-4. No matter which
>>> approach, some energy will be wasted. With more than one bits
>>> next_slot_used, nodeB can sleep on cell-2, cell-3,and cell-4 based on the
>>> indicator obtained on cell-1. Right? However, as you said, many bits of
>>> next_slot_used may bring redundant and waste bandwidth. Thus, I think 2 or
>>> 3 bits may be a value of trade-off. What do you think?
>>>
>>>
>>>
>>> Thanks
>>>
>>> Qin
>>>
>>>
>>>
>>>
>>>
>>> ·        Note that a chunk is different from a bundle. As defined in
>>> the 6tisch-terminology-draft:
>>>

---

From: Qin Wang <[email-masked]>
Date: Tue, 26 Nov 2013 12:50:37 +0800

Thomas,

Regarding to question  "how does a packet know which chunk to be sent on?",
IMHO, it is unnecessary for a packet to know which chunk it will use,
because packet is associated with bundle instead of chunk. What do you
think?

Thanks
Qin

On Tue, Nov 26, 2013 at 9:39 AM, Thomas Watteyne <[email-masked]
> wrote:

>> 1)how do we plan to deal with fragmentation of the schedule?
>> fragmentation can cause inefficiencies or even having nodes that are not
>> able to allocate their desired bw because cells are taken by others.
>>>> I think the co-next cell inherits its properties form the root cell,
>>>> and when used for RPL bundles links, I think that probably means soft.
>>>>
>>>> What do you think?
>>>>
>>>>
>>>>
>>>> Pascal
>>>>
>>>>
>>>>
>>>> I would like clarify what it means to 6top furthermore. I think it
>>>> means besides Shared and Dedicated, there is a new cell type, i.e. Co-next
>>>> cell. A Co-next cell is a Hard cell, belongs to a chunk of  a parent, and
>>>> will be assigned by parent to its children statically or dynamically. There
>>>> are many ways for a parent to assign a co-next cell to a child, e.g.
>>>> This means that we introduce a ‘want-more’ bit in the frame from a
>>>> child and the parent answers with the slot offset of the freecell.
>>>>
>>>>
>>>>
>>>> Let’s chat at the call…
>>>>
>>>>
>>>>
>>>> Pascal
>>>>
>>>>
>>>>
>>>> Regarding to 1), you are right, when a node use a specific cell within
>>>> a chunck, a CREATE.hardcell will be triggered.
>>>>
>>>>
>>>>
>>>> 1)      About 6top <-> chunk commands,  the CREATE.chunk command
>>>> should be invoked by a PCE, and  involve a given node (the one receiving
>>>> the set of cells to be used with any neighbor).  But then, when the node
>>>> will use a specific cell within the chunk  with a specific neighbor,
>>>> shouldn’t a CREATE.hardcell be  triggered?  About the DELETE.chunk command,
>>>> as you are suggesting, it should trigger a set of DELETE.hardcell.
>>>>
>>>>
>>>>
>>>> 2)      About Next-Slot-Used, yes, it should be associated to a
>>>> Bundle. IMHO, it doesn’t make sense to add more than 1 bit for indicating
>>>> that the next N slots will not be used. With  the next-slot-used 1 bit,
>>>>  you will know, step by step, if the next one is used or not. I think the
>>>> other bits indicating the not-used N slots will bring redundant
>>>> information.  What do you think?
>>>>
>>>>
>>>>
>>>> Maria Rita
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ·        1) *Different Approaches for allocating a time slot within
>>>> the schedule*
>>>>
>>>> ·        It could be useful to allocate for a given node a chunk,
>>>> i.e., a collection of cells in the schedule that can be used by that *node
>>>> to talk to any other neighbor, *when needed.
>>>>
>>>> ·        Q1: How to select the specific cells in a chunk? Or the
>>>> number of cells in a chunk?
>>>>
>>>> When a group of cells (chunk) is reserved for a given node, a single
>>>> bit could be used for indicating that the next time slot is actually
>>>> needed and thus, used by that nod.
>>>>
>>>> When a chunk is reserved for a given node, it does not mean that it
>>>> will use all the cells. Thus, the same time slots could be allocated to
>>>> specification*, when building the scheduling. (this point was raised
>>>> up by Don Sturek at IETF88)
>>>>
>>>>
>>>>
>>>>
>>>>

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Tue, 26 Nov 2013 10:42:35 +0000

Thomas, IMHO having more chunks in a node will just make things more complicate. And we want to keep them easy as much as possible.
A chunk is a set of cells that a node can use with any neighbor. What's the point of having more than one? How a chunk should differ from the others? In the end, we just want to over-provision cells to be used when and if needed.
If we allow more than one chunk per node, we will need not only mechanisms for choosing the cell within the chunk, but also mechanisms for selecting the chunk itself.
That's just my thought...
Maria Rita

From: 6tisch [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Tuesday, November 26, 2013 2:40 AM
To: [email-masked]
Subject: Re: [6tisch] time slot allocation

Xavi,

I would not worry too much those policy decisions at this point, and focus on the mechanisms, if we envision that they will be useful to some policy using them.
Thoughts?

I have a number of clarifying questions about chunks (not sure who to ask them to)
- Can there be multiple chunks in a node?
- If yes, are chunks associated with some identifier?
- how does a packet know which chunk to be sent on?

Once we have a clear answer to those questions, it will be easy to add primitive to manipulate chunks to 6top.

Thomas

On Fri, Nov 22, 2013 at 10:36 PM, Xavier Vilajosana Guillen <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

have some questions about chunk management vs not using chunks. As far as I understand a chunk is a block of the schedule that is allocated to a node by some management entity, the chunk is uniquely assigned to a node. Chunks can be of different sizes and the management of chunks is similar to the management of memory in linux systems (can be allocated/deallocated, have different sizes, etc..). A buddy algorithm can be used for that purpose, but requires communication.

The questions are:

1)how do we plan to deal with fragmentation of the schedule? fragmentation can cause inefficiencies or even having nodes that are not able to allocate their desired bw because cells are taken by others.
2)who will manage chunks and what messages are required (coordination?)
3)what is the advantage of allocating a cell in a chunk vs allocating a cell in the whole schedule? Can we quantify it? In order to avoid collisions when allocating cells a node needs to know if there are others using the same cell and they are in the collision range, using chunks requires that other nodes in the neighborhood know that the particular chunk is being used (implies messaging), not using a chunk and allocating a cell directly to the schedule requires the same knowledge.

I think that the concept of chunk might be useful but we need to understand very well the implications/requirements because a partition on the schedule is only a logical organization. I understand that some assumptions can be made but we have to make sure that this implicit knowledge is general enough so the mechanism is useful in most of the cases.

my 5 cents :-)
X

On Fri, Nov 22, 2013 at 2:44 PM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Pascal,

I'm not sure. The main difference between hard cell and soft cell is if 6top can reallocate it or not. My understanding is that chunk is created by PCE to ensure there is no conflict among the chunks owned by those parents who are in the same radio area. If a cell selected from such kind of chunk is re-allocated by 6top locally, the new cell may conflict with some cell in other chunk, unless the cell is only moved in the chunk. Right? Is it what you want?

Maybe, the "soft" here means the binding between a hard cell and its owner is soft, instead of that the binding between bandwidth and (slotOffset, channelOffset) is soft. What do you think?

Thanks
Qin

Thanks
Qin

On Sat, Nov 23, 2013 at 4:21 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
I certainly agree, Qin, but for the term hard cell.

Pascal

From: Qin Wang [mailto:[email-masked]<mailto:[email-masked]>]
Sent: vendredi 22 novembre 2013 19:35
To: Pascal Thubert (pthubert)
Cc: Prof. Diego Dujovne; Maria Rita PALATTELLA; [email-masked]<mailto:[email-masked]>

Hi Pascal,

What do you think?

Thanks
Qin

Pascal

Hi Deigo,

Thanks
Qin

Hi Maria Rita,

Thanks
Qin

Maria Rita

Hi Maria Rita,

What do you think?

Qin

--
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl<http://www.ingenieria.udp.cl>
(56 2) 676 8125<tel:%2856%202%29%20676%208125>

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Tue, 26 Nov 2013 10:46:27 +0000

Qin, I do agree that a packet should be associated with a bundle, based on the next hop, and thus, the node to who the packet has to be forwarded.
The cells within a chunk could be used for increasing the bundle size (and thus, allocated for a specific neighbor), if needed.
Maria Rita

From: 6tisch [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: Tuesday, November 26, 2013 5:51 AM
To: Thomas Watteyne
Cc: [email-masked]
Subject: Re: [6tisch] time slot allocation

Thomas,

Regarding to question  "how does a packet know which chunk to be sent on?", IMHO, it is unnecessary for a packet to know which chunk it will use, because packet is associated with bundle instead of chunk. What do you think?

Thanks
Qin

On Tue, Nov 26, 2013 at 9:39 AM, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> wrote:
Xavi,

Thomas

The questions are:

my 5 cents :-)
X

Thanks
Qin

Thanks
Qin

Pascal

Hi Pascal,

What do you think?

Thanks
Qin

Pascal

Hi Deigo,

Thanks
Qin

Hi Maria Rita,

Thanks
Qin

Maria Rita

Hi Maria Rita,

What do you think?

Qin

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 26 Nov 2013 14:07:13 +0000

I see your point Qin,

The hard cells are taken from a pool that the PCE owns. So if the pool that the PCE owns is made of chunks then those are hard cells.

The PCE may format the slot-frame in chunks, giving each chunk a number (a chunk-id). Then a node (typically a RPL parent) that need cells would auto-configure a chunk and claim the chunk-id ( by asking around ) to make sure no interfering neighbor is already using that chunk.

It results that the chunk that the parent obtains and manages for its parent-to-child bundles is owned by that parent, and it is in charge to allocate the cells therein in bundles; so it may move them as well. Those cells are reserved to a bundle, but may be moved;  so they are soft, correct?

Cheers,

- Pascal -

Sent: vendredi 22 novembre 2013 23:44

Pascal,

Thanks
Qin

Thanks
Qin

Pascal

Hi Pascal,

What do you think?

Thanks
Qin

Pascal

Hi Deigo,

Thanks
Qin

Hi Maria Rita,

Thanks
Qin

Maria Rita

Hi Maria Rita,

What do you think?

Qin

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 26 Nov 2013 14:31:18 +0000

Hello Xavi

From: Xavier Vilajosana Guillen [mailto:[email-masked]]
Sent: samedi 23 novembre 2013 07:37
To: Qin Wang
Cc: Pascal Thubert (pthubert); Maria Rita PALATTELLA; [email-masked]; Prof. Diego Dujovne
Subject: Re: [6tisch] time slot allocation

Hi,

[PT] Chunks can be reused in a different interference domain, and the formatting of slot-frame into chunks may be done by some management entity, but the allocation of a chunk to a node may be done though auto-configuration, just grabbing chunk-id that does not seem to be in use around. We could actually have heuristics for that such as forcing a parent that owns a chunk to use preferably some cells from that chunk so the use of those cells would be a signature of the bundle. Screening for energy in the air in those particular cells would indicate that the chunk is in use by a potential interferer and this node should peek a different chunk-id. We probably want to keep cells apart to limit the gap between cells, so buddy may not be the way, see below:

The questions are:

1)how do we plan to deal with fragmentation of the schedule? fragmentation can cause inefficiencies or even having nodes that are not able to allocate their desired bw because cells are taken by others.
[PT] A chunk is a lost of cells but it is not contiguous. In fact, we probably want the other way around, a list of well-distributed cells in time and frequency  within the schedule.

2)who will manage chunks and what messages are required (coordination?)
[PT] Chunks can be preprogrammed in a static schedule. We could have a simple rule to auto-compute them based on prime numbers.
Or chunks could be computed with the schedule by the PCE. The idea is that each cell would be tagged with the chunk-id.

[PT] If there is a need to ask around whether a cell is being used before self can use a cell, then the chunk divides that overhead by the number of cells in a chunk.

[PT] Agreed! Can we propose a simple auto-chunking of minimal schedule? Say we have 100 slots / 16 channels. Say we decide to autoformat 50 bundles of 32 cells. The first 2 time slots give you one cell per bundle, and then a +7 modulo 16 rotation in the channel every 2 slots give you automatically the other slots in that chunk. The first of every ten cells in a chunk must be used preferably so it can be screened as a signature of others to discover if that chunk is being used.
A node that find no energy on those signature cells and has no history that a neighbor claimed the associated chunk-id can claim it via a 2-3 hops flooding, and if no competition arises, decide to own the chunk, using preferably the signature slots.

What do you think?

my 5 cents :-)
X

Thanks
Qin

Thanks
Qin

Pascal

Hi Pascal,

What do you think?

Thanks
Qin

Pascal

Hi Deigo,

Thanks
Qin

Hi Maria Rita,

Thanks
Qin

Maria Rita

Hi Maria Rita,

What do you think?

Qin

---

From: "Prof. Adam Wolisz" <[email-masked]>
Date: Tue, 26 Nov 2013 19:19:22 +0100

Hi,

a short comment from an observer of this activity:

The idea of sending some information to keep the
reservation status is - in essence -

the re-usage/extension of a well understood (and appreciated!)
PRMA Algorithm

Packet Reservation Multiple Access for Local Wireless
Communications"

D.J. Goodman, R.A. Valenzuela, K.T. Gayliard, and B. Ramamurthi

IEEE Transactions on
Communications, Vol. COM-37, No. 8, pp 885-890 (August
1989)

It is very nice for distributed claiming time units /keeping these
resources reserved

for real time traffic (at that time voice..)

-------

Just my two cents...

Best

adam

On 26.11.2013 15:31, Pascal Thubert
(pthubert) wrote:

Hello
Xavi

From:
Xavier Vilajosana Guillen
[mailto:[email-masked]]

To: Qin Wang

Cc: Pascal Thubert (pthubert); Maria Rita
PALATTELLA; [email-masked]; Prof. Diego Dujovne

Hi,

have some questions about chunk
management vs not using chunks. As far as I understand a
chunk is a block of the schedule that is allocated to a
node by some management entity, the chunk is uniquely
assigned to a node. Chunks can be of different sizes and
the management of chunks is similar to the management of
memory in linux systems (can be allocated/deallocated,
have different sizes, etc..). A buddy algorithm can be
used for that purpose, but requires communication.

[PT]
Chunks can be reused in a different interference
domain, and the formatting of slot-frame into
chunks may be done by some management entity, but
the allocation of a chunk to a node may be done
though auto-configuration, just grabbing chunk-id
that does not seem to be in use around. We could
actually have heuristics for that such as forcing
a parent that owns a chunk to use preferably some
cells from that chunk so the use of those cells
would be a signature of the bundle. Screening for
energy in the air in those particular cells would
indicate that the chunk is in use by a potential
interferer and this node should peek a different
chunk-id. We probably want to keep cells apart to
limit the gap between cells, so buddy may not be
the way, see below:

The questions are:

1)how do we plan to deal with
fragmentation of the schedule? fragmentation can cause
inefficiencies or even having nodes that are not able to
allocate their desired bw because cells are taken by
others.

[PT]
A chunk is a lost of cells but it is not
contiguous. In fact, we probably want the other
way around, a list of well-distributed cells in
time and frequency  within the schedule.

2)who will manage chunks and what
messages are required (coordination?)

[PT]
Chunks can be preprogrammed in a static schedule.
We could have a simple rule to auto-compute them
based on prime numbers.

Or
chunks could be computed with the schedule by the
PCE. The idea is that each cell would be tagged
with the chunk-id.

3)what is the advantage of allocating
a cell in a chunk vs allocating a cell in the whole
schedule? Can we quantify it? In order to avoid
collisions when allocating cells a node needs to know if
there are others using the same cell and they are in the
collision range, using chunks requires that other nodes
in the neighborhood know that the particular chunk is
being used (implies messaging), not using a chunk and
allocating a cell directly to the schedule requires the
same knowledge.

[PT]
If there is a need to ask around whether a cell is
being used before self can use a cell, then the
chunk divides that overhead by the number of cells
in a chunk.

I think that the concept of chunk
might be useful but we need to understand very well the
implications/requirements because a partition on the
schedule is only a logical organization. I understand
that some assumptions can be made but we have to make
sure that this implicit knowledge is general enough so
the mechanism is useful in most of the cases.

[PT]
Agreed! Can we propose a simple auto-chunking of
minimal schedule? Say we have 100 slots / 16
channels. Say we decide to autoformat 50 bundles
of 32 cells. The first 2 time slots give you one
cell per bundle, and then a +7 modulo 16 rotation
in the channel every 2 slots give you
automatically the other slots in that chunk. The
first of every ten cells in a chunk must be used
preferably so it can be screened as a signature of
others to discover if that chunk is being used.

A
node that find no energy on those signature cells
and has no history that a neighbor claimed the
associated chunk-id can claim it via a 2-3 hops
flooding, and if no competition arises, decide to
own the chunk, using preferably the signature
slots.

What
do you think?

my 5 cents :-)

X

On Fri, Nov 22, 2013 at 2:44 PM, Qin
Wang <[email-masked]>
wrote:

Pascal,

I'm not sure. The main difference
between hard cell and soft cell is if 6top can
reallocate it or not. My understanding is that chunk
is created by PCE to ensure there is no conflict
among the chunks owned by those parents who are in
the same radio area. If a cell selected from such
kind of chunk is re-allocated by 6top locally, the
new cell may conflict with some cell in other chunk,
unless the cell is only moved in the chunk. Right?
Is it what you want?

Maybe, the "soft" here means the
binding between a hard cell and its owner is soft,
instead of that the binding between bandwidth and
(slotOffset, channelOffset) is soft. What do you
think?

Thanks

Qin

Thanks

Qin

On Sat, Nov 23, 2013 at 4:21
AM, Pascal Thubert (pthubert) <[email-masked]>
wrote:

I
certainly agree, Qin, but for the term
hard cell.

I
think the co-next cell inherits its
properties form the root cell, and when
used for RPL bundles links, I think that
probably means soft.

What
do you think?

Pascal

From:
Qin Wang [mailto:[email-masked]]

Sent: vendredi 22 novembre 2013
19:35

Cc: Prof. Diego Dujovne; Maria Rita
PALATTELLA;
[email-masked]

Subject: Re: [6tisch] time slot
allocation

Hi
Pascal,

I
think the concept of co-next can
address my problem.

I
would like clarify what it means to
6top furthermore. I think it means
besides Shared and Dedicated, there
is a new cell type, i.e. Co-next
cell. A Co-next cell is a Hard cell,
belongs to a chunk of  a parent, and
will be assigned by parent to its
children statically or dynamically.
There are many ways for a parent to
assign a co-next cell to a child,
e.g. pre-assignment (i.e. what Maria
Rita and I discussed), "want-more"
oriented assignment.

What
do you think?

Thanks

Qin

On
Fri, Nov 22, 2013 at 11:42 PM,
Pascal Thubert (pthubert) <[email-masked]>
wrote:

Hello
Qin:

If
the parent knows that the next
cell in a bundle is not used
(child did not set the more
bit) then the parent may
reaffect the particular cell
to another child
opportunistically.

This
means that we introduce a
‘want-more’ bit in the frame
from a child and the parent
answers with the slot offset
of the freecell.

Let’s
chat at the call…

Pascal

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

Sent: vendredi 22
novembre 2013 16:35

To: Prof. Diego Dujovne

Cc: Maria Rita
PALATTELLA;
[email-masked]

Subject: Re: [6tisch]
time slot allocation

Hi
Deigo,

First
of all, when we say
"next cell", we refer to
the next active cell in
a bundle, instead of
slotOffset+1.

Then,
regarding to the
motivation to have
next_slot_used, I think
it is because
over-provision and
dynamic traffic may
happen. With
next_slot_used
indicator, we can save
energy in those
situations. Thought?

Thanks

Qin

On
Fri, Nov 22, 2013 at
11:17 PM, Prof. Diego
Dujovne <[email-masked]>
wrote:

Maria Rita,
Qin:

An active-cell list
within a Bundle
would require to
maintain a shared

table between nodes,
which can be less
power-hungry than a
relative jump to the
next

cell. On the other
side, a relative
jump may limit the
maximum number of
cells inside

a Bundle, thinking
about the longest
jump between cells.

Another possibility
may be a bare
linked-list of cells
within the

Bundle,
using more bits, but
with an absolute
index number to
identify the cell,

again
limiting the Bundle
size.

Altogether, the
next-cell approach,
although less
efficient, may

keep things simple
if cells are
consecutive.

My question is,
which is the purpose
of jumping between
cells

inside
a Bundle?

Any thoughts?

Thank you,

Diego Dujovne

2013/11/22
Maria Rita
PALATTELLA <[email-masked]>

Qin,
I see your
point about
the
next-slot-used
and its number
of bits.

Keeping
in mind that
each bundle
can have a
different
size, what
about using
the
next-slot-used
bit for
specifying
only the
active cells?
Meaning that,
following your
example, if
only cell-1 is
used, by
saying that
cell 1 is
used, we will
implicitly say
that all the
others will
not be used.
If, instead,
cell-1 and
cell-3 are
used, then we
will specify
cell-1 and
cell-3 are
active,
instead of
saying: cell-1
is active,
cell-2 is not
active, cell-3
is active,
cell-4 is not
active.

What
do you think?

Maria
Rita

From:
Qin Wang
[mailto:[email-masked]]

Sent:
Friday,
November 22,
2013 3:46 PM

To:
Maria Rita
PALATTELLA

Cc: [email-masked]

Subject:
Re: [6tisch]
time slot
allocation

Hi Maria
Rita,

Regarding to
1), you are
right, when a
node use a
specific cell
within a
chunck, a
CREATE.hardcell
will be
triggered.

Regarding to
2), for
example,
assume there
are 4 cells in
a bundle,
nodeA only
wants to use
cell-1 to send
data to nodeB.
If
next_slot_used
is only 1 bit,
one possible
approach is
that nodeA
sends data to
nodeB on
cell-1 and
tell nodeB
cell-2 will
not be used,
and sends data
with empty
payload on
cell-3 and
tells nodeB
cell-4 will
not be used;
another
possible
approach is
nodeA only
sends data on
cell-1, then
nodeB can
sleep on
cell-2, but
has to
idle-listen on
cell-3 and
cell-4. No
matter which
approach, some
energy will be
wasted. With
more than one
bits
next_slot_used,
nodeB can
sleep on
cell-2,
cell-3,and
cell-4 based
on the
indicator
obtained on
cell-1. Right?
However, as
you said, many
bits of
next_slot_used
may bring
redundant and
waste
bandwidth.
Thus, I think
2 or 3 bits
may be a value
of trade-off.
What do you
think?

Thanks

Qin

On Fri, Nov
22, 2013 at
7:07 PM, Maria
Rita
PALATTELLA
<[email-masked]>
wrote:

Hello
Qin,

Thanks
for your
comments.

1)
About
6top <->
chunk
commands,  the
CREATE.chunk
command should
be invoked by
a PCE, and
involve a
given node
(the one
receiving the
set of cells
to be used
with any
neighbor).
But then,
when the node
will use a
specific cell
within the
chunk  with a
specific
neighbor,
shouldn’t a
CREATE.hardcell
be  triggered?
About the
DELETE.chunk
command, as
you are
suggesting, it
should trigger
a set of
DELETE.hardcell.

2)
About
Next-Slot-Used,
yes, it should
be associated
to a Bundle.
IMHO, it
doesn’t make
sense to add
more than 1
bit for
indicating
that the next
N slots will
not be used.
With  the
next-slot-used
1 bit,  you
will know,
step by step,
if the next
one is used or
not. I think
the other bits
indicating the
not-used N
slots will
bring
redundant
information.
What do you
think?

Maria
Rita

From:
Qin Wang
[mailto:[email-masked]]

Sent:
Wednesday,
November 20,
2013 4:07 PM

To:
Maria Rita
PALATTELLA

Cc: [email-masked]

Subject:
Re: [6tisch]
time slot
allocation

Hi Maria
Rita,

Thanks you
for your
summary.

Regarding to
item 2), I
think new 6top
commands are
needed to
support Chunk
operations. It
is easy to
CREATE a
chunk, because
it is invoked
by PCE and
will not
affect
neighbors.
But, it may
not be that
easy to DELETE
a chunk after
it has been
used, because
it will affect
neighbors and
trigger some
DELETE.hardcell
operations.
Right?

Regarding to
item 3), my
understanding
is the
Next-Slot-Used
will be
carried in
data packet to
indicate next
slot will be
used or not,
so as receiver
will know if
it should
listen to or
not in the
next slot. If
it is the
case, the
Next-Slot-Used
indicator
should be
associated
with Bundle,
instead of
Chunk, right?
In addition,
does it make
sense to add
more than one
bit to
indicate next
N slots will
not be used?
For example,
adding 2bits
to indicate
next 0-3 slots
will not be
used.

What do you
think?

Qin

On Wed, Nov
20, 2013 at
6:02 PM, Maria
Rita
PALATTELLA
<[email-masked]>
wrote:

Dear all,

Let’s keep
our
interesting
discussion on
the
time slot
allocation
alive.

I will try to
sum up our
last ideas,
mainly the
open issues on
which we still
need to
discuss:

·
1)
Different
Approaches for
allocating a
time slot
within the
schedule

·
centralized
(PCE-like):
not-scalable

·
fully
distributed
(e.g., OTF):
risk of
collision –
need of
monitoring the
cells usage
and the
collision
occurrence (using 6top?)

·
hybrid
(semi-distributed,
parent-based
allocation) :
more-scalable,
based on
bulk
allocation and
redistribution

Each approach
has pros and
cons, and it
can be
suitable in
different
scenarios/applications.

For
each of them
we need to
specify HOW to
allocate
cells, or
group of cells
with the same
neighbor
(bundle) or
with different
neighbors
(chunk).

Centralized
solutions will
mainly use
HARD cells,
while
distributed or
hybrid
algorithms
are more
lucky to use
soft cells.

·
2)
CHUNK
– a new
concept
different from
bundle!

·
It
could be
useful to
allocate for a
given node a
chunk, i.e., a

collection of
cells in the
schedule that
can be used by
that node
to talk to any
other
neighbor,
when
needed.

·
Note
that a chunk
is different
from a bundle.
As defined in
the

·
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.

·
Q1:
How to select
the specific
cells in a
chunk? Or the
number of
cells in a
chunk?

·
Q2:
How 6top can
support the
chunk
allocation?
New
commands/functionalities
should be
added

3) Next-Slot-Used
indication

When a group
of cells
(chunk) is
reserved for a
given node, a
single bit
could be used
for
indicating
that the next
time slot is
actually
needed and
thus, used by
that nod.

Q:
how 6top
should deal
with this?

4) Multiply
allocated time
slots

When
a chunk is
reserved for a
given node, it
does not mean
that it will
use all the
cells. Thus,
the same time
slots could be
allocated to
different
nodes. If
several nodes
will need the
same cell at
the same time,
a collision
could occur.

Q:
How can we
multiply
allocated time
slots, while
avoiding
collision?

Maybe
allocating
them to nodes
that will not
interfere,
because they
are far away,
one from the
other.

·
5)
Take
into account
the ETSI
recommendations
(e.g.,
ETSI
restrictions
on percentage
of channel
usage), and
the
ISA100.11a
specification,
when building
the
scheduling.
(this point
was raised up
by Don Sturek
at IETF88)

Please, do
not hesitate
to jump into
the discussion
and add
anything else
that is
missing.

Thnak you!

Maria
Rita

6tisch mailing
list

[email-masked]

6tisch mailing
list

[email-masked]

--

DIEGO DUJOVNE

Académico Escuela de
Ingeniería en
Informática y
Telecomunicaciones

Facultad de
Ingeniería UDP

www.ingenieria.udp.cl

(56 2) 676 8125

6tisch mailing list

[email-masked]

---

From: Qin Wang <[email-masked]>
Date: Wed, 27 Nov 2013 14:24:22 +0800

Hi Pascal,

I will suggest to add another type of cell, saying semi-soft cell, to
identify those cells who can be moved by parent and in a given chunk. I can
imagine the procedure and message for moving soft cell and semi soft cell
will be different. What do you think?

Thanks
Qin

On Tue, Nov 26, 2013 at 10:07 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  I see your point Qin,
>
>
>
> The hard cells are taken from a pool that the PCE owns. So if the pool
> that the PCE owns is made of chunks then those are hard cells.
>
>
>
> The PCE may format the slot-frame in chunks, giving each chunk a number (a
> chunk-id). Then a node (typically a RPL parent) that need cells would
> auto-configure a chunk and claim the chunk-id ( by asking around ) to make
> sure no interfering neighbor is already using that chunk.
>
>
>
> It results that the chunk that the parent obtains and manages for its
> parent-to-child bundles is owned by that parent, and it is in charge to
> allocate the cells therein in bundles; so it may move them as well. Those
> cells are reserved to a bundle, but may be moved;  so they are soft,
> correct?
>
>
>
> Cheers,
>
>
>
> - Pascal -
>
>
>
> *Sent:* vendredi 22 novembre 2013 23:44
>

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Wed, 27 Nov 2013 07:18:39 -0200

Qin,
       I think chunk and no-chunk modes are mutually exclusive: when in
chunk mode, the nodes cannot select a cell outside their chunk, while in
no-chunk mode, the nodes can select any cell from the schedule, given other
restrictions, such as colision resolution, for example. In this scenario,
only one type of softcell would be needed.
       What do you think?

                       Diego

El 27/11/2013 03:24, "Qin Wang" <[email-masked]> escribió:

>> The PCE may format the slot-frame in chunks, giving each chunk a number
>> (a chunk-id). Then a node (typically a RPL parent) that need cells would

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 27 Nov 2013 10:37:32 -0800

Adam,
Thanks a million for the link to the paper. A great read for the upcoming
days off here in the US. I'm sure it will be very helpful.

Maria Rita, Pascal,
I'm 100% for making things as simple as possible. I'm trying to understand
Pascal's proposal better, and in particular the interaction between the
more bit and the concept of chunks. In particular, if the more bit is set,
how do the sender/receiver know which cell to use next? The slides
presented last week give ideas on where those cells should be in the
schedule, but not how they are logically linked to one another.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 27 Nov 2013 19:34:48 +0000

We have to define that chaining but ot is linked to the concept of bundle not that of chunk.

Trouble is I had typos in my text using bundle for chunk, sorry!

Once a parent owns a chunk it has a reserve of free cells. Then it assembles free cells in bundles to create an L3 link. The cells in a bundle form a list, and the parent decides which cells are always on and which are conext.

Let us chat more in the light of the references paper!

Pascal

Le 27 nov. 2013 à 19:32, "Thomas Watteyne" <[email-masked]<mailto:[email-masked]>> a écrit :

Adam,
Thanks a million for the link to the paper. A great read for the upcoming days off here in the US. I'm sure it will be very helpful.

Maria Rita, Pascal,
I'm 100% for making things as simple as possible. I'm trying to understand Pascal's proposal better, and in particular the interaction between the more bit and the concept of chunks. In particular, if the more bit is set, how do the sender/receiver know which cell to use next?

On Wed, Nov 27, 2013 at 1:18 AM, Prof. Diego Dujovne <[email-masked]<mailto:[email-masked]>> wrote:

Qin,
       I think chunk and no-chunk modes are mutually exclusive: when in chunk mode, the nodes cannot select a cell outside their chunk, while in no-chunk mode, the nodes can select any cell from the schedule, given other restrictions, such as colision resolution, for example. In this scenario, only one type of softcell would be needed.
       What do you think?

                       Diego

El 27/11/2013 03:24, "Qin Wang" <[email-masked]<mailto:[email-masked]>> escribió:

Hi Pascal,

I will suggest to add another type of cell, saying semi-soft cell, to identify those cells who can be moved by parent and in a given chunk. I can imagine the procedure and message for moving soft cell and semi soft cell will be different. What do you think?

Thanks
Qin

On Tue, Nov 26, 2013 at 10:07 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
I see your point Qin,

Cheers,

- Pascal -

Pascal,

Thanks
Qin

Thanks
Qin

Pascal

Hi Pascal,

What do you think?

Thanks
Qin

If the parent knows that the next cell in a bundle is not used (child did not set the more bit) then the parent may reaffect the particular cell to another child opportunistically.
This means that we introduce a ‘want-more’ bit in the frame from a child and the parent answers with the slot offset of the freecell.

Let’s chat at the call…

Pascal

Hi Deigo,

Thanks
Qin

Hi Maria Rita,

Thanks
Qin

1)      About 6top <-> chunk commands,  the CREATE.chunk command should be invoked by a PCE, and  involve a given node (the one receiving the set of cells to be used with any neighbor).  But then, when the node will use a specific cell within the chunk  with a specific neighbor, shouldn’t a CREATE.hardcell be  triggered?  About the DELETE.chunk command, as you are suggesting, it should trigger a set of DELETE.hardcell.

2)      About Next-Slot-Used, yes, it should be associated to a Bundle. IMHO, it doesn’t make sense to add more than 1 bit for indicating that the next N slots will not be used. With  the next-slot-used 1 bit,  you will know, step by step, if the next one is used or not. I think the other bits indicating the not-used N slots will bring redundant information.  What do you think?

Maria Rita

Hi Maria Rita,

What do you think?

Qin

Let’s keep our interesting discussion on the time slot allocation alive.

•        1) Different Approaches for allocating a time slot within the schedule

•        centralized (PCE-like): not-scalable

•         fully distributed (e.g., OTF): risk of collision – need of monitoring the cells usage and the collision occurrence (using 6top?)

•         hybrid (semi-distributed, parent-based allocation) : more-scalable, based on bulk allocation and redistribution
Each approach has pros and cons, and it can be suitable in different scenarios/applications.
For each of them we need to specify HOW to allocate cells, or group of cells with the same neighbor (bundle) or with different neighbors (chunk).
Centralized solutions will mainly use HARD cells, while distributed or hybrid algorithms  are more lucky to use soft cells.

•        2) CHUNK – a new concept different from bundle!
•        It could be useful to allocate for a given node a chunk, i.e., a collection of cells in the schedule that can be used by that node to talk to any other neighbor, when needed.
•        Note that a chunk is different from a bundle. As defined in the 6tisch-terminology-draft:
•        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.
•        Q1: How to select the specific cells in a chunk? Or the number of cells in a chunk?
•        Q2: How 6top can support the chunk allocation? New commands/functionalities should be added

•        5) Take into account the ETSI recommendations (e.g., ETSI restrictions on percentage of channel usage), and the ISA100.11a specification, when building the scheduling. (this point was raised up by Don Sturek at IETF88)

--
Thomas Watteyne, Ph. D
Sr. Networking Design Engineer
Linear Technology, Dust Networks Product Group
30695 Huntwood Ave
Hayward, CA 94544-7021
+1 (510) 400-2978
[email-masked]<mailto:[email-masked]>

This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail, or by telephone at (510) 400-2978, and destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

---

From: Qin Wang <[email-masked]>
Date: Thu, 28 Nov 2013 10:54:19 +0800

Diego,

I think the allocation and re-allocation of those cells in chunk is
distinguished from that for original soft cells by its Parent-Children
relationship. Only parent,  like a local PCE, has right to allocate and
re-allocate the cells in its owned chunk, which may result in sort of
asymmetric protocol. Thus, I think additional cell type is needed.

What do you think?

Thanks
Qin

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 28 Nov 2013 15:09:09 +0000

Hello Qin

Chunks are an allocation paradigm, used to obtain sole ownership of a bunch of cells, knowing that none of the neighbors will try to use the cells that compose the chunk. If you like, we can define the stash as the collection of the unused cells from the collection of chunks that the parent got allocated so far. Slots in the stash should never be used in the air by anyone since this node as sole ownership and does not use them. A parent creates bundles from cells that it finds in its stash. When the stash is empty the parent must obtain an additional chunk of cells and place the obtained cells in the stash.

IOW the chunk is a list of cells that is used by a parent to get ownership of the cells. The obtained cells are placed in a stash that is the collection of all the cells that are not currently allocated for a transmission. A bundle is also a list of cells, but it is used in runtime to forward packets to or from the parent that administers the bundles, using cells from the stash to grow the bundles and giving back the cells to the stash when the bundle dwindles.

If a cell in a bundle does not operate well, that cell must be replaced by another cell. That's soft cells for us. The term "move" is an image of that process but really it is a swap. In practice, the bad cell is placed back in the stash and another cell is selected from the stash and placed in the bundle instead. The 6top layer in the parent and the child must then agree on the new list of cells that form the bundle.

When the need-more bit is set, meaning that the bundle is exhausted and there is more data to send over that bundle, the parent can opportunistically propose unused co-next cells from another bundle for one round of the slotframe only. The parent may also pick a cell from the stash and grant it either for one round only, or to be added to the bundle in a more permanent fashion.

If you agree we are not talking about a new move, but refining how a move happens.

Make sense ?

Pascal

Sent: mercredi 27 novembre 2013 07:24

Hi Pascal,

Thanks
Qin

Cheers,

- Pascal -

Pascal,

Thanks
Qin

Thanks
Qin

Pascal

Hi Pascal,

What do you think?

Thanks
Qin

Pascal

Hi Deigo,

Thanks
Qin

Hi Maria Rita,

Thanks
Qin

Maria Rita

Hi Maria Rita,

What do you think?

Qin

---

From: "Prof. Adam Wolisz" <[email-masked]>
Date: Thu, 28 Nov 2013 20:45:59 +0100

Dear all,

While I appreciate very much the idea of optimization and

"very efficient resource usage" I wonder, if it is not better to

follow a rather popular three steps approach

a/ define some basic, really SIMPLE mechanism- default,
obligatory

b/ allow some "free bits" for possible extensions (optional!!)

c/ propose  some nice extension (as discussed here!) as OPTION!

while leaving open  the possibility to introduce other options
later

... after real experience has been collected..

Just my two cents..

best

adam wolisz

On 28.11.2013 16:09, Pascal Thubert
(pthubert) wrote:

Hello
Qin

Chunks
are an allocation paradigm, used to obtain sole ownership of
a bunch of cells, knowing that none of the neighbors will
try to use the cells that compose the chunk. If you like, we
can define the stash as the collection of the unused cells
from the collection of chunks that the parent got allocated
so far. Slots in the stash should never be used in the air
by anyone since this node as sole ownership and does not use
them. A parent creates bundles from cells that it finds in
its stash. When the stash is empty the parent must obtain an
additional chunk of cells and place the obtained cells in
the stash.

IOW
the chunk is a list of cells that is used by a parent to get
ownership of the cells. The obtained cells are placed in a
stash that is the collection of all the cells that are not
currently allocated for a transmission. A bundle is also a
list of cells, but it is used in runtime to forward packets
to or from the parent that administers the bundles, using
cells from the stash to grow the bundles and giving back the
cells to the stash when the bundle dwindles.

If
a cell in a bundle does not operate well, that cell must be
replaced by another cell. That’s soft cells for us. The term
“move” is an image of that process but really it is a swap.
In practice, the bad cell is placed back in the stash and
another cell is selected from the stash and placed in the
bundle instead. The 6top layer in the parent and the child
must then agree on the new list of cells that form the
bundle.

When
the need-more bit is set, meaning that the bundle is
exhausted and there is more data to send over that bundle,
the parent can opportunistically propose unused co-next
cells from another bundle for one round of the slotframe
only. The parent may also pick a cell from the stash and
grant it either for one round only, or to be added to the
bundle in a more permanent fashion.

If
you agree we are not talking about a new move, but refining
how a move happens.

Make sense ?

Pascal

From:

Cc: Prof. Diego Dujovne; Maria Rita PALATTELLA;
[email-masked]

Hi Pascal,

I will suggest to add another type of
cell, saying semi-soft cell, to identify those cells who
can be moved by parent and in a given chunk. I can
imagine the procedure and message for moving soft cell
and semi soft cell will be different. What do you think?

Thanks

Qin

On Tue, Nov 26, 2013 at 10:07 PM,
Pascal Thubert (pthubert) <[email-masked]>
wrote:

I
see your point Qin,

The
hard cells are taken from a pool that the PCE
owns. So if the pool that the PCE owns is made of
chunks then those are hard cells.

The
PCE may format the slot-frame in chunks, giving
each chunk a number (a chunk-id). Then a node
(typically a RPL parent) that need cells would
auto-configure a chunk and claim the chunk-id ( by
asking around ) to make sure no interfering
neighbor is already using that chunk.

It
results that the chunk that the parent obtains and
manages for its parent-to-child bundles is owned
by that parent, and it is in charge to allocate
the cells therein in bundles; so it may move them
as well. Those cells are reserved to a bundle, but
may be moved;  so they are soft, correct?

Cheers,

-
Pascal -

From:

Pascal,

I'm
not sure. The main difference between hard
cell and soft cell is if 6top can
reallocate it or not. My understanding is
that chunk is created by PCE to ensure
there is no conflict among the chunks
owned by those parents who are in the same
radio area. If a cell selected from such
kind of chunk is re-allocated by 6top
locally, the new cell may conflict with
some cell in other chunk, unless the cell
is only moved in the chunk. Right? Is it
what you want?

Maybe,
the "soft" here means the binding between
a hard cell and its owner is soft, instead
of that the binding between bandwidth and
(slotOffset, channelOffset) is soft. What
do you think?

Thanks

Qin

Thanks

Qin

On
Sat, Nov 23, 2013 at 4:21 AM, Pascal
Thubert (pthubert) <[email-masked]>
wrote:

I
certainly agree, Qin, but for the
term hard cell.

I
think the co-next cell inherits its
properties form the root cell, and
when used for RPL bundles links, I
think that probably means soft.

What
do you think?

Pascal

From:

Sent: vendredi 22 novembre
2013 19:35

Cc: Prof. Diego Dujovne;
Maria Rita PALATTELLA;
[email-masked]

Subject: Re: [6tisch] time
slot allocation

Hi
Pascal,

I
think the concept of co-next
can address my problem.

I
would like clarify what it
means to 6top furthermore. I
think it means besides Shared
and Dedicated, there is a new
cell type, i.e. Co-next cell.
A Co-next cell is a Hard cell,
belongs to a chunk of  a
parent, and will be assigned
by parent to its children
statically or dynamically.
There are many ways for a
parent to assign a co-next
cell to a child, e.g.
pre-assignment (i.e. what
Maria Rita and I discussed),
"want-more" oriented
assignment.

What
do you think?

Thanks

Qin

On

Hello
Qin:

If
the parent knows that
the next cell in a
bundle is not used
(child did not set the
more bit) then the
parent may reaffect the
particular cell to
another child
opportunistically.

This
means that we introduce
a ‘want-more’ bit in the
frame from a child and
the parent answers with
the slot offset of the
freecell.

Let’s
chat at the call…

Pascal

From:
On Behalf Of Qin
Wang

Sent: vendredi 22
novembre 2013 16:35

To: Prof. Diego
Dujovne

Cc: Maria Rita
PALATTELLA;
[email-masked]

Subject: Re:
[6tisch] time slot
allocation

Hi
Deigo,

First of all,
when we say "next
cell", we refer to
the next active
cell in a bundle,
instead of
slotOffset+1.

Then,
regarding to the
motivation to have
next_slot_used, I
think it is
because
over-provision and
dynamic traffic
may happen. With
next_slot_used
indicator, we can
save energy in
those situations.
Thought?

Thanks

Qin

On Fri, Nov
22, 2013 at 11:17
PM, Prof. Diego

Maria Rita,
Qin:

An active-cell
list within a
Bundle would
require to
maintain a
shared

table between
nodes, which
can be less
power-hungry
than a
relative jump
to the next

cell. On the
other side, a
relative jump
may limit the
maximum number
of cells
inside

a Bundle,
thinking about
the longest
jump between
cells.

Another
possibility
may be a bare
linked-list of
cells within
the

Bundle, using
more bits, but
with an
absolute index
number to
identify the
cell,

again
limiting the
Bundle size.

Altogether,
the next-cell
approach,
although less
efficient, may

keep things
simple if
cells are
consecutive.

My question
is, which is
the purpose of
jumping
between cells

inside a
Bundle?

Any thoughts?

Thank you,

Diego Dujovne

2013/11/22
Maria Rita
PALATTELLA

Qin,
I see your
point about
the
next-slot-used
and its number
of bits.

Keeping
in mind that
each bundle
can have a
different
size, what
about using
the
next-slot-used
bit for
specifying
only the
active cells?
Meaning that,
following your
example, if
only cell-1 is
used, by
saying that
cell 1 is
used, we will
implicitly say
that all the
others will
not be used.
If, instead,
cell-1 and
cell-3 are
used, then we
will specify
cell-1 and
cell-3 are
active,
instead of
saying: cell-1
is active,
cell-2 is not
active, cell-3
is active,
cell-4 is not
active.

What
do you think?

Maria
Rita

From:
Qin Wang

Sent:
Friday,
November 22,
2013 3:46 PM

To:
Maria Rita
PALATTELLA

Cc: [email-masked]

Subject:
Re: [6tisch]
time slot
allocation

Hi Maria
Rita,

Regarding to
1), you are
right, when a
node use a
specific cell
within a
chunck, a
CREATE.hardcell
will be
triggered.

Regarding to
2), for
example,
assume there
are 4 cells in
a bundle,
nodeA only
wants to use
cell-1 to send
data to nodeB.
If
next_slot_used
is only 1 bit,
one possible
approach is
that nodeA
sends data to
nodeB on
cell-1 and
tell nodeB
cell-2 will
not be used,
and sends data
with empty
payload on
cell-3 and
tells nodeB
cell-4 will
not be used;
another
possible
approach is
nodeA only
sends data on
cell-1, then
nodeB can
sleep on
cell-2, but
has to
idle-listen on
cell-3 and
cell-4. No
matter which
approach, some
energy will be
wasted. With
more than one
bits
next_slot_used,
nodeB can
sleep on
cell-2,
cell-3,and
cell-4 based
on the
indicator
obtained on
cell-1. Right?
However, as
you said, many
bits of
next_slot_used
may bring
redundant and
waste
bandwidth.
Thus, I think
2 or 3 bits
may be a value
of trade-off.
What do you
think?

Thanks

Qin

On Fri, Nov
22, 2013 at
7:07 PM, Maria
Rita
PALATTELLA

Hello
Qin,

Thanks
for your
comments.

1)
About
6top <->
chunk
commands,  the
CREATE.chunk
command should
be invoked by
a PCE, and
involve a
given node
(the one
receiving the
set of cells
to be used
with any
neighbor).
But then,
when the node
will use a
specific cell
within the
chunk  with a
specific
neighbor,
shouldn’t a
CREATE.hardcell
be  triggered?
About the
DELETE.chunk
command, as
you are
suggesting, it
should trigger
a set of
DELETE.hardcell.

2)
About
Next-Slot-Used,
yes, it should
be associated
to a Bundle.
IMHO, it
doesn’t make
sense to add
more than 1
bit for
indicating
that the next
N slots will
not be used.
With  the
next-slot-used
1 bit,  you
will know,
step by step,
if the next
one is used or
not. I think
the other bits
indicating the
not-used N
slots will
bring
redundant
information.
What do you
think?

Maria
Rita

From:
Qin Wang

Sent:
Wednesday,
November 20,
2013 4:07 PM

To:
Maria Rita
PALATTELLA

Cc: [email-masked]

Subject:
Re: [6tisch]
time slot
allocation

Hi Maria
Rita,

Thanks you
for your
summary.

Regarding to
item 2), I
think new 6top
commands are
needed to
support Chunk
operations. It
is easy to
CREATE a
chunk, because
it is invoked
by PCE and
will not
affect
neighbors.
But, it may
not be that
easy to DELETE
a chunk after
it has been
used, because
it will affect
neighbors and
trigger some
DELETE.hardcell
operations.
Right?

Regarding to
item 3), my
understanding
is the
Next-Slot-Used
will be
carried in
data packet to
indicate next
slot will be
used or not,
so as receiver
will know if
it should
listen to or
not in the
next slot. If
it is the
case, the
Next-Slot-Used
indicator
should be
associated
with Bundle,
instead of
Chunk, right?
In addition,
does it make
sense to add
more than one
bit to
indicate next
N slots will
not be used?
For example,
adding 2bits
to indicate
next 0-3 slots
will not be
used.

What do you
think?

Qin

On Wed, Nov
20, 2013 at
6:02 PM, Maria
Rita
PALATTELLA

Dear all,

Let’s keep
our
interesting
discussion on
the
time slot
allocation
alive.

I will try to
sum up our
last ideas,
mainly the
open issues on
which we still
need to
discuss:

·
1)
Different
Approaches for
allocating a
time slot
within the
schedule

·
centralized
(PCE-like):
not-scalable

·
fully
distributed
(e.g., OTF):
risk of
collision –
need of
monitoring the
cells usage
and the
collision
occurrence (using 6top?)

·
hybrid
(semi-distributed,
parent-based
allocation) :
more-scalable,
based on
bulk
allocation and
redistribution

Each approach
has pros and
cons, and it
can be
suitable in
different
scenarios/applications.

For
each of them
we need to
specify HOW to
allocate
cells, or
group of cells
with the same
neighbor
(bundle) or
with different
neighbors
(chunk).

Centralized
solutions will
mainly use
HARD cells,
while
distributed or
hybrid
algorithms
are more
lucky to use
soft cells.

·
2)
CHUNK
– a new
concept
different from
bundle!

·
It
could be
useful to
allocate for a
given node a
chunk, i.e., a

collection of
cells in the
schedule that
can be used by
that node
to talk to any
other
neighbor,
when
needed.

·
Note
that a chunk
is different
from a bundle.
As defined in
the

·
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.

·
Q1:
How to select
the specific
cells in a
chunk? Or the
number of
cells in a
chunk?

·
Q2:
How 6top can
support the
chunk
allocation?
New
commands/functionalities
should be
added

3) Next-Slot-Used
indication

When a group
of cells
(chunk) is
reserved for a
given node, a
single bit
could be used
for
indicating
that the next
time slot is
actually
needed and
thus, used by
that nod.

Q:
how 6top
should deal
with this?

4) Multiply
allocated time
slots

When
a chunk is
reserved for a
given node, it
does not mean
that it will
use all the
cells. Thus,
the same time
slots could be
allocated to
different
nodes. If
several nodes
will need the
same cell at
the same time,
a collision
could occur.

Q:
How can we
multiply
allocated time
slots, while
avoiding
collision?

Maybe
allocating
them to nodes
that will not
interfere,
because they
are far away,
one from the
other.

·
5)
Take
into account
the ETSI
recommendations
(e.g.,
ETSI
restrictions
on percentage
of channel
usage), and
the
ISA100.11a
specification,
when building
the
scheduling.
(this point
was raised up
by Don Sturek
at IETF88)

Please, do
not hesitate
to jump into
the discussion
and add
anything else
that is
missing.

Thnak you!

Maria
Rita

6tisch mailing
list

[email-masked]

6tisch mailing
list

[email-masked]

--

DIEGO DUJOVNE

Académico
Escuela de
Ingeniería en
Informática y
Telecomunicaciones

Facultad de
Ingeniería UDP

www.ingenieria.udp.cl

(56 2) 676
8125

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 28 Nov 2013 20:03:39 +0000

Hello Adam:

Most of this particular discussion is actually at the edge of the charter.

Our charter has exactly what you suggest and we start with a minimal support that has a fixed schedule and will use that to work out what is needed on devices that can take more.

But as we also work on information models, and we try to figure what we  may need next at a conceptual level, this this discussion.

Cheers

Pascal

Le 28 nov. 2013 à 20:46, "Prof. Adam Wolisz" <[email-masked]<mailto:[email-masked]>> a écrit :

Dear all,
While I appreciate very much the idea of optimization and
"very efficient resource usage" I wonder, if it is not better to
follow a rather popular three steps approach
a/ define some basic, really SIMPLE mechanism- default, obligatory
b/ allow some "free bits" for possible extensions (optional!!)
c/ propose  some nice extension (as discussed here!) as OPTION!
 while leaving open  the possibility to introduce other options later
    ... after real experience has been collected..

Just my two cents..
best
adam wolisz
On 28.11.2013 16:09, Pascal Thubert (pthubert) wrote:
Hello Qin

If a cell in a bundle does not operate well, that cell must be replaced by another cell. That’s soft cells for us. The term “move” is an image of that process but really it is a swap. In practice, the bad cell is placed back in the stash and another cell is selected from the stash and placed in the bundle instead. The 6top layer in the parent and the child must then agree on the new list of cells that form the bundle.

Make sense ?

Pascal

Hi Pascal,

Thanks
Qin

Cheers,

- Pascal -

Pascal,

Thanks
Qin

Thanks
Qin

Pascal

Hi Pascal,

What do you think?

Thanks
Qin

Let’s chat at the call…

Pascal

Hi Deigo,

Thanks
Qin

Hi Maria Rita,

Thanks
Qin

Maria Rita

Hi Maria Rita,

What do you think?

Qin

---

From: Qin Wang <[email-masked]>
Date: Fri, 29 Nov 2013 18:33:03 +0800

Pascal,

I agree almost everything you said except one thing I'm not very sure, that
is regarding to "The 6top layer in the parent and the child must then agree
on the new list of cells that form the bundle". I think the procedure for
making the agreement, i.e. the 6top<=>6top protocol, should be different in
chunk case from that in no chunk case. In chunk case, parent owns the cells
and thus should have more power to make decision. Right?

Qin

On Thu, Nov 28, 2013 at 11:09 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Hello Qin
>
>
>
> Chunks are an allocation paradigm, used to obtain sole ownership of a
> bunch of cells, knowing that none of the neighbors will try to use the
> cells that compose the chunk. If you like, we can define the stash as the
> collection of the unused cells from the collection of chunks that the
> parent got allocated so far. Slots in the stash should never be used in the
> air by anyone since this node as sole ownership and does not use them. A
> parent creates bundles from cells that it finds in its stash. When the
> stash is empty the parent must obtain an additional chunk of cells and
> place the obtained cells in the stash.
>
>
>
> IOW the chunk is a list of cells that is used by a parent to get ownership
> of the cells. The obtained cells are placed in a stash that is the
> collection of all the cells that are not currently allocated for a
> transmission. A bundle is also a list of cells, but it is used in runtime
> to forward packets to or from the parent that administers the bundles,
> using cells from the stash to grow the bundles and giving back the cells to
> the stash when the bundle dwindles.
>
>
>
> If a cell in a bundle does not operate well, that cell must be replaced by
> another cell. That’s soft cells for us. The term “move” is an image of that
> process but really it is a swap. In practice, the bad cell is placed back
> in the stash and another cell is selected from the stash and placed in the
> bundle instead. The 6top layer in the parent and the child must then agree
> on the new list of cells that form the bundle.
>
>
>
> When the need-more bit is set, meaning that the bundle is exhausted and
> there is more data to send over that bundle, the parent can
> opportunistically propose unused co-next cells from another bundle for one
> round of the slotframe only. The parent may also pick a cell from the stash
> and grant it either for one round only, or to be added to the bundle in a
> more permanent fashion.
>
>
>
> *Sent:* mercredi 27 novembre 2013 07:24
>