Many parts of critical infrastructures rely on uninterrupted access to GNSS positioning, navigation and timing services, but, at the same time, threats to denial of GNSS services are increasing. Radio frequency interference can be unintentionally emitted by commercial high power transmitters, ultra-wideband radar, television, VHF, mobile satellite services and personal electronic devices. Moreover, malicious intentional interference is produced by jammers, whose rapid diffusion is becoming a severe threat to GNSS.

To ensure GNSS is protected, there is now a need to respond at an international level to ensure that there is: i) a common standard for real-world GNSS threat monitoring and reporting, and ii) a global standard for assessing the performance of GNSS receivers and applications under threat. GNSS threat-reporting standards would allow for compilation of real-world threats into a database that could be analyzed to develop GNSS receiver test standards that ensure new applications are validated against the latest threats. Both standards are missing across all civil application domains and are considered a barrier to the wider adoption and success of GNSS in the higher value markets.

This article discusses the STRIKE3 project that was specifically developed to address the issues outlined above.

STRIKE3 Overview

The STRIKE3 (Standardizsation of GNSS Threat reporting and Receiver testing through International Knowledge Exchange, Experimentation and Exploitation) project is a European initiative that addresses the need to monitor, detect and characterize GNSS threats to support the increasing use of GNSS within safety, security, governmental and regulated applications. STRIKE3 has deployed an international network of GNSS interference monitoring sites that monitor interference on a global scale and capture real-world threats for analysis and to ultimately test GNSS receiver resilience.

Using thousands of threats collected from their network over a three-year period, STRIKE3 has developed a baseline set of threats that can be used to assess performance of different GNSS receivers under a range of typical real-world interference/jamming threats. The resulting specification consists of five different threats: wide swept frequency with fast repeat rate, narrow band signal at L1 carrier frequency, triangular and triangular wave swept frequency and tick swept frequency. For details of how these five threats were selected, refer to the Additional Reading section at the end of the article.

Finally, the STRIKE3 project has begun using its test specification to test receiver performance in the presence of various threats. Below is a discussion of how this is done as well as some results for a specific type of interference.

Collectively, the above activities aim to improve mitigation and resilience of future GNSS receivers against interference threats.

Receiver Testing

The main objectives of the testing component of the STRIKE3 project are: first, to validate the proposed testing standards to demonstrate they are clearly defined, useful, and practical; and second, to assess performance of a variety of receivers against real-world threats detected by the STRIKE3 monitoring network. Using real-world threats detected at the monitoring sites enables interested stakeholders (e.g., certification bodies, applic

ation developers, receiver manufacturers, etc.) to better assess the risk to GNSS performance during operations and to develop appropriate countermeasures.

The remainder of this article presents some illustrative examples for multi-GNSS mass-market and professional grade receiver testing against a single interference type that is very commonly detected at STRIKE3 monitoring sites, namely a triangular chirp swept frequency signal as depicted in Figure 1.

The test platform used is shown in Figure 2. The clean GNSS signal is generated from a multi-constellation, multi-frequency Spectracom GSG-6 hardware simulator, whereas the threat signature is generated using a Keysight Vector Signal Generator (VSG) N5172B through the replay of raw I/Q (In-phase/Quad-phase) sample data. Raw I/Q data captured in the field for a real-world event is used as input to the VSG which then re-creates the detected threat by continuously replaying the data in a loop.

Both the GNSS signal simulator and the VSG are controlled via software in order to automate the testing process. The automation script is used to control these devices remotely and to limit human intervention. The script also provides synchronization between the two instruments in order to ensure repeatability of the tests and the reliability of the results.

The clean GNSS signal and the interference signal are combined using an RF combiner, and the interferencecontaminated GNSS signal is fed to the Receiver Under Test (RUT), which produces its own output metrics. For the validation of

baseline performance under nominal signal conditions, the VSG does not generate any interference signal. In this case, the input signal to the RUT is only the clean GNSS signal produced by the GNSS constellation simulator.

A laptop is used to record and analyze the performance of the receiver against the different threat signals. The analysis is performed using a MATLAB-based script that processes the NMEA output messages from the RUT.

For each receiver category — namely mass-market and professional grade — three different test methodologies are performed:

• Baseline – a clean GNSS signal in the absence of interference is fed to the RUT to validate its performance under nominal conditions. The total duration of this test is 60 minutes.
• Time To Re-compute Position (TTRP) solution – this test is used to measure the time taken for the RUT to recover after a strong interference event. In this test, the interference is switched on 14 minutes after the simulated scenario starts and it is applied for 90 seconds. The interference power is fixed to a value such that the receiver immediately loses its position solution. In this test case scenario the interference power corresponds to a Jamming-to-Signal (J/S) ratio of ~90 dB. The time taken between switching off the interference source and the first position fix is recorded as the TTRP. The profile of this test

  

  methodology, whose total duration is 30 minutes, is illustrated in Figure 3.

• Sensitivity – this test scenario is conducted by varying the power of the interfering signal. The interference is turned on 10 minutes after the simulation starts and it follows a two-peak ramp power profile. The initial interference power is such that J/S is ~5 dB, and then the interference power is increased by
  5 dB every 45 seconds until reaching a J/S of 65 dB. After the first peak has been reached, the interference power is decreased in a reverse manner. The power profile is then repeated a second time. The profile of this test methodology is illustrated in Figure 4.

In order to assess the performance of the RUT in the presence of interference, different metrics were selected. The following outputs from the GNSS receiver are recorded and analyzed for all the test methodologies:

• Number of tracked satellites
• Position fix indicator (a Boolean to indicate if a 3D position fix is available or not)
• Number of satellites used in fix
• Carrier-to-Noise density (C/N0) ratio
• East-North-Up position error

Moreover, depending on the test methodology, additional parameters are evaluated. For example, in the case of the TTRP test method, the time tak

en for the RUT to re-obtain a position fix after a strong interference event is measured. For the sensitivity test method, the Jamming-to-Signal ratio at which the position solution is no longer available and the availability of the position solution during the interference event are computed. Furthermore, position accuracy statistics are computed for the interval in which the interference is present when the receiver offers a valid position fix.

Currently, only GPS L1 and Galileo E1 signals are used for testing and the RUT is configured to operate in static stand-alone mode.

Table 1 provides an overview of the simulated scenario settings, including the receiver location, the start time, the duration, the GNSS signal power and the interference power levels for the different test methodologies.

When performing the tests, an elevation mask of 5° is applied for the Position, Velocity and Time (PVT) computation. The RUT’s default C/N0 mask is used in all cases. The RUT settings are summarized in Table 2.

Results

This section presents the results of the standardized tests of a mass-market and a professional grade receiver against one of the most frequently detected interference types at STRIKE3 monitoring sites. The spectrum and the spectrogram of such interference signal are sho

wn in Figure 1.

The accuracy and availability of the receiver’s position solution during the interference interval is analyzed in the sensitivity tests. As the interference power increases, the receiver performance continues to degrade and at some point the RUT loses the position fix. The East-North-Up (ENU) deviations of the position solution for the mass-market (top) and the professional grade receiver (bottom) are shown in Figure 5.

Both receivers offer inaccurate position solutions in the beginning, especially in the vertical component. This is due to the cold start and the resulting unavailability of ionospheric parameters, and to the convergence of the navigation filter.

It can be seen that the mass-market RUT prioritizes the availability of the position solution over its accuracy. In particular, during the interference interval, there are only a few epochs at which the receiver does not yield a solution, but this high yield comes with degraded positioning accuracy.

On the other hand, the professional grade RUT prioritizes the accuracy over the availability. It does not offer the position solution as often during the interference interval, but when it does the position errors are minor.

In order to have a better understanding of the interference impact on the RUT, a comparison with respect to the baseline test case is also carried out. Figure 6 shows the drop in the average C/N0 of the satellites used in position fix with respect to the baseline for the entire duration of the test. As expected, in the presence of interference, the signal quality worsens as the interference signal’s power increases. Given the wideband nature of the interfering signal, GPS and

Galileo are affected similarly.

The difference between the mass-market and the professional grade receivers’ behavior is also visible here. While the former continues to use very low quality signals in order to provide a position solution, even if inaccurate, for as long as possible, the professional grade RUT stops computing the solution when the signal quality decreases by about 20 dB.

A summary of the results is given in Table 3. The maximum horizontal and vertical errors are computed for the interval in which the interference is present when the receiver offers a valid position fix. As already discussed, the position fix availability during the interference interval for the mass-market receiver is high at the expense of position accuracy. On the other hand, the professional grade RUT preserves the position accuracy at the expense of solution availability: the maximum horizontal and vertical errors in the test case are only slightly larger than in the baseline case.

The J/S at which the position solution is no longer available, J/SPVT_lost, is also determined. It can be observed from Table 3 that the mass market RUT has much higher sensitivity as compared to professional grade RUT, when manufacturer’s default receiver settings are used. Finally, it can be observed that TTRP values are much better for mass-market RUT than professional grade RUT.

Conclusion

Given the increasing dependence on GNSS technology and its vulnerability to intentional and unintentional interference, it is important to understand the magnitude and evolution of the GNSS threat scene. The STRIKE3 project is addressing this need through the development of monitoring and reporting standards, the deployment of a worldwide monitoring network to test the reporting standards and to provide a database of real-world events, the development of receiver testing standards against threats, and an intensive testing activity against the detected real-world interferences in order to test the resilience of different multi-GNSS receivers.

Additional Reading

For more details on the European H2020 project ‘STRIKE3’, please refer to: STRIKE3 (2016) Standardizsation of GNSS Threat reporting and Receiver testing through International Knowledge Exchange, Experimentation and Exploitation [STRIKE3]. http://www.gnss-strike3.eu/.

For more details on STRIKE3 proposed GNSS threat reporting standards, please refer to: Thombre, S., Bhuiyan, M. Z. H., Eliardsson, P., Gabrielsson, B., Pattinson, M., Dumville, M., Fryganiotis, D., Hill, S., Manikundalam, V., Pölöskey, M., Lee, S., Ruotsalainen, L., Söderholm, S., Kuusniemi, H. (2017) “GNSS Threat Monitoring and Reporting: Past, Present, and a Proposed Future”, The Journal of Navigation 71(3):513-529.

For more details on draft standards for receiver testing against threats, please refer to: Pattinson, M., Sanguk, L., Bhuiyan, M. Z. H., Thombre, S., Manikundalam, V., Hill, S. (2017) “Draft Standards for Receiver Testing against Threats”, available online via: http://www.gnss-strike3.eu/.

Authors

Nunzia Giorgia Ferrara is a Research Scientist in the Department of Navigation and Positioning at the Finnish Geospatial Research Institute and a PhD candidate at Tampere University of Technology where she was a Marie Curie Fellow from 2014 to 2016. Her research focuses on multi-GNSS receiver design and interference detection and mitigation.

Dr. M. Zahidul H. Bhuiyan is working as a Research Manager at the Department of Navigation and Positioning in the Finnish Geospatial Research Institute. He is also serving as the head of the Satellite and Radio Navigation research group of the institute. His main research interests include various aspects of multi-GNSS receiver design, GNSS vulnerabilities, SBAS, differential GNSS, etc.

Amin Hashemi is a Research Scientist with the Navigation and Positioning department of the Finnish Geospatial Research Institute. His current focus is on

localizing GNSS interference sources.

Dr. Sarang Thombre is a Research Manager and Deputy Leader of the Satellite and Radio Navigation research group at the Department of Navigation and Positioning of FGI. He earned his Ph.D. degree in April 2014 from Tampere University of Technology, Finland. His research interests include GNSS receiver design and implementation, autonomous vehicle PNT techniques, and RF interference to GNSS.

Dr. Michael Pattinson is a Principal Navigation Engineer at NSL and jointly leads the Safety and Integrity business unit. His main activities include advanced position techniques (high accuracy and high integrity), as well as GNSS performance monitoring and anomaly investigation to enhance GNSS robustness and reliability.

The post How can we ensure GNSS receivers are robust to real-world interference threats? appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

An end-to-end simulation is presented using the Positioning and Integrity Performance Evaluator (PIPE). The simulation includes side by side comparison of a vehicle path in the presence of spoofing as evaluated by the authors’ Generalized Pseudo Bayesian 1 (GPB1) algorithm and a snapshot least squares algorithm. Every field application has its own operational conditions and resulting requirements with respect to accuracy, availability, and continuity for systems that provide position, velocity, and time (PVT) measurements. For example, Global Satellite Navigation Systems (GNSS) found application for certain approach procedures in commercial aviation due to the advent of Satellite Based Augmentation Systems (SBAS) that provide additional integrity information to GNSS receivers. GNSS reception environments for aircraft are nominally clear-sky conditions and the combination of GNSS, SBAS, and advanced processing techniques like Receiver Autonomous Integrity Monitoring (RAIM) yields the required compliance for probabilities of detecting malfunctions and times-to-alert.

Providing absolute, three-dimensional positions on Earth together with well-proven and cost-efficient receiver technologies predestines GNSS equipment to enter the emerging markets of land-based users such as autonomous vehicles and the railway industry. However, since the operational conditions of these applications differ dramatically from those present in the aviation world, PVT measurements with integrity based on GNSS as previously developed cannot be translated directly to land-based users.

This article presents the scope and an application example of the Integrity for Navigation Land Users (INLU) research study as part of the European Space Agency’s Technology Research Program (see Additional Resources, J. Wendel et alia (2016a)) that develops techniques to provide PVT solutions to land-based users within defined integrity bounds.

The environments in which landbased users move impose reception limitations on GNSS receivers. In cities, the GNSS signals are frequently blocked and reflected by buildings, structures, and other traffic, for example. The same is true for railway applications. Here, GNSS blockages arise from features ranging from shunting yards over railway stations to rides through cuttings and tunnels.

To be able to create new satellite navigation technologies that provide PVT information with integrity and solutions for high-precision positioning even under difficult conditions, a well-suited end-to-end simulation tool is required. End-to-end means that realistic signals from complete satellite constellations can be generated which take, for example, transmitter and receiver antenna characteristics, atmospheric and local wave propagation mechanisms, receiver dynamics, and other distorting effects into account.

Often such end-to-end simulations are performed using a radio frequency constellation simulator (RFCS) and hardware GNSS receivers. A number of commercial off-the-shelf solutions are available for each of these items. However, for the development of said algorithms, it is more efficient to be able to use pure software or hybrid hardware/ software solutions. This allows for a much higher frequency for the development-integration-test cycles of a project.

To respond to INLU’s requirements and to meet today’s needs of GNSS endto- end simulations, Airbus Defense and Space has been developing the Positioning and Integrity Performance Evaluator (PIPE) as a research activity since 2012. Beyond INLU, PIPE found applications for the development of novel tracking (F. M. Schubert et alia (2014a); F. M. Schubert et alia (2015)) and channel model research (I. Gulie et alia; F. M Schubert et alia (2016)), to name a few examples.

The article’s organization follows the high-level procedure of getting results from an end-to-end simulation run using PIPE. We first describe the scenario definition in terms of user trajectory, satellite constellation, and propagation channel conditions. Next, the configuration of the simulated receiver is reported with methods for acquisition and tracking of GNSS signals and computation of the PVT solutions. An example is then given that reports a filter bank approach developed during the INLU project. It is used for mitigating the influence a spoofer has on the receiver’s performance.

Scenario Generation

Figure 1 reports the general structure of end-to-end GNSS simulations that can be performed using PIPE. PIPE consists of three groups of programs: tools for digital signal processing (DSP), a GNSS scenario and constellation simulator, and a GNSS receiver. PIPE’s DSP provides classical signal chain simulations consisting of a signal source, one or multiple signal processors, and a signal sink. Among other programs, PIPE includes GNSS signal generators, filters, up- and down-converters, and interference signal generators.

PIPE’s scenario and constellation simulator programs are able to generate user trajectories, satellite positions for given times and orbits, and the propagation channel response based on multipath components. As this group of scenario-related programs differs from the DPS programs, they are called SNIPE tools — short for Scenarios for Navigation and Integrity Performance Evaluation. INLU also requires the possibility to process real-world signals. Signal sources for the PIPE receiver can be sampled signals as sensed by antennas, the PIPE software GNSS signal generator, or samples recorded from an RFCS’s output.

PIPE accommodates INLU’s diverse requirements by a modular approach of signal chain simulations: Certain software elements of the chain can be replaced by hardware components. Additionally, interfaces to front-end sampling and replay devices are available.

The following subsections describe the creation of the user’s trajectory, the simulation of a satellite constellation as well as the processing of the response stemming from a propagation channel model.

Trajectory Generation

The first step in the scenario generation process is the creation of the user’s trajectory. This trajectory serves as input for the generation of GNSS observations, as well as further sensor data like odometers, inertial sensors, baro-altimeters, and magnetometers. The challenge hereby is to produce consistent dynamics data. When the accelerations and angular rates provided by the trajectory generator are used for the generation of inertial sensor data assuming an ideal inertial measurement unit, the output of an ideally initialized strapdown algorithm must match the original trajectory exactly, even after longer simulation times. This is achieved in the trajectory generator first by producing desired positions and attitudes over time. Then, a strapdown algorithm together with a flight control-like algorithm is applied. From the small offsets between desired positions and attitudes and the strapdown state, accelerations and angular rates are generated, which are provided to the strapdown algorithm in the next epoch and drive these offsets to zero.

Constellation Simulation

From the trajectory generation, the GNSS antenna positions and velocities also can be calculated at equidistant points in time. For each of these points, the constellation simulation needs to calculate the corresponding satellite positions and velocities based on RINEX files. The trajectory time scale defines the times of reception of the satellite signals. In order to calculate the satellite positions and velocities, the times of transmission at the satellite need to be determined. This is achieved by approximating the satellite orbit in a time interval of T=0.1 seconds by a straight line, which is accurate to the sub-millimeter level. Denoting the time of reception with t0, the satellite position pS at the time of transmission t0–t can be expressed as

It must now be considered that the ECEF frame is rotating. The ephemeris describes the satellite position in the ECEF frame at the point in time for which a satellite position is calculated. In order to express the satellite position at t0–T in the ECEF frame that is valid at t0, the rotation of the ECEF frame in the time interval T needs to be considered:

In the following, pS(t0–T) always refers to the satellite position at t0–T, expressed in the ECEF frame at t0. In order to determine the time of flight of the satellite signal t, the equation relating the range between satellite position at time of transmission, pS(t0–t), and antenna position at time of reception, pA(t0), is used:

Here, c denotes the speed of light. Inserting the linear approximation of the satellite orbit and squaring the equation leads to

This is a quadratic equation that can be solved for the time of flight, t. Consequently, the satellite position at time of transmission, pS(t0–T), in coordinates of the ECEF frame at time of reception, t0, is obtained. The carrier phase, code phase, and Doppler measurements obtained at t0 can then be generated using appropriate error models.

Propagation Channel Models

The reception conditions for land-based users are impacted to a large extent by multipath propagation caused by objects and structures in the receiver’s vicinity. Moreover, in urban areas, signals are often blocked and diffracted by buildings and trees. State-of-the-art multipath propagation models reproduce these effects and generate channel impulse responses (CIR) at a given rate dependent on the receiver’s dynamics. CIRs contain components that reflect the complex amplitude and delay of line-of-sight as well as multipath components.

PIPE’s interface to a channel response generated by a multipath propagation model is given by the Channel Data Exchange format (CDX) (see CDX – Channel Data Exchange Library in Additional Resources). The PIPE GNSS signal generator can read the channel impulse response for every time step from a CDX file and generate the corresponding multipath components with their respective delays and complex amplitudes in the output signal. This allows for the usage of various channel models for INLU. Within the project, the model recommended by ITU-R P.681 for urban environments was used. Additionally, this model was extended for railway applications during a research activity (I. Gulie et alia). Figure 2 shows the visualization of a common railway scenery.

The INLU project also requires the generation of RF signals by hardware constellation simulators using the mentioned channel models. As these models produce more multipath components than a common hardware constellation simulator can re-produce, a component count reduction step is required. In INLU, a method based on F. M. Schubert et alia (2014b) is applied.

Land User Receiver Prototype

The PIPE GNSS Receiver used to run the INLU simulations is not only able to process samples, bit-true mode in INLU terms, it has also a semi-analytic operation mode that calculates correlation results based on pre-computed autocorrelation functions of GNSS signals. The semi-analytic mode runs multiple times faster than the bit-true mode and allows for simulation of long runs. The scenario input data as well as the receiver’s implementations for items such as tracking loops and PVT computation are identical for both modes.

Tracking Algorithms

In addition to standard tracking methods like Early-Minus-Late and Bump Jumping, the PIPE receiver offers a number of state-of the-art tracking techniques, such as the Double Delta Correlator, Kalman filter-based methods, Double Estimator, and Maximum Likelihood-based methods, such as Multipath Estimating DLL and Vision Correlator. All these methods are scrutinized during the INLU project. For the following example, the Astrium Correlator (AC) is applied which offers robustness against locks to false side peaks while tracking binary offset carrier (BOC) signals (F. M. Schubert et alia (2014a)). For signal tracking, the AC uses a BOC’s signal subcarrier to exploit the higher accuracy that can be achieved when tracking such signals to the legacy binary phase shift keying (BPSK) signals. At the same time, the AC checks if it tracks the BOC signal’s central peak via the observation of the BPSK envelope of the signal. If a lock to a side peak is detected, the tracker is commanded to switch its tracking point toward the correct main peak.

Integrity Algorithms ARAIM Tailored to the Railway Environment

The main objective of INLU was the development of integrity algorithms tailored to the land user environment. The following integrity concept for railway users was developed as an INLU scenario.

Providing integrity for train position information is a major technical challenge due to the small integrity risk that is tolerated in railway applications. In the current implementation of the European Rail Traffic Management System (ERTMS), the train position is propagated using odometry, and corrected when a balise group is reached. A balise is a transponder that provides an absolute location reference to the on-board unit of the train, allowing the train to locate itself within a movement authority. GNSS positioning is being considered in the context of the ERTMS evolution for the realization of a virtual balise concept, where GNSS is used for the detection of virtual balises. The approach of virtualizing the balise transmission system aims to reduce the cost of trackside infrastructure associated with the installation and maintenance of physical balises, while minimizing changes to the existing system and maximizing interoperability. Consequentially, requirements on the integrity of position information provided by the GNSS receiver are very stringent.

The integrity concept within INLU can be seen as a step towards a realization of the virtual balise function. A block diagram of this concept is shown in Figure 3. The integrity algorithm processes pseudorange measurements from a GNSS receiver, measurements from odometry, and exploits information contained in a map database. It consists of two major building blocks, a module for pseudorange measurement rejection, and the integrity module that calculates the projection level.

The measurement rejection module consists of a Kalman filter that integrates the odometer measurements with the track database and the pseudoranges from the GNSS receiver. The a priori position available from this filter is used to calculate the Mahalanobis distance of each pseudorange, and upon excess of a pre-defined threshold for the Mahalano-bis distance, the respective pseudorange is rejected.

The integrity module calculating the projection levels uses the pseudoranges that passed the Mahalanobis distance check in the measurement rejection module as well as information from the track database. In consequence, the position solution provided by the integrity module is independent of the odometry, in the sense that the odometer readings do not enter in the position calculation. For projection level calculation, a solution separation approach is used. In solution separation RAIM, the spread of subset position solutions with respect to the full set position solution is assessed. Subset position solutions are obtained by excluding subsets of satellites from the position calculation. Thus, the number of satellites that are excluded must reflect the number of simultaneous faults that need to be considered. The probability that a higher number of simultaneous faults occurs is very low, but might still be included in the integrity risk budgeting.

The major difference between a conventional solution separation RAIM outlined above and the proposed integrity concept is that from the pseudoranges which have passed the measurement rejection module, a three dimensional position solution is not calculated, but rather a GNSSbased odometer distance results. Using this GNSS-based odometer distance, a three-dimensional position solution can then be obtained from the track database. Consequently, for the calculation of protection levels, the spread of GNSS-based odometer distances is assessed, not the spread of position solutions. Obviously, calculating a GNSSbased odometer distance instead of a three dimensional position reduces the number of unknowns from four to two, which means that with two pseudoranges only, a solution can be obtained. More details of this integrity algorithm are given by J. Wendel et alia (2016b).

Filter Bank for GNSS and INS Integrity

Within the INLU project, integrate navigation systems were also addressed, in which the software GNSS receiver is combined with inertial sensors in loose, tight, and ultra-tight coupling architectures. Such architectures do not allow for the calculation of protection levels using ARAIM algorithms because these require that full set and subset position solutions are calculated using snapshot least squares.

A variety of techniques can be found in literature which aim at the provision of integrity for integrated navigation systems. Batch processing approaches re-formulate the GNSS/INS data fusion as a least squares problem, which then allows us to apply RAIM or ARAIM techniques (M. Joerger and B. Pervan). Another option is to use a filter bank. Each elemental filter in the filter bank is robust with respect to a specific fault.

In the simplest case, an elemental filter does not process the measurements of a specific satellite. In case the measurements of this satellite are faulty, this filter is not affected. This also avoids the need for a pseudorange fault model which is an advantage because such a model is in general rarely available. Examples of filter bank approaches can be found in (M. Brenner; J. Diesel and S. Luu), with the basic concept illustrated in Figure 4 with three filters only. Obviously,
a real GNSS/INS filter bank contains many more filters. For the single fault case, the number of elemental filters matches the number of satellites from which measurements are available, with possibly an additional elemental filter assuming no faults are added. Each of the elemental filters propagates its state and covariance matrix forward in time using the measurements provided by an inertial measurement unit (IMU).

When pseudorange and delta range measurements become available, they are processed by each elemental filter except for those the elemental filter assumes to be faulty. Hereby, the model probabilities are also updated. For each elemental filter, the model probabilities represent the likelihood that the assumptions of the filter are correct, i.e., that the satellites that the elemental filter assumes to be faulty actually are faulty. This update is based on the ability of the filter to predict measurements. The better the elemental filter pseudorange and delta range predictions match the actually available measurements, the higher the model probability.

After the measurement processing, a mixing step is executed. In this mixing step, each elemental filter is reinitialized with a new state estimate and covariance matrix, which are calculated from the model probabilities, state estimates, and covariance matrices of all elemental filters. It is important to note that for the most widely used filter bank, i.e., the Interacting Multiple Model (IMM) filter bank, all elemental filters are initialized differently. Therefore, state and covariance of each elemental filter must be propagated separately, even if all elemental filters assume the same system model.

The main drawback of such a filter bank is the huge computational load. In most integrated navigation systems, most of the computational cost is spent in the propagation step. The reason for this is that the state and covariance matrices of the navigation filter must be propagated with a reasonable update rate in order to cope with the vehicle’s dynamics. For example, in a GNSS/INS system, several propagation steps are performed (for example, every 5 milliseconds when the inertial sensors provide measurements) before one measurement step takes place, i.e., every second when a typical GNSS receiver provides measurements. With the values given in this example, 200 propagation steps are performed before one measurement step is performed.

Within the INLU project, a GNSS/INS integrity algorithm based on a Generalized Pseudo-Bayesian 1 (GPB1) filter bank was developed. The only difference between an IMM and a GPB1 filter bank is the mixing step. For the GPB1 filter bank, the mixing step initializes all elemental filters identically. As all the elemental filters have the same system model — namely the error propagation equations of inertial navigation plus additional states to estimate the inertial sensor biases — the use of a GPB1 filter bank allows INLU to perform propagation steps with one elemental filter only, instead of with each elemental filter of the filter bank. Then, when GNSS measurements become available, all elemental filters are initialized with the propagated state and covariance of this first elemental filter before each elemental filter processes the measurements. This approach avoids, to a large extent, the increase in processing complexity typically connected to filter bank integrity algorithms.

Application Example: Spoofing Scenario

The previously introduced technique is demonstrated with a scenario employing a spoofer using a hardware constellation simulator. The scenario simulates a short drive of a land vehicle. The multipath environment was generated according to the ITU-R P.681 channel model; nominal Galileo and GPS constellations were assumed. Additionally, an ideal spoofing of one Galileo and one GPS Open Service signal was simulated. From a certain point in time onwards, a ramp on the pseudoranges of the respective satellites was generated, starting from zero. Using this RFCS scenario, baseband samples were recorded and then post-processed with the PIPE Receiver. Additionally, artificial inertial sensor data simulating a medium-grade MEMS was generated.

The results of the post processing of the recorded baseband samples are shown in Figure 5. The trajectory starts in the left upper corner and follows the road that is visible in the Google Earth picture. Two different PVT solvers were used: a snapshot least squares solver that produced the position fixes indicated by the red markers, and the GNSS/INS filter bank approach described in the previous section, indicated by the blue markers. Obviously, the snapshot least squares position fixes, for which no attempt to counter spoofing was made, walks off the road. In comparison, the GPB1-based GNSS/INS integrity algorithm proves to be robust with respect to the simulated spoofing threat.

Conclusion

To further grow the application of GNSS receivers for landbased applications, the integrity of the computed PVT solutions must be ensured for this user community in a comparable fashion as is done for the aviation industry. In doing so, the integrity risks of the respective applications like vehicles in cities and railways have to be accounted for. The list of nominal and non-nominal threats is comprehensive, ranging from false locks during tracking over unintentional interference and intentional counterfeiting of GNSS signals, i.e., spoofing.

During the INLU project, various state-of-the-art and promising candidates of future receiver techniques are studied to understand how they can contribute to robust PVT results for land-based users. This comprises not only tracking and RAIM algorithms but also integration of GNSS with inertial measurements using, for example, filter banks.

A GNSS end-to-end simulator needs to have a high versatility to be able to accommodate the manifold requirements that such a project imposes on it. Key factors for the achieved flexibility of the PIPE and SNIPE tools are:

• partitioning into units that serve single tasks with clear inter-module and input data interfaces,
• abstraction layers that allow for the addition of tracking and PVT computation methods to the receiver with minimum effort and the ability to operate these in bit-true and semianalytic modes.

The effectiveness of the chosen approach was demonstrated in a scenario where a traditional GNSS receiver was misled by a spoofer while the implemented filter bank approach corrected for the error transparently.

A separate article will report on the entirety of INLU’s results, i.e., the conclusions drawn from results gained from a number of stochastic scenarios.

The post Navigation Integrity for Land Users Robust Positioning in Challenging Environments appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

It is important, therefore, to ensure satellite orbit calculations are as accurate as possible. As discussed in this article, Earth rotation plays a key role in this regard but surprisingly few references on orbit calculation actually mention its affect explicitly or how to compensate for it. Don’t fret, however, the correction is certainly applied or positioning accuracy would be much worse than is currently attained.

Reference Frames

Earth rotation is important because of the choice of reference system in which orbital calculations are performed. In particular, GNSS orbits — either from the broadcast orbital models or precise post-mission estimation — are parameterized in an
Earth-Centered Earth-Fixed (ECEF) coordinate frame such as the WGS84 reference frame used for GPS.

A common definition of an ECEF frame is one whose z-axis is the rotational axis of the Earth (pointing north), whose x-axis is in the equatorial plane and includes the median passing through Greenwich, and the y-axis completes the frame (typically in a right-handed sense). By definition,such a frame rotates with the Earth and is thus time-varying in inertial space with a period of 24 hours.

In the context of satellite position computations, this means that satellite locations can be computed at any given time, in an ECEF coordinate frame that is valid at that same time.

An easy way to visualize this point is to consider an ideal geostationary satellite whose position relative to the Earth does not change over time — orbital parameters or orbital files would always yield the same coordinates for the satellite.

Effect of Earth Rotation

So where does Earth rotation enter the picture? Well, precisely from the fact that the time at which a satellite transmits a signal, and the time a receiver receives that signal differs. Between the time of transmission (tt) and the time of reception (tr) — roughly 70 milliseconds (give or take few milliseconds) for medium-Earth orbiting (MEO) satellites — the Earth has rotated by ωe . (tr – tt), where ωe is the rotation rate of the Earth.

To illustrate the effect of this, we return to our idealized geostationary satellite. We further consider a user located directly below the satellite. Figure 1 shows this situation looking down on the north pole. To simplify later discussions, we consider this figure to apply at the time of signal transmission.

Since the orbital radius of a geostationary satellite is known (approximately 42,164 kilometers) and the radius of the Earth is known (approximately 6,371 kilometers) the separation of the user and satellite at any given instant is constant and can be easily computed.

Now consider Figure 2, which shows the same figure but also includes the location of the user and satellite at time of signal reception. Because of Earth rotation, the signal travels the path denoted by the blue line, which is obviously longer than the instantaneous separation of the satellite and user. This is the path in inertial space (ignoring the Earth’s orbit around the sun for simplicity).

The problem, however, is that because orbits are parameterized in an ECEF frame, the computed position of the satellite will still be directly above the user. This leads to a situation where the true signal path and the computed signal path differ. Unless accounted for, this difference will manifest as a ranging error in the receiver’s position engine, which computes the difference of the measured and predicted signal paths (i.e., ranges). The magnitude of the position error depends on the number and distribution of satellites, as well as user latitude. As an example, in Calgary, Canada, ignoring Earth rotation results in a shift in the estimated user position of about 20 meters, primarily in the east/west direction.

Before moving on, although we used the example of a geostationary satellite, the exact same effect applies to non-geostationary orbits as well. The main difference is that the satellite positions in Figures 1 and 2 would not necessarily be directly above the user, and the distance between the user and satellites, projected into the equatorial plane (which is shown in Figures 1 and 2), will vary with time as satellites move along their orbits. The good news is that regardless of the orbit, the method of compensation is the same.

Simple Solution

To remove the discrepancy between the measured and computed signal paths, we need to compute the ECEF position of the satellite at the time of transition in the ECEF frame at the time of signal reception. Fortunately, this is easily accomplished by realizing that the two coordinate frames are related by a rotation about the z-axis.

Mathematically, we can write

where is a position vector at the subscripted time (or frame), and R3 (ωe . (tr – tt)) is the rotation matrix about the z-axis by the angle subtended by the Earth rotated during signal propagation.

Applying the transformation in (1) yields the position of the yellow satellite in Figure 2, which allows for the proper computation of the (orange) user position.

The astute reader might be wondering how the propagation time is computed. This can be found by iterating to a solution: first, assume an initial distance between the user and satellite (e.g., 70 milliseconds); then compute the satellite position using this assumed distance (for Earth rotation compensation); use the approximate user position to re-compute the range to the satellite; and finally use this range to compute the satellite position.

The accuracy of the user position in the iteration is not typically a problem. The reason is because, even with a position error of 10 kilometers, the worstcase propagation time error would be 33.3 μs (i.e., 10 km / 3e8 m/s). Multiplying this by Earth rotation rate (~7.3e-5 rad/s) yields an angular error of about 2.4 nanoradians. Even over an orbital radius of 26,000 kilometers (assuming a MEO orbit), the orbital error is less than a decimeter. Then, of course, after the first epoch, the position error is typically several orders of magnitude smaller making the effect of user position error negligible.

Summary

This article has shown why Earth rotation needs to be accounted for when computing satellite coordinates for GNSS applications. The compensation is simple but crucial steps for obtaining the highest possible positioning accuracies.

The post How does Earth’s rotation affect GNSS orbit computations? appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

A: As of today, all open civil GNSS signals are transmitted in the clear, conforming to interface specifications that are fully available in the public domain. Receivers will accept any input that conforms to the specifications and treat it as if it came from a GNSS satellite. Combined with the extremely low power levels of GNSS signals this makes it almost trivially simple to spoof a GNSS receiver.

As early as 2003, Logan Scott proposed a number of techniques that could be implemented at the satellite level to “harden” the civil GNSS signals against spoofing attacks. The first and most straightforward amongst these was NMA.

Message Authentication is a concept that has a long history in digital communications, the basic idea being that the receiver of a message would like to ensure that the message they receive: 1) is identical to the message that was transmitted; 2) was generated by a trusted source. NMA is, unsurprisingly, the application of the Message Authentication concept to the navigation messages generated by GNSS satellites.

So How Does NMA Work?
Message authentication has been referred to as the “second face” of cryptology, and it uses many of the same tools and techniques as the more well-known first face of cryptology: cryptography, or data secrecy. In message authentication the sender uses a secret key to generate an authentication signature from the original message. Both message and signature are then transmitted to the receiver, which uses a key (potentially different to that used by the transmitter) to verify that the message and authentication signature correspond.

When the received message is authenticated the receiver can conclude that:

1. The transmitted and received message are the same

2. Only someone with access to the transmitter’s secret key could have generated the authentication message

There are two different ways to generate authentication signatures:

1. Using symmetric key techniques in which both transmitter and receiver share a secret key

2. Using asymmetric key techniques in which the secret key is split into two parts, a “private” key, known only to the transmitter, and a public key which can be distributed publicly. The private key is used to generate the authentication message, while the public key is used in the verification step.

There are some issues associated with each of the two techniques. In the symmetric key case the most difficult issue is how to distribute the “private” key to all users, without also giving the spoofer access to this key. Similarly, for the asymmetric case, the receiver needs some mechanism to ensure that the “public” key does indeed come from the trusted transmitter (the GNSS system operator in the case of NMA). This problem is usually solved using a Public Key Infrastructure (PKI) consisting of a trusted authority that manages the certification that public keys do indeed belong to the organization that claims them.

So it would appear that the asymmetric approach is superior, as the infrastructure is simplified and the “secret” key can remain secret. However, asymmetric encryption has two major drawbacks: firstly, it is much more computationally intensive than symmetric key encryption; secondly, much longer keys are required for the same level of security.

Interestingly, both symmetric and asymmetric NMA approaches have been proposed for GPS (on the new L1C signal) and Galileo (on the E1 Open Service signal), as discussed below.

The GPS Approach – Asymmetric NMA
The Chips-Message Robust Authentication (Chimera) is a hybrid NMA and spreading code authentication technique proposed for use with the GPS L1C signal. The NMA portion of this scheme is based on the asymmetric elliptic curve digital signature algorithm (ECDSA) P-224, which is a well-established standard. The public key is 448-bits long for an equivalent security of about 112 bits (i.e., it is equivalent to a 112-bit symmetric key system).

The Chimera proposal uses two Subframe 3 pages of the C/NAV message to transmit each digital signature, with a repetition rate of at most once every three minutes. In this way a receiver can verify that the navigation message is authentic every three minutes.

The ECDSA scheme is a well-established Federal Information Processing Standard (FIPS) standard and is implemented in most Open Source and commercially available cryptographic libraries, which simplifies the integration of the scheme into existing GNSS receivers.

Chimera requires receivers to have occasional access, via non-GPS channels, to infrastructure to provide authenticated GPS system public keys. This Public Key Infrastructure (PKI) is essential to any asymmetric crypto-system, including the Transport Layer Security (TLS) system used in securing websites. In this system, each entity that wishes to provide an authenticated public key obtains a signed certificate from a trusted Certification Authority (CA). A user can then verify that the public key provided corresponds to that in the signed certificate. Reusing this certification process should be straightforward in the GNSS context.

The Galileo Approach – Hybrid Symmetric/Asymmetric NMA
The proposal for Galileo Open Service Navigation Message Authentication (OSNMA) differs from Chimera in that it is based on a hybrid symmetric/ asymmetric key approach known as the Timed Efficient Streamed Loss-Tolerant Authentication (TESLA) scheme.

TESLA addresses the issue of symmetric key distribution as follows. First, a Message Authentication Code (MAC) is generated using the message and the private key. Both the message and the MAC are transmitted and then, sometime later, the private key is broadcast. This delayed release mechanism should ensure that the key used to generate the MAC is not known until after the message and MAC are already received. However, this does not prevent a spoofer from simply generating their own messages, keys and MACs and broadcasting them in a manner compliant with the specifications.

To address this latter issue, TESLA uses the concept of a chain of keys. An initial key K₀ is randomly selected. Each subsequent key in the chain K_i+1 is generated from the previous key K_i using a one way function: K_i+1 = f(K_i). A one way function is a mathematical transformation that is easy to compute but very difficult to invert. Thus, given K_i it is easy to compute K_i+1, but given K_i+1 it is computationally infeasible to establish K_i. In TESLA the system generates a chain of length N, then transmits the Nth key (called the root key) along with a digital signature generated using a standard asymmetric scheme, such as ECDSA. The chain keys are then used in reverse order to generate the MACs. Knowing the one-way function, the receiver can verify that each chain key is from the same chain as the digitally signed root key, but cannot predict “future” chain keys.

Once a TESLA chain has been established by asymmetric cryptographic means, the satellites begin transmitting messages, MACs and keys using the delayed release mechanism. The receiver extracts the messages and MACs and stores them until the key is received. The key is first checked to ensure that it is part of the TESLA chain in force using the known one way function. If the key passes this test, it is then used to verify that the MAC and the message correspond.

There is one absolutely critical assumption that must be made for the TESLA-based scheme to work: the receiver must have an authenticated time synchronization that is at least better than the key delay (in TESLA nomenclature this is referred to as the security condition). Without this assurance, the receiver cannot be certain that the navigation message has not been generated by a spoofer that has already received the perfectly valid signing key from a live satellite signal. This naturally raises the question as to how the receiver can “bootstrap” — if it does not have authenticated coarse synchronization how does it go about achieving it?

The OSNMA proposal is currently in draft form and subject to change. As it stands it uses 40 bits every two seconds of the Galileo E1b I/NAV message. The data are grouped into subframes of 30 seconds duration, and each MAC is only 10 to 32 bits in length, while key sizes range from 80 to 256 bits. This enables OSNMA to sign many more messages per second than Chimera, enabling such features as cross-satellite and even cross-system authentication. The receiver side computation cost of this high authentication rate remains to be seen, as it includes both MAC computation and key validation through the evaluation of the one way function. Similar to Chimera, the OSNMA scheme is built from a number of standard cryptographic building blocks, facilitating its implementation in receivers. However, unlike ECDSA the TESLA scheme itself is not a standard implementation and therefore will require more effort to integrate into GNSS receivers.

As with Chimera, the problem of Public Key Infrastructure (PKI) arises for OSNMA. In this case, the receiver must have access to known, trusted public keys in order to authenticate the digitally signed root keys. At present the OSNMA proposal envisages two public key distribution mechanisms: 1) the receiver can be initialized with a valid Galileo system public key in the factory; 2) new public keys can be transmitted over the E1b navigation message, a process known as Over the Air Rekeying (OTAR). In the current draft neither of these techniques are defined, though signal bandwidth is available for the OTAR mechanism. Of course, with OTAR new higher level public keys are required in order to authenticate the root key signing public keys broadcast from the satellites. Ultimately a PKI similar to that used for authenticating public keys used by commercial websites must be put in place to support public key distribution for both OSNMA and Chimera.

What Does This Mean For Users?
NMA is not a panacea, and by itself does not solve the spoofing problem. In Scott’s terminology, this is but Level 1 of a series of three system-side, signal level defenses. On the other hand, an NMA scheme that is correctly implemented in the receiver does constrain the spoofer’s “attack space” — essentially the spoofer is constrained to only broadcast valid navigation messages.

From the user’s perspective, the desired outcome is most likely to obtain an authenticated PVT, or at the very least, to be able to detect a spoofing attack. NMA on its own is insufficient for PVT authentication since this requires both the navigation message and range measurements from each satellite, and NMA does not authenticate the range. However, certain types of spoofing attack are detectable when NMA is implemented.

Over the last number of months two different “spoofing” attacks have been reported in this magazine (see Additional Resources). The first, almost certainly a repeater, affected a number of ships in the Black Sea in June 2017. The second, not technically spoofing as it was unintentional, was due to a GNSS simulator operating in the exhibition hall at the ION GNSS+ 2017 conference in Portland, Oregon in September 2017.

NMA on its own would have been of no assistance whatsoever in the Black Sea case, assuming that this was in fact a repeater, as this simple attack involves re-broadcast of live GNSS signals in near real-time. The navigation message broadcast by the spoofer would have been identical to that broadcast by the satellites, and hence would have passed the authentication verification step. Such an attack can only be detected by careful monitoring of various signal parameters and looking for sudden, physically impossible jumps, a process known as consistency checking.

The simulator incident is an interesting case, as it shows really how vulnerable many receivers are to spoofing. The cause of the incident appears to have been an improperly terminated output port on a GNSS simulator that was running a demonstration in the exhibition hall. The energy radiated from this port was sufficient to capture the GNSS receivers in many attendees’ smartphones. The simulated scenario was located somewhere in Europe and set in January 2014. Clearly, again simply monitoring the existing signal parameters available in the receivers should have provided some indication that there was a problem; jumping across continents or back in time is not something most receivers are capable of. But could NMA have helped in this situation? The short answer is yes, as the simulator would either have generated invalid signatures, or re-used out of date messages. However, in truth, the onus should really be on the receiver to detect sudden, physically impossible jumps in space or time.

In short, for the scenarios considered above, the most reliable test for spoofing is the receiver consistency check.

Summary
Navigation Message Authentication is coming to both Galileo and GPS in the next few years, which demonstrates that the system operators are serious about the civil spoofing threat. Other system level protection measures are also under development: Chimera implements secure spreading sequences for some signal level protection, while Galileo provides fully encrypted spreading codes in its Commercial Service.

NMA is but one tool in the arsenal that GNSS receivers can deploy against spoofing, but is certainly a step in the right direction. However, such efforts on the part of the system providers must be matched by the receiver manufacturers for there to be any benefit to the end user. Many receiver level defenses can, and should, be implemented today without waiting for the arrival of NMA.

Further Reading
Logan Scott’s paper on how to harden GNSS receivers:

• Scott, L. (2003) “Anti-Spoofing & Authenticated Signal Architectures for Civil Navigation Systems”, ION GNSS 2003.

Details about the proposed GPS and Galileo NMA proposals:

• Anderson, J. L.; Carroll, K. L.; DeVilbiss, N. P.; Gillis, J. T.; Hinks, J. C.; O’Hanlon, B. W.; Rushanan, J. J; Scott, L.; Yazdi, R.A (2017) “Chips-Message Robust Authentication (Chimera) for GPS Civilian Signals”, ION GNSS+ 2017.

• Fernandez, I; Rijmen, V.; Ashur, T.: Walker, P.; Seco, G.; Simon, J.; Sarto, C.; Burkey, D.; Pozzobon, O., “Galileo Navigation Message Authentication Specification for Signal-In-Space Testing”, Version 1.0, November 2016.

Additional Reading on the TESLA Scheme:

• Perrig, A.; Canetti, R.; Tygar, J.D.; Song, D., “Efficient Authentication and Signing of Multicast Streams over Lossy Channels”, Proceedings of the IEEE Symposium on Security and Privacy, 2000.

Additional Resources
[1] Goff, S. “Reports of Mass GPS Spoofing Attack in the Black Sea Strengthen Calls for PNT Backup”, Inside GNSS, 24 July 2017.
[2] Scott, L. “Spoofing Incident Report: An Illustration of Cascading Security Failure” Inside GNSS, 9 October 2017.

The post What is navigation message authentication? appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

Q: Do modern multi-frequency civil receivers eliminate the ionospheric effect?

Q: Do modern multi-frequency civil receivers eliminate the ionospheric effect?

A: It is common knowledge in the GNSS community that the ionosphere is dispersive in the L-band, meaning the refractive effects on the carrier phases are proportional to the wavelengths of the carriers, in turn causing differential variation in the measured codes and phases of the various navigation signals transmitted by the satellites. Use of multiple signals of distinct center frequency transmitted from the same GNSS satellite allows direct observation and removal of the great majority of the ionospheric delay, and gives the impression to users that the ionosphere may not be a problem for modernized receivers. While the general assumption of nearly perfect correlation between the effects measured on multiple independent signals is correct in normal conditions, it does not appear to hold in the presence of ionospheric scintillation.

High and Low Latitude Scintillation Effects
Scintillation refers to random fluctuations in the received wave field strength (“signal fading”), as well as phase and group delay caused by the irregular structure of the propagation medium. Ionospheric scintillations are random rapid variations in the intensity and phase of the received signals resulting from plasma density irregularities in the ionosphere.

Many of the important contributors to ionospheric scintillation are already known, such as the variation of scintillation activity with magnetic activity, geographic location, local time, season, and the 11-year solar cycle.

The most significant and frequent scintillation activity including both phase and amplitude variations is observed in low latitude regions within about 15° of the Earth’s magnetic equator, particularly in the hours after local sunset. In high latitude regions scintillation is frequent but generally less severe in terms of signal tracking disruptions than that in the equatorial regions. The high-latitude environment can be divided into two subregions, the polar caps (regions around the magnetic poles) and the auroral zones (approximately circular regions around the two geomagnetic poles located at about 67° north and south geographic latitudes, and about 3° to 6° wide). Of these, the polar cap experiences both amplitude as well as phase scintillation activity, while mainly phase scintillation is observed at high latitude auroral regions.

In mid-latitude regions scintillation is rarely observed, but during intense ionospheric storm conditions phenomena can extend into the mid-latitudes.

Figures 1 and 2 (see inset photo, above right, for all figures) show examples of ionospheric scintillation as observed on the detrended signal intensity (effectively power) and detrended carrier phase measurements at 69.5° latitude (Tromsø, Norway) and 21° latitude (Hanoi, Vietnam), respectively. In the particular event shown in Figure 2 the depth of fades reaches 43 decibels (dB) on L1CA which is severe by any metric, and is a substantial qualitative difference from the high-latitude phase scintillation events where only very weak fading activity is typically observed. It should be noted that ionospheric activity is more dependent on the geomagnetic latitude of the user than the geographic latitude. While it might be clear that Tromsø station is located in the auroral region, the Hanoi station has somewhat lower geomagnetic latitude than geographic latitude and is in fact located within the equatorial zone.

Since ionospheric scintillation is essentially a rapid variation in the apparent ionosphere it is easy to assume that the typical approaches applied for removing ionospheric influence will be effective during scintillation.

Ionosphere-Free Combination
The advantage of multi-frequency GNSS receivers in terms of handling the ionospheric error is that they can combine carrier phase measurements at different frequencies to cancel out the first order effect due to ionospheric refraction. The receiver does not typically measure the ionospheric delay directly, but is using the so-called ionosphere-free linear combination of the observables. Consider generalized versions of carrier phase measurements on two frequencies, i and j, expressed in meters:

Φ_Li = ρ + λ_iN_i − I_i     (1)
Φ_Lj = ρ + λ_jN_j − I_j

where ρ is the geometric range between the satellite and the receiver; λ_i and λ_j are the wavelengths, N_i and N_j are the integer ambiguity terms, I_i and I_j are the ionospheric propagation delay errors. For simplicity, the receiver noise and multipath errors are not included. The expression for an arbitrary linear combination of two carrier phase measurements can be written as follows: (For more on this topic, read the GNSS Solutions column from January/February 2009).

Φ_ij = αΦ_Li + βΦ_Lj     (2)

where α and β are constants. This allows one to model a linear combination of phases in the same way as the individual observables:

Φ_ij = ρ + λ_ijN_ij − I_ijη     (3)

In (3), λ_ij is the wavelength, N_ij is the integer ambiguity term, and I_ij is the ionospheric propagation delay error for the linear combination. In order to remove the ionospheric error (η = 0), but leave the geometric portion unchanged and the resulting ambiguity still an integer, the ionosphere-free combination has been proposed:

Φ_IFree = f_i²Φ_Li − f_j²Φ_Lj  ∕ f_i² − f_j²     (4)

where f_i and f_j are the carrier frequencies expressed in hertz. The phase scintillation is, however, caused by both refractive and diffractive effects. The diffractive effects cause rapid transitions in the phase which do not scale with the carrier wavelength resulting in a residual error in the ionosphere-free linear combination (4) of phase measurements.

While this correction term is for most purposes considered complete, there are factors that can cause apparent deviation between the two carriers including multipath, receiver noise, and un-modelled terms in (4). Corrections produced using (4) will have a residual error due to second and third order dispersion effects, which are conservatively bounded to 0–2 centimeters and 0–2 millimeters at zenith respectively, under an assumption of a 100 TECU (total electron content unit; 1 TECU ≈ 16 cm at GPS L1) background ionosphere. Since 100 TECU is a high value for zenith ionosphere the value of the higher order terms will often be well below 2 centimeters instantaneously, and will vary by only a small fraction of this amount over short time periods.

Although some recent findings have shown that magnitudes of 3 centimeters referenced to L1 are possible due to the higher order terms, it has also been shown that the variation rate is typically limited to the level of centimeters per hour.

During phase scintillation events it is possible that the multiple carriers of a given satellite will (when scaled for frequency as in Figure 3) track each other within the margins of error expected when accounting for thermal and oscillator phase noise on each channel. However, it is also possible that near total de-correlation of the phases will occur during phase scintillation accompanied by fading events as is depicted in Figure 4 where the detrended scaled carrier phase observables from L1, L2 and L5 transmitted by a block IIF GPS satellite visibly deviate from one another. Even the closely-spaced L2 and L5 carriers exhibit substantial decorrelation, equivalent at times to a full L1 carrier cycle of nearly 20 centimeters, well outside of the level which could be plausibly attributed to higher order terms ignored by (4).

On close inspection, the data shown in Figure 4 does not appear to contain any stepwise transitions of a magnitude commensurate with a full or half cycle slip on any of the carriers, meaning that this decorrelation is unlikely to be a signal tracking error. Unlike static group delay errors, it is not possible to measure and estimate this error contribution a priori. It is effectively an additional noise source present only during scintillation. Since it will influence the magnitude of the residual error in the case of multi/dual frequency processing it is interesting to analyze this phenomena and attempt to quantify its expected magnitude by considering the level of correlation between carriers during a cross section of scintillation events affecting modernized civil signals believed to be free of cycle slips.

To quantify the correlation level between the scintillation effects on GNSS frequencies, the phase correlation coefficient can be calculated for the observed scintillation events according to the following relationship:

ρ_δφ = ⟨δφ₁δφ₂⟩/(⟨δφ₁²δφ₂²⟩)^1/2, −1 < ρ_δφ < 1     (5)

where the terms δφ₁ and δφ₂ represent epoch to epoch changes in the detrended phases. Figures 5 and 6 show the results for the events observed at 69.5° latitude (Tromsø, Norway) and 21° latitude (Hanoi, Vietnam). In Figure 6 the level of correlation versus the intensity of the phase variation is plotted for L1CA vs. L2CM, and in contrast to the high latitude example shown in Figure 5, where increasing phase instability leads to an increasing level of phase correlation between the two carriers, for the Hanoi data the outcome is entirely different. Indeed, the phase correlation between the two carriers appears to be nearly non-existent on average, as the distribution of correlation measures is bifurcated with half the distribution tending towards higher positive correlation levels, while the other half of the sampled distribution tends towards anti-correlated results.

Ionosphere-free Residual
When scaled by their wavelengths, the carrier phase measurements on different GNSS frequencies appear to match closely when the scintillation effect is weak or moderate, but diverge from one another when the scintillation effect is strong regardless of whether the dominant scintillation effect is on the phase or amplitude of the signal. It is believed that these divergences occur when diffraction alters the phases by a factor that is not proportional to the wavelengths of their carriers leading to a residual in the ionosphere-free phase combination. An example of this phenomena is the so-called “canonical fade”, which may be the cause of the decorrelation events presented here. Figure 7 shows the average absolute L1/L2 ionosphere-free combination residual from Tromsø (69.5° N) observations, whereas results generated based on the data from Hanoi (21° N) are illustrated in Figures 8, 9 and 10.

Noting that the range of carrier phase standard deviation considered in Figures 8, 9 and 10 is smaller than that considered in the high latitude plot, it is clear that the level of ionosphere-free residual present in the Hanoi data increases much more rapidly with rising phase standard deviation than was the case with the high latitude observations.

While it is not unexpected that the L1/L5 combination residual is also substantial, as indicated in Figure 9, the more interesting observation is that the L2C and L5 signals also have considerable levels of decorrelation despite their relatively small 51 megahertz of spectral separation, compared to the nearly 350 megahertz of spectral separation between L1 and L2. In Figure 10, it is seen that for one of the tracked satellites during this event, the level of ionosphere-free residual in the L2CM/L5Q combination seems to exceed one meter even while the underlying data shows no signs of cycle slips.

Conclusion
To summarize, it has been demonstrated that ionospheric scintillation phenomena tend to cause an additional measurement residual in the nominal ionosphere-free combinations that greatly exceeds the expected value of the neglected higher order terms and may be a substantial or dominant nuisance term in some applications. While the residual is present with both phase and amplitude scintillation, and is more pronounced with strong scintillation to a point, the relationship appears stochastic and not deterministic.

It is tempting to assume that concerns about ionospheric effects during all but deep amplitude fades would disappear when users had switched from semi-codeless multi-frequency observables to the use of modernized civil signals due to their much higher tracking robustness. Instead, it seems that even with the modernized signals there is a measurable and occasionally meter level sense in which the ionosphere-free observables are not at all free of ionospheric influence.

Additional Resources

For additional information about ionospheric scintillation:
[1] Conker, R.S., M.B. El-Arini, C.J. Hegarty and T. Hsiao (2003) “Modelling the effects of ionospheric scintillation on GPS/Satellite-Based Augmentation System Availability”, Radio Science, vol.38, no.1.
[2] Carrano, C. S., K. M. Groves, W. J. McNeil, and P. H. Doherty (2013), Direct measurement of the residual in the ionosphere-free linear combination during scintillation, Proceedings of the 2013 Institute of Navigation ION NTM meeting, San Diego, CA, January 28-30, 2013.

For additional information on higher-order ionospheric effects:
[3] Hoque, M.M., and N. Jankowski (2007), “Higher order ionospheric effects in precise GNSS positioning,” Journal of Geodesy number 81, pp 259-268
[4] Liu, Z., Y. Li, J. Guo, and F. Li (2016) “Influence of higher-order ionospheric delay correction on GPS precise orbit determination and precise positioning,” Geodesy and Geodynamics, Volume 7, Issue 5, September 2016, pp 369-376

For information about canonical fades:
[5] Liu, Z., Y. Li, J. Guo, and F. Li (2016) “Influence of higher-order ionospheric delay correction on GPS precise orbit determination and precise positioning,” Geodesy and Geodynamics, Volume 7, Issue 5, September 2016, pp 369-376.

The post Do modern multi-frequency civil receivers eliminate the ionospheric effect? appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

Q: How do you use GNSS to compute the attitude of an object?

A: GNSS technology is used to support a wide range of position, velocity and time applications across numerous platforms. One of the lesser-known applications of GNSS is its ability to determine the attitude, or orientation, of an object. Such systems can be made to be quite small and can yield accurate solutions that operate in virtually any environment in which GNSS satellite visibility is reasonable. The only requirement from a GNSS receiver perspective is that the receiver be able to provide reliable carrier phase measurements.

This article begins with a brief summary of how the attitude of a vehicle is determined and then explains how GNSS can be used. It wraps up with a brief discussion about attainable accuracies.

Attitude Determination
Attitude determination is the process of determining the rotation angles that relate two different coordinate frames. Although any two coordinate frames can be used, we herein consider the rotation between a local-level frame (e.g., North, East, Up or East, North, Down, etc.) and the body frame. The body frame is a frame attached to the object (“body”) whose attitude is desired (an example body frame is given later).

With this in mind, we present the following key relationship

r⃗^l = R^l_br⃗^b     (1) 

where r⃗ is a vector parameterized in the local-level (superscript l) or body (superscript b) frame and R^l_b is the rotation matrix (or direction cosine matrix) from the body frame to the local-level frame.

The rotation matrix between any two frames can be defined using three consecutive rotations about the three coordinates axes — these are called Euler angles. For the case under consideration, since one of the frames is the local-level frame, the Euler angles can be expressed as familiar roll, pitch and azimuth angles.

To compute the rotation matrix, one needs to know or measure at least two vectors in each coordinate frame. These vectors could be anything including velocity, rotation rates, etc., as long as they are non-collinear (i.e., not parallel). It is possible to use a single vector, but then you cannot determine all three Euler angles; more on this later.

GNSS Attitude System Setup
For GNSS attitude determination systems, the vectors used in equation (1) are relative position vectors. The question, of course, is: where do these come from?

Before answering this question, let’s clarify what constitutes a GNSS attitude system. To determine the full attitude, at least three GNSS receivers are needed. The only other requirement is some software to process the data from these receivers.

Returning to the question that opened this section, the body frame vectors are defined by the location of the receivers (actually the antennas; denoted A ‒ C) on the object whose attitude is desired. Assuming a three-antenna system, a common (if not easy to understand) configuration is to mount the antennas such that two antennas fall along the direction of travel, and the third one is 90 degrees offset. One possible setup is illustrated in Figure 1 (see inset photo, above right) for the case of a road vehicle.

Once installed, the body frame coordinates are defined by measuring the position of the antennas relative to the coordinate frame of the vehicle. The coordinate frame of the vehicle can be arbitrarily defined but is usually selected such that one axis is along the direction of travel, one lateral to the direction of travel, and the third axis completes on orthogonal frame (e.g., forward, right, down).

As might be expected, these same vectors in the local-level frame are determined from GNSS measurements. Once computed, the rotation matrix between the body and local-level frames can then be determined. Both of these steps are accomplished by the processing software and are discussed in the next section.

Data Processing
As mentioned, the inter-antenna vectors in the local-level frame are computed from GNSS. For an N-antenna system, only N-1 independent vectors need to be solved. Although not required, this is commonly done by selecting one antenna/receiver as the “base” and then computing the vector to each of the other antennas/receivers in the system.

Continuing with the three-receiver example in Figure 1, we select antenna A as the base and compute vectors ray AB and ray BC. Of course, if there are other antennas, the vector from Point A to each point would also be computed.

To be more specific, the inter-receiver vectors are computed using standard differential carrier phase processing. Because the inter-antenna spacing is typically limited to a few meters, the spatially-correlated orbit, ionosphere and troposphere errors are virtually zero. This dramatically simplifies the ambiguity resolution process, since the only errors that need to be handled are multipath, noise and antenna phase center variation, which are generally small, as discussed later.

It is also possible to use the known baseline length between the receivers (as measured in the body frame), or any a priori attitude information to make the ambiguity resolution process even more robust.

Some of you might be wondering why I have not mentioned the requirement for a base station. The reason is precisely because we are estimating relative, not absolute, position vectors. By definition, differential data processing yields a relative position vector. If the location of the base station is known in an absolute sense — this is the most common use of a base station — then the resulting solution of the rover is also absolute.

For attitude determination, absolute location is not important. As such, the location of the base receiver (Point A in the above example) can be computed from a standalone (single point) solution. Even absolute positioning errors of 100 meters (which would be extremely large if the carrier phase data needed for attitude determination is still available) will be buried by the other errors in the system, and thus can be ignored.

The only other effect that might be important here is the timing accuracy of each receiver. As discussed in the March/April 2011 GNSS Solutions column, “GNSS Receiver Clocks,” a relative timing error of Δt between the receivers will result in a relative position error of s · Δt, where s is the speed of the vehicle. Assuming a timing error of 2 milliseconds (most receivers limit timing errors to ±1 milliseconds) and a vehicle traveling at 100 kilometers per hour, the relative positioning error would be approximately 5.6 centimeters. As discussed below, this would dominate the error budget and would therefore have to be properly accounted for.

The outputs of the GNSS processing are the vectors in the local-level frame; these can be computed directly in that frame or can be computed from vectors in an Earth-Centered Earth-Fixed (ECEF) frame. Mathematically, this is written as

r⃗^GNSS = r⃗^l + n⃗^GNSS
= R^l_br⃗^b + n⃗^GNSS     (2)

where r⃗^GNSS is the GNSS-derived vector in the local-level frame, n⃗^GNSS is the measurement noise, and equation (1) was used to get from the first to second line. Equation (2) is written in parametric form and can thus be used as input to any standard least-squares or Kalman filtering estimation algorithm to estimate the Euler angles embedded in R^l_b.

Two-Antenna Systems
Until now, we have only considered systems consisting of three or more receivers in order to estimate the full attitude of an object. However, two-receiver systems can be used to estimate rotations orthogonal to the vector connecting the two antennas.

The most common two-receiver system is one where the two receivers are set up parallel (or orthogonal) to the direction of travel. This allows for estimation of the azimuth and pitch (or roll) of the vehicle; the third angle is unobservable.

Expected Accuracy
As discussed above, the GNSS measurement errors are limited to multipath (2‒3 centimeters), noise (less than 1 millimeter) and phase center variation (1‒2 centimeters or less) (all values quoted as one standard deviation values). Assuming the measurement geometry is reasonable (HDOP ≈ 1 and VDOP ≈ 1.5), the main factor affecting accuracy is the length of the inter-antenna vectors.

To illustrate, let’s consider a two-receiver system with the understanding that there is an analogous relationship for three-plus receiver systems. Specifically, for the setup in Figure 2 (see inset photo, above right), for an inter-receiver separation of d, the pitch (ϕ) and azimuth (α) can be computed as

(see inset photo, above right for equations)

where σ_EIN is the North/East relative positioning uncertainty, σ_U is the vertical relative positioning accuracy, and d_h is the horizontal distance between the receivers. In other words, the longer the inter-receiver separation the better the attitude accuracy.

To give some numbers, for the lower- end measurement errors and DOP values listed at the start of this section, and nominal horizontal receiver separation of 1 meter, the pitch and azimuth accuracy would be 1.3 and 1.9 degrees, respectively. This is a one-off accuracy estimate and further filtering/ averaging would yield even better performance.

Summary
This article has given an overview of how GNSS can be used to determine the attitude of an object. Although reliant on ambiguity resolution, the short baselines involved make the process quite robust. The result can be highly accurate attitude estimates that can be applied to a wide range of applications.

The post How do you use GNSS to compute the attitude of an object? appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

A: Much like many industries and organizations, as the nature of Public Safety grows and evolves, its members have looked to leverage available technologies that help them achieve their goals. In this case, the goals are first and foremost Public Safety followed closely by Member Safety whether it be police, fire or others.

Q: How is Public Safety reliant on GNSS and is this a concern?

A: Much like many industries and organizations, as the nature of Public Safety grows and evolves, its members have looked to leverage available technologies that help them achieve their goals. In this case, the goals are first and foremost Public Safety followed closely by Member Safety whether it be police, fire or others.

Hand in hand with the benefits of new technologies comes the dependency on said technology and the need to plan for the “what if” scenario should technology fail or let us down as it can on occasion.

One technology that is not new to Public Safety but is growing in its use is GNSS. The most obvious use of GNSS is to support location services for staff and assets — the tracking of team members and vehicles. However, with the latest advances in technology it has also become a necessity for precise timing to support basic radio/communications system operation. This aspect or use of GNSS/GPS is often overlooked.

This article provides some examples of how Public Safety can be threatened by over-reliance on GNSS and justifies why contingency plans have been put in place. Although the examples are specific to Public Safety services in the Greater Toronto Area (GTA), Canada, they can be expected to be similarly relevant in other jurisdictions in Canada, the United States, and abroad.

GNSS Timing in Public Safety
Public Safety users are still very dependent on reliable LMR (Land Mobile Radio) radio communications to provide a high level of public safety while ensuring their own safety.

Modern Public Safety LMR systems make use of two key elements that are very dependent on precise timing and both are used in the current APCO (Association of Public Safety Communications Officers) standard (APCO 25) that is often referred to as “P25 Phase II”. APCO applies in Canada and the United States, and thus covers most of North America. Other jurisdictions (e.g., Europe, Asia, etc.) may use different standards, but it is expected that they all have similar reliance on GNSS, as described below.

The first of these key elements is the fact that P25 Phase II is a TDMA (Time Division Multiple Access) technology and uses a modulation scheme that time slices a 12 kilohertz radio channel to allow two conversations, or talk groups, to exist in the same spectrum. This is a way to increase the radio channel and system capacity allowing more users access to the system, higher availability and a higher grade of service.

To ensure that this time slicing of the spectrum is possible, the system must have a very precise time standard that is identical across the network and the same at all nodes or radios sites. In Canada, these networks can span cities, regions or provinces and have hundreds of sites. At each of these sites and nodes there are two GNSS receivers — a main and a standby — that are used to keep all radio transmissions in time.

Without this timing reference and without the accuracy and precision afforded by GNSS, the time slots and corresponding voice conversations that they contain would start to bump into each other and the users would have garbled, missed and/or lost radio transmissions. From a Public Safety perspective, any disruption to communications is of course concerning and compromises the two prime goals listed in the opening paragraph.

The second use of precise timing is for the purpose of Simulcast. Simulcast is the process in modern Public Safety radio systems where radio signals on the same frequency or channel from two different sites intentionally overlap the same geographic area. This overlap is to ensure that Public Safety members have radio coverage at all times with no gaps. This approach is different than a cellular network when the handset “hops” from site to site rather than listening to multiple sites.

In order for the Public Safety portable radios to listen to multiple sites that are located random distances away and still properly decode the incoming transmissions, the timing of these overlapping signals must be stable, synchronized and well known. The GNSS receivers located at each site are also used to provide the required timing for this aspect of the radio system operation.

Considering the above, the dependency of Public Safety on GNSS-derived time signals is obviously very high — should the time standard drift or become unavailable for an extended period of time the system would become unstable and fall into a mode that shuts down sites and reduces coverage and capacity. This is often referred to as “fail-soft”. When in this mode, it can seriously affect user communications and in turn the ability to maintain the key goals of Public and Member Safety.

To prevent fail-soft and degraded/ limited service, the system has many built-in redundancies and contingencies.

The first of these is having multiple GNSS receivers distributed across the network to provide geo-redundancy and help to reduce the impact of single unit failure or local interference.

The second is to have these receivers equipped with a rubidium standard that allows them to “free run” without a synchronizing signal for some days while still maintaining the required synchronization.

The third is to have the GNSS devices equipped with receivers that span multiple bands and constellations in case of a constellation failure or issue.

Examples of Over-Reliance
Despite these contingencies, GNSS outages and disruptions can and have occurred and caused local and even wide spread outages across the radio networks. Below are several examples where Public Safety services in the GTA experienced short-term problems that, thankfully, did not adversely affect Public Safety.

In one case, in January of 2016, an incorrect satellite code upload to the GPS constellation triggered an error in the time standard. For additional details, read “GPS Glitch Caused Outages, Fueled Arguments for Backup”. GNSS receivers in many LMR systems saw this as a valid fault or error in the time standard and if they were pre-set in a particular way (the factory default) they would shut themselves down as a preventative measure.

The issue in this case for many systems was that all receivers in the system were programmed the same way and so all GNSS receivers in the system perceived the timing as a local anomaly and took themselves offline — assuming other GNSS receivers in the same system would take over. The operational impact of this and the short-term — I dare say — panic that ensued was very disconcerting, to say the least.

To avoid this from occurring in the future there have been changes made to the GNSS receiver programming and they have been configured to ignore short-term timing anomalies and marshal on for as long as possible relying on their internal rubidium standards to provide the required synchronization. This of course would be sufficient and work in the short term, but the system would eventually fall back to fail-soft if it persisted.

In another case that occurred over a 6-hour period on Good Friday 2017 (starting late-morning and ending mid-afternoon in the Eastern time zone), there were local disruptions to GNSS receiver availability due to local in-band radio interference. Fortunately, this was a short period of time and on a holiday like this the system traffic was low and the potential disruption and impact was nominal.

The concern over this particular event is that it occurred very close to a strategic node in the system that is key to the systems operation and affected a large number of GNSS receivers including the one that provides timing to the Public Safety services’ internal IT network. Had it persisted and if the source could not be found there was a contingency plan in place to “fail over” to the redundant node — located some distance away — that would have been able to provide the timing required.

The cause of the interference was never found and it disappeared as suddenly as it appeared — 6 hours later — and has not been seen since. It could have been as sinister as a “GPS jammer” that is known to exist or as simple as a rogue unlicensed wireless mic or cordless phone. We have polled the surrounding area to no avail.

A similar event to this some months ago that affected the main dispatch channels was traced to an older and inexpensive TV antenna amplifier that had been plugged in by the home owner after being out of service. The device was voluntarily removed by the home owner.

Summary and Outlook
In summary, the dependency of Public Safety users on GNSS constellations and the timing that they provide is growing and becoming more critical for basic operations and are no longer nice-to-have capabilities.

This dependency has made it necessary to be vigilant and monitor the health of these data streams and the systems that are dependent on them. It has also prompted the development of strategies to ensure that there are redundancies and fallback solutions should the GNSS data stream be disrupted for long periods of time.

Some of these strategies may include the use of multiple frequency GNSS receivers, GNSS receivers that can make use of multiple constellations or even alternative time signals from terrestrial based systems.

I would encourage the custodians of all Public Safety systems to investigate the potential vulnerability and conduct a risk assessment when it comes to GNSS and its use.

The post How is Public Safety reliant on GNSS and is this a concern? appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

A: This is somewhat of a classic GNSS question, but before getting to the answer, let’s seek some clarity about what is being asked. First, by definition, “more” signals or “more” systems must be referenced against some baseline configuration. This is commonly assumed to be a GPS L1 C/A solution, and this assumption is also used herein.

Q: Would you prefer to have more signals or more satellites?

A: This is somewhat of a classic GNSS question, but before getting to the answer, let’s seek some clarity about what is being asked. First, by definition, “more” signals or “more” systems must be referenced against some baseline configuration. This is commonly assumed to be a GPS L1 C/A solution, and this assumption is also used herein.

Second, “more signals” is most commonly interpreted as meaning more frequencies for a given GNSS (e.g., using GPS L1 C/A and L2C), and “more satellites” is typically interpreted as using additional GNSS relative to the baseline case (e.g., GPS and GLONASS, or GPS and Galileo).

Returning back to the original question, as is the case for so many GNSS questions, the answer is: it depends. It depends primarily on the operating environment and the desired positioning accuracy, although other issues may also be critical factors.

By extension, there is no one-size-fits-all answer to this question. Instead, below is a summary of the benefits and challenges of having more signals and having more satellites. I adopted this approach with the hope that readers will better appreciate the trade-offs between the two approaches such that they can make decisions for their specific applications.

More Satellites
Having more satellites is generally most useful when satellite visibility is reduced, such as in deep urban areas. In such cases being able to track signals from multiple GNSS makes it more likely to be able to compute a solution at all. That is, a multi-GNSS approach improves solution availability.

However, even if a single-GNSS solution were possible, having data from multiple GNSS will yield better measurement geometry, or lower dilution of precision (DOP) values. In turn, this results in more precise position estimates.

Having measurements to more satellites also allows the position filter to be more selective about the measurements to be used. For example, ongoing research is investigating how to use carrier to noise-density ratio (C/N₀) information, 3D building models, cameras, or some combination of these to determine when a received signal does not contain a line-of-sight (LOS) component. These satellites can then be rejected leaving, hopefully, only LOS signals—or perhaps multipath-corrupted LOS signals—to derive a more accurate position estimate. To realize the full benefit of such approaches there needs to be enough LOS-based signals available to compute a solution. It follows that the probability of this happening increases as more GNSS are used.

Multi-GNSS approaches also offer accuracy benefits in less benign environments, but to a lesser extent. The reason for this is because in the absence of large errors arising from non-LOS (NLOS) or multipath signals, the main benefit is in terms of improved geometry. But the absence of (many) NLOS signals suggests good sky visibility, in which case even the baseline configuration of a single-GNSS solution will typically have reasonable geometry already.

Since DOP is approximately proportional ¹⁄_√N to where N is the number of satellites used, doubling the number of satellites only provides about 30% reduction in DOP, but tripling the number of satellites reduces DOP by only 42%. Although always beneficial, it is obvious that adding more and more satellites offers diminishing returns.

Unrelated to position accuracy, using more satellites will improve the statistical reliability of the system. In other words, a multi-GNSS solution is more likely (in terms of a probability) to identify a measurement blunder of a certain magnitude than is a single-GNSS solution. Equivalently, a multi-GNSS solution will be able to identify smaller blunders than a single-GNSS solution with the same level of probability.

Although the details of this are beyond the scope of this article, the reason for this is that the magnitude of blunder that can be detected at a given probability level is dependent on geometry which, as described above, is better with multi-GNSS solutions.

On the downside, multi-GNSS solutions need to properly handle differences, if any, in reference ellipsoids (e.g., WGS48 for GPS and PZ-90 for GLONASS) and time scales between the different GNSS. This is not particularly difficult, but ignoring such effects can have significant impacts on positioning performance. Of particular note is that extra states may need to be added to the position filter to properly account for timing differences.

Before moving on, it should be noted that if many satellites are being tracked but the receiver’s processing resources and/or power are limited, it may be desirable and/or necessary to only process a subset of all possible satellites to minimize power consumption. Such situations are likely to be uncommon (and much more enviable than other GNSS-related challenges), but selecting which satellites to process will need to consider the trade-offs between processing complexity, solution precision and statistical reliability.

More Signals
The main benefit of using multiple signals is improved accuracy. This happens in two ways: mitigating ionospheric effects and, to a lesser extent, minimizing multipath effects.

It is well known that ionospheric errors, I, are a function of the carrier frequency of the signal passing through the medium

I(f) = ^{40.3 x TEC}/_{f ²}

where TEC is the total electron count in a square-meter cross-section along the signal path and f is the signal’s carrier frequency. This dispersive quality allows measurements from two signal frequencies to correct for the first-order ionospheric effects. This accounts for typically 99% of the errors, but using three (or more) frequencies allows for the removal higher-order effects.

The downside of this approach is an increase in noise arising from the combination of multiple noisy measurements, for example, noise increases nearly three-fold when using GPS L1 and L2 measurements.

Ionosphere error minimization is the primary benefit of using multiple signals. Practically, however, this benefit is only realized if ionospheric errors represent a significant part of the error budget. This would include situations where multipath effects are limited and/or for real-time kinematic positioning with carrier phase data to improve ambiguity resolution.

For pseudorange-based systems, the benefit of removing the ionosphere will depend largely on the level of measurement noise; if the noise is too high relative to the ionospheric error, then there may be little practical benefits to be realized. That said, increased measurement noise is zero-mean and can be reduced with sufficient averaging/filtering, if the application allows.

Having multiple signals can also be helpful at minimizing the effect of multipath when the LOS signal is present (this contrasts with scenarios where there is multipath but all paths are NLOS). In such cases, the reflected paths are the same for both signals, meaning they both have the same path delay. However, the phase difference between the LOS and NLOS signals at the receiver is generally not the same and so averaging across signals offers some benefits, especially if one of the signals has a large multipath effect.

Of course, if the LOS signal is not present, then there is no benefit since the LOS signal cannot be recovered.

In theory, a multi-signal approach will also improve the statistical reliability of the solution. Practically, these improvements are minimal because GNSS measurement blunders typically arise from multipath and such errors (albeit with different magnitudes, as discussed above) are present on all signals from a given satellite. With this in mind, it should be intuitively obvious that using a blundered measurement to detect a blunder in another measurement does not typically yield the desired result.

The final benefit of multiple signals is the improved resilience to interference. This arises from the simple fact that jamming two or more signals in different bands is inherently more difficult than jamming a single frequency. If the additional signals also have ranging codes with wider bandwidths and/or different auto-correlation properties, this can further improve interference mitigation—this latter benefit would therefore be realized for multi-GNSS systems as well.

The challenges of using multiple signals are two-fold. First, the receiver will need two front-ends, which in turn requires more power. This will be especially important for power-sensitive applications. Second, inter-frequency biases need to be properly accounted for. Most receivers already calibrate these but this is nevertheless a source of error.

Summary
Table 1 (at the top of this article) summarizes the benefits and challenges of each of the two scenarios discussed above. Broadly speaking, if you have to choose between the two approaches, multi-GNSS systems will be most beneficial in signal-obstructed the receiver is not ideally located on the object being positioned (e.g., inside a car or inside a bag). In contrast, multi-signal systems will typically be most useful for improving accuracy when signal visibility is less of a concern. areas such as urban canyons or when

That said, GNSS applications vary widely in terms of their requirements, operating environments, or both. It is the responsibility of the system designer to consider the benefits and challenges of the different approaches in order to maximize performance for their application.

Of course, the most desirable option would always be to use a multi-signal, multi-GNSS system, if possible.

The post Would you prefer to have more signals or more satellites? appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

A: GNSS jammers are an ongoing threat to the reliable use of GNSS. The problem of geolocating GNSS jammers can be addressed using a time-difference-of-arrival (TDOA) processing technique; however, this problem is quite different than geolocating jammers in other radio frequency systems. The two main differences are:

(1) No GNSS are available to use as a timing reference.

Q: Is it possible to build a low-cost system to detect and locate a single GNSS jammer in near-real time?

A: GNSS jammers are an ongoing threat to the reliable use of GNSS. The problem of geolocating GNSS jammers can be addressed using a time-difference-of-arrival (TDOA) processing technique; however, this problem is quite different than geolocating jammers in other radio frequency systems. The two main differences are:

(1) No GNSS are available to use as a timing reference.

(2) The signal of interest (i.e., the GNSS signals) are weak. This contrast with other applications (e.g., mobile phone jamming) where the signal of interest is much stronger.

The first point forces the TDOA technique to be unconventional, but still possible. The second point eliminates the complexities of having to discern desired versus undesired signals in the band.

To address these issues the Communications Research Centre (CRC) Canada, which is the Government of Canada’s primary laboratory for wireless research, has been doing work in this area. Two complementary systems were devised to solve the problem of geolocating a single GPS jammer: iGeoLoc_GPS (interference Geolocation) and jAware_GPS (jammer situational awareness). iGeoLoc_GPS can geolocate GPS band interference, but the effect on a GPS receiver is unknown. jAware_GPS can indicate if a GPS receiver is jammed, but not geolocate the jammer source.

The iGeoLoc_GPS uses a 5 MHz bandwidth centered at GPS L1. The jAware_GPS examines all outputs of a GPS timing receiver for both timing and position errors and other irregularities.

In order to facilitate testing with an illegal device, a typical GPS chirp jammer was frequency-translated to a nearby experimental-licensed band and will be referred to as the translated- jammer. The “jammer” will refer to a signal source originating from either an intentional jammer device or a source of unintentional interference. Intentional or not, both sources can degrade a GPS receiver.

System Level
First, let’s take a look at the overall jammer detection systems under consideration.

jAware_GPS Description. In some cases only awareness that the onsite GPS signal is being disrupted is required. jAware_GPS is meant to answer the question: “Do we have a jamming problem?”

This stationary sensor uses the number and received power of satellites, positional drift, GPS receiver lock status, and the accuracy of the pulse-per-second (PPS) output to determine the status of a GPS receiver. The PPS error is measured using the internal phase meter of a chip scale atomic clock (CSAC).

The phase meter measures the time difference, with a resolution of 450 picoseconds, between the internal CSAC 1 PPS and the externally applied PPS from the GPS receiver. In order to use the phase meter the CSAC is always configured in 1 PPS discipline mode with a 10-second time constant, and the PPS time difference is reported once a second (cycle to cycle) in nanoseconds. If the PPS time difference exceeds 10 nanoseconds, the position drifts more than a threshold, or a sudden change occurs in satellite information, a GPS outage is reported until the signals are stable for 10 seconds.

iGeoLoc_GPS Description. The current iGeoLoc_GPS (Figure 1) uses four semi-transportable sensing nodes (A, B, C and D) connected in two separate networks: a real-time data network and a Wi-Fi control network.

Each sensing node receives the translated-jammer band and retransmits it in its own dedicated backhaul band to the processing node (Figure 6, 8, and 9). This continuous real-time frequency translation is referred to as the data network.

The jammer geolocation is calculated at the processing node using a TDOA technique followed by a geolocation algorithm. No waveform assumptions are used. A blind cross-correlation is computed between all pairs of sensing node datasets to determine their relative time differences of arrival.

A common jammer signal must be detected by at least three sensing nodes. This permits at least two time differences to be calculated and then used to generate possible hyperbolic intersections and hence possible geolocation points (in the horizontal plane).

The TDOA cross-correlation and geolocation processing works with 2¹⁸ complex samples per node and has a latency of 6 to 10 seconds. As the processing node continuously receives all sensing node data, geolocation points can be continuously produced with the aforementioned latency.

In order to achieve greater sensitivity, the low-level processing is required to do overlapped cross-correlations of different sizes across all three combinations of sensing node data. These cross-correlations are then mode filtered, multipath-filtered, parabolically interpolated, and given a quality metric.

Cross-correlation qualities that are greater than a predefined threshold are then fed into the Bancroft geolocation algorithm, which enable one to obtain a direct solution of the receiver position and the clock offset without requesting any a priori knowledge for the receiver location. The geolocation results can then be enhanced by an optional snap to the road filter. We will provide details of these steps in the following sections.

iGeoLoc_GPS Sensing Nodes. Each sensing node contains two software-defined radios and the necessary RF filters and amplifiers to perform the previously mentioned frequency translation for the data network. Each sensing node is controlled by a small micro-processing computer that controls and configures both the radios and a camera attached to a panoramic lens. A panoramic photo is taken once a second, providing context to the geolocation results. The computer communicates on the Wi-Fi control network. The component cost of a sensing node is approximately $5,000 CAD (about US$3,777). (See Figure 2)

iGeoLoc_GPS Processing Node. The processing node uses an appropriate RF antenna, filters and amplifiers to allow a software-defined radio with a custom field-programmable gate array (FPGA) design to receive the four sensing node backhaul bands and digitally down-convert them synchronously to baseband. The previously described processing chain (cross-correlation through geolocation) is then performed. The component cost of the processing node was approximately $20,000 CAD (about US$15,108), which can be reduced by using a low-cost alternative to a server-class computer for signal processing.

Reference Frequency – 27 Megahertz. The sensing nodes’ radios have RF local oscillators (LOs) that can drift relative to each other unless provided with a common reference. To avoid this, the processing node generates and transmits a continuous one-watt constant 27-megahertz tone as the reference signal. The 27-megahertz tone is in an industrial, scientific, and medical (ISM) RF band and in the range of the radios’ acceptable reference phase locked loop (PLL) frequency (5 to 104 megahertz). The implementation of this reference scheme encountered standard HF difficulties, of large antenna dimensions and high RF power.

Cross-Correlation Processing. Traditionally TDOA is performed by calculating the difference of arrival between two signals with absolute timestamps. Since a difference is a relative measure, it does not need to be derived from two absolute measurements; the difference can be obtained from a cross-correlation process with a known relative offset between the two signals. A calibration process (described later) ensures that the offsets in a set of node-pair differences form a consistent set of equations for computing the jammer’s location.

The cross-correlations are performed using 262,144 complex samples. With a bandwidth of five megahertz, a stationary assumption can be used for a source travelling at highway speeds. An overlapped method that varies the data block size by multiples of 8,192 complex samples was created to generate more cross-correlation results over the dataset that could then be used for the mode filtering (described later).

The five-megahertz sensing bandwidth also allows for cross-correlation peak determination with a resolution of 200 nanoseconds (59.95 meters). Figure 3 shows an example cross-correlation result.

Multipath Mitigation. CRC developed a cross-correlation quality metric to ensure that only reliable data is used for locating the jammer. The metric is defined to be the magnitude difference between the highest and second-highest cross-correlation peaks in the cross-correlation function.

To illustrate the need for this metric, Figure 4 shows how multiple cross-correlation peaks can result from multipath effects. These can sometimes be discerned based on having longer delays than the true signal, but this is not always possible. The peaks considered were above a noise level where the noise level is defined as the first peak, sorted in descending order (by magnitude), that is at most two-thirds the amplitude of the next-highest peak.

The system considered a maximum of two peaks and took the peak with the least delay; otherwise the cross-correlation was not used. Finally, a parabolic interpolation between samples was done to provide accuracies better than the 59.95- meter resolution mentioned earlier.

Mode Filtering. Low-level data processing involves mode filtering. In order to distinguish it from noise, a true crosscorrelation peak should be consistent through a great majority of all the overlapped cross-correlations in the dataset. The geolocation algorithm only uses cross-correlations with a mode value greater than 70 percent occurrence.

Calibration of Sensing Node’s Local Oscillators. The 27-megahertz common reference frequency locks (synchronizes) all the sensing nodes; however, it will arrive at the nodes at different phases. The phase difference between nodes will be a constant error. The system can calibrate out any constant errors as the TDOA technique is based on a difference in time that is relative. The calibration stage produces an offset for each combination of node pairs that compensates for all constant errors. A recalibration is required every time the radios’ LO changes, which is on reconfiguration, restart or reboot.

A linear system of equations is empirically obtained by transmitting white noise in the translated-jammer band, from one node at a time and cross correlating the receiving nodes to get the corresponding delay. This noise is generated by a pseudorandom bit sequence (PRBS) in the software-define radios of the sensing nodes. A minimum of three node pairs are required to be determined empirically, and the others can be solved analytically.

Geolocation Algorithm. The geolocation is accomplished using Bancroft’s Algorithm to solve the multilateration equations. However, this can result in multiple solutions due to the multiple points of intersecting hyperbolas, an example of which is shown in Figure 5.

A simple clustering algorithm is used to determine the best points. The clustering criterion is the number of neighbors within a pre-defined threshold distance. The remaining points can also be displayed, as shown in Figure 6. The clustering is only meant to aid a system operator and suffices for a stationary jammer, as the best points should be close together. However, if the jammer is believed to be mobile, a snap-to-road filter can be employed.

The snap-to-road filter uses the OSRM (open source routing machine) project. Offline maps are generated for use with the OSRM algorithm, which uses a Hidden Markov Model as the probabilistic approach in determining route feasibilities. “No U-turns” is the only constraint used with the OSRM routing algorithm. Figure 7 shows the estimated jammer position after applying the snap-to-road filter.

Geolocation to Google Earth – Testbed Visualization
In order to visualize the system, the processing node creates keyhole markup language (KML) files that describe the translated-jammer’s position and the generated geolocation point(s). These KML files along with the sensor nodes’ photos are sent over a one-kilometer Wi-Fi link to an office computer to display the results in Google Earth in near real-time (Figure 8 and Figure 9).

Interference Geolocation – iGeoLoc_GPS Results
Parameters and results from recent experimentation performed at the CRC Testbed for the geolocation were as follows:

iGeoLoc_GPS (interference geolocation)

• Tracked route of a mobile 200-milliwatt GPS jammer
• Four sensing nodes covering a 450×300–meter track 
• ~10second latency, with a 0–20-meter error

These excellent performance results led to some further validation tests outside of the CRC testbed, where we expected very poor performance due to the large network size and poor measurement geometry and obstructed propagation paths. The results were as follows:

iGeoLoc_GPS Range

• Tracked approximate position of mobile 1,200-milliwatt GPS jammer
• Some detections were 1.4 kilometers away (Figure 10) 

Jammer Situational Awareness – (jAware_GPS) Results
The results for the situational awareness are:

• jAware_GPS (jammer situational awareness) 
• detected only disruptive GPS jammers up to 200–250 meters away at highway speeds 
• one-second delay, measured actual GPS outage time

To validate the previously described translated jammer testbed, jAware_GPS was brought to a site along the highway in Ottawa where illegal GPS jammers were initially found in 2011. The jAware_GPS sensor was used to trigger a low-cost spectrum recorder, with a multi-second ring buffer, upon jammer detection. A post-processing algorithm found some chirp jammers in the triggered spectrum collection. However, other unknown events were detected that resulted in similar GPS outage periods, as were caused by the identified GPS jammers. Further investigation is warranted and is being undertaken. Figure 12 illustrates a correlation amplitude of a jAware_GPS-detected chirp jammer event and can be contrasted against Figure 11 where no jammer is present.

A GPS status report across the country, similar to a weather report, could be generated by networking jAware_GPS sensors along major highways to report current and forecast future GPS status. If such a system were in place, a GPS outage could be seen moving along a highway, and an outage forecast could be generated for critical infrastructure (e.g., outage approaching airports).

Conclusions
This effort has proven that it is possible to build a low-cost system to detect and locate GNSS jammers in near-real time. In just more than one year CRC has designed, built, and tested such a system using many novel and sophisticated techniques to achieve impressive results. The iGeoLoc_GPS and jAware_GPS systems are new tools that can protect GNSS from the perils of jammers. The GNSS community can now employ these tools, empowering its spectral awareness.

Acknowledgement
The author would like to thank the dedicated team members — Wayne Brett, Dr. Paul Guinand, and Russell Matt—as well as the CRC for making this project a success. 

The post Is it possible to build a low-cost system to detect and locate a single GNSS jammer in near-real time? appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.

A: Simulating the propagation and reception of GNSS signals in complex environments is a challenging task. Indeed, the user always has to trade off between the computation time and the reliability of the output. Moreover, the motion of GNSS satellites, atmospheric effects, and building geometry are always difficult to model.

Q: What are the challenges of ray-tracing for GNSS applications?

A: Simulating the propagation and reception of GNSS signals in complex environments is a challenging task. Indeed, the user always has to trade off between the computation time and the reliability of the output. Moreover, the motion of GNSS satellites, atmospheric effects, and building geometry are always difficult to model.

This article describes how ray-tracing methods can produce consistent and reliable output. It also provides an example of validation of a software suite using a graphics processing unit (GPU)–based ray-tracing algorithm to model obscuration and multipath.

Methods for Modeling GNSS Signal Propagation
Simulations can help us assess the impact of the environment on the propagation of GNSS signals in con-strained surroundings such as urban settings. Indeed, simulations are relevant alternatives to test the performance of GNSS systems and services, compared to measurement campaigns in a live environment. Simulators enable users to control completely the operational parameters and then to test systems or services in different conditions. They also provide users with data to forecast the reception in a given area (for instance, for mission planning) or to analyze what happened in the field (for instance, for mission debriefing).

Several methods exist to compute the propagation of GNSS signals in constrained environments. These are summarized in Figure 1 (see photo at the top of this article for figures 1 – 4) and can be sorted into four categories according to the methods used to model the environment and the propagation.

Pure statistical methods (such as Rayleigh, Rice, Nakagami, and so forth) provide results quickly, but their accuracy and relevance can be low. Moreover, these methods rely on empirical parameters that can be difficult to tune to fit to real environments. Hybrid methods may partially overcome this drawback by using a deterministic approach to define either the environment or the propagation model.

Deterministic methods return accurate data but have two major disadvantages. Firstly, their reliability relies largely on the quality of models (or synthetic environments) used to define the environment (satellites locations, clocks, atmospheric conditions, buildings, vehicles, receiver properties, etc.). Indeed, the user can achieve a Laplace demon for a while only if the environment modelling (3D virtual scene and simulation parameters) perfectly matches reality. Unfortunately, it is not possible to create such a model with limited time and effort. Moreover, these methods are often time-consuming in complex environments such as urban areas.

Pure deterministic methods can be sorted in two categories as shown in Figure 2: full exact (such as Finite Element methods) and asymptotic methods. Unlike full exact methods, asymptotic approaches use approximations to solve the Maxwell equations but with greater efficiency. Specifically, they assume the dimensions of objects are greater than the wavelength of the emitted signal.

Asymptotic methods are divided in two main categories: ray-based and current-based algorithms. The first category uses geometrical optics (GO) and its extension for diffractions (uniform theory of diffraction or UTD) to compute the propagation of the signal whereas the second category relies on physical optics (PO) laws.

The objective of this article is to describe how ray-based asymptotic methods can be chosen to assess the propagation of GNSS signals in constrained environments and explain their added values and limitations.

What is Ray-Tracing?
A ray can be defined by three parameters: O, location of the emission source; ⃗dir, the direction vector; t, distance crossed by the ray.

The equation of the ray is: ray = O + dir⃗ * t

The objective of ray-tracing is to find all the possible paths from the receiver (also called the observer) to the emitter (also called the source), considering a limited number of interactions per emitted rays. A ray-tracer (or ray-tracing algorithm) uses a primary grid to cast primary rays, as shown in Figure 3. Then, it iteratively computes the possible interactions between these rays and the virtual scene (often defined using triangles). If those interactions exist (i.e., if they are compliant with the laws of physics) and if the number of interactions to reach the emitter is below the maximum number of interactions set by the user, a ray (or multipath) is created.

Ray-tracing techniques have two major issues: they require time-consuming algorithms and their accuracy depends on the resolution of the primary grid. Indeed, depending on the complexity of the scene (basically the number of triangles), a combinatorial problem to find the possible multipaths reaching the receiver makes the ray-tracer very slow. That is the reason why the most difficult task to achieve during the coding of a ray-tracing algorithm is to develop acceleration techniques to quicken the computation process.

Several solutions exist to either improve the intersection determination (for instance, based on spatial hierarchies such as bounding volume hierarchies or BVH techniques), or to decrease the number of cast rays (often based on adaptive sampling techniques), or even to replace rays with beams or cones. Moreover, today we can use the resources of a computer’s graphic board to accelerate the computation. Indeed, as ray-tracing can be coded by a large number of primary functions that can be treated simultaneously, it can be easily ported into a GPU.

As for the dependency of a ray-tracing technique’s accuracy on the resolution of the primary grid, details and therefore rays may be missed if the three-dimensional scene is made up of small details. This issue is called aliasing. Aliasing artefacts appear, for instance, in parts of the scene with abrupt changes (such as edges) or in complex areas with lots of constituent objects. Solutions (or anti-aliasing techniques), such as adaptive or stochastic samplings, exist that can deal with this phenomenon.

Ray Tracing for GNSS
Ray-tracing techniques are often used to model the propagation of GNSS signals in constrained environments. Indeed, by means of a ray-tracing algorithm, software can simulate two phenomena of propagation (see Figure 4):

• obscurations, line-of-sight (LOS) signals that cannot reach the receiver due to the presence of buildings between the emitters and the receivers, which may lead to availability problems
• multipaths, reflected, diffracted, transmitted, scattered signals that generate positioning errors and fading effects.

As ray-tracing is a deterministic method, specular multipaths can be displayed in 3D and their attributes (receiver power, phase, polarization, Doppler, geometry of the ray, and so forth) are known. It is therefore easy to see the contribution of some part of the environment on the propagation of the signal.

The Synthetic Environment
The main input of a ray-tracing algorithm is the synthetic environment, a virtual modeling of a real or realistic environment in terms of both geometry and physics. The geometries of the buildings or the objects define the shape of the rays. The definition of the intrinsic parameters of the materials of the objects (permittivity, conductivity, and thicknesses of the walls, and so on) enables computation of the interaction between the signal and the objects.

These synthetic environments may be sorted into three categories:

• Fictitious mock-ups. These 3D scenes do not model any real or realistic environment. The mock-ups are mainly used to assess a GNSS system or service, in particular, geometrical and/or physical configurations, or to study the impact on the results when varying some parameters, such as the influence of a modification of roof shapes (buildings with realistic roofs, with flat roofs, without any roof, and so forth) on the visibility of the satellites.
• Geotypical mock-ups. These mock-ups model a realistic environment, i.e., an environment that does not exist but that looks familiar (e.g., dense European city, a mountainous area). They are based on real parameters such as real footprints and/or heights of buildings but some parts (for instance, the shapes and the locations of the doors or the windows or the roofs) are randomly defined. Templates of buildings are used to characterize the global shapes of the buildings to be created. Geotypical environments are mainly used to assess the availability and performance of GNSS systems in a typical environment, for instance for statistical studies.
• Geospecific mock-ups. These mock-ups model a real environment, and are accurate descriptions of a real scene in terms of geometry and physics. These 3D scenes are used to either reproduce actual signal reception (e.g., for mission debriefing), or to forecast a reception (e.g., for mission planning) or even to populate a measurement campaign with simulated data. In such cases, the quality of the 3D mock-ups has a strong effect on the consistency and the reliability of the results. Indeed, the geometries of the buildings or obstacles (such as street lights, road signs, vehicles, etc.) must mimic the local environment as closely as possible in order to be compared to measurements.

Validation – Example of Simulated Data
A measurement campaign was recently conducted to validate the performance of a simulator based on ray-tracing algorithms. Two parts comprised the simulation system (screenshots shown in Figure 5 (see inset photo, above right, for figures 5 – 8)): a typical GNSS simulator capable of modeling the constellation and relevant receiver characteristics and a GPU-based ray-tracing algorithm to deterministically compute obscuration and multipath parameters.

Both software applications communicate in real-time through a TCP/IP protocol. The computation frequency has been set to 10 hertz.

We selected a U.S. street for the simulation and for the measurement campaign with the local environment created from raw data. These raw data, which model the geometry of the large structures (buildings, large objects), have been created using photogrammetry techniques from satellite stereoscopic imagery. The resolution of the input images was 50 centimeters.

Then, we post-processed these data to add geometrical details (buildings windows, doors, street objects, and so on) and to define the building materials. Figure 6 shows how the model evolves from low to high resolution.

Figure 7 compares measured and simulated data when only obscuration has been considered (no multipath). The results of the measurement campaign indicates that general trends are globally reproduced: the simulated levels of the received power are fair for GPS-05 and GLO-09. Regarding GPS-02, the drop of power is caused by the obscuration of the LOS signal as explained by the simulated data. However, the simulated power does not correctly mimic the small variations of power, mainly due to multipath interactions and interferences.

Figure 8 shows the evolution of the simulated carrier-to-noise-density ratio (C/N₀) when multipath is considered: a maximum of four reflections and one diffraction per multipath have been modeled and 10 multipaths per channel have been taken into account.

The graphs in Figure 8 show a better consistency between measured and simulated data. The variation of power is more erratic and the visibility of the satellites is similar to actual measurements of signals.

Nevertheless, some discrepancies can be observed in the power level. Several causes can explain such discrepancies, such as quality of the scene (especially for low elevation satellites with only non-LOS reception) or the surrounding traffic during the test (vehicle or pedestrian) and the vegetation (for instance, isolated trees), which have not been modeled in the simulation.

Deterministic simulations never produce data that fits perfectly with real measurements. Indeed, they highly depend on the realism of the synthetic environment, and it is not possible (with limited time and effort) to perfectly mimic a real configuration. However, the added value of using such algorithms is certain when we compare measurements with statistical and deterministic simulations.

Ray-tracing algorithms will not perfectly reproduce what happened or what could/will happen, but they can supply data that match real measurements as closely as possible, according to the quality of the definition of the synthetic environment.

The post Challenges of Ray-Tracing for GNSS Applications appeared first on Inside GNSS - Global Navigation Satellite Systems Engineering, Policy, and Design.