6TSCH X. Vilajosana, Ed.
Internet-Draft Universitat Oberta de Catalunya
Intended status: Informational June 20, 2013
Expires: December 22, 2013
Minimal 6TSCH Configuration
draft-vilajosana-6tsch-basic-00
Abstract
This document describes the minimal set of rules to operate a
[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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 22, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Vilajosana Expires December 22, 2013 [Page 1]
Internet-Draft 6tsch-basic June 2013
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Slotframe . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Cells and cells Options . . . . . . . . . . . . . . . . . 4
2.3. Retransmissions . . . . . . . . . . . . . . . . . . . . . 5
2.4. Time Slot timming . . . . . . . . . . . . . . . . . . . . 5
3. Enhanced Beacons Configuration and Content . . . . . . . . . 6
3.1. Sync IE . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. IE Content . . . . . . . . . . . . . . . . . . . . . 7
3.2. Frame and Link IE . . . . . . . . . . . . . . . . . . . . 7
3.2.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. IE Content . . . . . . . . . . . . . . . . . . . . . 7
4. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. ACK/NACK Time Correction IE . . . . . . . . . . . . . . . 8
4.1.1. IE Header . . . . . . . . . . . . . . . . . . . . . . 8
4.1.2. IE Content . . . . . . . . . . . . . . . . . . . . . 8
5. Neighbor information . . . . . . . . . . . . . . . . . . . . 9
5.1. Neighbor Table . . . . . . . . . . . . . . . . . . . . . 9
5.2. Time Parent Selection . . . . . . . . . . . . . . . . . . 10
6. Queues and Priorities . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11
7.3. External Informative References . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
The nodes in a [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
Vilajosana Expires December 22, 2013 [Page 2]
Internet-Draft 6tsch-basic June 2013
[IEEE802154e] TSCH-compliant network, at the necessary price of
lesser efficiency.
2. Schedule
In order to form a network, a minimum schedule configuration is
required so nodes can advertise the presence of the network, and
exchange data.
2.1. Slotframe
The slotframe, as defined by
[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.
Basic configuration configuration
+---------------------------------+----------------------+
| 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 |
+---------------------------------+----------------------+
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 Section 2.2. These cells are scheduled at
slotOffset 1 to 5, and channeOffset 0. Per the IEEE802.15.4e TSCH
Vilajosana Expires December 22, 2013 [Page 3]
Internet-Draft 6tsch-basic June 2013
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.
Basic schedule overview
+-----+-----+-----+-----+-----+-----+-----+ +-----+
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
2.2. Cells and cells Options
Per the [IEEE802154e] TSCH standard, each active cell is assigned a
bitmap of cell options.
The EB cell is assigned the following bitmap of cell options:
b0 = Transmit = 1 (set)
b1 = Receive = 0 (clear)
b2 = Shared = 0 (clear)
b3 = Timekeeping = 0 (clear)
b4 = Hard = 1 (set)
b5-b7 = Reserved (clear)
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 [IEEE802154e] TSCH to resolve
collisions.
b0 = Transmit = 1 (set)
b1 = Receive = 1 (set)
Vilajosana Expires December 22, 2013 [Page 4]
Internet-Draft 6tsch-basic June 2013
b2 = Shared = 1 (set)
b3 = Timekeeping = 0 (clear)
b4 = Hard = 1 (set)
b5-b7 = Reserved (clear)
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.
2.3. Retransmissions
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.
2.4. Time Slot timming
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.
Time slot internal timing diagram
Vilajosana Expires December 22, 2013 [Page 5]
Internet-Draft 6tsch-basic June 2013
/------------------- Time Slot duration --------------------/
| /tsShortGT/ |
| | | | | |
|------------+-----------------+--------------+------+------|
TX | | TX-Packet | |RX Ack| |
|------------+-----------------+--------------+------+------|
|/tsTxOffset/| | | | |
| | | | | |
|------------+-----------------+--------------+------+------|
RX | | | | RX-Packet | |TX Ack| |
|---------+--+--+--------------+--------------+------+------|
| | | | | | | |
| /tsLongGT/ |/TsTxAckDelay/| | |
Start End
of of
Slot Slot
[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.
Timeslot durations
+---------------------------------+------------------+
| IEEE802.15.4e TSCH duration | Value |
+---------------------------------+------------------+
| TsTxOffset | 4000us |
+---------------------------------+------------------+
| TsLongGT | 1300us |
+---------------------------------+------------------+
| TsTxAckDelay | 4606us |
+---------------------------------+------------------+
| TsShortGT | 500us |
+---------------------------------+------------------+
| Time Slot duration | 15000us |
+---------------------------------+------------------+
3. Enhanced Beacons Configuration and Content
[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.
Vilajosana Expires December 22, 2013 [Page 6]
Internet-Draft 6tsch-basic June 2013
EBs must be sent with the Beacon IEEE802.15.4 frame type and this
document recommends that they carry the following Information
Elements (IEs):
3.1. Sync IE
Contains synchronization information such as ASN and join priority.
3.1.1. IE Header
Length (b0-b7) = 0x06
Sub-ID (b8-b14) = 0x1a
Type (b15) = 0x00 (short)
3.1.2. IE Content
ASN Byte 1 (b16-b23)
ASN Byte 2 (b24-b31)
ASN Byte 3 (b32-b39)
ASN Byte 4 (b40-b47)
ASN Byte 5 (b48-b55)
Join Priority (b56-b63)
3.2. Frame and Link IE
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 [IEEE802154e] fully to
be able to configure their schedule as they join the network, and
interact with nodes using a hard-coded schedule.
3.2.1. IE Header
Length (b0-b7) = variable
Sub-ID (b8-b14) = 0x1b
Type (b15) = 0x00 (short)
3.2.2. IE Content
Vilajosana Expires December 22, 2013 [Page 7]
Internet-Draft 6tsch-basic June 2013
# Slotframes (b16-b23) = 0x01
Slotframe ID (b24-b31) = 0x01
Size Slotframe (b32-b47) = 0x65
# Links (b48-b55) = 0x06
For each link in the basic schedule:
Channel Offset (2B) = 0x00
Slot Number (2B) = from (0x00 to 0x05)
LinkOption (1B) = as described in Section 2.2
4. Acknowledgement
MAC-layer acknowledgement frames are built according to
[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:
4.1. ACK/NACK Time Correction IE
The ACK/NACK time correction IE is used to carry the measured
desynchronization between the sender and the receiver.
4.1.1. IE Header
Length (b0-b7) = 0x02
Sub-ID (b8-b14) = 0x1e
Type (b15) = 0x00 (short)
4.1.2. IE Content
Time Synch Info and ACK status (b16-b31)
The possible values for the Time Synch Info and ACK status are
described in the following table:
ACK status and Time Synch information.
Vilajosana Expires December 22, 2013 [Page 8]
Internet-Draft 6tsch-basic June 2013
+-----------------------------------+------------------+
| 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 |
+-----------------------------------+------------------+
5. Neighbor information
[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:
5.1. Neighbor Table
The exact format of the neighbor table is implementation-specific,
but it should at least contain the following information, for each
neighbor:
Neighbor statistics:
number of transmitted packets to that neighbor
number of transmitted packets that have been acknowledged by
that neighbor
number of received packets from that neighbor
number of received packets that have been acknowledged for that
neighbor
Neighbor address.
ASN when that neighbor was last heard. This can be used to
trigger a keep-alive.
RPL rank of that neighbor.
A flag which indicates whether this neighbor is a time source
neighbor.
Vilajosana Expires December 22, 2013 [Page 9]
Internet-Draft 6tsch-basic June 2013
Connectivity statistics (RSSI, LQI, etc), which can be used to
help determine the quality of the link.
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.
5.2. Time Parent Selection
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.
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.
6. Queues and Priorities
[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:
When the node is not synchronized to the network, higher layers
are not able to insert packets into the queue.
Lower-layer packets have a higher priority that packets received
from a higher layer.
IEEE802.15.4 frames of types Beacon and Command have a higher
priority than IEEE802.15.4 frames of types Data and ACK.
One entry in the queue is reserved at all times for a IEEE802.15.4
frames of types Beacon or Command frames.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Vilajosana Expires December 22, 2013 [Page 10]
Internet-Draft 6tsch-basic June 2013
7.2. Informative References
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012.
[I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-12 (work in
progress), March 2013.
[I-D.phinney-roll-rpl-industrial-applicability]
Phinney, T., Thubert, P., and R. Assimiti, "RPL
applicability in industrial networks", draft-phinney-roll-
rpl-industrial-applicability-02 (work in progress),
February 2013.
[I-D.watteyne-6tsch-tsch-lln-context]
Watteyne, T., Palattella, M., and L. Grieco, "Using
IEEE802.15.4e TSCH in an LLN context: Overview, Problem
Statement and Goals", draft-watteyne-6tsch-tsch-lln-
context-02 (work in progress), May 2013.
[I-D.draft-palattella-6tsch-terminology]
Palattella, MR., Ed., Thubert, P., Watteyne, T., and Q.
Wang, "Terminology in IPv6 over Time Slotted Channel
Hopping. draft-palattella-6tsch-terminology-00 (work in
progress) ", March 2013.
[I-D.draft-thubert-6tsch-architecture]
Thubert, P., Ed., Assimiti, R., and T. Watteyne, "An
Architecture for IPv6 over Time Synchronized Channel
Hopping. draft-thubert-6tsch-architecture-00 (work in
progress) ", March 2013.
[I-D.draft-wang-6tsch-6tus]
Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6tus Sub-
Layer Specification. draft-wang-6tsch-6tus-01 (work in
progress) ", May 2013.
7.3. External Informative References
[IEEE802154e]
IEEE standard for Information Technology, "IEEE std.
802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
Networks (LR-WPANs) Amendament 1: MAC sublayer", April
2012.
Vilajosana Expires December 22, 2013 [Page 11]
Internet-Draft 6tsch-basic June 2013
[IEEE802154]
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.
[OpenWSN] , "Berkeley's OpenWSN Project Homepage", ,
<http://www.openwsn.org/>.
Author's Address
Xavier Vilajosana (editor)
Universitat Oberta de Catalunya
156 Rambla Poblenou
Barcelona, Catalonia 08018
Spain
Phone: +34 (646) 633 681
Email: xvilajosana@uoc.edu
Vilajosana Expires December 22, 2013 [Page 12]