Achieving Maximum Realism in GNSS Spoofing


Creating a realistic test environment is essential for understanding the receiver’s likely behaviour in real-world adversarial conditions.

The aim of GNSS receiver testing is to understand and optimise how the device will perform in the real world. But that immediately creates a quandary for test teams. Rigorous testing requires the test environment to be repeatable and controllable, but the real-world environment is rich and dynamic. So how can testers bring realism into their workflows without sacrificing repeatability and controllability?

Let’s take an example from vulnerabilities testing. GNSS signal spoofing is a growing threat to receivers, evidenced in incidents like those in the Black Sea in 2017 and in Shanghai in 2019, where multiple ships’ navigation systems were spoofed into reporting a false position.

Receiver developers and integrators need to know how their product will behave when confronted with a fake signal. Will it be able to distinguish it from the genuine signals and reject it, or will it lock on to the fake signal and potentially endanger the equipment, its users or others in the vicinity?

Fully simulated signals can create a worst case scenario

Spoofing testing is typically conducted in the lab, with the simulator equipment generating both the ‘truth’ signals and the spoofed signals. This way, the test can be re-run with exactly the same conditions, or the parameters of the test can be changed and the results observed. The tester has full control over the environment, so any differences in the way the receiver responds can be confidently put down to the receiver design rather than external conditions.

But while this provides valuable insight into the receiver’s ability to withstand a spoofing attack, it isn’t representative of the way the same receiver might experience a spoofing attack in the real world.

In a real scenario, the genuine signals emanate from space, while spoofing signals come from a nearby spoofer, usually on the ground. Crucially, the two sets of signals will never be fully synchronised, even with a smart spoofer that is able to estimate the position of the receiver it’s attacking and compensate for it.

This means the results observed in the lab tend to represent a “worst case” scenario, in which a spoofing attack is fully synchronised with real-world signals. In reality, it’s extremely challenging for an attacker to generate and broadcast a replica signal that will cause a receiver to lock on to it – particularly if the aim is to take control of that receiver and direct it to a desired location.

So how can testers create lab conditions that will give a more realistic idea of how the receiver will behave in a genuine spoofing attack?

Bringing live sky signals into the lab for improved test realism

One major step towards realism is to have the receiver use genuine live sky signals and generate the spoofed signals in a simulator. This can be done outdoors on a dedicated test range, but it can be challenging – particularly because it typically requires a lot of paperwork to gain permits to broadcast simulated signals outdoors. As such it’s often only really viable for end-stage performance testing for high-end receivers.

A more viable approach is to bring genuine signals to the device under test (DUT) alongside the replica signal generated by a simulator. That can be done by having the DUT receive live signals from a roof-mounted antenna, and aligning the simulated spoofing signals with them.
To ensure the simulated spoofing signals are aligned with the live sky signals, a tool like Spirent’s Standpoint obtains timing and ephemeris data from live sky for accurate synchronization (see diagram below).

Test setup for conducting lab-based spoofing vulnerability tests using simulated spoofing signals synchronised with live sky signals.

Spirent tests show the difference when live signals are used

To understand the impact of this improved realism, in 2020 Spirent conducted spoofing tests on the same two GPS receivers – firstly with all signals simulated, and then with simulated spoofing signals but genuine live sky signals. In the latter case we used the Standpoint tool to synchronise the two sets of signals.

The results – summarised in a blog by Spirent’s Dan Martin – showed that the receivers responded differently to a simulated spoofing attack when live sky signals were present. For example, in the live sky scenario, one of the receivers was able to resist an attack from a 10m range, which it had not in the fully-simulated scenario. However, although their behaviour was different with live sky signals present, the tests showed that both receivers were still vulnerable to attacks within a 50–100m range of the spoofer.

These results demonstrate the value of bringing more realism into vulnerabilities testing, since behaviour observed under fully-simulated lab conditions may not reflect the behaviour exhibited by the receiver in real-world conditions. Developers and designers therefore need a mix of both approaches to evaluate and address receiver vulnerabilities as early as possible in the product development cycle.

Standpoint: more than just spoofing testing

Spirent’s Standpoint tool isn’t just useful for synchronising live signals with simulated spoofing signals. It also enables testers to move seamlessly from a live sky environment to an anechoic chamber for testing. Standpoint’s Live Sync utility means the device does not have to be cold started when moving from the live environment into the chamber, allowing faster and easier testing.

If you’d like to know more about the importance of realism in GNSS testing and how to achieve it, watch our recent webinar, Realism in GNSS Testing, or read our ebook, How to Create a Realistic GNSS Test Environment in the Lab.




Romain Zimmermann
Romain Zimmermann

Product Line Manager

Romain Zimmermann has worked on various aspects of PNT testing at Spirent, from product management to business development. He is currently responsible for Spirent’s inertial sensor simulation portfolio and has a particular interest in new PNT challenges brought by the development of applications such as autonomous vehicles, robots and 5G. Prior to his work at Spirent, Romain worked in mobile telecommunications as a product manager within network equipment manufacturers and service providers. Romain holds a MSc in Telecommunications Engineering from Telecom SudParis, in France.