idnits 2.17.1
draft-watteyne-6tsch-tsch-lln-context-01.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 :
----------------------------------------------------------------------------
** The document seems to lack a Security Considerations section.
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (February 21, 2013) is 4082 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Missing Reference: 'IEEE802154e' is mentioned on line 547, but not
defined
== Missing Reference: 'IEEE802154' is mentioned on line 553, but not defined
== Missing Reference: 'WHART' is mentioned on line 559, but not defined
== Missing Reference: 'ISA100' is mentioned on line 563, but not defined
== Missing Reference: 'Emerson' is mentioned on line 567, but not defined
== Missing Reference: 'CurrentCalculator' is mentioned on line 586, but not
defined
== Missing Reference: 'OpenWSN' is mentioned on line 572, but not defined
== Missing Reference: 'OpenWSNETT' is mentioned on line 575, but not defined
== Missing Reference: 'IPSO' is mentioned on line 583, but not defined
== Missing Reference: 'TSMP' is mentioned on line 599, but not defined
== Missing Reference: 'TASA-PIMRC' is mentioned on line 629, but not defined
== Missing Reference: 'TASA-SENSORS' is mentioned on line 636, but not
defined
== Missing Reference: 'TASA-WCNC' is mentioned on line 643, but not defined
== Missing Reference: 'PANA' is mentioned on line 658, but not defined
== Unused Reference: 'RFC2119' is defined on line 423, but no explicit
reference was found in the text
== Unused Reference: 'I-D.thubert-roll-forwarding-frags' is defined on line
483, but no explicit reference was found in the text
== Unused Reference: 'I-D.tsao-roll-security-framework' is defined on line
488, but no explicit reference was found in the text
== Unused Reference: 'I-D.thubert-roll-asymlink' is defined on line 494,
but no explicit reference was found in the text
== Unused Reference: 'I-D.ietf-roll-terminology' is defined on line 499,
but no explicit reference was found in the text
== Unused Reference: 'I-D.ietf-roll-p2p-rpl' is defined on line 504, but no
explicit reference was found in the text
== Unused Reference: 'I-D.ietf-roll-trickle-mcast' is defined on line 510,
but no explicit reference was found in the text
== Unused Reference: 'I-D.thubert-6lowpan-backbone-router' is defined on
line 516, but no explicit reference was found in the text
== Unused Reference: 'I-D.sarikaya-core-sbootstrapping' is defined on line
521, but no explicit reference was found in the text
== Unused Reference: 'I-D.gilger-smart-object-security-workshop' is defined
on line 528, but no explicit reference was found in the text
== Outdated reference: A later version (-02) exists of
draft-thubert-roll-forwarding-frags-00
== Outdated reference: A later version (-13) exists of
draft-ietf-roll-terminology-11
== Outdated reference: A later version (-17) exists of
draft-ietf-roll-p2p-rpl-16
== Outdated reference: A later version (-12) exists of
draft-ietf-roll-trickle-mcast-03
== Outdated reference: A later version (-03) exists of
draft-thubert-6lowpan-backbone-router-02
== Outdated reference: A later version (-05) exists of
draft-sarikaya-core-sbootstrapping-04
== Outdated reference: A later version (-03) exists of
draft-gilger-smart-object-security-workshop-00
== Outdated reference: A later version (-02) exists of
draft-phinney-roll-rpl-industrial-applicability-01
== Outdated reference: A later version (-18) exists of
draft-ietf-core-coap-13
Summary: 2 errors (**), 0 flaws (~~), 34 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 6TSCH T. Watteyne, Ed.
3 Internet-Draft Linear Technology
4 Intended status: Informational February 21, 2013
5 Expires: August 25, 2013
7 Using IEEE802.15.4e TSCH in an LLN context:
8 Overview, Problem Statement and Goals
9 draft-watteyne-6tsch-tsch-lln-context-01
11 Abstract
13 This document describes the environment, problem statement, and goals
14 for using the IEEE802.15.4e TSCH MAC protocol in the context of LLNs.
15 The set of goals enumerated in this document form an initial set
16 only.
18 Status of this Memo
20 This Internet-Draft is submitted in full conformance with the
21 provisions of BCP 78 and BCP 79.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF). Note that other groups may also distribute
25 working documents as Internet-Drafts. The list of current Internet-
26 Drafts is at http://datatracker.ietf.org/drafts/current/.
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
33 This Internet-Draft will expire on August 25, 2013.
35 Copyright Notice
37 Copyright (c) 2013 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents
42 (http://trustee.ietf.org/license-info) in effect on the date of
43 publication of this document. Please review these documents
44 carefully, as they describe your rights and restrictions with respect
45 to this document. Code Components extracted from this document must
46 include Simplified BSD License text as described in Section 4.e of
47 the Trust Legal Provisions and are provided without warranty as
48 described in the Simplified BSD License.
50 Table of Contents
52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
53 2. TSCH in the LLN Context . . . . . . . . . . . . . . . . . . . 5
54 3. Problems and Goals . . . . . . . . . . . . . . . . . . . . . . 7
55 3.1. Network Formation . . . . . . . . . . . . . . . . . . . . 7
56 3.2. Network Maintenance . . . . . . . . . . . . . . . . . . . 7
57 3.3. Multi-Hop Topology . . . . . . . . . . . . . . . . . . . . 8
58 3.4. Routing and Timing Parents . . . . . . . . . . . . . . . . 8
59 3.5. Resource Management . . . . . . . . . . . . . . . . . . . 8
60 3.6. Dataflow Control . . . . . . . . . . . . . . . . . . . . . 9
61 3.7. Deterministic Behavior . . . . . . . . . . . . . . . . . . 9
62 3.8. Path Computation Engine . . . . . . . . . . . . . . . . . 9
63 3.9. Secure Communication . . . . . . . . . . . . . . . . . . . 10
64 4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
67 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13
68 6.2. Informative References . . . . . . . . . . . . . . . . . . 13
69 6.3. External Informative References . . . . . . . . . . . . . 15
70 Appendix A. TSCH Protocol Highlights . . . . . . . . . . . . . . 19
71 A.1. Timeslots . . . . . . . . . . . . . . . . . . . . . . . . 19
72 A.2. Slotframes . . . . . . . . . . . . . . . . . . . . . . . . 19
73 A.3. Mote Communication Schedule . . . . . . . . . . . . . . . 19
74 A.4. Links and Paths . . . . . . . . . . . . . . . . . . . . . 20
75 A.5. Dedicated vs. Shared Slots . . . . . . . . . . . . . . . . 20
76 A.6. Absolute Slot Number . . . . . . . . . . . . . . . . . . . 21
77 A.7. Channel Hopping . . . . . . . . . . . . . . . . . . . . . 21
78 A.8. Time Synchronization . . . . . . . . . . . . . . . . . . . 22
79 A.9. Power Consumption . . . . . . . . . . . . . . . . . . . . 23
80 A.10. Network Communication Schedule . . . . . . . . . . . . . . 23
81 A.11. Join Process . . . . . . . . . . . . . . . . . . . . . . . 23
82 A.12. Information Elements . . . . . . . . . . . . . . . . . . . 24
83 A.13. Extensibility . . . . . . . . . . . . . . . . . . . . . . 24
84 Appendix B. TSCH Gotchas . . . . . . . . . . . . . . . . . . . . 25
85 B.1. Collision Free Communication . . . . . . . . . . . . . . . 25
86 B.2. Multi-Channel vs. Channel Hopping . . . . . . . . . . . . 25
87 B.3. Cost of (continuous) Synchronization . . . . . . . . . . . 25
88 B.4. Topology Stability . . . . . . . . . . . . . . . . . . . . 26
89 B.5. Multiple Concurrent Slotframes . . . . . . . . . . . . . . 26
90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
92 1. Introduction
94 The IEEE802.15.4e standard [IEEE802154e] was published in 2012 as an
95 amendment to the Medium Access Control (MAC) protocol defined by the
96 IEEE802.15.4-2011 [IEEE802154] standard. The Timeslotted Channel
97 Hopping (TSCH) mode of IEEE802.15.4e is the object of this document.
99 TSCH was designed to "allow IEEE802.15.4 devices to support a wide
100 range of industrial applications" [IEEE802154e]. At its core is a
101 medium access technique which uses time synchronization to achieve
102 ultra low-power operation and channel hopping to enable high
103 reliability. This is very different from the "legacy" IEEE802.15.4
104 MAC protocol, and is therefore better described as a "redesign".
105 TSCH does not amend the physical layer; i.e., it can operate on any
106 IEEE802.15.4-compliant hardware.
108 IEEE802.15.4e can be seen as the latest generation of ultra-lower
109 power and reliable networking solutions for LLNs. Its core
110 technology is similar to the one used in industrial networking
111 technologies such as WirelessHART [WHART] or ISA100.11a [ISA100].
112 These protocol solutions have been targeted essentially at the
113 industrial market. WirelessHART is for example the wireless
114 extension of HART, a long standing protocol suite for networking
115 industrial equipment.
117 [RFC5673] discusses industrial applications, and highlights the harsh
118 operating conditions as well as the stringent reliability,
119 availability, and security requirements for an LLN to operate in an
120 industrial environment. Industrial protocols such as WirelessHART
121 satisfy those requirements, and with tens of thousands of networks
122 deployed [Emerson], these types of networks have a large impact on
123 industrial applications. Commercial networking solutions are
124 available today in which motes consume 10's of micro-amps on average
125 [CurrentCalculator] with end-to-end packet delivery ratios over
126 99.999% [doherty07channel].
128 IEEE802.15.4e builds on the same foundations as WirelessHART, and
129 therefore exhibits similar performance. Yet, unlike an industrial
130 protocol which is, by nature, application-specific, IEEE802.15.4e
131 TSCH focuses on the MAC layer only. This clean layering allows for
132 TSCH to fit under an IPv6 enabled protocol stack for LLNs, running
133 6LoWPAN [RFC6282], RPL [RFC6550] and CoAP [I-D.ietf-core-coap].
135 Bringing industrial-like performance into the LLN stack developed by
136 the 6LoWPAN, ROLL and CORE working groups opens up new application
137 domains for these networks. Sensors deployed in smart cities
138 [RFC5548] will be able to be installed for years without needing
139 battery replacement. "Umbrella" networks will interconnect smart
140 elements from different entities in smart buildings [RFC5867]. Peel-
141 and-stick switches will obsolete the need for costly conduits for
142 lighting solutions in smart homes [RFC5826].
144 While [IEEE802154e] defines the mechanisms for a TSCH mote to
145 communicate, it does not define the policies to build and maintain
146 the communication schedule, match that schedule to the multi-hop
147 paths maintained by RPL, adapt the resources allocated between
148 neighbor nodes to the data traffic flows, enforce a differentiated
149 treatment for data generated at the application layer and signaling
150 messages needed by 6LoWPAN and RPL to discover neighbors, react to
151 topology changes, self-configure IP addresses, or manage keying
152 material.
154 In other words, IEEE802.15.4e TSCH is designed to allow optimizations
155 and strong customizations, simplifying the merging of TSCH with a
156 protocol stack based on IPv6, 6LoWPAN, and RPL.
158 2. TSCH in the LLN Context
160 In many cases, to map the services required by the IP layer to the
161 services provided by the link layer, an adaptation layer is used
162 [palattella12standardized]. The 6LoWPAN working group started
163 working in 2007 on specifications for transmitting IPv6 packets over
164 IEEE802.15.4 networks [RFC4919]. Typically, low-power WPANs are
165 characterized by small packet sizes, support for addresses with
166 different lengths, low bandwidth, star and mesh topologies, battery
167 powered devices, low cost, large number of devices, unknown node
168 positions, high unreliability, and periods during which communication
169 interfaces are turned off to save energy. Given these features, it
170 is clear that the adoption of IPv6 on top of a Low-Power WPAN is not
171 straightforward, but poses strong requirements for the optimization
172 of this adaptation layer. For instance, due to the IPv6 default
173 minimum MTU size (1280 bytes), an un-fragmented IPv6 packet is too
174 large to fit in an IEEE802.15.4 frame. Moreover, the overhead due to
175 the 40-byte long IPv6 header wastes the scarce bandwidth available at
176 the PHY layer [RFC4944]. For these reasons, the 6LoWPAN working
177 group has defined an effective adaptation layer [RFC6568]. Further
178 issues encompass the auto-configuration of IPv6 addresses
179 [RFC2464][RFC6755], the compliance with the recommendation on
180 supporting link-layer subnet broadcast in shared networks [RFC3819],
181 the reduction of routing and management overhead [RFC6606], the
182 adoption of lightweight application protocols (or novel data encoding
183 techniques), and the support for security mechanisms (confidentiality
184 and integrity protection, device bootstrapping, key establishment,
185 and management).
187 These features can run on top of TSCH. There are, however, important
188 issues to solve, as highlighted in Section 3.
190 Routing issues are challenging for 6LoWPAN, given the low-power and
191 lossy radio-links, the battery supplied nodes, the multi-hop mesh
192 topologies, and the frequent topology changes due to mobility.
193 Successful solutions take into account the specific application
194 requirements, along with IPv6 behavior and 6LoWPAN mechanisms
195 [palattella12standardized]. The ROLL working group has defined RPL
196 in [RFC6550]. RPL can support a wide variety of link layers,
197 including ones that are constrained, potentially lossy, or typically
198 utilized in conjunction with host or router devices with very limited
199 resources, as in building/home automation [RFC5867][RFC5826],
200 industrial environments [RFC5673], and urban applications [RFC5548].
201 RPL is able to quickly build up network routes, distribute routing
202 knowledge among nodes, and adapt to a changing topology. In a
203 typical setting, motes are connected through multi-hop paths to a
204 small set of root devices, which are usually responsible for data
205 collection and coordination. For each of them, a Destination
206 Oriented Directed Acyclic Graph (DODAG) is created by accounting for
207 link costs, node attributes/status information, and an Objective
208 Function, which maps the optimization requirements of the target
209 scenario. The topology is set up based on a Rank metric, which
210 encodes the distance of each node with respect to its reference root,
211 as specified by the Objective Function. Regardless of the way it is
212 computed, the Rank monotonically decreases along the DODAG towards
213 the destination, building a gradient. RPL encompasses different
214 kinds of traffic and signaling information. Multipoint-to-Point
215 (MP2P) is the dominant traffic in LLN applications. Data is routed
216 towards nodes with some application relevance, such as the LLN
217 gateway to the larger Internet, or to the core of private IP
218 networks. In general, these destinations are the DODAG roots and act
219 as data collection points for distributed monitoring applications.
220 Point-to-Multipoint (P2MP) data streams are used for actuation
221 purposes, where messages are sent from DODAG roots to destination
222 nodes. Point-to-Point (P2P) traffic allows communication between two
223 devices belonging to the same LLN, such as a sensor and an actuator.
224 A packet flows from the source to the common ancestor of those two
225 communicating devices, then downward towards the destination. RPL
226 therefore has to discover both upward routes (i.e. from nodes to
227 DODAG roots) in order to enable MP2P and P2P flows, and downward
228 routes (i.e. from DODAG roots to nodes) to support P2MP and P2P
229 traffic.
231 Section 3 highlights the challenges that need to be addressed to use
232 RPL on top of TSCH.
234 Several open-source initiatives have emerged around TSCH. The
235 OpenWSN project [OpenWSN][OpenWSNETT] is an open-source
236 implementation of a fully standards-based protocol stack, which aims
237 at evaluating the applicability of TSCH to different applications.
238 This implementation was used as the foundation for an IP for Smart
239 Objects Alliance (IPSO) [IPSO] iteroperability event in 2011. In the
240 absence of a standardized scheduling mechanism for TSCH, a "slotted
241 Aloha" schedule was used.
243 3. Problems and Goals
245 As highlighted in Appendix A, TSCH is different for traditional low-
246 power MAC protocols because of its scheduled nature. TSCH defines
247 the mechanisms to execute a communication schedule, but it is the
248 entity that sets up that schedule which controls the topology of the
249 network, and the resources allocated to each link in that topology.
251 How this entity should operate is out of scope of TSCH. The
252 remainder of this section highlights the problems this entity needs
253 to address. For simplicity, we will refer to this entity by the
254 generic name "6TSCH", without loss of generality. In particular, we
255 do not assume the nature of 6TSCH, whether an adaptation layer, a
256 distributed reservation protocol, a centralized path computation
257 engine, or any combination thereof.
259 Some of the issues 6TSCH need to target might overlap with the scope
260 of other protocols (e.g., 6LoWPAN, RPL, and RSVP). In this case, it
261 is entailed that 6TSCH will profit from the services provided by
262 other protocols to pursue these objectives.
264 3.1. Network Formation
266 6TSCH needs to control the way the network is formed, including how
267 new motes join, and how already joined motes advertise the presence
268 of the network. 6TSCH needs to:
270 1. Define the Information Elements to include in the Enhanced
271 Beacons advertising the presence of the network.
273 2. For a new mote, define rules to process and filter received
274 Enhanced Beacons. This includes a mechanism to select the best
275 mote through which to join the network.
277 3. Define the joining procedure. This includes a mechanism to
278 assign a unique 16-bit address to a mote, and the management of
279 initial keying material.
281 4. Define a mechanism to secure the joining process and the
282 subsequent optional process of scheduling more communication
283 links.
285 3.2. Network Maintenance
287 Once a network is formed, 6TSCH needs to maintain the network's
288 health, allowing for motes to stay synchronized. 6TSCH needs to:
290 1. Manage each mote's time source neighbor(s).
292 2. Define a mechanism for a mote to update the join priority it
293 announces in its Enhanced Beacon.
295 3. Schedule transmissions of Enhanced Beacons to advertise the
296 presence of the network.
298 3.3. Multi-Hop Topology
300 RPL, given a weighted connectivity graph, determines multi-hop
301 routes. 6TSCH needs to:
303 1. Define a mechanism to gather topological information, which it
304 can then feed to RPL.
306 2. Ensure that the TSCH schedule contains links along the multi-hop
307 routes identified by RPL.
309 3. Where applicable, maintain independent sets of links to transport
310 independent flows of data.
312 3.4. Routing and Timing Parents
314 At all times, a TSCH mote needs to have at least one time source
315 neighbor it can synchronize to. 6TSCH therefore needs to assign time
316 source neighbors to allow for correct operation of the TSCH network.
317 These time source neighbors could, or not, be related to RPL time
318 parents.
320 3.5. Resource Management
322 A link in a TSCH schedule is a "unit" of resource. The number of
323 links to assign between neighbor motes needs to be appropriate for
324 the size of the traffic flow. 6TSCH needs to:
326 1. Define rules on when to create or delete a slotframe.
328 2. Define rules to determine the length of a slotframe, and the
329 trigger to modify the length of a slotframe.
331 3. Define rules on when to add or delete links in a particular
332 slotframe.
334 4. Define a mechanism for neighbor nodes to exchange information
335 about their schedule and, if applicable, negotiate the addition/
336 deletion of links.
338 5. Allow for a (possibly centralized) entity to take full control
339 over the schedule.
341 6. Define a set of metrics to evaluate the tradeoff between latency,
342 bandwidth and energy consumption achieved by a particular
343 schedule.
345 3.6. Dataflow Control
347 TSCH defines mechanisms for a mote to signal it cannot accept an
348 incoming packet. It does not, however, define the policy which
349 determines when to stop accepting packets. 6TSCH need to:
351 1. Define a queueing policy for incoming and outgoing packets.
353 2. Manage the buffer space, and indicate to TSCH when to stop
354 accepting incoming packets.
356 3. Handle transmissions that have failed. A transmission is
357 declared failed when TSCH has retransmitted the packet multiple
358 times, without receiving an acknowledgment. This covers both
359 dedicated and shared links.
361 3.7. Deterministic Behavior
363 As highlighted in [RFC5673], in some applications, data is generated
364 periodically and has a well understood data bandwidth requirement,
365 which is deterministic and predictable. 6TSCH need to:
367 1. Ensure timely delivery of such data.
369 2. Provide a mechanism for such deterministic flows to coexist with
370 bursty or infrequent traffic flows of different priorities.
372 3.8. Path Computation Engine
374 As highlighted in [I-D.phinney-roll-rpl-industrial-applicability],
375 bandwidth allocation and multi-hop routes can be optimized by an
376 external Path Computation Engine (PCE). 6TSCH need to:
378 1. Provide a mechanism for an external PCE to be able to control the
379 entire schedule of the network, including the slotframes, links
380 and time source neighbor assignment.
382 2. Define a optional mechanism for the schedule managed by this PCE
383 to coexist with scheduling elements (slotframes, links) managed
384 up by a different mechanism such as a distribute scheduling
385 algorithm.
387 3.9. Secure Communication
389 Given some keying material, TSCH defines mechanisms to encrypt and
390 authenticate MAC frames. It does not define how this keying material
391 is generated. 6TSCH need to:
393 1. Define the keying material and authentication mechanism needed by
394 a new mote to join an existing network.
396 2. Define a mechanism to allow for the secure transfer of
397 application data between neighbor motes.
399 3. Define a mechanism to allow for the secure transfer of signaling
400 data between motes and 6TSCH.
402 4. Contributors
404 Maria Rita Palattella
405 SnT/University of Luxembourg
407 maria-rita.palattella@uni.lu
409 Luigi Alfredo Grieco
410 Politecnico di Bari
412 a.grieco@poliba.it
414 5. Acknowledgements
416 Special thanks to Jonathan Simon for his review and valuable
417 comments.
419 6. References
421 6.1. Normative References
423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
424 Requirement Levels", BCP 14, RFC 2119, March 1997.
426 6.2. Informative References
428 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
429 Networks", RFC 2464, December 1998.
431 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
432 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
433 Wood, "Advice for Internet Subnetwork Designers", BCP 89,
434 RFC 3819, July 2004.
436 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
437 over Low-Power Wireless Personal Area Networks (6LoWPANs):
438 Overview, Assumptions, Problem Statement, and Goals",
439 RFC 4919, August 2007.
441 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
442 "Transmission of IPv6 Packets over IEEE 802.15.4
443 Networks", RFC 4944, September 2007.
445 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
446 "Routing Requirements for Urban Low-Power and Lossy
447 Networks", RFC 5548, May 2009.
449 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
450 Routing Requirements in Low-Power and Lossy Networks",
451 RFC 5826, April 2010.
453 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
454 "Building Automation Routing Requirements in Low-Power and
455 Lossy Networks", RFC 5867, June 2010.
457 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney,
458 "Industrial Routing Requirements in Low-Power and Lossy
459 Networks", RFC 5673, October 2009.
461 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
462 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
463 September 2011.
465 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
466 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
468 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
469 Lossy Networks", RFC 6550, March 2012.
471 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and
472 Application Spaces for IPv6 over Low-Power Wireless
473 Personal Area Networks (6LoWPANs)", RFC 6568, April 2012.
475 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
476 Statement and Requirements for IPv6 over Low-Power
477 Wireless Personal Area Network (6LoWPAN) Routing",
478 RFC 6606, May 2012.
480 [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
481 for OAuth", RFC 6755, October 2012.
483 [I-D.thubert-roll-forwarding-frags]
484 Thubert, P. and J. Hui, "LLN Fragment Forwarding and
485 Recovery", draft-thubert-roll-forwarding-frags-00 (work in
486 progress), March 2012.
488 [I-D.tsao-roll-security-framework]
489 Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A
490 Security Framework for Routing over Low Power and Lossy
491 Networks", draft-tsao-roll-security-framework-02 (work in
492 progress), March 2010.
494 [I-D.thubert-roll-asymlink]
495 Thubert, P., "RPL adaptation for asymmetrical links",
496 draft-thubert-roll-asymlink-02 (work in progress),
497 December 2011.
499 [I-D.ietf-roll-terminology]
500 Vasseur, J., "Terminology in Low power And Lossy
501 Networks", draft-ietf-roll-terminology-11 (work in
502 progress), February 2013.
504 [I-D.ietf-roll-p2p-rpl]
505 Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J.
506 Martocci, "Reactive Discovery of Point-to-Point Routes in
507 Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-16
508 (work in progress), February 2013.
510 [I-D.ietf-roll-trickle-mcast]
511 Hui, J. and R. Kelsey, "Multicast Protocol for Low power
512 and Lossy Networks (MPL)",
513 draft-ietf-roll-trickle-mcast-03 (work in progress),
514 January 2013.
516 [I-D.thubert-6lowpan-backbone-router]
517 Thubert, P., "6LoWPAN Backbone Router",
518 draft-thubert-6lowpan-backbone-router-02 (work in
519 progress), June 2010.
521 [I-D.sarikaya-core-sbootstrapping]
522 Sarikaya, B., Ohba, Y., Moskowitz, R., Cao, Z., and R.
523 Cragie, "Security Bootstrapping Solution for Resource-
524 Constrained Devices",
525 draft-sarikaya-core-sbootstrapping-04 (work in progress),
526 April 2012.
528 [I-D.gilger-smart-object-security-workshop]
529 Gilger, J. and H. Tschofenig, "Report from the 'Smart
530 Object Security Workshop', 23rd March 2012, Paris,
531 France", draft-gilger-smart-object-security-workshop-00
532 (work in progress), October 2012.
534 [I-D.phinney-roll-rpl-industrial-applicability]
535 Phinney, T., Thubert, P., and R. Assimiti, "RPL
536 applicability in industrial networks",
537 draft-phinney-roll-rpl-industrial-applicability-01 (work
538 in progress), October 2012.
540 [I-D.ietf-core-coap]
541 Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
542 "Constrained Application Protocol (CoAP)",
543 draft-ietf-core-coap-13 (work in progress), December 2012.
545 6.3. External Informative References
547 [IEEE802154e]
548 IEEE standard for Information Technology, "IEEE std.
549 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
550 Networks (LR-WPANs) Amendament 1: MAC sublayer",
551 April 2012.
553 [IEEE802154]
554 IEEE standard for Information Technology, "IEEE std.
555 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
556 and Physical Layer (PHY) Specifications for Low-Rate
557 Wireless Personal Area Networks", June 2011.
559 [WHART] www.hartcomm.org, "Highway Addressable Remote Transducer,
560 a group of specifications for industrial process and
561 control devices administered by the HART Foundation".
563 [ISA100] ISA, "ISA100, Wireless Systems for Automation", May 2008,
564 < http://www.isa.org/Community/
565 SP100WirelessSystemsforAutomation>.
567 [Emerson] Emerson Process Management, "Emerson Process Management
568 Smart Wireless Homepage", < http://
569 www2.emersonprocess.com/en-US/plantweb/wireless/Pages/
570 WirelessHomePage-Flash.aspx>.
572 [OpenWSN] "Berkeley's OpenWSN Project Homepage",
573 .
575 [OpenWSNETT]
576 Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F.,
577 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN:
578 a standards-based low-power wireless development
579 environment", Transactions on Emerging Telecommunications
580 Technologies 2012, August 2012, .
583 [IPSO] "IP for Smart Objects Alliance Homepage",
584 .
586 [CurrentCalculator]
587 Linear Technology, "Application Note: Using the Current
588 Calculator to Estimate Mote Power", August 2012, .
593 [doherty07channel]
594 Doherty, L., Lindsay, W., and J. Simon, "Channel-Specific
595 Wireless Sensor Network Path Data", IEEE International
596 Conference on Computer Communications and Networks
597 (ICCCN) 2008, 2007.
599 [TSMP] Pister, K. and L. Doherty, "TSMP: Time Synchronized Mesh
600 Prootocol", International Symposium on Distributed Sensor
601 Networks (DSN) 2008, Nov. 2008, < http://
602 robotics.eecs.berkeley.edu/~pister/publications/2008/
603 TSMP%20DSN08.pdf>.
605 [tinka10decentralized]
606 Tinka, A., Watteyne, T., and K. Pister, "A Decentralized
607 Scheduling Algorithm for Time Synchronized Channel
608 Hopping", Ad Hoc Networks 2010, 2010, < http://
609 robotics.eecs.berkeley.edu/~pister/publications/2008/
610 TSMP%20DSN08.pdf>.
612 [watteyne09reliability]
613 Watteyne, T., Mehta, A., and K. Pister, "Reliability
614 Through Frequency Diversity: Why Channel Hopping Makes
615 Sense", International Conference on Performance Evaluation
616 of Wireless Ad Hoc, Sensor, and Ubiquitous Networks (PE-
617 WASUN) 2009, Oct. 2009, .
620 [kerkez09feasibility]
621 Kerkez, B., Watteyne, T., and M. Magliocco, "Feasibility
622 analysis of controller design for adaptive channel
623 hopping", International Workshop on Performance
624 Methodologies and Tools for Wireless Sensor Networks
625 (WSNPERF) 2009, Oct. 2009, .
629 [TASA-PIMRC]
630 Palattella, MR., Accettura, N., Dohler, M., Grieco, LA.,
631 and G. Boggia, "Traffic Aware Scheduling Algorithm for
632 Multi-Hop IEEE 802.15.4e Networks", IEEE PIMRC 2012,
633 Sept. 2012, < http://www.cttc.es/resources/doc/
634 120531-submitted-tasa-25511.pdf>.
636 [TASA-SENSORS]
637 Palattella, MR., Accettura, N., Dohler, M., Grieco, LA.,
638 and G. Boggia, "Traffic-Aware Time-Critical Scheduling In
639 Heavily Duty-Cycled IEEE 802.15.4e For An Industrial IoT",
640 IEEE SENSORS 2012, Oct. 2012, < http://www.cttc.es/
641 resources/doc/120821-sensors2012-4396981770946977737.pdf>.
643 [TASA-WCNC]
644 Accettura, N., Palattella, MR., Dohler, M., Grieco, LA.,
645 and G. Boggia, "Standardized Power-Efficient and Internet-
646 Enabled Communication Stack for Capillary M2M Networks",
647 IEEE WCNC 2012, Apr. 2012, < http://www.cttc.es/resources/
648 doc/120109-1569521283-submitted-58230.pdf>.
650 [palattella12standardized]
651 Palattella, MR., Accettura, N., Vilajosana, X., Watteyne,
652 T., Grieco, LA., Boggia, G., and M. Dohler, "Standardized
653 Protocol Stack For The Internet Of (Important) Things",
654 IEEE Communications Surveys and Tutorials 2012, Dec. 2012,
655 < http://www.cttc.es/resources/doc/
656 121025-completestackforiot-clean-4818610916636121981.pdf>.
658 [PANA] Kanda, M., Ohba, Y., Das, S., and S. Chasko, "PANA
659 applicability in constrained environments", Febr. 2012, .
663 Appendix A. TSCH Protocol Highlights
665 This appendix gives an overview of the key features of the
666 IEEE802.15.4e Timeslotted Channel Hopping (TSCH) amendment. It makes
667 no attempt at repeating the standard, but rather focuses on the
668 following:
670 o Concepts which are sufficiently different from traditional
671 IEEE802.15.4 networking that they may need to be defined and
672 presented precisely.
674 o Techniques and ideas which are part of IEEE802.15.4e and which
675 might be useful for the work of 6TSCH.
677 A.1. Timeslots
679 All motes in a TSCH network are synchronized. Time is sliced up into
680 time slots. A time slot is long enough for a MAC frame of maximum
681 size to be sent from mote A to mote B, and for mote B to reply with
682 an acknowledgment (ACK) frame indicating successful reception.
684 The duration of a timeslot is not defined by the standard. With
685 IEEE802.15.4-compliant radios operating in the 2.4GHz frequency band,
686 a maximum-length frame of 127 bytes takes about 4ms to transmit; a
687 shorter ACK takes about 1ms. With a 10ms slot (a typical duration),
688 this leaves 5ms to radio turnaround, packet processing and security
689 operations.
691 A.2. Slotframes
693 Timeslots are grouped into one of more slotframes. A slotframe
694 continuously repeats over time. TSCH does not impose a slotframe
695 size. Depending on the application needs, these can range from 10s
696 to 1000s of timeslots. The shorter the slotframe, the more often a
697 timeslot repeats, resulting in more available bandwidth, but also in
698 a higher power consumption.
700 A.3. Mote Communication Schedule
702 A communication schedule instructs each mote what to do in each slot:
703 transmit, receive or sleep. The schedule indicates, for each active
704 (transmit or receive) timeslot a channelOffset and the address of the
705 neighbor to communicate with.
707 Once a mote obtains its schedule, it executes it:
709 o For each transmit slot, the mote checks whether there is a packet
710 in the outgoing buffer which matches the neighbor written in the
711 schedule information for that slot. If there is none, the mote
712 keeps its radio off for the duration of the slot. If there is
713 one, the mote can ask for the neighbor to acknowledge it, in which
714 case it has to listen for the acknowledgment after transmitting.
716 o For each receive slot, the mote listens for possible incoming
717 packets. If none is received after some listening period, it
718 shuts down its radio. If a packet is received, addressed to the
719 mote, and passes security checks, the mote can send back an
720 aknowledgment.
722 How the schedule is built, updated and maintained, and by which
723 entity, is outside of the scope of the IEEE802.15.4e standard.
725 A.4. Links and Paths
727 Assuming the schedule is well built, if mote A is scheduled to
728 transmit to mote B at slotOffset 5 and channelOffset 11, mote B will
729 be scheduled to receive from mote A at the same slotOffset and
730 channelOffset.
732 A single slot of the schedule (i.e., a single cell of the grid),
733 characterized by a slotOffset and channelOffset, and reserved for
734 mote A to transmit to mote B (or for mote B to receive from mote A),
735 is called a "link".
737 If there is a lot of data flowing from mote A to mote B, the schedule
738 might contain multiple slots from A to B, at different times.
739 Multiple links scheduled to the same neighbor are typically
740 equivalent, i.e. the MAC layer sends the packet on whichever of these
741 links happens to show up first after the packet was put in the MAC
742 queue. The union of all links between two neighbors, A and B, is
743 called a "path". Since the slotframe repeats over time (and the
744 length of the slotframe is typically constant), each link gives a
745 "quantum" of bandwidth to a given neighbor. Modifying the number of
746 links in a path modifies the amount of resources allocated between
747 two neighbors.
749 A.5. Dedicated vs. Shared Slots
751 By default, each transmit timeslot within the TSCH schedule is
752 dedicated, i.e., reserved only for mote A to transmit to mote B.
753 IEEE802.15.4e allows also to mark a slot as shared. In a shared
754 slot, multiple motes can transmit at the same time, on the same
755 fequency. To avoid contention, TSCH defines a back-off algorithm for
756 shared slots.
758 A slot can be marked as both transmitting and receiving. In this
759 case, a mote transmits if it has an appropriate packet in its output
760 buffer, or listens otherwise. Marking a slot as
761 [transmit,shared,receive] results in slotted-Aloha behavior.
763 A.6. Absolute Slot Number
765 TSCH defines a timeslot counter called Absolute Slot Number (ASN).
766 When a new network is created, the ASN is initialized to 0; from then
767 on, it increments by 1 at each timeslot. In detail:
769 ASN = (k*S+t)
771 where k is the slotframe cycle (i.e., the number of slotframe
772 occurences over time), S the slotframe size and t the slotOffset. A
773 mote learns the current ASN when it joins the network. Since motes
774 are synchronized, they all know the current value of the ASN, and any
775 time. The ASN is encoded as a 5-byte number: this allows it to
776 increment for hundreds of years (the exact value depends on the
777 duration of a timeslot) without wrapping. The ASN is used (i) to
778 calculate the frequency to communicate on, jointly with the
779 channelOffset, (ii) to build unique security nonce counters used by
780 CCM*.
782 A.7. Channel Hopping
784 For each active slot, the schedule specifies a slotOffset and a
785 channelOffset. In a well-built schedule, when mote A has a transmit
786 slot to mote B on channelOffset 5, mote B has a receive slot from
787 mote A on the same channelOffset. The channelOffset is translated by
788 both nodes into a frequency using the following function:
790 frequency = F {(ASN + channelOffset) mod nFreq}
792 The function F consists of a look-up table containing the set of
793 available channels. The value nFreq (the number of available
794 frequencies) is the size of this look-up table. There are as many
795 channelOffset values as there are frequencies available (e.g. 16 when
796 using IEEE802.15.4-compliant radios at 2.4GHz, when all channels are
797 used). Since both motes have the same channelOffset written in their
798 schedule for that timeslot, and the same ASN counter since they are
799 synchronized, they compute the same frequency. At the next iteration
800 (cycle) of the slotframe, however, the channelOffset will be the
801 same, but the ASN will have changed, resulting in the computation of
802 a different frequency. If the slotframe size, S (used for computing
803 ASN), and the number of channel offsets, nFreq, are relatively prime,
804 the translation function ensures that each link rotates through k
805 available channels over k slotframe cycles. This results in "channel
806 hopping": even with a static schedule, pairs of neighbors "hop"
807 between the different frequencies when communicating.
809 The look-up table F can be built to contain only a subset of all
810 available channels. This results in frequency "blacklisting".
812 Channel hopping is a technique known to efficiently combat multi-path
813 fading and external interference. This results in a TSCH network
814 having a more stable topology than if only a single channel were used
815 for the entire network.
817 A.8. Time Synchronization
819 Because of the slotted nature of communication in a TSCH network,
820 motes have to maintain tight synchronization. All motes are assumed
821 to be equipped with clocks to keep track of time (32kHz crystal
822 oscillators are typically used). Yet, because clocks in different
823 motes drift with respect to one another, neighbor motes need to
824 periodically re-synchronize.
826 In detail, each mote periodically synchronizes its network clock to
827 at least one other mote, and it also provides its network time to its
828 neighbors. It is up to the entity that manages the schedule to
829 assign adequate time source neighbor(s) to each mote, i.e., to
830 indicate in the schedule which of its neighbor(s) are its "time
831 source neighbors". While setting the time source neighbor, it is
832 important to avoid synchronization loops, which could result in the
833 formation of independent clusters of motes.
835 Typically, in a IEEE802.15.4e TSCH network, time propagates outwards
836 from the PAN coordinator (i.e., the root node). But the direction of
837 time propagation is independent of data flow in the network. A new
838 mote joining a TSCH network, because it does not have a schedule yet,
839 maintains time synchronization, using the information carried by the
840 Enhanced Beacons (EBs), sent by the advertising motes.
842 TSCH adds timing information in all packets that are exchanged (both
843 data and ACK frames). This means that neighbor motes can
844 resynchronize to one another whenever they exchange data. In detail,
845 in the IEEE 802.15.4e standard two methods are defined for allowing a
846 device to synchronize in a TSCH network: (I) Acknowledgment-Based and
847 (II) Frame-Based synchronization. In both cases, the receiver
848 calculates the difference in time between the expected time of frame
849 arrival and its actual arrival. In Acknowledgment-Based
850 synchronization, the receiver provides such information to the sender
851 mote in its acknowledgment. Thus, in this case, it is the sender
852 mote that synchronizes to the clock of the receiver. In Frame-Based
853 synchronization, the receiver uses the computed delta for adjusting
854 its own clock. Therefore, it is the receiver mote that synchronizes
855 to the clock of the sender.
857 Different synchronization policies are possible. Motes can keep
858 synchronization exclusively by exchanging EBs. Motes can also keep
859 synchronized by periodically sending valid frames to time source
860 neighbors to use the acknowledgement to resynchronize. Both method
861 (or a combination thereof) are valid synchronization policies; which
862 one to use depends on network requirements.
864 A.9. Power Consumption
866 There are only a handful of activities a mote can perform during a
867 timeslot: transmit, receive, or sleep. Each of these operations has
868 some energy cost associated to them, the exact value depending on the
869 the hardware used. Given the schedule of a mote, it is
870 straighforward to calculate the expected average power consumption of
871 that mote.
873 A.10. Network Communication Schedule
875 The schedule defines entirely the synchronization and communication
876 between motes. By adding/removing links between neighbors, one can
877 adapt a schedule to the needs of the application. Intuitive examples
878 are:
880 o Make the schedule "sparse" for applications where motes need to
881 consume as little energy as possible, at the price of reduced
882 bandwidth.
884 o Make the schedule "dense" for applications where motes generate a
885 lot of data, at the price of increased power consumption.
887 o Add more links along a multi-hop route over which many packets
888 flow.
890 A.11. Join Process
892 Motes already part of the network can periodically send Enhanced
893 Beacon (EB) frames to announce the presence the network. These
894 contain information about the size of the timeslot used in the
895 network, the current ASN, information about the slotframes and
896 timeslots the beaconing mote is listening on, and a 1-byte join
897 priority. This join priority corresponds to the number of hops
898 separating the mote sending the EB, and the PAN coordinator. Because
899 of the channel hopping nature of TSCH, these EB frames are sent on
900 all frequencies.
902 A mote wishing to join the network listens on some frequency for EBs.
904 It can wait to receive multiple, and can use the join priority in
905 those EBs to identify the best mote through which to join the
906 network. Using the ASN and the other timing information of the EB,
907 the new mote synchronizes to the network. Using the slotframe and
908 link information from the EB, it knows how to contact the mote it
909 just joined.
911 The TSCH standard does not define the steps beyond this "kickstart".
912 These steps can include a security handshake and the addition of more
913 communication links to the new mote's schedule.
915 A.12. Information Elements
917 TSCH introduces the concept of Information Elements (IES). An
918 information element is a list of Type-Length-Value containers placed
919 at the end of the MAC header. A small number of types are defined
920 for TSCH (e.g., the ASN in the EB is contained in an IE), and an
921 unmanaged range is available for extensions.
923 A data bit in the MAC header indicates whether the frame contains
924 IEs. IEs are grouped into Header IEs, consumed by the MAC layer and
925 therefore typically invisible to the next higher layer, and Payload
926 IEs, which are passed untouched to the next higher layer, possibly
927 followed by regular payload. Payload IEs can therefore be used for
928 the next higher layers of two neighbor motes to exchange information.
930 A.13. Extensibility
932 The TSCH standard is designed to be extensible. It introduces the
933 mechanisms as "building block" (e.g. links, slotframes, etc.), but
934 leaves entire freedom to the upper layer to assemble those. The MAC
935 protocol can be extended by defining new Header IEs. An intermediate
936 layer can be defined to manage the MAC layer by defining new Payload
937 IEs.
939 Appendix B. TSCH Gotchas
941 This section lists features of TSCH which we believe are important
942 and beneficial to the work of 6TSCH.
944 B.1. Collision Free Communication
946 TSCH allows one to easily design a schedule which yields collision-
947 free communication. This is done by building the schedule with
948 dedicated links in such a way that at most one link occupies each
949 slotOffset/channelOffset cell. Multiple pairs of neighbor motes can
950 exchange data at the same time, but on different frequencies. If a
951 deployment is done over a large area, slotOffset/channelOffset cells
952 can be reused by pairs of neigbors sufficiently far appart not to
953 interfere.
955 B.2. Multi-Channel vs. Channel Hopping
957 A TSCH schedule looks like a matrix of width "slotframe size", S, and
958 of height "number of frequencies", nFreq. For a scheduling
959 algorithm, these can be considered atomic "units" to schedule. In
960 particular, because of the channel hopping nature of TSCH, the
961 scheduling algorithm should not worry about the actual frequency
962 communication happens on, since it changes at each slotframe
963 iteration.
965 B.3. Cost of (continuous) Synchronization
967 When there is traffic in the network, motes which are communicating
968 implicitly re-synchronize using the data frames they exchange. In
969 the absence of data traffic, motes are required to synchronize to
970 their time source neighbor(s) periodically not to drift in time. If
971 they have not been communicating for some time (typically 30s), motes
972 can exchange an empty data frame, often referred to as a "Keep-alive"
973 message, to re-synchronize. The frequency at which such message need
974 to be transmitted depends on the stability of the clock source, and
975 on how "early" each mote starts listening for data (the "guard
976 time"). Theoretically, with a 10ppm clock and a 1ms guard time, this
977 period can be 100s. When acknowledgment-based synchronization is
978 used, re-synchronizing consists in sending any valid frame to the
979 time source neighbor and using the timing information in the ACK to
980 realign the clocks. Assuming this exchange causes the mote's radio
981 to be on for 5ms, this yields a radio duty cycle needed to keep
982 synchronized of 5ms/100s=0.005%. While TSCH does requires motes to
983 resynchronize periodically, the cost of doing so can be considered
984 almost negligible in many applications.
986 B.4. Topology Stability
988 The channel hopping nature of TSCH causes links to be very "stable".
989 Wireless phenomena such as multi-path fading and external
990 interference impact a wireless link between two motes differently on
991 each frequency. If a transmission from mote A to mote B fails,
992 retransmitting on a different frequency has a higher likelihood of
993 succeeding that retransmitting on the same frequency. As a result,
994 even when some frequencies are "behaving bad", channel hopping
995 "smoothens" the contribution of each frequency, resulting in more
996 stable links, and therefore a more stable topology.
998 B.5. Multiple Concurrent Slotframes
1000 The TSCH standard allows for multiple slotframes to coexist in a
1001 mote's schedule. It is possible that at some slot, a mote has
1002 multiple activities scheduled (e.g. transmit to mote B on slotFrame
1003 2, receive from mote C on slotFrame 1). To handle this situation,
1004 the TSCH standard defines the following precedence rules:
1006 1. Transmissions take precedence over receptions;
1008 2. Lower slotframe identifiers take precedence over higher slotframe
1009 identifiers.
1011 In the example above, the mote would transmit to mote B on slotFrame
1012 2.
1014 Author's Address
1016 Thomas Watteyne (editor)
1017 Linear Technology
1018 30695 Huntwood Avenue
1019 Hayward, CA 94544
1020 USA
1022 Phone: +1 (510) 400-2978
1023 Email: twatteyne@linear.com