Subject: [6tisch] The channel hopping scheme seems to be suboptimal

From: [email-masked] (Dale R. Worley)
Date: Thu, 22 Sep 2016 10:39:51 -0400

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.

Dale

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 23 Sep 2016 08:43:19 +0200

Dale,

Please note that RFC7554 is informational, and describes/introduces the
functioning of TSCH. The actual standard is IEEE802.15.4-2015 [1]. 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
Number":
- 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 [2].

Thomas

[1] http://standards.ieee.org/about/get/802/802.15.html
[2] https://www.ietf.org/mail-archive/web/6tisch/current/msg04760.html

On Thu, Sep 22, 2016 at 4:39 PM, Dale R. Worley <[email-masked]> wrote:

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

-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 23 Sep 2016 14:52:10 -0400

> you want those different transmissions to happen at a different frequency

Although you could construct the schedule so that the nodes have
different channel offsets for the different slots within the schedule.

> Security is such that we never want to re-use the same nonce.

Although you could construct the nonce to be (ASFN * nSlots +
slotOffset).  And you need to do a construction like that to make sure
that different nodes with different channel offsets during the same slot
do not use the same nonce.

I suspect the main reason is that several slotframe schedules of
different lengths can be active at the same time in one network.
Keeping a separate ASFN for each schedule would require a lot of work.

Dale

---

From: Simon Duquennoy <[email-masked]>
Date: Fri, 23 Sep 2016 21:02:39 +0200

> Keeping a separate ASFN for each schedule would require a lot of work.

With the standard you also get the guarantee that slots with different
channel offsets will never collide, regardless of the slotframe and
node they belong to.

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 23 Sep 2016 21:27:07 +0200

Dale,
Agreed, although what you propose results in the same behaviornasnASN. ASN
is what was chosen.
Thomas

On Friday, September 23, 2016, Dale R. Worley <[email-masked]> wrote:

> Thomas Watteyne <[email-masked] <javascript:;>> writes:

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 27 Sep 2016 16:29:52 +0300

> different channel offsets for the different slots within the schedule.

There can also be multiple networks (or parts of network) using
different set of slotframe lengths, and channel offsets etc, and if
things are set properly they do not collide.

I.e. if you have network(s) using same hopping sequence and hopping
sequence length, but different number of slots (slotframe length) and
different channel offsets, they can coexists in same space, and they
will not transmit on the same channel.

I made an excel sheet to demonstrate this:

https://mentor.ieee.org/802.15/dcn/15/15-15-0604-00-0mag-example-of-tsch-schedule.xls

Here you can have multiple networks (A-J) and they can have different
number number of slots and different channel offset and you can see
that do not collide if parameters are selected properly (i.e. they use
different channel offset).

Using different channel offsets you can configure network with
different slot frame lengths, i.e. you can have one with slotframe
length of 100 to allow lots of clients, and another one with slotframe
length of 5 to allow fast access to media etc.

If device is part of multiple of those it will pick which of those
networks it is using based on priority, i.e., if it wants to transmit
something and has slot that allows transmit on one network, it tunes
in to that channel and transmits. Otherwise it picks the one of the
receive channels and listents to that etc.

802.15.4 has some text about this, but mostly this is defined by the
vendor making the devices...

> do not use the same nonce.

Nonce also has the transmitters extended address, which makes the
nonces different for each transmitter, and one transmitter can only
transmit one packet on each slot thus nonce is unique. 

> Keeping a separate ASFN for each schedule would require a lot of work.

Yes.
-- 
[email-masked]

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 27 Sep 2016 15:59:44 +0200

Tero, agreed.

Thomas Watteyne, PhD

www.thomaswatteyne.com