--- 1/draft-ietf-6tisch-tsch-02.txt 2014-10-27 16:15:00.433285771 -0700 +++ 2/draft-ietf-6tisch-tsch-03.txt 2014-10-27 16:15:00.485287004 -0700 @@ -1,22 +1,22 @@ 6TiSCH T. Watteyne, Ed. Internet-Draft Linear Technology Intended status: Informational MR. Palattella -Expires: April 20, 2015 University of Luxembourg +Expires: April 30, 2015 University of Luxembourg LA. Grieco Politecnico di Bari - October 17, 2014 + October 27, 2014 Using IEEE802.15.4e TSCH in an IoT context: Overview, Problem Statement and Goals - draft-ietf-6tisch-tsch-02 + draft-ietf-6tisch-tsch-03 Abstract This document describes the environment, problem statement, and goals 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 only. Status of This Memo @@ -26,21 +26,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 20, 2015. + This Internet-Draft will expire on April 30, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -49,57 +49,57 @@ include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. TSCH in the LLN Context . . . . . . . . . . . . . . . . . . . 4 4. Problems and Goals . . . . . . . . . . . . . . . . . . . . . 6 - 4.1. Network Formation . . . . . . . . . . . . . . . . . . . . 6 + 4.1. Network Formation . . . . . . . . . . . . . . . . . . . . 7 4.2. Network Maintenance . . . . . . . . . . . . . . . . . . . 7 4.3. Multi-Hop Topology . . . . . . . . . . . . . . . . . . . 7 - 4.4. Routing and Timing Parents . . . . . . . . . . . . . . . 7 + 4.4. Routing and Timing Parents . . . . . . . . . . . . . . . 8 4.5. Resource Management . . . . . . . . . . . . . . . . . . . 8 4.6. Dataflow Control . . . . . . . . . . . . . . . . . . . . 8 4.7. Deterministic Behavior . . . . . . . . . . . . . . . . . 8 - 4.8. Scheduling Mechanisms . . . . . . . . . . . . . . . . . . 8 + 4.8. Scheduling Mechanisms . . . . . . . . . . . . . . . . . . 9 4.9. Secure Communication . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 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 - A.1. Timeslots . . . . . . . . . . . . . . . . . . . . . . . . 15 + Appendix A. TSCH Protocol Highlights . . . . . . . . . . . . . . 16 + A.1. Timeslots . . . . . . . . . . . . . . . . . . . . . . . . 16 A.2. Slotframes . . . . . . . . . . . . . . . . . . . . . . . 16 A.3. Node TSCH Schedule . . . . . . . . . . . . . . . . . . . 16 - A.4. Cells and Bundles . . . . . . . . . . . . . . . . . . . . 16 + A.4. Cells and Bundles . . . . . . . . . . . . . . . . . . . . 17 A.5. Dedicated vs. Shared Cells . . . . . . . . . . . . . . . 17 - A.6. Absolute Slot Number . . . . . . . . . . . . . . . . . . 17 + A.6. Absolute Slot Number . . . . . . . . . . . . . . . . . . 18 A.7. Channel Hopping . . . . . . . . . . . . . . . . . . . . . 18 - A.8. Time Synchronization . . . . . . . . . . . . . . . . . . 18 + A.8. Time Synchronization . . . . . . . . . . . . . . . . . . 19 A.9. Power Consumption . . . . . . . . . . . . . . . . . . . . 19 - A.10. Network TSCH Schedule . . . . . . . . . . . . . . . . . . 19 + A.10. Network TSCH Schedule . . . . . . . . . . . . . . . . . . 20 A.11. Join Process . . . . . . . . . . . . . . . . . . . . . . 20 - A.12. Information Elements . . . . . . . . . . . . . . . . . . 20 - A.13. Extensibility . . . . . . . . . . . . . . . . . . . . . . 20 + A.12. Information Elements . . . . . . . . . . . . . . . . . . 21 + A.13. Extensibility . . . . . . . . . . . . . . . . . . . . . . 21 Appendix B. TSCH Gotchas . . . . . . . . . . . . . . . . . . . . 21 B.1. Collision Free Communication . . . . . . . . . . . . . . 21 B.2. Multi-Channel vs. Channel Hopping . . . . . . . . . . . . 21 - B.3. Cost of (continuous) Synchronization . . . . . . . . . . 21 - B.4. Topology Stability . . . . . . . . . . . . . . . . . . . 21 + B.3. Cost of (continuous) Synchronization . . . . . . . . . . 22 + B.4. Topology Stability . . . . . . . . . . . . . . . . . . . 22 B.5. Multiple Concurrent Slotframes . . . . . . . . . . . . . 22 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction IEEE802.15.4e [IEEE802154e] was published in 2012 as an amendment to the Medium Access Control (MAC) protocol defined by the IEEE802.15.4-2011 [IEEE802154] standard. IEEE802.15.4e will be 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. @@ -121,27 +121,35 @@ IEEE802.15.4e is the latest generation of ultra-lower power and reliable networking solutions for LLNs. [RFC5673] discusses industrial applications, and highlights the harsh operating conditions as well as the stringent reliability, availability, and security requirements for an LLN to operate in an industrial 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 nodes consume 10's of micro-amps on average [CurrentCalculator] with end-to-end packet delivery ratios over 99.999% [doherty07channel]. + IEEE802.15.4e has been designed for low-power constrained devices, + often called "motes". Several terms are used in the IETF to refer to + those devices, including "LLN nodes" [RFC7102] and "constrained + nodes" [RFC7228]. In this document, we use the generic (and shorter) + term "node", used as a synonym for "LLN node", "constrained node" or + "mote". + 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 layering allows for TSCH to fit under an IPv6 enabled protocol stack for LLNs, running 6LoWPAN [RFC6282], IPv6 Routing Protocol for Low @@ -144,21 +152,21 @@ IEEE802.15.4e TSCH focuses on the MAC layer only. This clean layering allows for TSCH to fit under an IPv6 enabled protocol stack for LLNs, running 6LoWPAN [RFC6282], IPv6 Routing Protocol for Low power and Lossy Networks (RPL) [RFC6550] and the Constrained Application Protocol (CoAP) [RFC7252]. What is missing is a Logical Link Control (LLC) layer between the IP abstraction of a link and the TSCH MAC, which is in charge of scheduling a timeslot for a given packet coming down the stack from the upper layer. - While [IEEE802154e] defines the mechanisms for a TSCH mote to + While [IEEE802154e] defines the mechanisms for a TSCH node to communicate, it does not define the policies to build and maintain the communication schedule, match that schedule to the multi-hop paths maintained by RPL, adapt the resources allocated between neighbor nodes to the data traffic flows, enforce a differentiated treatment for data generated at the application layer and signaling messages needed by 6LoWPAN and RPL to discover neighbors, react to topology changes, self-configure IP addresses, or manage keying material. In other words, IEEE802.15.4e TSCH is designed to allow optimizations @@ -210,21 +218,21 @@ Successful solutions take into account the specific application requirements, along with IPv6 behavior and 6LoWPAN mechanisms [palattella12standardized]. The ROLL working group has defined RPL in [RFC6550]. RPL can support a wide variety of link layers, including ones that are constrained, potentially lossy, or typically utilized in conjunction with host or router devices with very limited resources, as in building/home automation [RFC5867][RFC5826], industrial environments [RFC5673], and urban applications [RFC5548]. RPL is able to quickly build up network routes, distribute routing knowledge among nodes, and adapt to a changing topology. In a - typical setting, motes are connected through multi-hop paths to a + typical setting, nodes are connected through multi-hop paths to a small set of root devices, which are usually responsible for data collection and coordination. For each of them, a Destination Oriented Directed Acyclic Graph (DODAG) is created by accounting for link costs, node attributes/status information, and an Objective Function, which maps the optimization requirements of the target scenario. 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 @@ -275,45 +283,45 @@ generic "LLC". 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 case, it is entailed that the LLC will profit from the services provided by other protocols to pursue these objectives. 4.1. Network Formation 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 nodes join, and how already joined nodes advertise the presence of the network. The LLC needs to: 1. Define the Information Elements included in the Enhanced Beacons advertising the presence of the network. - 2. For a new mote, define rules to process and filter received + 2. For a new node, define rules to process and filter received Enhanced Beacons. 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 node, and the management of initial keying material. 4. Define a mechanism to secure the joining process and the subsequent optional process of scheduling more communication cells. 4.2. Network Maintenance Once a network is formed, the LLC needs to maintain the network's - health, allowing for motes to stay synchronized. The LLC needs to: + health, allowing for nodes to stay synchronized. The LLC needs to: - 1. Manage each mote's time source neighbor. + 1. Manage each node's time source neighbor. - 2. Define a mechanism for a mote to update the join priority it + 2. Define a mechanism for a node to update the join priority it announces in its Enhanced Beacon. 3. Schedule transmissions of Enhanced Beacons to advertise the presence of the network. 4.3. Multi-Hop Topology RPL, given a weighted connectivity graph, determines multi-hop routes. The LLC needs to: @@ -321,42 +329,42 @@ can then feed to RPL. 2. Ensure that the TSCH schedule contains cells along the multi-hop routes identified by RPL. 3. Where applicable, maintain independent sets of cells to transport independent flows of data. 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 node needs to have a time source neighbor it can synchronize to. The LLC therefore needs to assign a time source neighbor to allow for correct operation of the TSCH network. A time source neighbors could, or not, be taken from the RPL routing parent set. 4.5. Resource Management A cell in a TSCH schedule is an atomic "unit" of resource. The - number of cells to assign between neighbor motes needs to be + number of cells to assign between neighbor nodes needs to be appropriate for the size of the traffic flow. The LLC needs to: 1. Define a mechanism for neighbor nodes to exchange information about their schedule and, if applicable, negotiate the addition/ deletion of cells. 2. Allow for an entity (e.g., a set of devices, a distributed protocol, a PCE, etc.) to take control of the schedule. 4.6. Dataflow Control - TSCH defines mechanisms for a mote to signal it cannot accept an + TSCH defines mechanisms for a node to signal it cannot accept an incoming packet. It does not, however, define the policy which determines when to stop accepting packets. The LLC needs to: 1. Define a queuing policy for incoming and outgoing packets. 2. Manage the buffer space, and indicate to TSCH when to stop accepting incoming packets. 3. Handle transmissions that have failed. A transmission is declared failed when TSCH has retransmitted the packet multiple @@ -395,27 +403,27 @@ 3. Define an mechanism for these different scheduling mechanisms to coexist in the same network. 4.9. Secure Communication Given some keying material, TSCH defines mechanisms to encrypt and authenticate MAC frames. It does not define how this keying material is generated. The LLC needs to: 1. Define the keying material and authentication mechanism needed by - a new mote to join an existing network. + a new node to join an existing network. 2. Define a mechanism to allow for the secure transfer of - application data between neighbor motes. + application data between neighbor nodes. 3. Define a mechanism to allow for the secure transfer of signaling - data between motes and the LLC. + data between nodes and the LLC. 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. @@ -434,20 +442,26 @@ 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014. + [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for + Constrained-Node Networks", RFC 7228, May 2014. + + [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and + Lossy Networks", RFC 7102, January 2014. + [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing", RFC 6606, May 2012. [RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6568, April 2012. [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., @@ -490,40 +504,40 @@ [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [I-D.ietf-6tisch-tsch] Watteyne, T., Palattella, M., and L. Grieco, "Using - IEEE802.15.4e TSCH in an LLN context: Overview, Problem - Statement and Goals", draft-ietf-6tisch-tsch-01 (work in - progress), July 2014. + IEEE802.15.4e TSCH in an IoT context: Overview, Problem + Statement and Goals", draft-ietf-6tisch-tsch-02 (work in + progress), October 2014. [I-D.ietf-6tisch-architecture] Thubert, P., Watteyne, T., and R. Assimiti, "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4e", draft-ietf-6tisch-architecture-03 (work in progress), July 2014. [I-D.ietf-6tisch-terminology] Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, "Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e", draft-ietf-6tisch-terminology-02 (work in progress), July 2014. [I-D.ietf-6tisch-minimal] Vilajosana, X. and K. Pister, "Minimal 6TiSCH - Configuration", draft-ietf-6tisch-minimal-02 (work in - progress), July 2014. + Configuration", draft-ietf-6tisch-minimal-03 (work in + progress), October 2014. [I-D.ietf-6tisch-6top-interface] Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH Operation Sublayer (6top) Interface", draft-ietf-6tisch- 6top-interface-01 (work in progress), July 2014. [I-D.wang-6tisch-6top-sublayer] Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH Operation Sublayer (6top)", draft-wang-6tisch-6top- sublayer-01 (work in progress), July 2014. @@ -696,254 +710,255 @@ o Concepts which are sufficiently different from traditional IEEE802.15.4 networking that they may need to be defined and presented precisely. o Techniques and ideas which are part of IEEE802.15.4e and which might be useful for the work of the 6TiSCH WG. A.1. Timeslots - All motes in a TSCH network are synchronized. Time is sliced up into + All nodes in a TSCH network are synchronized. Time is sliced up into timeslots. A timeslot is long enough for a MAC frame of maximum size - to be sent from mote A to mote B, and for mote B to reply with an + to be sent from node A to node B, and for node B to reply with an acknowledgment (ACK) frame indicating successful reception. The duration of a timeslot is not defined by the standard. With 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 shorter ACK takes about 1ms. With a 10ms slot (a typical duration), this leaves 5ms to radio turnaround, packet processing and security operations. A.2. Slotframes Timeslots are grouped into one of more slotframes. A slotframe continuously repeats over time. TSCH does not impose a slotframe size. Depending on the application needs, these can range from 10s to 1000s of timeslots. The shorter the slotframe, the more often a timeslot repeats, resulting in more available bandwidth, but also in a higher power consumption. A.3. Node TSCH Schedule - A TSCH schedule instructs each mote what to do in each timeslot: + A TSCH schedule instructs each node what to do in each timeslot: transmit, receive or sleep. The schedule indicates, for each scheduled (transmit or receive) cell, a channelOffset and the address of the neighbor to communicate with. - Once a mote obtains its schedule, it executes it: + Once a node 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 node checks whether there is a packet in the outgoing buffer which matches the neighbor written in the schedule information for that timeslot. If there is none, the - 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, + node keeps its radio off for the duration of the timeslot. If + there is one, the node can ask for the neighbor to acknowledge it, in which case it has to listen for the acknowledgment after transmitting. - o For each receive cell, the mote listens for possible incoming + o For each receive cell, the node listens for possible incoming packets. If none is received after some listening period, it shuts down its radio. If a packet is received, addressed to the - mote, and passes security checks, the mote can send back an + node, and passes security checks, the node can send back an acknowledgment. How the schedule is built, updated and maintained, and by which entity, is outside of the scope of the IEEE802.15.4e standard. A.4. Cells and Bundles - 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 - be scheduled to receive from mote A at the same slotOffset and + Assuming the schedule is well built, if node A is scheduled to + transmit to node B at slotOffset 5 and channelOffset 11, node B will + be scheduled to receive from node A at the same slotOffset and channelOffset. A single element of the schedule 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) within a given slotframe, is called a + channelOffset, and reserved for node A to transmit to node B (or for + node B to receive from node A) within a given slotframe, is called a "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 node A to node B, the schedule might contain multiple cells from A to B, at different times. Multiple cells scheduled to the same neighbor can be equivalent, i.e. the MAC layer sends the packet on whichever of these cells shows up first after the packet was put in the MAC queue. The union of all cells between two neighbors, A and B, is called a "bundle". Since the slotframe repeats over time (and the length of the slotframe is typically constant), each cell gives a "quantum" of bandwidth to a given neighbor. Modifying the number of equivalent cells in a bundle modifies the amount of resources allocated between two neighbors. A.5. Dedicated vs. Shared Cells 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 node A to transmit to node B. 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 nodes can transmit at the same time, on the same frequency. To avoid contention, TSCH defines a back-off algorithm for shared cells. 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 node transmits if it has an appropriate packet in its output buffer, or listens otherwise. Marking a cell as [transmit,receive,shared] results in slotted-Aloha behavior. A.6. Absolute Slot Number TSCH defines a timeslot counter called Absolute Slot Number (ASN). When a new network is created, the ASN is initialized to 0; from then on, it increments by 1 at each timeslot. In detail: ASN = (k*S+t) where k is the slotframe cycle (i.e., the number of slotframe repetitions since the network was started), S the slotframe size and - t the slotOffset. A mote learns the current ASN when it joins the - network. Since motes are synchronized, they all know the current + t the slotOffset. A node learns the current ASN when it joins the + network. Since nodes are synchronized, they all know the current value of the ASN, at any time. The ASN is encoded as a 5-byte number: this allows it to increment for hundreds of years (the exact value depends on the duration of a timeslot) without wrapping over. The ASN is used to calculate the frequency to communicate on, and can be used for security-related operations. A.7. Channel Hopping For each scheduled cell, the schedule specifies a slotOffset and a - 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 - mote A on the same channelOffset. The channelOffset is translated by + channelOffset. In a well-built schedule, when node A has a transmit + cell to node B on channelOffset 5, node B has a receive cell from + node A on the same channelOffset. The channelOffset is translated by both nodes into a frequency using the following function: frequency = F {(ASN + channelOffset) mod nFreq} The function F consists of a look-up table containing the set of available channels. The value nFreq (the number of available frequencies) is the size of this look-up table. There are as many channelOffset values as there are frequencies available (e.g. 16 when 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 nodes have the same channelOffset written in their schedule for that scheduled cell, and the same ASN counter, they compute the same frequency. At the next iteration (cycle) of the slotframe, however, while the channelOffset is the same, the ASN has changed, resulting in the computation of a different frequency. This results in "channel hopping": even with a static schedule, pairs of neighbors "hop" between the different frequencies when communicating. A way of ensuring communication happens on all 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 Because of the slotted nature of communication in a TSCH network, - motes have to maintain tight synchronization. All motes are assumed + nodes have to maintain tight synchronization. All nodes are assumed to be equipped with clocks to keep track of time. Yet, because - clocks in different motes drift with respect to one another, neighbor - motes need to periodically re-synchronize. + clocks in different nodes drift with respect to one another, neighbor + nodes need to periodically re-synchronize. - Each mote needs to periodically synchronize its network clock to - another mote, and it also provides its network time to its neighbors. + Each node needs to periodically synchronize its network clock to + another node, and it also provides its network time to its neighbors. It is up to the entity that manages the schedule to assign an - adequate time source neighbor to each mote, i.e., to indicate in the + adequate time source neighbor to each node, i.e., to indicate in the schedule which of neighbor is its "time source neighbor". While setting the time source neighbor, it is important to avoid synchronization loops, which could result in the formation of - independent clusters of synchronized motes. + independent clusters of synchronized nodes. 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 nodes can resynchronize to one another whenever they exchange data. In detail, two methods are defined in IEEE802.15.4e-2012 for allowing a device to synchronize in a TSCH network: (i) Acknowledgment-Based and (ii) Frame-Based synchronization. In both cases, the receiver 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. In this case, it is the sender mote that + receiver provides such information to the sender node in its + acknowledgment. In this case, it is the sender node that synchronizes to the clock of the receiver. In Frame-Based synchronization, the receiver uses the computed delta for adjusting - its own clock. In this case, it is the receiver mote that + its own clock. In this case, it is the receiver node that synchronizes to the clock of the sender. - Different synchronization policies are possible. Motes can keep - synchronization exclusively by exchanging EBs. Motes can also keep + Different synchronization policies are possible. Nodes can keep + synchronization exclusively by exchanging EBs. Nodes can also keep synchronized by periodically sending valid frames to a time source neighbor and use the acknowledgment to resynchronize. Both method (or a combination thereof) are valid synchronization policies; which one to use depends on network requirements. 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 node can perform during a timeslot: transmit, receive, or sleep. Each of these operations has 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 node, it is straightforward to calculate the expected average power consumption - of that mote. + of that node. A.10. Network TSCH Schedule The schedule entirely defines the synchronization and communication - between motes. By adding/removing cells between neighbors, one can + between nodes. By adding/removing cells between neighbors, one can adapt a schedule to the needs of the application. Intuitive examples are: - o Make the schedule "sparse" for applications where motes need to + o Make the schedule "sparse" for applications where nodes need to 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 nodes generate a lot of data, at the price of increased power consumption. o Add more cells along a multi-hop route over which many packets flow. A.11. Join Process - Motes already part of the network can periodically send Enhanced + Nodes already part of the network can periodically send Enhanced Beacon (EB) frames to announce the presence of the network. These contain information about the size of the timeslot used in the network, the current ASN, information about the slotframes and - timeslots the beaconing mote is listening on, and a 1-byte join - 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. + timeslots the beaconing node is listening on, and a 1-byte join + priority. The join priority field gives information to make a better + decision of which node to join. 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. - A mote wishing to join the network listens for EBs. Since EBs are + A node wishing to join the network listens for EBs. Since EBs are sent on all frequencies, the joining node can listen on any frequency - until it hears an EB. What frequency it listens on, and whether it - 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. + until it hears an EB. What frequency it listens on is + implementation-specific. Once it has received one or more EBs, the + new node enables the TSCH mode and uses the ASN and the other timing + information from the EB to synchronize 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 network "bootstrap". A.12. Information Elements TSCH introduces the concept of Information Elements (IEs). An 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 for TSCH (e.g., the ASN in the EB is contained in an IE), and an unmanaged range is available for extensions. A data bit in the MAC header indicates whether the frame contains IEs. IEs are grouped into Header IEs, consumed by the MAC layer and therefore typically invisible to the next higher layer, and Payload IEs, which are passed untouched to the next higher layer, possibly 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 nodes to exchange information. A.13. Extensibility The TSCH standard is designed to be extensible. It introduces the mechanisms as "building block" (e.g., cells, bundles, slotframes, etc.), but leaves entire freedom to the upper layer to assemble those. The MAC protocol can be extended by defining new Header IEs. An intermediate layer can be defined to manage the MAC layer by defining new Payload IEs. @@ -951,76 +966,76 @@ This section lists features of TSCH which we believe are important and beneficial to the work of 6TiSCH. B.1. Collision Free Communication TSCH allows one to design a schedule which yields collision-free communication. This is done by building the schedule with dedicated cells in such a way that at most one node communicates with a specific neighbor in each slotOffset/channelOffset cell. Multiple - pairs of neighbor motes can exchange data at the same time, but on + pairs of neighbor nodes can exchange data at the same time, but on different frequencies. B.2. Multi-Channel vs. Channel Hopping A TSCH schedule looks like a matrix of width "slotframe size", S, and of height "number of frequencies", nFreq. For a scheduling algorithm, these can be considered atomic "units" to schedule. In particular, because of the channel hopping nature of TSCH, the scheduling algorithm should not worry about the actual frequency communication happens on, since it changes at each slotframe iteration. B.3. Cost of (continuous) Synchronization - When there is traffic in the network, motes which are communicating + When there is traffic in the network, nodes which are communicating implicitly re-synchronize using the data frames they exchange. In - the absence of data traffic, motes are required to synchronize to + the absence of data traffic, nodes are required to synchronize to their time source neighbor(s) periodically not to drift in time. If - they have not been communicating for some time (typically 30s), motes + they have not been communicating for some time (typically 30s), nodes can exchange an dummy data frame to re-synchronize. The frequency at which such messages need to be transmitted depends on the stability - of the clock source, and on how "early" each mote starts listening + of the clock source, and on how "early" each node starts listening for data (the "guard time"). Theoretically, with a 10ppm clock and a 1ms guard time, this period can be 100s. Assuming this exchange - causes the mote's radio to be on for 5ms, this yields a radio duty + causes the node'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 is + requires nodes to resynchronize periodically, the cost of doing so is very low. B.4. Topology Stability The channel hopping nature of TSCH causes links to be very "stable". Wireless phenomena such as multi-path fading and external - interference impact a wireless link between two motes differently on - each frequency. If a transmission from mote A to mote B fails, + interference impact a wireless link between two nodes differently on + each frequency. If a transmission from node A to node B fails, retransmitting on a different frequency has a higher likelihood of succeeding that retransmitting on the same frequency. As a result, even when some frequencies are "behaving bad", channel hopping "smoothens" the contribution of each frequency, resulting in more stable links, and therefore a more stable topology. B.5. Multiple Concurrent Slotframes The TSCH standard allows for multiple slotframes to coexist in a - mote's schedule. It is possible that, at some timeslot, a mote has - multiple activities scheduled (e.g. transmit to mote B on slotframe - 2, receive from mote C on slotframe 1). To handle this situation, + node's schedule. It is possible that, at some timeslot, a node has + multiple activities scheduled (e.g. transmit to node B on slotframe + 2, receive from node C on slotframe 1). To handle this situation, the TSCH standard defines the following precedence rules: 1. Transmissions take precedence over receptions; 2. Lower slotframe identifiers take precedence over higher slotframe identifiers. - In the example above, the mote would transmit to mote B on slotframe + In the example above, the node would transmit to node B on slotframe 2. Authors' Addresses Thomas Watteyne (editor) Linear Technology 30695 Huntwood Avenue Hayward, CA 94544 USA