Subject: [6tsch] Re: TSCH with multiple DAGroots

From: Tom Phinney <[email-masked]>
Date: Thu, 14 Feb 2013 16:20:50 -0700

It's probably worth noting that duocast does not
inherently necessitate a different slot duration than unicast; it
is the attempt to use duocast with maximal-length initial PDUs
that drives the longer slot duration.

It is quite feasible to define slot templates for broadcast and
unicast that permit the initial 802.15.4 PDU to have a 127-byte
MAC length, while those used for duocast are appreciably shorter,
such that the subslot interval needed for the second
acknowledgment is (to at least a large extent) provided by the
savings in maximum transmit duration of that initial (now shorter)
PDU. This works in practice because the process state information
publications for which duocast is usually employed are quite
compact, typically consisting of only one or two 5-byte process
state APDUs, each of which typically consists of a 1-byte status
data struct and a 4-byte float32.

Incidentally, such a limited use of duocast is compatible with the
existing design of WirelessHART.

-Tom

=====

Qin,

Your question implies a misunderstanding. Nodes do not HAVE slot
durations; nodes USE slot durations. A node that uses duocast for a
specific class of transmissions (e.g., 4 Hz process state
publishing) uses unicast or broadcast for all remaining
transactions.

Existing industrial systems that use duocast employ duocast only for
state reporting for high-speed control loops. Those devices are, in
the absence of router failure, just one hop off the backbone, which
is typical for similar-usage devices in WirelessHART systems.
Emerson and Honeywell and other vendors of such high-loop-rate
control devices agree that one-hop placement is needed in most cases
to support the control requirements of the underlying process.

Unicast and broadcast are used by all the other nodes in that system
for all messaging, and by the nodes that use duocast for messaging
needs other than high-frequency process state publishing where
delivery reliability per transmission attempt is paramount.

FYI, I was one of the designers of both WirelessHART and ANSI/ISA
100.11a, and have had these discussions with the other designers of
each protocol.

-Tom

=====

On 2013.02.14 15:06, Qin Wang wrote:

> Hi Tom,

> Thank you for your explanation. It is very clear.

> I have one further question: Is there any constraint or
assumption for

> nodes with different slot duration? For example, the nodes with
different

> slot duration should belong to different DL network, or.....

> Thanks

> Qin

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 14 Feb 2013 15:31:28 -0800

Hi Tom,

that's completely clear now, however my concerns are:
1)what would be the role of 6tsch w.r.t the ability of the underlaying 
mac layer to use duocast or not? Is there something particular for 6tsch 
that would be different? I guess that 6tsch will provide some operations 
to schedule links (i.e slot and ch.offset). As far as I can imagine, 
someone can define slot as a integer number (ASN) or as time interval 
(as you explained before) which 6tsch may not constrain.

2)As far as I know IEEE802.15.4e does not define the possibility to use 
time ranges instead of ASN. And even this can be done as you state in 
the case of WirelessHART, it seems to me more a DLL problem instead of a 
6TSCH layer problem.

thanks,
Xavi

On 14/02/13 15:20, Tom Phinney wrote:
> It's probably worth noting that duocast does not inherently 
> necessitate a different slot duration than unicast; it is the attempt 
> to use duocast with maximal-length initial PDUs that drives the longer 
> slot duration.
>
> unicast that permit the initial 802.15.4 PDU to have a 127-byte MAC 
> length, while those used for duocast are appreciably shorter, such 
> that the subslot interval needed for the second acknowledgment is (to 
> at least a large extent) provided by the savings in maximum transmit 
> duration of that initial (now shorter) PDU. This works in practice 
> because the process state information publications for which duocast 
> is usually employed are quite compact, typically consisting of only 
> one or two 5-byte process state APDUs, each of which typically 
> consists of a 1-byte status data struct and a 4-byte float32.
>
> specific class of transmissions (e.g., 4 Hz process state publishing) 
> uses unicast or broadcast for all remaining transactions.
>
> the absence of router failure, just one hop off the backbone, which is 
> typical for similar-usage devices in WirelessHART systems. Emerson and 
> Honeywell and other vendors of such high-loop-rate control devices 
> agree that one-hop placement is needed in most cases to support the 
> control requirements of the underlying process.
>
> > I have one further question: Is there any constraint or assumption for
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch

---

From: Pascal Thubert <[email-masked]>
Date: Sat, 16 Feb 2013 12:14:37 +0100

Hello Xavi

I think that the need for some very high availability such as
implemented by duocast might be visible from L3, either as a class of
service, or some state associated to a flow.
How it is implemented at lower layers, is probably very opaque.

Cheers,

Pascal
2013/2/15 Xavier Vilajosana <[email-masked]>:
> 1)what would be the role of 6tsch w.r.t the ability of the underlaying mac
> layer to use duocast or not? Is there something particular for 6tsch that
> would be different? I guess that 6tsch will provide some operations to
> schedule links (i.e slot and ch.offset). As far as I can imagine, someone
> can define slot as a integer number (ASN) or as time interval (as you
> explained before) which 6tsch may not constrain.
>
> 2)As far as I know IEEE802.15.4e does not define the possibility to use time
> ranges instead of ASN. And even this can be done as you state in the case of
> WirelessHART, it seems to me more a DLL problem instead of a 6TSCH layer
> problem.
>
> thanks,
> Xavi
>
>
>
> It's probably worth noting that duocast does not inherently necessitate a
> different slot duration than unicast; it is the attempt to use duocast with
> maximal-length initial PDUs that drives the longer slot duration.
>
> It is quite feasible to define slot templates for broadcast and unicast that
> permit the initial 802.15.4 PDU to have a 127-byte MAC length, while those
> used for duocast are appreciably shorter, such that the subslot interval
> needed for the second acknowledgment is (to at least a large extent)
> provided by the savings in maximum transmit duration of that initial (now
> shorter) PDU. This works in practice because the process state information
> publications for which duocast is usually employed are quite compact,
> typically consisting of only one or two 5-byte process state APDUs, each of
> which typically consists of a 1-byte status data struct and a 4-byte
> float32.
>
> Incidentally, such a limited use of duocast is compatible with the existing
> design of WirelessHART.
>
> -Tom
> =====
> Qin,
>
> Your question implies a misunderstanding. Nodes do not HAVE slot durations;
> nodes USE slot durations. A node that uses duocast for a specific class of
> transmissions (e.g., 4 Hz process state publishing) uses unicast or
> broadcast for all remaining transactions.
>
> Existing industrial systems that use duocast employ duocast only for state
> reporting for high-speed control loops. Those devices are, in the absence of
> router failure, just one hop off the backbone, which is typical for
> similar-usage devices in WirelessHART systems. Emerson and Honeywell and
> other vendors of such high-loop-rate control devices agree that one-hop
> placement is needed in most cases to support the control requirements of the
> underlying process.
>
> Unicast and broadcast are used by all the other nodes in that system for all
> messaging, and by the nodes that use duocast for messaging needs other than
> high-frequency process state publishing where delivery reliability per
> transmission attempt is paramount.
>
> FYI, I was one of the designers of both WirelessHART and ANSI/ISA 100.11a,
> and have had these discussions with the other designers of each protocol.
>
> -Tom
> =====
>
>> nodes with different slot duration? For example, the nodes with different

-- 
Pascal