pith. sign in

arxiv: 2606.20568 · v1 · pith:YEM2RRYWnew · submitted 2026-04-21 · 💻 cs.NI · cs.DC· cs.ET

Handling Interoperability Issues in 6G ORAN: Lessons Learned from Research Lab-based Integrations

Poonam Yadav , Yifan Liu , Mohit Bidikar , Rana M. Sohaib , Yi Chu , David Grace This is my paper

Pith reviewed 2026-07-05 06:09 UTC · model glm-5.2

classification 💻 cs.NI cs.DCcs.ET
keywords ORANE2 interfaceinteroperability6GASN.1RICopen RANmulti-vendor
0
0 comments X

The pith

Lab tests expose ORAN's E2 interface as a barrier to multi-vendor 6G

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

This paper reports hands-on integration experiments testing the E2 interface — the critical link between the RAN Intelligent Controller (RIC) and radio network nodes — across three vendor combinations: commercial-to-open-source, fully open-source, and fully commercial. The central finding is that the E2 interface, despite being designed to enable vendor-neutral interoperability, actively obstructs it. The authors identify specific failure mechanisms including ASN.1 message encoding mismatches between vendors, limited Key Performance Measurement (KPM) report style support, latency-induced SCTP heartbeat instability, and the inability to debug closed-source commercial components. In the fully commercial pairing, the E2 interface could not even be established due to protocol-level encoding incompatibility, and the failure remained unresolved due to lack of source code access. In contrast, open-source pairings allowed code-level fixes within hours. Based on these concrete failures, the authors argue that the E2 interface's reliance on rigid ASN.1 encoding and static service models is the root cause, and they propose transitioning to an API-driven control plane using gRPC or REST to eliminate decoding dependencies and enable dynamic capability discovery.

Core claim

The paper's central discovery is that ORAN's E2 interface fails to deliver vendor-neutral interoperability in practice due to three systemic mechanisms: (1) vendor-specific interpretations of ASN.1 encoding specifications that cause message decoding failures at the protocol level, (2) inconsistent adoption of service model versions and report styles that limit functional capability, and (3) latency sensitivity in SCTP heartbeat handling that destabilizes connections in multi-server deployments. The commercial-to-commercial integration failed completely at the E2 setup stage and could not be resolved without vendor intervention, while open-source integrations were fixed in 1-2 hours through源码

What carries the argument

The E2 interface is the central object — the standardized protocol link between the Near-RT RIC and E2 nodes (CU/DU). It uses ASN.1 encoding for messages and supports service models like E2SM-KPM (Key Performance Measurement) and E2SM-RC (RAN Control). The RIC Intelligent Controller (RIC) manages xApps (microservices) that monitor RAN state and issue control commands via E2. The paper identifies ASN.1 encoding rigidity, static service models, and SCTP heartbeat latency as the three load-bearing failure mechanisms.

If this is right

  • Telecom operators deploying multi-vendor ORAN for 6G should expect significant integration delays and may need to maintain single-vendor relationships as a fallback, undermining ORAN's vendor-neutral promise.
  • The O-RAN Alliance specifications may need tighter conformance testing requirements, particularly for ASN.1 encoding format selection, to prevent the kind of vendor-specific interpretation gaps documented here.
  • Open-source ORAN stacks (like srsRAN and OSC RIC) may become de facto reference implementations for interoperability testing, as their transparency allows rapid diagnosis of protocol mismatches that closed-source vendors cannot independently resolve.
  • The proposed shift to API-driven control planes (gRPC/REST) could lower the barrier to entry for new RAN vendors, as standard web-service tooling would replace specialized ASN.1 expertise.
  • Security protocol variations between vendors, if left unstandardized, could create exploitable interface boundaries in multi-vendor 6G deployments where trust assumptions differ across components.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • If API-driven interfaces (gRPC/REST) replace E2, they would need to meet sub-millisecond latency budgets currently handled by SCTP-based E2AP — a non-trivial constraint that web-service protocols are not typically engineered for in real-time control loops.
  • The vendor-specific encoding mismatches observed here suggest the O-RAN specification itself may contain ambiguities or underspecified areas that allow multiple valid interpretations, meaning the problem may be fixable through specification clarification rather than wholesale architectural replacement.
  • The latency-induced dissociation issue observed in multi-server deployments may compound significantly at network scale, potentially requiring hardware-level timestamp synchronization (e.g., PTP) that goes beyond the software-level fixes applied in the lab.

Load-bearing premise

The paper assumes that the integration failures observed across three lab setups reflect systemic interoperability problems in ORAN's E2 interface, and that replacing E2 with API-driven architectures (gRPC/REST) would inherently avoid the same vendor-specific interpretation issues — a claim that remains untested.

What would settle it

If a broader survey of ORAN deployments found that E2 integration failures are rare and resolved through standard conformance testing, or if API-driven control planes exhibited equivalent vendor-specific interpretation mismatches, the paper's central proposal would be undermined.

Figures

Figures reproduced from arXiv: 2606.20568 by David Grace, Mohit Bidikar, Poonam Yadav, Rana M. Sohaib, Yi Chu, Yifan Liu.

Figure 1
Figure 1. Figure 1: E2 node interaction workflow with Near-RT RIC. [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 3
Figure 3. Figure 3: Setup 1 – Commercial E2 Node from Vendor A with [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figure 5
Figure 5. Figure 5: Setup 3: Commercial E2 Node from Vendor A with [PITH_FULL_IMAGE:figures/full_fig_p004_5.png] view at source ↗
Figure 4
Figure 4. Figure 4: Setup 2 - srsRAN with OSC RIC [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
read the original abstract

As 6G networks continue to evolve, the Open Radio Access Network (ORAN) framework is gaining prominence for its promise of network flexibility, vendor-neutral architecture, and enhanced service delivery. However, achieving true interoperability across diverse hardware and software components from multiple vendors remains a critical challenge. This research focuses on identifying and addressing interoperability issues within 6G ORAN environments, leveraging insights from research lab-based integrations. By systematically analysing lab-based case studies, the study aims to uncover the root causes of integration failures, propose solutions to ensure smooth multi-vendor compatibility, and establish a set of best practices for future deployments. This work will contribute to developing robust guidelines for 6G ORAN ecosystems, accelerating seamless and scalable deployments in real-world networks.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 7 minor

Summary. This manuscript reports on hands-on integration experiences across three ORAN E2 interface setups: (1) a commercial E2 node with the open-source OSC RIC, (2) srsRAN with the OSC RIC, and (3) a commercial E2 node with a commercial RIC. The authors document specific interoperability failures, including ASN.1 encoding mismatches in KPM IndicationHeader formats, limited KPM report style support, SCTP heartbeat latency sensitivity, and debugging limitations in closed-source commercial components. Based on these observations, the paper proposes transitioning from the ASN.1-based E2 interface to API-driven architectures (gRPC/REST) for future 6G deployments.

Significance. The paper provides concrete, reproducible evidence for ORAN E2 interoperability challenges, including specific code modifications (Listing 1) and log traces that substantiate the encoding mismatch claims. The structured root cause analysis methodology (Section III.D) and the comparison table between open-source and proprietary debugging capabilities (Table III) are valuable practical contributions for the network integration community. The documentation of specific failure modes, such as the IndicationHeader-Format1 vs. generic IndicationHeader mismatch, offers actionable insights for ORAN implementers.

major comments (3)
  1. Section V claims that API-driven interfaces (gRPC/REST) would 'effectively eliminate many of the issues exposed in this study.' However, the specific failure documented in Setup 1 (Section III.A) was a semantic mismatch: Vendor A used the generic IndicationHeader while OSC RIC expected IndicationHeader-Format1. This is a disagreement about which message variant to use, not a limitation of ASN.1 as a serialization format. The same class of mismatch would occur with protobuf (e.g., one side sending a generic KpmIndicationHeader message while the other expects KpmIndicationHeaderFormat1). The paper does not explain how gRPC/REST would resolve this specific class of semantic disagreement. The claim should be substantiated or scoped to the specific issues that API-driven architectures would actually resolve (e.g., schema discovery, tooling).
  2. Section IV.B: The latency-induced dissociation issue was caused by SCTP heartbeat timing and was resolved by co-locating the E2 node and RIC on the same server. This is a transport/deployment issue, not an artifact of E2's ASN.1 encoding or service model architecture. Section V lists this issue among those that an API-driven control plane would eliminate, but gRPC/REST would face analogous latency sensitivity in multi-server deployments. The paper should clarify which of the documented issues are genuinely tied to E2's architecture versus general distributed systems challenges that would persist regardless of interface technology.
  3. Section III.C (Setup 3): The commercial-to-commercial integration failure is described as an 'encoding mismatch' that prevented E2 Setup Request/Response completion, but no technical detail is provided. Unlike Setup 1, where specific ASN.1 field values and code modifications are documented, Setup 3 offers no log traces, Wireshark captures, or specification references. This setup is a key data point supporting the paper's argument about commercial interoperability barriers, and the lack of technical detail weakens the empirical contribution. At minimum, the nature of the encoding mismatch (e.g., which E2AP IE failed) should be specified.
minor comments (7)
  1. Section III.D, step (b): 'errrors' should be 'errors'.
  2. Section III.D, step (c): 'Discrepency' should be 'Discrepancy'.
  3. Section V: The bullet list contains duplicate entries. 'Simplifying debugging, versioning, and backward compatibility through mature cloud-native DevOps tools and continuous integration workflows' and 'Simplifying debugging, versioning, and backward compatibility through mature cloud-native tools' are near-identical. Similarly, 'Allowing seamless integration with AI-native and intent-based management systems' appears twice. These should be consolidated.
  4. Section III states 'We describe four key experiment setups,' but only three setups (A, B, C) are described. Either a fourth setup is missing or the count should be corrected.
  5. Table III, 'Root Cause Depth' row: 'proprietary often inclusive without vendor input' is unclear. Consider revising to 'proprietary often inconclusive without vendor input.'
  6. Section V claims APIs are 'self-describing.' This conflates schema discovery with semantic agreement. OpenAPI/protobuf schemas describe field structure but do not resolve which variant a vendor chooses to send. This distinction should be clarified.
  7. Section V claims APIs would enable 'dynamic capability discovery' but does not address why E2AP's existing E2 Setup procedure (which already exchanges service model capabilities) fails to achieve the same goal. A brief comparison would strengthen the argument.

Simulated Author's Rebuttal

3 responses · 1 unresolved

We thank the referee for a careful and constructive review. The referee correctly identifies that our Section V claim about API-driven interfaces is overbroad in two respects: (1) the semantic mismatch in Setup 1 (IndicationHeader variant disagreement) would persist under any serialization format, and (2) the SCTP latency issue in Setup 2 is a transport/deployment problem, not specific to ASN.1 or E2's service model architecture. We also acknowledge that Setup 3 lacks the technical detail (log traces, specific IE identification) that would make it a strong empirical data point. We will revise the manuscript to scope the API-driven proposal to the specific issues it genuinely addresses (schema discovery, tooling, debugging transparency, dynamic capability negotiation) and will add all available technical detail for Setup 3, subject to vendor NDA constraints.

read point-by-point responses

  1. Referee: Section V claims that API-driven interfaces (gRPC/REST) would 'effectively eliminate many of the issues exposed in this study.' However, the specific failure documented in Setup 1 was a semantic mismatch: Vendor A used the generic IndicationHeader while OSC RIC expected IndicationHeader-Format1. This is a disagreement about which message variant to use, not a limitation of ASN.1 as a serialization format. The same class of mismatch would occur with protobuf. The paper does not explain how gRPC/REST would resolve this specific class of semantic disagreement.

    Authors: The referee is correct. The Setup 1 failure was a semantic disagreement about which message variant to use, not a limitation of ASN.1 as a serialization format. An analogous mismatch (one side sending a generic KpmIndicationHeader while the other expects KpmIndicationHeaderFormat1) would indeed occur with protobuf. We concede that our Section V claim is overbroad as currently written. However, we believe API-driven architectures do offer genuine advantages for a *subset* of the issues we documented—specifically: (a) dynamic capability discovery via self-describing schemas and reflection APIs, which would make variant disagreements detectable at connection time rather than at decode-failure time; (b) mature tooling ecosystems (protobuf compilers, gRPC reflection, schema registries) that simplify debugging and versioning; and (c) improved transparency through standardized introspection mechanisms. We will revise Section V to explicitly scope the claim: the semantic mismatch class of problem would persist under any serialization format, but API-driven architectures could improve *detection and diagnosis* of such mismatches through dynamic schema discovery and reflection, which the current E2 framework lacks. We will remove or qualify the blanket statement that API-driven interfaces would 'effectively eliminate many of the issues exposed in this study.' revision: yes

  2. Referee: Section IV.B: The latency-induced dissociation issue was caused by SCTP heartbeat timing and was resolved by co-locating the E2 node and RIC on the same server. This is a transport/deployment issue, not an artifact of E2's ASN.1 encoding or service model architecture. Section V lists this issue among those that an API-driven control plane would eliminate, but gRPC/REST would face analogous latency sensitivity in multi-server deployments.

    Authors: The referee is correct. The SCTP heartbeat timing issue is a transport-layer and deployment-configuration problem, not an artifact of E2's ASN.1 encoding or service model architecture. gRPC/REST would face analogous latency sensitivity in multi-server deployments. We will revise Section V to explicitly separate the documented issues into two categories: (1) issues genuinely tied to E2's architecture (ASN.1 decoding dependencies, static service model definitions, limited capability negotiation) versus (2) general distributed systems challenges that would persist regardless of interface technology (latency sensitivity, multi-node scalability, security protocol variations). The latency issue will be reclassified into category (2), and we will clarify that API-driven architectures do not claim to resolve transport-layer or deployment-level challenges. revision: yes

  3. Referee: Section III.C (Setup 3): The commercial-to-commercial integration failure is described as an 'encoding mismatch' that prevented E2 Setup Request/Response completion, but no technical detail is provided. Unlike Setup 1, where specific ASN.1 field values and code modifications are documented, Setup 3 offers no log traces, Wireshark captures, or specification references. This setup is a key data point supporting the paper's argument about commercial interoperability barriers, and the lack of technical detail weakens the empirical contribution. At minimum, the nature of the encoding mismatch (e.g., which E2AP IE failed) should be specified.

    Authors: The referee is correct that Setup 3 lacks the technical specificity that would strengthen its empirical contribution. We will add available technical detail to the revised manuscript. However, we must be transparent about a genuine constraint: the commercial vendor agreements (NDAs) under which Vendor A and Vendor B provided their equipment restrict the level of detail we can publicly disclose about internal protocol handling and specific IE-level failures. We can and will add the following: (a) the specific E2AP procedure stage at which the failure occurred (E2 Setup Request/Response exchange), (b) the Wireshark-discoverable symptoms (SCTP association established but E2AP setup procedure timeout), and (c) the general category of the mismatch (encoding of E2AP protocol IEs in the Setup Request message, as observable from the RIC-side rejection logs). We cannot provide the full Wireshark captures or vendor-internal log traces due to the NDA restrictions. We will add a note in the manuscript explicitly acknowledging this limitation and explaining that the restricted detail is itself a manifestation of the debugging transparency problem documented in Section IV.E and Table III. This constraint is a standing limitation we cannot fully resolve. revision: partial

standing simulated objections not resolved
  • Setup 3 technical detail is constrained by vendor NDA agreements. We can add the externally observable symptoms and the general category of the encoding mismatch, but we cannot publish full Wireshark captures or vendor-internal logs that would provide the IE-level specificity the referee (rightly) identifies as ideal. This limitation is itself part of the paper's argument about commercial debugging barriers, but we acknowledge it weakens the empirical contribution of Setup 3.

Circularity Check

0 steps flagged

No circularity found: empirical integration study with no formal derivation chain

full rationale

This paper is an empirical study documenting hands-on ORAN E2 integration failures across three lab setups and proposing future directions. There is no formal derivation chain, no fitted parameters, no uniqueness theorem, and no mathematical predictions that could be circular by construction. The findings (encoding mismatches, latency-induced dissociation, limited KPM report style support) are direct observations from experiments, not derived results. The proposal in Section V to explore API-driven interfaces (gRPC/REST) is a suggestion for future work, not a derived prediction. Self-citations are minimal and non-load-bearing: the paper cites external work by Mehran et al. [2], Hö schele et al. [3], and others for context, with no self-citation chain supporting a central claim. The architectural recommendation in Section V is not formally derived from the experimental results—it is a qualitative proposal. While the skeptic may question whether API-driven interfaces would actually resolve the observed semantic mismatches (a correctness concern), this is not a circularity issue. The paper's claims are based on direct observation, and its proposals are suggestions rather than derived results. No step in the paper reduces to its inputs by construction.

Axiom & Free-Parameter Ledger

0 free parameters · 3 axioms · 0 invented entities

The paper is an empirical systems study with no mathematical derivations or invented physical entities. The axioms are domain assumptions about ORAN standards and the representativeness of lab setups.

axioms (3)
  • domain assumption O-RAN specifications (E2SM-KPM v04.00) are the correct standard against which interoperability should be measured.
    Invoked throughout Section III.A and III.D to identify encoding mismatches and discrepancies.
  • domain assumption The lab-based integration setups are representative of real-world ORAN deployment challenges.
    Stated implicitly in the Introduction and Section III; the paper generalizes lab findings to propose best practices and architectural changes.
  • ad hoc to paper API-driven architectures (gRPC, REST) inherently provide better interoperability than ASN.1-based E2 interfaces.
    Invoked in Section V to justify the proposed future direction; this is asserted without empirical validation in the paper.

pith-pipeline@v1.1.0-glm · 11102 in / 1921 out tokens · 765243 ms · 2026-07-05T06:09:49.196485+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

18 extracted references · 18 canonical work pages

  1. [1]

    O-ran: Towards an open and smart ran, 2020

    O-RAN Alliance. O-ran: Towards an open and smart ran, 2020. [Online]. Available: https://www.o-ran.org/. Accessed: July, 2025

    work page 2020

  2. [2]

    Experimental evaluation of multi-vendor 5g open rans: Promises, challenges, and lessons learned.IEEE Access, 2024

    Farhad Mehran, Charles Turyagyenda, and Dritan Kaleshi. Experimental evaluation of multi-vendor 5g open rans: Promises, challenges, and lessons learned.IEEE Access, 2024

    work page 2024

  3. [3]

    5g interoperability of open ran components in large testbed ecosystem: Towards 6g flexibility

    Thomas H ¨oschele, Florian Kaltenberger, Andreas Ingo Grohmann, Elif Tasdemir, Martin Reisslein, and Frank HP Fitzek. 5g interoperability of open ran components in large testbed ecosystem: Towards 6g flexibility. InEuropean Wireless 2022; 27th European Wireless Conference, pages 1–6. VDE, 2022

    work page 2022

  4. [4]

    Evolving open ran interoperability: A large-scale definition

    Aziz Kord, Jason B Coder, and Vu Le. Evolving open ran interoperability: A large-scale definition. In2024 IEEE International Conference on Communications Workshops (ICC Workshops), pages 2095–2100. IEEE, 2024

    work page 2095

  5. [5]

    5g-ct: Automated deployment and over-the-air testing of end-to-end open radio access networks.IEEE Communications Magazine, 2024

    Leonardo Bonati, Michele Polese, Salvatore D’Oro, Pietro Brach del Prever, and Tommaso Melodia. 5g-ct: Automated deployment and over-the-air testing of end-to-end open radio access networks.IEEE Communications Magazine, 2024

    work page 2024

  6. [6]

    X5g: An open, programmable, multi-vendor, end-to-end, private 5g o-ran testbed with nvidia arc and openairinterface.arXiv preprint arXiv:2406.15935, 2024

    Davide Villa, Imran Khan, Florian Kaltenberger, Nicholas Hedberg, Ruben Soares da Silva, Stefano Maxenti, Leonardo Bonati, Anupa Kelkar, Chris Dick, Eduardo Baena, et al. X5g: An open, programmable, multi-vendor, end-to-end, private 5g o-ran testbed with nvidia arc and openairinterface.arXiv preprint arXiv:2406.15935, 2024

    work page arXiv 2024

  7. [7]

    Open ai cellular (oaic): An open source 5g o-ran testbed for design and testing of ai-based ran management algorithms.IEEE Network, 37(5):7–15, 2023

    Pratheek S Upadhyaya, Nishith Tripathi, Joseph Gaeddert, and Jeffrey H Reed. Open ai cellular (oaic): An open source 5g o-ran testbed for design and testing of ai-based ran management algorithms.IEEE Network, 37(5):7–15, 2023

    work page 2023

  8. [8]

    Open6g otic: A blueprint for programmable o-ran and 3gpp testing infrastructure

    Gabriele Gemmi, Michele Polese, Pedram Johari, Stefano Maxenti, Michael Seltser, and Tommaso Melodia. Open6g otic: A blueprint for programmable o-ran and 3gpp testing infrastructure. In2024 IEEE 100th Vehicular Technology Conference (VTC2024-Fall), pages 1–5. IEEE, 2024

    work page 2024

  9. [9]

    Ara-o-ran: End-to-end programmable o-ran living lab for agriculture and rural communities

    Tianyi Zhang, Joshua Ofori Boateng, Taimoor UI Islam, Arsalan Ahmad, Hongwei Zhang, and Daji Qiao. Ara-o-ran: End-to-end programmable o-ran living lab for agriculture and rural communities. InIEEE INFO- COM 2024-IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), pages 1–6. IEEE, 2024

    work page 2024

  10. [10]

    Campus5g: A campus scale private 5g open ran testbed.arXiv preprint arXiv:2506.23740, 2025

    Andrew E Ferguson, Ujjwal Pawar, Tianxin Wang, and Mahesh K Marina. Campus5g: A campus scale private 5g open ran testbed.arXiv preprint arXiv:2506.23740, 2025

    work page arXiv 2025

  11. [11]

    Colosseum: The open ran digital twin.IEEE Open Journal of the Communications Society, 5:5452–5466, 2024

    Michele Polese, Leonardo Bonati, Salvatore D’Oro, Pedram Johari, Davide Villa, Sakthivel Velumani, Rajeev Gangula, Maria Tsampazi, Clifton Paul Robinson, Gabriele Gemmi, et al. Colosseum: The open ran digital twin.IEEE Open Journal of the Communications Society, 5:5452–5466, 2024

    work page 2024

  12. [12]

    Michele Polese, Leonardo Bonati, Salvatore D’Oro, Stefano Basagni, and Tommaso Melodia. Colo-ran: Developing machine learning-based xapps for open ran closed-loop control on programmable experimental platforms.IEEE Transactions on Mobile Computing, 22(10):5787–5800, 2023

    work page 2023

  13. [13]

    Nexran: Closed-loop ran slicing in powder-a top-to-bottom open-source open- ran use case

    David Johnson, Dustin Maas, and Jacobus Van Der Merwe. Nexran: Closed-loop ran slicing in powder-a top-to-bottom open-source open- ran use case. InProceedings of the 15th ACM Workshop on Wireless Network Testbeds, Experimental evaluation & CHaracterization, pages 17–23, 2022

    work page 2022

  14. [14]

    Interoperability testing tool for operations and main- tenance interfaces of 5g open ran base station

    Wan-Chien Yang. Interoperability testing tool for operations and main- tenance interfaces of 5g open ran base station. In2022 23rd Asia-Pacific Network Operations and Management Symposium (APNOMS), pages 1–

    work page

  15. [15]

    Understanding o-ran: Architecture, interfaces, algorithms, security, and research challenges.IEEE Communications Surveys & Tutorials, 25(2):1376–1411, 2023

    Michele Polese, Leonardo Bonati, Salvatore D’Oro, Stefano Basagni, and Tommaso Melodia. Understanding o-ran: Architecture, interfaces, algorithms, security, and research challenges.IEEE Communications Surveys & Tutorials, 25(2):1376–1411, 2023

    work page 2023

  16. [16]

    Toward integrating intelligence and programmability in open radio access networks: A comprehensive survey.IEEE Access, 10:67747–67770, 2022

    Azadeh Arnaz, Justin Lipman, Mehran Abolhasan, and Matti Hiltunen. Toward integrating intelligence and programmability in open radio access networks: A comprehensive survey.IEEE Access, 10:67747–67770, 2022

    work page 2022

  17. [17]

    Open ran test and integration.Open RAN: The Definitive Guide, pages 172–190, 2023

    Ian Wong. Open ran test and integration.Open RAN: The Definitive Guide, pages 172–190, 2023

    work page 2023

  18. [18]

    Ed. R. Stewart. Stream control transmission protocol, 2007. Accessed: 2024-10-22

    work page 2007