One document matched: draft-ietf-6tisch-minimal-01.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes" ?>
<rfc category="info" ipr="trust200902" docName="draft-ietf-6tisch-minimal-01">
<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 a <xref target="IEEE802154e"/> Timeslotted Channel Hopping (TSCH) network. This minimal mode of operation can be used during network bootstrap, as a fallback mode of operation when no dynamic scheduling solution is available or functioning, or during early interoperability testing and development.
</t>
</abstract>
<note title="Requirements Language">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.
</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>
The nodes in a <xref target="IEEE802154e"/> TSCH network follow a communication schedule. The entity (centralized or decentralized) responsible for building and maintaining that schedule has very precise control over the trade-off between the network's latency, bandwidth, reliability and power consumption. During early interoperability testing and development, however, simplicity is often more important than efficiency. One goal of this document is to define the simplest set of rules for building a <xref target="IEEE802154e"/> TSCH-compliant network, at the necessary price of lesser efficiency. Yet, this minimal mode of operation can also be used during network bootstrap before any schedule is installed into the network so nodes can self-organize and the management and configuration information be distributed. In addition, as outlined in <xref target="I-D.phinney-roll-rpl-industrial-applicability"/>, the minimal configuration can be used as a fallback mode of operation, ensuring connectivity of nodes in case that dynamic scheduling mechanisms fail or are not available. <xref target="IEEE802154e"/> provides a mechanism whereby the details of slotframe length, timeslot timing, and channel hopping pattern are communicated at synchronization to a node, also Enhanced Beacons can be used to periodically update nodes information. This document describes specific settings for these parameters. Nodes MUST broadcast properly formed Enhanced Beacons to announce these values, but during initial implementation and debugging it may be convenient to preconfigure these values.
</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 exchange Enhanced Beacons (EBs) and data packets. 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 attempts to tx)|
+------------------------------------+----------------------+
</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 data and EBs, and receive information. 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 and are not acknowledged. Data packets, as described in <xref target="sec_cell_options"/> use the same active slot. Per <xref target="IEEE802154e"/>, data packets sent unicast on this cell are acknowledged by the receiver. The remaining cells are unscheduled, and MAY be used by dynamic scheduling solutions. Details about such dynamic scheduling solution are out of scope.
</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 1.01% 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="IEEE802154e"/> 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 clearly. If one uses a timeslot duration different than 10ms, it is RECOMMENDED to use a power-of-two of 10ms (i.e. 20ms, 40ms, 80ms, etc.). In this case, EBs MUST contain the complete TimeSlot IE as described in <xref target="sec_tstiming"/>.
</t>
<figure>
<preamble>
Example schedule with 1.01% duty cycle
</preamble>
<artwork>
Chan. +----------+----------+
Off.0 | TxRxS/EB | OFF |
Chan. +----------+----------+
Off.1 | | |
+----------+----------+
...
Chan. +----------+----------+
Off.15 | | |
+----------+----------+
0 1-100
EB: Enhanced Beacon
Tx: Transmit
Rx: Receive
S: Shared
OFF: Unscheduled (can be used by a dynamic scheduling mechanism)
</artwork>
</figure>
</section>
<section title="Cell Options" anchor="sec_cell_options">
<t>
Per the <xref target="IEEE802154e"/> TSCH, each scheduled cell has an associated bitmap of cell options, called LinkOption. The scheduled cell in the minimal schedule is configured as Hard cell <xref target="I-D.ietf-6tisch-tsch"/><xref target="I-D.ietf-6tisch-6top-interface"/>. Additional available cells can 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, and listens otherwise. Because the "shared" bit is set, the back-off mechanism defined in <xref target="IEEE802154e"/> is used to resolve contention. This results in "Slotted Aloha" behavior. The "Timekeeping" flag is never set, since the time source neighbor is 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 = 0 (clear)</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 acknowledgement, if none is received after a total of 4 attempts, the transmissions 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 acknowledgement 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 byte of the transmitted packet leaves the radio of the TX node. The radio of the RX node is turned on TsLongGT/2 before that instant, and listens for at least TsLongGT. This allows for a de-synchronization between the two node of at most TsLongGT. The RX node needs to send the first byte of the MAC acknowledgement exactly TsTxAckDelay after the end of the last byte of the received packet. TX's radio has to be turned on TsShortGT/2 before that time, and keep listening for at least TsShortGT.
</t>
<figure>
<preamble>
Time slot internal timing diagram
</preamble>
<artwork>
/------------------- Time Slot duration --------------------/
| /tsShortGT/ |
| | | | | |
|------------+-----------------+--------------+------+------|
TX | | TX-Packet | |RX Ack| |
|------------+-----------------+--------------+------+------|
|/tsTxOffset/| | | | |
| | | | | |
|------------+-----------------+--------------+------+------|
RX | | | | RX-Packet | |TX Ack| |
|---------+--+--+--------------+--------------+------+------|
| | | | | | | |
| /tsLongGT/ |/TsTxAckDelay/| | |
Start End
of of
Slot Slot
</artwork>
</figure>
<t>
A 10ms time slot length is the default value defined by <xref target="IEEE802154e"/>. Section 6.4.3.3.3 of the <xref target="IEEE802154e"/> defines a default macTimeslotTemplate, i.e. the different duration within the slot. These values are summarized in the following table and MUST be used when utilizing the default time slot duration. In this case, the Timeslot IE only transports the macTimeslotTemplateId (0x00) as the timing values are well-known. If a timeslot template other than the default is used, the EB MUST contain a complete TimeSlot IE, which requires 25 extra bytes.
</t>
<figure>
<preamble>
Default timeslot durations (per <xref target="IEEE802154e"/>, Section 6.4.3.3.3)
</preamble>
<artwork>
+--------------------------------+------------+
| IEEE802.15.4e TSCH parameter | Value |
+--------------------------------+------------+
| TsTxOffset | 2120us |
+--------------------------------+------------+
| TsLongGT | 2000us |
+--------------------------------+------------+
| TsTxAckDelay | 1000us |
+--------------------------------+------------+
| TsShortGT | 400us |
+--------------------------------+------------+
| Time Slot duration | 10000us |
+--------------------------------+------------+
</artwork>
</figure>
</section>
</section>
<section title="Enhanced Beacons Configuration and Content">
<t>
<xref target="IEEE802154e"/> does not define how often EBs are sent, not their contents. The choice of the duration between two EBs needs to take into account whether EBs are used as the only mechanism to synchronize devices, or whether a Keep-Alive (KA) mechanism is also used. For a minimal TSCH configuration, a mote SHOULD send an EB every EB_PERIOD. For additional reference see <xref target="I-D.ietf-6tisch-tsch"/> where different synchronization approaches are summarized.
</t>
<t>
EBs MUST be sent with the Beacon IEEE802.15.4 frame type and this EBs MUST carry the Information Elements (IEs) listed below.
</t>
<t>
The content of the IEs is presented here for completeness, however this information is redundant with <xref target="I-D.ietf-6tisch-tsch"/> and <xref target="IEEE802154e"/>.
</t>
<section title="Sync IE">
<t>
Contains synchronization information such as ASN and Join Priority. The value of Join Priority is discussed in <xref target="sec_timesource"/>.
</t>
<section title="IE Header">
<t>
<list>
<t>Length (b0-b7) = 0x06</t>
<t>Sub-ID (b8-b14) = 0x1a</t>
<t>Type (b15) = 0x00 (short)</t>
</list>
</t>
</section>
<section title="IE Content">
<t>
<list>
<t>ASN Byte 1 (b16-b23)</t>
<t>ASN Byte 2 (b24-b31)</t>
<t>ASN Byte 3 (b32-b39)</t>
<t>ASN Byte 4 (b40-b47)</t>
<t>ASN Byte 5 (b48-b55)</t>
<t>Join Priority (b56-b63)</t>
</list>
</t>
</section>
</section>
<section title="TSCH Timeslot IE">
<t>
Contains the timeslot template identifier. This specification uses the default timeslot template as defined in <xref target="IEEE802154e"/>, Section 5.2.4.15.
</t>
<section title="IE Header">
<t>
<list>
<t>Length (b0-b7) = 0x01</t>
<t>Sub-ID (b8-b14) = 0x1c</t>
<t>Type (b15) = 0x00 (short)</t>
</list>
</t>
</section>
<section title="IE Content">
<t>
<list>
<t>Timeslot Template ID (b0-b7) = 0x00 </t>
</list>
</t>
</section>
</section>
<section title="Channel Hopping IE">
<t>
Contains the channel hopping template identifier. This specification uses the default channel hopping template, as defined in <xref target="IEEE802154e"/>, Section 5.2.4.16.
</t>
<section title="IE Header">
<t>
<list>
<t>Length (b0-b7) = 0x01</t>
<t>Sub-ID (b8-b14) = 0x1d</t>
<t>Type (b15) = 0x00 (short)</t>
</list>
</t>
</section>
<section title="IE Content">
<t>
<list>
<t>Channel Hopping Template ID (b0-b7) = 0x00</t>
</list>
</t>
</section>
</section>
<section title="Frame and Link IE">
<t>
Each node MUST indicate the schedule in each EB through a Frame and Link IE. This enables nodes which implement <xref target="IEEE802154e"/> to configure their schedule as they join the network.
</t>
<section title="IE Header">
<t>
<list>
<t>Length (b0-b7) = variable </t>
<t>Sub-ID (b8-b14) = 0x1b </t>
<t>Type (b15) = 0x00 (short) </t>
</list>
</t>
</section>
<section title="IE Content">
<t>
<list>
<t> # Slotframes (b16-b23) = 0x01</t>
<t> Slotframe ID (b24-b31) = 0x01</t>
<t> Size Slotframe (b32-b47) = variable </t>
<t> # Links (b48-b55) = 0x01</t>
</list>
</t>
<t>
For the active cell in the minimal schedule:
<list>
<t>Channel Offset (2B) = 0x00</t>
<t>Slot Number (2B) = 0x00</t>
<t>LinkOption (1B) = as described in <xref target="sec_cell_options"/></t>
</list>
</t>
</section>
</section>
</section>
<section title="Acknowledgment">
<t>
Link-layer acknowledgment frames are built according to <xref target="IEEE802154e"/>. Data frames and command frames sent to a unicast MAC destination address request an acknowledgment. The acknowledgment frame is of type ACK (0x10). Each acknowledgment contains the following IE:
</t>
<section title="ACK/NACK Time Correction IE">
<t>
The ACK/NACK time correction IE carries the measured de-synchronization between the sender and the receiver.
</t>
<section title="IE Header">
<t>
<list>
<t>Length (b0-b7) = 0x02</t>
<t>Sub-ID (b8-b14) = 0x1e</t>
<t>Type (b15) = 0x00 (short)</t>
</list>
</t>
</section>
<section title="IE Content">
<t>
<list>
<t>Time Synchronization Information and ACK status (b16-b31)</t>
</list>
</t>
<t>
The possible values for the Time Synchronization Information and ACK status are described in <xref target="IEEE802154e"/> and reproduced in the following table:
</t>
<figure>
<preamble>
ACK status and Time Synchronization Information.
</preamble>
<artwork>
+-----------------------------------+-----------------+
| ACK Status | Value |
+-----------------------------------+-----------------+
| ACK with positive time correction | 0x0000 - 0x07ff |
+-----------------------------------+-----------------+
| ACK with negative time correction | 0x0800 - 0x0fff |
+-----------------------------------+-----------------+
| NACK with positive time correction| 0x8000 - 0x87ff |
+-----------------------------------+-----------------+
| NACK with negative time correction| 0x8800 - 0x8fff |
+-----------------------------------+-----------------+
</artwork>
</figure>
</section>
</section>
</section>
<section title="Neighbor information">
<t>
<xref target="IEEE802154e"/> does not define how and when each node in the network keeps information about its neighbors. This document recommends to keep the following information in the neighbor table:
</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 when that neighbor was heard for the last time. This can be based on the ASN counter or any other time base. Can be used to trigger a keep-alive message.
</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 Section 5.2.4.13 and Table 52b of <xref target="IEEE802154e"/>. The Sync IE contains the ASN and 1 Byte field named Join Priority. The Join Priority of any node is equivalent to the result of the function DAGRank(rank) as defined by <xref target="RFC6550"/> and <xref target="sec_rankcomp"/>. The Join Priority of the DAG root is zero, i.e., EBs sent from the DAG root are sent with Join Priority equal to 0. A lower value of the Join Priority indicates that the device is the preferred one to connect to. When a node joins the network, 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), 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"/>. If connectivity to the time source neighbor is lost, a new time source neighbor 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 open to implementers. 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="IEEE802154e"/> does not define the use of queues to handle upper layer data (either application or control data from upper layers). This document recommends the use of a single queue with the following rules:
</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 priority than packets received from a higher layer.
</t>
<t>
IEEE802.15.4 frames of types Beacon and Command have a higher priority than IEEE802.15.4 frames of types Data and ACK.
</t>
<t>
One entry in the queue is reserved at all times for an IEEE802.15.4 frames of types Beacon or Command frames.
</t>
</list>
</t>
</section>
<section title="RPL on TSCH">
<t>
Nodes in the 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 network MUST use the RPL routing protocol <xref target="RFC6550"/> and 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. Briefly, a node rank is computed by the following equation:
</t>
<t>
R(N) = R(P) + rank_increase
</t>
<t>
rank_increase = (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_increase: 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_increase computation. If none is configured, rank_factor of 1 is used. In this specification, a rank_factor of 1 MUST be used.
</t>
<t>
Sp (step_of_rank): (strictly positive integer) - an intermediate computation based on the link properties with a certain neighbor. In this specification, 2*ETX (Expected Transmissions) as defined by <xref target="decouti03high"/> and <xref target="RFC6551"/> MUST be used. The ETX is computed as the inverse of the Packet Delivery Ratio (PDR), and MAY be computed as the number of acknowledged packets, divided by the number of transmitted packets to a certain node. E.g: Sp=2*numTX/numTXAck
</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 MUST 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 (Rf*Sp + Sr) 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)
</t>
</list>
</t>
<figure>
<preamble>
Rank computation scenario
</preamble>
<artwork>
+-------+
| P | R(P)
| |
+-------+
|
|
|
+-------+
| N | R(N)=R(P) + rank_increase
| | rank_increase = (Rf*Sp + Sr) * MinHopRankIncrease
+-------+ Sp=2*ETX
</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 = 2* ETX</t>
<t>Sr = 0</t>
<t>minHopRankIncrease = 256 (default in RPL)</t>
<t>ETX=(numTX/numTXAck)</t>
<t>r(n) = r(p) + rank_increase</t>
<t>rank_increase = (Rf*Sp + Sr) * minHopRankIncrease</t>
<t>rank_increase = 512*numTx/numTxACK</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(0)=0
| | DAGRank(R(0)) = 0
+-------+
|
|
+-------+
| 1 | R(1)=R(0)+683=683
| | DAGRank(R(1)) = 2
+-------+
|
|
+-------+
| 2 | R(2)=R(1)+683=1366
| | DAGRank(R(2)) = 5
+-------+
|
|
+-------+
| 3 | R(3)=R(2)+683=2049
| | DAGRank(R(3)) = 8
+-------+
|
|
+-------+
| 4 | R(4)=R(3)+683=2732
| | DAGRank(R(4)) = 10
+-------+
|
|
+-------+
| 5 | R(5)=R(4)+683=3415
| | DAGRank(R(5)) = 13
+-------+
</artwork>
</figure>
</section>
</section>
<section title="RPL Configuration">
<t>
In addition to the Objective Function (OF), a minimal configuration for RPL should indicate the preferred mode of operation and trickle timer operation so different RPL implementations can inter-operate. RPL information SHOULD be transported in the flow label in the LLN as defined in <xref target="I-D.thubert-6man-flow-label-for-rpl"/>
</t>
<section title="Mode of Operation">
<t>
For downstream route maintenance, in a minimal configuration, RPL SHOULD be set to operate in the Non-Storing mode as described by <xref target="RFC6550"/> Section 9.7. Storing mode (<xref target="RFC6550"/> Section 9.8) MAY be supported in less constrained devices.
</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, the recommendation for this document is to use PARENT_SWITCH_THRESHOLD equal to 394 as the metric being used is 2*ETX. This is mechanism is suited to deal with parent hysteresis in both cases routing parent and time source neighbor selection.
</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 | 394 |
+-------------------------+----------+
</artwork>
</figure>
</section>
</section>
</section>
<section title="Acknowledgements">
<t>
The authors would like to acknowledge the guidance and input provided by the 6TiSCH Chairs Pascal Thubert and Thomas Watteyne.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.6206'?>
<?rfc include='reference.RFC.6550'?>
<?rfc include='reference.RFC.6551'?>
<?rfc include='reference.RFC.6552'?>
<?rfc include='reference.RFC.6719'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-6tisch-tsch'?>
<?rfc include='reference.I-D.ietf-6tisch-architecture'?>
<?rfc include='reference.I-D.ietf-6tisch-terminology'?>
<?rfc include='reference.I-D.ietf-6tisch-6top-interface'?>
<?rfc include='reference.I-D.richardson-6tisch-security-architecture'?>
<?rfc include='reference.I-D.ietf-roll-terminology'?>
<?rfc include='reference.I-D.phinney-roll-rpl-industrial-applicability'?>
<?rfc include='reference.I-D.thubert-6man-flow-label-for-rpl'?>
</references>
<references title="External Informative References">
<reference anchor="IEEE802154e">
<front>
<title>
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 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="June" year="2011"/>
</front>
</reference>
<reference anchor="decouti03high">
<front>
<title>
A High-Throughput Path Metric for Multi-Hop Wireless Routing", MobiCom '03, The 9th ACM International Conference on Mobile Computing and Networking, San Diego, California
</title>
<author>
<organization>De Couto, D., Aguayo, D., Bicket, J., and R. Morris</organization>
</author>
<date month="June" year="2003"/>
</front>
</reference>
<reference anchor="OpenWSN" target="http://www.openwsn.org/">
<front>
<title>Berkeley's OpenWSN Project Homepage</title>
<author/>
<date/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 20:32:34 |