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