# Firmware Updates over the Air via LoRa: Unicast and Broadcast Combination for Boosting Update Speed
## 5 Simulation Tests and Results
### Effect of the Number of Nodes  
In this subsection, we introduce a series of tests designed to assess the impact of varying the number of nodes updated. The frame size is fixed to 215 bytes, and two different values for the distance are employed: 400 m (Figure 17) and 2 km (Figure 18).  
In the case of the _only unicast_ method, it can be observed that the update time is (roughly) proportional to the number of nodes (this cannot be directly observed in the graphs, since they are in logarithmic scale).  
The two methods that employ broadcast frames have a clear advantage, because a high number of nodes will potentially receive the chunks at the same time. In the _broadcast + unicast_ method, it can be observed that the initial broadcast round saves a high percentage of the update time: if the scenario is small (400 m, Figure 17), it only requires 9.4% of the time required by the _only unicast_ method for 10 nodes. When 150 nodes are used, the time required by the _broadcast + unicast_ method is only 0.88% of the time used by the _only unicast_ method (it is more than two orders of magnitude faster). If the scenario is higher (2 km, Figure 18), the saving is smaller: the first broadcast round is less effective, so the method behaves more closely to the _only unicast_ approach. The time is 35% of the _only unicast_ method for 10 nodes and 29.17% for 150 nodes.  
Figure 16: Effect of payload size on update time. Maximum radius 2 km: (**a**) _Only unicast_ method; (**b**) _Broadcast + unicast_ method; and (**c**) _Only broadcast_ method. Note that the \(Y\) axis is in logarithmic scale.  
As far as the _only broadcast_ method is concerned, if the scenario is small (400 m), the results are slightly worse than those of the _broadcast + unicast_ method: the initial broadcast round is quite effective, so many nodes receive the vast majority of the chunks in that  
Figure 17: Effect of the number of nodes on update time. Maximum radius 400 m: (**a**) _Only unicast_ method; (**b**) _Broadcast + unicast_ method; and (**c**) _Only broadcast_ method. Note that the \(Y\) axis is in logarithmic scale.  
Figure 18: Effect of the number of nodes on update time. Maximum radius 2 km: (**a**) _Only unicast_ method; (**b**) _Broadcast + unicast_ method; and (**c**) _Only broadcast_ method. Note that the \(Y\) axis is in logarithmic scale.  
moment. The _only broadcast_ method is 4.2% worse for 10 nodes and 38.1% worse for 150 nodes.  
However, the efficacy of the _only broadcast_ method becomes distinctly evident in the big scenario (2 km): as the number of nodes increases, so does the benefit with respect to the _broadcast + unicast_ method. With 10 nodes, the time is 65.7% of the one required by the _broadcast + unicast_ method. For 150 nodes, the time is only 13.3%. The reason is that, with a higher number of nodes, the likelihood of a node receiving a chunk from any previous transmissions increases significantly.  
This fits with the theoretical results (see Figures 4 and 5): the _only broadcast_ method is less sensitive to the number of nodes than the _broadcast + unicast_ method: it is able to maintain low update times, even for high numbers of devices.