Resilient Control Loops in Autonomous Vehicles Under Adversarial Jamming via Spectral Perception and Network-Layer Failover

I. INTRODUCTION

• Wireless interference can degrade feedback timing, but prior work often emphasizes link-layer metrics rather than physical interference’s effects on ROS 2 and physical robots.The paper frames this as a gap in empirical evaluation.Source: §I · p. 1
• Environmental variability makes fixed thresholds prone to false alarms or missed detections, motivating systems that distinguish ordinary noise from intentional attacks.The paper calls for context-aware reasoning and recovery as jamming techniques evolve toward protocol-specific targeting.Source: §I · p. 1
• The framework combines real-time SDR sensing with adaptive machine-learning detection and multi-modal communication switching, evaluated on ROS 2-based UxVs.The testbed uses HackRF and USRP B210 radios.Source: §I · p. 1
• 141 ms recovery latency and 78.9% lower pooled RMS path error were achieved with hardware-assisted band switching versus standard software-based methods.These are the reported communication-recovery and path-tracking results.Source: §I · p. 2

II. BACKGROUND AND RELATED WORKS

• Reported UAV losses and protocol-aware SDR jammers illustrate electronic-warfare threats to unmanned systems and mission-critical remote-control links.The cited work reports protocol-aware jamming at lower jam-to-signal ratios than naive broadband jammers.Source: §II · p. 2

1) SDR-Based Experiments and Counter-UAV Systems:

• SDR studies survey detection and defense systems, characterize GPS interference, and propose RF-SDR detection with selective jamming.Source: 1) SDR-Based Experiments and… · p. 2

2) ML-Based Jamming Detection and Classification:

• Machine-learning approaches use spectral and signal features to classify jammer types, infer interference, and sense or identify signals.The cited work also includes reinforcement-learning surveys and detectors,.Source: 2) ML-Based Jamming Detection and… · p. 2

3) ROS 2 and DDS Middleware Resilience:

• Prior studies address ROS 2 latency [17], [18], DDS security [19], lossy-link behavior [20], wireless optimization [21], and DDS bottlenecks [22], but treat wireless effects abstractly rather than tracing IEMI into control.Source: 3) ROS 2 and DDS Middleware Resilience · p. 2

4) Adaptive Anti-Jamming and Multi-Modal Switching:

• Prior defenses include channel hopping, learned detectors, and reinforcement-learning or game-theoretic policies –; this work instead switches between pre-authenticated interfaces and measures physical path-tracking error.Reactive or persistent jammers that follow links across bands can defeat band switching,, and are not exercised by the continuous-wave evaluation.Source: 4) Adaptive Anti-Jamming and… · p. 2

III. METHODOLOGY AND APPROACH

• The methodology frames resilience as cross-layer synchronization between environment-aware interference detection and network-layer mitigation using physical-layer redundancy.Source: §III · p. 2

1) Context-Aware Interference Perception:

• Spectral entropy, channel occupancy, and PSD variance characterize the nominal RF environment, allowing adaptation to noise-floor shifts from mobility or obstacles.Significant deviations from the learned baseline identify IEMI and provide awareness for triggering recovery.Source: 1) Context-Aware Interference Perception · pp. 2–3
• Hot-standby authenticated pathways avoid the link-layer handshake bottleneck; the validated implementation uses dual-band Wi-Fi and is described as extendable to other radio protocols.The passage names cellular, satellite, and proprietary sub-GHz links as possible extensions.Source: 3) Network-Layer Mitigation and… · p. 3

3) Network-Layer Mitigation and Control Loop Stability:

• Routing-table and default-gateway updates redirect control and telemetry at the network layer, reducing recovery from multi-second re-association to the millisecond range.The passage links this design to ROS 2 control-loop sensitivity to jitter and packet loss.Source: 3) Network-Layer Mitigation and… · p. 3
• 141 ms recovery latency and 78.9% lower path-following RMS error were achieved with hardware-assisted switching versus standard software-based methods.Validation used a ROS 2 autonomous vehicle with two independent Wi-Fi interfaces on different frequency bands.Source: 4) Validation Case Study: Dual-Band… · p. 3

IV. EXPERIMENTAL SETUP

• The setup was organized to support reproducibility and closed-loop evaluation of the IEMI detection and recovery framework.Source: §IV · p. 3

A. Robot Platform and Software Stack

• The TurtleBot3 Burger used a Raspberry Pi 4 running Ubuntu Server 24.04, an OpenCR motor controller, ROS 2 Humble, and Cyclone DDS.ROS 2 handled command, telemetry, and state estimation.Source: A. Robot Platform and Software Stack · p. 3
• Figure 3 shows the mobile robot platform and Software Defined Radios as experimental setup components.Source: Figure 3 · p. 3

B. Software-Defined Radio (SDR) Platforms

• The HackRF One passively monitored the active Wi-Fi channel at 2.5 MS/s, while the USRP B210 generated programmable interference.The HackRF was a low-cost half-duplex receiver; the USRP supported calibrated gain, full duplex, and stable phase coherence.Source: B. Software-Defined Radio (SDR)… · p. 3

1) HackRF Configuration:

• A 512-point FFT produced PSD estimates over a 20 MHz window, from which five descriptors were computed for detection.The descriptors were mean, standard deviation, and maximum PSD, spectral entropy, and channel occupancy; after band switches, detection resumed after a five-sample cooldown.Source: 1) HackRF Configuration · p. 4

2) USRP B210 Configuration:

• The USRP transmitted 5-second CW interference events at 85 dB gain, using 2.447 GHz for 2.4 GHz trials and 5.2 GHz for 5 GHz trials.Source: 2) USRP B210 Configuration · p. 4

C. Wireless Network Topology

• The robot used one router exposing 2.4 GHz and 5 GHz BSSIDs; the advertised 6 GHz network was excluded because the Raspberry Pi 4 interface did not support it.Keeping the access point constant avoided router heterogeneity across trials.Source: C. Wireless Network Topology · p. 4

D. Switching Architectures

• The baseline used one Wi-Fi interface and a static-threshold detector, requiring 75 consecutive above-threshold samples before initiating reassociation.Its fixed thresholds were -30 dB for 2.4 GHz and -18 dB for 5 GHz; reassociation involved deauthentication, scanning, authentication, a WPA2 handshake, and restoration of ROS 2 communication.Source: 1) Static-Threshold Software Switching… · p. 4
• Adaptive ML-based software switching used five spectral descriptors and a Random Forest classifier, but retained the baseline's single-interface reassociation recovery path.It required three consecutive positive classifications, used thresholds of 75% for 2.4 GHz and 50% for 5 GHz, and applied a five-sample cooldown.Source: 2) Adaptive ML-Based Software Switching · p. 4
• Dual-interface hardware-assisted switching kept both Wi-Fi links authenticated and active, redirecting traffic by changing the Linux default route when jamming was detected.The TP-Link AC600 was associated with 2.4 GHz and the onboard interface with 5 GHz; both used static IP addresses on the same subnet.Source: 3) Adaptive Hardware-Assisted Switching · p. 4
• Figure 4 plots 2.4 GHz RMS power and jam-flag output over time.Source: Figure 4 · p. 5

• The experiments compared three switching architectures for real-time network recovery and closed-loop waypoint tracking under intentional RF interference.Source: §V · p. 5
• Detection used band-specific Random Forest probability thresholds of 75% for 2.4 GHz and 50% for 5 GHz, with three consecutive positive intervals required to declare IEMI.Nominal spectral profiles differed by band, and the section reports that static power thresholds were susceptible to false positives from environmental noise.Source: §V · p. 5
• A stationary USRP B210 jammer transmitted at 85 dB gain for 5 seconds while the TurtleBot3 completed two 60-second laps of a 1 m × 1 m square.The robot-to-transmitter distance varied from 2 m to 4 m; the jammer activated 8 seconds into the first leg of the first lap, and telemetry was logged locally.Source: §V · p. 5

A. Interference Detection Validation

• The initial validation used a controlled jamming envelope with a CW interference source, and Table I covers interference-target and sensing parameters.Source: A. Interference Detection Validation · p. 5, Table I · p. 5
• 0.6 s detection latency at 2.5 MS/s matched the analytical prediction based on 75 consecutive above-threshold readings.The validation describes this as deterministic latency and reports that empirical measurements matched the prediction.Source: A. Interference Detection Validation · p. 5
• At approximately 8 seconds, jammer activation produced a greater-than-20 dB step increase in RMS signal power.Fig. 4 tracks 2.4 GHz RMS power alongside the binary jam-flag output during a representative run.Source: A. Interference Detection Validation · p. 5

C. Closed-Loop Robotics Path Tracking Impact

• Recovery time was measured from threat declaration to successful end-to-end ICMP ping verification; tracking error was pooled across 15 runs against an unjammed control trajectory.Source: B. Channel Switching Latency Analysis · p. 5, C. Closed-Loop Robotics Path Tracking… · p. 5

B. Channel Switching Latency Analysis

• 141 ms average recovery with hardware-assisted switching compared with 2.549 s for machine-learning software detection and 6.001 s for static-threshold software switching.Dual active, pre-authenticated interfaces and network-layer routing-table updates bypass the link-layer handshake.Source: B. Channel Switching Latency Analysis · p. 5, Table II · p. 5

C. Closed-Loop Robotics Path Tracking Impact

• 0.60 cm pooled RMS path error was 78.9% below software switching’s 2.84 cm; hardware’s 0.88 cm worst-case deviation beat software’s 0.70 cm best case.Table III reports path-tracking errors and run deviations; Fig. 5 presents the kinematic trajectories under active IEMI.Source: Table III · p. 5, Figure 6 · p. 6, Figure 5 · p. 6
• During the 5-second jamming window and immediately afterward, software switching distorted the path, while hardware-assisted failover tracked the nominal baseline smoothly.The passage attributes prevention of cascading into system-level task failure to mitigating communication downtime at the network layer.Source: C. Closed-Loop Robotics Path Tracking… · p. 6, Figure 5 · p. 6

VI. CONCLUSION AND FUTURE WORK

• The framework paired SDR sensing and a Random Forest classifier with network-layer failover, achieving 141 ms average recovery and 78.9% lower pooled RMS path error than software re-association.Source: §VI · p. 6
• The evaluation was limited to a continuous-wave jammer on a single robotic platform, leaving more capable adversaries untested.Source: §VI · p. 6
• Future work proposes testing reactive, protocol-aware, and frequency-agile jammers and extending the detector and failover policy against them.Source: §VI · p. 6