idnits 2.17.1
draft-ietf-6tisch-tsch-05.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document doesn't use any RFC 2119 keywords, yet seems to have RFC
2119 boilerplate text.
-- The document date (January 8, 2015) is 3395 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Missing Reference: 'IEEE802154e' is mentioned on line 532, but not
defined
== Missing Reference: 'IEEE802154' is mentioned on line 538, but not defined
== Missing Reference: 'CurrentCalculator' is mentioned on line 557, but not
defined
== Missing Reference: 'OpenWSN' is mentioned on line 544, but not defined
== Missing Reference: 'OpenWSNETT' is mentioned on line 547, but not defined
== Missing Reference: 'IPSO' is mentioned on line 554, but not defined
== Missing Reference: 'TASA-PIMRC' is mentioned on line 585, but not defined
-- Obsolete informational reference (is this intentional?): RFC 2460
(Obsoleted by RFC 8200)
== Outdated reference: A later version (-10) exists of
draft-ietf-6tisch-terminology-02
== Outdated reference: A later version (-04) exists of
draft-wang-6tisch-6top-sublayer-01
Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 6TiSCH T. Watteyne, Ed.
3 Internet-Draft Linear Technology
4 Intended status: Informational MR. Palattella
5 Expires: July 12, 2015 University of Luxembourg
6 LA. Grieco
7 Politecnico di Bari
8 January 8, 2015
10 Using IEEE802.15.4e TSCH in an IoT context:
11 Overview, Problem Statement and Goals
12 draft-ietf-6tisch-tsch-05
14 Abstract
16 This document describes the environment, problem statement, and goals
17 for using the IEEE802.15.4e TSCH MAC protocol in the context of LLNs.
18 The set of goals enumerated in this document form an initial set
19 only.
21 Status of This Memo
23 This Internet-Draft is submitted in full conformance with the
24 provisions of BCP 78 and BCP 79.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF). Note that other groups may also distribute
28 working documents as Internet-Drafts. The list of current Internet-
29 Drafts is at http://datatracker.ietf.org/drafts/current/.
31 Internet-Drafts are draft documents valid for a maximum of six months
32 and may be updated, replaced, or obsoleted by other documents at any
33 time. It is inappropriate to use Internet-Drafts as reference
34 material or to cite them other than as "work in progress."
36 This Internet-Draft will expire on July 12, 2015.
38 Copyright Notice
40 Copyright (c) 2015 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents
45 (http://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document. Code Components extracted from this document must
49 include Simplified BSD License text as described in Section 4.e of
50 the Trust Legal Provisions and are provided without warranty as
51 described in the Simplified BSD License.
53 Table of Contents
55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
57 3. TSCH in the LLN Context . . . . . . . . . . . . . . . . . . . 4
58 4. Problems and Goals . . . . . . . . . . . . . . . . . . . . . 6
59 4.1. Network Formation . . . . . . . . . . . . . . . . . . . . 7
60 4.2. Network Maintenance . . . . . . . . . . . . . . . . . . . 7
61 4.3. Multi-Hop Topology . . . . . . . . . . . . . . . . . . . 7
62 4.4. Routing and Timing Parents . . . . . . . . . . . . . . . 8
63 4.5. Resource Management . . . . . . . . . . . . . . . . . . . 8
64 4.6. Dataflow Control . . . . . . . . . . . . . . . . . . . . 8
65 4.7. Deterministic Behavior . . . . . . . . . . . . . . . . . 8
66 4.8. Scheduling Mechanisms . . . . . . . . . . . . . . . . . . 9
67 4.9. Secure Communication . . . . . . . . . . . . . . . . . . 9
68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
70 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
72 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
73 8.2. Informative References . . . . . . . . . . . . . . . . . 10
74 8.3. External Informative References . . . . . . . . . . . . . 12
75 Appendix A. TSCH Protocol Highlights . . . . . . . . . . . . . . 13
76 A.1. Timeslots . . . . . . . . . . . . . . . . . . . . . . . . 13
77 A.2. Slotframes . . . . . . . . . . . . . . . . . . . . . . . 14
78 A.3. Node TSCH Schedule . . . . . . . . . . . . . . . . . . . 14
79 A.4. Cells and Bundles . . . . . . . . . . . . . . . . . . . . 14
80 A.5. Dedicated vs. Shared Cells . . . . . . . . . . . . . . . 15
81 A.6. Absolute Slot Number . . . . . . . . . . . . . . . . . . 15
82 A.7. Channel Hopping . . . . . . . . . . . . . . . . . . . . . 16
83 A.8. Time Synchronization . . . . . . . . . . . . . . . . . . 16
84 A.9. Power Consumption . . . . . . . . . . . . . . . . . . . . 17
85 A.10. Network TSCH Schedule . . . . . . . . . . . . . . . . . . 17
86 A.11. Join Process . . . . . . . . . . . . . . . . . . . . . . 18
87 A.12. Information Elements . . . . . . . . . . . . . . . . . . 18
88 A.13. Extensibility . . . . . . . . . . . . . . . . . . . . . . 18
89 Appendix B. TSCH Gotchas . . . . . . . . . . . . . . . . . . . . 19
90 B.1. Collision Free Communication . . . . . . . . . . . . . . 19
91 B.2. Multi-Channel vs. Channel Hopping . . . . . . . . . . . . 19
92 B.3. Cost of (continuous) Synchronization . . . . . . . . . . 19
93 B.4. Topology Stability . . . . . . . . . . . . . . . . . . . 20
94 B.5. Multiple Concurrent Slotframes . . . . . . . . . . . . . 20
95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
97 1. Introduction
99 IEEE802.15.4e [IEEE802154e] was published in 2012 as an amendment to
100 the Medium Access Control (MAC) protocol defined by the
101 IEEE802.15.4-2011 [IEEE802154] standard. IEEE802.15.4e will be
102 rolled into the next revision of IEEE802.15.4, scheduled to be
103 published in 2015. The Timeslotted Channel Hopping (TSCH) mode of
104 IEEE802.15.4e is the object of this document.
106 This document describes the main issues arising from the adoption of
107 the IEEE802.15.4e TSCH in the LLN context, following the terminology
108 defined in [I-D.ietf-6tisch-terminology].
110 TSCH was designed to allow IEEE802.15.4 devices to support a wide
111 range of applications including, but not limited to, industrial ones
112 [IEEE802154e]. At its core is a medium access technique which uses
113 time synchronization to achieve ultra low-power operation and channel
114 hopping to enable high reliability. Synchronization accuracy impacts
115 power consumption, and can vary from micro-seconds to milli-seconds
116 depending on the solution. This is very different from the "legacy"
117 IEEE802.15.4 MAC protocol, and is therefore better described as a
118 "redesign". TSCH does not amend the physical layer; i.e., it can
119 operate on any IEEE802.15.4-compliant hardware.
121 IEEE802.15.4e is the latest generation of ultra-lower power and
122 reliable networking solutions for LLNs. [RFC5673] discusses
123 industrial applications, and highlights the harsh operating
124 conditions as well as the stringent reliability, availability, and
125 security requirements for an LLN to operate in an industrial
126 environment. In these environments, vast deployment environments
127 with large (metallic) equipment cause multi-path fading and
128 interference to thwart any attempt of a single-channel solution to be
129 reliable; the channel agility of TSCH is the key to its ultra high
130 reliability. Commercial networking solutions are available today in
131 which nodes consume 10's of micro-amps on average [CurrentCalculator]
132 with end-to-end packet delivery ratios over 99.999%
133 [doherty07channel].
135 IEEE802.15.4e has been designed for low-power constrained devices,
136 often called "motes". Several terms are used in the IETF to refer to
137 those devices, including "LLN nodes" [RFC7102] and "constrained
138 nodes" [RFC7228]. In this document, we use the generic (and shorter)
139 term "node", used as a synonym for "LLN node", "constrained node" or
140 "mote".
142 Bringing industrial-like performance into the LLN stack developed by
143 Internet of Things (IoT) related IETF working groups such as 6Lo,
144 ROLL and CoRE opens up new application domains for these networks.
146 Sensors deployed in smart cities [RFC5548] will be able to be
147 installed for years without needing battery replacement. "Umbrella"
148 networks will interconnect smart elements from different entities in
149 smart buildings [RFC5867]. Peel-and-stick switches will obsolete the
150 need for costly conduits for lighting solutions in smart homes
151 [RFC5826].
153 IEEE802.15.4e TSCH focuses on the MAC layer only. This clean
154 layering allows for TSCH to fit under an IPv6 enabled protocol stack
155 for LLNs, running 6LoWPAN [RFC6282], IPv6 Routing Protocol for Low
156 power and Lossy Networks (RPL) [RFC6550] and the Constrained
157 Application Protocol (CoAP) [RFC7252]. What is missing is a Logical
158 Link Control (LLC) layer between the IP abstraction of a link and the
159 TSCH MAC, which is in charge of scheduling a timeslot for a given
160 packet coming down the stack from the upper layer.
162 While [IEEE802154e] defines the mechanisms for a TSCH node to
163 communicate, it does not define the policies to build and maintain
164 the communication schedule, match that schedule to the multi-hop
165 paths maintained by RPL, adapt the resources allocated between
166 neighbor nodes to the data traffic flows, enforce a differentiated
167 treatment for data generated at the application layer and signaling
168 messages needed by 6LoWPAN and RPL to discover neighbors, react to
169 topology changes, self-configure IP addresses, or manage keying
170 material.
172 In other words, IEEE802.15.4e TSCH is designed to allow optimizations
173 and strong customizations, simplifying the merging of TSCH with a
174 protocol stack based on IPv6, 6LoWPAN, and RPL.
176 2. Requirements Language
178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
180 document are to be interpreted as described in RFC 2119 [RFC2119].
182 3. TSCH in the LLN Context
184 To map the services required by the IP layer to the services provided
185 by the link layer, an adaptation layer is used
186 [palattella12standardized]. The 6LoWPAN working group started
187 working in 2007 on specifications for transmitting IPv6 packets over
188 IEEE802.15.4 networks [RFC4919]. Low-power WPANs are characterized
189 by small packet sizes, support for addresses with different lengths,
190 low bandwidth, star and mesh topologies, battery powered devices, low
191 cost, large number of devices, unknown node positions, high
192 unreliability, and periods during which communication interfaces are
193 turned off to save energy. Given these features, it is clear that
194 the adoption of IPv6 on top of a Low-Power WPAN is not
195 straightforward, but poses strong requirements for the optimization
196 of this adaptation layer.
198 For instance, due to the IPv6 default minimum MTU size (1280 bytes),
199 an un-fragmented IPv6 packet is too large to fit in an IEEE802.15.4
200 frame. Moreover, the overhead due to the 40-byte long IPv6 header
201 wastes the scarce bandwidth available at the PHY layer [RFC4944].
202 For these reasons, the 6LoWPAN working group has defined an effective
203 adaptation layer [RFC6282]. Further issues encompass the auto-
204 configuration of IPv6 addresses [RFC2460][RFC4862], the compliance
205 with the recommendation on supporting link-layer subnet broadcast in
206 shared networks [RFC3819], the reduction of routing and management
207 overhead [RFC6606], the adoption of lightweight application protocols
208 (or novel data encoding techniques), and the support for security
209 mechanisms (confidentiality and integrity protection, device
210 bootstrapping, key establishment, and management).
212 These features can run on top of TSCH. There are, however, important
213 issues to solve, as highlighted in Section 4.
215 Routing issues are challenging for 6LoWPAN, given the low-power and
216 lossy radio links, the battery-powered nodes, the multi-hop mesh
217 topologies, and the frequent topology changes due to mobility.
218 Successful solutions take into account the specific application
219 requirements, along with IPv6 behavior and 6LoWPAN mechanisms
220 [palattella12standardized]. The ROLL working group has defined RPL
221 in [RFC6550]. RPL can support a wide variety of link layers,
222 including ones that are constrained, potentially lossy, or typically
223 utilized in conjunction with host or router devices with very limited
224 resources, as in building/home automation [RFC5867][RFC5826],
225 industrial environments [RFC5673], and urban applications [RFC5548].
226 RPL is able to quickly build up network routes, distribute routing
227 knowledge among nodes, and adapt to a changing topology. In a
228 typical setting, nodes are connected through multi-hop paths to a
229 small set of root devices, which are usually responsible for data
230 collection and coordination. For each of them, a Destination
231 Oriented Directed Acyclic Graph (DODAG) is created by accounting for
232 link costs, node attributes/status information, and an Objective
233 Function, which maps the optimization requirements of the target
234 scenario.
236 The topology is set up based on a Rank metric, which encodes the
237 distance of each node with respect to its reference root, as
238 specified by the Objective Function. Regardless of the way it is
239 computed, the Rank monotonically decreases along the DODAG towards
240 the root, building a gradient. RPL encompasses different kinds of
241 traffic and signaling information. Multipoint-to-Point (MP2P) is the
242 dominant traffic in LLN applications. Data is routed towards nodes
243 with some application relevance, such as the LLN gateway to the
244 larger Internet, or to the core of private IP networks. In general,
245 these destinations are the DODAG roots and act as data collection
246 points for distributed monitoring applications. Point-to-Multipoint
247 (P2MP) data streams are used for actuation purposes, where messages
248 are sent from DODAG roots to destination nodes. Point-to-Point (P2P)
249 traffic allows communication between two devices belonging to the
250 same LLN, such as a sensor and an actuator. A packet flows from the
251 source to the common ancestor of those two communicating devices,
252 then downward towards the destination. RPL therefore has to discover
253 both upward routes (i.e. from nodes to DODAG roots) in order to
254 enable MP2P and P2P flows, and downward routes (i.e. from DODAG roots
255 to nodes) to support P2MP and P2P traffic.
257 Section 4 highlights the challenges that need to be addressed to use
258 RPL on top of TSCH.
260 Several open-source initiatives have emerged around TSCH. The
261 OpenWSN project [OpenWSN][OpenWSNETT] is an open-source
262 implementation of a standards-based protocol stack, which aims at
263 evaluating the applicability of TSCH to different applications. This
264 implementation was used as the foundation for an IP for Smart Objects
265 Alliance (IPSO) [IPSO] interoperability event in 2011. In the
266 absence of a standardized scheduling mechanism for TSCH, a "slotted
267 Aloha" schedule was used.
269 4. Problems and Goals
271 As highlighted in Appendix A, TSCH differs from traditional low-power
272 MAC protocols because of its scheduled nature. TSCH defines the
273 mechanisms to execute a communication schedule, yet it is the entity
274 that sets up that schedule which controls the topology of the
275 network. This scheduling entity also controls the resources
276 allocated to each link in that topology.
278 How this entity should operate is out of scope of TSCH. The
279 remainder of this section highlights the problems this entity needs
280 to address. For simplicity, we refer to this entity by the generic
281 name "LLC". Note that the 6top sublayer, currently being defined in
282 [I-D.wang-6tisch-6top-sublayer], can be seen as an embodiment of this
283 generic "LLC".
285 Some of the issues the LLC needs to target might overlap with the
286 scope of other protocols (e.g., 6LoWPAN, RPL, and RSVP). In this
287 case, it is entailed that the LLC will profit from the services
288 provided by other protocols to pursue these objectives.
290 4.1. Network Formation
292 The LLC needs to control the way the network is formed, including how
293 new nodes join, and how already joined nodes advertise the presence
294 of the network. The LLC needs to:
296 1. Define the Information Elements included in the Enhanced Beacons
297 advertising the presence of the network.
299 2. For a new node, define rules to process and filter received
300 Enhanced Beacons.
302 3. Define the joining procedure. This might include a mechanism to
303 assign a unique 16-bit address to a node, and the management of
304 initial keying material.
306 4. Define a mechanism to secure the joining process and the
307 subsequent optional process of scheduling more communication
308 cells.
310 4.2. Network Maintenance
312 Once a network is formed, the LLC needs to maintain the network's
313 health, allowing for nodes to stay synchronized. The LLC needs to:
315 1. Manage each node's time source neighbor.
317 2. Define a mechanism for a node to update the join priority it
318 announces in its Enhanced Beacon.
320 3. Schedule transmissions of Enhanced Beacons to advertise the
321 presence of the network.
323 4.3. Multi-Hop Topology
325 RPL, given a weighted connectivity graph, determines multi-hop
326 routes. The LLC needs to:
328 1. Define a mechanism to gather topological information, node and
329 link state, which it can then feed to RPL.
331 2. Ensure that the TSCH schedule contains cells along the multi-hop
332 routes identified by RPL.
334 3. Where applicable, maintain independent sets of cells to transport
335 independent flows of data.
337 4.4. Routing and Timing Parents
339 At all times, a TSCH node needs to have a time source neighbor it can
340 synchronize to. The LLC therefore needs to assign a time source
341 neighbor to allow for correct operation of the TSCH network. A time
342 source neighbors could, or not, be taken from the RPL routing parent
343 set.
345 4.5. Resource Management
347 A cell in a TSCH schedule is an atomic "unit" of resource. The
348 number of cells to assign between neighbor nodes needs to be
349 appropriate for the size of the traffic flow. The LLC needs to:
351 1. Define a mechanism for neighbor nodes to exchange information
352 about their schedule and, if applicable, negotiate the addition/
353 deletion of cells.
355 2. Allow for an entity (e.g., a set of devices, a distributed
356 protocol, a PCE, etc.) to take control of the schedule.
358 4.6. Dataflow Control
360 TSCH defines mechanisms for a node to signal it cannot accept an
361 incoming packet. It does not, however, define the policy which
362 determines when to stop accepting packets. The LLC needs to:
364 1. Define a queuing policy for incoming and outgoing packets.
366 2. Manage the buffer space, and indicate to TSCH when to stop
367 accepting incoming packets.
369 3. Handle transmissions that have failed. A transmission is
370 declared failed when TSCH has retransmitted the packet multiple
371 times, without receiving an acknowledgment. This covers both
372 dedicated and shared cells.
374 4.7. Deterministic Behavior
376 As highlighted in [RFC5673], in some applications, data is generated
377 periodically and has a well understood data bandwidth requirement,
378 which is deterministic and predictable. The LLC needs to:
380 1. Ensure timely delivery of such data.
382 2. Provide a mechanism for such deterministic flows to coexist with
383 bursty or infrequent traffic flows of different priorities.
385 4.8. Scheduling Mechanisms
387 Several scheduling mechanisms can be envisioned, and possibly coexist
388 in the same network. For example,
389 [I-D.phinney-roll-rpl-industrial-applicability] describes how the
390 allocation of bandwidth can be optimized by an external Path
391 Computation Element (PCE). Another centralized (PCE-based) traffic-
392 aware scheduling algorithm is defined in [TASA-PIMRC].
393 Alternatively, two neighbor nodes can adapt the number of cells
394 autonomously by monitoring the amount of traffic, and negotiating the
395 allocation to extra cell when needed. An example of decentralized
396 algorithm is provided in [tinka10decentralized]. This mechanism can
397 be used to establish multi-hop paths in a fashion similar to RSVP.
398 The LLC needs to:
400 1. Provide a mechanism for two 6TiSCH devices to negotiate the
401 allocation and deallocation of cells between them.
403 2. Provide a mechanism for device to monitor and manage the 6TiSCH
404 capabilities of a node several hops away.
406 3. Define an mechanism for these different scheduling mechanisms to
407 coexist in the same network.
409 4.9. Secure Communication
411 Given some keying material, TSCH defines mechanisms to encrypt and
412 authenticate MAC frames. It does not define how this keying material
413 is generated. The LLC needs to:
415 1. Define the keying material and authentication mechanism needed by
416 a new node to join an existing network.
418 2. Define a mechanism to allow for the secure transfer of
419 application data between neighbor nodes.
421 3. Define a mechanism to allow for the secure transfer of signaling
422 data between nodes and the LLC.
424 5. IANA Considerations
426 This memo includes no request to IANA.
428 6. Security Considerations
430 This memo is an informational overview of existing standards, and
431 does define any new mechanisms or protocols.
433 It does describe the need for the 6TiSCH WG to define a secure
434 solution. In particular, Section 4.1 describes security in the join
435 process. Section 4.9 discusses data frame protection.
437 7. Acknowledgments
439 Special thanks to Dominique Barthel, Patricia Brett, Guillaume
440 Gaillard, Pat Kinney, Ines Robles, Timothy J. Salo, Jonathan Simon,
441 Rene Struik, Xavi Vilajosana for reviewing the document and providing
442 valuable feedback. Thanks to the IoT6 European Project (STREP) of
443 the 7th Framework Program (Grant 288445).
445 8. References
447 8.1. Normative References
449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
450 Requirement Levels", BCP 14, RFC 2119, March 1997.
452 8.2. Informative References
454 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
455 Application Protocol (CoAP)", RFC 7252, June 2014.
457 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
458 Constrained-Node Networks", RFC 7228, May 2014.
460 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
461 Lossy Networks", RFC 7102, January 2014.
463 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
464 Statement and Requirements for IPv6 over Low-Power
465 Wireless Personal Area Network (6LoWPAN) Routing", RFC
466 6606, May 2012.
468 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
469 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
470 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
471 Lossy Networks", RFC 6550, March 2012.
473 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
474 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
475 September 2011.
477 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
478 "Building Automation Routing Requirements in Low-Power and
479 Lossy Networks", RFC 5867, June 2010.
481 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
482 Routing Requirements in Low-Power and Lossy Networks", RFC
483 5826, April 2010.
485 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney,
486 "Industrial Routing Requirements in Low-Power and Lossy
487 Networks", RFC 5673, October 2009.
489 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
490 "Routing Requirements for Urban Low-Power and Lossy
491 Networks", RFC 5548, May 2009.
493 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
494 "Transmission of IPv6 Packets over IEEE 802.15.4
495 Networks", RFC 4944, September 2007.
497 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
498 over Low-Power Wireless Personal Area Networks (6LoWPANs):
499 Overview, Assumptions, Problem Statement, and Goals", RFC
500 4919, August 2007.
502 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
503 Address Autoconfiguration", RFC 4862, September 2007.
505 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
506 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
507 Wood, "Advice for Internet Subnetwork Designers", BCP 89,
508 RFC 3819, July 2004.
510 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
511 (IPv6) Specification", RFC 2460, December 1998.
513 [I-D.ietf-6tisch-terminology]
514 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
515 "Terminology in IPv6 over the TSCH mode of IEEE
516 802.15.4e", draft-ietf-6tisch-terminology-02 (work in
517 progress), July 2014.
519 [I-D.wang-6tisch-6top-sublayer]
520 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
521 Operation Sublayer (6top)", draft-wang-6tisch-6top-
522 sublayer-01 (work in progress), July 2014.
524 [I-D.phinney-roll-rpl-industrial-applicability]
525 Phinney, T., Thubert, P., and R. Assimiti, "RPL
526 applicability in industrial networks", draft-phinney-roll-
527 rpl-industrial-applicability-02 (work in progress),
528 February 2013.
530 8.3. External Informative References
532 [IEEE802154e]
533 IEEE standard for Information Technology, "IEEE std.
534 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
535 Networks (LR-WPANs) Amendment 1: MAC sublayer", April
536 2012.
538 [IEEE802154]
539 IEEE standard for Information Technology, "IEEE std.
540 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
541 and Physical Layer (PHY) Specifications for Low-Rate
542 Wireless Personal Area Networks", June 2011.
544 [OpenWSN] "Berkeley's OpenWSN Project Homepage",
545 .
547 [OpenWSNETT]
548 Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F.,
549 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN:
550 a Standards-Based Low-Power Wireless Development
551 Environment", Transactions on Emerging Telecommunications
552 Technologies , August 2012.
554 [IPSO] "IP for Smart Objects Alliance Homepage",
555 .
557 [CurrentCalculator]
558 Linear Technology, "Application Note: Using the Current
559 Calculator to Estimate Mote Power", August 2012,
560 .
564 [doherty07channel]
565 Doherty, L., Lindsay, W., and J. Simon, "Channel-Specific
566 Wireless Sensor Network Path Data", IEEE International
567 Conference on Computer Communications and Networks (ICCCN)
568 2008, 2007.
570 [tinka10decentralized]
571 Tinka, A., Watteyne, T., and K. Pister, "A Decentralized
572 Scheduling Algorithm for Time Synchronized Channel
573 Hopping", Ad Hoc Networks 2010, 2010, <
574 http://robotics.eecs.berkeley.edu/~pister/
575 publications/2008/TSMP%20DSN08.pdf>.
577 [watteyne09reliability]
578 Watteyne, T., Mehta, A., and K. Pister, "Reliability
579 Through Frequency Diversity: Why Channel Hopping Makes
580 Sense", International Conference on Performance Evaluation
581 of Wireless Ad Hoc, Sensor, and Ubiquitous Networks (PE-
582 WASUN) 2009, Oct. 2009, .
585 [TASA-PIMRC]
586 Palattella, MR., Accettura, N., Dohler, M., Grieco, LA.,
587 and G. Boggia, "Traffic Aware Scheduling Algorithm for
588 Multi-Hop IEEE 802.15.4e Networks", IEEE PIMRC 2012, Sept.
589 2012, < http://www.cttc.es/resources/
590 doc/120531-submitted-tasa-25511.pdf>.
592 [palattella12standardized]
593 Palattella, MR., Accettura, N., Vilajosana, X., Watteyne,
594 T., Grieco, LA., Boggia, G., and M. Dohler, "Standardized
595 Protocol Stack For The Internet Of (Important) Things",
596 IEEE Communications Surveys and Tutorials 2012, Dec. 2012,
597 < http://www.cttc.es/resources/doc/121025-
598 completestackforiot-clean-4818610916636121981.pdf>.
600 Appendix A. TSCH Protocol Highlights
602 This appendix gives an overview of the key features of the
603 IEEE802.15.4e Timeslotted Channel Hopping (TSCH) amendment. It makes
604 no attempt at repeating the standard, but rather focuses on the
605 following:
607 o Concepts which are sufficiently different from traditional
608 IEEE802.15.4 networking that they may need to be defined and
609 presented precisely.
611 o Techniques and ideas which are part of IEEE802.15.4e and which
612 might be useful for the work of the 6TiSCH WG.
614 A.1. Timeslots
616 All nodes in a TSCH network are synchronized. Time is sliced up into
617 timeslots. A timeslot is long enough for a MAC frame of maximum size
618 to be sent from node A to node B, and for node B to reply with an
619 acknowledgment (ACK) frame indicating successful reception.
621 The duration of a timeslot is not defined by the standard. With
622 IEEE802.15.4-compliant radios operating in the 2.4GHz frequency band,
623 a maximum-length frame of 127 bytes takes about 4ms to transmit; a
624 shorter ACK takes about 1ms. With a 10ms slot (a typical duration),
625 this leaves 5ms to radio turnaround, packet processing and security
626 operations.
628 A.2. Slotframes
630 Timeslots are grouped into one of more slotframes. A slotframe
631 continuously repeats over time. TSCH does not impose a slotframe
632 size. Depending on the application needs, these can range from 10s
633 to 1000s of timeslots. The shorter the slotframe, the more often a
634 timeslot repeats, resulting in more available bandwidth, but also in
635 a higher power consumption.
637 A.3. Node TSCH Schedule
639 A TSCH schedule instructs each node what to do in each timeslot:
640 transmit, receive or sleep. The schedule indicates, for each
641 scheduled (transmit or receive) cell, a channelOffset and the address
642 of the neighbor to communicate with.
644 Once a node obtains its schedule, it executes it:
646 o For each transmit cell, the node checks whether there is a packet
647 in the outgoing buffer which matches the neighbor written in the
648 schedule information for that timeslot. If there is none, the
649 node keeps its radio off for the duration of the timeslot. If
650 there is one, the node can ask for the neighbor to acknowledge it,
651 in which case it has to listen for the acknowledgment after
652 transmitting.
654 o For each receive cell, the node listens for possible incoming
655 packets. If none is received after some listening period, it
656 shuts down its radio. If a packet is received, addressed to the
657 node, and passes security checks, the node can send back an
658 acknowledgment.
660 How the schedule is built, updated and maintained, and by which
661 entity, is outside of the scope of the IEEE802.15.4e standard.
663 A.4. Cells and Bundles
665 Assuming the schedule is well built, if node A is scheduled to
666 transmit to node B at slotOffset 5 and channelOffset 11, node B will
667 be scheduled to receive from node A at the same slotOffset and
668 channelOffset.
670 A single element of the schedule characterized by a slotOffset and
671 channelOffset, and reserved for node A to transmit to node B (or for
672 node B to receive from node A) within a given slotframe, is called a
673 "scheduled cell".
675 If there is a lot of data flowing from node A to node B, the schedule
676 might contain multiple cells from A to B, at different times.
677 Multiple cells scheduled to the same neighbor can be equivalent, i.e.
678 the MAC layer sends the packet on whichever of these cells shows up
679 first after the packet was put in the MAC queue. The union of all
680 cells between two neighbors, A and B, is called a "bundle". Since
681 the slotframe repeats over time (and the length of the slotframe is
682 typically constant), each cell gives a "quantum" of bandwidth to a
683 given neighbor. Modifying the number of equivalent cells in a bundle
684 modifies the amount of resources allocated between two neighbors.
686 A.5. Dedicated vs. Shared Cells
688 By default, each scheduled transmit cell within the TSCH schedule is
689 dedicated, i.e., reserved only for node A to transmit to node B.
690 IEEE802.15.4e allows also to mark a cell as shared. In a shared
691 cell, multiple nodes can transmit at the same time, on the same
692 frequency. To avoid contention, TSCH defines a back-off algorithm
693 for shared cells.
695 A scheduled cell can be marked as both transmitting and receiving.
696 In this case, a node transmits if it has an appropriate packet in its
697 output buffer, or listens otherwise. Marking a cell as
698 [transmit,receive,shared] results in slotted-Aloha behavior.
700 A.6. Absolute Slot Number
702 TSCH defines a timeslot counter called Absolute Slot Number (ASN).
703 When a new network is created, the ASN is initialized to 0; from then
704 on, it increments by 1 at each timeslot. In detail:
706 ASN = (k*S+t)
708 where k is the slotframe cycle (i.e., the number of slotframe
709 repetitions since the network was started), S the slotframe size and
710 t the slotOffset. A node learns the current ASN when it joins the
711 network. Since nodes are synchronized, they all know the current
712 value of the ASN, at any time. The ASN is encoded as a 5-byte
713 number: this allows it to increment for hundreds of years (the exact
714 value depends on the duration of a timeslot) without wrapping over.
715 The ASN is used to calculate the frequency to communicate on, and can
716 be used for security-related operations.
718 A.7. Channel Hopping
720 For each scheduled cell, the schedule specifies a slotOffset and a
721 channelOffset. In a well-built schedule, when node A has a transmit
722 cell to node B on channelOffset 5, node B has a receive cell from
723 node A on the same channelOffset. The channelOffset is translated by
724 both nodes into a frequency using the following function:
726 frequency = F {(ASN + channelOffset) mod nFreq}
728 The function F consists of a look-up table containing the set of
729 available channels. The value nFreq (the number of available
730 frequencies) is the size of this look-up table. There are as many
731 channelOffset values as there are frequencies available (e.g. 16 when
732 using IEEE802.15.4-compliant radios at 2.4GHz, when all channels are
733 used). Since both nodes have the same channelOffset written in their
734 schedule for that scheduled cell, and the same ASN counter, they
735 compute the same frequency. At the next iteration (cycle) of the
736 slotframe, however, while the channelOffset is the same, the ASN has
737 changed, resulting in the computation of a different frequency.
739 This results in "channel hopping": even with a static schedule, pairs
740 of neighbors "hop" between the different frequencies when
741 communicating. A way of ensuring communication happens on all
742 available frequencies is to set the number of timeslots in a
743 slotframe to a prime number. Channel hopping is a technique known to
744 efficiently combat multi-path fading and external interference
745 [watteyne09reliability].
747 A.8. Time Synchronization
749 Because of the slotted nature of communication in a TSCH network,
750 nodes have to maintain tight synchronization. All nodes are assumed
751 to be equipped with clocks to keep track of time. Yet, because
752 clocks in different nodes drift with respect to one another, neighbor
753 nodes need to periodically re-synchronize.
755 Each node needs to periodically synchronize its network clock to
756 another node, and it also provides its network time to its neighbors.
757 It is up to the entity that manages the schedule to assign an
758 adequate time source neighbor to each node, i.e., to indicate in the
759 schedule which of neighbor is its "time source neighbor". While
760 setting the time source neighbor, it is important to avoid
761 synchronization loops, which could result in the formation of
762 independent clusters of synchronized nodes.
764 TSCH adds timing information in all packets that are exchanged (both
765 data and ACK frames). This means that neighbor nodes can
766 resynchronize to one another whenever they exchange data. In detail,
767 two methods are defined in IEEE802.15.4e-2012 for allowing a device
768 to synchronize in a TSCH network: (i) Acknowledgment-Based and (ii)
769 Frame-Based synchronization. In both cases, the receiver calculates
770 the difference in time between the expected time of frame arrival and
771 its actual arrival. In Acknowledgment-Based synchronization, the
772 receiver provides such information to the sender node in its
773 acknowledgment. In this case, it is the sender node that
774 synchronizes to the clock of the receiver. In Frame-Based
775 synchronization, the receiver uses the computed delta for adjusting
776 its own clock. In this case, it is the receiver node that
777 synchronizes to the clock of the sender.
779 Different synchronization policies are possible. Nodes can keep
780 synchronization exclusively by exchanging EBs. Nodes can also keep
781 synchronized by periodically sending valid frames to a time source
782 neighbor and use the acknowledgment to resynchronize. Both method
783 (or a combination thereof) are valid synchronization policies; which
784 one to use depends on network requirements.
786 A.9. Power Consumption
788 There are only a handful of activities a node can perform during a
789 timeslot: transmit, receive, or sleep. Each of these operations has
790 some energy cost associated to them, the exact value depends on the
791 the hardware used. Given the schedule of a node, it is
792 straightforward to calculate the expected average power consumption
793 of that node.
795 A.10. Network TSCH Schedule
797 The schedule entirely defines the synchronization and communication
798 between nodes. By adding/removing cells between neighbors, one can
799 adapt a schedule to the needs of the application. Intuitive examples
800 are:
802 o Make the schedule "sparse" for applications where nodes need to
803 consume as little energy as possible, at the price of reduced
804 bandwidth.
806 o Make the schedule "dense" for applications where nodes generate a
807 lot of data, at the price of increased power consumption.
809 o Add more cells along a multi-hop route over which many packets
810 flow.
812 A.11. Join Process
814 Nodes already part of the network can periodically send Enhanced
815 Beacon (EB) frames to announce the presence of the network. These
816 contain information about the size of the timeslot used in the
817 network, the current ASN, information about the slotframes and
818 timeslots the beaconing node is listening on, and a 1-byte join
819 priority. The join priority field gives information to make a better
820 decision of which node to join. Even if a node is configured to send
821 all EB frames on the same channel offset, because of the channel
822 hopping nature of TSCH described in Appendix A.7, this channel offset
823 translates into a different frequency at different slotframe cycles.
824 As a result, EB frames are sent on all frequencies.
826 A node wishing to join the network listens for EBs. Since EBs are
827 sent on all frequencies, the joining node can listen on any frequency
828 until it hears an EB. What frequency it listens on is
829 implementation-specific. Once it has received one or more EBs, the
830 new node enables the TSCH mode and uses the ASN and the other timing
831 information from the EB to synchronize to the network. Using the
832 slotframe and cell information from the EB, it knows how to contact
833 other nodes in the network.
835 The IEEE802.15.4e TSCH standard does not define the steps beyond this
836 network "bootstrap".
838 A.12. Information Elements
840 TSCH introduces the concept of Information Elements (IEs). An
841 information element is a list of Type-Length-Value containers placed
842 at the end of the MAC header. A small number of types are defined
843 for TSCH (e.g., the ASN in the EB is contained in an IE), and an
844 unmanaged range is available for extensions.
846 A data bit in the MAC header indicates whether the frame contains
847 IEs. IEs are grouped into Header IEs, consumed by the MAC layer and
848 therefore typically invisible to the next higher layer, and Payload
849 IEs, which are passed untouched to the next higher layer, possibly
850 followed by regular payload. Payload IEs can therefore be used for
851 the next higher layers of two neighbor nodes to exchange information.
853 A.13. Extensibility
855 The TSCH standard is designed to be extensible. It introduces the
856 mechanisms as "building block" (e.g., cells, bundles, slotframes,
857 etc.), but leaves entire freedom to the upper layer to assemble
858 those. The MAC protocol can be extended by defining new Header IEs.
860 An intermediate layer can be defined to manage the MAC layer by
861 defining new Payload IEs.
863 Appendix B. TSCH Gotchas
865 This section lists features of TSCH which we believe are important
866 and beneficial to the work of 6TiSCH.
868 B.1. Collision Free Communication
870 TSCH allows one to design a schedule which yields collision-free
871 communication. This is done by building the schedule with dedicated
872 cells in such a way that at most one node communicates with a
873 specific neighbor in each slotOffset/channelOffset cell. Multiple
874 pairs of neighbor nodes can exchange data at the same time, but on
875 different frequencies.
877 B.2. Multi-Channel vs. Channel Hopping
879 A TSCH schedule looks like a matrix of width "slotframe size", S, and
880 of height "number of frequencies", nFreq. For a scheduling
881 algorithm, cells can be considered atomic "units" to schedule. In
882 particular, because of the channel hopping nature of TSCH, the
883 scheduling algorithm should not worry about the actual frequency
884 communication happens on, since it changes at each slotframe
885 iteration.
887 B.3. Cost of (continuous) Synchronization
889 When there is traffic in the network, nodes which are communicating
890 implicitly re-synchronize using the data frames they exchange. In
891 the absence of data traffic, nodes are required to synchronize to
892 their time source neighbor(s) periodically not to drift in time. If
893 they have not been communicating for some time (typically 30s), nodes
894 can exchange an dummy data frame to re-synchronize. The frequency at
895 which such messages need to be transmitted depends on the stability
896 of the clock source, and on how "early" each node starts listening
897 for data (the "guard time"). Theoretically, with a 10ppm clock and a
898 1ms guard time, this period can be 100s. Assuming this exchange
899 causes the node's radio to be on for 5ms, this yields a radio duty
900 cycle needed to keep synchronized of 5ms/100s=0.005%. While TSCH does
901 requires nodes to resynchronize periodically, the cost of doing so is
902 very low.
904 B.4. Topology Stability
906 The channel hopping nature of TSCH causes links to be very "stable".
907 Wireless phenomena such as multi-path fading and external
908 interference impact a wireless link between two nodes differently on
909 each frequency. If a transmission from node A to node B fails,
910 retransmitting on a different frequency has a higher likelihood of
911 succeeding that retransmitting on the same frequency. As a result,
912 even when some frequencies are "behaving bad", channel hopping
913 "smoothens" the contribution of each frequency, resulting in more
914 stable links, and therefore a more stable topology.
916 B.5. Multiple Concurrent Slotframes
918 The TSCH standard allows for multiple slotframes to coexist in a
919 node's schedule. It is possible that, at some timeslot, a node has
920 multiple activities scheduled (e.g. transmit to node B on slotframe
921 2, receive from node C on slotframe 1). To handle this situation,
922 the TSCH standard defines the following precedence rules:
924 1. Transmissions take precedence over receptions;
926 2. Lower slotframe identifiers take precedence over higher slotframe
927 identifiers.
929 In the example above, the node would transmit to node B on slotframe
930 2.
932 Authors' Addresses
934 Thomas Watteyne (editor)
935 Linear Technology
936 32990 Alvarado-Niles Road, Suite 910
937 Union City, CA 94587
938 USA
940 Phone: +1 (510) 400-2978
941 Email: twatteyne@linear.com
942 Maria Rita Palattella
943 University of Luxembourg
944 Interdisciplinary Centre for Security, Reliability and Trust
945 4, rue Alphonse Weicker
946 Luxembourg L-2721
947 LUXEMBOURG
949 Phone: +352 46 66 44 5841
950 Email: maria-rita.palattella@uni.lu
952 Luigi Alfredo Grieco
953 Politecnico di Bari
954 Department of Electrical and Information Engineering
955 Via Orabona 4
956 Bari 70125
957 Italy
959 Phone: +39 08 05 96 3911
960 Email: a.grieco@poliba.it