# Bell-X, An Opportunistic Time Synchronization Mechanism for Scheduled Wireless Sensor Networks
## 2 Timing for TSCH and RPL
### RPL Trickle Timer  
It is necessary to build a network topology once the devices achieve synchronization with the TSCH slotframe of their neighbours, so that the nodes know the best routes to carry out multi-hop communications. Wireless Sensor Networks consist of a set of constrained devices, limited by either computing power, memory, or energy consumption. The RPL protocol calls these types of networks Low-power and Lossy Networks (LLN). RPL is specially designed to be able to establish routing rules in networks with low-resource devices. For this reason, the RPL protocol is widely used as a de facto standard for establishing routes and maintaining the topology in meshed wireless networks. Using a set of objective functions, the RPL protocol allows for the nodes to dynamically and autonomously update their routes, estimating the quality of the links through different metrics.  
For the formation of the RPL DODAG (Destination-Oriented Directed Acyclic Graph) tree, different ICMPv6 control messages are used. DODAG Information Object (DIO) messages are sent by the nodes of the RPL network to keep the routes updated and allow for new nodes to join the network. DODAG Information Solicitation (DIS) messages are sent to request that nodes that are already in the network send a DIO message with the RPL information that is needed to join the topology. Finally, Destination Advertisement Object (DAO) messages allow for the ascending routes to the coordinator node of the RPL tree to be created.  
RPL protocol uses a Trickle-based timer, described in RFC6206 [8], to carry out the dissemination of DIO messages in such a way that control traffic is significantly reduced when the RPL topology is stable. This algorithm allows for the DIO Trickle timer value to be modified as long as the information received does not indicate that the topology has undergone any changes. The DIO Trickle timer will be reset when an inconsistency in the topology is detected or when a multicast DIS is received. In Figure 3, the evolution of the RPL Trickle Timer is shown. Each time the timer expires, the algorithm doubles its value until it reaches its maximum value. In the case shown in the graph, the Trickle Timer reaches its maximum value in a few minutes.  
In the real implementations of a communication stack, such as the one carried out by the Contiki OS [9], the TSCH medium access mechanism uses the RPL Trickle timer to modify the EB transmission period. This modification allows for advertising traffic to be reduced, as is the case with control DIO messages. However, this change is controlled by RPL, where the DIO messages used to keep the routes updated do not have the same criticality as the messages to keep the network synchronized. Figure 4 shows a representation of the beacon transmission mechanism, modified with the RPL trickle timer.  
\begin{table}
\begin{tabular}{c c c c c} \hline \hline  & **Request RX by Node1** & **Requests TX** & **Time Elapsed before Synchronizing** & **Success Rate** \\ \hline Node2 & 15 & 1227 & 1:42:17.147 & 1.2\% \\ Node3 & 10 & 1223 & 1:42:17.347 & 0.8\% \\ Node4 & 18 & 1030 & 1:26:16.197 & 1.7\% \\ Node5 & 22 & 1377 & 1:55:20.832 & 1.6\% \\ Node6 & 13 & 873 & 1:13:14.367 & 1.5\% \\ Total & 78 & 5730 & & 1.4\% \\ \hline \hline \end{tabular}
\end{table}
Table 1: Success rate for beacon request simulations.