6TISCH Adaptation Layer

What needs does the 6Tisch layer respond to ?

Quick Reminder
under TSCH, transmissions are organized within a recurring slotframe. In this slotframe, each
individual transmission scheduled, called a cell, is positioned in time at a specific timeslot and in
trequence at a specific channel offset, forming a (timeslot, channel offset) pair. Each cell can be
reserved for a specific node to receive and/or to transmit a packet. The cell can also be dedicated to
a unicast link, or shared among multiple nodes, typically for control packets. In the latter case, the
nodes use a contention-based (i.e., random access) method to access the radio channel.

Nodes wishing to join the network must synchronize themselves with the slotframe. Thus, a special
control frame at the MAC layer, known as the Enhanced Beacon (EB), is periodically sent over the air
to announce the slotframe characteristics and beginning. This message, usually sent in the (0, 0) cell,
contains, among other things, the size of the slotframe, the number of channels available and the
current ASN value.

Limitations
The IEEE Std 802.15.4-2015 TSCH standard does not define the strategies to construct and maintain
the schedule of cells within the slotframes, just the concept of cells and how they must be
interpreted by the MAC layer to perform transmissions and receptions. Instead, the management of
this schedule is left to external entities. These solutions can be either centralized, where a node is
selected as a coordinator for the entire network, or distributed, where each node makes its decisions
locally in collaboration with its neighbors. While the latter is more suited to larger and somewhat
unstable networks, the lack of a global network view makes it harder for these to ensure efficient
multi-hop communication.
Another solution, the Minimal Scheduling Function (MSF) , currently worked on by the IPv6 over the
TSCH mode of IEEE 802.15.4e (6TiSCH)  Working Group (WG) at the IETF, provides a reactive
algorithm which can adapt to traffic variations and collisions, displacing conflicting cells or allocating
new cells when needed.

6TiSCH Architecture
The 6TiSCH WG envisions an IPv6-based wireless sensor network architecture based on TSCH that
aims for high-reliability packet delivery. To this end, it defines the following network stack:
6TiSCH defines scheduling functions which implement distributed slotframe scheduling strategies and
the 6TiSCH operation sublayer (6top)  which supports the negotiation of cells between neighboring
nodes.

6TiSCH Operation Sublayer

6P , defines the messages and transaction mechanisms to add, delete, or relocate cells within the
slotframe.

Additionally, it also provides commands to count, list, or clear all the cells reserved for
communication between two nodes as well as a signaling mechanism for proper operation of the
scheduling functions. The decision of when and how many cells to add or delete is left to a 6TiSCH
Scheduling Function (SF).

Minimal Scheduling Function (MSF)

The 6P protocol only provides the necessary transactions to manipulate cells in each node’s
schedule. It is up to the scheduling functions to decide when to add or delete cells from those
schedules. To this end, the 6TiSCH WG proposes a reactive and distributed scheduling solution
known as the Minimal Scheduling Function (MSF). This scheduling function defines the bootstrapping
process for a node to join the network and a subsequent mechanism for each node to adapt to traffic
changes, routing changes, and schedule collisions.
Resource management using 6p and msf
Explanation of 6P and the MSF
6p

In this case, node A requests from node B the addition of two new cells to its own (A’s) schedule.

To this end, the scheduling function on node A proposes a list of three candidate cells and locks
those in its schedule until a 6P response is received.

When the request is successfully delivered to node B, indicated by the reception of a MAC-layer ACK
by node A, node A also starts a timeout to abort the transaction if no response is received for its
request.

The scheduling function on node B selects two cells among the proposed candidates and locks
those in its schedule until the response has been successfully received.
Minimal Scheduling Function

Types of Cells

MSF relies on 3 different types of cells for its operations: the minimal cell, autonomous cells and ne-
gotiated cells. In case multiple cells are scheduled at the same timeslot and channel offset, the mi-
nimal cell has the highest priority, followed by autonomous cells and finally negociated cells(for
new nodes).

The minimal cell is a single mandatory(obligatoire) shared cell used to bootstrap the network and
ensure minimal connectivity. It is used to exchange the Enhanced Beacons advertising the network
and its configuration. The minimal cell is usually located at timeslot 0 and channel offset 0.

Addition / Deletion Rules

MSF dynamically adapts the number of negotiated cells of each node. This happens in the three
following cases.

 Firstly, when the available link-layer resources need to be adapted to the current traffic
load.
 Secondly, when a new preferred parent is selected, as part of RPL operations and cells
must be re-negotiated.
 Finally, when certain cells experiencing excessive schedule collisions need to be relocated.

Adapting to Traffic Changes

A node adapts its number of negotiated cells when it detects a significant increase or decrease in traf -
fic. To this end, it estimates the traffic load over a recent window of time expressed as a number of
cells. This is done by maintaining a pair of counters (NumCellsUsed and NumCellsPassed) per neighbor
and per traffic direction. In the following discussion we only consider traffic going upstream, through
the preferred parent. NumCellsPassed counts the elapsed number of scheduled cells to the preferred
parent whether or not they resulted in a transmission, while NumCellsUsed counts the subset of those
cells that were used for a transmission, whether or not that transmission was successful.

A node updates and adapts its schedule after a certain number of cells, MAX_NUM_CELLS, has passed,
that is, when NumCellsPassed > MAX_NUM_CELLS. At the time of decision, its estimate of the current
traffic load is \frac{NumCellsUsed}{MAX\_NUM\_CELLS} MAX_NUM_CELLSNumCellsUsed, which is
used with hysteresis to decide if cells must be requested or deleted. To this end, if NumCellsUsed >
LIM_NUMCELLSUSED_HIGH, then the node uses 6P to add a single negotiated cell. Otherwise, if Num-
CellsUsed< LIM_NUMCELLSUSED_LOW, then the node uses 6P to remove a single negotiated cell. In
any case, the node afterwards resets both counters (NumCellsPassed, NumCellsUsed) to 0.
This behavior is illustrated in the following figure:

Handling Schedule Collisions

Since the schedule is constructed in a distributed fashion, there is a possibility for two pairs of nearby
neighbor nodes to schedule over the same cell (timeSlot, channelOffset). This could result in a colli-
sion if both pairs of nodes try to exchange packets at the same time.

A node detects such collisions with the use of two counters per each negotiated TX cell. NumTx counts
the number of times a node tried to transmit a packet while NumTxAck counts the number of times
such transmission is successful, that is, the number of transmissions for which an acknowledgment
was received.

The value of both counters is divided by 2 when NumTx reaches 256. Thus, the counters can incre-
ment continuously without changing the value of the CDR.

How to build an MSF Schedule

Explanation of the MSF parameters
Configurable parameters

SLOTFRAME_LENGTH

Default value: 101 timeslots

This is the the slotframe length, which also defines the time period of the schedule repetition. A
bigger slotframe length will provide more “space” to allocate cells, but these will repeat with a lo-
wer frequency due to the increased length. The converse holds for smaller slotframe lengths.
MAX_NUM_CELLS
Default value: 100 cells

The MAX_NUM_CELLS value configures the time period of re-evaluation of link needs. The value
should depend on what kind of traffic the network has. 

Higher values lead to better accuracy in estimating the real cell usage by network traffic.

Additionally, since 6P ADD or DEL(ete) transactions are triggered after each MAX_NUM_CELLS per-
iod, increasing this value leads to fewer such 6P transactions and therefore lower overhead (re-
member that 6P transactions use at a minimum two cells for a 2-step transaction, excluding MAC-
layer retransmissions).

Periodic and constant traffic

If the traffic is periodic and constant, then after the initial time to allocate the needed cells when a
new node initializes, the value of MAX_NUM_CELLS will not affect adaptation latency.

However, the time needed for a new node to allocate the required cells is affected by the
MAX_NUM_CELLS value, with higher values leading to higher delays in allocating the cells.

Bursty or irregular traffic

If the traffic is bursty or irregular, then adaptation latency will be higher since adapting to the new
and fluctuating value will take longer, having to wait for a larger MAX_NUM_CELLS time period to
pass before cells can be added or removed.

LIM_NUMCELLSUSED_HIGH
Default value: 75 cells

This value is used as the upper threshold when, after a MAX_NUM_CELLS period has elap-
sed, the MSF needs to decide whether to allocate or deallocate a cell. More specifically, if
NumCellsUsed > LIM_NUMCELLSUSED_HIGH, then the node uses 6P to add a single nego-
tiated cell.

Setting this value too high will result in allocation of new cells to only happen when the
link is already very saturated, and thus risking that packets are lost due to packet buffer
overflows.

Conversely, if a too low value is used, then the node will very eagerly allocate new cells,
even if only transient needs are presented, and as a result cells will be over-allocated lea-
ding to network and energy overheads. Additionally, more 6P ADD transitions will be is-
sued which add their own network and energy overhead.
LIM_NUMCELLSUSED_LOW
Default value: 25 cells

This value is used as the lower threshold when, after a MAX_NUM_CELLS period has elap-
sed, the MSF needs to decide whether to allocate or deallocate a cell. More specifically, if
NumCellsUsed < LIM_NUMCELLSUSED_LOW, then the node uses 6P to remove a single ne-
gotiated cell.

Setting this value too low will result in de-allocation of existing cells to only happen when
the link is barely used, thus delaying the deallocation and incurring network and energy
overheads through over-allocated resources.

Conversely, if a too high value is used, then the node will very eagerly de-allocate existing
cells, and thus when minor additional traffic requirements are made, the lack of resources
will lead to increased risks of packet losses due to packet buffer overflows or to increased
packet transmission latency due to increased packet queue lengths.

Additionally, more 6P DEL transitions will be issued which add their own network and
energy overhead.
How a node connects to an existing network