# RRC Signaling Storm Detection in O-RAN

arXiv: https://arxiv.org/abs/2504.15738 · HTML: https://mlsanity.com/paper/2504.15738/

## Key facts

- Cited by 3 papers in the map (data through 14 Oct 2026).
- First posted on arXiv 22 Apr 2025.

## Built on by (most cited first, 3 of 3)

- [AI-Native Closed-Loop Security for 6G-Enabled Cyber-Physical Systems: From Edge Detection to Network-Wide Mitigation](https://mlsanity.com/paper/2606.08173/) (2026)
- [Diff-DDoS: Realistic Cyber-Physical Attack Synthesis and Robust Detection for 5G-Enabled CPS Using Tabular Diffusion Models](https://mlsanity.com/paper/2608.17796/) (2026)
- [Diffusion-Based Stress Testing of Overload Monitoring for Resilient Emergency Cellular Networks Using Internet CDR Proxies](https://mlsanity.com/paper/2610.04526/) (2026)

## Abstract (arXiv)

The Open Radio Access Network (O-RAN) marks a significant shift in the mobile network industry. By transforming a traditionally vertically integrated architecture into an open, data-driven one, O-RAN promises to enhance operational flexibility and drive innovation. In this paper, we harness O-RAN's openness to address one critical threat to 5G availability: signaling storms caused by abuse of the Radio Resource Control (RRC) protocol. Such attacks occur when a flood of RRC messages from one or multiple User Equipments (UEs) deplete resources at a 5G base station (gNB), leading to service degradation. We provide a reference implementation of an RRC signaling storm attack, using the OpenAirInterface (OAI) platform to evaluate its impact on a gNB. We supplement the experimental results with a theoretical model to extend the findings for different load conditions. To mitigate RRC signaling storms, we develop a threshold-based detection technique that relies on RRC layer features to distinguish between malicious activity and legitimate high network load conditions. Leveraging O-RAN capabilities, our detection method is deployed as an external Application (xApp). Performance evaluation shows attacks can be detected within 90ms, providing a mitigation window of 60ms before gNB unavailability, with an overhead of 1.2% and 0% CPU and memory consumption, respectively.