# Slotted ALOHA on LoRaWAN-Design, Analysis, and Deployment
## 5 Real Time Clock Synchronization over LoRaWAN Stack
Since the packet in response to the uplink transmission takes a variable delay before reaching the node, the offset calculation is needed to update the received timestamp that could be no longer current. The offset calculation procedure consists in measurement between the response packet and the initial instant when the transmission by the end node ends, this instant coincides also with the arrival of the packet to the gateway, which is the moment where the gateway \"marks\" the message with the timestamp included in the RX1. The electromagnetic propagation speed is negligible factor respect to the times involved. A total of 30 synchronization tests were carried out with two, three and four nodes: the results are shown in Table 1, where the time difference in ms is expressed taking as reference the end node N0. The purpose of this evaluation is to verify the synchronization performance with many devices, indeed they are programmed to send a timestamp request every 15 s, which is comparable with 320 end nodes with a request-rate of 80 min each. From Table 1 it is possible to notice how the increase of devices that request the synchronization from the gateway significantly reduces the synchronization accuracy; this result is probably due to the management of processes at the operating system level within the gateway. Since the management of the timestamps is done by the software working on the Linux operating system, the priority of the processes on the gateway is not well known, and consequently, the final accuracy of the timestamp associated with the received packet cannot be under one millisecond. The results achieved shows that the average error between all the devices is 5.37 ms, with a maximum value of 37.08 ms, such uncertainty must be considered in S-ALOHA deployment to avoid transmission overlaps between adjacent slots. To decrease the timestamp error some LoRaWAN gateways embed a GPS module, used by the physical layer to associate exactly the time reference at the end of the packet frame, but, since this feature is not mandatory from the protocol rules, we tested our Slotted LoRaWAN without this support. Figure 8a presents the plots of synchronization deviation between end nodes, from two to four, where are indicated the median, and the bottom and top edges of the box, respectively the 25 th and 75 th percentiles. Figure 8a shows that, as the number of nodes increases, the mean and the width of the interquartile gap (blue box) increases, which is a dispersion index provides a measure of how far the points move away from a central value, such as standard deviation. As a result of the increase in the number of devices, the number of \"off-average\" synchronizations indicated in the graph with red crosses also increases. Figure 8b represents the maximum synchronization uncertainty between nodes since last clock alignment and provides fundamental information to calculate the \(T_{\rm b}\) period as well as the RTC \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Number of** & **Min. Synch. Error** & **Max. Synch. Error** & **Avg. Synch. Error** & **Delta Avg. Error** \\
**End Nodes** & **[ms]** & **[ms]** & **[ms]** & **[\%]** \\ \hline
2 & 0.072 & 8.296 & 3.310 & - \\
3 & 0.120 & 33.260 & 4.705 & +42 \\
4 & 0.243 & 37.080 & 5.370 & +62 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Results of the measurements carried out to verify the RTC synchronization between multiples end node connected to a single Gateway. refresh rate, which are dependent from application and transmission period. For example, in the worst case, when the end node integrates an 80 ppm crystal, an error of 200 ms is generated every 40 min.