RFC 7554

Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement

📅 published May 2015, from ietf

RFC 7554: Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement 🎀

Okay bestie, this one is an Informational RFC, so it's not a Standards Track spec, just really useful background 🧚 It came out in May 2015 with ISSN 2070-1721. The editor is T. Watteyne, Ed. from Linear Technology, and the other authors are M. Palattella (University of Luxembourg) and L. Grieco (Politecnico di Bari). Its title block doesn't list anything it obsoletes or updates, so it doesn't replace or change any other RFC 💖

Abstract

This doc describes the environment, problem statement, and goals for using the Time-Slotted Channel Hopping (TSCH) Medium Access Control (MAC) protocol of IEEE 802.14.4e in the context of Low-Power and Lossy Networks (LLNs). The set of goals listed here is only an initial set. 🦋

Status of This Memo

Okay, the status bit: this is not an Internet Standards Track spec. It's published just for information ✨

It's a product of the IETF, so it represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the full picture 💅

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7554 🌸

Copyright Notice

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they stood on the publication date. Please actually read them, because they explain your rights and restrictions for this doc. Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🙈

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
2.  TSCH in the LLN Context . . . . . . . . . . . . . . . . . . .   5
3.  Problems and Goals  . . . . . . . . . . . . . . . . . . . . .   7
  3.1.  Network Formation . . . . . . . . . . . . . . . . . . . .   8
  3.2.  Network Maintenance . . . . . . . . . . . . . . . . . . .   8
  3.3.  Multi-Hop Topology  . . . . . . . . . . . . . . . . . . .   8
  3.4.  Routing and Timing Parents  . . . . . . . . . . . . . . .   8
  3.5.  Resource Management . . . . . . . . . . . . . . . . . . .   9
  3.6.  Dataflow Control  . . . . . . . . . . . . . . . . . . . .   9
  3.7.  Deterministic Behavior  . . . . . . . . . . . . . . . . .   9
  3.8.  Scheduling Mechanisms . . . . . . . . . . . . . . . . . .  10
  3.9.  Secure Communication  . . . . . . . . . . . . . . . . . .  10
4.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
  5.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
  5.2.  Informative References  . . . . . . . . . . . . . . . . .  11
Appendix A.  TSCH Protocol Highlights . . . . . . . . . . . . . .  15
  A.1.  Time Slots  . . . . . . . . . . . . . . . . . . . . . . .  15
  A.2.  Slotframes  . . . . . . . . . . . . . . . . . . . . . . .  15
  A.3.  Node TSCH Schedule  . . . . . . . . . . . . . . . . . . .  15
  A.4.  Cells and Bundles . . . . . . . . . . . . . . . . . . . .  16
  A.5.  Dedicated vs. Shared Cells  . . . . . . . . . . . . . . .  17
  A.6.  Absolute Slot Number  . . . . . . . . . . . . . . . . . .  17
  A.7.  Channel Hopping . . . . . . . . . . . . . . . . . . . . .  17
  A.8.  Time Synchronization  . . . . . . . . . . . . . . . . . .  18
  A.9.  Power Consumption . . . . . . . . . . . . . . . . . . . .  19
  A.10. Network TSCH Schedule . . . . . . . . . . . . . . . . . .  19
  A.11. Join Process  . . . . . . . . . . . . . . . . . . . . . .  19
  A.12. Information Elements  . . . . . . . . . . . . . . . . . .  20
  A.13. Extensibility . . . . . . . . . . . . . . . . . . . . . .  20
Appendix B.  TSCH Features  . . . . . . . . . . . . . . . . . . .  21
  B.1.  Collision-Free Communication  . . . . . . . . . . . . . .  21
  B.2.  Multi-Channel vs. Channel Hopping . . . . . . . . . . . .  21
  B.3.  Cost of (Continuous) Synchronization  . . . . . . . . . .  21
  B.4.  Topology Stability  . . . . . . . . . . . . . . . . . . .  21
  B.5.  Multiple Concurrent Slotframes  . . . . . . . . . . . . .  22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  22
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

1. Introduction ✨

IEEE 802.15.4e [IEEE.802.15.4e] came out in 2012 as an amendment to the MAC protocol from the IEEE 802.15.4 standard (the 2011 version) [IEEE.802.15.4]. It's getting rolled into the next revision of IEEE 802.15.4, which is scheduled for publication in 2015. The Time-Slotted Channel Hopping (TSCH) mode of IEEE 802.15.4e is the star of this doc 🌟 When this doc says "TSCH", it means TSCH as used in [IEEE.802.15.4e].

This doc covers the main issues that come up when you adopt TSCH in the LLN context, using the terminology from [TERMS-6TISCH]. Appendix A gives an overview of the key features of the TSCH amendment to IEEE 802.15.4e 📚 Appendix B digs into TSCH features that might be interesting for the 6TiSCH WG 🧚

TSCH was designed so IEEE 802.15.4 devices can support a wide range of applications, including (but not limited to) industrial ones [IEEE.802.15.4e]. At its core is a medium access technique that uses time synchronization for low-power operation and channel hopping for high reliability. Synchronization accuracy affects power consumption and can range from microseconds to milliseconds depending on the solution. This is super different from the "legacy" IEEE 802.15.4 MAC protocol, so it's better described as a "redesign" 💅 TSCH doesn't amend the physical layer, which means it can run on any hardware that's compliant with IEEE 802.15.4 🫶

IEEE 802.15.4e is the latest generation of ultra-low-power, reliable networking for LLNs 🔥 [RFC5673] talks about industrial applications and the harsh conditions they bring, plus the strict reliability, availability, and security requirements an LLN has to meet to work in an industrial environment. In those places, huge deployments with big metal equipment cause multi-path fading and interference, so any single-channel solution struggles to be reliable. The channel agility of TSCH is the secret to its ultra-high reliability. Commercial networking solutions exist today where nodes consume 10's of microamps on average [CurrentCalculator], with end-to-end packet delivery ratios over 99.999% [Doherty07channel]. Iconic 🤩

IEEE 802.15.4e was designed for low-power constrained devices, often called "motes" 🍓 The IETF uses several terms for these devices, including "LLN nodes" [RFC7102] and "constrained nodes" [RFC7228]. In this doc, we use the generic (and shorter) term "node," which is a synonym for "LLN node," "constrained node," or "mote."

Making the LLN protocol stack work in industrial environments opens up new application domains for these networks 🌈 Sensors deployed in smart cities [RFC5548] can be installed for years without needing a battery replacement. "Umbrella" networks can interconnect smart elements from different entities in smart buildings [RFC5867]. Peel-and-stick switches will make costly conduits for lighting solutions in smart homes unnecessary [RFC5826] 🦋

TSCH focuses on the MAC layer only, and that clean layering lets TSCH fit under an IPv6-enabled protocol stack for LLNs. That stack includes IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) [RFC6282], the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550], and the Constrained Application Protocol (CoAP) [RFC7252] 💖 What's still missing is a functional entity in charge of scheduling the TSCH time slots that frames get sent on. This doc calls that entity the "Logical Link Control" (LLC), keeping in mind that it can be realized in different ways, including as a distributed protocol or as a centralized server doing the scheduling 👑

IEEE 802.15.4e defines the mechanisms for a TSCH node to communicate, but it doesn't define the policies for building and maintaining the communication schedule. It also doesn't cover matching that schedule to the multi-hop paths RPL maintains, adapting the resources between neighbor nodes to the data traffic flows, enforcing differentiated treatment for application-layer data versus the signaling messages 6LoWPAN and RPL need to discover neighbors, reacting to topology changes, self-configuring IP addresses, or managing keying material 🙈

In other words, TSCH is designed to allow optimizations and strong customizations, which makes it easier to merge TSCH with a protocol stack based on IPv6, 6LoWPAN, and RPL 🎀

2. TSCH in the LLN Context ✨

Okay bestie, so the big question is how IP's needs get matched up with what the link layer actually offers 🫶. The answer is an adaptation layer [Palattella12standardized], and it's giving main character energy. 🎀 Back in 2007 the 6LoWPAN WG started working on specs for sending IPv6 packets over IEEE 802.15.4 networks [RFC4919]. 🦋 A low-power Wireless Personal Area Network (WPAN) is usually a big crowd of battery-powered devices scattered in spots nobody planned ahead of time 🌸. They form a star or a mesh, they talk to each other at a low datarate using short frames, and the wireless links are unreliable, ngl 💀. Nodes also keep their radios off most of the time to save energy. So yeah, putting IPv6 on a low-power WPAN is NOT straightforward. It puts serious demands on how this adaptation layer gets optimised 🔥.

Here's one example. The IPv6 default minimum MTU is 1280 bytes, so an unfragmented IPv6 packet is way too big for an IEEE 802.15.4 frame 😭. On top of that, the 40-byte-long IPv6 header eats up the scarce bandwidth at the PHY layer [RFC4944]. That's why the 6LoWPAN WG came up with an effective adaptation layer [RFC6282] 👑. There's more on the list too: autoconfiguration of IPv6 addresses [RFC2460] [RFC4862], following the recommendation on supporting link-layer subnet broadcast in shared networks [RFC3819], cutting down routing and management overhead [RFC6606], using lightweight application protocols (or new data encoding techniques), and supporting security mechanisms (confidentiality and integrity protection, device bootstrapping, key establishment, and management) 🔐.

These features can all run on top of TSCH ✨. BUT there are important issues to solve, which Section 3 spills the tea on 🙈.

Routing is a whole challenge for 6LoWPAN, bestie. You've got low-power and lossy radio links, battery-powered nodes, multi-hop mesh topologies, and topology changes that happen all the time because of mobility 😵‍💫. The good solutions take the specific application requirements into account, along with IPv6 behaviour and 6LoWPAN mechanisms [Palattella12standardized]. The ROLL WG defined RPL in [RFC6550] 💜. RPL can handle a wide variety of link layers, including constrained and potentially lossy ones, or ones typically used with host or router devices that have very limited resources. Think building and home automation [RFC5867] [RFC5826], industrial environments [RFC5673], and urban applications [RFC5548] 🏙️. RPL quickly builds up network routes, spreads routing knowledge among the nodes, and adapts when the topology changes 🧚. Usually nodes connect through multi-hop paths to a small set of root devices, which are normally in charge of data collection and coordination 👑. For each root, a Destination-Oriented Directed Acyclic Graph (DODAG) gets created by looking at link costs, node attributes and status information, and an Objective Function, which maps the optimisation requirements of the target scenario 🌈.

The topology is built on a Rank metric, which encodes how far each node is from its reference root, as the Objective Function specifies 📏. No matter how it's computed, the Rank monotonically decreases along the DODAG towards the root, so you get a gradient ⭐. RPL covers different kinds of traffic and signalling information. Multipoint-to-Point (MP2P) is the dominant traffic in LLN applications 💅. Data gets routed towards nodes with some application relevance, like the LLN gateway to the bigger Internet or to the core of private IP networks. Generally those destinations are the DODAG roots, acting as data collection points for distributed monitoring apps 🍓. Point-to-Multipoint (P2MP) data streams are for actuation, where messages go from DODAG roots to destination nodes 🔥. Point-to-Point (P2P) traffic lets two devices in the same LLN talk to each other, like a sensor and an actuator 🦋. A packet goes from the source up to the common ancestor of those two devices, then back down towards the destination. So RPL has to discover upward routes (from nodes to DODAG roots) to support MP2P and P2P flows, AND downward routes (from DODAG roots to nodes) to support P2MP and P2P traffic 🫶.

Section 3 breaks down the challenges you need to tackle to use RPL on top of TSCH 💖.

Open-source projects have popped up around TSCH too 🌸. OpenWSN [OpenWSN] [OpenWSNETT] was the first open-source implementation of a standards-based protocol stack, and it was the foundation for an IP for the Smart Objects Alliance (IPSO) [IPSO] interoperability event in 2011 ✨. Since there wasn't a standardised scheduling mechanism for TSCH yet, a "slotted Aloha" schedule was used 🙈.

3. Problems and Goals

Like Appendix A explains, TSCH is different from other low-power MAC protocols because it's scheduled 🗓️. TSCH defines the mechanisms to execute a communication schedule, but the entity that sets up the schedule is the one controlling the topology of the network 👑. That same scheduling entity also controls the resources given to each link in that topology 💅.

How this entity should operate is out of scope for TSCH 🙅‍♀️. The rest of this section lists the problems this entity needs to solve. To keep things simple, we call it the generic name "LLC" 🎀. Heads up: the 6top sublayer, which is currently being defined in [SUBLAYER-6top], can be seen as an embodiment of this generic "LLC" 💜.

Some of the issues the LLC has to target might overlap with other protocols (like 6LoWPAN, RPL, and RSVP). When that happens, the LLC will profit from the services those other protocols provide to hit its goals 🤝.

3.1. Network Formation

The LLC controls how the network forms, including how new nodes join and how nodes that already joined announce that the network exists 🌈. The LLC needs to:

Define the Information Elements included in the Enhanced Beacons (EBs) [IEEE.802.15.4e] that advertise the presence of the network.
(For a new node) define rules to process and filter received EBs.
Define the joining procedure. This might include a mechanism to assign a unique 16-bit address to a node and the management of initial keying material 🔑.
Define a mechanism to secure the joining process and the subsequent optional process of scheduling more communication cells 🔐.

3.2. Network Maintenance

Once the network is formed, the LLC has to keep its health up so nodes can stay synchronised 💖. The LLC needs to:

Manage each node's time source neighbour.
Define a mechanism for a node to update the join priority it announces in its EB.
Schedule transmissions of EBs to advertise the presence of the network 📢.

3.3. Multi-Hop Topology

RPL, given a weighted connectivity graph, figures out multi-hop routes 🗺️. The LLC needs to:

Define a mechanism to gather topological information (node and link state) that it can then feed to RPL.
Ensure that the TSCH schedule contains cells along the multi-hop routes identified by RPL (a cell in a TSCH schedule is an atomic "unit" of resource, see Section 3.5) 🧩.
Where applicable, maintain independent sets of cells to carry independent flows of data 🌊.

3.4. Routing and Timing Parents

At all times, a TSCH node needs a time-source neighbour to sync up with ⏰. So the LLC needs to assign a time-source neighbour to keep the TSCH network working correctly. A time-source neighbour could, or could not, be taken from the RPL routing parent set 🤷‍♀️.

3.5. Resource Management

A cell in a TSCH schedule is an atomic "unit" of resource 🍰. The number of cells to assign between neighbour nodes has to fit the size of the traffic flow. The LLC needs to:

Define a mechanism for neighbour nodes to exchange information about their schedule and, if applicable, negotiate the addition/deletion of cells.
Allow for an entity (e.g., a set of devices, a distributed protocol, a Path Computation Element (PCE), etc.) to take control of the schedule 👑.

3.6. Dataflow Control

TSCH has mechanisms for a node to signal when it can't accept an incoming packet 🚦. It does NOT, however, define the policy that decides when to stop accepting packets. The LLC needs to:

Allow for the implementation and configuration of policy to queue incoming and outgoing packets.
Manage the buffer space, and indicate to TSCH when to stop accepting incoming packets.
Handle transmissions that have failed. A transmission is declared failed when TSCH has retransmitted the packet multiple times without receiving an acknowledgment. This covers both dedicated and shared cells 😤.

3.7. Deterministic Behavior

As highlighted in [RFC5673], in some applications data is generated periodically and has a well-understood data bandwidth requirement, which is deterministic and predictable 📅. The LLC needs to:

Ensure that the data is delivered to its final destination before a deadline possibly determined by the application ⏳.
Provide a mechanism for such deterministic flows to coexist with bursty or infrequent traffic flows of different priorities 🚗.

3.8. Scheduling Mechanisms

Lots of scheduling mechanisms can be imagined, and they could possibly coexist in the same network 🌐. For example, [RPL] describes how bandwidth allocation can be optimised by an external PCE [RFC4655]. Another centralised (PCE-based) traffic-aware scheduling algorithm is defined in [TASA-PIMRC]. Alternatively, two neighbour nodes can adapt the number of cells on their own, by monitoring how much traffic there is and negotiating an extra cell when it's needed 📊. An example of a decentralised algorithm (i.e., no PCE is needed) is given in [Tinka10decentralized]. This mechanism can be used to set up multi-hop paths in a way similar to RSVP [RFC2205] 🛤️. The LLC needs to:

Provide a mechanism for two devices to negotiate the allocation and deallocation of cells between them.
Provide a mechanism for the device to monitor and manage the capabilities of a node several hops away 🔭.
Define a mechanism for these different scheduling mechanisms to coexist in the same network 🤝.

3.9. Secure Communication

Given some keying material, TSCH defines mechanisms to encrypt and authenticate MAC frames 🔒. It does NOT define how that keying material gets generated. The LLC needs to:

Define the keying material and authentication mechanism a new node needs to join an existing network.
Define a mechanism to allow for the secure transfer of application data between neighbour nodes.
Define a mechanism to allow for the secure transfer of signalling data between nodes and the LLC 🛡️.

4. Security Considerations 🚨

This memo is an informational overview of existing standards, and it does NOT define any new mechanisms or protocols. Not a new protocol, bestie, just a map of what's already out there 🗺️.

It DOES describe the need for the 6TiSCH WG to define a secure solution, and this part is seriously important 😱. In particular, Section 3.1 describes security in the join process, and Section 3.9 discusses data-frame protection 🔐. Please don't skip those sections!!

5. References 📚

5.1. Normative References

Okay, bestie, these are the must-read references 💅 Normative means you genuinely need them to get the spec, so no skipping!

[IEEE.802.15.4] IEEE, "IEEE Standard for Local and metropolitan area networks -- Part. 15.4: Low-Rate Wireless Personal Area Networks", IEEE Std. 802.15.4-2011, September 2011. 📡
[IEEE.802.15.4e] IEEE, "IEEE Standard for Local and metropolitan area networks -- Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) Amendment 1: MAC sublayer", IEEE Std. 802.15.4e-2012, April 2012. ✨

5.2. Informative References

These ones are the extra-credit reading 🧚 They're not required, but they're absolutely iconic for context.

[CurrentCalculator] Linear Technology, "Application Note: Using the Current Calculator to Estimate Mote Power", August 2012, <http://www.linear.com/docs/43189>. 🔋
[Doherty07channel] Doherty, L., Lindsay, W., and J. Simon, "Channel-Specific Wireless Sensor Network Path Data", IEEE International Conference on Computer Communications and Networks (ICCCN), pp. 89-94, 2007. 🌸
[IPSO] IPSO Alliance, "IP for Smart Objects Alliance Homepage", <http://www.ipso-alliance.org/>. 🫶
[OpenWSN] "Berkeley's OpenWSN Project Homepage", <http://www.openwsn.org/>. 🦋
[OpenWSNETT] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: A Standards-Based Low-Power Wireless Development Environment", Transactions on Emerging Telecommunications Technologies, Volume 23: Issue 5, August 2012. 💜
[Palattella12standardized] Palattella, MR., Accettura, N., Vilajosana, X., Watteyne, T., Grieco, LA., Boggia, G., and M. Dohler, "Standardized Protocol Stack For The Internet Of (Important) Things", IEEE Communications Surveys and Tutorials, Volume: 15, Issue 3, December 2012. 🌈
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <http://www.rfc-editor.org/info/rfc2205>. 🎀
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>. 👑
[RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, DOI 10.17487/RFC3819, July 2004, <http://www.rfc-editor.org/info/rfc3819>. 🍓
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>. 🧭
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>. ⭐
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, August 2007, <http://www.rfc-editor.org/info/rfc4919>. 🌸
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>. 🫶
[RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and D. Barthel, Ed., "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May 2009, <http://www.rfc-editor.org/info/rfc5548>. 🏙️
[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October 2009, <http://www.rfc-editor.org/info/rfc5673>. 🏭
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, DOI 10.17487/RFC5826, April 2010, <http://www.rfc-editor.org/info/rfc5826>. 🏠
[RFC5867] Martocci, J., Ed., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June 2010, <http://www.rfc-editor.org/info/rfc5867>. 🔥
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <http://www.rfc-editor.org/info/rfc6282>. 🗜️
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, <http://www.rfc-editor.org/info/rfc6550>. 🛣️
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing", RFC 6606, DOI 10.17487/RFC6606, May 2012, <http://www.rfc-editor.org/info/rfc6606>. 📝
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2014, <http://www.rfc-editor.org/info/rfc7102>. 📖
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>. 🤏
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>. 💌
[RPL] Phinney, T., Thubert, P., and R. Assimiti, "RPL applicability in industrial networks", Work in Progress, draft-ietf-roll-rpl-industrial-applicability-02, October 2013. 🛠️
[SUBLAYER-6top] Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH Operation Sublayer (6top)", Work in Progress, draft-wang-6tisch-6top-sublayer-01, July 2014. 🧩
[TASA-PIMRC] Palattella, MR., Accettura, N., Dohler, M., Grieco, LA., and G. Boggia, "Traffic Aware Scheduling Algorithm for reliable low-power multi-hop IEEE 802.15.4e networks", IEEE 23rd International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC), pp. 327-332, September 2012. 🚦
[TERMS-6TISCH] Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, "Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e", Work in Progress, draft-ietf-6tisch-terminology-04, March 2015. 📚
[Tinka10decentralized] Tinka, A., Watteyne, T., and K. Pister, "A Decentralized Scheduling Algorithm for Time Synchronized Channel Hopping", Ad Hoc Networks, 2010. 🐝
[Watteyne09reliability] Watteyne, T., Mehta, A., and K. Pister, "Reliability Through Frequency Diversity: Why Channel Hopping Makes Sense", Proceedings of the 6th ACM Symposium on Performance Evaluation of Wireless Ad Hoc, Sensor, and Ubiquitous Networks (PE-WASUN), pp. 116-123, October 2009. 🦄

Appendix A. TSCH Protocol Highlights ✨

This appendix is basically a cheat sheet for the key features of the IEEE 802.15.4e TSCH amendment 🎀 It's not trying to copy the whole standard. Instead, it zooms in on:

Concepts that are sufficiently different from other IEEE 802.15.4 networking that they may need to be defined and presented precisely. 🔍
Techniques and ideas that are part of IEEE 802.15.4e and that might be useful for the work of the 6TiSCH WG. 💡

A.1. Time Slots

Okay so, every node in a TSCH network is synchronized, and time gets sliced up into time slots ⏱️ A time slot has to be long enough for a MAC frame of maximum size to go from node A to node B, plus enough room for node B to reply with an acknowledgment (ACK) frame saying it got the message successfully. It's giving teamwork 🫶

The standard doesn't define how long a time slot is. With IEEE 802.15.4 radios in the 2.4 GHz band, a maximum-length frame of 127 bytes takes about 4 ms to send, and a shorter ACK takes about 1 ms. So with a typical 10 ms slot, you still get 5 ms left over for radio turnaround, packet processing, and security operations. Math is mathing 🧮💖

A.2. Slotframes

Time slots get grouped into one or more slotframes, and a slotframe keeps repeating over time 🔁 TSCH doesn't put a limit on slotframe size. Depending on what the application needs, they can range from 10's to 1000's of time slots. Here's the tea: the shorter the slotframe, the more often each time slot comes around. That means more bandwidth available, but also higher power consumption 🔋⚡ Trade-offs, bestie 💅

A.3. Node TSCH Schedule

A TSCH schedule tells each node what to do in each time slot: transmit, receive, or sleep 📅 For every scheduled cell (transmit or receive), the schedule gives a channelOffset and the address of the neighbor the node should talk to.

Once a node has its schedule, this is how it runs it:

For each transmit cell, the node checks whether there is a packet in the outgoing buffer that matches the neighbor written in the schedule information for that time slot. If there is none, the node keeps its radio off for the duration of the time slot. If there is one, the node can ask for the neighbor to acknowledge it, in which case it has to listen for the acknowledgment after transmitting. 📤
For each receive cell, the node listens for possible incoming packets. If none is received after some listening period, it shuts down its radio. If a packet is received, addressed to the node, and passes security checks, the node can send back an acknowledgment. 📥

Heads up, bestie: how the schedule gets built, updated, and maintained, and which entity does it, is totally outside the scope of the IEEE 802.15.4e standard 🙈

A.4. Cells and Bundles ✨

Okay so, if the schedule is well built and node A is scheduled to transmit to node B at slotOffset 5 and channelOffset 11, then node B is scheduled to receive from node A at that same slotOffset and channelOffset. 💖

A single element of the schedule, identified by a slotOffset and a channelOffset and reserved for node A to transmit to node B (or for node B to receive from node A) within a given slotframe, is called a "scheduled cell". 🧚

If there's a LOT of data flowing from node A to node B, the schedule might contain multiple cells from A to B, at different times. Multiple cells scheduled to the same neighbor can be equivalent, which means the MAC layer sends the packet on whichever of these cells shows up first after the packet was put in the MAC queue. 🦋 The union of all cells between two neighbors, A and B, is called a "bundle".

Since the slotframe repeats over time (and its length is usually constant), each cell gives a "quantum" of bandwidth to a given neighbor. So changing the number of equivalent cells in a bundle changes how much resources get allocated between two neighbors. 💅

A.5. Dedicated vs. Shared Cells

By default, each scheduled transmit cell within the TSCH schedule is dedicated, meaning it's reserved only for node A to transmit to node B. 🌸 IEEE 802.15.4e also lets a cell be marked as shared. In a shared cell, multiple nodes can transmit at the same time, on the same frequency. To avoid contention, TSCH defines a backoff algorithm for shared cells. 🙈

A scheduled cell can be marked as both transmitting and receiving. In this case, a node transmits if it has an appropriate packet in its output buffer, or listens otherwise. Marking a cell as [transmit,receive,shared] results in slotted-Aloha behavior. 🔥

A.6. Absolute Slot Number

TSCH defines a timeslot counter called Absolute Slot Number (ASN). When a new network is created, the ASN is initialized to 0. From then on, it goes up by 1 at each timeslot. In detail:

ASN = (k*S+t)

where k is the slotframe cycle (i.e., the number of slotframe repetitions since the network was started), S is the slotframe size, and t is the slotOffset. A node learns the current ASN when it joins the network. Since nodes are synchronized, they all know the current value of the ASN at any time. The ASN is encoded as a 5-byte number, which lets it count up for hundreds of years (the exact value depends on the duration of a timeslot) without wrapping over. ⭐ The ASN is used to calculate the frequency to communicate on and can be used for security-related operations. 🔐

A.7. Channel Hopping

For each scheduled cell, the schedule specifies a slotOffset and a channelOffset. In a well-built schedule, when node A has a transmit cell to node B on channelOffset 5, node B has a receive cell from node A on the same channelOffset. Both nodes translate the channelOffset into a frequency using the following function:

frequency = F {(ASN + channelOffset) mod nFreq}

The function F is a lookup table containing the set of available channels. The value nFreq (the number of available frequencies) is the size of this lookup table. There are as many channelOffset values as there are frequencies available (e.g., 16 when using radios that are compliant with IEEE 802.15.4 at 2.4 GHz, when all channels are used). Since both nodes have the same channelOffset written in their schedule for that scheduled cell, and the same ASN counter, they compute the same frequency. At the next iteration (cycle) of the slotframe, however, the channelOffset is still the same but the ASN has changed, so a different frequency gets computed. 🦋

This results in "channel hopping": even with a static schedule, pairs of neighbors "hop" between the different frequencies when communicating. 🌈 A way of making sure communication happens on all available frequencies is to set the number of timeslots in a slotframe to a prime number. Channel hopping is a technique known to efficiently combat multi-path fading and external interference [Watteyne09reliability].

A.8. Time Synchronization

Because communication in a TSCH network is slotted, nodes have to maintain tight synchronization. 🕰️ All nodes are assumed to be equipped with clocks to keep track of time. Yet, because clocks in different nodes drift with respect to one another, neighbor nodes need to periodically resynchronize.

Each node needs to periodically synchronize its network clock to another node, and it also provides its network time to its neighbors. It is up to the entity that manages the schedule to assign an adequate time source neighbor to each node, i.e., to indicate in the schedule which neighbor is its "time source neighbor". While setting the time source neighbor, it is important to avoid synchronization loops, which could result in the formation of independent clusters of synchronized nodes. 😭

TSCH adds timing information in all packets that are exchanged (both data and ACK frames). This means neighbor nodes can resynchronize to one another whenever they exchange data. In detail, two methods are defined in IEEE 802.15.4e (of 2012) for allowing a device to synchronize in a TSCH network: (i) Acknowledgment-based and (ii) Frame-based synchronization. In both cases, the receiver calculates the difference in time between the expected time of frame arrival and its actual arrival. In Acknowledgment-based synchronization, the receiver provides that information to the sender node in its acknowledgment, and it is the sender node that synchronizes to the clock of the receiver. In Frame-based synchronization, the receiver uses the computed delta to adjust its own clock, and it is the receiver node that synchronizes to the clock of the sender. 💜

Different synchronization policies are possible. Nodes can keep synchronization exclusively by exchanging EBs. Nodes can also stay synchronized by periodically sending valid frames to a time source neighbor and using the acknowledgment to resynchronize. Both methods (or a combination of them) are valid synchronization policies, and which one to use depends on network requirements. 🎀

A.9. Power Consumption

There are only a handful of activities a node can perform during a timeslot: transmit, receive, or sleep. Each of these operations has some energy cost associated with it, and the exact value depends on the hardware used. Given the schedule of a node, it's straightforward to calculate that node's expected average power consumption. 🔋

A.10. Network TSCH Schedule

The schedule entirely defines the synchronization and communication between nodes. By adding or removing cells between neighbors, you can adapt a schedule to the needs of the application. Intuitive examples are:

Make the schedule "sparse" for applications where nodes need to consume as little energy as possible, at the price of reduced bandwidth. 🍃
Make the schedule "dense" for applications where nodes generate a lot of data, at the price of increased power consumption. ⚡
Add more cells along a multi-hop route over which many packets flow. 🛤️

A.11. Join Process

Nodes already part of the network can periodically send EB frames to announce the presence of the network. These contain information about the size of the timeslot used in the network, the current ASN, information about the slotframes and timeslots the beaconing node is listening on, and a 1-byte join priority. The join priority field gives information to help make a better decision about which node to join. Even if a node is configured to send all EB frames on the same channelOffset, because of the channel hopping nature of TSCH described in Appendix A.7, this channelOffset translates into a different frequency at different slotframe cycles. As a result, EB frames are sent on all frequencies. 🌍

A node wishing to join the network listens for EBs. Since EBs are sent on all frequencies, the joining node can listen on any frequency until it hears an EB. What frequency it listens on is implementation specific. Once it has received one or more EBs, the new node enables the TSCH mode and uses the ASN and the other timing information from the EB to synchronize to the network. Using the slotframe and cell information from the EB, it knows how to contact other nodes in the network. 🚀

The IEEE 802.15.4e TSCH standard does not define the steps beyond this network "bootstrap". 🤷‍♀️

A.12. Information Elements

TSCH introduces the concept of Information Elements (IEs). An IE is a list of Type-Length-Value containers placed at the end of the MAC header. A small number of types are defined for TSCH (e.g., the ASN in the EB is contained in an IE), and an unmanaged range is available for extensions. 🧩

A data bit in the MAC header indicates whether the frame contains IEs. IEs are grouped into Header IEs, which are consumed by the MAC layer and are therefore typically invisible to the next higher layer, and Payload IEs, which are passed untouched to the next higher layer, possibly followed by regular payload. Payload IEs can therefore be used for the next higher layers of two neighbor nodes to exchange information. 💌

A.13. Extensibility

The TSCH standard is designed to be extensible. It introduces the mechanisms as "building blocks" (e.g., cells, bundles, slotframes, etc.), but leaves entire freedom to the upper layer to assemble those. The MAC protocol can be extended by defining new Header IEs. An intermediate layer can be defined to manage the MAC layer by defining new Payload IEs. 🏗️

Appendix B. TSCH Features ✨

This section details features of TSCH that might be interesting for the work of the 6TiSCH WG. It does not define any requirements. 👀

B.1. Collision-Free Communication

TSCH allows one to design a schedule that yields collision-free communication. This is done by building the schedule with dedicated cells in such a way that at most one node communicates with a specific neighbor in each slotOffset/channelOffset cell. Multiple pairs of neighbor nodes can exchange data at the same time, but on different frequencies. 🫶

B.2. Multi-Channel vs. Channel Hopping

A TSCH schedule looks like a matrix of width "slotframe size", S, and of height "number of frequencies", nFreq. For a scheduling algorithm, cells can be considered atomic "units" to schedule. In particular, because of the channel hopping nature of TSCH, the scheduling algorithm should not worry about the actual frequency communication happens on, since it changes at each slotframe iteration. 🦋

B.3. Cost of (Continuous) Synchronization

okay so when nodes are actively chatting, they quietly resync off the data frames they swap 🫶. But if there's no data traffic, nodes are required to sync up with their time source neighbor(s) every so often so they don't drift apart in time ⏰. If they haven't talked in a while (typically 30 s), they can send a dummy data frame to resync. How often that needs to happen depends on how stable the clock source is and how "early" each node starts listening for data (the "guard time") 🧚. Theoretically, with a 10 ppm clock and a 1 ms guard time, the period can be 100 s. Assuming this exchange keeps the radio on for 5 ms, the radio duty cycle needed to stay synced comes out to 5 ms / 100 s = 0.005%. So yes, TSCH does require nodes to resynchronize periodically, but the cost of doing so is literally tiny 💅✨

B.4. Topology Stability

the channel hopping nature of TSCH makes links super "stable" 🦋 wireless stuff like multi-path fading and external interference hits a link between two nodes differently on each frequency. so if a transmission from node A to node B fails, retransmitting on a different frequency has a higher likelihood of succeeding than retransmitting on the same frequency 🤯 as a result, even when some frequencies are "behaving bad," channel hopping "smoothens" the contribution of each frequency. that means more stable links and therefore a more stable topology 👑

B.5. Multiple Concurrent Slotframes

the TSCH standard lets multiple slotframes coexist in a node's schedule 🌈 so it's possible that, at some timeslot, a node has multiple activities scheduled (e.g., transmit to node B on slotframe 2, receive from node C on slotframe 1). to handle that, the TSCH standard defines these precedence rules:

Transmissions take precedence over receptions;
Lower slotframe identifiers take precedence over higher slotframe identifiers.

so in the example above, the node would transmit to node B on slotframe 2. no notes, just vibes 💅

Acknowledgments

Special thanks to Dominique Barthel, Patricia Brett, Guillaume Gaillard, Pat Kinney, Ines Robles, Timothy J. Salo, Jonathan Simon, Rene Struik, and Xavi Vilajosana for reviewing the document and providing valuable feedback 🫶💖 Thanks also to the IoT6 European Project (STREP) of the 7th Framework Program (Grant 288445) 🌸

Authors' Addresses

the squad behind this one 👑 (contact details exactly as published):

Thomas Watteyne (editor)
Linear Technology
32990 Alvarado-Niles Road, Suite 910
Union City, CA  94587
United States

Phone: +1 (510) 400-2978
EMail: twatteyne@linear.com


Maria Rita Palattella
University of Luxembourg
Interdisciplinary Centre for Security, Reliability and Trust
4, rue Alphonse Weicker
Luxembourg  L-2721
Luxembourg

Phone: +352 46 66 44 5841
EMail: maria-rita.palattella@uni.lu


Luigi Alfredo Grieco
Politecnico di Bari
Department of Electrical and Information Engineering
Via Orabona 4
Bari  70125
Italy

Phone: +39 08 05 96 3911
EMail: a.grieco@poliba.it

📦 where this page comes from

ietf: rfc7554 2015-05
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms