< draft-ietf-6tisch-tsch-01.txt   draft-ietf-6tisch-tsch-02.txt >
6TiSCH T. Watteyne, Ed. 6TiSCH T. Watteyne, Ed.
Internet-Draft Linear Technology Internet-Draft Linear Technology
Intended status: Informational MR. Palattella Intended status: Informational MR. Palattella
Expires: January 5, 2015 University of Luxembourg Expires: April 20, 2015 University of Luxembourg
LA. Grieco LA. Grieco
Politecnico di Bari Politecnico di Bari
July 4, 2014 October 17, 2014
Using IEEE802.15.4e TSCH in an LLN context: Using IEEE802.15.4e TSCH in an IoT context:
Overview, Problem Statement and Goals Overview, Problem Statement and Goals
draft-ietf-6tisch-tsch-01 draft-ietf-6tisch-tsch-02
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 IEEE802.15.4e TSCH MAC protocol in the context of LLNs.
The set of goals enumerated in this document form an initial set The set of goals enumerated in this document form an initial set
only. only.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015. This Internet-Draft will expire on April 20, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. TSCH in the LLN Context . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Problems and Goals . . . . . . . . . . . . . . . . . . . . . 6 3. TSCH in the LLN Context . . . . . . . . . . . . . . . . . . . 4
3.1. Network Formation . . . . . . . . . . . . . . . . . . . . 6 4. Problems and Goals . . . . . . . . . . . . . . . . . . . . . 6
3.2. Network Maintenance . . . . . . . . . . . . . . . . . . . 6 4.1. Network Formation . . . . . . . . . . . . . . . . . . . . 6
3.3. Multi-Hop Topology . . . . . . . . . . . . . . . . . . . 7 4.2. Network Maintenance . . . . . . . . . . . . . . . . . . . 7
3.4. Routing and Timing Parents . . . . . . . . . . . . . . . 7 4.3. Multi-Hop Topology . . . . . . . . . . . . . . . . . . . 7
3.5. Resource Management . . . . . . . . . . . . . . . . . . . 7 4.4. Routing and Timing Parents . . . . . . . . . . . . . . . 7
3.6. Dataflow Control . . . . . . . . . . . . . . . . . . . . 8 4.5. Resource Management . . . . . . . . . . . . . . . . . . . 8
3.7. Deterministic Behavior . . . . . . . . . . . . . . . . . 8 4.6. Dataflow Control . . . . . . . . . . . . . . . . . . . . 8
3.8. Scheduling Mechanisms . . . . . . . . . . . . . . . . . . 8 4.7. Deterministic Behavior . . . . . . . . . . . . . . . . . 8
3.9. Secure Communication . . . . . . . . . . . . . . . . . . 9 4.8. Scheduling Mechanisms . . . . . . . . . . . . . . . . . . 8
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 4.9. Secure Communication . . . . . . . . . . . . . . . . . . 9
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5.1. Normative References . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.2. Informative References . . . . . . . . . . . . . . . . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
5.3. External Informative References . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10
8.3. External Informative References . . . . . . . . . . . . . 13
Appendix A. TSCH Protocol Highlights . . . . . . . . . . . . . . 15 Appendix A. TSCH Protocol Highlights . . . . . . . . . . . . . . 15
A.1. Timeslots . . . . . . . . . . . . . . . . . . . . . . . . 15 A.1. Timeslots . . . . . . . . . . . . . . . . . . . . . . . . 15
A.2. Slotframes . . . . . . . . . . . . . . . . . . . . . . . 15 A.2. Slotframes . . . . . . . . . . . . . . . . . . . . . . . 16
A.3. Node TSCH Schedule . . . . . . . . . . . . . . . . . . . 15 A.3. Node TSCH Schedule . . . . . . . . . . . . . . . . . . . 16
A.4. Cells and Bundles . . . . . . . . . . . . . . . . . . . . 16 A.4. Cells and Bundles . . . . . . . . . . . . . . . . . . . . 16
A.5. Dedicated vs. Shared Cells . . . . . . . . . . . . . . . 16 A.5. Dedicated vs. Shared Cells . . . . . . . . . . . . . . . 17
A.6. Absolute Slot Number . . . . . . . . . . . . . . . . . . 17 A.6. Absolute Slot Number . . . . . . . . . . . . . . . . . . 17
A.7. Channel Hopping . . . . . . . . . . . . . . . . . . . . . 17 A.7. Channel Hopping . . . . . . . . . . . . . . . . . . . . . 18
A.8. Time Synchronization . . . . . . . . . . . . . . . . . . 18 A.8. Time Synchronization . . . . . . . . . . . . . . . . . . 18
A.9. Power Consumption . . . . . . . . . . . . . . . . . . . . 18 A.9. Power Consumption . . . . . . . . . . . . . . . . . . . . 19
A.10. Network TSCH Schedule . . . . . . . . . . . . . . . . . . 19 A.10. Network TSCH Schedule . . . . . . . . . . . . . . . . . . 19
A.11. Join Process . . . . . . . . . . . . . . . . . . . . . . 19 A.11. Join Process . . . . . . . . . . . . . . . . . . . . . . 20
A.12. Information Elements . . . . . . . . . . . . . . . . . . 19 A.12. Information Elements . . . . . . . . . . . . . . . . . . 20
A.13. Extensibility . . . . . . . . . . . . . . . . . . . . . . 20 A.13. Extensibility . . . . . . . . . . . . . . . . . . . . . . 20
Appendix B. TSCH Gotchas . . . . . . . . . . . . . . . . . . . . 20 Appendix B. TSCH Gotchas . . . . . . . . . . . . . . . . . . . . 21
B.1. Collision Free Communication . . . . . . . . . . . . . . 20 B.1. Collision Free Communication . . . . . . . . . . . . . . 21
B.2. Multi-Channel vs. Channel Hopping . . . . . . . . . . . . 20 B.2. Multi-Channel vs. Channel Hopping . . . . . . . . . . . . 21
B.3. Cost of (continuous) Synchronization . . . . . . . . . . 20 B.3. Cost of (continuous) Synchronization . . . . . . . . . . 21
B.4. Topology Stability . . . . . . . . . . . . . . . . . . . 21 B.4. Topology Stability . . . . . . . . . . . . . . . . . . . 21
B.5. Multiple Concurrent Slotframes . . . . . . . . . . . . . 21 B.5. Multiple Concurrent Slotframes . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
The IEEE802.15.4e standard [IEEE802154e] was published in 2012 as an IEEE802.15.4e [IEEE802154e] was published in 2012 as an amendment to
amendment to the Medium Access Control (MAC) protocol defined by the the Medium Access Control (MAC) protocol defined by the
IEEE802.15.4-2011 [IEEE802154] standard. The Timeslotted Channel IEEE802.15.4-2011 [IEEE802154] standard. IEEE802.15.4e will be
Hopping (TSCH) mode of IEEE802.15.4e is the object of this document. rolled into the next revision of IEEE802.15.4, scheduled to be
published in 2015. The Timeslotted Channel Hopping (TSCH) mode of
IEEE802.15.4e is the object of this document.
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 IEEE802.15.4e TSCH in the LLN context, following the terminology
defined in [I-D.ietf-6tisch-terminology]. defined in [I-D.ietf-6tisch-terminology].
TSCH was designed to "allow IEEE802.15.4 devices to support a wide TSCH was designed to allow IEEE802.15.4 devices to support a wide
range of industrial applications" [IEEE802154e]. At its core is a range of applications including, but not limited to, industrial ones
medium access technique which uses time synchronization to achieve [IEEE802154e]. At its core is a medium access technique which uses
ultra low-power operation and channel hopping to enable high time synchronization to achieve ultra low-power operation and channel
reliability. This is very different from the "legacy" IEEE802.15.4 hopping to enable high reliability. Synchronization accuracy impacts
MAC protocol, and is therefore better described as a "redesign". power consumption, and can vary from micro-seconds to milli-seconds
TSCH does not amend the physical layer; i.e., it can operate on any depending on the solution. This is very different from the "legacy"
IEEE802.15.4-compliant hardware. IEEE802.15.4 MAC protocol, and is therefore better described as a
"redesign". TSCH does not amend the physical layer; i.e., it can
operate on any IEEE802.15.4-compliant hardware.
IEEE802.15.4e can be seen as the latest generation of ultra-lower IEEE802.15.4e is the latest generation of ultra-lower power and
power and reliable networking solutions for LLNs. [RFC5673] reliable networking solutions for LLNs. [RFC5673] discusses
discusses industrial applications, and highlights the harsh operating industrial applications, and highlights the harsh operating
conditions as well as the stringent reliability, availability, and conditions as well as the stringent reliability, availability, and
security requirements for an LLN to operate in an industrial security requirements for an LLN to operate in an industrial
environment. Commercial networking solutions are available today in environment. In these environments, vast deployment environments
with large (metallic) equipment cause multi-path fading and
interference to thwart any attempt of a single-channel solution to be
reliable; the channel agility of TSCH is the key to its ultra high
reliability. Commercial networking solutions are available today in
which motes consume 10's of micro-amps on average [CurrentCalculator] which motes consume 10's of micro-amps on average [CurrentCalculator]
with end-to-end packet delivery ratios over 99.999% with end-to-end packet delivery ratios over 99.999%
[doherty07channel]. [doherty07channel].
Bringing industrial-like performance into the LLN stack developed by
Internet of Things (IoT) related IETF working groups such as 6Lo,
ROLL and CoRE opens up new application domains for these networks.
Sensors deployed in smart cities [RFC5548] will be able to be
installed for years without needing battery replacement. "Umbrella"
networks will interconnect smart elements from different entities in
smart buildings [RFC5867]. Peel-and-stick switches will obsolete the
need for costly conduits for lighting solutions in smart homes
[RFC5826].
IEEE802.15.4e TSCH focuses on the MAC layer only. This clean IEEE802.15.4e TSCH focuses on the MAC layer only. This clean
layering allows for TSCH to fit under an IPv6 enabled protocol stack layering allows for TSCH to fit under an IPv6 enabled protocol stack
for LLNs, running 6LoWPAN [RFC6282], RPL [RFC6550] and CoAP for LLNs, running 6LoWPAN [RFC6282], IPv6 Routing Protocol for Low
[RFC7252]. power and Lossy Networks (RPL) [RFC6550] and the Constrained
Application Protocol (CoAP) [RFC7252]. What is missing is a Logical
Bringing industrial-like performance into the LLN stack developed by Link Control (LLC) layer between the IP abstraction of a link and the
the 6LoWPAN, ROLL and CORE working groups opens up new application TSCH MAC, which is in charge of scheduling a timeslot for a given
domains for these networks. Sensors deployed in smart cities packet coming down the stack from the upper layer.
[RFC5548] will be able to be installed for years without needing
battery replacement. "Umbrella" networks will interconnect smart
elements from different entities in smart buildings [RFC5867]. Peel-
and-stick switches will obsolete the need for costly conduits for
lighting solutions in smart homes [RFC5826].
While [IEEE802154e] defines the mechanisms for a TSCH mote to While [IEEE802154e] defines the mechanisms for a TSCH mote 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 signalling 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, IEEE802.15.4e TSCH is designed to allow optimizations
and strong customizations, simplifying the merging of TSCH with a and strong customizations, simplifying the merging of TSCH with a
protocol stack based on IPv6, 6LoWPAN, and RPL. protocol stack based on IPv6, 6LoWPAN, and RPL.
2. TSCH in the LLN Context 2. Requirements Language
In many cases, to map the services required by the IP layer to the The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
services provided by the link layer, an adaptation layer is used "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. TSCH in the LLN Context
To map the services required by the IP layer to the services provided
by the link layer, an adaptation layer is used
[palattella12standardized]. The 6LoWPAN working group started [palattella12standardized]. The 6LoWPAN working group started
working in 2007 on specifications for transmitting IPv6 packets over working in 2007 on specifications for transmitting IPv6 packets over
IEEE802.15.4 networks [RFC4919]. Typically, low-power WPANs are IEEE802.15.4 networks [RFC4919]. Low-power WPANs are characterized
characterized by small packet sizes, support for addresses with by small packet sizes, support for addresses with different lengths,
different lengths, low bandwidth, star and mesh topologies, battery low bandwidth, star and mesh topologies, battery powered devices, low
powered devices, low cost, large number of devices, unknown node cost, large number of devices, unknown node positions, high
positions, high unreliability, and periods during which communication unreliability, and periods during which communication interfaces are
interfaces are turned off to save energy. Given these features, it turned off to save energy. Given these features, it is clear that
is clear that the adoption of IPv6 on top of a Low-Power WPAN is not the adoption of IPv6 on top of a Low-Power WPAN is not
straightforward, but poses strong requirements for the optimization straightforward, but poses strong requirements for the optimization
of this adaptation layer. For instance, due to the IPv6 default of this adaptation layer.
minimum MTU size (1280 bytes), an un-fragmented IPv6 packet is too
large to fit in an IEEE802.15.4 frame. Moreover, the overhead due to For instance, due to the IPv6 default minimum MTU size (1280 bytes),
the 40-byte long IPv6 header wastes the scarce bandwidth available at an un-fragmented IPv6 packet is too large to fit in an IEEE802.15.4
the PHY layer [RFC4944]. For these reasons, the 6LoWPAN working frame. Moreover, the overhead due to the 40-byte long IPv6 header
group has defined an effective adaptation layer [RFC6568]. Further wastes the scarce bandwidth available at the PHY layer [RFC4944].
issues encompass the auto-configuration of IPv6 addresses For these reasons, the 6LoWPAN working group has defined an effective
[RFC2464][RFC6755], the compliance with the recommendation on adaptation layer [RFC6282]. Further issues encompass the auto-
supporting link-layer subnet broadcast in shared networks [RFC3819], configuration of IPv6 addresses [RFC2460][RFC4862], the compliance
the reduction of routing and management overhead [RFC6606], the with the recommendation on supporting link-layer subnet broadcast in
adoption of lightweight application protocols (or novel data encoding shared networks [RFC3819], the reduction of routing and management
techniques), and the support for security mechanisms (confidentiality overhead [RFC6606], the adoption of lightweight application protocols
and integrity protection, device bootstrapping, key establishment, (or novel data encoding techniques), and the support for security
and management). mechanisms (confidentiality and integrity protection, device
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 4.
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 working group has defined RPL
in [RFC6550]. RPL can support a wide variety of link layers, in [RFC6550]. RPL can support a wide variety of link layers,
including ones that are constrained, potentially lossy, or typically including ones that are constrained, potentially lossy, or typically
utilized in conjunction with host or router devices with very limited utilized 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, motes are connected through multi-hop paths to a typical setting, motes 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. The topology is set up based on a Rank metric, which scenario.
encodes the distance of each node with respect to its reference root,
as specified by the Objective Function. Regardless of the way it is The topology is set up based on a Rank metric, which encodes the
distance of each node with respect to its reference root, as
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 destination, building a gradient. RPL encompasses different the root, building a gradient. RPL encompasses different kinds of
kinds of traffic and signalling information. Multipoint-to-Point traffic and signaling information. Multipoint-to-Point (MP2P) is the
(MP2P) is the dominant traffic in LLN applications. Data is routed dominant traffic in LLN applications. Data is routed towards nodes
towards nodes with some application relevance, such as the LLN with some application relevance, such as the LLN gateway to the
gateway to the larger Internet, or to the core of private IP larger Internet, or to the core of private IP networks. In general,
networks. In general, these destinations are the DODAG roots and act these destinations are the DODAG roots and act as data collection
as data collection points for distributed monitoring applications. points for distributed monitoring applications. Point-to-Multipoint
Point-to-Multipoint (P2MP) data streams are used for actuation (P2MP) data streams are used for actuation purposes, where messages
purposes, where messages are sent from DODAG roots to destination are sent from DODAG roots to destination nodes. Point-to-Point (P2P)
nodes. Point-to-Point (P2P) traffic allows communication between two traffic allows communication between two devices belonging to the
devices belonging to the same LLN, such as a sensor and an actuator. same LLN, such as a sensor and an actuator. A packet flows from the
A packet flows from the source to the common ancestor of those two source to the common ancestor of those two communicating devices,
communicating devices, then downward towards the destination. RPL then downward towards the destination. RPL therefore has to discover
therefore has to discover both upward routes (i.e. from nodes to both upward routes (i.e. from nodes to DODAG roots) in order to
DODAG roots) in order to enable MP2P and P2P flows, and downward enable MP2P and P2P flows, and downward routes (i.e. from DODAG roots
routes (i.e. from DODAG roots to nodes) to support P2MP and P2P to nodes) to support P2MP and P2P traffic.
traffic.
Section 3 highlights the challenges that need to be addressed to use Section 4 highlights the challenges that need to be addressed to use
RPL on top of TSCH. RPL on top of TSCH.
Several open-source initiatives have emerged around TSCH. The Several open-source initiatives have emerged around TSCH. The
OpenWSN project [OpenWSN][OpenWSNETT] is an open-source OpenWSN project [OpenWSN][OpenWSNETT] is an open-source
implementation of a standards-based protocol stack, which aims at implementation of a standards-based protocol stack, which aims at
evaluating the applicability of TSCH to different applications. This evaluating the applicability of TSCH to different applications. This
implementation was used as the foundation for an IP for Smart Objects implementation was used as the foundation for an IP for Smart Objects
Alliance (IPSO) [IPSO] interoperability event in 2011. In the Alliance (IPSO) [IPSO] interoperability event in 2011. In the
absence of a standardized scheduling mechanism for TSCH, a "slotted absence of a standardized scheduling mechanism for TSCH, a "slotted
Aloha" schedule was used. Aloha" schedule was used.
3. Problems and Goals 4. Problems and Goals
As highlighted in Appendix A, TSCH is different for traditional low- As highlighted in Appendix A, TSCH differs from traditional low-power
power MAC protocols because of its scheduled nature. TSCH defines MAC protocols because of its scheduled nature. TSCH defines the
the mechanisms to execute a communication schedule, yet it is the mechanisms to execute a communication schedule, yet it is the entity
entity that sets up that schedule which controls the topology of the that sets up that schedule which controls the topology of the
network. This scheduling entity also controls the resources network. This scheduling entity also controls the resources
allocated to each link in that topology. allocated to each 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 will refer to this entity by the to address. For simplicity, we refer to this entity by the generic
generic name "6TiSCH". Note that the 6top sublayer, currently being name "LLC". Note that the 6top sublayer, currently being defined in
defined in [I-D.wang-6tisch-6top-sublayer], can be seen as an [I-D.wang-6tisch-6top-sublayer], can be seen as an embodiment of this
embodiment of this generic "6TiSCH". generic "LLC".
Some of the issues 6TiSCH 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 6TiSCH will profit from the services case, it is entailed that the LLC will profit from the services
provided by other protocols to pursue these objectives. provided by other protocols to pursue these objectives.
3.1. Network Formation 4.1. Network Formation
6TiSCH 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 motes join, and how already joined motes advertise the presence new motes join, and how already joined motes advertise the presence
of the network. 6TiSCH needs to: of the network. The LLC needs to:
1. Define the Information Elements to include in the Enhanced 1. Define the Information Elements included in the Enhanced Beacons
Beacons advertising the presence of the network. advertising the presence of the network.
2. For a new mote, define rules to process and filter received 2. For a new mote, define rules to process and filter received
Enhanced Beacons. Enhanced Beacons.
3. Define the joining procedure. This includes a mechanism to 3. Define the joining procedure. This might include a mechanism to
assign a unique 16-bit address to a mote, and the management of assign a unique 16-bit address to a mote, 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
links. cells.
3.2. Network Maintenance 4.2. Network Maintenance
Once a network is formed, 6TiSCH needs to maintain the network's Once a network is formed, the LLC needs to maintain the network's
health, allowing for motes to stay synchronized. 6TiSCH needs to: health, allowing for motes to stay synchronized. The LLC needs to:
1. Manage each mote's time source neighbor. 1. Manage each mote's time source neighbor.
2. Define a mechanism for a mote to update the join priority it 2. Define a mechanism for a mote to update the join priority it
announces in its Enhanced Beacon. announces in its Enhanced Beacon.
3. Schedule transmissions of Enhanced Beacons to advertise the 3. Schedule transmissions of Enhanced Beacons to advertise the
presence of the network. presence of the network.
3.3. Multi-Hop Topology 4.3. Multi-Hop Topology
RPL, given a weighted connectivity graph, determines multi-hop RPL, given a weighted connectivity graph, determines multi-hop
routes. 6TiSCH needs to: routes. The LLC needs to:
1. Define a mechanism to gather topological information, which it 1. Define a mechanism to gather topological information, which it
can then feed to RPL. can then feed to RPL.
2. Ensure that the TSCH schedule contains links along the multi-hop 2. Ensure that the TSCH schedule contains cells along the multi-hop
routes identified by RPL. routes identified by RPL.
3. Where applicable, maintain independent sets of links 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 4.4. Routing and Timing Parents
At all times, a TSCH mote needs to have a time source neighbor it can At all times, a TSCH mote needs to have a time source neighbor it can
synchronize to. 6TiSCH therefore needs to assign a time source synchronize to. The LLC therefore needs to assign a time source
neighbor to allow for correct operation of the TSCH network. A time neighbor to allow for correct operation of the TSCH network. A time
source neighbors could, or not, be taken from the RPL routing parent source neighbors could, or not, be taken from the RPL routing parent
set. set.
3.5. Resource Management 4.5. Resource Management
A link in a TSCH schedule is a "unit" of resource. The number of
links to assign between neighbor motes needs to be appropriate for
the size of the traffic flow. 6TiSCH needs to:
1. Define rules on when to create or delete a slotframe.
2. Define rules to determine the length of a slotframe, and the
trigger to modify the length of a slotframe.
3. Define rules on when to add or delete links in a particular A cell in a TSCH schedule is an atomic "unit" of resource. The
slotframe. number of cells to assign between neighbor motes needs to be
appropriate for the size of the traffic flow. The LLC needs to:
4. 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 links. deletion of cells.
5. 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 PCE, etc.) to take control of the schedule. protocol, a PCE, etc.) to take control of the schedule.
6. Define a set of metrics to evaluate the trade-off between 4.6. Dataflow Control
latency, bandwidth and energy consumption achieved by a
particular schedule.
3.6. Dataflow Control
TSCH defines mechanisms for a mote to signal it cannot accept an TSCH defines mechanisms for a mote to signal it cannot accept an
incoming packet. It does not, however, define the policy which incoming packet. It does not, however, define the policy which
determines when to stop accepting packets. 6TiSCH needs to: determines when to stop accepting packets. The LLC needs to:
1. Define a queueing policy for incoming and outgoing packets. 1. Define a queuing policy for 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 acknowledgement. This covers both times, without receiving an acknowledgment. This covers both
dedicated and shared links. dedicated and shared cells.
3.7. Deterministic Behavior 4.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. 6TiSCH needs to: which is deterministic and predictable. The LLC needs to:
1. Ensure timely delivery of such data. 1. Ensure timely delivery of such data.
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 4.8. Scheduling Mechanisms
Several scheduling mechanisms can be envisioned, and possibly coexist Several scheduling mechanisms can be envisioned, and possibly coexist
in the same network. For example, in the same network. For example,
[I-D.phinney-roll-rpl-industrial-applicability] describe how the [I-D.phinney-roll-rpl-industrial-applicability] describes how the
allocation of bandwidth can be optimized by an external Path allocation of bandwidth can be optimized by an external Path
Computation Element (PCE). Alternatively, two neighbor nodes can Computation Element (PCE). Alternatively, two neighbor nodes can
adapt the number of cells autonomously by monitoring the amount of adapt the number of cells autonomously by monitoring the amount of
traffic, and negotiating the allocation to extra cell when needed. traffic, and negotiating the allocation to extra cell when needed.
This mechanism can be used to establish multi-hop paths in a fashion This mechanism can be used to establish multi-hop paths in a fashion
similar to RSVP. 6TiSCH needs to: similar to RSVP. The LLC needs to:
1. Provide a mechanism for two 6TiSCH devices to negotiate the 1. Provide a mechanism for two 6TiSCH devices to negotiate the
allocation and deallocation of cells between them. allocation and deallocation of cells between them.
2. Provide a mechanism for device to monitor and manage the 6TiSCH 2. Provide a mechanism for device to monitor and manage the 6TiSCH
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 an mechanism for these different scheduling mechanisms to
coexist in the same network. coexist in the same network.
3.9. Secure Communication 4.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. 6TiSCH 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 mote to join an existing network. a new mote 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 motes. application data between neighbor motes.
3. Define a mechanism to allow for the secure transfer of signalling 3. Define a mechanism to allow for the secure transfer of signaling
data between motes and 6TiSCH. data between motes and the LLC.
4. Acknowledgements 5. IANA Considerations
This memo includes no request to IANA.
6. Security Considerations
This memo is an informational overview of existing standards, and
does define any new mechanisms or protocols.
It does describe the need for the 6TiSCH WG to define a secure
solution. In particular, Section 4.1 describes security in the join
process. Section 4.9 discusses data frame protection.
7. Acknowledgments
Special thanks to Jonathan Simon for his review and valuable Special thanks to Jonathan Simon for his review and valuable
comments. Thanks to the IoT6 European Project (STREP) of the 7th comments. Thanks to the IoT6 European Project (STREP) of the 7th
Framework Program (Grant 288445). Framework Program (Grant 288445).
5. References 8. References
5.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
5.2. Informative References 8.2. Informative References
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, June 2014. Application Protocol (CoAP)", RFC 7252, June 2014.
[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
for OAuth", RFC 6755, October 2012.
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
Statement and Requirements for IPv6 over Low-Power Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing", RFC Wireless Personal Area Network (6LoWPAN) Routing", RFC
6606, May 2012. 6606, May 2012.
[RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and
Application Spaces for IPv6 over Low-Power Wireless Application Spaces for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)", RFC 6568, April 2012. Personal Area Networks (6LoWPANs)", RFC 6568, April 2012.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
skipping to change at page 10, line 39 skipping to change at page 11, line 14
[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, September 2007.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs): over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals", RFC Overview, Assumptions, Problem Statement, and Goals", RFC
4919, August 2007. 4919, August 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89, Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, July 2004. RFC 3819, July 2004.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
Networks", RFC 2464, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[I-D.ietf-6tisch-tsch] [I-D.ietf-6tisch-tsch]
Watteyne, T., Palattella, M., and L. Grieco, "Using Watteyne, T., Palattella, M., and L. Grieco, "Using
IEEE802.15.4e TSCH in an LLN context: Overview, Problem IEEE802.15.4e TSCH in an LLN context: Overview, Problem
Statement and Goals", draft-ietf-6tisch-tsch-00 (work in Statement and Goals", draft-ietf-6tisch-tsch-01 (work in
progress), November 2013. progress), July 2014.
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., Watteyne, T., and R. Assimiti, "An Thubert, P., Watteyne, T., and R. Assimiti, "An
Architecture for IPv6 over the TSCH mode of IEEE Architecture for IPv6 over the TSCH mode of IEEE
802.15.4e", draft-ietf-6tisch-architecture-02 (work in 802.15.4e", draft-ietf-6tisch-architecture-03 (work in
progress), June 2014. progress), July 2014.
[I-D.ietf-6tisch-terminology] [I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terminology in IPv6 over the TSCH mode of IEEE "Terminology in IPv6 over the TSCH mode of IEEE
802.15.4e", draft-ietf-6tisch-terminology-01 (work in 802.15.4e", draft-ietf-6tisch-terminology-02 (work in
progress), February 2014. progress), July 2014.
[I-D.ietf-6tisch-minimal] [I-D.ietf-6tisch-minimal]
Vilajosana, X. and K. Pister, "Minimal 6TiSCH Vilajosana, X. and K. Pister, "Minimal 6TiSCH
Configuration", draft-ietf-6tisch-minimal-01 (work in Configuration", draft-ietf-6tisch-minimal-02 (work in
progress), June 2014. progress), July 2014.
[I-D.ietf-6tisch-6top-interface] [I-D.ietf-6tisch-6top-interface]
Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
Operation Sublayer (6top) Interface", draft-ietf-6tisch- Operation Sublayer (6top) Interface", draft-ietf-6tisch-
6top-interface-00 (work in progress), March 2014. 6top-interface-01 (work in progress), July 2014.
[I-D.wang-6tisch-6top-sublayer] [I-D.wang-6tisch-6top-sublayer]
Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
Operation Sublayer (6top)", draft-wang-6tisch-6top- Operation Sublayer (6top)", draft-wang-6tisch-6top-
sublayer-00 (work in progress), February 2014. sublayer-01 (work in progress), July 2014.
[I-D.ietf-6tisch-coap] [I-D.ietf-6tisch-coap]
Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and
Interaction using CoAP", draft-ietf-6tisch-coap-00 (work Interaction using CoAP", draft-ietf-6tisch-coap-01 (work
in progress), May 2014. in progress), July 2014.
[I-D.thubert-roll-forwarding-frags] [I-D.thubert-roll-forwarding-frags]
Thubert, P. and J. Hui, "LLN Fragment Forwarding and Thubert, P. and J. Hui, "LLN Fragment Forwarding and
Recovery", draft-thubert-roll-forwarding-frags-02 (work in Recovery", draft-thubert-roll-forwarding-frags-02 (work in
progress), September 2013. progress), September 2013.
[I-D.tsao-roll-security-framework] [I-D.tsao-roll-security-framework]
Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A
Security Framework for Routing over Low Power and Lossy Security Framework for Routing over Low Power and Lossy
Networks", draft-tsao-roll-security-framework-02 (work in Networks", draft-tsao-roll-security-framework-02 (work in
skipping to change at page 12, line 44 skipping to change at page 13, line 23
Object Security Workshop', 23rd March 2012, Paris, Object Security Workshop', 23rd March 2012, Paris,
France", draft-gilger-smart-object-security-workshop-00 France", draft-gilger-smart-object-security-workshop-00
(work in progress), October 2012. (work in progress), October 2012.
[I-D.phinney-roll-rpl-industrial-applicability] [I-D.phinney-roll-rpl-industrial-applicability]
Phinney, T., Thubert, P., and R. Assimiti, "RPL Phinney, T., Thubert, P., and R. Assimiti, "RPL
applicability in industrial networks", draft-phinney-roll- applicability in industrial networks", draft-phinney-roll-
rpl-industrial-applicability-02 (work in progress), rpl-industrial-applicability-02 (work in progress),
February 2013. February 2013.
5.3. External Informative References 8.3. External Informative References
[IEEE802154e] [IEEE802154e]
IEEE standard for Information Technology, "IEEE std. IEEE standard for Information Technology, "IEEE std.
802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
Networks (LR-WPANs) Amendament 1: MAC sublayer", April Networks (LR-WPANs) Amendament 1: MAC sublayer", April
2012. 2012.
[IEEE802154] [IEEE802154]
IEEE standard for Information Technology, "IEEE std. IEEE standard for Information Technology, "IEEE std.
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
skipping to change at page 15, line 24 skipping to change at page 15, line 52
presented precisely. presented precisely.
o Techniques and ideas which are part of IEEE802.15.4e and which o Techniques and ideas which are part of IEEE802.15.4e and which
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. Timeslots
All motes in a TSCH network are synchronized. Time is sliced up into All motes in a TSCH network are synchronized. Time is sliced up into
timeslots. A timeslot is long enough for a MAC frame of maximum size timeslots. A timeslot is long enough for a MAC frame of maximum size
to be sent from mote A to mote B, and for mote B to reply with an to be sent from mote A to mote B, and for mote B to reply with an
acknowledgement (ACK) frame indicating successful reception. acknowledgment (ACK) frame indicating successful reception.
The duration of a timeslot is not defined by the standard. With The duration of a timeslot is not defined by the standard. With
IEEE802.15.4-compliant radios operating in the 2.4GHz frequency band, IEEE802.15.4-compliant radios operating in the 2.4GHz frequency band,
a maximum-length frame of 127 bytes takes about 4ms to transmit; a a maximum-length frame of 127 bytes takes about 4ms to transmit; a
shorter ACK takes about 1ms. With a 10ms slot (a typical duration), shorter ACK takes about 1ms. With a 10ms slot (a typical duration),
this leaves 5ms to radio turnaround, packet processing and security this leaves 5ms to radio turnaround, packet processing and security
operations. operations.
A.2. Slotframes A.2. Slotframes
skipping to change at page 15, line 46 skipping to change at page 16, line 25
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 10s
to 1000s of timeslots. The shorter the slotframe, the more often a to 1000s of timeslots. The shorter the slotframe, the more often a
timeslot repeats, resulting in more available bandwidth, but also in timeslot 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 mote what to do in each timeslot: A TSCH schedule instructs each mote what to do in each timeslot:
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 to communicate with.
Once a mote obtains its schedule, it executes it: Once a mote obtains its schedule, it executes it:
o For each transmit cell, the mote checks whether there is a packet o For each transmit cell, the mote checks whether there is a packet
in the outgoing buffer which matches the neighbor written in the in the outgoing buffer which matches the neighbor written in the
schedule information for that timeslot. If there is none, the schedule information for that timeslot. If there is none, the
mote keeps its radio off for the duration of the timeslot. If mote keeps its radio off for the duration of the timeslot. If
there is one, the mote can ask for the neighbor to acknowledge it, there is one, the mote can ask for the neighbor to acknowledge it,
in which case it has to listen for the acknowledgement after in which case it has to listen for the acknowledgment after
transmitting. transmitting.
o For each receive cell, the mote listens for possible incoming o For each receive cell, the mote 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
mote, and passes security checks, the mote can send back an mote, and passes security checks, the mote can send back an
acknowledgement. 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 IEEE802.15.4e standard.
A.4. Cells and Bundles A.4. Cells and Bundles
Assuming the schedule is well built, if mote A is scheduled to Assuming the schedule is well built, if mote A is scheduled to
transmit to mote B at slotOffset 5 and channelOffset 11, mote B will transmit to mote B at slotOffset 5 and channelOffset 11, mote B will
be scheduled to receive from mote A at the same slotOffset and be scheduled to receive from mote 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 mote A to transmit to mote B (or for channelOffset, and reserved for mote A to transmit to mote B (or for
mote B to receive from mote A) within a given slotframe, is called a mote B to receive from mote A) within a given slotframe, is called a
"scheduled cell". "scheduled cell".
If there is a lot of data flowing from mote A to mote B, the schedule If there is a lot of data flowing from mote A to mote 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, i.e.
the MAC layer sends the packet on whichever of these cells happens to the MAC layer sends the packet on whichever of these cells shows up
show up first after the packet was put in the MAC queue. The union first after the packet was put in the MAC queue. The union of all
of all cells between two neighbors, A and B, is called a "bundle". cells between two neighbors, A and B, is called a "bundle". Since
Since the slotframe repeats over time (and the length of the the slotframe repeats over time (and the length of the slotframe is
slotframe is typically constant), each cell gives a "quantum" of typically constant), each cell gives a "quantum" of bandwidth to a
bandwidth to a given neighbor. Modifying the number of equivalent given neighbor. Modifying the number of equivalent cells in a bundle
cells in a bundle modifies the amount of resources allocated between modifies the amount of resources allocated between two neighbors.
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 mote A to transmit to mote B. dedicated, i.e., reserved only for mote A to transmit to mote B.
IEEE802.15.4e allows also to mark a cell as shared. In a shared IEEE802.15.4e allows also to mark a cell as shared. In a shared
cell, multiple motes can transmit at the same time, on the same cell, multiple motes can transmit at the same time, on the same
frequency. To avoid contention, TSCH defines a back-off algorithm frequency. To avoid contention, TSCH defines a back-off algorithm
for shared cells. 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 mote transmits if it has an appropriate packet in its In this case, a mote 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,shared,receive] 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 mote learns the current ASN when it joins the t the slotOffset. A mote learns the current ASN when it joins the
network. Since motes are synchronized, they all know the current network. Since motes 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. The value depends on the duration of a timeslot) without wrapping over.
ASN is used to calculate the frequency to communicate on, and can be The ASN is used to calculate the frequency to communicate on, and can
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 mote A has a transmit channelOffset. In a well-built schedule, when mote A has a transmit
cell to mote B on channelOffset 5, mote B has a receive cell from cell to mote B on channelOffset 5, mote B has a receive cell from
mote A on the same channelOffset. The channelOffset is translated by mote 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}
skipping to change at page 17, line 51 skipping to change at page 18, line 28
channelOffset values as there are frequencies available (e.g. 16 when channelOffset values as there are frequencies available (e.g. 16 when
using IEEE802.15.4-compliant radios at 2.4GHz, when all channels are using IEEE802.15.4-compliant radios at 2.4GHz, when all channels are
used). Since both motes have the same channelOffset written in their used). Since both motes have the same channelOffset written in their
schedule for that scheduled cell, and the same ASN counter, they schedule for that scheduled cell, and the same ASN counter, they
compute the same frequency. At the next iteration (cycle) of the compute the same frequency. At the next iteration (cycle) of the
slotframe, however, while the channelOffset is the same, the ASN has slotframe, however, while the channelOffset is the same, the ASN has
changed, resulting in the computation of a different frequency. 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. Channel hopping is a technique known to efficiently communicating. A way of ensuring communication happens on all
combat multi-path fading and external interference. available frequencies is to set the number of timeslots in a
slotframe to a prime number. Channel hopping is a technique known to
efficiently combat multi-path fading and external interference.
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,
motes have to maintain tight synchronization. All motes are assumed motes have to maintain tight synchronization. All motes 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 motes drift with respect to one another, neighbor clocks in different motes drift with respect to one another, neighbor
motes need to periodically re-synchronize. motes need to periodically re-synchronize.
Each mote needs to periodically synchronize its network clock to Each mote needs to periodically synchronize its network clock to
another mote, and it also provides its network time to its neighbors. another mote, 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 mote, i.e., to indicate in the adequate time source neighbor to each mote, i.e., to indicate in the
schedule which of neighbor is its "time source neighbor". While schedule which of neighbor is its "time source neighbor". While
setting the time source neighbor, it is important to avoid setting the time source neighbor, it is important to avoid
synchronization loops, which could result in the formation of synchronization loops, which could result in the formation of
independent clusters of motes. independent clusters of synchronized motes.
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 motes can data and ACK frames). This means that neighbor motes can
resynchronize to one another whenever they exchange data. In detail, resynchronize to one another whenever they exchange data. In detail,
in the IEEE 802.15.4e standard two methods are defined for allowing a two methods are defined in IEEE802.15.4e-2012 for allowing a device
device to synchronize in a TSCH network: (i) Acknowledgement-Based to synchronize in a TSCH network: (i) Acknowledgment-Based and (ii)
and (ii) Frame-Based synchronization. In both cases, the receiver Frame-Based synchronization. In both cases, the receiver calculates
calculates the difference in time between the expected time of frame the difference in time between the expected time of frame arrival and
arrival and its actual arrival. In Acknowledgement-Based its actual arrival. In Acknowledgment-Based synchronization, the
synchronization, the receiver provides such information to the sender receiver provides such information to the sender mote in its
mote in its acknowledgement. Thus, in this case, it is the sender acknowledgment. In this case, it is the sender mote that
mote 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. Therefore, it is the receiver mote that synchronizes its own clock. In this case, it is the receiver mote that
to the clock of the sender. synchronizes to the clock of the sender.
Different synchronization policies are possible. Motes can keep Different synchronization policies are possible. Motes can keep
synchronization exclusively by exchanging EBs. Motes can also keep synchronization exclusively by exchanging EBs. Motes 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 acknowledgement to resynchronize. Both method neighbor and use the acknowledgment to resynchronize. Both method
(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 mote can perform during a There are only a handful of activities a mote 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 depending on the some energy cost associated to them, the exact value depends on the
the hardware used. Given the schedule of a mote, it is the hardware used. Given the schedule of a mote, it is
straightforward to calculate the expected average power consumption straightforward to calculate the expected average power consumption
of that mote. of that mote.
A.10. Network TSCH Schedule A.10. Network TSCH Schedule
The schedule defines entirely the synchronization and communication The schedule entirely defines the synchronization and communication
between motes. By adding/removing cells between neighbors, one can between motes. 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 motes need to o Make the schedule "sparse" for applications where motes 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 motes generate a o Make the schedule "dense" for applications where motes 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
Motes already part of the network can periodically send Enhanced Motes already part of the network can periodically send Enhanced
Beacon (EB) frames to announce the presence the network. These Beacon (EB) frames to announce the presence of the network. These
contain information about the size of the timeslot used in the contain information about the size of the timeslot used in the
network, the current ASN, information about the slotframes and network, the current ASN, information about the slotframes and
timeslots the beaconing mote is listening on, and a 1-byte join timeslots the beaconing mote is listening on, and a 1-byte join
priority. Because of the channel hopping nature of TSCH, these EB priority. Even if a node is configured to send all EB frames on the
same channel offset, because of the channel hopping nature of TSCH
described in Appendix A.7, this channel offset translates into a
different frequency at different slotframe cycles. As a result, EB
frames are sent on all frequencies. frames are sent on all frequencies.
A mote wishing to join the network listens for EBs. Using the ASN A mote wishing to join the network listens for EBs. Since EBs are
and the other timing information of the EB, the new mote synchronizes sent on all frequencies, the joining node can listen on any frequency
to the network. Using the slotframe and link information from the until it hears an EB. What frequency it listens on, and whether it
EB, it knows how to contact the network. slowly changes frequency during this joining period is
implementation-specific. Using the ASN and the other timing
information of the EB, the new mote synchronizes to the network.
Using the slotframe and cell information from the EB, it knows how to
contact other nodes in the network.
The IEEE802.15.4e TSCH standard does not define the steps beyond this The IEEE802.15.4e TSCH standard does not define the steps beyond this
network "bootstrap". 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
information element is a list of Type-Length-Value containers placed information element is a list of Type-Length-Value containers placed
at the end of the MAC header. A small number of types are defined at the end of the MAC header. A small number of types are defined
for TSCH (e.g., the ASN in the EB is contained in an IE), and an for TSCH (e.g., the ASN in the EB is contained in an IE), and an
skipping to change at page 20, line 25 skipping to change at page 21, line 14
Appendix B. TSCH Gotchas Appendix B. TSCH Gotchas
This section lists features of TSCH which we believe are important This section lists features of TSCH which we believe are important
and beneficial to the work of 6TiSCH. and beneficial to the work of 6TiSCH.
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 which 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 can communicate 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 motes can exchange data at the same time, but on pairs of neighbor motes 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, these can be considered atomic "units" to schedule. In algorithm, these 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
skipping to change at page 21, line 24 skipping to change at page 22, line 12
each frequency. If a transmission from mote A to mote B fails, each frequency. If a transmission from mote A to mote 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
mote's schedule. It is possible that at some timeslot, a mote has mote's schedule. It is possible that, at some timeslot, a mote has
multiple activities scheduled (e.g. transmit to mote B on slotframe multiple activities scheduled (e.g. transmit to mote B on slotframe
2, receive from mote C on slotframe 1). To handle this situation, 2, receive from mote 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 mote would transmit to mote B on slotframe In the example above, the mote would transmit to mote B on slotframe
 End of changes. 99 change blocks. 
231 lines changed or deleted 264 lines changed or added

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