These include satellite clock and ephemeris faults and atmospheric (ionospheric and tropospheric) anomalies. Civil aviation has used RAIM for this purpose for many years in Area Navigation (RNAV) and Required Navigation Performance (RNP) operations. ARAIM improves upon the performance and availability of RAIM and will (in a few years) make it possible to conduct instrument approaches with vertical navigation without the need to receive corrections and integrity information from augmentation systems.

Table 1 shows the integrity performance commitments that GNSS service providers have made to civil aviation via the International Civil Aviation Organization (ICAO) [1]. These are used as inputs in the ARAIM user algorithm [2] and identify the additional protection ARAIM must provide to achieve the integrity risk of 10^-7 per operation or below for operations with failure consequences deemed “Hazardous,” as is the case for precision approach under restricted-visibility conditions. For example, GPS commits to a fault rate (R_sat) no greater than 10^-5 per satellite per hour for faults affecting individual satellites that are not correlated across multiple satellites. ARAIM (or any other integrity subsystem) must reduce this probability to a small fraction of the integrity risk requirement by detecting and excluding such faults or alerting that use of GNSS is no longer safe within the 6-second time to alert (TTA) for CAT I precision approaches.

Adding RAIM and ARAIM to Integrity Monitoring 

GNSS applications with the most demanding accuracy and integrity requirements normally employ augmentation systems such as Satellite-based and Ground-based Augmentation Systems (SBAS and GBAS, respectively). The corrections generated by these systems reduce user measurement errors, provide bounds on these errors, and indicate which measurements should not be used based on ground-system monitoring with multiple static reference receivers. This has the effect of reducing the 
probabilities of undetected faults on satellites and other SIS anomalies to below 10^-7 per hour. As a result, users with access to either SBAS or GBAS corrections are likely to use them to simplify user integrity monitoring. For example, airborne users applying the SBAS or GBAS Minimum Operational Performance Requirements (MOPS) are encouraged to use RAIM when it is available, they are not required to, nor are they limited by the higher protection levels (PLs) generated by RAIM due to its need for redundant satellite measurements.

This raises the question: Is RAIM or (particularly) ARAIM a useful addition to integrity monitoring for users who make use of augmentation system integrity monitoring? The answer depends on the operational environment of each user. For aircraft in flight with an excellent view of the sky and far from reflecting surfaces other than those of the aircraft itself, the probability of large errors generated at the aircraft itself due to multipath or radio frequency interference (RFI) is very low. However, for automobile, train, ship and unmanned aerial vehicles (UAVs) that are much closer to obstacles and reflecting surfaces (including the ground and the sea surface) and potential RFI or spoofing transmitters, local threats may be more likely than SIS failures that can be mitigated by augmentation systems. Under these conditions, ARAIM may be a necessary addition to external SIS monitoring.

Consider the use of augmented GNSS on a vehicle being driven autonomously and relying on GNSS and other sensors to stay within a lane of traffic. In rural areas, multipath errors will be relatively benign (albeit worse than on an aircraft), but as the vehicle approaches urban areas and especially “urban canyons,” very large multipath errors may occur due to the GNSS receiver tracking a reflected signal instead of the one directly from a satellite. ARAIM would thus be useful (and perhaps necessary) to exclude or at least detect such large errors on one or multiple satellites. 

Working with ARAIM

ARAIM has a major advantage over traditional RAIM in that it can directly represent and monitor faults on multiple satellites. In ARAIM, each hypothesized fault on one or more measurements is represented by its own fault hypothesis, and every one of these hypotheses is checked by comparing the all-in-view position solution to the solution that would apply if the measurement(s) in that hypothesis were faulted. If this difference between these solutions is large compared to nominal conditions, the fault hypothesis in question is likely to be true, and ARAIM would then proceed to try to isolate the fault to that specific hypothesis or, failing that, alert the user that safe operations are no longer feasible.

However, if the probability of individual measurement faults is much larger than what is typical for SIS faults in Table 1, the number of multiple-measurement fault hypotheses will grow quickly and may exceed the ability of the user’s processor to update ARAIM every time new measurements are obtained. For example, if 16 satellites are in view from two constellations (e.g., GPS and Galileo), and each satellite has an independent probability of excessive multipath of 0.001, the probability of excessive multipath on any pair of satellites is (0.001)²=10^-6, which is small but not negligible (and would be larger when multipath errors correlated among nearby satellites are included). Therefore, each of the 16-choose-2=120 independent satellite pairs must be monitored by ARAIM, creating a total of 16+120=136 hypotheses to be checked and updated every epoch (e.g., every second). 

For users with powerful processors, ARAIM calculations with hundreds of fault hypotheses may be workable, but this is not the case for most off-the-shelf automotive and maritime user equipment today. The best alternative is to combine the various multiple-fault hypotheses into groups so the number of hypotheses that must be checked every epoch is limited to what the user’s processor can handle. One way of doing this is to group satellites in similar locations in the sky into single hypotheses [3]. Returning to the example above, if the 16 satellites in view can be grouped into four sets of four nearby satellites each, only four fault hypotheses would remain to be monitored. The disadvantage of this approach is resolution of faults in individual satellites is reduced, leading to significantly larger protection levels.

Conclusion 

ARAIM is an important addition to integrity monitoring for augmented users when local faults from multipath or RFI are more likely to occur than the SIS faults mitigated by augmentation systems. When the number of satellites in view is large, hundreds of individual fault hypotheses may need to be monitored, but this number can be reduced by grouping individual measurements at the cost of losing fault resolution and therefore suffering higher protection levels. This is a key tradeoff to investigate when designing and procuring cost-effective user receiver and processor hardware.

References

[1] ICAO SARPS, Annex 10, Vol. I, Radio Navigation Aids, 8th Edition, July 2023.

[2] J. Blanch, T. Walter, et al., “Baseline Advanced RAIM User Algorithm: Proposed Updates,” Proceedings of ION ITM 2022, Long Beach, CA, January 2022.

[3] J. Blanch, T. Walter, et al., “Fixed Subset Selection to Reduce Advanced RAIM Complexity,” Proceedings of ION ITM 2018, Reston, VA, January 2018.

The post Q: Are RAIM and Advanced RAIM useful for applications that take advantage of differential GNSS corrections for integrity? appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

ZIXI LIU, SHERMAN LO, JUAN BLANCH, YU-HSUAN CHEN, TODD WALTER AND SAM PULLEN, STANFORD UNIVERSITY

A: GNSS serves safety-of-life applications in aviation (e.g., precision approach and landing operations), land vehicles and marine users. One threat to these applications is radio frequency interference (RFI). A variety of RFI events affecting GNSS signal bands have been observed over the many years of GNSS usage [1]. RFI leading to unexpected loss of GNSS navigation forces reliance on backup sensors and operational modes. While this is tolerable if sufficiently rare, equipping and planning for these events increases the cost and complexity of safety-critical navigation. Spoofing of GNSS signals also has been observed in the last few years and is more worrying because it could cause GNSS to output hazardously incorrect information and thus pose a direct threat to user safety.

Since the Russian invasion of Ukraine in February 2022, RFI and spoofing that appears to be both intentional and malicious has been observed in Eastern Europe [2, 3]. Most Western observers believe the Russian military is the source of these events, and its purpose is primarily military [2, 4]. However, these events also affect civil users and pose hazards that might not be intended but are no less real. This article examines what we have observed from recent RFI and spoofing in Eastern Europe, how it has affected civil aviation, and lessons for civil user safety and operational efficiency.

Observation Using ADS-B Messages 

Automatic Dependent Surveillance (ADS)-B messages broadcast by aircraft are an important source of information regarding the timing and effects of GNSS RFI, and this information is now readily available online (e.g., at GPSJam, managed by John Wiseman [5], which uses data from ADS-B Exchange [6]). Figure 1 from [5] shows an example view of GNSS RFI affecting ADS-B on February 21, 2024. The colors on the map indicate regions where at least 98% of aircraft report good ADS-B accuracy (green), where between 90% and 98% of aircraft report good accuracy (yellow), and where fewer than 90% of aircraft report good accuracy (red) based on the NACp parameter defined below. The locations in red on this map have seen frequent GNSS RFI and spoofing events.

Our research also uses data collected from the OpenSky network [7] and ADS-B Exchange [6]. It contains GNSS-derived position information from aircraft along with built-in accuracy and integrity indicators known as Navigation Accuracy Category—Position (NACp) and Navigation Integrity Category (NIC), which provide the transmitting aircraft’s estimate of its GNSS position quality. NACp gives the 2D horizontal error radius that is expected to bound the current horizontal position error with a probability of 95%, while NIC does the same for the much higher probability of 99.999%, meaning that no more than one error exceeding this radius should occur in 100,000 samples. 

Figure 2 shows values for both NACp and NIC as defined by the RTCA ADS-B MOPS (DO-260C) [8]. Note that higher integer values correspond to smaller error bounds and thus better performance. The ADS-B equipment performance requirements defined in [9] state that, under normal circumstances, aircraft NIC values must be 7 or higher. As shown in Figure 2, a NIC of 7 corresponds to a horizontal containment radius of 370.4 meters, while a NACp of 7 corresponds to a 95% horizontal error bound of half that (185.2 meters). These error magnitudes are much larger than would be expected of the GPS Standard Positioning Service (SPS) under anything close to “normal” conditions [10]. Thus, NIC values lower than 7 suggest an anomaly is present, of which RFI denying GNSS service is the most likely cause in locations where we have already determined that RFI is occasionally present. While this information from ADS-B does not directly observe the presence of RFI, it shows the impact on civil aviation of the RFI that is present.

RFI Events in the Baltic Sea Region

An increase in interference to GPS signals in the Baltic Sea region was observed to begin on December 25, 2023, and is continuing at the time of writing. Figure 3 shows examples of significantly affected days in which ADS-B messages suggest the presence of high-powered RFI. Each map shows the reported locations of aircraft sending ADS-B messages over the course of a day from midnight-to-midnight UTC. Most of these points have NIC values of 7 or higher (“High NIC”) and are shown in green, while the smaller set of points with NIC below 7 (“Low NIC”) are shown in red. As explained earlier, the points in red have containment radii far above typical for GPS SPS, suggesting the presence of RFI. The red points extend over a large region centered on the southern shore of the Baltic Sea from Gdansk (Poland) eastward to the Lithuanian border and include the Kaliningrad Oblast of Russia isolated between Poland and Lithuania. The lower-right map in Figure 3 shows an earlier example day (December 6, 2023) that appears to have little or no RFI for comparison. The handful of scattered red points on this map suggest temporary navigation problems unique to particular aircraft. 

Figure 4 shows bar charts of the number of High NIC (green) and Low NIC (red) samples during each one-hour interval for the same days shown in Figure 3. While some of these days (e.g., January 10 and 16 2024) have fractions of Low NIC observations that remain similar throughout most of the day, others (e.g., December 25, 2023, and January 19, 2024) have higher Low NIC ratios at different times of day (late afternoon on December 25, morning on January 19). These patterns, along with different behavior on different days, suggest the RFI causing these observations is tuned to specific activities and is not unintentional (which might cause it to be active continuously). Note the times indicated on the x-axis are in UTC, which is one hour behind local time in Poland and two hours behind in Lithuania and Kaliningrad.

We have looked at all days between December 25, 2023, and February 10, 2024, and found some spatial and temporal characteristics related to the Baltic disruption. First, most of the days were only affected during early morning (0000-0500 UTC) and late evening (2100-2400 UTC). Only some of the days shown in Figures 3 and 4 have been affected for almost the entire day. This further suggests the motivation for this RFI could potentially be related to underlying (possibly military) activities limited to those hours or those days. Second, most of the jammed days have similar affected regions in terms of size, shape and location. Figure 5 shows similar maps and bar charts for some example days with those characteristics.

Localization of Baltic Sea RFI Events

We have developed RFI transmitter localization techniques based on modeling the relationship between ADS-B reported NIC and received jamming power and then using iterative non-linear least-squares to estimate the location where the jamming is strongest (i.e., received GNSS signal weakest) given the locations of the reported NIC values [1, 11, 12]. This method relies on the assumptions of free-space propagation and that the source is a static, continuous, single element, omni-directional antenna. Figure 6 shows a preliminary localization result over the Baltic Sea region between 1500 and 1600 UTC on December 25, 2023. A smooth gradient in estimated power appears on these plots and indicates a minimum near the southern Black Sea coast between Gdansk and Kaliningrad. 

The uncertainty in this initial jammer location estimate can be refined by using “bootstrap” sub-sampling of the ADS-B data and by using data from a day where Low NIC observations are limited to a smaller region around the minimum-power location shown in Figure 6 (January 4, 2024, from 0500 to 2100 UTC). Figure 7 shows a map that, based on data from this day, includes an ellipse with a 95% probability of including the actual jammer location. The overland component of this ellipse includes the Kaliningrad Oblast of Russia, which is the headquarters of the Russian Baltic Fleet and is known to have an extensive array of modern Russian weaponry, including the latest aircraft and missiles [2].

Spoofing Events in the Black Sea Region

Spoofing of GNSS positions reported by ADS-B has been observed over the Balkans and the Black Sea region. Figure 8 shows an example spoofing event in which affected aircraft were spoofed onto a landing trajectory. The left-hand plot in Figure 8 shows ADS-B positions and NIC values for aircraft passing to the southwest of Russia on December 6, 2023. The right-hand plot shows the location that aircraft were spoofed to. The reported spoofed locations are over the Crimean Peninsula in a small area corresponding to the location of Belbek Airport (33.6º E, 44.7º N), which is now a Russian military airfield that has been periodically attacked by Ukraine since the Russian invasion [4]. The motivation for spoofing vehicle positions to this location is unclear, but the target appears to be military rather than civilian aircraft.

Figure 9 shows aircraft positions before, during and after spoofing on December 6, 2023. The red star in both plots indicates the locations where aircraft were spoofed to, which were mostly over the runway of Belbek Airport as shown in Figure 8. The left-hand plot shows each aircraft’s last observed position before being spoofed, and the right-hand plot shows each aircraft’s first observed position after recovering. The color of each point shows the time difference between the before/after position and the spoofed position. This is due to the lack of ADS-B ground receiver coverage along the coast, as most of these flights were not observed by ground receivers while they were flying over the Black Sea. For instance, for points with gaps longer than 20 minutes (i.e., all points that are not shown in blue in the left-hand plot), aircraft are not being spoofed directly from the “before” position to the “spoofed” position. Instead, the “before” position was the last time the aircraft was seen before being spoofed.

We estimated the region affected by spoofing based on the locations before and after aircraft were spoofed. We focused on aircraft with short time gaps between “before,” “spoofed” and “after” locations to maximize accuracy. Figure 10 illustrates the potential region affected by spoofing using red dashed lines. These are formed by connecting each aircraft’s flight paths before and after being spoofed. This relies on the assumption that the gap between the two components of the original flight trajectory is where the aircraft were actually flying while being spoofed. Therefore, spoofing is affecting the region that contains those gaps. The black dotted lines show the actual reported positions and how each flight jumped from its assumed path to the spoofed location at Belbek Airport. 

Unusual “Circle” Spoofing inside Russia

Another apparent spoofing of GNSS positions reported by ADS-B has been observed over Smolensk Oblast, Russia, in which aircraft were spoofed into circular trajectories. This type of spoofing was previously observed in receivers onboard ships near China and Iran (using AIS data) [13] and more recently observed in aviation by Zach Clements at UT Austin [3]. Figure 11 shows an example circle spoofing event on December 25, 2023. The reason for spoofing in circles is unclear, but [13] theorizes that (a) this is intended to confuse observers into believing the spoofer is near the center of the circle when it may not be, and (b) reducing the radius of the spoofed circular path can avoid triggering user alerts based on estimating Horizontal Position Error (HPE). 

Figure 12 shows similar plots of aircraft positions before, during and after spoofing on December 25, 2023. Compared with spoofing events in the Black Sea region, this circle spoofing affects aircraft from different locations that are far away from each other, which can be observed by comparing the 
locations of points colored in blue, red and green. This further suggests there could be multiple spoofers performing similar attacks at the same time. This motivates us to estimate the region affected by spoofing using a different method. 

Figure 13 shows the estimated region affected by spoofing based on interpolated aircraft trajectories. Rather than connecting the apparent gaps in each aircraft’s flight path, we estimated where each aircraft was actually flying while being spoofed. We used this interpolated trajectory to identify each aircraft position immediately before being spoofed (in black) and immediately after recovering from spoofing (in blue). By connecting those two interpolated position points, we can estimate the location of the affected region more accurately by filling in the gap from loss of reports due to lack of ADS-B ground reception. The red lines in Figure 13 indicate the estimated regions affected by spoofing. The black lines identify how aircraft jumped from their intended flight paths to the spoofed location and how they recovered back to their original flight paths.

Summary and Conclusions

This article describes what the authors currently know about instances of both RFI (jamming) and spoofing observed in Eastern Europe within or near the borders of Russia. We have observed spoofing directed to a small set of locations at Belbek Airport in the Crimea and into circular movement patterns near Smolensk. These events appear to be caused by deliberate Russian military action based on what we have observed and what others have reported [2, 3]. The purpose of this spoofing is unclear but appears to be targeting opposing (e.g., Ukrainian) military operations.

These events are unavoidably affecting civil aviation, as demonstrated by the degradation of ADS-B NACp and NIC parameters that make them observable to us. At least some civil transport aircraft in the regions affected by spoofing report dramatically incorrect locations. Fortunately, to date, civil transport airplanes appear to be able to live with these threats while still operating safely, as they are merely passing over the affected regions.

Acknowledgments

The authors would like to thank the FAA for its support of this research as well as the other members of our laboratory and Prof. Dennis Akos of the University of Colorado for contributing to this research. We also thank the OpenSky Network [7] and the ADS-B Exchange [6] for providing ADS-B data for this study.

References

(1) Z. Liu, S. Lo, et al., “GNSS Interference: Getting to the Source,” Inside GNSS, Vol. 18, No. 3, May/June 2023, pp. 46-51. 

(2) S. Willis, “Kaliningrad: Impregnable Fortress or ‘Russian Alamo’?,” CNA in-depth blog, May 15, 2023. https://www.cna.org/our-media/indepth/2023/05/kaliningrad-impregnable-fortress-or-russian-alamo

(3) D. Goward, “Circle Spoofing Comes to Aviation—first the Baltic, now the Mediterranean,” The Resilient Navigation and Timing Foundation, Jan. 7, 2024. https://rntfnd.org/2024/01/07/circle-spoofing-comes-to-aviation-first-the-baltic-now-the-mediterranean/

(4) E. Cook, “Crimea Airbase Attacked as Russians Bemoan Fighter Jet, Troop Losses,” Newsweek, Feb. 1, 2024. https://www.newsweek.com/crimea-airbase-attacks-ukraine-missile-storm-shadow-fighter-jets-russia-losses-1865896

(5) J. Wiseman, “GPSJam: Daily Maps of GPS Interference,” https://gpsjam.org/

(6) “ADS-B Exchange: World’s largest source of unfiltered flight data,” https://www.adsbexchange.com/

(7) M. Schäfer, M. Strohmeier, V. Lenders, I. Martinovic, M. Wilhelm, “Bringing up OpenSky: A large-scale ADS-B sensor network for research,” Proc. 13th Int’l. Symp. on Information Processing in Sensor Networks, Berlin, Germany, April 2014. 

(8) Minimum Operational Performance Standards for 1090 MHz Extended Squitter Automatic Dependent Surveillance—Broadcast (ADS-B) and Traffic Information Services—Broadcast (TIS-B). Washington, DC, RTCA DO-260C, Dec. 17, 2020.

(9) Title 14 of the Code of Federal Regulations—14 CFR Part 91. Office of the Federal Register, National Archives and Records Administration, Washington, DC, updated 16 Feb. 2024. https://www.ecfr.gov/current/title-14/chapter-I/subchapter-F/part-91?toc=1

(10) GPS Standard Positioning Service (SPS) Performance Standard (GPS SPS PS), Washington DC, U.S. Dept. of Defense, 5th Edition, April 2020. https://www.gps.gov/technical/ps/2020-SPS-performance-standard.pdf

(11) Z. Liu, S. Lo, et al., “Real-time Detection and Localization of GNSS Interference Source,” Proceedings of ION GNSS+ 2022, Denver, CO, Sept. 2022, pp. 3731-3742.

(12) Z. Liu, S. Lo, et al., “Locating GNSS Interference Sources using ADS-B with Non-linear Least Squares,” Submitted to Navigation (forthcoming). 

(13) G. Buesnel, “‘Circle Spoofing’ Is on the Rise,” Spirent blog, Aug. 17, 2020. https://www.spirent.com/blogs/circle-spoofing-is-on-the-rise

Authors

Zixi Liu is a Ph.D. candidate at the GPS Laboratory at Stanford University. She received her B.Sc. degree from Purdue University in 2018 and her M. Sc. degree from Stanford University in 2020.

Sherman Lo is a senior research engineer at the Stanford GPS Laboratory and the executive director of the Stanford Center for Position Navigation and Time. He received his Ph.D. in Aeronautics and Astronautics from Stanford University in 2002. He has and continues to work on navigation robustness and safety, often supporting the FAA. He has conducted research on Loran, alternative navigation, SBAS, ARAIM, GNSS for railways and automobiles. He also works on spoof and interference mitigation for navigation. He has published over 100 research papers and articles. He was awarded the ION Early Achievement Award.

Juan Blanch is a senior research engineer at Stanford University, where he works on integrity algorithms for Space-based Augmentation Systems and on Receiver Autonomous Integrity Monitoring. A graduate of Ecole Polytechnique in France, he holds an MS in Electrical Engineering and a Ph.D. in Aeronautics and Astronautics from Stanford University. He received the 2004 ION Parkinson Award for his Ph.D. dissertation and the 2010 ION Early Achievement Award.

Yu-Hsuan Chen is a research engineer in the GPS laboratory at Stanford University. He received his Ph.D. in electrical engineering from National Cheng Kung University in 2011.

Todd Walter is a Research Professor in the Department of Aeronautics and Astronautics at Stanford University. He is also a member of the National Space-Based Positioning, Navigation, and Timing (PNT) Advisory Board. His research focuses on implementing satellite navigation systems for safety-of-life applications. He has received the Institute of Navigation (ION) Thurlow and Kepler awards. He is also a fellow of ION and has served as its president.

The post GNSS Spoofing and Jamming in Eastern Europe appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

A: Many augmentations of GNSS satellite navigation have been developed and fielded since the GPS constellation was completed and declared fully operational in 1995. The best known of these are satellite-based and ground-based augmentation systems (SBAS and GBAS), which are public systems designed to support civil aviation.

The corrections and integrity information broadcast by SBAS and GBAS are available to all GNSS users with the necessary equipment, but relatively few users beyond aviation have incorporated them into their applications (although this is slowly changing). In addition, many private augmentation systems now provide precise point positioning (PPP) and/or real-time kinematic (RTK) corrections to support other applications requiring sub-meter accuracy. Examples of these applications include surveying, mining and intelligent agriculture.

A growing subset of GNSS applications have demanding safety requirements in addition to needing sub-meter accuracy. These include railway, maritime, automobile and unmanned aerial vehicle (UAV) applications in which passengers and other people are potentially at risk. Specialized GNSS augmentation systems are needed to meet these requirements, and in many cases, multiple different types and sources of augmentation must be combined.

This article describes one example of a “multi-tier” GNSS augmentation system known as the High Integrity EGNSS Layer for Multimodal Eco-friendly Transportation, or HELMET [1] (EGNSS stands for “European Global Navigation Satellites System, although HELMET is not limited to European applications). HELMET is designed to support multiple Service Levels (SLs), where each SL satisfies a set of requirements linked to specific rail and automotive applications. Depending on the SL for a particular user class, HELMET applies different combinations of corrections and user algorithms to maximize performance and availability.

Requirements for Rail and Automotive Navigation 

Table 1 summarizes the requirements and corresponding rail, automotive and UAV applications for four different SLs defined for HELMET. These requirements are specified in terms of 95% accuracy in along-track (AT) and cross-track (CT) position axes, integrity alert limits (ALs), tolerable hazard rates (THRs) of loss of integrity (LOI), and times to alert (TTAs) within which anomalies potentially leading to LOI are alerted or (preferably) detected and excluded. LOI occurs when the specified ALs are exceeded in one or more position axes without fault exclusion or annunciation within the TTA. THRs represent the maximum tolerable probability of LOI per exposure interval.

Figure 1 illustrates one of the key railway applications supported by HELMET SLs 1 and 2, which is known as the European Rail Traffic Management System (ERTMS), within which lies the European Train Control System (ETCS) [1,2,3]. ERTMS uses balises placed at known locations along a pre-surveyed track. When a train passes over a balise or a group of closely-spaced balises (provided for redundancy), it receives the balise transmission and obtains its precise location along the track from a database that includes the identifiers and locations of all balises. In between balise groups, the train uses odometry to estimate how far it has progressed along the track. The confidence interval on 1-D train position used to ensure safe separation of trains along the track grows predictably between balise groups and resets itself to a small value when the next balise group is encountered.

While ERTMS is certified and is in operation today, the expense of fielding and maintaining balise groups every few hundred meters along ERTMS-equipped tracks motivated the search for a less expensive variation that uses augmented GNSS to replace physical balises with virtual ones. A GNSS-equipped train knows when it has reached a virtual balise when its GNSS-based location matches its existing database of balise locations. In this way, GNSS can be introduced into ERTMS without otherwise changing the way ERTMS works today or the communication protocols between trackside controllers and individual trains. The Railway High Integrity Navigation Overlay System (RHINOS) project demonstrated the practicality of this approach to GNSS-enabled ERTMS in 2017 [4], and HELMET extends it to additional rail applications (such as track identification) along with automotive and UAV applications.

The existence of high-integrity systems like ERTMS in the rail domain means requirements for GNSS-based rail navigation can be derived from existing standards. The same is not yet true for automotive applications such as driver assistance or autonomous driving. The automotive requirements shown for SLs 3 and 4 in Table 1 are not yet standardized but serve as a guide to the eventual requirements on GNSS augmentation in support of vehicle navigation [5].

HELMET Multi-Service Architecture

Figure 2 shows a system-level depiction of HELMET that simultaneously supports rail, automotive and UAV applications. A key architectural feature is that GNSS augmentation used within HELMET is broken down into two tiers. The first tier represents SBAS, which is both provided to users via the datalinks built into HELMET (so users are no longer dependent on SBAS corrections transmitted from Geosynchronous satellites) and used as inputs to HELMET’s own integrity monitoring in its Augmentation and Integrity Monitoring Network (AIMN), which is part of the second tier. AIMN consists of a network of reference receivers at fixed sites in the manner of SBAS but with typical separations between receivers of several tens of kilometers instead of hundreds of kilometers.

The second tier of augmentation in Figure 2 also includes separate “adaptation layers” for rail, automotive and UAVs. These layers convert the GNSS corrections and integrity information provided by AIMN into messages specifically designed for different types of users. For example, ERTMS supporting rail applications has existing subsystems such as Radio Block Centers (RBCs) and communication protocols that will be retained. UAV and automobile users are expected to need adaptation to support future messaging and control protocols created for these domains.

Using GNSS augmentation to support multiple user classes is a key HELMET feature and is motivated by economics and efficiency. To meet the requirements of HELMET SLs beyond SL 1, local or regional differential corrections and integrity monitoring provided by the second tier are required. This requires a network of reference receiver sites designed for very high integrity, continuity and availability. Deploying and maintaining these sites and the communications from them to the Reference Station Operating Center (RSOC) shown in Figure 2 represents a significant expense that can and should be shared with multiple user classes.

The functions performed by AIMN within HELMET’s second tier are shown in Figure 3. AIMN applies the reference station measurements collected by the RSOC to calculate code-phase (DGNSS) and carrier-phase corrections (RTK/NRTK/PPP) to support multiple service levels. In parallel, the reference station measurements and SBAS information from the first tier are combined to detect and exclude reference station measurement faults and any remaining Signal-in-Space (satellite and atmospheric) faults not already detected by SBAS. In particular, the smaller separations between HELMET reference stations aids detection of anomalous gradients in ionospheric and tropospheric delays that can create significant errors in DGNSS, PPP and RTK corrections. The resulting corrections are broadcast using RTCM SC-104 and (pending) SC-134 message formats to users and to the adaptation layers that format this information for different user classes.

The subsystems and functions of the train’s on-board units (OBUs) are shown in Figure 4. Sensors include augmented GNSS as well as inertial measurement units (IMUs) and cameras and/or LiDAR to provide an independent representation of the track ahead and the terrain to the sides. GNSS fault detection and exclusion (FDE), including advanced (solution-separation-based) RAIM (ARAIM), occurs before the surviving measurements are combined (“fused”) with those from the other sensors, followed by a second FDE stage in which the redundancy created by multiple sensors is exploited to check for unusual errors in any individual sensor.

Proof-of-Concept Test Results

Several trials of a proof-of-concept (PoC) HELMET architecture have been conducted to evaluate performance and demonstrate the feasibility of HELMET supporting rail and automotive applications. The first one described in this article was conducted in April 2022 along the track and nearby road between central Rome and Leonardo da Vinci-Fiumicino International Airport (FCO) [1]. As shown in Figure 6, a highway (A51) runs along the same route roughly parallel to the track. This allows for testing the user algorithms in the automobile shown in Figure 7 rather than on an active train, which is harder to equip and collect data from. In this PoC architecture, the first tier of augmentation is provided by EGNOS (the European SBAS), and the second tier is made up of eight reference stations in central Italy that are part of the GNSS R&D Network (GRDNet) deployed and operated by SOGEI, the technology partner of the Italian Ministry of Economy and Finance.

While, in general, automotive and rail OBUs are likely to use different elements of the GNSS corrections provided by AIMN, the automotive OBU for this test was designed to emulate along-track rail navigation as much as possible. For example, automobile OBUs cannot make use of the knowledge of the surveyed track location exploited by train OBUs. To remove this limitation, the automobile OBU was provided with a digital map of the road lane centerlines constructed separately using post-processed RTK measurements. The automobile was kept as close as possible to the center of the lane by careful driving and lane-keeping assistance. Navigation errors were estimated by differencing a RTK-based truth solution from a separate source (not the same as the source of lane centerlines) from the real-time automotive OBU position estimate.

Figure 8 uses the Stanford triangle diagram to compare along-track position errors (on the x-axis) with the protection levels (PLs) computed by the OBU as bounds on this error to the GNSS THR of 10^-6 per hour for this application under SL 1 in Table 1. Figure 9 shows the same position error data as a function of time during the drive from Rome to Fiumicino airport. These plots show the actual position error did not exceed about 1.25 meters for time epochs that were available, where “available” means the calculated protection level did not exceed the 5-meter alert limit for SL 1 in Table 1 (PL and AL are known to the OBU in real time and are one means of protecting integrity). As shown in Figure 8, eight epochs had PLs exceeding 5 meters, shown as red points in Figure 9. The errors observed during these unavailable epochs were significantly larger than those of the available epochs, reaching as high as 3 meters. However, because the PLs in these cases were above 5 meters, integrity would have been maintained (error ≤ PL) even if the availability determination (PL ≤ AL) were ignored.

In November 2022, the passenger train shown in Figure 10 was equipped with a prototype rail OBU and used to collect HELMET PoC measurements along the line from Cagliari to Decimomannu in southern Sardinia shown in Figure 11. This allowed HELMET to be tested in an operational rail environment.

The position errors estimated during this experiment look much like those obtained from the automobile along the Rome-to-Fiumicino highway. Figure 12 shows the Stanford triangle diagram for this test and Figure 13 shows the along-track position error versus time. The position errors in this rail test were slightly larger than those along the highway but did not exceed 2.2 meters. The along-track protection levels on the y-axis in Figure 12 were also similar to those observed along the highway. Only two out of 1,349 epochs in the rail test had protection levels exceeding the alert limit (and thus unavailable). However, note the alert limit shown in Figure 12 is 12 meters to correspond to the existing 1-D along-track requirement for ERTMS. The alert limit in Figure 9 for the automobile test is 5 meters. If it had been set to 12 meters, none of the epochs would have been unavailable. 

Summary

This article describes HELMET as an example of a single GNSS augmentation architecture that includes multiple service levels and multiple types of GNSS corrections and integrity information to serve multiple user classes and different requirements within each class. HELMET includes two tiers of GNSS augmentation, with multiple forms of corrections and integrity information included within the second tier (e.g., code-phase, PPP and RTK corrections). HELMET represents a practical, cost-effective approach for rail, automotive and UAV applications. HELMET illustrates how multiple forms of GNSS augmentation can be combined to support many different classes of GNSS and navigation users without requiring individual, specialized systems for each one. 

Acknowledgments

The authors would like to thank the team of engineers at RadioLabs and the external partners of HELMET who developed and performed the HELMET prototype tests. They would also like to thank Dr. Daniel Lopour from EUSPA for his technical and programmatic support and Rete Ferroviaria Italiana SpA (RFI) and Azienda Nazionale Autonoma Delle Strade (ANAS) for their help in developing requirements for rail and automotive applications. The HELMET project was developed under contract 870257 from EUSPA.

References

[1] F. Rispoli, A. Vennarini, et al., “On the GNSS augmentation services for the ERTMS train control and
Connected Car applications: technical synergies and opportunities,” Proceedings of ION GNSS+ 2022.
Denver, CO, Sept. 2022, pp. 1514-1528.
https://www.researchgate.net/publication/364115778_On_the_GNSS
_augmentation_services_for_the_ERTMS_train_control_and_Connected_Car_applications_technical_sy
nergies_and_opportunities
[2] A. Neri, F. Rispoli, P. Salvatori, “The Perspective of Adopting the GNSS for the Evolution of the
European Train Control System (ERTMS): A Roadmap for a Standardized and Certifiable Platform,
”Proceedings of ION GNSS+ 2015. Tampa, FL, Sept. 2015, pp. 542-552.
https://www.ion.org/publications/abstract.cfm?articleID=12903
[3] C. Stallo, A. Neri, et al., “GNSS Integrity Monitoring for Rail Applications: Two-Tiers Method,” IEEE
Transactions on Aerospace and Electronic Systems. Vol. 55, No. 4, Aug. 2019, pp. 1850-1863.
https://doi.org/10.1109/TAES.2018.2876735
[4] S. Lo, S. Pullen, et al., “Projected Performance of a Baseline High Integrity GNSS Railway
Architecture under Nominal and Faulted Conditions,” Proceedings of ION GNSS+ 2017. Portland, OR,
Sept. 2017, pp. 2148-2171. http://web.stanford.edu/
group/scpnt/gpslab/pubs/papers/Lo_IONGNSS_2017_Railway.pdf
[5] T.G.R. Reid, A. Neish, B. Manning, “Localization & Mapping Requirements for Level 2+
Autonomous Vehicles,” Proceedings of the 2023 International Technical Meeting (ITM). Long Beach, CA,
Jan. 2023, pp. 107-123. https://doi.org/10.33012/2023.18634

Authors

Francesco Rispoli
is the General Director of RadioLabs and the Manager of the National Cluster of Transports. From 2011 to 2020, he was with Hitachi Rail, responsible for satellite operations, and was previously with Telespazio and Alenia Spazio. He received a degree in Electronic Engineering from the Polytechnic of Turin in 1978 and a Master on Applied Electromagnetism from the University La Sapienza in Roma in 1980. 

Alessandro Neri 
is a full professor in Telecommunications at Roma Tre University. Since 2009, he is the President of RadioLabs, a not-for-profit research center based on a partnership between universities and industrial companies. Since November 2022, he is the Vice Rector for Innovation and Technology Transfer at Roma Tre University. He is the chairman of WG-2 of the RTCM SC-134 Special Committee. His research activity has mainly been focused on information theory, signal and image processing, and location and navigation technologies.

Alessia Vennarini received a Master’s Degree in Information and Communication Technology Engineering from University Roma Tre in 2011. In 2012 she joined the RadioLabs Research Center as a GNSS expert. Since then, she has been involved in European and national projects concerning the use of GNSS for train traffic management and connected road vehicles.

Arianna Persia received a Master’s Degree in Telecommunication Engineering from the University of L’Aquila (Italy). In 2020, she received a Ph.D. in Information and Communication Technologies in the Department of Information Engineering, Computer Science and Mathematics of the University of L’Aquila. Since 2020, she has been a researcher at the RadioLabs Consortium, where she is currently involved in European and national projects in the field of satellite navigation and connected road vehicles.

Roberto Capua 
is an Electronic Engineer with 25 years of experience in GNSS applications along with Research and Development for Public and Private Organizations. Currently, he is responsible for GNSS R&D for SOGEI, the technological partner of the Ministry of Economy and Finance of Italy. He is the Secretary of the Galileo Services Association and the Chairman of the RTCM SC-134 Committee “Integrity for GNSS-Based High Accuracy Applications.”

The post Q: How can GNSS augmentation services be combined to simultaneously support multiple user classes with demanding but varied requirements? appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

A: A serious and growing concern for users of GPS and other GNSS constellations is the possibility that the pseudorandom code signals and navigation data encoded on them might be altered from what is originally transmitted by GNSS satellites. Instances of likely or potential GNSS spoofing have been reported multiple times in this magazine ([1]), as well as various approaches and tools for detection and mitigation ([2,3]), and concerns for specific user segments with the most demanding integrity requirements ([3]). The last two decades of research on spoofing and its mitigation have shown that, while most types of spoofing can be detected by existing receivers using a variety of monitor algorithms, it is difficult to guarantee detection of the most sophisticated forms of spoofing without new tools.

One useful technique likely to be provided to users in the future is the ability to authenticate their received GNSS signals. “Authentication” in this context means confirming that the received signals are the same as those transmitted by authorized sources (GNSS satellites) and have not been modified or overwhelmed by spoofers. Authentication can be limited to the navigation data encoded within the PRN code signal (see [4]) or include the spreading code signal as well. 

Unlike indirect monitoring of the potential presence of spoofing, authentication represents a direct confirmation of the authenticity of received signals. To achieve this, some form of cryptography is required. This is a significant change because it implies modifying the interface between GNSS service provider and future users while not significantly affecting existing users who are not aware of this change and don’t need the benefits of authentication.

The basics of cryptographic authentication as it applies to GNSS signals are explained in [5, 6]. Unlike encryption, cryptographic authentication does not modify or obfuscate the transmitted data but instead adds a “signature” to it that is used later to verify the authenticity of the remainder of the data. 

Authentication requires additional data bandwidth for these signatures, posing a significant challenge given the constrained data bandwidth of current signals and their pre-internet design. This article focuses on recent work ([7] and [8]) using multiple cryptographic techniques that consider the trade-off between authentication integrity strength and desired features (e.g., minimizing the probability of authenticating a modified message), feasibility of modification of existing signals (for operator and user acceptance), and limited impact on existing users who will form the vast majority of the GNSS user population for some time to come.

Watermarking

Existing civil GNSS signal authentication concepts, such as Chimera, incorporate the insertion of unpredictable “watermarks” of uninformative content into the GNSS spreading codes, which later allows authentication after the insertions are disclosed [9]. These watermarks are designed to have minimal effect on the spreading codes so that they can be inserted into existing signals without affecting legacy users who do not need signal authentication. Because this attempts to validate the spreading code as well as the encoded navigation data, receivers attempting to authenticate their signals must store raw radio frequency data containing the watermarked spreading codes. After the GNSS provider broadcasts these watermarked codes, the provider separately distributes a cryptographic “seed” so that receivers can generate replicas of the watermarks. Receivers can then go back and re-autocorrelate the spreading codes, considering the signal cryptographically authentic if the replica-to-raw autocorrelation increases correctly after incorporating the watermarks into the replicas [7].

There are several ways to generate watermarks from cryptographic seeds as part of this process, but it is essential to make implementation as data-efficient as possible for both the service provider and user while maintaining a high degree of authentication integrity. One approach based on Timed Efficient Stream Loss-tolerant Authentication (TESLA) was customized to support authentication of SBAS correction and integrity signals in [10] and can be expanded for use with all types of GNSS civil signals. 

TESLA and ECDSA

Generating cryptographic seeds using TESLA is an alternative to the method known as (the) Elliptic Curve Digital Signature Algorithm, or ECDSA. With ECDSA, a provider produces a message and a signature for a receiver to use for immediate authentication. This signature is pseudorandom and thus can serve as the cryptographic seed of the watermarks. For ECDSA, this is done by asymmetrically providing a “public key” to all users and encoding the signature messages with a “private key” which is secret. The resulting signature can then be verified almost instantaneously by applying the public key. However, the signature messages that result tend to be very large relative to typical GNSS data rates of 50 to 500 bps, and the computation needed to perform authentication in real time is non-trivial [5]. 

TESLA mitigates these problems by instead providing symmetric keys (the same keys at provider and user) that are provided soon after the signature messages that the keys are used to encode. This creates asymmetry in time: a key received at time t is used to authenticate a signature broadcast some time earlier (t – δt). Figure 1 (Figure 2 of [5]) illustrates the use of TESLA’s procedure to validate navigation data in terms of a time series of messages (m), keys (k, K), and Message Authentication Codes (MAC). The MACs represent message signatures and are verified using the same keys that generated (signed) them. First, the MAC is broadcast; then, the key is broadcast later. Both the MACs and the corresponding keys are needed to verify the message data, and since the keys are transmitted after some delay, verification of each set of messages is delayed until the key is provided. The security of authentication arises from how only the original message provider could have generated the message with the transmitted MAC signature before the release of the key [5]. 

TESLA-based Message Authentication

Authentication of the spreading codes is more complex than authentication of encoded data. Since the spreading codes in GNSS ranging signals exist below the thermal noise floor, receivers must know and therefore be able to generate local replicas of the spreading code to deduce pseudoranges. Cryptographic pseudorandom information added to the spreading code must be delivered to receivers separately from the spreading code itself. The advantage of ECDSA in non-GNSS contexts (e.g., internet authentication) is that the receiver can authenticate information immediately, as opposed to the required delay for a so-called “bit-commitment” scheme such as TESLA. However, since the nature of GNSS (the need for correlation of received signals to local replicas) invalidates this feature of ECDSA, it would be better to use a method based on TESLA to exploit the additional features provided by bit-commitment schemes [7].

TESLA provides several advantages relevant to GNSS over exclusively using ECDSA. 

First, a small cryptographic distribution can authenticate unlimited information, alleviating the constraint posed by limited GNSS message bandwidth. Second, if a receiver misses a cryptographic distribution, a receiver can rederive that distribution from a later distribution, providing loss tolerance. Third, the cryptographic functions used can be more computationally efficient, saving receiver computation and power. Further, TESLA is used in tandem with ECDSA rather than completely replacing it. ECDSA’s use within TESLA effectively acts as the rekeying operation for TESLA.

TESLA requires the construction of a one-way set of n-bit integers related via repeated application of a cryptographic hash function, where n is the security level of the protocol. Each n-bit integer among the set serves as a hash message authentication code (HMAC) key at a particular time agreed to by provider and receiver [11]. Each n-bit integer is called a Hash Point, and a collection of Hash Points consecutively related via the Hash Function is called a Hash Path. Non-consecutive Hash Points further along the Hash Path are connected via repeated application of the Hash Function. The first Hash Point along the path is called the Hash Path Start, which is just a random n-bit integer. The last Hash Point along the path is called the Hash Path End. The Hash Function (e.g., SHA-256—see [11]) is secure in that it is trivially easy to compute the final Hash Point of the Hash Function given the initial Hash Point, but one can only use exhaustive search to find any initial Hash Point. In other words, the Hash Path is a one-way path. The domain of n-bit integers, together with a randomized n-bit “salt” inclusion to the Hash Function and n ≥ 128, make external precomputation attacks (also called Rainbow Table Attacks) infeasible with modern supercomputers. To complete the security framework, the Hash Path End is separately signed with the ECDSA procedure [7].

Figure 2 (Figure 1 of [7])shows a simple stream of messages authenticated with TESLA. In this figure, the message provider first generates a complete Hash Path and holds the entire Hash Path secret except for the Hash Path End. In Figure 2, the length of the path is 100 Hash Points (HPs). Second, the provider uses ECDSA to sign the Hash Path End (HP 100) and distributes the Hash Path End with an ECDSA signature. Third, the provider sends a message (Message 1 in Figure 2) with an HMAC derived from both that message and the currently-secret “preimage” of the Hash Path End, meaning the immediately preceding HP in the Hash Path (i.e., HP 99). Fourth, the provider sends the actual preimage of the Hash Path End (HP 99), meaning it is no longer secret. Fifth, the provider returns to the third step to send a new message (Message 2) and HMAC with the secret second preimage of the Hash Path End (HP 98). This repeats until the provider runs out of preimage Hash Points, at which point it must return to the first step and regenerate a new Hash Path. The receiver’s procedure for validating this received message path is described in detail in [7].

Multi-Rate Message Authentication

Reference [7] describes an intricate procedure for extending the TESLA-based message authentication procedure to spreading-code authentication based on the generation of separate “slow” and “fast” Hash Paths from a single TESLA sequence to minimize the degradation in spreading code performance created by the insertion of watermarks for authentication (this degradation would be greater if separate Hash Paths were generated independently). This approach takes advantage of the scalability of the TESLA approach since a fixed distribution of TESLA Hash Points can authenticate any amount of information transmitted prior to the Hash Point distribution (within user computation constraints).

Figure 3 (Figure 2 of [7]) shows an overview of this procedure and illustrates the derivation of higher-rate Hash Paths from slower ones by “forking,” as defined mathematically in Section II of [7]. Each black arrow in this figure represents a “normal” hash operation as described previously. The Slow Channel (Hash Path) at the top of the figure is generated first, and the Fast Channel is created from periodic forks (green arrows) of the Slow Channel (via equations (3) and (4) of [7]) combined with normal hash operations in between Slow-Channel updates. Each HP in the Fast Channel is then forked (via equations (7) and (8) of [7]) to generate the watermarks introduced into the spreading-code signal. 

Figure 4 (Figure 3 of [7]) shows how the procedure of Figure 3 is further extended to the authentication of both code and data components of GNSS signals. In Figure 4, “Ephemeris” refers to the navigation data messages encoded within these signals that supplies satellite ephemeris information, clock corrections, satellite health, and other information. It is authenticated using “Eph Keys” generated from the Fast Channel (red and purple arrows, which correspond to equation (5) of [7] and the normal hashing process of [11]). The watermarks inserted into the spreading code are created by a two-step process from the Fast Channel (blue arrows corresponding to equation (7) of [7]) and yellow arrows corresponding to the “watermarking function” derived in Section V of [7]. With this procedure, we can authenticate all GNSS navigation message data and spreading codes with a minimal distribution and better utilize the limited GNSS data bandwidth. 

The (Near) Future of GNSS Authentication

This article and the details in [7] describe one approach to combined navigation message and spreading code authentication. However, the complexity of this and similar approaches and the need to modify both service provider/satellite transmission protocols and receiver algorithms for users who desire authentication suggests that both code and data GNSS authentication capability will not be in operation before the end of this decade. However, important steps toward this goal are already being made, starting with the easier task of authenticating navigation data messages. 

Recently, the European Union Agency for the Space Programme (EUSPA) has published an Info Note and technical details regarding a test phase for Galileo Open Service Navigation Message Authentication (OSNMA) [12, 13]. OSNMA uses a variant of TESLA to distribute cryptographic signatures authenticating Galileo Open Service navigation data messages. These signatures will be broadcast in previously reserved segments of the Galileo navigation message definition (so as not to create a demand for additional bandwidth) from a subset of Galileo satellites. Cross-authentication allows OSNMA to verify navigation data messages from all satellites using only signatures from a subset of the satellites [13]. 

Authentication of the 250-bit correction and integrity messages encoded on Satellite-based Augmentation System (SBAS) signals is also an area of active development. Reference [10] defines a combined TESLA-ECDSA technique for this that is related to the multi-rate procedure for combined code and data authentication described here and in [7]. Message authentication will help maintain confidence that SBAS continues to meet the demanding integrity requirements that apply to aviation applications of SBAS, such as precision approach under low-visibility conditions. 

Summary

GNSS signal authentication is expected to be integrated within GNSS services in the next decade or two. One approach to combined authentication of both GNSS navigation data and spreading codes is presented, and its advantages relative to other standard techniques are discussed. Making authentication feasible for future users who require or desire it requires significant changes to both service provider and user equipment and procedures. This emphasizes the need to select authentication approaches that provide the required message verification without undue signal modification, receiver complexity, or undesired effects on the bulk of existing users who will continue to operate without this feature. 

References

(1) “Sinister Spoofing in Shanghai,” Inside GNSS, December 10, 2019. 

(2) G.W. Hein, “Real World Spoofing Trials and Mitigation,” Inside GNSS, May 27, 2017. 

(3) “DHS Publishes Free Resources to Protect Critical Infrastructure from GPS Spoofing,” Inside GNSS. March 5, 2021. 

(4) “What is navigation message authentication?,” Inside GNSS, January 1, 2018. 

(5) A. Neish and T. Walter, “Securing GNSS—A Trip Down Cryptography Lane,” Inside GNSS, May 20, 2020. 

(6) “From Data Schemes to Supersonic Codes,” Inside GNSS, January 16, 2015. 

(7) J. Anderson, S. Lo, T. Walter, “Efficient and Secure Use of Cryptography for Watermarked Signal Authentication,” Proceedings of ION ITM 2022, Long Beach, CA, January 25-27, 2022 (forthcoming). 

(8) J. Anderson, S. Lo, T. Walter, “Cryptographic Ranging Authentication with TESLA, Rapid Re-keying, and a PRF,” Proceedings of ION ITM 2022, Long Beach, CA, January 25-27, 2022 (forthcoming). 

(9) J. M. Anderson, K. L. Carroll, N. P. DeVilbiss, et al, “Chips-Message Robust Authentication (Chimera) for GPS Civilian Signals,” Proceedings of ION GNSS+ 2017, Portland, OR, September 25-29, 2017, pp. 2388–2416. 

(10) J. Anderson, S. Lo, A. Neish, T. Walter, “On SBAS Authentication with Over-the-Air Re-keying (OTAR) Schemes,” Proceedings of ION GNSS+ 2021. St. Louis, MO, Sept. 20-24, 2021, pp. 4288-4304. 

(11) “HMAC,” Wikipedia. https://en.wikipedia.org/wiki/HMAC. Accessed January 11th, 2022.

(12) “Info Note Available for Galileo Message Authentication (OSNMA); Public Observation Now Underway,” Inside GNSS. December 29, 2021.

(13) Galileo Open Service Navigation Message Authentication (OSNMA): Info Note, EUSPA, December 2021. doi:10.2878/49446. https://www.gsc-europa.eu/sites/default/files/sites/all/files/Galileo_OSNMA_Info_Note.pdf.

The post Q: How could GNSS users determine in real time that their received navigation signals are correct? What methods are recommended, and when might they go into operation? appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

The value of the GPS SPS PS goes far beyond the specific parameters that it contains. It has a great deal of information regarding how GPS operates and ideally should be read in full (including the appendices) by everyone who works with GPS at the measurement level.

The post How can the parameters given in the most recent GPS Standard Positioning Service (SPS) Performance Standard (SPS PS) be used to quantify the performance of GPS applications? appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

The GNSS Solutions column in the May/June issue of Inside GNSS ([1], hereafter “Part I”) explained that error bounds valid to very low probabilities such as 10-7 to 10-9 are needed to calculate protection levels (PLs) that can be compared to safe error limits (“alert limits”) to confirm that safety is maintained in real time. It also highlighted the difficulties in creating such error bounds when the probability distributions governing GNSS errors at such small probabilities are unknown and often have tails that are fatter than those of a normal (Gaussian) distribution.

Part I addressed this problem empirically by showing how Gaussian distributions with larger (inflated) sigma values can be used to bound the tails of sampled error data. This approach is commonly used and provides some confidence that rare-event error values used to compute protection levels for GNSS applications with demanding integrity requirements are acceptably conservative. However, when inflated sigma values are determined empirically, no guarantee exists that the resulting position-domain protection levels bound actual errors to the required probabilities.

To address this problem and to further fortify the confidence that safety-of-life users have in their protection levels, a significant amount of research has focused on methods to analytically determine bounding probability distributions and parameters and identify the conditions under which such bounds are guaranteed to hold. While none of these magically solve the problem of not knowing the true error distributions, they provide a great deal of insight into why this problem is hard and what can be done to reduce bounding uncertainty without requiring extreme conservatism (e.g., very large inflation factors, which result in loss of availability). This column summarizes several important examples from this research to highlight the most useful principles and techniques.

CDF Bounding

A paper published by Bruce DeCleene in 2000 [2] was a key starting point in understanding the difficulty of analytically bounding rare-event errors and proposing analysis techniques. This paper explained the concept of cumulative distribution function (CDF) bounding that is the foundation for most practical bounding techniques. CDF bounding requires that the CDF of a bounding distribution (in the range domain) exceed the true (unknown) CDF for every error value above the mean error and be below the true CDF for every error value below the mean. When multiple statistically independent bounding distributions in the range domain are combined (convolved) together to form position-domain error distributions, the resulting distributions will also bound actual position-domain errors as long as the following conditions are met for both the bounding distribution and the underlying error distribution [2,3]:

• Both distributions are zero-mean (or any non-zero means are known and accounted for in determining error probabilities).

• Both distributions are symmetric about the mean, meaning that the shape of the probability density function (PDF) and CDF on both sides of the mean are identical. Symmetric distributions have the same mean, median, and mode.

• Both distributions are unimodal, meaning that the distribution has only one peak frequency of occurrence and continuously falls off in probability on both sides of this peak (i.e., its PDF has only one “hump”).

In practice, the bounding distribution is usually a Gaussian distribution with a standard deviation made large enough to bound data sets of actual error samples (the empirical technique in Part I uses this approach). This supports the existing Gaussian formulation of the protection level equations for civil aviation applications and makes range to position domain convolution straightforward.

The difficulty, of course, is determining if these properties hold for an unknown actual error distribution. In practice, even for symmetrical distributions, the true mean error is difficult to observe with sufficient confidence, so a conservative estimate of it needs to be included in the inflated bounding sigma. In addition, error distributions are not symmetric and unimodal in general, especially for low-probability errors. Some GNSS range-domain error sources, such as multipath and atmospheric delay, may have different distribution shapes on positive and negative sides for physical reasons. Also, multiple local maxima often occur at low probabilities in actual data, but it is hard to tell if these are due to statistical randomness or actual error behavior. As noted in Part I, the “nominal” conditions described by a single error distribution encompass many different nominal, near-nominal, and off-nominal conditions. Off-nominal events with low probabilities can be bounded by a single distribution with an inflated CDF, but they can create additional “peaks” in the PDF that violate the unimodal condition.

For illustration, Figure 1 shows the histogram (in PDF form) of a data set generated by Monte Carlo sampling from multiple Gaussian distributions with different means in the manner conducted in Part I. Table 1 shows the five Gaussian distributions sampled from and the probability that applies to each, meaning that each of the 10 million samples collected has that probability of being taken from the corresponding Gaussian distribution. Since four of the five distributions (all but r0) are biased in the positive direction by different amounts, the resulting distribution is not symmetric. In addition, because two of these distributions (r2 and r4, with means of 2.5 and 5.5, respectively) have similar probabilities of occurrence as the unbiased distribution, two humps appear at those bias values and prevent unimodality (with the hump from r2 being the highest).

Paired Bounding and Extensions

Given how difficult it is to guarantee CDF bounding by proving that the above conditions are met, subsequent work developed approaches for achieving a similar guarantee while relaxing them. One such approach is “paired bounding” as described in [3]. This approach replaces the single bounding distribution of [2] with a pair of distributions, one which “left bounds” all possible error values and another which “right bounds” all error values. Mathematically, defining GL and GR as the CDFs of the left and right bounding distributions, Ga as the unknown actual CDF, and x representing the vector of possible error values, this requires [3]:

A combination of left and right-hand bounding distributions that satisfies these conditions preserves bounding through convolution (including range-to-position domain convolution) even if these three distributions do not meet the (single) CDF bounding conditions described above.

One difficulty of this approach is the need to create and convey distinct left and right-hand bounding distributions to users whose protection-level equations assume a single bounding distribution. The implementation proposed in [3] creates separate but parallel left and right-hand Gaussian bounding distributions with the same standard deviation and the same bias magnitude as the empirical distribution used as input (i.e., a data-generated estimate of the actual distribution). Thus, only a single bias parameter is added to the standard deviation that is already transmitted. If existing user interfaces do not have room to add this bias, the broadcast standard deviation must be inflated substantially to bound this bias with a zero-mean Gaussian distribution.

Another weakness of paired bounding is illustrated in a more recent paper [4]. It is very difficult to meet the pair-bounding condition when, as just mentioned, the actual distribution (Ga) is represented by an empirical function generated from data (e.g., a histogram of error values collected into discrete bins) without excessive conservatism, such as selecting a bias value that is orders of magnitude larger than the sample mean. An extension of paired bounding using “excess mass” functions (see [5]) is one way to ameliorate this conservatism and is also applied in [4].

Single-CDF and Paired Bounding

The method proposed in [4] combines the single CDF and paired bounding techniques in a two-step process. The first step applies a heuristic algorithm to create a single discrete symmetric and unimodal distribution from the original data set (expressed as a histogram) which in general is neither symmetric nor unimodal. The second step determines the means and standard deviations of two Gaussian distributions that left-bound and right-bound the output of the first step. Because each of these two bounds starts with a symmetric, unimodal distribution but only has to bound half of its CDF (instead of all of it), the resulting bias needed to meet the CDF bounding condition is much lower than for single-step paired bounding. Matlab scripts that implement the methods described in [4] are available online at [7].

Figure 2 (from Figure 3(b) of [4]) shows this improvement graphically by comparing the CDFs of the tighter two-step Gaussian bound (in green) to the looser (more conservative) one-step Gaussian bound that would have been generated (in black) using paired bounding only. The blue line represents the CDF of the original sampled data, and the almost identical red line shows the CDF after heuristic modification to make it symmetric and unimodal.

Non-Gaussian Bounding and EVT

The methods described above focus on developing Gaussian distribution bounds for empirical error data with unknown distributions. In other words, the only knowledge of the actual error distribution (at least in the tails) comes from the collected data itself. Many examples of collected error data have tails that appear fatter than Gaussian as far as the data extends. Any form of Gaussian bounding implicitly assumes that actual error probabilities beyond those covered by the number of samples (and are thus unobservable) fall below the Gaussian tail shape, which is very optimistic since Gaussian tails fall off quickly with increasing error sizes. Even within the range of probabilities covered by the empirical data, high inflation factors are often required to bound the observed tails (see the example in Part I).

Approaches have been developed that addresses this limitation by proposing non-Gaussian (and fatter-than-Gaussian) distributions to bound the tails of the distribution. The method proposed in [6] combines Gaussian bounding of the core (center) of the actual error distribution with bounding via a generalized Pareto distribution (GPD) for the tails. Use of the GPD is motivated by Extreme Value Theory (EVT), which has been applied in many fields to approximate bounds on low-probability events. EVT states that the tails of all continuous distributions approach that of the GPD as the threshold separating the tail from the core approaches a maximum value (up to infinity—see Section 3 of [6] for details). Since the actual threshold cannot be infinite to be useful, this is an approximation at best, but the GPD is practically useful as a better model of fatter-than Gaussian tails. Section 4 of [6] describes a method of selecting appropriate threshold values and estimating the Gaussian and GPD parameters of the core and tail components that form a combined bounding distribution.

The benefits of the combined Gaussian core/GPD tail bounding approach in [6] is illustrated in Figure 3 (Figure 8 from [6]), which uses a data set of 5 years of estimated Differential GPS pseudorange errors between two NGS CORS reference stations tracking satellites at elevation angles between 30 and 35 degrees (range-domain errors are a function of elevation angle, so only measurements at nearly the same elevation angles should be combined to limit the “mixing” phenomenon described in Part I). In this figure, the y-axis probabilities are scaled such that the CDF of a Gaussian distribution is a straight line. The black line shows the empirical CDF of the observed data, which is much more closely fit by the combined Gaussian/GPD bounding CDF (dashed red line) compared to the dotted blue line formed by a single bounding Gaussian distribution. As a result, use of the Gaussian/GPD bound in (modified) protection-level calculations gives a lower protection level than would be obtained using existing protection level equations with a single Gaussian distribution.

Conclusions

This article has introduced several analytical approaches to bounding unknown GNSS range-domain error distributions with Gaussian distributions, potentially augmented with non-Gaussian tail distributions. Analytical methods have three general advantages over the purely empirical approach of Part I:

• They provide additional flexibility in modeling low-probability (tail) error behavior,

• They are more systematic and repeatable, and

• They provide theoretical assurance that the resulting bounds hold at the required integrity probabilities under certain conditions.

In practice, these advantages are useful but are less important than they might seem. The use of non-Gaussian models of errors in the tail leads to significantly tighter bounds, but it conflicts with the many existing applications whose protection level equations assume Gaussian-distributed tails only. Systematized algorithms help reduce variations due to individual judgement, but extensive judgment is still required, particularly when deciding how to collect representative error data, how to sort it into sets that represent different environmental conditions, and how much error data is needed to provide sufficient sampling of errors at low probabilities.

Finally, the theoretical bases for assured bounds generally do not apply in the real world (or, at least, they cannot be demonstrated to apply), thus they can only be assumed or “asserted.” Beyond the conditions described here, these analytical methods (and the empirical approach in Part I) assume that range-domain errors on individual satellites are statistically independent when they are combined into the position domain. This is virtually never true due to atmospheric delays being correlated in space and multipath errors being correlated by the local reflective environment. Furthermore, all these methods assume that the empirical CDFs of collected error data are perfect models of the actual error distribution out to infinitely small probabilities. Because of practical limits on the number of data samples and unavoidable differences between practical data-collection scenarios and the much larger set of environments that affect actual users, this cannot be the case either. All these factors must be kept in mind when utilizing the results of any error bounding algorithm in a safety-critical application.

References

(1) S. Pullen, “Why is bounding GNSS errors under rare or anomalous conditions important?” Inside GNSS, May/June 2020.

(2) B. DeCleene, “Defining Pseudorange Integrity—Overbounding,” Proceedings of ION GPS 2000, Salt Lake City, UT, 2000.

(3) J. Rife, S. Pullen, P. Enge, B. Pervan, “Paired Overbounding for Nonideal LAAS and WAAS Error Distributions,” IEEE Transactions on Aerospace and Electronic Systems, Vol. 42, No. 4, October 2006..

(4) J. Blanch, T. Walter, P. Enge, “Gaussian Bounds of Sample Distributions for Integrity Analysis,” ibid, Vol. 55, No. 4, October 2018.

(5) J. Rife, T. Walter, J. Blanch, “Overbounding SBAS and GBAS Error Distributions with Excess-Mass Functions,” Proceedings of 2004 International Symposium on GNSS/GPS, 2004.

(6) J.D. Larson, D. Gebre-Egziabher, J. Rife, “Gaussian-Pareto Overbounding of DGNSS Pseudoranges from CORS,” Navigation: Journal of the Institute of Navigation, Vol. 66, No. 1, Spring 2019, pp. 139-150.

(7) “Gaussian Overbound,” Stanford GPS Lab Software Tools (Online), https://gps.stanford.edu/resources/software-tools/gaussian-overbound.

The post Can Analytical Techniques Guarantee That GNSS Errors Are Bounded Under Rare Conditions? What Techniques Are Available? appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

At least two different classes of GNSS analysis software exist, although some tools support multiple objectives. The first class includes tools that predict GNSS performance based on propagating GNSS satellite orbits and calculating GNSS performance factors at specific user locations and times based on the projected locations of GNSS satellites (“satellite geometries”). The second class focuses on analysis of previously-collected GNSS measurements converted into a standard data format. This article will focus on performance prediction, and a later article within this column will examine the processing of measurement data. Future articles in this column may also consider the use of software tools to emulate GNSS receiver functions in real-time and post-processing.

One of the original motivations for software to predict GNSS performance was simply to show the quality of future GNSS satellite geometry at specific places and times. In the early years of GPS, when the GPS constellation had fewer and shorter-lived satellites than it does now, periods of weak GPS geometries (either an insufficient number of visible and healthy satellites to compute a solution or a sufficient number but with poor Dilution of Precision, or DOP, which relates range measurement error to position and/or timing error) were not uncommon. However, absent a sudden change in the health of the GPS satellites, these periods could (and can) be predicted in advance.

Trimble Online GNSS Planning Tool

The Trimble Online GNSS Planning Tool available at [3] is useful because it is easy to access and run. It is an evolution of software previously provided by Trimble to help surveyors and other users of Trimble GNSS receivers identify the periods when GNSS satellite geometries would be good enough to support their applications. Figure 1 shows the screen presented to a user when first connecting to the website. The central window shows the default user location at the intersection of the equator and the prime meridian, the elevation angle cutoff (“mask angle”) for satellite visibility, and the time period to be simulated, while the left-hand screen shows the GNSS satellite constellations that can be used (or not used) as part of the performance prediction. All of these parameters are easy to change. The user location, for example, can be changed manually or by using the map in the right-hand window, while the usable satellites can be set by constellation or individually by satellite (using the “Satellite Library” menu tab). When constellations are selected to be used, all satellites marked as “healthy” by the latest almanac downloaded for that constellation are set to be used, while those marked as “unhealthy” are set as unused, but this can be changed on a satellite-by-satellite basis.

Figure 2 shows a scenario in which the user location has been changed to St. John’s, Newfoundland and Labrador, Canada, to investigate GNSS performance at higher latitudes. The left-hand window shows that only GPS satellites are used in this scenario and that 30 GPS satellites are healthy in the latest almanac. The time of interest is set to be the 24 hours following midnight Universal Time (UT) on Christmas Day, 25 December 2019 (note that local time in St John’s is 3 hours and 30 minutes behind UT in winter), and the elevation mask angle is left at the default value of 10 degrees.

Figure 3 shows two of the plots obtained by selecting the “Charts” menu item at the top of the screen. The upper plot shows the number of visible (and healthy) GPS satellites in view over the selected time period, and the lower plot shows five varieties of DOP values over this period, differentiated by different line colors. (The cursor can be placed at any point within the plot to read off exact numbers.) These plots show that between 7 and 12 healthy GPS satellites are visible over this period, and the PDOP (3D position DOP, not including time) varies between about 1.3 and 3.5, which is significant.

Figure 4 shows these same two plot results when the scenario is changed to use all satellite constellations. Now, as expected, the picture is very different, as GLONASS, Galileo, and BeiDou satellites also contribute significantly to positioning geometry (QZSS and IRNSS are used but are not visible at this location). The total number of visible and healthy satellites now ranges from 24 to 35, and PDOP varies between about 0.8 and 1.3. Not only are the DOPs much improved from before, but their variation with time decreases, making it much more unlikely that periods of unavailability will exist.

A key limitation of this tool is that all satellites are treated as having identical performance (both within and across constellations) except for being healthy or unhealthy, and key details such as satellite almanac parameters are fixed and cannot be changed. To perform more in-depth studies of GNSS performance, tools that allow access to these details and allow users to design their own performance metrics are needed.

Stanford MAAST

The Stanford Matlab Algorithm Availability Simulation Tool, or MAAST, is available at [4] and is a publicly-available set of source-code scripts that run within Matlab (and require a Matlab license to use). MAAST was originally developed about 20 years ago to predict Satellite-based Augmentation System (SBAS) performance (now “MAAST Version 1.4”) and has more recently been extended to support Advanced RAIM or ARAIM analysis (in “MAAST for ARAIM Version 0.4”). Dated but useful information on using and modifying MAAST software is contained in the “User’s Guide” and “Developer’s Guide” also available at [4]. Both versions of the MAAST source code can be modified and extended to support other GNSS applications.

The script “maast.m” within the SBAS version of MAAST currently runs a script called “maastgui.m,” which provides a graphical user interface (GUI) that allows users to change settings and execute performance simulations. This can be changed to instead run “maast_no_gui.m,” which allows these settings and parameters to be altered within the Matlab files. Figure 5 shows the control panel of the GUI after it has been altered to change certain parameters, including the values of UDRE (satellite clock/ephemeris error after SBAS corrections), GIVE (grid ionospheric vertical error after SBAS corrections), CNMP (receiver code noise and multipath error) models, user grid (covering all of North America in a grid of 2 × 2 degrees in latitude and longitude), GPS satellite almanac (the Yuma almanac for GPS Week 35 as of early December 2019, downloaded from the U.S. Coast Guard Navigation Center website at [5] and copied into the MAAST folder), the time update interval (one day at 300-second or 5-minute updates starting from the time of applicability of the almanac), the alert limits for SBAS-supported LPV approaches (HAL = 40 m, VAL = 35 m, corresponding to LPV-200, meaning LPV down to a 200-ft minimum decision height), and the output contour plots desired (vertical and horizontal protection levels, VPL and HPL, in addition to LPV-200 availability).

Pressing the “RUN” button at the lower right in the GUI starts a MAAST simulation with these parameters that generates the selected plots. Figure 6 shows the resulting contours of LPV-200 availability, which is defined as the probability at a given user grid location over the 288 simulated GPS geometries that VPL ≤ VAL and HPL ≤ HAL. The color scale at the bottom of the figure indicates the range of availability achieved within each contour, and these contours show how LPV-200 availability with these settings varies from above 99.9% (meaning in this case that all 288 geometries are available) near the center of the simulated reference station network to lower values farther away from the center of North America. The “Coverage(95%)” statistic at the bottom right indicates the percentage of user locations in the 2 x 2 user grid within the map that have availability of 95% or higher. It is less than 50% because the majority of the user grid is far away from the reference station network and does not expect to obtain high availability from SBAS.

Since vertical positioning is more challenging than horizontal positioning for GNSS, and because VAL is below HAL for LPV-200, the VPL ≤ VAL constraint on availability dominates the similar constraint on HPL. Figure 7 shows contours of 95th-percentile (95%) values of VPL from the same run that generated the availability results of Figure 6.These contours roughly (but not exactly) correspond to those of Figure 6, as the region in Figure 6 where availability exceeds 95% (light blue or darker) is similar to the region in Figure 7 where 95% VPL is below the VAL of 35 meters (light green or darker).

Note that, because the parameters shown in the GUI settings of Figure 5 (particularly the fixed values of UDRE and GIVE) are idealized and only roughly approximate actual SBAS values, these results do not mirror those achieved by today’s SBAS in North America (WAAS). Non-public versions of MAAST include the actual (proprietary) WAAS algorithms and give very accurate predictions for today’s WAAS as well as variations that are being considered for the future. The internal code of public version of MAAST described here can be modified to input WAAS UDRE or GIVE maps stored online, such as those provided in real time at the FAA NSTB website [6].

To show how to modify MAAST internal code scripts, it is easier to start with the ARAIM version mentioned above, which only runs in offline mode (starting with “main_maast_araim.m”). ARAIM is an evolution of traditional RAIM that uses multiple hypothesis solution separation to support real-time monitoring of multiple-satellite and constellation faults and is thus not limited to single-satellite faults, as is traditional RAIM. A detailed algorithmic description of ARAIM is at [7] (also see [Blanch, et al, 2015]).

Figures 8 and 9 show the results of running the default ARAIM version of “main_maast_araim.m” except for two changes to reduce the granularity in the results. The first change (at lines 214-215) is to change the worldwide user grid to 5 × 5 instead of 10 × 10 degrees. The default ARAIM user grid covers almost the entire world because it is based on uncorrected (“standalone”) GNSS measurements and is not region-limited, as is SBAS. The second change (at line 225) reduces the interval between time epochs from 300 to 60 seconds, meaning that 1440 separate epochs are run to complete 1 day. Note that, unlike for SBAS, this ARAIM simulation uses a combination of 24 GPS satellites and 24 Galileo satellites to provide high availability of LPV-200 while also considering possible faults of all satellites in one constellation or the other.

The availability contours in Figure 8 show that the use of both GPS and Galileo (with the assumed default parameters) provides LPV-200 availability of 99.9% or better in most locations on Earth. Some high-latitude locations in both northern and southern hemispheres (at latitudes above the inclinations of GPS and Galileo satellite orbits) have availabilities as low as 99%. The contours of 99.5th-percentile VPL in Figure 9 show that it is these high latitudes that have the highest probability of VPL exceeding the 35-meter VAL for LPV-200. Within 60 degrees of the Equator, the 99.5th-percentile VPL appears to never exceed 35 meters.

Again, the key advantage of the no-GUI version of MAAST is the ability to modify any of the parameters or algorithms that are described in the code. Table 1 summarizes where several key aspects of the ARAIM performance model are described in MAAST code files so that specific changes are easier to make.

Other Performance Analysis Tools

Several other GNSS analysis tools are freely available online, including the GPS Toolkit (GPSTk) [8] and RTKLIB [9]. Both of these are extensive and capable packages that support measurement analysis and position calculations based on data collected from GNSS receivers and stored in RINEX or other formats. A description of tools like these will appear in a subsequent article in this column.

Useful Links

SatNav Toolbox for Matlab

GPS Propagator for STK 

Trimble GNSS Planning Online

Stanford Matlab Algorithm Availability Simulation Tool (MAAST)

U.S. Coast Guard Navigation Center website for GPS NANUS, ALMANACS, OPS ADVISORIES, & SOF

Federal Aviation Administration William J. Hughes Technical Center WAAS Team test site

ARAIM Reference ADD, Version 3.0 (2017)

GPS Toolkit (GPSTkt) 

RTKLIB: An Open Source Program Package for GNSS Positioning

Additional Reading

The post What freeware or open-source software packages are available to support GNSS performance evaluations? appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.