# A Joining Procedure and Synchronization for TSCH-RPL Wireless Sensor Networks
## 6 Results
### Probability of Connection Success
This time is chosen after verifying that it is the maximum needed to connect all of the neighbours within the coverage area of a node sending EBs. The probability of a node connecting after 2 min is negligible. Once these two minutes have passed, the beacon transmission period is changed to 16 s.  
This stimulates the synchronization process over a short period, and then relaxes because the nodes in the next level, which are recently connected, will start sending beacons on their own with the 4-s interval. Hence, it takes advantage of the propagation behaviour of the synchronization, speeding up but keeping the energy and congestion sustainable. In addition, this assumption results in 12 min for all six levels in the selected topology (Figure 7) to connect correctly, which is then successfully covered by the 15 min simulation time that was chosen. Figure 9: The probability of synchronization and connection success for different numbers of scan channels. As can be seen, increasing the number of beacons considerably improves the synchronization and connection mechanism's success, achieving configurations that connect successfully virtually 100% of the time. In the first configuration, Figure 10a, the beacon transmission period is modified following the modifications of the Trickle Timer that is used by RPL and recommended in the Contiki OS implementation, which means that within a few seconds of starting the network, this period has increased considerably. The second configuration, Figure 10b, uses the fixed beacon transmission period that was initially recommended in the standard. This transmission period has been set at 16 s, obtaining results that are similar to those of the Trickle Timer configuration. The last two configurations, in Figure 10c,d, show how connection probabilities close to 100% are achieved for most nodes in the network. The difference lies in the traffic generated by each configuration that directly affects the energy consumption of the nodes. Figure 11 shows the generated traffic for each of the configurations that are depicted in Figure 10. On the one hand, the first two configurations show a rather reduced amount of signalling traffic with respect to the last two configurations. This has been proven to greatly hinder the probability that nodes connect successfully in a short time. On the other hand, it can be seen how the configuration with a variable beacon transmission period obtains similar connection success results to the fixed transmission period every 4 s, but with a much smaller amount of traffic. Figure 11: The number of packets for different EB period configurations. Figure 10: The probability of synchronization and connection success for different EB period configurations. It is important to highlight the influence of the DIS messages that are used by the RPL protocol to request information on the topology. Note that the two configurations that show better results hardly need these control messages to build the topology. This is because these messages were designed to request information about the RPL tree; however, by including the TSCH mechanism, all these messages are discarded as long as there is no synchronization with their time source. Different simulations have been carried out that increase the rate of DIS message transmission (as described in Table 2: Extra Test), and it has been observed that they have a negligible influence on the synchronization mechanism. Another key result is the maximum connection time that is needed by nodes for the different configurations. Figure 12 shows the connection time for each node and configuration. In the cases where some nodes are not able to connect, a maximum time value of 8 min has been adopted to avoid deviations that are too far from standard values. Consequently, the first two configurations obtain much higher connection times, mainly because some of the nodes never connect within the first 8 min of simulation.