Enhancing GNSS Situational Awareness by Monitoring the New Galileo Services ^†

Abstract

Global Navigation Satellite Systems (GNSSs) have become a critical service in modern society, and this has increased the need for GNSS situational awareness. On top of this, the GNSS field is rapidly changing. Increased signal interference has been observed in the last few decades, requiring more prominent GNSS services, in addition to flexibility and adaptability from GNSS monitoring systems. With the emergence of new Galileo features, such as Open Service Navigation Message Authentication (OSNMA) and the High Accuracy Service (HAS), monitoring systems have the opportunity to leverage these new services to enhance GNSS situational awareness. The Finnish Geospatial Research Institute (FGI) has developed an open GNSS situational awareness service called GNSS-Finland, which monitors signal quality, detects potential interference, and informs users of the expected level of performance of different services around 47 stations in the Finnish Continuously Operating Reference Station (CORS) network (FinnRef). Recently GNSS-Finland’s capabilities have been extended to monitor and leverage OSNMA and the HAS around FinnRef stations. Due to the novelty of both OSNMA and the HAS, custom software solutions are needed to integrate these services into GNSS-Finland. We give an overview of GNSS-Finland and its flexible architecture, present the integration of the new Galileo services into GNSS-Finland, and finally discuss how these new services can be leveraged from a monitoring system point of view.

1. Introduction

The positioning, navigation, and timing (PNT) information that global navigation satellite system (GNSS) signals provide has become vital in many applications, and with this, the need to monitor signal and service quality has increased. GNSS signals are of interest to many different end users, who have different performance requirements and consequently use different performance indicators. Some users, such as land surveyors, are interested in the positioning accuracy. It might not make a difference to them whether a failure to meet some accuracy requirements is due to intentional or natural interference. On the other hand, knowing the exact reason for the interference is paramount for other users, especially in safety-critical applications such as aviation or maritime navigation. Overall, there are a variety of quality indicators to use and large areas to cover. All of this highlights the need for GNSS situational awareness services and serves as motivation for the further development of GNSS-Finland.

Naturally, satellite service providers, like the U.S. Department of Defense for the Global Positioning System (GPS) and the European Space Agency (ESA) for Galileo, monitor their services through ground stations. However, the provided information is related to the overall service operation. Most local effects, therefore, cannot be observed based on this data. For example, a land surveyor may not be directly interested in the Galileo or GPS system’s status, but rather they are interested in the available positioning accuracy and signal conditions at the specific location where they intend to perform measurements. A dense network of monitoring stations is needed to satisfy all of the users’ needs. These types of GNSS monitoring systems have already existed for quite some time [1,2,3], and, over time, their requirements and importance have increased.

In this paper, we provide an overview of the GNSS-Finland service and present the software implementation used to monitor the new Galileo services. Specifically, the paper proceeds as follows. In Section 2 we introduce GNSS-Finland and discuss its data sources and software architecture. In Section 3 we give a basic overview of the new Galileo services and discuss how their monitoring is implemented in GNSS-Finland. Finally in Section 4 we conclude the paper.

2. GNSS-Finland

In this section, we present the GNSS-Finland service, particularly considering its requirements, data sources, and software architecture.

2.1. Overview

GNSS-Finland is a GNSS situational awareness service developed by the Finnish Geospatial Research Institute (FGI). To be more precise, the goal is to monitor continuously and in real time the various aspects of GNSS signals that are of interest to end users. These monitored aspects include the positioning accuracy; signal quality, such as the carrier-to-noise ratio; satellite visibility; real-time kinematic and Galileo High Accuracy Service (HAS) corrections; and the Open Service Navigation Message Authentication (OSNMA) authentication status of Galileo satellites. An example of signal quality monitoring by GNSS-Finland. GNSS-Finland monitors this information from various constellations, such as the GPS, Galileo, GLONASS, and BeiDou, and from various signals. In addition to this, the detection of intentional interference, such as GNSS jamming or spoofing, is an important goal of GNSS-Finland.

The GNSS sector has evolved drastically over time. New services and features have been introduced, and unfortunately the presence of intentional interference has become more common [4]. As GNSS services and interference events keep evolving, a monitoring service should be able to accommodate this flexibly. As such, the requirements of GNSS-Finland or any other GNSS monitoring service are quite demanding. What make these requirements even more demanding is the fact that data quality monitoring is usually not performed at just one station, but instead across a network of dozens or even hundreds of stations. Therefore to achieve these goals network-wide, careful consideration needs to be given to the software, algorithms, and hardware used. The implementation and feasibility of this type of system was discussed in [5]. The next section discuss these aspects in relation to GNSS-Finland that can be seen in Figure 1.

2.2. Data

GNSS-Finland receives most of its GNSS data through Networked Transport of RTCM via Internet Protocol (NTRIP). Accommodating new NTRIP data sources is as simple as adding the NTRIP server information to a configuration file. As NTRIP is a widely used protocol in the GNSS community and many receivers can function as an NTRIP server out of the box, this makes GNSS-Finland capable of monitoring almost any receiver. In general GNSS-Finland has relatively few requirements for receivers; however, the features of the receiver can somewhat set the limits of what can be monitored. For example, monitoring multiple constellations and signals will naturally require support from both the receiver and antenna sides. And while the core processing is reliant only on NTRIP, some of the more advanced processing, such as processing related to the HAS and OSNMA, also requires access to the raw navigation data pages. This data is not available from all receivers, and different manufacturers have different interfaces for accessing this data.

Today the production version of GNSS-Finland monitors 47 of the national Finnish GNSS reference network, FinnRef, stations. These FinnRef stations and their statuses are visible in the GNSS-Finland main map view, as seen in Figure 2. These stations have high-quality, survey-grade receivers, but the exact model in each station varies, again highlighting that the system is not tied to any particular receiver or manufacturer. However, as already mentioned, monitoring stations can be added easily, and a variety of different receivers of different quality levels have been used as temporary monitoring stations in the internal version of GNSS-Finland.

In general, there can be advantages in utilizing both low-cost and higher-grade receivers. When higher-grade receivers and antennas are used, any results (whether related to the positioning accuracy or signal quality) are less likely to be due to the hardware. On the other hand, it is much cheaper to deploy a dense monitoring network when low-cost receivers are utilized. If the interest is in detecting highly anomalous situations, such as jamming or spoofing, low-cost receivers are likely sufficient, and having a denser receiver network is likely more valuable than focusing on the quality of the individual receivers.

2.3. Software Architecture

GNSS-Finland has a highly decoupled and modular software architecture, as seen in Figure 3. The decoupled nature of the architecture has multiple benefits, such as the following:

• Scaling: The different modules of the architecture do not need to be hosted on the same computer/server, and the different pieces can also be duplicated as needed. This enables the service to be scaled up almost indefinitely; what is more, the different pieces can be hosted in appropriate environments. For example, certain pieces may benefit from a higher-performance central processing unit (CPU), and certain analysis modules may even benefit from having access to a graphics processing unit (GPU), while many parts of the software require only modest computational resources.
• Extension: Adding new modules is relatively straightforward. Modules can be developed without giving almost any thought to the rest of GNSS-Finland. The module only needs to handle the data input and output, or rather the data subscription and publishing, through the data distribution service (DDS). If the result is to be visualized in the web front-end, then such a component should be added, but most standard visualizations are simple to add.
• Deployment: The decoupled nature caters to some well-known frameworks, such as Docker or Kubernetes. While using such frameworks is not a requirement, it can make the deployment and management of the system somewhat simpler.

In general, most of the communication between different components goes through the DDS. The DDS is based on a publisher/subscriber pattern, which is implemented using the ZeroC Ice and IceStorm libraries. In particular, the NTRIP data source module will publish the RTCM messages from the stations to the DDS. Correspondingly the analysis modules may subscribe to this information and further publish their results. It is worth noting that the Ice framework supports data serialization, deserialization, and transport in multiple different programming languages. In particular, this means that components written in different programming languages can communicate through Ice, and by extension through the GNSS-Finland DDS. The data are stored in a PostgreSQL database, and the data can be retrieved using a REST-API. The user can view visualizations and reports through the web front-end, which is implemented using the JavaScript React library.

3. Monitoring the New Galileo Services

The Galileo constellation has recently introduced two new services: the HAS and OSNMA. Both are them are open services and offer all users novel and concrete benefits.

However, due to the novelty of both OSNMA and the HAS, custom software solutions are needed to monitor these services. This will be discussed more in the following subsections. In the future it is likely that more receivers will support these services natively, therefore reducing the need for custom solutions. However, even when OSNMA and the HAS become widely supported by receivers, the currently used software framework has the advantages of flexibility and the ability to perform in-depth investigations, and it is less restrictive in terms of the receiver choice. The high-level architecture and data flow of the new Galileo service components is highlighted in Figure 4.

3.1. Open Service Navigation Message Authentication

The Galileo OSNMA is the first service to offer navigation message authentication to the civilian sector. Navigation message authentication can be used to improve spoofing detection [6,7] or to perform authenticated positioning (i.e., positioning based on cryptographically verified data) [8].

The basic principles of OSNMA are as follows, though full information can be found in the interface control document (ICD) [9]. The Timed Efficient Stream Loss-Tolerant Authentication (TESLA) protocol [10] is used to distribute cryptographic keys, which are used to essentially sign the navigation messages. The keys are distributed with a 30s delay compared to the signatures, or tags as they are called in OSNMA. Moreover, the keys form a so-called hash chain. This means that the keys are generated by iterating a cryptographic hash function on a seed value, but the keys will be transmitted in reverse order with respect to the order of their generation. Consequently, it follows that to verify a key, the user simply needs to hash the received key, and the result should be equal to the previous key. However, forging a key would require the attacker to invert the hash function, and as cryptographic hash functions are designed to be one-way and collision-resistant, this is practically impossible. Therefore, it is also practically impossible to fake the signatures.

The OSNMA pipeline in GNSS-Finland is implemented as follows. First of all, OSNMA data bits retrieved from the E1 signal are available from the I/NAV navigation pages. The main processing is conducted by the FGI-OSNMA [11] software library, which takes these I/NAV pages as an input and handles the authentication logic. Therefore, it is not a requirement for the OSNMA authentication results or even the OSNMA data bits to be directly accessible from the receiver. Instead, only the raw binary-format I/NAV navigation pages are needed. The navigation pages can often be retrieved from the receivers in one way or another, making this approach feasible for almost any receiver. However, different manufacturers have different interfaces to retrieve the I/NAV pages, so some software-side support is still needed for each specific manufacturer. FGI-OSNMA will decode and parse the different OSNMA messages and fields from the I/NAV pages and perform the authentications and react to specific events (such as chain renewal or public key renewal) according to the specification. FGI-OSNMA will generate different authentication events, which will be passed on to GNSS-Finland for storage and visualization. The need for the ability to communicate with different external programs has been taken into account in both FGI-OSNMA and GNSS-Finland. Whenever different authentication events occur, FGI-OSNMA has the capability to execute user-defined callback functions, which in this case will publish the data to the DDS of GNSS-Finland. The different authentication events generated by FGI-OSNMA will be visualized as a timeline in GNSS-Finland, as seen in Figure 5. Specifically, both successful and failed authentications are visible here, as well as some other miscellaneous information related to the authentication process.

3.2. High Accuracy Service

The Galileo HAS is an open service for providing real-time Precise Point Positioning (PPP) corrections. The corrections can be retrieved from the internet, but perhaps more importantly, the corrections can be retrieved directly from the signal-in-space (SIS), meaning that no additional data links are needed.

The HAS pipeline implementation is somewhat analogous to the OSNMA pipeline implementation in GNSS-Finland. An RTCM stream for the GNSS observables and a stream of raw Galileo C/NAV messages from which the HAS corrections will be parsed are needed. We used the HASlib [12,13] software library to decode the HAS corrections and essentially converted the stream of C/NAV pages into an RTCM stream of State Space Representation (SSR) corrections. The HAS SSR corrections themselves can be interesting to monitor, and therefore the corrections are transmitted to GNSS-Finland for storage and visualization, as seen in Figure 6. In addition to this, the RTCM stream with the observables and the RTCM HAS correction stream are used in RTKlib [14] to compute the HAS position solution. Again, the HAS position solution will be transmitted to GNSS-Finland for analysis, storage, and visualization.

Monitoring the HAS puts slightly more requirements on the receiver. In practice, the receiver and the antenna need to be triple-band with E1, E5, and E6. This is because the HAS corrections are received from E6, and E1 + E5 are required to perform positioning with the dual-frequency ionospheric-free combination.

As noted before, the advantage of this processing pipeline is that its implementation is feasible on almost any receiver. In particular, the receiver does not need to be an “HAS receiver”, which are rather scarce on the market at the moment due to the novelty of the HAS. However, this also means that positioning is performed on the server side, and not on the receiver side, thus increasing the server’s computational demands. While this processing can be performed for a single station in real time with only modest computational resources, scaling this to dozens or hundreds of stations requires a considerable amount of computational resources and distributed processing as shown in Figure 7.

4. Conclusions

We introduced the GNSS-Finland service and presented how it can be used as a tool for achieving GNSS situational awareness at a national level. The software architecture of GNSS-Finland and the rationale behind it were discussed. Special attention was paid to the new Galileo services, not only due to them being topical but also to highlight the ability to flexibly extend GNSS-Finland with new features. The processing related to OSNMA and the HAS involves only open-source tools, and therefore, it could be replicated in other monitoring services as well.