TSCH Evaluation under heterogeneous Mobile Scenarios

Time Slotted Channel Hopping (TSCH) is a Medium Access Control (MAC) protocol for Internet of Things (IoT) applications, which has been used broadly in industry since it can offer high level of reliability and robustness [12]. TSCH is implemented as a channel hopping mechanism to avoid interference and multi-path fading which Low-power and Lossy Networks (LLN) are prone to. Furthermore, all devices in a TSCH network are synchronized to a common time source, the coordinator node. Essentially all the nodes are synchronized (with a tolerated offset) and a schedule is calculated. The purpose of the schedule is to dictate which node is supposed to perform an action (receive, transmit, sleep), on which channel and at which point in time.

The modular nature of TSCH has enabled high flexibility and therefore, there are numerous application scenarios which have utilized the TSCH mechanism. Industrial monitoring [8], environmental monitoring[21], smart home for healthcare[13], smart buildings [6] and many more. Since there are different requirements in every application scenario, there are several modified versions of TSCH in this regard. One common way to tailor TSCH based on the application requirements is to have a different approach on the scheduling scheme. Thus, there is a rich scientific literature describing different scheduling approaches for TSCH which can be summarized in three main categories: centralized, distributed, autonomous. In centralized scheduling [8] a node is responsible to calculate the schedule and distribute it to the rest nodes. In distributed scheduling approaches, the schedule is constructed based on the relations between neighboring nodes [7]. In the autonomous approaches each node is constructing its own schedule mostly based on routing information that are present on the node already [11].

Several aspects of TSCH have been explored such as energy consumption [20], scalability [14, 11], and latency[9]. However it is still unclear how a TSCH network is performing under a mobile scenario since that topic is not explored thoroughly in the scientific literature. The mobility feature in IoT is emerging as application scenarios like autonomous robots and vehicles [18] operate in remote areas in some cases, where there is no access on cellular network. Furthermore other applications like warehouse logistics [16] for instance, where a synergy of moving machinery, autonomous robots/vehicles and workers might require low power mobile communication to fulfil the application requirements.

In this paper, the main research question we try to answer is how reliable are the current TSCH schedulers under different mobile scenarios. We consider two mobile scenarios and based on simulations we evaluate three different schedulers to examine the reliability of TSCH. Specifically we evaluate how mobility affects its reliability in terms of Packet Received Ratio (PRR), downtime, and the initial joining time. In addition we consider how different number of nodes in a network architecture would impact the network reliability. The results illustrate that the current TSCH approaches do not operate efficiently in that cases and we provide some proposals towards improving them. As a main evaluation tool we use Cooja [17] simulator.

The rest of the paper is organized as follows: Section II describes basic principles of TSCH and the schedulers used in this paper, Section III lists the state of the art and how it relates to the presented approach. Section IV illustrates the technical details and motivation behind the selected mobility patterns and the representing applications, Section V presents the evaluation method and the obtained results and Section VI discusses future work and concludes the paper.

This section provides a technical overview of TSCH protocol and the TSCH schedulers which are used in the evaluation part. TSCH is included in the IEEE 802.15.4 [3] standard which is in an amendment in IEEE 802.15.4e-2015 [2].

TSCH is a link layer protocol which utilizes frequency hopping and synchronization techniques. Essentially neighboring nodes can transmit and receive packets based on a scheduler which defines the time slot and the channel. In order to avoid collisions it should not be allowed multiple packet transmission at the same time and channel. Thus, the schedule is organized in a two dimensional table called slotframe. Figure 1 depicts a slotframe along with the assumed topology. The $x$ axis in the slotframe stands for the time offset and the $y$ axis stands for the channel offset. A cell corresponding to a specific time and channel offset is also called timeslot and usually has a duration of $10\>ms$. In the depicted example of Figure 1, there are 6 timeslots and 5 channel offsets. The length of the slotframe is defined from the number of the timeslots and it is associated with several tradeoffs concerning the network performance. In each cell every node is allowed to perform one of the following actions, mandated by the schedule: (1) transmit a packet; (2) receive a packet; or (3) put the radio on sleep mode. For instance, in the mentioned example node B can send a packet to node E at the cell (0,4), node C can send a packet to node F at the cell (0,2) and the rest actions can be executed as defined from the schedule.

The TSCH coordinator is responsible for the construction of a TSCH network. More specifically, it defines the network ID, slotframe size and the Frequency Hopping Sequence (FHS). It also initializes the Absolute Slot Number (ASN) to 0 which is increased with each new timeslot. In order to join the TSCH network a node has to receive an Enhanced Beacon (EB) packet which is broadcast by the coordinator or other joined nodes. EB contains important information required like the time source to synchronize with the other nodes of the network. A channel for a given cell can be computed through Equation 1 where CO stands for Channel Offset. If there is more than one transmission cell at the same time, there is a priority mechanism for the cell with more packets.

This section presents the state of the art of TSCH operating in mobile scenarios. Unfortunately, there are very few instances focusing on this topic, thus we consider it as motivation to investigate further this topic in order to provide insight and new solutions to these research questions.

Al-Nidawi et al. in [5] investigate the performance of TSCH and LLDN protocols under mobility scenarios. More specifically the authors focus on the overhead that joining and leaving the networks cause in terms of delay and energy. The authors claim that if a slotframe has a large channel offset then the scanning procedure will take more time and cost more energy since there are more channels to scan. This issue can be counter-measured with an according timeslot and scheduling approach. In addition, the authors show that TSCH can operate in mobile scenarios and do not consume more power if there is a sufficient number of nodes to provide a good network coverage. In a follow up paper [4], the same authors introduce Mobile TSCH, which is designed to reduce the delay which occurs when joining a TSCH network. The authors take advantage of ACK packets which are transmitted on a specific channel to advertise the TSCH network. In other words, the ACK packets behave as an Enhanced Beacon (EB) packet as well. The EB packets in TSCH are used to advertise the TSCH network and a node requires to successfully receive one in order to join the network. Thus, the scanning procedure takes place in a single channel and the delay and the energy consumption gets decreased.

A more recent attempt to investigate TSCH mobility is described in [19]. The authors focus on cases where mobile nodes are leaving and re-joining a TSCH network due to issues which are related with the synchronization degree. They carry out an evaluation based on simulations which takes into account a combination of stationary and mobile nodes and measuring the downtime (the time a node is out of TSCH network), energy consumption, and the amount of Keep Alive (KA) packets (KA packets are used to update the synchronization of a node). Moreover, they regulate the number of the nodes and the speed, to see their impact on TSCH performance. The results describe a tradeoff between the downtime and the consuming energy connected with the operating speed. Essentially an increased speed might decrease the downtime but it will increase the energy consumption. Among other results they present that when the coverage of the network is sufficient with adequate number of mobile nodes, TSCH performance is very close to a static TSCH network.

The aforementioned approaches describe TSCH performance based on very basic mobility patterns and do not consider the state of the art of the TSCH schedulers. Furthermore these approaches consider a single mobility pattern in their evaluation method, but as it mentioned in Section IV, mobility in IoT can vary a lot as it is dictated from several spatio-temporal variables. In contrast, the results presented in this paper are obtained considering the latest TSCH schedulers and we consider two mobile scenarios which differ in terms of randomness between them. Furthermore, the mobility patterns are inspired and designed based on real life application scenarios, thus the results reflect more to these cases.

This section describes the details of the mobility patterns used and the motivation behind it. The mobility pattern among IoT applications scenario vary a lot and includes several spatio-temporal variables which are difficult to be modelled in a general context. To this end we defined two scenarios which we focus on. The first one represents an application where autonomous agriculture vehicles operate on the field and the nodes follow a specific trail. The nodes are supposed to be part of a fleet collaboration system, enabling and allowing multiple autonomous agricultural robots to collaborate with each other as well as human operated tractors and machinery. TSCH is envisioned as part of a multiple-protocol solution with robust safety degradation features.

In the second one, a random movement mobility pattern represents moving machinery, autonomous robots/vehicles and workers who communicate in a smart warehouse environment. The patterns were implemented in Python and then imported in the Cooja simulator for the evaluation part. For the random movements in the smart warehouse pattern, we used the random library from Python, with a uniform distribution.

This section presents the details of the evaluation method we used, the results we obtained and a discussion about the findings.

To simulate the proposed scenarios, we used Cooja, [17] a popular network simulator which is part of Contiki-OS [10]. To enable mobility we also used a mobility plugin for Cooja [1]. We first created several trails in Python following the mobility patterns described in Section IV. In this sense every node will follow its own trail following a specific mobility pattern. The field a node can move is $1000\;$x $1000\;m$, the transmission range is $450\;m$ and the mobility speed $2\;m/s$. The simulation was based on Cooja motes, a virtual platform offered by the simulator which is able to execute Contiki-OS as a native process and utilize directly all the hardware accesses. The duration time of each simulation was $4$ hours. The slotframe size and the channel offset for the MSF scheduler is defined using a hash function which takes into account the amount of neighbors. Orchestra in our evaluation has a size of $397$ slots for EB slotframe, $31$ for the broadcast slotframe and for the Unicast slotframe it is constructed by the same hash function described before. For Alice the EB and Broadcast slotframe sizes are the same the Unicast though is constructed again every time the slotframe is completed based on directional link information and multiple channel offsets.

We focus on a scenario where the traffic is directed from nodes to the coordinator. In this scenario every node is transmitting a packet every $6$ seconds. To have statistically valid results we executed the same simulation with $20$ different seeds for each selected scheduler and as we changed the number of nodes to observe how it can affect the performance of TSCH in each one. We conducted 360 simulations in total which correspond to $1440$ simulation hours and more than $3161000$ packets which were transmitted. However the initial positions of the nodes remain the same in order to investigate systematically when coverage issues that may or may not occur. For instance, the mobility pattern representing the autonomous agricultural vehicles include three to five nodes. In every simulation for the autonomous agricultural vehicles case, there is a node with severe coverage issues as it starts its trail away from the rest of the nodes and is having a hard time to join the network due to the fact that there is an increased time delay to join TSCH network and the time this node interacts with the rest of the nodes is not enough to complete this process. This is not happening in the smart warehouse mobility pattern, where none of the nodes spent significant time outside of the network.

In this paper we report how TSCH schedulers perform during heterogeneous mobile scenarios and where we should focus to improve it for such cases. We defined two mobility patterns representing two different mobile applications which the first one is more deterministic, as it is consisted of repetitive patterns, and the second one is more stochastic. We run simulations after selecting TSCH approaches from the state of the art and perform evaluation terms of PRR, downtime and the initial join time. The results show that the current approaches cannot be utilized in mobile scenarios as their performance is inadequate. The main contribution of the paper is in the identification of the directions researchers should concentrate in order to improve TSCH performance towards mobile scenarios.