Galileo Authentication and High Accuracy: Getting to the Truth - Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design

Galileo Authentication and High Accuracy: Getting to the Truth

A look at the infrastructure, recent performance results and prospects for the future.





The truth is rarely pure and never simple,” an Oscar Wilde character said in his best-known play. This sentence fits the satellite navigation message well, where the “truth” is the exact position of a satellite transmitting a signal and its time of transmission. Satellite position and time are always contaminated by errors in the estimated orbit and clock and, apart from natural error sources, the true message can be supplanted without the user being able to detect it. Accurately estimating these errors and protecting the signal against potential falsification is far from simple.

For the last decade, Galileo, the European satnav system, has developed an Open Service Navigation Message Authentication (OSNMA) mechanism and a High Accuracy Service (HAS) to provide the most precise orbit and timing corrections with the current infrastructure. In January 2015, Inside GNSS published the results of the first-ever tests of a GNSS with message authentication and high accuracy corrections. The tests consisted of pre-recorded correction files injected into the system offline, and rebroadcast some minutes later through the E6-B signal component (1278.75 MHz). Thanks to this message, which was also authenticated, receivers achieved an accuracy of about 30 cm RMS per 3D position component [1]. During the last eight years, Galileo designed, developed operationally and tested OSNMA and HAS, and today both services are transmitted worldwide, openly and free of charge. This article presents some background on the Galileo infrastructure, followed by a high-level technical description of OSNMA and HAS, recent performance results and prospects for the near future.

Galileo Infrastructure

Galileo has provided positioning services since its Initial Service Declaration in December 2016. Its space segment is composed of three orbital planes. Each plane includes eight satellites with additional spares at an altitude of approximately 23,222 km. Its ground segment includes two Galileo Control Centers (GCCs), in Fucino (Italy) and Oberpfaffenhofen (Germany), 14 monitoring stations, and six Telemetry, Tracking and Control (TTC) stations, five of which are also mission Up-Link Stations (ULSs). In addition, there is a so-called GNSS Service Center (GSC), located in Torrejón de Ardoz (Spain), which hosts Galileo’s web services and also OSNMA/HAS data generators to minimize changes to Galileo’s first generation core infrastructure. At the time of writing, Galileo has 23 operational satellites, out of the nominal 24-satellite constellation. Figure 1 shows an overview of Galileo’s ground segment. A description of Galileo services can be found in [2].

Originally, Galileo also foresaw a Safety of Life (SoL) service to provide GNSS integrity worldwide. In 2013 SoL was removed, but it left an architecture designed for a tight, low-latency ground-to-space connection and some spare bandwidth in the signal message. Both features have been used for OSNMA and HAS, allowing their implementation at a low cost compared to the overall cost of the program: The current expenses allocated to OSNMA and HAS amounts to less than 1% of the total program cost so far. 

Galileo OSNMA and HAS were initially designed as components of the so-called Galileo “Commercial Service” (CS), aimed at providing “added-value” services for a fee. However, the Galileo program later considered it more beneficial to offer them for free. The third component of CS, a spreading-code authentication service currently under testing, may follow the same path. 



OSNMA is Galileo’s navigation message authentication mechanism [3]. Galileo provides the equivalent of a digital signature. This ensures the satellite navigation data is coming from the Galileo system, thus helping receivers protect from spoofing.

Architecture and Protocol

The first choice for providing data authentication potentially to a multi-billion user base, such as Galileo’s, is to use asymmetric cryptography. Galileo could simply publish a public key and then append to the navigation message a digital signature, for example of 512 bits, currently considered as secure, and allow receivers to authenticate the orbit and clock parameters. This is possible but would imply about a 100% bandwidth overhead, as the signature would be as long as the message. Instead of using digital signatures, and mainly, but not only, because of bandwidth reasons, OSNMA uses a lightweight protocol called TESLA (Timed-Efficient Stream Loss-Tolerant Authentication), adapted to GNSS. TESLA is now part of an ISO standard [4], which also includes specific features originally designed for Galileo OSNMA. 

With OSNMA, Galileo data is authenticated with Message Authentication Codes (MACs), truncated to a few-bit tags. These tags are generated based on symmetric cryptography with a TESLA key still-secret to the receiver. The TESLA key is then disclosed after about 30 seconds, allowing the tag verification and ensuring the authenticity of the navigation message. The drawback of this mechanism with respect to standard digital signatures is it requires the receiver to be loosely synchronized to the Galileo time from an external time reference, with an accuracy of about some seconds or a few minutes, depending on the use case. This ensures an adversary cannot receive the key, forge the data and replay the signal. 

OSNMA is transmitted in the E1-B I/NAV message (1575.42 MHz) in a 40-bit field every 2 seconds. It is potentially available to most receivers, including consumer devices such as smartphones. Out of the 40 bits, eight bits are devoted to the OSNMA header and Digital Signature Messages (DSMs). The remaining 32 bits transmit several tags authenticating different satellites and data, followed by one TESLA key. The overall OSNMA message structure is depicted in Figure 2 [5] for a 30-second I/NAV subframe.

The basic OSNMA operations are depicted in Figure 3, and a full description can be found in the OSNMA Signal In Space (SIS) Interface Control Document (ICD) [6] and receiver guidelines [7]. Their latest versions, describing the initial OSNMA service, were recently published on the European GNSS Service Centre (GSC) website [8]. 

What follows is a sequential description of the steps in an OSNMA-enabled receiver, including the main cryptographic functions, assuming it already has a valid public key PK. First, the receiver receives a DSM and authenticates its message M(K0), which includes a TESLA root key K0 and other parameters of the TESLA chain, such as tag length or key length, as follows:


Where signature (⋅) is the digital signature algorithm that uses the public key PK, P is a padding bitstring, (⋅||⋅) indicates the concatenation, ‘==’ is the comparison operator and DS is the digital signature transmitted in the DSM. If the verification is successful, the receiver has an authentic K0 and can recurrently authenticate navigation data with the three necessary elements: a tag, the data to authenticate and the key, described hereafter.

Each tag is followed by a Tag-Info section that includes the PRN transmitting the navigation data to authenticate, or PRND (which may not be the same as the PRN transmitting the authentication data, or PRNA) and a parameter called ADKD (Authentication Data and Key Delay) that defines the data to authenticate as follows:

• ADKD0: navigation message, with a key disclosed in the next I/NAV sub-frame, i.e. at least 30 seconds later.

• ADKD12: navigation message, with a key disclosed 11 I/NAV sub-frames later, i.e. at least 330 seconds later, allowing to serve users with a lower synchronization level.

• ADKD4: timescale offset parameters (Words 6 and 10 of the I/NAV), with a key disclosed in the next subframe.

As for the data, the receiver forms a navdata bitstring with the navigation bits to authenticate. The navdata bitstring for ADKD0 and 12 is depicted in Figure 4. It shows the main elements of the satellite ephemerides: the orbital Keplerian parameters, the clock corrections, the satellite health flags, and the ionospheric corrections, which are common to the whole constellation. 

Then, the full message to authenticate is formed as follows:


Where GSTSF is the Galileo System Time at the start of the sub-frame of the tag transmission, CTR counts the tag position in the sub-frame, NMAS is the OSNMA status (operational, test, don’t use) in the SIS, and P is a padding bitstring. 

After the tag is received, the receiver waits for at least the next 30-second subframe to receive the related key, KI. Kis authenticated through the keychain one-way function F applied I times and compared to the previously authenticated K0 as follows:


Where one iteration of F is:


Where trunc(⋅) is the truncation operator, lk is the key length (currently 128 bits), hashchain is a one-way hash function (currently SHA-256), GSTSFI-1 is the GST at the start of the KI-1 transmission sub-frame, and α is a random 48-bit string to prevent chain pre-computation. Note that once a key KI is verified against the root key K0, successive keys can be verified against KI without having to compute the hashes back to the root.

Finally, once m, KI and the tag are available, the receiver performs the following data authentication check:


Where lt is the tag length and mac(⋅) is the MAC function (currently HMAC). 

OSNMA is configurable in terms of type and length of tags, key length and other parameters. While this may increase receiver complexity, it is considered necessary to cope with the growing Galileo system capabilities (mainly number of satellites and number of uplinks) and cryptology evolutions. Currently, OSNMA is transmitted with 128-bit keys, 40-bit tags, with six tags per 30-second sub-frame, and this tag sequence repeated every two-sub-frames: [00S, 00E, 04S, 00E, 12S, 00E; 00S, 00E, 00E, 12S, 00E, 12S]. The first two digits describe the ADKD (0, 4, 12) and the last character defines whether the transmitting satellite is self-authenticating (S,PRNA=PRND) or cross-authenticating another Galileo satellite (E, PRNA≠PRND). The protocol allows that the OSNMA-transmitting satellites, currently up to 20, can cross-authenticate nearby satellites. Cross-authentication may authenticate GPS L1 C/A data as well, although for the moment this function is disabled. The recently published ICD also includes some minor additions with respect to the test ICD, such as a “cut-off parameter” to facilitate the link between transmitted and authenticated navigation data. 



Figure 5 shows the availability of OSNMA worldwide over September 2022. OSNMA is considered available if two ADKD0 tags for at least four satellites above 5º are received within a window of 120 seconds. It is expected that this assumption used for the test phase will be reduced to one 40-bit tag for initial service. The figure shows an availability in the mid-to-high 99% in every location worldwide, demonstrating the global capacity to compute a PVT solution using authenticated navigation data.

In terms of accuracy, Figure 6 shows the difference at the 95th percentile between a Galileo I/NAV E1-E5b position with and without OSNMA from 12 Galileo experimental sensor stations (GESS) around the globe, with a 5º elevation angle, for two months (May 1 to June to 30, 2022). OSNMA affects positioning accuracy when tags are not received for all visible satellites, thus leading to the exclusion of the corresponding measurements from the PVT. However, the impact is minimal, mostly in the order of centimeters. 

In terms of time to first authenticated fix (TTFAF), OSNMA inherently introduces a delay as the receiver needs to wait at least 30s to receive the TESLA key. Figure 7 presents the time required to authenticate the navigation data from at least four satellites, based on OSNMA internal testing data and assuming OSNMA hot start as per [7], meaning the receiver has PK and K0. Different data retrieving strategies are analyzed: recombining the data on a sub-frame basis (red), or on a page basis (yellow), and with the possibility to further exploit the IODnav repetition (green). The figure shows an authentication time between 90s (static open sky) and approximately 120s (dynamic suburban). TTFAF optimizations are possible and under analysis, and further details can be found in [9].


Prospects and Applications

OSNMA SIS internal testing started in November 2020, but the specification was published in November 2021 through the OSNMA User ICD for the Test Phase and related receiver guidelines. After more than two years of SIS testing, OSNMA SIS ICD for the Initial Service and the related guidelines were published in December 2022 [6] [7]. This is an important publication defining the baseline applicable for OSNMA service provision. During mid 2023, the Galileo signal is planned to transition from the test ICD specification to the service one, although the OSNMA status flag will remain in ‘test’ mode. The initial service declaration is expected by the end of 2023, after which the OSNMA status will transition from ‘test’ to ‘operational.’ The first public key and associated cryptographic material for the OSNMA Initial Service will be published over the course of 2023, and a service definition document including minimum performance levels will be published for service declaration.

OSNMA can serve many applications, as described in [10], from consumer to professional, as all are sensitive to the threat of spoofing. It also supports EU policies, such as the Smart Tachograph regulation, which requires OSNMA. In terms of developments, already starting to amount to many, apart from Septentrio’s Test User Receiver- Navigation, other examples include Qascom’s first OSNMA prototype in the AALECS/CS Demonstrator project, the OSNMA-enabled NGene software receiver developed by LINKS [11], and OSNMALib, an open source Python library implementing OSNMA [12].

A recurrent question related to OSNMA and message authentication in general is: Can OSNMA by itself ensure the authenticity of the receiver position? The short answer is no, as this position depends on the navigation data and the measurements, and also the assurance that the receiver has not been tampered with. However, OSNMA cryptographic information makes the signal unpredictable, and therefore much more difficult to spoof, also protecting the ranging measurements. Receivers may also combine OSNMA with power, signal quality or consistency measures, or use future spreading code-authenticated signals, as those provided with GPS’s CHIMERA or Galileo, to be transmitted in the Galileo E6-C component, soon to be encrypted for this purpose. PNT applications also can use other radionavigation or timing systems as backups.

Table III


Galileo HAS provides orbit, clock and bias corrections enabling Precise Point Positioning (PPP) worldwide, for free. Initially, HAS was conceived to offer satellite bandwidth for commercial PPP providers for a fee, but in 2018 the European Commission’s top management decided to provide it for free as part of the Galileo services, given its potential societal benefits. Since then, Galileo has strived to define an optimal implementation of a PPP service with the existing architecture and signals. 

The HAS infrastructure is based on 14 monitoring sites, or GSS, as shown in Figure 1, with one site to be added soon (Wallis Island), and where each site includes two different GPS + Galileo receivers. More stations will be added in the following years, but in comparison with other PPP services, with 100+ stations, this is a very low number. In exchange, an advantage of HAS is that its infrastructure is used for other Galileo services and it is subject to stringent reliability requirements, compared e.g. to scientific networks. GPS and Galileo measurements are received at the High Accuracy Data Generator (HADG), currently located at the GSC, which generates the PPP corrections that are broadcast a few seconds later in the Galileo E6-B and through the internet in a State-Space Representation (SSR) format.

The HAS SIS message offers 448 bps per HAS-transmitting satellite, divided into a 24-bit header and a 424-bit HAS encoded page, as shown in Figure 8. HAS-transmitting satellites are in principle the same as OSNMA-transmitting satellites, i.e. those connected to the ground segment, and therefore currently up to 20, as for OSNMA and as per Figure 1, as a ground-to-satellite connection is required to transmit fresh corrections. Currently, two HAS messages are defined: A 17-page (7208-bit) ‘slow’ message with the satellite mask, orbit and code bias corrections, updated every 50 seconds, and a 2-page (848-bit) ‘fast’ message, with the clock corrections updated every 10 seconds, but the HAS SIS ICD allows for flexible update rates [13]. The same message is transmitted worldwide, and encoded through High-Parity Vertical Reed-Solomon (HPVRS), thanks to which both slow and fast messages can be received in a few seconds [14], as every page counts for decoding the message.

Clock corrections are currently provided for the ionosphere-free Galileo I/NAV E1-E5b and GPS L1C/A-L2P CNAV measurements, and code biases are provided for four Galileo frequencies (E1, E5a, E5b, E6-B), and two GPS frequencies (L1 C/A, L2P/C), allowing the use of uncombined measurements in the PPP solution. The HAS SIS ICD allows for carrier phase biases but are not provided yet operationally, although that’s expected soon. HAS gradual evolutions will include biases for more frequencies (at least Galileo E5 AltBOC and GPS L5), HAS message authentication, accuracy confidence bounds, and an ionospheric message in Europe.


An intensive HAS validation campaign has been carried out over the past months. In terms of corrections accuracy and availability, Table 1 presents the orbit, clock and code bias accuracy and availability for Galileo and GPS from September 1 to 5, 2022, considered as representative of the HAS validation phase. The table provides the values per day and their average. CNES products have been used as a reference for the orbits and clocks [15] and for the code biases [16]. 

RMS-1D is calculated as per Equation 6, where each RMS computes the errors in each component (N, T and W for radial, tangential and cross-track respectively) of the satellite position for all available satellites and epochs of the day.


For RMS-3D P95, the RMS of the instantaneous 3D error of all satellites every epoch is calculated, and the 95th percentile of this RMS for one day is shown. For the clocks, SIGMA provides the standard deviation of the 1-day error distribution. Then, for each constellation, the RMS of the instantaneous clock error of all satellites, subtracted from the average constellation error, is calculated every epoch, and the 95th percentile of a 1-day observation period is shown as RMS P95. The same process is followed for the code biases of each signal (according to the RINEX format definition [17]: C1C = E1-C (Galileo) and L1C/A (GPS), C5Q = E5a-Q, C7Q = E5b-Q, C6C = E6-C, C2P = L2P). Finally, the rightmost column contains the 5-day average. 

The availability of corrections is shown at the bottom of the table. It is computed as the percentage of time satellites with corrections available of each type (orbit, clock, bias), for GPS and Galileo, are passing through a 10ºx10º cell in a global grid, and then averaged for all cells.

The results show that RMS-1D or 1-SIGMA averaged errors are between 3.8 and 6.8 cm for Galileo and GPS orbits and clocks, which is quite remarkable for the current Galileo infrastructure. 95th percentile values are in the one-to-two-decimeter level for both orbits and clocks, and this takes into account the higher errors of less stable clocks, such as those from GPS IIR and IIRM blocks. The code biases show values higher than initially expected, also at the decimeter level but, as code biases are very stable, they are estimated together with other biases by the positioning algorithm and therefore do not significantly degrade positioning accuracy. Anyway, code bias estimation is being tuned so lower bias errors are expected soon. Further details about HAS performance can be found in [18].

In terms of user performance, the results presented here were obtained with a GMV Global station network [19] of open-sky receivers worldwide, as per Figure 9, and the GMV GSharp PPP solution. Table 2 shows user errors with Galileo (E1-E5a ionosphere-free) + GPS (L1C/A-L2C ionosphere-free combination) and a float ambiguity algorithm, without HAS phase biases and no IAR (integer ambiguity resolution). Further details are beyond the scope of this article, but the reader can refer to [20] for general PPP user algorithm theory.

The performance is generally better in Europe, as there are more monitoring stations, with very good 95th percentile values in horizontal and vertical accuracy. In other areas the performance is also good, e.g. in America, with usually below-dm error in horizontal components, although with some degradation with respect to the EU, which is higher in Asia due to the current lack of stations. Figure 10 shows the time series for Sept. 1, 2022, for the stations in Sweden and Namibia. 

Convergence time is a critical aspect of any PPP service nowadays. While it is sensitive to the number of frequencies used and receiver algorithm, and it is currently under study, recent work shows dual frequency convergence time below 300s, 95%, with two frequencies, under the conditions defined in [21].

Finally, another HAS feature worth mentioning is satellite fault detection: giving the short latency and update rate of the ‘fast’ message with the clock corrections, satellite faults can be detected and flagged within seconds, as shown in [22], which describes a satellite E01 clock runoff in September 2021 corrected by HAS just before flagging the satellite as not available. While there is no HAS fault detection commitment at the moment, this feature can be exploited at the users’ convenience in combination with receiver autonomous integrity monitoring (RAIM) or other methods.

The HAS Declaration 

Based on these and other results, notably the exhaustive validation campaign performed over the last months, a High Accuracy Service (HAS) service definition document (SDD) accompanied the HAS initial service declaration (ISD) presenting minimum performance levels, which took place on January 24, with some margins with respect to the results reported here. At the time of ISD, the HAS status in the signal transitioned from ‘test’ to ‘operational’ mode. Over the next few years, the service performance is expected to improve, until reaching its full capability, which will include a commitment to horizontal/vertical user accuracy of 20/40cm 95% and a convergence time below 300s, reduced to 100s in Europe thanks to the ionospheric corrections message, as per Table 3. Note the E6-C pilot tone accompanying the E6-B data component will be encrypted to provide spreading code authentication. An open pilot signal in that carrier is expected as part of the Galileo 2nd Generation signal plan. 

In terms of applications, the possible use cases for HAS are innumerable. While HAS will coexist with other global and regional services, including commercial, payable applications providing already sub-cm level, Galileo HAS is the only service transmitting openly and worldwide PPP corrections from space. This may create new value chains or provide redundancy to existing services. HAS will also provide coverage where there is no ground or satellite communication possible, which, as of today, still represents the majority of the Earth surface, and beyond, including air and space users. 


Galileo provides a message authentication mechanism in its open service E1 signal, OSNMA, and high accuracy corrections through HAS in the E6-B signal component and through the internet. The HAS initial service declaration will be followed by the OSNMA initial service declaration, which is expected by the end of the year. Both OSNMA and HAS are already transmitted by Galileo globally and with very good accuracy and availability. 

Galileo will gradually complete its service offering with the authentication of the HAS message itself, spreading code authentication, and further information such as precise ionospheric corrections and confidence bounds. We also expect HAS and OSNMA, together with other receiver improvements, will become gradually more integrated into the consumer and professional ecosystem, facilitating positioning, navigation and timing applications to “get to the truth,” or at least closer to it. 


The results shown in this article are based on multiple cooperative activities by the EC, EUSPA and ESA, with support from several industrial contracts, in particular by Airbus Defence and Space (ADS) for OSNMA validation and by Thales Alenia Space Italy (TAS-IT) and GMV for HAS validation. This article also summarizes results already presented in papers at ION ITM 2022 and ION GNSS+ 2022, as referred to in the additional resources. The authors would like to acknowledge the work performed by all Galileo teams involved supporting OSNMA and HAS.


[1] I. Fernandez-Hernandez, I. Rodríguez, G. Tobías, J. D. Calle, E. Carbonell, G. Seco-Granados, J.
Simón and R. Blasi, “Testing GNSS High Accuracy and Authentication – Galileo’s Commercial
Service,” Inside GNSS, pp. 37-48, Jan-Feb 2015.
[2] EUSPA, “European GNSS Service Centre,” [Online]. Available: https://www.gsc- [Accessed 12 2022].
[3] C. O’Driscoll, “What is navigation message authentication,” InsideGNSS, vol. 1, 2018.
[4] ISO, “International Standards Organisation – ISO/IEC 29192-7: IT Security Techniques – Lightweight
Cryptography – Part 7: Broadcast Authentication Protocols,” 2018.
[5] S. Damy, L. Cucchi and M. Paonni, “Performance Assessment of Galileo OSNMA Data Retrieval
Strategies,” in Proceedings of the NAVITEC 2022 conference, NL, 5-7 April 2022.
[6] European Union, “Galileo Open Service Navigation Message Authentication (OSNMA) Signal-In-
Space Interface Control Document (SIS ICD), Issue 1.0,” EUSPA, December 2022.
[7] European Union, “Galileo Open Service Navigation Message Authentication (OSNMA) – Receiver
Guidelines, Issue 1.0,” EUSPA, December 2022.
[8] EUSPA, “Programme Reference Documents: OSNMA,” [Online]. Available: https://www.gsc-
[9] S. Damy, L. Cucchi and M. Paonni, “Impact of OSNMA Configurations, Operations and User’s
Strategies on Receiver Performances,” in Proceedings of the 35th International Technical Meeting
of the Satellite Division of The Institute of Navigation (ION GNSS+ 2022), Denver, CO, 2022.
[10] EUSPA, “Galileo OSNMA Info Note,” EUSPA –
authentication-osnma-info-note-now-available, 2021.
[11] M. Troglia Gamba, M. Nicola and B. Motella, “Computational Load Analysis of a Galileo OSNMA-
Ready Receiver for ARM-Based Embedded Platforms,” Sensors , vol. 2, no. 467, 2021 .
[12] A. Galan, I. Fernandez-Hernandez, L. Cucchi and G. Seco-Granados, “OSNMAlib: An Open Python
Library for Galileo OSNMA,” in 2022 10th Workshop on Satellite Navigation Technology (NAVITEC)
IEEE., NL, 2022.
[13] European Union, “Galileo High Accuracy Service Signal-In-Space Interface Control Document (HAS
SIS ICD) issue 1.0,” EUSPA, May 2022.
[14] D. Borio, T. Senni and I. Fernandez-Hernandez, “Galileo’s High Accuracy Service: Field
Experimentation of Data Dissemination Schemes,” InsideGNSS, 2020.

[15] NASA, “CDDIS – NASA’s Archive of Space Geodesy Data,” [Online]. Available: . [Accessed 2022].
[16] CNES, “PPP Wizard,” [Online]. Available:
. [Accessed 2022].
[17] I. Romero(ed), “RINEX – The Receiver Independent Exchange Format – Version 4.00,” 2021.
[Online]. Available:
[18] I. Fernandez-Hernandez, A. Chamorro-Moreno, P. Zoccarato, D. Blonski, T. Senni, F. J. d. Blas, C.
Hernández, J. Simón and A. Mozo, “Galileo High Accuracy Service: Initial Definition and
Performance,” GPS Solutions, p. 26 (65), 2022.
[19] GMV, “Global GNSS network data,” [Online]. Available: [Accessed 2022].
[20] J. Kouba and P. Héroux, “Precise point positioning using IGS orbit and clock products,” GPS
solutions, vol. 5, no. 2, pp. 12-28, 2001.
[21] P. Pintor, E. González, A. Senado, P. Bohlig, A. Sperl, P. Henkel, J. Simón, C. Hernández, J. de Blas
and J. Vázquez, “Galileo High Accuracy Service (HAS) Algorithm and Receiver Development and
Testing,” in Proceedings of the 35th International Technical Meeting of the Satellite Division of The
Institute of Navigation (ION GNSS+ 2022), Denver, Colorado, September 2022, pp. 836-851, 2022.
[22] I. Martini, M. Susi, M. Paonni, M. Sgammini and I. Fernandez-Hernandez, “Satellite Anomaly
Detection with PPP Corrections: A Case Study with Galileo’s High Accuracy Service,” in ION
ITM/PTTI 2022, 2022.
[23] CNES, “CNES/CLS Analysis Center for IGS – products,” [Online]. Available: https://igsac- [Accessed April 2021].


Ignacio Fernandez-Hernandez is responsible for Galileo high accuracy and authentication services at the EC, DG DEFIS, where he has led the design and development of OSNMA and HAS. He is an electronics engineer by ICAI (Madrid) and holds a Ph.D. from Aalborg University.

Sophie Damy is a scientific project officer within the European Commission’s Joint Research Centre (JRC). Her current work focuses on Galileo authentication services, in particular OSNMA. She received an M.Sc from ENAC (France) and a Ph.D. from Imperial College London (UK).

Simón Cancela-Diaz holds an MSc in Advanced Mathematics from the Universidad Complutense de Madrid. He joined GMV in 2015 and has been involved in projects related to the design and development of GNSS authentication, anti-spoofing algorithms and high accuracy positioning.

Adrián Chamorro-Moreno holds an MSc in Space Systems Engineering from the Technical University of Madrid. He joined GMV in 2017 and has been involved in high accuracy projects and algorithms for safe and accurate autonomous driving.

J. David Calle-Calle holds an MSc in computer engineering from the University of Salamanca. He is head of GNSS Services Section at GMV, coordinating the activities related to Galileo services and automotive applications.

Melania Susi holds a Ph.D. from the University of Nottingham where she was a Marie Curie fellow. Currently, she works at the Joint Research Centre of the European Commission in Galileo high accuracy, among other activities.

Dr. Ilaria Martini received a master’s degree in telecommunication engineering and a Ph.D. in information technology from the University of Florence, Italy. She currently is advisor of the European Commission on GNSS, including ARAIM, EGNOS and high accuracy.

Dr. Jón Ó. Winkel is currently an advisor to the EC on GNSS, focusing on authentication services. He received a Diploma in Physics from the University in Hamburg and a Ph.D. from the university FAF Munich. He has over 25 years of experience in GNSS.

F. Javier de Blas holds an MSc in Aeronautical Engineering and in Airport Systems from the Technical University of Madrid (UPM). He has more than 16 years of experience in the aerospace industry. He works at EUSPA as Galileo Commercial and High Accuracy Service Manager.

Javier Simón is OSNMA service manager at EUSPA. He holds an MSc degree in telecommunications engineering from the Polytechnic University of Madrid, Spain.

Daniel Blonski is a Navigation System Performance Engineer at ESTEC, ESA, where he is contributing to the development of the European Navigation Systems as a member of the ESA Directorate of Navigation.

David Ibanez Izquierdo is head of the Galileo G1 System Engineering Unit at ESA. He graduated in telecommunication engineering from the Polytechnic University of Madrid and has more than 20 years of expertise in space systems engineering.