Galileo Up-Link Station (ULS) on Svalbard (Norway) showing the two uplink antennas, protected by a radome each. (ESA photo)
Galileo’s Commercial Service
Testing GNSS High Accuracy and Authentication
In the near future, the Galileo program will decide on the design and implementation of a Commercial Service for civil applications that provides high-accuracy positioning and signal authentication. A team of authors involved in the program describes the evolution of this service, its current design, and the results of tests of its capabilities using actual signals in space.
After some years of concept studies and simulations, the Galileo Commercial Service is taking off. The journey has started toward what can be the most accurate and secure worldwide satellite-based navigation services for civil use.
Employing only GNSS signals, authenticated position fixes accurate to the decimeter level were achieved for the first time in the summer of 2014. Future prospects are for even better results. Although the journey is exciting, many challenges still lay ahead. This article presents the work accomplished thus far on the development of the Commercial Service and the first results of the Authentic and Accurate Location Experimentation with the Commercial Service (AALECS) project with real Galileo signals.
Galileo and the Commercial Service
This approach helped the EU Member States to make the important decision for Europe to develop its own satellite-based navigation system. However, the “added-value” services that Galileo could offer, on top of the ubiquitous, free, and already excellently performing GPS — especially after the removal of that system’s civil accuracy–degrading Selective Availability feature in 2000 — remained unclear.
Perhaps the lack of a clear return on investment ultimately deterred prospective industrial concessionaires from accepting the risk of building Galileo with their own resources. After years of negotiations, the concession-based approach was discarded in the late 2000s, in favor of a fully EU-funded program. At that time, priorities were shifted to those services considered to be more critical for public or governmental uses, such as the PRS, the Open Service (OS), and the Safety-Of-Life (SOL) and Search-And-Rescue (SAR) services.
The evolving Galileo regulation that guided program development still mandated the existence of a commercial service with “improved performance and data with greater added value” than the other services. However, that “added value” was not concretized in any mission or system requirement, and the program budget was already fully allocated to other priorities. Early definition tasks identified high accuracy (HA) and authentication as the two most promising services, but it was not clear if and how the services could be provided, what their performance would be, and how they would be implemented and operated.
The re-profiling of the Galileo SOL in the early 2010s was an important event for the Galileo CS. SOL had been a major factor in defining the Galileo ground infrastructure and signal structure. Its original mission was to provide a worldwide integrity service, satisfying the stringent requirements of aviation communities, among others.
For several reasons, the Galileo program decided to re-profile the SOL into a lighter service, currently being defined, which will provide integrity in likely cooperation with other regions. Therefore, some Galileo features designed to provide the SOL service became available for other purposes. These features include:
A Broader Scope
With these objectives in mind, by early 2013, two parallel studies were launched to define the Commercial Service and its implementation in Galileo. The main premise for the studies was to offer the maximum value with the minimum modifications, if any, to the Galileo core infrastructure. This means no or minimal modifications to the Galileo ground infrastructure and the satellite on-board software, and no modifications at all to the satellite hardware, which implies that the current Galileo CS signal definition needs to be maintained.
The Galileo CS Signals
The signals are modulated with a binary phase shift keying BPSK(5) at a carrier frequency of 1278.75 MHz, which is used by all satellites and shared through a code division multiple access (CDMA) RF channel access method. Therefore, the signal main lobe and most of the signal power is in the 1273.75-1283.75 MHz band. Figure 1 (see inset photo, above right) shows the CS and other signals from all satellite-based navigation systems operating in the same band.
Both E6-B and E6-C signals are modulated on the in-phase component, leaving the quadrature component to the E6-A signal, used in conjunction with the E1-A for the Public Regulated Service. Table 1 (see inset photo, above right) summarizes the main properties of the E6-B and E6-C signal components.
A relevant feature of the CS signal is that the primary spreading codes of both components can be either encrypted or in the clear when transmitted. When encrypted, the spreading codes are replaced by an unpredictable bit-stream generated through a secret key, making the signal indistinguishable from noise for unauthorized receivers.
One of the challenges for the Galileo CS is that it will have to share the RF spectrum with other users. The 1240–1300 MHz band is currently used by several applications, and ensuring compatibility with some of them, such as aeronautical and land military radars or the amateur radio community, may require coordination and interference mitigation in the vicinity of these systems’ ground-based transmitters.
In addition to those applications, the E6 band is also used by the space research and satellite-based Earth exploration communities. Early CS tests involving real signals have shown satisfactory performance when no interferers are around but have suffered interference effects in the vicinities of transmitters.
The European Commission (EC) is pursuing actions to facilitate the use of the E6 for satellite-based radionavigation to the widest extent, and discussions with telecom regulators and user communities will continue over the next few years, in parallel with the experimentation of the services that Galileo CS aims to offer: high accuracy and authentication.
PPP is based on the use of accurate GNSS satellite orbits and clock data to estimate a user position based on carrier phase measurements, where the ionospheric delay is typically removed by performing the iono-free combination. The main disadvantage of PPP is the time needed to converge to a centimeter-level accuracy, which currently takes about 15–30 minutes to achieve, while RTK is almost instantaneous. The most common and optimized technique in terms of bandwidth for real-time PPP is to send orbits and clock corrections to the navigation message, allowing the reconstruction of the accurate values in the receiver.
The Galileo E6-B channel is well suited to transmit PPP information. Various analyses have shown that the available rate of 448 bps per satellite allows the transmission of satellite orbits and clock data at an adequate update rate to provide accuracy at the centimeter level. (See Table 2 (inset photo, above right).)
The data update rate is especially relevant for satellite clock corrections, which are not as stable in the medium and long term as the orbits. In order to obtain the highest accuracy, corrections must be updated every few seconds, especially for the satellites with less stable clocks.
Figure 2, generated for GALCS (“Galileo Commercial Service definition”), one of the two parallel studies mentioned previously, shows the evolution of the 3D position error and the corresponding root mean square (RMS) for a static GNSS receiver after convergence on a position solution. The reference products were computed by means of a network of 50 worldwide GPS and GLONASS stations. The corrections used below 400 bps, which is compatible with the CS.
The panel on the left of Figure 2 shows the PPP positioning error with a 5-second clock update rate, while the panel on the right shows the error with a 30-second clock update rate. The system latency was configured to 5 seconds, understanding latency as the time between when the system processes the satellite measurements and when corrections based on these measurements are transmitted.
Both latency and clock update rates contribute to the age of data of the clock corrections applied at a given time, which have an impact on the PPP accuracy. As the CS allows for the transmission of different bits from different satellites, the total bandwidth can be highly increased leading to a better performance that, when combined with other factors may reduce the PPP receiver convergence time.
Spreading Code Encryption
In addition to other technical and regulatory measures, features in the GNSS signals allowing authentication are undoubtedly a major building block of location security. GNSS authentication is different from information authentication, as its objective is not only to authenticate the information encoded in the signal but also to authenticate the signal time of arrival, at least against certain threats and with a certain confidence level. Both factors are required for a trustworthy position and time estimation.
With this in mind, Galileo is a good candidate to offer authentication services to civil communities for two main reasons. The first is that Galileo E6-B and E6-C signal spreading codes can be encrypted, which provides spreading code authentication for receivers (or server-receiver architectures) having the encryption keys. Also, the fact that the keys are not used for military purposes implies that they can be shared under certain conditions with certain users, providing additional flexibility. The second reason is that the available bandwidth in both E6-B and E1-B Galileo signals permits the transmission of authentication and re-keying data while guaranteeing full backward-compatibility.
Navigation Message Authentication
Some work already performed shows that Galileo can achieve very good performance, including the possibility to authenticate the navigation messages of other constellations. (For further discussion of this point, see the article by I. Fernández-Hernández et alia (2014a) listed in the Additional Resource section near the end of this article.)
Putting It All Together
Conceptually, the provision by Galileo of different authentication services (PRS, CS, OS) seems coherent with general security principles, whereby the level of security is commensurate with the criticality of the assets to protect.
Galileo CS Architecture
Figure 3 shows the CS data transmission process, which consists of the following steps:
This scheme not only allows transmission of CS data in the E6-B but also transmission of data in the E1 I/NAV “Reserved 1” field as per the OS SIS ICD.
The AALECS Project: Three Steps Ahead
The project, carried out by a consortium composed of GMV, CGI, Qascom, IfEN, KUL, and Veripos, will run until 2016 and is composed of three phases. Firstly, it has developed an early proof-of-concept (EPOC) platform for initial testing, the results of which will be reported later in this article. Secondly, the AALECS project is developing a distributed platform across Europe to transmit and receive real-time CS data through the Galileo satellites. The platform is composed by four receivers located in UK, Italy, Germany and Spain, as well as two core platforms in Spain and Italy, as shown in Figure 4.
In addition, the platform will integrate EC Joint Research Center’s simulation capabilities. Finally, in its last phase, AALECS will support potential external providers to test their applications and solutions with Galileo.
The EPOC: AALECS’s First Step
As shown in Figure 5, the EPOC platform is composed of three independent hardware and software items: the CS Receiver, the receiver platform (RXP) host and the EPOC-host. The CS receiver is a modified multi-frequency commercial receiver capable of performing E6 ranging with and without spreading code encryption (SCE) and can decode data from the E6-B channel.
The RXP-host commands the CS receiver and includes the authentication and position/velocity/time (PVT) software modules that process the received CS data together with the observations gathered from Galileo and GPS satellites. The EPOC-host generates the authenticated high-accuracy data to be broadcast in the E6 signal. It also includes the historical archive, where the generated and received data is stored, and a software tool that analyzes the received data.
Each EPOC test consists of the following steps:
In addition to the foregoing, for tests with SCE enabled, the EPOC operator needs to install the NAVSEC key (i.e., the key used to encrypt the E6-B/C components) in the receiver, to enable decryption of the spreading code.
Generating High Accuracy and Authentication Data
The current format allows for 8 HA sections every 5 seconds, for a total of 48 HA sections every 30 seconds. All Galileo satellites synchronously transmit the same 30-second sequence of authenticated HA data for 32 GPS + 3 Galileo satellites. The remaining HA sections are left empty.
Data obtained from the International GNSS Service (IGS) Multi-GNSS Experiment (MGEX) station network feeds the software tool set in order to generate the satellite ephemerides and clock products. One of the major limitations of the EPOC compared with a future operational CS is the data latency: Satellite orbit and clock predictions had to be generated and transmitted to the Galileo operator about two days in advance of the planned test; therefore, the age of the predicted products — and associated decorrelation of real-time and predicted data — limited EPOC’s achievable PVT performance.
The authentication solution used for the EPOC is an adaptation of the Timed-Efficient Stream Loss-tolerant Authentication (TESLA) algorithm described in the article by A. Perrig et alia listed in the Additional Resources section near the end of this article. TESLA seems more bandwidth-efficient compared to other solutions, such as standard digital signatures.
The proposed TESLA implementation is based on a single one-way chain of 256-bit keys for data authentication. An initial random seed key (Kn) generates this chain by performing a given number of hashes using the SHA-256 algorithm. The key-chain is generated from Kn to K0, but keys are disclosed to the user from K0 (certified as correct through non-SIS means in this implementation) to Kn, as shown in Figure 7.
This approach enables the user to recover an old key from a recently disclosed one, while insuring that future keys cannot be inferred from disclosed ones. As shown in Figure 6, out of five seconds of the data message, four are devoted to authenticated HA data and one to the authentication key, plus a bit pattern to differentiate key pages from HA pages, and a message authentication code (MAC) of the preceding HA packet (HAP) authenticated with a key delivered 30 seconds later. This MAC is intended to resist data spoofing attacks to receivers with very inaccurate clocks using already disclosed keys, and is called “Long Term Authentication” by the EPOC developers (as opposed to “Short Term Authentication,” which refers to all other cases).
The keys are used to authenticate the HA 160-bit data through a hash-based MAC (HMAC) function truncated to 64 bits. The receiver can then verify the authenticity of the HA data by comparing the MAC generated from the HA data and the later disclosed key, with the previously received MAC.
In the Additional Resources section, further details on the authentication solution implemented in the EPOC can be found in the article by D. Calle et alia, and additional details about TESLA-based implementations for satellite-based navigation in the articles by C. Wullems et alia, S. Lo and P. Enge, and J. T. Curran et alia.
We must emphasize that this message structure and data definition have been implemented for testing purposes only and are not bandwidth-optimized, neither for high accuracy nor for authentication. We must also highlight the fact that future HA and authentication services are expected to be provided separately, although they may be combined in the receiver.
Test slots were predicted that would guarantee the best visibility of the three available Galileo in-orbit validation (IOV) satellites over GMV’s premises in Madrid. Based on these predictions and other operational constraints, six-hour slots were allocated to the EPOC SIS tests on a weekly basis.
The test campaign began on June 12 and finished on September 30, 2014, with the following main outcomes:
The following sections describe the results obtained in terms of data transmission, authentication, and high accuracy. We will analyze the test performed on July 22 in detail as it illustrates the results obtained under nominal conditions in most of the other tests.
Data Transmission Results
As expected, some tracking losses were observed at the end of the satellite pass, principally when satellites were at a 5/7-degree elevation. A few other tracking losses were observed due to receiver or environmental issues, but overall the page-loss ratio was below 0.5 percent.
Other tests confirmed this good data transmission performance and also showed that SCE and decryption at the receiver are correctly implemented.
These results demonstrate that a seamless synchronization was achieved during almost all of the several hours of tests. This feature is very important not only for the HA data transmission but also for the TESLA-based authentication requirements, which require fully synchronized messages. In summary, the field testing has demonstrated the correct transmission of external data through the E6 signal. Given that the Galileo system is still under deployment and the performance is expected to improve, we consider the data transmission results to be very good.
TBA is five seconds without SCE and zero seconds with SCE, as the receiver can navigate with previously authenticated data and continuously re-authenticated spreading codes. TTFAF is around 30 seconds (the time to receive from E6 all the HA data, excluding the time for a PPP algorithm to converge and the potential need to extrapolate from two XYZ given satellite datasets). As regards AER, it is calculated as follows:
AER + 1 − (1 − BER)NNA 
where BER is the bit error rate, calculated according to the method described in the book by E. Kaplan and C. Hegarty (see Additional Resources), and NNA is the number of bits for navigation and authentication, which for a given authentication verification are 480 bits (160 + 64 + 256), as per Figure 6. Figure 9 characterizes AER versus the carrier-to-noise power spectral density ratio (C/N0) analytically for an additive white Gaussian noise (AWGN) channel.
By way of example, Figure 10 shows the actual (short-term) AER versus C/N0 results from the July 22 test for E11, E12, and E19. AER was measured every 30 seconds, i.e., it was the percentage of failed data authentications per satellite every 30 seconds out of the total expected authentications. Some spikes observed for E12 and E19 at around 19:40 UTC are related to the previously mentioned uplink transition.
Some smaller spikes observed for E19 between 21:30 UTC and 22:00 UTC are related to the aforementioned data file de-synchronization. This latter event affected TESLA synchronization leading to failed authentications. All other AER spikes are related to C/N0 drops. The figures show that, at a C/N0 below 40 dBHz, AER starts to increase. Further analyses are ongoing to understand the discrepancy with respect to the theoretical values, and C/N0 higher than expected, which seem due to a C/N0 overestimation in the receiver.
All in all, these valuable results show how asymmetric authentication can work in a real satellite navigation system. They also confirm the feasibility of data authentication through Galileo, which can be extremely valuable in thinking of future data-based and even spreading-code–based open authentication services for future Galileo generations. One could, for example, foresee a scheme whereby spreading codes are water-marked with a TESLA key and transmitted some time before the key is disclosed.
High Accuracy Results
The performances are remarkably good given the age of corrections and show accuracies on the order of decimeters. So, the CS performance appears promising, especially taking into account that the target data latency for Galileo is on the order of seconds rather than days.
Figure 12 shows the authenticated high-accuracy performance on September 17 during a kinematic test, including open-sky and deep urban environments, as well as around GMV’s premises in Tres Cantos, Madrid. Figure 13 shows the trajectory followed.
For this test, HA data was transmitted 15 hours after its generation. The solution remains stable after the convergence period (due to good modeling of satellite clock behavior) and is only destabilized when the environmental conditions go beyond a certain level of severity. The first signs of instability are seen at 16:25 UTC, and then the position solution is definitely destabilized by 16:35 UTC.
Although the accuracy results are not as good as in other cases, due to a higher error in the clock predictions for this particular test, they are still very good and — to the knowledge of the authors — better than the accuracy provided to date by the navigation message of any global navigation system. (Note that the user error includes not only the orbital and clock error but also propagation and receiver effects.) We should also point out that, even under harsh urban conditions, the AER of E12, the only satellite visible, remained very low, leading to almost no degradation of the authenticated versus non-authenticated performance, as shown in Figure 14.
These results, we conclude, demonstrate the feasibility of obtaining high accuracy from the Galileo Commercial Service, even with the substantial latency imposed by the test design. When this latency is reduced, we expect the achievable performance can be much higher — down to the centimeter-level error of state-of-the-art, high-accuracy services.
Conclusions and Next Steps
Galileo, through the Commercial Service, presents relevant differentiators with respect to other systems, such as an external data transmission channel and spreading code–encrypted signals for purely civil purposes. These capabilities, even if limited for the time being, have demonstrated accurate positioning and authentication, as shown in detail for the first time in this article. The test results are remarkable, considering that an accuracy at the decimeter level has been achieved by a standalone receiver with two-day-old orbit and clock predictions. Further, data and code authentication schemes over civil GNSS signals have been tested for the first time, to the knowledge of the authors.
In the years to come, Galileo has a great opportunity to deliver highly accurate and robust services worldwide. In spite of the many challenges ahead, the authors believe that the Galileo program will be capable of turning the test results of today into the operational services of tomorrow for the benefit of industries and citizens.
ManufacturersThe EPOC test set up used magicGNSS from GMV, Tres Cantos, Madrid, Spain, to generate satellite orbit and clock predictions, and a NAVX-NTR receiver from IFEN GmbH, Poing, Germany. The map data in Figure 13 came from Google Inc., Mountain View, California USA; CNES/Spot, Toulouse, France; Digital Globe, Longmont, Colorado; and Terrametrics, Inc., Littleton, Colorado, USA.
Copyright © 2017 Gibbons Media & Research LLC, all rights reserved.