Minimal 6TiSCH Configuration

The nodes in a 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. One goal of this document is to define the simplest set of rules for building a TSCH-compliant network, at the necessary price of lesser efficiency. Yet, this minimal mode of operation can also be used during network bootstrap before any schedule is installed into the network so nodes can self organize and the management and configuration information be distributed. In addition, as outlined in the minimal configuration can be used as a fallback mode of operation, ensuring connectivity of nodes in case that dynamic scheduling mechanisms fail or are not available. provides a mechanism whereby the details of slotframe length, timeslot timing, and channel hopping pattern are communicated at synchronization to a node, also Enhanced Beacons can be used to periodically update nodes information. This document describes specific settings for these parameters. Nodes SHOULD broadcast properly formed Enhanced Beacons to announce these values, but during initial implementation and debugging it may be convenient to hard-code these values.

In order to form a network, a minimum schedule configuration is required so nodes can advertise the presence of the network, and allow other nodes to join.

The slotframe, as defined in , 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 a minimal TSCH network, nodes need to be synchronized with the same slotframe configuration so they can exchange Enhanced Beacons (EBs) and data packets. This document recommends the following slotframe configuration.

Minimal configuration +------------------------------------+----------------------+ | Property | Value | +------------------------------------+----------------------+ | Number of time slots per Slotframe | 101 | +------------------------------------+----------------------+ | Number of available channels | 16 | +------------------------------------+----------------------+ | Number of EBs cells | 1 (slotOffset 0) | +------------------------------------+----------------------+ | Number of scheduled cells | 5 (slotOffsets | | | 1,2,3,4,5) | +------------------------------------+----------------------+ | Number of unscheduled cells | 95 (from slotOffset | | | 6 to 100) | +------------------------------------+----------------------+ | Number of MAC retransmissions (max)| 3 | +------------------------------------+----------------------+ | Time Slot duration | 15ms | +------------------------------------+----------------------+ The suggested minimal schedule may be hard-coded in each node. The slotframe is composed of 101 time slots. The first slot in the slotframe is used to send Enhanced Beacons announcing the presence of the network. These EBs are not acknowledged. Five cells are scheduled for exchanging data packets, as described in . These cells are scheduled at slotOffset 1 to 5, and channeOffset 0. Per the IEEE802.15.4e TSCH, data packets sent on these cells to a unicast MAC address are acknowledged by the receiver. The 95 remaining cells are unscheduled, but are available to be allocated by dynamic scheduling solutions.

Per the TSCH, each scheduled cell has a bitmap of cell options assigned, named LinkOption. All scheduled cells in the minimal schedule are configured as Hard cells . Additional available cells can be scheduled by a dynamic scheduling solution and can either be configured as hard cells or soft cells without any restriction. 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 options below that results in "Slotted Aloha" behaviour. Because both the "Transmit" and "Receive" bits are set, a node either transmits, if there is a packet in its queue, or listens if it has nothing to transmit. Because the "shared" bit is set, the back-off mechanism defined in is used to resolve contention. 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 are unscheduled. Thus the nodes can keep their radio off. In a memory efficient implementation, scheduled cells could be represented by a circular linked list. Unscheduled cells SHOULD NOT occupy any memory.

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 and the MAC layer MUST notify the upper layer. Packets sent to the broadcast MAC address (including EBs) are not acknowledged and therefore not retransmitted.

The figure below shows an active timeslot in which a packet is sent from the transmitter node (TX) to the receiver node (RX). 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 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). This document recommends to pre-configure the different durations to the values listed below or use EBs to learn those values included in the TimeSlot IE.

Timeslot durations +---------------------------------+------------------+ | IEEE802.15.4e TSCH parameter | Value | +---------------------------------+------------------+ | TsTxOffset | 4000us | +---------------------------------+------------------+ | TsLongGT | 2600us | +---------------------------------+------------------+ | TsTxAckDelay | 4606us | +---------------------------------+------------------+ | TsShortGT | 1000us | +---------------------------------+------------------+ | Time Slot duration | 15000us | +---------------------------------+------------------+

does not define how 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 a Keep-Alive (KA) mechanism is used in parallel. For a simplest TSCH configuration, a mote SHOULD send an EB every 10s. For additional reference see where different synchronization approaches are summarized. EBs MUST be sent with the Beacon IEEE802.15.4 frame type and this EBs MUST carry the following Information Elements (IEs): (The content of the IEs is presented here for clarity, however this information is redundant with and .)

Contains synchronization information such as ASN and Join Priority. The value of Join Priority is discussed in .

Length (b0-b7) = 0x06 Sub-ID (b8-b14) = 0x1a Type (b15) = 0x00 (short)

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)

Although the schedule may be hard-coded during development, each node MUST indicate the schedule in each EB through a Frame and Cell IE. This enables nodes which implement fully to configure their schedule as they join the network, and interact with nodes using a hard-coded schedule.

Length (b0-b7) = variable Sub-ID (b8-b14) = 0x1b Type (b15) = 0x00 (short)

# Slotframes (b16-b23) = 0x01 Slotframe ID (b24-b31) = 0x01 Size Slotframe (b32-b47) = 0x65 (101) # Links (b48-b55) = 0x06 For each link in the minimal schedule: Channel Offset (2B) = 0x00 Slot Number (2B) = from 0x00 to 0x05 LinkOption (1B) = as described in

MAC-layer acknowledgement frames are built according to . Data frames and command frames sent to a unicast MAC destination address request an acknowledgement. The acknowledgement frame is of type ACK (0x10). Each acknowledgement contains the following IE:

The ACK/NACK time correction IE is used to carry the measured de-synchronization between the sender and the receiver.

Length (b0-b7) = 0x02 Sub-ID (b8-b14) = 0x1e Type (b15) = 0x00 (short)

Time Synch Info and ACK status (b16-b31) The possible values for the Time Synch Info and ACK status are described in and reproduced in the following table:

does not define how and when each node in the network keeps information about its neighbours. This document recommends to keep the following information in the Neighbour table:

The exact format of the neighbour table is implementation-specific, but it SHOULD contain the following information for each neighbour: Neighbour statistics: numTx: number of transmitted packets to that neighbour numTxAck: number of transmitted packets that have been acknowledged by that neighbour numRx: number of received packets from that neighbour The EUI64 of the neighbour address. Timestamp when that neighbour was heard for the last time. This can be based on the ASN counter or any other time base. Can be used to trigger a keep-alive message. RPL rank of that neighbour. A flag which indicates whether this neighbour is a time source neighbour. Connectivity statistics (e.g., RSSI), which can be used to determine 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 neighbour and connectivity statistics. An example RPL objective function is the OF Zero as described in and .

Each node MUST select at least one time source neighbour amongst its known neighbours in its RPL routing parent set. When a node joins a network, it has no routing information yet. To select its time source neighbour, uses the Join Priority information advertised in the EB as described in Section 5.2.4.13 and Table 52b of . The Sync IE contains the ASN and 1 Byte field named Join Priority. The Join Priority of any node is equivalent to the result of the function DAGRank(rank) as defined by and . The Join Priority of the DAG root is zero, i.e., EBs sent from the DAG root are sent with Join Priority equal to 0. A lower value of the Join Priority indicates that the device is the preferred one to connect to. When a node Joins the network MUST NOT be allowed to send EBs until it has acquired a RPL rank. The latter avoids topology loops and matches RPL topology with underlying mesh topology. As soon as a node acquires a RPL rank (see and ), it SHOULD send Enhanced Beacons including a Sync IE with Join Priority field set as DAGRank(rank) where rank is the rank of the actual node. In case of a node receives EBs from different nodes with equal Join Priority, the time source neighbour selection should be assessed by other metrics that can help to determine the better connectivity link. Time source neighbor hysteresis SHOULD be addressed according to the rules defined in . If connectivity to the time source neighbor is lost, a new time source neighbor MUST be chosen among the neighbor in the RPL routing parent set. Optionally, some form of hysteresis SHOULD be implemented to avoid frequent changes in time source neighbors.

does not define the use of queues to handle upper layer data (either application or control data from upper layers). This document recommends the use of 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. Frames generated by the MAC layer (e.g., EBs and ACK) have a higher priority than 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 an IEEE802.15.4 frames of types Beacon or Command frames.

Nodes in the network MUST use the RPL routing protocol

Nodes in the network MUST use the RPL routing protocol .

The rank computation is described at Section 4.1. Briefly, a node rank is computed by the following equation: R(N) = R(P) + rank_increase rank_increase = (Rf*Sp + Sr) * MinHopRankIncrease Where: R(N): Rank of the node. R(P): Rank of the parent obtained as part of the DIO information. rank_increase: The result of a function that determines the rank increment. Rf (rank_factor): A configurable factor that is used to multiply the effect of the link properties in the rank_increase computation. If none is configured, then a rank_factor of 1 is used. For the purpose of this document rank_factor MUST be set to 1. Sp (step_of_rank): (strictly positive integer) - an intermediate computation based on the link properties with a certain neighbour. For the purpose of this document 2*ETX (Expected Transmissions) as defined by and MUST be used. The ETX will be computed as the inverse of the Packet Delivery Ratio (PDR) computed as the number of acknowledged packets divided by the number of transmitted packets to a certain node. E.g: Sp=2*numTX/numTXAck Sr (stretch_of_rank): (unsigned integer) - the maximum augmentation to the step_of_rank of a preferred parent to allow the selection of an additional feasible successor. If none is configured to the device, then the step_of_rank is not stretched. For the present document stretch_of_rank MUST be set to 0. MinHopRankIncrease: the MinHopRankIncrease is set to the fixed constant DEFAULT_MIN_HOP_RANK_INCREASE . DEFAULT_MIN_HOP_RANK_INCREASE has a value of 256. DAGRank(rank): Equivalent to the floor of (Rf*Sp + Sr) as defined by . Specifically, when an Objective Function computes Rank this is defined as an unsigned integer (i.e., 16-bit) Rank quantity. When the Rank is compared, e.g., for determination of parent relationships or loop detection, the integer portion of the Rank is used. The integer portion of the Rank is computed by the DAGRank() macro as floor(x) where floor(x) is the function that evaluates to the greatest integer less than or equal to x. DAGRank(rank) = floor(rank/MinHopRankIncrease)

Rank computation scenario +-------+ | P | R(P) | | +-------+ | | | +-------+ | N | R(N)=R(P) + rank_increase | | rank_increase = (Rf*Sp + Sr) * MinHopRankIncrease +-------+ Sp=2*ETX

This sections illustrates with an example the use of the Objective Function Zero. Assume the following parameters: Rf = 1 Sp = 2* ETX Sr = 0 minHopRankIncrease = 256 (default in RPL) ETX=(numTX/numTXAck) r(n) = r(p) + rank_increase rank_increase = (Rf*Sp + Sr) * minHopRankIncrease rank_increase = 512*numTx/numTxACK

Rank computation example for 5 hop network where numTx=100 and numTxAck=75 for all nodes +-------+ | 0 | R(0)=0 | | DAGRank(R(0)) = 0 +-------+ | | +-------+ | 1 | R(1)=R(0)+683=683 | | DAGRank(R(1)) = 2 +-------+ | | +-------+ | 2 | R(2)=R(1)+683=1366 | | DAGRank(R(2)) = 5 +-------+ | | +-------+ | 3 | R(3)=R(2)+683=2049 | | DAGRank(R(3)) = 8 +-------+ | | +-------+ | 4 | R(4)=R(3)+683=2732 | | DAGRank(R(4)) = 10 +-------+ | | +-------+ | 5 | R(5)=R(4)+683=3415 | | DAGRank(R(5)) = 13 +-------+

In addition to the Objective Function (OF), a minimal configuration for RPL should indicate the preferred mode of operation and trickle timer operation so different RPL implementations can interoperate.

For downstream route maintenance, in a minimal configuration, RPL MUST be set to operate in the Non-Storing mode as described by Section 9.7. Storing mode ( Section 9.8) MAY be supported in less constrained devices.

RPL signalling messages such as DIOs are sent using the Trickle Algorithm (Section 8.3.1) and . For the purpose of this document, the Trickle Timer MUST be used with the RPL defined default values (Section 8.3.1). For a description of the Trickle timer operation see Section 4.2 on .

According to the recommends the use of a boundary value (PARENT_SWITCH_THRESHOLD) to avoid constant changes of parent when ranks are compared. When evaluating a parent that belongs to a smaller path cost than current minimum path, the candidate node is selected as new parent only if the difference between the new path and the current path is greater than the defined PARENT_SWITCH_THRESHOLD. Otherwise the node MAY continue to use the current preferred parent. As for the recommended value for PARENT_SWITCH_THRESHOLD is 192 when ETX metric is used, the recommendation for this document is to use PARENT_SWITCH_THRESHOLD equal to 394 as the metric being used is 2*ETX. This is mechanism is suited to deal with parent hysteresis in both cases routing parent and time source neighbor selection.

The authors would like to acknowledge the guidance and input provided by the 6TiSCH Chairs Pascal Thubert and Thomas Watteyne.