# TSCH and RPL Joining Time Model for Industrial Wireless Sensor Networks
## 6 Simulations and Results
In addition, to prevent these schedules from overlapping, a slotframe size (\(SF_{SIZE}\)) has been configured equal to 101 slots in both cases. The size of 101 slots allows the same slot to repeat approximately every second, which allows for enough slots to transmit signaling messages every 4 s.  
Two types of simulations were performed, one to characterize the evolution of the synchronization process in TSCH, and another to characterize the connection time of the new node to the RPL tree. In this way, it is possible to isolate the behavior of each of the protocols, so that changes in the configuration of the other protocol have as little influence as possible. In the case of the simulations for TSCH, both the number of neighbors already synchronized and the period of beacon transmission were modified, allowing the behavior with different configurations to be observed. On the RPL side, its configuration was left as the default, leaving the Trickle Timer to modify the DIO transmission period. The simulation ends at the moment the new node receives the EB message in order to synchronize with \begin{table}
\begin{tabular}{l l} \hline \hline
**Parameters** & **Values** \\ \hline TSCH Scan Duration & 256 s \\ TSCH Timeslot Duration & 10 ms \\ Orchestra Slotframe size for EBs & 101 slots \\ Orchestra Slotframe size for RPL & 101 slots \\ TSCH Number of Channels & 4 channels \\ TSCH Number of Scan Channels & 4 channels \\ RPL. Trickle Timer Interval Min & 4 s \\ RPL. Trickle Timer Interval Doublings & From 1 to 4 \\ RPL. Trickle Timer Redundancy Constant & 10 \\ RPL. DIS Interval & 60 s \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Protocol stack configuration. \begin{table}
\begin{tabular}{l l} \hline \hline
**Parameters** & **Values** \\ \hline Number of neighbors for the new node & [1; 2; 5; 7; 10; 15] \\ Seeds per simulation & 30 \\ Time until stationary network & 15-20 min \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Simulation configuration. the WSN. Table 5 shows a summary of all the variations of each parameter to be modified in the TSCH simulations. The combination of all these configuration parameter variations gives a total of 24 simulated configuration variations, and 30 iterations were performed for each of them. Figure 4 shows the results obtained for the TSCH simulations. The equation obtained from the TSCH analytical model is shown as a curve, superimposing the results of the average, using an asterisk, and standard deviation, with a plus sign, of the results of 30 simulations. As shown in the graphs, the simulations performed yielded results very close to the behavior of the proposed analytical model. From these results it is worth noting the behavior of the standard deviation of the results, whose dispersion is more accentuated in those simulations where the TSCH signaling traffic is quite dispersed. This occurs both in simulations where there are few nodes transmitting beacons and in those where the sampling period is longer. The most extreme case occurs when there is only one node and the transmission period is 32 s.  
For the RPL simulations, the number of nodes was modified, as in the TSCH simulations, along with the transmission period of the DIO messages. In this case, instead of using the Trickle Timer for RPL, a fixed transmission period was used for multi-cast DIO messages once the network has stabilized, so that all nodes have a standardized DIO period value in each simulation variant. This simplification has been made due to the fact that the Trickle Timer is not synchronized between the nodes. In this way, a normalized value of the Trickle Timer is maintained in each simulation for all nodes, which allows analysis of each of the phases of the Trickle Timer period. In the case of the TSCH EB message transmission period, a fixed transmission period of 4 s was used to allow for rapid synchronization of the nodes. Table 5 also shows a summary of all the variations of each parameter to be