# Toward Real-Time RAN Observability in Open-Source 5G Systems

Yassir Amami, Ziyad Mabrouk, Chadi Barakat, Thierry Turletti

► To cite this version:

Yassir Amami, Ziyad Mabrouk, Chadi Barakat, Thierry Turletti. Toward Real-Time RAN Observability in Open-Source 5G Systems. The 29th Conference on Innovation in Clouds, Internet and Networks (ICIN 2026), Mar 2026, Athens, Greece. hal-05448027

HAL Id: hal-05448027

https://inria.hal.science/hal-05448027v1

Submitted on 8 Jan 2026

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# Toward Real-Time RAN Observability in Open-Source 5G Systems

Yassir Amami, Ziyad Mabrouk, Chadi Barakat, Thierry Turletti

Inria, Université Côte d'Azur, France

{yassir.amami, ziyad.mabrouk, chadi.barakat, thierry.turletti}@inria.fr

**Abstract**—Diagnosing performance issues in 5G and future dis-aggregated networks remains challenging due to the complexity of the protocol stack and the multitude of interdependent metrics. This is especially true in experimental environments using open-source 5G software, where logs are often verbose, fragmented, and difficult to interpret. Real-time visual observability, especially at the Radio Access Network (RAN) level, is therefore essential for effective troubleshooting. However, tools like 5GC-Observer and Monarch provide only partial support, focusing mainly on the core network and lacking visibility into the RAN, where many performance bottlenecks originate. To tackle this, we present a Prometheus-compatible telemetry pipeline for the OpenAirInterface (OAI) gNB that extracts RAN metrics, adjusts acquisition intervals via a custom FlexRIC model, and visualizes the data in real time with Grafana. The pipeline is also compatible with SRSRAN through a lightweight Telegraf-Prometheus integration, extending its use to multiple open-source stacks. We integrate our solution into the Monarch monitoring architecture for cloud-native 5G, enabling end-to-end observability. An Ansible-based automation simplifies testbed setup and ensures reproducible experimentation. Validation on a realistic testbed shows real-time RAN metrics exposure with negligible overhead.

**Index Terms**—5G, RAN, Real-time monitoring, OpenAirInterface, Monarch, Prometheus, srsRAN

## I. INTRODUCTION

Monitoring 5G networks is essential for ensuring performance guarantees, identifying bottlenecks, and supporting closed-loop control. While core network observability has seen significant progress, the RAN (Radio Access Network) remains largely opaque in both research and practical deployments. The gNB (5G base station) is responsible for critical operations such as scheduling, link adaptation, and resource allocation, yet its internal metrics are rarely exposed in a fine-grained, real-time, and user-friendly manner. This lack of visibility complicates the analysis of 5G behavior under dynamic conditions like congestion, interference, or mobility.

In this work, we bridge this gap by enabling fine-grained, per-User Equipment (UE) monitoring of gNB activity, exposing metrics from the Medium Access Control (MAC), Radio Resource Control (RRC), and physical layers. These metrics are typically present in gNB logs as unstructured text and remain locally stored, making them difficult for network operators to access remotely. Our system extends the Monarch monitoring framework [1], originally designed for slice-aware core observability, without modifying its orchestration logic.

Through a Prometheus-based pipeline [2], we export metrics from the gNB to the Prometheus database. Our framework is designed as a research-oriented tool for experimentation and in-depth RAN analysis, rather than large-scale deployments. It targets moderately sized scenarios where scalability is not the primary concern, making it ideal for prototyping and academic research. The main contributions of this paper are:

* **Design and implementation of an extended RAN monitoring pipeline**, built on Monarch, supporting both OAI [3] and SRSRAN [4] gNBs. The system parses OAI logs and leverages the native SRSRAN JSON metrics (via TELEGRAF) to export fine-grained per-User Equipment (UE) data in a Prometheus-compatible format. It also implements on-the-fly RAN control through a FlexRIC xApp that dynamically adjusts the OAI gNB's log-writing frequency if this is needed by the monitoring task.

* **Validation on a realistic testbed** using real radio hardware to ensure results' reproducibility and accessibility.

* **Evaluation of two representative RAN scenarios**—controlled RF noise injection and multi-UE resource contention—to illustrate real-time visualization and explore relationships between RAN metrics.

* **Turnkey automation for researchers**: an interactive Ansible-based launcher that ships multiple 5G implementations (e.g., Open5GS, OAI, srsRAN, UERANSIM), enables one-command scenario customization and deployment on commodity hardware, and provides ready-made dashboards for rapid, clean insight into 5G behavior.

* **Open-source release** of all developed tools to facilitate adoption and extension by the community.

The rest of this paper is structured as follows. Section II reviews related work and identifies gaps in existing monitoring solutions. Sections III and IV present our observability architecture. Section V describes the testbed setup and experimental scenarios. Section VI evaluates the overhead of the RAN monitoring. Finally, Section VII concludes the paper and outlines future directions.

## II. RELATED WORK

Monitoring and troubleshooting 5G networks is challenging due to their multi-layered protocol stacks and the diversity of performance metrics that must be considered simultaneously. Initially, generic cloud-native observability platforms such as Prometheus [2] and the ELK stack [5] were widely adopted for telemetry collection, storage, and visualization in distributed

<footnote>This work was supported by the ANR under the France 2030 program, grant "NF-NAI: ANR-22-PEFT-0003".</footnote>
systems. While these platforms are scalable and modular, they
are inherently protocol-agnostic and require substantial adap-
tation to support telecom-specific abstractions such as per-UE
visibility and network slice identifiers. To address this, recent
research has focused on observability frameworks tailored
specifically for 5G core monitoring [1], [6]. In [6], the authors
propose 5GC-Observer, a framework that leverages eBPF
probes to capture user- and control-plane metrics from 5G core
functions with minimal overhead, offering real-time insights
into network slice behavior. Similarly, Monarch [1] adopts a
Prometheus-based architecture to deliver slice-aware monitor-
ing of Open5GS cores, visualizing key performance metrics,
primarily slice throughput. However, these approaches either
overlook the RAN, where many performance issues originate,
or rely on simulated environments (e.g., UERANSIM) rather
than real-world deployments, thereby limiting their practical
applicability. In contrast, complementary work has extended
observability to the RAN domain [7]–[10]. For example,
ElasticSDK [7] introduces a software development kit for
programmable monitoring and control across multiple net-
work domains. Programmable telemetry frameworks such as
Janus [9] inject eBPF-based “codelets” directly into real-
time Medium Access Control (MAC) and Physical Layer
(PHY) processing to enable fine-grained RAN monitoring and
control. RANSight [10], instead, leverages programmable O-
RAN interfaces to dynamically adjust telemetry granularity
and deliver slice-level metrics to Radio Intelligent Controller
(RIC) xApps. Beyond these research-oriented frameworks,
some implementations already include internal debugging
tools. Within the OpenAirInterface ecosystem, the T tracer
tool<fnref n="1" /> provides a built-in debugging and monitoring framework
for the RAN. It includes a real-time event collector in the
signal processing chain, plus tools for recording, replaying,
and visualizing PHY/MAC traces. While useful for offline LTE
disbugging, it is not ported to 5G NR and lacks standardized
telemetry (e.g., Prometheus) or cloud-native integration (e.g.,
Grafana). Despite these advances, existing solutions exhibit
several limitations. Most fail to provide fine-grained, per-UE
telemetry in operational RAN deployments or require invasive
modifications to gNB implementations. Many also assume
programmable RIC infrastructure, not always available. Real-
world validation is rare, with few studies in controlled Radio
Frequency (RF) environments (e.g., anechoic chambers) for
repeatable, interference-free RAN analysis. In this paper, we
propose a non-intrusive RAN observability framework that
extends the Monarch telemetry pipeline to support detailed
per-UE metrics across Layer 1 (L1), MAC, and Radio Re-
source Control (RRC). For the OAI gNB, it is log-driven,
extracting metrics from existing statistic files; for sRSRAN,
it uses native JSON metrics via TELEGRAF. All metrics are
exported via a Prometheus-compatible interface and visual-
ized in Grafana, enabling real-time, slice-aware insights with
minimal overhead. The design avoids intrusive modifications,

supports adaptive monitoring via a lightweight FlexRIC-based
controller, and integrates with automated testbed scripts for
reproducible 5G experimentation.

### III. BACKGROUND

The Monarch framework [1] was developed to address a
critical need in 5G networks: slice-aware monitoring across
dynamic, cloud-native 5G deployments. Unlike traditional
monitoring solutions, which often focus on individual network
functions, Monarch was designed to provide visibility at the
slice level, supporting advanced orchestration and closed-loop
control use cases. At its core, Monarch adopts a modular,
cloud-native architecture. It relies on Prometheus exporters
to collect metrics from network functions and stores them
in a Prometheus time-series database (TSDB) for scalable
and efficient access. A northbound API allows operators
and applications to issue high-level monitoring requests in
JSON format, that Monarch translates into low-level data
collection primitives. These primitives are executed by Mon-
itoring Data Exporters (MDEs), which fetch relevant met-
rics, and by slice-specific Key Performance Indicator (KPI)
calculators that compute and aggregate results such as slice
throughput. Monarch also integrates with container orches-
tration platforms such as Kubernetes, allowing monitoring
functions to scale with network load and adapt to dynamic
slice instantiation or removal. The original implementation
of Monarch focused on monitoring 5G core networks based
on OPEN5GS, using UERANSIM as a simulated RAN [11].
The evaluation showed that Monarch introduced only modest
CPU and memory overhead. This makes Monarch a natural
foundation for extending observability beyond the core, as it
already provides slice-aware abstractions, adaptive monitoring
mechanisms, and a cloud-native telemetry pipeline that can
be consistently reused across network domains. However,
Monarch's scope remains limited in several important ways: (i)
it targets only core network monitoring, lacking visibility into
the RAN, where many performance bottlenecks originate; (ii)
it supports only one slice-level KPI (throughput), restricting
deeper insights into per-UE or lower-layer behaviors; and
(iii) it was primarily validated with simulated RANs, such
as UERANSIM, which cannot fully capture the complexity
and variability of real radio deployments. These limitations
directly motivate our work, in which we extend Monarch's
architecture with new monitoring capabilities at the gNB level
to capture real-time RAN performance metrics. We also enrich
the telemetry pipeline with additional system-level indicators
such as pod resource utilization and power consumption to
enable a more holistic analysis of 5G behavior. Unlike prior
evaluations limited to simulated setups, we validate our frame-
work using real RAN implementations with physical antennas
and commercial UEs, including OAI and srsRAN, thereby
demonstrating its applicability in practical environments.

### IV. RAN MONITORING FRAMEWORK

We extend Monarch by introducing RAN-level observability
using a gNB based on OAI at first. Our architecture, shown

<footnote n="1">¹T tracer: https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/2025.w05/common/utils/T/DOC/T.md</footnote>
<figure><img src="image_2.png" /><figcaption>Fig. 1: OAI RAN Monitoring Architecture.</figcaption></figure>

in Figure 1, focuses on exposing per-UE metrics from the gNB's internal operations, spanning L1, MAC, and RRC. These values are present in runtime logs but are not exported in a structured or queryable format. To bridge this, we developed a lightweight Prometheus-compatible exporter that parses gNB logs and transforms key entries into labeled metrics that can be scraped by a dedicated MDE that we added to the Monarch architecture. This approach mirrors the Prometheus client integration already present in the Open5GS User Plane Function (UPF) and Session Management Function (SMF) Docker images that Monarch uses for core monitoring. The exporter extracts various metrics, including MAC-level data volumes, signal quality indicators such as Reference Signal Received Power (RSRP), Reference Signal Received Quality (RSRQ), and Signal-to-Noise Ratio (SNR), Hybrid Automatic Repeat reQuest (HARQ) round statistics (errors and retransmissions), BLock Error Rate (BLER) and Modulation and Coding Scheme (MCS) values. Each metric is tagged with UE-level identifiers (i.e., Radio Network Temporary Identifier (RNTI)<fnref n="2" />), enabling temporal and cross-UE comparison.

Our monitoring approach exclusively relies on three dedicated OAI runtime log files: `nrMAC_stats.log`, `nrL1_stats.log`, and `nrRRC_stats.log`. These files are separate from the primary gNB log and are updated based on a hardcoded frequency of 1s, where each new entry overwrites the previous one. This ensures that logs do not grow over time, avoiding memory buildup. Furthermore, since these logs are written independently of the gNB's global logging configuration, adjusting verbosity settings or enabling debug modes does not affect the metrics we extract.

We chose log parsing as our primary extraction method because existing FlexRIC monitoring xApps expose only a

restricted set of metrics. Implementing other metrics that already exist on the gNB logs would require substantial changes to both the OAI FlexRIC agent and gNB internals to extend the monitoring E2 Service Model (E2SM), a complex and error-prone process. Instead, we use FlexRIC only to control the frequency at which the gNB generates logs, enabling adaptive monitoring without altering how metrics themselves are extracted. Specifically, we extended the C source code of both the gNB and FlexRIC to define a custom E2SM that controls the log writing interval. We also developed an xApp that receives the desired monitoring interval from Monarch and enforces it on the gNB through the E2 interface. This enhancement ensures compatibility with Monarch's future adaptive monitoring algorithms and supports on-the-fly tuning of monitoring granularity without service disruption.

<figure><img src="image_3.png" /><figcaption>Fig. 2: RAN Adaptive Monitoring Solution.</figcaption></figure>

Additionally, to support higher-level insights, we extended Monarch's KPI computation module to derive RAN-specific KPIs, including per-UE MAC throughput (uplink and downlink), the number of connected UEs per gNB, and uplink Physical Resource Block (PRB) saturation per UE. These are exposed via the same JSON-based request mechanism used in Monarch, which then deploys the necessary data collection and computation components automatically.

Beyond the OAI-based deployment, the proposed gNB MDE was also made compatible with SRSRAN-based setups. In this case, we leverage TELEGRAF to subscribe to the SRSRAN gNB's built-in JSON metrics endpoint. Notably, the SRSRAN configuration natively supports a configurable reporting periodicity parameter that defines the frequency (in milliseconds) at which certain metrics are generated. Telegraf parses these real-time JSON metrics and converts them into Prometheus-compatible time series, which are then collected by Monarch's monitoring stack.

Finally, we developed an extensive and fully programmable ANSIBLE-based framework that automates the deployment of the entire 5G testbed and monitoring infrastructure on commodity hardware. This unified codebase supports both the OPEN5GS and OAI cores, as well as multiple RAN implementations (OAI, SRSRAN and UERANSIM), operating

<footnote n="2">²RNTI is a unique identifier assigned by the gNB to each connected UE, used to address and distinguish UEs over the radio interface.</footnote>
either with real radio hardware or in simulated RF environ-
ments. Designed as a turnkey tool for researchers, it enables
one-command setup, repeatable experiments, and effortless
switching between different 5G configurations without manual
intervention. This automation removes time-consuming and
error-prone setup procedures, thus accelerating reproducible
experimentation and comparative analysis across diverse 5G
deployments.

All of these contributions are open-source, publicly avail-
able on GitHub <fnref n="3" /> and ready to use by whoever wants to start
5G experimentation:

* `/5g_ansible`: Automates the full testbed setup and orchestrates the execution of experimental scenarios.

* `/5g-monarch`: Extends Monarch for RAN metrics and new KPIs.

* `/flexric`: Modified FlexRIC with new E2SM for adaptive log control.

* `/oai-gnb-log-parser`: Lightweight Prometheus exporter for OAI gNB logs.

* `/openairinterface5g`: Modified OAI gNB with E2SM support for monitoring interval control.

* `/srsran-helm`: Dockerfiles and Kubernetes deployment manifests for SRSRAN, SRSUE, and TELEGRAF-based monitoring integration.

V. EXPERIMENTAL SCENARIOS

To validate and illustrate the observability capabilities of our
RAN monitoring extension, we designed two complementary
experimental scenarios using the OAI gNB. These scenarios
address distinct yet realistic network stress conditions: one
focused on **radio channel degradation**, and the other on
**resource contention between multiple users**. To further
validate the generality of the monitoring approach beyond the
OAI-based deployment, we conducted a third scenario using
SRSRAN. All experiments in this work were conducted on
a hybrid testbed combining the SLICES-RI<fnref n="4" /> infrastructure,
which provides open access to researchers through a simple
registration process, and R2LAB<fnref n="5" />, a controlled radio experi-
mentation facility located at Inria. The RAN is deployed using
a AW2S JAGUAR 2T2R RADIO UNIT (RU)<fnref n="6" />, operating under
CPRI Split 8 with a maximal bandwidth of 50 MHz and 2×2
Multiple Input and Multiple Output (MIMO) capabilities. The
UEs used in our experiments are composed of RASPBERRY
PI 4 boards with 5G QUECTEL RM500Q-GL and QUECTEL
RM520N-GL modules (referred to as *qhat*). As part of our
experimental scenarios, we also use a USRP N320 software
radio device as a Gaussian noise generator. Our deployment
spans three physical servers in the SLICES cluster:

* `sopnode-f1` and `sopnode-f2` servers, each equipped with AMD EPYC 9374F CPUs and 192 GiB of RAM,

* `sopnode-f3` server, featuring an INTEL XEON PLATINUM 8462Y+ processor and 512 GiB of RAM.

Each component is distributed across these nodes via Kuber-
netes: the OPEN5GS 5G CORE is deployed on `sopnode-f2`
with two slices; the OAI gNB and FLEXRIC controller run on
`sopnode-f3`; and the MONITORING STACK, comprising the
MONARCH framework with our RAN MONITORING EXTEN-
sION, operates on `sopnode-f1`. This testbed setup enables a
realistic yet controllable environment for exploring UE-level
metrics, radio dynamics, and network behavior under well-
defined experimental conditions.

A. Scenario 1: Controlled Interference

<figure><img src="image_4.png" /><figcaption>Fig. 3: gNB spectrum abstractly represented by a 2D grid of resource elements.</figcaption></figure>

To evaluate the RAN performance under interference using
our monitoring solution, we deploy the OAI gNB with a
narrow configuration of 51 PRBs using the Jaguar RU <fnref n="7" />. This
setup operates over the frequency range 3401.22 MHz to
3419.52 MHz (approximately 20 MHz bandwidth) and 1x1
Single Input and Single Output (SISO). Figure 3 provides a
conceptual mapping of the allocated PRBs as a 2D grid of
resource elements. We connect the *qhat01* UE on *slice 1*
and initiate a full-duplex (uplink and downlink) *TCP iperf3*
*test* for 5 minutes. After 100 seconds, we introduce artificial
interference using a USRP N320 as a noise generator with
the GNURadio *uhd_siggen* utility. Spectrum visualization
is handled using a USRP B210 running the GNURadio
*uhd_fft* tool.

1) Scenario 1A: Narrowband Interference (2 MHz):
We begin by generating a 2 MHz-wide Gaussian noise from

<footnote n="3">³https://github.com/yassir63/5g_ansible</footnote>

<footnote n="4">⁴SLICES-RI: https://www.slices-ri.eu/</footnote>

<footnote n="5">⁵R2lab: https://r2lab.inria.fr</footnote>

<footnote n="6">⁶Jaguar RU: https://www.aw2s.com/solutions/rrh-rru/</footnote>

<footnote n="7">⁷The gNB configuration used is available at: https://github.com/yassir63/oai5g-rru/blob/gen-cn2/ran-config/conf/gnb.sa.bande78.51prb.aw2s.ddsuu.20MHz.conf</footnote>
3401.22 MHz to 3403.22 MHz, at a moderate gain of 40 dB. This frequency band overlaps with the first 5 PRBs, as computed by: $\frac{2 \text{ MHz}}{12 \times 30 \text{ kHz}} \approx 5.6$ PRBs, where 12 is the number of sub-carriers per PRB, and 30kHz is the sub-carrier spacing. This noise is visible in the spectrum scan on Figure 4 as an elevated gain over the impacted range.

<figure><img src="image_5.png" /><figcaption>Fig. 4: Spectrum visualization for Scenario 1A.</figcaption></figure>

In the Grafana dashboard (Figure 5), the top panels display the slice-level throughput in downlink and uplink, which were the only metrics originally available in Monarch’s Grafana dashboard, calculated via the built-in `/metrics` endpoints of the SMF and UPF in the Open5Gs core. As part of our contribution, we added the new `RAN Stats` section that surfaces RAN metrics extracted from the gNB runtime logs, where the `MAC Throughput`, `gNB Uplink PRB Saturation` and `Number of Connected UEs` are the high-level KPIs computed through the modified KPI-calculator module of Monarch and the rest are raw gNB metrics. This new set of metrics is critical for understanding the gNB’s behavior under RF impairment. The observed impacts include:

*   **Physical Random Access Channel (PRACH) $I_0$**, which represents the total received interference plus noise during random access, surges from 15 dB to approximately 32 dB, reflecting increased uplink noise power.

*   **SNR per RNTI** becomes unstable and increases in variance, jumping from a previous cap of around 20 dB to peaks of approximately 33 dB, reflecting fluctuating interference levels.

*   In contrast, UE-reported metrics, like the `RSRP`, `RSRQ`, and `SINR`, remain unchanged, likely because the UE is unable to differentiate between desired signal and Gaussian noise, reporting total power instead.

*   **PRB $I_0$ noise deviation** clearly identifies the noise-affected PRBs: the first six PRBs show deviation values of 2, 9, 11, 12, 9 and 1 dB respectively, while unaffected PRBs remain between -9 dB to -20 dB deviation from the average interference value of -44 dB stored as value for PRB 25, to which all other PRBs are compared.

On the uplink (right side of Figure 5):

*   **MCS per RNTI** drops from about 16 to 14, corresponding to a shift in modulation order from $Q_m = 4$ to $Q_m = 2$ bits per symbol, based on 3GPP TS 38.214, Table 5.1.3.1-3.

*   Consequently, **MAC Throughput** drops from approximately 25 Mbps to about 20 Mbps.

<figure><img src="image_6.png" /><figcaption>Fig. 5: Grafana dashboard for Scenario 1A.</figcaption></figure>
* HARQ errors rise significantly post-interference, indicating decoding failures.

* The downlink BLER remains nearly constant at about 0.07%. When interference degrades the channel, the scheduler quickly lowers the MCS to a more robust scheme, preventing noticeable packet losses. A brief BLER rise likely occurs during this adaptation but is too short to appear clearly on the dashboard.

On the downlink (left side of Figure 5):

* Most metrics, like HARQ errors, MCS, and SNR remain unaffected, indicating stronger robustness.

* The only visible change is a small increase in BLER, from 0% to approximately 0.02%, suggesting minor decoding difficulties, reflected in a small decrease of MAC Throughput of 1Mbps.

The uplink-downlink asymmetry reveals that uplink is more vulnerable to narrowband interference in our SISO setup. This is expected, as the UE's transmit power is limited and more susceptible to localized jamming than the gNB's stronger and more centralized downlink signal.

## 2) Scenario 1B: Wideband Interference (20 MHz):
We now extend the experiment by generating a 20MHz-wide Gaussian noise covering the entire spectrum used by the gNB. The noise is transmitted by the USRP N320 with a high gain of 110 dB, completely overlapping the 51 PRBs of the gNB. This scenario represents a severe jamming condition, simulating full-spectrum high-level interference. The results are shown in the Grafana dashboard snippet (Figure 6) and reveal a dramatic degradation in gNB performance across multiple layers. The observed impacts are as follows:

* Downlink and Uplink MAC Throughput collapse entirely. The throughput drops from a sustained 50 Mbps in the downlink and 25 Mbps in the uplink, to about 750 kbps, reflecting near-total communication breakdown between the gNB and the UE.

* BLER increases sharply, jumping from 0% to approximately 0.35% in the downlink, and from 0.1% to around 0.45% in the uplink.

* MCS also undergoes a drastic reduction, dropping from 28 in the downlink (corresponding to $Q_m = 6$) and 16 in the uplink ($Q_m = 4$) to 0, which implies $Q_m = 2$ with the lowest possible code rate of $R = 30/1024$. This sharp MCS drop shows the UE and gNB can no longer negotiate an effective PHY configuration, transmitting only highly redundant, minimal data.

In contrast to the 2-MHz narrowband case, where the impact was primarily observed in the uplink, both downlink and uplink are equally affected in this scenario. Notably, as soon as the interference source is turned off, the system shows immediate and complete recovery. The MAC Throughput, MCS, and BLER metrics return to their original healthy states within seconds, confirming that the gNB and the UE remain responsive and capable of renegotiating PHY parameters once the channel becomes viable again.

<figure><img src="image_7.png" /><figcaption>Fig. 6: Grafana dashboard snippet for Scenario 1B.</figcaption></figure>

## B. Scenario 2: Multiple UEs with iperf

In this second scenario, we evaluate the effect of parallel traffic generation across multiple UEs connected to 2 different slices. Specifically, four UEs ($qhat01$, $qhat02$, $qhat03$, and $qhat11$) were connected simultaneously to the Jaguar gNB, with the following slice settings: $qhat01$ and $qhat03$ were mapped to slice 1, while $qhat02$ and $qhat11$ were assigned to slice 2. The gNB was configured with 133 PRBs and 2x2 MIMO.<fnref n="8" /> A 400-second-long full-duplex TCP iperf3 session was initiated from each UE in a sequential fashion: $qhat01$ at time $t = 0s$, $qhat02$ at $t = 100s$, $qhat03$ at $t = 200s$, and finally $qhat11$ at $t = 300s$. As each UE joins, the total available MAC throughput is redistributed across all active UEs, leading to a proportional drop in per-UE throughput.

We can observe this effect in Figure 7. Initially, $qhat01$ alone achieves approximately 250 Mbps downlink and 30 Mbps uplink. When $qhat02$ joins, both UEs share the bandwidth, stabilizing around 150 Mbps downlink and 19 Mbps uplink each. Upon addition of $qhat03$, the average per-UE throughput becomes 106 Mbps downlink and 13 Mbps uplink, and finally, with all four UEs active, the average drops to 77 Mbps downlink and 10 Mbps uplink per UE. A symmetrical trend is observed in reverse as each UE completes its 400-second iperf session. Once $qhat01$ finishes, the bandwidth is redistributed across the remaining three UEs, and so on. The dashboard also confirms these dynamics at the slice-level throughput, where both slice 1 and slice 2 show throughput variations that reflect the number and activity of their respective UEs. In particular, the total MAC throughput remains relatively stable, peaking at about 330 Mbps in downlink and 41 Mbps in the uplink, which confirms the gNB's ability to utilize the available radio resources consistently. It is also

<footnote n="8">⁸The used gNB configuration file is at: https://github.com/yassir63/oai5g-rru/blob/gen-cn2/ran-config/conf/gnb.sa.ban d78.133prb.aw2s.dddsu.50MHz.conf</footnote>
<figure><img src="image_8.png" /><figcaption>Fig. 7: Grafana dashboard snippet after Scenario 2.</figcaption></figure>

worth noting the impact of radio conditions on throughput, as *qhat11*, the last UE to start, is physically located further from the antenna.⁹This is reflected in its significantly lower RSRP value of -103 dB, compared to the -66 dB (*qhat01* and *qhat03*) and -67 dB (*qhat02*) values for the other UEs. This poorer radio condition leads to a noticeably lower throughput for *qhat11*, which in turn causes a slight drop in the total MAC throughput during the final 100 seconds of the experiment, when it is the only active UE.

### C. Scenario 3: Controlled Interference with srsRAN gNB

In this setup, the USRP N300 acted as the SRSRAN gNB, configured for 20MHz operation in FDD Band n3 with a downlink Absolute Radio Frequency Channel Number (ARFCN) of 368,500, corresponding to center frequencies of 1842.5 MHz (DL) and 1747.5 MHz (UL) according to 3GPPTS 38.104. The system operated in a 1x1 SISO configuration.<fnref n="10" /> We connected the *qhat01* UE on *slice 2* and ran a 10-minute downlink TCP iperf3 session. After 4 minutes, we introduced a 10MHz-wide interference signal, transmitted at high gain (110 dB) from a USRP B210 and centered at 1842.5 MHz. Since this is the downlink carrier frequency, the injected noise affects only the downlink.

Figure 8 shows the resulting Grafana dashboard. The downlink throughput, initially at 59 Mbps, drops to about 35 Mbps during interference and returns to 59 Mbps once the noise is

<figure><img src="image_9.png" /><figcaption>Fig. 8: Grafana dashboard snippet after Scenario 3.</figcaption></figure>

removed. This behavior aligns with the downlink *MCS*, which falls from 28 to roughly 20 before recovering, and with the downlink *BLER*, which rises from near 0% to around 4% and then returns to baseline. Throughout the experiment, the *Channel Quality Indicator (CQI)* remains stable, indicating that the UE observes only mild variations in average channel quality while the gNB PHY metrics reflect the short-term impairment more clearly.

SRSRAN exposes several additional RAN metrics (e.g., buffer occupancy, multi-layer latency and scheduler indicators...), though we omit them here for brevity. At the same time, certain interesting OAI-specific metrics, such as the per-PRB $I_0$ noise deviation, are not reported by SRSRAN. Uplink metrics (e.g., uplink *BLER*, bitrate, and SNR) are also exposed, but they are not relevant here since no uplink traffic was generated apart from TCP acknowledgements.

This scenario confirms that our monitoring extension operates seamlessly with SRSRAN, producing the expected metric behavior under controlled interference, consistent with our observations on OAI.

## VI. RAN MONITORING OVERHEAD

To evaluate the overhead introduced by our RAN monitoring extension, we analyzed the resource usage in terms of CPU, memory, and disk space across different numbers of connected

<footnote n="9">⁹Radio devices positions on the testbed setup: Jaguar RU antenna at slot 3; USRP N320 antenna at slot 8; USRP B210 at slot 2; UEs *qhat01*, *qhat02*, *qhat03* and *qhat11* at slots 4, 13, 9 and 28 respectively.</footnote>

<footnote n="10">¹⁰gNB configuration: https://github.com/Ziyad-Mabrouk/srsran-helm/blob/main/charts/srsran-gnb/values-n300.yaml</footnote>