GNSS jamming & spoofing detection and RF interference classification

Satellite navigation underpins aviation, shipping, telecom timing and power grids, yet its signals arrive at the receiver weaker than thermal noise and are easy to overpower. Since 2022 persistent jamming and spoofing, especially around the Baltic, Black Sea and Eastern Mediterranean, has made detection an operational necessity. ML on spectrum data, receiver telemetry and aircraft/vessel integrity reports turns raw RF into classified alerts, interference maps and enforcement evidence.

Problem & value

• Who: air navigation service providers (ANSPs), airports, airlines, spectrum regulators (e.g. Bundesnetzagentur), mobile and broadcast operators, grid and financial-market timing operators, maritime authorities, and defence users.
• Today: detection relies on pilot reports, receiver alarms, a few fixed monitoring stations and manual spectrum analysis. Spoofing is the harder case: EASA stresses it may not be immediately noticeable to crews and carries more safety risk than jamming, which usually shows immediately [1].
• AI value: continuous classification of interference type, earlier spoofing detection without specialised hardware, fusing many weak sensors into maps, and consistent evidence for NOTAMs and enforcement. Publicly reported ML results (e.g. high accuracy on jamming detection from raw measurements) come from curated datasets and must not be read as field performance [3][4].
• Context: EASA SIB 2022-02 has been revised repeatedly (Revision 4 in 2026) with a joint EASA-EUROCONTROL task force on GNSS interference [1]; ADS-B-derived maps such as GPSJam show the geographic spread [2].

Variants

• Aviation/ANSP: ground monitoring plus ADS-B integrity analytics for airspace-wide awareness.
• Spectrum regulator: fixed and mobile monitoring networks, direction finding, emitter localisation and enforcement files.
• Timing-critical infrastructure: telcos, grids, data centres monitoring antenna-side GNSS timing receivers and triggering holdover.
• Maritime/logistics: fleet receiver telemetry; behaviour analysis of AIS is ANOM-032.
• Smartphone/crowd-sourced: Android raw GNSS measurements as distributed sensors.
• Defence: electronic-warfare awareness; only architecture level here.

How it works

1. sensors (spectrum receivers | GNSS receivers | ADS-B/AIS feeds | phones)
2. feature extraction (spectrogram, C/N0 & AGC statistics, cross-satellite correlation, NIC/NACp)
3. detectors (unsupervised baseline anomaly | supervised interference classifier | spoofing classifier)
4. multi-sensor fusion (time-difference/power-based localisation, grid aggregation)
5. alert + map + evidence package
6. human review (spectrum engineer / ATC supervisor)
7. NOTAM, regulator action, fallback to PNT backup

• Interference classification: CNNs or gradient boosting on spectrograms/IQ separate CW, chirp (swept), pulsed and wideband noise jammers from clean signals. Published work treats this as image or time-series classification of time-frequency representations [4].
• Spoofing detection: features such as cross-correlation of C/N0 time series across satellites, Doppler/pseudorange consistency and clock jumps feed SVM or tree models; research demonstrates this on smartphone raw measurements without low-level receiver access [3]. Cryptographic navigation message authentication (Galileo OSNMA) gives a non-ML ground truth for labelling and cross-checking [5].
• Crowd-sourced integrity: aircraft broadcast position quality; aggregating degraded values per hex cell and time window yields maps without own sensors [2].
• Human-in-the-loop: classification and localisation are decision support; NOTAM issuance, enforcement and operational changes stay with qualified staff.

Data preparation

Data comes from several worlds: spectrum monitoring receivers (IQ files, spectrograms), GNSS receiver logs and timing equipment (often only local logs or SNMP/NMEA streams), ADS-B/AIS feeds from public aggregators, and operator or pilot reports kept in e-mail, ticket systems or paper forms. Typical gaps: inconsistent time stamps and clock sync across sensors, missing calibration metadata (antenna, gain, location), very few labelled events, receiver telemetry that is overwritten after days, and unclear access rights for sensitive sensor positions.

Preparation steps: - Inventory every GNSS-dependent system and its telemetry (see [[PREP-001]], [[PREP-005]] for exports and connectors). - Centralise logs with synchronised UTC time stamps, a common schema and defined retention. - Record calibration and site metadata next to each recording ([[PREP-010]]). - Build labels from operator reports, Galileo OSNMA status and known events, with experts defining the classes first ([[PREP-019]], [[PREP-018]]). - Classify and restrict access to maps and sensor locations ([[PREP-024]]).

Tools: Kafka or MQTT, TimescaleDB, Grafana, H3 grids, simple Python scripts. Rough share of effort: about 30-40 percent of the project, mostly time sync, labelling and log retention. See also [[GUIDE-003]].

Implementation paths

Which path for whom

• Enterprise (ANSPs, telcos, grid operators): B, because calibrated sensors are bought but fusion with own receiver telemetry, ADS-B/AIS feeds and alert processes needs integration that no single product covers.
• Public (regulators, authorities): A, because enforcement evidence needs certified, calibrated monitoring and direction-finding equipment with vendor support and procurement-proof contracts.
• Developer: C, because GNU Radio, GNSS-SDR and open ML stacks on HW1 edge nodes allow research and prototypes with full control of the signal chain.

Path A — Buy

• Spectrum monitoring and interference geolocation: Rohde & Schwarz (DE; ARGUS, R&S MNT, Spectrum Monitoring portfolio), CRFS (UK), Thales, Comsec-class regulator systems, Keysight.
• GNSS resilience/monitoring: Septentrio (BE; AIM+ interference and spoofing monitoring), u-blox (CH; onboard jamming/spoofing indicators), Safran/Orolia (FR), Spirent testing, Hexagon/NovAtel.
• Aviation analytics: OpenSky Network (CH), Flightradar24 and EUROCONTROL tools for ADS-B-based interference analysis.
• Choose A when: you are a regulator, ANSP or operator needing certified, calibrated gear and support; AI is a feature of the product, not your own build.

Path B — Build on cloud APIs

• Ingest ADS-B/AIS feeds (OpenSky API, commercial aggregators), run aggregation and anomaly detection on EU-region cloud (time-series DB, stream processing, managed ML).
• LLMs add value only around the edges: drafting incident reports and summarising reports; they do not process RF. Keep raw sensor data out of general LLM APIs if it reveals sensitive infrastructure.

Path C — Self-host (open source)

• SDR front ends: USRP, HackRF, RTL-SDR for experiments; calibrated receivers for regulator use.
• Software: GNU Radio, GNSS-SDR, PyTorch/torchsig-style signal classification, scikit-learn/ XGBoost, Kafka plus TimescaleDB/Grafana, H3 grids for maps.
• Hardware: HW1 edge nodes (Jetson/CPU) per sensor for inference; a small central server for fusion. Training on a workstation GPU (HW2).
• Effort: needs RF engineers; labelled field data is the bottleneck.

Path D — Custom training

Often justified: interference signatures depend on local sensors and noise floors. Needs recordings of known jammers (from controlled, licensed test campaigns), clean baselines and simulator-generated spoofing (e.g. Spirent/GNSS-SDR-based), plus domain adaptation across receivers. Synthetic-to-real transfer is the key risk. Testing with transmitters requires regulatory permission.

State of the art (2026)

• Classification of common jammer types on spectrograms is mature in the lab; open-set detection of unknown emitters and robustness across receivers are still active research [4].
• Spoofing detection moves towards authentication (Galileo OSNMA, plus planned GPS and other augmentations) combined with statistical anomaly checks; ML supports fusion, not replaces authentication [3][5].
• Crowd-sourced mapping from ADS-B is widely used operationally and journalistically, but reveals interference at flight altitude and is biased by traffic density [2].
• Regulatory: EASA revisions add phraseology, EFB integration and training requirements, reflecting operations rather than detection alone [1].
• Limits: false alarms from legitimate interference (radar, faulty equipment, unintentional emitters); meaconing and sophisticated coherent spoofing mimic genuine signals; adversaries adapt; published accuracies of 99% rely on benchmark data; localisation accuracy depends on sensor geometry.

Shared resources & combinations

• Time-series and anomaly stack shared with ANOM-005 (industrial sensors), ANOM-030 (KPI anomalies) and ANOM-008 (grid anomalies).
• ANOM-032: AIS-spoofing behaviour analysis complements RF-level evidence for vessels.
• SEC-006: packet-level detection; combine with RF alerts for timing-infrastructure incidents.
• VIS-044: counter-UAS sensing fuses RF detection with cameras and radar.
• ROBO-006: drones need GNSS-denied fallback behaviour informed by these alerts.

Effort, cost & KPIs

• Path A: months to procure and calibrate; sensor hardware and licences dominate cost.
• Path B: 2-4 months for an ADS-B/AIS analytics pipeline.
• Path C/D: 6-12+ months, RF expertise, field campaigns and long-term sensor operation.
• KPIs: detection latency, precision/recall per interference class against labelled events, false alarm rate per sensor per day, localisation error (km), share of events with usable evidence, time from alert to NOTAM/advisory, timing-holdover events avoided.

People & change

Involve management early for budget and responsibility for alerts, and the department lead (operations, spectrum management or ATC supervision) as process owner. IT and IT security integrate sensors and protect sensitive interference maps; data owners release receiver logs and feeds. Legal/compliance clarifies spectrum law, evidence standards, NIS2 duties and AI Act role. Define with end users (engineers, supervisors) who acts on an alert before tuning models.

Works council: depends. The system mostly analyses signals, not staff. Co-determination under §87(1) no. 6 BetrVG arises if operator logs, shift data or user activity of the alert tool are recorded and could monitor performance; §90(1) no. 3 requires timely information when work processes are planned with AI. In public bodies the staff council (Personalrat) applies. Data protection: the DPO checks tail numbers, vessel owners and smartphone crowd data; a DPIA is likely for crowd-sourced location data, and an AVV is needed for cloud providers.

AI literacy: support staff with short training on false alarms, limits of published accuracy and when to escalate (Art. 4 AI Act). Start with a pilot at one site or region, run alerts in shadow mode, and keep humans in control: NOTAMs, enforcement and fallbacks stay with qualified staff. Typical concern: alert fatigue; address it with false-alarm KPIs and feedback loops.

Guides: [[GUIDE-009]], [[GUIDE-013]], [[GUIDE-004]].

Risks, regulation & compliance

• EU AI Act: typically not prohibited. Systems used as safety components in the management and operation of critical digital infrastructure or air traffic may be high-risk under Annex III(2) or Annex I sectoral law; a pure monitoring/analytics tool is often minimal. Classification depends on role: assess per deployment. No Art. 5 practice involved unless data is used to profile individuals.
• GDPR: ADS-B/AIS are broadcast and mostly non-personal, but tail numbers or vessels can be linked to natural persons (owners, pilots); smartphone crowd data is personal data (location, device IDs) needing consent or legitimate-interest assessment, minimisation and aggregation.
• Spectrum law: ITU Radio Regulations and national law (TKG in Germany) prohibit harmful interference; evidence handling must satisfy enforcement standards. Monitoring stations need appropriate authorisation; never test jammers outside licensed ranges.
• Sector rules: NIS2 for critical sectors; ICAO and EASA guidance for aviation.
• Sensitivity: interference maps can reveal military activity or sensor positions; apply access control. This entry covers detection and policy only, not methods of generating interference.
• Mitigations: human review of alerts, multi-sensor corroboration, non-GNSS fallbacks (inertial, DME/VOR, eLoran-class timing, atomic holdover), model monitoring.

Getting started

1. Inventory GNSS dependencies (aviation, timing, fleet) and existing receiver alarms.
2. Pull ADS-B-based interference data (OpenSky, GPSJam) for your region to establish a baseline.
3. Log receiver telemetry (C/N0, AGC, satellite count) centrally and build an unsupervised baseline.
4. Add one spectrum sensor or buy a monitoring service; label events with operator reports.
5. Define the alert-to-action process (who issues NOTAM, who notifies the regulator) before tuning ML.

Sources

1. EASA news — SIB on GNSS interference (SIB 2022-02, Rev. 4) — https://www.easa.europa.eu/en/newsroom-and-events/news/easa-updates-safety-information-bulletin-gnss-interference
2. GPSJam, ADS-B-derived GPS interference map — https://gpsjam.org
3. Rustamov, Minetto, Dovis — spoofing detection on smartphone raw GNSS measurements — https://iris.polito.it/retrieve/handle/11583/2977330/669243
4. arXiv 2501.02352 — GNSS/GPS spoofing and jamming identification using ML and DL — https://arxiv.org/abs/2501.02352v1
5. Galileo OSNMA (European GNSS Service Centre) — https://www.gsc-europa.eu/galileo/services/galileo-open-service-navigation-message-authentication-osnma
6. Inside GNSS — Leveraging advanced ML to detect and mitigate spoofing and jamming — https://insidegnss.com/leveraging-advanced-ml-to-detect-and-mitigate-spoofing-and-jamming/
7. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj