Please note that RFC7554 is informational, and describes/introduces the
functioning of TSCH. The actual standard is IEEE802.15.4-2015 . In
particular, in case of discrepencies between the docs, IEEE802.15.4-2015 is
the one to follow.
You raise a valid point. There are a couple of points, though, that make an
"Absolute Slot Number" more favorable compared to an "Absolute Slotframe
- if you schedule multiple cells between two nodes in a single slotframe,
you want those different transmissions to happen at a different frequency
- ASN is used to construct a nonce when securing link-layer frames.
Security is such that we never want to re-use the same nonce.
Happy to answer further questions to might have, also during the interim
meeting later today .
On Thu, Sep 22, 2016 at 4:39 PM, Dale R. Worley <wor...@ariadne.com> wrote:
> Pardon me, I'm new here, but I was wondering why the channel hopping
> scheme is defined the way it is. Currently, RFC 7554 notes that the
> channel selected for a transmission by a node is:
> frequency = frequency_table [ (ASN + channelOffset) mod nFreq ]
> where channelOffset is a set value for this node to use in this slot of
> the slotframe cycle, frequency_table is a set array of frequencies, and
> nFreq is the size of frequency_table.
> The question I have is with ASN, the "absolute slot number". RFC 7554
> states that it increments one for each slot time, so that as a
> particular slotframe slot recurs, the ASN is incremented by the number
> of slots in the slotframe.
> The result is that to ensure that each node's transmissions cycle
> through all the frequencies in the frequency_table, the length of the
> slotframe needs to be relatively prime to nFreq:
> A way of ensuring communication happens on all available frequencies
> is to set the number of timeslots in a slotframe to a prime number.
> My question is that if ASN was redefined to be a counter of slotframes
> rather than of slots, then each node would cycle through all the
> frequencies regardless of the size of the slotframe, because each node's
> frequency index would advance 1 with each slotframe rather than
> (slotframe_size mod nFreq).
> This alternative is fairly obvious, so there must be a known reason why
> it isn't desirable.
> 6tisch mailing list
Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH
6tisch mailing list