Blog

Markus Irsigler, Sebastian Kehl-Waas, Carsten Stöber, Jürgen Dampf, Rohde & Schwarz GmbH & Co. KG

GNSS jamming and spoofing pose a significant threat to global security, as satellite-based navigation and timing systems are utilized in various application fields, including critical infrastructure, transportation, military operations and communication networks. These intentional interferences disrupt signals or deceive GNSS receivers, leading to navigation errors, loss of situational awareness and potential safety hazards.

Local, low-power jamming is often used to deliberately prevent GNSS-capable devices from recording their positions and being tracked. Such jamming devices, known as personal privacy devices (PPDs), are typically used to prevent fleet monitoring, concealing personal travel, or evading toll systems. Although mostly illegal, PPDs are fairly widespread and can pose a significant threat to GNSS availability, at least on a local scale.

On the other hand, larger-scale incidents are observed very frequently. Regional jamming often occurs in conflict zones to protect military assets or disrupt enemy operations. Jamming has also been reported near critical infrastructure. Spoofing is typically less frequent than jamming, but it poses a more concerning integrity threat when incorrect PVT data is used for navigation. Well-documented events include the (in)famous 2017 incident affecting ships in the Black Sea, where a spoofed GNSS signal led vessels to report incorrect positions. Jamming and spoofing also play an important role in the Ukraine conflict, where it is used to disrupt enemy drones, guided munitions, and navigation. Such events clearly highlight the vulnerability of GNSS-dependent systems and the need for robust mitigation techniques and strategies.

Against this background, testing how GNSS devices react to such threats has become more and more important, especially if they feature dedicated jamming detection and mitigation techniques. In such cases, the main test objective is to verify that these detection and mitigation techniques work as expected and that the GNSS receiver reacts properly and as expected in response to such attacks.

Categorization of GNSS Threats

Although jamming and spoofing can be considered the most critical threats, GNSS signals can be degraded in various other ways. Signal degradation effects can occur anywhere along the path from the GNSS satellite to the user. They can be caused by the transmitting satellite itself, usually in the form of hardware malfunctions, typically referred to as “evil waveforms.” They can also occur along the signal path in the form of ionospheric and tropospheric errors or scintillation effects, or they can be a result of the conditions in the vicinity of the GNSS user. This includes jamming, spoofing, RF interference caused by other signals, as well as signal obscuration and multipath caused by buildings or trees.

“Evil waveforms” can pose a significant threat to GNSS signal integrity, leading to large positioning errors. However, the occurrence of this effect is very rare and therefore not specifically considered in this article. There are also some atmospheric effects that have the potential to significantly degrade the quality of GNSS signals. Especially ionospheric and tropospheric scintillation due to temporal, fast-changing atmospheric conditions can cause rapid amplitude and phase variations, leading to reduced C/N0 or even loss of lock. Again, this does usually not happen every day and is therefore not discussed in detail below either.

The most critical and common GNSS threats originate from interference signals that occur in the vicinity of a user receiver. Unlike system-inherent threats that originate from GNSS satellites or atmospheric conditions, these threats can be termed as “man-made” and categorized as shown in Figure 1.

Jamming can be divided into two types of attacks. Brute-force jamming aims at completely blocking GNSS reception for a receiver by deliberately emitting interference signals like CW interferers, broadband noise or frequency sweeps with very high-power levels. As a result, the carrier-to-noise values will drop below the receiver’s acquisition and/or tracking threshold, and GNSS signals cannot be processed anymore. In contrast to such a simple jamming attack, where the attacker needs to have only basic knowledge about the GNSS signals (e.g. center frequencies and signal bandwidths), systematic jamming is a much more sophisticated attack, which can be further divided into

• Intelligent or smart jamming. The objective is to jam only a specific part of the navigation message (e.g. the ephemeris data section), so that the navigation message can never be fully decoded and the receiver will never be able to perform a position fix. All other parts of the navigation message remain unaffected, allowing signal tracking to continue for the receiver. Figure 2 illustrates this attack on the GPS L1 C/A signal.

Smart jamming is much more complicated to implement for an attacker as the jammer must only be active during specific time intervals; this requires that the jammer is somehow synchronized with GNSS/Coordinated Universal Time. Moreover, the attack requires knowledge of the navigation message structure and what information the receiver needs to compute a position. Nevertheless, if done correctly, the attack is rather difficult to detect [1].

• Matched spectrum jamming. The objective is to generate a GNSS-like jammer signal with the same spectral characteristics as the real GNSS signals but without any valuable navigation information (i.e. the navigation message is missing). Matched-spectrum jamming is not straightforward, and to be effective, an attacker must replicate the GNSS signals for multiple visible satellites simultaneously, considering signal characteristics such as pseudo-random noise codes and, ideally, their correct Doppler shifts.
In contrast to jamming, GNSS deception techniques aim to force the receiver to compute an incorrect PVT solution, compromising the integrity of GNSS-based navigation. The two basic methods are:

• Meaconing. This rather simple approach is based on rebroadcasting a delayed version of live GNSS signals. This can be realized by using a commercial GNSS repeater. Alternatively, previously recorded actual GNSS signals can be replayed.

• Spoofing. This includes generation and broadcast of forged GNSS signals. This is typically done using a GNSS simulator, but specialized, modified GNSS receivers combined with a transmitting unit can also be used. The simulated signals need to be self-consistent, i.e. a GNSS receiver must be able to compute a PVT solution based on the simulated constellation. Spoofing attacks can be rather simple, e.g. broadcasting high power signals that represent a different location than those of the receiver under attack. The aim is to force the receiver into a reacquisition process, tracking and processing only the fake GNSS signals. More sophisticated spoofing attacks are possible [2], but not discussed in this article.

Additionally, the PVT performance of a GNSS receiver can also be degraded by objects in the vicinity of a GNSS user, causing signal obstruction and reflections from buildings, trees, or the ground. Multipath can cause significant ranging and positioning errors. Multipath effects can hardly be avoided and must be seen as a permanent threat to GNSS signal quality.

Finally, other existing signals and services can interfere with GNSS, either because there is a frequency overlap (in-band interference) or harmonics from other signals fall into the GNSS bands (out-of-band interference). As an example, the upper part of the DME/TACAN band overlaps with a significant portion the GNSS L5 band. The effect of this type of interference on GNSS receiver performance can be analyzed by performing coexistence tests.

RX-Internal Detection and Mitigation Methods

At least some of the threats discussed above can be detected and/or mitigated by the GNSS receiver. The capability of a GNSS receiver to detect and apply countermeasures to threats such as multipath, jamming or spoofing depends on the receiver’s availability of specific features and its basic architecture. Figure 3 shows the basic building blocks of a typical GNSS receiver with a single, fixed reception pattern antenna (FRPA).

Figure 3. Basic architecture of a FRPA receiver

The three basic building blocks are the antenna, the RF front-end and the digital signal processing section. The antenna is responsible for receiving the weak GNSS signals as well as for successive amplifying and band-limiting. It typically features a low noise amplifier (LNA) and a band-pass filter. The signals are then fed to the receiver front-end where the signals are amplified, down-converted to an intermediate frequency and converted to the digital domain. Part of this process is the automatic gain control (AGC) loop; the AGC acts as a variable amplifier, adjusting the power of the incoming signal and keep it constant over time. The sampled and quantized stream of IQ data is then fed to the digital signal processing section, where signal conditioning, acquisition and tracking, and PVT solution computations take place.

In contrast to using a single antenna with a fixed antenna pattern, some receivers use an adaptive antenna array, also referred to as controlled reception pattern antenna (CRPA). The idea is to weigh the signals received by each element according to dedicated optimization criteria. Typical optimization criteria are to minimize the signal’s output power towards a dedicated direction (“null-steering”), or to maximize the signal to interference or signal to noise ratio (“beamforming”). The underlying receiver architecture is more complex as signal weighting mechanisms must be added to the signal processing chain. These can be integrated before the digital processing block (“pre-correlation”) or implemented as an additional processing step between the correlation and tracking stages in the digital signal processing section (“post-correlation”). Both approaches are very effective in mitigating jamming and spoofing attacks, as they can either form a null in the direction of a strong jammer/spoofer or form beams towards the wanted signals from GNSS satellites, thereby de-weighting any unwanted signals coming from other directions.

Pre-correlation architecture of a 4-channel CRPA receiver

Post-correlation architecture of a 4-channel CRPA receiver

Within the processing chain of a GNSS receiver, there are different approaches and methods to detect and mitigate interfering signals, which are summarized in the following table:

AGC monitoring	●	●	Monitoring of the gain in the AGC loop. A sudden drop of the AGC gain can be an indication of an interfering signal; detection of high-power interferers; low-power spoofing attacks very difficult to detect
Spectrum monitoring	●	●	Detection of interferers and jammers above the noise floor; especially suited for detecting CW interferers. Not suited for the detection of matched-spectrum jammers, spoofers and meaconing attacks as their spectrum is typ. identical to the GNSS spectrum.
Frequency domain adaptive filtering	●	●	Dynamically identifies and suppresses unwanted frequency components (e.g., interference or multipath) by adjusting (notch) filter parameters.
Pulse blanking	●	●	Pulse blanking is a time-domain interference detection and mitigation technique used in GNSS receivers to detect and suppress short-duration, high-power pulses, typically caused by pulse jammers or Radar transmitters. Monitors the incoming signal power in short time windows and “ignores” this signal part in case certain power level thresholds are exceeded. Effective to mitigate pulsed jammers, not suited for multipath mitigation or anti-spoofing measures.
C/N0 monitoring	●	●	Monitoring over time and/or comparison against theoretical max. value; detection of all types of interferers; low-power spoofing attacks very difficult to detect
Time jump detection	●	●	Time jumps (backwards or forwards) are clear indications for meaconing or spoofing attacks.
PVT monitoring, incl. RAIM	●	●	Example: The computed position can be constantly compared against a known reference position. Not possible to distinguish between jamming/spoofing or other environmental effects like multipath. This also includes receiver-autonomous integrity monitoring (RAIM) schemes, that can be considered as a special form of PVT monitoring.
Doppler monitoring	●	●	Compare Doppler against theoretical/geometrical values; monitored Doppler profiles may show irregularities in case of an attack. Difficult to be separated from environmental or atmospheric effects.
CMC monitoring	●	●	„Code minus Carrier“ observable shows irregularities and increased noise in case of an attack. Difficult to be separated from environmental or atmospheric effects.
Signal Quality Monitoring (SQM)	●	●	Sampling of the correlation function using a few correlators; can detect distortions of the correlation function resulting from multipath, jamming or spoofing attacks.
Massive multi-correlator monitoring	●	●	Continuous, high resolution observation of the code/Doppler space. Can be done during signal acquisition and tracking. Can detect multipath, jamming, meaconing and spoofing attacks.

Derived Test Requirements

Based on the typical threat signal and attack characteristics, as well as the receiver-internal detection and mitigation methods discussed above, the test and simulation requirements listed in the table below can be derived. In addition to the requirements related to threat simulations (grey background), the table also contains “base requirements” for the simulation of realistic GNSS scenarios (blue background):

Testing: Methods, Setups and Challenges

The test methods, strategies and setups used depend on the architecture of the GNSS receiver being tested, the receiver features that need to be evaluated and the specific testing objectives.

A first categorization can be made by examining the origin of the GNSS signals being used for testing. The signals may come from real GNSS satellites and be used instantly and on-site (live GNSS testing) or recorded, stored, and played back in the lab (record/replay). Alternatively, testing can be done entirely in a lab environment using GNSS simulators. There are also hybrid test methods that will be discussed later in this article. In comparison to using real GNSS signals – either via live testing or the record/replay approach – using GNSS simulators in a lab environment offers significant benefits.

Simulation vs. Live GNSS Testing. One major drawback of using live signals is that the system conditions are often unknown at a given point in time, and – most importantly – they change over time. The locations of the satellites — and thus the geometric conditions — change as the satellites move along their orbits. Errors, such as atmospheric effects, are also time- and location-dependent. One of the most unpredictable error influences is multipath. The magnitude of multipath errors depends on a variety of different parameters, including the number of reflections, the distance between the reflection points and the antenna or the strength of the reflected signal. The latter is determined by the material properties of the reflecting surface. Both the geometric conditions and the material properties of the reflectors change or may change over time – the geometric conditions due to the permanent motion of the satellites and the reflector properties due to meteorological influences like rain, dew, or snow.

As a result, when using live signals, one must expect that the conditions change permanently and unpredictably and will never be the same for two distinct points in time. It is therefore very unlikely that two successive test runs can be performed under identical conditions. Repeatable testing, which is one of the most important test requirements, is impossible when using live GNSS signals.

Well-defined and controlled simulation conditions can only be ensured by using a GNSS simulator. A simulator typically offers fully customizable and repeatable scenarios (i.e., one and the same test scenario) that can be repeated as often as needed, producing the same signals with the same characteristics. Moreover, a simulator is often a more cost-effective and efficient solution, whereas using live signals would be time-consuming, complex, expensive or even impractical (e.g. test of airborne and spaceborne receivers).

The following discussion of typical test setups therefore focuses on the use of signal generators for GNSS testing. In terms of test scenarios, the focus will be on jamming, spoofing and coexistence testing. Testing against multipath influences is not specifically discussed below.

Basic simulator setups. The basic approach for testing against GNSS threats is to combine a “clean” reference GNSS simulation scenario with interfering signals and add the combined signals to the device under test (DUT). This basic concept can be implemented using two separate signal generators or an integrated solution that combines GNSS simulation and threat signal generation in a single instrument. Based on the architecture of the integrated solution (1 RF output vs. multiple RF outputs), GNSS and interfering signals are already combined internally, or GNSS and interfering signals can be fed to different RF outputs and combined with an external combiner before fed to the DUT.

Using two separate signal generators for GNSS threat testing. The interference generator (red) can either be a second GNSS simulator for generating spoofing signals or any other signal generator providing non-GNSS signals for jamming or coexistence tests.

Using a GNSS simulator with integrated interference generation capabilities. The signal generator features 1 RF outputs. GNSS and interfering signals are combined internally. An external combiner is not needed, but the dynamic range between GNSS and interferer (J/S) is usually limited.

Using a GNSS simulator with integrated interference generation capabilities. The signal generator features 2 RF outputs. GNSS and interfering signals fed to individual RF ports and combined externally. This requires an external combiner, but with the benefit that very high J/S ratios can be achieved.

Conducted testing vs. OTA testing. The basic setups introduced above only work if the receiver has dedicated and accessible input connectors to feed the antenna signal to the receiver’s front end. This is sometimes not the case, so that conducted testing is not possible and over-the-air (OTA) tests must be considered. A classic example of such DUTs is mobile phones, where no antenna connector is available, at least not without dismantling the device.

Testing such devices against interfering signals is still possible by using a shield box. The shield box has an RF input to feed in the combined GNSS and interfering signals. The signals are then retransmitted into the inside of the box and the DUT uses its integrated antenna to receive and process the signals coming from the GNSS simulator.

Using a GNSS simulator in combination with a shield box to test GNSS devices with integrated antennas.

OTA GNSS threat simulation using a shield box with 2 RF inputs and 2 transmit antennas. The GNSS signals and the interfering signals are fed separately (uncombined) into the shield box.

An alternative setup is to use a shield box with two RF inputs. In this case, the wanted signals and the interfering signals are not combined externally but are fed to the shield box via separate RF input connectors and transmitted to the GNSS DUT via separate transmit antennas.

Additional aspects and challenges must be considered when performing OTA tests using mobile phones as a GNSS DUT. This includes conducting a proper cold start, removing all preexisting navigation-related information from its memory, and disabling any other sensors that may contribute to computing the phone’s position, including any assisted GNSS services. This is typically not a concern for most standalone GNSS receivers that feature dedicated cold start procedures and usually have no other positioning sensors on board. On the other hand, initiating a real cold start for GNSS modules in mobile phones can be tricky. Just rebooting the phone does not necessarily work, and the availability of dedicated settings also depends on the phone’s operating system (e.g. iOS vs. Android).

Another challenge during OTA testing of mobile phones is how to assess and analyze the impact of any interfering signals on signal acquisition, tracking and positioning. This requires detailed analysis and monitoring features on the mobile phone, which are typically not a standard feature of the phone’s operating system. Specialized GNSS monitoring apps can be used instead. To get access to the data during the test, special screen mirroring apps can be installed on the mobile phone.

Testing with live signals. GNSS tests may also be performed in combination with live GNSS signals using already existing field infrastructure such as GNSS receivers installed at mobile base stations. A typical use case is to add one or several jamming/spoofing signals, or even an entire (stronger) “spoofing constellation” to an existing “live GNSS constellation” and test how the GNSS receiver reacts to such an attack. The typical test setup is illustrated in Figure 4.

This approach may be a good alternative to simulating everything with a GNSS simulator, as much more HW, i.e., more GNSS channels and more RF paths, are required with a simulator-internal approach. On the other hand, there are also some challenges associated with this test method, e.g., the signal generators, which need to be operated in a field environment. Moreover, for more sophisticated spoofing attacks, a prerequisite is the capability to time-synchronize the GNSS simulation with the live GNSS constellation.

CRPA testing. For testing GNSS receivers with multiple antenna inputs, particularly CRPA systems, several RF sources/paths need to be combined and synchronized. The following illustration shows a possible setup for testing a 4-channel CRPA receiver against jamming or spoofing attacks. It is based on the 2-path architecture introduced above. It consists of two signal generators for generating GNSS signals for each antenna (left part of the setup) and two signal generators for generating the jammer/spoofer signals (right part of the setup). GNSS and interfering signals are combined per antenna element and fed to the RF inputs of the CRPA receiver under test.

For CRPA testing, generating phase-coherent signals is a must, i.e., it must be ensured that the phase relations between the GNSS signals and between the interfering signals represent the actual geometrical conditions and, above all, remain consistent throughout the simulation. To achieve this, a common LO signal needs to be used for generating the GNSS and interferer signals in all signal paths.

Another challenge is related to calibration. To correctly simulate the directions of the satellite signals and the interference signals, the test system must be calibrated at the RF interface to the DUT with respect to amplitude, phase and propagation time. This means that the amplitude, phase and propagation time differences between the individual RF paths, resulting for example from cables orRF components, must be compensated.

Rohde & Schwarz Solution

With GNSS test solutions from Rohde & Schwarz, all the relevant requirements for testing GNSS receivers against GNSS threats can be addressed. Available test solutions range from simple, single-channel, waveform-based signal generation with limited simulation time up to multi-frequency, multi-constellation GNSS simulators with 2 RF outputs, hundreds of GNSS channels and internal threat simulation capabilities, including non-GNSS signals for jamming and coexistence tests. For these advanced GNSS tests, the R&SSMW200A high-end vector signal generator is the ideal choice. It can be equipped with a multitude of GNSS options and feature sets.

Jammer simulation. There are several ways to generate jamming and coexistence signals with Rohde & Schwarz signal generators in general and especially with the R&SSMW200A. Simple interference signals like noise or a CW interferer can be generated by using an optional integrated noise generator. For coexistence testing, the instrument can be equipped with signal generation capabilities for various standard-conforming communication signals, such as LTE. Customized interferer signals in the form of waveform files can be created by external software tools like MATLAB or Python and replayed by the instrument.

Customized jamming signal as well as entire jamming and coexistence scenarios can also be created using the R&SPulse Sequencer. The software allows to generate typical simple GNSS jamming signals like CW interferer, frequency sweeps, or pulsed interferers, but also complex jamming scenarios with consideration of moving interference sources and moving GNSS receivers, user-defined antenna patterns and scans. Depending on the signal characteristics, the jammer and receiver positions and the antenna arrangement, the software calculates the correct amplitude, phase angle and signal propagation times for the jamming signals.

Further reading

[1] Curran, James T. et. al. (2017): A look at the Threat of Systematic Jamming of GNSS, InsideGNSS, September/October 2017

[2] Dovis, Fabio et. al. (2015): GNSS Interference Threats and Countermeasures, GNSS Technology and Application Series, Artech House, 2015