Subject: [6tisch] slot schedluing

From: Randy Turner <[email-masked]>
Date: Wed, 7 Dec 2016 15:37:09 -0500

Hi All,
Just re-confirming an assumption — from a TSCH perspective, slot scheduling assumes any single transmission “cannot” exceed a slot boundary — if transmissions require a certain amount of time, then the slot width is increased to deal with this ( or possibly increase the TX bit rate if possible )

Is this correct ?

Thanks!
Randy

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 8 Dec 2016 13:22:20 +0100

Hi Randy,

Table 8-145—TSCH MAC PIB attributes for macTimeslotTemplate of the
IEEE802.15.4-2015 define the timeslot timing values. Any transmission
should follow that. If not the state machine of the MAC aborts that slot.
If you need more time than what is defined in the default value you can
increase the slot macTsTimeslotLength value and the rest of PIB values
accordingly. Higher data rates are depend to the underlying radio
technology and their use may not be standard compliant. The use of longer
timeslot is advertised in the EB through the TSCH Timeslot IE.

In the minimal draft you can find an example of a macTimeslotTemplate
defining a timeslot of 15ms.

hope this helps!
regards,
Xavi

2016-12-07 21:37 GMT+01:00 Randy Turner <[email-masked]>:

> Hi All,
> Just re-confirming an assumption — from a TSCH perspective, slot
> scheduling assumes any single transmission “cannot” exceed a slot boundary
> — if transmissions require a certain amount of time, then the slot width is
> increased to deal with this ( or possibly increase the TX bit rate if
> possible )
>
> Is this correct ?
>
> Thanks!
> Randy
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 8 Dec 2016 14:23:32 +0200

Randy Turner writes:
> scheduling assumes any single transmission “cannot” exceed a slot
> boundary —

Yes.

IEEE Std. 802.15.4-2015 requires that "The transmission of frames and
the associated Ack frames need to be completed at least one SIFS time
before the end of the ATI", and ATI (allowed transmission interval) is
specified for TSCH as "TSCH timeslot: start and end time defined the
macSlotframeHandle, macTimeslot and macTsTimeslotLength". (section
6.7.5 of 802.15.4-2015).

> if transmissions require a certain amount of time, then the slot
> width is increased to deal with this ( or possibly increase the TX
> bit rate if possible )

In practice no. Yes, you could recreate the network with new
parameters, but in practice you need to decide parameters beforehand,
and those parameters will then limit what you can do. For example
dynamically changing the timeslot length would not really work in
TSCH, as there is no way to syncronize that change throughout the
network, and devices sleeping would get out of sync if they do not see
the beacon announcing new parameters.

If such feature would be needed, I think you need to tear down the
network and recreate it if you want to change any core parameters in
the TSCH network. You can add new slots and add new slotframe
descriptors, but changing existing ones are harder.

The 802.15.4-2015 do warn you about this: (section 6.2.6.1):

   Each timeslot allows enough time for a pair of devices to exchange
   a frame and an acknowledgment. It is possible, although usually
   undesirable, to define a timeslot that is not long enough for a
   pair of devices to exchange a maximum length frame and an Ack
   frame.

So it is better to decide the required parameters before you start the
network and stick with them....
-- 
[email-masked]

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 08 Dec 2016 15:38:14 -0500

Randy Turner <[email-masked]> writes:
> Just re-confirming an assumption -- from a TSCH perspective, slot
> scheduling assumes any single transmission "cannot" exceed a slot
> boundary -- if transmissions require a certain amount of time, then the
> slot width is increased to deal with this ( or possibly increase the
> TX bit rate if possible )
>
> Is this correct ?

As others have noted, extending the slot width can only be done when the
network is initialized.  In practice, packets that do not fit within a
slot time are fragmented.  My understanding is that all such packets are
IP packets, and are fragmented using using the layer 2 fragmentation
defined in RFC 6282 (not the one defined in RFC 4944).  Thus, the
minimum (layer 3) IPv6 MTU of 1280 bytes is supported.

As far as I know, there is no fragmentation mechanism for the EB
(extended beacon) layer-2 packets.  But that does not seem to be a
problem in practice.

Dale

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 9 Dec 2016 15:38:58 +0100

Dale,

+1 on your answer.

Thomas

-- 
_______________________________________

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: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 13 Dec 2016 15:18:06 +0000

Seems that large EBs at low rates ended up being a problem in subgig cases after all, Dale.

The discussion at the interim was either to make very large slots => impractical, or preconfigure sometimes, 2 or more consecutive time slots are paired; the second is never scheduled, and is free to accept the remainder of the frame sent in the first… The pairing will be interesting to make work, ince the channel computation is based on ASN so the consecutive time slots to not have the same channel offset….

Cheers

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: vendredi 9 décembre 2016 15:39
To: Dale R. Worley <[email-masked]>
Cc: Randy Turner <[email-masked]>; [email-masked]
Subject: Re: [6tisch] slot schedluing

Dale,

+1 on your answer.

Thomas

On Thu, Dec 8, 2016 at 9:38 PM, Dale R. Worley <[email-masked]<mailto:[email-masked]>> wrote:

Dale

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

Thomas Watteyne, PhD

www.thomaswatteyne.com<http://www.thomaswatteyne.com>
_______________________________________

---

From: Randy Turner <[email-masked]>
Date: Tue, 13 Dec 2016 10:34:42 -0500

Hi Pascal,

That was the other alternative on the call I was referring to, if a node (application) requires spanning a slot for TX, then an application/context-based cell scheduling algorithm would just schedule adjacent cells ( on the same channel )— but this is just one alternative, there are probably other considerations…I’m still studying scheduling documents.

R.

> On Dec 13, 2016, at 10:18 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> From: 6tisch [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Thomas Watteyne
> To: Dale R. Worley <[email-masked] <mailto:[email-masked]>>
> Cc: Randy Turner <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On Thu, Dec 8, 2016 at 9:38 PM, Dale R. Worley <[email-masked] <mailto:[email-masked]>> wrote:
> Randy Turner <[email-masked] <mailto:[email-masked]>> writes:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
> 
> 
>  
> -- 
> www.thomaswatteyne.com <http://www.thomaswatteyne.com/>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>

---

From: Randy Turner <[email-masked]>
Date: Tue, 13 Dec 2016 13:12:10 -0500

Regarding transmissions spanning a slot…it’s potentially multiple slots.  If the max MAC frame size is 1500 bytes.  At the worst case 50 kbps, that would be ~242 ms to send the frame - given a 10ms slot, thats 24 slots, or at 25 ms slots, that’s still almost 10 slots — The average packet size on our network is somewhat less, but for “bulk” types of traffic ( like network-wide firmware update scenarios ) it’s a problem, although this happens at higher bit-rates so it’s not as bad as 50kbps.

Randy

> On Dec 13, 2016, at 10:34 AM, Randy Turner <[email-masked]> wrote:
> 
> Hi Pascal,
> 
>> On Dec 13, 2016, at 10:18 AM, Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 14 Dec 2016 11:49:44 -0500

> Seems that large EBs at low rates ended up being a problem in subgig

Ouch!

My memory is that 802.15.4 limits the EB to 127 bytes (plus the
link-layer overheads), and that maximum-length frames can be transmitted
in the default slot size.  And that 802.15.4 fixes the EB format in a
way that does not provide for fragmentation.  So I don't see how you
could even transmit an extra-long EB, much less have to worry about a
slot for it.

But I suspect that my inexperience is making me overlook how extra-long
frames can be handled.

I can see a way of avoiding this by partitioning the optional IEs you
want to send in the EB into several subsets, transmitting first an EB
with subset 1, then an EB with subset 2, etc.  I suppose you'd need yet
another IE to tell the listener which subset this is and how many
subsets there are so that the listener could know when it had heard the
whole set.

Dale

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 16 Dec 2016 14:34:32 +0200

Dale R. Worley writes:
> in the default slot size.

IEEE Std. 802.15.4-2015 EB can be up to any length that the PHY will
support. In the normal 2.4GHz O-QPSK PHY this is 127 bytes.

Other PHYs do have other limits, and for example the 802.15.4t
"Amendment: Higher Rate (2 Mb/s) Physical (PHY) Layer" will support
max frame size of 2048 bytes on the same 2.4GHz band (with higher data
rate).

802.15.4t is now in sponsor ballot phase, so it might be out quite soon.

> And that 802.15.4 fixes the EB format in a way that does not provide
> for fragmentation. So I don't see how you could even transmit an
> extra-long EB, much less have to worry about a slot for it.

All of that will depend on the PHY you plan to use.

> subsets there are so that the listener could know when it had heard the

In the 802.15.10 " Recommended Practice for Routing Packets in IEEE
Std 802.15.4 Dynamically Changing Wireless Networks" which provides
mesh networking and routing to the 802.15.4 they will include several
IEs in EBs, and EBs are separated so that some EBs have TC IEs, some
have NLM IEs and so on. And because NLM IEs can still be too large,
they will send them in pieces, i.e., the NLM IE contains internal
subsetting, where they send the whole list of neighbors over multiple
NLM IEs. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 16 Dec 2016 14:42:04 +0200

Pascal Thubert (pthubert) writes:
> The discussion at the interim was either to make very large slots =>
> impractical, or preconfigure sometimes, 2 or more consecutive time slots are
> paired; the second is never scheduled, and is free to accept the remainder of
> the frame sent in the first… The pairing will be interesting to make work,
> ince the channel computation is based on ASN so the consecutive time slots to
> not have the same channel offset….

I do not think you can do that. 802.15.4-2015 section 6.7.5
Transmission timing restrictions specifies that you have allowed
transmission interval (ATI), and in TSCH that is TSCH timeslot, which
have specific start and stop times. Node is not allowed to go over
that, i.e., the transmission must be completed before the end of ATI,
and also if this is ACKed transmission the original sender must allow
enough time for the other end to send back the appropriate ACK frame
with required IEs (i.e. Time Synchronization in TSCH). There is also
guard time to make sure that even if someone starts early we do not
run over with previous transmission.
-- 
[email-masked]

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 16 Dec 2016 10:07:20 -0500

> max frame size of 2048 bytes on the same 2.4GHz band (with higher data

So that's the keys, different PHYs have different link-level framing,
and some allow longer packets.

I assume that if using one of those PHYs, the time slots are still long
enough for any frame (within the limits allowed by the PHY and network
configuration).

> In the 802.15.10 "Recommended Practice for Routing Packets in IEEE

That's interesting, as it sounds like 802.15.10 will put the routing
protocol will be done at the link level rather than within IPv6.  Is
this aligned with the work ROLL is doing, or is it an alternative?

Dale