One document matched: draft-vilajosana-6tsch-basic-00.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-vilajosana-6tsch-basic-00">
<front>
<title abbrev="6tsch-basic">
Minimal 6TSCH 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>
<date month="June" year="2013" />
<workgroup>6TSCH</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. These rules can be used during early interoperability testing and development, when the centralized and distributed solutions developed by the 6TSCH group are not fully implemented yet, or otherwise not available.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The nodes in a <xref target="IEEE802154e"/> TSCH network follow a communication schedule. The entity 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. The goal of this document is to defines the simplest set of rules for building a <xref target="IEEE802154e"/> TSCH-compliant network, at the necessary price of lesser efficiency.
</t>
</section>
<section title="Schedule">
<t>
In order to form a network, a minimum schedule configuration is required so nodes can advertise the presence of the network, and exchange data.
</t>
<section title="Slotframe">
<t>
The slotframe, as defined by <xref target="I-D.draft-palattella-6tsch-terminology"/>, is an abstraction of the MAC layer that defines a collection of time slots of equal length and priority, and which repeats over time. In order to set up a minimal TSCH network, nodes need to use the same slotframe configuration so they can exchange Enhanced Beacons (EBs) and data packets. This document recommends the following slotframe configuration.
</t>
<figure>
<preamble>
Basic configuration configuration
</preamble>
<artwork>
+---------------------------------+----------------------+
| Property | Value |
+---------------------------------+----------------------+
| Number of time slots | 101 |
+---------------------------------+----------------------+
| Number of available channels | 16 |
+---------------------------------+----------------------+
| Number of EBs slots | 1 (slotOffset 0) |
+---------------------------------+----------------------+
| Number of active cells | 5 (slotOffsets |
| | 1,2,3,4,5) |
+---------------------------------+----------------------+
| Number of inactive slots | 95 (from slotOffset |
| | 6 to 100) |
+---------------------------------+----------------------+
| Number of MAC retransmissions | 3 |
+---------------------------------+----------------------+
| Time Slot duration | 15ms |
+---------------------------------+----------------------+
</artwork>
</figure>
<t>
This schedule is hard-coded in each node. The slotframe is composed of 101 time slots, the first slot in the slotframe is used to send Enhanced Beacons to announce the presence of the network. These EBs are not acknowledged. Five cells are scheduled for exchangeing data packets, as described in <xref target="sec_cell_options"/>. These cells are scheduled at slotOffset 1 to 5, and channeOffset 0. Per the IEEE802.15.4e TSCH standard, data packets sent on these cells to a unicast MAC address are acknowledged by the receiver. The 95 remaining cells are inactive, i.e. the radio of the nodes remains off.
</t>
<figure>
<preamble>
Basic schedule overview
</preamble>
<artwork>
+-----+-----+-----+-----+-----+-----+-----+ +-----+
chan.Off. 0 | EB |TxRxS|TxRxS|TxRxS|TxRxS|TxRxS| OFF | ... | OFF |
+-----+-----+-----+-----+-----+-----+-----+ +-----+
chan.Off. 1 | | | | | | | | ... | |
+-----+-----+-----+-----+-----+-----+-----+ +-----+
...
+-----+-----+-----+-----+-----+-----+-----+ +-----+
chan.Off. 15 | | | | | | | | ... | |
+-----+-----+-----+-----+-----+-----+-----+ +-----+
0 1 2 3 4 5 6 100
</artwork>
</figure>
</section>
<section title="Cells and cells Options" anchor="sec_cell_options">
<t>
Per the <xref target="IEEE802154e"/> TSCH standard, each active cell is assigned a bitmap of cell options.
</t>
<t>
The EB cell is assigned the following bitmap of cell options:
<list>
<t>b0 = Transmit = 1 (set)</t>
<t>b1 = Receive = 0 (clear)</t>
<t>b2 = Shared = 0 (clear)</t>
<t>b3 = Timekeeping = 0 (clear)</t>
<t>b4 = Hard = 1 (set)</t>
<t>b5-b7 = Reserved (clear)</t>
</list>
</t>
<t>
The data cells are assigned the bitmap of cell options below. This results in "Slotted Aloha" behavior. Because both the "Transmit" and "Receive" bits are set, the either transmits, or listens when it has nothing to transmit. Because the "shared" bit it set, it uses the backoff mechanism defined in <xref target="IEEE802154e"/> TSCH to resolve collisions.
<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 = Hard = 1 (set)</t>
<t>b5-b7 = Reserved (clear)</t>
</list>
</t>
<t>
All remaining cells are inactive, and so the nodes' radios remain off. In a memory efficient implementation, active cells could be represented by a circular linked list. Inactive cells should not occupy any memory.
</t>
</section>
<section title="Retransmissions">
<t>
The maximum number of MAC-layer retransmissions is set to 3. For packets which require an acknowledgement, if none is received after a total of 4 attempts, the transmissions is considered failed at the MAC layer, and the upper layer needs to be notified. Packets sent to the broadcast MAC address (including EBs) are not acknowledged and therefore not retransmitted.
</t>
</section>
<section title="Time Slot timming">
<t>
The figure below shows an active timeslot in which a packet is sent from the transmitter node (TX) to the receiver node (RX), and a MAC acknowledgement is sent back from the RX to the TX node, indicating successful reception. The TsTxOffset duration defines the instant in the timeslot when the first byte of the transmitted packet leaves the radio of the TX node. The radio of the RX node is turned on TsLongGT/2 before that instant, and listen for at least TsLongGT. This allows for a de-synchronization between the two node of at most TsLongGT. The RX node needs to send the first byte of the MAC acknowledgement exactly TsTxAckDelay after the end of the last byte of the received packet. TX's radio has to be turned on TsShortGT/2 before that time, and keep listening for at least TsShortGT.
</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>
<xref target="IEEE802154e"/> does not define the different durations of a time slot. It does allow those durations to be sent in the EBs (through a TimeSlot IE), but for simplicity, this document recommends to hard-code the different durations to the values listed below.
</t>
<figure>
<preamble>
Timeslot durations
</preamble>
<artwork>
+---------------------------------+------------------+
| IEEE802.15.4e TSCH duration | Value |
+---------------------------------+------------------+
| TsTxOffset | 4000us |
+---------------------------------+------------------+
| TsLongGT | 1300us |
+---------------------------------+------------------+
| TsTxAckDelay | 4606us |
+---------------------------------+------------------+
| TsShortGT | 500us |
+---------------------------------+------------------+
| Time Slot duration | 15000us |
+---------------------------------+------------------+
</artwork>
</figure>
</section>
</section>
<section title="Enhanced Beacons Configuration and Content">
<t>
<xref target="IEEE802154e"/> does not define when EBs are sent. The choice of the duration between two EBs needs to take into account whether EBs are used as the only mechanism to synchronize devices, or whether a Keep-Alive (KA) mechanism is used in parallel. For a simplest TSCH configuration, it is recommended to sent EBs at least once every 10s.
</t>
<t>
EBs must be sent with the Beacon IEEE802.15.4 frame type and this document recommends that they carry the following Information Elements (IEs):
</t>
<section title="Sync IE">
<t>
Contains synchronization information such as ASN and join priority.
</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="Frame and Link IE">
<t>
Although the schedule is hard-coded in each node, this document recommends to indicate the schedule in each EB through a Frame and Link IE. This enables nodes which implement <xref target="IEEE802154e"/> fully to be able to configure their schedule as they join the network, and interact with nodes using a hard-coded schedule.
</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) = 0x65</t>
<t> # Links (b48-b55) = 0x06</t>
</list>
</t>
<t>
For each link in the basic schedule:
<list>
<t>Channel Offset (2B) = 0x00</t>
<t>Slot Number (2B) = from (0x00 to 0x05)</t>
<t>LinkOption (1B) = as described in <xref target="sec_cell_options"/></t>
</list>
</t>
</section>
</section>
</section>
<section title="Acknowledgement">
<t>
MAC-layer acknowledgement frames are built according to <xref target="IEEE802154e"/>. Data frames and command frames sent to a unicast MAC destination address request an acknowledged. The acknowledgement frame is of type ACK (0x10). Each acknowledgement contains the following IE:
</t>
<section title="ACK/NACK Time Correction IE">
<t>
The ACK/NACK time correction IE is used to carry the measured desynchronization 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 Synch Info and ACK status (b16-b31)</t>
</list>
</t>
<t>
The possible values for the Time Synch Info and ACK status are described in the following table:
</t>
<figure>
<preamble>
ACK status and Time Synch 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 when information is be kept at each node about each neighbor. This document recommends to keep the following information in the neighbor table:
</t>
<section title="Neighbor Table">
<t>
The exact format of the neighbor table is implementation-specific, but it should at least contain the following information, for each neighbor:
<list>
<t>
Neighbor statistics:
<list>
<t>number of transmitted packets to that neighbor</t>
<t>number of transmitted packets that have been acknowledged by that neighbor</t>
<t>number of received packets from that neighbor</t>
<t>number of received packets that have been acknowledged for that neighbor</t>
</list>
</t>
<t>
Neighbor address.
</t>
<t>
ASN when that neighbor was last heard. This can be used to trigger a keep-alive.
</t>
<t>
RPL rank of that neighbor.
</t>
<t>
A flag which indicates whether this neighbor is a time source neighbor.
</t>
<t>
Connectivity statistics (RSSI, LQI, etc), which can be used to help determine the quality of the link.
</t>
</list>
</t>
<t>
In addition of 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 ETX.
</t>
</section>
<section title="Time Parent Selection">
<t>
Each node selects a time parent amongst its known neighbors. When a node joins a network, it has no routing information yet. Its (possibly temporary) time parent is the node it can hear "best", for example based on RSSI measurements of the EBs it received. After having acquired a RPL rank, the RPL routing parents should also be IEEE802.15.4e time source neighbors.
</t>
<t>
Optionally, a node can choose to use an counter to avoid frequent changes in time source neighbor selection. Based on some thresholds (on RSSI for example), if the quality of the link with time parent changes over or below the thresholds for a certain number of times (e.g. 3), the instability counter is incremented and another time parent is selected.
</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 to use 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>
Lower-layer packets have a higher priority that 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 a IEEE802.15.4 frames of types Beacon or Command frames.
</t>
</list>
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.6550'?>
<?rfc include='reference.I-D.ietf-roll-terminology.xml'?>
<?rfc include='reference.I-D.phinney-roll-rpl-industrial-applicability'?>
<?rfc include='reference.I-D.watteyne-6tsch-tsch-lln-context'?>
<reference anchor="I-D.draft-palattella-6tsch-terminology">
<front>
<title>
Terminology in IPv6 over Time Slotted Channel Hopping. draft-palattella-6tsch-terminology-00 (work in progress)
</title>
<author initials="MR" surname="Palattella" fullname="Maria Rita Palattella" role="editor"/>
<author initials="P" surname="Thubert" fullname="Pascal Thubert"/>
<author initials="T" surname="Watteyne" fullname="Thomas Watteyne"/>
<author initials="Q" surname="Wang" fullname="Qin Wang"/>
<date month="March" year="2013"/>
</front>
</reference>
<reference anchor="I-D.draft-thubert-6tsch-architecture">
<front>
<title>
An Architecture for IPv6 over Time Synchronized Channel Hopping. draft-thubert-6tsch-architecture-00 (work in progress)
</title>
<author initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor"/>
<author initials="R" surname="Assimiti" fullname="Robert Assimiti"/>
<author initials="T" surname="Watteyne" fullname="Thomas Watteyne"/>
<date month="March" year="2013"/>
</front>
</reference>
<reference anchor="I-D.draft-wang-6tsch-6tus">
<front>
<title>
6tus Sub-Layer Specification. draft-wang-6tsch-6tus-01 (work in progress)
</title>
<author initials="Q" surname="Wang" fullname="Qin Wang" role="editor"/>
<author initials="X" surname="Vilajosana" fullname="Xavier Vilajosana"/>
<author initials="T" surname="Watteyne" fullname="Thomas Watteyne"/>
<date month="May" year="2013"/>
</front>
</reference>
</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) Amendament 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="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-22 12:33:57 |