< draft-watteyne-6tsch-tsch-lln-context-00.txt   draft-watteyne-6tsch-tsch-lln-context-01.txt >
6TSCH T. Watteyne, Ed. 6TSCH T. Watteyne, Ed.
Internet-Draft Linear Technology Internet-Draft Linear Technology
Intended status: Informational February 8, 2013 Intended status: Informational February 21, 2013
Expires: August 12, 2013 Expires: August 25, 2013
Using IEEE802.15.4e TSCH in an LLN context: Using IEEE802.15.4e TSCH in an LLN context:
Overview, Problem Statement and Goals Overview, Problem Statement and Goals
draft-watteyne-6tsch-tsch-lln-context-00 draft-watteyne-6tsch-tsch-lln-context-01
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 34 skipping to change at page 1, line 34
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 August 12, 2013. This Internet-Draft will expire on August 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. TSCH in the LLN Context . . . . . . . . . . . . . . . . . . . 5 2. TSCH in the LLN Context . . . . . . . . . . . . . . . . . . . 5
3. Problems and Goals . . . . . . . . . . . . . . . . . . . . . . 7 3. Problems and Goals . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Network Formation . . . . . . . . . . . . . . . . . . . . 7 3.1. Network Formation . . . . . . . . . . . . . . . . . . . . 7
3.2. Network Maintenance . . . . . . . . . . . . . . . . . . . 7 3.2. Network Maintenance . . . . . . . . . . . . . . . . . . . 7
3.3. Multi-Hop Topology . . . . . . . . . . . . . . . . . . . . 8 3.3. Multi-Hop Topology . . . . . . . . . . . . . . . . . . . . 8
3.4. Routing and Timing Parents . . . . . . . . . . . . . . . . 8 3.4. Routing and Timing Parents . . . . . . . . . . . . . . . . 8
3.5. Resource Management . . . . . . . . . . . . . . . . . . . 8 3.5. Resource Management . . . . . . . . . . . . . . . . . . . 8
3.6. Dataflow Control . . . . . . . . . . . . . . . . . . . . . 9 3.6. Dataflow Control . . . . . . . . . . . . . . . . . . . . . 9
3.7. Secure Communication . . . . . . . . . . . . . . . . . . . 9 3.7. Deterministic Behavior . . . . . . . . . . . . . . . . . . 9
4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.8. Path Computation Engine . . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 3.9. Secure Communication . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. External Informative References . . . . . . . . . . . . . 14 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13
Appendix A. TSCH Protocol Highlights . . . . . . . . . . . . . . 18 6.2. Informative References . . . . . . . . . . . . . . . . . . 13
A.1. Timeslots . . . . . . . . . . . . . . . . . . . . . . . . 18 6.3. External Informative References . . . . . . . . . . . . . 15
A.2. Slotframes . . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. TSCH Protocol Highlights . . . . . . . . . . . . . . 19
A.3. Mote Communication Schedule . . . . . . . . . . . . . . . 18 A.1. Timeslots . . . . . . . . . . . . . . . . . . . . . . . . 19
A.4. Links and Paths . . . . . . . . . . . . . . . . . . . . . 19 A.2. Slotframes . . . . . . . . . . . . . . . . . . . . . . . . 19
A.5. Dedicated vs. Shared Slots . . . . . . . . . . . . . . . . 19 A.3. Mote Communication Schedule . . . . . . . . . . . . . . . 19
A.6. Absolute Slot Number . . . . . . . . . . . . . . . . . . . 20 A.4. Links and Paths . . . . . . . . . . . . . . . . . . . . . 20
A.7. Channel Hopping . . . . . . . . . . . . . . . . . . . . . 20 A.5. Dedicated vs. Shared Slots . . . . . . . . . . . . . . . . 20
A.8. Time Synchronization . . . . . . . . . . . . . . . . . . . 21 A.6. Absolute Slot Number . . . . . . . . . . . . . . . . . . . 21
A.9. Power Consumption . . . . . . . . . . . . . . . . . . . . 21 A.7. Channel Hopping . . . . . . . . . . . . . . . . . . . . . 21
A.10. Network Communication Schedule . . . . . . . . . . . . . . 21 A.8. Time Synchronization . . . . . . . . . . . . . . . . . . . 22
A.11. Join Process . . . . . . . . . . . . . . . . . . . . . . . 22 A.9. Power Consumption . . . . . . . . . . . . . . . . . . . . 23
A.12. Information Elements . . . . . . . . . . . . . . . . . . . 22 A.10. Network Communication Schedule . . . . . . . . . . . . . . 23
A.13. Extensibility . . . . . . . . . . . . . . . . . . . . . . 23 A.11. Join Process . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix B. TSCH Gotchas . . . . . . . . . . . . . . . . . . . . 24 A.12. Information Elements . . . . . . . . . . . . . . . . . . . 24
B.1. Collision Free Communication . . . . . . . . . . . . . . . 24 A.13. Extensibility . . . . . . . . . . . . . . . . . . . . . . 24
B.2. Multi-Channel vs. Channel Hopping . . . . . . . . . . . . 24 Appendix B. TSCH Gotchas . . . . . . . . . . . . . . . . . . . . 25
B.3. Cost of (continuous) Synchronization . . . . . . . . . . . 24 B.1. Collision Free Communication . . . . . . . . . . . . . . . 25
B.4. Topology Stability . . . . . . . . . . . . . . . . . . . . 24 B.2. Multi-Channel vs. Channel Hopping . . . . . . . . . . . . 25
B.5. Multiple Concurrent Slotframes . . . . . . . . . . . . . . 25 B.3. Cost of (continuous) Synchronization . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 B.4. Topology Stability . . . . . . . . . . . . . . . . . . . . 26
B.5. Multiple Concurrent Slotframes . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
The IEEE802.15.4e standard [IEEE802154e] was published in 2012 as an The IEEE802.15.4e standard [IEEE802154e] was published in 2012 as an
amendment to the Medium Access Control (MAC) protocol of the amendment to the Medium Access Control (MAC) protocol defined by the
IEEE802.15.4-2011 [IEEE802154] standard. The Timeslotted Channel IEEE802.15.4-2011 [IEEE802154] standard. The Timeslotted Channel
Hopping (TSCH) mode of the IEEE802.15.4e standard is the object of Hopping (TSCH) mode of IEEE802.15.4e is the object of this document.
this document.
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 industrial applications" [IEEE802154e]. At its core is a
medium access technique which uses time synchronization to achieve medium access technique which uses time synchronization to achieve
ultra low-power operation and channel hopping to enable high ultra low-power operation and channel hopping to enable high
reliability. This is very different from the "legacy" IEEE802.15.4 reliability. This is very different from the "legacy" IEEE802.15.4
MAC protocol, and is therefore better described as a "redesign". MAC protocol, and is therefore better described as a "redesign".
TSCH does not amend the physical layer; i.e. it can operate on any TSCH does not amend the physical layer; i.e., it can operate on any
IEEE802.15.4-compliant hardware. IEEE802.15.4-compliant hardware.
IEEE802.15.4e can be seen as the latest generation of ultra-lower IEEE802.15.4e can be seen as the latest generation of ultra-lower
power and reliable networking solutions for LLNs. Its core power and reliable networking solutions for LLNs. Its core
technology is similar to the one used in industrial networking technology is similar to the one used in industrial networking
technologies such as WirelessHART [WHART] or ISA100.11a [ISA100]. technologies such as WirelessHART [WHART] or ISA100.11a [ISA100].
These protocol solutions have been targeted essentially at the These protocol solutions have been targeted essentially at the
industrial market. WirelessHART is for example the wireless industrial market. WirelessHART is for example the wireless
extension of HART, a long standing protocol suite for networking extension of HART, a long standing protocol suite for networking
industrial equipment. industrial equipment.
[RFC5673] discusses industrial applications, and highlights the harsh [RFC5673] discusses industrial applications, and highlights the harsh
operating conditions as well as the stringent reliability, operating conditions as well as the stringent reliability,
availability and security requirements for an LLN to operate in an availability, and security requirements for an LLN to operate in an
industrial environment. Industrial protocols such as WirelessHART industrial environment. Industrial protocols such as WirelessHART
satisfy those requirements, and with tens of thousands of networks satisfy those requirements, and with tens of thousands of networks
deployed [Emerson], these types of networks have a large impact on deployed [Emerson], these types of networks have a large impact on
industrial applications. Commercial networking solutions are industrial applications. Commercial networking solutions are
available today in which motes consume 10's of micro-amps on average available today in which motes consume 10's of micro-amps on average
[CurrentCalculator] with end-to-end packet delivery ratios over [CurrentCalculator] with end-to-end packet delivery ratios over
99.999% [Doherty]. 99.999% [doherty07channel].
IEEE802.15.4e builds on the same foundations as WirelessHART, and IEEE802.15.4e builds on the same foundations as WirelessHART, and
therefore exhibits similar performance. Yet, unlike an industrial therefore exhibits similar performance. Yet, unlike an industrial
protocol which is, by nature, application-specific, IEEE802.15.4e protocol which is, by nature, application-specific, IEEE802.15.4e
TSCH focuses on the MAC layer only. This clean layering allows for TSCH focuses on the MAC layer only. This clean layering allows for
TSCH to fit under an IPv6 enabled protocol stack for LLNs, running TSCH to fit under an IPv6 enabled protocol stack for LLNs, running
6LoWPAN [RFC6282], RPL [RFC6550] and CoAP [I-D.ietf-core-coap]. 6LoWPAN [RFC6282], RPL [RFC6550] and CoAP [I-D.ietf-core-coap].
Bringing industrial-like performance into the LLN stack developed by Bringing industrial-like performance into the LLN stack developed by
the 6LoWPAN, ROLL and CORE working groups will open up new the 6LoWPAN, ROLL and CORE working groups opens up new application
application domains for these networks. Sensors deployed in smart domains for these networks. Sensors deployed in smart cities
cities [RFC5548] will be able to be installed for years without [RFC5548] will be able to be installed for years without needing
needing battery replacement. "Umbrella" networks will interconnect battery replacement. "Umbrella" networks will interconnect smart
smart elements from different entities in smart buildings [RFC5867]. elements from different entities in smart buildings [RFC5867]. Peel-
Peel-and-stick switches will obsolete the need for costly conduits and-stick switches will obsolete the need for costly conduits for
for lighting solutions in smart homes [RFC5826]. 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 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-configuring 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
and strong customizations, simplifying the merging of TSCH with a
protocol stack based on IPv6, 6LoWPAN, and RPL.
2. TSCH in the LLN Context 2. TSCH in the LLN Context
In many cases, to map the services required by the IP layer to the In many cases, to map the services required by the IP layer to the
services provided by the link layer, an adaptation layer is used services provided by the link layer, an adaptation layer is used
[palattella12standardized]. The 6LoWPAN working group has started in [palattella12standardized]. The 6LoWPAN working group started
2007 to work on specifications for transmitting IPv6 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]. Typically, low-power WPANs are
characterized by small packet sizes, support for addresses with characterized by small packet sizes, support for addresses with
different lengths, low bandwidth, star and mesh topologies, battery different lengths, low bandwidth, star and mesh topologies, battery
powered devices, low cost, large number of devices, unknown node powered devices, low cost, large number of devices, unknown node
positions, high unreliability, and periods during which communication positions, high unreliability, and periods during which communication
interfaces are turned off to save energy. Given these features, it interfaces are turned off to save energy. Given these features, it
is clear that the adoption of IPv6 on top of a Low-Power WPAN is not is clear that 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. For instance, due to the IPv6 default
minimum MTU size (1280 bytes), an un-fragmented IPv6 packet would be minimum MTU size (1280 bytes), an un-fragmented IPv6 packet is too
too large to fit in an IEEE802.15.4 frame. Moreover, the overhead large to fit in an IEEE802.15.4 frame. Moreover, the overhead due to
due to the 40-byte long IPv6 header would waste the scarce bandwidth the 40-byte long IPv6 header wastes the scarce bandwidth available at
available at the PHY layer [RFC4944]. For these reasons, the 6LoWPAN the PHY layer [RFC4944]. For these reasons, the 6LoWPAN working
working group has defined an effective adaptation layer [RFC6568]. group has defined an effective adaptation layer [RFC6568]. Further
Further issues encompass the auto-configuration of IPv6 addresses issues encompass the auto-configuration of IPv6 addresses
[RFC2464][RFC6755], the compliance with the recommendation on [RFC2464][RFC6755], the compliance with the recommendation on
supporting link-layer subnet broadcast in shared networks [RFC3819], supporting link-layer subnet broadcast in shared networks [RFC3819],
the reduction of routing and management overhead [RFC6606], the the reduction of routing and management overhead [RFC6606], the
adoption of lightweight application protocols (or novel data encoding adoption of lightweight application protocols (or novel data encoding
techniques), and the support for security mechanisms (confidentiality techniques), and the support for security mechanisms (confidentiality
and integrity protection, device bootstrapping, key establishment, and integrity protection, device bootstrapping, key establishment,
and management). 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.
skipping to change at page 5, line 48 skipping to change at page 5, line 48
lossy radio-links, the battery supplied nodes, the multi-hop mesh lossy radio-links, the battery supplied 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].
It is able to quickly build up network routes, to distribute routing RPL is able to quickly build up network routes, distribute routing
knowledge among nodes, and to adapt the topology. In a typical knowledge among nodes, and adapt to a changing topology. In a
setting, motes are connected through multi-hop paths to a small set typical setting, motes are connected through multi-hop paths to a
of root devices, which are usually responsible for data collection small set of root devices, which are usually responsible for data
and coordination duties. For each of them, a Destination Oriented collection and coordination. For each of them, a Destination
Directed Acyclic Graph (DODAG) is created by accounting for link Oriented Directed Acyclic Graph (DODAG) is created by accounting for
costs, node attributes/status information, and an Objective Function, link costs, node attributes/status information, and an Objective
which maps the optimization requirements of the target scenario. The Function, which maps the optimization requirements of the target
topology is set-up based on a Rank metric, which encodes the distance scenario. The topology is set up based on a Rank metric, which
of each node with respect to its reference root, as specified by the encodes the distance of each node with respect to its reference root,
Objective Function. Regardless of the way it is computed, the Rank as specified by the Objective Function. Regardless of the way it is
monotonically decreases along the DODAG towards the destination, computed, the Rank monotonically decreases along the DODAG towards
following a gradient-based approach. RPL encompasses different kinds the destination, building a gradient. RPL encompasses different
of traffic and signaling information. Multipoint-to-Point (MP2P) is kinds of traffic and signaling information. Multipoint-to-Point
the dominant traffic in LLN applications. Data is routed towards (MP2P) is the dominant traffic in LLN applications. Data is routed
nodes with some application relevance, such as the LLN gateway to the towards nodes with some application relevance, such as the LLN
larger Internet, or to the core of private IP networks. In general, gateway to the larger Internet, or to the core of private IP
these destinations are the DODAG roots and they act as data networks. In general, these destinations are the DODAG roots and act
collection points for distributed monitoring applications. Point-to- as data collection points for distributed monitoring applications.
Multipoint (P2MP) data streams are used for actuation purposes, where Point-to-Multipoint (P2MP) data streams are used for actuation
messages are sent from DODAG roots to destination nodes. Point-to- purposes, where messages are sent from DODAG roots to destination
Point (P2P) traffic allows communication between two devices nodes. Point-to-Point (P2P) traffic allows communication between two
belonging to the same LLN, e.g. a sensor and an actuator. A packet devices belonging to the same LLN, such as a sensor and an actuator.
will flow from the source towards the common ancestor of those two A packet flows from the source to the common ancestor of those two
communicating devices, then downward towards the destination. As an communicating devices, then downward towards the destination. RPL
consequence, RPL has to discover both upward routes (i.e., from nodes therefore has to discover both upward routes (i.e. from nodes to
to DODAG roots) in order to enable MP2P and P2P flows, and downward DODAG roots) in order to enable MP2P and P2P flows, and downward
routes (i.e., from DODAG roots to nodes) to support P2MP and P2P routes (i.e. from DODAG roots to nodes) to support P2MP and P2P
traffic. 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.
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 fully standards-based protocol stack, which aims implementation of a fully standards-based protocol stack, which aims
at evaluating the applicability of TSCH to different applications. at evaluating the applicability of TSCH to different applications.
This implementation was used as the foundation for an IP for Smart This implementation was used as the foundation for an IP for Smart
Objects Alliance (IPSO) [IPSO] iteroperability demo in 2011. In the Objects Alliance (IPSO) [IPSO] iteroperability 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 3. Problems and Goals
As highlighted in Appendix A, TSCH is different for traditional low- As highlighted in Appendix A, TSCH is different for traditional low-
power MAC protocols because of its scheduled nature. TSCH defines power MAC protocols because of its scheduled nature. TSCH defines
the mechanisms to execute a communication schedule, but it is the the mechanisms to execute a communication schedule, but it is the
entity that sets up that schedule which controls the topology of the entity that sets up that schedule which controls the topology of the
network, and the resources allocated to each link in that topology. network, and the resources 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 will refer to this entity by the
generic name "6TSCH", without loss of generality. In particular, we generic name "6TSCH", without loss of generality. In particular, we
do not assume the nature of 6TSCH, whether an adaptation layer, a do not assume the nature of 6TSCH, whether an adaptation layer, a
distributed reservation protocol, a centralized path computation distributed reservation protocol, a centralized path computation
engine, or any combination thereof. engine, or any combination thereof.
Some of the issues 6TSCH need to target might overlap with the scope
of other protocols (e.g., 6LoWPAN, RPL, and RSVP). In this case, it
is entailed that 6TSCH will profit from the services provided by
other protocols to pursue these objectives.
3.1. Network Formation 3.1. Network Formation
6TSCH needs to control the way the network is formed, including how 6TSCH 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. 6TSCH needs to: of the network. 6TSCH needs to:
1. Define the Information Elements to include in Enhanced Beacons 1. Define the Information Elements to include in the Enhanced
advertising the presence of the network. Beacons 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. This includes a mechanism to select the best Enhanced Beacons. This includes a mechanism to select the best
mote to join the network through. mote through which to join the network.
3. Define the joining procedure. This includes a mechanism to 3. Define the joining procedure. This includes 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
subsequent optional process of scheduling more communication
links.
3.2. Network Maintenance 3.2. Network Maintenance
Once a network is formed, 6TSCH needs to maintain the network's Once a network is formed, 6TSCH needs to maintain the network's
health, allowing for motes to stay synchronized. 6TSCH needs to: health, allowing for motes to stay synchronized. 6TSCH needs to:
1. Manage each mote's time source neighbor(s). 1. Manage each mote's time source neighbor(s).
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 an Enhanced Beacon 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 3.3. Multi-Hop Topology
RPL, given a weighted connectivity graph, determines multi-hop RPL, given a weighted connectivity graph, determines multi-hop
routes. 6TSCH needs to: routes. 6TSCH needs to:
1. Define a mechanism whereby it gathers topological information, 1. Define a mechanism to gather topological information, which it
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 links 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 links 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 mote needs to have at least one time source At all times, a TSCH mote needs to have at least one time source
skipping to change at page 8, line 33 skipping to change at page 8, line 41
source neighbors to allow for correct operation of the TSCH network. source neighbors to allow for correct operation of the TSCH network.
These time source neighbors could, or not, be related to RPL time These time source neighbors could, or not, be related to RPL time
parents. parents.
3.5. Resource Management 3.5. Resource Management
A link in a TSCH schedule is a "unit" of resource. The number of 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 links to assign between neighbor motes needs to be appropriate for
the size of the traffic flow. 6TSCH needs to: the size of the traffic flow. 6TSCH needs to:
1. Define rules on when to create or delete a slotframes. 1. Define rules on when to create or delete a slotframe.
2. Define rules to determine the length of a slotframe, and the 2. Define rules to determine the length of a slotframe, and the
trigger to modify the length of a slotframe. trigger to modify the length of a slotframe.
3. Define rules on when to add or delete links in a particular 3. Define rules on when to add or delete links in a particular
slotframe. slotframe.
4. Define a mechanism for neighbor nodes to exchange information 4. 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 links.
skipping to change at page 9, line 9 skipping to change at page 9, line 16
over the schedule. over the schedule.
6. Define a set of metrics to evaluate the tradeoff between latency, 6. Define a set of metrics to evaluate the tradeoff between latency,
bandwidth and energy consumption achieved by a particular bandwidth and energy consumption achieved by a particular
schedule. schedule.
3.6. Dataflow Control 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 not to accept. 6TSCH need to: determines when to stop accepting packets. 6TSCH need to:
1. Define a queueing policy for incoming and outgoing packets. 1. Define a queueing 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 packet. accepting incoming packets.
3. Handle transmissions that have failed. 3. Handle transmissions that have failed. A transmission is
declared failed when TSCH has retransmitted the packet multiple
times, without receiving an acknowledgment. This covers both
dedicated and shared links.
3.7. Secure Communication 3.7. Deterministic Behavior
As highlighted in [RFC5673], in some applications, data is generated
periodically and has a well understood data bandwidth requirement,
which is deterministic and predictable. 6TSCH need to:
1. Ensure timely delivery of such data.
2. Provide a mechanism for such deterministic flows to coexist with
bursty or infrequent traffic flows of different priorities.
3.8. Path Computation Engine
As highlighted in [I-D.phinney-roll-rpl-industrial-applicability],
bandwidth allocation and multi-hop routes can be optimized by an
external Path Computation Engine (PCE). 6TSCH need to:
1. Provide a mechanism for an external PCE to be able to control the
entire schedule of the network, including the slotframes, links
and time source neighbor assignment.
2. Define a optional mechanism for the schedule managed by this PCE
to coexist with scheduling elements (slotframes, links) managed
up by a different mechanism such as a distribute scheduling
algorithm.
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. 6TSCH need to: is generated. 6TSCH need 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.
skipping to change at page 13, line 38 skipping to change at page 14, line 38
Networks", draft-tsao-roll-security-framework-02 (work in Networks", draft-tsao-roll-security-framework-02 (work in
progress), March 2010. progress), March 2010.
[I-D.thubert-roll-asymlink] [I-D.thubert-roll-asymlink]
Thubert, P., "RPL adaptation for asymmetrical links", Thubert, P., "RPL adaptation for asymmetrical links",
draft-thubert-roll-asymlink-02 (work in progress), draft-thubert-roll-asymlink-02 (work in progress),
December 2011. December 2011.
[I-D.ietf-roll-terminology] [I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-10 (work in Networks", draft-ietf-roll-terminology-11 (work in
progress), January 2013. progress), February 2013.
[I-D.ietf-roll-p2p-rpl] [I-D.ietf-roll-p2p-rpl]
Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J.
Martocci, "Reactive Discovery of Point-to-Point Routes in Martocci, "Reactive Discovery of Point-to-Point Routes in
Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-16 Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-16
(work in progress), February 2013. (work in progress), February 2013.
[I-D.ietf-roll-trickle-mcast] [I-D.ietf-roll-trickle-mcast]
Hui, J. and R. Kelsey, "Multicast Protocol for Low power Hui, J. and R. Kelsey, "Multicast Protocol for Low power
and Lossy Networks (MPL)", and Lossy Networks (MPL)",
skipping to change at page 18, line 36 skipping to change at page 19, line 36
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
Timeslots are grouped into one of more slotframes. A slotframe Timeslots are grouped into one of more slotframes. A slotframe
continuously repeats over time. TSCH does not impose any 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. Mote Communication Schedule A.3. Mote Communication Schedule
A communication schedule instructs each mote what to do in each slot: A communication schedule instructs each mote what to do in each slot:
transmit, receive or sleep. The schedule indicates, for each active transmit, receive or sleep. The schedule indicates, for each active
(transmit or receive) timeslot a channelOffset and the address of the (transmit or receive) timeslot a channelOffset and the address of the
neighbor to communicate with. 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 slot, the mote checks whether there is a packet o For each transmit slot, 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 slot. If there is none, the mote schedule information for that slot. If there is none, the mote
keeps its radio off for the duration of the slot. If there is keeps its radio off for the duration of the slot. If there is
one, the mote can ask for the neighbor to acknowledge it, in which one, the mote can ask for the neighbor to acknowledge it, in which
case it has to listen for the acknowledgment after the case it has to listen for the acknowledgment after transmitting.
transmission.
o For each receive slot, the mote listens for possible incoming o For each receive slot, 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 typically sends back mote, and passes security checks, the mote can send back an
and aknowledgment. aknowledgment.
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. Links and Paths A.4. Links and Paths
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 slot of the schedule (i.e., a single cell of the grid), A single slot of the schedule (i.e., a single cell of the grid),
characterized by a slotOffset and channelOffset, and reserved for characterized by a slotOffset and channelOffset, and reserved for
mote A to transmit to mote B (or for mote B to receive from mote A), mote A to transmit to mote B (or for mote B to receive from mote A),
is called a "link". is called a "link".
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 slots from A to B, at different times. might contain multiple slots from A to B, at different times.
Multiple links scheduled to the same neighbor are typically Multiple links scheduled to the same neighbor are typically
equivalent, i.e. the MAC layer sends the packet on whichever of these equivalent, i.e. the MAC layer sends the packet on whichever of these
links happens to show up after the packet was put in the MAC queue. links happens to show up first after the packet was put in the MAC
The union of all links between two neighbors, A and B, is called a queue. The union of all links between two neighbors, A and B, is
"path". Since the slotframe repeats over time (and the length of the called a "path". Since the slotframe repeats over time (and the
slotframe is typically constant), each link gives a "quantum" of length of the slotframe is typically constant), each link gives a
bandwidth to a given neighbor. Modifying the number of links in a "quantum" of bandwidth to a given neighbor. Modifying the number of
path modify the amount of resources allocated between two neighbors. links in a path modifies the amount of resources allocated between
two neighbors.
A.5. Dedicated vs. Shared Slots A.5. Dedicated vs. Shared Slots
By default, each transmit timeslot within the TSCH schedule is By default, each transmit timeslot 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 slot as shared. In a shared IEEE802.15.4e allows also to mark a slot as shared. In a shared
slot, multiple motes can transmit at the same time, on the same slot, multiple motes can transmit at the same time, on the same
fequency. To avoid contention, TSCH defines a back-off algorithm for fequency. To avoid contention, TSCH defines a back-off algorithm for
shared slots. shared slots.
A slot can be marked as both transmitting and receiving. In this A slot can be marked as both transmitting and receiving. In this
case, a mote transmits if it has an appropriate packet in its output case, a mote transmits if it has an appropriate packet in its output
buffer, or listens otherwise. Marking a slot as buffer, or listens otherwise. Marking a slot as
[transmit,shared,receive] results in slotted-Aloha behavior. [transmit,shared,receive] 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 S is the slotframe size and k the slotframe cycle (i.e., the where k is the slotframe cycle (i.e., the number of slotframe
number of slotframe occurences over time). A mote learns the current occurences over time), S the slotframe size and t the slotOffset. A
ASN when it joins the network. Since motes are synchronized, they mote learns the current ASN when it joins the network. Since motes
all know the current value of the ASN, and any time. The ASN is are synchronized, they all know the current value of the ASN, and any
encoded as a 5-byte number: this allows it to increment for hundreds time. The ASN is encoded as a 5-byte number: this allows it to
of years (the exact value depends on the duration of a timeslot) increment for hundreds of years (the exact value depends on the
without wrapping. The ASN is used (i) to calculate the frequency to duration of a timeslot) without wrapping. The ASN is used (i) to
communicate on, jointly with the channelOffset, (ii) to build unique calculate the frequency to communicate on, jointly with the
security nonce counters, when the CCM* mode is activated. channelOffset, (ii) to build unique security nonce counters used by
CCM*.
A.7. Channel Hopping A.7. Channel Hopping
For each active slot, the schedule specifies a timeOffset and a For each active slot, 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
slot to mote B on channelOffset 5, mote B has a receive slot from slot to mote B on channelOffset 5, mote B has a receive slot from
mote A on the same channelOffset. The channelOffset, is translated mote A on the same channelOffset. The channelOffset is translated by
by both nodes into a frequency using the following function: both nodes into a frequency using the following function:
frequency = F {(ASN + channelOffset) mod nCh} 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 look-up table containing the set of
available channels. The value nCh (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 look-up 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 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 timeslot, and the same ASN counter since they are schedule for that timeslot, and the same ASN counter since they are
synchronized, they compute the same frequency. At the next iteration synchronized, they compute the same frequency. At the next iteration
(cycle) of the slotframe, however, the channelOffset will be the (cycle) of the slotframe, however, the channelOffset will be the
same, but the ASN will have changed, resulting in the computation of same, but the ASN will have changed, resulting in the computation of
a different frequency. If the slotframe size, S (used for computing a different frequency. If the slotframe size, S (used for computing
ASN), and the number of channel offsets, nCh, are relatively prime, ASN), and the number of channel offsets, nFreq, are relatively prime,
the translation function ensures that each link rotates through k the translation function ensures that each link rotates through k
available channels over k slotframe cycles. This results in "channel available channels over k slotframe cycles. This results in "channel
hopping": even with a static schedule, pairs of neighbors "hop" hopping": even with a static schedule, pairs of neighbors "hop"
between the different frequencies when communicating. between the different frequencies when communicating.
The look-up table F can be built to contain only a subset of all The look-up table F can be built to contain only a subset of all
available channels. This results in "blacklisting". available channels. This results in frequency "blacklisting".
Channel hopping is a technique known to efficiently combat multi-path Channel hopping is a technique known to efficiently combat multi-path
fading and external interference. This results in a TSCH network fading and external interference. This results in a TSCH network
having a more stable topology than if only a single channel were used having a more stable topology than if only a single channel were used
for the entire network. for the entire network.
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 (32kHz crystal to be equipped with clocks to keep track of time (32kHz crystal
oscillators are typically used). Yet, because clocks in different oscillators are typically used). Yet, because clocks in different
motes drift with respect to one another, neighbor motes need to motes drift with respect to one another, neighbor motes need to
periodically re-synchronize. periodically re-synchronize.
In detail, each mote periodically synchronizes its network clock to
at least one other mote, and it also provides its network time to its
neighbors. It is up to the entity that manages the schedule to
assign adequate time source neighbor(s) to each mote, i.e., to
indicate in the schedule which of its neighbor(s) are its "time
source neighbors". While setting the time source neighbor, it is
important to avoid synchronization loops, which could result in the
formation of independent clusters of motes.
Typically, in a IEEE802.15.4e TSCH network, time propagates outwards
from the PAN coordinator (i.e., the root node). But the direction of
time propagation is independent of data flow in the network. A new
mote joining a TSCH network, because it does not have a schedule yet,
maintains time synchronization, using the information carried by the
Enhanced Beacons (EBs), sent by the advertising 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. The resynchronize to one another whenever they exchange data. In detail,
schedule of a mote indicates which of its neighbor(s) are its "time in the IEEE 802.15.4e standard two methods are defined for allowing a
source neighbors". When a mote communicates with one of its time device to synchronize in a TSCH network: (I) Acknowledgment-Based and
source neighbors, it uses the timing information in the exchanged (II) Frame-Based synchronization. In both cases, the receiver
frames to realign its clock to its neighbor's. calculates the difference in time between the expected time of frame
arrival and its actual arrival. In Acknowledgment-Based
synchronization, the receiver provides such information to the sender
mote in its acknowledgment. Thus, in this case, it is the sender
mote that synchronizes to the clock of the receiver. In Frame-Based
synchronization, the receiver uses the computed delta for adjusting
its own clock. Therefore, it is the receiver mote that synchronizes
to the clock of the sender.
It is up to the entity that manages the schedule to assign adequate Different synchronization policies are possible. Motes can keep
time source neighbor(s) to each mote. It is important to avoid synchronization exclusively by exchanging EBs. Motes can also keep
synchronization loops, which could result in the formation of synchronized by periodically sending valid frames to time source
independent clusters of motes. neighbors to use the acknowledgement to resynchronize. Both method
(or a combination thereof) are valid synchronization policies; which
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. Depending on the the hardware timeslot: transmit, receive, or sleep. Each of these operations has
used, each of these operations has some energy cost associated to some energy cost associated to them, the exact value depending on the
them. Given the schedule of a mote, it is straighforward to the hardware used. Given the schedule of a mote, it is
calculate the expected average power consumption of that mote. straighforward to calculate the expected average power consumption of
that mote.
A.10. Network Communication Schedule A.10. Network Communication Schedule
The schedule defines entirely the synchronization and communication The schedule defines entirely the synchronization and communication
between motes. By adding/removing link between neighbors, one can between motes. By adding/removing links 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 as possible, at the price of reduced bandwidth. consume as little energy as possible, at the price of reduced
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 links along a multi-hop route over which many packets o Add more links 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
skipping to change at page 22, line 24 skipping to change at page 24, line 4
Beacon (EB) frames to announce the presence the network. These Beacon (EB) frames to announce the presence 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. This join priority corresponds to the number of hops priority. This join priority corresponds to the number of hops
separating the mote sending the EB, and the PAN coordinator. Because separating the mote sending the EB, and the PAN coordinator. Because
of the channel hopping nature of TSCH, these EB frames are sent on of the channel hopping nature of TSCH, these EB frames are sent on
all frequencies. all frequencies.
A mote wishing to join the network listens on some frequency for EBs. A mote wishing to join the network listens on some frequency for EBs.
It can wait to receive multiple, and can use the join priority in It can wait to receive multiple, and can use the join priority in
those EBs to identify the best mote to join the network through. those EBs to identify the best mote through which to join the
Using the ASN and the other timing information of the EB, the new network. Using the ASN and the other timing information of the EB,
mote synchronizes to the network. Using the slotframe and link the new mote synchronizes to the network. Using the slotframe and
information from te EB, it knows how to contact the mote it just link information from the EB, it knows how to contact the mote it
joined. just joined.
The TSCH standard does not define the steps beyond this "kickstart". The TSCH standard does not define the steps beyond this "kickstart".
These steps can include a security handshake and the addition of more These steps can include a security handshake and the addition of more
communication links to the new mote's schedule. communication links to the new mote's schedule.
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), but an for TSCH (e.g., the ASN in the EB is contained in an IE), and an
unmanaged range is available for extensions. unmanaged range is available for extensions.
A bit in the MAC header indicates whether the frame contains IEs. A data bit in the MAC header indicates whether the frame contains
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 motes to exchange information. the next higher layers of two neighbor motes 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. links, frame, etc.), but leaves mechanisms as "building block" (e.g. links, slotframes, etc.), but
entire freedom to the upper layer to assemble those. The MAC leaves entire freedom to the upper layer to assemble those. The MAC
protocol can be extended by defining new Header IEs. An intermediate protocol can be extended by defining new Header IEs. An intermediate
layer can be defined to manage the MAC layer by defining Payload IEs. layer can be defined to manage the MAC layer by defining new Payload
IEs.
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 6TSCH. and beneficial to the work of 6TSCH.
B.1. Collision Free Communication B.1. Collision Free Communication
TSCH allows you to easily design a schedule which yields collision- TSCH allows one to easily design a schedule which yields collision-
free communication. This is done by building the schedule in such a free communication. This is done by building the schedule with
way that at most one link occupies each slotOffset/channelOffset dedicated links in such a way that at most one link occupies each
cell. Multiple pairs of neighbor motes can exchange data at the same slotOffset/channelOffset cell. Multiple pairs of neighbor motes can
time, but on different frequencies. If a deployment is done over a exchange data at the same time, but on different frequencies. If a
large area, slotOffset/channelOffset cells can be reused by pairs of deployment is done over a large area, slotOffset/channelOffset cells
neigbors sufficiently far appart not to interfere. can be reused by pairs of neigbors sufficiently far appart not to
interfere.
B.2. Multi-Channel vs. Channel Hopping B.2. Multi-Channel vs. Channel Hopping
A TSCH schedule looks like a matrix of width "slotFrame length" and A TSCH schedule looks like a matrix of width "slotframe size", S, and
height "number of channels". For a scheduling algorithm, these can of height "number of frequencies", nFreq. For a scheduling
be considered atomic "units" to schedule. In particular, because of algorithm, these can be considered atomic "units" to schedule. In
the channel hopping nature of TSCH, the scheduling algorithm should particular, because of the channel hopping nature of TSCH, the
not worry about the actual frequency communication happens on, since scheduling algorithm should not worry about the actual frequency
it changes at each slotFrame iteration. communication happens on, since it changes at each slotframe
iteration.
B.3. Cost of (continuous) Synchronization B.3. Cost of (continuous) Synchronization
In the absence of data traffic, a mote is required to synchronize to When there is traffic in the network, motes which are communicating
its time source neighbor(s) periodically not to drift in time. The implicitly re-synchronize using the data frames they exchange. In
period at which this needs to happen depends on the stability of the the absence of data traffic, motes are required to synchronize to
clock source, and on how "early" each mote starts listening for data their time source neighbor(s) periodically not to drift in time. If
(the "guard time"). Theoretically, with a 10ppm clock and a 1ms they have not been communicating for some time (typically 30s), motes
guard time, this period can be 100s. Resynchronizing consists in can exchange an empty data frame, often referred to as a "Keep-alive"
sending any valid frame to the time source neighbor and using the message, to re-synchronize. The frequency at which such message need
timing information in the ACK to realign the clocks. If this to be transmitted depends on the stability of the clock source, and
exchange causes the mote's radio to be on for 5ms, this yields a on how "early" each mote starts listening for data (the "guard
radio duty cycle needed to keep synchronized of 5ms/100s=0.005%. time"). Theoretically, with a 10ppm clock and a 1ms guard time, this
While TSCH does requires motes to resynchronize periodically, the period can be 100s. When acknowledgment-based synchronization is
cost of doing so in almost negligible. used, re-synchronizing consists in sending any valid frame to the
time source neighbor and using the timing information in the ACK to
realign the clocks. Assuming this exchange causes the mote's radio
to be on for 5ms, this yields a radio duty cycle needed to keep
synchronized of 5ms/100s=0.005%. While TSCH does requires motes to
resynchronize periodically, the cost of doing so can be considered
almost negligible in many applications.
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 motes differently on interference impact a wireless link between two motes differently on
each frequency. It 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 slot, a mote has mote's schedule. It is possible that at some slot, a mote has
multiple activities scheduled (e.g. transmit to mote 0xfeed on multiple activities scheduled (e.g. transmit to mote B on slotFrame
slotFrame 2, receive from mote 0xbeef on slotFrame 1). To handle 2, receive from mote C on slotFrame 1). To handle this situation,
this situation, the TSCH standard defines the following precedence the TSCH standard defines the following precedence rules:
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 0xfeed on In the example above, the mote would transmit to mote B on slotFrame
slotFrame 2. 2.
Author's Address Author's Address
Thomas Watteyne (editor) Thomas Watteyne (editor)
Linear Technology Linear Technology
30695 Huntwood Avenue 30695 Huntwood Avenue
Hayward, CA 94544 Hayward, CA 94544
USA USA
Phone: +1 (510) 400-2978 Phone: +1 (510) 400-2978
 End of changes. 58 change blocks. 
183 lines changed or deleted 263 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/