Abstract
The capacity to update firmware is a vital component in the lifecycle of Internet of Things (IoT) devices, even those with restricted hardware resources. This paper explores the best way to wirelessly (Over The Air, OTA) update low-end IoT nodes with difficult access, combining the use of unicast and broadcast communications. The devices under consideration correspond to a recent industrial IoT project that focuses on the installation of intelligent lighting systems within ATEX (potentially explosive atmospheres) zones, connected via LoRa to a gateway. As energy consumption is not limited in this use case, the main figure of merit is the total time required for updating a project. Therefore, the objective is to deliver all the fragments of the firmware to each and all the nodes in a safe way, in the least amount of time. Three different methods, combining unicast and broadcast transmissions in different ways, are explored analytically, with the aim of obtaining the expected update time. The methods are also tested via extensive simulations, modifying different parameters such as the size of the scenario, the number of bytes of each firmware chunk, the number of nodes, and the number of initial broadcast rounds. The simulations show that the update time of a project can be significant, considering the limitations posed by regulations, in terms of the percentage of airtime consumption. However, significant time reductions can be achieved by using the proper method: in some cases, when the number of nodes is high, the update time can be reduced by two orders of magnitude if the correct method is chosen. Moreover, one of the proposed methods is implemented using actual hardware. This real implementation is used to perform firmware update experiments in a lab environment. Overall, the article illustrates the advantage of broadcast approaches in this kind of technology, in which the transmission rate is constant despite the distance between the gateway and the node. However, the advantage of these broadcast methods with respect to the unicast one could be mitigated if the nodes do not run exactly the same firmware version, since the control of the broadcast update would be more difficult and the total update time would increase.
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.