# Computational Load Analysis of a Galileo OSNMA-Read Receiver for ARM-Based Embedded Platforms +
## 4 Software Profiling Analysis of the OSNMA Functions
### Some More Considerations about the Real-Time Compatibility  
Apart from P256, results for the other elliptic curves pose some concerns about their compatibility with real-time execution. In particular, as better detailed in [17], the receiver main loop elaborates 1 ms bunches of samples for each channel, i.e., satellite, meaning that the cumulated elaboration time of the whole signal processing chain, including acquisition and tracking for all the channels, OSNMA support and other operations, cannot exceed 1 ms. This means that functions with very high computational burdens might cause the loss of input samples and compromise the real-time capability. Despite one step of TESLA chain exhibiting a very low execution time, as shown in Table 4, the total computational load required to verify a TESLA key depends on the number of steps to be traversed in the chain, as mentioned before. As soon as the first received TESLA key has been verified, a maximum of NMACK \(\times\) NS steps has to be performed in each subframe. At the power on stage, instead, the receiver has to cross the chain back to the root key, implying a huge burden in case of a long TESLA chain, e.g., more than six million steps in the current configuration reported in Table 3 if the root key dates back one month. This aspect has been already fully addressed in [17], for which the implementation of a strategy based on the workload spreading over time has been carried out in order to preserve the real-time capability of the receiver. Such a strategy could be extended also to other OSNMA functions, such as the digital signature verification. In addition to this, a reduction of the call rate could also be evaluated, for instance, avoiding repeating the key root authentication unless a chain or public key renewal occurs. The same approach could be used to limit the number of MAC verifications, in the case of excessive computational burden.  
\begin{table}
\begin{tabular}{c c c c c c c c c c} \hline \hline  & & \multicolumn{3}{c}{**Platform 2 [16]**} & \multicolumn{3}{c}{**Platform 3**} & \multicolumn{3}{c}{**Platform 4**} \\ \hline \multirow{4}{*}{**Sensors**} & **Sets of** & \multirow{2}{*}{_avr (\(\mu\)s)_} & \multirow{2}{*}{_\(\sigma\) (\(\mu\)s)_} & \multirow{2}{*}{_\(\varepsilon\) (\%)_} & \multirow{2}{*}{_avr (\(\mu\)s)_} & \multirow{2}{*}{_\(\sigma\) (\(\mu\)s)_} & \multirow{2}{*}{_\(\varepsilon\) (\%)_} & \multirow{2}{*}{_avr (\(\mu\)s)_} & \multirow{2}{*}{_\(\varepsilon\) (\%)_} & \multirow{2}{*}{_avr (\(\mu\)s)_} & \multirow{2}{*}{_\(\sigma\) (\(\mu\)s)_} & \multirow{2}{*}{_\(\varepsilon\) (\%)_} \\ \cline{2-2} \cline{6-11}  & **Values** & S1 & 2835.13 & 6.64 & 0.23 & 1857.40 & 11.63 & 0.62 & 1416.60 & 18.25 & 1.29 \\ \cline{2-2} \cline{6-11}  & **S2** & 932.90 & 4.34 & 0.46 & 706.54 & 5.75 & 0.81 & 457.51 & 13.62 & 2.98 \\ \cline{2-2} \cline{6-11}  & **S3** & 10,189.00 & 16.97 & 0.17 & 5959.01 & 31.05 & 0.5 & 3997.05 & 31.35 & 0.78 \\ \cline{2-2} \cline{6-11}  & **S4** & 22,982.28 & 16.28 & 0.07 & 14,074.56 & 61.98 & 0.44 & 9419.61 & 18.82 & 0.20 \\ \hline \hline \end{tabular}
\end{table}
Table 7: Execution time profiling of the digital signature verification obtained on the three embedded platforms with the sets of values S1 to S4 in Table 3. © [2020] IEEE. Extended, with permission, from [16].  
Figure 5: Execution time percentage improvements \(I\) for platforms 3 and 4 with respect to platform 2 for all the four ECDSA options of the digital signature verification in Table 3.