Jamming Smarter, Not Harder: Exploiting O-RAN Y1 RAN Analytics for Efficient Interference

Abiodun Ganiyu; Dara Ron; Syed Rafiul Hussain; Vijay K Shah

REVIEW 4 major objections 4 minor 19 references

Jamming Smarter, Not Harder: Exploiting O-RAN Y1 RAN Analytics for Efficient Interference

T0 review · 4 major / 4 minor · reviewed 2026-08-05 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This paper tries to establish that a malicious but authenticated O-RAN Y1 consumer can passively read RAN analytics and use them to drive a selective jammer that disrupts downlink traffic almost as effectively as an always-on jammer while t

desk verdict First paper to treat a malicious Y1 consumer as a jamming vector, with a real OTA testbed; plausible but single-run evidence and a cluster-label inconsistency need fixing before it's fully credible. read the letter →

arxiv 2509.05161 v1 pith:2GTDQIKU submitted 2025-09-05 cs.CR

Abiodun Ganiyu , Dara Ron , Syed Rafiul Hussain , Vijay K Shah This is my paper · ORCID

classification cs.CR

keywords O-RANY1interfaceRANanalyticsjammingDBSCANtrafficprofiling5Gsecuritystealthy

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper tries to establish that a malicious but authenticated O-RAN Y1 consumer can passively read RAN analytics and use them to drive a selective jammer that disrupts downlink traffic almost as effectively as an always-on jammer while transmitting far less. On an over-the-air LTE/5G testbed, a threshold-based jammer matched always-on disruption with a 27% reduction in transmission time, and a clustering-based jammer caused up to 18.1% bitrate drop while active only 25% of the time. If correct, this shows that the Y1 analytics exposure, intended for third-party optimization, creates a new side channel for low-footprint interference, with direct relevance to military and mission-critical O-RAN deployments.

What carries the argument

The load-bearing mechanism is the Y1 RAI subscription-notification flow: a compromised consumer receives periodic JSON telemetry (CQI, MCS, bitrate, BLER, and other metrics) from a Y1 Producer that pulls analytics from the RIC database via the Shared Data Layer. The jammer's decision rule is either a threshold on bitrate or a nearest-centroid classifier built from DBSCAN clusters of normalized feature vectors; the clusters are semantically labeled (high/medium/low/idle traffic) and the jammer selects the high-traffic cluster for interference. This converts a passive analytics stream into a transmission schedule for the jammer.

What would settle it

Run the same jammer strategies in a multi-UE cell where aggregate cell bitrate is driven by many users and test whether the threshold or DBSCAN cluster labels still separate the target's active and idle states; alternatively, check whether any production O-RAN RIC actually exposes the Table II metrics over Y1, since the paper concedes they are not explicitly in the specification.

Watch

Extended reading notes

Core claim

The central claim is that aggregate, cell-level RAN analytics exposed over the Y1 interface reveal enough about downlink traffic state to make interference selective: an attacker subscribes to periodic notifications, forwards the metrics to a software-defined jammer, and the jammer activates only when the observed metrics signal active or high-value traffic. The paper demonstrates this with two strategies: a simple threshold on bitrate, and an offline DBSCAN clustering model that labels traffic classes and targets the highest-throughput cluster. Under an unlimited jamming budget, the threshold jammer achieves near-identical BLER and bitrate loss to always-on jamming at 73% activity; under co

Load-bearing premise

The attack depends on real Y1 deployments exposing metrics like cell-level bitrate and CQI; the paper's own implementation uses a custom Flask-based Y1 producer because current open-source RICs lack Y1 support, and the nine metrics it uses are not explicitly listed in the current Y1 specification, while the testbed's single UE makes aggregate bitrate a clean proxy for the jammer's target.

Editorial extensions

If this is right

A Y1 consumer with legitimate credentials no longer needs physical-layer sensing to know when to jam; passive analytics give the attack a ready-made schedule of active and idle windows.
Selective jamming lowers energy use and detection risk, making O-RAN analytics exposure a credible concern for covert and energy-constrained military operations.
The same telemetry channel could be used for other targeted attacks, such as inducing handover storms or starving specific services, not just physical jamming.
Because mutual TLS authentication alone does not constrain post-authentication behavior, defending against this attack requires behavioral monitoring and anomaly detection on Y1 consumers.
The attack generalizes beyond the specific metrics used: any sufficiently informative RAN telemetry can serve as a profiling side channel, as the paper argues explicitly.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

If Y1 analytics are exposed at per-UE or slice granularity rather than cell-level aggregation, the attack could be aimed at specific victims rather than an entire cell, which would make the threat sharper than the paper's single-UE testbed suggests.
The attack's real-world viability hinges on the latency between analytics generation, Y1 delivery, and jammer activation; a testable extension is to measure how much delay the profiling pipeline tolerates before the threshold or cluster decisions lose accuracy.
The DBSCAN profile is trained offline on a fixed traffic mix; an adaptive online clustering variant could track drifting traffic patterns and keep the jammer effective over longer missions, something the paper does not explore.
The side channel could be reversed defensively: a RIC operator who suspects Y1 misuse could inject decoy metrics into the analytics stream to bait the jammer into wasting its budget, turning the attack channel into a countermeasure.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Quick take: This is the first paper I've seen that treats a malicious Y1 consumer as a real attack vector, and it backs it up with an actual over-the-air testbed. The headline claim is plausible: a jammer guided by RAN analytics can match the disruption of always-on jamming while transmitting only during active traffic periods. Worth a serious referee, but the paper needs more runs, more transparency, and one cluster discrepancy needs fixing.

What's genuinely new: prior O-RAN security work is about xApp defenses or manipulating telemetry, not about using the Y1 exposure itself to steer external interference. The authors built a custom Y1 producer because no open-source RIC supports Y1 yet, which is a real gap. Their Part A result is clean: the threshold jammer is active 73% of the time versus 75.4% actual traffic activity, and gets within 5 points of the always-on bitrate drop. That directly validates the passive-learning-to-active-jamming chain. Part B's high-traffic cluster jammer beats random jamming at the same budget, which supports the selective-targeting argument.

The problems are mostly about evidence quality. Every table is a single run with no variance. For a wireless experiment that is not enough; channel draws change results. They also don't ship code or data. The Y1 realism gap is real: the metrics they use aren't in the current Y1 spec, and they concede that in VI-F. The attack concept is metric-agnostic, but the numbers are tied to their chosen metrics. The single-UE testbed means cell-level aggregates are a perfect proxy for target activity; in a multi-UE network that may not hold. Minor: the abstract says LTE/5G, but the testbed is srsRAN 4G.

There's also a consistency issue the authors should fix: Section VI-B says the Part B traffic has 4 Mbps, 2 Mbps, 500 Kbps and idle. Section VI-C then reports clusters labeled 4 Mbps, 500 Kbps, 100 Kbps, and idle. The 2 Mbps class is missing and a 100 Kbps class appears. That could be a typo, but it means the cluster-to-traffic mapping is not well validated, which weakens the clean attribution of the 18.1% drop to "high traffic" targeting.

Bottom line: This is a new and plausible threat demonstration, not a rigorous quantitative study. It deserves peer review with demands for repeated runs and better validation of the Y1 metric assumptions. If the authors fix those, it's a solid addition to the O-RAN security literature. You could cite it as the first Y1-consumer attack if you need that example, but I'd wait for the revised version.

Referee Report

4 major / 4 minor

Summary. The paper proposes and evaluates two Y1-interface-aided jamming strategies—a threshold-based jammer and a DBSCAN clustering-based jammer—against always-on and random jammers on an over-the-air LTE/5G O-RAN testbed. The threat model is an authenticated but malicious Y1 consumer that forwards RAN analytics to an external software-defined jammer. In Part A (fixed 4 Mbps traffic, unlimited jamming budget), the threshold jammer achieves a 40.5% bitrate drop while active only 73% of the time, compared to 45.4% and 100% for the always-on jammer. In Part B (multi-rate traffic, constrained budgets), the clustering-based jammer targeting the high-traffic cluster yields the largest bitrate drop, up to 18.1% at a 25% budget. The paper argues that Y1 analytics exposure creates a new, efficient jamming attack surface.

Significance. If the results hold, this is a timely and relevant contribution to O-RAN security. The work identifies a realistic threat model—a compromised Y1 consumer—that has not been studied before, and it grounds the attack in an actual over-the-air testbed using srsRAN, GNU Radio, and a custom Y1 producer/consumer with mTLS. The comparison of multiple jamming strategies under both unlimited and budget-constrained settings is a useful framework for evaluating analytics-driven interference. The main strengths are the concrete testbed implementation and the clear demonstration that traffic-aware jamming can reduce transmission duty cycle while preserving much of the disruption of always-on jamming. However, the central quantitative claims depend on parameter choices and experimental procedures that currently lack adequate validation.

major comments (4)

[§VI-B vs §VI-C] The cluster-to-traffic labeling is internally inconsistent. Part B's defined traffic profile (Section VI-B) consists of 4 Mbps, 2 Mbps, 500 Kbps, and idle, but Section VI-C reports clusters labeled as high (4 Mbps), medium (500 Kbps), low (100 Kbps), and idle. The 2 Mbps class is absent and a 100 Kbps class that was never generated appears. This means the reported 18.1% bitrate drop for the 'High Traffic' jammer (Table IV) cannot be cleanly attributed to targeting the highest-throughput flow; the 2 Mbps samples may have been merged into another cluster or treated as noise. Please report cluster centroids, indicate where 2 Mbps samples were assigned, and re-evaluate with ground-truth labels. If labels were assigned post hoc, this must be stated and justified.
[§V and §VI-C] The jammer parameters are selected on the same traffic distribution used for evaluation, so the measured efficiency is partly in-sample. The threshold θ is 'selected based on offline traffic profiling' of the same fixed 4 Mbps scenario; DBSCAN ε=0.30, minPts=10 are tuned on n=227 samples from the same Part B traffic; and the cluster-to-traffic labels are manually assigned. The reported duty-cycle reductions and bitrate drops therefore reflect tuned parameters, not a parameter-free attack. Please use a held-out traffic trace for parameter selection, or provide a sensitivity analysis showing how results vary with θ, ε, minPts, and label assignment.
[Tables III and IV] All experimental results are single-run point estimates with no variance, no number of trials, and no statistical tests. For example, the claim that the threshold jammer 'closely replicates' the always-on jammer rests on a 40.5% vs 45.4% bitrate drop difference; without repeated runs, this gap may not be significant. Similarly, the conclusion that the high-traffic jammer 'consistently delivers' the highest disruption is based on one run per budget level. Please report means, confidence intervals, and the number of OTA repetitions for each strategy and budget.
[§VI-F and Table II] The paper concedes that the nine metrics in Table II are not explicitly listed in the current Y1 specification and that the Y1 producer is a custom Flask implementation because no open-source RIC supports Y1. This is a load-bearing limitation: the attack's feasibility in real deployments depends on whether current or near-future Y1 RAI types expose sufficiently informative metrics. The abstract claims the work 'exploits' the Y1 interface, which overstates the current specification's exposure. Please frame the contribution as demonstrating an attack against a plausible Y1 analytics extension, and state explicitly which of the nine metrics are available in today's Y1 RAI definitions versus which are assumed.

minor comments (4)

[§V-B, Eq. (3)] The symbol I is used both as the index set of jamming-target clusters and as the identity (in 'if j* ∉ I'); this is confusing. Use a different symbol, e.g., J_target.
[Table IV] The table formatting is corrupted: several entries run together (e.g., '2141635 11.58.332065406 14.610.612013937 16.720.711954988 18.118.47'). Please fix the table so each numeric column is clearly separated.
[§VI-D] All metrics are said to be 'averaged across active UEs,' but the testbed contains a single UE. Clarify whether the aggregate cell-level metric equals the single-UE metric, and discuss how multi-UE scenarios would affect the threshold/clustering logic.
[§VI-C] The DBSCAN configuration is described as 'optimal' after parameter tuning, but no tuning criterion is given. State the objective function or validation procedure used to choose ε=0.30 and minPts=10.

Circularity Check

2 steps flagged · score 6.0 of 10

Part of the claimed efficiency is built into the jammer's fitted threshold, and the clustering evaluation is in-sample; the disruption measurements are independent but the transmission-time reduction reduces to the input traffic schedule.

fitted input called prediction [Section V-A (Eq. 1) and Section VI-B/VI-E.1 (Part A, Table III)]
"JAM if Bitrate_t ≥ θ; NO JAM otherwise, where θ is a predefined threshold selected based on offline traffic profiling. For example, if the traffic is expected to operate consistently at 4Mbps during active periods, a threshold θ=1Kbps may be sufficient to distinguish active from idle states. ... The total traffic session spans approximately 270 seconds, with 75.4% active traffic and 24.6% idle time. ... the Y1-Threshold jammer ... achieves ... 73% transmission activity closely aligned with the true traffic activity level of 75.4% as defined in the traffic scenario."

The threshold θ is chosen using the known active bitrate (4 Mbps) and idle bitrate of the same Part A traffic schedule. With θ=1 Kbps, Eq. (1) becomes, by construction, an indicator of the pre-defined active/idle intervals. Therefore the reported 27% transmission-time saving is not an independent empirical finding; it is the input idle fraction (24.6%) plus a small classification error. The disruption metrics (BLER, bitrate drop) are measured and not forced, so the circularity is partial.
other [Section VI-C and Table IV (Part B)]
"Manual inspection of the feature centroids revealed semantic groupings: Cluster 3 corresponded to high traffic (4 Mbps), Cluster 0 to medium traffic (500 Kbps), Cluster 2 to low traffic (100 Kbps), and Cluster 1 to idle states (near-zero activity). These labels were used to guide the jammer's live decisions in Part B. ... It achieves a maximum bitrate drop of 18.1% at 25% jamming budget, substantially higher than the random and lower traffic jammers, by focusing its transmission solely on the highest-bandwidth flow (4 Mbps)."

The cluster-to-traffic mapping is assigned post hoc by manual inspection on the same traffic distribution used for the evaluation, and no ground-truth validation is reported. Moreover, the mapping conflicts with the stated Part B profile (4 Mbps, 2 Mbps, 500 Kbps, idle): the 2 Mbps class is absent and a 100 Kbps class that was not generated appears. This means the 'High Traffic' jammer's target is not cleanly identified as the 4 Mbps flow, so the headline 18.1% result is not supported by a verified derivation; it is an in-sample, manually labeled maximum rather than an independent prediction.

full rationale

The paper's core contribution is an over-the-air empirical comparison, and the always-on and random jammers provide external benchmarks with independent content. There is no load-bearing self-citation chain or imported uniqueness theorem. However, the threshold jammer's transmission-time reduction is essentially fixed by choosing θ from the same traffic schedule used for evaluation; Eq. (1) with θ=1 Kbps and a 4 Mbps-vs-idle signal makes the 73% active time a restatement of the 75.4% active input. The DBSCAN model and its cluster labels are also trained/tuned on the same Part B traffic profile, and the manual label assignment is inconsistent with the stated traffic classes (2 Mbps missing, 100 Kbps spurious), so the 18.1% 'high-traffic' result is best understood as an in-sample fitted maximum, not a clean prediction. The admitted gap between the implemented metrics and the current Y1 specification (Section VI-F) is an external-validity limitation, not a circularity. Overall, the disruption magnitudes are measured and not tautological, but one component of the central efficiency claim reduces by construction, warranting a partial-circularity score of 6.

Assumptions & free parameters 5 free parameters · 4 assumptions · 0 invented entities

The paper introduces no new physical entities, forces, or conserved quantities; the 'malicious consumer' and 'external jammer' are roles in the threat model, not new theoretical objects. The central claim rests on experimental parameters and domain assumptions about Y1 telemetry availability and behavior.

free parameters (5)

Threshold theta for Y1-threshold jammer = Not explicitly stated; example given as 1 Kbps for 4 Mbps traffic
Chosen based on offline traffic profiling and directly determines the 73% active time in Part A; it is fitted to the known traffic pattern rather than derived.
DBSCAN epsilon = 0.30
Tuned to produce four clusters in Part B; directly controls the clustering-based jammer's decision boundaries.
DBSCAN minPts = 10
Tuned along with epsilon; determines which points are considered noise and affects cluster membership and centroid computation.
Cluster-to-traffic labels = Cluster 3 = 4 Mbps, Cluster 0 = 500 Kbps, Cluster 2 = 100 Kbps, Cluster 1 = idle
Assigned by manual inspection of centroids after clustering; the 'high traffic' targeting strategy is defined post hoc from the same data used in evaluation.
Y1 notification period = 1 s
Fixed in the testbed; determines how quickly the jammer can react to traffic changes and therefore shapes all reported efficiency results.

assumptions (4)

domain assumption An authenticated Y1 consumer can forward analytics to an external jammer without being detected by mTLS or other controls
Threat model in Section IV-A assumes valid credentials and a compromised consumer; the paper states the Y1 spec does not define fine-grained behavioral auditing post-authentication.
domain assumption The metrics used (DL CQI, MCS, bitrate, BLER) are representative of what a real Y1 producer would expose
Section VI-F concedes these metrics are not explicitly listed in the current Y1 specification; the attack's generality depends on this assumption.
domain assumption Cell-level aggregate analytics reflect the active and idle state of the traffic targeted by the jammer
The testbed has a single UE, so aggregate bitrate cleanly indicates the target's activity; in a multi-UE cell aggregate metrics may not identify a specific victim's traffic.
domain assumption Over-the-air jammer transmissions degrade the LTE downlink as assumed
Standard physical-layer jamming assumption, verified here through measured SNR, BLER, and bitrate changes in the specific testbed configuration.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Jamming Smarter, Not Harder: Exploiting O-RAN Y1 RAN Analytics for Efficient Interference." pith.science (2026). https://pith.science/paper/2GTDQIKU

@misc{pith2026250905161,
  author       = {Pith},
  title        = {Pith review of: Jamming Smarter, Not Harder: Exploiting O-RAN Y1 RAN Analytics for Efficient Interference},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/2GTDQIKU}},
  note         = {Machine review of arXiv:2509.05161}
}

read the original abstract

The Y1 interface in O-RAN enables the sharing of RAN Analytics Information (RAI) between the near-RT RIC and authorized Y1 consumers, which may be internal applications within the operator's trusted domain or external systems accessing data through a secure exposure function. While this visibility enhances network optimization and enables advanced services, it also introduces a potential security risk -- a malicious or compromised Y1 consumer could misuse analytics to facilitate targeted interference. In this work, we demonstrate how an adversary can exploit the Y1 interface to launch selective jamming attacks by passively monitoring downlink metrics. We propose and evaluate two Y1-aided jamming strategies: a clustering-based jammer leveraging DBSCAN for traffic profiling and a threshold-based jammer. These are compared against two baselines strategies -- always-on jammer and random jammer -- on an over-the-air LTE/5G O-RAN testbed. Experimental results show that in unconstrained jamming budget scenarios, the threshold-based jammer can closely replicate the disruption caused by always-on jamming while reducing transmission time by 27\%. Under constrained jamming budgets, the clustering-based jammer proves most effective, causing up to an 18.1\% bitrate drop while remaining active only 25\% of the time. These findings reveal a critical trade-off between jamming stealthiness and efficiency, and illustrate how exposure of RAN analytics via the Y1 interface can enable highly targeted, low-overhead attacks, raising important security considerations for both civilian and mission-critical O-RAN deployments.

Figures

Figures reproduced from arXiv: 2509.05161 by the authors.

**Figure 2.** This is the OTA experimental setup, which consists of Near-RT RIC, [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗

**Figure 3.** Distribution of samples across DBSCAN-generated clusters. Noise [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗

Figures from the paper (1 more)

**Figure 4.** Figure 4: Part A: Network Performance Metrics [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

19 extracted references · 18 canonical work pages

[1]

N. D. Tripathi and V . K. Shah,Fundamentals of O-RAN. John Wiley & Sons, 2025

2025
[2]

Dual-Use Commercial and Military Communications on a Single Platform using RAN Domain Specific Language

A. Gatherer, C. Sengupta, S. Sen, and J. H. Reed, “Dual-use commercial and military communications on a single platform using ran domain specific language,” 2024. [Online]. Available: https://arxiv.org/abs/2412.00983

work page Pith review arXiv 2024
[3]

Towards adversary- resilient interference management in o-ran: Requirements and gap analysis,

S. Gopal, W. Garey, R. Rouil, and S. Kowdley, “Towards adversary- resilient interference management in o-ran: Requirements and gap analysis,” National Institute of Standards and Technology, Gaithersburg, MD, NIST Interagency/Internal Report (NISTIR), 2025. [Online]. Available: https://doi.org/10.6028/NIST.IR.8560

work page doi:10.6028/nist.ir.8560 2025
[4]

O-ran specifications,

O.-R. ALLIANCE, “O-ran specifications,” 2023, accessed: 2025-05-29. [Online]. Available: https://www.o-ran.org/specifications

work page 2023
[5]

O-ran y1 interface: General aspects and principles,

W. G. 3, “O-ran y1 interface: General aspects and principles,” O-RAN ALLIANCE Working Group 3, Technical Specification O-RAN.WG3.Y1GAP-R004-v01.01, 2024. [Online]. Available: https: //orandownloadsweb.azurewebsites.net/specifications

work page 2024
[6]

Enhancing o-ran security: Evasion attacks and robust defenses for graph reinforcement learning-based connection management,

R. Balakrishnan, M. Arvinte, N. Himayat, H. Nikopour, and H. Moustafa, “Enhancing o-ran security: Evasion attacks and robust defenses for graph reinforcement learning-based connection management,” 2024. [Online]. Available: https://arxiv.org/abs/2405. 03891

work page 2024
[7]

Federated deep reinforce- ment learning for efficient jamming attack mitigation in o-ran,

Z. A. E. Houda, H. Moudoud, and B. Brik, “Federated deep reinforce- ment learning for efficient jamming attack mitigation in o-ran,”IEEE Trans. Veh. Technol., vol. 73, no. 7, pp. 9334–9343, 2024

work page 2024
[8]

Radar: Robust drl-based resource allocation against adversarial attacks in intelligent o-ran,

Y . A. Ergu and V .-L. Nguyen, “Radar: Robust drl-based resource allocation against adversarial attacks in intelligent o-ran,”IEEE Trans. Green Commun. Networking, pp. 1–1, 2025

work page 2025

Show all 19 references

[9]

Efficient adversarial attacks against drl-based resource allocation in intelligent o-ran for v2x,

Y . A. Ergu, V .-L. Nguyen, R.-H. Hwang, Y .-D. Lin, C.-Y . Cho, H.-K. Yang, H. Shin, and T. Q. Duong, “Efficient adversarial attacks against drl-based resource allocation in intelligent o-ran for v2x,”IEEE Trans. Veh. Technol., vol. 74, no. 1, pp. 1674–1686, 2025

2025
[10]

System-level analysis of adversarial attacks and defenses on intelligence in o-ran based cellular networks,

A. Chiejina, B. Kim, K. Chowhdury, and V . K. Shah, “System-level analysis of adversarial attacks and defenses on intelligence in o-ran based cellular networks,” inProceedings of the 17th ACM Conference on Security and Privacy in Wireless and Mobile Networks. New York, NY , US...

2024
[11]

Integrated llm-based intrusion detection with secure slicing xapp for securing o- ran-enabled wireless network deployments,

J. Moore, A. S. Abdalla, P. Khanal, and V . Marojevic, “Integrated llm-based intrusion detection with secure slicing xapp for securing o- ran-enabled wireless network deployments,” 2025. [Online]. Available: https://arxiv.org/abs/2504.00341

2025 arXiv
[12]

Anomaly detection for mitigating xapp and e2 interface threats in o-ran near-rt ric,

C.-F. Hung, C.-H. Tseng, and S.-M. Cheng, “Anomaly detection for mitigating xapp and e2 interface threats in o-ran near-rt ric,”IEEE Open Journal of the Communications Society, vol. 6, pp. 1682–1694, 2025

2025
[13]

Securing 5g openran with a scalable authorization framework for xapps,

T. O. Atalay, S. Maitra, D. Stojadinovic, A. Stavrou, and H. Wang, “Securing 5g openran with a scalable authorization framework for xapps,” inIEEE INFOCOM 2023 - IEEE Conference on Computer Communications, 2023, pp. 1–10

2023
[14]

Rogue cell: Adversarial attack and defense in untrusted o-ran setup exploiting the traffic steering xapp,

E. Aizikovich, D. Mimran, E. Grolman, Y . Elovici, and A. Shabtai, “Rogue cell: Adversarial attack and defense in untrusted o-ran setup exploiting the traffic steering xapp,” 2025. [Online]. Available: https://arxiv.org/abs/2505.01816

2025 arXiv
[15]

A system- atic learning method for optimal jamming,

S. Amuru, C. Tekin, M. van der Schaar, and R. M. Buehrer, “A system- atic learning method for optimal jamming,” in2015 IEEE International Conference on Communications (ICC), 2015, pp. 2822–2827

2015
[16]

Welcome to o-ran shared data layer (sdl) in c++ documentation,

O.-R. S. Docs, “Welcome to o-ran shared data layer (sdl) in c++ documentation,”O-RAN Software Community, RIC SDL Documentation, 2023

2023
[17]

O-ran security test specifications,

O-RAN ALLIANCE Security Work Group (WG11), “O-ran security test specifications,” O-RAN ALLIANCE, Tech. Rep., 2024, accessed: 2025- 05-30. [Online]. Available: https://specifications.o-ran.org/specifications

2024
[18]

Point-cloud clustering and tracking algorithm for radar interferometry,

M. F. Ivarsen, J.-P. St-Maurice, G. C. Hussey, D. R. Huyghebaert, and M. D. Gillies, “Point-cloud clustering and tracking algorithm for radar interferometry,”Phys. Rev. E, vol. 110, p. 045207, Oct 2024. [Online]. Available: https://link.aps.org/doi/10.1103/PhysRevE.110.045207

2024 doi
[19]

srsran: Open-source lte/5g ran software suite,

S. R. Systems, “srsran: Open-source lte/5g ran software suite,” GitHub Repository, 2024, accessed: 2024-12-09. [Online]. Available: https://github.com/srsran/srsRAN

2024

Pith tools

Reviewed August 5, 2026 · model on record in the stance chip above.

[1] [1]

N. D. Tripathi and V . K. Shah,Fundamentals of O-RAN. John Wiley & Sons, 2025

2025

[2] [2]

Dual-Use Commercial and Military Communications on a Single Platform using RAN Domain Specific Language

A. Gatherer, C. Sengupta, S. Sen, and J. H. Reed, “Dual-use commercial and military communications on a single platform using ran domain specific language,” 2024. [Online]. Available: https://arxiv.org/abs/2412.00983

work page Pith review arXiv 2024

[3] [3]

Towards adversary- resilient interference management in o-ran: Requirements and gap analysis,

S. Gopal, W. Garey, R. Rouil, and S. Kowdley, “Towards adversary- resilient interference management in o-ran: Requirements and gap analysis,” National Institute of Standards and Technology, Gaithersburg, MD, NIST Interagency/Internal Report (NISTIR), 2025. [Online]. Available: https://doi.org/10.6028/NIST.IR.8560

work page doi:10.6028/nist.ir.8560 2025

[4] [4]

O-ran specifications,

O.-R. ALLIANCE, “O-ran specifications,” 2023, accessed: 2025-05-29. [Online]. Available: https://www.o-ran.org/specifications

work page 2023

[5] [5]

O-ran y1 interface: General aspects and principles,

W. G. 3, “O-ran y1 interface: General aspects and principles,” O-RAN ALLIANCE Working Group 3, Technical Specification O-RAN.WG3.Y1GAP-R004-v01.01, 2024. [Online]. Available: https: //orandownloadsweb.azurewebsites.net/specifications

work page 2024

[6] [6]

Enhancing o-ran security: Evasion attacks and robust defenses for graph reinforcement learning-based connection management,

R. Balakrishnan, M. Arvinte, N. Himayat, H. Nikopour, and H. Moustafa, “Enhancing o-ran security: Evasion attacks and robust defenses for graph reinforcement learning-based connection management,” 2024. [Online]. Available: https://arxiv.org/abs/2405. 03891

work page 2024

[7] [7]

Federated deep reinforce- ment learning for efficient jamming attack mitigation in o-ran,

Z. A. E. Houda, H. Moudoud, and B. Brik, “Federated deep reinforce- ment learning for efficient jamming attack mitigation in o-ran,”IEEE Trans. Veh. Technol., vol. 73, no. 7, pp. 9334–9343, 2024

work page 2024

[8] [8]

Radar: Robust drl-based resource allocation against adversarial attacks in intelligent o-ran,

Y . A. Ergu and V .-L. Nguyen, “Radar: Robust drl-based resource allocation against adversarial attacks in intelligent o-ran,”IEEE Trans. Green Commun. Networking, pp. 1–1, 2025

work page 2025