*4.2. Synchronization Process*

In this section, we investigate and discuss the periodic synchronization process steps in detail. We conduct the synchronization process frequently, with a time period of *Psyn* to conserve the time offset of all nodes within a suitable range (depending on the application). Once the scheduling process selects all reference nodes and their time slots, the synchronization process begins with the sink as the first reference node. The sink node's time is considered the reference time to all surrounding nodes. The synchronization process consists of three simple steps that are repeated in each hierarchical level over a multi-hop network. Since each reference node has its own time slot, *Schslot*, it should perform the synchronization process within the scheduled time to avoid collisions. The synchronization process of LPSRS occurs in a single broadcast domain. *R* is the reference node, *SIR* is the specified reference node, and *K* represents the other neighbor's nodes of *R*. Algorithm 3 and Figure 4 show how to estimate the total offset for frequent synchronization. In the first step, at time *T*1,*R*, the *R* = sink node broadcasts synchronization message number 1 (*Sync*1) to all its surrounding nodes. *Sync*1 includes the specified reference node, *SIR*, that has been randomly pre-selected (from the reference nodes neighbor list) by *SIR* to send back a response (line 1 to 6).

**Figure 4.** The synchronization process of LPSRS in a single broadcast domain. *R* is the reference node, *SIR* is the specified reference node, and *K* represents the other neighbor's nodes of *R*.

Every node *<sup>k</sup>* <sup>∈</sup> <sup>U</sup>(*R*) saves the time stamp, *<sup>T</sup>*2,*<sup>k</sup>* for the arrival time of *Sync*1 (line 9). Here, U(*R*) denotes a group of nearby nodes inside the wireless range of *R*. Next, *SIR* sends synchronization massage 2 (*Sync*2) back to *R*. *Sync*2 contains the arrival time of *Sync*1, *T*2,*SIR*, as well as the time stamp for the transmit time, *T*3,*R*, of *Sync*2 (line 10 to 13). Once *R* gathers all time stamps *T*1,*R*, *T*2,*SIR*, *T*3,*SIR*, and *T*4,*<sup>R</sup>* (the time right after receiving *Sync*3), *R* estimates the offset by

$$O\_{R,SIR} = \frac{\left(T\_{2,SIR} + T\_{3,SIR}\right) - \left(T\_{4,R} + T\_{1,R}\right)}{2} \tag{2}$$

Here, *OR*,*SIR* is the offset between *R* and *SIR*. *R* then broadcasts a synchronization message number (*Sync*3) to all its neighbor nodes, *<sup>k</sup>* <sup>∈</sup> <sup>U</sup>(*R*), which contains time *<sup>T</sup>*2,*SIR* and *Or*,*SIR* (line 18 to 23). Each node, *<sup>k</sup>*, in <sup>U</sup>(*R*) receives *Sync*3 and checks the sequence number, *SeqN*. It only reacts if the current *SeqN* in the message is higher than the previous one. Then, (line 26) it estimates the offset difference between *SIR* and *k*, *OSIR*,*k*, according to *SIR* by

$$O\_{SIR,k} = T\_{2,SIR} - T\_{2,k} \tag{3}$$

Then, (line 27) every node, *k*, determines its total offset, *OR*,*k*, as

$$O\_{R,k} = O\_{R,SIR} + O\_{SIR,k} \tag{4}$$

Here, *OR*,*<sup>k</sup>* is the offset difference between *R* and *k*. Finally, each node, *k*, compensates its local time by subtracting the total offset, *OR*,*k*, from its old local time, *Told <sup>k</sup>* , using

$$T\_k^{new} = T\_k^{old} - O\_{R,k} \tag{5}$$

where *Told <sup>k</sup>* denotes the old local time, and *<sup>T</sup>new <sup>k</sup>* is the new local time of node *k* (line 28). After all, the reference nodes within the wireless range of the sink node become synchronized and each reference node initiates the synchronization timer (ST) to repeat the same procedure until no further node can be synchronized (line 30 to 34). Each reference uses its time slot, *Schslot*, to avoid message collision.

For more clarification, we show an example of the synchronization method considering the depicted network in Figure 4. In the beginning, all nodes use Algorithm 3 for the synchronization process, and *S* fills the synchronization message (Type: *Sync*1) as follows.


Next, it broadcasts *Sync*1 to all its neighbor nodes at the time *T*1,S. Since it has a list of neighbor reference nodes (*B* and *C*), it selects node *B* to be the responder (lines 1~7).

All nodes (*B*, *A*, *D*, and *C*) receive *Sync*1 and keep the arrival time of *Sync*1 (*T*2,*B*, *T*2,*A*, *T*2,*D*, and *T*2,*C*) (line 9). Next, each reference node (*B* and *C*) starts its own ST (lines 14~17). Node *B* sends back *Sync*2 to node *S*. *Sync*2 consists of the arrival time of *Sync*1, *T*2,*B*, as well as the time stamp for the transmit time, *T*3,*B*, of *Sync*2 (lines 10~13). Node B sets the synchronization message as follows.


As soon as node *S* receives the *Sync*2, it records the arrival time of *Sync*2, *T*4,s. Then, it calculates the offset using (2) and broadcasts *Sync*3 to all its neighbor nodes (lines 19–23). In addition, S fills the synchronization message (Type: *Sync*3) as follows.


Nodes (*B*, *A*, *D*, and *C*) receive *Sync*3 and check *SeqN*. They find the *SeqN* = 1 is higher than the previous one (default value = 0). Then, they estimate their offset and compensate their local time using (3), (4), and (5) (lines 25 to 29).

Nodes *B*, *C*, *I*, and *F* repeat the same process after their ST expires (lines 31 to 34). The synchronization process requires only three broadcast messages per reference node, regardless of the network size or density. Additionally, the scheduling process reduces the set of reference nodes. Thus, LPSRS can significantly reduce the number of message exchanges and is, therefore, well suited for low-power applications.

**Algorithm 3**: LPSRS pseudo-code for the synchronization process.

```
1. if (NodeID = sink node) Then
2. R ← sink node
3. SIR ← select rondlmly f romRef Neighbors list
4. SeqN ← 1
5. T1,R←ReadCurrent Time
6. send Sync1
    < 0xFFFF, R, SIR, Sync1, SeqN, −1, −1, −1, 0 >
7. end if
8.  Upon receiving Sync1
9. T2,k ← Read Current Time // k represents all neighbor nodes of R
10. if (NodeID == SIR) Then
11. T2,SIR ← T2,k
    T3,SIR ← Read Current Time
12. send Sync2
    < R, NodeID, −1, Sync2, SeqN, T2,SIR, T3,SIR, −1, 0 >
13. end if
14. if (NodeID is in Ref Node) Then
15. WaitingTime ← (mySchSlot − SchSlotSrcID)
16. Setup Synchronization timer ST(WaitingTime)
17. end if
18.  Upon receiving Sync2
19. if (NodeID == R) Then
20. T4,R ← Read Current Time
21. OR,SIR ← ((T2,SIR + T3,SIR) − (T4,R − T1,R))/2
22. send Sync3< 0xFFFF, R, −1, Sync3, SeqN, −1, −1, T2,SIR,OR,SIR >
23. end if
24.  Upon receiving Sync3
25. if (Received SeqN > SeqN) Then
26. Ok,SIR ← T2,SIR − T2,k
27. OR,k ← OR,SIR + ONodeID,SIR
28. Tnew
        k ← Told
                k − OR,k
29. end if
30.  Upon ST expires
31. R ← NodeID
32. SIR ← select rondlmly f rom Ref Neighbors list
33. T1,R ← ReadCurrent Time
34. send Sync1
    < 0xFFFF, R, SIR, Sync1, SeqN, −1, −1, −1, 0 >
```
#### **5. Experimental and Simulation Results**

In this section, we present our achieved experimental results, followed by the simulation results. We have used the number of transmitted messages in each protocol during the synchronization process as the performance metric. Before discussing and explaining the experimental results, as described below, we show how the number of transmitted messages is the key performance indicator related to power consumption.

#### *5.1. Power Consumption Analysis*

In general, to analyze power consumption, we focus on the major power consumption caused by packet transmission and reception on sensor nodes. To save energy, wireless networks often cycle between sleep and active modes. As a result, power consumption is roughly proportional to the number of broadcasts and received packets, assuming a MAClayer protocol that reduces idle listening time. Besides, wireless networks are broadcast domains [34]. As a result, for each broadcast, there are many receptions. Assume we have a wireless network with *N* nodes that is equally distributed, with each node surrounded by *m* nodes. The total power consumption, *PT*, can be expressed by transmission power, *PTX*, and reception power, *PRX*, as defined by

$$P\_T = A(P\_{TX} + mP\_{RX})\left(\frac{L}{D}\right) \tag{6}$$

where *A* indicates the number of transmitted messages, *L* indicates the trace length in seconds, while *D* indicates the duration of the message. The *PRX* has different modes. For example, NXP's MCU with the RF transceiver chip KW01Z128 [35] has different modes. At the highest mode, the *PRX* is almost equal to *PTX*. On the other hand, at the lowest mode, *PRX* is around 0.2 of *PTX*. In this article, for sake of simplicity, we have chosen *PRX* ≈ *PTX*. Since *PRX*, is almost equal to *PTX* [35], we can, therefore, simplify (6) into

$$P\_T = A \frac{P\_{TX}L(m+1)}{D} \tag{7}$$

According to (7), power usage is dependent on the number of messages sent, since the number of transmitted messages has a big impact on power consumption. In addition, we analyze the required number of the transmitted messages, *M*, for each protocol [35].

In R-sync, each node transmits a message to help build the spanning tree. The number of sent messages in the network is three times greater than the number of referenced links at the start of the time synchronization procedure. Additionally, there are further required messages for pulling isolated nodes. Thus, the total number of transmitted messages of R-Sync is: *MR*-*Sync* = *N* + 3(*R* − 1) + *P*. Here *N* is the node number, *R* is the number of reference nodes, and *P* is the number of pulling messages [9]. We note that *MR*-*Sync* is directly proportional to the number of nodes and the number of selected reference nodes.

Meanwhile, HRTS constructs a multi-level hierarchy of the network. At every level, each node sends two messages and obtains a response from the selected reference node. Therefore, the total number of transmitted messages of HRTS is *MHRTS* = 2*N* + *R* [2]. *MHRTS* is directly proportional to the number of nodes [5].

Lastly, LPSRS requires *MLPSRS* = 3(*R* − 1) messages. However, LPSRS minimizes the number of reference nodes by using an efficient scheduling technique for the reference nodes. Besides, LPSRS is able to avoid collisions during its operations.

#### *5.2. Experimental Results*

The LPSRS protocol was built in C++ and implemented in an embedded CPU in the hardware sensors. We used the Arduino Nano RF (ANRF) as the hardware sensor. The ANRF utilizes an NRF24L01 RF transceiver and an ATmega328P CPU [36,37]. Moreover, it has a 2 kB memory and 32 KB Flash. The ANRF operated at a frequency of 2.4 GHz, and the bitrate was 50 kbps. We used 0 dBm as the transmitted power [38]. We created a testbed of 25 nodes, as shown in Figure 5, to build a wireless sensor network. For simplicity of the testing, with the help of the programming, we designed a wireless network of 3-way grid topology to test our protocol over a multi-hop network as depicted in Figure 6. In the 3-way grid topology, each node only receives incoming messages from nodes that have a common solid line. For example, in Figure 6, N12 only receives messages from N6, N7, N11, N13, N17, and N18. Therefore, we can evaluate LPSRS and other protocols under a realistic transmission contention and conditions of congestion.

**Figure 5.** The 25-node setup.

**Figure 6.** The 3-way grid network.

Table 1 shows the number of the transmitted message of LPSRS, R-sync, and HRTS for the network topology of Figure 6. It demonstrates that LPSRS, R-sync, and HRTS exchanged 42, 57, and 64 messages, respectively. LPSRS outperforms other technics (R-sync and HRTS). It can decrease the number of transmitted messages by around 26% and 35% compared to R-Sync and HRTS. Although the improvement in LPSRS looks moderate when compared to other protocols in the tiny test network shown in Figure 6, it develops fast as the network size increases. Due to the complexity of building large-scale actual hardware networks, we demonstrated this enhancement using simulations.

**Table 1.** Comparison of LPSRS, R-sync, and HRTS.


#### *5.3. Simulation Results*

To further test our proposed LPSRS protocol, we originally built a simulator that runs the LPSRS and HRTS algorithms. Meanwhile, the R-Sync simulation findings [9] have been adopted. In MATLAB, simulations were created employing wireless networks of varying sizes and ranges. We assumed the N sensor nodes were uniformly disrupted and scattered at random in a square area of 1000 m × 1000 m. Each node had a wireless communication range, denoted by *r*. We also presumed that all nodes were similar and self-contained. The sink node had two positions: (1) at the network's center and (2) at the network's corner. Due to the homogeneous distribution of the nodes, there was no significant change in the findings due to the position of the sink node. In this article, to prevent repetition, we only presented the findings if the sink node was placed in the network's center, as other locations yielded similar results. In addition, we tested with LPSRS in the simulation using a wide variety of 12 distinct scenario networks, ranging from sparse to congested. We could simulate several different sorts of sensor nodes with varying wireless ranges by varying the transmission range. Changing the number of nodes in the network, on the other hand, allowed us to show the behavior of our protocol from a sparse network (200 nodes) up to a dense network (450 nodes).

Through simulations, we measured the number of transmitted messages in each protocol during the synchronization process, which is the key performance indicator related to power consumption. As described in Section II, HRTS and R-Sync often incur a large number of collisions during the synchronization process, while LPSRS is guaranteed to have no collisions. For the sake of simplicity, we assumed that no collisions happen even in HRTS and R-Sync.

Figure 7 depicts the number of messages delivered by all three protocols (LPSRS, R-Sync, and HRTS) across a range of network different sizes from 200 to 450 nodes. For a large network with 450 nodes, it can be seen that R-Sync and HRTS generated 970 messages and 1071 messages, respectively. On the other hand, LPSRS generated around 500 messages. That is, LPSRS outperformed the other two protocols, as it decreased the number of transmitted messages to around 49% and 53% compared to R-Sync and HRTS, respectively.

**Figure 7.** Required number of messages (*r* = 85 m, N = 240: 450).

Figure 8 shows the number of transmitted messages under different communication ranges from 85 m to 160 m. It can be found that LPSRS substantially outperformed the other methods. For a network with a communication range of 85m, LPSRS decreased the number of transmitted messages to around 55% and 34% compared to R-Sync and HRTS, respectively. On the other hand, for a network with a long communication range of 160 m, LPSRS generates around 175 messages. LPSRS outperformed HRTS and R-Sync by a factor of around 3 and 1.4, respectively.

**Figure 8.** Required number of messages (*r* = 85 m: 160 m, N = 240).

Based on the results presented above, it is reasonable to conclude that LPSRS consumes less energy than the other techniques. LPSRS, on the other hand, does not compromise timing accuracy. The offset calculations described by HRTS [12] and DTSync [7] during the synchronization process were used, which is recognized to provide high timing accuracy. For more details, we compared DTSync and HRTS in our previous work with more protocols (see Table 11 [11]). Furthermore, LPSRS can manage high-density networks without losing its key features, making it a highly scalable and flexible protocol.

#### **6. Conclusions**

In this article, we suggested LPSRS as a time synchronization protocol for the IoT. It addressed the power consumption and collision issues in IoT networks. LPSRS significantly decreased the number of messages, resulting in significant power savings. We constructed LPSRS into a real wireless sensor network with different configurations and an extensive simulation with large-scale networks. According to the experimental results, LPSRS requires fewer messages than prior approaches such as R-Sync and HRTS. It can decrease the number of transmitted messages by around 26% and 35% compared to R-Sync, and this benefit, in turn, reduces LPSRS's energy use. In addition, we can consider LPSRS as a semi-centralized synchronization protocol, as some tasks are completed by the sink node and other tasks are completed locally by each node. Therefore, LPSRS is very convenient for those applications in which the network topology is recognized, e.g., smart metering.

**Author Contributions:** M.E., M.A.A.E.-G. and S.P. came up with the concept for this study; M.E., H.K. and S.P. developed the research technique; M.E., M.A.A.E.-G. and H.K. carried out the experiments and simulations; M.E., H.K. and S.P. evaluated the data and wrote the paper. All authors have read and agreed to the published version of the manuscript.

**Funding:** This research was supported in part by Korea University and in part by the MSIT (Ministry of Science and ICT), Korea, under the ITRC (Information Technology Research Center) support program (IITP-2021-0-01810) supervised by the IITP (Institute for Information and Communications Technology Planning and Evaluation).

**Institutional Review Board Statement:** Not applicable.

**Informed Consent Statement:** Not applicable.

**Data Availability Statement:** Not applicable.

**Acknowledgments:** We gratefully appreciate the anonymous reviewers' variable reviews and comments.

**Conflicts of Interest:** The authors declare no conflict of interest.
