# Firmware Updates over the Air via LoRa: Unicast and Broadcast Combination for Boosting Update Speed
## 1 Introduction  
The ability to perform firmware updates is an essential part of the lifecycle of Internet of Things (IoT) devices, even those with constrained hardware resources. This is primarily because security algorithms require regular updates, either as a response to the discovery of a vulnerability or as a proactive measure. Additionally, firmware updates facilitate the introduction of new functionalities on devices. In certain situations, devices requiring updates can be manually flashed using a connector. Alternatively, they may be connected via a cable that allows for the update. However, in many instances, these devices are inaccessible. For example, they may be in the field or situated in ATEX (potentially explosive atmospheres) zones, where access requires specially trained personnel and specific equipment. For instance, a luminaire designed for an ATEX zone might be installed on the ceiling of an oil and gas facility's warehouse,making it challenging to reach. In addition, the installation of additional wiring may not be a feasible solution in these scenarios. Many industrial IoT (IIoT) devices are dispersed across the field, and, particularly in ATEX zones, regulations restrict the installation of extra wires. At the same time, security is a must in these areas, usually related to critical infrastructures which require relatively frequent security updates. Many IoT protocols have been designed with the main objective of having a long range, at the cost of a limited bandwidth. From the lowest to the upper layers, they are conceived with a specific purpose in mind: to enable the efficient transmission of sensor data over extensive distances, while necessitating only a minimal byte count. In many instances, these protocols function within license-free bands of the electromagnetic spectrum. Regulatory bodies impose certain restrictions on airtime usage to prevent potential congestion situations. Consequently, the volume of information that can be transmitted by each device per unit of time is significantly limited. Numerous wireless protocols possess the capability to transmit both broadcast (or multicast) and unicast messages to and from devices. Although broadcast messages may, in principle, provide a higher level of scalability, they have a limitation: they cannot be acknowledged, so the sender is unable to ascertain which devices have received the messages and which have not. Furthermore, the sending of broadcast messages cannot be optimized (rate and power) for each of the receivers. In this context, the problem to be addressed in this paper is to explore the ways to wirelessly (Over The Air, OTA) update low-end IoT nodes with difficult access, combining the use of broadcast and unicast communications. Specifically, the devices used in the present study would correspond to the _Low-end, Class 2_ category of the classification presented in [1] (roughly 50 kB of RAM and 250 kB of flash). The challenge is to streamline the roll out of a system update, eliminating the need for physical interaction with the device, while minimizing the time required. The update requires the successful transmission of a set of fragments (chunks) of the firmware, and the subsequent flashing of the received update by each and all the nodes. If the quality of communication is high, an initial transmission of all firmware chunks via broadcast/multicast frames could lead to a significant proportion of nodes possessing a large portion of these fragments. Following this broadcast phase, a unicast communication could be used to ascertain the status of each node and deliver any remaining segments. However, in situations where communication quality is poor, the initial broadcast phase may not be as effective. This raises several research questions related to scalability: Is it always beneficial to start with a broadcast phase? Would it be more effective to conduct multiple broadcast phases prior to the final unicast stage? Other questions of interest are: Should the maximum frame size always be used?