Esteban Municio
email: esteban.municio@uantwerpen.be

| Glenn Daneels

| Mališa Vučinić

Steven Latré

Jeroen Famaey

Yasuyuki Tanaka

| Keoma Brun

| Kazushi Muraoka

| Xavier

| Thomas Watteyne

Simulating 6TiSCH Networks

6TiSCH is a working group at the IETF which is standardizing how to combine IEEE802.15.4 Time-Slotted Channel Hopping (TSCH) with IPv6. The result is a solution which offers both industrial performance and seamless integration into the Internet, and is therefore seen as a key technology for the Industrial Internet of Things. This article presents the 6TiSCH Simulator, created as part of the standardization activity, and which has been used extensively by the working group. The goal of the simulator is to benchmark 6TiSCH against realistic scenarios, something which is hard to do using formal models or real-world deployments. This article discusses the overall architecture of the simulator, details the different models it uses (i.e. energy, propagation), compares it to other simulation/emulation platforms, and presents 5 published examples of how the 6TiSCH Simulator has been used.

INTRODUCTION

Reliable, deterministic and time-sensitive networking is critical for the Industrial Internet of Things (IIoT). The Time-Slotted Channel Hopping (TSCH) mode of IEEE802.15.4 is at the core of virtually all low-power wireless standards for the IIoT, including WirelessHART, ISA100.11a and IEEE802.15.4-2015 [START_REF]IEEE . IEEE Standard for Local and metropolitan area networks[END_REF]. Tens of thousands of TSCH-based low-power wireless networks are deployed today 1 . TSCH is a technology which has demonstrated to provide wire-like reliability and over a decade of battery lifetime [START_REF] Thomas | Industrial IEEE802.15.4e Networks: Performance and Trade-offs[END_REF]. The IETF is standardizing a new TSCH-based technology, which combines the performance of TSCH with the ease-of-use of IPv6 (one of the main differentiators with previous standards). This work is being done at the IPv6 over the TSCH mode of IEEE 802. [START_REF] Kazushi | Simple Distributed Scheduling with Collision Detection in TSCH Networks[END_REF].4e (6TiSCH) working group, which has just completed its base set of specifications [START_REF] Thomas | Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement[END_REF]4,[START_REF] Qin | 6top Protocol (6P). draft-ietf-6tisch[END_REF][START_REF] Mališa | Minimal Security Framework for 6TiSCH[END_REF][START_REF] Tengfei | Vilajosana Xavier. 6TiSCH Minimal Scheduling Function (MSF)[END_REF].

Besides the purely standardization efforts, there are also many research and implementation works focusing on 6TiSCH. It is now supported by all the main open-source low-power wireless implementations: OpenWSN, Contiki-NG, RIOT and TinyOS [START_REF] Thomas | Industrial Wireless IP-based Cyber-physical Systems[END_REF]. Improvements to 6TiSCH are being proposed by the academic community [START_REF] Duy Thang Phan | Distributed Cell Selection for Scheduling Function in 6TiSCH Networks[END_REF][START_REF] Katina | A Load Balancing Algorithm for Resource Allocation in IEEE 802[END_REF][START_REF] Glenn | ReSF: Recurrent Low-Latency Scheduling in IEEE 802.15.4e TSCH networks[END_REF][START_REF] Iacob | Stripe: a Distributed Scheduling Protocol for 802.15.4e TSCH Networks[END_REF]. But while this activity is a clear indication of the activity of the 6TiSCH community, what is needed now to speed up market adoption is slightly different.

Before a company adopts (and invests in) 6TiSCH, it needs to know whether the technology works for its applications. This means answering very down-to-earth questions about the performance of the network: What is the latency distribution 6TiSCH would offer in this particular industrial deployment? If I use 6TiSCH in my smart agriculture application, how often will I have to replace batteries? Would 6TiSCH offer over 99.999% end-to-end reliability in this particular smart parking deployment? What is needed to answer these questions is a way of benchmarking the solution standardized today. That is, we need a tool which can turn a particular deployment and traffic pattern in key networking performance indicators such as per-node battery lifetime, end-to-end reliability, and latency distribution.

Of course, it would be possible to answer these questions through a comprehensive real-world experimentation campaign. And while extensive experimentation is happening (and will be happening more and more), we argue that it lacks the flexibility of doing quick "what-if" analysis. For that, simulation offers several advantages. First, it allows us to quickly estimate the performance for a given scenario and a set of parameters. Second, it allows us to tune the parameters in a flexible manner until the desired performance is reached and map these values to the real-world deployment. That being said, simulation is necessarily an imperfect model of physical reality, in particular the radio propagation/connectivity between nodes. And while simulation results must be taken with a grain of salt, they are a necessary first step before any deployment (discussed further in Section 3).

This article presents the 6TiSCH Simulator: a tool for simulating 6TiSCH networks and estimating their performance in a flexible manner. Other network simulators exist -and are surveyed in Section 3 -but they fail to capture the specifics of 6TiSCH networks in a manner that can be useful for a real-world deployment. The reason for creating a new simulator is that we wanted to give priority to simplicity over the extreme extensibility and generality existing in other platforms. We consider that the 6TiSCH simulator enables new users to deploy quick simulations and have direct control over the 6TiSCH parameters without the learning curve required for other platforms.

The simulator mimics exactly the behavior of the full 6TiSCH solution, including network formation, routing and scheduling. It analyzes different 6TiSCH sub-layers for a wide variety of conditions, while ensuring accuracy regarding the standardcompliant hardware implementations [START_REF] Thomas | OpenWSN: a Standards-based Low-power Wireless Development Environment[END_REF][START_REF] Simon | TSCH and 6TiSCH for Contiki: Challenges, Design and Evaluation[END_REF]. It allows end-users and potential adopters to assess whether 6TiSCH would "work" for their applications. It allows researchers to (easily) evaluate the performance of some custom addition to the otherwise fully standards-compliant implementation. The simulator allows for fully automated execution on multiple cores. A graphical interface allows the user to drive the simulation and visualize the behavior of 6TiSCH. In a number of published works on 6TiSCH, the simulator proves itself as a timely and usefully contribution [START_REF] Duy Thang Phan | Distributed Cell Selection for Scheduling Function in 6TiSCH Networks[END_REF][START_REF] Katina | A Load Balancing Algorithm for Resource Allocation in IEEE 802[END_REF][START_REF] Glenn | ReSF: Recurrent Low-Latency Scheduling in IEEE 802.15.4e TSCH networks[END_REF][START_REF] Iacob | Stripe: a Distributed Scheduling Protocol for 802.15.4e TSCH Networks[END_REF][START_REF] Kazushi | Simple Distributed Scheduling with Collision Detection in TSCH Networks[END_REF][START_REF] Palattella | On-the-fly Bandwidth Reservation for 6TiSCH Wireless Industrial Networks[END_REF][START_REF] Vučinić Mališa | Broadcasting Strategies in 6TiSCH Networks[END_REF][START_REF] Esteban | Decentralized Broadcast-based Scheduling for Dense Multi-hop TSCH Networks[END_REF][START_REF] Gomes | MABO-TSCH: Multihop and Blacklist-based Optimized Time Synchronized Channel Hopping[END_REF][START_REF] Esteban | A distributed density optimized scheduling function for IEEE 802.15. 4e TSCH networks[END_REF].

The main goal of this article is to provide an overview of the 6TiSCH Simulator, and discuss its design drivers and approach. The contribution is two-fold. First, we provide the 6TiSCH Simulator as open-source code 2 . Second, we validate the simulator through comparative tests and we provide use case examples that discuss relevant open research questions regarding 6TiSCH.

The remainder of this article is organized as follows. Section 2 introduces the 6TiSCH protocol stack. Section 3 discusses other network simulators/emulators, and why a new 6TiSCH-specific simulator was developed. Section 4 discusses the overall architecture of the simulator and details the different models it uses (including energy and propagation). Section 5 presents the results that validate the tool and Section 6 shows its performance. Section 7 presents 5 published examples of how the 6TiSCH Simulator has been used. Finally, Section 8 concludes this article.

A 6TISCH PRIMER

6TiSCH targets building-sized networks and typical IIoT applications, such as monitoring and control. It builds upon the IEEE802.15.4 physical-layer standards, typically used in the license-free 2.4 GHz ISM band with a 250 kbps bit rate. IEEE802.15.4 splits that band into 16 orthogonal frequencies. The maximum PDU of IEEE802.15.4 is 127 bytes. IEEE802.15.4 defines different modes on how the radio channel is accessed. The mode used by 6TiSCH is TSCH. The main principle of TSCH is to combine Time Division Multiple Access (TDMA) for collision-free access with channel hopping for robustness against multi-path fading and external interference. TDMA slots are wide enough (typically 10 ms) to accommodate the transmission of the largest frame and a short acknowledgement. A group of slots that repeat in time is called a slotframe.

Whether a node transmits, receives or sleeps during a slot is defined by the schedule. The schedule can be visualized as an × matrix, where is the number of available physical channels, and is the number of slots in the slotframe. Each element in the schedule matrix is called a cell. A cell is simply an abstraction that carries information needed for a node to handle the slot. This information is the type of cell (transmit, receive, sleep) and the address of the corresponding radio neighbor. A group of cells to a particular neighbor constitutes an (IP) link. A cell is uniquely identified by its channel offset and its slot offset. A cell's slot offset maps to the time the slot is executed and it is identified by a unique Absolute Slot Number (ASN). A cell's channel offset maps to a different frequency for each slotframe iteration, resulting in channel hopping.

How the schedule is built and communicated to the nodes is not defined by IEEE802.15.4 and is where 6TiSCH fits in. 6TiSCH builds the schedule in a completely distributed fashion. A cell in a 6TiSCH network can either be "hard" or "soft". Soft cells are installed in a dynamic fashion by the 6top sub-layer, hard cells are static. RFC8180 (4) defines the usage of a single hard cell used for network bootstrap, referred to as the "minimal" cell. A node can use the minimal cell both for transmission and reception. Since all nodes in the network have this cell in their schedule, collisions are possible and handled by the exponential back-off algorithm defined in IEEE802.15.4. The nodes obtain the information about the minimal cell dynamically, when they receive a special frame called Enhanced Beacon (EB), used for initial synchronization with the network. The minimal cell carries all the broadcast traffic in the network as well as the unicast traffic required to build the network.

Soft cells are installed by the 6top Protocol (6P) [START_REF] Qin | 6top Protocol (6P). draft-ietf-6tisch[END_REF]. When a node wants to add or delete cells in its schedule with neighbor , it triggers a 6P transaction. In a 2-step 6P transaction, selects a candidate list of cells and sends it to . then selects cells from the list and communicates it to by sending a response. When receives an acknowledgement of its transmission to , it knows that has received the response and adds the selected cells in its schedule. In a 3-step transaction, it is which provides a list of candidate cells and which selects the exact cells to be used. Apart from adding and deleting cells, 6P also allows the existing cells to be relocated to a different position in the schedule matrix.

6P provides a means for the cells to be installed in a dynamic fashion. The algorithm by which a node decides that it needs to add/delete cells is called a Scheduling Function (SF). The SF enables the deterministic nature of 6TiSCH: it decides when to add/delete cells and to which neighbor, how many cells to add/delete and which exact cells to use. This allows the optimization of different criteria, such as latency or energy consumption. There are many SF proposals in 6TiSCH. The Minimal Scheduling Function (MSF) [START_REF] Tengfei | Vilajosana Xavier. 6TiSCH Minimal Scheduling Function (MSF)[END_REF], for example, monitors link utilization and adapts the number of cells to keep utilization within pre-defined bounds. Effectively, this allows MSF to dynamically adapt to traffic. The risk of distributed scheduling is that two disjoint pairs of nodes in the network decide to use the same cell. This results in a schedule collision and degrades performance as the transmissions during the corresponding slots may interfere at the receiver(s). To tackle this problem, MSF monitors the Packet Delivery Ratio (PDR) of each cell individually, and relocates the cell if it observes that the PDR is significantly lower than the average PDR of other cells with the same neighbor. Research around SFs has been very active [START_REF] Duy Thang Phan | Distributed Cell Selection for Scheduling Function in 6TiSCH Networks[END_REF][START_REF] Glenn | ReSF: Recurrent Low-Latency Scheduling in IEEE 802.15.4e TSCH networks[END_REF][START_REF] Palattella | On-the-fly Bandwidth Reservation for 6TiSCH Wireless Industrial Networks[END_REF][START_REF] Iacob | Stripe: a Distributed Scheduling Protocol for 802.15.4e TSCH Networks[END_REF][START_REF] Adnan | DeAMON: A Decentralized Adaptive Multi-Hop Scheduling Protocol for 6TiSCH Wireless Networks[END_REF] and we expect other proposals to be standardized in the future.

There is another research issue with regards to figuring out the policy that yields minimal cell utilization. The minimal cell carries routing information exchanged by the Routing Protocol for Low-Power and Lossy Networks (RPL), EBs transmitted by all the nodes in the network in order to extend the network range, and unicast traffic needed for the network to bootstrap. This unicast traffic includes the secure join protocol standardized in 6TiSCH [START_REF] Mališa | Minimal Security Framework for 6TiSCH[END_REF], whose goal is to provide the new node with security keys once it has been authenticated. Moreover, it includes the first 6P transaction to a given neighbor. Because of this, the way EBs and RPL messages are sent significantly influences the time it takes for the network to form [START_REF] Vučinić Mališa | Broadcasting Strategies in 6TiSCH Networks[END_REF].

The remainder of the 6TiSCH stack (depicted in Figure 1 ) is standardized in other working groups of the Internet Engineering Task Force (IETF). 6TiSCH uses the RPL routing protocol. RPL optimizes multipoint-to-point routes, i.e. from the nodes towards the root of the network, and point-to-multipoint routes for the root to be able to reach each node. The multipoint-topoint routes are created by building a Destination Oriented Directed Acyclic Graph (DODAG) -each node selects a preferred parent based on the rank information received in the DODAG Information Object (DIO) messages. Once the DODAG is built, each node sends Destination Advertisement Object (DAO) messages to the root, which is then able to construct the source route and append it to each packet addressed to nodes in the network. A node can also switch parents. This is coordinated by RPL but has a direct impact on necessary TSCH link resources. The parent switch is handled by MSF in order to quickly allocate additional cells to the new parent and remove remnant cells with the old parent. At the transport and network layers, 6TiSCH uses User Datagram Protocol (UDP) and IPv6, which are compressed by 6LoWPAN compression mechanisms. 6TiSCH uses Constrained Application Protocol (CoAP) at the application layer, secured by an object security mechanism called Object Security for Constrained RESTful Environments (OSCORE).

RELATED SIMULATION PLATFORMS

Network simulation is a common approach used in the design, implementation and performance evaluation of different algorithms and protocols when there is a need for assessing the behavior of a network given a set of models and constraints. In the low-power wireless case, discrete event-driven network simulators are widely used since: 1) they can be used not only as a flexible and inexpensive tool for testing the network without the need of having to deploy an actual physical network, and 2) they can be more accurate and realistic than mathematical models where usually simplifications and abstractions are assumed.

FIGURE 1

The IETF 6TiSCH Protocol Stack.

Although real-world deployments are the most reliable approach for evaluating network performance, it involves important practical difficulties (logistically and economically), not only for deployment and testing but also for modifying and debugging the network. This is especially relevant in large-scale deployments. Unlike real-world deployments, network simulators allows us to flexibly switch and exchange the different protocols and layers in the stack and quickly evaluate network performance for a number of configurations and scenarios.

Mathematical models and problem formulations, although very relevant for describing and predicting behaviors, sometimes lack the accuracy present not only in the standards and RFCs but also aspects inherent to real-world deployments. In this sense, network simulators can provide the required standard-compliant accuracy in a flexible manner. Additionally, complex models become impossible to solve in acceptable time when the network size increases. This makes network simulators a crucial research tool for bridging the mathematical models with real-world deployments.

The open-source network simulators NS-2 [START_REF]NS-2 Simulator Homepage[END_REF] and JSim [START_REF] Hung-Ying | Design, Realization and Evaluation of a Component-based Compositional Software Architecture for Network Simulation[END_REF] have been traditionally used for simulating low-power wireless networks. Currently, NS-3 [START_REF]NS-3 Network Simulator Homepage[END_REF], OMNet++ [START_REF]OMNet++ Network[END_REF] and TOSSIM [START_REF] Philip | TOSSIM: Accurate and Scalable Simulation of Entire TinyOS Applications[END_REF] are arguably the most widely used. However, none of these simulators fulfill the goals for which the 6TiSCH Simulator was designed: compliance with the standard, scalability and simplicity.

• NS-3, an advanced and more modular version of NS-2, is probably the most widely used network simulator nowadays. It has a number of modules for different technologies and protocols and the support of a big community of users. Although NS-3 is a very powerful simulator, its complexity and generic purpose involve a significant learning curve and nonsignificant programming time for a non-expert user. No 6TiSCH implementation currently exists.

• OMNet++ is also a very extensively used simulator for simulating low-power wireless networks. Its INET framework implements most of the more common network protocols. A very realistic PHY layer is available in Castalia ( 27), an OMNet++-based simulator which implements accurate wireless channels and radio access models. As in NS-3, no 6TiSCH implementation is available.

• TOSSIM is a simulator for TinyOS [START_REF] Philip | TinyOS: an Operating System for Sensor Networks[END_REF]. Although TinyOS has been one of the first low-power wireless implementations, support has officially ended in 2013.

Other emulation options are available, including Cooja (29) (the Contiki emulator) 3 and OpenSim (13) (the OpenWSN emulator). These platforms are very powerful on emulating the behavior of a 6TiSCH network without needing the actual hardware, since they run the same binary as goes on a low-power wireless device. The emulation approach has two main drawbacks. First, unlike discrete event-driven simulators, their scalability is rather poor, since the real-time requirements of the instances limit the size of the network up to few tens of nodes. Second, due to its bit-level accuracy, new implementations in routing, scheduling functions or traffic management require significantly more effort than in discrete event-driven simulators where some functions can be abstracted.

A comparison between the different existing alternatives is shown in Table 1 . It evidences why the 6TiSCH Simulator has been developed. First, it has a 6TiSCH implementation that follows the requirements specified in the 6TiSCH RFCs and drafts (e.g. Cooja does not implement MSF). Second, it scales up easily up to several hundreds of nodes. Finally, it has low complexity, enabling to quickly implement and test different scheduling functions, RPL objective functions and traffic management strategies. These points are detailed in Section 4. In that sense, the 6TiSCH simulator is not really comparable to NS-3 or OMNet++, since they are generic purpose simulators which contain a high number of libraries supporting different protocols and models. The 6TiSCH simulator is a highly specialized protocol specific tool for fast prototyping.

THE 6TISCH SIMULATOR

The 6TiSCH Simulator is a discrete-event simulator written in Python. Its design minimizes typical simulation drawbacks by careful abstractions specific to 6TiSCH. It makes no attempt at simulating physical behavior that can only be accurately studied with real hardware such as: synchronization issues due to imperfect crystals, bit-specific transmission errors, hardwaredependent processing delays. Instead, it focuses on simulating the behavior that is observed in the network from the MAC layer. We achieve this with two abstractions. First, we quantize time in TSCH slots: an event can only take place at the slot boundary. Second, we abstract the protocol messages to only carry semantically-relevant parameters: exchanged messages are not byte-accurate.

We build upon these two abstractions to provide a simulator that can accurately monitor:

• the behavior of the SF in response to generated traffic (in frames/second).

• the behavior of the routing protocol in response to topological changes.

• the behavior of 6P in response to MAC-layer drops.

• the behavior of the application in response to scheduling, routing, and network stack configuration.

Different simulator instances can be scheduled to execute in parallel on available processor cores (tested up to 56 cores). The simulator is implemented in approximately 8000 lines of Python code, spanning 6 core files and a graphical interface 4 . The internal architecture of the simulator is shown in Figure 2 . The main component is Mote, where the major part of the 6TiSCH stack is implemented. It is configured by SimSettings, which contains the input parameters introduced by the user. Mote also generates metrics for SimStats and SimGUI and programs events that are scheduled and processed by SimEngine. Some of these events are the TXs and RXs, which are evaluated by Propagation depending on the existing Topology.

The graphical user interface (Figure 3 ) shows the aggregated schedule of all nodes. The user can control the simulation run, and see real-time statistics on different cells, links and nodes. The simulator can also be run in a "headless" mode (i.e. no graphical interface), allowing for fully automated runs. Finally, several generic post-processing and plot scripts are also provided in the simulator.

SimEngine

The event-driven core of the simulator is implemented in SimEngine. Events are generated by the Mote every time a new task needs to be scheduled in the future, such as increasing the ASN in the nodes, propagating a packet or firing a timeout. These events are uniquely identified by a tag formed by the node ID and a label, the event's UUID. Since more than one event can happen at the same time instant, events are registered with a specific priority and processed accordingly.

The set of events to be executed in the future, the Future Event Set (FES), is implemented using a Python list, in which events are added with the insert method and removed with the pop intermediate method. The time complexity for insert is ( ) on average, where n is the number elements in the list. The time complexity for pop intermediate is ( ) where k is the index of the event to be removed, which on average is also ( ). Each instance of the 6TiSCH simulator is run sequentially in a single thread. This means that there are no concurrency risks when two events are scheduled at the same time. The scheduler always executes first the events with lower ASN regardless its priority. For the same ASN, events with the highest priority will be inserted before other events with lower priority. In case the ASN and the priority are the same, the new event will be inserted after the last event with the same ASN and priority (i.e. in order of arrival). The simulator engine also prevents events to be inserted in the current ASN in order to remove inconsistencies when popping the next event and avoid event loops. Figure 4 shows an example of how events are inserted and removed. For example, when adding a new event with UUID X at ASN 197 and priority 1, the scheduler will iterate through the list until it finds an event with a higher ASN and lower priority than the new event.

For canceling an event, e.g. UUID B at ASN 197 in Figure 4 , the list will be iterated until the event is found. Afterwards, the event is deleted and the remaining events in the list are shifted to the left. As with the insert method, the simulator engine does not allow to remove events in the current ASN. This avoids nondeterministic behavior when trying to execute an event that is about to be deleted or vice versa.

Topology

In order to rule out the impact of a specific topology on network performance, the simulator generates a new random topology for each simulation run. The user specifies the size of the deployment area. Nodes are placed at random locations until each node has a stable physical link to a pre-configured number of neighbors. Ensuring a minimum number of neighbors per node is a common real-world deployment practice [START_REF]Linear Technology, Application Note: Planning A Deployment[END_REF]. Each link is assigned a PDR, as described in Section 4.3. Furthermore, additional topologies such as start topology and linear topology are easily configurable in the Topology file.

Propagation Model

The default propagation model implemented in the 6TiSCH Simulator is based on the Pister-Hack model [START_REF] Hanh-Phuc | Energy-Aware Routing in Wireless Sensor Networks with Adaptive Energy-Slope Control[END_REF]. This model is used to obtain the initial RSSI value of each pair of nodes in the network. This value is calculated by subtracting a uniform variance of 40 dB from the Friis model equation output. The model was independently verified in an experimental setting [START_REF] Keoma | Not So) Intuitive Results from a Smart Agriculture Low-power Wireless Mesh Deployment[END_REF]. RSSI values are then converted to Packet Delivery Ratio (PDR) values by a conversion table that is based on real-world deployments 5 . It accurately reflects the relationship between the RSSI and PDR in large indoors industrial scenarios at the 2.4 GHz band. The Pister-Hack model and the RSSI-PDR conversion table are depicted in Figure 5 and Table 2 , respectively.

The PDR values are used to calculate if a transmission is successful or not, by flipping a biased coin. In order to model the interference, the RSSI from the interfering neighbors at any given transmission is added to the ground noise in order to calculate the signal-to-interference-plus-noise ratio (SINR), which is converted eventually in the actual perceived PDR.

Energy Consumption Model

The simulator implements the energy consumption published by Vilajosana et al. [START_REF] Xavier | A Realistic Energy Consumption Model for TSCH Networks[END_REF]. The model takes a component-based approach. It defines the energy consumption of the different types of slots and combines them according to the schedule configuration. Figure 5 presents the sequence of actions that occur during a TSCH timeslot. The energy model uses that sequence of actions to model the energy consumed by a node.

For example, an active slot transmitting a data packet and receiving an acknowledgement frame (referred to as TxDataRxAck) turns the radio on twice: once for sending the data frame (for a duration of TX Packet) and once for receiving the acknowledgement frame (for a duration of RX ACK). The node's CPU is turned on during these phases, while the node stays in a deep sleep mode in the others. The model characterizes the consumption of these sub-periods within the slot and takes into account the current draw of the radio when on, the number of bytes transmitted, the data rate, and the energy consumption of the CPU in its different modes and transitions.

The model implemented within the simulator considers different types of slots as per Table 3 . After the execution of the slot, the simulator aggregates the consumed energy. The default current draw for each operation matches that of the OpenMote platform [START_REF] Xavier | OpenMote: Open-Source Prototyping Platform for the Industrial IoT[END_REF] but those values can easily be adapted to other platforms.

TABLE 3

Possible slot types as per the energy consumption model implemented within the 6TiSCH Simulator.

State Description

Idle

The node idle listens. This is a RX state where nothing is received. Hence it only listens for the duration of the guard time.

Sleep

The node Deep Sleeps. The slot is off so no CPU nor radio activity due to communication. TxDataRxAck The node transmits a packet and receives an ACK for it.

TxData

The node sends a broadcast packet not requiring ACK. RxDataTxAck The node receives a packet and responds with an ACK.

RxData

The node receives a frame that does not require to be acknowledged.

Model of a 6TiSCH "Mote"

A "mote" is an abstraction of a 6TiSCH network node and implements its different sublayers in the Mote file. At boot time, the simulation engine instantiates the required number of Mote objects and assigns the role of root to one of them. The root triggers the network formation by adding periodically EBs and RPL DIOs to its transmission queue. Simultaneously, the remaining nodes start to listen in a randomly picked channel. At every slot, the Propagation model evaluates which nodes have scheduled transmissions at this ASN and which nodes are listening. For every packet, it will determine the outcome of the transmission regarding the signal strength and the interference level provoked by concurrent transmissions in the same radio vicinity. Nodes schedule TX/RX events according to their schedule. Initially the root only wakes up in the ASNs that correspond to the minimal cell, where it sends or receives a packet accordingly. The nodes that are not synchronized yet, schedule RX events for waking up at every ASN. When a node eventually receives an EB, it synchronizes (enables its TSCH MAC layer ( 1)), and starts the joining process according to [START_REF] Tengfei | Vilajosana Xavier. 6TiSCH Minimal Scheduling Function (MSF)[END_REF]. After the node joins the network through its Join Proxy [START_REF] Mališa | Minimal Security Framework for 6TiSCH[END_REF], is able to decipher DIOs messages that allows him to select a preferred parent and obtain a rank. Once a node has selected its preferred parent, it triggers its first dedicated cell allocation (4,[START_REF] Qin | 6top Protocol (6P). draft-ietf-6tisch[END_REF]. Nodes are only allowed to send data packets only when they have dedicated cells.

The booting sequence is triggered with the help of several housekeeping callback functions that are periodically scheduled to perform specific actions at every sublayer (TSCH, RPL, MSF, etc.). Also, different events are scheduled whenever a timeout is required (6P timeout, Join timeout, MSF timeout, etc.). These events are registered in the SimEngine and will trigger the callback functions when the timers expire.

Every sublayer in Mote is highly configurable through the SimSettings component. For example, it is possible to configure the TSCH layer frame size, timeslot duration, beacon period, etc. The 6top sublayer and the scheduling function MSF can be configured by changing the parameters originated from the draft (i.e. MAX_NUMCELLS, LIM_NUMCELLSUSED_LOW, HOUSEKEEPINGCOLLISION_PERIOD, etc.). The RPL layer is implemented in the non-storing mode and also supports different configurations (DIO period, DAO period, etc.). Finally, application traffic can be constant or variable, and can be injected at any time during the simulation. The variable traffic can be modeled according to different probability distributions and configurable traffic bursts can be scheduled.

Metrics

During the execution of the simulation, event handlers trigger updates for the different metrics. Over 50 different metrics are currently implemented, however the addition of new metrics is supported and is easily implementable. Metrics can be defined as per cycle to monitor the evolution of a specific metric per TSCH slotframe cycle or as absolute in order to obtain the resulting total value after the simulation. We refer to slotframe cycle as the number of timeslots in a slotframe (i.e. 101 slots by default). Absolute metrics (such as charge consumed) can be obtained per node or aggregated over all the nodes in the network. RSSI values for every physical link are also logged. Table 4 details some of the most important metrics of the simulator.

The simulator by default logs the metrics of each simulation independently in a log file. However, simulation runs use different files and folders regarding the CPU ID and the network size. The logging directory structure can also be easily changed by the user in SimSettings. The simulator also provides with a set of helper scripts that allow the user to post-process and plot any desired metric in a fully automated manner.

VALIDATION

In order to validate the 6TiSCH Simulator we have carried out several experiments in both the simulator and OpenWSN, which is the most up-to-date 6TiSCH stack implementation available.

For the first set of experiments we compare the booting procedure while measuring the network time (i.e. number of ASNs): the synchronization time (i.e. the time in which a node receives its first valid EB), the joining time (i.e. the time in which a node securely joins the network) and the first cell time (i.e. the time in which a node has its first dedicated cell with its preferred parent). We perform 2000 iterations for both platforms in a 2-node network (root node and leaf node), using the parameters defined in the current RFCs and drafts (4,[START_REF] Qin | 6top Protocol (6P). draft-ietf-6tisch[END_REF][START_REF] Mališa | Minimal Security Framework for 6TiSCH[END_REF][START_REF] Tengfei | Vilajosana Xavier. 6TiSCH Minimal Scheduling Function (MSF)[END_REF]. In this case, we have used OpenSim, which is the Python emulator platform of OpenWSN. OpenSim runs exactly the same 6TiSCH implementation that is used in the real hardware, but objectifies the files and runs them in an abstracted Python board that virtualizes the hardware functions.

Figure 6 shows that the CDF of the three different metrics are equivalent (synchronization time, joining time and first cell time). The values are obtained in ASN, but converted to seconds for a timeslot duration of 15ms. In the three cases, the maximum error between OpenWSN and the 6TiSCH Simulator is 3.89%, 1.73% and 1.35% for sync time, join time and first cell time respectively when averaging all the samples. This proves that the simulator, although an abstraction, behaves as an accurate tool when implementing the current 6TiSCH RFCs and drafts. In the second set of experiments we asses how the performance in terms of latency is reproduced in the 6TiSCH Simulator in comparison to OpenWSN. In this case we use two real OpenMote devices that are running the OpenWSN firmware. The OpenMote devices consist of an OpenMote-CC2538 attached to an OpenUSB [START_REF] Xavier | OpenMote: Open-Source Prototyping Platform for the Industrial IoT[END_REF]. Once the leaf node has synchronized, joined and scheduled its first dedicated cell, we send 15s periodic UDP data packets from the leaf node to the root. Figure 7 a) shows that the CDFs for both platforms match and that the average latencies are practically identical, with a difference of only 0.45%. Additionally, Figure 7 b) shows that the latency patterns due to uncoupled timing between the App timer and the TSCH timer are correctly produced. This experiment not only shows that the simulator is compliant with the OpenWSN 6TiSCH implementation but also produces equivalent results as the ones obtained with OpenWSN running on real hardware. The final set of experiments consists of simulating 6TiSCH mesh networks with different numbers of nodes. We have randomly generated up to 500 full-mesh networks and used them for both the 6TiSCH simulator and OpenWSN (OpenSim). As we did in the first set of experiments, we log the sync time, joining time and first cell time of each node and we plot them in Figure 8 as absolute values starting from the initialization of the network. The bars represent the average value of each run of all the nodes (except the root node). Figure 8 shows that times are similar for all networks. For example, in case of the first cell time, the differences are 1.35%, 3.08%, 1.69%, 1.55% and 2.91% for 2, 4, 6, 8 and 10 nodes respectively.

PERFORMANCE EVALUATION

In order to give an overview of the computational performance of the 6TiSCH simulator and analyze its scalability, we have carried out simulations varying the number of nodes in the network. We have used two independent testbeds, Testbed 1 and Testbed 2, the first one being more powerful than the second one:

• Testbed 1 consists of a server equipped with 56 Intel Xeon E5-2680 CPUs at 2.40GHz and 35840 KiB of CPU cache.

Each CPU has 14 internal cores.

• Testbed 2 consists of a desktop computer equipped with 4 Intel Core 2 Duo E4-500 CPUs at 2.20GHz and 2048 KiB of CPU cache. Each CPU has 2 internal cores.

The tests were performed using only one CPU per run without additional process load. Each run consisted of running a fullymeshed 6TiSCH network for 2000 cycles (3000 seconds when using a timeslot of 15 ms). Once all the nodes in the nodes in the network were synchronized, joined the network and allocated their first dedicated cell to their preferred parent, each node sent 1 packet every 5 seconds to the root. When considering DIOs, EBs, DAOs and DATA packets, each node sent on average of 1500 packets during the simulation.

Figure 9 (a) shows the CPU time (user time) used by the process running the 6TiSCH simulator. It shows that the time required for simulating a 6TiSCH network of 1000 nodes scales up to 31 one hours when using Testbed 1. When using Testbed 2, this time increases to 38 hours.

Regarding the memory usage, both testbeds show an approximately linear-like behavior, having a maximum of memory usage of less than 97 MiB for 1000 nodes.

These results are merely an indicator of the overall performance of the simulator since they are only valid for this specific scenario. CPU times and memory used for simulating different network sizes will vary depending on the number of cycles simulated and the traffic load. For example, 1000 runs of 1000 cycles each of a network with 50 nodes, can be simulated in less than 8 minutes.

EXAMPLE USE CASES

The 6TiSCH Simulator is an interesting tool to answer questions that commonly arise when running "what-if" scenarios with different topologies, traffic patterns and application-level networking requirements. This section gives 5 example use cases of the 6TiSCH simulation. The results of these examples have been published in previous works. Network formation and joining process: How does the number of nodes influences the network time formation? Vučinić et al. conducted a study on the optimal broadcast transmission probability in 6TiSCH networks [START_REF] Vučinić Mališa | Broadcasting Strategies in 6TiSCH Networks[END_REF]. One of the major research contributions of the paper is the given set of values for improving the network formation time. Figure 10 illustrates how the collision probability in a broadcast cell increases in terms of network density. For this work, the 6TiSCH Simulator easily allows to not only perform quick simulations with different broadcast parameters (i.e. different EB periods) but also implement new broadcast strategies (i.e. test the new Bayesian broadcast mode). One of the outcomes of this work is that by using probabilities of = 1∕3 and = 0.1 the network formation time is the lowest for networks of up to 45 nodes. Also, the Bayesian broadcast is introduced, which is implemented in both the 6TiSCH Simulator and OpenWSN.

Scheduling policies: Which is the average latency of a packet for different scheduling alternatives? Daneels et al. present a new scheduling function for recurrent traffic patterns, called ReSF [START_REF] Glenn | ReSF: Recurrent Low-Latency Scheduling in IEEE 802.15.4e TSCH networks[END_REF]. ReSF calculates minimal-latency paths from source to sink, only activating these paths when recurrent traffic is expected. They also compare ReSF with other state-of-the-art scheduling functions such as LLSF and SF0. Figure 11 shows how ReSF optimizes latency and outperforms the mentioned SFs, which can have delays of up to several seconds. This work is an example of how the 6TiSCH Simulator can be used for studying the performance of 6TiSCH networks (in this case, latency and energy consumption) and for proposing new methods to improve it. ReSF is implemented and tested for a number of configurations, while varying the traffic rate and its period change probability [START_REF] Duy Thang Phan | Distributed Cell Selection for Scheduling Function in 6TiSCH Networks[END_REF]. By analyzing the cell density of a given portion in the schedule, nodes can select the portion which has the least number of used cells. As shown in Figure 12 a, collisions are notably reduced when using ESF0 due to portions of the schedule that are distributed more uniformly than in SF0 and LLSF so that the collision probability is lower. Another approach for avoiding scheduling collisions is presented by Muraoka et al. [START_REF] Kazushi | Simple Distributed Scheduling with Collision Detection in TSCH Networks[END_REF]. In this work, a reactive policy of cell relocation is proposed to reduce packet collisions by measuring and tracking the PDR at every cell. A cell with a bad PDR is replaced if its PDR is unexpectedly lower than the average. Since these unexpected low PDRs are usually due to collisions, reactive cell allocation shows to be an effective approach for collision avoidance. Figure 12 b shows that, by running relocation algorithms at both transmitter and receiver, the number of collisions can be reduced significantly. These two works are also examples of using the 6TiSCH Simulator for fast and dynamic implementation of scheduling functions in order to reduce the 6TiSCH internal interference and increase network reliability. [START_REF] Katina | A Load Balancing Algorithm for Resource Allocation in IEEE 802[END_REF]. The Local Voting algorithm tries to minimize the maximum latency in the network by evenly distributing the traffic among the nodes in the network. This traffic distribution is performed by monitoring the queue length of the neighbors of every node and adding or removing links accordingly to minimize latency and reduce power consumption.

Figure 13 illustrates, for bursty traffic of 5 packets per burst, how the queues are filled, showing the differences between the proposed algorithm Local Voting and SF0 for different cell thresholds. This last use case shows how the 6TiSCH Simulator metrics (in this case, queue length and queue drops) is a useful tool for implementing new scheduling functions to improve traffic management.

FIGURE 13

Queue usage during a simulation for different SF0 thresholds and when using a Local Voting scheme for load balancing. Reproduced from [START_REF] Katina | A Load Balancing Algorithm for Resource Allocation in IEEE 802[END_REF].

CONCLUSIONS

This article introduces the 6TiSCH Simulator, a tool for easily evaluating the performance of a fully standards-based 6TiSCH network. It allows end-users and potential 6TiSCH adopters to conduct "what-if" scenarios and evaluate whether 6TiSCH is applicable to their application. It allows researchers to compare the performance of their optimization against the fully standardscomplaint solution. It allows the 6TiSCH working group to verify the performance of what is being standardized. The simulator is published under an open-source license. This article validates the tool, does a computational performance analysis and shows 5 example use cases of previously-published works which use the 6TiSCH Simulator as the primary tool for performance evaluation.

FIGURE 2

 2 FIGURE 2 Internal architecture of the 6TiSCH Simulator.

FIGURE 3

 3 FIGURE 3 Screenshot of the 6TiSCH Simulator user interface.

FIGURE 4

 4 FIGURE 4Example of how the FES is managed in the 6TiSCH Simulator.

FIGURE 5

 5 FIGURE 5 RSSI values generated using the Pister-Hack model.

FIGURE 5

 5 FIGURE 5 Timeslot timing and sequence of actions used to derive the energy consumption of a node.

FIGURE 6

 6 FIGURE 6Comparison between the 6TiSCH Simulator and OpenSim in terms of synchronization time, joining time and the time it takes for a node to have the first dedicated cell since joining the network.

FIGURE 7

 7 FIGURE 7Latency comparison between the 6TiSCH Simulator and OpenWSN.

FIGURE 8

 8 FIGURE 8Comparison between the 6TiSCH Simulator and OpenWSN (OpenSim) in terms of synchronization time, joining time and first cell time for different network sizes.

FIGURE 9

 9 FIGURE 9 CPU Time and memory consumed for different network sizes in two different testbeds.

FIGURE 10

 10 FIGURE 10 Probability of collision as a function of the number of nodes in the network. Reproduced from (17).

FIGURE 11

 11 FIGURE[START_REF] Glenn | ReSF: Recurrent Low-Latency Scheduling in IEEE 802.15.4e TSCH networks[END_REF] Latency obtained with 100 nodes for different scheduling functions (SF0, eLLSF and ReSF). Reproduced from[START_REF] Glenn | ReSF: Recurrent Low-Latency Scheduling in IEEE 802.15.4e TSCH networks[END_REF].

FIGURE 12

 12 FIGURE 12 How different scheduling functions tackle the packet collision problem in 6TiSCH.

TABLE 1

 1 Comparison between the 6TiSCH Simulator and the different network simulator alternatives.

	Simulator	Learning Curve Scalability 6TiSCH implementation Standard-Compliant
	ns-3	High	Medium	None	N/A
	OMNet++	High	Medium	None	N/A
	TOSSIM	Medium	High	None	N/A
	Cooja (emulator)	High	Low	Yes (Partial)	Partially
	OpenSim (emulator)	High	Low	Yes	Yes (byte-accurate)
	6TiSCH Simulator	Low	High	Yes	Yes (behavioral)

TABLE 2

 2 RSSI-PDR translation.

TABLE 4

 4 Some of the available metrics in the 6TiSCH Simulator

	State	Type	Description
	Average latency	Per cycle	Average latency of packets arriving at the root (in ASNs)
	Charge consumed	Absolute	Charge consumed by all nodes during the simulation
	Charge consumed at every node Absolute	Total charge consumed by a node during the simulation
	App packets generated/received Per cycle	Number of data packets generated and received at every cycle
	Number of TX/RX	Per cycle	Number of MAC frames sent and received at every cycle
	Number of drops	Per cycle Drops are classified by its cause: QueueFull, MaxRetries and NoRoute
	Number of used cells	Per cycle	TX/RX/SHARED cells used by all the nodes
	Colliding cells	Per cycle	Dedicated cells used in more than one link
	Parent changes	Per cycle	Number of parent changes per cycle

One vendor alone -Emerson -reports over 35,000 networks deployed, which translates to over 10-Billion operating hours (https://www.emerson.com/en-us/ expertise/automation/industrial-internet-things/pervasive-sensing-solutions/wireless-technology)

As an online addition to this article, the code of the simulator, published under an open-source BSD license, can be found at https://bitbucket.org/6tisch/simulator

A less detailed, but fully-simulated version is also available, but is still significantly time consuming.

In contrast, other network simulators, such as NS-3 in the current 3.28 version, have up to 1483072 lines when considering ".cc", ".h" and ".py" files.

The connectivity traces were obtained from the http://wsn.berkeley.edu/connectivity/ project at the University of California, Berkeley, lead by Thomas Watteyne and Prof. Kris Pister. The dataset used is "soda", created by Jorge Ortiz and Prof. David Culler.

ACKNOWLEDGMENTS

This work is partially supported by the Flemish FWO SBO S004017N IDEAL-IoT (Intelligent DEnse And Long range IoT networks) project, the ICON CONAMO project with support from VLAIO (Flanders Innovation and Entrepreneurship), the Spanish Ministry of Economy and the FEDER regional development fund through the SINERGIA project (TEC2015-71303-R), and the European Commission through the H2020 F-Interop and H2020 ARMOUR projects.


Xavier Vilajosana

Borja Martinez

Ignasi Vilajosana

Thomas Watteyne

On the Suitability of 6TiSCH for Wireless Seismic Data Streaming

Keywords: Wireless seismic data acquisition, passive seismic, IETF 6TiSCH, Wireless Data transmission, Low Power

Seismic tomography is a technique for imaging the subsurface of the Earth with seismic waves produced by earthquakes (passive) or explosions (active). A typical instrumentation deployment involves hundreds or even thousands of equally distributed data-loggers, reading from geophones, that sample typically between 250 Hz and 2000 Hz in a synchronized manner. This data is streamed outside the data-logger network for postexperiment processing. In this letter, we evaluate the suitability of IETF 6TiSCH technology for a standards-based real-time data streaming solution, and highlight the benefits of standardization in this market sector.

I. INTRODUCTION

T HE sub-soil exploration concept can be compared to the procedure executed by a digital camera, but instead of using a CCD optical sensor array over an area of a few square millimeters, seismic exploration uses thousands of geophone vibration sensors spread over a field of a few square kilometers. An seismic source (an earthquake, or a hammer) creates seismic waves which propagate throughout the soil and get reflected on inflection points, such as the ones created by pockets of oil. The reflected waves are recorded by surface sensors and post-analyzed to get a precise idea of the composition of the sub-soil.

Large-scale deployments typically use cabled solutions, leading to typical cable lengths of 1,000 km for medium fields and 10,000 km for larger fields. In addition, the depth of exploration depends on the total end-to-end dimension of the field, also referred to as aperture, where a larger aperture allows for greater depths. Finally, the distance between the sensors determines the resolution where a denser field yields a higher subsoil resolution.

In the last years, seismic prospection equipment has been augmented with wireless capabilities, i.e. battery operation and capacity to store the data, in order to reduce operating costs during deployments. Cabling large extensions of irregular terrain is a very labor-intensive task, which vendors and prospection companies are well-aware of. The new trend is to deploy battery-equipped devices capable of storing the collected data for post-experiment extraction. However, postexperiment data extraction is perceived as risky by the industry as the experiment costs are important, and typically cannot be repeated. Quality control (QC) mechanism are therefore progressively being adopted. The latest QC best practice exploits wireless communication technologies to extract samples of the measured data, and stream them to a central unit for pseudo real-time processing. This yields more advanced solutions that aim to stream all the data in real time.

The complexity of the wireless deployments is mainly due to the reliability expected from the network and the scale of the deployment. The devices are at ground level and propagation is subject to multi-path fading and Fresnel zone obstruction that require power amplifiers and directional antennas or complex TDMA link-layer schemes to cope with internal interference. Current approaches build complex network structures combining WiFi clusters and wireless back-hauling technologies to stream the data out of the aggregation points. WiFi Mesh technologies are being adopted to overcome the limitations of star topologies, at the cost of high energy consumption. Lowpower wireless technologies are barely explored in the field due to their low data rates.

The requirements for real time data streaming in such deployments encompass the capacity to stream 250 to 2000 samples per second for different sensing channels. A sample is usually 24 bits and an experiment lasts between a few days to several months. Quality Control is another system feature where few samples of data are extracted continuously to certify the correctness of that data. This requires in the order of 20 samples per second. Nodes are spread in a regular topology and traffic is constant during the experiment. This means simple TDMA scheduling approaches can be used, with the important requirement that no sample is lost. This strict reliability consideration is a challenge for any wireless technology and hence one of the most important technical barriers.

This letter explores the suitability of a novel low-power wireless standard to address this application. We study the suitability of the IETF 6TiSCH protocol stack [START_REF] Dujovne | 6TiSCH: Deterministic IP-enabled Industrial Internet (of Things)[END_REF] -rooted in the IEEE802.15.4-2015 Time Synchronized Channel Hopping standard -to stream data from the dataloggers. We evaluate the limits of this technology and outline the most useful configurations for the target application. We also claim the benefits of standardization in this scenario, and point out some future improvements in the technology to better support reliable data streaming.

The remainder of this article is organized as follows. Section II provides a technical overview of seismic acquisition solutions, with a particular focus on wireless. Section III provides a baseline to understand the traffic requirements and network topology in the wireless seismic network. Section IV introduces 6TiSCH, and discusses the suitability of possible configurations to meet the baseline requirements. Section V presents key advantages of using the 6TiSCH technology, especially focusing on energy efficiency when compared to WiFi-based solutions. Finally, Section VI discusses the directions taken by the seismic data acquisition market, and outlines possible improvements to the standard technology.

II. RELATED APPROACHES

Enabling wireless data acquisition in seismic prospection has been a prominent development topic in the data logger industry. In this field, two different approaches have coexisted. The historical solution involves standalone battery-powered devices with local storage, but no real time data extraction capabilities. These solutions are based nodes with internal storage capabilities to store the sampled data. Recent products include wireless connectivity interfaces to extract data after the experimentation, for quality control or on-demand. In most of the cases however, devices are collected after the experimentation and racked together to a base station that extracts the data from their memories. The solutions that are developing today include wireless communicating, allowing for both real-time and off-site data transmission.

Example products include the IoN Firefly1 , a first generation wireless device using licensed band wireless communication. The product was abandoned 2011 due to the poor performance, the difficulties to cope with terrain irregularities and the high power consumption and cost.

Sercel2 , acquired Vibtech and their expertise in IEEE802.11 technologies. Their current UNITE recorder and base station uses WiFi to build a star of stars topology. It uses dual-band WiFi to link nodes to relays at 2.4 GHz. Relays then use the 5 GHz band to mesh the data to a base station. The product features high-gain antennas to allow links of up to 1 km in line-of-sight conditions. The system remains expensive and power hungry. Wireless Seismic4 developed a proprietary low power mesh protocol based on low power IEEE802.15.4. They exploit a particular implementation of Time Synchronized Channel Hopping (TSCH), building a multi-hop time-slotted structure. Nodes form a mesh network with a very regular topology, usually organized in lines. Their network supports control, status and data transmission in real time. Wireless Seismic technology is ultra-low power when compared to other technologies.

III. UNDERSTANDING THE STREAMING REQUIREMENTS

In a seismic data collection scenario, the physical topology is very regular, with nodes equally-spaced throughout the deployment area. Network density depends on the type of deployment; devices can be deployed 10 m to 1000 m apart. While there is no line-of-sight across the entire deployment area, the topology is usually regular from a geographical point of view (as seen in Fig. III) redundant . Devices are usually deployed in hard-to-reach areas, and need to operate continuously for days or weeks. As a result, nodes are usually battery powered, and need to be low-power and small. The total bandwidth β required for a particular deployment composed of h nodes is determined by the sampling rate n (samples per second) of the nodes in the network, the size of each sample σ (bytes), and the total size of the timestamp and metadata associated to the samples τ (bytes). β is given in [START_REF] Dujovne | 6TiSCH: Deterministic IP-enabled Industrial Internet (of Things)[END_REF].

β = h k=0 (n k * σ k ) + τ k (1)
This total bandwidth β is a key parameter when designed the network as it represents the capacity that a base station must support to collect the data.

The overhead τ can take different forms: one timestamp and metadata block for the entire set of n k samples, or a timestamp for each sample. The former assumes sampling at a constant period; the latter lifts that requirement, at the cost of at least n k times the size of the timestamp.

IV. 6TISCH CAPACITY AND CONFIGURATION

The IETF 6TiSCH working group is standardizing a set of protocols to enable IPv6 connectivity and distributed scheduling on top of the IEEE802.15.4 Time Synchronized Channel Hopping (TSCH) link layer operation. TSCH targets demanding industrial application scenarios providing higher levels of reliability [START_REF] Watteyne | Reliability Through Frequency Diversity: Why Channel Hopping Makes Sense[END_REF], [START_REF] Watteyne | Lessons Learned from Large-Scale Dense IEEE802.15.4 Connectivity Traces[END_REF]. TSCH combines network-wide synchronization and channel hopping to achieve over 99.999% end-to-end reliability, and over a decade of battery lifetime. TSCH is the root concept for protocols such as TSMP [START_REF] Pister | TSMP: Time Synchronized Mesh Protocol[END_REF], WirelessHART and ISA100.11a. In the following subsections, we describe what the capacity limits of a 6TiSCH network are, and detail the configuration trade-off to optimize the network capacity in order to address the target application.

A. 6TiSCH Capacity

The IEEE802.15.4 standard defines a data rate of 250 kbps, a maximum frame size is 127 B, and a default timeslot duration is 10 ms. This yields a maximum raw datarate of approx. 100 kbps.

Fig. 3 presents the mapping between the sampling rate n and the number of nodes h, given a fixed sample size of 24 bits and considering an IEEE802.15.4e TSCH, 6LoWPAN and UDP header overhead of 22 bytes. 6TiSCH supports different network structures for sampling rates under 1000 sps. This means the technology covers quality control data extraction and use cases for passive seismic where the required sampling rates are well below 1000 sps [START_REF] Schubert | Treatise on Geophysics[END_REF].

A 6TiSCH base station can be equipped with multiple receivers, enabling up to 16 concurrent subnetworks to be operating at the same time. In this case, the capacity depicted in Fig. 3 is multiplied by the number of available transmission channels, and leads to an interesting increment in the scale of the deployment. If we consider a deployment where nodes sample at 500 sps, with a time slot duration of 10 ms, 6TiSCH can handle 8 devices for each communication channel. When using the 16 available channels 5 , a single base station can support up to 128 devices transmitting simultaneously.

B. 6TiSCH Configuration

In order to optimize the 6TiSCH protocol stack, the IEEE802.15.4 TSCH MAC layer needs to be configured to minimize the header length. According to the minimal 6TiSCH profile [START_REF] Vilajosana | Minimal IPv6 over the TSCH Mode of IEEE 802[END_REF], once the network has formed, nodes use short addresses and PANID compression. The Frame Control (FCF) field of the IEEE802.15.4 header should be used with the configuration depicted in Tab. I, leading to a MAC layer header size of 12 bytes, including the security header and FCS. The 6LowPAN [START_REF] Montenegro | Transmission of IPv6 Packets over IEEE 802.15.4 Networks, IETF Std. RFC4944[END_REF] header accounts for an addition 4 bytes, because of the 6LoRH header [START_REF] Thubert | IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch[END_REF], assuming one page and carrying the RPL RPI option for routing purposes [START_REF] Hui | The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams[END_REF]. The IPHC header [START_REF] Hui | Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks[END_REF] adds another 2 bytes, using the UDP compressed Next Header (NH) and full IPv6 address compression. UDP adds an overhead of 2 bytes, assuming the CRC is elided and a UDP port in the range 61617-61624 is used [START_REF] Hui | Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks[END_REF]. This leads a total overhead of 22 bytes for all headers, leaving 105 bytes for application data.

To further optimize the bandwidth, the signaling overhead of the protocols needs to be minimized. This is achieved by the 6TiSCH distributed operation layer. 6TiSCH has developed a configuration profile [START_REF] Vilajosana | Minimal IPv6 over the TSCH Mode of IEEE 802[END_REF] that enables a network to form a simple control and data plane for nodes to join. Once the network has been formed, distributed scheduling policiesreferred as "Scheduling Functions" -operate in a distributed manner, and reserve the required resources to meet the application communication requirements [START_REF] Chang | LLSF: Low Latency Scheduling Function for 6TiSCH Networks[END_REF], [START_REF] Dujovne | 6TiSCH 6top Scheduling Function Zero (SF0)[END_REF], [START_REF] Domingo-Prieto | Distributed PID-Based Scheduling for 6TiSCH Networks[END_REF]. The routing topology is maintained by the RPI header once the network has been formed. RPL DIO and DAO message periods can be significantly reduced as 6LoRH routing extension headers update the topological information. Once a data collection experiment starts, the stable bandwidth requirement reduce the control plane overhead as the schedule of the network is already configured. In addition, network synchronization is maintained with no additional overhead.

V. ENERGY CONSUMPTION EVALUATION

We model the network schedule of a device, taking into account the maximum supported throughput, and evaluate its energy consumption based on a well-establish energy model for TSCH [START_REF] Vilajosana | A Realistic Energy Consumption Model for TSCH Networks[END_REF]. This model computes the energy spent by a node as a function of the type of slot (sleep, transmitting, receiving, idle listening). We compare those results to WiFi, with the same traffic requirements. The WiFi model considers that the energy consumed by an 802.11 device is dominated by the type of operation: (i) the idle consumption, (ii) the energy spent by the protocol stack when transmitting the packet, (iii) the power required to transmit the packet, (vi) the power consumed in retransmissions, (v) the reception power, (vi) the energy overhead of processing the received frames , and (vii) the energy spent on sending and receiving ACK frames.

We assume we are using an IEEE802.15.4 TI CC2650 in the TSCH case, and an IEEE802.11 CC3200 in the WiFi case. Both chips are representative to the technology at the time of writing. Datasheet numbers for both chips are summarized in Table II.

Fig. 4 presents the energy consumption of a WiFi and 6TiSCH based solution. We model the best-case connectivity in which there are not WiFi retransmissions. The advantage of using 6TiSCH over WiFi at low sampling rates is clear.

VI. CONCLUSION

This letter discusses the suitability of the IETF 6TiSCH protocol stack for real-time wireless seismic data acquisition. It presents the 6TiSCH protocol configuration to maximize network capacity. 6TiSCH can support clusters of up to 128 nodes per gateway, enabling a reliable real-time network for sampling rates below 1000 samples per second. Moreover, due to the low-power characteristics of IEEE802.15.4, the energy consumption is several times lower than WiFi.

ACKNOWLEDGMENTS

This work is partially supported by the Spanish Ministry of Economy and the FEDER regional development fund through the AVANZA (RADIOOIL) project and the SINERGIA project (TEC2015-71303-R), and the European Commission through the H2020 F-Interop and H2020 ARMOUR projects.

Fig. 1 .

 1 Fig. 1. A typical active seismic deployment involving dataloggers deployed on the ground and trucks that generate seismic waves.

Fig. 2 .

 2 Fig. 2. Deployments are made using regular topologies where different sinks or collection devices gather date from clusters of nodes. A backhauling technology is used then to relay the data.

Fig. 3 .

 3 Fig. 3. Network capacity in relation to the number of nodes in the network considering header overhead. Red and green lines delimit the capacity for 10ms and 5ms slot sizes.

Fig. 4 .

 4 Fig. 4. Relative energy efficiency of a 6TiSCH node when compared to WiFi in relation to the sampling rate.

TABLE I FRAME

 I CONTROL FIELD CONFIGURATION FOR SMALLEST PACKET SIZE

	Type	Security Enabled	Frame Pending	ACK Requested	Intra-PAN	seqnum Suppression	IE Present	Destination Addr. Mode	Frame Version	Src. Addr. Mode
	Data 01	1	0	1	0	1	0	10	10	10
	ACK 10	1	0	0	0	1	1	10	10	10

http://www.iongeo.com/2007AR/firefly blog.htm

http://www.sercel.com

http://www.iseis.com

http://www.wirelessseismic.com

between 2.405 MHz and 2.480 MHz.


Mali A Vu Ini
email: malisa.vucinic@inria.fr

| Thomas Watteyne

| Xavier Vilajosana

Broadcasting Strategies in 6TiSCH Networks

We consider IPv6-enabled networks that run on top of the time-slotted channel hopping mode of IEEE802.15.4 (6TiSCH). The ongoing discussions in the standardization community concern the network formation process and the definition of a bootstrapping protocol by which a new mote is admitted into the network. Because the bootstrapping tra c uses the same shared slots as the network broadcasts, the key to the optimal performance of the network formation process lays in the optimization of the network broadcasting strategy. The problem boils down to the issue of stabilizing slotted Aloha. To do so, we adapt a broadcast algorithm to the specifics of 6TiSCH networks. By simulation, we evaluate the optimal broadcast transmission probability in the network. We answer the open questions in the IETF 6TiSCH standardization community that concern the performance of the network formation process for the optimal values of transmission probability. As the main contribution of the letter, we provide network administrators with a set of values that allow the formation of dense networks.

INTRODUCTION

6TiSCH is a technology being standardized by the IETF which combines the performance of IEEE802.15.4 TSCH with the interoperability of IPv6. 6TiSCH is a key enabling low-power wireless technology for the Industrial Internet of Things (IIoT). The working group currently focuses most of its e ort on the bootstrapping protocol that allows a new mote to be admitted into the network. This protocol is currently under heavy discussion within the security design team at the IETF 6TiSCH working group; this letter addresses the open questions that concern its performance.

In 6TiSCH networks, the bootstrapping tra c is combined with broadcast tra c and transmitted in shared slots in a slotted Aloha fashion. For this reason, the performance of the bootstrapping protocol is inherently dependent on the broadcasting strategy used in the network. This letter proposes an optimization of the performance of a generic bootstrapping protocol by revisiting the broadcasting strategy in the network.

As each mote joins the network, it starts broadcasting within a single shared slot that is defined by the recently standardized "Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration" [START_REF] Vilajosana | Minimal IPv6 over the TSCH Mode of IEEE 802[END_REF]. Broadcasts in 6TiSCH networks include Enhanced Beacons (EBs) -used by new motes to synchronize to the network -and RPL DIOs -used by motes to build a directed acyclic graph for routing purposes. In dense networks, this creates congestion: broadcast tra c of di erent motes collides due to the limited bandwidth. E ectively, this limits the formation of large networks when the instability point of slotted Aloha is reached.

State-of-the-art approaches [START_REF] Duquennoy | Orchestra: Robust Mesh Networks Through Autonomously Scheduled TSCH[END_REF][START_REF] Khoufi | Building an IEEE 802.15. 4e TSCH network[END_REF][START_REF] Vogli | Fast join and synchronization schema in the[END_REF] address the problem by assigning additional bandwidth; this comes with extra maintenance and energy cost [START_REF] Vilajosana | A Realistic Energy Consumption Model for TSCH Networks[END_REF]. Using the Trickle timer (6) to schedule EBs is not feasible in 6TiSCH as new motes have no means of soliciting its reset without being synchronized with the network. We adopt a di erent approach and adapt the Bayesian broadcast algorithm [START_REF] Rivest | Network control by Bayesian broadcast[END_REF] to stabilize slotted Aloha. In Bayesian broadcast, each broadcast frame is transmitted with a given probability of transmission. It is possible to maximize the probability that exactly one transmission occurs during the slot by using an optimal value of probability of transmission. However, in the 6TiSCH case, apart from the broadcast tra c, bootstrapping tra c also ends up in the slotted Aloha slot. Depending on the load of the bootstrapping tra c, the optimal probability of transmission changes.

We simulate 6TiSCH networks for di erent bootstrapping loads to evaluate the optimal probability of transmission. Then, to answer the open questions in the IETF 6TiSCH working group, we evaluate the performance of the bootstrapping protocol with these optimal values of broadcast probability of transmission. The contributions of this letter is three-fold:

• We provide a practical adaptation of the Bayesian broadcast algorithm to 6TiSCH networks.

• We extend the 6TiSCH simulator1 to simulate the shared slots, downwards and bootstrapping tra c and provide the open-source extension for the benefit of the community.

• We provide extensive results on the duration of the network formation process in 6TiSCH networks, as well as on the optimal set of parameters to run a 6TiSCH network.

The remainder of this letter is organized as follows. Section 2 outlines the network formation process in 6TiSCH networks. We adapt the Bayesian broadcast algorithm to 6TiSCH in Section 3. Section 4 studies the performance of the proposed approach and gives estimates on the duration of the network formation process. Section 5 concludes this letter.

NETWORK FORMATION IN 6TISCH NETWORKS

In a 6TiSCH network, all motes periodically transmit Enhanced Beacon (EB) frames. Motes that are joining the network continuously listen for EBs sent by nearby motes. The EB contains enough information for a new mote to synchronize to the slotframe and the slot boundary of the given network, once an EB is received. Because transmissions in a TSCH network cycle over all available channels, to hear an EB, a new mote needs to keep its radio constantly listening on a single channel. A well-known approach is that motes select a random channel to listen on, which distributes the load on the network by new motes joining. This e ectively divides the load by the number of channels, as motes receive EBs at di erent instants and therefore independently trigger the join process.

The reception of an EB indicates to the mote the position of a shared cell that is used for network bootstrapping [START_REF] Vilajosana | Minimal IPv6 over the TSCH Mode of IEEE 802[END_REF]. All broadcast tra c in the network -as well as the bootstrapping (join) unicast tra c -is transmitted within this shared cell, in a slotted Aloha fashion. Bootstrapping (join) tra c refers to frames exchanged as a result of the security protocol by which a new mote is admitted into the network. We consider a generic bootstrapping protocol with variable number of round trips in order to shed light on how this protocol design consideration a ects the network performance. The broadcast tra c is divided into EBs and the routing protocol overhead, which in 6TiSCH are RPL DIO messages [START_REF] Winter | RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks[END_REF]. DIOs are used for the construction of a directed acyclic graph for upwards routing. As each mote joins, it starts emitting EBs and DIOs in the slotted Aloha cell.

Once first hop motes join and start transmitting EBs, they extend the range of the network by serving as relays to the secondhop motes. The process repeats, with the critical part being the radio access in the slotted Aloha manner. The network formation finalizes when the last hop motes join.

The problem arises as more and more motes join, they start congesting the slotted Aloha cell with EBs and DIOs, preventing new motes to join. Related work tackles the problem by assigning additional cells for maintenance tra c [START_REF] Duquennoy | Orchestra: Robust Mesh Networks Through Autonomously Scheduled TSCH[END_REF][START_REF] Khoufi | Building an IEEE 802.15. 4e TSCH network[END_REF][START_REF] Vogli | Fast join and synchronization schema in the[END_REF]. Such approaches -which statically assign a set of additional cells -incur additional energy consumption and management overhead. They are also not compliant to the recently standardized "Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration" (1).

BAYESIAN BROADCAST ALGORITHM IN 6TISCH

The shared cell in a 6TiSCH network needs to accommodate three types of tra c: (1) EBs; (2) DIOs; (3) bootstrapping -or "join" -tra c. Our goal is to tune the probability of transmission of these frames in order to lower the contention and so operate at a stable point of slotted Aloha. We therefore propose the adaptation of the Bayesian Broadcast Algorithm by Rivest [START_REF] Rivest | Network control by Bayesian broadcast[END_REF] to 6TiSCH networks.

The basic idea of the Bayesian Broadcast Algorithm is simple: at each shared cell, each mote in a network transmits a (broadcast) packet with a probability p tx . Given a fully-meshed network with N motes, the probability that there is exactly one transmission in a shared cell is denoted as P success and given in Eq. [START_REF] Vilajosana | Minimal IPv6 over the TSCH Mode of IEEE 802[END_REF].

P success = Np tx (1 * p tx ) N*1 .
(1) The probability of success is highest for p tx = 1_N [START_REF] Rivest | Network control by Bayesian broadcast[END_REF]. We consider N as known, as it is easy to estimate locally using, for example, received EBs. The problem in the 6TiSCH case, however, is how to locally configure the broadcasting probability of di erent types of tra c, taking into account a non-broadcast component p join caused by bootstrapping. The p join component is the result of non-deterministic tra c sent by each mote during bootstrapping stage.

p tx = p ® EB + p ® DIO + p join .
(2) We maximize throughput when the value of p tx in Eq. ( 2) is 1_N. For each slotted Aloha transmission opportunity (i.e. for each shared cell), each mote flips a biased coin and sends an EB with a probability p ® EB = p EB _N, or a DIO with a probability p ® DIO = p DIO _N. It is important to stress that N includes only motes that have already joined the network so it dynamically changes during the formation process. In Section 4, we simulate the network formation process to evaluate the optimal value of p EB for di erent load of the bootstrapping protocol. The load of the bootstrapping protocol a ects the p join component in Eq.

(2).

Eq. ( 1) considers the case where N motes are present in the network and are all broadcasting DIOs and EBs. During the network formation process, this is not the case as motes join one by one, and only start broadcasting once joined. By conditioning N, we can approximate Eq. ( 1) in the network formation by Eq. ( 3).

P ® success = N … n=1 np tx (1 * p tx ) n*1 ù P (N = n). (3)
Similarly to Eq. ( 1), the probability of a "hole" (per the terminology of ( 7), the case where there is no packets transmitted in the slotted Aloha cell) with N motes broadcasting is expressed in Eq. ( 4).

P hole = (1 * p tx ) N .
(4) In the network formation case, the probability of a hole can be found similarly to Eq. (3). And finally, the probability of collision is expressed in Eq. [START_REF] Vilajosana | A Realistic Energy Consumption Model for TSCH Networks[END_REF]. P collision = 1 * P success * P hole .

(5) A metric of interest in the 6TiSCH case is T F B , the mean time between the moment a new -unsynchronized -mote is powered on, and the moment it receives a first beacon. Considering the minimal schedule [START_REF] Vilajosana | Minimal IPv6 over the TSCH Mode of IEEE 802[END_REF] where there is one opportunity to transmit broadcast once per slotframe, this time is expressed in Eq. [START_REF] Levis | Trickle: A Self-Regulating Algorithm for Code Propagation and Maintenance in Wireless Sensor Networks[END_REF].

T F B = L S ù C p EB , (6)
In Eq. ( 6), L S denotes the slotframe length and C number of channels in use.

EVALUATION

We want to answer the following question: what is the optimal configuration of a 6TiSCH network, given the tra c load of the bootstrapping protocol and maximal number of motes in a radio neighborhood. By simulation, we find the optimal value of p EB ; given that value, we further study the overall duration of network formation process and its energy consumption. We extend the 6TiSCH simulator to support shared cells and downward tra c. Our contributions are open-source for the benefit of the community. The simulator implements the bootstrapping schedule according to [START_REF] Vilajosana | Minimal IPv6 over the TSCH Mode of IEEE 802[END_REF].

We perform the simulations for fully-meshed networks, as this represents the worst case in terms of slotted Aloha contention. For all results in this section, we fix p DIO to one-third of the optimal probability of transmission in order to permit the construction of the directed acyclic graph and give enough room for the bootstrapping tra c and EBs (see Eq. ( 2)). The e ect of p DIO setting can only be seen in multihop topologies. We found one-third to be a good compromise between the tra c load and the speed of convergence of the directed acyclic graph.

We measure the probability of success, i.e. the probability that exactly one transmission occurs during the shared slot, as it gives us an idea how throughput behaves as a function of tra c load. We also measure the probability of collision, i.e. the probability that more than one transmission occurs during the shared slot, in order to understand the relation of tra c load and wasted transmissions. Finally, we study the performance of the overall join process in terms of its duration and energy consumption as it gives us an insight on how costly it is to build a network at startup. We fix the probability by which DIOs are sent and vary the tra c load by increasing the value of p EB . We also vary the tra c load of the bootstrapping protocol by increasing the number of required round trips. We expect that, with the increased bootstrapping load, the optimal value of p EB decreases due to the increased load on the shared cell.

Each data point is an average of 100 simulation runs; we plot 95% confidence intervals.

The probability of success increases for small values of beacon probability (see Fig. 1 a) due to the fact that there is not enough tra c generated in the network and the shared cell remains unoccupied. It hits the optimal value for beacon probability that is around 0.1 for 1 and 2 round-trip bootstrap protocol. The performance degrades after the optimal peak as there is increasing load on the slotted Aloha cell and contention appears. Because probability of success corresponds to the normalized throughput, we can see that the higher load of the bootstrapping protocol e ectively reduces the network throughput during the join process.

The reduced throughput with increasing bootstrapping load is the consequence of a higher number of collisions, which can be seen in Fig. 1 b. Note that, for the optimal value of beacon probability (0.1), the pass from a single round-trip bootstrap protocol to two round-trips doubles the collisions. As expected, probability of collision increases with beacon probability, as the load on the slotted Aloha cell increases.

The duration of the join process represents the time until the last mote in the network has joined, i.e. has performed all exchanges of the join protocol. It is an important metric as it tells us from the practical standpoint how much slotted Aloha contention a ects the network set up time. We consider the worst case where all motes are switched on at the same time, the root being switched on last. The duration of the join process takes into account the initial delay while the motes are unsynchronized and are constantly receiving, waiting for EBs. Fig. 2 a shows the results for a single round-trip protocol. For smaller values of p EB , the time until first beacon decreases, and with it the duration of the join. For beacon probabilities larger than p EB = 0.1, the dominant component is the time it takes for the mote to join the network after it has received the beacon. As for larger beacon probabilities, the load on the slotted Aloha cell is larger, so is the probability of collision (see Fig. 1 b) which prolongs the time it takes for motes to perform the exchanges of the join protocol. Fig. 2 b shows the duration as a function of the number of motes in the fully-meshed network. We can see that the join duration "explodes" after a given number of motes in the network is reached which e ectively prevents the construction of larger networks. Therefore, in order for large networks to form within a reasonable amount of time, it is necessary to reduce the beacon probability and so increase "room" for the p join component in Eq. [START_REF] Duquennoy | Orchestra: Robust Mesh Networks Through Autonomously Scheduled TSCH[END_REF].

We proceed by estimating the average charge consumed per mote in Fig. 3 for the LTC5800 chip from Linear Technology based on the values reported in its datasheet 2 . We use this particular chip as it is best-in-class for power consumption, as is commercially available. We can see that the trend follows Fig. 2 a, although the optimal value is shifted to the right. This means that the optimal value of p EB in terms of the overall join duration is not the same when it comes to energy consumption. The reason is that motes spend more energy while initially un-synchronized and constantly listening for beacons. Therefore, the energy consumption benefits higher p EB , as the time until first beacon is shorter (see Eq. ( 6)). To put the numbers in Fig. 3 into perspective, consider that an alkaline AA battery typically carries 7920 C (2200 mAh), so that the charge consumed during the join process for p EB = 0.1 represents around 0.001% of the total charge. For this SoC, the average current consumption during the join is around 500 A, which represents a factor of 5 to 50 increase in comparison to the typical consumption during regular network operation (10-100 A average typical). Di erent boards have, however, di erent consumption. Based on the measured values presented in Vilajosana et al. [START_REF] Vilajosana | A Realistic Energy Consumption Model for TSCH Networks[END_REF], in Table 1 we compare the total charge consumed during the join process for p EB = 0.1 and p DIO = 1_3 for LTC5800 SoC, OpenMote-STM32F board and GINA. Finally, in Fig. 4 we compare in terms of collision probability the Bayesian approach with periodic beaconing, current state-of-practice in open-source implementations of TSCH. As expected, the periodic approach results in exponential increase in collision probability with increasing number of motes in the network. Depending on the EB and DIO periods used in the network, the performance lines cross for approximately 13, 19 and 25 motes in the fully-meshed network. The advantage of Bayesian broadcast can clearly be seen as the network density increases.

CONCLUSION

This letter presents an adaptation of the Bayesian broadcast algorithm to optimize the network formation process in 6TiSCH networks. Through extensive simulation, we parametrize the network and stabilize the slotted Aloha cell in the standards-compliant minimal profile defined by the IETF 6TiSCH working group. For networks with up to 40 motes in a radio neighborhood, we find that setting p DIO to one third and p EB to 0.1 gives good results in terms of network formation time. The load of the bootstrapping protocol a ects the maximal number of motes that can be in a radio neighborhood. We found that with a single round-trip bootstrap protocol, we can build networks that have up to 45 motes in a radio neighborhood. With 2 and 3 round-trip protocols, this number decreases to 35 and 30, respectively.

FIGURE 3

Charge consumed during the network formation assuming a LTC5800 System-on-Chip is used. The value of p EB that minimizes energy consumption is slightly higher compared to Fig. 2 a due to the initial unsynchronized period where motes constantly listen for EBs.

FIGURE 1

 1 FIGURE 1 a) Probability of success for a 40-mote fully-meshed network and p DIO = 1_3. The increased bootstrapping load reduces the throughput during network formation process due to the increase in collisions. b) Probability of collision for a 40-mote fully-meshed network and p DIO = 1_3. For optimal p EB = 0.1, collisions double with increasing bootstrapping load.

FIGURE 2

 2 FIGURE 2 a) Join duration for a single round trip bootstrap protocol and p DIO = 1_3. For smaller values of p EB , the dominant component of the duration is the time the mote spends unsynchronized waiting for EBs. For larger values (and increased tra c load) bootstrap retransmissions prevail. b) Join duration for beacon probability p EB = 0.1 and p DIO = 1_3. For a given join process duration, the number of motes in the network decreases with increasing tra c load.

FIGURE 4

 4 FIGURE 4Comparison of Bayesian and periodic broadcast techniques.

TABLE 1

 1 Charge consumed during join in a 40-mote network with di erent hardware.

	Board	total charge [mC]
	LTC5800	109.8
	GINA	380.9
	OpenMote-STM32F	905.6

https://bitbucket.org/6tisch/simulator

www.linear.com/docs/41870

Funding Information

This research was supported by the European Commission through the H2020 ARMOUR and H2020 F-Interop projects, and by the Spanish Ministry of Economy and the FEDER regional development fund under SINERGIA project (TEC2015-71303-R).


C Bormann

Network Working Group

When employing adaptation layer fragmentation in 6LoWPAN, it may be beneficial for a forwarder not to have to reassemble each packet in its entirety before forwarding it.

This has been always possible with the original fragmentation design of RFC 4944. Apart from a brief mention of the way to do this in Section 2.5.2 of the 6LoWPAN book, this has not been extensively described in the literature. The present document attempts to fill that gap.

One of the problems that need to be solved to enable sending IPv6 packets over low-power radios is that some of these (including IEEE 802.15.4) do not support frames that are large enough to hold IPv6 packets of the minimum MTU (Maximum Transmission Unit) defined for IPv6, 1280 bytes. This necessitates providing a fragmentation or segmentation scheme in the IP adaptation layer for the radio.

When employing adaptation layer fragmentation on constrained-node networks [START_REF] Bormann | Terminology for Constrained-Node Networks[END_REF], it may be beneficial for a forwarder not to have to reassemble each packet in its entirety before forwarding it.

This has been always possible with the original fragmentation design of RFC 4944. Apart from a brief mention of the way to do this in Section 2.5.2 of the 6LoWPAN book [BOOK], this has not been extensively described in the literature. The present document attempts to fill that gap.

[I-D.watteyne-6lo-minimal-fragment] provides additional context and discussion about handling fragment forwarding in the 6Lo standards suite.

Bormann & Watteyne Expires January 3, 2019

[Page 2] Internet-Draft
Virtual reassembly buffers in 6LoWPAN July 2018

Reassembly buffers

An adaptation layer implementation for 6LoWPAN needs to perform reassembly of every fragmented packet received in order to be able to forward the packet (re-fragmenting it in the process).

A reassembly buffer for 6LoWPAN contains: o datagram_size, o datagram_tag and L2 sender and receiver addresses (to which the datagram_tag is local), o actual packet data from the fragments received so far, in a form that makes it possible to detect when the whole packet has been received and can be processed or forwarded, o a timer that allows discarding the partial packet after a timeout.

This requires a reassembly buffer for each fragmented packet the reception of which is in progress. Since the forwarder may be receiving fragments for multiple packets concurrently (e.g., from different senders), this means that multiple reassembly buffers are needed, easily dominating the memory requirements in a 6LoWPAN implementation. Worse, as this space may still be limited, any lack of reassembly buffers may lead to an increased loss rate for fragmented packets (which already have to cope with a higher compound loss rate).

Virtual reassembly

To reduce the memory requirement for reassembly buffers, the implementation may opt to not keep the actual packet data in the reassembly buffer. Instead, it may attempt to send out the data for a fragment in the form of a forwarded fragment, as soon as all necessary information for that is available. Obviously, all fragments need to be sent with the same outgoing address (otherwise a full reassembly implementation would discard the fragments) and the same datagram_tag.

To this end, the reassembly buffer now also stores, as soon as enough of the packet is available to make a forwarding decision (i.e., as soon as the first fragment has been received):

o L2 destination address used for forwarding, o outgoing datagram_tag chosen for this packet.

Bormann & Watteyne Expires January 3, 2019 [Page 3]

Internet-Draft

Virtual reassembly buffers in 6LoWPAN

July 2018

A simple implementation may do away with any attempt to keep packet data in the virtual reassembly buffer. It then has to discard all non-first fragments for which a reassembly buffer is not already available (penalizing reordering, which however may be rare).

Note that the decision to do local processing of a packet needs to be taken with the first fragment -such packets of course do need to be fully reassembled (unless transport and application also can cope with fragments, which they rarely can in the presence of security).

Header compression

[RFC6282] defines the header compression format for 6LoWPAN. One important impact of header compression is that the header is no longer of a fixed length. In particular, changes made by a forwarder may gain or lose the ability to use a more highly compressed variant, changing the length of the header in the packet. If the change increases the size, the maximum frame size may be exceeded, leading to the need to re-fragment in the forwarder. This is less of a problem with full reassembly, but with virtual reassembly can lead to the need for sending an additional frame for each packet.

The well-known approach to minimize the probability of this need is for the original sender to put all slack in the frame sizes into the _first_ packet, making this the smallest fragment and not the last one as would be done in a naive implementation. (This also has other consequences related to delivery probability, which are not discussed here.) This makes sure an additional fragment only needs to be sent if the header expansion during forwarding would have created an additional fragment with full reassembly as well.

IANA Considerations

This document makes no requests of IANA.

Table of Contents 1 .

 of1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Reassembly buffers . . . . . . . . . . . . . . . . . . . . . 3 3. Virtual reassembly . . . . . . . . . . . . . . . . . . . . . 3 4. Header compression . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. Security considerations . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 7.2. Informative References . . . . . . . . . . . . . . . . . 5 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .

5 1. Introduction 6LoWPAN [RFC4944] is the seminal standard for the transmission of IPv6 packets over IEEE 802.15.4 networks and has served as a blueprint for a number of related standards addressing low-power radios and other IoT connectivity solutions (the "6Lo suite").

  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <https://www.rfc-editor.org/info/rfc4944>.

	6. Security considerations
	TBD
	7. References
	7.1. Normative References
	[RFC4944] Bormann & Watteyne	Expires January 3, 2019	[Page 4]

Acknowledgements

Many people have mentioned that it would be good to have a description of virtual reassembly in 6LoWPAN. Finally, Thomas Watteyne assembled a design team that intends to work on 6Lo fragmentation. Writing up the present document has been motivated by that work.

Internet-Drafts. The list of current Internet-Drafts is at https://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

Authors' Addresses