One document matched: draft-ietf-6tisch-minimal-12.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes" ?>
<rfc category="std" ipr="trust200902" docName="draft-ietf-6tisch-minimal-12">
<front>
<title abbrev="6tisch-minimal">
Minimal 6TiSCH Configuration
</title>
<author initials="X" surname="Vilajosana" fullname="Xavier Vilajosana" role="editor">
<organization>Universitat Oberta de Catalunya</organization>
<address>
<postal>
<street>156 Rambla Poblenou</street>
<city>Barcelona</city>
<region>Catalonia</region>
<code>08018</code>
<country>Spain</country>
</postal>
<phone>+34 (646) 633 681</phone>
<email>xvilajosana@uoc.edu</email>
</address>
</author>
<author initials="K" surname="Pister" fullname="Kris Pister">
<organization>University of California Berkeley</organization>
<address>
<postal>
<street>490 Cory Hall</street>
<city>Berkeley</city>
<region>California</region>
<code>94720</code>
<country>USA</country>
</postal>
<email>pister@eecs.berkeley.edu</email>
</address>
</author>
<date/>
<area>Internet Area</area>
<workgroup>6TiSCH</workgroup>
<keyword>Draft</keyword>
<abstract>
<t>
This document describes the minimal set of rules to operate an IEEE 802.15.4 Timeslotted Channel Hopping (TSCH) network. This minimal mode of operation can be used during network bootstrap, as a fall-back mode of operation when no dynamic scheduling solution is available or functioning, or during early interoperability testing and development.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The nodes in a IEEE 802.15.4 TSCH network follow a communication schedule. The entity (centralized or decentralized) responsible for building and maintaining that schedule has 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 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 MAY 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, the minimal configuration MAY be used as a fall-back mode of operation, ensuring connectivity of nodes in case that dynamic scheduling mechanisms fail or are not available. <xref target="IEEE802154"/> provides a mechanism whereby the details of slotframe length, timeslot timing, and channel hopping pattern are communicated when a node synchronizes to the network. This document describes specific settings for these parameters. Nodes must broadcast properly-formed Enhanced Beacons to announce these values.
</t>
</section>
<section anchor="ref_for_later" title="Requirements Language">
<t>
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 <xref target="RFC2119">RFC 2119</xref>.
</t>
</section>
<section title="Minimal Schedule Configuration">
<t>
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.
</t>
<section title="Slotframe">
<t>
The slotframe, as defined in <xref target="I-D.ietf-6tisch-terminology"/>, is an abstraction of the link layer that defines a collection of time slots of equal length, 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 communicate. This document recommends the following slotframe configuration.
</t>
<figure>
<preamble>
Minimal configuration
</preamble>
<artwork>
+------------------------------------+----------------------+
| Property | Value |
+------------------------------------+----------------------+
| Number of time slots per Slotframe | Variable |
+------------------------------------+----------------------+
| Number of available frequencies | 16 |
+------------------------------------+----------------------+
| Number of scheduled cells | 1 (slotOffset 0) |
| | (macLinkType NORMAL) |
+------------------------------------+----------------------+
| Number of unscheduled cells | The remainder of the |
| | slotframe |
+------------------------------------+----------------------+
| Number of MAC retransmissions (max)| 3 (4 transmission |
| | attempts) |
+------------------------------------+----------------------+
</artwork>
</figure>
<t>
The slotframe is composed of a configurable number of time slots. Choosing the number of time slots per slotframe needs to take into account network requirements such as density, bandwidth per node, etc. In the minimal configuration, there is only a single active slot in slotframe, used to transmit/receive both EBs and data link-layer frames. The trade-off between bandwidth, latency and energy consumption can be controlled by choosing a different slotframe length. The active slot MAY be scheduled at the slotOffset 0x00 and channelOffset 0x00 and MUST be announced in the EBs. EBs are sent using this active slot to the link-layer broadcast address (and are therefore not acknowledged). Data packets, as described in <xref target="sec_cell_options"/>, use the same active slot. Per <xref target="IEEE802154"/>, data packets sent unicast on this cell are acknowledged by the receiver. The remaining cells in the slotframe are unscheduled, and MAY be used by other (dynamic) scheduling solutions. Details about such dynamic scheduling solution are out of scope of this document. Details about the usage of the non scheduled cells are out of scope of this document.
</t>
<t>
The slotframe length (expressed in number of time slots) is configurable. The length used determines the duty cycle of the network. For example, a network with a 0.99% duty cycle is composed of a slotframe of 101 slots, which includes 1 active slot. The present document RECOMMENDS the use of a default slot duration set to 10ms and its corresponding default timeslot timings defined by the <xref target="IEEE802154"/> macTimeslotTemplate. The use of the default macTimeslotTemplate MUST be announced in the EB by using the Timeslot IE containing only the default macTimeslotTemplateId. Other time slot durations MAY be supported and MUST be announced in the EBs. If one uses a timeslot duration different than 10ms, EBs MUST contain the complete TimeSlot IE as described in <xref target="sec_tstiming"/>. This document also recommends to clearly indicate nodes not supporting the default timeslot value.
</t>
<figure>
<preamble>
Example schedule with 0.99% duty cycle
</preamble>
<artwork>
Chan. +----------+----------+ +----------+
Off.0 | TxRxS/EB | OFF | | OFF |
Chan. +----------+----------+ +----------+
Off.1 | | | ... | |
+----------+----------+ +----------+
.
.
.
Chan. +----------+----------+ +----------+
Off.15 | | | | |
+----------+----------+ +----------+
slotOffset 0 1 100
EB: Enhanced Beacon
Tx: Transmit
Rx: Receive
S: Shared
OFF: Unscheduled (MAY be used by a dynamic scheduling mechanism)
</artwork>
</figure>
</section>
<section title="Cell Options" anchor="sec_cell_options">
<t>
Per <xref target="IEEE802154"/> TSCH, each scheduled cell has an associated bitmap of cell options, called LinkOptions. The scheduled cell in the minimal schedule is configured as a Hard cell <xref target="RFC7554"/><xref target="I-D.ietf-6tisch-6top-interface"/>. Additional available cells MAY be scheduled by a dynamic scheduling solution. The dynamic scheduling solution is out of scope, and this specification does not make any restriction on the LinkOption associated with those dynamically scheduled cells (i.e. they can be hard cells or soft cells).
</t>
<t>
The active cell is assigned the bitmap of cell options below. Because both the "Transmit" and "Receive" bits are set, a node transmits if there is a packet in its queue, listens otherwise. Because the "shared" bit is set, the back-off mechanism defined in <xref target="IEEE802154"/> is used to resolve contention when transmitting. This results in "Slotted Aloha" behavior. The "Timekeeping" flag is set so nodes initialy joining the network can maintin synchronization to the advertising node using that slot. Other time source neighbors are selected using the DODAG structure of the network (detailed below).
<list>
<t>b0 = Transmit = 1 (set)</t>
<t>b1 = Receive = 1 (set)</t>
<t>b2 = Shared = 1 (set)</t>
<t>b3 = Timekeeping = 1 (set)</t>
<t>b4-b7 = Reserved (clear)</t>
</list>
</t>
<t>
All remaining cells are unscheduled. In unscheduled cells, the nodes SHOULD keep their radio off. In a memory-efficient implementation, scheduled cells can be represented by a circular linked list. Unscheduled cells SHOULD NOT occupy any memory.
</t>
</section>
<section title="Retransmissions">
<t>
The maximum number of link layer retransmissions is set to 3. For packets which require an acknowledgment, if none is received after a total of 4 attempts, the transmission is considered failed and the link layer MUST notify the upper layer. Packets sent to the broadcast MAC address (including EBs) are not acknowledged and therefore not retransmitted.
</t>
</section>
<section title="Time Slot timing" anchor="sec_tstiming">
<t>
The figure below 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. As for a minimal configuration, CCA is OPTIONAL.
</t>
<figure>
<preamble>
Time slot internal timing diagram
</preamble>
<artwork>
/---------------------- Time Slot 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
</artwork>
</figure>
<t>
The timing parameters for the default macTimeslotTemplate (macTimeslotTemplateId = 0) MUST be used when utilizing the default time slot duration. In this case, the Timeslot IE only transports the macTimeslotTemplateId with value 0x00. If a timeslot template other than the default is used, the EB MUST contain a complete TimeSlot IE indicating the timeslot duration and the corresponding timeslot timings. Note however that in case of discrepancy between the values in this document and <xref target="IEEE802154"/>, the IEEE standard has precedence.
</t>
</section>
</section>
<section title="IEEE.802.15.4 Specific Header Fields and Considerations" anchor = "sec_154fields">
<t>
The IEEE802.15.4 header of BEACON, DATA, ACKNOWLEDGEMENT, MAC COMMAND frames MUST include the Sequence Number field, the Source Address field and the Destination Address field. Frame Version field MUST be set to 0b10 (Frame Version 2).
</t>
<t>
The PAN ID Compression bit in a BEACON frame MUST indicate that the Source PAN ID is "Not Present" and the Destination PAN ID is "Present". The source address field MUST be filled with an extended address (64 bit) and this be indicated in the corresponding Frame Control field. The Destination address field MUST be filled with a short address (16bit) with a value of 0xffff to represent the broadcast short address.
</t>
<t>
A Node aiming to join the network by receving a properly formed BEACON shall enter in a scan phase and shall store the value of macPANId and then set it to 0xffff for the duration of the scan in order to meet the filtering rules in <xref target="IEEE802154"/>.
</t>
<t>
When using DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types the source and destination address fields MUST be filled with an extended address (64 bit) and this be indicated in the corresponding Frame Control field. The Destination PAN ID MUST be present, the Source PAN ID MUST be elided. The PAN ID Compression field MUST indicate that the Destination PAN ID is "Present" and the Source PAN ID is "Not Present". With <xref target="IEEE802154-2012"/> and according to Table 2a, this is accomplished by setting the PAN ID Compression bit to 0b0.
</t>
<t>
When preparing the security header, the ASN MUST be written into the Nonce in MSB format (most significant byte first) as indicated in <xref target="IEEE802154"/>.
</t>
<t>
</t>
</section>
<section title="Enhanced Beacons Configuration and Content" anchor = "sec_EBconfig">
<t>
<xref target="IEEE802154"/> does not define how often EBs are sent, nor their contents. EBs MUST NOT in general be used for synchronization. Synchronization is achieved via acknowledgements to normal packet traffic, and keepalives. For a minimal TSCH configuration, a mote SHOULD send an EB every EB_PERIOD. For additional reference see <xref target="RFC7554"/> where different synchronization approaches are summarized. EBs are only authenticated and neither Payload IEs nor the frame payload are encrypted.
</t>
<t>
EBs MUST be sent as per <xref target="IEEE802154"/> and MUST carry the Information Elements (IEs) listed below. Refer to <xref target="sec_example1"/> for an example of the Information Elements Header Content.
</t>
<t>
<list>
<t>Synchronization IE: Contains synchronization information such as ASN and Join Priority. The value of Join Priority is discussed in <xref target="sec_timesource"/>. </t>
<t>TSCH Timeslot IE: Contains the timeslot template identifier. This specification uses the default timeslot template as defined in <xref target="IEEE802154"/>. In the case that a non-default timeslot template is used, the IE Content MUST follow the specification as defined in <xref target="IEEE802154"/> . Refer to <xref target="sec_example1"/> for an illustrative example of non default timeslot template. </t>
<t>Channel Hopping IE: Contains the channel hopping template identifier. This specification uses the default channel hopping template, as defined in <xref target="IEEE802154"/>. The default sequence for the 2.4GHz OQPSK PHY is [5, 6, 12, 7, 15, 4, 14, 11, 8, 0, 1, 2, 13, 3, 9, 10] <xref target="IEEE802154"/>. Note however that in case of discrepancy between the values in this document and <xref target="IEEE802154"/>, the IEEE standard specification has preference. </t>
<t>Frame and Link IE: Each node MUST indicate the schedule in each EB through a Frame and Link IE. This enables nodes which implement <xref target="IEEE802154"/> to learn the schedule used in the network as they join it. This draft defines the use of a single cell set at channel offset 0x00, slot offset 0x00 and with linkOption 0x0F (TX, RX, SHARED bits set).</t>
</list>
</t>
</section>
<section title="Acknowledgment">
<t>
Link-layer acknowledgment frames are built according to <xref target="IEEE802154"/>. Unicast frames sent to a unicast MAC destination address MUST request an acknowledgment. The sender node MUST set the ACK requested bit in the MAC header. The acknowledgment frame is of type ACK (frame type value 0b010). Each acknowledgment contains the following IE:
</t>
<t>
<list>
<t>ACK/NACK Time Correction IE: The ACK/NACK time correction IE carries the measured de-synchronization between the sender and the receiver. Refer to <xref target="sec_example3"/> for an example of the Header IE content. The possible values for the Time Synchronization Information and ACK status are described in <xref target="IEEE802154"/>.</t>
</list>
</t>
</section>
<section title="Neighbor information">
<t>
<xref target="IEEE802154"/> does not define how and when each node in the network keeps information about its neighbors. Keeping the following information in the neighbor table is RECOMMENDED:
</t>
<section title="Neighbor Table" anchor="sec_neighbour">
<t>
The exact format of the neighbor table is implementation-specific, but it SHOULD contain the following information for each neighbor:
<list>
<t>
Neighbor statistics:
<list>
<t>numTx: number of transmitted packets to that neighbor</t>
<t>numTxAck: number of transmitted packets that have been acknowledged by that neighbor</t>
<t>numRx: number of received packets from that neighbor</t>
</list>
</t>
<t>
The EUI64 of the neighbor.
</t>
<t>
Timestamp of the last frame 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.
</t>
<t>
RPL rank of that neighbor.
</t>
<t>
A flag indicating whether this neighbor is a time source neighbor.
</t>
<t>
Connectivity statistics (e.g., RSSI), which can be used to determine the quality of the link.
</t>
</list>
</t>
<t>
In addition to that information, each node has to be able to compute some RPL Objective Function (OF), taking into account the neighbor and connectivity statistics. An example RPL objective function is the OF Zero as described in <xref target="RFC6552"/> and <xref target="sec_rankcomp"/>.
</t>
</section>
<section title="Time Source Neighbor Selection" anchor="sec_timesource">
<t>
Each node MUST select at least one Time Source Neighbor among the nodes in its RPL routing parent set. When a node joins a network, it has no routing information. To select its time source neighbor, it uses the Join Priority field in the EB, as described in <xref target="IEEE802154"/>. The Sync IE contains the ASN and 1 Byte field named Join Priority. The Join Priority of any node MUST be equivalent to the result of the function DAGRank(rank)-1. The Join Priority of the DAG root is also equivalent to DAGRank(rank)-1. According to <xref target="sec_rankcomp"/> the DAGRank(rank(0)) = 1 and therefore the DAGRank(rank(0))-1 is 0 which is compliant with the requirement of Join Priority = 0 imposed by <xref target="IEEE802154"/>. A lower value of the Join Priority indicates higher preference to connect to that device. When a node joins the network, it MUST NOT send EBs before having acquired a RPL rank. This avoids routing loops and matches RPL topology with underlying mesh topology. As soon as a node acquires a RPL rank (see <xref target="RFC6550"/> and <xref target="sec_rankcomp"/>), it SHOULD send Enhanced Beacons including a Sync IE with Join Priority field set to DAGRank(rank)-1, where rank is the node's rank. If a node receives EBs from different nodes with equal Join Priority, the time source neighbor selection SHOULD be assessed by other metrics that can help determine the better connectivity link. Time source neighbor hysteresis SHOULD be used, according to the rules defined in <xref target="sec_hysteresis"/>. At any time, a node MUST maintain connectivity to at least one time source neighbor. New time source neighbors MUST be chosen among the neighbors in the RPL routing parent set.
</t>
<t>
The decision for a node to select one Time Source Neighbor when multiple EBs are received is implementation-specific.
</t>
<t>
For example, a node MAY wait until one EB from NUM_NEIGHBOURS_TO_WAIT neighbors have been received to select the best Time Source Neighbor. This condition MAY apply unless a second EB is not received after MAX_EB_DELAY seconds. This avoids initial hysteresis when selecting a first Time Source Neighbor.
</t>
<t>
Optionally, some form of hysteresis SHOULD be implemented to avoid frequent changes in time source neighbors.
</t>
</section>
</section>
<section title="Queues and Priorities">
<t>
<xref target="IEEE802154"/> does not define the use of queues to handle upper layer data (either application or control data from upper layers). The use of a single queue with the following rules is RECOMMENDED:
</t>
<t>
<list>
<t>
When the node is not synchronized to the network, higher layers are not able to insert packets into the queue.
</t>
<t>
Frames generated by the MAC layer (e.g., EBs and ACK) have a higher queuing priority than packets received from a higher layer.
</t>
<t>
Frame types Beacon and Command have a higher queuing priority than frame types Data and ACK.
</t>
<t>
One entry in the queue is reserved at all times for frames of types Beacon or Command frames.
</t>
</list>
</t>
</section>
<section title="Security">
<t>
As this document refers to the interaction between Layer 3 and Layer
2 protocols, this interaction MUST be secured by L2 security
mechanisms as defined by <xref target="IEEE802154"/>. Two security mechanisms are
considered, authentication and encryption, authentication applies to
all packet content while encryption applies to header IEs and MAC
payload. Key distribution is out of scope of this document, but
examples include pre-configured keys at the nodes, shared keys among
peers or well-known keys.
</t>
<t>
The present document assumes the existence of two cryptographic keys,
which can be pre-configured. One of the keys (K1) is used to
authenticate EBs. As defined in Section <xref target="sec_EBconfig"/>, EBs MUST be
authenticated, with no payload encryption. This facilitates logical
segregation of distinct networks. A second key (K2) is used to
authenticate DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types and
respective header IEs, with payload encryption. Depending on
security policy, these keys could be the same (i.e., K1=K2).
</t>
<t>
For early interoperability, K1 MAY be set to 36 54 69 53 43 48 20 6D 69 6E 69 6D 61 6C 31 35 ("6TiSCH minimal15").
</t>
</section>
<section title="RPL on TSCH">
<t>
Nodes in a multihop network MUST use the RPL routing protocol <xref target="RFC6550"/>.
</t>
<section title="RPL Objective Function Zero" anchor="rpl_obj_func">
<t>
Nodes in the multihop network MUST implement the RPL Objective Function Zero <xref target="RFC6552"/>.
</t>
<section title="Rank computation" anchor="sec_rankcomp">
<t>
The rank computation is described at <xref target="RFC6552"/>, Section 4.1. A node rank is computed by the following equation:
</t>
<t>
R(N) = R(P) + rank_increment
</t>
<t>
rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease
</t>
<t>
Where:
<list>
<t>
R(N): Rank of the node.
</t>
<t>
R(P): Rank of the parent obtained as part of the DIO information.
</t>
<t>
rank_increment: The result of a function that determines the rank increment.
</t>
<t>
Rf (rank_factor): A configurable factor that is used to multiply the effect of the link properties in the rank_increment computation. If none is configured, rank_factor of 1 is used. In this specification, a rank_factor of 1 SHOULD be used.
</t>
<t>
Sp (step_of_rank): (strictly positive integer) - an intermediate computation based on the link properties with a certain neighbor, 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 <xref target="decouto03high"/> and <xref target="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 <xref target="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. One RECOMMENDED way to achieve this in an interoperable fashion is to set Sp to (3*ETX)-2.
</t>
<t>
Sr (stretch_of_rank): (unsigned integer) - the maximum increment 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. In this specification, stretch_of_rank SHOULD be set to 0.
</t>
<t>
MinHopRankIncrease: the MinHopRankIncrease is set to the fixed constant DEFAULT_MIN_HOP_RANK_INCREASE <xref target="RFC6550"/>. DEFAULT_MIN_HOP_RANK_INCREASE has a value of 256.
</t>
<t>
DAGRank(rank): Equivalent to the floor of "rank" as defined by <xref target="RFC6550"/>. Specifically, when an Objective Function computes Rank, this is defined as an unsigned integer (i.e., a 16-bit value) Rank quantity. When the Rank is compared, e.g. to determine 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). Nodes compute its DAGRank(rank) using DAGRank(R(N)).
</t>
</list>
</t>
<figure>
<preamble>
Rank computation scenario
</preamble>
<artwork>
+-------+
| P | R(P)
| |
+-------+
|
|
+-------+
| N | R(N)=R(P) + rank_increment
| | rank_increment = (Rf*Sp + Sr) * MinHopRankIncrease
+-------+ Sp= (3*ETX) - 2
</artwork>
</figure>
</section>
<section title="Rank computation Example">
<t>
This section illustrates with an example the use of the Objective Function Zero. Assume the following parameters:
<list>
<t>Rf = 1 </t>
<t>Sp = (3*ETX)-2 </t>
<t>Sr = 0</t>
<t>minHopRankIncrease = 256 (default in RPL)</t>
<t>ETX=(numTX/numTXAck)</t>
<t>r(n) = r(p) + rank_increment</t>
<t>rank_increment = (Rf*Sp + Sr) * minHopRankIncrease</t>
<t>rank_increment = ((3*numTx/numTxAck)-2)*minHopRankIncrease = 512</t>
</list>
</t>
<figure>
<preamble>
Rank computation example for 5 hop network where numTx=100 and numTxAck=75 for all nodes
</preamble>
<artwork>
+-------+
| 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
+-------+
</artwork>
</figure>
</section>
</section>
<section title="RPL Configuration">
<t>
In addition to the Objective Function (OF), nodes in a multihop network MUST indicate the preferred mode of operation using the MOP field in DIO. Nodes not being able to operate in the specified mode of operation MUST only join as leaf nodes. RPL information and hop-by-hop extension headers MUST follow <xref target="RFC6553"/> and <xref target="RFC6554"/> specification. In the case that the packets formed at the LLN need to cross through intermediate routers, these MUST obey to the IP in IP encapsulation requirement specified by the <xref target="RFC6282"/> and <xref target="RFC2460"/>. RPI and RH3 extension headers and inner IP headers MUST be compressed according to <xref target="RFC6282"/>.
</t>
<section title="Mode of Operation">
<t>
Nodes implementing a minimal configuration and forming a multihop network, MUST support the non-storing (<xref target="RFC6550"/> Section 9.7) mode of operation. The storing (<xref target="RFC6550"/> Section 9.8) mode of operation SHOULD be supported by nodes with enough capabilities. Non-storing mode of operation is the default mode that a node selects when acting as a DAG root.
</t>
</section>
<section title="Trickle Timer">
<t>
RPL signaling messages such as DIOs are sent using the Trickle Algorithm <xref target="RFC6550"/> (Section 8.3.1) and <xref target="RFC6206"/>. For this specification, the Trickle Timer MUST be used with the RPL defined default values <xref target="RFC6550"/> (Section 8.3.1). For a description of the Trickle timer operation see Section 4.2 on <xref target="RFC6206"/>.
</t>
</section>
<section title="Hysteresis" anchor="sec_hysteresis">
<t>
According to <xref target="RFC6552"/>, <xref target="RFC6719"/> 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 <xref target="RFC6719"/> the recommended value for PARENT_SWITCH_THRESHOLD is 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 mechanism is suited to deal with parent hysteresis in both cases including routing parent and time source neighbor selection.
</t>
</section>
<section title="Variable Values" anchor="sec_variables">
<t>
The following table presents the RECOMMENDED values for the RPL-related variables defined in the previous section.
</t>
<figure>
<preamble>
Recommended variable values
</preamble>
<artwork>
+-------------------------+-------+
| Variable | Value |
+-------------------------+-------+
| EB_PERIOD | 10s |
+-------------------------+-------+
| MAX_EB_DELAY | 180 |
+-------------------------+-------+
| NUM_NEIGHBOURS_TO_WAIT | 2 |
+-------------------------+-------+
| PARENT_SWITCH_THRESHOLD | 640 |
+-------------------------+-------+
</artwork>
</figure>
</section>
</section>
</section>
<section title="Examples">
<t>
Several examples are provided to illustrate the content of the packets used by the minimal configuration as proposed by this document. Each example follows the same structure presenting first a schematic header diagram, then the LSB stream of bytes that conform the header and finally a description of each of the IEs the form the packet. The packet formats are specific for the <xref target="IEEE802154-2012"/> 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 <xref target="IEEE802154-2012"/>, the later has presedence.
</t>
<t>
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 by the PHY, from left to right, where the leftmost bit is transmitted first in time. 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, hence little endian ordering.
</t>
<section title="Example 1. Information Elements in EBs" anchor="sec_example1">
<t>
Mandatory content for the EB as proposed by this draft. The example uses a slotframe of 101 slots. The following figure represents schematically the Header IE and Payload IE content of an EB.
</t>
<figure>
<preamble>
</preamble>
<artwork>
Schematic representation of the IE header in an EB:
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 Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stream of bytes (in little-endian ordering) that derive
from the previous schematic header:
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 IE fields in the example:
#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 Priority = 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)
</artwork>
</figure>
</section>
<section title="Example 2. Information Elements in EBs not using default timeslot template" anchor="sec_example2">
<t>
Using a non-default timeslot template in EBs. Timeslot length set to 15ms instead of the 10ms default.
</t>
<figure>
<preamble>
</preamble>
<artwork>
Schematic representation of the IE header in an EB:
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 Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stream of bytes (in little-endian ordering) that derive
from the previous schematic header:
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 IE fields in the example:
#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 Priority = 1 Byte
#MLME-SubIE TSCH TimeSlot
Len4 = Lenght in bytes of the sub-IE payload (25 Bytes)
SubID = 0x1c (MLME-SubIE Timeslot)
Type = Short (0)
TimeSlot template ID = 0x01 (non-default)
Example timeslot timming using 15ms timeslot.
+--------------------------------+------------+
| 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 |
+--------------------------------+------------+
| Time Slot 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)
</artwork>
</figure>
</section>
<section title="Example 3. Information Elements in ACKs" anchor="sec_example3">
<t>
Acknowledgement packets carry the ACK/NACK Time Correction IE (Header IE). The following example illustrates the IE format as specified in <xref target="IEEE802154-2012"/>.
</t>
<figure>
<preamble>
</preamble>
<artwork>
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stream of bytes (in little-endian ordering) that derive
from the previous schematic header:
02 0F TS#0 TS#1
Description of the IE fields in the example:
#Header IE Header
Len1 = Header IE Length (2 Bytes)
Element ID = 0x1e - ACK/NACK Time Correction IE
Type 0
</artwork>
</figure>
</section>
<section title="Example 4. Auxiliary Security Header" anchor="sec_example4">
<t>
The example illustrates content of the Auxiliary Security Header as mandated by this document, if security is enabled. Security Level in the example is set to ENC-MIC-32 (5).
</t>
<figure>
<preamble>
</preamble>
<artwork>
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stream of bytes (in LSB format) that derive from the previous
schematic header:
6D IDX#0
Description of the 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)
</artwork>
</figure>
</section>
</section>
<section title="IANA Considerations">
<t>
This document requests no immediate action by IANA.
</t>
</section>
<section title="Acknowledgments">
<t>
The authors would like to acknowledge the guidance and input provided by Rene Struik, Pat Kinney, Michael Richardson, Tero Kivinen, Nicola Accettura, Malisa Vucinic and for the exhaustive and detailed review of the examples section to Simon Duquennoy, Guillaume Gaillard, Tengfei Chang and Jonathan Muñoz. Also our acknowledge to the 6TiSCH Chairs Pascal Thubert and Thomas Watteyne for their guideance and advice.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.6719'?>
<?rfc include='reference.RFC.6282'?>
<?rfc include='reference.RFC.6554'?>
<?rfc include='reference.RFC.6553'?>
<?rfc include='reference.RFC.6552'?>
<?rfc include='reference.RFC.6551'?>
<?rfc include='reference.RFC.6550'?>
<?rfc include='reference.RFC.6206'?>
<?rfc include='reference.RFC.2460'?>
<?rfc include='reference.RFC.2119'?>
<reference anchor="IEEE802154-2012">
<front>
<title>
IEEE standard for Information Technology, IEEE std.
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
and Physical Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks, June 2011 as amended by IEEE std.
802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
Networks (LR-WPANs) Amendment 1: MAC sublayer
</title>
<author>
<organization>IEEE standard for Information Technology</organization>
</author>
<date month="April" year="2012"/>
</front>
</reference>
<reference anchor="IEEE802154">
<front>
<title>
IEEE standard for Information Technology, IEEE std.
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
and Physical Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks
</title>
<author>
<organization>IEEE standard for Information Technology</organization>
</author>
<date month="" year=""/>
</front>
</reference>
<reference anchor="decouto03high">
<front>
<title>
A High-Throughput Path Metric for Multi-Hop Wireless Routing
</title>
<author initials="D." surname="De Couto" fullname="Douglas De Couto" />
<author initials="D." surname="Aguayo" fullname="Daniel Aguayo" />
<author initials="J." surname="Bicket" fullname="John Bicket" />
<author initials="R." surname="Morris" fullname="Robert Morris" />
<date month="June" year="2003"/>
</front>
<seriesInfo name="ACM International Conference on Mobile Computing and Networking (MobiCom)" value="" />
</reference>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.7554'?>
<?rfc include='reference.RFC.7102'?>
<?rfc include='reference.RFC.3610'?>
<?rfc include='reference.I-D.ietf-6tisch-terminology'?>
<?rfc include='reference.I-D.ietf-6tisch-6top-interface'?>
</references>
<references title="External Informative References">
<reference anchor="CCM">
<front>
<title>
Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality. SP 800-38C
</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="May" year="2004"/>
</front>
</reference>
<reference anchor="CCM-Star">
<front>
<title>
Formal Specification of the CCM* Mode of Operation, IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs).
</title>
<author initials="R." surname="Struik" fullname="René Struik" />
<date month="September" year="2005"/>
</front>
</reference>
<reference anchor="OpenWSN">
<front>
<title>OpenWSN: a Standards-Based Low-Power Wireless Development Environment</title>
<author initials="T." surname="Watteyne" fullname="Thomas Watteyne" />
<author initials="X." surname="Vilajosana" fullname="Xavier Vilajosana" />
<author initials="B." surname="Kerkez" fullname="Branko Kerkez" />
<author initials="F." surname="Chraim" fullname="Fabien Chraim" />
<author initials="K." surname="Weekly" fullname="Kevin Weekly" />
<author initials="Q." surname="Wang" fullname="Qin Wang" />
<author initials="S." surname="Glaser" fullname="Steven Glaser" />
<author initials="K." surname="Pister" fullname="Kris Pister" />
<date month="August" year="2012" />
</front>
<seriesInfo name="Transactions on Emerging Telecommunications Technologies" value="" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 06:59:26 |