RFC 8480
6TiSCH Operation Sublayer (6top) Protocol (6P)
Pages: 50
Proposed Standard
Proposed Standard
Part 1 of 4 – Pages 1 to 16
Internet Engineering Task Force (IETF) Q. Wang, Ed. Request for Comments: 8480 Univ. of Sci. and Tech. Beijing Category: Standards Track X. Vilajosana ISSN: 2070-1721 Universitat Oberta de Catalunya T. Watteyne Analog Devices November 2018 6TiSCH Operation Sublayer (6top) Protocol (6P)Abstract
This document defines the "IPv6 over the TSCH mode of IEEE 802.15.4e" (6TiSCH) Operation Sublayer (6top) Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes to add/delete Time-Slotted Channel Hopping (TSCH) cells to/on one another. 6P is part of the 6TiSCH Operation Sublayer (6top), the layer just above the IEEE Std 802.15.4 TSCH Medium Access Control layer. 6top is composed of one or more Scheduling Functions (SFs) and the 6top Protocol defined in this document. A 6top SF decides when to add/delete cells, and it triggers 6P Transactions. The definition of SFs is out of scope for this document; however, this document provides the requirements for an SF. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8480.
Copyright Notice Copyright (c) 2018 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 (https://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 ....................................................3 1.1. Requirements Language ......................................5 2. 6TiSCH Operation Sublayer (6top) ................................5 2.1. Hard/Soft Cells ............................................6 2.2. Using 6P with the Minimal 6TiSCH Configuration .............6 3. 6top Protocol (6P) ..............................................7 3.1. 6P Transactions ............................................7 3.1.1. 2-Step 6P Transaction ...............................8 3.1.2. 3-Step 6P Transaction ..............................10 3.2. Message Format ............................................12 3.2.1. 6top Information Element (IE) ......................12 3.2.2. Generic 6P Message Format ..........................12 3.2.3. 6P CellOptions .....................................13 3.2.4. 6P CellList ........................................16 3.3. 6P Commands and Operations ................................17 3.3.1. Adding Cells .......................................17 3.3.2. Deleting Cells .....................................19 3.3.3. Relocating Cells ...................................21 3.3.4. Counting Cells .....................................27 3.3.5. Listing Cells ......................................28 3.3.6. Clearing the Schedule ..............................30 3.3.7. Generic Signaling between SFs ......................31 3.4. Protocol Functional Details ...............................31 3.4.1. Version Checking ...................................31 3.4.2. SFID Checking ......................................32 3.4.3. Concurrent 6P Transactions .........................32 3.4.4. 6P Timeout .........................................33 3.4.5. Aborting a 6P Transaction ..........................33 3.4.6. SeqNum Management ..................................33 3.4.7. Handling Error Responses ...........................40 3.5. Security ..................................................40
4. Requirements for 6top Scheduling Function (SF) Specifications ..41 4.1. SF Identifier (SFID) ......................................41 4.2. Requirements for an SF Specification ......................41 5. Security Considerations ........................................42 6. IANA Considerations ............................................43 6.1. IETF IE Subtype 6P ........................................43 6.2. 6TiSCH Parameters Subregistries ...........................43 6.2.1. 6P Version Numbers .................................43 6.2.2. 6P Message Types ...................................44 6.2.3. 6P Command Identifiers .............................44 6.2.4. 6P Return Codes ....................................45 6.2.5. 6P Scheduling Function Identifiers .................46 6.2.6. 6P CellOptions Bitmap ..............................47 7. References .....................................................48 7.1. Normative References ......................................48 7.2. Informative References ....................................48 Appendix A. Recommended Structure of an SF Specification ..........49 Authors' Addresses ................................................501. Introduction
All communication in an "IPv6 over the TSCH mode of IEEE 802.15.4e" (6TiSCH) network is orchestrated by a schedule [RFC7554]. The schedule is composed of cells, each identified by a [slotOffset,channelOffset] (Section 3.2.4). This specification defines the 6TiSCH Operation Sublayer (6top) Protocol (6P), which is terminated by 6top. 6P allows a node to communicate with a neighbor node to add/delete Time-Slotted Channel Hopping (TSCH) cells to/on one another. This results in distributed schedule management in a 6TiSCH network. 6top is composed of one or more Scheduling Functions (SFs) and the 6top Protocol defined in this document. The definition of SFs is out of scope for this document; however, this document provides the requirements for an SF.
The example network depicted in Figure 1 is used to describe the interaction between nodes. We consider the canonical case where node "A" issues 6P Requests (also referred to as "commands" in this document) to node "B". We use this example throughout this document: node A always represents the node that issues a 6P Request, and node B represents the node that receives this request. (R) / \ / \ (B)-----(C) | | | | (A) (D) Figure 1: A Simple 6TiSCH Network We consider that node A monitors the communication cells it has in its schedule to node B: o If node A determines that the number of link-layer frames it is sending to node B per unit of time exceeds the capacity offered by the TSCH cells it has scheduled to node B, it triggers a 6P Transaction with node B to add one or more cells to the TSCH schedule of both nodes. o If the traffic is lower than the capacity offered by the TSCH cells it has scheduled to node B, node A triggers a 6P Transaction with node B to delete one or more cells in the TSCH schedule of both nodes. o Node A MAY also monitor statistics to determine whether collisions are happening on a particular cell to node B. If this feature is enabled, node A communicates with node B to "relocate" this particular cell to a different [slotOffset,channelOffset] location in the TSCH schedule. This results in distributed schedule management in a 6TiSCH network. The 6top SF defines when to add/delete a cell to/on a neighbor. Different applications require different SFs; this topic is out of scope for this document. Different SFs are expected to be defined in future companion specifications. A node MAY implement multiple SFs and run them at the same time. At least one SF MUST be running. The SFID field contained in all 6P messages allows a node to invoke the appropriate SF on a per-6P Transaction basis.
Section 2 describes 6top. Section 3 defines 6P. Section 4 provides guidelines on how to define an SF.1.1. Requirements Language
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.2. 6TiSCH Operation Sublayer (6top)
As depicted in Figure 2, 6top is the layer just above the IEEE Std 802.15.4 TSCH Medium Access Control (MAC) layer [IEEE802154]. We use "802.15.4" as a short version of "IEEE Std 802.15.4" in this document. . | . | | higher layers | +------------------------------------------+ | 6top | +------------------------------------------+ | IEEE Std 802.15.4 TSCH | | . | . Figure 2: 6top in the Protocol Stack The roles of 6top are to: o Terminate 6P, which allows neighbor nodes to communicate to add/delete cells to/on one another. o Run one or multiple 6top SFs, which define the rules that decide when to add/delete cells.
2.1. Hard/Soft Cells
Each cell in the schedule is either "hard" or "soft": o A soft cell can be read, added, deleted, or updated by 6top. o A hard cell is read-only for 6top. In the context of this specification, all the cells used by 6top are soft cells. Hard cells can be used, for example, when "hard-coding" a schedule [RFC8180].2.2. Using 6P with the Minimal 6TiSCH Configuration
6P MAY be used alongside the minimal 6TiSCH configuration [RFC8180]. In this case, it is RECOMMENDED to use two slotframes, as depicted in Figure 3: o Slotframe 0 is used for traffic defined in the minimal 6TiSCH configuration. In Figure 3, Slotframe 0 is five slots long, but it can be shorter or longer. o 6P allocates cells from Slotframe 1. In Figure 3, Slotframe 1 is 10 slots long, but it can be shorter or longer. | 0 1 2 3 4 | 0 1 2 3 4 | +------------------------+------------------------+ Slotframe 0 | | | | | | | | | | | 5 slots long | EB | | | | | EB | | | | | (Minimal 6TiSCH) | | | | | | | | | | | +-------------------------------------------------+ | 0 1 2 3 4 5 6 7 8 9 | +-------------------------------------------------+ Slotframe 1 | | | | | | | | | | | 10 slots long | |A->B| | | | | | |B->A| | (6P) | | | | | | | | | | | +-------------------------------------------------+ Figure 3: 2-Slotframe Structure when Using 6P alongside the Minimal 6TiSCH Configuration The minimal 6TiSCH configuration cell SHOULD be allocated from a slotframe of higher priority than the slotframe used by 6P for dynamic cell allocation. This way, dynamically allocated cells cannot "mask" the cells used by the minimal 6TiSCH configuration. 6top MAY support additional slotframes; how to use additional slotframes is out of scope for this document.
3. 6top Protocol (6P)
6P enables two neighbor nodes to add/delete/relocate cells in their TSCH schedule. Conceptually, two neighbor nodes "negotiate" the location of the cells to add, delete, or relocate in their TSCH schedule.3.1. 6P Transactions
We call "6P Transaction" a complete negotiation between two neighbor nodes. A particular 6P Transaction is executed between two nodes as a result of an action triggered by one SF. For a 6P Transaction to succeed, both nodes must use the same SF to handle the particular transaction. A 6P Transaction starts when a node wishes to add/delete/relocate one or more cells with one of its neighbors. A 6P Transaction ends when (1) the cell(s) has been added/deleted/ relocated in the schedule of both nodes or (2) the 6P Transaction has failed. 6P messages exchanged between nodes A and B during a 6P Transaction SHOULD be exchanged on non-shared unicast cells ("dedicated" cells) between nodes A and B. If no dedicated cells are scheduled between nodes A and B, shared cells MAY be used. Keeping consistency between the schedules of the two neighbor nodes is important. A loss of consistency can cause loss of connectivity. One example is when node A has a transmit cell to node B but node B does not have the corresponding reception cell. To verify consistency, neighbor nodes maintain a sequence number (SeqNum). Neighbor nodes exchange the SeqNum as part of each 6P Transaction to detect a possible inconsistency. This mechanism is explained in Section 3.4.6.2. An implementation MUST include a mechanism to associate each scheduled cell with the SF that scheduled it. This mechanism is implementation specific and is out of scope for this document. A 6P Transaction can consist of two or three steps. A 2-step transaction is used when node A selects the cells to be allocated. A 3-step transaction is used when node B selects the cells to be allocated. An SF MUST specify whether to use 2-step transactions, 3-step transactions, or both. We illustrate 2-step and 3-step transactions using the topology in Figure 1.
3.1.1. 2-Step 6P Transaction
Figure 4 shows an example 2-step 6P Transaction. In a 2-step transaction, node A selects the candidate cells. Several elements are left out so that the diagram is easier to understand. +----------+ +----------+ | Node A | | Node B | +----+-----+ +-----+----+ | | | 6P ADD Request | | Type = REQUEST | | Code = ADD | | SeqNum = 123 | cells | NumCells = 2 | locked | CellList = [(1,2),(2,2),(3,5)] | +-- |-------------------------------------->| | | L2 ACK | | 6P Timeout |<- - - - - - - - - - - - - - - - - - - | | | | | | | | 6P Response | | | | Type = RESPONSE | | | | Code = RC_SUCCESS | | | | SeqNum = 123 | cells | | | CellList = [(2,2),(3,5)] | locked +-> X |<--------------------------------------| --+ | L2 ACK | | | - - - - - - - - - - - - - - - - - - ->| <-+ | | Figure 4: An Example 2-Step 6P Transaction In this example, the 2-step transaction occurs as follows: 1. The SF running on node A determines that two extra cells need to be scheduled to node B. 2. The SF running on node A selects candidate cells for node B to choose from. Node A MUST select at least as many candidate cells as the number of cells to add. Here, node A selects three candidate cells. Node A locks those candidate cells in its schedule until it receives a 6P Response.
3. Node A sends a 6P ADD Request to node B, indicating that it
wishes to add two cells (the "NumCells" value) and specifying the
list of three candidate cells (the "CellList" value). Each cell
in the CellList is a [slotOffset,channelOffset] tuple. This 6P
ADD Request is link-layer acknowledged by node B (labeled "L2
ACK" in Figure 4).
4. After having successfully sent the 6P ADD Request (i.e.,
receiving the link-layer acknowledgment), node A starts a 6P
Timeout to abort the 6P Transaction in the event that no response
is received from node B.
5. The SF running on node B selects two out of the three cells from
the CellList of the 6P ADD Request. Node B locks those cells in
its schedule until the transmission is successful (i.e., node B
receives a link-layer ACK from node A). Node B sends back a 6P
Response to node A, indicating the cells it has selected. The
response is link-layer acknowledged by node A.
6. Upon completion of this 6P Transaction, two cells from node A to
node B have been added to the TSCH schedule of both nodes A
and B.
7. An inconsistency in the schedule can happen if the 6P Timeout
expires when the 6P Response is in the air, if the last
link-layer ACK for the 6P Response is lost, or if one of the
nodes is power-cycled during the transaction. 6P provides an
inconsistency detection mechanism to cope with such situations;
see Section 3.4.6.2 for details.
3.1.2. 3-Step 6P Transaction
Figure 5 shows an example 3-step 6P Transaction. In a 3-step transaction, node B selects the candidate cells. Several elements are left out so that the diagram is easier to understand. +----------+ +----------+ | Node A | | Node B | +----+-----+ +-----+----+ | | | 6P ADD Request | | Type = REQUEST | | Code = ADD | | SeqNum = 178 | | NumCells = 2 | | CellList = [] | |-------------------------------------->| | L2 ACK | 6P Timeout |<- - - - - - - - - - - - - - - - - - - | | | | | | 6P Response | | | Type = RESPONSE | | | Code = RC_SUCCESS | | | SeqNum = 178 | cells | | CellList = [(1,2),(2,2),(3,5)] | locked X |<--------------------------------------| --+ | L2 ACK | | | - - - - - - - - - - - - - - - - - - ->| 6P Timeout | | | | | | 6P Confirmation | | | | Type = CONFIRMATION | | | | Code = RC_SUCCESS | | | cells | SeqNum = 178 | | | locked | CellList = [(2,2),(3,5)] | | | +-- |-------------------------------------->| X <--+ | | L2 ACK | +-> |<- - - - - - - - - - - - - - - - - - - | | | Figure 5: An Example 3-Step 6P Transaction
In this example, the 3-step transaction occurs as follows:
1. The SF running on node A determines that two extra cells need to
be scheduled to node B. The SF uses a 3-step transaction, so it
does not select candidate cells.
2. Node A sends a 6P ADD Request to node B, indicating that it
wishes to add two cells (the "NumCells" value), with an empty
"CellList". This 6P ADD Request is link-layer acknowledged by
node B.
3. After having successfully sent the 6P ADD Request, node A starts
a 6P Timeout to abort the transaction in the event that no 6P
Response is received from node B.
4. The SF running on node B selects three candidate cells and locks
them. Node B sends back a 6P Response to node A, indicating the
three cells it has selected. The response is link-layer
acknowledged by node A.
5. After having successfully sent the 6P Response, node B starts a
6P Timeout to abort the transaction in the event that no 6P
Confirmation is received from node A.
6. The SF running on node A selects two cells from the CellList
field in the 6P Response and locks them. Node A sends back a 6P
Confirmation to node B, indicating the cells it selected. The
confirmation is link-layer acknowledged by node B.
7. Upon completion of the 6P Transaction, two cells from node A to
node B have been added to the TSCH schedule of both nodes A
and B.
8. An inconsistency in the schedule can happen if the 6P Timeout
expires when the 6P Confirmation is in the air, if the last
link-layer ACK for the 6P Confirmation is lost, or if one of the
nodes is power-cycled during the transaction. 6P provides an
inconsistency detection mechanism to cope with such situations;
see Section 3.4.6.2 for details.
3.2. Message Format
3.2.1. 6top Information Element (IE)
6P messages travel over a single hop. 6P messages are carried as payload of an 802.15.4 Payload Information Element (IE) [IEEE802154]. The messages are encapsulated within the Payload IE header. The Group ID is set to the IETF IE value defined in [RFC8137]. The content is encapsulated by a subtype ID, as defined in [RFC8137]. Since 6P messages are carried in IEs, IEEE bit/byte ordering applies. Bits within each field in the "6top IE" subtype 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 copied to the packet in the order from the octet containing the lowest-numbered bits to the octet containing the highest-numbered bits (little endian). This document defines the 6top IE, a subtype of the IETF IE defined in [RFC8137], with subtype SUBID_6TOP. The subtype content of the 6top IE is defined in Section 3.2.2. The length of the 6top IE content is variable.3.2.2. Generic 6P Message Format
All 6P messages follow the generic format shown in Figure 6. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| T | R | Code | SFID | SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Other Fields... +-+-+-+-+-+-+-+-+- Figure 6: Generic 6P Message Format 6P Version (Version): The version of 6P. Only version 0 is defined in this document. Future specifications may define subsequent versions of 6P. Type (T): The type of message. The message types are defined in Section 6.2.2. Reserved (R): Reserved bits. These two bits SHOULD be set to zero when sending the message and MUST be ignored upon reception.
Code: The Code field contains a 6P command identifier when the 6P
message has a Type value of REQUEST. Section 6.2.3 lists the
6P command identifiers. The Code field contains a 6P return
code when the 6P message has a Type value of RESPONSE or
CONFIRMATION. Section 6.2.4 lists the 6P return codes. The
same return codes are used in both 6P Response and 6P
Confirmation messages.
6top Scheduling Function Identifier (SFID): The identifier of the SF
to use to handle this message. The SFID is defined in
Section 4.1.
SeqNum: The sequence number associated with the 6P Transaction.
Used to match the 6P Request, 6P Response, and 6P Confirmation
of the same 6P Transaction. The value of SeqNum MUST be
different for each new 6P Request issued to the same neighbor
and using the same SF. The SeqNum is also used to ensure
consistency between the schedules of the two neighbors.
Section 3.4.6 details how the SeqNum is managed.
Other Fields: The list of other fields and how they are used are
detailed in Section 3.3.
6P Request, 6P Response, and 6P Confirmation messages for a given
transaction MUST share the same Version, SFID, and SeqNum values.
Future versions of the 6P message SHOULD maintain the format of the
6P Version, Type, and Code fields for backward compatibility.
3.2.3. 6P CellOptions
An 8-bit 6P CellOptions bitmap is present in the following 6P
Requests: ADD, DELETE, COUNT, LIST, and RELOCATE. The format and
meaning of this field MAY be redefined by the SF; the routine that
parses this field is therefore associated with a specific SF.
o In the 6P ADD Request, the 6P CellOptions bitmap is used to
specify what type of cell to add.
o In the 6P DELETE Request, the 6P CellOptions bitmap is used to
specify what type of cell to delete.
o In the 6P RELOCATE Request, the 6P CellOptions bitmap is used to
specify what type of cell to relocate.
o In the 6P COUNT and LIST Requests, the 6P CellOptions bitmap is
used as a selector of a particular type of cells.
The content of the 6P CellOptions bitmap applies to all elements in
the CellList field. The possible values of the 6P CellOptions are as
follows:
o TX = 1 (resp. 0) refers to macTxType = TRUE (resp. FALSE) in the
macLinkTable of 802.15.4 [IEEE802154].
o RX = 1 (resp. 0) refers to macRxType = TRUE (resp. FALSE) in the
macLinkTable of 802.15.4.
o S = 1 (resp. 0) refers to macSharedType = TRUE (resp. FALSE) in
the macLinkTable of 802.15.4.
Section 6.2.6 provides the format of the 6P CellOptions bitmap; this
format applies unless redefined by the SF. Figure 7 shows the
meaning of the 6P CellOptions bitmap for the 6P ADD, DELETE, and
RELOCATE Requests (unless redefined by the SF). Figure 8 shows the
meaning of the 6P CellOptions bitmap for the 6P COUNT and LIST
Requests (unless redefined by the SF).
Note: Here, we assume that node A issues the 6P command to node B.
+-------------+-----------------------------------------------------+
| CellOptions | The type of cells B adds/deletes/relocates to its |
| Value | schedule when receiving a 6P ADD/DELETE/RELOCATE |
| | Request from A |
+-------------+-----------------------------------------------------+
|TX=0,RX=0,S=0| Invalid combination. RC_ERR is returned |
+-------------+-----------------------------------------------------+
|TX=1,RX=0,S=0| Add/delete/relocate RX cells at B (TX cells at A) |
+-------------+-----------------------------------------------------+
|TX=0,RX=1,S=0| Add/delete/relocate TX cells at B (RX cells at A) |
+-------------+-----------------------------------------------------+
|TX=1,RX=1,S=0| Add/delete/relocate TX|RX cells at B (and at A) |
+-------------+-----------------------------------------------------+
|TX=0,RX=0,S=1| Invalid combination. RC_ERR is returned |
+-------------+-----------------------------------------------------+
|TX=1,RX=0,S=1| Add/delete/relocate RX|SHARED cells at B |
| | (TX|SHARED cells at A) |
+-------------+-----------------------------------------------------+
|TX=0,RX=1,S=1| Add/delete/relocate TX|SHARED cells at B |
| | (RX|SHARED cells at A) |
+-------------+-----------------------------------------------------+
|TX=1,RX=1,S=1| Add/delete/relocate TX|RX|SHARED cells at B |
| | (and at A) |
+-------------+-----------------------------------------------------+
Figure 7: Meaning of the 6P CellOptions Bitmap for the
6P ADD, DELETE, and RELOCATE Requests
Note: Here, we assume that node A issues the 6P command to node B. +-------------+-----------------------------------------------------+ | CellOptions | The type of cells B selects from its schedule when | | Value | receiving a 6P COUNT or LIST Request from A, | | | from all the cells B has scheduled with A | +-------------+-----------------------------------------------------+ |TX=0,RX=0,S=0| All cells | +-------------+-----------------------------------------------------+ |TX=1,RX=0,S=0| All cells marked as RX only | +-------------+-----------------------------------------------------+ |TX=0,RX=1,S=0| All cells marked as TX only | +-------------+-----------------------------------------------------+ |TX=1,RX=1,S=0| All cells marked as TX and RX only | +-------------+-----------------------------------------------------+ |TX=0,RX=0,S=1| All cells marked as SHARED (regardless of TX, RX) | +-------------+-----------------------------------------------------+ |TX=1,RX=0,S=1| All cells marked as RX and SHARED only | +-------------+-----------------------------------------------------+ |TX=0,RX=1,S=1| All cells marked as TX and SHARED only | +-------------+-----------------------------------------------------+ |TX=1,RX=1,S=1| All cells marked as TX, RX, and SHARED | +-------------+-----------------------------------------------------+ Figure 8: Meaning of the 6P CellOptions Bitmap for the 6P COUNT and LIST Requests The CellOptions constitute an opaque set of bits, sent unmodified to the SF. The SF MAY redefine the format and meaning of the CellOptions field.
3.2.4. 6P CellList
A CellList field MAY be present in a 6P ADD Request, a 6P DELETE Request, a 6P RELOCATE Request, a 6P Response, or a 6P Confirmation. It is composed of a concatenation of zero or more 6P Cells as defined in Figure 9. The content of the CellOptions field specifies the options associated with all cells in the CellList. This necessarily means that the same options are associated with all cells in the CellList. A 6P Cell is a 4-byte field; its default format is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | slotOffset | channelOffset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: 6P Cell Format slotOffset: The slot offset of the cell. channelOffset: The channel offset of the cell. The CellList is an opaque set of bytes, sent unmodified to the SF. The length of the CellList field is implicit and is determined by the IE Length field of the Payload IE header as defined in 802.15.4. The SF MAY redefine the format of the CellList field; the routine that parses this field is therefore associated with a specific SF.
(next page on part 2)