# Firmware Updates over the Air via LoRa: Unicast and Broadcast Combination for Boosting Update Speed
## 4 Analytical Expression of the Total Update Time
### Only Broadcast Method  
This method has a first stage in which all the chunks are broadcast \(B\) times. The time required for this stage is the one obtained in (8).  
In the second stage, the gateway sends a request to the first node, specifically inquiring about the chunks that are missing. After the node's response including the bitmap, these chunks are sent in broadcast frames that can also be received by any other node. After that, the gateway asks again about the missing chunks: if the response of the first node is an \(ALL\)  
Figure 4: _Broadcast + unicast_ method: total update time for different values of the number of nodes and the number of broadcast rounds: (**a**) loss probability = 1% and (**b**) loss probability = 40%. Note that the \(Y\) axis is in logarithmic scale, and that the ranges of (**a**,**b**) are different.  
CHUNKS RECEIVED_ frame, the gateway switches to the second node; otherwise, it means that the first node is still missing some chunks, so they are broadcast again to it, and so on.  
To obtain the total update time of a node during the second stage, we must calculate the number of times a chunk is sent to the air in this phase. For simplicity, we will assume that the time required to exchange the bitmaps is negligible with respect to the time required to exchange the firmware chunks (\(ToA_{ch}\gg ToA_{req}+ToA_{bit}\)).  
Let \(n_{i,j}\) be the number of times that chunk \(i\) is sent to node \(j\). To calculate its expected value for the first node (\(j=1\)), namely E[\(n_{i,1}\)], we can consider that it is the product of the probability of node 1 not having received chunk \(i\) in the first \(B\) rounds (\(p_{1}\)B), and the number of times it will be sent specifically to node 1 in its round, i.e., \(1/(1-p_{1})\):  
\[\mathrm{E}[n_{i,1}]\ =\ \frac{1}{1-p_{1}}.p_{1}{}^{B}. \tag{13}\]  
The subsequent values of E[\(n_{i,j}\)] (\(j>1\)) will depend on the number of times that chunk \(i\) has been previously sent to the air (E[\(n_{i,j-1}\)]). E[\(n_{i,j}\)] can be obtained as the sum of E[\(n_{i,j-1}\)] plus the number of times the chunk is sent in this round, i.e., the product of the number of times the chunk will be sent to node \(j\), i.e., \(1/(1-p_{j})\), and the probability of node \(j\) having not received it. The value can, therefore, be calculated recursively with this formula:  
\[\mathrm{E}[n_{i,j}]\ =\ \mathrm{E}[n_{i,j-1}]\ +\ \frac{1}{1-p_{j}}.p_{j}^{E[n_{i,j-1}]}. \tag{14}\]  
Using the same parameters employed in the previous subsection, the update time of this method can now be depicted: Figure 4(a) is obtained with \(p_{j}=1\%\) for all the nodes, and Figure 4(b) with \(p_{j}=40\%\). The graphs show that the loss probability has a strong influence on the update time, as could be expected. In this case, the graphs keep on growing, even for \(B=15\): as the total time required by this method is lower, the time spent in the initial rounds is more significant than that of the _broadcast + unicast_ method.  
In this case, it is exactly the same to perform an initial broadcast round (\(B=1\)) as just starting to sending the firmware chunks to the first node (\(B=0\)), so the rest of the nodes will hear and store some of them. In addition, the optimal number of broadcast rounds is 0 or 1, i.e., making more than one round does not provide any benefit.  
Figure 5: _Cont._