# TSCH and RPL Joining Time Model for Industrial Wireless Sensor Networks
## 5 RPL Analytical Model  
In the case of RPL, the nodes must already be synchronized by TSCH, and they need to obtain the information from the RPL tree. To do this, they must receive a DIO message from one of the nodes in the network, within their coverage area, and then send a DAO to the root. This DAO message will influence the connection time with the RPL tree, since the messages must be transmitted several hops away from the root. RPL and TSCH schedules must not overlap, so we will be able to avoid the collisions that could occur between these two sources of traffic. This consideration is achieved thanks to the use of Orchestra when obtaining the TSCH schedule. This allows the creation of two schedules for each traffic plane, while avoiding collisions between them. In addition, for the RPL traffic plane, the system starts from a scheduling based on minimal 6 TSCH, in which only one slot shared by all the nodes that are part of the network is enabled, so that access to the radio resource will be resolved through contention. Table 2 shows the different parameters that influence the process of joining the RPL topology. These parameters have been taken into account when defining the analytical model, which characterizes the time it takes a node to obtain this configuration. After the synchronization phase, the nodes that are already part of the RPL tree send DIO messages based on the current value of their Trickle Timer. From this, the probability of a node transmitting a DIO message is established. \[P_{dio}=\frac{SF_{RPL}}{T_{trickle}} \tag{4}\]  
This probability will be determined by the size of the slotframe, \(SF_{RPL}\), which will only have one shared active slot, and also by the current value of the Trickle Timer, \(T_{trickle}\), which will be different depending on when the Trickle Timer is found, or if it is restarted, since the model seeks to characterize each of the individual states of the Trickle Timer, represented by the steps in Figure 2. To avoid collisions within this shared slot, it is possible to establish the probability of this happening, which will be:  
\[P_{dio}\cdot(1-P_{dio})^{N-1} \tag{5}\]where \(N-1\) is the number of nodes that are not sending DIO messages. As we can receive messages from all the nodes, this probability will be multiplied by \(N\). \[N\cdot P_{dio}\cdot(1-P_{dio})^{N-1} \tag{6}\]  
By analyzing the probability of transmission success (\(PDR\)), it is possible to determine the number of messages, or number of slotframes to be received correctly. With a probability determined by the \(PDR\), the DIO message will be received in the worst case at a time determined by the \(SF_{RPL}\) variable, and in the best case, it will be received in the next timeslot. If its average value is taken, there will be a time equal to \(SF_{RPL}/2\). With a probability \((1-PDR)\), the DIO message will not be transmitted in the first slotframe, but in the following slotframes, there will be a maximum of four retries for each message. \[t_{pdr}=\sum_{i=0}^{4}(SF_{RPL}\cdot i+\frac{SF_{RPL}}{2})\cdot PDR\cdot(1- PDR)^{i} \tag{7}\]  
The transmission time of a DIO correctly sent will be as follows, where \(T_{trickle}/2N\) is the average time to receive a DIO message with \(N\) neighboring nodes, to which is added the time required to send a DIO, which depends on the \(PDR\) and on the possible collision with other DIO messages:  
\[T_{DIO}=\frac{T_{trickle}}{2\cdot N}+\frac{t_{pdr}}{N\cdot(1-P_{dio})^{N-1}} \tag{8}\]  
During the simulations carried out to validate the proposed RPL model, only the reception time of a DIO message was used, since it reflects the moment when the node itself obtains the routing information and becomes fully connected. To complete the process of creating routing tables for downstream traffic, it is necessary to send back a DAO message to the root node once the new node obtains the RPL information from the DIO message.