# Firmware Updates over the Air via LoRa: Unicast and Broadcast Combination for Boosting Update Speed
## 2 Related Work
### Over the Air Update of IoT Devices  
Back in 2006, before the rise of the IoT, the authors of [10], when talking about the updating of wireless sensor networks, detailed the main challenges to be met by firmware update algorithms: they should adapt to the limited processing capacity and memory of the devices and they should be energy efficient, while ensuring the correct delivery of the firmware. Finally, scalability was also considered as a relevant question, since it was (rightly) expected that node density could increase dramatically in the near future. More recently, an examination was carried out on the support for OTA updates across 26 open-source IoT operating systems and embedded software projects [11]. The findings revealed that comprehensive information regarding the implementation of OTA updates was not provided by all projects, so the authors advocated for the establishment of standard mechanisms. This would eliminate the necessity to construct OTA update systems from scratch each time a new technology is under consideration for testing or implementation. A recent standardization effort carried out by the Software Updates for Internet of Things (SUIT) Working Group of the Internet Engineering Task Force (IETF) resulted in the proposal of an architecture for firmware updates applicable to IoT devices, as detailed in [2]. The architecture defines a set of entities: the cloud part, a firmware server, and the end devices. It also defines a set of stages, including the validation of a manifest, the firmware exchange, its validation, and secure flashing, etc. The authors of [12] pioneered the implementation and testing of a firmware update solution aligned with the architecture proposed by the IETF. Their tests were conducted in two distinct environments, one of them using Wi-Fi in an LAN, and the other in a real-world scenario with LoRaWAN gateways. [PERSON]'s work [13] was constructed entirely on the foundation of the same IETF architecture, prior to its formalization as in [2], demonstrating its adaptability and practicality. The implementation used Contiki-NG [14] as the embedded operating system and the tests were carried out on a single board device. The study in [15] presented LoRaP2P, describing an architecture and a method for firmware updates in agricultural scenarios. A TDMA-based (Time-Division Multiple Access) MAC protocol was defined, including a cycle of 32 time slots of 0.5 s each. In the _firmware updating_ stage, the gateway sent the chunks in broadcast frames, including 30 bytes of the firmware each, according to a customized packet structure. A \"go-back N\" mechanism was implemented. To avoid problems if a node was restarted, the received chunks were stored in a non-volatile memory. The system was implemented and tested with real hardware. The authors of [16] presented a system for remotely flashing ATMEL AVR microcontrollers via Wi-Fi and LoRa technologies. The paper was mainly focused on the hardware part, and not on the exchange of firmware chunks. A simulation tool called FUOTASim was developed in [8], with the aim of studying the effects of LoRaWAN parameters on the firmware update process, considering the impact on time, energy consumption, and efficiency. It allows the use of different data rates, firmware and chunk sizes, and redundant codes. The study presented in [17] proposed a firmware update protocol over LoRaWAN based on adaptative data rate techniques, defined as a couple of spreading factor and bandwidth values. It was studied by the means of simulations, using as KPIs the energy consumption of the end devices powered by batteries and the security. The possibility of the firmware being stolen during the FUOTA process was also studied. The present paper is focused on the firmware delivery stage, and not so much on the architecture (although an architecture is defined and employed, presented in Section 6).