idnits 2.17.1
draft-watteyne-6tsch-tsch-lln-context-00.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 8, 2013) is 4093 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Missing Reference: 'IEEE802154e' is mentioned on line 504, but not
defined
== Missing Reference: 'IEEE802154' is mentioned on line 510, but not defined
== Missing Reference: 'WHART' is mentioned on line 516, but not defined
== Missing Reference: 'ISA100' is mentioned on line 520, but not defined
== Missing Reference: 'Emerson' is mentioned on line 524, but not defined
== Missing Reference: 'CurrentCalculator' is mentioned on line 543, but not
defined
== Missing Reference: 'Doherty' is mentioned on line 125, but not defined
== Missing Reference: 'OpenWSN' is mentioned on line 529, but not defined
== Missing Reference: 'OpenWSNETT' is mentioned on line 532, but not defined
== Missing Reference: 'IPSO' is mentioned on line 540, but not defined
== Missing Reference: 'TSMP' is mentioned on line 556, but not defined
== Missing Reference: 'TASA-PIMRC' is mentioned on line 586, but not defined
== Missing Reference: 'TASA-SENSORS' is mentioned on line 593, but not
defined
== Missing Reference: 'TASA-WCNC' is mentioned on line 600, but not defined
== Missing Reference: 'PANA' is mentioned on line 615, but not defined
== Unused Reference: 'RFC2119' is defined on line 380, but no explicit
reference was found in the text
== Unused Reference: 'I-D.thubert-roll-forwarding-frags' is defined on line
440, but no explicit reference was found in the text
== Unused Reference: 'I-D.tsao-roll-security-framework' is defined on line
445, but no explicit reference was found in the text
== Unused Reference: 'I-D.thubert-roll-asymlink' is defined on line 451,
but no explicit reference was found in the text
== Unused Reference: 'I-D.ietf-roll-terminology' is defined on line 456,
but no explicit reference was found in the text
== Unused Reference: 'I-D.ietf-roll-p2p-rpl' is defined on line 461, but no
explicit reference was found in the text
== Unused Reference: 'I-D.ietf-roll-trickle-mcast' is defined on line 467,
but no explicit reference was found in the text
== Unused Reference: 'I-D.thubert-6lowpan-backbone-router' is defined on
line 473, but no explicit reference was found in the text
== Unused Reference: 'I-D.sarikaya-core-sbootstrapping' is defined on line
478, but no explicit reference was found in the text
== Unused Reference: 'I-D.gilger-smart-object-security-workshop' is defined
on line 485, but no explicit reference was found in the text
== Unused Reference: 'I-D.phinney-roll-rpl-industrial-applicability' is
defined on line 491, 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-10
== 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 (~~), 36 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 8, 2013
5 Expires: August 12, 2013
7 Using IEEE802.15.4e TSCH in an LLN context:
8 Overview, Problem Statement and Goals
9 draft-watteyne-6tsch-tsch-lln-context-00
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 12, 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. Secure Communication . . . . . . . . . . . . . . . . . . . 9
62 4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
63 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
65 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
66 6.2. Informative References . . . . . . . . . . . . . . . . . . 12
67 6.3. External Informative References . . . . . . . . . . . . . 14
68 Appendix A. TSCH Protocol Highlights . . . . . . . . . . . . . . 18
69 A.1. Timeslots . . . . . . . . . . . . . . . . . . . . . . . . 18
70 A.2. Slotframes . . . . . . . . . . . . . . . . . . . . . . . . 18
71 A.3. Mote Communication Schedule . . . . . . . . . . . . . . . 18
72 A.4. Links and Paths . . . . . . . . . . . . . . . . . . . . . 19
73 A.5. Dedicated vs. Shared Slots . . . . . . . . . . . . . . . . 19
74 A.6. Absolute Slot Number . . . . . . . . . . . . . . . . . . . 20
75 A.7. Channel Hopping . . . . . . . . . . . . . . . . . . . . . 20
76 A.8. Time Synchronization . . . . . . . . . . . . . . . . . . . 21
77 A.9. Power Consumption . . . . . . . . . . . . . . . . . . . . 21
78 A.10. Network Communication Schedule . . . . . . . . . . . . . . 21
79 A.11. Join Process . . . . . . . . . . . . . . . . . . . . . . . 22
80 A.12. Information Elements . . . . . . . . . . . . . . . . . . . 22
81 A.13. Extensibility . . . . . . . . . . . . . . . . . . . . . . 23
82 Appendix B. TSCH Gotchas . . . . . . . . . . . . . . . . . . . . 24
83 B.1. Collision Free Communication . . . . . . . . . . . . . . . 24
84 B.2. Multi-Channel vs. Channel Hopping . . . . . . . . . . . . 24
85 B.3. Cost of (continuous) Synchronization . . . . . . . . . . . 24
86 B.4. Topology Stability . . . . . . . . . . . . . . . . . . . . 24
87 B.5. Multiple Concurrent Slotframes . . . . . . . . . . . . . . 25
88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
90 1. Introduction
92 The IEEE802.15.4e standard [IEEE802154e] was published in 2012 as an
93 amendment to the Medium Access Control (MAC) protocol of the
94 IEEE802.15.4-2011 [IEEE802154] standard. The Timeslotted Channel
95 Hopping (TSCH) mode of the IEEE802.15.4e standard is the object of
96 this document.
98 TSCH was designed to "allow IEEE802.15.4 devices to support a wide
99 range of industrial applications" [IEEE802154e]. At its core is a
100 medium access technique which uses time synchronization to achieve
101 ultra low-power operation and channel hopping to enable high
102 reliability. This is very different from the "legacy" IEEE802.15.4
103 MAC protocol, and is therefore better described as a "redesign".
104 TSCH does not amend the physical layer; i.e. it can operate on any
105 IEEE802.15.4-compliant hardware.
107 IEEE802.15.4e can be seen as the latest generation of ultra-lower
108 power and reliable networking solutions for LLNs. Its core
109 technology is similar to the one used in industrial networking
110 technologies such as WirelessHART [WHART] or ISA100.11a [ISA100].
111 These protocol solutions have been targeted essentially at the
112 industrial market. WirelessHART is for example the wireless
113 extension of HART, a long standing protocol suite for networking
114 industrial equipment.
116 [RFC5673] discusses industrial applications, and highlights the harsh
117 operating conditions as well as the stringent reliability,
118 availability and security requirements for an LLN to operate in an
119 industrial environment. Industrial protocols such as WirelessHART
120 satisfy those requirements, and with tens of thousands of networks
121 deployed [Emerson], these types of networks have a large impact on
122 industrial applications. Commercial networking solutions are
123 available today in which motes consume 10's of micro-amps on average
124 [CurrentCalculator] with end-to-end packet delivery ratios over
125 99.999% [Doherty].
127 IEEE802.15.4e builds on the same foundations as WirelessHART, and
128 therefore exhibits similar performance. Yet, unlike an industrial
129 protocol which is, by nature, application-specific, IEEE802.15.4e
130 TSCH focuses on the MAC layer only. This clean layering allows for
131 TSCH to fit under an IPv6 enabled protocol stack for LLNs, running
132 6LoWPAN [RFC6282], RPL [RFC6550] and CoAP [I-D.ietf-core-coap].
134 Bringing industrial-like performance into the LLN stack developed by
135 the 6LoWPAN, ROLL and CORE working groups will open up new
136 application domains for these networks. Sensors deployed in smart
137 cities [RFC5548] will be able to be installed for years without
138 needing battery replacement. "Umbrella" networks will interconnect
139 smart elements from different entities in smart buildings [RFC5867].
140 Peel-and-stick switches will obsolete the need for costly conduits
141 for lighting solutions in smart homes [RFC5826].
143 While [IEEE802154e] defines the mechanisms for a TSCH mote to
144 communicate, it does not define the policies to build and maintain
145 the communication schedule, match that schedule to the multi-hop
146 paths maintained by RPL, adapt the resources allocated between
147 neighbor nodes to the data traffic flows, enforce a differentiated
148 treatment for data generated at the application layer and signaling
149 messages needed by 6LoWPAN and RPL to discover neighbors, react to
150 topology changes, self-configuring IP addresses, or manage keying
151 material.
153 2. TSCH in the LLN Context
155 In many cases, to map the services required by the IP layer to the
156 services provided by the link layer, an adaptation layer is used
157 [palattella12standardized]. The 6LoWPAN working group has started in
158 2007 to work on specifications for transmitting IPv6 over
159 IEEE802.15.4 networks [RFC4919]. Typically, low-power WPANs are
160 characterized by small packet sizes, support for addresses with
161 different lengths, low bandwidth, star and mesh topologies, battery
162 powered devices, low cost, large number of devices, unknown node
163 positions, high unreliability, and periods during which communication
164 interfaces are turned off to save energy. Given these features, it
165 is clear that the adoption of IPv6 on top of a Low-Power WPAN is not
166 straightforward, but poses strong requirements for the optimization
167 of this adaptation layer. For instance, due to the IPv6 default
168 minimum MTU size (1280 bytes), an un-fragmented IPv6 packet would be
169 too large to fit in an IEEE802.15.4 frame. Moreover, the overhead
170 due to the 40-byte long IPv6 header would waste the scarce bandwidth
171 available at the PHY layer [RFC4944]. For these reasons, the 6LoWPAN
172 working group has defined an effective adaptation layer [RFC6568].
173 Further issues encompass the auto-configuration of IPv6 addresses
174 [RFC2464][RFC6755], the compliance with the recommendation on
175 supporting link-layer subnet broadcast in shared networks [RFC3819],
176 the reduction of routing and management overhead [RFC6606], the
177 adoption of lightweight application protocols (or novel data encoding
178 techniques), and the support for security mechanisms (confidentiality
179 and integrity protection, device bootstrapping, key establishment,
180 and management).
182 These features can run on top of TSCH. There are, however, important
183 issues to solve, as highlighted in Section 3.
185 Routing issues are challenging for 6LoWPAN, given the low-power and
186 lossy radio-links, the battery supplied nodes, the multi-hop mesh
187 topologies, and the frequent topology changes due to mobility.
188 Successful solutions take into account the specific application
189 requirements, along with IPv6 behavior and 6LoWPAN mechanisms
190 [palattella12standardized]. The ROLL working group has defined RPL
191 in [RFC6550]. RPL can support a wide variety of link layers,
192 including ones that are constrained, potentially lossy, or typically
193 utilized in conjunction with host or router devices with very limited
194 resources, as in building/home automation [RFC5867][RFC5826],
195 industrial environments [RFC5673], and urban applications [RFC5548].
196 It is able to quickly build up network routes, to distribute routing
197 knowledge among nodes, and to adapt the topology. In a typical
198 setting, motes are connected through multi-hop paths to a small set
199 of root devices, which are usually responsible for data collection
200 and coordination duties. For each of them, a Destination Oriented
201 Directed Acyclic Graph (DODAG) is created by accounting for link
202 costs, node attributes/status information, and an Objective Function,
203 which maps the optimization requirements of the target scenario. The
204 topology is set-up based on a Rank metric, which encodes the distance
205 of each node with respect to its reference root, as specified by the
206 Objective Function. Regardless of the way it is computed, the Rank
207 monotonically decreases along the DODAG towards the destination,
208 following a gradient-based approach. RPL encompasses different kinds
209 of traffic and signaling information. Multipoint-to-Point (MP2P) is
210 the dominant traffic in LLN applications. Data is routed towards
211 nodes with some application relevance, such as the LLN gateway to the
212 larger Internet, or to the core of private IP networks. In general,
213 these destinations are the DODAG roots and they act as data
214 collection points for distributed monitoring applications. Point-to-
215 Multipoint (P2MP) data streams are used for actuation purposes, where
216 messages are sent from DODAG roots to destination nodes. Point-to-
217 Point (P2P) traffic allows communication between two devices
218 belonging to the same LLN, e.g. a sensor and an actuator. A packet
219 will flow from the source towards the common ancestor of those two
220 communicating devices, then downward towards the destination. As an
221 consequence, RPL has to discover both upward routes (i.e., from nodes
222 to DODAG roots) in order to enable MP2P and P2P flows, and downward
223 routes (i.e., from DODAG roots to nodes) to support P2MP and P2P
224 traffic.
226 Section 3 highlights the challenges that need to be addressed to use
227 RPL on top of TSCH.
229 Several open-source initiatives have emerged around TSCH. The
230 OpenWSN project [OpenWSN][OpenWSNETT] is an open-source
231 implementation of a fully standards-based protocol stack, which aims
232 at evaluating the applicability of TSCH to different applications.
233 This implementation was used as the foundation for an IP for Smart
234 Objects Alliance (IPSO) [IPSO] iteroperability demo in 2011. In the
235 absence of a standardized scheduling mechanism for TSCH, a "slotted
236 Aloha" schedule was used.
238 3. Problems and Goals
240 As highlighted in Appendix A, TSCH is different for traditional low-
241 power MAC protocols because of its scheduled nature. TSCH defines
242 the mechanisms to execute a communication schedule, but it is the
243 entity that sets up that schedule which controls the topology of the
244 network, and the resources allocated to each link in that topology.
246 How this entity should operate is out of scope of TSCH. The
247 remainder of this section highlights the problems this entity needs
248 to address. For simplicity, we will refer to this entity by the
249 generic name "6TSCH", without loss of generality. In particular, we
250 do not assume the nature of 6TSCH, whether an adaptation layer, a
251 distributed reservation protocol, a centralized path computation
252 engine, or any combination thereof.
254 3.1. Network Formation
256 6TSCH needs to control the way the network is formed, including how
257 new motes join, and how already joined motes advertise the presence
258 of the network. 6TSCH needs to:
260 1. Define the Information Elements to include in Enhanced Beacons
261 advertising the presence of the network.
263 2. For a new mote, define rules to process and filter received
264 Enhanced Beacons. This includes a mechanism to select the best
265 mote to join the network through.
267 3. Define the joining procedure. This includes a mechanism to
268 assign a unique 16-bit address to a mote, and the management of
269 initial keying material.
271 3.2. Network Maintenance
273 Once a network is formed, 6TSCH needs to maintain the network's
274 health, allowing for motes to stay synchronized. 6TSCH needs to:
276 1. Manage each mote's time source neighbor(s).
278 2. Define a mechanism for a mote to update the join priority it
279 announces in its Enhanced Beacon.
281 3. Schedule transmissions of an Enhanced Beacon to advertise the
282 presence of the network.
284 3.3. Multi-Hop Topology
286 RPL, given a weighted connectivity graph, determines multi-hop
287 routes. 6TSCH needs to:
289 1. Define a mechanism whereby it gathers topological information,
290 which it can then feed to RPL.
292 2. Ensure that the TSCH schedule contains links along the multi-hop
293 routes identified by RPL.
295 3. Where applicable, maintain independent sets of links to transport
296 independent flows of data.
298 3.4. Routing and Timing Parents
300 At all times, a TSCH mote needs to have at least one time source
301 neighbor it can synchronize to. 6TSCH therefore needs to assign time
302 source neighbors to allow for correct operation of the TSCH network.
303 These time source neighbors could, or not, be related to RPL time
304 parents.
306 3.5. Resource Management
308 A link in a TSCH schedule is a "unit" of resource. The number of
309 links to assign between neighbor motes needs to be appropriate for
310 the size of the traffic flow. 6TSCH needs to:
312 1. Define rules on when to create or delete a slotframes.
314 2. Define rules to determine the length of a slotframe, and the
315 trigger to modify the length of a slotframe.
317 3. Define rules on when to add or delete links in a particular
318 slotframe.
320 4. Define a mechanism for neighbor nodes to exchange information
321 about their schedule and, if applicable, negotiate the addition/
322 deletion of links.
324 5. Allow for a (possibly centralized) entity to take full control
325 over the schedule.
327 6. Define a set of metrics to evaluate the tradeoff between latency,
328 bandwidth and energy consumption achieved by a particular
329 schedule.
331 3.6. Dataflow Control
333 TSCH defines mechanisms for a mote to signal it cannot accept an
334 incoming packet. It does not, however, define the policy which
335 determines when not to accept. 6TSCH need to:
337 1. Define a queueing policy for incoming and outgoing packets.
339 2. Manage the buffer space and indicate to TSCH when to stop
340 accepting incoming packet.
342 3. Handle transmissions that have failed.
344 3.7. Secure Communication
346 Given some keying material, TSCH defines mechanisms to encrypt and
347 authenticate MAC frames. It does not define how this keying material
348 is generated. 6TSCH need to:
350 1. Define the keying material and authentication mechanism needed by
351 a new mote to join an existing network.
353 2. Define a mechanism to allow for the secure transfer of
354 application data between neighbor motes.
356 3. Define a mechanism to allow for the secure transfer of signaling
357 data between motes and 6TSCH.
359 4. Contributors
361 Maria Rita Palattella
362 SnT/University of Luxembourg
364 maria-rita.palattella@uni.lu
366 Luigi Alfredo Grieco
367 Politecnico di Bari
369 a.grieco@poliba.it
371 5. Acknowledgements
373 Special thanks to Jonathan Simon for his review and valuable
374 comments.
376 6. References
378 6.1. Normative References
380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
381 Requirement Levels", BCP 14, RFC 2119, March 1997.
383 6.2. Informative References
385 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
386 Networks", RFC 2464, December 1998.
388 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
389 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
390 Wood, "Advice for Internet Subnetwork Designers", BCP 89,
391 RFC 3819, July 2004.
393 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
394 over Low-Power Wireless Personal Area Networks (6LoWPANs):
395 Overview, Assumptions, Problem Statement, and Goals",
396 RFC 4919, August 2007.
398 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
399 "Transmission of IPv6 Packets over IEEE 802.15.4
400 Networks", RFC 4944, September 2007.
402 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
403 "Routing Requirements for Urban Low-Power and Lossy
404 Networks", RFC 5548, May 2009.
406 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
407 Routing Requirements in Low-Power and Lossy Networks",
408 RFC 5826, April 2010.
410 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
411 "Building Automation Routing Requirements in Low-Power and
412 Lossy Networks", RFC 5867, June 2010.
414 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney,
415 "Industrial Routing Requirements in Low-Power and Lossy
416 Networks", RFC 5673, October 2009.
418 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
419 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
420 September 2011.
422 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
423 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
425 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
426 Lossy Networks", RFC 6550, March 2012.
428 [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and
429 Application Spaces for IPv6 over Low-Power Wireless
430 Personal Area Networks (6LoWPANs)", RFC 6568, April 2012.
432 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
433 Statement and Requirements for IPv6 over Low-Power
434 Wireless Personal Area Network (6LoWPAN) Routing",
435 RFC 6606, May 2012.
437 [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
438 for OAuth", RFC 6755, October 2012.
440 [I-D.thubert-roll-forwarding-frags]
441 Thubert, P. and J. Hui, "LLN Fragment Forwarding and
442 Recovery", draft-thubert-roll-forwarding-frags-00 (work in
443 progress), March 2012.
445 [I-D.tsao-roll-security-framework]
446 Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A
447 Security Framework for Routing over Low Power and Lossy
448 Networks", draft-tsao-roll-security-framework-02 (work in
449 progress), March 2010.
451 [I-D.thubert-roll-asymlink]
452 Thubert, P., "RPL adaptation for asymmetrical links",
453 draft-thubert-roll-asymlink-02 (work in progress),
454 December 2011.
456 [I-D.ietf-roll-terminology]
457 Vasseur, J., "Terminology in Low power And Lossy
458 Networks", draft-ietf-roll-terminology-10 (work in
459 progress), January 2013.
461 [I-D.ietf-roll-p2p-rpl]
462 Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J.
463 Martocci, "Reactive Discovery of Point-to-Point Routes in
464 Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-16
465 (work in progress), February 2013.
467 [I-D.ietf-roll-trickle-mcast]
468 Hui, J. and R. Kelsey, "Multicast Protocol for Low power
469 and Lossy Networks (MPL)",
470 draft-ietf-roll-trickle-mcast-03 (work in progress),
471 January 2013.
473 [I-D.thubert-6lowpan-backbone-router]
474 Thubert, P., "6LoWPAN Backbone Router",
475 draft-thubert-6lowpan-backbone-router-02 (work in
476 progress), June 2010.
478 [I-D.sarikaya-core-sbootstrapping]
479 Sarikaya, B., Ohba, Y., Moskowitz, R., Cao, Z., and R.
480 Cragie, "Security Bootstrapping Solution for Resource-
481 Constrained Devices",
482 draft-sarikaya-core-sbootstrapping-04 (work in progress),
483 April 2012.
485 [I-D.gilger-smart-object-security-workshop]
486 Gilger, J. and H. Tschofenig, "Report from the 'Smart
487 Object Security Workshop', 23rd March 2012, Paris,
488 France", draft-gilger-smart-object-security-workshop-00
489 (work in progress), October 2012.
491 [I-D.phinney-roll-rpl-industrial-applicability]
492 Phinney, T., Thubert, P., and R. Assimiti, "RPL
493 applicability in industrial networks",
494 draft-phinney-roll-rpl-industrial-applicability-01 (work
495 in progress), October 2012.
497 [I-D.ietf-core-coap]
498 Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
499 "Constrained Application Protocol (CoAP)",
500 draft-ietf-core-coap-13 (work in progress), December 2012.
502 6.3. External Informative References
504 [IEEE802154e]
505 IEEE standard for Information Technology, "IEEE std.
506 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
507 Networks (LR-WPANs) Amendament 1: MAC sublayer",
508 April 2012.
510 [IEEE802154]
511 IEEE standard for Information Technology, "IEEE std.
512 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
513 and Physical Layer (PHY) Specifications for Low-Rate
514 Wireless Personal Area Networks", June 2011.
516 [WHART] www.hartcomm.org, "Highway Addressable Remote Transducer,
517 a group of specifications for industrial process and
518 control devices administered by the HART Foundation".
520 [ISA100] ISA, "ISA100, Wireless Systems for Automation", May 2008,
521 < http://www.isa.org/Community/
522 SP100WirelessSystemsforAutomation>.
524 [Emerson] Emerson Process Management, "Emerson Process Management
525 Smart Wireless Homepage", < http://
526 www2.emersonprocess.com/en-US/plantweb/wireless/Pages/
527 WirelessHomePage-Flash.aspx>.
529 [OpenWSN] "Berkeley's OpenWSN Project Homepage",
530 .
532 [OpenWSNETT]
533 Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F.,
534 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN:
535 a standards-based low-power wireless development
536 environment", Transactions on Emerging Telecommunications
537 Technologies 2012, August 2012, .
540 [IPSO] "IP for Smart Objects Alliance Homepage",
541 .
543 [CurrentCalculator]
544 Linear Technology, "Application Note: Using the Current
545 Calculator to Estimate Mote Power", August 2012, .
550 [doherty07channel]
551 Doherty, L., Lindsay, W., and J. Simon, "Channel-Specific
552 Wireless Sensor Network Path Data", IEEE International
553 Conference on Computer Communications and Networks
554 (ICCCN) 2008, 2007.
556 [TSMP] Pister, K. and L. Doherty, "TSMP: Time Synchronized Mesh
557 Prootocol", International Symposium on Distributed Sensor
558 Networks (DSN) 2008, Nov. 2008, < http://
559 robotics.eecs.berkeley.edu/~pister/publications/2008/
560 TSMP%20DSN08.pdf>.
562 [tinka10decentralized]
563 Tinka, A., Watteyne, T., and K. Pister, "A Decentralized
564 Scheduling Algorithm for Time Synchronized Channel
565 Hopping", Ad Hoc Networks 2010, 2010, < http://
566 robotics.eecs.berkeley.edu/~pister/publications/2008/
567 TSMP%20DSN08.pdf>.
569 [watteyne09reliability]
570 Watteyne, T., Mehta, A., and K. Pister, "Reliability
571 Through Frequency Diversity: Why Channel Hopping Makes
572 Sense", International Conference on Performance Evaluation
573 of Wireless Ad Hoc, Sensor, and Ubiquitous Networks (PE-
574 WASUN) 2009, Oct. 2009, .
577 [kerkez09feasibility]
578 Kerkez, B., Watteyne, T., and M. Magliocco, "Feasibility
579 analysis of controller design for adaptive channel
580 hopping", International Workshop on Performance
581 Methodologies and Tools for Wireless Sensor Networks
582 (WSNPERF) 2009, Oct. 2009, .
586 [TASA-PIMRC]
587 Palattella, MR., Accettura, N., Dohler, M., Grieco, LA.,
588 and G. Boggia, "Traffic Aware Scheduling Algorithm for
589 Multi-Hop IEEE 802.15.4e Networks", IEEE PIMRC 2012,
590 Sept. 2012, < http://www.cttc.es/resources/doc/
591 120531-submitted-tasa-25511.pdf>.
593 [TASA-SENSORS]
594 Palattella, MR., Accettura, N., Dohler, M., Grieco, LA.,
595 and G. Boggia, "Traffic-Aware Time-Critical Scheduling In
596 Heavily Duty-Cycled IEEE 802.15.4e For An Industrial IoT",
597 IEEE SENSORS 2012, Oct. 2012, < http://www.cttc.es/
598 resources/doc/120821-sensors2012-4396981770946977737.pdf>.
600 [TASA-WCNC]
601 Accettura, N., Palattella, MR., Dohler, M., Grieco, LA.,
602 and G. Boggia, "Standardized Power-Efficient and Internet-
603 Enabled Communication Stack for Capillary M2M Networks",
604 IEEE WCNC 2012, Apr. 2012, < http://www.cttc.es/resources/
605 doc/120109-1569521283-submitted-58230.pdf>.
607 [palattella12standardized]
608 Palattella, MR., Accettura, N., Vilajosana, X., Watteyne,
609 T., Grieco, LA., Boggia, G., and M. Dohler, "Standardized
610 Protocol Stack For The Internet Of (Important) Things",
611 IEEE Communications Surveys and Tutorials 2012, Dec. 2012,
612 < http://www.cttc.es/resources/doc/
613 121025-completestackforiot-clean-4818610916636121981.pdf>.
615 [PANA] Kanda, M., Ohba, Y., Das, S., and S. Chasko, "PANA
616 applicability in constrained environments", Febr. 2012, .
620 Appendix A. TSCH Protocol Highlights
622 This appendix gives an overview of the key features of the
623 IEEE802.15.4e Timeslotted Channel Hopping (TSCH) amendment. It makes
624 no attempt at repeating the standard, but rather focuses on the
625 following:
627 o Concepts which are sufficiently different from traditional
628 IEEE802.15.4 networking that they may need to be defined and
629 presented precisely.
631 o Techniques and ideas which are part of IEEE802.15.4e and which
632 might be useful for the work of 6TSCH.
634 A.1. Timeslots
636 All motes in a TSCH network are synchronized. Time is sliced up into
637 time slots. A time slot is long enough for a MAC frame of maximum
638 size to be sent from mote A to mote B, and for mote B to reply with
639 an acknowledgment (ACK) frame indicating successful reception.
641 The duration of a timeslot is not defined by the standard. With
642 IEEE802.15.4-compliant radios operating in the 2.4GHz frequency band,
643 a maximum-length frame of 127 bytes takes about 4ms to transmit; a
644 shorter ACK takes about 1ms. With a 10ms slot (a typical duration),
645 this leaves 5ms to radio turnaround, packet processing and security
646 operations.
648 A.2. Slotframes
650 Timeslots are grouped into one of more slotframes. A slotframe
651 continuously repeats over time. TSCH does not impose any slotframe
652 size. Depending on the application needs, these can range from 10s
653 to 1000s of timeslots. The shorter the slotframe, the more often a
654 timeslot repeats, resulting in more available bandwidth, but also in
655 a higher power consumption.
657 A.3. Mote Communication Schedule
659 A communication schedule instructs each mote what to do in each slot:
660 transmit, receive or sleep. The schedule indicates, for each active
661 (transmit or receive) timeslot a channelOffset and the address of the
662 neighbor to communicate with.
664 Once a mote obtains its schedule, it executes it:
666 o For each transmit slot, the mote checks whether there is a packet
667 in the outgoing buffer which matches the neighbor written in the
668 schedule information for that slot. If there is none, the mote
669 keeps its radio off for the duration of the slot. If there is
670 one, the mote can ask for the neighbor to acknowledge it, in which
671 case it has to listen for the acknowledgment after the
672 transmission.
674 o For each receive slot, the mote listens for possible incoming
675 packets. If none is received after some listening period, it
676 shuts down its radio. If a packet is received, addressed to the
677 mote, and passes security checks, the mote typically sends back
678 and aknowledgment.
680 How the schedule is built, updated and maintained, and by which
681 entity, is outside of the scope of the IEEE802.15.4e standard.
683 A.4. Links and Paths
685 Assuming the schedule is well built, if mote A is scheduled to
686 transmit to mote B at slotOffset 5 and channelOffset 11, mote B will
687 be scheduled to receive from mote A at the same slotOffset and
688 channelOffset.
690 A single slot of the schedule (i.e., a single cell of the grid),
691 characterized by a slotOffset and channelOffset, and reserved for
692 mote A to transmit to mote B (or for mote B to receive from mote A),
693 is called a "link".
695 If there is a lot of data flowing from mote A to mote B, the schedule
696 might contain multiple slots from A to B, at different times.
697 Multiple links scheduled to the same neighbor are typically
698 equivalent, i.e. the MAC layer sends the packet on whichever of these
699 links happens to show up after the packet was put in the MAC queue.
700 The union of all links between two neighbors, A and B, is called a
701 "path". Since the slotframe repeats over time (and the length of the
702 slotframe is typically constant), each link gives a "quantum" of
703 bandwidth to a given neighbor. Modifying the number of links in a
704 path modify the amount of resources allocated between two neighbors.
706 A.5. Dedicated vs. Shared Slots
708 By default, each transmit timeslot within the TSCH schedule is
709 dedicated, i.e., reserved only for mote A to transmit to mote B.
710 IEEE802.15.4e allows also to mark a slot as shared. In a shared
711 slot, multiple motes can transmit at the same time, on the same
712 fequency. To avoid contention, TSCH defines a back-off algorithm for
713 shared slots.
715 A slot can be marked as both transmitting and receiving. In this
716 case, a mote transmits if it has an appropriate packet in its output
717 buffer, or listens otherwise. Marking a slot as
718 [transmit,shared,receive] results in slotted-Aloha behavior.
720 A.6. Absolute Slot Number
722 TSCH defines a timeslot counter called Absolute Slot Number (ASN).
723 When a new network is created, the ASN is initialized to 0; from then
724 on it increments by 1 at each timeslot. In detail:
726 ASN = (k*S+t)
728 where S is the slotframe size and k the slotframe cycle (i.e., the
729 number of slotframe occurences over time). A mote learns the current
730 ASN when it joins the network. Since motes are synchronized, they
731 all know the current value of the ASN, and any time. The ASN is
732 encoded as a 5-byte number: this allows it to increment for hundreds
733 of years (the exact value depends on the duration of a timeslot)
734 without wrapping. The ASN is used (i) to calculate the frequency to
735 communicate on, jointly with the channelOffset, (ii) to build unique
736 security nonce counters, when the CCM* mode is activated.
738 A.7. Channel Hopping
740 For each active slot, the schedule specifies a timeOffset and a
741 channelOffset. In a well-built schedule, when mote A has a transmit
742 slot to mote B on channelOffset 5, mote B has a receive slot from
743 mote A on the same channelOffset. The channelOffset, is translated
744 by both nodes into a frequency using the following function:
746 frequency = F {(ASN + channelOffset) mod nCh}
748 The function F consists of a look-up table containing the set of
749 available channels. The value nCh (the number of available
750 frequencies) is the size of this look-up table. There are as many
751 channelOffset values as there are frequencies available (e.g. 16 when
752 using IEEE802.15.4-compliant radios at 2.4GHz, when all channels are
753 used). Since both motes have the same channelOffset written in their
754 schedule for that timeslot, and the same ASN counter since they are
755 synchronized, they compute the same frequency. At the next iteration
756 (cycle) of the slotframe, however, the channelOffset will be the
757 same, but the ASN will have changed, resulting in the computation of
758 a different frequency. If the slotframe size, S (used for computing
759 ASN), and the number of channel offsets, nCh, are relatively prime,
760 the translation function ensures that each link rotates through k
761 available channels over k slotframe cycles. This results in "channel
762 hopping": even with a static schedule, pairs of neighbors "hop"
763 between the different frequencies when communicating.
765 The look-up table F can be built to contain only a subset of all
766 available channels. This results in "blacklisting".
768 Channel hopping is a technique known to efficiently combat multi-path
769 fading and external interference. This results in a TSCH network
770 having a more stable topology than if only a single channel were used
771 for the entire network.
773 A.8. Time Synchronization
775 Because of the slotted nature of communication in a TSCH network,
776 motes have to maintain tight synchronization. All motes are assumed
777 to be equipped with clocks to keep track of time (32kHz crystal
778 oscillators are typically used). Yet, because clocks in different
779 motes drift with respect to one another, neighbor motes need to
780 periodically re-synchronize.
782 TSCH adds timing information in all packets that are exchanged (both
783 data and ACK frames). This means that neighbor motes can
784 resynchronize to one another whenever they exchange data. The
785 schedule of a mote indicates which of its neighbor(s) are its "time
786 source neighbors". When a mote communicates with one of its time
787 source neighbors, it uses the timing information in the exchanged
788 frames to realign its clock to its neighbor's.
790 It is up to the entity that manages the schedule to assign adequate
791 time source neighbor(s) to each mote. It is important to avoid
792 synchronization loops, which could result in the formation of
793 independent clusters of motes.
795 A.9. Power Consumption
797 There are only a handful of activities a mote can perform during a
798 timeslot: transmit, receive, or sleep. Depending on the the hardware
799 used, each of these operations has some energy cost associated to
800 them. Given the schedule of a mote, it is straighforward to
801 calculate the expected average power consumption of that mote.
803 A.10. Network Communication Schedule
805 The schedule defines entirely the synchronization and communication
806 between motes. By adding/removing link between neighbors, one can
807 adapt a schedule to the needs of the application. Intuitive examples
808 are:
810 o Make the schedule "sparse" for applications where motes need to
811 consume as little as possible, at the price of reduced bandwidth.
813 o Make the schedule "dense" for applications where motes generate a
814 lot of data, at the price of increased power consumption.
816 o Add more links along a multi-hop route over which many packets
817 flow.
819 A.11. Join Process
821 Motes already part of the network can periodically send Enhanced
822 Beacon (EB) frames to announce the presence the network. These
823 contain information about the size of the timeslot used in the
824 network, the current ASN, information about the slotframes and
825 timeslots the beaconing mote is listening on, and a 1-byte join
826 priority. This join priority corresponds to the number of hops
827 separating the mote sending the EB, and the PAN coordinator. Because
828 of the channel hopping nature of TSCH, these EB frames are sent on
829 all frequencies.
831 A mote wishing to join the network listens on some frequency for EBs.
832 It can wait to receive multiple, and can use the join priority in
833 those EBs to identify the best mote to join the network through.
834 Using the ASN and the other timing information of the EB, the new
835 mote synchronizes to the network. Using the slotframe and link
836 information from te EB, it knows how to contact the mote it just
837 joined.
839 The TSCH standard does not define the steps beyond this "kickstart".
840 These steps can include a security handshake and the addition of more
841 communication links to the new mote's schedule.
843 A.12. Information Elements
845 TSCH introduces the concept of Information Elements (IES). An
846 information element is a list of Type-Length-Value containers placed
847 at the end of the MAC header. A small number of types are defined
848 for TSCH (e.g., the ASN in the EB is contained in an IE), but an
849 unmanaged range is available for extensions.
851 A bit in the MAC header indicates whether the frame contains IEs.
852 IEs are grouped into Header IEs, consumed by the MAC layer and
853 therefore typically invisible to the next higher layer, and Payload
854 IEs, which are passed untouched to the next higher layer, possibly
855 followed by regular payload. Payload IEs can therefore be used for
856 the next higher layers of two neighbor motes to exchange information.
858 A.13. Extensibility
860 The TSCH standard is designed to be extensible. It introduces the
861 mechanisms as "building block" (e.g. links, frame, etc.), but leaves
862 entire freedom to the upper layer to assemble those. The MAC
863 protocol can be extended by defining new Header IEs. An intermediate
864 layer can be defined to manage the MAC layer by defining Payload IEs.
866 Appendix B. TSCH Gotchas
868 This section lists features of TSCH which we believe are important
869 and beneficial to the work of 6TSCH.
871 B.1. Collision Free Communication
873 TSCH allows you to easily design a schedule which yields collision-
874 free communication. This is done by building the schedule in such a
875 way that at most one link occupies each slotOffset/channelOffset
876 cell. Multiple pairs of neighbor motes can exchange data at the same
877 time, but on different frequencies. If a deployment is done over a
878 large area, slotOffset/channelOffset cells can be reused by pairs of
879 neigbors sufficiently far appart not to interfere.
881 B.2. Multi-Channel vs. Channel Hopping
883 A TSCH schedule looks like a matrix of width "slotFrame length" and
884 height "number of channels". For a scheduling algorithm, these can
885 be considered atomic "units" to schedule. In particular, because of
886 the channel hopping nature of TSCH, the scheduling algorithm should
887 not worry about the actual frequency communication happens on, since
888 it changes at each slotFrame iteration.
890 B.3. Cost of (continuous) Synchronization
892 In the absence of data traffic, a mote is required to synchronize to
893 its time source neighbor(s) periodically not to drift in time. The
894 period at which this needs to happen depends on the stability of the
895 clock source, and on how "early" each mote starts listening for data
896 (the "guard time"). Theoretically, with a 10ppm clock and a 1ms
897 guard time, this period can be 100s. Resynchronizing consists in
898 sending any valid frame to the time source neighbor and using the
899 timing information in the ACK to realign the clocks. If this
900 exchange causes the mote's radio to be on for 5ms, this yields a
901 radio duty cycle needed to keep synchronized of 5ms/100s=0.005%.
902 While TSCH does requires motes to resynchronize periodically, the
903 cost of doing so in almost negligible.
905 B.4. Topology Stability
907 The channel hopping nature of TSCH causes links to be very "stable".
908 Wireless phenomena such as multi-path fading and external
909 interference impact a wireless link between two motes differently on
910 each frequency. It a transmission from mote A to mote B fails,
911 retransmitting on a different frequency has a higher likelihood of
912 succeeding that retransmitting on the same frequency. As a result,
913 even when some frequencies are "behaving bad", channel hopping
914 "smoothens" the contribution of each frequency, resulting in more
915 stable links, and therefore a more stable topology.
917 B.5. Multiple Concurrent Slotframes
919 The TSCH standard allows for multiple slotframes to coexist in a
920 mote's schedule. It is possible that at some slot, a mote has
921 multiple activities scheduled (e.g. transmit to mote 0xfeed on
922 slotFrame 2, receive from mote 0xbeef on slotFrame 1). To handle
923 this situation, the TSCH standard defines the following precedence
924 rules:
926 1. Transmissions take precedence over receptions;
928 2. Lower slotframe identifiers take precedence over higher slotframe
929 identifiers.
931 In the example above, the mote would transmit to mote 0xfeed on
932 slotFrame 2.
934 Author's Address
936 Thomas Watteyne (editor)
937 Linear Technology
938 30695 Huntwood Avenue
939 Hayward, CA 94544
940 USA
942 Phone: +1 (510) 400-2978
943 Email: twatteyne@linear.com