## 4 Performance Evaluation
### Simulation
In this context, during our experiments, we evaluated the latency of REL, AODV and LABILE. Each received packet was categorized into one of the three latency categories presented in Table 2. This classification aims to clarify the performance analysis of the evaluated protocols. For scenarios with 20 nodes, results show that REL improves the latency up to 0.8%, the latency between 0 and 40 ms, and 0.4% for packets above 80 ms. LABILE obtained results similar to REL for scenarios with 20, 40 and 60 nodes, where the maximum difference between them was 1% in packets  
\begin{table}
\begin{tabular}{c c c c c} \hline  & **Number** & \multicolumn{3}{c}{**Latency**} \\ Protocol & of Nodes & 0–40 ms & 40–80 ms & \(>\)80 ms \\ \hline  & 20 & 99\% & 0.6\% & 0.4\% \\  & 40 & 94.5\% & 4.3\% & 1.2\% \\ AODV & 60 & 90.6\% & 5.4\% & 4\% \\  & 80 & 85  
with latency between 0 and 40 ms. However, if the number of nodes increases, the difference rises to 4% for scenarios with 100 nodes. Additionally, the performance of AODV decreases by up to 17.9% compared with REL, and 13.9% compared with LABILE, for latency between 0 and 40 ms, and for scenarios with to 100 nodes. In the case where the scenarios with few numbers of nodes, the improvement of latency result is reduced due to the availability of short routes. However, in large-scale scenarios, such as 80, 100, and 200, nodes achieve good gains when the REL protocol is used. In a scenario with 80 nodes, REL exceeded LABILE by up 2.4% in the lower delay category and 1% in the highest delay. The performance gain increases in a scenario with 100 nodes, where the differences are 4% and 1.8%, respectively. These results show the efficiency of REL for improving the usage of network resources. In the scenario with 200 nodes, the protocol AODV reaches more than 40 ms delay in 26.4% of transmitted packets, a result 6% lower than obtained in the scenario of 100 nodes due to the high number of overhead and interference created in the densest scenario. Regarding the protocol LABILE, the difference reaches 17.5% and 21.6% compared with REL. In the category of delays up to 40 ms, REL maintains the highest performance, exceeding in 4.1% and 20.6% LABILE and AODV, respectively. The PDR was used to measure the reliability of REL, LABILE and AODV. Figure 9 shows the PDR for all packet transmissions in scenarios with different node densities. Figure 9 establishes an interval from 80% to 100% to make it easier to analyze the results. As can be seen in Figure 9, REL outperforms AODV and LABILE in all experiments. The difference increases when there is a rise in the number of nodes in the simulated scenario. This can be explained by the load balancing scheme and reliable route selection proposed in REL, when compared with LABILE and AODV that do not have load balancing solutions and select routes based only on link quality and the number of hops. The scenario with 20 nodes confirms the accuracy of the simulation results in comparison with the testbed is presented in Figure 2. In the case of the testbed experiments, the average value of PDR for AODV was 92.4% and for REL was 96.8%. These results reflect the close approximation of the real and simulated experiments. In a similar way to what was found in the latency results, there is an improvement of REL, in terms of PDR, compared with AODV and LABILE when the node density increases. These scenarios with high node density are expected for many IoT applications, such as automation of homes and offices, smart parking, healthcare and environmental monitoring. The scenarios with 60 and 80 nodes show results that correspond to the increasing number of nodes. REL improves by 8.8% when compared with AODV and 4.5% with LABILE in a scenario with 60 nodes. In the scenario with 100 nodes, REL increases the number of packets delivered in 9.4% and 7.9%, respectively. This is due to the fact that increasing the node density also increases the number of available routes for load balancing and causes the phenomenon of signal attenuation.