Building Confidence: OSNMA Client Integration in Real Scenarios

Upon every step in the development of the OSNMA client in Rokubun, post-process tests were undergone to verify the correct implementation of the algorithm. These tests included the test vectors provided by EUSPA in the OSNMA Receiver Guidelines for the Test Phase v1.1, as well as some real-time processing tests at Rokubun headquarters. These tests bolstered our confidence in achieving a satisfactory level of integration.

The testing activities were done in the Joint Research Centre facilities in Ispra, Italy, during the 27th and 28th of February.

The OSNMA client has been developed in the scope of the BANSHEE project (EUSPA - GSA/GRANT/04/2019). BANSHEE is a project that hybridizes GNSS with Wi-Fi RTT technology and one of the technologies being pursued in the project is spoofing detection with alternate PNT systems (e.g. Wi-Fi RTT) and OSNMA.

The validation test

The OSNMA client was embedded in the Rokubun’s MEDEA receiver, based on a u-blox ZED-F9P and an application processor (see Figure 1). This was the Device Under Test and was connected to different spoofing sources throughout the testing process. The undergone tests include the spoofing detection with a simulated signal and the spoofing detection with live synchronized counterfeit signal, all of which were successful.

Figure 1. Device Under Test: Rokubun’s MEDEA GNSS receiver‌‌

For the first test, the spoofing detection with a simulated signal, the Spirent GSS9000 signal simulator with a predefined static scenario centered at ISPRA was used (see Figure 2). A text file containing the 240 bits of the navigation message were fed to the Spirent simulator, which was in charge of generating the bits in the signal being generated. These navigation bits could be modified manually to represent the possible OSNMA failure scenarios to encounter: failure of the tags verification, failure of the TESLA chain key and the failure of the KROOT verification.

Figure 2. A static scenario centred at ISPRA was used during the execution of the tests

A nominal conditions run was initially conducted as a baseline test. Then, the degraded tests were run starting from the tag verification failure scenario. To simulate this, the IOD value for all satellites was shifted; as this value is part of the ADKD0 message to be verified, the verification of the tags in the MACK should fail. Next, the failure of the TESLA chain key test was performed. Some bits of the TESLA key in the MACK were shifted so that its verification against the KROOT failed. Finally, the failure of the KROOT verification was simulated by changing one bit of the WN value needed to perform the digital signature verification to verify the authenticity of the KROOT.

The second test, the spoofing detection with live synchronized counterfeit signal, checks the OSNMA functionality in a scenario where the legit signal, coming from the rooftop antenna, is mixed with a forged signal that mimics the actual real and live signal. This is done using an Orolia simulator with a Septentrio receiver in charge of providing the simulator with the live time information and with the observed GPS and Galileo navigation files (see Figure 3). The forged signal is configured to imitate the visibility conditions of the live signal, but the spoofed position it transmits corresponds to the entrance to the JRC facilities.

Figure 3. The Orolia simulator used a Septentrio receiver to collect data from the roof, feed it back to the simulator to simulate a scenario that resembles the live signal

Results

All of the obtained results were in line with the expected behavior of the client. The results of each test were observed via the MEDEA Dashboard, in which we could see the OSNMA status of all the satellites in view (Figure 4), as well as via the logs of the code (Figure 5).

Figure 4. Front-end of the MEDEA Dashboard. In the Trust monitor section, OS-NMA status of all satellites in view display are Validated.

Figure 5. Code logs in the baseline test.

Conclusions

Through the tests conducted at the Joint Research Centre, Rokukubun's protocol implementation was evaluated in degraded conditions, both in simulated and live environments. The successful outcomes of the OSNMA tests ensurances the effectiveness of the algorithm within Rokubun’s processing engine.

Currently, the Rokubun OSNMA client is undergoing ongoing advancements, enabling its validation for resilient drone surveillance. Moreover, it has been tailored for embedded platforms, ensuring smooth integration and comprehensive support across multiple platforms.

Rokubun is a deep-tech company that develops innovative navigation technologies, oriented to fulfilling a new demand for ubiquitous, accurate, and scalable geolocation technologies.

SPEAR (Satellite Positioning Engine for Accurate Real-Time Navigation) is a software library for accurate and robust navigation that can enhance the location of the devices to the range of centimetres. SPEAR can work on any platform (platform-agnostic) and is designed to get the best navigation performance of mass-market or industrial devices, such as smartphones, cars, or drones.