Subject: [6tsch] TSCH with multiple DAGroots

From: Thomas Watteyne <[email-masked]>
Date: Tue, 12 Feb 2013 19:57:27 -0800

I'd like to take a different view on Sateesh's comment and discuss an issue
which I believe is extremely important: multiple DAG roots.

Section 3.1.3 of RFC6550 (RPL) identifies the following topologies:
1) *1* DODAG,  *1* root.
2) *n* DODAGs, *n* roots.
3) *1* DODAG,  *n* (virtual) roots

For 1), I think we have reached a consensus that having TSCH pick RPL
routing parents as time source neigbors is a good idea.

I'd like to spend some time thinking about 2) and 3). RPL gives us the
wonderful flexibility of being able to add/remove DAG roots. In case of 3)
for example, traffic can flow to the DAG root topologically closest, and
the DAG can adjust to the arrival of a new DAG root. This allows for very
flexible network (i.e. some motes in a forest has intermittent GSM
connectivity and play DAG root when they have). I'd like to make sure this
is supported when using TSCH underneath.

I see two challenges, both related with synchronization:
- what does the synchronization DAG(s) look like in the presence of
multiple roots?
- what becomes of this synchronization DAG when a DAGroot is removed? is
added?

Since each DAG root is a time master, if they are not synchronized, they
will form independent synchronization DAGs, which will lead to
synchronization chaos.

I can think of several options:
- DAG roots use some common time source to synchronize (e.g. GPS) and
inject that time into the rest of the network. This allows only for slots
to be aligned, and there still needs to be a mechanism for rootA to use the
same ASN as rootB.
- DAG root use some out-of-band protocol to coordinate. If we assume the
DAG roots are egress points to the Internet, that out-of-band channel could
be the Internet.
- some in-band protocol is used. As pointed out by Tom, this is of course
the best solution.

Before getting too far into these ideas, I'd like to ask for thoughts from
the group.

Thomas

---

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 12 Feb 2013 20:25:11 -0800

Hi Thomas,
good point!

I think that having multiple DAGroot appearing and disappearing may only 
have implications on the rank of some nodes. A node appearing will 
trigger a chain of rank updates that will modify the routing topology 
and some nodes will change their parent. A node disappearing will cause 
some nodes having to change its parent. The important thing here is how 
fast RPL can deal with that dynamism.

As for synchronization, I guess that having a network wide 
synchronization protocol is the best idea. Where should this network 
synchronization protocol reside? it seems more a L3 protocol.

regards,
Xavi

On 12/02/13 19:57, Thomas Watteyne wrote:
> I'd like to take a different view on Sateesh's comment and discuss an 
> issue which I believe is extremely important: multiple DAG roots.
>
> 1) /1/ DODAG, /1/ root.
> 2) /n/ DODAGs, /n/ roots.
> 3) /1/ DODAG, /n/ (virtual) roots
>
> wonderful flexibility of being able to add/remove DAG roots. In case 
> of 3) for example, traffic can flow to the DAG root topologically 
> closest, and the DAG can adjust to the arrival of a new DAG root. This 
> allows for very flexible network (i.e. some motes in a forest has 
> intermittent GSM connectivity and play DAG root when they have). I'd 
> like to make sure this is supported when using TSCH underneath.
>
> - what becomes of this synchronization DAG when a DAGroot is removed? 
> is added?
>
> Since each DAG root is a time master, if they are not synchronized, 
> they will form independent synchronization DAGs, which will lead to 
> synchronization chaos.
>
> inject that time into the rest of the network. This allows only for 
> slots to be aligned, and there still needs to be a mechanism for rootA 
> to use the same ASN as rootB.
> - DAG root use some out-of-band protocol to coordinate. If we assume 
> the DAG roots are egress points to the Internet, that out-of-band 
> channel could be the Internet.
> - some in-band protocol is used. As pointed out by Tom, this is of 
> course the best solution.
>
> Before getting too far into these ideas, I'd like to ask for thoughts 
> from the group.
>
> Thomas
>
>
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch

---

From: Tom Phinney <[email-masked]>
Date: Wed, 13 Feb 2013 04:11:06 -0700

Thomas, your comment "there still needs to be a
mechanism for rootA to use the same ASN as rootB" implies to me
that you are still using the concept of Absolute Slot Number
(presumably the meaning of ASN) rather than time as the basis for
nonces, cutover coordination, etc. In the industrial wireless
world this was the approach used in WirelessHART. However,
ISA100.11a shows us that there is a better, more forward-looking
way, and that is to use time itself, in a truncated fractional
representation, as the nonce basis.

The fallacy / limitation of using ASN becomes instantly apparent
as soon as one considers a system in which different slots
(perhaps in different superframes) can have different durations.
As RF technology progresses beyond the limitations of the current
IEEE 802.15.4 PHY design, such as to use FEC in some frames, it
becomes highly desirable to permit different communication flows
with differing criticality to use different slot durations. In
ISA100.11a this use largely occurs in conjunction with duocast,
where participating motes use a slot template that has two
separate acknowledgment intervals. Except when checking that an
effective backup receiver exists, the mote that initiated the
acknowledged transaction responds to the first successful
acknowledgment by shutting off its receiver. However, both devices
that are receiving the acknowledged transaction, which are usually
powered backbone-connected access points (e.g., routers to a
faster subnet) when duocast is used, acknowledge the duocast
transmission in their respective assigned slots. Given that RF
typically experiences a 5% mean non-reception rate from all
causes, duocast reduces the effective non-reception rate per
transmission to nearly (.05)^2, which is 0.25%. It is that
innovation that makes reliable closed-loop 1 Hz and 4 Hz control
feasible over IEEE 802.15.4 radios (and in a 6TSCH system).

A similar situation would exist with a PHY that could enable FEC,
which would require longer transmission durations, and hence
longer slots, to carry the same payload. Military communications
experience in the presence of heavy fading and interference shows
that FEC is often a more robust way to communicate than an
unlimited number of ARQ cycles. However, use of FEC would dictate
longer slots for those critical communications where FEC use was
deemed appropriate (e.g., safety system messaging in an industrial
plant, or super high critical alarms).

The moment that a system is designed to permit concurrent
assignment of slots of differing duration, the entire ASN approach
collapses. The only feasible yet practical solution is to use time
itself, in some digital representation, as the synchronizing
information. I had presumed, apparently, in error, that this
lesson was already learned and widely known. There really is no
alternative, particularly when looking at a future of radios with
greater capabilities -- perhaps even SDR -- than those employed
today.

-Tom

====

On 2013.02.12 21:25, Xavier Vilajosana wrote:

Hi Thomas,

good point!

I think that having multiple DAGroot appearing and disappearing
may only have implications on the rank of some nodes. A node
appearing will trigger a chain of rank updates that will modify
the routing topology and some nodes will change their parent. A
node disappearing will cause some nodes having to change its
parent. The important thing here is how fast RPL can deal with
that dynamism.

As for synchronization, I guess that having a network wide
synchronization protocol is the best idea. Where should this
network synchronization protocol reside? it seems more a L3
protocol.

regards,

Xavi

I'd like to take a different view on Sateesh's comment and
discuss an issue which I believe is extremely important:
multiple DAG roots.

Section 3.1.3 of RFC6550 (RPL) identifies the following
topologies:

1) 1 DODAG,  1 root.

2) n DODAGs, n roots.

3) 1 DODAG,  n (virtual) roots

For 1), I think we have reached a consensus that having
TSCH pick RPL routing parents as time source neigbors is a
good idea.

I'd like to spend some time thinking about 2) and 3). RPL
gives us the wonderful flexibility of being able to add/remove
DAG roots. In case of 3) for example, traffic can flow to the
DAG root topologically closest, and the DAG can adjust to the
arrival of a new DAG root. This allows for very flexible
network (i.e. some motes in a forest has intermittent GSM
connectivity and play DAG root when they have). I'd like to
make sure this is supported when using TSCH underneath.

- what does the synchronization DAG(s) look like in the
presence of multiple roots?

- what becomes of this synchronization DAG when a DAGroot
is removed? is added?

Since each DAG root is a time master, if they are not
synchronized, they will form independent synchronization DAGs,
which will lead to synchronization chaos.

- DAG roots use some common time source to synchronize
(e.g. GPS) and inject that time into the rest of the network.
This allows only for slots to be aligned, and there still
needs to be a mechanism for rootA to use the same ASN as
rootB.

- DAG root use some out-of-band protocol to coordinate. If
we assume the DAG roots are egress points to the Internet,
that out-of-band channel could be the Internet.

- some in-band protocol is used. As pointed out by Tom,
this is of course the best solution.

Before getting too far into these ideas, I'd like to ask
for thoughts from the group.

Thomas

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Wed, 13 Feb 2013 15:49:18 +0000

Thomas, Xavi,

from my point of view, synchronization isn't the only problem with which we will have to deal when we have multiple DAGroot appearing/disappearing. A change of topology, and thus a change of the nodes' parent will have an impact also on the schedule. I mean, once a node changes its parents, also the links A->B will change and the schedule should be updated and distributed again, without taking long time, and of course, without wasting a lot of energy. Thus, we will need for sure, some mechanisms that interacts between L2 and L3, in order to deal with that.

Moreover, we could use multiple DAGroot for having multiple slotframe running at the same time. About multiple slotframe, we will need to define how each of them can be aware of the others, in order to build efficient schedules, that allows to schedule the maximum number of transmissions at the same time, without having collision and interference.

Looking forward to having feedbacks/ideas.

Regards,
Maria Rita
________________________________
From: [email-masked] [[email-masked]] on behalf of Xavier Vilajosana [[email-masked]]
Sent: Wednesday, February 13, 2013 5:25 AM
To: [email-masked]
Subject: Re: [6tsch] TSCH with multiple DAGroots

Hi Thomas,
good point!

I think that having multiple DAGroot appearing and disappearing may only have implications on the rank of some nodes. A node appearing will trigger a chain of rank updates that will modify the routing topology and some nodes will change their parent. A node disappearing will cause some nodes having to change its parent. The important thing here is how fast RPL can deal with that dynamism.

As for synchronization, I guess that having a network wide synchronization protocol is the best idea. Where should this network synchronization protocol reside? it seems more a L3 protocol.

regards,
Xavi

On 12/02/13 19:57, Thomas Watteyne wrote:
I'd like to take a different view on Sateesh's comment and discuss an issue which I believe is extremely important: multiple DAG roots.

For 1), I think we have reached a consensus that having TSCH pick RPL routing parents as time source neigbors is a good idea.

I'd like to spend some time thinking about 2) and 3). RPL gives us the wonderful flexibility of being able to add/remove DAG roots. In case of 3) for example, traffic can flow to the DAG root topologically closest, and the DAG can adjust to the arrival of a new DAG root. This allows for very flexible network (i.e. some motes in a forest has intermittent GSM connectivity and play DAG root when they have). I'd like to make sure this is supported when using TSCH underneath.

I see two challenges, both related with synchronization:
- what does the synchronization DAG(s) look like in the presence of multiple roots?
- what becomes of this synchronization DAG when a DAGroot is removed? is added?

Since each DAG root is a time master, if they are not synchronized, they will form independent synchronization DAGs, which will lead to synchronization chaos.

I can think of several options:
- DAG roots use some common time source to synchronize (e.g. GPS) and inject that time into the rest of the network. This allows only for slots to be aligned, and there still needs to be a mechanism for rootA to use the same ASN as rootB.
- DAG root use some out-of-band protocol to coordinate. If we assume the DAG roots are egress points to the Internet, that out-of-band channel could be the Internet.
- some in-band protocol is used. As pointed out by Tom, this is of course the best solution.

Before getting too far into these ideas, I'd like to ask for thoughts from the group.

Thomas

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

---

From: [email-masked]
Date: Wed, 13 Feb 2013 10:39:28 -0800

Hi Tom,

Could you please explain more about "a system in which different slots
(perhaps in different superframes) can have different durations"?

In addition, with FEC, longer slot duration may be needed, but it is
unnecessary to have different slot duration in one network.

How do you think?

Thanks
Qin

> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
>   <head>
>     <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
>   </head>
>   <body bgcolor="#ffffff" text="#000000">
>     <font face="Arial">Thomas, your comment "there still needs to be a
>       representation, as the nonce basis.<br>
>       <br>
>       feasible over IEEE 802.15.4 radios (and in a 6TSCH system).<br>
>       <br>
>       plant, or super high critical alarms).<br>
>       <br>
>       today.<br>
>       <br>
>       -Tom<br>
>       ====</font><br>
>     <blockquote cite="mid:[email-masked]"
>       type="cite">
>       <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
>       <div class="moz-cite-prefix">Hi Thomas,<br>
>         good point!<br>
>         <br>
>         that dynamism.<br>
>         <br>
>         <br>
>         protocol. <br>
>         <br>
>         regards,<br>
>         Xavi<br>
>         <br>
>         <br>
>         <br>
>         <br>
>         On 12/02/13 19:57, Thomas Watteyne wrote:<br>
>       </div>
>       <blockquote
> cite="mid:[email-masked]"
>         type="cite">
>         <div>I'd like to take a different view on Sateesh's comment and
>           multiple DAG roots.</div>
>         <div><br>
>         </div>
>         <div>Section 3.1.3 of RFC6550 (RPL) identifies the following
>           topologies:</div>
>         <div>1) <i>1</i> DODAG,  <i>1</i> root.</div>
>         <div>2) <i>n</i> DODAGs, <i>n</i> roots.</div>
>         <div>3) <i>1</i> DODAG,  <i>n</i> (virtual) roots </div>
>         <div><br>
>         </div>
>         <div>For 1), I think we have reached a consensus that having
>           good idea.</div>
>         <div><br>
>         </div>
>         <div>I'd like to spend some time thinking about 2) and 3). RPL
>           make sure this is supported when using TSCH underneath.</div>
>         <div><br>
>         </div>
>         <div>I see two challenges, both related with
> synchronization:</div>
>         <div>- what does the synchronization DAG(s) look like in the
>           presence of multiple roots?</div>
>         <div>- what becomes of this synchronization DAG when a DAGroot
>           is removed? is added?</div>
>         <div><br>
>         </div>
>         <div>Since each DAG root is a time master, if they are not
>           which will lead to synchronization chaos.</div>
>         <div><br>
>         </div>
>         <div>I can think of several options:</div>
>         <div>- DAG roots use some common time source to synchronize
>           rootB.</div>
>         <div>- DAG root use some out-of-band protocol to coordinate. If
>           that out-of-band channel could be the Internet.</div>
>         <div>- some in-band protocol is used. As pointed out by Tom,
>           this is of course the best solution.</div>
>         <div><br>
>         </div>
>         <div>Before getting too far into these ideas, I'd like to ask
>           for thoughts from the group.</div>
>         <div><br>
>         </div>
>         <div>Thomas</div>
>         <br>
>         <fieldset class="mimeAttachmentHeader"></fieldset>
>         <br>
>         <pre wrap="">_______________________________________________
> 6tsch mailing list
> <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
> href="mailto:[email-masked]">[email-masked]</a>
> <a moz-do-not-send="true" class="moz-txt-link-freetext"
> href="https://www.ietf.org/mailman/listinfo/6tsch">https://www.ietf.org/mailman/listinfo/6tsch</a>
> </pre>
>       </blockquote>
>       <br>
>       <pre wrap="">
> <fieldset class="mimeAttachmentHeader"></fieldset>
> <a class="moz-txt-link-abbreviated"
> href="mailto:[email-masked]">[email-masked]</a>
> <a class="moz-txt-link-freetext"
> href="https://www.ietf.org/mailman/listinfo/6tsch">https://www.ietf.org/mailman/listinfo/6tsch</a>
> </pre>
>     </blockquote>
>   </body>
> </html>

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 13 Feb 2013 23:20:23 -0800

Tom,

This is a very interesting feature indeed, which I confirm does not appear
in 15.4e (although the standard is flexible enough that you could play with
some of those concepts). You convinced me of the interest of such as scheme
by this duo/triocast. In that case, what would be destination address be of
a duocast packet?

That being said, I believe the scope of the 6TSCH group is the existing
IEEE802.15.4e standard. And while certainly a food for lots of thoughts, I
think we're bound to using the notion of ASN in the context of this group.

I hope you agree.

Thomas

On Wed, Feb 13, 2013 at 3:11 AM, Tom Phinney <[email-masked]> wrote:

> **
> Thomas, your comment "there still needs to be a mechanism for rootA to use
> the same ASN as rootB" implies to me that you are still using the concept
> of Absolute Slot Number (presumably the meaning of ASN) rather than time as
> the basis for nonces, cutover coordination, etc. In the industrial wireless
> world this was the approach used in WirelessHART. However, ISA100.11a shows
> us that there is a better, more forward-looking way, and that is to use
> time itself, in a truncated fractional representation, as the nonce basis.
>
> The fallacy / limitation of using ASN becomes instantly apparent as soon
> as one considers a system in which different slots (perhaps in different
> superframes) can have different durations. As RF technology progresses
> beyond the limitations of the current IEEE 802.15.4 PHY design, such as to
> use FEC in some frames, it becomes highly desirable to permit different
> communication flows with differing criticality to use different slot
> durations. In ISA100.11a this use largely occurs in conjunction with
> duocast, where participating motes use a slot template that has two
> separate acknowledgment intervals. Except when checking that an effective
> backup receiver exists, the mote that initiated the acknowledged
> transaction responds to the first successful acknowledgment by shutting off
> its receiver. However, both devices that are receiving the acknowledged
> transaction, which are usually powered backbone-connected access points
> (e.g., routers to a faster subnet) when duocast is used, acknowledge the
> duocast transmission in their respective assigned slots. Given that RF
> typically experiences a 5% mean non-reception rate from all causes, duocast
> reduces the effective non-reception rate per transmission to nearly
> (.05)^2, which is 0.25%. It is that innovation that makes reliable
> closed-loop 1 Hz and 4 Hz control feasible over IEEE 802.15.4 radios (and
> in a 6TSCH system).
>
> A similar situation would exist with a PHY that could enable FEC, which
> would require longer transmission durations, and hence longer slots, to
> carry the same payload. Military communications experience in the presence
> of heavy fading and interference shows that FEC is often a more robust way
> to communicate than an unlimited number of ARQ cycles. However, use of FEC
> would dictate longer slots for those critical communications where FEC use
> was deemed appropriate (e.g., safety system messaging in an industrial
> The moment that a system is designed to permit concurrent assignment of
> slots of differing duration, the entire ASN approach collapses. The only
> feasible yet practical solution is to use time itself, in some digital
> representation, as the synchronizing information. I had presumed,
> apparently, in error, that this lesson was already learned and widely
> known. There really is no alternative, particularly when looking at a
> future of radios with greater capabilities -- perhaps even SDR -- than
> those employed today.
>
> -Tom
> ====
>
> have implications on the rank of some nodes. A node appearing will trigger
> a chain of rank updates that will modify the routing topology and some
> nodes will change their parent. A node disappearing will cause some nodes
> having to change its parent. The important thing here is how fast RPL can
> deal with that dynamism.
>
>
> As for synchronization, I guess that having a network wide synchronization
> protocol is the best idea. Where should this network synchronization
> protocol reside? it seems more a L3 protocol.
>
> regards,
> Xavi
>
>
>
>
> 6tsch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tsch
>
>
>
> 6tsch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tsch
>
>

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 13 Feb 2013 23:57:21 -0800

Maria Rita,

Absolutely, also need to be updated when a DAG root changes.

Let me try and illustrate a bit with an example. Say that I want to deploy
100 motes in a square patch of forest, and I have 4 motes equipped with
cell modems and therefore Internet connectivity. Motes measure data and
send data through the network to one of these 4 motes; I don't really care
which one, as long as it gets to my server at home.

>From a RPL point of view, this would be a single DODAG, with 4 virtual
roots: the rank increases from each of the roots outwards, and mote sends
data to whichever root is topologically closest. There is nice redundancy
since the networkhas 4 egress points.

>From a TSCH point of view, however, things are a bit more complicated. If I
boot my 4 roots, they can not start advertising at will, since they are not
synchronized with one another. Even if motes can attach to whichever they
hear first, you will end up with 4 smaller independent networks, not one
highly redundant network.

One option is to pre-program rootA to be the time master, and rootB/C/D
time slaves. That is, when booted rootB/C/D search for a network like any
other mote. When they attach to the network, however, they must somehow
indicate that they are a DAGroot (in RPL), but NOT a time source. This
effectively builds a synchronization DAG (around rootA only), and a routing
DAG (around rootA/B/C/D).

This somehow breaks our earlier agreement that "RPL routing parents are
also TSCH time source neighbors".

Thomas

On Wed, Feb 13, 2013 at 7:49 AM, Maria Rita PALATTELLA <
[email-masked]> wrote:

>  Thomas, Xavi,
>
> from my point of view, synchronization isn't the only problem with which
> we will have to deal when we have multiple DAGroot appearing/disappearing.
> A change of topology, and thus a change of the nodes' parent will have an
> impact also on the schedule. I mean, once a node changes its parents, also
> the links A->B will change and the schedule should be updated and
> distributed again, without taking long time, and of course, without wasting
> a lot of energy. Thus, we will need for sure, some mechanisms that
> interacts between L2 and L3, in order to deal with that.
>
> Moreover, we could use multiple DAGroot for having multiple slotframe
> running at the same time. About multiple slotframe, we will need to define
> how each of them can be aware of the others, in order to build efficient
> schedules, that allows to schedule the maximum number of transmissions at
> the same time, without having collision and interference.
>
> ------------------------------
> *From:* [email-masked] [[email-masked]] on behalf of
> Xavier Vilajosana [[email-masked]]
> *Sent:* Wednesday, February 13, 2013 5:25 AM
> *To:* [email-masked]
> *Subject:* Re: [6tsch] TSCH with multiple DAGroots
>
>   Hi Thomas,
> good point!
>

---

From: Robert Assimiti <[email-masked]>
Date: Thu, 14 Feb 2013 13:25:50 -0500

Thomas,

I fully agree with Tom's suggestions.

The TSCH MAC must not be limited solely for operation over the IEEE 802.15.4 -2006 2.4 GHZ PHY.

It is a very nimble MAC that can and is being used over other PHYs. We currently use it over 802.15.4g.

It is important to note that the length of the timeslot will vary according to the PHY (bitrate, etc) used.

TSCH currently uses the concept of ASN which can also be used when using timeslots of different duration.

But why not also allow time synchronization that is based on an time stamp (UTC, TAI)? We could easily define an IE that would allow us to disseminate the timestamp.

Robert Assimiti

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Thursday, February 14, 2013 2:20 AM
To: [email-masked]
Subject: Re: [6tsch] TSCH with multiple DAGroots

Tom,

This is a very interesting feature indeed, which I confirm does not appear in 15.4e (although the standard is flexible enough that you could play with some of those concepts). You convinced me of the interest of such as scheme by this duo/triocast. In that case, what would be destination address be of a duocast packet?

That being said, I believe the scope of the 6TSCH group is the existing IEEE802.15.4e standard. And while certainly a food for lots of thoughts, I think we're bound to using the notion of ASN in the context of this group.

I hope you agree.

Thomas

On Wed, Feb 13, 2013 at 3:11 AM, Tom Phinney <[email-masked]<mailto:[email-masked]>> wrote:
Thomas, your comment "there still needs to be a mechanism for rootA to use the same ASN as rootB" implies to me that you are still using the concept of Absolute Slot Number (presumably the meaning of ASN) rather than time as the basis for nonces, cutover coordination, etc. In the industrial wireless world this was the approach used in WirelessHART. However, ISA100.11a shows us that there is a better, more forward-looking way, and that is to use time itself, in a truncated fractional representation, as the nonce basis.

The fallacy / limitation of using ASN becomes instantly apparent as soon as one considers a system in which different slots (perhaps in different superframes) can have different durations. As RF technology progresses beyond the limitations of the current IEEE 802.15.4 PHY design, such as to use FEC in some frames, it becomes highly desirable to permit different communication flows with differing criticality to use different slot durations. In ISA100.11a this use largely occurs in conjunction with duocast, where participating motes use a slot template that has two separate acknowledgment intervals. Except when checking that an effective backup receiver exists, the mote that initiated the acknowledged transaction responds to the first successful acknowledgment by shutting off its receiver. However, both devices that are receiving the acknowledged transaction, which are usually powered backbone-connected access points (e.g., routers to a faster subnet) when duocast is used, acknowledge the duocast transmission in their respective assigned slots. Given that RF typically experiences a 5% mean non-reception rate from all causes, duocast reduces the effective non-reception rate per transmission to nearly (.05)^2, which is 0.25%. It is that innovation that makes reliable closed-loop 1 Hz and 4 Hz control feasible over IEEE 802.15.4 radios (and in a 6TSCH system).

A similar situation would exist with a PHY that could enable FEC, which would require longer transmission durations, and hence longer slots, to carry the same payload. Military communications experience in the presence of heavy fading and interference shows that FEC is often a more robust way to communicate than an unlimited number of ARQ cycles. However, use of FEC would dictate longer slots for those critical communications where FEC use was deemed appropriate (e.g., safety system messaging in an industrial plant, or super high critical alarms).

The moment that a system is designed to permit concurrent assignment of slots of differing duration, the entire ASN approach collapses. The only feasible yet practical solution is to use time itself, in some digital representation, as the synchronizing information. I had presumed, apparently, in error, that this lesson was already learned and widely known. There really is no alternative, particularly when looking at a future of radios with greater capabilities -- perhaps even SDR -- than those employed today.

-Tom
====

On 2013.02.12 21<tel:2013.02.12%2021>:25, Xavier Vilajosana wrote:
Hi Thomas,
good point!

regards,
Xavi

Thomas

6tsch mailing list

6tsch mailing list

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 14 Feb 2013 11:07:58 -0800

Robert,
Please see inline.
Thomas

On Thu, Feb 14, 2013 at 10:25 AM, Robert Assimiti <[email-masked]
> wrote:

> Thomas,****
>
> ** **
>
> I fully agree with Tom’s suggestions. ****
>
> ** **
>
> The TSCH MAC must not be limited solely for operation over the IEEE
> 802.15.4 -2006 2.4 GHZ PHY.****
>
> **
>
Agreed.

> **
>
> It is a very nimble MAC that can and is being used over other PHYs. We
> currently use it over 802.15.4g. ****
>
>
> Agreed.

> It is important to note that the length of the timeslot will vary
> according to the PHY (bitrate, etc) used. ****
>
> **
>
Agreed.

> Agreed.

> ****
>
> But why not also allow time synchronization that is based on an time stamp
> (UTC, TAI)? We could easily define an IE that would allow us to disseminate
> the timestamp.****
>
> **
>

I understand the potential of doing this, and I'm all in to explore all the
flexibility TSCH offers. I'm just afraid that we veer off course from
"6LoWPAN/ROLL over TSCH" into TSCH-only. I understand that you/Tom do not
agree with that, and I'm very happy to discuss this. Let's reach a rough
consensus over the phone tomorrow. Pascal, I guess we could add this issue
in the "ML discussions" of the agenda?

Thomas

> **
>
> ** **
>
> *Robert Assimiti*
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Thomas Watteyne
> *Sent:* Thursday, February 14, 2013 2:20 AM
>
> *To:* [email-masked]
> *Subject:* Re: [6tsch] TSCH with multiple DAGroots****
>
> ** **
>
> Tom,****
>
> ** **
>
> a duocast packet?****
> ** **
> ****
> ** **
> I hope you agree.****
> ** **
> Thomas****
> ** **
> On Wed, Feb 13, 2013 at 3:11 AM, Tom Phinney <[email-masked]> wrote:*
> ***
>
> ====****
> On 2013.02.12 21:25, Xavier Vilajosana wrote: ****
>
> Hi Thomas,
> good point!
>
> On 12/02/13 19:57, Thomas Watteyne wrote:****
>
> issue which I believe is extremely important: multiple DAG roots.****
>
> ** **
>
> Section 3.1.3 of RFC6550 (RPL) identifies the following topologies:****
>
> 1) *1* DODAG,  *1* root.****
>
> 2) *n* DODAGs, *n* roots.****
>
> 3) *1* DODAG,  *n* (virtual) roots ****
>
> ** **
>
> routing parents as time source neigbors is a good idea.****
>
> ** **
>
> is supported when using TSCH underneath.****
>
> ** **
>
> I see two challenges, both related with synchronization:****
>
> multiple roots?****
> added?****
> ** **
> synchronization chaos.****
>
> ** **
>
> I can think of several options:****
>
> same ASN as rootB.****
> be the Internet.****
> the best solution.****
> ** **
> the group.****
> ** **
> Thomas****
> ** **
> _______________________________________________****
>
> 6tsch mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>
> ** **
>
> _______________________________________________****
>
> 6tsch mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>

---

From: Tom Phinney <[email-masked]>
Date: Thu, 14 Feb 2013 12:58:57 -0700

> I think we're bound to using the notion of ASN in the context
of this group.

In that case I believe that the relevance of this effort to heavy
industry is limited to monitoring and control of inessential
elements of industrial processes. Most real industrial processes in
refining, chemical plants, batch mixing plants, pharmaceuticals,
etc. use 1 Hz or 4 Hz control, for which ARQ of unicast
transmissions is generally too unreliable.

There is nothing in the ASN concept, other than its historical basis
in the work of your group at Berkeley, that makes it essential to an
implementation. ANSI/ISA 100.11a, which is being standardized as IEC
62734, demonstrates clearly how time, rather than a local concept of
a count of slots of uniform duration and aligned starting times, can
be used for 6TSCH systems.

The implication of your text below, that IEEE 802.15.4 precludes use
of time for such nonces, may have been true in the past but was
remedied with the amendments of IEEE 802.15.4e:2012 (which is now
obtainable for free from the IEEE, since it is over six months since
its adoption).

While ANSI/ISA 100.11a is not totally conformant to IEEE 802.15.4 as
amended, the difference is only in the use of shorter addressing
modes in acknowledgments and advertisements than the inefficient
ones mandated for IEEE 802.15.4 data frames (which are used in
ANSI/ISA 100.11a so that their PDUs can be cryptographic secured,
unlike the readily-spoofed acknowledgments of IEEE 802.15.4 that
they replace)

Of course it is possible to employ multiple, different 6TSCH
networking technologies in the same physical area of a plant, for
example WirelessHART and ISA100.11a, but the inability to harmonize
schedules to minimize RF interference between the two systems makes
such an approach unattractive. Thus I would expect most large
industrial plants to end up in the long term with time-based nonces,
rather than ASN-based ones, and for this effort to migrate to use of
time-based nonces to increase its relevance.

Of course use of time, rather than a locally-originated ASN, makes
it feasible for multiple DAG roots to start up independently but
with closely harmonized (though not precisely synchronized) senses
of time. Thus, unlike when each DAG root initiates its own
zero-origin ASN sequence, the resulting subnets can merge with at
most only slight pauses for some of them when aligning their senses
of time (so that nonces do not repeat). That is one of the many
advantages of using a nonce source that can be obtained
approximately from many external sources, such as cell networks or
reception of GPS transmissions, as well as maintained during periods
of extended sleep when a microcomputer's low-power clock oscillator
may be the only circuit powered on the chip.

-Tom Phinney

===

On 2013.02.14 00:20, Thomas Watteyne wrote:

Tom,

This is a very interesting feature indeed, which I confirm
does not appear in 15.4e (although the standard is flexible
enough that you could play with some of those concepts). You
convinced me of the interest of such as scheme by this
duo/triocast. In that case, what would be destination address be
of a duocast packet?

That being said, I believe the scope of the 6TSCH group is
the existing IEEE802.15.4e standard. And while certainly a food
for lots of thoughts, I think we're bound to using the notion of
ASN in the context of this group.

I hope you agree.

Thomas

On Wed, Feb 13, 2013 at 3:11 AM, Tom
Phinney <[email-masked]>
wrote:

Thomas,
your comment "there still needs to be a mechanism for
rootA to use the same ASN as rootB" implies to me that
you are still using the concept of Absolute Slot Number
(presumably the meaning of ASN) rather than time as the
basis for nonces, cutover coordination, etc. In the
industrial wireless world this was the approach used in
WirelessHART. However, ISA100.11a shows us that there is
a better, more forward-looking way, and that is to use
time itself, in a truncated fractional representation,
as the nonce basis.

The fallacy / limitation of using ASN becomes instantly
apparent as soon as one considers a system in which
different slots (perhaps in different superframes) can
have different durations. As RF technology progresses
beyond the limitations of the current IEEE 802.15.4 PHY
design, such as to use FEC in some frames, it becomes
highly desirable to permit different communication flows
with differing criticality to use different slot
durations. In ISA100.11a this use largely occurs in
conjunction with duocast, where participating motes use
a slot template that has two separate acknowledgment
intervals. Except when checking that an effective backup
receiver exists, the mote that initiated the
acknowledged transaction responds to the first
successful acknowledgment by shutting off its receiver.
However, both devices that are receiving the
acknowledged transaction, which are usually powered
backbone-connected access points (e.g., routers to a
faster subnet) when duocast is used, acknowledge the
duocast transmission in their respective assigned slots.
Given that RF typically experiences a 5% mean
non-reception rate from all causes, duocast reduces the
effective non-reception rate per transmission to nearly
(.05)^2, which is 0.25%. It is that innovation that
makes reliable closed-loop 1 Hz and 4 Hz control
feasible over IEEE 802.15.4 radios (and in a 6TSCH
system).

A similar situation would exist with a PHY that could
enable FEC, which would require longer transmission
durations, and hence longer slots, to carry the same
payload. Military communications experience in the
presence of heavy fading and interference shows that FEC
is often a more robust way to communicate than an
unlimited number of ARQ cycles. However, use of FEC
would dictate longer slots for those critical
communications where FEC use was deemed appropriate
(e.g., safety system messaging in an industrial plant,
or super high critical alarms).

The moment that a system is designed to permit
concurrent assignment of slots of differing duration,
the entire ASN approach collapses. The only feasible yet
practical solution is to use time itself, in some
digital representation, as the synchronizing
information. I had presumed, apparently, in error, that
this lesson was already learned and widely known. There
really is no alternative, particularly when looking at a
future of radios with greater capabilities -- perhaps
even SDR -- than those employed today.

-Tom

====

On 2013.02.12 21:25, Xavier
Vilajosana wrote:

Hi Thomas,

good point!

I think that having multiple DAGroot appearing and
disappearing may only have implications on the
rank of some nodes. A node appearing will trigger
a chain of rank updates that will modify the
routing topology and some nodes will change their
parent. A node disappearing will cause some nodes
having to change its parent. The important thing
here is how fast RPL can deal with that dynamism.

As for synchronization, I guess that having a
network wide synchronization protocol is the best
idea. Where should this network synchronization
protocol reside? it seems more a L3 protocol.

regards,

Xavi

I'd like to take a different view on
Sateesh's comment and discuss an issue which I
believe is extremely important: multiple DAG
roots.

Section 3.1.3 of RFC6550 (RPL) identifies the
following topologies:

1) 1 DODAG,  1 root.

2) n DODAGs, n roots.

3) 1 DODAG,  n (virtual)
roots

For 1), I think we have reached a consensus
that having TSCH pick RPL routing parents as
time source neigbors is a good idea.

I'd like to spend some time thinking about 2)
and 3). RPL gives us the wonderful flexibility
of being able to add/remove DAG roots. In case
of 3) for example, traffic can flow to the DAG
root topologically closest, and the DAG can
adjust to the arrival of a new DAG root. This
allows for very flexible network (i.e. some
motes in a forest has intermittent GSM
connectivity and play DAG root when they have).
I'd like to make sure this is supported when
using TSCH underneath.

I see two challenges, both related with
synchronization:

- what does the synchronization DAG(s) look
like in the presence of multiple roots?

- what becomes of this synchronization DAG
when a DAGroot is removed? is added?

Since each DAG root is a time master, if they
are not synchronized, they will form independent
synchronization DAGs, which will lead to
synchronization chaos.

- DAG roots use some common time source to
synchronize (e.g. GPS) and inject that time into
the rest of the network. This allows only for
slots to be aligned, and there still needs to be
a mechanism for rootA to use the same ASN as
rootB.

- DAG root use some out-of-band protocol to
coordinate. If we assume the DAG roots are
egress points to the Internet, that out-of-band
channel could be the Internet.

- some in-band protocol is used. As pointed
out by Tom, this is of course the best solution.

Before getting too far into these ideas, I'd
like to ask for thoughts from the group.

Thomas

6tsch mailing list

[email-masked]

---

From: Tom Phinney <[email-masked]>
Date: Thu, 14 Feb 2013 13:55:57 -0700

Qin,

Each slot in a TSCH system is, in principle, usable for any transaction
whose duration will not exceed the length of the slot. Where a
significant percentage of the transactions that are expected to occur in
a system are of much shorter maximum duration than others, it may make
sense to have schedules with different slot durations, enabling
conveyance of more messages per second.

Without showing the required guard-bands and other periods of enforced
RF inactivity for each constituent subelement, the basic template for
use of a TSCH slot is generally:
 <CCA assessment interval> <primary PDU of the transaction>
[<immediate-acknowlegment-1> [<immediate-acknowlegment-2> [...
<immediate-acknowlegment-N>]  ] ]

In generally planar industrial environments such as refineries and
pharmaceutical manufacturing cells that use 1 Hz and 4 Hz wireless
control loops, the N above needs to be N=2. However on highly metallic
3D structures such as offshore oil platforms, N may need to be N=3.
Whereas in less challenging environments such as are now used for
WirelessHART, N can be (and is) N=1.

If some of the slots in a TSCH system require N=2 or N=3 immediate
acknowledgments to achieve the necessary delivery reliability, then a
single slot template must include time for each of those immediate
acknowledgments. For example, in today's deployments of ANSI/ISA 100.11a
systems, the slots that provide for N=2 acknowledgments tend to be 12 ms
in duration. However, that particular feature - duocast - is used only
for reporting of the process status of those 1 Hz and 4 Hz loops; most
other traffic is unicast, for which a 10 ms slot duration is adequate.
If the traffic mix in such a system is 1/3 duocast and 2/3 other
(unicast with an occasional broadcast), then requiring use of 12 ms
slots for the traffic that could use 10 ms slots results in an 11%
reduction of total subnet messaging capacity.

If FEC were to be available for industrial automation systems, it would
likely be used for only a small percentage of the communications. Again,
as above, each slot could be sized so that every transmission used FEC.
However, in practice, perhaps 5% or less of the transactions would
require FEC, since safety-related communications is typically only a
very small part of such systems. There would be an inordinate waste of
communication capacity if all devices employed FEC, which would increase
the duration of their transmissions and receptions, and thus the power
drain required for communication. Thus a mixture of slot durations is
again appropriate.

Independent of how many acknowledgments are anticipated for a specific
transaction, it is worth noting that there are at least two useful
timing alignments for the start of immediate acknowledgments. One
alternative is a defined fixed offset AFTER the end of reception of the
primary PDU of the transaction, where the delay accounts for required
transmit/receive and receive/transmit turnaround times in the
correspondent nodes (which may be either motes or infrastructure
wireless routers, which is why I do not always call such "motes").
Another alternative is a defined fixed offset BEFORE the scheduled end
of the slot. In either case, when the slot template provides for
multiple immediate acknowledgments, each acknowledgment has a different
offset relative to the defining event, which is either 1) detection of
end of reception or 2) the scheduled end of the slot.

Figures 4 and 5 of the attached patent application show how this could
work for N=3. The discussion in paragraph [0064] and following gives
some indication of when the alternative 2) might be used. The economic
driver for this alternative is the ability, using time-aligned
acknowledgments and co-scheduling of inbound or outbound message flow in
concurrent slots in multiple channels, to build a multi-channel backbone
router that uses a single antenna and wideband RF front end shared by
multiple low-power transceiver chips. Such a structure enables the
construction of low-cost high-throughput backbone routers that can be
installed in real systems precisely because such routers do not require
the installation of multiple separated antennae that are spaced
sufficiently far apart to not encounter near/far problems. Real
industrial plants seldom can collocate multiple backbone routers,
precisely because they cannot install adequately separated antennae for
those routers in the places where the routers are needed.

-Tom Phinney
===
On 2013.02.13 11:39, [email-masked] wrote:
> Hi Tom,
>
> Could you please explain more about "a system in which different slots (perhaps in different superframes) can have different durations"?
>
> In addition, with FEC, longer slot duration may be needed, but it is unnecessary to have different slot duration in one network.
>
> How do you think?
>
> Thanks
> Qin

---

From: Kris Pister <[email-masked]>
Date: Thu, 14 Feb 2013 17:05:23 -0800

Tom - that's a bit dramatic.  Duo-cast is pretty clever, but it's not 
like you can't close a 4Hz control loop without it.  Duo-cast let's you 
hit a desired level of reliability with lower power consumption, and 
less spectrum utilization.  Those are good things. At one point duo-cast 
was in the 4e standard - I'm not sure what happened to it.

I agree that there is nothing essential in the ASN concept, except for 
the fact that ASN is what the IEEE actually voted on and put into the 4e 
standard.  Please let's get RPL up and running on 4e as written first, 
and then go in and fix what's broken with the IEEE second.

ksjp

On 2/14/2013 11:58 AM, Tom Phinney wrote:
> > I think we're bound to using the notion of ASN in the context of 
> this group.
> industry is limited to monitoring and control of inessential elements 
> of industrial processes. Most real industrial processes in refining, 
> chemical plants, batch mixing plants, pharmaceuticals, etc. use 1 Hz 
> or 4 Hz control, for which ARQ of unicast transmissions is generally 
> too unreliable.
>
> 62734, demonstrates clearly how time, rather than a local concept of a 
> count of slots of uniform duration and aligned starting times, can be 
> used for 6TSCH systems.
>
>
> amended, the difference is only in the use of shorter addressing modes 
> in acknowledgments and advertisements than the inefficient ones 
> mandated for IEEE 802.15.4 data frames (which are used in ANSI/ISA 
> 100.11a so that their PDUs can be cryptographic secured, unlike the 
> readily-spoofed acknowledgments of IEEE 802.15.4 that they replace)
>
>
> Of course use of time, rather than a locally-originated ASN, makes it 
> feasible for multiple DAG roots to start up independently but with 
> closely harmonized (though not precisely synchronized) senses of time. 
> Thus, unlike when each DAG root initiates its own zero-origin ASN 
> sequence, the resulting subnets can merge with at most only slight 
> pauses for some of them when aligning their senses of time (so that 
> nonces do not repeat). That is one of the many advantages of using a 
> nonce source that can be obtained approximately from many external 
> sources, such as cell networks or reception of GPS transmissions, as 
> well as maintained during periods of extended sleep when a 
> microcomputer's low-power clock oscillator may be the only circuit 
> powered on the chip.
>
> -Tom Phinney
> ===
>> This is a very interesting feature indeed, which I confirm does not 
>> appear in 15.4e (although the standard is flexible enough that you 
>> could play with some of those concepts). You convinced me of the 
>> interest of such as scheme by this duo/triocast. In that case, what 
>> would be destination address be of a duocast packet?
>>
>> That being said, I believe the scope of the 6TSCH group is the 
>> existing IEEE802.15.4e standard. And while certainly a food for lots 
>> of thoughts, I think we're bound to using the notion of ASN in the 
>> context of this group.
>>
>> I hope you agree.
>>
>> Thomas
>>
>>     Thomas, your comment "there still needs to be a mechanism for
>>     rootA to use the same ASN as rootB" implies to me that you are
>>     still using the concept of Absolute Slot Number (presumably the
>>     meaning of ASN) rather than time as the basis for nonces, cutover
>>     coordination, etc. In the industrial wireless world this was the
>>     approach used in WirelessHART. However, ISA100.11a shows us that
>>     there is a better, more forward-looking way, and that is to use
>>     acknowledgment by shutting off its receiver. However, both
>>     devices that are receiving the acknowledged transaction, which
>>     are usually powered backbone-connected access points (e.g.,
>>     routers to a faster subnet) when duocast is used, acknowledge the
>>     duocast transmission in their respective assigned slots. Given
>>     that RF typically experiences a 5% mean non-reception rate from
>>     all causes, duocast reduces the effective non-reception rate per
>>     deemed appropriate (e.g., safety system messaging in an
>>     industrial plant, or super high critical alarms).
>>
>>     assignment of slots of differing duration, the entire ASN
>>     approach collapses. The only feasible yet practical solution is
>>     to use time itself, in some digital representation, as the
>>     synchronizing information. I had presumed, apparently, in error,
>>     that this lesson was already learned and widely known. There
>>     really is no alternative, particularly when looking at a future
>>     of radios with greater capabilities -- perhaps even SDR -- than
>>     those employed today.
>>
>>     -Tom
>>     ====
>>
>>     On 2013.02.12 21 <tel:2013.02.12%2021>:25, Xavier Vilajosana wrote:
>>>     Hi Thomas,
>>>     good point!
>>>
>>>>     For 1), I think we have reached a consensus that having TSCH
>>>>     pick RPL routing parents as time source neigbors is a good idea.
>>>>
>>>>     I'd like to spend some time thinking about 2) and 3). RPL gives
>>>>     us the wonderful flexibility of being able to add/remove DAG
>>>>     roots. In case of 3) for example, traffic can flow to the DAG
>>>>     root topologically closest, and the DAG can adjust to the
>>>>     - DAG roots use some common time source to synchronize (e.g.
>>>>     GPS) and inject that time into the rest of the network. This
>>>>     allows only for slots to be aligned, and there still needs to
>>>>     be a mechanism for rootA to use the same ASN as rootB.
>>>>     - DAG root use some out-of-band protocol to coordinate. If we
>>>>     assume the DAG roots are egress points to the Internet, that
>>>>     out-of-band channel could be the Internet.
>>>>     [email-masked]  <mailto:[email-masked]>
>>>     [email-masked]  <mailto:[email-masked]>
>>     [email-masked] <mailto:[email-masked]>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 15 Feb 2013 11:51:34 +0000

Hi Kris and Tom:

I think that it is great that we have that discussion now to make sure that an issue like this does not pop up too late in the process and kills our BoF.

OTOH I read details in this thread that hopefully are contained at the sublayer that we have been talking about -or below-.
For that layer, which I'm not entirely sure that we can standardize anyway (maybe try experimental?). In any case, we will not be allowed to charter a drift in IEEE land.
I'm not discussing the value and the need of a feature like FEC, but just that the IETF will not be able to do more than remote influence on IEEE.

Even working on the sublayer will probably cause discussions at the BoF.
We need good answers why the work belongs here, and a close liaison with IEEE (802.1AS?) to converge on the IP abstraction from a deterministic lower layer will certainly help.

My hope is that the sublayer will be designed in a fashion that is open to future improvements in the MAC, and to me duocast and FEC clearly qualify.
Missing that means that the spec will probably become obsolete a bit too fast. But I cannot see that we'll change a word in those

Now what is the bottom line for upper layers, RPL/OF , etc??? I think one core issue is whether 2 DODAGs in a same instance are time synchronized and how closely.
This impacts RPL because a node must be able to listen to parents in another DODAG of same instance. I read that keeping them synchronized is a lot less effort at the end of the day.

To get there we need the assumption of 1) a common backbone, and 2) the backbone routers  (BBR)  are synchronized over the backbone.
For 1) RPL needs a common backbone/backhaul for multiple DODAGs in a same subnet.
For 2) this is not the only thing we need from the backbone router. It is needed as a RPL root, a 6LoWPAN LBR, and it needs to proxy ND in a fashion we have to define.  And we also need  BBRs to elect a virtual root when we operate as a single DAG, in which case the need to keep them in sync over the backbone is even more obvious...

So - following Xavi here -  the next simplification on the table is that the BBRs are expected to be sync'ed. What do others think?

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kris Pister
Sent: vendredi 15 février 2013 02:05
To: [email-masked]
Subject: Re: [6tsch] Use of ASN vs quantized time as a basis for nonces (was TSCH with multiple DAGroots)

Tom - that's a bit dramatic.  Duo-cast is pretty clever, but it's not like you can't close a 4Hz control loop without it.  Duo-cast let's you hit a desired level of reliability with lower power consumption, and less spectrum utilization.  Those are good things.  At one point duo-cast was in the 4e standard - I'm not sure what happened to it.

I agree that there is nothing essential in the ASN concept, except for the fact that ASN is what the IEEE actually voted on and put into the 4e standard.  Please let's get RPL up and running on 4e as written first, and then go in and fix what's broken with the IEEE second.

ksjp
On 2/14/2013 11:58 AM, Tom Phinney wrote:
> I think we're bound to using the notion of ASN in the context of this group.
In that case I believe that the relevance of this effort to heavy industry is limited to monitoring and control of inessential elements of industrial processes. Most real industrial processes in refining, chemical plants, batch mixing plants, pharmaceuticals, etc. use 1 Hz or 4 Hz control, for which ARQ of unicast transmissions is generally too unreliable.

There is nothing in the ASN concept, other than its historical basis in the work of your group at Berkeley, that makes it essential to an implementation. ANSI/ISA 100.11a, which is being standardized as IEC 62734, demonstrates clearly how time, rather than a local concept of a count of slots of uniform duration and aligned starting times, can be used for 6TSCH systems.

The implication of your text below, that IEEE 802.15.4 precludes use of time for such nonces, may have been true in the past but was remedied with the amendments of IEEE 802.15.4e:2012 (which is now obtainable for free from the IEEE, since it is over six months since its adoption).

While ANSI/ISA 100.11a is not totally conformant to IEEE 802.15.4 as amended, the difference is only in the use of shorter addressing modes in acknowledgments and advertisements than the inefficient ones mandated for IEEE 802.15.4 data frames (which are used in ANSI/ISA 100.11a so that their PDUs can be cryptographic secured, unlike the readily-spoofed acknowledgments of IEEE 802.15.4 that they replace)

Of course it is possible to employ multiple, different 6TSCH networking technologies in the same physical area of a plant, for example WirelessHART and ISA100.11a, but the inability to harmonize schedules to minimize RF interference between the two systems makes such an approach unattractive. Thus I would expect most large industrial plants to end up in the long term with time-based nonces, rather than ASN-based ones, and for this effort to migrate to use of time-based nonces to increase its relevance.

Of course use of time, rather than a locally-originated ASN, makes it feasible for multiple DAG roots to start up independently but with closely harmonized (though not precisely synchronized) senses of time. Thus, unlike when each DAG root initiates its own zero-origin ASN sequence, the resulting subnets can merge with at most only slight pauses for some of them when aligning their senses of time (so that nonces do not repeat). That is one of the many advantages of using a nonce source that can be obtained approximately from many external sources, such as cell networks or reception of GPS transmissions, as well as maintained during periods of extended sleep when a microcomputer's low-power clock oscillator may be the only circuit powered on the chip.

-Tom Phinney
===

I hope you agree.

Thomas

-Tom
====

regards,
Xavi

Thomas

6tsch mailing list

6tsch mailing list

6tsch mailing list

6tsch mailing list