# Firmware Updates over the Air via LoRa: Unicast and Broadcast Combination for Boosting Update Speed
## 5 Simulation Tests and Results
### Discussion about the Methods  
As a first conclusion, the analysis and the simulations show that the update times can be significant, in some cases in the order of tens or hundreds of hours. This problem can be mitigated by the selection of the best-suited method.  
There is a big difference between the _only unicast_ method and the two ones in which broadcast transmission is employed. This fits with the results observed in the analytical section (see Figures 4 and 5). The difference is usually significant: both broadcast methods can perform the firmware exchange using between 10 and 35% of the time required by the _only unicast_ method. In small scenarios (up to 400 m), the broadcast methods are always one order of magnitude faster, and in some cases, this advantage can be of two orders of magnitude (150 nodes with a distance of 400 m). In big scenarios (2 km), the advantage of the broadcast methods is reduced: the _broadcast + unicast_ method is able to complete the update in a time between 20 and 30% of the time, whereas the _only broadcast_ method is usually faster. For example, with 150 nodes, it only requires 12.5% of the time required by the _broadcast + unicast_ method. In conclusion, it seems clear that sending all the chunks in broadcast frames is the best option, also considering that there is an optimal value of the number of initial broadcast rounds. This also confirms the results obtained in the theoretical part (Figures 4 and 5).  
However, there are other considerations to be made, in order to establish the scenarios in which these conclusions are fully valid.  
First, the two methods that send broadcast frames are valid if all the nodes run exactly the same firmware. Otherwise, the broadcast should be performed in groups, as this would reduce the benefit and complicate the implementation and control, as it requires a tight control of what has been received by each node.  
The broadcast methods could also be used in LoRaWAN scenarios. For example, the firmware update presented in [8] showed an FUOTA protocol based on multicast frames. Its limitation, which would be overcome by the methods proposed in the present paper, is that it does not define a policy for retransmitting failed chunks. In contrast, our methods could enhance the whole update process in terms of speed and efficiency.  
Finally, it should be considered that, although the conclusion that broadcast is the best option is valid in our case (LoRa with a constant spreading factor and channel bandwidth), it may not be applicable in other scenarios: if technology allowing an adaptive rate is employed, this can be different. For example, in 802.11, multicast frames, and by extension, broadcast ones, are typically transmitted at one of the _Basic Rates_, i.e., one of the rates that the Access Point (AP) has designated as mandatory for all its clients to support if they wish to connect [34]. This approach ensures that these frames are received by all clients, as these frames are not acknowledged at the 802.11 layer. Therefore, there would be cases in which the unicast option could be faster. As an example, if 10 nodes must receive new firmware, sending it individually in unicast frames at 54 Mbps will be faster than sending it once in broadcast frames at 1 Mbps.