On the suitability of 6TiSCH for industrial wireless communication

. The IETF, concerned with the evolution of the Internet architecture, nowadays also looks into industrial automation processes. The contributions of a variety of IETF activities, initiated during the last ten years, enable now the replacement of proprietary standards by an open standardized protocol stack. This stack, denoted in the following as 6TiSCH-stack, is tailored for industrial internet of things (IIoTs). The suitability of 6TiSCH-stack for Industry 4.0 is yet to explore. In this paper, we identify four challenges that, in our opinion, may delay or hinder its adoption. As a prime example of that, we focus on the initial 6TiSCH-network formation, highlighting the shortcomings of the default procedure and introducing our current work for a fast and reliable formation of dense network.


Introduction
Wireless technology is at the same time tremendously appealing and excessively intimidating for industrial automation. On the one hand, it provides access to assets or instruments that were previously considered unreachable due to physical or economic barriers [GH09]. On the other hand, it leaves doubts on the fulfilment of critical requirements such as reliability, latency and security, which are mandatory for industrial applications [Fr15].
Plenty of wireless solutions have been proposed by academia, consortia of manufactures and standardisation bodies in recent years and for several industry sectors. However, a reality check article such as [MCV18] reveals how the level of their adoption is notably extensive only in process control applications, often characterised by more relaxed requirements (e.g., latency of 10's or 100's of ms) than those of factory automation. Here, WirelessHART [In16] and ISA100.11a [Wi11] have established themselves as the two prevailing technologies, able to provide reliable wireless communication. This fact pushed IEEE to add in the recently published revision of the 802.15.4 standard [IE16] the Time-Slotted Channel Hopping (TSCH), which has a design inherited from WirelessHART and ISA100.11a. TSCH is a Medium Access Control (MAC) that orchestrates low power wireless communications through Time Division Channel Access (TDMA) combined with frequency hopping. Hence, it guarantees determinism of channel access and enhances resilience to interference.
In this context, the IETF IPv6 over the Time Slotted Channel Hopping mode of IEEE 802.15.4 working group (6TiSCH-WG) [TW13] promotes the adoption of the open standardised protocol stack, the 6TiSCH-stack, where the upper lowpower IPv6-stack and the industrial wireless technology TSCH at the bottom are glued together by the 6TiSCH-WG standardization activities.
The adoption of the 6TiSCH-Stack promises above all interoperability between vendors and seamlessly integration of industrial wireless sensor networks (IWSNs) into the Internet.
Despite these high potentials, the use of 6TiSCH-stack for Industry 4.0 is yet to explore. First, this paper identifies a list of challenges that, in our opinion, may delay or hinder its adoption. Then, as a prime example of these challenges, we focus on the initial 6TiSCH-network formation, discussing the limits of the procedure standardised by the 6TiSCH-WG as RFC8180 [VPW17]. Finally, we review related works from literature, and we introduce our current proposal for improving the 6TiSCH network formation in term of reliability and duration.
The remainder of this paper is organised as follows. Section 2 gives an overview of the 6TiSCH-Stack and its related standardisation activities. Section 3 lists the challenges that, in our opinion, may delay or hinder the adoption of the 6TiSCH-Stack in the Industry 4.0. The dynamic of the 6TiSCH-network formation, its shortcomings and possible improvements are described in Section 4. Section 5 concludes this paper. The 6TiSCH-stack, depicted in Figure 1, aims to replace the substantially overlapping and competing standards mentioned in Section 1 and to realise the Industrial Internet of Things (IIoTs) paradigm. The Constrained Application Protocol (CoAP) [SHB14] and UDP [Po80] are used in conjunction as transport protocol between constrained end-points for web-applications and management. IPv6 and the adaptation layer 6LoWPAN give IP-based bi-directional communication to any devices in the plant. The RPL routing protocol [Wi12] addresses the specific routing challenges in a 6TiSCH network, i.e. a multi-hop redundant mesh of up to ca. hundreds of low-power devices formed around a gateway (or sink node) and characterised by lossy links. The 6top protocol [WVW18] and other 6TiSCH standardisation activities build together the sublayer between the low-power IPv6 upper stack and the TSCH protocol at the MAC layer.
For the sake of brevity, we focus only on TSCH, RPL and a selection of 6TiSCH activities, since these two standards and their interplay orchestrated by 6TiSCH WG have the most impact on the reliability and delay-bounds offered by the 6TiSCH networks.

Time Slotted Channel Hopping
Time Slotted Channel Hopping (TSCH) is one of the three new MAC mode introduced by the last revision of IEEE 802.15.4 [IE16]. Different works in literature such as [Al15] and [Ku17] underline its better performance in term of end-to-end delay and flexibility in comparison to the other modes and sustain its selection done by the 6TiSCH-WG as the fit protocol for the realization of the IIoT paradigm.
TSCH borrows key elements from WirelessHART and ISA100.1 as explained below. In TSCH, time is organised as a continuously repeating sequence of slotframes formed by several timeslots, typically 10 ms or 15 ms long. In each timeslot, a node may transmit or receive a frame, or it may turn its radio off for saving energy. A value shared by all nodes in the network, called Asynchronous Sequence Number (ASN), labels each timeslot. In particular, ASN = k · N s + t s counts the total numbers of timeslots elapsed since the start of the network, where k defines the slotframe cycle, N s is the slotframe size and t s points out a timeslot in one slotframe. Up to N c ≤ 16 different physical frequencies are available for transmission at each timeslot. As a result, TSCH provides a matrix of links (or cells) for scheduling communications in the network, where each link can be identified by a pair, [t s , ch of ], specifying the timeslot t s in the slotframe and the channel offset ch of used in that timeslot. The channel offset translates into a physical frequency as follows: The function F can be implemented as a lookup table. Simultaneous communications can take place without interfering in the same timeslot and so the network capacity is increased. In addition, Eq. (1) returns a different frequency for the same link at successive slotframes, following a pseudo-random hopping pattern. This is an efficient way to minimise the effects of multipath fading and external interference. Each link allows a node to send a frame, and if expected, to receive the related acknowledgement (ACK). Links can be dedicated or shared. Dedicated links are allocated to a single sender-receiver couple and are contention free. On the other hand, CSMA-CA regulates the transmission on shared links. Let us consider the multi-hop network from Figure 2 and its possible TSCH schedule, illustrated as a matrix of links in in Figure 3. The number of channel offsets, i.e., the height of the matrix, is equal to the number of available frequencies (N c = 4) and N s = 7 is the number of timeslots in a slotframe, i.e. the width of the matrix. In particular, the link [0, 0] is a shared link, allocated for broadcasting frame and used by more than one transmitter node. Furthermore, simultaneous communications happen at timeslot t s = 1 and t s = 2 . Each node can translate this TSCH schedule into a local slotframe, where scheduled activities (transmit, receive or sleep) repeat over time, as shown in Figure 4 for the sink and node B. In particular, node B is only active in four of seven timeslots, resulting in a duty-cycle of about 57% (that is, however, atypical in practice).

Routing protocol RPL
RPL is a distance-vector protocol designed by IETF ROLL working group to operate on top of low power and lossy networks (LLNs), where energy, computation and bandwidth resources are very constrained, and communication is prone to high error rates [Wi12]. RPL is a gradient-based routing that organises nodes as a Destination Oriented Directed Acyclic Graph (DODAG). The DODAG is a directed tree, rooted at the sink, which is usually responsible for data collection. The gradient is called rank, and it encodes the distance of each node from the sink, as specified by an Objective Function. The Objective Function offers a flexible way to optimise the network topology, defining which metrics and how these are used to compute a node's rank. Exchanging signaling information, each node can choose a set of parents (nodes with lower rank) among neighbours and select one as its preferred parent, which is the next-hop on a path towards the sink. Section 4.1 explains the DODAG formation procedure and its interplay with TSCH networks synchronisation, as defined by 6TiSCH in [VPW17].

6TiSCH-WG standardization activities
The 6TiSCH-WG faces the problem of building and maintaining multi-hop schedules for RPL-organized, TSCH-based networks. To this end, it is necessary to enhance the IEEE 802.15.4 standard, which just defines how a node executes a given TSCH schedule, and not the link allocation mechanism, i.e., how to build a TSCH communication schedule. The 6top protocol and the other standardisation activities of the 6TiSCH-WG should fill this gap. The 6top protocol, currently defined by the draft [WVW18], acts as a sublayer and turns the complexity of the TSCH schedule in a simple IP link between neighbours for the upper layers. The 6top protocol is responsible for (1) negotiating the (de)allocation of communication links between nodes, (2) monitoring performance and (3) collecting statistics. Moreover, it provides a set of commands to support decentralised, centralised and hybrid scheduling solutions, called Scheduling Function using the 6TiSCH glossary.
The 6TiSCH-WG is currently defining a bootstrapping protocol by which a new mote is admitted into the multi-hop network. The 6TiSCH minimal configuration (6TiSCH-MC) [VPW17] provides a basic interoperability between nodes and defines and the elemental coordination between RPL and TSCH during the initial network formation. The standardisation of a secure join process [Vu18], where a node requests the admission into the network and sets up keys used to authenticate and encrypt subsequent transmission, is being currently defined.

Challenges
A quick literature research in the IEEE Xplore and ACM digital libraries reveals the steadily growing interest of the academic community for the 6TiSCH-WG and its used protocols. However, we believe that this emerging protocol stack will experience a real, massive industrial adoption in the next years only if the following challenges will be overcome. Challenge 1: Convergence on industrial concerns The 6TiSCH-WG was created to realise the vision of the IIoT, bridging the gap between industrial and information technology worlds. Hence, huge efforts were primarily dedicated to enabling IPv6 over the TSCH mode of the IEEE 802.15.4 standard and to providing a seamless integration of industrial wireless sensor nodes into the Internet. Unfortunately, this integration of the industrial network with the Internet may be perceived more as a possible security risk than an added value for several stakeholders, which consider the keeping of collected measurements inside the operational technology networks mandatory, and thus they may obstruct the adoption of 6TiSCH.
The fact that wireless nodes natively support IPv6 and may connect with any part of a production process without a protocol specific gateway enables new development methodologies. The perception of this added value can be improved by working on specific use-case deployments, i.e. for adaptable factory or predictive maintenance as targeted application. In this context, more effort to provide continuity and interoperability with legacy industrial transport and application protocols on top of 6TiSCH-stack appears for us also essential. The collaboration between 6TiSCH and Deterministic Networking (DetNet) [FB14] WGs goes in this direction and may foster 6TiSCH-networks as an extension of an IEEE 802.1 TSN Ethernet backbone, similarly to the past successful extension of the Fieldbus protocol Highway Addressable Remote Transducer (HART) done by WirelessHART. Challenge 2: Avoidance of specification -implementation mismatches The IETF standardization process relies both on (a) prior implementation and testing and on (b) clear and concise documentation. In the case of 6TiSCH, diverse popular open-source operating systems for WSN are implementing this family of standards and their interoperability is tested regularly [Wa16], [Pa15a]. However, the full compliance with the standards is challenging and is not always offered by those implementations. We experienced discrepancy by the implementation of particular algorithms (e.g., the generation of EBs and its periodicity), where the developer has introduced optimisations (e.g., a specific randomisation of the EB transmission period) based on experience or testing. Moreover, this issue relates to the value of default protocol parameters, which is declared in specific RFCs but adjusted in the implementation of the 6TiSCH-stack.
The lack of clear documentation on these mismatches is an entry barrier to those industry professionals that are aiming to use 6TiSCH-stack but have limited experience or time to get into this technology. Furthermore, it can lead to a distrust in the implementations. Broader documentation of lessons learned from implementers would provide a better understanding of applicability and limits of the 6TiSCH-stack and improve the perception about this technology.
Challenge 3: Design of the management architecture scheme 6TiSCH-WG proposes different options (static, centralised and distributed) on how to manage the communication resources, and simultaneously does not prescribe a specific policy. However, until now the 6TiSCH-WG activities have been focusing on the static and on the distributed approach, as proven by the standardisation of 6TiSCH-MC and by the active Internet-Draft on the Minimal Scheduling Function (MSF) [Ch18] respectively. This fact clashes with the experience from widely used proprietary technology in industrial automation, such as WirelessHART and ISA100. They rely on a centralised approach, where a central network manager performs complex and optimal scheduling algorithms using topology information in combination with communication requirements provided by devices and applications.
Soon, the 6TiSCH-WG will target the definition of the protocols required for the central scheduling, reusing and extending the DetNet Architecture. In this context, both the coordination of the different scheduling options supported by 6TiSCH-stack and the integration of network management functions of various industrial automation protocols are challenging and require further investigation.
Another question related to this challenge is whether and to what extent the choice of RPL as routing protocol obstacles the adoption of the 6TiSCH-stack in industrial automation. From [Ri17] and [Ri18] it emerges that the interplay between 6top protocol and the dynamic of the RPL negatively affects the performance of the 6TiSCH-networks. We believe that the re-design of several mechanisms adopted by RPL (i.e. link-quality assessment, ) for a better interplay with the 6TiSCH-stack is a prospective research topic.
Challenge 4: Concurrence of other wireless technologies As mentioned in Section 2, TSCH is a building block of the 6TiSCH-stack, and it builds on IEEE 802.15.4, a standard for low-power, low-rate and short-range radio applications. Supporting multi-hop networks, the 6TiSCH-stack may extend the radius of the network (i.e., up to 1km), but the fulfilment of the typical strict industrial requirement in deep 6TiSCH-networks is unrealistic. Moreover, different Industry 4.0 use-cases needs wide-area communication [WSJ17]. In this scenario, other wireless technologies such as 5G Mobile Radio (5G), Narrow-Band IoT (NBIoT) and Long-Range WAN (LoRa) are recently developed to enable IoT connections over long-ranges (i.e., 10 -15 km) and to establish themselves as transmission technologies for future use.
We see this challenge as an opportunity to (1) realize the vision of benchmarking low-power-wireless networking described in [Bo18], and (2) to study the coexistence and interoperability of short-range and long-range wireless technologies.

Analysis and Improvements of the 6TiSCH minimal configuration
The 6TiSCH-stack has already been subjects of several studies in the literature in the last years. The majority of them either proposes different scheduling algorithms (both centralized [Pa13] and distributed [Ac15], [Du15]) for fulfilling the strict requirements of industrial networks (e.g., in term of reliability, latency etc.) or evaluates the 6TiSCH-stack in specific context (e.g., [Pa15b], [Sc17]). These works mainly consider the data transmission, when the network is fully operational. In comparison, the initial 6TiSCH-network formation has attracted less attention from academia, although this phase is mandatory, before nodes may transmit any sensed data. Besides, the coordination between MAC and network layer is here challenging. Therefore our work aims to fill this gap.

6TiSCH network formation procedure
When wireless sensor nodes run TSCH and RPL protocols, they have at least to synchronise on a slotframe structure and to join a DODAG, before they can transmit the sensed data to the sink. We call these two processes TSCH networkwide synchronisation and RPL DODAG construction respectively. These two processes take place at two different layers and have to be executed by each node until the initial network formation procedure ends and the network is operational. The 6TiSCH-MC defines (1) a static TSCH-schedule for the whole network for the transmission of bootstrapping traffic and (2) the guidelines for the coordination of these two processes, as explained below. The network formation starts with the sink node (or root), which sets the static minimal schedule, composed by only a single shared link and a timeslots. The sink node acts as the first advertiser node by broadcasting Enhanced Beacon (EB) frames and DODAG Information Element (DIO) packets to announce the network presence. EBs are generated every t eb and contain all the necessary time information to allow the initial synchronisation among nodes, including the timeslot timing, the slotframe length of the minimal schedule and the channel hopping sequence. DIO packets are ICMPv6 control messages, which announce the DODAGID, the sender's rank and other configuration parameters used for DODAG construction and maintenance. The Trickle algorithm controls the generation rate of DIO messages as specified in [LC11], using adaptive transmission periods and a timer suppression mechanism configured mainly by the following three parameters: minimal interval size, I min , number of doublings M and redundancy constant c. The advertiser node places the generated EBs and DIOs in the transmit queue and exploits the shared slots, offered every N s · t s by the minimal schedule, for their transmissions. Specifically, 6TiSCH-MC sets the precedence to EBs over DIOs, so that the transmission of EB is performed in the next active shared slot, but, by contrast, DIOs may be buffered as long as EBs are pending in the outgoing queue (assuming that only EBs and DIOs are generated during this procedure). This process is exemplified in Figure 5, where t eb = 200ms, I min = 128ms, and the minimal schedule are used.
When a node wishes to join the network, it uses preferably passive scanning, i.e., it turns the radio on to a randomly chosen frequency, and it listens for EBs. While waiting for a valid EB, the joining node keeps its radio always on and changes frequency every t scan . After hearing a valid EB, a node learns the minimal schedule in the network, so it knows when to wake up for receiving or sending control frames related to the network formation procedure. Then, when at least one DIO message is received, the node can compute its rank and select its preferred parent, i.e. the initially designated neighbour for data forwarding toward the sink node. From this point, the joined node also becomes an advertiser and starts broadcasting both EBs and DIOs, so that the multi-hop network formation may be gradually formed. The 6TiSCH-network formation finishes when all nodes become synchronised with the TSCH minimal schedule and are part of the DODAG.

Shortcomings of 6TiSCH-MC
Authors in [VWV18], [Vass] and [FSK18] recently have studied the performance of the 6TiSCH network process specified by 6TiSCH-MC. In [VWV18], the congestion problem originated by the only one shared slot in the 6TiSCH minimal schedule is considered as well as a factual issue in a dense network and motivates there the adoption of a 6TiSCH specific broadcasting strategy as the answer to this problem. Both [Vass] and [FSK18] highlight that the minimal configuration needs at least a proper parameter tuning of TSCH and RPL to avoid prolonged or unsuccessful network formation. The authors of [Vass] first provide an analytical model for expressing the average number of slotframes required for a joining node to become operational as a function of the number of advertiser nodes in the neighbourhood. Then, they highlight the dependence between the slotframe length and the node joining time distribution in the 6TiSCH-MC. In our previous contribution [FSK18], we evaluated through simulation the impact of EB broadcast period and RPL minimum interval I min on the duration of and the energy consumed for the network formation process of different typical network topologies. With an improper TSCH and RPL parameter tuning (i.e. using default value declared in the RFCs) in relation to the network density, we observed collisions of control frames, the starvation of DIO packets in the transmission queue and TSCH de-synchronisation. These events hinder a reliable and fast 6TiSCH-network formation.

Improvements of 6TiSCH-MC
The works mentioned above do not restrict themselves to analysing the performance of 6TiSCH-MC and its limits, but they also propose modifications to improve both reliability and efficiency of the 6TiSCH network formation. In [VWV18], the authors propose the adaptation of the Bayesian broadcast algorithm to 6TiSCH. Specifically, each node locally set optimal values of transmission probability for EBs, DIOs and other bootstrapping traffic. These values depend on the estimated number of advertiser nodes in the neighbourhood and change during the formation process. The 6TiSCH-WG seems to obey this approach currently defining the 6TiSCH Minimal Scheduling Function in [Ch18]. Increasing the number of transmission opportunities in the minimal schedule is one other possible approach to address the limitation of 6TiSCH-MC in large networks. Following this approach, Vallati et al. propose an allocation strategy for TSCH shared timeslot that is dynamic and distributed. Specifically, 2 m shared timeslots are allocated equally spaced in the slotframe, and the allocation exponent m is updated periodically by estimating the rate of control messages transmitted within a neighbourhood [Vass]. The use of additional TSCH shared timeslots for the transmission of EBs and RPL messages speeds up the network formation in dense topologies. Furthermore, it has a beneficial impact on the routing protocol in discovering better routes towards the sink node, since, avoiding the adverse events mentioned in Section 4.2, each node has a superior view of the neighbourhood compared with 6TiSCH-MC.

Diagonal : Our improvement proposal for 6TiSCH-MC
To overcome the shortcomings of 6TiSCH-MC highlighted in Section 4.2, we currently work on the definition of diagonal, an algorithm that coordinates the allocation of TSCH links for control messages in the neighbourhood in a dynamic and distributed way. It follows a brief description of the key elements of our proposal.
-We reserve at most N max TSCH links per slotframe for the transmission of control messages. The (t s , ch of ) index of these TSCH-links are so selected that only one frequency per slotframe is used for these transmissions. Considering the TSCH-matrix and Eq. (1) with F (x) = x, we see in Figure 6 a diagonal pattern of these links, which reveals the name of the algorithm. Our proposed approach utilises shared (S) and dedicated (D) TSCH-links for the transmission of EBs and RPL messages.
-The network formation started at the sink, which broadcasts control messages using N D = 1 D link and sets N s S links in the TSCH schedule. Similar to 6TiSCH-MC, a joining node implementing the diagonal algorithm, choose a frequency among the available frequencies, and start listening for EBs and DIOs, when switched on. Upon receiving the first EB, the joining node is synchronised and must continue listening for additional control messages in the neighbourhood. These transmissions occur on the same frequency and in N = N D + N S < N max links. -Collisions of control frames may happen only in the S links. Therefore, the joining node learns the number of neighbours in its vicinity, and passively estimates the link quality to them from the packets received on the D links. Besides, the joining node acquires the RPL rank, if in the neighbourhood DIO packets are sent, and selects its preferred parent. -After having joined the DODAG, the joining node becomes an advertiser, and it must contend for one of the S links in the neighbourhood in a distributed manner. That is an additional step compared with the joining procedure defined in the 6TiSCH-MC. To this end, no explicit request-notify messages between nodes is used, but instead, each EB and DIO carries with it a specifically designed information element (IE), called diagonal IE. The IE is a flexible and extensible container of information, placed at the end of the MAC header, and it is broadly used by TSCH, e.g., for broadcasting timing information in EBs. We define the diagonal IE as shown in Figure 7.
With the timeslot bitmap, each advertiser node specifies the types (D or S) of the N < N max links in its neighbourhood. Thus, after listening for diagonal IEs sent in the neighbourhood during a TSCH slotframe, a node has a 2-hop bitmap view. -At this point, the new advertiser node knows for which S links it can contend without interfering any other advertisers. It does that directly, transmitting an EB on a randomly chosen S link and then listening for feedback in the next slotframe. Nodes gather the feedback analysing the collision (CF) and the pending flag (PF) in each received diagonal IE. A CF set to one notifies a collision during the previous slotframe (on one of the S links), and it returns negative feedback for the advertising nodes, that have previously transmitted an EB on such links. These nodes choose another link (with probability γ) for the next EB transmission. The PF is used to inform the neighbours, that the advertiser node is trying to gain a D link, so its EB includes only a candidate timeslot bitmap in the diagonal IE . -The diagonal algorithm applies a dynamic allocation strategy, since N (the number of TSCH-links for transmitting the control messages) changes locally following the increase/decrease of the number of advertiser nodes in the 2hop neighbourhood of a node.
A simulative study, similar to that conducted alike in [FSK18], is ongoing for the proposed algorithm. First results show that the diagonal algorithm helps in reducing the network formation time, without inducing a relevant increase of the energy consumption, compared to the 6TiSCH-MC. However, we wait for experimental results and a comparison with [VWV18] and [Vass] to give more insights into the quality of the diagonal algorithm.

Conclusions
This paper introduced the 6TiSCH-stack, an open standardised protocol architecture built by several IETF standardisation activities for IoTs and by TSCH, a proven wireless technology especially tailored for industrial applications. Although the 6TiSCH-stack seems ready to use and its potential benefits are clear, we have investigated if this architecture is suitable for industry 4.0. On the one hand, we have identified and discussed four challenges that may delay or limit the adoption of 6TiSCH in industrial automation. On the other hand, we have remarked, how the 6TiSCH community is now working on some of these challenges. In particular, we have directed our attention towards the 6TiSCH-MC, the IETF recommendation that describes the 6TiSCH network formation phase and the coordination between TSCH and RPL protocols. We reported on its limits, on the risk of its blind adoption and on works related to its improvements. Finally, we presented the essential elements of diagonal, our proposal for improving the 6TiSCH-MC. The evaluation of our proposed schema is ongoing, and some refinements may be necessary, but the first results are promising. In the light of these preliminary results and the other ongoing efforts, we are confident, that 6TiSCH-stack will become a key technology for the IIoT.