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

HAL
open science

# Comparative E2E Performance Analysis of O-RAN Designs in a 5G Standalone Testbed

Moussa Guemdani, Pengwenlong Gu, Chi Dung Phung, Stefano Secci

► To cite this version:

Moussa Guemdani, Pengwenlong Gu, Chi Dung Phung, Stefano Secci. Comparative E2E Performance Analysis of O-RAN Designs in a 5G Standalone Testbed. IEEE HPSR, May 2025, Osaka (Japan), Japan. 10.1109/HPSR64165.2025.11038873. [hal-05039989](https://hal.science/hal-05039989v1)

HAL Id: hal-05039989

https://hal.science/hal-05039989v1

Submitted on 18 Apr 2025

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_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Comparative E2E Performance Analysis of O-RAN
Designs in a 5G Standalone Testbed

Moussa Guemdani, Pengwenlong Gu, Chi-Dung Phung, Stefano Secci

CEDRIC, CNAM, France. Email: first-name.last-name@cnam.fr.

***Abstract***—The Open Radio Access Network (O-RAN) paradigm has attracted considerable attention from both academic researchers and industry stakeholders, owing to its capacity to significantly enhance the adaptability and flexibility of cellular network architectures. However, the disaggregation of Generation NodeB (gNB) in O-RAN introduces increased system complexity and potential variability in performance metrics, necessitating empirical evaluation to determine whether its performance can rival or exceed that of conventional monolithic designs. In this study, we developed a standalone (SA) testbed to quantitatively assess the downlink (DL) transmission performance of two O-RAN architectures, implemented on two widely adopted open-source platforms: srsRAN and OAI. To ensure a scientifically robust and comprehensive analysis, we meticulously selected key performance metrics, implemented measures to provide solid statistical results and eliminate residual effects between test iterations. Test results show that the split enhances network flexibility by offloading certain processing tasks to the Distributed Unit (DU), thereby reducing the overall hardware usage burden and potentially improving the computational efficiency and resource allocation in future RAN networks.

## I. INTRODUCTION

The Open Radio Access Network (O-RAN) has garnered significant interest from both the research community and industry due to its potential to dramatically enhance the flexibility of cellular networks. Unlike traditional RANs, Open-RAN utilizes standardized open interfaces and decouples network functionalities into modular components, thus establishing an ecosystem that overcomes issues related to node coordination, network reconfiguration latency, and vendor lock-in [1]. This framework enables advanced, data-driven optimization strategies, closed-loop control mechanisms, and automation processes, which collectively enhance network performance, efficiency, and scalability.

While the disaggregation of RAN represents a significant advancement toward more flexible, cost-effective, and innovative mobile network architectures, it simultaneously escalates system complexity and introduces potential uncertainties in performance metrics. Therefore, extensive empirical testing of O-RAN frameworks is necessary to evaluate whether these disaggregated architectures can match or surpass the performance of traditional monolithic RAN designs. Moreover, it is crucial to assess whether identical configuration parameters yield comparable performance outcomes across different O-RAN implementations.

Several studies have explored open-source platforms such as srsRAN [2] and OpenAirInterface (OAI) [3], evaluating their utility in building 5G Standalone (SA) testbeds. Key

areas of focus include interoperability, performance metrics across diverse configurations, and compatibility testing with various user equipment (UE). In [4], the authors conducted a detailed performance analysis of single-cell 5G testbeds, assessing multiple configurations including Uplink (UL) and Downlink (DL) data rates, end-to-end (E2E) latency, and network coverage using Open5GS, srsRAN and OAI RAN. To evaluate the computational efficiency of the testbeds, they monitored the CPU and memory consumption of the host computer running the 5GC and RAN. In [5], the authors conducted a comparative analysis of two versions of the srsRAN platform, tailored for 4G and 5G networks. The study encompasses both wired and wireless configurations, testing under single-UE and multi-UE scenarios. Performance metrics included UL and DL data rates, latency, and system stability. The wired connectivity mode provides a more controlled environment for loansharking, eliminating interference and wireless channel imperfections, whereas the wireless mode represents more realistic deployment scenarios. In [6] the authors evaluated the performance of srsRAN and OAI with a single UE system but with different combinations of RAN and core software (Open 5GS and OAI 5GC [7]) under uniform hardware and configuration settings. Performance metrics also include UL and DL data rates and latency. Analysis indicated that the srsRAN Project and Open5GS were more resilient, managing disconnections with greater efficiency than the OAI platforms, which frequently necessitated software restarts. In terms of bitrate performance, the OAI 5G RAN demonstrated a superior DL rate and the srsRAN excelled in UL performance. Regarding latency, OAI 5G RAN provided more consistent and lower latency results. It was further observed that the choice between Open5GS and OAI 5GC core network software had a negligible effect on both data rates and latency, suggesting that the RAN software predominantly dictates performance. Besides the tests focused on the O-RAN platforms, a study was conducted in [8] on the impact of Next Generation NodeB (gNB) configurations on UL and DL throughput and latency. However, to the best of our knowledge, no study has yet provided a detailed, link-by-link analysis of the disaggregated O-RAN model using both srsRAN and OAI platforms.

In this paper, we established a SA testbed to quantitatively evaluate the DL transmission performance of two O-RAN architectures, utilizing two widely used platforms: srsRAN and OAI. For a comprehensive analysis, we selected a suite of key performance metrics including backhaul, midhaul, fronthaul, and E2E bitrate, complemented by packet loss, jitter, CPU
utilization, and disk I/O to systematically assess user-plane performance and identify potential bottlenecks across both architectural configurations on these platforms. To ensure experimental consistency and mitigate residual effects between trials, we rebooted the servers following each test iteration and replicated each test scenario 30 times, enhancing statistical robustness. Test results show that the split enhances network flexibility by offloading certain processing tasks to the Distributed Unit (DU), thereby reducing the overall hardware usage burden and potentially improving the computational efficiency and resource allocation in future RAN networks.

## II. TESTBED CONFIGURATION

This section details the integration of our end-to-end 5G SA testbed. As illustrated in Fig. 1, it supports both monolithic and disaggregated gNB architectures. The testbed utilizes the srsRAN Project (Release 24.10) and OpenAirInterface (OAI, v2.2.0) to implement the gNB protocol stack.

### A. Monolithic gNB

1) **5G SA Core:** Our testbed leverages an open-source C-language implementation of the 5G Core (5GC). The 5GC runs on a general-purpose computer equipped with 16 Gibibytes of RAM and an Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz 16-core CPU. We leverage Open5GS to deliver key 5GC functionalities such as the Access and Mobility Management Function (AMF), Session Management Function (SMF), and User Plane Function (UPF). An important parameter to be configured is the Public Land Mobile Network (PLMN) ID, composed of Mobile Country Code (MCC) and Mobile Network Code (MNC), which are set to 001 and 01 respectively.

2) **gNB:** The RAN control-plane interfaces share a common protocol stack that utilizes the Stream Control Transmission Protocol (SCTP) over IP. The 5G RAN introduces SCTP endpoint management, which enhances virtualized deployments by enabling flexible scaling and redundancy. Each interface also employs its own application protocol layered atop SCTP, tailored to its specific role within the network.

The user plane of the 5G RAN adheres to a standardized protocol stack, utilizing the GPRS Tunneling Protocol User Plane (GTP-U) over UDP/IP. This enables the efficient transport of user data packets between 5G RAN nodes and the User Plane Function (UPF) or among the RAN nodes themselves. The 5G user plane is designed to ensure effective data transfer across the radio interface while maintaining the required Quality of Service (QoS). Some key functions are listed as follows:

* Service Data Adaptation Protocol (SDAP): SDAP maps packets to Data Radio Bearers (DRBs) based on QoF Flow Identifier (QFIs).

* Packet Data Convergence Protocol (PDCP): It provides security by implementing encryption and integrity protection, enhances reliability and reduces latency through retransmission and packet duplication, and continuously manages reordering and duplicate detection.

<figure><img src="image_3.png" /><figcaption>Fig. 1: Our 5G SA Testbed Platform.</figcaption></figure>

* Radio Link Control (RLC): RLC operates in three modes, Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). It segments and reassembles data while supporting retransmission via Automatic Repeat request (ARQ).

* Medium Access Control (MAC): MAC multiplexes logical channel data into transport blocks, prioritizes traffic scheduling, and manages Hybrid ARQ (HARQ) for efficient retransmission.

The monolithic gNB stack is deployed on a dedicated server equipped with 256 GB of RAM and an AMD Ryzen Threadripper PRO 7955WX 16-core CPU. The connections between the 5GC, gNB, and O-RU utilize 10-Gb SFI/SFP+ network interfaces, which enable high-speed communication. These links are established using fiber-optic cables.

3) **O-RU and UE:** In this 5G system deployment, the Ettus Research USRP X310 is used as the RU due to its high-performance software-defined radio (SDR) capabilities, and support for high-frequency operating bands. Over-the-air transmission occurs on the N77 band (3.3-4.2 GHz). CNAM has authorized to operate within the 3.8 to 4.2 GHz range, with a maximum bandwidth allocation of 100 MHz. The testbed includes a diverse selection of 5G-compatible UEs, such as the OnePlus 8 Pro, iPhone 13, iPhone 15, Samsung Galaxy S24 Ultra, and the Apal plug-and-play 5G USB dongle. For the experiments discussed in this paper, the Galaxy S24 Ultra was selected due to its consistently high network performance, particularly in terms of channel quality and modulation adaptability.

### B. Disaggregated gNB

In one disaggregated model, the gNB is functionally split into three components: the Open Centralized Unit (O-CU), the Open Distributed Unit (O-DU), and the Open Radio Unit (O-RU). Both frameworks support two major split options: Option 2 and Option 7.2. Option 2, standardized by 3GPP, involves decoupling the O-CU and O-DU, which are connected via an F1 link. This split separates the control and user planes, facilitating centralized control plane deployments and potentially reducing hardware costs. Notably, in the OAI 5G RAN, the O-CU is further divided into a Control Plane (O-CUCP) and a User Plane (O-CU-UP), linked by an E1 interface. In contrast, Option 7.2, introduced by the O-RAN Alliance, focuses on ensuring interoperability between the O-DU and O-RU through the Open Fronthaul Interface (OFI).
1) O-CU: The O-CU-CP and O-CU-UP functional stacks are deployed on the same host as the 5GC. Unlike monolithic deployments, CU deployment involves the configuration of one or more nodes that connect to the 5GC. The connection is validated through AMF logs in the Open5GS console, which show control plane activity such as successful CU attachment, including CU instance count, IP addresses, and N2 interface status via the GTP protocol. For the connection between the O-CU and O-DU, we use 10-Gb SFI/SFP+ Network Interfaces.

The CU-CP's functional configuration consists of multiple parameter blocks, each dedicated to a specific function within the CU-CP node. These functions manage control plane operations, including resource allocation, connection establishment and release, and mobility management. Mobility management ensures uninterrupted service as the UE moves, handling handovers (HO), location updates, and transitions between tracking areas (TACs). CU-CP also handles connections between RAN and AMF. From a specification view, the AMF IP address is specified as `cu cp:amf:addr` in srsRAN and `amf ip address` in OAI. To ensure proper binding to the N2 interface, a local IP address is defined: `cu cp amf:bind addr` in srsRAN and `GNB IPv4 ADDRESS FOR NG AMF` in OAI. For F1-C communication between the CU and DUs, srsRAN uses `flap bind addr`, whereas OAI uses `local s address`. The CU-UP manages the connectivity between the RAN and the UPF, specifying the UPF's IP address and a network device for binding to the N3 interface. It also manages the NR User Plane (NRU) traffic for F1-U connections between the CU-UP and DUs. In srsRAN, the parameter `nru:bind addr` specifies the bind IP address for the NRU instance in the CU-UP node, while in OAI, the user plane uses the same IP address as its control plane node.

2) O-DU: The DU functional stack is deployed on the same physical host previously used for the monolithic RAN deployment. This deployment is entirely separate from the CU 5GC host server. It is responsible for managing cells, including configuring the number of antennas for both downlink and uplink transmissions. It also handles the assignment of TACs and bandwidth setups.

**Bandwidth:** The configuration of downlink and uplink bandwidth in the OAI 5G RAN differs from that in srsRAN. In OAI, the bandwidth: `dl carrier Bandwidth` and `ul carrier Bandwidth` are defined in terms of resource blocks (RBs), whereas srsRAN streamlines bandwidth configuration by specifying it in MHz with `channel bandwidth MHz`. We set in both cases a bandwidth up-to 60 MHz, corresponding to 162 RBs.

**Synchronization Signal Block (SSB) allocation:** To establish initial access and manage mobility, the UE initiates the cell search procedure to achieve time and frequency synchronization with a cell. During this phase, the UE utilizes the Primary Synchronization Signal (PSS), Secondary Synchronization Signal (SSS), and Physical Broadcast Channel (PBCH), all of which are included in the SSB. SSBs are transmitted periodically, and their frequency impacts resource utilization.

A higher density of SSBs facilitates quicker synchronization and enhances mobility performance but also uses up more resources, thereby reducing the available bandwidth for data transmission. Thus, strategic planning of SSB placement is crucial. In the case study using OAI, the positioning of the SSB within the specified bandwidth and operating band must be explicitly defined. Conversely, srsRAN provides automatic SSB positioning, although it allows for specifying a particular position within HO configuration. The SSB's position is determined by the frequency offset between the PBCH block and a reference point (Point A), which is the center of the lowest RB. The first step involves setting the `dl absolute Frequency Point A` parameter, which is expressed as the Absolute Radio Frequency Channel Number (ARFCN) for the lowest RB. In our scenario, this value is 660084, corresponding to a frequency of 3901.260 MHz. Following this, the absolute frequency of the SSB is calculated to determine its position within the allocated bandwidth. This value is the ARFCN, corresponds to the Global Synchronization Channel (GSCN), adhering to the NR frequency raster specifications outlined in [9]. The calculated ARFCN of the SSB is 663360, which correspond to 3950.400 MHz.

### III. EVALUATIONS AND RESULTS

Evaluating the performance of software-defined radio (SDR)-based cellular networks involves a statistical analysis of key performance indicators (KPIs). These KPIs offer a comprehensive measure of the efficiency, scalability, and reliability of both monolithic and disaggregated architectures. The chosen metrics shed light on various dimensions of network performance, encompassing user experience and infrastructure efficiency. In this paper, for downlink performance, we select backhaul, midhaul, fronthaul, and E2E bitrate, along with packet loss, jitter, CPU usage, and disk I/O, as key metrics to comprehensively evaluate user-plane performance and pinpoint potential bottlenecks in both architectures.

Separately analyzing the fronthaul, midhaul, and backhaul bitrates is essential for gaining a deeper understanding of network performance across distinct segments. By definition, fronthaul refers to the link between the DU and the RU, backhaul links the CU to the 5GC, and midhaul is particularly relevant in disaggregated architecture, refers to the link between the CU and the DU in a splitted gNB. Throughout the E2E *iperf3* test, we monitor the interfaces using the Linux network statistics tool *ifstat* to capture and report results, while employing real-time bandwidth monitoring tools *bmon* and *nload* to verify the findings.

In addition to individual measurements, metrics such as E2E bitrate, jitter, and packet-loss ratio collectively indicate the overall performance of the entire RAN system. E2E bitrate quantifies the total data transfer rate between the UE and the UPF, serving as an indicator of the RAN and core networks data-handling efficiency. E2E jitter assesses the variation in packet delay, a critical factor for real-time applications such as voice and video communication, where excessive jitter can degrade the quality of experience (QoE) and diminish
user satisfaction. E2E packet-loss ratio, which measures the percentage of packets lost between transmission and reception, is vital for ensuring reliability in low-latency applications like Voice over IP (VoIP) and video streaming. These metrics can all be effectively gathered using the iperf3 tool.

We also monitor hardware utilization during the tests for both architectures, focusing primarily on CPU and hard disk usage. For these two architectures, we evaluate CPU utilization and disk I/O in distinct ways: in the monolithic architecture, we measure these metrics on the gNB, where all components run on a single machine, while in the disaggregated architecture, we monitor them on the DU. Specifically, both metrics can be obtained in the psutil library, and with the command `disk_io.write_bytes` to capture disk I/O in bytes.

Through the analysis of these KPIs, our objective is to deliver a clear and fair performance comparison between the srsRAN and the OAI 5G RAN, considering both monolithic and disaggregated (3GPP Split Option 2) architectures. In the subsequent subsections, we will detail the step-by-step test execution process and present the resulting test outcomes.

## A. Step-by-Step test execution

The test setup is configured with varying bandwidths, a transmission center frequency of 3950.4 MHz, 92.16 sampling rate, and a MIMO configuration featuring two transmitters and two receivers (2Tx2Rx). Initially, after configuring the parameters, we generated traffic at a high bitrate. However, we observed lower-than-expected air interface bitrate and E2E throughput. This prompted an in-depth debugging process to pinpoint the root causes of the performance degradation. Additionally, we noted significant fluctuations in the maximum observed throughput, coupled with substantial packet loss.

The following three calibration steps [10] are applied on the RU (USRP x310) to address the low bitrate issue:

* USRP Tx calibration: This step minimizes TX IQ imbalance (noise) versus the LO frequency.

* USRP Rx calibration: This step focuses on minimizing RX In-Phase Quadrature (IQ) imbalance relative to the Local Oscillator (LO) frequency.

* USRP Tx calibration for Tx Direct Current (DC) Offset: This step minimizes TX DC offset relative to the LO frequency.

Before initiating the formal statistical evaluation tests, we conducted preliminary assessments using various bitrate values to determine the achievable bitrate. We employed iperf3 to transmit UDP packets at incrementally increasing speeds, starting at 100 Mbps and progressing to 150 Mbps, 200 Mbps, 280 Mbps, and ultimately 300 Mbps. This process enabled us to find out the throughput capacity of our testbed.

To perform a statistical evaluation of throughput performance, we generated traffic at a consistent rate of 300 Mbps from the UPF to the UE. Each test scenario was repeated 30 times with identical configurations to ensure strong statistical reliability. In total, we conducted 120 individual tests for four configurations: srsRAN monolithic, OAI monolithic, srsRAN disaggregated and OAI disaggregated. This structured

<figure><img src="image_4.png" /><figcaption>Fig. 2: CDF of bitrate for monolithic deployments of srsRAN and OAI</figcaption></figure>

approach allowed us to effectively capture performance variations, yielding a robust dataset for comparative analysis. To ensure consistency and eliminate residual effects between test runs, we rebooted the servers after each test.

## B. Test Results Analysis

In this subsection, following the comprehensive evaluation, we analyze the collected data to derive significant insights into the performance of various network configurations, facilitating a comparison of the DL transmission performance of two RAN architectures implemented on srsRAN and OAI, respectively. To ensure a fair comparison, we evaluated both the average and maximum bitrate for each test, alongside other metrics detailed in the preceding subsection. Since each test was conducted 30 times, the results are depicted as a Cumulative Distribution Function (CDF) curve consisting of 30 data points, providing an intuitive representation of the probability distribution of the observed values.

Overall, it can be observed that OAI exhibited a lower E2E bitrate than srsRAN across both monolithic and disaggregated architectures, potentially attributable to a recurring [RLC] SDU rejected, SDU buffer full error. We are currently engaging with the developers to obtain further clarification and details.

It can also be observed that the backhaul bitrate distributions for both implementations appear nearly identical. The fronthaul throughput is much higher because of the FPGA processing bandwidth. This is particularly important for the IQ data transmission between the gNB and RU/USRP, which requires high data rates. As illustrated in Fig. 2, the fronthaul bitrate on both platforms reaches levels in the Gbps range, which is explained in [11] and [12].

The CDF of bitrate values for the split architecture deployments of srsRAN and OAI is presented in Fig. 3, where the midhaul, backhaul, and fronthaul bitrate values exhibit tight clustering. This indicates that, in a split deployment, these segments deliver consistent transport capacity with minimal variability. A notable observation is that the E2E bitrate for OAI is lower than that for srsRAN. However, the midhaul throughput for both OAI and srsRAN is nearly identical,
<figure><img src="image_5.png" /><figcaption>Fig. 3: CDF of bitrate for split architecture deployments of srsRAN and OAI.</figcaption></figure>

<figure><img src="image_6.png" /><figcaption>Fig. 4: CDF of achievable Max E2E bitrate for monolithic and disaggregated deployments of srsRAN and OAI.</figcaption></figure>

suggesting that both protocol stacks encounter comparable constraints within this segment. Additionally, srsRANs front-haul bitrate appears slightly higher than OAI. Furthermore, this test enables an analysis of the performance implications of disaggregating the gNB into distinct functional units. The tight clustering of midhaul and backhaul bitrate values indicates that these segments do not constitute bottlenecks in this model.

Fig. 4 presents the CDF of the maximum achievable E2E bitrate for both monolithic and disaggregated deployments using srsRAN and OAI, respectively. It is evident that across both implementations, srsRAN consistently achieves a high and stable bitrate, whereas OAI exhibits significant variability across a wide range. This observation confirmed our earlier hypothesis that OAI’s transmission performance is substantially constrained by the recurring ‘buffer full’ error. Additionally, when comparing the two architectures on the same platform, the monolithic configuration slightly outperforms the disaggregated architecture.

The CDF of CPU usage for the monolithic (gNB) and disaggregated (DU) implementations of srsRAN and OAI is given in Fig. 5. It can be observed that across the two platforms, both architectures implemented on OAI exhibit lower CPU usage compared to their srsRAN counterparts. Specifically, the CPU usage for both the OAI gNB and OAI DU shows a distribution tightly concentrated within the 7 to

<figure><img src="image_7.png" /><figcaption>Fig. 5: CDF of CPU usage comparison between monolithic (gNB) and disaggregated (DU) implementations of srsRAN and OAI.</figcaption></figure>

<figure><img src="image_8.png" /><figcaption>Fig. 6: CDF of packet loss ratio for comparing the monolithic and disaggregated implementations of srsRAN and OAI.</figcaption></figure>

8% range. In contrast, the srsRAN gNB and srsRAN DU demand higher CPU utilization, with values distributed across a wider range, extending beyond 10%. Furthermore, when comparing the two architectures within each platform, the disaggregated DU deployments for both srsRAN and OAI demonstrate lower CPU usage than their monolithic gNB counterparts. This suggests that the CU-DU split enhances network flexibility by offloading certain processing tasks to the DU, thereby reducing the overall CPU usage burden and potentially improving the computational efficiency of resource allocation in disaggregated architectures.

The CDF of packet loss percentages for all four test scenarios is given in Fig. 6. As previously discussed, OAI exhibits an exceptionally high packet loss ratio, primarily attributable to the recurring ‘buffer full’ error. For srsRAN, both the monolithic and disaggregated implementations display closely aligned loss levels, indicating that disaggregation does not significantly contribute to additional packet loss. In contrast, for OAI, the disaggregated implementation demonstrates a slight improvement in performance compared to its monolithic counterpart, although loss rates remain elevated. This suggests that OAI’s packet loss is not exclusively a consequence of its monolithic architecture but may also stem from inefficiencies within its protocol stack or transport mechanisms.
<figure><img src="image_9.png" /><figcaption>Fig. 7: CDF of disk write counter values for comparing the monolithic and disaggregated implementations of srsRAN and OAI.</figcaption></figure>

<figure><img src="image_10.png" /><figcaption>Fig. 8: CDF of E2E jitter for comparing the monolithic and disaggregated implementations of srsRAN and OAI.</figcaption></figure>

Fig. 7 shows the CDF of disk write performance (in bytes) derived from the test results. During this evaluation, logging was enabled in OAI, resulting in elevated disk write activity compared to srsRAN, where logging was disabled. In a separate test with logging disabled for both platforms, the disk write performance of the OAI monolithic architecture was nearly identical to that of the srsRAN monolithic architecture. The primary difference between the two frameworks lies in the magnitude of disk writes: OAIs monolithic and disaggregated architectures generate substantially higher disk write volumes, suggesting a greater dependence on disk storage for various processing tasks. In contrast, srsRAN exhibits a significantly lower disk write footprint, indicative of more efficient memory and disk management strategies. The CDF curve for srsRAN is tightly clustered, reflecting consistent disk write values across test iterations, whereas OAI displays a wider distribution, highlighting greater variability in disk write intensity.

The CDF of E2E Jitter in four tests are illustrated in Fig. 8, where a clear performance gap between OAI and srsRAN in terms of average jitter can be observed for both architectures. OAI exhibits significantly higher jitter values, meaning its packet arrival times fluctuate more. In contrast, srsRAN maintains lower jitter, suggesting more consistent network timing.

## IV. CONCLUSION

In this paper, we conducted an empirical evaluation of the DL transmission performance of two O-RAN architectures, leveraging a SA testbed implemented on the widely utilized open-source platforms srsRAN and OAI. By systematically comparing the disaggregated O-RAN architecture with its monolithic counterpart, we discussed the critical question of whether the enhanced flexibility and adaptability of O-RAN come at the cost of performance relative to traditional designs. Our comprehensive analysis, grounded in carefully selected key performance metrics revealed nuanced insights into the efficiency, scalability, and implemented measures to provide solid statistical results and eliminate residual effects between test iterations. Test results show that the split enhances network flexibility by offloading certain processing tasks to the DU, thereby reducing the overall hardware usage burden and potentially improving the computational efficiency and resource allocation in future RAN networks. For future work, we aim to extend our investigation by evaluating the UL transmission performance of the disaggregated O-RAN architecture, while proposing and validating solutions to enhance transmission efficiency for both UL and DL directions, with a particular focus on optimizing the near-real-time control module.

## ACKNOWLEDGMENTS

This work was funded by the IPCEI ME/CT (DOS0239248) and the ANR HEIDIS (ANR-21-CE25-0019) projects.

## REFERENCES

[1] M. Polese, L. Bonati, S. Doro, S. Basagni, and T. Melodia, "Understanding o-ran: Architecture, interfaces, algorithms, security, and research challenges," *IEEE Communications Surveys Tutorials*, vol. 25, no. 2, pp. 1376-1411, 2023.

[2] "Srsran project documentation," https://docs.srsran.com/projects/project/en/latest/, accessed: 2025-02-18.

[3] "Openairinterface 5g documentation," https://gitlab.eurecom.fr/oai/openairinterface5g/-/tree/develop/doc, accessed: 2025-02-18.

[4] M. Amini and C. Rosenberg, "Performance analysis and comparison of full-fledged 5g standalone experimental tdd testbeds in single multi-ue scenarios," 2024. [Online]. Available: https://arxiv.org/abs/2407.02341

[5] M. Amini, A. El-Ashmawy, C. Rosenberg, and A. K. Khandani, "5g diy: Impact of different elements on the performance of an e2e 5g standalone testbed," in *GLOBECOM 2023 - 2023 IEEE Global Communications Conference*, 2023, pp. 6377-6382.

[6] M. Amini and C. Rosenberg, "A comparative analysis of open-source software in an e2e 5g standalone platform," in *2024 IEEE Wireless Communications and Networking Conference (WCNC)*, 2024, pp. 1-6.

[7] L. Mamushiane, A. Lysko, H. Kobo, and J. Mwangama, "Deploying a stable 5g sa testbed using srsran and open5gs: Ue integration and troubleshooting towards network slicing," in *2023 International Conference on Artificial Intelligence, Big Data, Computing and Data Communication Systems (icABCD)*, 2023, pp. 1-10.

[8] S. Raffeck, S. G. Grsvik, S. Lange, T. Hossfeld, T. Zinner, and S. Geissler, "Parameterizing 5g new radio: A comparative measurement study on throughput and delay," in *2024 20th International Conference on Network and Service Management (CNSM)*, 2024, pp. 1-7.

[9] "Base Station (BS) radio transmission and reception," 3GPP, Technical Report TS 38.104, 2020.

[10] "Usrp hardware driver and usrp manual version: 4.8.0.0," https://files.ettus.com/manual/page Calibra tion.html, accessed: 2025-02-18.

[11] "About usrp bandwidths and sampling rates," https://kb.ettus.com/About_USRP_Bandwidths_and_Sampling_Rates, accessed: 2025-02-18.

[12] L. M. P. Larsen, A. Checko, and H. L. Christiansen, "A survey of the functional splits proposed for 5g mobile crosshaul networks," *IEEE Communications Surveys Tutorials*, vol. 21, no. 1, pp. 146-172, 2019.