# Efficient Runtime Firmware Update Mechanism for LoRaWAN Class A Devices
## 4 Results
\begin{table}
\begin{tabular}{l c c c c c} \hline \hline
**Parameter** & **Update \#1** & **Update \#2** & **Update \#3** & **Update \#4** & **Update \#5** \\ \hline Intel Hex File records & 6 & 6 & 17 & 57 & 10 \\ Updated rows in the uC flash & 1 & 3 & 5 & 7 & 8 \\ Intel Hex File size (bytes) & 194 & 198 & 643 & 2373 & 372 \\ Updated bytes in the uC flash & 63 & 64 & 226 & 876 & 128 \\ Average transmission time of the update file & 37.60 & 37.00 & 96.40 & 317.20 & 65.00 \\ using TTN (s) & 5.37 & 5.28 & 5.35 & 5.46 & 5.91 \\ Average transmission time between records (s) & 24.12 & 37.4 & 51.33 & 68.12 & 72.75 \\ Overall update process (ms) & 1.81 & 1.23 & 3.83 & 14.19 & 2.21 \\ Copy rows task (ms) & 1.75 & 6.71 & 9.43 & 5.91 & 18.45 \\ Erase rows task (ms) & 1.55 & 4.36 & 7.13 & 10.01 & 11.34 \\ Update row task (ms) & 1.37 & 5.61 & 9.75 & 14.91 & 16.77 \\ Verify update task (ms) & 17.64 & 19.49 & 21.19 & 23.10 & 23.98 \\ Downtime (ms) & 2.92 & 9.97 & 16.88 & 24.92 & 28.11 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Impact assessment of completing firmware update of different sizes. Figure 20: Time diagram of the LoRaWAN downlink process of the update records. depicted by the red line. Each stage begins when the corresponding IO pin is set to a high level and ends when it is set to a low level. Analysis of the results for the firmware update mechanism proposed, for Update #3, indicates that the process takes 51.33 ms to complete all stages, with a downtime of 16.88 ms. The findings of this study confirm that the proposed firmware update method during runtime, without IoT device reboot, offers significant advantages. Firstly, a substantial reduction in device downtime was observed, which is beneficial for applications requiring high availability. Additionally, there was a decrease in energy consumption during the update process compared to updating a complete firmware image, preserving the autonomy of Class A IoT devices. The proposed approach also minimizes the amount of data transmitted compared to updating a complete firmware image, thereby reducing the communication network load and concentrating the update process effort more on the end device, simplifying its implementation and operation. The reduction in computational load related to the update process is achieved by eliminating the reconstruction of the firmware image on the end device, optimizing resources both on the device side through more efficient memory usage and on the network side, which shows improved performance due to reduced traffic load. When comparing with related works, it was noted that, contrary to the idea advocated by [PERSON] et al. [3], the proposed method is efficient for the LoRa Alliance Class A data transmission mechanism, where downlink follows an uplink. Despite the LoRa Alliance specifications [21] for FUOTA, the proposed method utilizes the network server application layer, making the update process less complex and more agile. [PERSON] et al. [5] suggest improvements in the update process using multiple gateways; however, the method proposed in this article does not require changes to the existing network, except in scenarios without coverage. We partially agree with [PERSON], [PERSON] [22], who argues that Class B performs better in terms of transmission and energy efficiency for complete firmware image updates. However, since the proposed method significantly reduces the amount of data, it preserves network capacity and improves energy efficiency by drastically reducing the active time associated with the update process. In contrast to the study by [PERSON], [PERSON] [9], which suggests benefits in switching to Classes B or C, the implemented method demonstrates a significant reduction in downtime of 16.88 ms compared to the 42.48 s described in [9], without the need for a class change. This is primarily due to the method not requiring firmware image reconstruction from delta segments (18.57 s).