# Firmware Updates over the Air via LoRa: Unicast and Broadcast Combination for Boosting Update Speed
## 7 Conclusions and Future Research Directions  
This paper presented, analyzed, and compared three methods for performing the firmware exchange required by an Over The Air update of a project including a number of IoT nodes connected via LoRa. After presenting the three methods, an analytical expression of the required update time was obtained for each of them. The _only unicast_ method is the one that privileges control versus the update time: it allows an easier implementation and a simplified update, using a \"stop and wait\" policy. If a time reduction is desired, it was shown that an initial broadcast round (or more than one) and then a unicast completion of the missing chunks can significantly reduce the required time: this is the _broadcast + unicast_ method. Furthermore, an additional improvement can be included, sending the missing chunks in broadcast frames as well (the _only broadcast_ method). This can reduce the required time even more, especially if the distance and the number of nodes are high. Finally, it was shown that there is an optimal number of initial broadcast rounds. The methods were simulated in ns-3 varying different parameters, namely, the distance between the gateway and the nodes, the number of nodes, and the size of the payload. The advantages of each method were highlighted. The results showed that significant time reductions can be obtained by using the proper method: in some cases, if the number of nodes to be updated is high, the update time can be reduced by two orders of magnitude. Finally, one of the methods was implemented in real hardware, and some tests were run with it. The lessons learned from the implementation were explained in detail. It appears evident that broadcasting as many frames as possible is the optimal choice in our current scenario. This approach is particularly effective in the case of LoRa, where a fixed rate is employed. However, it is important to note that this strategy may not be suitable for all situations. For instance, if a project includes nodes with different firmware versions, the benefits would be mitigated. Furthermore, when using technology that supports adaptive rates, the dynamics could change: if broadcast frames are transmitted at lower rates, the unicast option can become potentially faster. Therefore, the choice of broadcast or unicast should be performed carefully, based on the specific technology and scenario at hand. As far as future research directions are concerned, more scenarios can be simulated and other methods can be implemented. For example, alternatives to the \"stop and wait\" approach could be explored, i.e., \"go back N\" or even \"selective ACK.\" This would be valid for the _only unicast_ method and for the second stage of the _broadcast + unicast_ method. Furthermore, different combinations of the three methods could be explored. More simulations could be performed, including interfering nodes. Other effects could then be observed. For example, it is possible that the use of smaller chunks provides a better performance in these cases. Considering the increasing interest in the use of machine learning for IoT environments [35], it would also be interesting to have a tool that takes, as an input, the characteristics of the scenario (the number of nodes, the groups of nodes that share the same firmware version, the distances, the size of the firmware, the energy consumption, and the background traffic, etc.) and generates an output specifying the best-suited method and best parameters for performing a firmware update on it. This tool could be trained using simulations or real results and improve its output automatically. Although the present paper is focused on the firmware exchange stage, the security of the previous stages could be improved, adding new layers based on blockchain [36].