# Firmware Updates over the Air via LoRa: Unicast and Broadcast Combination for Boosting Update Speed
## 5 Simulation Tests and Results
### Comparison between the Update Methods Using Single-Run Simulations
#### 5.2.3. Only Broadcast Method  
The third example presents the results of the _only broadcast_ method in the small scenario (maximum radius of 400 m). The initial broadcast stage lasts 16,097 s (Figure 11(a)), as in the previous case. In the next stage, the gateway asks each node for the bitmap including the missing chunks. When it receives the response, the chunks are sent in broadcast frames. Figure 11(b) represents the RSSI of the received chunk if the node was missing that chunk. In this case, the first broadcast phase is very successful, so only 19 chunks are sent to the nodes (in broadcast frames) in the second stage.  
The total time is 17,542 s, so it is slightly worse (4.5%) than that of the _broadcast + unicast_ method. This difference is caused by the method followed in the final rounds: in the _broadcast + unicast_ method, after a single request for the bitmap, all the pending chunks are sent and then the corresponding acknowledgement is received, which is relatively fast if the number of pending chunks is low. However, in the _only broadcast_ method, a _SEND ME THE BITMAP_ message has to be sent a number of times until an _ALL CHUNKS RECEIVED_ message is sent by the node. Therefore, the number of messages is higher. However, if the number of pending chunks is high, the _only broadcast_ method has the advantage of allowing any node to receive any pending chunk that is sent to the air in a broadcast frame, as we will see in the next example.  
Another simulation is run using the big scenario (maximum radius 2 km). In this case, the broadcast phase lasts exactly the same time: one round which lasts 16,097 s (Figure 12(a)). The advantage with respect to the _broadcast + unicast_ method can be clearly observed in the next stage: since the chunks are sent inside broadcast frames, other nodes different from the original destination may also receive and store them. In Figure 12(b), we represent the RSSI of the frames received by the nodes that are missing the corresponding chunks. As can be observed in Figure 12(b), at the beginning of this stage, a lot of nodes receive and store  
Figure 11: _Broadcast + unicast_ firmware update of 10 peers with a maximum radius of 2 km: (**a**) RSSI of the frames received by each node, containing the firmware chunks; and (**b**) RSSI of the ACK frames received by the gateway. The red line corresponds to the sensitivity of the receiver.  
missing chunks which were requested by other nodes. However, when a node receives all the chunks, its color disappears from the graph.  
This allows for a much faster completion of all the chunks for all the nodes. As a consequence of this advantage, the total update time is now 66,874 s. The second phase is reduced from 120,316 (_broadcast + unicast_) to 50,777 s (_only broadcast_). Overall, the _only broadcast_ only takes 49% of the time required by the _broadcast + unicast_ method, and it induces a reduction to 22.7% of the time required by the _only unicast_ method.