idnits 2.17.1 draft-ietf-6tisch-minimal-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A node MUST not queue frames containing higher-layer packets until the node has successfully joined a network. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Sp (step_of_rank): (strictly positive integer) - an intermediate computation based on the link properties with a certain neighbour, i.e., the Expected Transmission Count (ETX) which provides an average of number of packet transmissions between two nodes. ETX is defined in detail by [decouto03high] and [RFC6551]. The ETX is computed as the inverse of the Packet Delivery Ratio (PDR), this is the number of transmitted packets, divided by the number of acknowledged packets to a certain node (e.g., ETX = numTX/ numTXAck). An implementation MUST follow OF0's normalization guidance as discussed in Section 1 and Section 4.1 of [RFC6552], maintaining Sp between MINIMUM_STEP_OF_RANK of 1 to indicate a great quality and MAXIMUM_STEP_OF_RANK of 9 to indicate a really poor quality, with DEFAULT_STEP_OF_RANK indicating a normal, average quality. Sp SHOULD be set to (3*ETX)-2. Candidate parents with ETX greater than 3 SHOULD not be selected. -- The document date (November 27, 2015) is 3073 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '5' on line 438 -- Looks like a reference, but probably isn't: '6' on line 438 -- Looks like a reference, but probably isn't: '12' on line 438 -- Looks like a reference, but probably isn't: '7' on line 438 -- Looks like a reference, but probably isn't: '15' on line 438 -- Looks like a reference, but probably isn't: '4' on line 438 -- Looks like a reference, but probably isn't: '14' on line 438 -- Looks like a reference, but probably isn't: '11' on line 438 -- Looks like a reference, but probably isn't: '8' on line 438 -- Looks like a reference, but probably isn't: '0' on line 438 -- Looks like a reference, but probably isn't: '1' on line 438 -- Looks like a reference, but probably isn't: '2' on line 438 -- Looks like a reference, but probably isn't: '13' on line 438 -- Looks like a reference, but probably isn't: '3' on line 438 -- Looks like a reference, but probably isn't: '9' on line 438 -- Looks like a reference, but probably isn't: '10' on line 438 == Missing Reference: 'CCM' is mentioned on line 915, but not defined == Missing Reference: 'CCM-Star' is mentioned on line 920, but not defined == Missing Reference: 'OpenWSN' is mentioned on line 925, but not defined == Unused Reference: 'RFC7102' is defined on line 890, but no explicit reference was found in the text == Unused Reference: 'RFC3610' is defined on line 894, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154-2012' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154' == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-06 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH X. Vilajosana, Ed. 3 Internet-Draft Universitat Oberta de Catalunya 4 Intended status: Standards Track K. Pister 5 Expires: May 30, 2016 University of California Berkeley 6 November 27, 2015 8 Minimal 6TiSCH Configuration 9 draft-ietf-6tisch-minimal-13 11 Abstract 13 This document describes the minimal set of rules to operate an IEEE 14 802.15.4 Timeslotted Channel Hopping (TSCH) network. This minimal 15 mode of operation can be used during network bootstrap, as a fall- 16 back mode of operation when no dynamic scheduling solution is 17 available or functioning, or during early interoperability testing 18 and development. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 30, 2016. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Minimal Schedule Configuration . . . . . . . . . . . . . . . 3 58 4.1. Slotframe . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.2. Cell Options . . . . . . . . . . . . . . . . . . . . . . 7 60 4.3. Retransmissions . . . . . . . . . . . . . . . . . . . . . 8 61 4.4. Timeslot timing . . . . . . . . . . . . . . . . . . . . . 8 62 5. IEEE.802.15.4 Specific Header Fields and Considerations . . . 9 63 6. Enhanced Beacons Configuration and Content . . . . . . . . . 10 64 7. Acknowledgement Frames . . . . . . . . . . . . . . . . . . . 11 65 8. Neighbour information . . . . . . . . . . . . . . . . . . . . 11 66 8.1. Neighbour Table . . . . . . . . . . . . . . . . . . . . . 11 67 8.2. Time Source Neighbour Selection . . . . . . . . . . . . . 12 68 9. Queues and Priorities . . . . . . . . . . . . . . . . . . . . 13 69 10. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 11. RPL on TSCH . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 11.1. RPL Objective Function Zero . . . . . . . . . . . . . . 14 72 11.1.1. Rank computation . . . . . . . . . . . . . . . . . . 14 73 11.1.2. Rank computation Example . . . . . . . . . . . . . . 15 74 11.2. RPL Configuration . . . . . . . . . . . . . . . . . . . 17 75 11.2.1. Mode of Operation . . . . . . . . . . . . . . . . . 18 76 11.2.2. Trickle Timer . . . . . . . . . . . . . . . . . . . 18 77 11.2.3. Hysteresis . . . . . . . . . . . . . . . . . . . . . 18 78 12. Variable Values . . . . . . . . . . . . . . . . . . . . . . . 18 79 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 80 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 81 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 15.1. Normative References . . . . . . . . . . . . . . . . . . 19 83 15.2. Informative References . . . . . . . . . . . . . . . . . 21 84 15.3. External Informative References . . . . . . . . . . . . 21 85 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 22 86 A.1. Example 1. Information Elements in EBs . . . . . . . . . 22 87 A.2. Example 2. Information Elements in EBs not using default 88 timeslot template . . . . . . . . . . . . . . . . . . . . 24 89 A.3. Example 3. Information Elements in ACKs . . . . . . . . . 26 90 A.4. Example 4. Auxiliary Security Header . . . . . . . . . . 27 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 93 1. Requirements Language 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 2. Introduction 101 The nodes in a IEEE 802.15.4 TSCH network follow a communication 102 schedule. The entity (centralized or decentralized) responsible for 103 building and maintaining that schedule has precise control over the 104 trade-off between the network's latency, bandwidth, reliability and 105 power consumption. During early interoperability testing and 106 development, however, simplicity is more important than efficiency. 107 One goal of this document is to define the simplest set of rules for 108 building a TSCH-compliant network, at the necessary price of lesser 109 efficiency. Yet, this minimal mode of operation MAY also be used 110 during network bootstrap before any schedule is installed into the 111 network so nodes can self-organize and the management and 112 configuration information be distributed. In addition, the minimal 113 configuration MAY be used as a fall-back mode of operation, ensuring 114 connectivity of nodes in case that dynamic scheduling mechanisms fail 115 or are not available. The IEEE 802.15.4 specification provides a 116 mechanism whereby the details of slotframe length, timeslot timing, 117 and channel hopping pattern are communicated when a node time 118 synchronizes to the network [IEEE802154]. This document describes 119 specific settings for these parameters. 121 3. Terminology 123 This document uses terminology from the Terminology in IPv6 over the 124 TSCH mode of IEEE 802.15.4e [I-D.ietf-6tisch-terminology]. The 125 following concepts are used in this document: 127 CCA: Clear Channel Assessment. 129 4. Minimal Schedule Configuration 131 In order to form a network, a set of conventions need to be taken in 132 order to enable initial advertising of the network. Besides a set of 133 parameters need to be defined so joining nodes are configured so the 134 network can be formed and nodes interoperate. These set of rules and 135 default parameters conform a minimal configuration that nodes 136 implementing this specification MUST comply. The timeslot timing, 137 slotframe length, the number of active cells, their slot offset and 138 frequency offset and the purpose of the cells are mandatory 139 configurations for two nodes to communicate. The present document 140 defines those rules. Table 1 summarizes the main configuration 141 parameters for a "minimal" configuration. 143 A joining node learns the minimal configuration from the Enhanced 144 Beacon, except for the security keys. How the security keys are 145 obtained is out of the scope of this document. More details are 146 given in Section 10. 148 The present specification is independent of the actual physical layer 149 and it is only dependent on the IEEE 802.15.4 TSCH MAC layer 150 specification. 152 4.1. Slotframe 154 The slotframe, as defined in the Terminology in IPv6 over the TSCH 155 mode of IEEE 802.15.4e [I-D.ietf-6tisch-terminology], is an 156 abstraction of the link layer that defines a collection of timeslots 157 of equal length that repeats over time. In order to set up a minimal 158 TSCH network, nodes need to be time synchronized and configured to 159 use the same slotframe configuration so they can communicate. 160 Compliant nodes SHOULD obey to the following configuration as defined 161 in Table 1: 163 Table 1. Minimal configuration parameters. 165 +------------------------------------+--------------------------+ 166 | Property | Value | 167 +------------------------------------+--------------------------+ 168 | Number of timeslots per Slotframe | Variable | 169 | |(default 11) | 170 +------------------------------------+--------------------------+ 171 | Number of available frequencies | 16 | 172 +------------------------------------+--------------------------+ 173 | Number of scheduled cells | 1 (slotOffset 0x00) | 174 | (active) | (chOffset 0x00) | 175 | | (linkOption 0x0f) | 176 | | (macLinkType NORMAL) | 177 +------------------------------------+--------------------------+ 178 | Number of unscheduled cells | The remainder of the | 179 | (off) | slotframe | 180 +------------------------------------+--------------------------+ 181 | Number of MAC retransmissions (max)| 3 (4 transmission | 182 | | attempts) | 183 +------------------------------------+--------------------------+ 184 | Default timeslot timing | default | 185 | | macTimeslotTemplate | 186 | | template from | 187 | | IEEE802.15.4e | 188 | | macTimeslotTemplateId=0 | 189 +------------------------------------+--------------------------+ 190 | Enhanced Beacon Default Period | 10s | 191 | (referred as EB_PERIOD) | | 192 +------------------------------------+--------------------------+ 193 | Default Channel Hopping sequence | [5, 6, 12, 7, 15, | 194 | for the 2.4GHz OQPSK PHY | 4, 14, 11, 8, 0, | 195 | | 1, 2, 13, 3, 9, 10] | 196 +------------------------------------+--------------------------+ 198 The slotframe is composed of a configurable number of timeslots. The 199 number of timeslots in the slotframe is referred as slotframe length 200 [IEEE802154]. This document defines a default slotframe length of 11 201 slots. Choosing the number of time slots per slotframe needs to take 202 into account network requirements such as density, bandwidth per 203 node, etc. In the minimal configuration, there is only a single 204 active cell in the slotframe, used to transmit/receive both EBs and 205 data link-layer frames. The trade-off between bandwidth, latency and 206 energy consumption can be controlled by choosing a different 207 slotframe length. The active cell MAY be scheduled at any slotOffset 208 (default 0x00) and any channelOffset (default 0x00) within the 209 slotframe and this location MUST be announced in the EBs. EBs are 210 sent using this active cell to the link-layer broadcast address (and 211 are therefore not acknowledged). Data packets, as described in 212 Section 4.2, use the same active cell. Per IEEE 802.15.4 213 specification, data packets sent unicast on this cell are 214 acknowledged by the receiver [IEEE802154]. The remaining cells in 215 the slotframe are unscheduled, and MAY be used by other (dynamic) 216 scheduling solutions. Details about such dynamic scheduling solution 217 are out of scope of this document. Details about the usage of the 218 non scheduled cells are out of scope of this document. 220 The slotframe length determines the duty cycle of the network and 221 MUST be announced in the SlotFrame and Link IE of the EB. For 222 example, a network with a 0.99% duty cycle (as presented in Figure 1) 223 is composed of a slotframe of 101 timeslots, which includes 1 active 224 cell. 226 In a minimal configuration, a default timeslot duration set to 10ms 227 and its corresponding default timeslot internal timings defined by 228 the IEEE 802.15.4 specification SHOULD be used [IEEE802154]. The 229 timeslot timing is defined by the macTimeslotTemplate in the 230 IEEE802.15.4 specification. The use of the default 231 macTimeslotTemplate MUST be announced in the Enhanced Beacon (EB) by 232 using the Timeslot Information Element (IE) containing only the 233 default macTimeslotTemplateId. Other timeslot durations MAY be 234 supported and MUST be announced in the EBs. Joining nodes MUST learn 235 the configuration from the received EB. If a network uses a timeslot 236 duration different than the default (10ms), EBs MUST contain the 237 complete Timeslot IE and fill all the fields of the 238 macTimeslotTemplate as described in Section 4.4. Nodes not 239 supporting the default timeslot value SHOULD be clearly indicated. 241 Figure 1. Example schedule with 0.99% duty cycle. A slotframe of 242 101 timeslots and 16 channel offsets. Only one active cell at 243 slotOffset 0x00 and channelOffset 0x00. The remaining cells are 244 unscheduled. 246 Chan. +----------+----------+ +----------+ 247 Off.0 | TxRxS/EB | OFF | | OFF | 248 Chan. +----------+----------+ +----------+ 249 Off.1 | OFF | OFF | ... | OFF | 250 +----------+----------+ +----------+ 251 . 252 . 253 . 254 Chan. +----------+----------+ +----------+ 255 Off.15 | OFF | OFF | | OFF | 256 +----------+----------+ +----------+ 258 slotOffset 0 1 100 260 EB: Enhanced Beacon 261 Tx: Transmit 262 Rx: Receive 263 S: Shared 264 OFF: Unscheduled (MAY be used by a dynamic scheduling mechanism) 266 4.2. Cell Options 268 According to the IEEE 802.15.4 TSCH specification, each scheduled 269 cell is associated with a LinkOption bitmap [IEEE802154]. The active 270 cell in the minimal configuration MUST use a LinkOption with Value 271 0x0F. The bitmap in the active cell indicate that a node transmits 272 if there is a packet in its queue, listens otherwise as the 273 "Transmit" and "Receive" bits are set. A "Shared" bit is set and 274 therefore the back-off mechanism defined in the IEEE 802.15.4 275 specification is used to resolve contention when transmitting 276 [IEEE802154]. This results in "Slotted Aloha" behavior. The 277 "Timekeeping" flag is set so nodes initially joining the network can 278 maintain time synchronization to the advertising node using that 279 cell. Other time source neighbours MAY be selected using the routing 280 structure, e.g the DODAG structure of the network if RPL is used. 282 LinkOption bitmap setting for the active cell in the minimal 283 configuration slotframe: 285 b0 = Transmit = 1 (set) 287 b1 = Receive = 1 (set) 288 b2 = Shared = 1 (set) 290 b3 = Timekeeping = 1 (set) 292 b4-b7 = Reserved (clear) 294 In addition, the scheduled cell in the schedule is configured as a 295 Hard cell [RFC7554][I-D.ietf-6tisch-6top-interface] indicating that 296 cannot be moved or relocated by any dynamic scheduling mechanism. 297 Additional available cells MAY be scheduled by a dynamic scheduling 298 solution. The dynamic scheduling solution is out of scope, and this 299 specification does not make any restriction on the LinkOption bitmap 300 associated with those dynamically scheduled cells (i.e. they can be 301 Hard cells or Soft cells). 303 All remaining cells are unscheduled. In unscheduled cells, the nodes 304 SHOULD keep their radio off. 306 4.3. Retransmissions 308 The maximum number of link layer retransmissions is set to 3. For 309 packets which require an acknowledgement, if none are received after 310 a total of 4 attempts, the transmission is considered failed and the 311 link layer MUST notify the upper layer. Packets sent to the 312 broadcast MAC address (including EBs) are not acknowledged and 313 therefore not retransmitted. 315 4.4. Timeslot timing 317 Figure 2 shows an active timeslot in which a packet is sent from the 318 transmitter node (TX) to the receiver node (RX). A link-layer 319 acknowledgement is sent by the RX node to the TX node when the packet 320 is to be acknowledged. The TsTxOffset duration defines the instant 321 in the timeslot when the first bit after the Start of Frame Delimiter 322 (SFD) of the transmitted packet leaves the radio of the TX node. The 323 radio of the RX node is turned on tsRxWait/2 before that instant, and 324 listens for at least tsRxWait. This allows for a de-synchronization 325 between the two nodes of at most tsRxWait/2 in either direction 326 (early or late). The RX node needs to send the first bit after the 327 SFD of the MAC acknowledgement exactly TsTxAckDelay after the end of 328 the last byte of the received packet. TX's radio has to be turned on 329 tsAckWait/2 before that time, and keep listening for at least 330 tsAckWait. The TX node can perform a Clear Channel Assessment (CCA) 331 if required, this does not interfere with the scope of this document. 332 For the minimal configuration specified in this document, the use of 333 CCA is OPTIONAL. 335 Figure 2. Timeslot internal timing diagram 337 /---------------------- Timeslot Duration -----------------------/ 338 | / (5) / | 339 | | / tsRxAckDelay /| | | | 340 |-------------------+--------------+------------------+------+---| 341 TX |/(1)/ (2) / (3) /| TX frame | |RX ACK| | 342 |----+-------+------+--------------+------------------+------+---| 343 |/ tsTxOffset /| | | | | 344 | | | | | | 345 |-------------------+--------------+------------------+------+---| 346 RX | | | | RX frame | |TX ACK| | 347 |----------------+--+--+-----------+------------------+------+---| 348 | | | | | | | | 349 | / (4) / / tsTxAckDelay / | | 350 Start End 351 of of 352 Slot Slot 353 /(1)/ tsCCAOffset 354 /(2)/ tsCCA 355 /(3)/ tsRxTx 356 /(4)/ tsRxWait 357 /(5)/ tsAckWait 359 The timing parameters for the default macTimeslotTemplate 360 (macTimeslotTemplateId = 0) MUST be used when utilizing the default 361 timeslot duration. In this case, the TSCH Timeslot IE only 362 transports the macTimeslotTemplateId with value 0x00. If a timeslot 363 template other than the default is used, the EB MUST contain a 364 complete TimeSlot IE indicating the timeslot duration and the 365 corresponding timeslot timings. Note that in case of discrepancy 366 between the values in this document and the IEEE 802.15.4 367 specification [IEEE802154], the IEEE standard has precedence. 369 5. IEEE.802.15.4 Specific Header Fields and Considerations 371 The IEEE802.15.4 header of BEACON, DATA, ACKNOWLEDGEMENT, MAC COMMAND 372 frames MUST include the Sequence Number field, the Source Address 373 field and the Destination Address field. Frame Version field MUST be 374 set to 0b10 (Frame Version 2). 376 The PAN ID Compression bit in a BEACON frame MUST indicate that the 377 Source PAN ID is "Not Present" and the Destination PAN ID is 378 "Present". The source address field MUST be filled with an extended 379 address (64 bit) and this be indicated in the corresponding Frame 380 Control field. The Destination address field MUST be filled with a 381 short address (16bit) with a value of 0xffff to represent the 382 broadcast short address. 384 A Node aiming to join a network by receiving a properly formed BEACON 385 MUST use a PAN ID set to 0xffff in order meet the filtering rules in 386 the IEEE 802.15.4 specification [IEEE802154]. 388 When using DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types the source 389 and destination address fields MUST be filled with an extended 390 address (64 bit) and this be indicated in the corresponding Frame 391 Control field. The Destination PAN ID MUST be present, the Source 392 PAN ID MUST be elided. The PAN ID Compression field MUST indicate 393 that the Destination PAN ID is "Present" and the Source PAN ID is 394 "Not Present". According to Table 2a in the IEEE 802.15.4e 2012 395 specification document, this is accomplished by setting the PAN ID 396 Compression bit to 0b0 [IEEE802154-2012]. 398 When preparing the security header, the Absolute Sequence Number 399 (ASN) MUST be written into the Nonce in most significant byte first 400 (MSB) format as indicated in the IEEE 802.15.4 specification 401 [IEEE802154]. 403 6. Enhanced Beacons Configuration and Content 405 The IEEE 802.15.4 specification does not define how often EBs are 406 sent, nor their contents [IEEE802154]. EBs MUST NOT be used for time 407 synchronization. Time synchronization is achieved via 408 acknowledgements to normal packet traffic, and keepalives. For 409 additional reference see [RFC7554] where different time 410 synchronization approaches are summarized. 412 In a minimal TSCH configuration, a node SHOULD send an EB every 413 EB_PERIOD (default value = 10s). EBs are only authenticated and 414 neither Payload IEs nor the frame payload are encrypted. 416 EBs MUST be sent as per the IEEE 802.15.4 specification and MUST 417 carry the Information Elements (IEs) listed below [IEEE802154]. 418 Refer to Appendix A.1 for an example of the Information Elements 419 Header Content. 421 Synchronization IE: Contains synchronization information such as 422 ASN and Join Priority. The value of Join Priority is discussed in 423 Section 8.2. 425 TSCH Timeslot IE: Contains the timeslot template identifier. This 426 template is used to specify the internal timing of the timeslot. 427 This specification uses the default timeslot template as defined 428 in the IEEE 802.15.4 specification [IEEE802154]. In the case that 429 a non-default timeslot template is used, the IE Content MUST 430 follow the specification as defined in [IEEE802154] . Refer to 431 Appendix A.1 for an illustrative example of non default timeslot 432 template. 434 Channel Hopping IE: Contains the channel hopping template 435 identifier. This specification uses the default channel hopping 436 template, as defined in the IEEE 802.15.4 specification 437 [IEEE802154]. The default sequence for the 2.4GHz OQPSK PHY is 438 [5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 3, 9, 10] 439 [IEEE802154]. Note however that in case of discrepancy between 440 the values in this document and [IEEE802154], the IEEE standard 441 specification has preference. 443 SlotFrame and Link IE: Each node MUST indicate the schedule in 444 each EB through a SlotFrame and Link IE. This enables nodes which 445 implement the IEEE 802.15.4 specification [IEEE802154] to learn 446 the schedule used in the network as they join it. This draft 447 defines the use of a single cell set at the default channel offset 448 0x00, default timeslot offset 0x00 and with linkOption 0x0F (TX, 449 RX, SHARED bits set). A node SHOULD indicate the same information 450 in the "SlotFrame and Link IE" in the EBs it sends, than the 451 "SlotFrame and Link IE" information it has received in an EB. 453 7. Acknowledgement Frames 455 Unicast frames sent to a unicast MAC destination address MUST request 456 an acknowledgement. Each acknowledgement MUST contain an ACK/NACK 457 Time Correction IE. 459 8. Neighbour information 461 The IEEE 802.15.4 specification does not define how and when each 462 node in the network keeps information about its neighbours. A node 463 SHOULD keep at least the following information in a neighbour table: 465 8.1. Neighbour Table 467 The exact format of the neighbour table is implementation-specific. 468 Future version of the 6top Protocol [draft-wang-6tisch-sublayer] MAY 469 require those information and statistics. The neighbour table SHOULD 470 contain the following information for each neighbour: 472 Neighbour statistics: 474 numTx: number of transmitted packets to that neighbour 476 numTxAck: number of transmitted packets that have been 477 acknowledged by that neighbour 478 numRx: number of received packets from that neighbour 480 The EUI64 of the neighbour. 482 Timestamp of the last frame received from that neighbour. This 483 can be based on the ASN counter or any other time base. It can be 484 used to trigger a keep-alive message. 486 Routing metric such as the RPL rank of that neighbour. 488 A flag indicating whether this neighbour is a time source 489 neighbour. 491 Connectivity statistics (e.g., RSSI), which can be used to 492 determine the quality of the link. 494 In addition to that information, each node in a multihop topology and 495 implementing RPL has to be able to compute some RPL Objective 496 Function (OF), taking into account the neighbour and connectivity 497 statistics. An example RPL objective function is the OF Zero as 498 described in [RFC6552] and Section 11.1.1. 500 8.2. Time Source Neighbour Selection 502 Each node MUST select at least one Time Source Neighbour among the 503 nodes in its routing parent set (e.g the RPL parent set). When a 504 node joins a network, it has no routing information. To select its 505 time source neighbour, it uses the Join Priority field in the EB, as 506 described in the IEEE 802.15.4 specification [IEEE802154]. The Sync 507 IE contains the ASN and 1 Byte field named Join Priority. The Join 508 Priority of any node MUST be based on the routing metric of the 509 network and normalized to a value between 0 and 15. In case that the 510 network uses RPL, the Join Priority of any node MUST be equivalent to 511 the result of the function DAGRank(rank)-1. The Join Priority of the 512 DAG root MUST also be equivalent to DAGRank(rank)-1. According to 513 Section 11.1.1 the DAGRank(rank(0)) = 1 and therefore the 514 DAGRank(rank(0))-1 is 0 which is compliant with the requirement of 515 Join Priority = 0 imposed by the IEEE 802.15.4 specification 516 [IEEE802154]. A lower value of the Join Priority indicates higher 517 preference to connect to that device. 519 When a node joins the network, it MUST NOT send EBs before having 520 acquired a RPL rank. This applies to other routing protocols with 521 its corresponding routing metrics. This avoids inconsistencies in 522 the time synchronization structure. As soon as a node acquires 523 routing information (e.g RPL rank (see [RFC6550] and 524 Section 11.1.1)), it SHOULD send Enhanced Beacons including a Sync IE 525 with Join Priority field set as indicated above. If a node receives 526 EBs from different nodes with equal Join Priority, the time source 527 neighbour selection SHOULD be assessed by other metrics that can help 528 to determine the better connectivity link. Time source neighbour 529 hysteresis SHOULD be used, according to the rules defined in 530 Section 11.2.3. At any time, a node MUST maintain connectivity to at 531 least one time source neighbour. New time source neighbours MUST be 532 chosen among the neighbours in the routing parent set. 534 The decision for a node to select one Time Source Neighbour when 535 multiple EBs are received is implementation-specific. 537 For example, a node MAY wait until one EB from NUM_NEIGHBOURS_TO_WAIT 538 neighbours have been received to select the best Time Source 539 Neighbour. This condition MAY apply unless a second EB is not 540 received after MAX_EB_DELAY seconds. This avoids initial hysteresis 541 when selecting a first Time Source Neighbour. 543 Optionally, some form of hysteresis SHOULD be implemented to avoid 544 frequent changes in time source neighbours. 546 9. Queues and Priorities 548 The IEEE 802.15.4 specification [IEEE802154] does not define the use 549 of queues to handle upper layer data (either application or control 550 data from upper layers). A single queue with the following rules 551 SHOULD be used: 553 A node MUST not queue frames containing higher-layer packets until 554 the node has successfully joined a network. 556 Frames generated by the IEEE 802.15.4 layer are queued with higher 557 priority than frames containing higher-layer packets. 559 Frame types BEACON and COMMAND are queued with higher priority 560 than frame types DATA and ACK. 562 One entry in the queue is reserved at all times for frames of 563 types BEACON and COMMAND frames. 565 10. Security 567 As this document refers to the interaction between Layer 3 and Layer 568 2 protocols, this interaction MUST be secured by L2 security 569 mechanisms as defined by the IEEE 802.15.4 specification 570 [IEEE802154]. Two security mechanisms are considered, authentication 571 and encryption, authentication applies to all packet content while 572 encryption applies to header IEs and MAC payload. Key distribution 573 is out of scope of this document, but examples include pre-configured 574 keys at the nodes, shared keys among peers or well-known keys. 576 The present document assumes the existence of two cryptographic keys, 577 which can be pre-configured. One of the keys (K1) is used to 578 authenticate EBs. As defined in Section 6, EBs MUST be 579 authenticated, with no payload encryption. This facilitates logical 580 segregation of distinct networks. A second key (K2) is used to 581 authenticate DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types and 582 respective header IEs, with payload encryption. Depending on 583 security policy, these keys could be the same (i.e., K1=K2). 585 For early interoperability, K1 MAY be set to 36 54 69 53 43 48 20 6D 586 69 6E 69 6D 61 6C 31 35 ("6TiSCH minimal15"). 588 11. RPL on TSCH 590 In a multi-hop topology, the RPL routing protocol [RFC6550] MAY be 591 used. 593 11.1. RPL Objective Function Zero 595 If RPL is used, nodes MUST implement the RPL Objective Function Zero 596 (OF0) [RFC6552]. 598 11.1.1. Rank computation 600 The rank computation is described at [RFC6552], Section 4.1. 602 A node rank (see Figure 3 for an example) is computed by the 603 following equation: 605 R(N) = R(P) + rank_increment 607 rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease 609 Where: 611 R(N): Rank of the node. 613 R(P): Rank of the parent obtained as part of the DIO information. 615 rank_increment: The result of a function that determines the rank 616 increment. 618 Rf (rank_factor): A configurable factor that is used to multiply 619 the effect of the link properties in the rank_increment 620 computation. A minimal configuration SHOULD set rank_factor to 1. 622 Sp (step_of_rank): (strictly positive integer) - an intermediate 623 computation based on the link properties with a certain neighbour, 624 i.e., the Expected Transmission Count (ETX) which provides an 625 average of number of packet transmissions between two nodes. ETX 626 is defined in detail by [decouto03high] and [RFC6551]. The ETX is 627 computed as the inverse of the Packet Delivery Ratio (PDR), this 628 is the number of transmitted packets, divided by the number of 629 acknowledged packets to a certain node (e.g., ETX = numTX/ 630 numTXAck). An implementation MUST follow OF0's normalization 631 guidance as discussed in Section 1 and Section 4.1 of [RFC6552], 632 maintaining Sp between MINIMUM_STEP_OF_RANK of 1 to indicate a 633 great quality and MAXIMUM_STEP_OF_RANK of 9 to indicate a really 634 poor quality, with DEFAULT_STEP_OF_RANK indicating a normal, 635 average quality. Sp SHOULD be set to (3*ETX)-2. Candidate 636 parents with ETX greater than 3 SHOULD not be selected. 638 Sr (stretch_of_rank): (unsigned integer) - the maximum increment 639 to the step_of_rank of a preferred parent, to allow the selection 640 of an additional feasible successor. In this specification, 641 stretch_of_rank SHOULD be set to 0. 643 MinHopRankIncrease: the MinHopRankIncrease is set to the fixed 644 constant DEFAULT_MIN_HOP_RANK_INCREASE [RFC6550]. 645 DEFAULT_MIN_HOP_RANK_INCREASE has a value of 256. 647 DAGRank(rank): Equivalent to the floor of "rank" as defined by 648 [RFC6550]. DAGRank(rank) = floor(rank/MinHopRankIncrease). Nodes 649 compute its DAGRank(rank) using DAGRank(R(N)). 651 Figure 3. Rank computation scenario. 653 +-------+ 654 | P | R(P) 655 | | 656 +-------+ 657 | 658 | 659 +-------+ 660 | N | R(N)=R(P) + rank_increment 661 | | rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease 662 +-------+ Sp= (3*ETX) - 2 664 11.1.2. Rank computation Example 666 This section illustrates with an example the use of the Objective 667 Function Zero (refer to Figure 4 for specific details). Assume the 668 following parameters: 670 Rf = 1 672 Sp = (3*ETX)-2 674 Sr = 0 676 minHopRankIncrease = 256 (default in RPL) 678 ETX=(numTX/numTXAck) 680 r(n) = r(p) + rank_increment 682 rank_increment = (Rf*Sp + Sr) * minHopRankIncrease 684 rank_increment = ((3*numTx/numTxAck)-2)*minHopRankIncrease = 512 686 Figure 4. Rank computation example for 5 hop network where numTx=100 687 and numTxAck=75 for all nodes 689 +-------+ 690 | 0 | R(minHopRankIncrease) = 256 691 | | DAGRank(R(0)) = 1 692 +-------+ 693 | 694 | 695 +-------+ 696 | 1 | R(1)=R(0) + 512 = 768 697 | | DAGRank(R(1)) = 3 698 +-------+ 699 | 700 | 701 +-------+ 702 | 2 | R(2)=R(1) + 512 = 1280 703 | | DAGRank(R(2)) = 5 704 +-------+ 705 | 706 | 707 +-------+ 708 | 3 | R(3)=R(2) + 512 = 1792 709 | | DAGRank(R(3)) = 7 710 +-------+ 711 | 712 | 713 +-------+ 714 | 4 | R(4)=R(3) + 512 = 2304 715 | | DAGRank(R(4)) = 9 716 +-------+ 717 | 718 | 719 +-------+ 720 | 5 | R(5)=R(4) + 512 = 2816 721 | | DAGRank(R(5)) = 11 722 +-------+ 724 11.2. RPL Configuration 726 In addition to the Objective Function (OF), nodes in a multihop 727 network using RPL MUST indicate the preferred mode of operation using 728 the MOP field in DIO. Nodes not being able to operate in the 729 specified mode of operation MUST only join as leaf nodes. RPL 730 information and hop-by-hop extension headers MUST follow [RFC6553] 731 and [RFC6554] specification. In the case that the packets formed at 732 the LLN need to cross through intermediate routers, these MUST follow 733 the IP in IP encapsulation requirement specified by the [RFC6282] and 735 [RFC2460]. RPI and RH3 extension headers and inner IP headers MUST 736 be compressed according to [RFC6282]. 738 11.2.1. Mode of Operation 740 When RPL is used, nodes MUST support the non-storing ([RFC6550] 741 Section 9.7) mode of operation. The storing ([RFC6550] Section 9.8) 742 mode of operation SHOULD be supported by nodes with enough 743 capabilities. Non-storing mode of operation is the default mode that 744 a node selects when acting as a DAG root. 746 11.2.2. Trickle Timer 748 RPL signaling messages such as DIOs are sent using the Trickle 749 Algorithm [RFC6550] (Section 8.3.1) and [RFC6206]. For this 750 specification, the Trickle Timer MUST be used with the RPL defined 751 default values [RFC6550] (Section 8.3.1). For a description of the 752 Trickle timer operation see Section 4.2 on [RFC6206]. 754 11.2.3. Hysteresis 756 According to [RFC6552], [RFC6719] recommends the use of a boundary 757 value (PARENT_SWITCH_THRESHOLD) to avoid constant changes of parent 758 when ranks are compared. When evaluating a parent that belongs to a 759 smaller path cost than current minimum path, the candidate node is 760 selected as new parent only if the difference between the new path 761 and the current path is greater than the defined 762 PARENT_SWITCH_THRESHOLD.Otherwise the node MAY continue to use the 763 current preferred parent. As for [RFC6719] the 764 PARENT_SWITCH_THRESHOLD SHOULD be set to 192 when ETX metric is used 765 (in the form 128*ETX), the recommendation for this document is to use 766 PARENT_SWITCH_THRESHOLD equal to 640 if the metric being used is 767 (3*ETX-2)*minHopRankIncrease, or a proportional value. This 768 mechanism is suited to deal with parent hysteresis in both cases 769 including routing parent and time source neighbour selection. 771 12. Variable Values 773 Table 2 presents the values for the variables defined in this 774 document that SHOULD be used. 776 Table 2. Recommended variable values 778 +-------------------------+-------+ 779 | Variable | Value | 780 +-------------------------+-------+ 781 | MAX_EB_DELAY | 180 | 782 +-------------------------+-------+ 783 | NUM_NEIGHBOURS_TO_WAIT | 2 | 784 +-------------------------+-------+ 785 | PARENT_SWITCH_THRESHOLD | 640 | 786 +-------------------------+-------+ 788 13. IANA Considerations 790 This document requests no immediate action by IANA. 792 14. Acknowledgements 794 The authors would like to acknowledge the guidance and input provided 795 by Rene Struik, Pat Kinney, Michael Richardson, Tero Kivinen, Nicola 796 Accettura, Malisa Vucinic and for the exhaustive and detailed review 797 of the examples section to Simon Duquennoy, Guillaume Gaillard, 798 Tengfei Chang and Jonathan Munoz. Also our acknowledge to the 6TiSCH 799 Chairs Pascal Thubert and Thomas Watteyne for their guidance and 800 advice. 802 15. References 804 15.1. Normative References 806 [RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with 807 Hysteresis Objective Function", RFC 6719, 808 DOI 10.17487/RFC6719, September 2012, 809 . 811 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 812 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 813 DOI 10.17487/RFC6282, September 2011, 814 . 816 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 817 Routing Header for Source Routes with the Routing Protocol 818 for Low-Power and Lossy Networks (RPL)", RFC 6554, 819 DOI 10.17487/RFC6554, March 2012, 820 . 822 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 823 Power and Lossy Networks (RPL) Option for Carrying RPL 824 Information in Data-Plane Datagrams", RFC 6553, 825 DOI 10.17487/RFC6553, March 2012, 826 . 828 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 829 Protocol for Low-Power and Lossy Networks (RPL)", 830 RFC 6552, DOI 10.17487/RFC6552, March 2012, 831 . 833 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 834 and D. Barthel, "Routing Metrics Used for Path Calculation 835 in Low-Power and Lossy Networks", RFC 6551, 836 DOI 10.17487/RFC6551, March 2012, 837 . 839 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 840 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 841 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 842 Low-Power and Lossy Networks", RFC 6550, 843 DOI 10.17487/RFC6550, March 2012, 844 . 846 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 847 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 848 March 2011, . 850 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 851 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 852 December 1998, . 854 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 855 Requirement Levels", BCP 14, RFC 2119, 856 DOI 10.17487/RFC2119, March 1997, 857 . 859 [IEEE802154-2012] 860 IEEE standard for Information Technology, "IEEE standard 861 for Information Technology, IEEE std. 802.15.4, Part. 862 15.4: Wireless Medium Access Control (MAC) and Physical 863 Layer (PHY) Specifications for Low-Rate Wireless Personal 864 Area Networks, June 2011 as amended by IEEE std. 865 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 866 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 867 2012. 869 [IEEE802154] 870 IEEE standard for Information Technology, "IEEE standard 871 for Information Technology, IEEE std. 802.15.4, Part. 872 15.4: Wireless Medium Access Control (MAC) and Physical 873 Layer (PHY) Specifications for Low-Rate Wireless Personal 874 Area Networks". 876 [decouto03high] 877 De Couto, D., Aguayo, D., Bicket, J., and R. Morris, "A 878 High-Throughput Path Metric for Multi-Hop Wireless 879 Routing", ACM International Conference on Mobile Computing 880 and Networking (MobiCom) , June 2003. 882 15.2. Informative References 884 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 885 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 886 Internet of Things (IoT): Problem Statement", RFC 7554, 887 DOI 10.17487/RFC7554, May 2015, 888 . 890 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 891 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 892 2014, . 894 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 895 CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 896 2003, . 898 [I-D.ietf-6tisch-terminology] 899 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 900 "Terminology in IPv6 over the TSCH mode of IEEE 901 802.15.4e", draft-ietf-6tisch-terminology-06 (work in 902 progress), November 2015. 904 [I-D.ietf-6tisch-6top-interface] 905 Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer 906 (6top) Interface", draft-ietf-6tisch-6top-interface-04 907 (work in progress), July 2015. 909 15.3. External Informative References 911 [draft-wang-6tisch-sublayer] 912 IETF, "6TiSCH Operation Sublayer (6top) (work in 913 progress)", Nov 2015. 915 [CCM] National Institute of Standards and Technology, 916 "Recommendation for Block Cipher Modes of Operation: The 917 CCM Mode for Authentication and Confidentiality. SP 918 800-38C", May 2004. 920 [CCM-Star] 921 Struik, R., "Formal Specification of the CCM* Mode of 922 Operation, IEEE P802.15 Working Group for Wireless 923 Personal Area Networks (WPANs).", September 2005. 925 [OpenWSN] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., 926 Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: 927 a Standards-Based Low-Power Wireless Development 928 Environment", Transactions on Emerging Telecommunications 929 Technologies , August 2012. 931 Appendix A. Examples 933 Several examples are provided to illustrate the content of the 934 packets used by the minimal configuration as proposed by this 935 document. Each example follows the same structure presenting first a 936 schematic header diagram, then the LSB stream of bytes that conform 937 the header and finally a description of each of the IEs that form the 938 packet. The packet formats are specific for the [IEEE802154-2012] 939 revision and may vary in future releases of the IEEE standard. In 940 case of differences between the packet content presented in this 941 section and the [IEEE802154-2012], the latter has precedence. 943 The MAC header fields are described in a specific order. All field 944 formats in this examples are depicted in the order in which they are 945 transmitted by the PHY, from left to right, where the leftmost bit is 946 transmitted first in time. Bits within each field are numbered from 947 0 (leftmost and least significant) to k - 1 (rightmost and most 948 significant), where the length of the field is k bits. Fields that 949 are longer than a single octet are sent to the PHY in the order from 950 the octet containing the lowest numbered bits to the octet containing 951 the highest numbered bits, hence little endian ordering. 953 A.1. Example 1. Information Elements in EBs 955 Mandatory content for the EB as proposed by this draft. The example 956 uses a slotframe of 101 slots. Figure 5 represents schematically the 957 Header IE and Payload IE content of an EB. 959 Figure 5. Example of the IEs as proposed by this draft. 961 1 2 3 963 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 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | Len1 = 0 |Element ID=0x7e|0| Len2 = 26 |GrpId=1|1| 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Len3 = 6 |Sub ID = 0x1a|0| ASN 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 ASN | Join Priority | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | Len4 = 0x01 |Sub ID = 0x1c|0| TT ID = 0x00 | Len5 = 0x01 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 |ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A |Sub ID = 0x1b|0| 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | #SF = 0x01 | SF ID = 0x00 | SF LEN = 0x65 (101 slots) | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | #Links = 0x01 | SLOT OFFSET = 0x0000 | CHANNEL 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 OFF = 0x0000 |Link OPT = 0x0F| NO MAC PAYLOAD 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 Stream of bytes (in little-endian ordering) that derive 983 from the previous schematic header: 985 00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 01 1C 00 986 01 C8 00 0A 1B 01 00 65 00 01 00 00 00 00 0F 988 Description of the IE fields in the example: 990 #Header IE Header 991 Len1 = Header IE Length (0) 992 Element ID = 0x7e - termination IE indicating Payload IE coming next 993 Type 0 995 #Payload IE Header (MLME) 996 Len2 = Payload IE Len (26 Bytes) 997 GroupID = 1 MLME (Nested) 998 Type = 1 1000 #MLME-SubIE TSCH Synchronization 1001 Len3 = Length in bytes of the sub-IE payload (6 Bytes) 1002 SubID = 0x1a (MLME-SubIE TSCH Synchronization) 1003 Type = Short (0) 1004 ASN = Absolute Sequence Number (5 Bytes) 1005 Join Priority = 1 Byte 1007 #MLME-SubIE TSCH TimeSlot 1008 Len4 = Length in bytes of the sub-IE payload (1 Byte) 1009 SubID = 0x1c (MLME-SubIE Timeslot) 1010 Type = Short (0) 1011 TimeSlot template ID = 0x00 (default) 1013 #MLME-SubIE Ch. Hopping 1014 Len5 = Length in bytes of the sub-IE payload (1 Byte) 1015 SubID = 0x09 (MLME-SubIE Ch. Hopping) 1016 Type = Long (1) 1017 Channel Hopping Sequence ID = 0x00 (default) 1019 #MLME-SubIE TSCH Slotframe and Link 1020 Len6 = Length in bytes of the sub-IE payload (10 Bytes) 1021 SubID = 0x1b (MLME-SubIE TSCH Slotframe and Link) 1022 Type = Short (0) 1023 Number of slotframes = 0x01 1024 SlotFrame Handle = 0x00 1025 SlotFrame Size = 101 slots (0x65) 1026 Number of Links = 0x01 1027 Timeslot = 0x0000 (2B) 1028 Channel Offset = 0x0000 (2B) 1029 Link Option = 0x0F (tx,rx,shared,timekeeping) 1031 A.2. Example 2. Information Elements in EBs not using default timeslot 1032 template 1034 Using a non-default timeslot template in EBs. Timeslot length set to 1035 15ms instead of the 10ms default. Refer to Figure 6 for the specific 1036 IE fields. 1038 Figure 6. Example of a non-default timeslot template in EB. 1040 Schematic representation of the IE header in an EB: 1042 1 2 3 1043 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 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | Len1 = 0 |Element ID=0x7e|0| Len2 = 53 |GrpId=1|1| 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | Len3 = 6 |Sub ID = 0x1a|0| ASN 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 ASN | Join Priority | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Len4 = 25 |Sub ID = 0x1c|0| TT ID = 0x01 | macTsCCAOffset 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 = 2700 | macTsCCA = 128 | macTsTxOffset 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 = 3180 | macTsRxOffset = 1680 | macTsRxAckDelay 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 = 1200 | macTsTxAckDelay = 1500 | macTsRxWait 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 = 3300 | macTsAckWait = 600 | macTsRxTx 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 = 192 | macTsMaxAck = 2400 | macTsMaxTx 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 = 4256 | macTsTimeslotLength = 15000 | Len5 = 0x01 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 |ID=0x9 |1| CH ID = 0x00 | Len6 = 0x0A | ... 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 Stream of bytes (in little-endian ordering) that derive 1069 from the previous schematic header: 1071 00 3F 1A 88 06 1A ASN#0 ASN#1 ASN#2 ASN#3 ASN#4 JP 19 1C 01 8C 0A 80 1072 00 6C 0C 90 06 B0 04 DC 05 E4 0C 58 02 C0 00 60 09 A0 10 98 3A 01 C8 1073 00 0A ... 1075 Description of the IE fields in the example: 1077 #Header IE Header 1078 Len1 = Header IE Length (none) 1079 Element ID = 0x7e - termination IE indicating Payload IE coming next 1080 Type 0 1082 #Payload IE Header (MLME) 1083 Len2 = Payload IE Len (53 Bytes) 1084 GroupID = 1 MLME (Nested) 1085 Type = 1 1087 #MLME-SubIE TSCH Synchronization 1088 Len3 = Length in bytes of the sub-IE payload (6 Bytes) 1089 SubID = 0x1a (MLME-SubIE TSCH Synchronization) 1090 Type = Short (0) 1091 ASN = Absolute Sequence Number (5 Bytes) 1092 Join Priority = 1 Byte 1094 #MLME-SubIE TSCH TimeSlot 1095 Len4 = Length in bytes of the sub-IE payload (25 Bytes) 1096 SubID = 0x1c (MLME-SubIE Timeslot) 1097 Type = Short (0) 1098 TimeSlot template ID = 0x01 (non-default) 1100 Example timeslot timing using 15ms timeslot. 1101 +--------------------------------+------------+ 1102 | IEEE802.15.4 TSCH parameter | Value (us) | 1103 +--------------------------------+------------+ 1104 | tsCCAOffset | 2700 | 1105 +--------------------------------+------------+ 1106 | tsCCA | 128 | 1107 +--------------------------------+------------+ 1108 | tsTxOffset | 3180 | 1109 +--------------------------------+------------+ 1110 | tsRxOffset | 1680 | 1111 +--------------------------------+------------+ 1112 | tsRxAckDelay | 1200 | 1113 +--------------------------------+------------+ 1114 | tsTxAckDelay | 1500 | 1115 +--------------------------------+------------+ 1116 | tsRxWait | 3300 | 1117 +--------------------------------+------------+ 1118 | tsAckWait | 600 | 1119 +--------------------------------+------------+ 1120 | tsRxTx | 192 | 1121 +--------------------------------+------------+ 1122 | tsMaxAck | 2400 | 1123 +--------------------------------+------------+ 1124 | tsMaxTx | 4256 | 1125 +--------------------------------+------------+ 1126 | Timeslot duration | 15000 | 1127 +--------------------------------+------------+ 1129 #MLME-SubIE Ch. Hopping 1130 Len5 = Length in bytes of the sub-IE payload. (1 Byte) 1131 SubID = 0x09 (MLME-SubIE Ch. Hopping) 1132 Type = Long (1) 1133 Channel Hopping Sequence ID = 0x00 (default) 1135 A.3. Example 3. Information Elements in ACKs 1137 Acknowledgement packets carry the ACK/NACK Time Correction IE (Header 1138 IE). Figure 7 illustrates the IE format as specified in 1139 [IEEE802154-2012]. 1141 Figure 7. Acknowledgement packet IE content. 1143 1 2 3 1144 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 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 | Len1 = 2 |Element ID=0x1e|0| Time Sync Info | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 Stream of bytes (in little-endian ordering) that derive 1150 from the previous schematic header: 1152 02 0F TS#0 TS#1 1154 Description of the IE fields in the example: 1156 #Header IE Header 1157 Len1 = Header IE Length (2 Bytes) 1158 Element ID = 0x1e - ACK/NACK Time Correction IE 1159 Type 0 1161 A.4. Example 4. Auxiliary Security Header 1163 Figure 8 illustrates the content of the Auxiliary Security Header as 1164 mandated by this document, if security is enabled. Security Level in 1165 the example is set to ENC-MIC-32 (5). 1167 Figure 8. Example auxiliary security header. 1169 1 1170 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1172 |L = 5|M=1|1|1|0|Key Index = IDX| 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 Stream of bytes (in LSB format) that derive from the previous 1176 schematic header: 1178 6D IDX#0 1180 Description of the Security Auxiliary Header fields in the example: 1182 #Security Control (1 byte) 1183 L = Security Level ENC-MIC-32 (5) 1184 M = Key Identifier Mode (0x01) 1185 Frame Counter Suppression = 1 (omitting Frame Counter field) 1186 Frame Counter Size = 1 (construct Nonce from 5 byte ASN) 1187 Reserved = 0 1189 #Key Identifier (1 byte) 1190 Key Index = IDX (deployment-specific KeyIndex parameter that 1191 identifies the cryptographic key) 1193 Authors' Addresses 1195 Xavier Vilajosana (editor) 1196 Universitat Oberta de Catalunya 1197 156 Rambla Poblenou 1198 Barcelona, Catalonia 08018 1199 Spain 1201 Phone: +34 (646) 633 681 1202 Email: xvilajosana@uoc.edu 1204 Kris Pister 1205 University of California Berkeley 1206 490 Cory Hall 1207 Berkeley, California 94720 1208 USA 1210 Email: pister@eecs.berkeley.edu