arXiv:2609.18499v1 [cs.NI] 16 Sep 2026
Jamming Detection in 5G/6G Networks: From O-RAN Concept to OCUDU Deployment Marcin Hoffmann
Lukasz Kulacz
Osama Baldo
Rimedo Labs Poznan University of Technology Poznan, Poland
Rimedo Labs Poznan University of Technology Poznan, Poland
Keysight Technologies Santa Rosa, California, United States
Marcin Pakula
Balaji Raghothaman
Rimedo Labs Poznan University of Technology Poznan, Poland
Keysight Technologies Santa Rosa, California, United States
Abstract—RF jamming poses a severe threat to 5G/6G networks, increasing packet latency being especially disruption to mission-critical URLLC services. This paper introduces a proactive Jamming Detection xApp (JD-xApp) for the Open RAN architecture that detects attacks by monitoring the movingaverage Block Error Rate (BLER) via the E2 interface. Upon detection, the algorithm overrides standard link adaptation, enforcing a robust upper ceiling on the Modulation and Coding Scheme (MCS) to stabilize latency. To counter O-RAN platform adoption challenges, we transition the framework to an open-source Centralized Unit/Distributed Unit implementation (OCUDU). Evaluated with high-end Keysight lab equipment including the UXM 5G Wireless Test Platform and the PROPSIM F64 channel emulator, the JD-xApp reduces the expected number of packet retransmission attempts by about 67.3%. Finally, the system’s feasibility is validated via over-the-air deployment using the POWDER lab infrastructure.
I. I NTRODUCTION The 5G/6G networks offer high security and trustworthiness at the level of protocols and authentication. However, due to the open nature of the wireless channel, they are still prone to relatively straightforward attacks on the Radio Access Network (RAN), such as Radio Frequency (RF) jamming [1], [2]. In essence, access to the radio channel is restricted by formal regulations, agreements, and protocols, yet this does not prevent their intentional abuse. Moreover, jamming harmful to 5G/6G networks can be realized using cheap off-the-shelf components and does not require sophisticated algorithms to significantly reduce users’ Quality of Service (QoS). For example, a keyed jammer changing its state (on/off) faster than Channel State Information (CSI) reports can disrupt scheduler Modulation and Coding Schemes (MCS) allocation, increasing packet latency [3]. This can have significant negative consequences for both military and civilian missioncritical Ultra-Reliable Low-Latency Communication (URLLC) services. The key issue with a jamming attack is that it can only be truly overcome by eliminating the interference source, which requires its localization and action taken by the proper public services. Although this usually requires a significant
amount of time, some temporal actions can be taken to reduce its negative impact on the 5G/6G network, e.g., the carrier frequency can be adjusted so as to avoid the jammed band [4]. While this idea seems reasonable for a single cell, in practice it might be very challenging to coordinate relocation of carrier frequencies within a broader area of the mobile network, and potentially between multiple operators. As an alternative approach, which does not require reorganization of spectrum allocation in 5G/6G networks, the effects of jamming, such as latency, can be reduced by taking control over the scheduler and setting fixed MCS [3]. This enables overcoming scheduler instability when the keyed jamming rate exceeds CSI reporting intervals. However, typically RAN is provided by a single vendor and does not expose both low-layer Key Performance Metrics (KPMs) and the capability of interaction with the scheduler. This issue is addressed by the concept of Open RAN, which standardizes open interfaces that, together with the RAN Intelligent Controller (RIC), allow the deployment of thirdparty algorithms in the form of xApps (for near-real-time optimization) and rApps (for non-real-time optimization) [5]. In particular, the E2 interface between the Near Real-Time RIC (Near-RT RIC), which comes with a Lower Layer Control Service Model (E2SM-LLC), supports interaction with the scheduler [6]. Unfortunately, the practical adoption of NearRT RIC and xApps is limited to mostly open-source platforms, implementing only a small portion of the O-RAN ALLIANCE specifications [7]. Moreover, despite referring to the O-RAN ALLIANCE specifications, they usually come with different API and SDKs, which introduces additional software development overhead and limits true interoperability [5]. From this perspective, the Open RAN concept can evolve in a way that, to deploy a third-party algorithm, the gNB should expose any kind of proprietary API enabling the exposure of KPMs’ and control capabilities. Recently, the leading candidate for such a deployment is the OCUDU, which is part of the Linux Foundation and is an open-source implementation of the O-
RAN Centralized Unit and Distributed Unit originating from srsRAN [8]. In this paper, in Sec. II, we introduce the Jamming Detection xApp (JD-xApp), which detects the attack through monitoring of Block Error Rate (BLER) and mitigates its negative effects on latency through modification of the MCS allocated to the user. The provided insights go beyond the brief description in [3]. Then, in Sec. III, we discuss how the initial O-RAN JD-xApp can be deployed on the OCUDU. In Sec. IV, the proposed JD-xApp is evaluated using high-end lab equipment provided by Keysight, including the UXM 5G Wireless Test Platform and the PROPSIM F64 channel emulator. Finally, recent tests of JD-xApp deployment on OCUDU are presented in Sec. III. These are done over-the-air using the infrastructure of a POWDER lab [9]. II. JAMMING D ETECTION X A PP - C ORE A PPROACH The proposed JD-xApp provides a proactive, closed-loop framework for maintaining low-latency communication in 5G networks under intentional RF interference. Operating as an xApp on the O-RAN Near-RT RIC, the algorithm continuously monitors downlink transport block reception statistics (ACK/NACK signals) collected over the E2 interface using E2SM-LLC [6]. By calculating the moving-average BLER over a sliding observation window, the JD-xApp is able to detect both continuous and pulsed jamming attacks. Once a jamming event is detected, the mitigation mechanism instantly overrides standard link adaptation by issuing real-time control policies to the gNB MAC scheduler. Using E2SM-LLC, it enforces a strict upper ceiling on the Modulation and Coding Scheme (MCS), forcing transmission down to an ultra-robust profile. Although this administrative capping reduces overall spectral efficiency and throughput, it drastically lowers transport block decoding errors under elevated noise floors. By reducing heavy retransmission delays and buffer stalls, the algorithm stabilizes round-trip latency and prevents link failures for delay-sensitive traffic. The core end-to-end detection and mitigation workflow of JD-xApp is shown in Fig. 1. A. Measurement Telemetry Aggregation The UE transmits Hybrid Automatic Repeat Request (HARQ) feedback (ACK/NACK) over the Physical Uplink Control Channel (PUCCH) or Physical Uplink Shared Channel (PUSCH) in response to downlink Transport Blocks (TBs). The E2 Node (O-DU) aggregates these transport block reception outcomes and, via the E2 Application Protocol (E2AP) using the E2SM-LLC, streams periodic or event-triggered indication messages containing per-UE ACK/NACK statistics to the Near-RT RIC. B. Detection Algorithm Execution (Near-RT RIC) The JD-xApp processes incoming transport block statuses (ACK/NACK), marked as TBi , within a sliding observation window of N consecutive transmissions. The moving average BLER for a given UE is computed as:
Fig. 1. Jamming detection and mitigation: core approach. N
BLERavg =
1 X I(TBi = NACK), N i=1
(1)
where β is a calibrated detection threshold. If BLERavg > β, the JD-xApp flags a jamming attack. C. Mitigation Directive Enforcement Upon jamming detection, standard gNB link adaptation is suspended for a specific period of time, since rapid channel degradation from jammer bursts typically causes conventional adaptive modulation to fail due to delayed Channel State Information (CSI) reports. The JD-xApp issues an E2 Control message via the E2SM-LLC, imposing an absolute upper ceiling on the modulation scheme (MCS ≤ MCSsafe , e.g., MCS = 2, corresponding to robust BPSK/QPSK with heavy coding) directly onto the E2 Node’s MAC scheduler. This forced ultra-robust modulation allows transport blocks to withstand elevated noise floors and interference bursts, eliminating excessive HARQ retransmission delays for latency-critical URLLC traffic. III. O-RAN C ONCEPT TO OCUDU D EPLOYMENT While O-RAN E2SM-LLC is a good fit for deployment of JD-xApp in the sense of providing a unified mechanism to obtain the input KPMs and MCS control capability, the key issue is its poor adoption by existing RIC platforms; e.g., see available E2SMs in [7], [5]. Moreover, the E2SM-LLC utilizes ASN1-encoded messages, which introduces additional development overhead. In contrast, the OCUDU provides an open-source implementation of a 5G gNB base station [8]. It does not require complicated ASN1 syntax and exposes metrics and control capabilities directly through WebSocket using a standard JSON format. The data can be reported at 500 ms intervals, including various operational levels, and goes beyond O-RAN specifications. For example, the Radio Link
Control layer provides per-UE Data Radio Bearer metrics, such as maximum PUD latency. At the MAC layer, the telemetry captures scheduler performance, such as allocation error counters or real-time bitrates. At the Distributed Unit layer, the OCUDU evaluates allocated MCS, BLER, and Signal-to-interference-plus-Noise Ratio (SINR). The metrics also consist of the Centralized Unit Control Plane, with active PDU sessions, and the status of N2/NGAP interface. Finally, the Centralized Unit User Plane consists of PDCP layer metrics for Dowlink or Uplink traffic, and tracking average throughput. Moreover, using the OCUDU API, it is possible to enforce MCS for a certain UE. From this perspective, OCUDU provides all necessary metrics to deploy JD-xApp. The key observation is that the input and output data, along with the core approach, are literally the same. The major change is in the interface for communication with RAN. The comparison between O-RAN E2SM-LLCbased and OCUDU approaches is presented in Tab. I.
a jamming attack is modeled by the PROPSIM F64 channel emulator by introducing AWGN to the radio link, which causes packet retransmissions indicated by a growing BLER. To achieve sufficient deterioration of propagation conditions caused by jamming, the AWGN is increased iteratively and, after reaching a certain BLER level, MCS adaptation in the scheduler is verified, and logs are dumped to files for further processing.
TABLE I C OMPARISON BETWEEN O-RAN AND OCUDU DEPLOYMENT OF JD- X A PP.
Interface Format KPM: ACK/NACK Control: MCS Market Adoption
O-RAN (Near-RT RIC)
OCUDU
E2SM-LLC ASN1 Yes Yes Poor
Proprietary API JSON Yes Yes Growing
IV. T ESTS OF JD- X A PP C ORE A LGORITHM As the JD-xApp core approach is agnostic of the platform used for its deployment, the key requirement is to validate it using reliable tools. To achieve that, we used high-end lab equipment provided by Keysight Technologies: • E7515B UXM 5G Wireless Test Platform, enabling emulation of the 5G New Radio protocol stack. We use it to set up the communication between the cell and UE being subject to a jamming attack. • F8800A PROPSIM F64 Radio Channel Emulator, enabling realistic and repeatable radio link emulation with dynamic introduction of Additive White Gaussian Noise (AWGN). We used it for modeling radio channel characteristics between the UE and the cell, with AWGN being used to mimic a jamming attack. A. BLER-Based Link Adaptation Test To generate data for evaluation of JD-xApp using the Keysight UXM 5G Wireless Test Platform, we followed the BLER-Based Link Adaptation Test, which is summarized in Fig. 2. After starting the test a link-adaptation policy is selected. It can be either default MCS selection based on CSI, which reflects the standard operation of the gNB, or a fixed MCS, corresponding to the JD-xApp mitigation mechanism. Then, the 5G cell emulated by UXM is started and configured with the initial MCS according to the policy. During the test,
Fig. 2. Log processing and metric extraction.
B. Log Processing and Metric Extraction To validate the detection and mitigation logic under realistic radio conditions, the system was evaluated using log traces generated from a Keysight UXM 5G Wireless Test Platform. These logs are extensive, capturing a wide range of link-layer behaviors and statistics beyond the parameters required for jamming detection, and are streamed as sequential text records rather than structured data. A dedicated parsing routine, shown of Fig. 3, processes these records in batches extracting two categories of metrics relevant to the proposed algorithm: • HARQ Feedback: Each log entry containing a HARQ Feedback field is scanned to determine whether the reported outcome is a positive acknowledgment (ACK) or a negative acknowledgment (NACK). The routine maintains running counters for total feedback events and successful acknowledgments, while appending a binary indicator (0 for ACK, 1 for NACK) to a time-ordered sequence. This sequence directly corresponds to the indicator function I(TBi = NACK) used in the BLERavg equation (1). • MCS Index: Each log entry containing an MCS index field is parsed to extract the corresponding integer value. The routine accumulates a running total and occurrence count to support average MCS computation, and additionally appends each observed value to a time-ordered sequence for downstream analysis of link adaptation behavior over the course of the experiment. By aggregating these metrics incrementally across batches rather than loading the full log into memory at once, the parser
NACK/ACK Rate
MCS trace, which shows the xApp repeatedly and rapidly forcing the MCS index down to its safe floor (MCSsafe ≈ 2) at the onset of each detected error burst, before allowing it to recover towards nominal values once the assumed time. Fig. 8 shows the corresponding binary jamming-detection flag produced by the JD-xApp, which toggles to 1 in nearperfect correspondence with the MCS-capping events in Fig. 7, confirming that the mitigation actions are correctly triggered by the detection logic. Overall, these results indicate that while the reference (uncontrolled) system suffers from a prolonged period of severe link degradation under jamming, the proposed closedloop mechanism trades a temporary, self-limiting reduction in MCS for a substantial reduction in sustained block error rate, consistent with the design goal of prioritizing link robustness over peak throughput during interference events.
C. Experimental Results The proposed algorithm was evaluated against a pulsed jamming scenario generated with a Keysight UXM 5G Wireless Test Platform attached to the PROPSIM F64, in which the interference source was active from approximately t = 175 s to t = 405 s. To isolate the contribution of the JD-xApp, two configurations were logged from the same experimental scenario: a reference run with the mitigation algorithm disabled (standard gNB link adaptation only), and an active run with the JD-xApp enabled. Fig. 4 and Fig. 6 show the NACK/ACK rate and MCS index for the reference run. During the jamming interval, the NACK/ACK rate rises sharply and remains persistently elevated, reaching values close to 1.0 for extended periods. Critically, the standard MCS controller reacts only sluggishly to this degradation: the MCS index remains pinned near its maximum value (MCS ≈ 27) for most of the jamming duration and only begins a gradual decline towards the end of the interference window Fig. 6. Fig. 5 and Fig. 7 show the same metrics with the JD-xApp active. The NACK/ACK rate exhibits a markedly different pattern: rather than remaining persistently high, it appears as a series of short, sharp spikes, each promptly pulled back down towards zero. This behavior is explained by the corresponding
NACK/ACK Rate
accommodates the scale of the Keysight-generated traces while preserving the temporal ordering necessary to reconstruct the sliding-window BLER calculation offline, mirroring the online behavior of the JD-xApp described in Sec. II.
0.5 0.0
0
100
200 Time (s)
300
400
Fig. 4. NACK/ACK rate over time with the mitigation algorithm disabled (reference run). The rate remains persistently elevated throughout the jamming interval (≈ 175–405 s).
1.0 0.5 0.0
0
100
200 Time (s)
300
400
Fig. 5. NACK/ACK rate over time with the JD-xApp enabled. Error bursts are quickly suppressed, appearing as short spikes rather than sustained degradation.
MCS Index
Fig. 3. Log processing and metric extraction.
1.0
20 10 0
100
200 Time (s)
300
400
Fig. 6. MCS index over time with the mitigation algorithm disabled (reference run). Standard link adaptation fails to react promptly to the onset of jamming.
D. Impact on Retransmission Overhead and Latency To quantify the latency benefit of the proposed mitigation mechanism, the number of transmission attempts required per downlink transport block was extracted from the same paired experiment (mitigation disabled vs. enabled), over
MCS Index
with mitigation enabled — a reduction of roughly 218,800 retransmissions, or 86.3% fewer HARQ retries overall. Since each avoided retransmission removes one full Textra round-trip from the corresponding block’s delivery time, this reduction directly translates into lower and more predictable round-trip latency, which is consistent with the goal of preserving delaysensitive (URLLC) traffic performance under active jamming.
20 10 0
100
200 Time (s)
300
400
Jamming Detection
Fig. 7. MCS index over time with the JD-xApp enabled. The controller repeatedly forces the MCS down to MCSsafe upon jamming detection and releases it once conditions improve.
1.0 0.5 0.0
0
100
200 Time (s)
300
400
Fig. 8. Binary jamming-detection flag output by the JD-xApp, correlating with the MCS-capping events.
N = 415,972 logged transport blocks in each run. Under HARQ operation, a transport block that is acknowledged on the first attempt incurs a nominal transmission time T , while each additional retransmission attempt incurs a further delay Textra due to HARQ round-trip and scheduling overhead. The expected per-block latency is therefore E[Latency] = T + E[attempts] − 1 Textra
(2)
Table II summarizes the observed attempt-count distribution for both configurations and the resulting expected latency overhead, expressed in multiples of Textra . TABLE II T RANSMISSION ATTEMPT DISTRIBUTION AND RESULTING LATENCY OVERHEAD , WITH AND WITHOUT THE JAMMING MITIGATION ALGORITHM . Metric P (1st attempt) P (2nd attempt) P (3rd attempt) P (4th attempt) E[attempts] E[extra delay]
Reference (no alg.)
With JD-xApp
62.16% 20.38% 11.79% 5.67% 1.610 0.610
94.01% 4.23% 1.15% 0.61% 1.084 0.084
Without mitigation, 37.84% of transport blocks required at least one retransmission, and the expected number of attempts per block reached 1.61, meaning that on average each block incurred 0.61 Textra of additional delay beyond the nominal transmission time T . With the JD-xApp active, the probability of requiring any retransmission dropped to 5.99%, and the expected number of attempts fell to 1.084, corresponding to only 0.084 Textra of expected additional delay — an 86.3% reduction in expected retransmission-induced latency per transport block. Aggregated over the full experiment, this corresponds to approximately 253,600 retransmission attempts in the reference run versus approximately 34,800 retransmission attempts
V. OVER THE A IR T ESTS ON OCUDU After the verification of the JD-xApp core approach using high-end Keysight UXM 5G Wireless Test Platform, we move toward its deployment on the OCUDU. Currently, we have integrated the JD-xApp mitigation part into OCUDU and use the infrastructure of the POWDER lab (see [9]) to perform over-the-air tests. The topology for the evaluation scenario consists of the following elements: • CN5G: Hosts the Open5GS 5G Core Network. • OCUDU: Serves as a combined Central Unit and Distributed Unit (CU/DU) • Sdru-SDR (USRP X310): Acts as a Software-Defined Radio (SDR) connected to the CU/DU. • UE1, UE2: Commercial User Equipments. • Uemon-SDR: Provides monitoring and management capabilities across the radio-link setup. • JD-xApp: Communicates with OCUDU using WebSocket and performs jamming detection based on the captured KPMs. At the radio layer, OCUDU was configured to operate in 3GPP NR Band n78 with a channel bandwidth of 20 MHz and a subcarrier spacing of 30 kHz. The carrier frequency was defined as 3489.42 MHz. The USRP X310 SDR was set as a Radio Unit (RU). The RF gains were set at 30 dB for transmission and 20 dB for reception, operating at a baseband sampling rate of 92.16 MHz. A programmable attenuation matrix was used to control the Radio Frequency (RF) conditions between the network components and UEs. The prepared experimental environment therefore provided a platform for testing the developed algorithm in a 5G network. The jamming was introduced by rapidly switching the attenuation of the selected RF path between an attenuation level of 95 dB and the normal operating level. After the initial verification, the switching period was set to 10 ms. This is synchronized with a 5G frame duration and CSI reports, meaning that after the OCUDU scheduler receives information about the radio channel, its state rapidly changes, causing BLERs due to MCS selection mismatch. This is clearly visible in Fig. 9, which shows the UL NACK/ACK ratio during the experiment. During the jamming attack the increases from close to 0% to about 20%, indicating that the default MCS allocation scheme fails to keep up with the rapidly degraded radio link. It corresponds to an increased number of unsuccessful transmissions, which requires retransmissions and introduces latency. Note that, for some sensitive URLLC services, even a small additional delay can be harmful. The related MCS index over time is presented in Fig. 10. When jamming is enabled, the MCS decreases and fluctuates
Fig. 9. NACK/ACK rate over time. The rate remains persistently elevated throughout the jamming interval
around 22 − 23 values, reflecting the rapidly changing and degraded channel conditions. However, it is not enough to reduce BLER to a satisfactory level. This would require extending the OCUDU deployment of JD-xApp with a mitigation part, being responsible for adjusting the MCS during the attack.
compared to only 62.16% under default MCS allocation. Finally, the JD-xApp designed for O-RAN can be deployed on OCUDU, as we demonstrated through over-the-air tests in the POWDER lab. The OCUDU deployment will be subject to further development effort aiming to be extended with a mitigation part and extensive evaluation in terms of a broader set of KPMs. ACKNOWLEDGMENT The authors would like to thank Keysight Technologies for support in collecting evaluation data with their lab equipment: a UXM 5G Wireless Test Platform and PROPSIM F64 channel emulator; and the POWDER lab managed by the University of Utah for sharing their infrastructure for OCUDUbased deployment. The work was supported by Polish Ministry of Science and Higher Education under grant number: 0312/SBAD/8169, and 0312/SBAD/8170. R EFERENCES
Fig. 10. MCS index over time with jamming enabled.
Finally, Fig. 11 shows the jamming-detection flag generated by the JD-xApp. The detected intervals correspond closely to the periods of MCS degradation, indicating that the proposed detection mechanism is capable of reliably identifying the introduced jamming conditions.
Fig. 11. Jamming-detection flag output by the JD-xApp.
VI. C ONCLUSION The keyed jamming of a rate higher than the CSI report intervals can result in an MCS allocation mismatch at the level of the MAC scheduler, resulting in high BLER and latency. This can be mitigated by the proposed JD-xApp, which enforces fixed MCS allocation during the jamming attack to reduce packet retransmissions. Evaluation of the JD-xApp core approach with the high-end Keysight UXM 5G Wireless Test Platform showed that, under jamming, it enables transmitting about 94% of packets in the first attempt
[1] H. Pirayesh and H. Zeng, “Jamming attacks and anti-jamming strategies in wireless networks: A comprehensive survey,” IEEE Communications Surveys & Tutorials, vol. 24, no. 2, pp. 767–809, 2022. [2] P. Kryszkiewicz and M. Hoffmann, “Open ran for detection of a jamming attack in a 5g network,” in 2023 IEEE 97th Vehicular Technology Conference (VTC2023-Spring), 2023, pp. 1–2. [3] Bogucka, Hanna and Hoffmann, Marcin and Kryszkiewicz, Paweł and Kułacz, Łukasz, “An open-ran testbed for detecting and mitigating radioaccess anomalies,” IEEE Communications Magazine, vol. 63, no. 11, pp. 122–127, 2025. [4] L. Jia, N. Qi, F. Chu, S. Fang, X. Wang, S. Ma, and S. Feng, “Gametheoretic learning anti-jamming approaches in wireless networks,” IEEE Communications Magazine, vol. 60, no. 5, pp. 60–66, 2022. [5] M. Hoffmann, S. Janji, A. Samorzewski, L. Kulacz, C. Adamczyk, M. Dryjanski, P. Kryszkiewicz, A. Kliks, and H. Bogucka, “Open ran xapps design and evaluation: Lessons learnt and identified challenges,” IEEE Journal on Selected Areas in Communications, vol. 42, no. 2, pp. 473–486, 2024. [6] O-RAN Alliance, “O-RAN E2 Service Model (E2SM), Lower Layers Control (LLC),” O-RAN Alliance, Technical Specification O-RAN.WG3.E2SM-LLC-v01.00, Feb. 2025. [Online]. Available: https://www.o-ran.org/specifications [7] P. Rodgers and P. Harvey, “The xapp store: A framework for xapp onboarding and deployment in o-ran,” in 2025 IEEE 45th International Conference on Distributed Computing Systems Workshops (ICDCSW). IEEE, 2025, pp. 647–652. [8] OCUDU Project Contributors, “OCUDU: A Permissively-Licensed, Open-Source 5G CU/DU Project,” https://gitlab.com/ocudu/ocudu, 2026, accessed: 2026-08-13. [9] J. Breen, A. Buffmire, J. Duerig, K. Dutt, E. Eide, A. Ghosh, M. Hibler, D. Johnson, S. K. Kasera, E. Lewis, D. Maas, C. Martin, A. Orange, N. Patwari, D. Reading, R. Ricci, D. Schurig, L. B. Stoller, A. Todd, J. Van der Merwe, N. Viswanathan, K. Webb, and G. Wong, “Powder: Platform for open wireless data-driven experimental research,” Computer Networks, vol. 197, p. 108281, 2021. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S1389128621003017