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