Interoperability Assessment of Fronthaul and E2 Interfaces for Multi-Vendor Open RAN Systems

Interoperability Assessment of Fronthaul and E2 Interfaces for Multi-Vendor Open RAN Systems Farhad Mehran, Charles Turyagyenda, and Dritan Kaleshi

arXiv:2611.01862v1 [cs.NI] 1 Nov 2026

Digital Catapult London, UK {farhad.mehran, charles.turyagyenda, dritan.kaleshi}@digicatapult.org.uk

Abstract—Open Radio Access Networks (RANs) aim to transform the existing wireless network architectures by adopting open interfaces, disaggregating and virtualising RAN components, and enabling dynamic control of the system via data-driven methods. To accelerate the development of interoperable RAN solutions, rigorous assessment of Open Fronthaul and E2 interfaces based on O-RAN Alliance Interoperability Testing (IOT) specifications plays a key role as the integration of these interfaces seems to be very challenging, e.g. due to the need for alignment of Fronthaul IOT profiles and unforeseen challenges for E2 interface integration as Near-Real-Time RAN Intelligent Controller (Near-RT RIC) is relatively a new component introduced within the RAN architecture. In this paper, selected parts of the latest findings and lessons learned from interoperability assessment of Open Fronthaul and E2 interfaces for 13 multi-vendor Open RAN systems deployed in SmartRAN Open Network Interoperability Centre (SONIC) Labs are presented. Index Terms—5G, Open Fronthaul, Open RAN, O-RAN, RAN intelligent controller.

I. I NTRODUCTION Open Radio Access Network (RAN) has emerged as an architectural overhaul for the future wireless cellular networks to create a competitive ecosystem with a diverse range of RAN products [1]. This transformative evolution allows to mix-and-match innovative solutions, prevents vendor lock-in, and enables data-driven intelligent RAN operation. Still, Open RAN paradigm inevitably impose new challenges that did not exist in traditional monolithic systems. More specifically, one of the key architectural principles of Open RAN is openness for the interfaces that are interconnecting the constituent components of the disaggregated RAN. O-RAN Alliance defines the specifications for the Open RAN architecture, interfaces, and interoperability test cases between the pairs of RAN components. Fig. 1 shows the interfaces for Open RAN as defined by its embodiment in O-RAN specifications [2]. This architecture embraces the 3GPP functional split 7.2 [3], and disaggregates the RAN functions into O-RAN Central Unit (O-CU), Distributed Unit (O-DU), and Radio Unit (O-RU). Among the O-RAN interfaces, integration and interoperability validation of Open Fronthaul (FH) interface attracted strong interest due to the fact that the O-RU not only accounts for significant portion of CAPEX/OPEX for Mobile Network Operators (MNOs) but it also plays a key role in determining This work was supported by the Department for Science, Innovation and Technology (DSIT).

Fig. 1. O-RAN architecture [2]: RAN components are interconnected via O-RAN interfaces (solid lines) and 3GPP interfaces (dashed lines).

the overall performance of the network, e.g. by changing the MIMO configurations to scale the throughput performance or improve the coverage at the cell edge. Integration of Open Fronthaul interface is a challenging task, particularly for multi-vendor cases, due the need for alignment of several configuration parameters within the IOT profiles of the O-RU and O-DU, e.g. for delay management, IQ compression, etc. Also, within the O-RAN architecture, Near-Real-Time RAN Intelligent Controller (Near-RT RIC) is a core component as it empowers network optimisations and in this regard, E2 interface is the key interface that connects the O-DU/O-CU to the Near-RT RIC. The data-driven applications hosted within Near-RT RIC receive Key Performance Measurements (KPMs) from the O-DU/O-CU over the E2 interface, use them in pretrained models, and send back control actions to the O-DU/OCU. Hence, to ensure the correct operation of the Near-RT RIC (and functionality of its applications), it is essential to assess the interoperability of the E2 Nodes with respect to O-RAN standard specifications. However, for enabling interoperability over multi-vendor E2 interfaces, the readiness of the E2 interfaces for the existing O-RAN products has not yet reached the state of maturity. This is one of the major bottlenecks that currently does not allow to unleash the full potential of RIC-enabled use cases. This is due to several factors, namely lack of maturity in O-RAN standard specifications, proprietary elements within different vendors’ implementations, and lack of clarity about E2 design requirements as Near-RT RIC is relatively new component within RAN domain.

Authors’ accepted version. Published by VDE VERLAG in the proceedings of European Wireless 2025, pp. 91–96. Published version: https://ieeexplore.ieee.org/document/11442741.

To assess the reality of Open RAN technologies, validate maturity of products, and accelerate the developments needed for enabling plug-and-play solutions, various integration and testing centres around the globe serve as commercially neutral testbeds for conducting experimental evaluations and providing impartial assessment for the level of openness and interoperability that the Open RAN products have. In this regard, up to now, SmartRAN Open Network Interoperability Centre (SONIC Labs) led the collaborative integration and interoperability testing for 47 Open RAN systems (created from products of 21 vendors) on its commercially neutral multi-tenancy open network testbed [4]. Although Open RAN ecosystem has made significant progress towards defining test specifications and methodologies for performance validations, there is a notable gap in available literature about the technical findings, lessons learned, and analysis of observations as a result of conducting interoperability assessments between pairs of Open RAN products. To fill this gap, in [5], we presented the key findings from the interoperability and E2E performance evaluations of 34 Open RAN systems deployed in SONIC Labs, e.g. lessons learned on interoperability issues for KPM verification and reporting on E2 interface, alignment of FlexRAN implementations to successfully integrate Open Fronthaul interface, etc. In this paper, we share parts of the new findings and lessons learned as a result of conducting interoperability assessment of 13 Open RAN systems that were recently integrated in SONIC Labs and were not covered in our previous work [5]. In particular, we will, • Provide the results and breakdown of test cases that were selected and designed according to O-RAN Alliance specifications for assessing interoperability of Open Fronthaul and E2 interfaces, • Present guidelines for designing delay management profiles for O-RU and O-DU to enable successful integration and interoperability over Open Fronthaul interface, and • Share insights on E2 interface validations, e.g. verification of nested Information Elements (IEs) within IOT testing procedures and its impact on the overall interoperability between the pairs of RAN components. II. S YSTEM S ETUP I N SONIC L ABS This section describes the high-level architecture and the test setups for the Open RAN systems deployed on SONIC Labs testbed. Fig. 2 illustrates the hardware infrastructure for an instance of Open RAN system, which was composed of Dell R750 servers for deploying O-DU, O-CU, Near-RT RIC, and 5G Core (5GC) solutions, Dell switches to interconnect the Open RAN components, and also shielded box that hosts the O-RU and the commercial UE. For all of the systems, the O-RU was operating in 5G NR n77 band with 100 MHz bandwidth and configured as 4x4 MIMO. For the Open Fronthaul interoperability testing, the System-Under-Test (SUT) was composed of O-DU and O-RU. For the interoperability assessment of E2 interface, the SUT was composed of O-DU and Near-RT RIC, and also O-CU and Near RT-RIC.

Fig. 2. High-level architecture for an instance of Open RAN system deployed in SONIC Labs.

III. I NTEROPERABILITY A SSESSMENT: C HALLENGES AND L ESSONS L EARNED A. Open Fronthaul Interface Table I presents a summary of the results of interoperability assessment for the Open Fronthaul interface of two Open RAN systems. The set of test cases was designed according to the O-RAN IOT test specifications within Work Group 4 (WG4) [6]. This includes the assessment of interoperability and functionality of Open Fronthaul interface for Control and User Planes (CU-Planes) and Synchronisation Plane (S-Plane). Validation of Management Plane (M-Plane) was not part of the system integration for these systems. Interoperability Assessment for CU-Planes: the O-RAN functional split 7.2x has stringent delay requirements for Fronthaul interface. To integrate the CU-Planes, it is essential to ensure that the transmission and reception windows at the O-DU are aligned with the delay characteristics of transport network and O-RU. For this alignment, the delay management model as defined in O-RAN WG4 Control, User and Synchronisation Plane (CUS) specification [7] is used. The focus of this paper is on DL transmissions, and the related delay model that defines the reference points for input and output of the equipment for Open Fronthaul interface and the related timing relations are shown in Fig. 3. Here, T2a , T1a , and T12 define the delay from receive interface at O-RU (R2) to antenna interface at O-RU (Ra), delay from transmit interface at O-DU (R1) to Ra, and DL transport delay, respectively. The reference point for delay management (tDL = 0) is when the earliest IQ sample is transmitted from antenna interface and therefore, the transmission and reception windows are defined relative to Ra and relations are worked out backward in timeline. For the CU-Planes transmissions, the transmission window at the O-DU is defined by T1amax and T1amin that denote the earliest and latest transmission from the O-DU, respectively, and has the size

TABLE I O PEN F RONTHAUL I NTEROPERABILITY VALIDATIONS FOR TWO OPEN RAN SYSTEMS . Test Case 2.2.2.1

Functionality S-Plane

2.2.2.3

S-Plane

2.2.2.8

S-Plane

2.2.2.10

S-Plane

2.2.3.1

CU-Planes

2.2.3.2

CU-Planes

2.2.3.3

CU-Planes

2.2.4.5

CU-Planes

O-RAN Test Specification O-RAN.WG4.IOT.0-R004v12.00 [6] O-RAN.WG4.IOT.0-R004v12.00 [6] O-RAN.WG4.IOT.0-R004v12.00 [6] O-RAN.WG4.IOT.0-R004v12.00 [6] O-RAN.WG4.IOT.0-R004v12.00 [6] O-RAN.WG4.IOT.0-R004v12.00 [6] O-RAN.WG4.IOT.0-R004v12.00 [6] O-RAN.WG4.IOT.0-R004v12.00 [6]

Test Case Description Functional test of O-DU + O-RU using ITU-T G.8275.1 profile (LLS-C1) Functional test of O-DU + bridged network + O-RU using ITU-T G.8275.1 profile (LLS-C3) Performance test of O-DU + Two O-RUs using ITUT G.8275.1 profile (LLS-C1) Performance test of O-DU + bridged network + Two O-RUs using ITU-T G.8275.1 profile (LLS-C3) Radio Layer 3 C-Plane establishment and Initial Radio U-Plane data transfer Radio U-Plane downlink data transfer (Downlink throughput performance) Radio U-Plane uplink data transfer (Uplink throughput performance) Delay Management #3, normal fronthaul latency

Open RAN #1 N/A

Open RAN #2 Pass

Pass

N/A

N/A

Pass

Pass

N/A

Pass

Pass

Pass

Pass

Pass

Pass

Pass

Pass

of Wt = (T1amax − T1amin ). Also, the reception window is specified by the T2amax and T2amin that denote the earliest and latest reception at the O-RU, respectively, which has the size of Wr = (T2amax − T2amin ) . Hence, the delay relationships for U-Plane DL transmission are given by [7] ( T1amax ,up ≤ (T2amax ,up + T12 min ) (1) T1amin ,up ≥ (T2amin ,up + T12 max ) and for the C-Plane, it follows ( T1amax ,cp ≤ (T2amax ,cp + T12 min ) T1amin ,cp ≥ (T2amin ,cp + T12 max )

(2)

where subscripts up and cp present U-Plane and C-Plane timing parameters, respectively. From (1) and (2), the transmission/reception windows for U-Plane and C-Plane are denoted by Wt,up /Wr,up and Wt,cp /Wr,cp , respectively. To attain the information required for the O-DU to align the transmission window with the O-RU’s reception window and transport network delay variations, O-RAN specifications [7] introduced methods which are primarily relying on predefining and measuring the timing parameters. For this work, the O-DU timing parameters were configured based on predefined values (according to O-RU delay profile information) and without relying on Open FH M-Plane. Fig. 4 presents examples of Delay Management Profiles (DMPs) configured and used within distinct Open Fronthaul interfaces that were successfully integrated for Open RAN systems. From this figure, the following observations can be made: (i) Design of Transmission (Wt ) and Reception (Wr ) Window Size: for all the three cases, Wr > Wt holds for both C-Plane and U-Plane, as inequalities (1) and (2) imply that the reception window size is configured to be equal or larger than the transmission window size and the potential variations of delay in transport network. Here, for DMP #1, having Wr,up > 4 · Wt,up and Wr,cp > 4 · Wt,cp (i.e. Wr,up , Wr,cp = 241 µs and Wt,up , Wt,cp = 51 µs) provides high flexibility for where within the specified window the

Fig. 3. Delay management model for the O-RU and O-DU for DL transmissions: (a) reference points, (b) timing relations (taken from [7], [8]).

O-DU may commence the transmission, while limiting the reception window to 2 · Wt,up > Wr,up as in the DMP #2 (with Wr,up = 140 µs and Wt,up = 80 µs) provides smaller margins and flexibility. (ii) Flexibility for Configuring Individual Delay Parameters: for the DL transmission, the O-DU shall transmit the messages early and late enough to ensure the messages are received at the O-RU within the designed Wr , e.g. for DMP #1, the O-DU shall transmit U-Plane messages before T1amin ,up = 294 µs to ensure the message is received at the O-RU before T2amin ,up = 134 µ s. Also, while the packets are transmitted

Fig. 4. Delay Management Profiles (DMPs) on Open Fronthaul for DL transmissions: Timing parameters for (a) U-Plane and (b) C-Plane; and size of transmission and reception windows for (c) U-Plane and (d) C-Plane.

late enough at the O-DU (i.e. after T1amax ,up = 345 µs) to ensure they are received within the designed Wr,up , T2amax ,up can be configured in a way to relax the starting point of reception window of the O-RU and enlarge the Wr,up , e.g. for all the three systems, the O-DU sets T2amax ,up > T1amax ,up to allow flexibility for processing early packets at the ORU, and also helps with smooth interoperability testing, but it comes at the expense of addition processing cycles and increased buffer size that need to be optimised for efficient operation of network in real deployments. While increasing T2amax ,up allows to enlarge Wr,up and resulting in flexibility for early packets, the size of Wr,up can not be further increased via relaxing T2amin ,up for late packets, as O-RU inherently requires some time for generation of time domain IQ samples that starts from the reception of packets at the O-RU input point R2 and the transmission of the IQ samples from the antenna at Ra. (iii) Coordination of Timing Between C-Plane and UPlane: for processing U-Plane messages, the corresponding CPlane messages shall be available. Thus, O-RAN specifications [7] define the timing advance, Tcp adv dl , which specifies the amount of time that C-Plane messages shall arrive at the O-RU in advance of the latest possible time the first corresponding U-Plane messages may arrive, e.g. for DMP #1, the timing advance was set to Tcp adv dl = 125 µ s, with T1amax ,cp = 470 µ s and T1amax ,up = 345 µs configured, hence T1amax ,cp ≥ T1amax ,up + Tcp adv dl holds and as a result, this configuration allowed sufficiently early transmission of C-Plane packets at the O-DU. Also, as T2amax ,cp = 500 µs and T2amax ,up = 375 µ s were set, T2amax ,cp ≥ T2amax ,up +Tcp adv dl holds and therefore, the defined values allowed sufficiently early reception of C-Plane packets for the corresponding U-Plane packets at the O-RU. Also, for managing the delay between the C-Plane and U-Plane, it can be observed that for all the three systems, Wt,cp ≥ Wt,up holds with T1amax ,cp > T1amax ,up , allowing transmission of C-Plane packets earlier than the U-Plane packets. Still, not all systems were fully aligned with delay management model requirements specified in O-RAN CUSPlanes specifications [7], as in the case of DMP #3, the implementation was based on giving priority to sending packets as soon as possible at the O-DU, hence focusing more on tuning T1amax ,cp and T1amax ,up rather than T1amin ,cp and T1amin ,up . Hence, with Tcp adv dl = 0 µs, the integration and interoperability assessment for this implementation was successful over ideal Fronthaul transport network. (iv) Deployment Requirements: considering the design of transmission and reception windows, while DMP #2 allowed the maximum transport delay to be T12 max = 40 µs, DMP #1 accommodated a more flexible transport delay variations within [0, 160] µs that supports deployments that require less stringent requirements for delay variations of Fronthaul transport network. Interoperability over S-Plane: O-RAN WG4 [7] defines the topologies for supporting O-RU synchronisation needs, including the Lower-Layer Split (LLS) Configuration 1 (LLS-

C1) in which O-DU directly synchronises the O-RU, and LLSC3 that O-RU is synchronised via the Fronthaul network that distributes the network timing towards the O-RU and O-DU. The selection of synchronisation topology depends on various design factors, and is primarily specified by the deployment needs. For the deployment of Open RAN systems at SONIC Labs, as shown in Table I, LLS-C1 and LLS-C3 were used and when one of these configurations were used for one system, the other configuration was not deployed and therefore the related IOT test cases were not applicable. B. E2 Interface Interoperability Verifications for E2 Interface: Table II presents a summary of the results of IOT assessment for two systems. The test cases cover validations of two E2 Application Protocol (E2AP) modules: (i) Global Procedures, e.g. E2 Setup procedure that verifies the exchange of basic configuration parameters between the E2 Nodes and Near-RT RIC, and (ii) RIC Functional Procedures, such as RIC Subscription procedure, RIC Delete procedure, and RIC Indication procedure (e.g. to report KPM(s) per subscription request). Backward Compatibility of E2SM-KPM Specifications: for the integration of E2 interface, the verifications began with assessment of Global Procedures. Initially, the E2 Setup Request sent from the E2 Nodes were not decodable at the Near-RT RIC as the implementation of the O-DU and O-CU for E2SM-KPM were based on E2SM-KPM v1 specification [9], while the implementation of Near-RT RIC from another vendor was based on E2SM-KPM v2.02 [10]. It was found that these specifications for the E2SM-KPM were not backward compatible and therefore, the E2 Setup procedure was only successfully established after new E2 Agent instances were provided for implementation of O-DU and O-CU network functions to support E2SM-KPM v2.03 [11], while the NearRT RIC implementation of E2SM-KPM v2.02 was upgraded based on a new KPI monitoring (KPIMON) application. Alignment of Network Function Implementations According to O-RAN Specifications: the assessment of successful E2 integration and proper interoperability via this interface is not limited to verification of individual signalling procedures between the E2 Nodes and Near-RT RIC, and it also requires to examine whether the messages are decoded correctly or not to ensure the defined functions are operating as expected. In some cases, these verifications are not straightforward due the complexity of data relationships within Information Elements (IEs), such as complex structure of nested IEs which are IEs that consist of other IEs inside them, e.g. following the establishment of communication over E2 interface in previous example, it was observed that the E2 Node was reporting incorrect 5G NR Cell Identity (NCI) to the Near-RT RIC. After conducting the root-cause analysis within the nested IEs (as illustrated in Fig. 5), it was found that E2 Agent within the E2 Node was hardcoding the F1 setup information [12], including the NR Cell Group ID (CGI) which was conveyed within the E2 Node Component Configuration IE of E2 Setup Request message from the E2 Nodes. Here, NCI was specified

Fig. 5. Signalling flow between E2 Nodes and Near-RT RIC for E2 Setup and RIC Subscription procedures. Nested IEs need to be validated within IOT procedures to ensure correct interoperability between the RAN nodes.

within NR CGI IE which was incorrect value conveyed to the Near-RT RIC as part of this message exchange and could finally causing errors in messaging between E2 Nodes and Near-RT RIC. This was resolved by altering the E2 Agent implementation within the E2 Nodes to dynamically process the NR CGI information. Although the E2 Setup procedure was successful, the E2 Agent within the E2 Nodes was not correctly decoding the RIC Subscription Request coming from the Near-RT RIC. After analysing the messages, it was found that the NearRT RIC was using incorrect NCI (ffffffff0) within the RIC Subscription Request message instead of using the correct NCI (000d41f70). As shown in Fig. 5, this value was specified within RIC Action Definition IE, which provides additional information for the nominated Report [11]. This observation showed that the KPIMON was not reading the real NCI

TABLE II E2 I NTEROPERABILITY VALIDATIONS ( FOR BOTH O-DU AND O-CU) FOR THE TWO OPEN RAN SYSTEMS . Test Case 7.2.2.1.1

Functionality E2 on O-DU

O-RAN Test Specification O-RAN.WG3.E2TS-R003v02.00 [13]

7.2.2.1.1

E2 on O-CU

O-RAN.WG3.E2TS-R003v02.00 [13]

7.2.2.5.1

E2 on O-DU

7.2.2.5.1

E2 on O-CU

7.24

E2 on O-DU

7.24∗

E2 on O-CU

7.25

E2 on O-DU

7.25∗

E2 on O-CU

7.27

E2 on O-DU

7.27∗

E2 on O-CU

O-RAN.WG3.E2TS-R003v02.00 [13] O-RAN.WG3.E2TS-R003v02.00 [13] O-RAN.WG8.IOT.0-R004v12.00 [14] O-RAN.WG8.IOT.0-R004v12.00 [14] O-RAN.WG8.IOT.0-R004v12.00 [14] O-RAN.WG8.IOT.0-R004v12.00 [14] O-RAN.WG8.IOT.0-R004v12.00 [14] O-RAN.WG8.IOT.0-R004v12.00 [14]

Test Case Description For the O-DU, RIC Subscription and RIC Indication procedures with REPORT Service Style 1, Single Action Format Type 1, Indication Message Format Type 1 For the O-CU, RIC Subscription and RIC Indication procedures with REPORT Service Style 1, Single Action Format Type 1, Indication Message Format Type 1 For the O-DU, RIC Subscription Delete procedure with RIC Event Trigger Style 1 For the O-CU, RIC Subscription Delete procedure with RIC Event Trigger Style 1 Verify O-DU successfully establish E2 Interface with near RT-RIC Verify O-CU successfully establish E2 Interface with near RT-RIC Verify near RT-RIC server sends subscription request with type as REPORT to O-DU Verify near RT-RIC server sends subscription request with type as REPORT to O-CU Verify O-DU sends periodic report to the subscribed features to near RT-RIC server Verify O-CU sends periodic report to the subscribed features to near RT-RIC server

Open RAN #1 N/A

Open RAN #2 Pass

N/A

Pass

N/A

Pass

N/A

Pass

Pass

Pass

Pass

Pass

Pass

Pass

Pass

Pass

Pass

Pass

Pass

Pass

* Developed based on this test case that was originally developed for O-DU within O-RAN specifications [14].

conveyed within the latest E2 Setup Request message, rather it was using hardcoded NCI within the Near-RT RIC software instance. Following the upgrade of software implementation, the RIC Subscription procedure was successfully verified. These two examples were not the only cases in which NF implementations for Open RAN components (e.g. E2 Agent) were upgraded as a result of observations from conducting IOT verifications, and similar issues can be found in different domains of interoperability assessment. For example, although the Near-RT RIC was successfully decoding the E2 Setup Request message sent from both O-DU and O-CU, the E2 Manager within the Near-RT RIC was responding the E2 Setup Response message according to its hardcoded Global gNB ID and gNB-DU ID values instead of the identities of the connected E2 Nodes. Following an upgrade of E2 Manager implementation to fetch the E2 IDs from the E2 Setup Request message, the E2 Setup procedure was successful. Through these examples, it was shown that the successful verification of one IOT test case and validation of the related procedures does not necessarily translates into successful interoperability between the pairs of components, and it requires further analysis within IE data structures. This is particularly crucial with respect to design implementation of E2 Agent (within E2 Nodes) and E2 Manager (for the Near-RT RIC). IV. C ONCLUDING R EMARKS Open RAN is now deemed to be a dominant architectural framework for the future mobile radio networks and therefore, the interoperability assessment of Open RAN solutions in commercially neutral testbeds becomes increasingly important. In this paper, we shared insights about the lessons learned from the interoperability assessment of Open Fronthaul and E2 interfaces within Open RAN systems that were integrated

in SONIC Labs. We are extending the analysis of the experimental evaluation results, and we plan to publish further results and key findings in the future. R EFERENCES [1] M. Wani, M. Kretschmer, B. Schroder, A. Grebe, and M. Rademacher, “Open RAN: A Concise Overview,” IEEE Open J. Commun. Soc., vol. 6, pp. 13-28, Jul. 2024. [2] O-RAN Working Group 1, “RAN Work Group 1 (Use Cases and Overall Architecture): O-RAN Architecture Description,” ORAN.WG1.TS.OAD-R004-v13.00 Technical Specification, Feb. 2025. [3] Technical Specification Group Radio Access Network; Study on New Radio Access Technology: Radio Access Architecture and Interfaces, V14.0.0, 3GPP Standard TR 38.801, Mar. 2017. [4] SONIC Labs, The Programme. Accessed: May 2025. [Online]. Available: https://www.digicatapult.org.uk/expertise/programmes/programme/ sonic-labs/the-programme [5] F. Mehran, C. Turyagyenda, and D. Kaleshi, “Experimental Evaluation of Multi-Vendor 5G Open RANs: Promises, Challenges, and Lessons Learned,” IEEE Access, vol. 12, pp. 152241-152261, Oct. 2024. [6] O-RAN WG4, “O-RAN Fronthaul Working Group: Fronthaul Interoperability Test Specification (IOT),” O-RAN.WG4.IOT.0-R004-v12.00, Oct. 2024. [7] O-RAN WG4, “O-RAN Working Group 4 (Open Fronthaul Interfaces WG): Control, User and Synchronization Plane Specification,” ORAN.WG4.TS.CUS.0-R004-v17.01, Feb. 2025. [8] eCPRI Specification V1.0: “Common Public Radio Interface: eCPRI Interface Specification”. [9] O-RAN WG3,“Near-Real-Time RAN Intelligent Controller E2 Service Model (E2SM) KPM,” ORAN-WG3.E2SM-KPM-v01.00, Feb.2020. [10] O-RAN WG3,“Near-Real-Time RAN Intelligent Controller E2 Service Model (E2SM) KPM, ” O-RAN.O-RAN.WG3.E2SM-KPM-v02.02, Jul. 2022. [11] O-RAN WG3, “Near-Real-Time RAN Intelligent Controller E2 Service Model (E2SM) KPM,” O-RAN.WG3.E2SM-KPM-v02.03, Oct. 2022. [12] O-RAN WG3,“Near-Real-Time RAN Intelligent Controller, E2 Application Protocol (E2AP),” O-RAN.WG3.TS.E2AP-R004-v07.00, Feb. 2025. [13] O-RAN WG3, “O-RAN WG3: E2 Interface Test Specification,” ORAN.WG3.E2TS-R003-v02.00, Mar. 2023. [14] O-RAN WG8, “O-RAN Working Group 8 (Stack Reference Design): Stack Interoperability Test Specification,” O-RAN.WG8.IOT.0-R004v12.00, Feb. 2025.

Related documents

• A Comprehensive Tutorial and Survey of O-RAN: Exploring Slicing-Aware Architecture, Deployment Options, Use Cases, and Challenges#1379688
• Cross-Layer Optimization and System-Level Design of Next-Generation Wireless Networks via Intelligent RAN Control#423889
• Enabling Real-Time Programmability for RAN Functions: A Wasm-Based Approach for Isolated and Deterministic dApps#1232679
• Energy Consumption in Next Generation Radio Access Networks#1343578
• An O-RAN-Assisted MARL Approach for Dynamic Sidelink and Infrastructure Selection in V2X Communications#463191