# TSCH and RPL Joining Time Model for Industrial Wireless Sensor Networks
## 6 Simulations and Results  
To carry out the validation of the proposed analytical model, both for the TSCH model and for the RPL model, different simulations were carried out. In these simulations the number of neighbors that already belong to the network and the transmission period of the signaling messages (beacons in the case of TSCH and the DIO messages in the case of the RPL protocol), were modified. The configuration of the protocol stack, as well as the different variations of each of the simulated configurations, were based on the Contiki 3.0 operating system. In this operating system it is possible to configure a complete communications stack, based on IEEE 802.15.4, with different mechanisms for accessing the medium, including TSCH, and with protocols such as RPL for the routing and 6 LoWPAN as an IPv6 adaptation layer. This is necessary to encapsulate IP information in IEEE 802.15.4 frames. It also has different applications that are useful in the operation of TSCH-based WSNs, such as the autonomous scheduling mechanism Orchestra, which is used in these simulations. \begin{table}
\begin{tabular}{l l} \hline
**Symbol** & **Description** \\ \hline \(P\) & Probability of a node transmitting a DIO message. \\ \(T_{trickle}\), & represents the period of transmission of DIO control messages. \\ \(SF_{RPL}\), & Represent the size of the slotframe dedicated to the RPL traffic plane, counted as the number of timeslots that are repeated periodically. \\ \(N\) & represents the number of neighbors sending RPL control messages within the coverage area of the node that wants to join the network. \\ \(t_{pdr}\) & represents the time required to send a DIO message based on the probability of the PDR parameter. \\ \(T_{DIO}\) & represents the time needed to receive a DIO message after the node is synchronized to the TSCH network. \\ \(PDR\) & The Packet Delivery Rate parameter represents the success rate of message reception. \\ \hline \end{tabular}
\end{table} 
Table 2: RPL analytical model variables. The development environment of Contiki has a simulator called Cooja, which allows simulation of the behavior of a real sensor network based on the applications developed in Contiki. Table 3 summarizes the main physical configuration parameters, which will be common to all the simulations performed in this study. As indicated in the table, each of the configurations will be repeated a total of 30 times to have a sufficient statistical mass with which to assess the validity of the analytical model. As can be seen in Figure 3, the nodes that will be part of the set of devices already synchronized are located in line, always within the coverage area of the new node that has been added--in this case, node 6. This deployment has been carried out because, although the physical network topology does not matter, it is necessary that all the nodes that are already connected to the network are within the coverage area of the new node in order to send signaling traffic from both TSCH and RPL. The procedure to be followed in each simulation will start with the deployment of a network with a certain number of nodes, depending on the configuration to be characterized. Once all the nodes are connected, a time will be left for the network to stabilize and no changes in the topology will occur. This time will be between 15 and 20 min from when the network is started. Once this time has passed, a new node is added to the topology, which will be the node studied. The two events that determine the evolution of the simulation are: the instant in which the new node synchronizes with the network when it receives a Beacon from TSCH and the instant in which the new node receives a DIO message to obtain the topology information. Table 4 shows the basic configuration of the protocol stack used in all the simulations. In the case of scheduling, an Orchestra-based scheduling was chosen, since it allows us to separate the scheduling into different traffic planes, giving priority to those messages that are more important.