6TSCH X. Vilajosana, Ed. Internet-Draft Universitat Oberta de Catalunya Intended status: InformationalJune 20, 2013K. Pister Expires:December 22,January 15, 2014 University of California Berkeley July 14, 2013 Minimal 6TSCH Configurationdraft-vilajosana-6tsch-basic-00draft-vilajosana-6tsch-basic-01 Abstract This document describes the minimal set of rules to operate a [IEEE802154e] Timeslotted Channel Hopping (TSCH) network. These rules can be used during early interoperability testing and development, when the centralized and distributed solutions developed by the 6TSCH group are not fully implemented yet, or otherwise not available. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 onDecember 22, 2013.January 15, 2014. Copyright Notice Copyright (c) 2013 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Basic Schedule . . . . . . . . . . . . . . . . . . . . . . .. . . 32 2.1. Slotframe . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2.Cells and cellsCell Options . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Retransmissions . . . . . . . . . . . . . . . . . . . . . 5 2.4. Time Slot timming . . . . . . . . . . . . . . . . . . . . 5 3. Enhanced Beacons Configuration and Content . . . . . . . . . 6 3.1. Sync IE . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2. IE Content . . . . . . . . . . . . . . . . . . . . . 7 3.2. Frame and Link IE . . . . . . . . . . . . . . . . . . . . 7 3.2.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 7 3.2.2. IE Content . . . . . . . . . . . . . . . . . . . . .78 4. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. ACK/NACK Time Correction IE . . . . . . . . . . . . . . . 8 4.1.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 8 4.1.2. IE Content . . . . . . . . . . . . . . . . . . . . . 8 5. Neighbor information . . . . . . . . . . . . . . . . . . . . 9 5.1. Neighbor Table . . . . . . . . . . . . . . . . . . . . . 9 5.2. Time Parent Selection . . . . . . . . . . . . . . . . . . 10 6. Queues and Priorities . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 11 7.3. External Informative References . . . . . . . . . . . . .11 Author's Address .12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The nodes in a [IEEE802154e] TSCH network follow a communication schedule. The entity (centralized or decentralized) responsible for building and maintaining that schedule has very precise control over the trade-off between the network's latency, bandwidth, reliability and power consumption. During early interoperability testing and development, however, simplicity is often more important than efficiency. The goal of this document is todefinesdefine the simplest set of rules for building a [IEEE802154e] TSCH-compliant network, at the necessary price of lesser efficiency. 2. Basic Schedule In order to form a network, a minimum schedule configuration is required so nodes can advertise the presence of the network, andexchange data.allow other nodes to join. 2.1. Slotframe Theslotframe,Slotframe, as definedby [I-D.draft-palattella-6tsch-terminology],in [I-D.palattella-6tsch-terminology], is an abstraction of the MAC layer that defines a collection of time slots of equal length and priority, and which repeats over time. In order to set up aminimalbasic TSCH network, nodes need tousebe synchronized with the same slotframe configuration so they can exchange Enhanced Beacons (EBs) and data packets. This document recommends the following slotframe configuration. Basic configurationconfiguration +---------------------------------+----------------------++------------------------------------+----------------------+ | Property | Value |+---------------------------------+----------------------++------------------------------------+----------------------+ | Number of time slots per Slotframe | 101 |+---------------------------------+----------------------++------------------------------------+----------------------+ | Number of available channels | 16 |+---------------------------------+----------------------++------------------------------------+----------------------+ | Number of EBsslotscells | 1 (slotOffset 0) |+---------------------------------+----------------------++------------------------------------+----------------------+ | Number ofactivescheduled cells | 5 (slotOffsets | | | 1,2,3,4,5) |+---------------------------------+----------------------++------------------------------------+----------------------+ | Number ofinactive slotsunscheduled cells | 95 (from slotOffset | | | 6 to 100) |+---------------------------------+----------------------++------------------------------------+----------------------+ | Number of MAC retransmissions|(max)| 3 |+---------------------------------+----------------------++------------------------------------+----------------------+ | Time Slot duration | 15ms |+---------------------------------+----------------------+ This+------------------------------------+----------------------+ The suggested basic schedule is hard-coded in each node. The slotframe is composed of 101 timeslots, theslots. The first slot in the slotframe is used to send Enhanced Beaconsto announceannouncing the presence of the network. These EBs are not acknowledged. Five cells are scheduled forexchangeingexchanging data packets, as described in Section 2.2. These cells are scheduled at slotOffset 1 to 5, and channeOffset 0. Per the IEEE802.15.4e TSCH standard, data packets sent on these cells to a unicast MAC address are acknowledged by the receiver. The 95 remaining cells areinactive, i.e.unscheduled, i.e., the radio of the nodes remains off. Basic schedule overview +-----+-----+-----+-----+-----+-----+-----+ +-----+ chan.Off. 0 | EB |TxRxS|TxRxS|TxRxS|TxRxS|TxRxS| OFF | ... | OFF | +-----+-----+-----+-----+-----+-----+-----+ +-----+ chan.Off. 1 | | | | | | | | ... | | +-----+-----+-----+-----+-----+-----+-----+ +-----+ ... +-----+-----+-----+-----+-----+-----+-----+ +-----+ chan.Off. 15 | | | | | | | | ... | | +-----+-----+-----+-----+-----+-----+-----+ +-----+ 0 1 2 3 4 5 6 100 2.2.Cells and cellsCell Options Per the [IEEE802154e] TSCH standard, eachactivescheduled cellis assignedhas a bitmap of celloptions.options assigned. All scheduled cells in the basic schedule are configured as Hard cells [I-D.watteyne-6tsch-tsch-lln-context][I-D.draft-wang-6tsch-6top] since reallocation is not considered in that simple approach. The EB cell is assigned the following bitmap of cell options: b0 = Transmit = 1 (set) b1 = Receive = 0 (clear) b2 = Shared = 0 (clear) b3 = Timekeeping = 0 (clear) b4 = Hard = 1 (set) b5-b7 = Reserved (clear) The data cells are assigned the bitmap of cell optionsbelow. Thisbelow that results in "Slotted Aloha" behavior. Because both the "Transmit" and "Receive" bits are set,thea node either transmits, if there is a packet in its queue, or listenswhenif it has nothing to transmit. Because the "shared" bitit set,is set,in presence of collisions it uses the backoff mechanism defined in[IEEE802154e] TSCH to resolve collisions.[IEEE802154e]. b0 = Transmit = 1 (set) b1 = Receive = 1 (set) b2 = Shared = 1 (set) b3 = Timekeeping = 0 (clear) b4 = Hard = 1 (set) b5-b7 = Reserved (clear) All remaining cells areinactive, and sounscheduled. Thus thenodes' radios remainnodes can keep their radio off. In a memory efficient implementation,activescheduled cells could be represented by a circular linked list.InactiveUnscheduled cells should not occupy any memory. 2.3. Retransmissions The maximum number of MAC-layer retransmissions is set to 3. For packets which require an acknowledgement, if none is received after a total of 4 attempts, the transmissions is considered failed at the MAC layer, and the upper layer needs to be notified. Packets sent to the broadcast MAC address (including EBs) are not acknowledged and therefore not retransmitted. 2.4. Time Slot timming The figure below shows an active timeslot in which a packet is sent from the transmitter node (TX) to the receiver node (RX), and a MAC acknowledgement is sent back from the RX to the TX node, indicating successful reception. The TsTxOffset duration defines the instant in the timeslot when the first byte of the transmitted packet leaves the radio of the TX node. The radio of the RX node is turned on TsLongGT /2 before that instant, and listen for at least TsLongGT. This allows for a de-synchronization between the two node of at most TsLongGT. The RX node needs to send the first byte of the MAC acknowledgement exactly TsTxAckDelay after the end of the last byte of the received packet. TX's radio has to be turned on TsShortGT/2 before that time, and keep listening for at least TsShortGT. Time slot internal timing diagram /------------------- Time Slot duration --------------------/ | /tsShortGT/ | | | | | | | |------------+-----------------+--------------+------+------| TX | | TX-Packet | |RX Ack| | |------------+-----------------+--------------+------+------| |/tsTxOffset/| | | | | | | | | | | |------------+-----------------+--------------+------+------| RX | | | | RX-Packet | |TX Ack| | |---------+--+--+--------------+--------------+------+------| | | | | | | | | | /tsLongGT/ |/TsTxAckDelay/| | | Start End of of Slot Slot [IEEE802154e] does not define the different durations of a time slot. It does allow those durations to be sent in the EBs (through a TimeSlot IE), but for simplicity, this document recommends to hard- code the different durations to the values listed below. Timeslot durations +---------------------------------+------------------+ | IEEE802.15.4e TSCHdurationparmeter | Value | +---------------------------------+------------------+ | TsTxOffset | 4000us | +---------------------------------+------------------+ | TsLongGT |1300us2600us | +---------------------------------+------------------+ | TsTxAckDelay | 4606us | +---------------------------------+------------------+ | TsShortGT |500us1000us | +---------------------------------+------------------+ | Time Slot duration | 15000us | +---------------------------------+------------------+ 3. Enhanced Beacons Configuration and Content [IEEE802154e] does not definewhenhow often or which EBs are sent. The choice of the duration between two EBs needs to take into account whether EBs are used as the only mechanism to synchronize devices, or whether aKeep- AliveKeep-Alive (KA) mechanism is used in parallel. For a simplest TSCH configuration, it is recommended to sent EBs at least once every 10s. For additional reference see [I-D.watteyne-6tsch-tsch-lln-context] where different synchronization approaches are summarized. EBs must be sent with the Beacon IEEE802.15.4 frame type and this document recommends that they carry the following Information Elements (IEs): 3.1. Sync IE Contains synchronization information such as ASN and join priority. 3.1.1. IE Header Length (b0-b7) = 0x06 Sub-ID (b8-b14) = 0x1a Type (b15) = 0x00 (short) 3.1.2. IE Content ASN Byte 1 (b16-b23) ASN Byte 2 (b24-b31) ASN Byte 3 (b32-b39) ASN Byte 4 (b40-b47) ASN Byte 5 (b48-b55) Join Priority (b56-b63) 3.2. Frame and Link IE Although the schedule is hard-coded in each node, this document recommends to indicate the schedule in each EB through a Frame and Link IE. This enables nodes which implement [IEEE802154e] fully to be able to configure their schedule as they join the network, and interact with nodes using a hard-coded schedule. 3.2.1. IE Header Length (b0-b7) = variable Sub-ID (b8-b14) = 0x1b Type (b15) = 0x00 (short) 3.2.2. IE Content # Slotframes (b16-b23) = 0x01 Slotframe ID (b24-b31) = 0x01 Size Slotframe (b32-b47) = 0x65 # Links (b48-b55) = 0x06 For each link in the basic schedule: Channel Offset (2B) = 0x00 Slot Number (2B) = from (0x00 to 0x05) LinkOption (1B) = as described in Section 2.2 4. Acknowledgement MAC-layer acknowledgement frames are built according to [IEEE802154e]. Data frames and command frames sent to a unicast MAC destination address request anacknowledged.acknowledgement. The acknowledgement frame is of type ACK (0x10). Each acknowledgement contains the following IE: 4.1. ACK/NACK Time Correction IE The ACK/NACK time correction IE is used to carry the measured desynchronization between the sender and the receiver. 4.1.1. IE Header Length (b0-b7) = 0x02 Sub-ID (b8-b14) = 0x1e Type (b15) = 0x00 (short) 4.1.2. IE Content Time Synch Info and ACK status (b16-b31) The possible values for the Time Synch Info and ACK status are described in the following table: ACK status and Time Synch information. +-----------------------------------+------------------+ | ACK Status | Value | +-----------------------------------+------------------+ | ACK with positive time correction | 0x0000 - 0x07ff | +-----------------------------------+------------------+ | ACK with negative time correction | 0x0800 - 0x0fff | +-----------------------------------+------------------+ | NACK with positive time correction| 0x8000 - 0x87ff | +-----------------------------------+------------------+ | NACK with negative time correction| 0x8800 - 0x8fff | +-----------------------------------+------------------+ 5. Neighbor information [IEEE802154e] does not define how and wheninformation is be kept ateach node in the network keeps information abouteach neighbor.its neighbors. This document recommends to keep the following information in the neighbor table: 5.1. Neighbor Table The exact format of the neighbor table is implementation-specific, but it should at least contain the following information, for each neighbor: Neighbor statistics: number of transmitted packets to that neighbor number of transmitted packets that have been acknowledged by that neighbor number of received packets from that neighbor number of received packets that have been acknowledged for that neighbor Neighbor address. ASN when that neighbor was heard for the lastheard.time. This can be used to trigger akeep-alive.keep-alive message. RPL rank of that neighbor. A flag which indicates whether this neighbor is a time source neighbor. Connectivity statistics (RSSI, LQI, etc), which can be used tohelpdetermine the quality of the link. In addition of that information, each node has to be able to compute some RPL objective function (OF) taking into account the neighbor and connectivity statistics. An example RPL objective function is the ETX. 5.2. Time Parent Selection Each node selects a time parent amongst its known neighbors. When a node joins a network, it has no routing information yet. Its (possibly temporary) time parent is the node it can hear "best", for example based on RSSI measurements of the EBs it received. After having acquired a RPL rank, the RPL routing parents should also be IEEE802.15.4e time source neighbors. Optionally, a node can choose to use an counter to avoid frequent changes in time source neighbor selection. Based on some thresholds (on RSSI for example), if the quality of the link with time parent changes over or below the thresholds for a certain number of times(e.g.(e.g., 3), the instability counter is incremented and another time parent is selected. 6. Queues and Priorities [IEEE802154e] does not define the use of queues to handle upper layer data (either application or control data from upper layers). This document recommends to use a single queue with the following rules: When the node is not synchronized to the network, higher layers are not able to insert packets into the queue. Lower-layer packets have a higher priority that packets received from a higher layer. IEEE802.15.4 frames of types Beacon and Command have a higher priority than IEEE802.15.4 frames of types Data and ACK. One entry in the queue is reserved at all times for a IEEE802.15.4 frames of types Beacon or Command frames. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.7.2. Informative References[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012.[I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-12 (work in progress), March 2013. [I-D.phinney-roll-rpl-industrial-applicability] Phinney, T., Thubert, P., and R. Assimiti, "RPL applicability in industrial networks", draft-phinney-roll- rpl-industrial-applicability-02 (work in progress), February 2013.7.2. Informative References [I-D.watteyne-6tsch-tsch-lln-context] Watteyne, T., Palattella, M., and L. Grieco, "Using IEEE802.15.4e TSCH in an LLN context: Overview, Problem Statement and Goals", draft-watteyne-6tsch-tsch-lln- context-02 (work in progress), May 2013.[I-D.draft-palattella-6tsch-terminology] Palattella, MR., Ed.,[I-D.thubert-6tsch-architecture] Thubert, P.,Watteyne, T.,Assimiti, R., andQ. Wang, "Terminology inT. Watteyne, "An Architecture for IPv6 over Time Slotted ChannelHopping. draft-palattella-6tsch-terminology-00Hopping", draft-thubert-6tsch-architecture-01 (work inprogress) ", Marchprogress), April 2013.[I-D.draft-thubert-6tsch-architecture][I-D.palattella-6tsch-terminology] Palattella, M., Thubert, P.,Ed., Assimiti, R., and T.Watteyne,"An Architecture forT., and Q. Wang, "Terminology in IPv6 over TimeSynchronizedSlotted ChannelHopping. draft-thubert-6tsch-architecture-00Hopping", draft-palattella-6tsch-terminology-00 (work inprogress) ",progress), March 2013.[I-D.draft-wang-6tsch-6tus][I-D.draft-wang-6tsch-6top] Wang, Q., Ed., Vilajosana, X., and T. Watteyne,"6tus Sub- Layer Specification. draft-wang-6tsch-6tus-01"6TSCH Operation Sublayer (6top). draft-wang-6tsch-6top-00 (work in progress) ",MayJuly 2013. [I-D.ohba-6tsch-security] Chasko, S., Das, S., Lopez, R., Ohba, Y., Thubert, P., and A. Yegin, "Security Framework and Key Management Protocol Requirements for 6TSCH", draft-ohba-6tsch-security-01 (work in progress), July 2013. [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-12 (work in progress), March 2013. [I-D.phinney-roll-rpl-industrial-applicability] Phinney, T., Thubert, P., and R. Assimiti, "RPL applicability in industrial networks", draft-phinney-roll- rpl-industrial-applicability-02 (work in progress), February 2013. 7.3. External Informative References [IEEE802154e] IEEE standard for Information Technology, "IEEE std. 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) Amendament 1: MAC sublayer", April 2012. [IEEE802154] IEEE standard for Information Technology, "IEEE std. 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks", June 2011. [OpenWSN] , "Berkeley's OpenWSN Project Homepage", , <http://www.openwsn.org/>.Author's AddressAuthors' Addresses Xavier Vilajosana (editor) Universitat Oberta de Catalunya 156 Rambla Poblenou Barcelona, Catalonia 08018 Spain Phone: +34 (646) 633 681 Email: xvilajosana@uoc.edu Kris Pister University of California Berkeley 490 Cory Hall Berkeley, California 94720 USA Email: pister@eecs.berkeley.edu