Minimal 6TiSCH Configuration

Minimal 6TiSCH Configuration Universitat Oberta de Catalunya

156 Rambla Poblenou Barcelona Catalonia 08018 Spain xvilajosana@uoc.edu

University of California Berkeley

512 Cory Hall Berkeley California 94720 USA pister@eecs.berkeley.edu

Internet Area 6TiSCH Draft This document describes a minimal mode of operation for a 6TiSCH Network. It provides IPv6 connectivity over a Non-Broadcast Multi-Access (NBMA) mesh composed of IEEE802.15.4 Timeslotted Channel Hopping (TSCH) links. This minimal mode uses a collection of protocols including the 6LoWPAN framework to enable interoperable IPv6 connectivity over IEEE802.15.4 TSCH with minimal network configuration and infrastructure.

A 6TiSCH Network provides IPv6 connectivity over a Non-Broadcast Multi-Access (NBMA) network that is composed of IEEE802.15.4 Timeslotted Channel Hopping (TSCH) links. Nodes in an IEEE802.15.4 TSCH network follow a communication schedule. When following this specification, a node learns the schedule of the network when joining, the schedule is static and the same for all nodes. This specification defines operational parameters and procedures for a minimal mode of operation to build a 6TiSCH Network. The 802.15.4 TSCH mode, the 6LoWPAN framework, RPL , and its Objective Function 0 (OF0) , are used unmodified. Parameters and particular operations of TSCH are specified to guarantee interoperability between nodes in a 6TiSCH Network. RPL is a natural choice for routing on top of IEEE802.15.4 TSCH, and the specifics for interoperable interaction between RPL and TSCH are described. More advanced work is expected in the future to complement the Minimal Configuration with dynamic operations that can adapt the schedule to the needs of the traffic at run time.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

This document uses terminology from . The following concepts are used in this document: Start of Frame Delimiter. Reception. Transmission. Field in the TSCH Synchronization IE. Number of hops separating the node sending the EB, and the PAN coordinator.

An implementation compliant to this specification MUST implement the IEEE802.15.4 in "timeslotted channel hopping" (TSCH) mode. The remainder of this section details the RECOMMENDED TSCH settings, which are summarized in . A node MAY use different values. Any of the properties marked in the EB column are announced in the Enhanced Beacons (EB) the nodes send . Changing their value hence means changing the contents of the EB. In case of discrepancy between the values in this specification and the IEEE802.15.4 specification , the IEEE standard has precedence.

The TSCH slotframe is composed of a tunable number of timeslots. The slotframe length (i.e. the number of timeslots it contains) trades off bandwidth for energy consumption. The slotframe length needs to be tuned; the way of tuning it is out of scope of this specification. The slotframe length is announced in the EB. There is only a single scheduled cell in the slotframe. This cell MAY be scheduled at any slotOffset/channelOffset within the slotframe. The location of that cell in the schedule is announced in the EB. The macLinkType of the scheduled cell is ADVERTISING to allow EBs to be sent on it. shows an example of a slotframe of length 101 timeslots, resulting in a radio duty cycle below 0.99%.

Chan. +----------+----------+ +----------+ Off.0 | TxRxS/EB | OFF | | OFF | Chan. +----------+----------+ +----------+ Off.1 | OFF | OFF | ... | OFF | +----------+----------+ +----------+ . . . Chan. +----------+----------+ +----------+ Off.15 | OFF | OFF | | OFF | +----------+----------+ +----------+ slotOffset 0 1 100 EB: Enhanced Beacon TX: Transmit RX: Receive S: Shared OFF: Unscheduled by this specification A node MAY use the scheduled cell to transmit/receive all types of link-layer frames. EBs are sent to the link-layer broadcast address, and not acknowledged. Data frames are sent unicast, and acknowledged by the receiving neighbor. All remaining cells in the slotframe are unscheduled. Dynamic scheduling solutions MAY be defined in the future which schedule those cells. One example is the 6top Protocol (6P) . Dynamic scheduling solutions are out of scope of this document. Details about the usage of the non-scheduled cells are out of scope of this document. In particular, this specification does not make any restriction on the Link Option bitmap associated with those dynamically scheduled cells (i.e. they can be "Hard" or "Soft" cells, see ). The default values of the Timeslot template and Channel Hopping sequence (defined in ) SHOULD be used. A node MAY use different values by properly announcing it in its Enhanced Beacon.

In the scheduled cell, a node transmits if there is a packet to transmit, listens otherwise (both "TX" and "RX" bits are set). When a node transmits and does not receive a link-layer acknowledgment, it uses a back-off mechanism to resolve possible collisions ("Shared" bit is set). A node joining the network maintains time synchronization to its initial time source neighbor using that cell ("Timekeeping" bit is set). This translates into a Link Option for this cell of value 0x0f: b0 = TX Link = 1 (set) b1 = RX Link = 1 (set) b2 = Shared Link = 1 (set) b3 = Timekeeping = 1 (set) b4 = Priority = 0 (clear) b5-b7 = Reserved = 0 (clear) The scheduled cell is a "Hard cell" , i.e. it cannot be moved or relocated by any dynamic scheduling mechanism.

Per , the RECOMMENDED maximum number of link-layer retransmissions is 3. This means that, for packets requiring an acknowledgment, if none are received after a total of 4 attempts, the transmission is considered failed and the link layer MUST notify the upper layer. Packets not requiring an acknowledgment (including EBs) are not retransmitted.

shows an active timeslot in which a packet is sent from the transmitter node (TX) to the receiver node (RX). A link-layer acknowledgment is sent by the RX node to the TX node when the packet is to be acknowledged. The tsTxOffset duration defines the instant in the timeslot when the first bit after the Start of Frame Delimiter (SFD) of the transmitted packet leaves the radio of the TX node. The radio of the RX node is turned on tsRxWait/2 before that instant, and listens for at least tsRxWait. This allows for a de-synchronization between the two nodes of at most tsRxWait/2 in either direction (early or late). The RX node needs to send the first bit after the SFD of the MAC acknowledgment exactly tsTxAckDelay after the end of the last byte of the received packet. TX's radio has to be turned on tsAckWait/2 before that time, and keep listening for at least tsAckWait. The TX node can perform a Clear Channel Assessment (CCA) if required; this does not interfere with the scope of this document. The use of CCA is OPTIONAL.

/---------------------- Timeslot Duration -----------------------/ | / (5) / | | | / tsRxAckDelay /| | | | |-------------------+--------------+------------------+------+---| TX |/(1)/ (2) / (3) /| TX frame | |RX ACK| | |----+-------+------+--------------+------------------+------+---| |/ tsTxOffset /| | | | | | | | | | | |-------------------+--------------+------------------+------+---| RX | | | | RX frame | |TX ACK| | |----------------+--+--+-----------+------------------+------+---| | | | | | | | | | / (4) / / tsTxAckDelay / | | Start End of of Slot Slot /(1)/ tsCCAOffset /(2)/ tsCCA /(3)/ tsRxTx /(4)/ tsRxWait /(5)/ tsAckWait Per , the RECOMMENDED timeslot template is the default one defined in .

The following sections detail the RECOMMENDED format of link-layer frames of different types. A node MAY use a different formats (bit settings, etc), but MUST implement IEEE802.15.4 TSCH correctly. As long as an implementation follows IEEE802.15.4 TSCH correctly, it is compliant to this specification.

The IEEE802.15.4 header of BEACON, DATA and ACKNOWLEDGMENT frames SHOULD include the Source Address field and the Destination Address field. The Frame Version field SHOULD be set to 0b10 (Frame Version 2). The IEEE802.15.4 header SHOULD include Source Address field and the Destination Address field. The Sequence Number field MAY be elided. The PAN ID Compression bit SHOULD indicate that the Source PAN ID is "Not Present" and the Destination PAN ID is "Present". The value of the PAN ID Compression bit is specified in Table 7-6 of the IEEE802.15.4 2015 specification, and depends on the type of the destination and source link-layer addresses (short, extended, not present). While listening for EBs, a joining node set its own PAN ID to 0xffff in order to meet the filtering rules in the IEEE802.15.4 specification . The Nonce is formatted according to . In the IEEE802.15.4 specification , nonce generation is described in Section 9.3.2.2, and byte ordering in Section 9.3.1, Annex B.2 and Annex B.2.2.

The IEEE802.15.4 specification does not define how often EBs are sent, nor their contents . In a minimal TSCH configuration, a node SHOULD send an EB every EB_PERIOD. Tuning EB_PERIOD allows a trade-off between joining time and energy consumption. EBs SHOULD NOT be used for time synchronization. Time synchronization SHOULD only be achieved through normal data traffic and keep-alive frames. further discusses different time synchronization approaches. EBs MUST be sent as per the IEEE802.15.4 specification and SHOULD carry the Information Elements (IEs) listed below . Contains synchronization information such as ASN and Join Metric. The value of the Join Metric field is discussed in . Contains the timeslot template identifier. This template is used to specify the internal timing of the timeslot. This specification RECOMMENDS the default timeslot template. Contains the channel hopping sequence identifier. This specification RECOMMENDS the default channel hopping sequence. Enables joining nodes to learn the initial schedule to be used as they join the network. This document RECOMMENDS the use of a single cell. If a node strictly follows the recommended setting from , the EB it sends has the exact same contents as an EB it has received when joining, except for the Join Metric field in the TSCH Synchronization IE.

Per , each acknowledgment contain an ACK/NACK Time Correction IE.

All link-layer frames MUST be secured by the link-layer security mechanisms defined in IEEE802.15.4 : link-layer authentication and link-layer encryption. Link-layer authentication applies to the entire frame, including the IEEE802.15.4 header. Link-layer encryption applies only to IEEE802.15.4 payload IEs and the IEEE802.15.4 payload. This specification assumes the existence of two cryptographic keys. These keys can be pre-configured, or learned during a key distribution phase. Key distribution is out of scope of this document. Key K1 is used to authenticate EBs. As defined in , EBs MUST be authenticated only (no encryption). This facilitates logical segregation of distinct networks. Key K2 is used to authenticate and encrypt DATA and ACKNOWLEDGMENT frames. Depending on the security policy, K1 and K2 could be the same key. For early interoperability testing, value 36 54 69 53 43 48 20 6D 69 6E 69 6D 61 6C 31 35 ("6TiSCH minimal15") MAY be used for K1.

In a multi-hop topology, the RPL routing protocol MAY be used.

If RPL is used, nodes MUST implement the RPL Objective Function Zero (OF0) .

The Rank computation is described at , Section 4.1. A node's Rank (see Figure 4 for an example) is computed by the following equations: R(N) = R(P) + rank_increment rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease lists the OF0 parameter values that MUST be used if RPL is used.

+----------------------+-------------------------------------+ | OF0 Parameters | Value | +----------------------+-------------------------------------+ | Rf | 1 | +----------------------+-------------------------------------+ | Sp | (3*ETX)-2 | +----------------------+-------------------------------------+ | Sr | 0 | +----------------------+-------------------------------------+ | MinHopRankIncrease | DEFAULT_MIN_HOP_RANK_INCREASE (256) | +----------------------+-------------------------------------+ | MINIMUM_STEP_OF_RANK | 1 | +----------------------+-------------------------------------+ | MAXIMUM_STEP_OF_RANK | 9 | +----------------------+-------------------------------------+ | ETX limit to select | 3 | | a parent | | +----------------------+-------------------------------------+ The step_of_rank (Sp) uses Expected Transmission Count (ETX) . ETX is computed using the reception/non-reception of link-layer ACKs. An implementation MUST follow OF0's normalization guidance as discussed in Section 1 and Section 4.1 of . Sp SHOULD be calculated as (3*ETX)-2. The minimum value of Sp (MINIMUM_STEP_OF_RANK) indicates a good quality link. The maximum value of Sp (MAXIMUM_STEP_OF_RANK) indicates a poor quality link. The default value of Sp (DEFAULT_STEP_OF_RANK) indicates an average quality link. Candidate parents with ETX greater than 3 SHOULD NOT be selected. This avoids having ETX values on used links which are larger that the maximum allowed transmission attempts.

This section illustrates the use of the Objective Function Zero (see ). We have: rank_increment = ((3*numTx/numTxAck)-2)*minHopRankIncrease = 512

+-------+ | 0 | R(minHopRankIncrease) = 256 | | DAGRank(R(0)) = 1 +-------+ | | +-------+ | 1 | R(1)=R(0) + 512 = 768 | | DAGRank(R(1)) = 3 +-------+ | | +-------+ | 2 | R(2)=R(1) + 512 = 1280 | | DAGRank(R(2)) = 5 +-------+ | | +-------+ | 3 | R(3)=R(2) + 512 = 1792 | | DAGRank(R(3)) = 7 +-------+ | | +-------+ | 4 | R(4)=R(3) + 512 = 2304 | | DAGRank(R(4)) = 9 +-------+ | | +-------+ | 5 | R(5)=R(4) + 512 = 2816 | | DAGRank(R(5)) = 11 +-------+

When RPL is used, nodes MUST support the non-storing ( Section 9.7) mode of operation. The storing ( Section 9.8) mode of operation SHOULD be supported by nodes with enough capabilities. Nodes not supporting RPL MUST join as leaf nodes.

RPL signaling messages such as DIOs are sent using the Trickle Algorithm (Section 8.3.1) and (Section 4.2). For this specification, the Trickle Timer MUST be used with the RPL defined default values (Section 8.3.1).

RPL information and hop-by-hop extension headers MUST follow and specification. In the case the packets formed at the LLN need to cross through intermediate routers, these MUST follow the IP-in-IP encapsulation requirement specified by the and . Routing extension headers such as RPI and SRH , and outer IP headers in case of encapsulation MUST be compressed according to and .

The Join Metric of the TSCH Synchronization IE in the EB MUST be calculated based on the routing metric of the node, normalized to a value between 0 and 255. A lower value of the Join Metric indicates the node sending the EB is topologically "closer" to the root of the network. A lower value of the Join Metric hence indicates higher preference for a joining node to synchronize to that neighbor. In case that the network uses RPL, the Join Metric of any node (including the DAG root) MUST be set to DAGRank(rank)-1. According to , DAGRank(rank(0)) = 1. DAGRank(rank(0))-1 = 0 is compliant IEEE802.15.4's requirement of having the root use Join Metric = 0.

When a node joins a network, it may hear EBs sent by different nodes already in the network. The decision of which neighbor to synchronize to (e.g. which neighbor becomes the node's initial time source neighbor) is implementation-specific. For example, after having received the first EB, a node MAY listen for at most MAX_EB_DELAY seconds until it has received EBs from NUM_NEIGHBOURS_TO_WAIT distinct neighbors. When receiving EBs from distinct neighbors, the node MAY use the Join Metric field in each EB to select the initial time source neighbor, as described in IEEE802.15.4 , Section 6.3.6.

When a RPL node joins the network, it MUST NOT send EBs before having acquired a RPL Rank to avoid inconsistencies in the time synchronization structure. This applies to other routing protocols with their corresponding routing metrics. As soon as a node acquires routing information (e.g. a RPL Rank, see ), it SHOULD start sending Enhanced Beacons.

At any time, a node MUST maintain connectivity to at least one time source neighbor. A node's time source neighbor MUST be chosen among the neighbors in its routing parent set.

Per and , the specification 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 the 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. Per , the PARENT_SWITCH_THRESHOLD SHOULD be set to 192 when ETX metric is used (in the form 128*ETX), the recommendation for this document is to use PARENT_SWITCH_THRESHOLD equal to 640 if the metric being used is ((3*ETX)-2)*minHopRankIncrease, or a proportional value. This deals with hysteresis both for routing parent and time source neighbor selection. In case a node has a security association with its parent, including routing parent or time source neighbor, the node SHOULD be allowed to keep the association despite of fluctuations of the rank.

The exact format of the neighbor table is implementation-specific. The RECOMMENDED per-neighbor information is (taken from the implementation): Identifier(s) of the neighbor (e.g. EUI-64). Number of link-layer transmission attempts to that neighbor. Number of transmitted link-layer frames that have been link-layer acknowledged by that neighbor. Number of link-layer frames received from that neighbor. When the last frame was received from that neighbor. This can be based on the ASN counter or any other time base. It can be used to trigger a keep-alive message. Such as the RPL Rank of that neighbor. A flag indicating whether this neighbor is a time source neighbor.

The IEEE802.15.4 specification does not define the use of queues to handle upper layer data (either application or control data from upper layers). The following rules are RECOMMENDED: A node is configured to keep in the queues a configurable number of Upper Layer packets per link (default NUM_UPPERLAYER_PACKETS) for a configurable time that should cover the join process (default MAX_JOIN_TIME). Frames generated by the IEEE802.15.4 layer (including EBs) are queued with a priority higher than frames coming from higher-layers. Frame types BEACON and COMMAND are queued with higher priority than frame types DATA and ACK. One entry in the queue is reserved at all times for frames of types BEACON and COMMAND frames.

lists RECOMMENDED values for the settings discussed in this specification.

+-------------------------+-------------------+ | Parameter | RECOMMENDED Value | +-------------------------+-------------------+ | MAX_EB_DELAY | 180 | +-------------------------+-------------------+ | NUM_NEIGHBOURS_TO_WAIT | 2 | +-------------------------+-------------------+ | PARENT_SWITCH_THRESHOLD | 640 | +-------------------------+-------------------+ | NUM_UPPERLAYER_PACKETS | 1 | +-------------------------+-------------------+ | MAX_JOIN_TIME | 300 | +-------------------------+-------------------+

This document requests no immediate action by IANA.

The authors acknowledge the guidance and input from Rene Struik, Pat Kinney, Michael Richardson, Tero Kivinen, Nicola Accettura, Malisa Vucinic, and thank Charles Perkins and Suresh Krishnan for the exhaustive and detailed review. Thanks to Simon Duquennoy, Guillaume Gaillard, Tengfei Chang and Jonathan Muñoz for the detailed review of the examples section. Thanks to 6TiSCH co-chairs Pascal Thubert and Thomas Watteyne for their guidance and advice.

IEEE Std 802.15.4-2015 Standard for Low-Rate Wireless Personal Area Networks (WPANs) IEEE standard for Information Technology OpenWSN: a Standards-Based Low-Power Wireless Development Environment

This section contains several example packets. Each example contains (1) a schematic header diagram, (2) the corresponding bytestream, (3) a description of each of the IEs that form the packet. Packet formats are specific for the revision and may vary in future releases of the IEEE standard. In case of differences between the packet content presented in this section and , the latter has precedence. The MAC header fields are described in a specific order. All field formats in this examples are depicted in the order in which they are transmitted, from left to right, where the leftmost bit is transmitted first. Bits within each field are numbered from 0 (leftmost and least significant) to k – 1 (rightmost and most significant), where the length of the field is k bits. Fields that are longer than a single octet are sent to the PHY in the order from the octet containing the lowest numbered bits to the octet containing the highest numbered bits (little endian).

1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Len1 = 0 |Element ID=0x7e|0| Len2 = 26 |GrpId=1|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Len3 = 6 |Sub ID = 0x1a|0| ASN +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ASN | Join Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Len4 = 0x01 |Sub ID = 0x1c|0| TT ID = 0x00 | Len5 = 0x01 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A |Sub ID = 0x1b|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | #SF = 0x01 | SF ID = 0x00 | SF LEN = 0x65 (101 slots) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | #Links = 0x01 | SLOT OFFSET = 0x0000 | CHANNEL +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OFF = 0x0000 |Link OPT = 0x0F| NO MAC PAYLOAD +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bytestream: 00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 01 1C 00 01 C8 00 0A 1B 01 00 65 00 01 00 00 00 00 0F Description of the IEs: #Header IE Header Len1 = Header IE Length (0) Element ID = 0x7e - termination IE indicating Payload IE coming next Type 0 #Payload IE Header (MLME) Len2 = Payload IE Len (26 Bytes) GroupID = 1 MLME (Nested) Type = 1 #MLME-SubIE TSCH Synchronization Len3 = Length in bytes of the sub-IE payload (6 Bytes) SubID = 0x1a (MLME-SubIE TSCH Synchronization) Type = Short (0) ASN = Absolute Sequence Number (5 Bytes) Join Metric = 1 Byte #MLME-SubIE TSCH TimeSlot Len4 = Length in bytes of the sub-IE payload (1 Byte) SubID = 0x1c (MLME-SubIE Timeslot) Type = Short (0) TimeSlot template ID = 0x00 (default) #MLME-SubIE Ch. Hopping Len5 = Length in bytes of the sub-IE payload (1 Byte) SubID = 0x09 (MLME-SubIE Ch. Hopping) Type = Long (1) Channel Hopping Sequence ID = 0x00 (default) #MLME-SubIE TSCH Slotframe and Link Len6 = Length in bytes of the sub-IE payload (10 Bytes) SubID = 0x1b (MLME-SubIE TSCH Slotframe and Link) Type = Short (0) Number of slotframes = 0x01 SlotFrame Handle = 0x00 SlotFrame Size = 101 slots (0x65) Number of Links = 0x01 Timeslot = 0x0000 (2B) Channel Offset = 0x0000 (2B) Link Option = 0x0F (tx,rx,shared,timekeeping)

Using a custom timeslot template in EBs: setting timeslot length to 15ms.

1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Len1 = 0 |Element ID=0x7e|0| Len2 = 53 |GrpId=1|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Len3 = 6 |Sub ID = 0x1a|0| ASN +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ASN | Join Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Len4 = 25 |Sub ID = 0x1c|0| TT ID = 0x01 | macTsCCAOffset +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 2700 | macTsCCA = 128 | macTsTxOffset +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 3180 | macTsRxOffset = 1680 | macTsRxAckDelay +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 1200 | macTsTxAckDelay = 1500 | macTsRxWait +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 3300 | macTsAckWait = 600 | macTsRxTx +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 192 | macTsMaxAck = 2400 | macTsMaxTx +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = 4256 | macTsTimeslotLength = 15000 | Len5 = 0x01 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bytestream: 00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 19 1C 01 8C 0A 80 00 6C 0C 90 06 B0 04 DC 05 E4 0C 58 02 C0 00 60 09 A0 10 98 3A 01 C8 00 0A ... Description of the IEs: #Header IE Header Len1 = Header IE Length (none) Element ID = 0x7e - termination IE indicating Payload IE coming next Type 0 #Payload IE Header (MLME) Len2 = Payload IE Len (53 Bytes) GroupID = 1 MLME (Nested) Type = 1 #MLME-SubIE TSCH Synchronization Len3 = Length in bytes of the sub-IE payload (6 Bytes) SubID = 0x1a (MLME-SubIE TSCH Synchronization) Type = Short (0) ASN = Absolute Sequence Number (5 Bytes) Join Metric = 1 Byte #MLME-SubIE TSCH TimeSlot Len4 = Length in bytes of the sub-IE payload (25 Bytes) SubID = 0x1c (MLME-SubIE Timeslot) Type = Short (0) TimeSlot template ID = 0x01 (non-default) The 15ms timeslot announced: +--------------------------------+------------+ | IEEE802.15.4 TSCH parameter | Value (us) | +--------------------------------+------------+ | tsCCAOffset | 2700 | +--------------------------------+------------+ | tsCCA | 128 | +--------------------------------+------------+ | tsTxOffset | 3180 | +--------------------------------+------------+ | tsRxOffset | 1680 | +--------------------------------+------------+ | tsRxAckDelay | 1200 | +--------------------------------+------------+ | tsTxAckDelay | 1500 | +--------------------------------+------------+ | tsRxWait | 3300 | +--------------------------------+------------+ | tsAckWait | 600 | +--------------------------------+------------+ | tsRxTx | 192 | +--------------------------------+------------+ | tsMaxAck | 2400 | +--------------------------------+------------+ | tsMaxTx | 4256 | +--------------------------------+------------+ | Timeslot duration | 15000 | +--------------------------------+------------+ #MLME-SubIE Ch. Hopping Len5 = Length in bytes of the sub-IE payload. (1 Byte) SubID = 0x09 (MLME-SubIE Ch. Hopping) Type = Long (1) Channel Hopping Sequence ID = 0x00 (default)

Enhanced Acknowledgment packets carry the Time Correction IE (Header IE).

1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Len1 = 2 |Element ID=0x1e|0| Time Sync Info | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bytestream: 02 0F TS#0 TS#1 Description of the IEs: #Header IE Header Len1 = Header IE Length (2 Bytes) Element ID = 0x1e - ACK/NACK Time Correction IE Type 0

IEEE802.15.4 Auxiliary Security Header with security Level set to ENC-MIC-32.

1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L = 5|M=1|1|1|0|Key Index = IDX| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bytestream: 6D IDX#0 Security Auxiliary Header fields in the example: #Security Control (1 byte) L = Security Level ENC-MIC-32 (5) M = Key Identifier Mode (0x01) Frame Counter Suppression = 1 (omitting Frame Counter field) Frame Counter Size = 1 (construct Nonce from 5 byte ASN) Reserved = 0 #Key Identifier (1 byte) Key Index = IDX (deployment-specific KeyIndex parameter that identifies the cryptographic key)