draft-ietf-6tisch-tsch-06.txt   rfc7554.txt 
6TiSCH T. Watteyne, Ed. Internet Engineering Task Force (IETF) T. Watteyne, Ed.
Internet-Draft Linear Technology Request for Comments: 7554 Linear Technology
Intended status: Informational MR. Palattella Category: Informational M. Palattella
Expires: September 10, 2015 University of Luxembourg ISSN: 2070-1721 University of Luxembourg
LA. Grieco L. Grieco
Politecnico di Bari Politecnico di Bari
March 9, 2015 May 2015
Using IEEE802.15.4e TSCH in an IoT context: Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
Overview, Problem Statement and Goals Internet of Things (IoT): Problem Statement
draft-ietf-6tisch-tsch-06
Abstract Abstract
This document describes the environment, problem statement, and goals This document describes the environment, problem statement, and goals
for using the IEEE802.15.4e TSCH MAC protocol in the context of LLNs. for using the Time-Slotted Channel Hopping (TSCH) Medium Access
The set of goals enumerated in this document form an initial set Control (MAC) protocol of IEEE 802.14.4e in the context of Low-Power
only. and Lossy Networks (LLNs). The set of goals enumerated in this
document form an initial set only.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on September 10, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7554.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. TSCH in the LLN Context . . . . . . . . . . . . . . . . . . . 4 2. TSCH in the LLN Context . . . . . . . . . . . . . . . . . . . 5
3. Problems and Goals . . . . . . . . . . . . . . . . . . . . . 6 3. Problems and Goals . . . . . . . . . . . . . . . . . . . . . 7
3.1. Network Formation . . . . . . . . . . . . . . . . . . . . 6 3.1. Network Formation . . . . . . . . . . . . . . . . . . . . 8
3.2. Network Maintenance . . . . . . . . . . . . . . . . . . . 7 3.2. Network Maintenance . . . . . . . . . . . . . . . . . . . 8
3.3. Multi-Hop Topology . . . . . . . . . . . . . . . . . . . 7 3.3. Multi-Hop Topology . . . . . . . . . . . . . . . . . . . 8
3.4. Routing and Timing Parents . . . . . . . . . . . . . . . 7 3.4. Routing and Timing Parents . . . . . . . . . . . . . . . 8
3.5. Resource Management . . . . . . . . . . . . . . . . . . . 8 3.5. Resource Management . . . . . . . . . . . . . . . . . . . 9
3.6. Dataflow Control . . . . . . . . . . . . . . . . . . . . 8 3.6. Dataflow Control . . . . . . . . . . . . . . . . . . . . 9
3.7. Deterministic Behavior . . . . . . . . . . . . . . . . . 8 3.7. Deterministic Behavior . . . . . . . . . . . . . . . . . 9
3.8. Scheduling Mechanisms . . . . . . . . . . . . . . . . . . 9 3.8. Scheduling Mechanisms . . . . . . . . . . . . . . . . . . 10
3.9. Secure Communication . . . . . . . . . . . . . . . . . . 9 3.9. Secure Communication . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Normative References . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Informative References . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 Appendix A. TSCH Protocol Highlights . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 10 A.1. Time Slots . . . . . . . . . . . . . . . . . . . . . . . 15
Appendix A. TSCH Protocol Highlights . . . . . . . . . . . . . . 13 A.2. Slotframes . . . . . . . . . . . . . . . . . . . . . . . 15
A.1. Timeslots . . . . . . . . . . . . . . . . . . . . . . . . 13 A.3. Node TSCH Schedule . . . . . . . . . . . . . . . . . . . 15
A.2. Slotframes . . . . . . . . . . . . . . . . . . . . . . . 14 A.4. Cells and Bundles . . . . . . . . . . . . . . . . . . . . 16
A.3. Node TSCH Schedule . . . . . . . . . . . . . . . . . . . 14 A.5. Dedicated vs. Shared Cells . . . . . . . . . . . . . . . 17
A.4. Cells and Bundles . . . . . . . . . . . . . . . . . . . . 14 A.6. Absolute Slot Number . . . . . . . . . . . . . . . . . . 17
A.5. Dedicated vs. Shared Cells . . . . . . . . . . . . . . . 15 A.7. Channel Hopping . . . . . . . . . . . . . . . . . . . . . 17
A.6. Absolute Slot Number . . . . . . . . . . . . . . . . . . 15 A.8. Time Synchronization . . . . . . . . . . . . . . . . . . 18
A.7. Channel Hopping . . . . . . . . . . . . . . . . . . . . . 16 A.9. Power Consumption . . . . . . . . . . . . . . . . . . . . 19
A.8. Time Synchronization . . . . . . . . . . . . . . . . . . 16 A.10. Network TSCH Schedule . . . . . . . . . . . . . . . . . . 19
A.9. Power Consumption . . . . . . . . . . . . . . . . . . . . 17 A.11. Join Process . . . . . . . . . . . . . . . . . . . . . . 19
A.10. Network TSCH Schedule . . . . . . . . . . . . . . . . . . 17 A.12. Information Elements . . . . . . . . . . . . . . . . . . 20
A.11. Join Process . . . . . . . . . . . . . . . . . . . . . . 18 A.13. Extensibility . . . . . . . . . . . . . . . . . . . . . . 20
A.12. Information Elements . . . . . . . . . . . . . . . . . . 18 Appendix B. TSCH Features . . . . . . . . . . . . . . . . . . . 21
A.13. Extensibility . . . . . . . . . . . . . . . . . . . . . . 18 B.1. Collision-Free Communication . . . . . . . . . . . . . . 21
Appendix B. TSCH Features . . . . . . . . . . . . . . . . . . . 19 B.2. Multi-Channel vs. Channel Hopping . . . . . . . . . . . . 21
B.1. Collision Free Communication . . . . . . . . . . . . . . 19 B.3. Cost of (Continuous) Synchronization . . . . . . . . . . 21
B.2. Multi-Channel vs. Channel Hopping . . . . . . . . . . . . 19 B.4. Topology Stability . . . . . . . . . . . . . . . . . . . 21
B.3. Cost of (continuous) Synchronization . . . . . . . . . . 19 B.5. Multiple Concurrent Slotframes . . . . . . . . . . . . . 22
B.4. Topology Stability . . . . . . . . . . . . . . . . . . . 20 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
B.5. Multiple Concurrent Slotframes . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
IEEE802.15.4e [IEEE802154e] was published in 2012 as an amendment to IEEE 802.15.4e [IEEE.802.15.4e] was published in 2012 as an amendment
the Medium Access Control (MAC) protocol defined by the to the Medium Access Control (MAC) protocol defined by the IEEE
IEEE802.15.4-2011 [IEEE802154] standard. IEEE802.15.4e will be 802.15.4 standard (of 2011) [IEEE.802.15.4]. IEEE 802.15.4e will be
rolled into the next revision of IEEE802.15.4, scheduled to be rolled into the next revision of IEEE 802.15.4, scheduled to be
published in 2015. The Timeslotted Channel Hopping (TSCH) mode of published in 2015. The Time-Slotted Channel Hopping (TSCH) mode of
IEEE802.15.4e is the object of this document. IEEE 802.15.4e is the object of this document. The term "TSCH"
refers to TSCH as used in [IEEE.802.15.4e].
This document describes the main issues arising from the adoption of This document describes the main issues arising from the adoption of
the IEEE802.15.4e TSCH in the LLN context, following the terminology the TSCH in the LLN context, following the terminology defined in
defined in [I-D.ietf-6tisch-terminology]. Appendix A further gives [TERMS-6TISCH]. Appendix A further gives an overview of the key
an overview of the key features of the IEEE802.15.4e Timeslotted features of the TSCH amendment to IEEE 802.15.4e. Appendix B details
Channel Hopping (TSCH) amendment. Appendix B details features of features of TSCH, which might be interesting for the work of the
IEEE802.15.4e TSCH which might be interesting for the work of the
6TiSCH WG. 6TiSCH WG.
TSCH was designed to allow IEEE802.15.4 devices to support a wide TSCH was designed to allow IEEE 802.15.4 devices to support a wide
range of applications including, but not limited to, industrial ones range of applications including, but not limited to, industrial ones
[IEEE802154e]. At its core is a medium access technique which uses [IEEE.802.15.4e]. At its core is a medium access technique that uses
time synchronization to achieve low power operation and channel time synchronization to achieve low-power operation and channel
hopping to enable high reliability. Synchronization accuracy impacts hopping to enable high reliability. Synchronization accuracy impacts
power consumption, and can vary from micro-seconds to milli-seconds power consumption and can vary from microseconds to milliseconds
depending on the solution. This is very different from the "legacy" depending on the solution. This is very different from the "legacy"
IEEE802.15.4 MAC protocol, and is therefore better described as a IEEE 802.15.4 MAC protocol and is therefore better described as a
"redesign". TSCH does not amend the physical layer; i.e., it can "redesign". TSCH does not amend the physical layer, i.e., it can
operate on any IEEE802.15.4-compliant hardware. operate on any hardware that is compliant with IEEE 802.15.4.
IEEE802.15.4e is the latest generation of ultra-lower power and IEEE 802.15.4e is the latest generation of ultra-lower power and
reliable networking solutions for LLNs. [RFC5673] discusses reliable networking solutions for LLNs. [RFC5673] discusses
industrial applications, and highlights the harsh operating industrial applications and highlights the harsh operating conditions
conditions as well as the stringent reliability, availability, and as well as the stringent reliability, availability, and security
security requirements for an LLN to operate in an industrial requirements for an LLN to operate in an industrial environment. In
environment. In these environments, vast deployment environments these environments, vast deployment environments with large
with large (metallic) equipment cause multi-path fading and (metallic) equipment cause multi-path fading and interference to
interference to thwart any attempt of a single-channel solution to be thwart any attempt of a single-channel solution to be reliable; the
reliable; the channel agility of TSCH is the key to its ultra high channel agility of TSCH is the key to its ultra-high reliability.
reliability. Commercial networking solutions are available today in Commercial networking solutions are available today in which nodes
which nodes consume 10's of micro-amps on average [CurrentCalculator] consume 10's of microamps on average [CurrentCalculator] with end-to-
with end-to-end packet delivery ratios over 99.999% end packet delivery ratios over 99.999% [Doherty07channel].
[doherty07channel].
IEEE802.15.4e has been designed for low-power constrained devices, IEEE 802.15.4e has been designed for low-power constrained devices,
often called "motes". Several terms are used in the IETF to refer to often called "motes". Several terms are used in the IETF to refer to
those devices, including "LLN nodes" [RFC7102] and "constrained those devices, including "LLN nodes" [RFC7102] and "constrained
nodes" [RFC7228]. In this document, we use the generic (and shorter) nodes" [RFC7228]. In this document, we use the generic (and shorter)
term "node", used as a synonym for "LLN node", "constrained node" or term "node", used as a synonym for "LLN node", "constrained node", or
"mote". "mote".
Enabling the LLN protocol stack to operate in industrial environments Enabling the LLN protocol stack to operate in industrial environments
opens up new application domains for these networks. Sensors opens up new application domains for these networks. Sensors
deployed in smart cities [RFC5548] will be able to be installed for deployed in smart cities [RFC5548] will be able to be installed for
years without needing battery replacement. "Umbrella" networks will years without needing battery replacement. "Umbrella" networks will
interconnect smart elements from different entities in smart interconnect smart elements from different entities in smart
buildings [RFC5867]. Peel-and-stick switches will obsolete the need buildings [RFC5867]. Peel-and-stick switches will obsolete the need
for costly conduits for lighting solutions in smart homes [RFC5826]. for costly conduits for lighting solutions in smart homes [RFC5826].
IEEE802.15.4e TSCH focuses on the MAC layer only. This clean TSCH focuses on the MAC layer only. This clean layering allows for
layering allows for TSCH to fit under an IPv6 enabled protocol stack TSCH to fit under an IPv6-enabled protocol stack for LLNs, running an
for LLNs, running 6LoWPAN [RFC6282], IPv6 Routing Protocol for Low IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN)
power and Lossy Networks (RPL) [RFC6550] and the Constrained [RFC6282], the IPv6 Routing Protocol for Low-Power and Lossy Networks
Application Protocol (CoAP) [RFC7252]. What is missing is a (RPL) [RFC6550], and the Constrained Application Protocol (CoAP)
functional entity which is in charge of scheduling TSCH timeslots for [RFC7252]. What is missing is a functional entity that is in charge
frames to be sent on. In this document, we refer to this entity as of scheduling TSCH time slots for frames to be sent on. In this
the "Logical Link Control" (LLC), bearing in mind that realizations document, we refer to this entity as the "Logical Link Control"
of this entity can be of different types, including a distributed (LLC), bearing in mind that realizations of this entity can be of
protocol or a centralized server in charge of scheduling. different types, including a distributed protocol or a centralized
server in charge of scheduling.
While [IEEE802154e] defines the mechanisms for a TSCH node to While [IEEE.802.15.4e] defines the mechanisms for a TSCH node to
communicate, it does not define the policies to build and maintain communicate, it does not define the policies to build and maintain
the communication schedule, match that schedule to the multi-hop the communication schedule, match that schedule to the multi-hop
paths maintained by RPL, adapt the resources allocated between paths maintained by RPL, adapt the resources allocated between
neighbor nodes to the data traffic flows, enforce a differentiated neighbor nodes to the data traffic flows, enforce a differentiated
treatment for data generated at the application layer and signaling treatment for data generated at the application layer and signaling
messages needed by 6LoWPAN and RPL to discover neighbors, react to messages needed by 6LoWPAN and RPL to discover neighbors, react to
topology changes, self-configure IP addresses, or manage keying topology changes, self-configure IP addresses, or manage keying
material. material.
In other words, IEEE802.15.4e TSCH is designed to allow optimizations In other words, TSCH is designed to allow optimizations and strong
and strong customizations, simplifying the merging of TSCH with a customizations, simplifying the merging of TSCH with a protocol stack
protocol stack based on IPv6, 6LoWPAN, and RPL. based on IPv6, 6LoWPAN, and RPL.
2. TSCH in the LLN Context 2. TSCH in the LLN Context
To map the services required by the IP layer to the services provided To map the services required by the IP layer to the services provided
by the link layer, an adaptation layer is used by the link layer, an adaptation layer is used
[palattella12standardized]. The 6LoWPAN working group started [Palattella12standardized]. In 2007, the 6LoWPAN WG started working
working in 2007 on specifications for transmitting IPv6 packets over on specifications for transmitting IPv6 packets over IEEE 802.15.4
IEEE802.15.4 networks [RFC4919]. Low-power Wireless Personal Area networks [RFC4919]. A low-power Wireless Personal Area Network
Networks (WPANs) typically feature small frame sizes, support for (WPAN) is typically composed of a large number of battery-powered
addresses with different lengths, low bandwidth, star and mesh devices that are deployed at locations that are unknown a priori.
topologies, battery powered devices, low cost, large number of Nodes form a star or a mesh topology and communicate with one another
devices, unknown node positions, high unreliability, and periods at a low datarate and using short frames. The wireless nature of the
during which communication interfaces are turned off to save energy. links means that they are unreliable in nature. Nodes turn off their
Given these features, it is clear that the adoption of IPv6 on top of radio interface most of the time to conserve energy. Given these
a Low-Power WPAN is not straightforward, but poses strong features, it is clear that the adoption of IPv6 on top of a low-power
requirements for the optimization of this adaptation layer. WPAN is not straightforward but poses strong requirements for the
optimization of this adaptation layer.
For instance, due to the IPv6 default minimum MTU size (1280 bytes), For instance, due to the IPv6 default minimum MTU size (1280 bytes),
an un-fragmented IPv6 packet is too large to fit in an IEEE802.15.4 an unfragmented IPv6 packet is too large to fit in an IEEE 802.15.4
frame. Moreover, the overhead due to the 40-byte long IPv6 header frame. Moreover, the overhead due to the 40-byte-long IPv6 header
wastes the scarce bandwidth available at the PHY layer [RFC4944]. wastes the scarce bandwidth available at the PHY layer [RFC4944].
For these reasons, the 6LoWPAN working group has defined an effective For these reasons, the 6LoWPAN WG has defined an effective adaptation
adaptation layer [RFC6282]. Further issues encompass the auto- layer [RFC6282]. Further issues encompass the autoconfiguration of
configuration of IPv6 addresses [RFC2460][RFC4862], the compliance IPv6 addresses [RFC2460] [RFC4862], the compliance with the
with the recommendation on supporting link-layer subnet broadcast in recommendation on supporting link-layer subnet broadcast in shared
shared networks [RFC3819], the reduction of routing and management networks [RFC3819], the reduction of routing and management overhead
overhead [RFC6606], the adoption of lightweight application protocols [RFC6606], the adoption of lightweight application protocols (or
(or novel data encoding techniques), and the support for security novel data encoding techniques), and the support for security
mechanisms (confidentiality and integrity protection, device mechanisms (confidentiality and integrity protection, device
bootstrapping, key establishment, and management). bootstrapping, key establishment, and management).
These features can run on top of TSCH. There are, however, important These features can run on top of TSCH. There are, however, important
issues to solve, as highlighted in Section 3. issues to solve, as highlighted in Section 3.
Routing issues are challenging for 6LoWPAN, given the low-power and Routing issues are challenging for 6LoWPAN, given the low-power and
lossy radio links, the battery-powered nodes, the multi-hop mesh lossy radio links, the battery-powered nodes, the multi-hop mesh
topologies, and the frequent topology changes due to mobility. topologies, and the frequent topology changes due to mobility.
Successful solutions take into account the specific application Successful solutions take into account the specific application
requirements, along with IPv6 behavior and 6LoWPAN mechanisms requirements, along with IPv6 behavior and 6LoWPAN mechanisms
[palattella12standardized]. The ROLL working group has defined RPL [Palattella12standardized]. The ROLL WG has defined RPL in
in [RFC6550]. RPL can support a wide variety of link layers, [RFC6550]. RPL can support a wide variety of link layers, including
including ones that are constrained, potentially lossy, or typically ones that are constrained, potentially lossy, or typically utilized
utilized in conjunction with host or router devices with very limited in conjunction with host or router devices with very limited
resources, as in building/home automation [RFC5867][RFC5826], resources, as in building/home automation [RFC5867] [RFC5826],
industrial environments [RFC5673], and urban applications [RFC5548]. industrial environments [RFC5673], and urban applications [RFC5548].
RPL is able to quickly build up network routes, distribute routing RPL is able to quickly build up network routes, distribute routing
knowledge among nodes, and adapt to a changing topology. In a knowledge among nodes, and adapt to a changing topology. In a
typical setting, nodes are connected through multi-hop paths to a typical setting, nodes are connected through multi-hop paths to a
small set of root devices, which are usually responsible for data small set of root devices, which are usually responsible for data
collection and coordination. For each of them, a Destination collection and coordination. For each of them, a Destination-
Oriented Directed Acyclic Graph (DODAG) is created by accounting for Oriented Directed Acyclic Graph (DODAG) is created by accounting for
link costs, node attributes/status information, and an Objective link costs, node attributes/status information, and an Objective
Function, which maps the optimization requirements of the target Function, which maps the optimization requirements of the target
scenario. scenario.
The topology is set up based on a Rank metric, which encodes the The topology is set up based on a Rank metric, which encodes the
distance of each node with respect to its reference root, as distance of each node with respect to its reference root, as
specified by the Objective Function. Regardless of the way it is specified by the Objective Function. Regardless of the way it is
computed, the Rank monotonically decreases along the DODAG towards computed, the Rank monotonically decreases along the DODAG towards
the root, building a gradient. RPL encompasses different kinds of the root, building a gradient. RPL encompass different kinds of
traffic and signaling information. Multipoint-to-Point (MP2P) is the traffic and signaling information. Multipoint-to-Point (MP2P) is the
dominant traffic in LLN applications. Data is routed towards nodes dominant traffic in LLN applications. Data is routed towards nodes
with some application relevance, such as the LLN gateway to the with some application relevance, such as the LLN gateway to the
larger Internet, or to the core of private IP networks. In general, larger Internet or to the core of private IP networks. In general,
these destinations are the DODAG roots and act as data collection these destinations are the DODAG roots and act as data collection
points for distributed monitoring applications. Point-to-Multipoint points for distributed monitoring applications. Point-to-Multipoint
(P2MP) data streams are used for actuation purposes, where messages (P2MP) data streams are used for actuation purposes, where messages
are sent from DODAG roots to destination nodes. Point-to-Point (P2P) are sent from DODAG roots to destination nodes. Point-to-Point (P2P)
traffic allows communication between two devices belonging to the traffic allows communication between two devices belonging to the
same LLN, such as a sensor and an actuator. A packet flows from the same LLN, such as a sensor and an actuator. A packet flows from the
source to the common ancestor of those two communicating devices, source to the common ancestor of those two communicating devices,
then downward towards the destination. RPL therefore has to discover then downward towards the destination. Therefore, RPL has to
both upward routes (i.e. from nodes to DODAG roots) in order to discover both upward routes (i.e., from nodes to DODAG roots) in
enable MP2P and P2P flows, and downward routes (i.e. from DODAG roots order to enable MP2P and P2P flows and downward routes (i.e., from
to nodes) to support P2MP and P2P traffic. DODAG roots to nodes) to support P2MP and P2P traffic.
Section 3 highlights the challenges that need to be addressed to use Section 3 highlights the challenges that need to be addressed to use
RPL on top of TSCH. RPL on top of TSCH.
Open-source initiatives have emerged around TSCH, with the OpenWSN Open-source initiatives have emerged around TSCH, with the OpenWSN
project [OpenWSN][OpenWSNETT] being the first open-source project [OpenWSN] [OpenWSNETT] being the first open-source
implementation of a standards-based protocol stack. This implementation of a standards-based protocol stack. This
implementation was used as the foundation for an IP for Smart Objects implementation was used as the foundation for an IP for the Smart
Alliance (IPSO) [IPSO] interoperability event in 2011. In the Objects Alliance (IPSO) [IPSO] interoperability event in 2011. In
absence of a standardized scheduling mechanism for TSCH, a "slotted the absence of a standardized scheduling mechanism for TSCH, a
Aloha" schedule was used. "slotted Aloha" schedule was used.
3. Problems and Goals 3. Problems and Goals
As highlighted in Appendix A, TSCH differs from other low-power MAC As highlighted in Appendix A, TSCH differs from other low-power MAC
protocols because of its scheduled nature. TSCH defines the protocols because of its scheduled nature. TSCH defines the
mechanisms to execute a communication schedule, yet it is the entity mechanisms to execute a communication schedule; yet, it is the entity
that sets up that schedule which controls the topology of the that sets up the schedule that controls the topology of the network.
network. This scheduling entity also controls the resources This scheduling entity also controls the resources allocated to each
allocated to each link in that topology. link in that topology.
How this entity should operate is out of scope of TSCH. The How this entity should operate is out of scope of TSCH. The
remainder of this section highlights the problems this entity needs remainder of this section highlights the problems this entity needs
to address. For simplicity, we refer to this entity by the generic to address. For simplicity, we refer to this entity by the generic
name "LLC". Note that the 6top sublayer, currently being defined in name "LLC". Note that the 6top sublayer, currently being defined in
[I-D.wang-6tisch-6top-sublayer], can be seen as an embodiment of this [SUBLAYER-6top], can be seen as an embodiment of this generic "LLC".
generic "LLC".
Some of the issues the LLC needs to target might overlap with the Some of the issues the LLC needs to target might overlap with the
scope of other protocols (e.g., 6LoWPAN, RPL, and RSVP). In this scope of other protocols (e.g., 6LoWPAN, RPL, and RSVP). In this
case, it is entailed that the LLC will profit from the services case, the LLC will profit from the services provided by other
provided by other protocols to pursue these objectives. protocols to pursue these objectives.
3.1. Network Formation 3.1. Network Formation
The LLC needs to control the way the network is formed, including how The LLC needs to control the way the network is formed, including how
new nodes join, and how already joined nodes advertise the presence new nodes join and how already joined nodes advertise the presence of
of the network. The LLC needs to: the network. The LLC needs to:
1. Define the Information Elements included in the Enhanced Beacons 1. Define the Information Elements included in the Enhanced Beacons
[IEEE802154e] advertising the presence of the network. (EBs) [IEEE.802.15.4e] advertising the presence of the network.
2. For a new node, define rules to process and filter received 2. (For a new node), define rules to process and filter received
Enhanced Beacons. EBs.
3. Define the joining procedure. This might include a mechanism to 3. Define the joining procedure. This might include a mechanism to
assign a unique 16-bit address to a node, and the management of assign a unique 16-bit address to a node and the management of
initial keying material. initial keying material.
4. Define a mechanism to secure the joining process and the 4. Define a mechanism to secure the joining process and the
subsequent optional process of scheduling more communication subsequent optional process of scheduling more communication
cells. cells.
3.2. Network Maintenance 3.2. Network Maintenance
Once a network is formed, the LLC needs to maintain the network's Once a network is formed, the LLC needs to maintain the network's
health, allowing for nodes to stay synchronized. The LLC needs to: health, allowing for nodes to stay synchronized. The LLC needs to:
1. Manage each node's time source neighbor. 1. Manage each node's time source neighbor.
2. Define a mechanism for a node to update the join priority it 2. Define a mechanism for a node to update the join priority it
announces in its Enhanced Beacon. announces in its EB.
3. Schedule transmissions of Enhanced Beacons to advertise the 3. Schedule transmissions of EBs to advertise the presence of the
presence of the network. network.
3.3. Multi-Hop Topology 3.3. Multi-Hop Topology
RPL, given a weighted connectivity graph, determines multi-hop RPL, given a weighted connectivity graph, determines multi-hop
routes. The LLC needs to: routes. The LLC needs to:
1. Define a mechanism to gather topological information, node and 1. Define a mechanism to gather topological information, node and
link state, which it can then feed to RPL. link state, which it can then feed to RPL.
2. Ensure that the TSCH schedule contains cells along the multi-hop 2. Ensure that the TSCH schedule contains cells along the multi-hop
routes identified by RPL (a cell in a TSCH schedule is an atomic routes identified by RPL (a cell in a TSCH schedule is an atomic
"unit" of resource, see Section 3.5). "unit" of resource, see Section 3.5).
3. Where applicable, maintain independent sets of cells to transport 3. Where applicable, maintain independent sets of cells to transport
independent flows of data. independent flows of data.
3.4. Routing and Timing Parents 3.4. Routing and Timing Parents
At all times, a TSCH node needs to have a time source neighbor it can At all times, a TSCH node needs to have a time-source neighbor to
synchronize to. The LLC therefore needs to assign a time source which it can synchronize. Therefore, LLC needs to assign a time-
neighbor to allow for correct operation of the TSCH network. A time source neighbor to allow for correct operation of the TSCH network.
source neighbors could, or not, be taken from the RPL routing parent A time-source neighbor could, or not, be taken from the RPL routing
set. parent set.
3.5. Resource Management 3.5. Resource Management
A cell in a TSCH schedule is an atomic "unit" of resource. The A cell in a TSCH schedule is an atomic "unit" of resource. The
number of cells to assign between neighbor nodes needs to be number of cells to assign between neighbor nodes needs to be
appropriate for the size of the traffic flow. The LLC needs to: appropriate for the size of the traffic flow. The LLC needs to:
1. Define a mechanism for neighbor nodes to exchange information 1. Define a mechanism for neighbor nodes to exchange information
about their schedule and, if applicable, negotiate the addition/ about their schedule and, if applicable, negotiate the addition/
deletion of cells. deletion of cells.
2. Allow for an entity (e.g., a set of devices, a distributed 2. Allow for an entity (e.g., a set of devices, a distributed
protocol, a Path Computation Element (PCE), etc.) to take control protocol, a Path Computation Element (PCE), etc.) to take control
of the schedule. of the schedule.
3.6. Dataflow Control 3.6. Dataflow Control
TSCH defines mechanisms for a node to signal it cannot accept an TSCH defines mechanisms for a node to signal when it cannot accept an
incoming packet. It does not, however, define the policy which incoming packet. It does not, however, define the policy that
determines when to stop accepting packets. The LLC needs to: determines when to stop accepting packets. The LLC needs to:
1. Allow for the implementation and configuration of policy to queue 1. Allow for the implementation and configuration of policy to queue
incoming and outgoing packets. incoming and outgoing packets.
2. Manage the buffer space, and indicate to TSCH when to stop 2. Manage the buffer space, and indicate to TSCH when to stop
accepting incoming packets. accepting incoming packets.
3. Handle transmissions that have failed. A transmission is 3. Handle transmissions that have failed. A transmission is
declared failed when TSCH has retransmitted the packet multiple declared failed when TSCH has retransmitted the packet multiple
times, without receiving an acknowledgment. This covers both times, without receiving an acknowledgment. This covers both
dedicated and shared cells. dedicated and shared cells.
3.7. Deterministic Behavior 3.7. Deterministic Behavior
As highlighted in [RFC5673], in some applications, data is generated As highlighted in [RFC5673], in some applications, data is generated
periodically and has a well understood data bandwidth requirement, periodically and has a well-understood data bandwidth requirement,
which is deterministic and predictable. The LLC needs to: which is deterministic and predictable. The LLC needs to:
1. Ensure that the data is delivered to its final destination before 1. Ensure that the data is delivered to its final destination before
a deadline possibly determined by the application. a deadline possibly determined by the application.
2. Provide a mechanism for such deterministic flows to coexist with 2. Provide a mechanism for such deterministic flows to coexist with
bursty or infrequent traffic flows of different priorities. bursty or infrequent traffic flows of different priorities.
3.8. Scheduling Mechanisms 3.8. Scheduling Mechanisms
Several scheduling mechanisms can be envisioned, and possibly coexist Several scheduling mechanisms can be envisioned and could possibly
in the same network. For example, coexist in the same network. For example, [RPL] describes how the
[I-D.phinney-roll-rpl-industrial-applicability] describes how the allocation of bandwidth can be optimized by an external PCE
allocation of bandwidth can be optimized by an external Path [RFC4655]. Another centralized (PCE-based) traffic-aware scheduling
Computation Element (PCE) [RFC4655]. Another centralized (PCE-based) algorithm is defined in [TASA-PIMRC]. Alternatively, two neighbor
traffic-aware scheduling algorithm is defined in [TASA-PIMRC]. nodes can adapt the number of cells autonomously by monitoring the
Alternatively, two neighbor nodes can adapt the number of cells amount of traffic and negotiating the allocation to extra cell when
autonomously by monitoring the amount of traffic, and negotiating the needed. An example of a decentralized algorithm (i.e., no PCE is
allocation to extra cell when needed. An example of decentralized needed) is provided in [Tinka10decentralized]. This mechanism can be
algorithm (i.e. no PCE is needed) is provided in used to establish multi-hop paths in a fashion similar to RSVP
[tinka10decentralized]. This mechanism can be used to establish [RFC2205]. The LLC needs to:
multi-hop paths in a fashion similar to RSVP [RFC2205]. The LLC
needs to:
1. Provide a mechanism for two devices to negotiate the allocation 1. Provide a mechanism for two devices to negotiate the allocation
and deallocation of cells between them. and deallocation of cells between them.
2. Provide a mechanism for device to monitor and manage the 2. Provide a mechanism for the device to monitor and manage the
capabilities of a node several hops away. capabilities of a node several hops away.
3. Define an mechanism for these different scheduling mechanisms to 3. Define a mechanism for these different scheduling mechanisms to
coexist in the same network. coexist in the same network.
3.9. Secure Communication 3.9. Secure Communication
Given some keying material, TSCH defines mechanisms to encrypt and Given some keying material, TSCH defines mechanisms to encrypt and
authenticate MAC frames. It does not define how this keying material authenticate MAC frames. It does not define how this keying material
is generated. The LLC needs to: is generated. The LLC needs to:
1. Define the keying material and authentication mechanism needed by 1. Define the keying material and authentication mechanism needed by
a new node to join an existing network. a new node to join an existing network.
2. Define a mechanism to allow for the secure transfer of 2. Define a mechanism to allow for the secure transfer of
application data between neighbor nodes. application data between neighbor nodes.
3. Define a mechanism to allow for the secure transfer of signaling 3. Define a mechanism to allow for the secure transfer of signaling
data between nodes and the LLC. data between nodes and the LLC.
4. IANA Considerations 4. Security Considerations
This memo includes no request to IANA.
5. Security Considerations
This memo is an informational overview of existing standards, and This memo is an informational overview of existing standards and does
does not define any new mechanisms or protocols. not define any new mechanisms or protocols.
It does describe the need for the 6TiSCH WG to define a secure It does describe the need for the 6TiSCH WG to define a secure
solution. In particular, Section 3.1 describes security in the join solution. In particular, Section 3.1 describes security in the join
process. Section 3.9 discusses data frame protection. process. Section 3.9 discusses data-frame protection.
6. Acknowledgments 5. References
Special thanks to Dominique Barthel, Patricia Brett, Guillaume 5.1. Normative References
Gaillard, Pat Kinney, Ines Robles, Timothy J. Salo, Jonathan Simon,
Rene Struik, Xavi Vilajosana for reviewing the document and providing
valuable feedback. Thanks to the IoT6 European Project (STREP) of
the 7th Framework Program (Grant 288445).
7. References [IEEE.802.15.4]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Part. 15.4: Low-Rate Wireless Personal Area
Networks", IEEE Std. 802.15.4-2011, September 2011.
7.1. Normative References [IEEE.802.15.4e]
IEEE, "IEEE Standard for Local and metropolitan area
networks -- Part 15.4: Low-Rate Wireless Personal Area
Networks (LR-WPANs) Amendment 1: MAC sublayer", IEEE Std.
802.15.4e-2012, April 2012.
[IEEE802154e] 5.2. Informative References
IEEE standard for Information Technology, "IEEE std.
802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
Networks (LR-WPANs) Amendment 1: MAC sublayer", April
2012.
[IEEE802154] [CurrentCalculator]
IEEE standard for Information Technology, "IEEE std. Linear Technology, "Application Note: Using the Current
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) Calculator to Estimate Mote Power", August 2012,
and Physical Layer (PHY) Specifications for Low-Rate <http://www.linear.com/docs/43189>.
Wireless Personal Area Networks", June 2011.
7.2. Informative References [Doherty07channel]
Doherty, L., Lindsay, W., and J. Simon, "Channel-Specific
Wireless Sensor Network Path Data", IEEE International
Conference on Computer Communications and Networks
(ICCCN), pp. 89-94, 2007.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [IPSO] IPSO Alliance, "IP for Smart Objects Alliance Homepage",
Application Protocol (CoAP)", RFC 7252, June 2014. <http://www.ipso-alliance.org/>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [OpenWSN] "Berkeley's OpenWSN Project Homepage",
Constrained-Node Networks", RFC 7228, May 2014. <http://www.openwsn.org/>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and [OpenWSNETT]
Lossy Networks", RFC 7102, January 2014. Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F.,
Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN:
A Standards-Based Low-Power Wireless Development
Environment", Transactions on Emerging Telecommunications
Technologies, Volume 23: Issue 5, August 2012.
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem [Palattella12standardized]
Statement and Requirements for IPv6 over Low-Power Palattella, MR., Accettura, N., Vilajosana, X., Watteyne,
Wireless Personal Area Network (6LoWPAN) Routing", RFC T., Grieco, LA., Boggia, G., and M. Dohler, "Standardized
6606, May 2012. Protocol Stack For The Internet Of (Important) Things",
IEEE Communications Surveys and Tutorials, Volume: 15,
Issue 3, December 2012.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
Lossy Networks", RFC 6550, March 2012. September 1997, <http://www.rfc-editor.org/info/rfc2205>.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
September 2011. December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D.,
"Building Automation Routing Requirements in Low-Power and Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Lossy Networks", RFC 5867, June 2010. Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, DOI 10.17487/RFC3819, July 2004,
<http://www.rfc-editor.org/info/rfc3819>.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Routing Requirements in Low-Power and Lossy Networks", RFC Element (PCE)-Based Architecture", RFC 4655,
5826, April 2010. DOI 10.17487/RFC4655, August 2006,
<http://www.rfc-editor.org/info/rfc4655>.
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
"Industrial Routing Requirements in Low-Power and Lossy Address Autoconfiguration", RFC 4862,
Networks", RFC 5673, October 2009. DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>.
[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
"Routing Requirements for Urban Low-Power and Lossy over Low-Power Wireless Personal Area Networks (6LoWPANs):
Networks", RFC 5548, May 2009. Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, DOI 10.17487/RFC4919, August 2007,
<http://www.rfc-editor.org/info/rfc4919>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007. Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<http://www.rfc-editor.org/info/rfc4944>.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 [RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and
over Low-Power Wireless Personal Area Networks (6LoWPANs): D. Barthel, Ed., "Routing Requirements for Urban Low-Power
Overview, Assumptions, Problem Statement, and Goals", RFC and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May
4919, August 2007. 2009, <http://www.rfc-editor.org/info/rfc5548>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.
Address Autoconfiguration", RFC 4862, September 2007. Phinney, "Industrial Routing Requirements in Low-Power and
Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October
2009, <http://www.rfc-editor.org/info/rfc5673>.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, DOI 10.17487/RFC5826, April 2010,
<http://www.rfc-editor.org/info/rfc5826>.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., [RFC5867] Martocci, J., Ed., De Mil, P., Riou, N., and W. Vermeylen,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. "Building Automation Routing Requirements in Low-Power and
Wood, "Advice for Internet Subnetwork Designers", BCP 89, Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June
RFC 3819, July 2004. 2010, <http://www.rfc-editor.org/info/rfc5867>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
(IPv6) Specification", RFC 2460, December 1998. Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011,
<http://www.rfc-editor.org/info/rfc6282>.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
Functional Specification", RFC 2205, September 1997. JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>.
[I-D.ietf-6tisch-terminology] [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, Statement and Requirements for IPv6 over Low-Power
"Terminology in IPv6 over the TSCH mode of IEEE Wireless Personal Area Network (6LoWPAN) Routing",
802.15.4e", draft-ietf-6tisch-terminology-03 (work in RFC 6606, DOI 10.17487/RFC6606, May 2012,
progress), January 2015. <http://www.rfc-editor.org/info/rfc6606>.
[I-D.wang-6tisch-6top-sublayer] [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
Operation Sublayer (6top)", draft-wang-6tisch-6top- 2014, <http://www.rfc-editor.org/info/rfc7102>.
sublayer-01 (work in progress), July 2014.
[I-D.phinney-roll-rpl-industrial-applicability] [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Phinney, T., Thubert, P., and R. Assimiti, "RPL Constrained-Node Networks", RFC 7228,
applicability in industrial networks", draft-phinney-roll- DOI 10.17487/RFC7228, May 2014,
rpl-industrial-applicability-02 (work in progress), <http://www.rfc-editor.org/info/rfc7228>.
February 2013.
[OpenWSN] "Berkeley's OpenWSN Project Homepage", [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
<http://www.openwsn.org/>. Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
[OpenWSNETT] [RPL] Phinney, T., Thubert, P., and R. Assimiti, "RPL
Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., applicability in industrial networks", Work in Progress,
Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: draft-ietf-roll-rpl-industrial-applicability-02, October
a Standards-Based Low-Power Wireless Development 2013.
Environment", Transactions on Emerging Telecommunications
Technologies , August 2012.
[IPSO] "IP for Smart Objects Alliance Homepage", [SUBLAYER-6top]
<http://www.ipso-alliance.org/>. Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
Operation Sublayer (6top)", Work in Progress, draft-wang-
6tisch-6top-sublayer-01, July 2014.
[CurrentCalculator] [TASA-PIMRC]
Linear Technology, "Application Note: Using the Current Palattella, MR., Accettura, N., Dohler, M., Grieco, LA.,
Calculator to Estimate Mote Power", August 2012, and G. Boggia, "Traffic Aware Scheduling Algorithm for
<http://www.linear.com/docs/42452>. reliable low-power multi-hop IEEE 802.15.4e networks",
IEEE 23rd International Symposium on Personal, Indoor and
Mobile Radio Communications (PIMRC), pp. 327-332,
September 2012.
[doherty07channel] [TERMS-6TISCH]
Doherty, L., Lindsay, W., and J. Simon, "Channel-Specific Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
Wireless Sensor Network Path Data", IEEE International "Terminology in IPv6 over the TSCH mode of IEEE
Conference on Computer Communications and Networks (ICCCN) 802.15.4e", Work in Progress, draft-ietf-6tisch-
2008, 2007. terminology-04, March 2015.
[tinka10decentralized] [Tinka10decentralized]
Tinka, A., Watteyne, T., and K. Pister, "A Decentralized Tinka, A., Watteyne, T., and K. Pister, "A Decentralized
Scheduling Algorithm for Time Synchronized Channel Scheduling Algorithm for Time Synchronized Channel
Hopping", Ad Hoc Networks 2010, 2010. Hopping", Ad Hoc Networks, 2010.
[watteyne09reliability] [Watteyne09reliability]
Watteyne, T., Mehta, A., and K. Pister, "Reliability Watteyne, T., Mehta, A., and K. Pister, "Reliability
Through Frequency Diversity: Why Channel Hopping Makes Through Frequency Diversity: Why Channel Hopping Makes
Sense", International Conference on Performance Evaluation Sense", Proceedings of the 6th ACM Symposium on
of Wireless Ad Hoc, Sensor, and Ubiquitous Networks (PE- Performance Evaluation of Wireless Ad Hoc, Sensor, and
WASUN) 2009, Oct. 2009. Ubiquitous Networks (PE-WASUN), pp. 116-123, October 2009.
[TASA-PIMRC]
Palattella, MR., Accettura, N., Dohler, M., Grieco, LA.,
and G. Boggia, "Traffic Aware Scheduling Algorithm for
Multi-Hop IEEE 802.15.4e Networks", IEEE PIMRC 2012, Sept.
2012.
[palattella12standardized]
Palattella, MR., Accettura, N., Vilajosana, X., Watteyne,
T., Grieco, LA., Boggia, G., and M. Dohler, "Standardized
Protocol Stack For The Internet Of (Important) Things",
IEEE Communications Surveys and Tutorials 2012, Dec. 2012.
Appendix A. TSCH Protocol Highlights Appendix A. TSCH Protocol Highlights
This appendix gives an overview of the key features of the This appendix gives an overview of the key features of the IEEE
IEEE802.15.4e Timeslotted Channel Hopping (TSCH) amendment. It makes 802.15.4e TSCH amendment. It makes no attempt at repeating the
no attempt at repeating the standard, but rather focuses on the standard, rather it focuses on the following:
following:
o Concepts which are sufficiently different from other IEEE802.15.4 o Concepts that are sufficiently different from other IEEE 802.15.4
networking that they may need to be defined and presented networking that they may need to be defined and presented
precisely. precisely.
o Techniques and ideas which are part of IEEE802.15.4e and which o Techniques and ideas that are part of IEEE 802.15.4e and that
might be useful for the work of the 6TiSCH WG. might be useful for the work of the 6TiSCH WG.
A.1. Timeslots A.1. Time Slots
All nodes in a TSCH network are synchronized. Time is sliced up into All nodes in a TSCH network are synchronized. Time is sliced up into
timeslots. A timeslot is long enough for a MAC frame of maximum size time slots. A time slot is long enough for a MAC frame of maximum
to be sent from node A to node B, and for node B to reply with an size to be sent from node A to node B, and for node B to reply with
acknowledgment (ACK) frame indicating successful reception. an acknowledgment (ACK) frame indicating successful reception.
The duration of a timeslot is not defined by the standard. With The duration of a time slot is not defined by the standard. With
IEEE802.15.4-compliant radios operating in the 2.4GHz frequency band, radios that are compliant with IEEE 802.15.4 operating in the 2.4 GHz
a maximum-length frame of 127 bytes takes about 4ms to transmit; a frequency band, a maximum-length frame of 127 bytes takes about 4 ms
shorter ACK takes about 1ms. With a 10ms slot (a typical duration), to transmit; a shorter ACK takes about 1 ms. With a 10 ms slot (a
this leaves 5ms to radio turnaround, packet processing and security typical duration), this leaves 5 ms to radio turnaround, packet
operations. processing, and security operations.
A.2. Slotframes A.2. Slotframes
Timeslots are grouped into one of more slotframes. A slotframe Time slots are grouped into one of more slotframes. A slotframe
continuously repeats over time. TSCH does not impose a slotframe continuously repeats over time. TSCH does not impose a slotframe
size. Depending on the application needs, these can range from 10s size. Depending on the application needs, these can range from 10's
to 1000s of timeslots. The shorter the slotframe, the more often a to 1000's of time slots. The shorter the slotframe, the more often a
timeslot repeats, resulting in more available bandwidth, but also in time slot repeats, resulting in more available bandwidth, but also in
a higher power consumption. a higher power consumption.
A.3. Node TSCH Schedule A.3. Node TSCH Schedule
A TSCH schedule instructs each node what to do in each timeslot: A TSCH schedule instructs each node what to do in each time slot:
transmit, receive or sleep. The schedule indicates, for each transmit, receive, or sleep. The schedule indicates, for each
scheduled (transmit or receive) cell, a channelOffset and the address scheduled (transmit or receive) cell, a channelOffset and the address
of the neighbor to communicate with. of the neighbor with which to communicate.
Once a node obtains its schedule, it executes it: Once a node obtains its schedule, it executes it:
o For each transmit cell, the node checks whether there is a packet o For each transmit cell, the node checks whether there is a packet
in the outgoing buffer which matches the neighbor written in the in the outgoing buffer that matches the neighbor written in the
schedule information for that timeslot. If there is none, the schedule information for that time slot. If there is none, the
node keeps its radio off for the duration of the timeslot. If node keeps its radio off for the duration of the time slot. If
there is one, the node can ask for the neighbor to acknowledge it, there is one, the node can ask for the neighbor to acknowledge it,
in which case it has to listen for the acknowledgment after in which case it has to listen for the acknowledgment after
transmitting. transmitting.
o For each receive cell, the node listens for possible incoming o For each receive cell, the node listens for possible incoming
packets. If none is received after some listening period, it packets. If none is received after some listening period, it
shuts down its radio. If a packet is received, addressed to the shuts down its radio. If a packet is received, addressed to the
node, and passes security checks, the node can send back an node, and passes security checks, the node can send back an
acknowledgment. acknowledgment.
How the schedule is built, updated and maintained, and by which How the schedule is built, updated, and maintained, and by which
entity, is outside of the scope of the IEEE802.15.4e standard. entity, is outside of the scope of the IEEE 802.15.4e standard.
A.4. Cells and Bundles A.4. Cells and Bundles
Assuming the schedule is well built, if node A is scheduled to Assuming the schedule is well built, if node A is scheduled to
transmit to node B at slotOffset 5 and channelOffset 11, node B will transmit to node B at slotOffset 5 and channelOffset 11, node B will
be scheduled to receive from node A at the same slotOffset and be scheduled to receive from node A at the same slotOffset and
channelOffset. channelOffset.
A single element of the schedule characterized by a slotOffset and A single element of the schedule characterized by a slotOffset and
channelOffset, and reserved for node A to transmit to node B (or for channelOffset, and reserved for node A to transmit to node B (or for
node B to receive from node A) within a given slotframe, is called a node B to receive from node A) within a given slotframe, is called a
"scheduled cell". "scheduled cell".
If there is a lot of data flowing from node A to node B, the schedule If there is a lot of data flowing from node A to node B, the schedule
might contain multiple cells from A to B, at different times. might contain multiple cells from A to B, at different times.
Multiple cells scheduled to the same neighbor can be equivalent, i.e. Multiple cells scheduled to the same neighbor can be equivalent,
the MAC layer sends the packet on whichever of these cells shows up i.e., the MAC layer sends the packet on whichever of these cells
first after the packet was put in the MAC queue. The union of all shows up first after the packet was put in the MAC queue. The union
cells between two neighbors, A and B, is called a "bundle". Since of all cells between two neighbors, A and B, is called a "bundle".
the slotframe repeats over time (and the length of the slotframe is Since the slotframe repeats over time (and the length of the
typically constant), each cell gives a "quantum" of bandwidth to a slotframe is typically constant), each cell gives a "quantum" of
given neighbor. Modifying the number of equivalent cells in a bundle bandwidth to a given neighbor. Modifying the number of equivalent
modifies the amount of resources allocated between two neighbors. cells in a bundle modifies the amount of resources allocated between
two neighbors.
A.5. Dedicated vs. Shared Cells A.5. Dedicated vs. Shared Cells
By default, each scheduled transmit cell within the TSCH schedule is By default, each scheduled transmit cell within the TSCH schedule is
dedicated, i.e., reserved only for node A to transmit to node B. dedicated, i.e., reserved only for node A to transmit to node B.
IEEE802.15.4e allows also to mark a cell as shared. In a shared IEEE 802.15.4e also allows a cell to be marked as shared. In a
cell, multiple nodes can transmit at the same time, on the same shared cell, multiple nodes can transmit at the same time, on the
frequency. To avoid contention, TSCH defines a back-off algorithm same frequency. To avoid contention, TSCH defines a backoff
for shared cells. algorithm for shared cells.
A scheduled cell can be marked as both transmitting and receiving. A scheduled cell can be marked as both transmitting and receiving.
In this case, a node transmits if it has an appropriate packet in its In this case, a node transmits if it has an appropriate packet in its
output buffer, or listens otherwise. Marking a cell as output buffer, or listens otherwise. Marking a cell as
[transmit,receive,shared] results in slotted-Aloha behavior. [transmit,receive,shared] results in slotted-Aloha behavior.
A.6. Absolute Slot Number A.6. Absolute Slot Number
TSCH defines a timeslot counter called Absolute Slot Number (ASN). TSCH defines a timeslot counter called Absolute Slot Number (ASN).
When a new network is created, the ASN is initialized to 0; from then When a new network is created, the ASN is initialized to 0; from then
on, it increments by 1 at each timeslot. In detail: on, it increments by 1 at each timeslot. In detail:
ASN = (k*S+t) ASN = (k*S+t)
where k is the slotframe cycle (i.e., the number of slotframe where k is the slotframe cycle (i.e., the number of slotframe
repetitions since the network was started), S the slotframe size and repetitions since the network was started), S the slotframe size, and
t the slotOffset. A node learns the current ASN when it joins the t the slotOffset. A node learns the current ASN when it joins the
network. Since nodes are synchronized, they all know the current network. Since nodes are synchronized, they all know the current
value of the ASN, at any time. The ASN is encoded as a 5-byte value of the ASN, at any time. The ASN is encoded as a 5-byte
number: this allows it to increment for hundreds of years (the exact number: this allows it to increment for hundreds of years (the exact
value depends on the duration of a timeslot) without wrapping over. value depends on the duration of a timeslot) without wrapping over.
The ASN is used to calculate the frequency to communicate on, and can The ASN is used to calculate the frequency to communicate on and can
be used for security-related operations. be used for security-related operations.
A.7. Channel Hopping A.7. Channel Hopping
For each scheduled cell, the schedule specifies a slotOffset and a For each scheduled cell, the schedule specifies a slotOffset and a
channelOffset. In a well-built schedule, when node A has a transmit channelOffset. In a well-built schedule, when node A has a transmit
cell to node B on channelOffset 5, node B has a receive cell from cell to node B on channelOffset 5, node B has a receive cell from
node A on the same channelOffset. The channelOffset is translated by node A on the same channelOffset. The channelOffset is translated by
both nodes into a frequency using the following function: both nodes into a frequency using the following function:
frequency = F {(ASN + channelOffset) mod nFreq} frequency = F {(ASN + channelOffset) mod nFreq}
The function F consists of a look-up table containing the set of The function F consists of a lookup table containing the set of
available channels. The value nFreq (the number of available available channels. The value nFreq (the number of available
frequencies) is the size of this look-up table. There are as many frequencies) is the size of this lookup table. There are as many
channelOffset values as there are frequencies available (e.g. 16 when channelOffset values as there are frequencies available (e.g., 16
using IEEE802.15.4-compliant radios at 2.4GHz, when all channels are when using radios that are compliant with IEEE 802.15.4 at 2.4 GHz,
used). Since both nodes have the same channelOffset written in their when all channels are used). Since both nodes have the same
schedule for that scheduled cell, and the same ASN counter, they channelOffset written in their schedule for that scheduled cell, and
compute the same frequency. At the next iteration (cycle) of the the same ASN counter, they compute the same frequency. At the next
slotframe, however, while the channelOffset is the same, the ASN has iteration (cycle) of the slotframe, however, while the channelOffset
changed, resulting in the computation of a different frequency. is the same, the ASN has changed, resulting in the computation of a
different frequency.
This results in "channel hopping": even with a static schedule, pairs This results in "channel hopping": even with a static schedule, pairs
of neighbors "hop" between the different frequencies when of neighbors "hop" between the different frequencies when
communicating. A way of ensuring communication happens on all communicating. A way of ensuring communication happens on all
available frequencies is to set the number of timeslots in a available frequencies is to set the number of timeslots in a
slotframe to a prime number. Channel hopping is a technique known to slotframe to a prime number. Channel hopping is a technique known to
efficiently combat multi-path fading and external interference efficiently combat multi-path fading and external interference
[watteyne09reliability]. [Watteyne09reliability].
A.8. Time Synchronization A.8. Time Synchronization
Because of the slotted nature of communication in a TSCH network, Because of the slotted nature of communication in a TSCH network,
nodes have to maintain tight synchronization. All nodes are assumed nodes have to maintain tight synchronization. All nodes are assumed
to be equipped with clocks to keep track of time. Yet, because to be equipped with clocks to keep track of time. Yet, because
clocks in different nodes drift with respect to one another, neighbor clocks in different nodes drift with respect to one another, neighbor
nodes need to periodically re-synchronize. nodes need to periodically resynchronize.
Each node needs to periodically synchronize its network clock to Each node needs to periodically synchronize its network clock to
another node, and it also provides its network time to its neighbors. another node, and it also provides its network time to its neighbors.
It is up to the entity that manages the schedule to assign an It is up to the entity that manages the schedule to assign an
adequate time source neighbor to each node, i.e., to indicate in the adequate time source neighbor to each node, i.e., to indicate in the
schedule which of neighbor is its "time source neighbor". While schedule which neighbor is its "time source neighbor". While setting
setting the time source neighbor, it is important to avoid the time source neighbor, it is important to avoid synchronization
synchronization loops, which could result in the formation of loops, which could result in the formation of independent clusters of
independent clusters of synchronized nodes. synchronized nodes.
TSCH adds timing information in all packets that are exchanged (both TSCH adds timing information in all packets that are exchanged (both
data and ACK frames). This means that neighbor nodes can data and ACK frames). This means that neighbor nodes can
resynchronize to one another whenever they exchange data. In detail, resynchronize to one another whenever they exchange data. In detail,
two methods are defined in IEEE802.15.4e-2012 for allowing a device two methods are defined in IEEE 802.15.4e (of 2012) for allowing a
to synchronize in a TSCH network: (i) Acknowledgment-Based and (ii) device to synchronize in a TSCH network: (i) Acknowledgment-based and
Frame-Based synchronization. In both cases, the receiver calculates (ii) Frame-based synchronization. In both cases, the receiver
the difference in time between the expected time of frame arrival and calculates the difference in time between the expected time of frame
its actual arrival. In Acknowledgment-Based synchronization, the arrival and its actual arrival. In Acknowledgment-based
receiver provides such information to the sender node in its synchronization, the receiver provides such information to the sender
acknowledgment. In this case, it is the sender node that node in its acknowledgment. In this case, it is the sender node that
synchronizes to the clock of the receiver. In Frame-Based synchronizes to the clock of the receiver. In Frame-based
synchronization, the receiver uses the computed delta for adjusting synchronization, the receiver uses the computed delta for adjusting
its own clock. In this case, it is the receiver node that its own clock. In this case, it is the receiver node that
synchronizes to the clock of the sender. synchronizes to the clock of the sender.
Different synchronization policies are possible. Nodes can keep Different synchronization policies are possible. Nodes can keep
synchronization exclusively by exchanging EBs. Nodes can also keep synchronization exclusively by exchanging EBs. Nodes can also keep
synchronized by periodically sending valid frames to a time source synchronized by periodically sending valid frames to a time source
neighbor and use the acknowledgment to resynchronize. Both method neighbor and use the acknowledgment to resynchronize. Both methods
(or a combination thereof) are valid synchronization policies; which (or a combination thereof) are valid synchronization policies; which
one to use depends on network requirements. one to use depends on network requirements.
A.9. Power Consumption A.9. Power Consumption
There are only a handful of activities a node can perform during a There are only a handful of activities a node can perform during a
timeslot: transmit, receive, or sleep. Each of these operations has timeslot: transmit, receive, or sleep. Each of these operations has
some energy cost associated to them, the exact value depends on the some energy cost associated to them; the exact value depends on the
the hardware used. Given the schedule of a node, it is hardware used. Given the schedule of a node, it is straightforward
straightforward to calculate the expected average power consumption to calculate the expected average power consumption of that node.
of that node.
A.10. Network TSCH Schedule A.10. Network TSCH Schedule
The schedule entirely defines the synchronization and communication The schedule entirely defines the synchronization and communication
between nodes. By adding/removing cells between neighbors, one can between nodes. By adding/removing cells between neighbors, one can
adapt a schedule to the needs of the application. Intuitive examples adapt a schedule to the needs of the application. Intuitive examples
are: are:
o Make the schedule "sparse" for applications where nodes need to o Make the schedule "sparse" for applications where nodes need to
consume as little energy as possible, at the price of reduced consume as little energy as possible, at the price of reduced
bandwidth. bandwidth.
o Make the schedule "dense" for applications where nodes generate a o Make the schedule "dense" for applications where nodes generate a
lot of data, at the price of increased power consumption. lot of data, at the price of increased power consumption.
o Add more cells along a multi-hop route over which many packets o Add more cells along a multi-hop route over which many packets
flow. flow.
A.11. Join Process A.11. Join Process
Nodes already part of the network can periodically send Enhanced Nodes already part of the network can periodically send EB frames to
Beacon (EB) frames to announce the presence of the network. These announce the presence of the network. These contain information
contain information about the size of the timeslot used in the about the size of the timeslot used in the network, the current ASN,
network, the current ASN, information about the slotframes and information about the slotframes and timeslots the beaconing node is
timeslots the beaconing node is listening on, and a 1-byte join listening on, and a 1-byte join priority. The join priority field
priority. The join priority field gives information to make a better gives information to make a better decision of which node to join.
decision of which node to join. Even if a node is configured to send Even if a node is configured to send all EB frames on the same
all EB frames on the same channel offset, because of the channel channelOffset, because of the channel hopping nature of TSCH
hopping nature of TSCH described in Appendix A.7, this channel offset described in Appendix A.7, this channelOffset translates into a
translates into a different frequency at different slotframe cycles. different frequency at different slotframe cycles. As a result, EB
As a result, EB frames are sent on all frequencies. frames are sent on all frequencies.
A node wishing to join the network listens for EBs. Since EBs are A node wishing to join the network listens for EBs. Since EBs are
sent on all frequencies, the joining node can listen on any frequency sent on all frequencies, the joining node can listen on any frequency
until it hears an EB. What frequency it listens on is until it hears an EB. What frequency it listens on is implementation
implementation-specific. Once it has received one or more EBs, the specific. Once it has received one or more EBs, the new node enables
new node enables the TSCH mode and uses the ASN and the other timing the TSCH mode and uses the ASN and the other timing information from
information from the EB to synchronize to the network. Using the the EB to synchronize to the network. Using the slotframe and cell
slotframe and cell information from the EB, it knows how to contact information from the EB, it knows how to contact other nodes in the
other nodes in the network. network.
The IEEE802.15.4e TSCH standard does not define the steps beyond this The IEEE 802.15.4e TSCH standard does not define the steps beyond
network "bootstrap". this network "bootstrap".
A.12. Information Elements A.12. Information Elements
TSCH introduces the concept of Information Elements (IEs). An TSCH introduces the concept of Information Elements (IEs). An IE is
information element is a list of Type-Length-Value containers placed a list of Type-Length-Value containers placed at the end of the MAC
at the end of the MAC header. A small number of types are defined header. A small number of types are defined for TSCH (e.g., the ASN
for TSCH (e.g., the ASN in the EB is contained in an IE), and an in the EB is contained in an IE), and an unmanaged range is available
unmanaged range is available for extensions. for extensions.
A data bit in the MAC header indicates whether the frame contains A data bit in the MAC header indicates whether the frame contains
IEs. IEs are grouped into Header IEs, consumed by the MAC layer and IEs. IEs are grouped into Header IEs, consumed by the MAC layer and
therefore typically invisible to the next higher layer, and Payload therefore typically invisible to the next higher layer, and Payload
IEs, which are passed untouched to the next higher layer, possibly IEs, which are passed untouched to the next higher layer, possibly
followed by regular payload. Payload IEs can therefore be used for followed by regular payload. Payload IEs can therefore be used for
the next higher layers of two neighbor nodes to exchange information. the next higher layers of two neighbor nodes to exchange information.
A.13. Extensibility A.13. Extensibility
skipping to change at page 19, line 4 skipping to change at page 20, line 38
IEs, which are passed untouched to the next higher layer, possibly IEs, which are passed untouched to the next higher layer, possibly
followed by regular payload. Payload IEs can therefore be used for followed by regular payload. Payload IEs can therefore be used for
the next higher layers of two neighbor nodes to exchange information. the next higher layers of two neighbor nodes to exchange information.
A.13. Extensibility A.13. Extensibility
The TSCH standard is designed to be extensible. It introduces the The TSCH standard is designed to be extensible. It introduces the
mechanisms as "building block" (e.g., cells, bundles, slotframes, mechanisms as "building block" (e.g., cells, bundles, slotframes,
etc.), but leaves entire freedom to the upper layer to assemble etc.), but leaves entire freedom to the upper layer to assemble
those. The MAC protocol can be extended by defining new Header IEs. those. The MAC protocol can be extended by defining new Header IEs.
An intermediate layer can be defined to manage the MAC layer by An intermediate layer can be defined to manage the MAC layer by
defining new Payload IEs. defining new Payload IEs.
Appendix B. TSCH Features Appendix B. TSCH Features
This section details features of IEEE802.15.4e TSCH which might be This section details features of TSCH, which might be interesting for
interesting for the work of the 6TiSCH WG. It does not define any the work of the 6TiSCH WG. It does not define any requirements.
requirements.
B.1. Collision Free Communication B.1. Collision-Free Communication
TSCH allows one to design a schedule which yields collision-free TSCH allows one to design a schedule that yields collision-free
communication. This is done by building the schedule with dedicated communication. This is done by building the schedule with dedicated
cells in such a way that at most one node communicates with a cells in such a way that at most, one node communicates with a
specific neighbor in each slotOffset/channelOffset cell. Multiple specific neighbor in each slotOffset/channelOffset cell. Multiple
pairs of neighbor nodes can exchange data at the same time, but on pairs of neighbor nodes can exchange data at the same time, but on
different frequencies. different frequencies.
B.2. Multi-Channel vs. Channel Hopping B.2. Multi-Channel vs. Channel Hopping
A TSCH schedule looks like a matrix of width "slotframe size", S, and A TSCH schedule looks like a matrix of width "slotframe size", S, and
of height "number of frequencies", nFreq. For a scheduling of height "number of frequencies", nFreq. For a scheduling
algorithm, cells can be considered atomic "units" to schedule. In algorithm, cells can be considered atomic "units" to schedule. In
particular, because of the channel hopping nature of TSCH, the particular, because of the channel hopping nature of TSCH, the
scheduling algorithm should not worry about the actual frequency scheduling algorithm should not worry about the actual frequency
communication happens on, since it changes at each slotframe communication happens on, since it changes at each slotframe
iteration. iteration.
B.3. Cost of (continuous) Synchronization B.3. Cost of (Continuous) Synchronization
When there is traffic in the network, nodes which are communicating When there is traffic in the network, nodes that are communicating
implicitly re-synchronize using the data frames they exchange. In implicitly resynchronize using the data frames they exchange. In the
the absence of data traffic, nodes are required to synchronize to absence of data traffic, nodes are required to synchronize to their
their time source neighbor(s) periodically not to drift in time. If time source neighbor(s) periodically not to drift in time. If they
they have not been communicating for some time (typically 30s), nodes have not been communicating for some time (typically 30 s), nodes can
can exchange an dummy data frame to re-synchronize. The frequency at exchange a dummy data frame to resynchronize. The frequency at which
which such messages need to be transmitted depends on the stability such messages need to be transmitted depends on the stability of the
of the clock source, and on how "early" each node starts listening clock source and on how "early" each node starts listening for data
for data (the "guard time"). Theoretically, with a 10ppm clock and a (the "guard time"). Theoretically, with a 10 ppm clock and a 1 ms
1ms guard time, this period can be 100s. Assuming this exchange guard time, this period can be 100 s. Assuming this exchange causes
causes the node's radio to be on for 5ms, this yields a radio duty the node's radio to be on for 5 ms, this yields a radio duty cycle
cycle needed to keep synchronized of 5ms/100s=0.005%. While TSCH does needed to keep synchronized of 5 ms / 100 s = 0.005%. While TSCH
requires nodes to resynchronize periodically, the cost of doing so is does require nodes to resynchronize periodically, the cost of doing
very low. so is very low.
B.4. Topology Stability B.4. Topology Stability
The channel hopping nature of TSCH causes links to be very "stable". The channel hopping nature of TSCH causes links to be very "stable".
Wireless phenomena such as multi-path fading and external Wireless phenomena such as multi-path fading and external
interference impact a wireless link between two nodes differently on interference impact a wireless link between two nodes differently on
each frequency. If a transmission from node A to node B fails, each frequency. If a transmission from node A to node B fails,
retransmitting on a different frequency has a higher likelihood of retransmitting on a different frequency has a higher likelihood of
succeeding that retransmitting on the same frequency. As a result, succeeding that retransmitting on the same frequency. As a result,
even when some frequencies are "behaving bad", channel hopping even when some frequencies are "behaving bad", channel hopping
"smoothens" the contribution of each frequency, resulting in more "smoothens" the contribution of each frequency, resulting in more
stable links, and therefore a more stable topology. stable links and therefore a more stable topology.
B.5. Multiple Concurrent Slotframes B.5. Multiple Concurrent Slotframes
The TSCH standard allows for multiple slotframes to coexist in a The TSCH standard allows for multiple slotframes to coexist in a
node's schedule. It is possible that, at some timeslot, a node has node's schedule. It is possible that, at some timeslot, a node has
multiple activities scheduled (e.g. transmit to node B on slotframe multiple activities scheduled (e.g., transmit to node B on slotframe
2, receive from node C on slotframe 1). To handle this situation, 2, receive from node C on slotframe 1). To handle this situation,
the TSCH standard defines the following precedence rules: the TSCH standard defines the following precedence rules:
1. Transmissions take precedence over receptions; 1. Transmissions take precedence over receptions;
2. Lower slotframe identifiers take precedence over higher slotframe 2. Lower slotframe identifiers take precedence over higher slotframe
identifiers. identifiers.
In the example above, the node would transmit to node B on slotframe In the example above, the node would transmit to node B on slotframe
2. 2.
Acknowledgments
Special thanks to Dominique Barthel, Patricia Brett, Guillaume
Gaillard, Pat Kinney, Ines Robles, Timothy J. Salo, Jonathan Simon,
Rene Struik, and Xavi Vilajosana for reviewing the document and
providing valuable feedback. Thanks to the IoT6 European Project
(STREP) of the 7th Framework Program (Grant 288445).
Authors' Addresses Authors' Addresses
Thomas Watteyne (editor) Thomas Watteyne (editor)
Linear Technology Linear Technology
32990 Alvarado-Niles Road, Suite 910 32990 Alvarado-Niles Road, Suite 910
Union City, CA 94587 Union City, CA 94587
USA United States
Phone: +1 (510) 400-2978 Phone: +1 (510) 400-2978
Email: twatteyne@linear.com EMail: twatteyne@linear.com
Maria Rita Palattella Maria Rita Palattella
University of Luxembourg University of Luxembourg
Interdisciplinary Centre for Security, Reliability and Trust Interdisciplinary Centre for Security, Reliability and Trust
4, rue Alphonse Weicker 4, rue Alphonse Weicker
Luxembourg L-2721 Luxembourg L-2721
LUXEMBOURG Luxembourg
Phone: +352 46 66 44 5841 Phone: +352 46 66 44 5841
Email: maria-rita.palattella@uni.lu EMail: maria-rita.palattella@uni.lu
Luigi Alfredo Grieco Luigi Alfredo Grieco
Politecnico di Bari Politecnico di Bari
Department of Electrical and Information Engineering Department of Electrical and Information Engineering
Via Orabona 4 Via Orabona 4
Bari 70125 Bari 70125
Italy Italy
Phone: +39 08 05 96 3911 Phone: +39 08 05 96 3911
Email: a.grieco@poliba.it EMail: a.grieco@poliba.it
 End of changes. 128 change blocks. 
433 lines changed or deleted 447 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/