# Computational Load Analysis of a Galileo OSNMA-Read Receiver for ARM-Based Embedded Platforms +
## 5 Computational Burden Analysis of the Complete Receiver
### Profiling Analysis of the Complete Receiver Chain  
In order to perform the profiling of the complete receiving chain, the receiver has been fed by a 10 min file of raw samples, configured to elaborate 12 satellites, i.e., six GPS and six Galileo, and executed iterating six times, for a total of about 1 h of equivalent running time on all four platforms listed in Table 2.  
Table 9 reports the average execution time required by the main processing steps performed to elaborate one code period of input GNSS samples, i.e., 1 ms for GPS and 4 ms for Galileo, and compute the PVT. In particular, as better detailed in [17], and recalled hereafter for the reader's convenience, the receiver main loop elaborates 1 ms bunches of samples for each channel, i.e., satellite, through a finite state machine, illustrated in Figure 6. Such finite state machine includes acquisition, further detailed in coarse acquisition, Doppler and code refinements and confirmation, and tracking for all the channels. The tracking includes the calls to the Galileo OSNMA functionalities. \begin{table}
\begin{tabular}{c c} \hline \hline \multicolumn{2}{c}{**GNSS Signal Generator Setup**} \\ \hline
**GNSS Signals** & 10 GPS L1 and 6 Galileo E1 \\
**Galileo OSNMA setup** & set of values _S4_ in Table 3 \\
**GNSS Received Power** & \(-110\) dBm for all GNSS signals \\
**Simulated User Dynamic** & Static Position \\
**FE Configuration** & \\
**FE** & SiGe v2 [28] \\
**Sampling frequency\(f_{s}\) (MHz)** & 16.367 \\
**Intermediate frequency\(f_{IF}\) (MHz)** & 4.1304 \\ \hline \hline \end{tabular}
\end{table} 
Table 8: Test setup. In a global picture, the PVT computation certainly represents the heaviest processing step, as expected; besides, its very low call rate makes it less critical than the channel state machine's operations, showing call rates of at least three orders of magnitude higher. The coarse acquisition is the processing step that requires the highest execution time and the highest call rate, as already pointed out in [20], making it the most demanding one for a real-time execution. It is worth noticing that the impact of the OSNMA verifications on the Galileo tracking burden was expected to be negligible on average, due to their much lower call rate. This was confirmed by the achieved result, which shows it to be comparable to the Galileo tracking without OSNMA shown in [20] for the standard PC and ODROID-X2. As expected and already observed in Section 4, the standard PC outperforms all other platforms: the performance degradations in terms of execution time are reported in Table 10 and roughly range in the intervals 13-16 times, 6-9 times and 8-13 times for all the processing steps in the ODROID-X2, Raspberry Pi4 and ODROID-C4 machines, respectively. Furthermore, differently from what observed in Section 4 where the newer platforms basically showed similar performances with the advantage of ODROID-C4 being limited to the digital signature verification, here Raspberry Pi4 (platform 3) overcomes ODROID-C4 (platform 4), as is clearly visible in Figure 7 with improvements from 16% to 34%, except regarding the PVT computation with a degradation of about 4%. Although the two boards, namely, platforms 3 and 4, have somewhat similar hardware features, as reported in Table 2, the different results could be partially explained by the final purposes of the two different processors: indeed, as declared by the manufacturer, Cortex-A72, released  
\begin{table}
\begin{tabular}{c c c c c c} \hline \hline  & \multirow{2}{*}{**Call Rate (Hz)**} & \multicolumn{5}{c}{**Average Execution Time (\(\mu\)s)**} \\ \cline{3-6}  & & **Platform 1** & **Platform 2** & **Platform 3** & **Platform 4** \\ \hline \multirow{5}{*}{
\begin{tabular}{c} **  
in 2015, is a high single-threaded performance CPU, whereas Cortex-A55, released in 2017, targets more high power-efficiency mid-range applications.