## 5 Results
### Scenario 1  
The latency results obtained for the transmissions between the end devices and the final topic in the MQTT broker for all the devices that performed a topology change in scenario 1 are displayed in Figure 8. With this metric, it is possible to discern if the delays that may occur by performing multiple hops negatively affect the overall operation of the LoRaWAN network and its applications. The evolution of the changes in topology and transmission mode for each of the devices in this evaluation scenario is shown in Figure 9, where end devices 4 and 5 change into mesh mode, and end devices 2 and 6 change into hybrid mode. Devices 1 and 3 remain in star mode for the duration of the complete test. This setup was performed manually through the control UI to generate the desired scenario. As can be seen from the results, the latency of end devices 4 and 5 increases when they change from star to mesh mode because an additional hop to the route of the data frame is added. Furthermore, there is an increase in latency variations for both devices, with oscillating values that remain above 0.5 s and below 2.5 s. Regarding the devices that changed into hybrid mode, the latency of device 2 increased and the latency of device 6 decreased compared to their starting point, although both remained within the range of 0.725 and 2.362 s. Although the messages from the end devices in mesh mode undergo one more hop to reach the gateway, their latency stays in the range obtained from the end devices in hybrid mode. The latency of devices 1 and 3, which continued in star mode, stayed significantly more stable compared to the devices in mesh or hybrid mode. It is also important to note that latency increases with elapsed time for all devices. This phenomenon can be attributed to network congestion, which accumulates over time. Although star devices typically experience lower delays, their performance can be impacted under high network load. Additionally, we observed that some hybrid and mesh-mode devices experienced longer queuing times due to topology changes. External interference or environmental conditions may have also played a role in latency variations, further impacting transmission reliability across all topologies. Overall, this increase in latency remains within acceptable values for typical LoRaWAN telemetry applications that do not operate in strict real-time.  
The RSSI and SNR values for scenario 1 are plotted in Figures 10 and 11, respectively. After the topology mode change, devices 4 and 5 reveal more variations in RSSI, obtaining both higher and lower values compared to the average RSSI before the topology change. However, after the topology change, the average RSSI is \(-\)75.41 dBm for device 4 and \(-\)75.11 dBm for device 5, which is better than the average RSSI prior to the topology mode change of \(-\)77.45 dBm and \(-\)75.53 dBm, respectively. The rest of the devices did not experience noticeable changes throughout the test. Regarding the SNR, there are no significant changes caused by updating the topology mode at the end devices. Therefore, considering the values obtained when all the devices were in the conventional star mode with the conditions of this experiment, we can conclude that the link quality remains within usual values for current LoRaWAN networks.  
Figure 8: Latency in scenario 1.  
Figure 10: RSSI of the devices in scenario 1.  
Figure 9: Topology changes of the devices in scenario 1.  
The compilation of minimum, maximum, average, and variance of the metrics for each device in scenario 1 is provided in Table 3.