| 6TiSCH | X. Vilajosana, Ed. |
| Internet-Draft | Universitat Oberta de Catalunya |
| Intended status: Best Current Practice | K. Pister |
| Expires: July 24, 2017 | University of California Berkeley |
| January 20, 2017 |
Minimal 6TiSCH Configuration
draft-ietf-6tisch-minimal-18
This document describes a minimal mode of operation for a 6TiSCH Network. A minimal mode of operation is a baseline set of protocols, recommended configurations and modes of operation sufficient to enable a 6TiSCH functional network. 6TiSCH provides IPv6 connectivity over a Time Synchronized Channel Hopping (TSCH) mesh composed of IEEE Std 802.15.4 TSCH links. This minimal mode uses a collection of protocols with the respective configurations, including the 6LoWPAN framework, enabling interoperable IPv6 connectivity over IEEE Std 802.15.4 TSCH. This minimal configuration provides the necessary bandwidth for network and security bootstrap and defines the proper link between the IETF protocols that interface to the IEEE Std 802.15.4 TSCH. This minimal mode of operation should be implemented by all 6TiSCH compliant devices.
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 July 24, 2017.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
A 6TiSCH Network provides IPv6 connectivity [RFC2460] over a Time Synchronized Channel Hopping (TSCH) mesh [RFC7554] composed of IEEE Std 802.15.4 TSCH links [IEEE802154-2015]. IPv6 connectivity is obtained by the use of the 6LoWPAN framework ([RFC4944], [RFC6282], [RFC8025],[I-D.ietf-6lo-routing-dispatch] and [RFC6775]), RPL [RFC6550], and its Objective Function 0 (OF0) [RFC6552].
This specification defines operational parameters and procedures for a minimal mode of operation to build a 6TiSCH Network. Any 6TiSCH complaint device SHOULD implement this mode of operation. This operational parameters configuration provides the necessary bandwidth for nodes to bootstrap the network. The bootstrap process includes initial network configuration and security bootstrap. In this specification, the 802.15.4 TSCH mode, the 6LoWPAN framework, RPL [RFC6550], and its Objective Function 0 (OF0) [RFC6552], are used unmodified. Parameters and particular operations of TSCH are specified to guarantee interoperability between nodes in a 6TiSCH Network. RPL is specified to provide the framework for time synchronization in an 802.15.4 TSCH network. The specifics for interoperable interaction between RPL and TSCH are described.
In a 6TiSCH network, nodes follow a communication schedule as per 802.15.4 TSCH. In it, nodes learn the schedule of the network when joining. When following this specification, the learned schedule is the same for all nodes and does not change over time. Future specifications may define mechanisms for dynamically managing the communication schedule. Dynamic scheduling solutions are out of scope of this document.
IPv6 addressing and compression are achieved by the 6LoWPAN framework. The framework includes [RFC4944], [RFC6282], [RFC8025], the 6LoWPAN Routing Header dispatch [I-D.ietf-6lo-routing-dispatch] for addressing and header compression, and [RFC6775] for duplicate address detection (DAD) and address resolution.
More advanced work is expected in the future to complement the Minimal Configuration with dynamic operations that can adapt the schedule to the needs of the traffic at run time.
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 RFC 2119 [RFC2119].
This document uses terminology from [I-D.ietf-6tisch-terminology]. The following concepts are used in this document:
An implementation compliant to this specification MUST implement IEEE Std 802.15.4 [IEEE802154-2015] in "timeslotted channel hopping" (TSCH) mode.
The remainder of this section details the RECOMMENDED TSCH settings, which are summarized in Figure 1. A node MAY use different values. Any of the properties marked in the EB column are announced in the Enhanced Beacons (EB) the nodes send [IEEE802154-2015] and learned by those joining the network. Changing their value hence means changing the contents of the EB.
In case of discrepancy between the values in this specification and IEEE Std 802.15.4 [IEEE802154-2015], the IEEE standard has precedence.
+--------------------------------+------------------------------+---+ | Property | Recommended Setting |EB*| +--------------------------------+------------------------------+---+ | Slotframe Size | Tunable. Trades-off | X | | | bandwidth against energy. | | +--------------------------------+------------------------------+---+ | Number of scheduled cells | 1 (slotOffset 0x0000) | X | | (active) | (chOffset 0x0000) | | | | (link Option 0x0f) | | | | (LinkType ADVERTISING) | | +--------------------------------+------------------------------+---+ | Number of unscheduled cells | All remaining cells in the | X | | (off) | slotframe | | +--------------------------------+------------------------------+---+ | Max Number MAC retransmissions | 3 (4 transmission attempts) | | +--------------------------------+------------------------------+---+ | Timeslot template | IEEE Std 802.15.4 default | X | | | (macTimeslotTemplateId=0) | | +--------------------------------+------------------------------+---+ | Enhanced Beacon Period | Tunable. Trades-off join | | | (EB_PERIOD) | time against energy. | | +--------------------------------+------------------------------+---+ | Number used frequencies | IEEE Std 802.15.4 default | X | | (2.4 GHz O-QPSK PHY) | (16) | | +--------------------------------+------------------------------+---+ | Channel Hopping sequence | IEEE Std 802.15.4 default | X | | (2.4 GHz O-QPSK PHY) | (macHoppingSequenceID = 0) | | +--------------------------------+------------------------------+---+ * an "X" in this column means this property's value is announced in the EB; a new node hence learns it when joining.
Figure 1: Recommended IEEE Std 802.15.4 TSCH Settings.
This minimal mode of operation uses a single slotframe. The TSCH slotframe is composed of a tunable number of timeslots. The slotframe size (i.e. the number of timeslots it contains) trades off bandwidth for energy consumption. The slotframe size needs to be tuned; the way of tuning it is out of scope of this specification. The slotframe size is announced in the EB. The slotframe handle (macSlotframeHandle) MAY be set to 0x80 so the slotframe has a medium priority (refer to [IEEE802154-2015] section 6.2.6.4), enabling other mechanism to position slotframes with higher or lower priority if needed. The use of other slotframes is out of the scope of this document.
There is only a single scheduled cell in the slotframe. This cell MAY be scheduled at any slotOffset/channelOffset within the slotframe. The location of that cell in the schedule is announced in the EB. The LinkType of the scheduled cell is ADVERTISING to allow EBs to be sent on it.
Chan. +----------+----------+ +----------+
Off.0 | TxRxS/EB | OFF | | OFF |
Chan. +----------+----------+ +----------+
Off.1 | OFF | OFF | ... | OFF |
+----------+----------+ +----------+
.
.
.
Chan. +----------+----------+ +----------+
Off.15 | OFF | OFF | | OFF |
+----------+----------+ +----------+
slotOffset 0 1 100
EB: Enhanced Beacon
Tx: Transmit
Rx: Receive
S: Shared
OFF: Unscheduled by this specification
Figure 2: Example slotframe of length 101 timeslots.
Figure 2 shows an example of a slotframe of length 101 timeslots, resulting in a radio duty cycle below 0.99%.
A node MAY use the scheduled cell to transmit/receive all types of link-layer frames. EBs are sent to the link-layer broadcast address, and not acknowledged. Data frames are sent unicast, and acknowledged by the receiving neighbor.
All remaining cells in the slotframe are unscheduled. Dynamic scheduling solutions may be defined in the future which schedule those cells. One example is the 6top Protocol (6P) [I-D.ietf-6tisch-6top-protocol]. Dynamic scheduling solutions are out of scope of this document.
The default values of the TSCH Timeslot template (defined in [IEEE802154-2015] section 8.4.2.2.3) and Channel Hopping sequence (defined in [IEEE802154-2015] section 6.2.10) SHOULD be used. A node MAY use different values by properly announcing them in its Enhanced Beacon.
In the scheduled cell, a node transmits if there is a packet to transmit, listens otherwise (both "TX" and "RX" bits are set). When a node transmits, requesting a link-layer acknowledgement per [IEEE802154-2015], and does not receive it, it uses a back-off mechanism to resolve possible collisions ("Shared" bit is set). A node joining the network maintains time synchronization to its initial time source neighbor using that cell ("Timekeeping" bit is set).
This translates into a Link Option for this cell of value 0x0f:
Per Figure 1, the RECOMMENDED maximum number of link-layer retransmissions is 3. This means that, for packets requiring an acknowledgment, if none are received after a total of 4 attempts, the transmission is considered failed and the link layer MUST notify the upper layer. Packets not requiring an acknowledgment (including EBs) are not retransmitted.
Per Figure 1, the RECOMMENDED timeslot template is the default one (macTimeslotTemplateId=0) defined in [IEEE802154-2015].
[IEEE802154-2015] defines the format of frames. Through a set of flags, [IEEE802154-2015] allows for several fields to be present or not, to have different lengths, and to have different values. This specification details the RECOMMENDED contents of 802.15.4 frames, while strictly complying to [IEEE802154-2015].
The Frame Version field SHOULD be set to 0b10 (Frame Version 2). The Sequence Number field MAY be elided.
EB Destination Address field SHOULD be set to 0xFFFF (short broadcast address). The EB Source Address field SHOULD be set as the node's short address if this is supported. Otherwise the long address SHOULD be used.
The PAN ID Compression bit SHOULD indicate that the Source PAN ID is "Not Present" and the Destination PAN ID is "Present". The value of the PAN ID Compression bit is specified in Table 7-2 of the IEEE Std 802.15.4-2015 specification, and depends on the type of the destination and source link-layer addresses (short, extended, not present).
Nodes follow the reception and rejection rules as per Section 6.7.2 of [IEEE802154-2015].
The Nonce is formatted according to [IEEE802154-2015]. In the IEEE Std 802.15.4 specification [IEEE802154-2015], nonce generation is described in Section 9.3.2.2, and byte ordering in Section 9.3.1, Annex B.2 and Annex B.2.2.
After booting, a TSCH node starts in an unsynchronized, unjoined state. Initial synchronization is achieved by listening for EBs. EBs from multiple networks may be heard. Many mechanisms exist for discrimination between networks, the details of which are out of scope. EBs are not secure.
The IEEE Std 802.15.4 specification does not define how often EBs are sent, nor their contents [IEEE802154-2015]. In a minimal TSCH configuration, a node SHOULD send an EB every EB_PERIOD. Tuning EB_PERIOD allows a trade-off between joining time and energy consumption.
EBs SHOULD be used to obtain information about local networks, and to synchronize ASN and time offset of the specific network that the node decides to join. Once joined to a particular network, a node MAY choose to continue to listen for EBs, to gather more information about other networks, for example. EBs heard after joining a network SHOULD NOT be used for time synchronization, or to change any other network parameters. During the joining process, before secure connections to time parents have been created, it MAY be necessary for a node to maintain synchronization using EBs. [RFC7554] discusses different time synchronization approaches.
EBs MUST be sent as per the IEEE Std 802.15.4 specification and SHOULD carry the Information Elements (IEs) listed below [IEEE802154-2015].
If a node strictly follows the recommended setting from Figure 1, the EB it sends has the exact same contents as an EB it has received when joining, except for the Join Metric field in the TSCH Synchronization IE.
Per [IEEE802154-2015], each acknowledgment contain an ACK/NACK Time Correction IE.
When securing link-layer frames, link-layer frames MUST be secured by the link-layer security mechanisms defined in IEEE Std 802.15.4 [IEEE802154-2015]. Link-layer authentication MUST be applied to the entire frame, including the 802.15.4 header. Link-layer encryption MAY be applied to 802.15.4 payload IEs and the 802.15.4 payload.
During normal network operation a cryptographic key KL is used to authenticate and optionally encrypt DATA and ACKNOWLEDGMENT frames. KL may be pre-provisioned. Key distribution is out of scope of this document. Provisioning mechanisms are defined for example in [I-D.ietf-6tisch-minimal-security] and [I-D.ietf-6tisch-dtsecurity-secure-join]. Some provisioning mechanisms will require some level of network access during the joining process.
During the join process, if KL has not been provisioned yet, a protocol identifier PI SHOULD be used in place of KL until both transmitter and receiver have KL. In particular, PI is used to authenticate EBs. In this case, PI MUST be pre-configured, and provides no security. PI does indicate that the authenticated frame was intended as a 6TiSCH EB. In a crowded 802.15.4 RF environment, this facilitates logical segregation of distinct networks. The value 36 54 69 53 43 48 20 6D 69 6E 69 6D 61 6C 31 38 ("6TiSCH minimal18") is RECOMMENDED for PI, but a network operator MAY change it for administrative and segregation reasons.
In the event of a network reset, the new network MUST either use a new cryptographic key or keys KL, or ensure that the ASN remains monotonically increasing.
In a multi-hop topology, the RPL routing protocol [RFC6550] MAY be used.
If RPL is used, nodes MUST implement the RPL Objective Function Zero (OF0) [RFC6552].
The Rank computation is described at [RFC6552], Section 4.1. A node's Rank (see Figure 4 for an example) is computed by the following equations:
Figure 3 lists the OF0 parameter values that MUST be used if RPL is used.
+----------------------+-------------------------------------+
| OF0 Parameters | Value |
+----------------------+-------------------------------------+
| Rf | 1 |
+----------------------+-------------------------------------+
| Sp | (3*ETX)-2 |
+----------------------+-------------------------------------+
| Sr | 0 |
+----------------------+-------------------------------------+
| MinHopRankIncrease | DEFAULT_MIN_HOP_RANK_INCREASE (256) |
+----------------------+-------------------------------------+
| MINIMUM_STEP_OF_RANK | 1 |
+----------------------+-------------------------------------+
| MAXIMUM_STEP_OF_RANK | 9 |
+----------------------+-------------------------------------+
| ETX limit to select | 3 |
| a parent | |
+----------------------+-------------------------------------+
Figure 3: OF0 parameters.
The step_of_rank (Sp) uses Expected Transmission Count (ETX) [RFC6551].
An implementation MUST follow OF0's normalization guidance as discussed in Section 1 and Section 4.1 of [RFC6552]. Sp SHOULD be calculated as (3*ETX)-2. The minimum value of Sp (MINIMUM_STEP_OF_RANK) indicates a good quality link. The maximum value of Sp (MAXIMUM_STEP_OF_RANK) indicates a poor quality link. The default value of Sp (DEFAULT_STEP_OF_RANK) indicates an average quality link. Candidate parents with ETX greater than 3 SHOULD NOT be selected. This avoids having ETX values on used links which are larger that the maximum allowed transmission attempts.
+-------+
| 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
+-------+
Figure 4: Rank computation example for 5-hop network where numTx=100 and numTxAck=75 for all links.
This section illustrates the use of the Objective Function Zero (see Figure 4). We have:
When RPL is used, nodes MUST implement the non-storing ([RFC6550] Section 9.7) mode of operation. The storing ([RFC6550] Section 9.8) mode of operation SHOULD be implemented by nodes with enough capabilities. Nodes not implementing RPL MUST join as leaf nodes.
RPL signaling messages such as DIOs are sent using the Trickle Algorithm [RFC6550] (Section 8.3.1) and [RFC6206] (Section 4.2). For this specification, the Trickle Timer MUST be used with the RPL defined default values [RFC6550] (Section 8.3.1).
RPL information and hop-by-hop extension headers MUST follow [RFC6553] and [RFC6554] specification. In the case the packets formed at the LLN need to cross through intermediate routers, these MUST follow the IP-in-IP encapsulation requirement specified by the [RFC6282] and [RFC2460]. Routing extension headers such as RPI [RFC6550] and SRH [RFC6554], and outer IP headers in case of encapsulation MUST be compressed according to [I-D.ietf-6lo-routing-dispatch] and [RFC8025].
The Join Metric of the TSCH Synchronization IE in the EB MUST be calculated based on the routing metric of the node, normalized to a value between 0 and 255. A lower value of the Join Metric indicates the node sending the EB is topologically "closer" to the root of the network. A lower value of the Join Metric hence indicates higher preference for a joining node to synchronize to that neighbor. In case that the network uses RPL, the Join Metric of any node (including the DAG root) MUST be set to DAGRank(rank)-1. According to Section 5.1.1, DAGRank(rank(0)) = 1. DAGRank(rank(0))-1 = 0 is compliant with 802.15.4's requirement of having the root use Join Metric = 0. When a node is not using RPL, the Join Metric value SHOULD follow the rules specified by [IEEE802154-2015].
When a node joins a network, it may hear EBs sent by different nodes already in the network. The decision of which neighbor to synchronize to (e.g. which neighbor becomes the node's initial time source neighbor) is implementation-specific. For example, after having received the first EB, a node MAY listen for at most MAX_EB_DELAY seconds until it has received EBs from NUM_NEIGHBOURS_TO_WAIT distinct neighbors. When receiving EBs from distinct neighbors, the node MAY use the Join Metric field in each EB to select the initial time source neighbor, as described in IEEE Std 802.15.4 [IEEE802154-2015], Section 6.3.6.
At any time, a node MUST maintain connectivity to at least one time source neighbor. A node's time source neighbor MUST be chosen among the neighbors in its RPL routing parent set.
When a RPL node joins the network, it MUST NOT send EBs before having acquired a RPL Rank to avoid inconsistencies in the time synchronization structure. This applies to other routing protocols with their corresponding routing metrics. As soon as a node acquires routing information (e.g. a RPL Rank, see Section 5.1.1), it SHOULD start sending Enhanced Beacons.
Per [RFC6552] and [RFC6719], the specification 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 the 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. Per [RFC6719], the PARENT_SWITCH_THRESHOLD SHOULD be set to 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 deals with hysteresis both for routing parent and time source neighbor selection. In case a node has a security association with its parent, including routing parent or time source neighbor, the node SHOULD be allowed to keep the association despite of fluctuations of the rank.
The exact format of the neighbor table is implementation-specific. The RECOMMENDED per-neighbor information is (taken from the [openwsn] implementation):
The IEEE Std 802.15.4 specification [IEEE802154-2015] does not define the use of queues to handle upper layer data (either application or control data from upper layers). The following rules are RECOMMENDED:
Figure 5 lists RECOMMENDED values for the settings discussed in this specification.
+-------------------------+-------------------+
| Parameter | RECOMMENDED Value |
+-------------------------+-------------------+
| MAX_EB_DELAY | 180 |
+-------------------------+-------------------+
| NUM_NEIGHBOURS_TO_WAIT | 2 |
+-------------------------+-------------------+
| PARENT_SWITCH_THRESHOLD | 640 |
+-------------------------+-------------------+
| NUM_UPPERLAYER_PACKETS | 1 |
+-------------------------+-------------------+
| MAX_JOIN_TIME | 300 |
+-------------------------+-------------------+
Figure 5: Recommended Settings.
This document is concerned only with MAC-layer security.
By their nature, many IoT networks have nodes in physically vulnerable locations. We should assume that nodes will be physically compromised, their memories examined, and their keys extracted. Fixed secrets will not remain secret. This impacts the node joining process. Provisioning a network with a fixed link key KL is not secure. For most applications, this implies that there will be a joining phase during which some level of authorization be allowed for nodes which have not been authenticated. Details are out of scope, but the MAC layer must provide some flexibility here.
During the joining phase, there are three choices for EB message integrity and security.
ASN provides a nonce for security operations in a slot. Any re-use of ASN with a given key exposes information about encrypted packet contents, and risks replay attacks. Replay attacks are prevented because, when the network resets, either the new network uses new cryptographic key(s), or ensures that the ASN increases monotonically (Section 4.6).
Maintaining accurate time synchronization is critical for network operation. Accepting timing information from unsecured sources MUST be avoided during normal network operation, as described in Section 4.5.2. During joining, a node may be susceptible to timing attacks before key KL is provisioned. During network operation, a node MAY maintain statistics on time updates from neighbors and monitor for anomalies.
Denial of service attacks at the MAC layer in an LLN are easy to achieve simply by RF jamming. This is the base case against which more sophisticated DoS attacks should be judged. For example, sending false EBs announcing a very low Join Metric may cause a node to waste time and energy trying to join a bogus network even when valid EBs are being heard. Proper join security will prevent the node from joining the false flag, but by then the time and energy will have been wasted. However, the energy cost to the attacker would be lower and the energy cost to the joining node higher if the attacker simply sent loud short packets in the middle of any valid EB that it hears.
The MAC-layer SHOULD keep track of anomalous events and report them to a higher authority. For example, EBs reporting low Join Metrics for networks which can not be joined, as described above, may be a sign of attack. Additionally, in normal network operation message integrity check failures on packets with valid CRC will occur at a rate on the order of once per million packets. Any significant deviation from this rate may be a sign of network attack. Along the same lines, time updates in ACKs or EBs that are inconsistent with the MAC-layer's sense of time and its own plausible time error drift rate may also be a result of network attack.
This document requests no immediate action by IANA.
The authors acknowledge the guidance and input from Rene Struik, Pat Kinney, Michael Richardson, Tero Kivinen, Nicola Accettura, Malisa Vucinic, Jonathan Simon and thank Charles Perkins, Brian Carpenter and Suresh Krishnan for the exhaustive and detailed review. Thanks to Simon Duquennoy, Guillaume Gaillard, Tengfei Chang and Jonathan Muñoz for the detailed review of the examples section. Thanks to 6TiSCH co-chairs Pascal Thubert and Thomas Watteyne for their guidance and advice.
| [I-D.ietf-6tisch-6top-protocol] | Wang, Q. and X. Vilajosana, "6top Protocol (6P)", Internet-Draft draft-ietf-6tisch-6top-protocol-03, October 2016. |
| [I-D.ietf-6tisch-terminology] | Palattella, M., Thubert, P., Watteyne, T. and Q. Wang, "Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e", Internet-Draft draft-ietf-6tisch-terminology-08, December 2016. |
| [I-D.ietf-6tisch-minimal-security] | malisa.vucinic@st.com, m., Simon, J. and K. Pister, "Minimal Security Framework for 6TiSCH", Internet-Draft draft-ietf-6tisch-minimal-security-00, December 2016. |
| [I-D.ietf-6tisch-dtsecurity-secure-join] | Richardson, M., "6tisch Secure Join protocol", Internet-Draft draft-ietf-6tisch-dtsecurity-secure-join-00, December 2016. |
| [RFC7554] | Watteyne, T., Palattella, M. and L. Grieco, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", RFC 7554, DOI 10.17487/RFC7554, May 2015. |
| [openwsn] | Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., Weekly, K., Wang, Q., Glaser, S. and K. Pister, "OpenWSN: a Standards-Based Low-Power Wireless Development Environment", Transactions on Emerging Telecommunications Technologies , August 2012. |
This section contains several example packets. Each example contains (1) a schematic header diagram, (2) the corresponding bytestream, (3) a description of each of the IEs that form the packet. Packet formats are specific for the [IEEE802154-2015] revision and may vary in future releases of the IEEE standard. In case of differences between the packet content presented in this section and [IEEE802154-2015], the latter has precedence.
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, from left to right, where the leftmost bit is transmitted first. 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 (little endian).
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 Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 = 0x80 | SF LEN = 0x65 (101 slots) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| #Links = 0x01 | SLOT OFFSET = 0x0000 | CHANNEL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OFF = 0x0000 |Link OPT = 0x0F| NO MAC PAYLOAD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bytestream:
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 80 65 00 01 00 00 00 00 0F
Description of the IEs:
#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)
Group ID = 1 MLME (Nested)
Type = 1
#MLME-SubIE TSCH Synchronization
Len3 = Length in bytes of the sub-IE payload (6 Bytes)
Sub-ID = 0x1a (MLME-SubIE TSCH Synchronization)
Type = Short (0)
ASN = Absolute Sequence Number (5 Bytes)
Join Metric = 1 Byte
#MLME-SubIE TSCH Timeslot
Len4 = Length in bytes of the sub-IE payload (1 Byte)
Sub-ID = 0x1c (MLME-SubIE Timeslot)
Type = Short (0)
Timeslot template ID = 0x00 (default)
#MLME-SubIE Channel Hopping
Len5 = Length in bytes of the sub-IE payload (1 Byte)
Sub-ID = 0x09 (MLME-SubIE Channel Hopping)
Type = Long (1)
Hopping Sequence ID = 0x00 (default)
#MLME-SubIE TSCH Slotframe and Link
Len6 = Length in bytes of the sub-IE payload (10 Bytes)
Sub-ID = 0x1b (MLME-SubIE TSCH Slotframe and Link)
Type = Short (0)
Number of slotframes = 0x01
Slotframe handle = 0x80
Slotframe size = 101 slots (0x65)
Number of Links (Cells) = 0x01
Timeslot = 0x0000 (2B)
Channel Offset = 0x0000 (2B)
Link Options = 0x0F
(TX Link, RX Link, Shared Link, Timekeeping)
Using a custom timeslot template in EBs: setting timeslot length to 15ms.
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 Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bytestream:
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 IEs:
#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)
Group ID = 1 MLME (Nested)
Type = 1
#MLME-SubIE TSCH Synchronization
Len3 = Length in bytes of the sub-IE payload (6 Bytes)
Sub-ID = 0x1a (MLME-SubIE TSCH Synchronization)
Type = Short (0)
ASN = Absolute Sequence Number (5 Bytes)
Join Metric = 1 Byte
#MLME-SubIE TSCH Timeslot
Len4 = Length in bytes of the sub-IE payload (25 Bytes)
Sub-ID = 0x1c (MLME-SubIE Timeslot)
Type = Short (0)
Timeslot template ID = 0x01 (non-default)
The 15ms timeslot announced:
+--------------------------------+------------+
| IEEE 802.15.4 TSCH parameter | Value (us) |
+--------------------------------+------------+
| macTsCCAOffset | 2700 |
+--------------------------------+------------+
| macTsCCA | 128 |
+--------------------------------+------------+
| macTsTxOffset | 3180 |
+--------------------------------+------------+
| macTsRxOffset | 1680 |
+--------------------------------+------------+
| macTsRxAckDelay | 1200 |
+--------------------------------+------------+
| macTsTxAckDelay | 1500 |
+--------------------------------+------------+
| macTsRxWait | 3300 |
+--------------------------------+------------+
| macTsAckWait | 600 |
+--------------------------------+------------+
| macTsRxTx | 192 |
+--------------------------------+------------+
| macTsMaxAck | 2400 |
+--------------------------------+------------+
| macTsMaxTx | 4256 |
+--------------------------------+------------+
| macTsTimeslotLength | 15000 |
+--------------------------------+------------+
#MLME-SubIE Channel Hopping
Len5 = Length in bytes of the sub-IE payload. (1 Byte)
Sub-ID = 0x09 (MLME-SubIE Channel Hopping)
Type = Long (1)
Hopping Sequence ID = 0x00 (default)
Enhanced Acknowledgment packets carry the Time Correction IE (Header IE).
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bytestream:
02 0F TS#0 TS#1
Description of the IEs:
#Header IE Header
Len1 = Header IE Length (2 Bytes)
Element ID = 0x1e - ACK/NACK Time Correction IE
Type 0
802.15.4 Auxiliary Security Header with security Level set to ENC-MIC-32.
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bytestream:
6D IDX#0
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)
ASN in Nonce = 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)