| 6TiSCH | Q. Wang, Ed. |
| Internet-Draft | Univ. of Sci. and Tech. Beijing |
| Intended status: Informational | X. Vilajosana |
| Expires: January 5, 2015 | Universitat Oberta de Catalunya |
| T. Watteyne | |
| Linear Technology | |
| July 4, 2014 |
6TiSCH Operation Sublayer (6top)
draft-wang-6tisch-6top-sublayer-01
The recently published [IEEE802154e] standard formalizes the concept of link-layer resources in LLNs. Nodes are synchronized and follow a schedule. A cell in that schedule corresponds to an atomic link-layer resource, and can be allocated to any pair of neighbors in the network. This allows the schedule to be built to tightly match each node's bandwidth, latency and energy constraints. The [IEEE802154e] standard does not, however, present a mechanism to do so, as building and managing the schedule is out of scope of the standard. This document describes the 6TiSCH Operation Sublayer (6top) and the commands it provides to upper network layers such as RPL or GMPLS. The set of functionalities includes feedback metrics from cell states so network layers can take routing decisions, TSCH configuration and control procedures, and the support for decentralized, centralized or hybrid scheduling. In addition, 6top can be configured to enable packet switching at layer 2.5, analogous to GMPLS.
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 RFC 2119 [RFC2119].
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 January 5, 2015.
Copyright (c) 2014 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.
As presented in [I-D.ietf-6tisch-tsch], the [IEEE802154e] standard defines the mechanisms for a TSCH node to communicate, given a schedule. It does not, however, define the mechanism to build and maintain the TSCH schedule, match that schedule to the multi-hop paths maintained by a network layer such as RPL or a 2.5 layer such as GMPLS, adapt the resources allocated between neighbor nodes to the data traffic flows, enforce a differentiated treatment for data generated at the application layer and signalling messages needed by 6LoWPAN and RPL to discover neighbors, react to topology changes, self-configure IP addresses, or manage keying material.
In a TSCH network, the MAC layer is not in charge of setting up the schedule that controls the connectivity graph of the network and the resources allocated to each node in that topology. This responsibility is left to the next-higher layer, defined in this document, called "6top".
This document describes the 6TiSCH Operation Sublayer (6top) and the main commands provided to upper network layers such as RPL or GMPLS. The set of functionalities include feedback metrics from cell state so the network layer can take routing decisions, TSCH configuration and control procedures, and support for the different scheduling mechanisms defined in [I-D.ietf-6tisch-architecture]. 6top addresses the set of functionalities described in [I-D.ietf-6tisch-tsch].
For example, network formation in a TSCH network involves the transmission of Enhanced Beacons (EB). EBs include information for joining nodes to be able to synchronize and set up an initial network topology. However, [IEEE802154e] does not specify how the period of EBs is configured, nor the rules for a node to select a particular node to join. 6top offers a set of commands so control mechanisms can be introduced on top of TSCH to configure nodes to join a specific node. Once a network is formed, 6top maintains the network's health, allowing for nodes to stay synchronized. It supplies mechanisms to manage each node's time source neighbor and configure the EB interval. Network layers running on top of 6top take advantage of the TSCH MAC layer information so routing metrics, topological information, energy consumption and latency requirements can be adjusted to TSCH, and adapted to application requirements.
TSCH requires a mechanism to manage its schedule; 6top provides a set of commands for upper layers to set up specific schedules, either explicitly by detailing specific cell information, or by allowing 6top to establish a schedule given a bandwidth or latency requirement. 6top is designed to enable decentralized, centralized or hybrid scheduling solutions. 6top enables internal TSCH queuing configuration, size of buffers, packet priorities, transmission failure behavior, and defines mechanisms to encrypt and authenticate MAC slotframes.
As described in [label-switching-154e], due to the slotted nature of a TSCH network, it is possible to use a label switched architecture on top of TSCH cells. As a cell belongs to a specific track, a label header is not needed at each packet; the input cell (or bundle) and the output cell (or bundle) uniquely identify the data flow. The 6top sublayer provides operations to manage the cell mappings.
6top is a sublayer which is the next-higher layer for TSCH (Figure 1), which architecture is detailed in [I-D.ietf-6tisch-architecture], and generaic data model is detailed in [I-D.ietf-6tisch-6top-interface]. 6top offers both management and data interfaces to an upper layer. It includes monitoring and statistics collection, both of which are configurable through the management interface.
Protocol Stack
+-----------------------------------+ | PCEP | CoAP | | 6LoWPAN | | | PCC | DTLS | PANA | ND |RPL | +------------------------------------------+ | TCP | UDP | ICMP | RSVP | +------------------------------------------+ | IPv6 | +------------------------------------------+ | 6LoWPAN HC | +------------------------------------------+ | 6top | +------------------------------------------+ | IEEE802.15.4e TSCH | +------------------------------------------+ | IEEE802.15.4 | +------------------------------------------+
Figure 1
6top distinguishes between hard cells and soft cells. It therefore requires an extra flag to all cells in the TSCH schedule, as detailed in Section 2.1.
When a higher layer gives 6top a 6LoWPAN packet for transmission, 6top maps it to the appropriate outgoing priority-based queue, as detailed in Section 2.2.
All 6top commands of the management and data interfaces are detailed in Section 3. This set of commands is designed to support decentralized, centralized and hybrid scheduling solutions. They form a conceptual interface an upper layer can use; implementations can use this set of commands, or any equivalent alternative.
6top defines TSCH Information Elements (IEs) for neighbors nodes to negotiate scheduling cells in the TSCH schedule. The format of those IEs is given in Section 4.1. Example data exchanges between neighbor nodes are given in Section 4.2.
Section 5 defines how 6top gathers statistics (e.g. link quality, energy level, queue usage), and what commands an upper layer can use to configure and retrieve those statistics.
6top can be configured to monitor the cells it has scheduled in order to detect cells with poor performance. It can automatically re-allocate those cells inside the TSCH schedule. This behavior is described in Section 6
[IEEE802154e] defines a set of options attached to each cell. A cell can be a Transmit cell, a Receive cell, a Shared cell or a Timekeeping cell. These options are not exclusive, as a cell can be qualified with more than one of them. The MLME-SET-LINK.request command defined in [IEEE802154e] uses a linkOptions bitmap to specify the options of a cell. Acceptable values are:
Only Transmit cells can also be marked as Shared cells. When the shared bit is set, a back-off procedure is applied to handle collisions. Shared behavior does not apply to Receive cells.
6top allows an upper layer to schedule a cell at a specific slotOffset and channelOffset, in a specific slotframe.
In addition, 6top allows an upper layer to schedule a certain amount of bandwidth to a neighbor, without having to specify the exact slotOffset and channelOffset of the corresponding cell(s). Once bandwidth is reserved, 6top is in charge of ensuring that this requirement is continuously satisfied. 6top dynamically reallocates cells if needed, and over-provisions if required.
6top allows an upper layer to associate a cell with a specific track by using a TrackID. A TrackID is a tuple (TrackOwnerAddr,InstanceID). TrackOwnerAddr is the address of the node which initiates the process of creating the track, i.e. the owner of the track. InstanceID is an instance identifier given by the owner of the track. InstanceID comes from the upper layer; it could for example be the local instance ID defined in RPL.
If the TrackID is set to (0,0), the cell can be used by the best-effort QoS configuration or as a Shared cell. If the TrackID is not set to (0,0), i.e. the cell belongs to a specific track, the cell MUST not be set as Shared cell.
6top allows an upper layer to ask a node to manage a portion of a slotframe, called a chunk. Chunks can be delegated explicitly by the PCE to a node, or claimed automatically by any node that participates to the distributed cell scheduling process. The cells in a chunk can be appropriated by the node, i.e. the node is in charge of managing the chunk.
Given this mechanism, 6top defines hard cells (which have been requested specifically) and soft cells (which can be reallocated dynamically). The hard/soft flag is introduced by the 6top sublayer named as CellType (0: soft cell, 1: hard cell). This option is mandatory; all cells are either hard or soft.
A hard cell is a cell that cannot be dynamically reallocated by 6top. A hard cell is uniquely identified by the following tuple:
A soft cell is a cell that can be reallocated by 6top dynamically. The CellType MUST be set to 0. This cell is installed by 6top given a specific bandwidth requirement. Soft cells are installed through the soft cell negotiation procedure described in Section 4.2.
The TSCH MAC layer is decoupled from the upper layer; the interaction between the upper layer and TSCH is asynchronous. This means that the MAC layer executes a schedule and checks at each timeslot according to the type of cell(i.e Transmit, Shared or Receive), whether there is something to send or receive. If that is the case, the packet is transmitted and the MAC layer continues its operation. When an upper layer sends a packet, this packet is pushed into a queue waiting for the MAC layer to read it and send it in a particular timeslot according to its destination and priority. 6top provides a set of queue management operations which enable upper layers to create different queues and set their priorities. This allows different classes of traffic to be handled by the forwarding plane by inserting a packet into the queue appropriate for its priority.
A 6top implementation MUST provide at least a Broadcast Queue and a Transmit Queue. The Broadcast Queue is associated with cells with LinkType=ADVERTISING in the sender's schedule, and LinkOption="Receive" and "Timekeeping" in all its neighbors' schedule. For example, NodeA uses slotOffset=5 and channelOffset=12 as Broadcast cell to its neighbors NodeB and NodeC. Then, in the schedule of NodeA the cell will be featured with neighbor address is Broadcast address, LinkType=ADVERTISING; and in the schedules of both nodeB and nodeC the cell will be featured with nodeA address as neighbor address, and LinkOption="Receive" and "Timekeeping", which ensure nodeB and nodeC will be active at least one time in the cell to receive broadcast packet during a Timekeeping period. A Transmit Queue is associated with the dedicated Transmit cells or Shared Cells.
Data Communication Commands (Section 3.12) can be used to send control messages and data messages. The operation is used to insert a message into a specific queue.
For example, a configuration can include two Broadcast Queues with priority High and Low, and three Transmit Queues with priority High, Mid, and Low.
When DestAddr is the broadcast address, its related MAC layer packets will be pushed into the Broadcast Queue with the corresponding priority. 6top is responsible for feeding these packets into broadcast cells.
When DestAddr is a unicast address, its related MAC layer packets will be pushed into the Transmit Queue with the corresponding priority. 6top is responsible for feeding these packets into Transmit or Shared Cells.
The QoS policy enforced by 6top is out of scope. As an example, packets in higher priority queues could be transmitted before the packets in lower priority queue. As a result, when there is an available broadcast/unicast cell, 6top checks the broadcast/unicast queue with higher priority first. 6top continues this search until it finds a broadcast/unicast packet, or finds that all of broadcast/unicast queues are empty.
Figure 2 shows how 6top shapes data from the upper layer (e.g., RPL, 6LoWPAN), and feeds it to TSCH. The properties associated with a packet/fragment from the upper layer includes the next hop neighbor (DestAddr), the packet priority, and TrackID(s).
6top Data Transfer Model
|
| (DestAddr, Priority, Fragment)
|
+---------------------------------------+
| I-MUX |
+---------------------------------------+
| | | | |
| | | | |
+---+ +---+ +---+ +---+ +---+
| | | | | | | | | |
|Q1 | |Q2 | |Q3 | |Q4 | ... |Qn |
| | | | | | | | | |
+---+ +---+ +---+ +---+ +---+
| | | | |
| | | | |
+---------------------------------------+
| MUX |
+---------------------------------------+
|
|
+---+
|PDU|
+---+
|
| TSCH MAC-payload
|
Figure 2
In Figure 2, Qi represents a queue, which is either broadcast or unicast, and is assigned a priority. The number of queues is configurable. The relationship between queues and tracks is configurable. For example, for a given queue, only one specific track can be used, all of the tracks can be used, or a subset of the tracks can be used.
When 6top receives a packet to transmit through a Send.data command (Section 3.12), the I-MUX module selects a queue in which to insert it. If the packet's destination address is a unicast (resp. broadcast) address, it is inserted into a unicast (resp. broadcast) queue.
The MUX module is invoked at each scheduled transmit cell by TSCH. When invoked, the MUX module goes through the queues, looking for the best matching frame to send. If it finds a frame, it hands it over to TSCH for transmission. If the next active cell is a broadcast cell, it selects a fragment only from broadcast queues.
How the MUX module selects the best frame is configurable. The following rules are a typical example:
Further rules can be configured to satisfy specific QoS requirements.
6top provides a set of commands as the interface with the higher layer. Most of these commands are related to the configuration of slotframes, cells and scheduling information. 6top also provides an interface allowing an upper layer to retrieve status information and statistics. The management commands provided by 6top are listed below. Note that this set defines a conceptual interface only; an implementation can choose to use this exact set of commands, or any equivalent alternative.
Besides management commands, 6top provides the following data commands:
In addition, 6top offers a delegation interface allowing an upper layer to configure TSCH. 6top only delegates the functionalities to the MAC security services. In other words, 6top allows an upper layer to access the security PIB (Table 60, Table 61, Table 63 in [IEEE802154]) by using MLME-GET/MLME-SET primitives defined in [IEEE802154].
6top provides the following commands to manage TSCH cells.
Creates one or more hard cells in the schedule. Fails if the cell already exists. A cell is uniquely identified by the tuple (slotframe ID, slotOffset, channelOffset).
To create a hard cell, the upper layer specifies:
6top schedules the cell and marks it as a hard cell, indicating that it cannot reschedule this cell. The return value is CellID and the created cell is also filled in CellList ([I-D.ietf-6tisch-6top-interface]).
The interaction between 6top and MAC layer caused by CREATE.hardcell is as follows.
Firstly, 6top calls the primitive MLME-SET-LINK.request defined in section 6.2.19.3 of [IEEE802154e]. The primitive parameters are set as follows.
+---------------------------------+---------------------------------+ | MLME-SET-LINK.request parameter | set by 6top | +---------------------------------+---------------------------------+ | operation | ADD-LINK | +---------------------------------+---------------------------------+ | LinkHandle | CellID | +---------------------------------+---------------------------------+ | slotframeHandle | slotframe ID | +---------------------------------+---------------------------------+ | timeslot | slotOffset | +---------------------------------+---------------------------------+ | channelOffset | channelOffset | +---------------------------------+---------------------------------+ | LinkOptions | LinkOption bitmap | +---------------------------------+---------------------------------+ | LinkType | LinkType | +---------------------------------+---------------------------------+ | nodeAddr | target node address | +---------------------------------+---------------------------------+
Secondly, if the status from MLME-SET-LINK.confirm defined in section 6.2.19.4 of [IEEE802154e] is SUCCESS, then add the LinkHandle to the BundleList specified by TrackID, and confirm to upper layer with status = SUCCESS; otherwise, confirm to upper layer with status = FAIL.
To create soft cell(s), the upper layer specifies:
6top is responsible for picking the exact slotOffset and channelOffset in the schedule, and ensure that the target node choose the same cell and TrackID. 6top marks these cells as soft cell, indicating that it will continuously monitor their performance and reschedule if needed. The return value is CellID, and the created cell is also filled in CellList ([I-D.ietf-6tisch-6top-interface]).
6top deals with the allocation process by negotiation with the target node. The command returns the number and the list of created cells defined by (slotframe ID, slotOffset, channelOffset). The number of crated cells is less than the required number of cells if the required number of cells is higher than the available number of cells in the schedule. The number of created cells equals to zero if the negotiation with the target node fails. The number of created cells equals to zero if the CellType bitmap indicates that the cell(s) MUST be Hard.
The interaction between 6top and TSCH happens on both sides described as follows.
For example, after negotiation, node A and node B find a specific cell, slotOffset=10, channelOffset=12, as a Tx cell and Rx cell, respectively, then the 6top in node A and node B will call the primitive MLME-SET-LINK.request defined in section 6.2.19.3 of [IEEE802154e], respectively. The primitive parameters are set in node A and node B as follows.
+---------------------------------+---------------------------------+ | MLME-SET-LINK.request parameter | set by A's 6top | set by B's top| +---------------------------------+---------------------------------+ | operation | ADD-LINK | ADD-LINK | +---------------------------------+---------------------------------+ | LinkHandle | CellID | CellID | +---------------------------------+---------------------------------+ | slotframeHandle | slotframe ID | slotframe ID | +---------------------------------+---------------------------------+ | timeslot | 10 | 10 | +---------------------------------+---------------------------------+ | channelOffset | 12 | 12 | +---------------------------------+---------------------------------+ | LinkOptions | Tx | Rx | +---------------------------------+---------------------------------+ | LinkType | NORMAL | NORMAL | +---------------------------------+---------------------------------+ | nodeAddr | Node A | Node B | +---------------------------------+---------------------------------+
If the Status from MLME-SET-LINK.confirm defined in section 6.2.19.4 of [IEEE802154e], 6top will notify upper layer failure.
Given a (slotframe ID, slotOffset, channelOffset), retrieves the cell information. Fails if the cell does not exist. The returned information contains:
A read command can be issued for any cell, hard or soft. 6top gets cell information from CellList ([I-D.ietf-6tisch-6top-interface]).
Update a hard cell, i.e., re-allocate it to a different slotOffset and/or channelOffset. Fails if the cell does not exist. Requires both old (slotframe ID, slotOffset, channelOffset) and new (slotframe ID, slotOffset, channelOffset) as parameters. And, the type of cell, target node address and TrackID are the fields that cannot be updated. Soft cells MUST NOT be updated by the UPDATE.cell command. REALLOCATE.softcell (Section 3.1.7) MUST be used instead.
It causes a old cell being removed and a new cell being created.
To remove a hard cell, the upper layer specifies:
This removes the hard cell from the node's schedule, from CellList ([I-D.ietf-6tisch-6top-interface])as well.
The interaction between 6top and MAC layer caused by DELETE.hardcell is as follows.
Firstly, 6top calls the primitive MLME-SET-LINK.request defined in section 6.2.19.3 of [IEEE802154e]. The primitive parameters are set as follows.
+---------------------------------+---------------------------------+ | MLME-SET-LINK.request parameter | set by 6top | +---------------------------------+---------------------------------+ | operation | DELETE-LINK | +---------------------------------+---------------------------------+ | LinkHandle | CellID | +---------------------------------+---------------------------------+ | slotframeHandle | slotframe ID | +---------------------------------+---------------------------------+ | timeslot | slotOffset | +---------------------------------+---------------------------------+ | channelOffset | channelOffset | +---------------------------------+---------------------------------+ | LinkOptions | LinkOption bitmap | +---------------------------------+---------------------------------+ | LinkType | LinkType | +---------------------------------+---------------------------------+ | nodeAddr | target node address | +---------------------------------+---------------------------------+
Secondly, if the status from MLME-SET-LINK.confirm defined in section 6.2.19.4 of [IEEE802154e] is SUCCESS, then remove the LinkHandle from its BundleList specified by TrackID, and confirm to upper layer with status = SUCCESS; otherwise, confirm to upper layer with status = FAIL.
To remove a (number of) soft cell(s), the upper layer specifies:
In the case a soft cell wants to be re-allocated from the allocated cell so a hard cell can be installed instead, the REALLOCATE.softcell (Section 3.1.7) MUST be used.
After the pair of nodes figure out the specific cell(s) to be removed, the interaction between 6top and TSCH on both sides will be similar to that caused by DELETE.hardcell, except LinkType should be set to NORMAL.
To force a re-allocation of a soft cell, the upper layer specifies:
The reallocated cell will be installed in a different slotOffset, channelOffset but slotframe and TrackID remain the same. Hard cells MUST NOT be reallocated.
The interaction between 6top and TSCH caused by this command includes that described in Section 3.1.6 and Section 3.1.2.
6top provides the following commands to manage TSCH slotframes.
Creates a new slotframe. The command requires:
Fails if the number of required timeslots is less than zero.
The interaction between 6top and MAC layer caused by CREATE.slotframe is as follows.
Firstly, 6top calls the primitive MLME-SET-SLOTFRAME.request defined in section 6.2.19.1 of [IEEE802154e]. The primitive parameters are set as follows.
+---------------------------------+---------------------------------+ | MLME-SET-SLOTFRAME.request | | | parameter | set by 6top | +---------------------------------+---------------------------------+ | slotframeHandle | slotframe ID | +---------------------------------+---------------------------------+ | operation | ADD | +---------------------------------+---------------------------------+ | size | number of timeslot | +---------------------------------+---------------------------------+
Secondly, if the status from MLME-SET-SLOTFRAME.confirm defined in section 6.2.19.2 of [IEEE802154e] is SUCCESS, then confirms to upper layer with status = SUCCESS; otherwise, confirm to upper layer with status = FAIL.
Returns the information of a slotframe given its slotframe ID. The command returns:
Fails if the slotframe ID does not exist.
Change the number of timeslots in a slotframe. The command requires:
Fails if the number of required timeslots is less than zero. Fails if the slotframe ID does not exist.
The interaction between 6top and MAC layer caused by UPDATE.slotframe is as follows.
Firstly, 6top calls the primitive MLME-SET-SLOTFRAME.request defined in section 6.2.19.1 of [IEEE802154e]. The primitive parameters are set as follows.
+---------------------------------+---------------------------------+ | MLME-SET-SLOTFRAME.request | | | parameter | set by 6top | +---------------------------------+---------------------------------+ | slotframeHandle | slotframe ID | +---------------------------------+---------------------------------+ | operation | MODIFY | +---------------------------------+---------------------------------+ | size | number of timeslot | +---------------------------------+---------------------------------+
Secondly, if the status from MLME-SET-SLOTFRAME.confirm defined in section 6.2.19.2 of [IEEE802154e] is SUCCESS, then confirms to upper layer with status = SUCCESS; otherwise, confirm to upper layer with status = FAIL.
Deletes a slotframe. The command requires:
Fails if the slotframe ID does not exist.
The interaction between 6top and MAC layer caused by DELETE.slotframe is as follows.
Firstly, 6top calls the primitive MLME-SET-SLOTFRAME.request defined in section 6.2.19.1 of [IEEE802154e]. The primitive parameters are set as follows.
+---------------------------------+---------------------------------+ | MLME-SET-SLOTFRAME.request | | | parameter | set by 6top | +---------------------------------+---------------------------------+ | slotframeHandle | slotframe ID | +---------------------------------+---------------------------------+ | operation | DELETE | +---------------------------------+---------------------------------+ | size | number of timeslot | +---------------------------------+---------------------------------+
Secondly, if the status from MLME-SET-SLOTFRAME.confirm defined in section 6.2.19.2 of [IEEE802154e] is SUCCESS, then confirms to upper layer with status = SUCCESS; otherwise, confirm to upper layer with status = FAIL.
Monitoring commands provide the means for upper layers to configure whether 6top must ensure the required bandwidth. This procedure is achieved through overprovisioning according to cell status feedback. Monitoring is also in charge of reallocating soft cells that are under the required QoS.
Configures the level of QoS the Monitoring process MUST enforce. The command requires:
Fails if the slotframe ID does not exist.
Reads the current Monitoring status. Requires the following parameters.
Returns the QoS levels for that Target node on that slotframe.
Fails if the slotframe ID does not exist.
6top keeps track of TSCH statistics for upper layers to adapt correctly to medium changes. The exact metrics for statistics are out of scope but the present commands SHOULD be used to configure and read monitored information regardless of the specific metric.
Configures Statistics process. The command requires:
Fails if the slotframe ID does not exist. The statistics service can be configured to retrieve statistics at different levels. For example to aggregate information by slotframe ID, or to retrieve statistics for a particular timeslot, etc. The CONFIGURE.statistics enables flexible configuration and supports empty parameters that will force 6top to conduct statistics on all members of that dimension. For example, if ChannelOffset is empty and metric is set as PDR, then, 6top will conduct the statistics of PDR on all of channels.
Reads a metric for the specified dimension. Information is aggregated according to the parameters. The command requires:
Returns the value for the requested metric.
Fails if empty metric or metric does not exits.
Resets the gathered statistics. The command requires:
Fails if empty metric or metric does not exits.
EBs need to be configured, including their transmission period, the slotOffset and channelOffset that they SHOULD be sent on, and the join priority they contain. The parameters for that command are optional and enable flexible configuration of EBs. If slotframe ID is specified, the EBs will be configured to use that specific slotframe; if not, they will use the first slotframe where the configured slotOffset is allocated. The slotOffset enforces the EB to a specific timeslot. In case slotOffset parameter is not present, the EB is sent in the first available transmit timeslot. In case channelOffset parameter is not set, the EB is configured to use the first available channel.
Configures EBs. The command requires:
Fails if the tuple (slotframe ID, slotOffset, channelOffset) is already scheduled.
Reads the EBs configuration. No parameters are required.
Returns the current EBs configuration for that slotframe, which contains:
Fails if the slotframe ID does not exist.
Commands to select time source neighbors.
Configures the Time Source Neighbor selection process. More than one time source neighbor can be selected. The command requires:
Fails if any of the time source neighbors do not exist or it is not reachable.
Retrieves information about the time source neighbors of that node. The command does not require any parameter.
Returns the following information for each of the time sources:
Fails if the slotframe ID or no time source neighbors exist.
Commands to manage neighbor table. The commands SHOULD be used by the upper layer to query the neighbor related information and by the lower layer to keep track of neighbors information.
Creates an entry for a neighbor in the neighbor table.
Returns whether the neighbor is created or not.
Returns the list of neighbors of that node. Fails if empty. For each neighbor in the list it returns:
Returns the information of a specific neighbor of that node specified by its neighbor address. Fails if it does not exists. For that neighbor it returns:
Updates an entry for a neighbor in the neighbor table. Fails if the neighbor does not exist. Updates stats parameters. Requires:
Returns whether the neighbor is updated or not.
Deletes a neighbor given its address. Fails if the neighbor does not exists.
Queues need to be configured. This includes queue length, retransmission policy, discarding of packets, etc.
Creates and Configures Queues. The command SHOULD be applied for each required queue. The command requires:
Returns the queue ID.
Reads the queue configuration. Requires the queue ID.
The command returns:
Reads the queue stats. Requires queue ID.
The command returns:
Update a Queue. The command requires:
Deletes a Queue. The command requires the queue ID. All packets in the queue are discarded and the queue is deleted.
6top is responsible for maintaining the mapping of input cells and output cells in the same track in a particular node. By keeping that mapping, layer 3 routing can be avoided as packets are forwarded by the 6top sublayer according to the input cells they were received on. The selected output cell is one of the cells that forward the packet to the subsequent hop in the track.
The command used by an upper layer to map an input cell or a bundle of input cells to an output cell or a bundle of output cells. 6top stores this mapping and makes sure that the packets are forwarded at the specific output cell/bundle. Label Switching is enabled by the specified bundle as soon as the mapping is installed.
The required parameters are:
The command used by upper layers to unmap one input cell or a bundle of input cells to an output cell or a bundle of output cells. The mapping is removed from the state kept by 6top.
The required parameters are:
Create a chunk which consists of one or more unappropriated cells.
To create a chunk, upper layer specifies:
ChunkID is the return value of the command ([I-D.ietf-6tisch-6top-interface]). The chunk is a set of cells in the given slotframe, consisting of (slotOffset(i),channelOffset(i)), i=0..Chunksize-1, slotOffset(i)= (slotBase + i * slotStep) % slotframeLen, channelOffset(i) = (channelBase + i * channelStep) % 16". Those cells will be added into ChunkCellList ([I-D.ietf-6tisch-6top-interface]) also.
Returns the information of a chunk given its ChunkId. The command returns:
Fails if the ChunkId does not exist.
To delete a chunk, upper layer specifies ChunkID.
It removes the chunk from ChunkList ([I-D.ietf-6tisch-6top-interface]), and also remove those entries corresponding to the cells of the chunk from ChunkCellList([I-D.ietf-6tisch-6top-interface]). In addition, it also causes all of the scheduled cells in the chunk are deleted from CellList ([I-D.ietf-6tisch-6top-interface]) and TSCH schedule as well.
Creates one or more hard cells from a chunk. Fails if the cell already exists. A cell is uniquely identified by the tuple (slotframe ID, slotOffset, channelOffset).
To create a hard cell from a chunk which is corresponding to a specific slotframe ID, the upper layer specifies:
6top schedules the cell and marks it as a hard cell, indicating that it cannot reschedule this cell. In addition, 6top will change the attributes corresponding to the cell in the ChunkCellList, i.e. its CellID is changed to the same CellID in the CellList, and its Status is changed to USED ([I-D.ietf-6tisch-6top-interface]).
The interaction between 6top and MAC layer caused by CREATE.hardcell.fromchunk is same as that caused by CREATE.hardcell (Section 3.1.1).
Returns the cell information of a chunk given its ChunkId. For each cell of the chunk, the command returns:
Fails if the ChunkId does not exist.
To remove a hard cell which comes from a chunk, the upper layer specifies:
This removes the hard cell from the node's schedule and CellList ([I-D.ietf-6tisch-6top-interface]). In addition, it changes the attributes corresponding to the cell in the ChunkCellList, i.e. its CellID is changed back to FFFF, and its Status is changed to UNUSED ([I-D.ietf-6tisch-6top-interface]).
The interaction between 6top and MAC layer caused by DELETE.hardcell is same as that caused by DELETE.hardcell (Section 3.1.5).
The command used by upper layers to queue a packet so underlying TSCH sends it. According to the specific priority, the packet is pushed into a Queue with the equivalent priority or following a criteria out of scope. Once a packet is inserted into a queue it waits to be transmitted by TSCH according to the model defined in Section 2.2. If the queue is full or destination address is not a L2 neighbor of the node, failure to enqueue will be indicated to the caller.
The required parameters are:
The command is invoked whenever a packet is received and inserted into a reception queue. The method acts as a callback function to notify to the upper layers the received message. Upper layers MUST terminate this indication.
The function has the following parameters:
This section defines the Information Element (IE) based message formats, and the 6top-to-6top communication time sequences.
6top has to negotiate the scheduling of soft cells with neighbor nodes. This negotiation happens through 6top-specific TSCH Information Elements, the format of which is defined in this section. For completeness, this section also details the formats of the IEs already defined in [IEEE802154e] and presented here without modification.
6top messages can contain one or more IEs. Section 4.1.1 defines the different IEs used by 6top, both the ones used without modification from [IEEE802154e], and the new ones defined by this document. Section 4.1.2 shows how several IEs are assembled to form the different frames used by 6top.
[IEEE802154e] defines Information elements (IEs). IEs are formatted data objects consisting of an ID, a length, and a data payload used to pass data between layers or devices. [IEEE802154e] defines Header IEs and Payload IEs; 6top only uses Payload IEs. A Payload IE includes one or more IEs, and ends with a termination IE (ID = 0x0f, see [IEEE802154e]).
6top uses the following Information Elements, some defined in [IEEE802154e], others introduced in this document.
A Synchronization IE (SyncIE) contains Information allowing a node to synchronize to a TSCH network, including the current ASN and a join priority. Synchronization IE MUST be included in all TSCH Enhanced Beacons.
6top re-uses this IE as defined in [IEEE802154e].
Format of a TSCH Synchronization IE (SyncIE).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | SubID |T| ASN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASN | Join Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3
Length=6
SubID=0x1a
T=0, i.e., short type
ASN (5 octets) contains the Absolute Slot Number corresponding to the timeslot in which the TSCH Enhanced Beacon is sent.
The Join Priority can be used by a joining device to select among beaconing devices when multiple beacons are heard. The PAN coordinator's join priority is zero. A lower value of join priority indicates that the device is the preferred one to connect to. As suggested by [I-D.ietf-6tisch-minimal], the beaconing device's join priority is its DAGRank(rank).
The Slotframe and Link IE (FrameAndLinkIE) contains one or more slotframes and their respective cells that a beaconing device advertises to allow other devices to join the network.
6top re-uses this IE as defined in [IEEE802154e].
Format of a TSCH Slotframe and Link IE (FrameAndLinkIE).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | SubID |T| NumFrame | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
// Slotframe and cell information //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4
Length=variable
SubID=0x1b
T=0, i.e., short type
NumFrame is set to the total number of slotframe descriptors contained in the TSCH Enhanced Beacon.
Format of a slotframe descriptor.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FrameID | FrameLen | NumCell |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Cell information for each cell (5x NumCell) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5
The FrameID field shall be set to the slotframeHandle that uniquely identifies the slotframe.
The FrameLen field shall be set to the size of the slotframe in number of timeslots.
The NumCell field shall be set to the number of cells that belong to the specific slotframe identified by the slotframeHandle.
Format of a Cell information.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LinkOption |
+-+-+-+-+-+-+-+-+
Figure 6
SlotOffset shall be set to the slotOffset of this cell.
ChannelOffset shall be set to the channelOffset of this cell.
LinkOption indicates whether this cell is a TX cell, an RX cell, or a SHARED TX cell, whether the device to which it is being linked is to be used for clock synchronization, and whether this cell is hard cell.
Timeslot Template IE (SlotTemplateIE) defines Timeslot template being used by the TSCH device.
6top re-uses this IE as defined in [IEEE802154e].
Format of a TSCH Timeslot Template IE (SlotTemplateIE).
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | SubID |T| TemplateID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7
Length=1
SubID=0x1c
T=0, i.e., short type
TemplateID shall be set to a Timeslot template handle. The full timeslot template, which contains the macTimeslotTemplate of TSCH (total 25 octets), MAY be included.(see [IEEE802154e]).
Channel Hopping IE (ChHoppingIE) defines the Hopping Sequence being used by the TSCH device.
6top re-uses this IE as defined in [IEEE802154e].
Format of a TSCH Channel Hopping IE (ChHoppingIE).
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | SubID |T| HopSequenceID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8
Length=1
SubID=0x09
T=1, i.e., long type
HopSequenceID shall be set to a Hopping Sequence handle. The full Hopping Sequence information MAY be included. (see [IEEE802154e]).
6top Opcode IE (OpcodeIE) defines operation codes of packets in 6top sublayer.
This IE is not present in [IEEE802154e] and is defined by 6top.
Format of a 6top Opcode IE (OpcodeIE).
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | SubID |T| OpcodeID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9
Length=1
SubID=0x41
T=0, i.e., short type
OpcodeID field shall be set to one of the following codes.
Bandwidth IE (BwIE) defines the number of cells to be reserved or actually been reserved.
This IE is not present in [IEEE802154e] and is defined by 6top.
Format of a 6top Bandwidth IE (BwIE).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | SubID |T| FrameID | NumCell |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10
Length=2
SubID=0x42
T=0, i.e., short type
FrameID MAY be set to the SlotFrameHandle to identify the slotframe from which cells are reserved. FrameID field MAY be set to NOP, which means no specific slotframe is associated.
NumCell shall be set to the number of cells. When BwIE is combined with the OpecodeID of Reserve Soft Cell Request, NumCell presents how many cells are required to reserve; and when BwIE is combined with the OpecodeID of Reserve Soft Cell Response, NumCell presents how many cells are reserved successfully.
TrackID IE (TrackIdIE) describes the track which the reserved/removed cell(s) are associated with.
This IE is not present in [IEEE802154e] and is defined by 6top.
Format of a 6top TrackID IE (TrackIdIE).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | SubID |T|OwnerInstID|rev| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
// //
| TrackOwnerAddr |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11
Length=3 or 7. When length=3, TrackOwnerAddr is 2 bytes short address, and when length=7, TrackOwnerAddr is 6 bytes long address.
SubID=0x43
T=0, i.e., short type
The combination of TrackOwnerAddr and OwnerInstId represents a specific TrackID.
Generic Schedule IE (ScheduleIE) describes cell sets. In different packets, ScheduleIE represents different information. See Section 4.1.2 for more detail.
This IE is not present in [IEEE802154e] and is defined by 6top.
Format of a 6top Generic Schedule IE (ScheduleIE).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | SubID |T| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
// Schedule Body //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12
Length=variable
SubID=0x44
T=0, i.e., short type
Schedule Body carries one or more schedule object. An object MAY carry a TLV (Type-Length-Value), which MAY itself comprise other TLVs. TLV format is as follows. Type: 1 byte, Length: 1 byte, Value: variable
The following are some examples of schedule object TLV.
Example 1. Cell Set TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=1 | Length | FrameID | NumCell |F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// CellObjects //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13
FrameID shall be set to the slotframeHandle that uniquely identifies the slotframe.
NumCell shall be set to the number of cells that belong to the specific slotframe identified by the slotframeHandle.
F=1 means the specified cells equals to what are listed in CellObjects, and F=0 means the specified cells equals to what are not listed in CellObjects.
CellObjects carries the information for one or more cells, including SlotOffset, ChannelOffset, LinkOption (Figure 6).
Example 2. Schedule Matrix TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=2 | Length | FrameID |StartSlotOffset|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|StartSLotOffset| NumSlot | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
// SlotBitMap (2x NumSlot) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14
FrameID field MUST be set to the slotframeHandle that uniquely identifies the slotframe.
StartSlotOffset field (2 octets) MUST be set to the slotOffset in the specific slotframe identified by the slotframeHandle.
NumSlot field MUST be set to the number of timeslots from StartSlotOffset in the specific slotframe identified by the slotframeHandle.
SlotBitMap (per timeslot) indicates for the given timeslot which channels are specified. For the 16 channels in 2.4GHz band, 2-octets are used to indicate which channel is specified. For example, given a timeslot and a SlotBitmap with value (10001000,00010000); the bitmap represents that ChannelOffset-0, ChannelOffset-4, ChannelOffset-11 are specified.
This section describes the packets used in 6top to form a network, reserve/maintain bandwidth using soft cells, and reserve/remove hard cells in both the transmitter side and receiver sides. Each of these packets uses one or more IEs defined in Section 4.1.1.
The TSCH Enhanced Beacon is used to announce the presence of the network and allows new nodes to join. It is an Enhanced Beacon packet defined in [IEEE802154e] with the following Payload IEs:
Payload IE of TSCH Enhanced Beacon Packet
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |GroupID|T| SyncIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SyncIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SyncIE | SlotTemplateIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SlotTemplateIE | ChHoppingIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// FrameAndLinkIE //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15
Length=variable
GroupID=0x1, i.e., MLME IE
T=1, i.e., payload IE
See Section 4.1.1.1, Section 4.1.1.3, Section 4.1.1.4,Section 4.1.1.2 for SyncIE, SlotTemplateIE, ChHoppingIE and FrameAndLinkIE.
A Soft Cell Reservation Request packet is a DATA packet defined in [IEEE802154e] with the following payload IE.
Payload IE of Soft Cell Reservation Request
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |GroupID|T| OpcodeIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpcodeIE | BwIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BwIE | |
+-+-+-+-+-+-+-+-+ |
// ScheduleIE //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16
Length=variable
GroupID=0x1, i.e., MLME IE
T=1, i.e., payload IE
The OpcodeID field in the 3-octet OpcodeIE SHOULD be set to 0x00, indicates Reserve Soft Cell Request operation.
The NumCell field in 4-octet BwIE SHOULD be set to the number of cells needed to be reserved.
The ScheduleIE specifies a candidate cell set, from which the cells SHOULD be reserved. ScheduleIE MAY be empty, means there is no constrain on which cells SHOULD not be reserved.
In addition, TrackIdIE can be added in the packet to associate the reserved soft cells to a specific TrackID.
Soft Cell Reservation Response is a DATA packet defined in [IEEE802154e] with the following payload IE.
Payload IE of Soft Cell Reservation Response
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |GroupID|T| OpcodeIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpcodeIE | BwIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BwIE | |
+-+-+-+-+-+-+-+-+ |
// ScheduleIE //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17
Length=variable
GroupID=0x1, i.e., MLME IE
T=1, i.e., payload IE
The OpcodeID field in the 3-octet OpcodeIE SHOULD be set to 0x01, indicates Reserve Soft Cell Response operation.
The NumCell field in 4-octet BwIE SHOULD be set to the number of cells which have been reserved successfully.
The ScheduleIE SHOULD specify all of the cells which have been reserved successfully.
In addition, TrackIdIE can be added in the packet to associate the reserved soft cells to a specific TrackID.
Soft Cell Remove Request is a DATA packet defined in [IEEE802154e] with the following payload IE.
Payload IE of Soft Cell Remove Request
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |GroupID|T| OpcodeIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpcodeIE | |
+-+-+-+-+-+-+-+-+ |
// ScheduleIE //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18
Length=variable
GroupID=0x1, i.e., MLME IE
T=1, i.e., payload IE
The OpcodeID field in the 3-octet OpcodeIE SHOULD be set to 0x02, indicates Remove Soft Cell Request operation.
The ScheduleIE SHOULD specify all the cells that need to be removed.
Hard Cell Reservation Request packet is a DATA packet defined in [IEEE802154e] with the following payload IE.
Payload IE of Hard Cell Reservation Request
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |GroupID|T| OpcodeIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpcodeIE | |
+-+-+-+-+-+-+-+-+ |
// ScheduleIE //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19
Length=variable
GroupID=0x1, i.e., MLME IE
T=1, i.e., payload IE
The OpcodeID field in the 3-octet OpcodeIE SHOULD be set to 0x03, indicates Reserve Hard Cell Request operation.
The ScheduleIE SHOULD specify all the cell that need to be reserved.
In addition, TrackIdIE can be added in the packet to associate the reserved hard cells to a specific TrackID.
Hard Cell Remove Request is a DATA packet defined in [IEEE802154e] with the following payload IE.
Payload IE of Hard Cell Remove Request
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |GroupID|T| OpcodeIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpcodeIE | |
+-+-+-+-+-+-+-+-+ |
// ScheduleIE //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20
Length=variable
GroupID=0x1, i.e., MLME IE
T=1, i.e., payload IE
The OpcodeID field in the 3-octet OpcodeIE SHOULD be set to 0x04, indicates Remove Hard Cell Request operation.
The ScheduleIE SHOULD specify all the cells that need to be removed.
6top neighbors exchange 6top-specific packets in the following cases, each detailed in a subsection.
Network formation consists of two processes: joining and maintenance.
A node already in the network sends out TSCH Enhanced Beacons periodically.
When a node is joining an existing network, it listens for TSCH Enhanced Beacons. After collecting one or more TSCH Enhanced BEACONs (the format of which is detailed in Section 4.1.2.1), the joining node MUST do the following.
Nodes MAY broadcast Enhance Beacons on the cells marked with LinkType=ADVERTISING, and listen for Enhanced Beacons from neighbors on the cells with LinkOptions "Receive" and "Timekeeping". If a cell with LinkType=ADVERTISING has both the "Receive" and "Timekeeping" LinkOptions set, which means that the cell is shared by neighbors and itself for broadcasting, then broadcasting Enhanced Beacon has higher priority.
Whenever a node receives an Enhanced Beacon, it SHOULD update its schedule if there is a difference regarding to the cells used for synchronizing with the advertiser of the Enhanced Beacon.
The upper layer instructs 6top to schedule one or more soft cells by calling the Create soft cell command. This command can also be called by the monitoring process internal to 6top.
When receiving a Create soft cell command, Node A's 6top sublayer forms a Soft Cell Reservation Request packet which includes the BwIE and ScheduleIE Information Elements. The BwIE indicates the number of cells to be reserved (N1); the ScheduleIE indicates set of a candidate cells from which the new cells SHOULD be selected. If the ScheduleIE is empty, Node A indicates there is no constraint on cell selection.
The Soft Cell Reservation Request is sent to the neighbor (Node B) with whom new cells need to be scheduled. After receiving the Soft Cell Reservation Request, Node B selects the cells from the candidate cell set defined by the ScheduleIE in the Soft Cell Reservation Request, and forms a Soft Cell Reservation Response packet. In the Cell Reservation Response packet, the BwIE indicates the number of cells actually being reserved (N2); the ScheduleIE indicates those reserved cells. If N2 is smaller than N1, node B indicates to node A that there are not enough qualified cells to be reserved. Node B MUST record the reserved cells into its local schedule when sending the Soft Cell Reservation Response. After receiving the Soft Cell Reservation Response, Node A MUST record the reserved cells into its local schedule.
The policy to build a candidate cell set and the policy to select cells from the candidate cell set to reserve are out of scope.
The format of Schedule Body is flexible. For example, Node A can use Cell Set TLV defined in Figure 13 with field 'F' set to '0', and the CellObjects includes all of the cells being used by Node A. In another word, the cell candidate set is all of the cells not being included in the list defined by CellObjects.
The behavior of the nodes when the soft cells negotiation fails is out of scope.
The upper layer instructs 6top to delete one or more soft cells by calling the Delete soft cell command (Section 3.1.6). This command can also be called by the monitoring process internal to 6top (Section 6).
When receiving a Delete soft cell command, Node A's 6top sublayer selects cells to be removed from its local schedule, and creates a Soft Cell Remove Request, which includes a ScheduleIE Information Element. The ScheduleIE indicates which specific cells to remove with a neighbor (Node B). The cells specified in the ScheduleIE SHOULD be removed from local schedule of Node A when the Soft Cell Remove Request is sent to Node B. When receiving the Soft Cell Remove Request, the cells specified in the ScheduleIE SHOULD be removed from the local schedule of Node B.
The policy to select cells corresponding to a Delete soft cell command is out of scope.
The monitoring process internal to 6top (Section 6) is responsible for monitoring and re-scheduling soft cells to meet some QoS requirements. The monitoring process MAY issue a soft cell Maintenance command, which indicate a set of cells to be re-allocated in the TSCH schedule.
When receiving a soft cell Maintenance command, 6top initializes a Soft Cell Remove Request (Section 4.2.3) with the neighbor in question, followed by a Soft Cell Reservation Request (Section 4.2.2).
The upper layer instructs 6top to create one or more hard cells by calling the Create hard cell command.
When receiving a Create hard cell command, Node A's 6top sublayer creates a Hard Cell Reservation Request, including a ScheduleIE. The ScheduleIE indicates which specific cells with a neighbor (Node B) to be added. The cells specified in the ScheduleIE SHOULD be added in local schedule of Node A while the Hard Cell Reserve Request is sent to Node B. When receiving the Hard Cell Reserve Request, the cells specified in the ScheduleIE SHOULD be added in the local schedule of Node B.
The upper layer instructs 6top to delete one or more hard cells by calling the Delete hard cell command.
When receiving a Delete hard cell command, Node A's 6top sublayer creates a Hard Cell Remove Request, including a ScheduleIE. The ScheduleIE indicates which specific cells with a neighbor (Node B) to be removed. The cells specified in the ScheduleIE SHOULD be removed from local schedule of Node A while the Hard Cell Remove Request is sent to Node B. When receiving the Hard Cell Remove Request, the cells specified in the ScheduleIE SHOULD be removed from the local schedule of Node B.
The 6top Statistics Function (SF) is responsible for collecting statistics, which it can provide to an upper layer and the Monitoring Function (Section 6).
6top is in charge of keeping statistics from a set of metrics gathered from the behavior of the TSCH layer.
The statistics data related to node states and cell metrics SHOULD be provided to upper layer for management, e.g., for RPL to calculate the node's Rank or for GMPLS to the required bandwidth is met. The specific algorithm to generate the statistics is out of scope. However, the statistics component SHOULD include the following metrics:
The Statistics Function SHOULD be configurable. The configuration parameters SHOULD include:
6top statistics function is enabled/disabled and configured by the commands defined in Section 3.4
The 6top Monitoring Function (MF) is responsible for monitoring cell quality, traffic load, and issuing soft cell Maintenance commands, or Create/Delete soft cell commands. The data provided by the Statistics Function MAY be used as an input of MF in taking a monitoring decision.
Monitoring Function SHOULD be configurable. The configuration parameters SHOULD include:
The 6top monitoring function is enabled/disabled and configured by the commands defined in Section 3.3
The cell quality statistics MAY be used to generate soft a cell Maintenance command, which triggers a soft cell Maintenance procedure (see Section 4.2.4). The traffic load statistics MAY be used to generate internal Create (resp. Delete) soft cell commands, which trggiers a soft cell Reservation (resp. Remove) process (see Section 4.2.2 and Section 4.2.3).
The policy to generate the soft cell Maintenance command and the policy to generate Create/Delete soft cell commands is out of scope.
The policy to generate Create/Delete soft cell commands MAY take QosLevel into account. For example, there are two slotframes existing, Slotframe-1 consists of 32 timeslots, Slotframe-2 consists of 96 timeslots; timeslot duration is 10ms; QosLevel=1.5. If, from the traffic load statistics, MF determines that 2 packet/second SHOULD be added, then the MF generates a Create soft cell command, where FrameID=2, NumCell=3.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [I-D.ietf-6tisch-tsch] | Watteyne, T., Palattella, M. and L. Grieco, "Using IEEE802.15.4e TSCH in an LLN context: Overview, Problem Statement and Goals", Internet-Draft draft-ietf-6tisch-tsch-00, November 2013. |
| [I-D.ietf-6tisch-architecture] | Thubert, P., Watteyne, T. and R. Assimiti, "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4e", Internet-Draft draft-ietf-6tisch-architecture-02, June 2014. |
| [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-01, February 2014. |
| [I-D.ietf-6tisch-minimal] | Vilajosana, X. and K. Pister, "Minimal 6TiSCH Configuration", Internet-Draft draft-ietf-6tisch-minimal-01, June 2014. |
| [I-D.ietf-6tisch-6top-interface] | Wang, Q., Vilajosana, X. and T. Watteyne, "6TiSCH Operation Sublayer (6top) Interface", Internet-Draft draft-ietf-6tisch-6top-interface-00, March 2014. |
| [I-D.wang-6tisch-6top-sublayer] | Wang, Q., Vilajosana, X. and T. Watteyne, "6TiSCH Operation Sublayer (6top)", Internet-Draft draft-wang-6tisch-6top-sublayer-00, February 2014. |
| [I-D.ietf-6tisch-coap] | Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and Interaction using CoAP", Internet-Draft draft-ietf-6tisch-coap-00, May 2014. |
| [IEEE802154e] | IEEE standard for Information Technology, "IEEE std. 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) Amendment 1: MAC sublayer", April 2012. |
| [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] | 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. |
| [label-switching-154e] | Morell, A., Vilajosana, X., Lopez-Vicario, J. and T. Watteyne, "Label Switching over IEEE802.15.4e Networks. Transactions on Emerging Telecommunications Technologies", June 2013. |