Subject: [6tisch] OTF & chunks

From: Nicola Accettura <[email-masked]>
Date: Thu, 20 Mar 2014 11:56:42 +0100

Dear all,
the current version of the OTF draft speaks about the necessity of chunks
as follows:

"OTF is prone to schedule collision.  Nodes might not be aware of the cells
allocated by other pairs of neighbors nodes.  A collision occurs when the
same cell is allocated by different pairs in the same interference space.
 The 6top sublayer cannot differentiate collisions from other sources of
packet loss.  The probability ofhaving allocation collision may be kept low
by grouping cells into chunks (see [I-D.ietf-6tisch-terminology] and
[I-D.ietf-6tisch-architecture] for more details).  The use of chunks is
outside the scope of this current version of the OTF draft."

Actually, as featured in the 6TOP sublayer draft, chunks can be managed by
a PCE or configured by upper layers:

"6top allows an upper layer to ask a node to manage a portion of a
slotframe, called a chunk.  Chunks can be delegated explicitly by the PCE
to a node, or claimed automatically by any node that participates to the
distributed cell scheduling process.  The cells in a chunk can be
appropriated by the node, i.e. the node is in charge of managing the chunk."

IMHO, to be useful in distributed and/or decentralized contexts chunks
should be given the possibility to be negotiated within specific IE. What
do you think about it?

In addition, the 6TOP sublayer draft allows only hard cells to be selected
in a chunk. This is clearly not suitable for OTF, which is supposed to work
only with soft cells. Am I missing something?

Cheers
Nicola

---

From: Qin Wang <[email-masked]>
Date: Thu, 20 Mar 2014 08:01:15 -0700 (PDT)

Hi Nicola,

Let's go back one step to discuss the reason to introduce Chunk into 6top. My understanding is as follows. 

6top supports centralized approach, i.e. PCE schedules hardcells for each node. 6top supports distributed approach, i.e. a pair of node allocate/reallocate some softcells by negotiation. Then, Chunk is a semi-centralized approach, i.e. a parent node is a local center, which delegate the PCE and manages a set of hardcell (i.e. Chunk), Comparing centralized approach, the Chunk approach will have advantage in terms of scalability and adaptability to dynamic radio environment, traffic load and other change in local.

Pascal, please point out if I'm wrong.

Thanks
Qin

On Thursday, March 20, 2014 6:57 PM, Nicola Accettura <[email-masked]> wrote:
 
Dear all,
the current version of the OTF draft speaks about the necessity of chunks as follows: 

"OTF is prone to schedule collision.  Nodes might not be aware of the cells allocated by other pairs of neighbors nodes.  A collision occurs when the same cell is allocated by different pairs in the same interference space.  The 6top sublayer cannot differentiate collisions from other sources of packet loss.  The probability ofhaving allocation collision may be kept low by grouping cells into chunks (see [I-D.ietf-6tisch-terminology] and [I-D.ietf-6tisch-architecture] for more details).  The use of chunks is outside the scope of this current version of the OTF draft."

Actually, as featured in the 6TOP sublayer draft, chunks can be managed by a PCE or configured by upper layers:
 
"6top allows an upper layer to ask a node to manage a portion of a slotframe, called a chunk.  Chunks can be delegated explicitly by the PCE to a node, or claimed automatically by any node that participates to the distributed cell scheduling process.  The cells in a chunk can be appropriated by the node, i.e. the node is in charge of managing the chunk."

IMHO, to be useful in distributed and/or decentralized contexts chunks should be given the possibility to be negotiated within specific IE. What do you think about it?

In addition, the 6TOP sublayer draft allows only hard cells to be selected in a chunk. This is clearly not suitable for OTF, which is supposed to work only with soft cells. Am I missing something?

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

---

From: Nicola Accettura <[email-masked]>
Date: Thu, 20 Mar 2014 18:12:58 +0100

Hi Qin,
of course, my understanding is the same as yours. Actually, I would like to
better feature what I meant.

Hard cells are allocated by exchanging 6top messages in the neighborhood,
but the delivery of such messages is triggered by entities different from
6top. For instance, a PCE coordinating scheduling duties in centralized
approaches. Decentralized or semi-centralized approaches would employ hard
cells as well. The key role is played by a central manager which is
intended to organize the cell allocation on each node in the network.

Soft cells, instead, could be used when a distributed approach is more
fitting to the application scenario (e.g., when mobility should be
accounted for). In this sense, OTF has been thought as a distributed
solution that relies on 6top soft-cell allocation/reallocation/deletion.

Let's consider chunks. As far as I understood, they can be fruitfully
exploited for avoiding collisions. A chunk is a subset of cells into the
slotframe. If a node holds a chunk, it will be allowed to allocate cells in
that subset. If the chunks related to each node in the network are well
distributed or interleaved, each pair of nodes will allocate cells without
interfering with other ones. For example, DeTAS (I presented some
implementation at the plugfest) would benefit from chunks.

In the current state of the 6TOP sublayer draft, it seems that chunks
cannot be computed dynamically on each node. I mean, only the PCE can do
this work or they should be preconfigured. I think it would be better to
extend the chunk properties, allowing the exchange of IE messages for
setting up proper chunks on each node. It is like having two levels of
allocation: nodes exchange messages in order to choose a subset (chunk) of
the slotframe where they could then allocate cells (after another round of
message exchange). Is that viable?

In addition, I think that chunks could be useful in both centralized and
distributed approaches for mitigating collisions. OTF would benefit for
sure from allowing soft cells to be reserved in a chunk more than in the
whole slotframe. Although OTF is distributed, there is always a central
entity which can tune properly the network behavior. It would be like RPL:
it is distributed, but the LLN sink is in charge of constructing the
network. What am I missing?

Thanks
Nicola

2014-03-20 16:01 GMT+01:00 Qin Wang <[email-masked]>:

> 6top supports centralized approach, i.e. PCE schedules hardcells for each
> node. 6top supports distributed approach, i.e. a pair of node
> allocate/reallocate some softcells by negotiation. Then, Chunk is a
> semi-centralized approach, i.e. a parent node is a local center, which
> delegate the PCE and manages a set of hardcell (i.e. Chunk), Comparing
> centralized approach, the Chunk approach will have advantage in terms of
> scalability and adaptability to dynamic radio environment, traffic load and
> other change in local.
>
> "OTF is prone to schedule collision.  Nodes might not be aware of the
> cells allocated by other pairs of neighbors nodes.  A collision occurs when
> the same cell is allocated by different pairs in the same interference
> space.  The 6top sublayer cannot differentiate collisions from other
> sources of packet loss.  The probability ofhaving allocation collision may
> be kept low by grouping cells into chunks (see
> [I-D.ietf-6tisch-terminology] and [I-D.ietf-6tisch-architecture] for more
> details).  The use of chunks is outside the scope of this current version
> of the OTF draft."
>

---

From: Qin Wang <[email-masked]>
Date: Thu, 20 Mar 2014 11:15:41 -0700 (PDT)

Hi Nicola,

I can see your point. Based on what you suggest about chunk, I think we can extent chunk related function as follows.
(1) If a node receives a set of cells from PCE or its parent (a chunk), it can ask its children to delegate part of the chunk (sub-chunk) or the whole chunk.
(2) The negotiation to allocate softcells can base on a given slotframe or a part of the slotframe (i.e. a chunk). Actually, it can be achieved based on current version of 6top, by using chunkID to define candidate list (see the sublayer draft).

What do you think?

Thanks
Qin   

On Friday, March 21, 2014 1:13 AM, Nicola Accettura <[email-masked]> wrote:
 
Hi Qin,
of course, my understanding is the same as yours. Actually, I would like to better feature what I meant.

Hard cells are allocated by exchanging 6top messages in the neighborhood, but the delivery of such messages is triggered by entities different from 6top. For instance, a PCE coordinating scheduling duties in centralized approaches. Decentralized or semi-centralized approaches would employ hard cells as well. The key role is played by a central manager which is intended to organize the cell allocation on each node in the network.

Soft cells, instead, could be used when a distributed approach is more fitting to the application scenario (e.g., when mobility should be accounted for). In this sense, OTF has been thought as a distributed solution that relies on 6top soft-cell allocation/reallocation/deletion.

Let's consider chunks. As far as I understood, they can be fruitfully exploited for avoiding collisions. A chunk is a subset of cells into the slotframe. If a node holds a chunk, it will be allowed to allocate cells in that subset. If the chunks related to each node in the network are well distributed or interleaved, each pair of nodes will allocate cells without interfering with other ones. For example, DeTAS (I presented some implementation at the plugfest) would benefit from chunks.  

In the current state of the 6TOP sublayer draft, it seems that chunks cannot be computed dynamically on each node. I mean, only the PCE can do this work or they should be preconfigured. I think it would be better to extend the chunk properties, allowing the exchange of IE messages for setting up proper chunks on each node. It is like having two levels of allocation: nodes exchange messages in order to choose a subset (chunk) of the slotframe where they could then allocate cells (after another round of message exchange). Is that viable?

In addition, I think that chunks could be useful in both centralized and distributed approaches for mitigating collisions. OTF would benefit for sure from allowing soft cells to be reserved in a chunk more than in the whole slotframe. Although OTF is distributed, there is always a central entity which can tune properly the network behavior. It would be like RPL: it is distributed, but the LLN sink is in charge of constructing the network. What am I missing?

Thanks
Nicola

Hi Nicola,

---

From: Nicola Accettura <[email-masked]>
Date: Thu, 20 Mar 2014 19:35:19 +0100

Hi Qin,
I think we are perfectly aligned.

Thank you
Nicola

2014-03-20 19:15 GMT+01:00 Qin Wang <[email-masked]>:

> Hi Nicola,
>
> I can see your point. Based on what you suggest about chunk, I think we
> can extent chunk related function as follows.
> (1) If a node receives a set of cells from PCE or its parent (a chunk), it
> can ask its children to delegate part of the chunk (sub-chunk) or the whole
> chunk.
> (2) The negotiation to allocate softcells can base on a given slotframe or
> a part of the slotframe (i.e. a chunk). Actually, it can be achieved based
> on current version of 6top, by using chunkID to define candidate list (see
> the sublayer draft).
>
> What do you think?
>
> Thanks
> Qin
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 20 Mar 2014 18:57:09 +0000

The problem, Qin, is that a chunk is only owned inside an interference domain.

If a parent subrents a piece of chunk to a child and the child uses it for a grand child to child communication, the grand child frame might interfere too far...

Cheers,
Pascal

Le 20 mars 2014 à 19:15, "Qin Wang" <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Nicola,

What do you think?

Thanks
Qin

On Friday, March 21, 2014 1:13 AM, Nicola Accettura <[email-masked]<mailto:[email-masked]>> wrote:
Hi Qin,
of course, my understanding is the same as yours. Actually, I would like to better feature what I meant.

Thanks
Nicola

2014-03-20 16:01 GMT+01:00 Qin Wang <[email-masked]<mailto:[email-masked]>>:
Hi Nicola,

Thanks
Qin

On Thursday, March 20, 2014 6:57 PM, Nicola Accettura <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,
the current version of the OTF draft speaks about the necessity of chunks as follows:

Cheers
Nicola

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

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

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

---

From: Qin Wang <[email-masked]>
Date: Thu, 20 Mar 2014 12:25:37 -0700 (PDT)

Hi Pascal,

You are right. If the parent has no knowledge about its children, grand-children's and grand-grand-children's topology, the renting, re-renting, and... may result in collision area. But if, like DeTas case, every parent has the topology knowledge (almost same information as PCE has), I think the collision could be avoided. Right?

Thanks
Qin

On Friday, March 21, 2014 2:57 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:

Cheers,
Pascal

Le 20 mars 2014 à 19:15, "Qin Wang" <[email-masked]> a écrit :

Hi Nicola,
>>"OTF is prone to schedule collision.  Nodes might not be aware of the cells allocated by other pairs of neighbors nodes.  A collision occurs when the same cell is allocated by different pairs in the same interference space.  The 6top sublayer cannot differentiate
 collisions from other sources of packet loss.  The probability ofhaving allocation collision may be kept low by grouping cells into chunks (see [I-D.ietf-6tisch-terminology] and [I-D.ietf-6tisch-architecture] for more details).  The use of chunks is outside
 the scope of this current version of the OTF draft."
>>"6top allows an upper layer to ask a node to manage a portion of a slotframe, called a chunk.  Chunks can be delegated explicitly by the PCE to a node, or claimed automatically by any node that participates to the distributed cell scheduling process.  The cells
 in a chunk can be appropriated by the node, i.e. the node is in charge of managing the chunk."

---

From: Tom Phinney <[email-masked]>
Date: Thu, 20 Mar 2014 13:31:47 -0700

Hi Qin,

Radio propagation and interference are not constant in time or
space. Even for fixed-location motes the actual extent of
interference changes with frequency, atmospheric conditions,
movement of any metal or person within the volume of space near the
sending or receiving antennae, etc. Then there is the "hidden
station" problem. Knowledge of three-dimensional topography is not
enough; one would need a site survey to determine, for a given
configuration of interfering and reflecting elements, the useful
propagation and destructive interference extents in 3-space of each
transmitter, and similarly the path attenuation seen by each
receiver relative to each of those senders.

Useful approximations of connectivity and interference can be
acquired without such a site survey, but only between pairs of
communicating nodes. The approximations degrade rapidly when one
attempts to extend this pairwise-transitively to additional nodes.
Thus the idea that a parent can determine the suitability of
propagation and extent of interference for child-to/from-grandchild
communication is questionable.

Note that I used the word "topography" since the "topology" of the
connectivity graph is not affected by the kind of movement of nodes
that would change interference relationships, so long as
intentionally-communicating pairs remained in communication.

-Tom

====

On 2014.03.20 12:25, Qin Wang wrote:

Hi Pascal,

You are right. If the parent has no
knowledge about its children, grand-children's and
grand-grand-children's topology, the renting, re-renting,
and... may result in collision area. But if, like DeTas
case, every parent has the topology knowledge (almost same
information as PCE has), I think the collision could be
avoided. Right?

Thanks

Qin

On Friday,
March 21, 2014 2:57 AM, Pascal Thubert (pthubert)
<[email-masked]> wrote:

The problem, Qin, is that a chunk is only owned
inside an interference domain.

If a parent subrents a piece of chunk to a
child and the child uses it for a grand child to
child communication, the grand child frame might
interfere too far...

Cheers,

Pascal

Le 20 mars 2014 à 19:15, "Qin Wang" <[email-masked]>
a écrit :

Hi Nicola,

I can see your point. Based on what
you suggest about chunk, I think we can
extent chunk related function as
follows.

(1) If a node receives a set of
cells from PCE or its parent (a chunk),
it can ask its children to delegate part
of the chunk (sub-chunk) or the whole
chunk.

(2) The negotiation to allocate
softcells can base on a given slotframe
or a part of the slotframe (i.e. a
chunk). Actually, it can be achieved
based on current version of 6top, by
using chunkID to define candidate list
(see the sublayer draft).

What do you think?

Thanks

Qin

On Friday, March 21,
2014 1:13 AM, Nicola Accettura
<[email-masked]>
wrote:

Hi Qin,

of course, my
understanding is the same as
yours. Actually, I would
like to better feature what
I meant.

Hard cells are allocated
by exchanging 6top messages
in the neighborhood, but the
delivery of such messages is
triggered by entities
different from 6top. For
instance, a PCE coordinating
scheduling duties in
centralized approaches.
Decentralized or
semi-centralized approaches
would employ hard cells as
well. The key role is played
by a central manager which
is intended to organize the
cell allocation on each node
in the network.

Soft cells, instead,
could be used when a
distributed approach is more
fitting to the application
scenario (e.g., when
mobility should be accounted
for). In this sense, OTF has
been thought as a
distributed solution that
relies on 6top soft-cell
allocation/reallocation/deletion.

Let's consider chunks. As
far as I understood, they
can be fruitfully exploited
for avoiding collisions. A
chunk is a subset of cells
into the slotframe. If a
node holds a chunk, it will
be allowed to allocate cells
in that subset. If the
chunks related to each node
in the network are well
distributed or interleaved,
each pair of nodes will
allocate cells without
interfering with other ones.
For example, DeTAS (I
presented some
implementation at the
plugfest) would benefit from
chunks.

In the current state of
the 6TOP sublayer draft, it
seems that chunks cannot be
computed dynamically on each
node. I mean, only the PCE
can do this work or they
should be preconfigured. I
think it would be better to
extend the chunk properties,
allowing the exchange of IE
messages for setting up
proper chunks on each node.
It is like having two levels
of allocation: nodes
exchange messages in order
to choose a subset (chunk)
of the slotframe where they
could then allocate cells
(after another round of
message exchange). Is that
viable?

In addition, I think
that chunks could be
useful in both centralized
and distributed approaches
for mitigating collisions.
OTF would benefit for sure
from allowing soft cells
to be reserved in a chunk
more than in the whole
slotframe. Although OTF is
distributed, there is
always a central entity
which can tune properly
the network behavior. It
would be like RPL: it is
distributed, but the LLN
sink is in charge of
constructing the network.
What am I missing?

Thanks

Nicola

2014-03-20
16:01 GMT+01:00 Qin Wang
<[email-masked]>:

Hi
Nicola,

Let's go
back one step to
discuss the
reason to
introduce Chunk
into 6top. My
understanding is
as follows.

6top supports
centralized
approach, i.e. PCE
schedules
hardcells for each
node. 6top
supports
distributed
approach, i.e. a
pair of node
allocate/reallocate
some softcells by
negotiation. Then,
Chunk is a
semi-centralized
approach, i.e. a
parent node is a
local center,
which delegate the
PCE and manages a
set of hardcell
(i.e. Chunk),
Comparing
centralized
approach, the
Chunk approach
will have
advantage in terms
of scalability and
adaptability to
dynamic radio
environment,
traffic load and
other change in
local.

Pascal, please
point out if I'm
wrong.

Thanks

Qin

On
Thursday,
March 20, 2014
6:57 PM,
Nicola
Accettura <[email-masked]>
wrote:

Dear
all,

the current
version of the
OTF draft
speaks about
the necessity
of chunks as
follows:

"OTF is prone
to schedule
collision.
Nodes might
not be aware
of the cells
allocated by
other pairs of
neighbors
nodes.  A
collision
occurs when
the same cell
is allocated
by different
pairs in the
same
interference
space.  The
6top sublayer
cannot
differentiate
collisions
from other
sources of
packet loss.
The
probability
ofhaving
allocation
collision may
be kept low by
grouping cells
into chunks
(see
[I-D.ietf-6tisch-terminology]
and
[I-D.ietf-6tisch-architecture]
for more
details).  The
use of chunks
is outside the
scope of this
current
version of the
OTF draft."

Actually, as
featured in
the 6TOP
sublayer
draft, chunks
can be managed
by a PCE or
configured by
upper layers:

"6top allows
an upper layer
to ask a node
to manage a
portion of a
slotframe,
called a
chunk.  Chunks
can be
delegated
explicitly by
the PCE to a
node, or
claimed
automatically
by any node
that
participates
to the
distributed
cell
scheduling
process.  The
cells in a
chunk can be
appropriated
by the node,
i.e. the node
is in charge
of managing
the chunk."

IMHO, to
be useful in
distributed
and/or
decentralized
contexts
chunks should
be given the
possibility to
be negotiated
within
specific IE.
What do you
think about
it?

In
addition, the
6TOP sublayer
draft allows
only hard
cells to be
selected in a
chunk. This is
clearly not
suitable for
OTF, which is
supposed to
work only with
soft cells. Am
I missing
something?

Cheers

Nicola

6tisch mailing
list

[email-masked]

6tisch mailing list

[email-masked]

6tisch mailing list

[email-masked]

6tisch mailing list

[email-masked]

---

From: Qin Wang <[email-masked]>
Date: Thu, 20 Mar 2014 14:09:53 -0700 (PDT)

Hi Tom,

I fully agree that the radio environment is time-varying. 

But, according to my understanding, in the centralized approaches like ISA100.11a and wirelessHART,  network manager can make un-conflicting (or approximate un-conflicting) schedule for each node. I guess the scheduling process bases on the information about network topology(or topograpy). Similarly, PCE should be able to make this kind of un-conflicting schedule after it get the topograpy information. Of course, sometime later, the un-conflicting situation may change while the radio environment changes significantly. Do you agree?

Now, question is if we can think a parent as a local PCE if it has the topograpy information of its subnet. My feeling is positive, but not very sure. If the answer is yes, I think the scheduling algorithm run in central PCE should be able to run on the parent, but only operate the chunk owned by the parent, instead of whole cells in the matrix of [slotOffset, channelOffset] of a slotframe. Make sense?

Thanks
Qin

On Thursday, March 20, 2014 4:31 PM, Tom Phinney <[email-masked]> wrote:
 
Hi Qin,

-Tom
====

Hi Pascal,
                                                          version of the
                                                          OTF draft
                                                          speaks about
                                                          the necessity
                                                          of chunks as
                                                          to schedule
                                                          collision.
                                                           Nodes might
                                                          not be aware
                                                          of the cells
                                                          allocated by
                                                          other pairs of
                                                          neighbors
                                                          nodes.  A
                                                          collision
                                                          occurs when
                                                          the same cell
                                                          is allocated
                                                          by different
                                                          pairs in the
                                                          same
                                                          interference
                                                          space.  The
                                                          6top sublayer
                                                          cannot
                                                          differentiate
                                                          collisions
                                                          from other
                                                          sources of
                                                          packet loss.
                                                           The
                                                          probability
                                                          ofhaving
                                                          allocation
                                                          collision may
                                                          be kept low by
                                                          grouping cells
                                                          into chunks
                                                          (see
                                                          featured in
                                                          the 6TOP
                                                          sublayer
                                                          draft, chunks
                                                          can be managed
                                                          by a PCE or
                                                          configured by
                                                          an upper layer
                                                          to ask a node
                                                          to manage a
                                                          portion of a
                                                          slotframe,
                                                          called a
                                                          chunk.  Chunks
                                                          can be
                                                          delegated
                                                          explicitly by
                                                          the PCE to a
                                                          node, or
                                                          claimed
                                                          automatically
                                                          by any node
                                                          that
                                                          participates
                                                          to the
                                                          distributed
                                                          cell
                                                          scheduling
                                                          process.  The
                                                          cells in a
                                                          chunk can be
                                                          appropriated
                                                          by the node,
                                                          i.e. the node
                                                          is in charge
                                                          of managing
                                                          the chunk."
                                                          list
>>>https://www.ietf.org/mailman/listinfo/6tisch
6tisch mailing list [email-masked] https://www.ietf.org/mailman/listinfo/6tisch

---

From: Nicola Accettura <[email-masked]>
Date: Thu, 20 Mar 2014 23:31:57 +0100

Dear all,
considering DeTAS, a parent must only know how much traffic will be
received from each of its own children, nothing else. Actually, a parent
would not delegate part of its chunk, but would compute a new chunk for
each child. A DeTAS node would hold a chunk for communicating to its parent
and a chunk for each child, and these chunks are interleaved and set on
different channel offsets (hidden and exposed terminal problems are thus
faced).

In this context a question arise: could a node own more than one chunk?

Nicola

2014-03-20 22:09 GMT+01:00 Qin Wang <[email-masked]>:

> But, according to my understanding, in the centralized approaches like
> ISA100.11a and wirelessHART,  network manager can make un-conflicting (or
> approximate un-conflicting) schedule for each node. I guess the scheduling
> process bases on the information about network topology(or topograpy).
> Similarly, PCE should be able to make this kind of un-conflicting schedule
> after it get the topograpy information. Of course, sometime later, the
> un-conflicting situation may change while the radio environment changes
> significantly. Do you agree?
>
> Now, question is if we can think a parent as a local PCE if it has the
> topograpy information of its subnet. My feeling is positive, but not very
> sure. If the answer is yes, I think the scheduling algorithm run in central
> PCE should be able to run on the parent, but only operate the chunk owned
> by the parent, instead of whole cells in the matrix of [slotOffset,
> channelOffset] of a slotframe. Make sense?
>
> Thanks
> Qin
>
>
> Radio propagation and interference are not constant in time or space. Even
> for fixed-location motes the actual extent of interference changes with
> frequency, atmospheric conditions, movement of any metal or person within
> the volume of space near the sending or receiving antennae, etc. Then there
> is the "hidden station" problem. Knowledge of three-dimensional topography
> is not enough; one would need a site survey to determine, for a given
> transmitter, and similarly the path attenuation seen by each receiver
> relative to each of those senders.
>
> Useful approximations of connectivity and interference can be acquired
> without such a site survey, but only between pairs of communicating nodes.
> The approximations degrade rapidly when one attempts to extend this
> pairwise-transitively to additional nodes. Thus the idea that a parent can
> determine the suitability of propagation and extent of interference for
> child-to/from-grandchild communication is questionable.
>
> connectivity graph is not affected by the kind of movement of nodes that
> would change interference relationships, so long as
>  You are right. If the parent has no knowledge about its children,
> grand-children's and grand-grand-children's topology, the renting,
> re-renting, and... may result in collision area. But if, like DeTas case,
> every parent has the topology knowledge (almost same information as PCE
> has), I think the collision could be avoided. Right?
>
>  Thanks
> Qin
>
>
>   On Friday, March 21, 2014 2:57 AM, Pascal Thubert (pthubert)
> <[email-masked]> <[email-masked]> wrote:
>  If a parent subrents a piece of chunk to a child and the child uses it
> for a grand child to child communication, the grand child frame might
> interfere too far...
>
>  Cheers,
> Pascal
>
>  (1) If a node receives a set of cells from PCE or its parent (a chunk),
> it can ask its children to delegate part of the chunk (sub-chunk) or the
> whole chunk.
>  (2) The negotiation to allocate softcells can base on a given slotframe
> or a part of the slotframe (i.e. a chunk). Actually, it can be achieved
> based on current version of 6top, by using chunkID to define candidate list
>  Hard cells are allocated by exchanging 6top messages in the
> neighborhood, but the delivery of such messages is triggered by entities
> different from 6top. For instance, a PCE coordinating scheduling duties in
> centralized approaches. Decentralized or semi-centralized approaches would
> employ hard cells as well. The key role is played by a central manager
> which is intended to organize the cell allocation on each node in the
> network.
>
>  6top supports centralized approach, i.e. PCE schedules hardcells for
> each node. 6top supports distributed approach, i.e. a pair of node
>  In addition, the 6TOP sublayer draft allows only hard cells to be
> selected in a chunk. This is clearly not suitable for OTF, which is
> supposed to work only with soft cells. Am I missing something?
>
>  Cheers
> Nicola
>
> 6tisch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tisch
>
>
>

---

From: Tom Phinney <[email-masked]>
Date: Thu, 20 Mar 2014 15:37:34 -0700

Hi Qin,

If the PCE has the full topography information, essentially in terms
of a 3-D propagation boundary (there are many ways to abstract an
approximation of this), then it can in theory make the same
computation as a centralized scheduler. The real question then
becomes one of PCE resources: does it have a complete-enough
database of nearby (in a propagation sense) nodes, and the compute
power to analyze the situation. My sense is that the compute power
required for an incremental change is relatively small, but that the
database could be large unless motes reduce their transmit power in
some cases to limit the number of devices in range.

An example of a problem scenario for this latter, in an industrial
environment, can be found in the pharmaceutical industry where
movable bio-reactor columns are on palettes, each with perhaps sixty
sensors and actuators within a 2 m radius cylinder that itself is
perhaps 2-3 m tall. Depending on the contract for finished product,
one or more of these palettized reactors can be placed essentially
side-by-side, perhaps only 3 m apart, so that it is easy to furnish
them all with the same raw materials. That places a number of what
should be independent subnets in very close proximity. A centralized
scheduler with visibility of the entire ensemble can optimize the
schedule to minimize interference, but it seems unlikely that any
local PCE for one reactor column has the needed information about
the other nearby reactor columns that such an optimization would
require.

Most use cases would not be so extreme, but it is entirely feasible
that there are a lot of local nodes in the vicinity that can be
coordinated in theory, but may not be under control of a single PCE.
Side-by-side businesses in a strip mall provide another example of
this. Of course in the limit everything devolves to slotted or
unslotted Aloha, at least on a per-physical-channel basis, but we
hope to do much better than that.

-Tom

=====

On 2014.03.20 14:09, Qin Wang wrote:

Hi Tom,

I fully agree that the radio environment
is time-varying.

But, according to my understanding, in
the centralized approaches like ISA100.11a and wirelessHART,  network manager can make
un-conflicting (or approximate un-conflicting) schedule for
each node. I guess the scheduling process bases on the
information about network topology(or topograpy). Similarly,
PCE should be able to make this kind of un-conflicting
schedule after it get the topograpy information. Of course,
sometime later, the un-conflicting situation may change
while the radio environment changes significantly. Do you
agree?

Now, question is if we can think a parent
as a local PCE if it has the topograpy information of its
subnet. My feeling is positive, but not very sure. If the
answer is yes, I think the scheduling algorithm run in central
PCE should be able to run on the parent, but only operate the
chunk owned by the parent, instead of whole cells in the
matrix of [slotOffset, channelOffset] of a slotframe. Make
sense?

Thanks

Qin

On Thursday,
March 20, 2014 4:31 PM, Tom Phinney
<[email-masked]> wrote:

Hi Qin,

Radio propagation and interference are not constant
in time or space. Even for fixed-location motes the
actual extent of interference changes with
frequency, atmospheric conditions, movement of any
metal or person within the volume of space near the
sending or receiving antennae, etc. Then there is
the "hidden station" problem. Knowledge of
three-dimensional topography is not enough; one
would need a site survey to determine, for a given
configuration of interfering and reflecting
elements, the useful propagation and destructive
interference extents in 3-space of each transmitter,
and similarly the path attenuation seen by each
receiver relative to each of those senders.

Useful approximations of connectivity and
interference can be acquired without such a site
survey, but only between pairs of communicating
nodes. The approximations degrade rapidly when one
attempts to extend this pairwise-transitively to
additional nodes. Thus the idea that a parent can
determine the suitability of propagation and extent
of interference for child-to/from-grandchild
communication is questionable.

Note that I used the word "topography" since the
"topology" of the connectivity graph is not affected
by the kind of movement of nodes that would change
interference relationships, so long as
intentionally-communicating pairs remained in
communication.

-Tom

====

On
2014.03.20 12:25, Qin Wang wrote:

Hi Pascal,

You
are right. If the parent has no knowledge
about its children, grand-children's and
grand-grand-children's topology, the
renting, re-renting, and... may result in
collision area. But if, like DeTas case,
every parent has the topology knowledge
(almost same information as PCE has), I
think the collision could be avoided. Right?

Thanks

Qin

On Friday, March 21,
2014 2:57 AM, Pascal Thubert
(pthubert) <[email-masked]>
wrote:

The problem, Qin, is that a
chunk is only owned inside an
interference domain.

If a parent subrents a piece of
chunk to a child and the child
uses it for a grand child to child
communication, the grand child
frame might interfere too far...

Cheers,

Pascal

Le 20 mars 2014 à 19:15, "Qin
Wang" <[email-masked]>

a écrit :

Hi Nicola,

I can see
your point. Based on
what you suggest about
chunk, I think we can
extent chunk related
function as follows.

(1) If a
node receives a set of
cells from PCE or its
parent (a chunk), it can
ask its children to
delegate part of the
chunk (sub-chunk) or the
whole chunk.

(2) The
negotiation to allocate
softcells can base on a
given slotframe or a
part of the slotframe
(i.e. a chunk).
Actually, it can be
achieved based on
current version of 6top,
by using chunkID to
define candidate list
(see the sublayer
draft).

What do
you think?

Thanks

Qin

On
Friday, March 21,
2014 1:13 AM,
Nicola Accettura

Hi
Qin,

of
course, my
understanding
is the same as
yours.
Actually, I
would like to
better feature
what I meant.

Hard
cells are
allocated by
exchanging
6top messages
in the
neighborhood,
but the
delivery of
such messages
is triggered
by entities
different from
6top. For
instance, a
PCE
coordinating
scheduling
duties in
centralized
approaches.
Decentralized
or
semi-centralized
approaches
would employ
hard cells as
well. The key
role is played
by a central
manager which
is intended to
organize the
cell
allocation on
each node in
the network.

Soft
cells,
instead, could
be used when a
distributed
approach is
more fitting
to the
application
scenario
(e.g., when
mobility
should be
accounted
for). In this
sense, OTF has
been thought
as a
distributed
solution that
relies on 6top
soft-cell

Let's
consider
chunks. As far
as I
understood,
they can be
fruitfully
exploited for
avoiding
collisions. A
chunk is a
subset of
cells into the
slotframe. If
a node holds a
chunk, it will
be allowed to
allocate cells
in that
subset. If the
chunks related
to each node
in the network
are well
distributed or
interleaved,
each pair of
nodes will
allocate cells
without
interfering
with other
ones. For
example, DeTAS
(I presented
some
implementation
at the
plugfest)
would benefit
from chunks.

In the
current state
of the 6TOP
sublayer
draft, it
seems that
chunks cannot
be computed
dynamically on
each node. I
mean, only the
PCE can do
this work or
they should be
preconfigured.
I think it
would be
better to
extend the
chunk
properties,
allowing the
exchange of IE
messages for
setting up
proper chunks
on each node.
It is like
having two
levels of
allocation:
nodes exchange
messages in
order to
choose a
subset (chunk)
of the
slotframe
where they
could then
allocate cells
(after another
round of
message
exchange). Is
that viable?

In
addition, I
think that
chunks could
be useful in
both
centralized
and
distributed
approaches for
mitigating
collisions.
OTF would
benefit for
sure from
allowing soft
cells to be
reserved in a
chunk more
than in the
whole
slotframe.
Although OTF
is
distributed,
there is
always a
central entity
which can tune
properly the
network
behavior. It
would be like
RPL: it is
distributed,
but the LLN
sink is in
charge of
constructing
the network.
What am I
missing?

Thanks

Nicola

2014-03-20

16:01
GMT+01:00 Qin
Wang
<[email-masked]>:

Hi
Nicola,

Let's go
back one step
to discuss the
reason to
introduce
Chunk into
6top. My
understanding
is as
follows.

6top supports
centralized
approach, i.e.
PCE schedules
hardcells for
each node.
6top supports
distributed
approach, i.e.
a pair of node
allocate/reallocate

some softcells
by
negotiation.
Then, Chunk is
a
semi-centralized
approach, i.e.
a parent node
is a local
center, which
delegate the
PCE and
manages a set
of hardcell
(i.e. Chunk),
Comparing
centralized
approach, the
Chunk approach
will have
advantage in
terms of
scalability
and
adaptability
to dynamic
radio
environment,
traffic load
and other
change in
local.

Pascal, please
point out if
I'm wrong.

Thanks

Qin

On

Thursday,
March 20, 2014
6:57 PM,
Nicola

wrote:

Dear

all,

the current
version of the
OTF draft
speaks about
the necessity
of chunks as
follows:

"OTF is prone
to schedule
collision.
Nodes might
not be aware
of the cells
allocated by
other pairs of
neighbors
nodes.  A
collision
occurs when
the same cell
is allocated
by different
pairs in the
same
interference
space.  The
6top sublayer
cannot
differentiate
collisions
from other
sources of
packet loss.
The
probability
ofhaving
allocation
collision may
be kept low by
grouping cells
into chunks
(see

Actually, as
featured in
the 6TOP
sublayer
draft, chunks
can be managed
by a PCE or
configured by
upper layers:

"6top allows
an upper layer
to ask a node
to manage a
portion of a
slotframe,
called a
chunk.  Chunks
can be
delegated
explicitly by
the PCE to a
node, or
claimed
automatically
by any node
that
participates
to the
distributed
cell
scheduling
process.  The
cells in a
chunk can be
appropriated
by the node,
i.e. the node
is in charge
of managing
the chunk."

IMHO, to
be useful in
distributed
and/or
decentralized
contexts
chunks should
be given the
possibility to
be negotiated
within
specific IE.
What do you
think about
it?

In
addition, the
6TOP sublayer
draft allows
only hard
cells to be
selected in a
chunk. This is
clearly not
suitable for
OTF, which is
supposed to
work only with
soft cells. Am
I missing
something?

Cheers

Nicola

6tisch mailing
list

[email-masked]

6tisch mailing
list

[email-masked]

6tisch mailing list

[email-masked]

6tisch mailing list

[email-masked]

6tisch mailing list

[email-masked]

---

From: Qin Wang <[email-masked]>
Date: Thu, 20 Mar 2014 17:07:38 -0700 (PDT)

Hi Nicola,

In DeTAS, is it assumed or required that the chunks in same radio area do not conflict with each other? If yes, how to compute the new chunks without the knowledge about its children's radio environment?

Thanks
Qin

On Thursday, March 20, 2014 6:45 PM, Nicola Accettura <[email-masked]> wrote:
 
Dear all,

considering DeTAS, a parent must  only know how much traffic will be received from each of its own children, nothing else. Actually, a parent would not delegate part of its chunk, but would compute a new chunk for each child. A DeTAS node would hold a chunk for communicating to its parent and a chunk for each child, and these chunks are interleaved and set on different channel offsets (hidden and exposed terminal problems are thus faced).

Nicola

Hi Tom,
                                                          version of the
                                                          OTF draft
                                                          speaks about
                                                          the necessity
                                                          of chunks as
                                                          to schedule
                                                          collision.
                                                           Nodes might
                                                          not be aware
                                                          of the cells
                                                          allocated by
                                                          other pairs of
                                                          neighbors
                                                          nodes.  A
                                                          collision
                                                          occurs when
                                                          the same cell
                                                          is allocated
                                                          by different
                                                          pairs in the
                                                          same
                                                          interference
                                                          space.  The
                                                          6top sublayer
                                                          cannot
                                                          differentiate
                                                          collisions
                                                          from other
                                                          sources of
                                                          packet loss.
                                                           The
                                                          probability
                                                          ofhaving
                                                          allocation
                                                          collision may
                                                          be kept low by
                                                          grouping cells
                                                          into chunks
                                                          (see
                                                          featured in
                                                          the 6TOP
                                                          sublayer
                                                          draft, chunks
                                                          can be managed
                                                          by a PCE or
                                                          configured by
                                                          an upper layer
                                                          to ask a node
                                                          to manage a
                                                          portion of a
                                                          slotframe,
                                                          called a
                                                          chunk.  Chunks
                                                          can be
                                                          delegated
                                                          explicitly by
                                                          the PCE to a
                                                          node, or
                                                          claimed
                                                          automatically
                                                          by any node
                                                          that
                                                          participates
                                                          to the
                                                          distributed
                                                          cell
                                                          scheduling
                                                          process.  The
                                                          cells in a
                                                          chunk can be
                                                          appropriated
                                                          by the node,
                                                          i.e. the node
                                                          is in charge
                                                          of managing
                                                          the chunk."
                                                          list

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 21 Mar 2014 07:09:14 +0000

Hello Qin,

I think Tom was very clear and I fully share his views and concerns. Topologies and topographies are very different beasts, each one very difficult to learn and maintain. Let me detail my thoughts in complement to Tom's words.

As a Distance Vector protocol, RPL allows devices to ignore both to space control and memory space. This was a conscious design point. I do not see the motes growing all of a sudden to the capacity to know about both.

The computation in the system (or network) manager is opaque to the outside and I do not know what people did effectively. This being said, for all I know from the outside, the computation ignores other networks even within interference domain.So the simplifying assumption that I expect to find there is to assume a single interference domain for all and use a chunk only once.

With 6TiSCH, we synchronize multiple DODAGs connected to a same backbone, allowing devices to jump from one DODAG to the next. The expectation for a chunk is that around a device that allocates the chunk, a domain will form where that chunk will not be reused. But outside that domain, the chunk will be reused so we can grow the network to the 10s of thousands.

As a result, each given chunk will create a partition of the network, "coloring" zones around the non-interfering RPL parents that use it. That coloring is related to the topology in that the colored zone comprises a RPL parent and its children. It is also related to topography in that colored zones do not overlap.

We have to design the way this will happen and that will probably be very similar to what we call automated site survey, or Radio Resource Management, or in Cisco marketing parlance, clean air. We know it is doable for having done similar work before, and so we can assume that this WG will achieve that goal. But we must work to make it very simple and with a minimum amount of state in the devices.

All in all, I'm afraid that subletting chunks to children is actually a drift from IETF work to IRTF or academic research.

Cheers,

Pascal

From: Qin Wang [mailto:[email-masked]]
Sent: jeudi 20 mars 2014 22:10
To: Tom Phinney; Pascal Thubert (pthubert)
Cc: Nicola Accettura; [email-masked]
Subject: Re: [6tisch] OTF & chunks

Hi Tom,

Thanks
Qin

On Thursday, March 20, 2014 4:31 PM, Tom Phinney <[email-masked]<mailto:[email-masked]>> wrote:
Hi Qin,

Radio propagation and interference are not constant in time or space. Even for fixed-location motes the actual extent of interference changes with frequency, atmospheric conditions, movement of any metal or person within the volume of space near the sending or receiving antennae, etc. Then there is the "hidden station" problem. Knowledge of three-dimensional topography is not enough; one would need a site survey to determine, for a given configuration of interfering and reflecting elements, the useful propagation and destructive interference extents in 3-space of each transmitter, and similarly the path attenuation seen by each receiver relative to each of those senders.

Useful approximations of connectivity and interference can be acquired without such a site survey, but only between pairs of communicating nodes. The approximations degrade rapidly when one attempts to extend this pairwise-transitively to additional nodes. Thus the idea that a parent can determine the suitability of propagation and extent of interference for child-to/from-grandchild communication is questionable.

Note that I used the word "topography" since the "topology" of the connectivity graph is not affected by the kind of movement of nodes that would change interference relationships, so long as intentionally-communicating pairs remained in communication.

-Tom
====

Thanks
Qin

On Friday, March 21, 2014 2:57 AM, Pascal Thubert (pthubert) <[email-masked]><mailto:[email-masked]> wrote:
The problem, Qin, is that a chunk is only owned inside an interference domain.

Cheers,
Pascal

What do you think?

Thanks
Qin

Thanks
Nicola

Thanks
Qin

Cheers
Nicola

6tisch mailing list

---

From: Nicola Accettura <[email-masked]>
Date: Fri, 21 Mar 2014 13:33:57 +0100

Hi Pascal, Qin, Tom,
I've got your points. I agree that chunks should not be sublet to children.
This is not what I was meaning. Perhaps, a node should be given the
possibility to create a new chunk (not overlapped with that shared with its
parent) and communicate neighbor-to-neighbor the new chunk to its children.
Chunks would color different interfering zones also in this case.

Chunks partition the slotframe matrix, and should be not overlapped.
Overlapped chunks could happen, but a schuduling technique (out of scope of
IETF) could be in charge of allowing such overlaps only for pair of nodes
which are far and possibly not keen to interfering each other. Such
partition can be made by the PCE, but also in a decentralized fashion.

Some examples: TASA creates chunks in centralized fashion, DeTAS in a
decentralized one. Here, I guess, we are abstracting from specific
allocation algorithms. At the same time, IMHO, all possibilities should be
accounted, am I right? Until now, chunks would work with centralized
algorithm. My proposal is to extend chunks to be computed in a
decentralized/distributed way, thus requiring specific IE to be exchanged
neighbor-to-neighbor. How that computation is perfomed is out of scope, of
course. But I believe it should be allowed in some way.

What do you think?

Yours sincerely
Nicola

2014-03-21 8:09 GMT+01:00 Pascal Thubert (pthubert) <[email-masked]>:

>  Hello Qin,
>
>
>
> I think Tom was very clear and I fully share his views and concerns.
> Topologies and topographies are very different beasts, each one very
> difficult to learn and maintain. Let me detail my thoughts in complement to
> Tom's words.
>
>
>
> As a Distance Vector protocol, RPL allows devices to ignore both to space
> control and memory space. This was a conscious design point. I do not see
> the motes growing all of a sudden to the capacity to know about both.
>
>
>
> The computation in the system (or network) manager is opaque to the
> outside and I do not know what people did effectively. This being said, for
> all I know from the outside, the computation ignores other networks even
> within interference domain.So the simplifying assumption that I expect to
> find there is to assume a single interference domain for all and use a
> chunk only once.
>
>
>
> With 6TiSCH, we synchronize multiple DODAGs connected to a same backbone,
> allowing devices to jump from one DODAG to the next. The expectation for a
> chunk is that around a device that allocates the chunk, a domain will form
> where that chunk will not be reused. But outside that domain, the chunk
> will be reused so we can grow the network to the 10s of thousands.
>
>
>
> As a result, each given chunk will create a partition of the network,
> "coloring" zones around the non-interfering RPL parents that use it. That
> coloring is related to the topology in that the colored zone comprises a
> RPL parent and its children. It is also related to topography in that
> colored zones do not overlap.
>
>
>
> We have to design the way this will happen and that will probably be very
> similar to what we call automated site survey, or Radio Resource
> Management, or in Cisco marketing parlance, clean air. We know it is doable
> for having done similar work before, and so we can assume that this WG will
> achieve that goal. But we must work to make it very simple and with a
> minimum amount of state in the devices.
>
>
>
> All in all, I'm afraid that subletting chunks to children is actually a
> drift from IETF work to IRTF or academic research.
>
>
>
> Cheers,
>
>
>
> Pascal
>
>
>
> *From:* Qin Wang [mailto:[email-masked]]
> *Sent:* jeudi 20 mars 2014 22:10
> *To:* Tom Phinney; Pascal Thubert (pthubert)
> *Cc:* Nicola Accettura; [email-masked]
> *Subject:* Re: [6tisch] OTF & chunks
>
>
>
> Hi Tom,
>
>
>
> If a parent subrents a piece of chunk to a child and the child uses it for
> a grand child to child communication, the grand child frame might interfere
> too far...
>
>
>
> Cheers,
> Pascal
>
>

---

From: Qin Wang <[email-masked]>
Date: Fri, 21 Mar 2014 07:04:44 -0700 (PDT)

Hi Pascal, Tom and Nicola,

I fully agree subletting chunks to children is not suitable to 6tisch.

But, how to collect information and compute new chunk locally is still a question for me. According to my understanding, the colored zone method requires the set of Colors are pre-defined, in another word, the chunk partition should be network-wide. Right? Based on the assumption, I think we can select chunk from the pre-defined chunk set locally by some sort of 6top-to-6top communication, but I can not see how it works to create/compute new chunks locally.

Maybe I missed something.

Thanks
Qin

On Friday, March 21, 2014 3:09 PM, Pascal Thubert (pthubert) <[email-masked]> wrote:
 
Hello Qin,
 
I think Tom was very clear and I fully share his views and concerns. Topologies and topographies are very different beasts, each one very difficult to learn and maintain. Let me detail my thoughts in complement to Tom’s words.

 
 
As a result, each given chunk will create a partition of the network, “coloring” zones around the non-interfering RPL parents that use it. That coloring is related to the topology in that the colored zone comprises a RPL parent and its children. It is also related to topography in that colored zones do not overlap.

All in all, I’m afraid that subletting chunks to children is actually a drift from IETF work to IRTF or academic research.
 
Cheers,
 
Pascal
 
From:Qin Wang [mailto:[email-masked]] 
 
Hi Tom,

 
 
Thanks
Qin

Radio propagation and interference are not constant in time or space. Even for fixed-location motes the actual extent of interference changes with frequency, atmospheric conditions, movement of any metal or person within the volume of space near the sending
 or receiving antennae, etc. Then there is the "hidden station" problem. Knowledge of three-dimensional topography is not enough; one would need a site survey to determine, for a given configuration of interfering and reflecting elements, the useful propagation
 and destructive interference extents in 3-space of each transmitter, and similarly the path attenuation seen by each receiver relative to each of those senders.

Useful approximations of connectivity and interference can be acquired without such a site survey, but only between pairs of communicating nodes. The approximations degrade rapidly when one attempts to extend this pairwise-transitively to additional nodes.
 Thus the idea that a parent can determine the suitability of propagation and extent of interference for child-to/from-grandchild communication is questionable.

-Tom
====

---

From: <[email-masked]>
Date: Fri, 21 Mar 2014 14:07:35 +0000

Dear Pascal, All,
I wish I understood your concern on the distributed scheme in allocating the chunk in interfering zones.
Two routers that are far enough from each other (e.g., two-hops away from each other) can reuse a same chunk. In a realistic setting, the interference range of a node may be much larger than its transmission range. When two pairs using the same selected chunk, communicate concurrently, interference will be unavoidable. Thanks to the scheduled communication concepts, this internal interference can be detected by observing the constant packet loss in those cells (belonging to that chuck) after reservation. The router that detects the potential conflict can change its chosen chunk, make it blacklist, and, subsequently, choose a new unused chunk in its neighborhood. Am I right?
Regards,
Pouria

From: 6tisch [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: Friday, March 21, 2014 3:05 PM
To: Pascal Thubert (pthubert); Tom Phinney
Cc: Nicola Accettura; [email-masked]
Subject: Re: [6tisch] OTF & chunks

Thanks
Qin

On Friday, March 21, 2014 3:09 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Qin,

Cheers,

Pascal

Cc: Nicola Accettura; [email-masked]<mailto:[email-masked]>

Hi Tom,

Thanks
Qin

-Tom
====

Thanks
Qin

Cheers,
Pascal

What do you think?

Thanks
Qin

Thanks
Nicola

Thanks
Qin

Cheers
Nicola

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 21 Mar 2014 14:09:11 +0000

Exact same here, Qin

My understanding is that the chunks must be well-known by all to start with.

Cheers,

Pascal

Sent: vendredi 21 mars 2014 15:05

Thanks
Qin

Cheers,

Pascal

Hi Tom,

Thanks
Qin

-Tom
====

Thanks
Qin

Cheers,
Pascal

What do you think?

Thanks
Qin

Thanks
Nicola

Thanks
Qin

Cheers
Nicola

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 21 Mar 2014 14:16:05 +0000

Hi Pouria;

The process to appropriate a chunk must reach farther than one transmission range if we want to limit the interference.
Xavi already discussed some methods based on multi-hop gossiping. It will be delicate to make it perfect but good enough in certainly in reach.
Then will come the question of external interferers, which can be treated as you explain.

We have concern, though, with the idea that the definition of the chunks could change in the network. For the time being chunks are well known so when I gossip “I want chunk 5” everyone knows which group of cells I wish to appropriate for myself in my interference domain…

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]]
Sent: vendredi 21 mars 2014 15:08
To: [email-masked]; Pascal Thubert (pthubert); [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [6tisch] OTF & chunks

Dear Pascal, All,

Thanks
Qin

Cheers,

Pascal

Hi Tom,

Thanks
Qin

-Tom
====

Thanks
Qin

Cheers,
Pascal

What do you think?

Thanks
Qin

Thanks
Nicola

Thanks
Qin

Cheers
Nicola

---

From: <[email-masked]>
Date: Fri, 21 Mar 2014 14:32:29 +0000

Hi Pascal,
Let me explain my point more clearly.
By internal interference I mean the interference from inside the network’s communication or the collisions caused by concurrent communications in the same cells or chunks. In addition, I assume that all the nodes have already agreed to use the same chunk size in the network.
I completely agree with you that we must reach farther that one hop. In my scenario, I assumed that each node has already gathered in list of reserved chucks in its two-hop neighborhood. However, this two-hop information cannot guarantees the interference free communication. Because, in a realistic setting, the interference range of a node may be much larger than its transmission range. When two pairs using the same selected chunk, communicate concurrently, interference will be unavoidable. Thanks to the scheduled communication concepts, this internal interference can be detected by observing the constant packet loss in those cells (belonging to that chuck) after reservation.
When a router detects that a particular chunk is already used outside of its neighborhood (by observing this constant collisions), it can blacklist the chunk. Blacklisting the chunk (unlike the blacklisting the frequency-channel 11-26 that is used to cope with external interference) can be used to cope with this internal interference, which is caused by having the conflicting zones in the network.

Am I right?

Regards,
Pouria

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Friday, March 21, 2014 3:16 PM
To: Zand, P. (EWI); [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [6tisch] OTF & chunks

Hi Pouria;

Cheers,

Pascal

Dear Pascal, All,
I wish I understood your concern on the distributed scheme in allocating the chunk in interfering zones.
Two routers that are far enough from each other (e.g., two-hops away from each other) can reuse a same chunk. Dear Pascal,
I wish I understood your concern on the distributed scheme in allocating the chunk in interfering zones.
Two routers that are far enough from each other (e.g., two-hops away from each other) can reuse a same chunk. In a realistic setting, the interference range of a node may be much larger than its transmission range. When two pairs using the same selected chunk, communicate concurrently, interference will be unavoidable. Thanks to the scheduled communication concepts, this internal interference can be detected by observing the constant packet loss in those cells (belonging to that chuck) after reservation. The router that detects the potential conflict can change its chosen chunk, make it blacklist, and, subsequently, choose a new unused chunk in its neighborhood.
Am I right?
Regards,
Pouria. Thanks to the scheduled communication concepts, this internal interference can be detected by observing the constant packet loss in those cells (belonging to that chuck) after reservation. The router that detects the potential conflict can change its chosen chunk, make it blacklist, and, subsequently, choose a new unused chunk in its neighborhood. Am I right?
Regards,
Pouria

Thanks
Qin

Cheers,

Pascal

Hi Tom,

Thanks
Qin

-Tom
====

Thanks
Qin

Cheers,
Pascal

What do you think?

Thanks
Qin

Thanks
Nicola

Thanks
Qin

Cheers
Nicola

---

From: Martin Turon <[email-masked]>
Date: Fri, 21 Mar 2014 08:34:43 -0700

Hi All,

I like the idea of decentralized chunk allocation.  

Perhaps some sort of sudoku-generator-like function can be found that generates numbers of the same length where all digits at a given placement are unique across the set.   Each digit would represent a channel, so if in base 16 hexadecimal, up to 16 channels would be allowed.  The digit placement would be the slot, and the total number of digits would be fixed and represent the slot frame size or some agreed upon subset of the slot frame for children.  

long chunkGet(int chunkId, int seed, int base, int length);

12654
27483
...

It may be good to have another utility function that outputs the maximum chunkID or total number of unique chunks across the given space based on the base and length parameter.

The seed would allow cycling through the various permutations in time across the set.  The generator function would have to be deterministic and agreed upon for it to work.

Martin

> On Mar 21, 2014, at 5:33 AM, Nicola Accettura <[email-masked]> wrote:
> 
> Hi Pascal, Qin, Tom,
> I've got your points. I agree that chunks should not be sublet to children. This is not what I was meaning. Perhaps, a node should be given the possibility to create a new chunk (not overlapped with that shared with its parent) and communicate neighbor-to-neighbor the new chunk to its children. Chunks would color different interfering zones also in this case.
> 
> Chunks partition the slotframe matrix, and should be not overlapped. Overlapped chunks could happen, but a schuduling technique (out of scope of IETF) could be in charge of allowing such overlaps only for pair of nodes which are far and possibly not keen to interfering each other. Such partition can be made by the PCE, but also in a decentralized fashion.
> 
> Some examples: TASA creates chunks in centralized fashion, DeTAS in a decentralized one. Here, I guess, we are abstracting from specific allocation algorithms. At the same time, IMHO, all possibilities should be accounted, am I right? Until now, chunks would work with centralized algorithm. My proposal is to extend chunks to be computed in a decentralized/distributed way, thus requiring specific IE to be exchanged neighbor-to-neighbor. How that computation is perfomed is out of scope, of course. But I believe it should be allowed in some way.
> 
> What do you think?
> 
> Yours sincerely
> Nicola 
> 
> 
> 
> 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 21 Mar 2014 16:39:02 +0000

Hi Martin:

Very neat! This is the sort of algorithm that we are after.
At this point we need to make sure that the parameters to reconstruct the chunks in the nodes are passed through the 6top interface.
I’d love to see a draft enumerating a few techniques to describe the chunks in a compressed form.
That would be a nice RFC for the 6TiSCH family when we recharter.

Cheers,

Pascal

From: Martin Turon [mailto:[email-masked]]
Sent: vendredi 21 mars 2014 16:35
To: Nicola Accettura
Cc: Pascal Thubert (pthubert); Qin Wang; Tom Phinney; [email-masked]
Subject: Re: [6tisch] OTF & chunks

Hi All,

12654
27483
...

Martin

On Mar 21, 2014, at 5:33 AM, Nicola Accettura <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pascal, Qin, Tom,
I've got your points. I agree that chunks should not be sublet to children. This is not what I was meaning. Perhaps, a node should be given the possibility to create a new chunk (not overlapped with that shared with its parent) and communicate neighbor-to-neighbor the new chunk to its children. Chunks would color different interfering zones also in this case.

What do you think?

Yours sincerely
Nicola

2014-03-21 8:09 GMT+01:00 Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>:
Hello Qin,

Cheers,

Pascal

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

Hi Tom,

Thanks
Qin

-Tom
====

Thanks
Qin

Cheers,
Pascal

What do you think?

Thanks
Qin

Thanks
Nicola

Thanks
Qin

Cheers
Nicola

6tisch mailing list