A Survey on Open Radio Access Networks: Challenges, Research Directions, and Open Source Approaches

• Open RAN is proposed as an evolution of vRAN that opens the RAN ecosystem’s previously closed nature.The stated aims include cost reduction through vendor competition and intelligent components that support energy savings and dynamic power management.Source: §1 · p. 1
• Earlier references covered parts of Open RAN’s history, projects, or O-RAN architecture, but not its full history, present condition, and future opportunities.Source: §1 · pp. 1–2
• The survey reviews Open RAN’s landscape, technologies, projects, activities, standards, architecture, challenges, research directions, and open-source approaches.It emphasizes Open RAN’s evolution from vRAN and uses O-RAN Alliance standards and architecture as a reference.Source: §1 · p. 2

2.1. Traditional RAN or D-RAN

• D-RAN integrates the RU and BBU near each base station, allowing straightforward independent operation without a high-speed interface between them.As UE numbers grow, network densification requires more base stations.Source: §2.1 · p. 2

2.2. C-RAN

• C-RAN pools BBUs and connects the pool to RRUs over fronthaul, reducing space and cooling costs but requiring high bandwidth and low latency.Cloud RAN places pooled BBUs in a cloud server; the survey attributes further energy, throughput, scalability, CapEx, and OpEx benefits to that cloud control.Source: §2.2 · pp. 2–3
• C-RAN’s fronthaul overhead, trust and security problems, and single-point failure concerns motivated a shift toward virtualization and edge computing.Source: §2.2 · p. 3

2. Evolution from Traditional RAN to vRAN

• vRAN separates network resources into virtual instances on cloud servers, enabling orchestration and scaling, but resource sharing and proprietary interfaces retain complexity and vendor lock-in.The survey reports that virtualization can reduce required Cloud RAN data-processing resources by approximately 50%.Source: §2.3 · p. 3

3.1. Open RAN Movement

• Open RAN is described as an evolution of vRAN centered on disaggregation and interoperability, with open interfaces and vendor-independent hardware and software.The movement is intended to support a multivendor environment and use of general-purpose processors.Source: §3 · pp. 3–4, §3.1 · pp. 4–5
• The monolithic RAN struggles to meet diverse 5G QoS requirements, while proprietary interfaces hinder interconnection and vendor dependence constrains operator control over innovation.The section also identifies the need to combine NFV with AI for network management and orchestration.Source: §3.1 · p. 4
• Disaggregation is presented as a route to flexible QoS handling, while softwarization and open interfaces support interoperability and faster software development and deployment.The section describes continuous integration and continuous deployment as software-development approaches that can reduce time to market and deployment time.Source: §3.1 · pp. 4–5
• Rakuten’s nationwide Open RAN deployment is reported as the first commercial-scale network using Open RAN standards and architecture, with approximately 40% lower 4G CapEx and 30% lower OpEx than traditional RAN.The passage also reports savings of up to 50% for Rakuten’s 5G deployment.Source: §3.1 · p. 5

3.2. Technologies Related to Open RAN

• The section introduces disaggregation and functional splits alongside virtualization, NFV, network slicing, and cloudification as technologies supporting Open RAN.Horizontal splits separate CU and DU or DU and RU, while vertical splits separate control and user planes; cloud choices include public, private, and hybrid deployments, with trade-offs.Source: §3.2 · pp. 6–7
• Automation and AI/ML support RAN management through RIC control loops, with RT RIC operating below 10 ms, Near-RT RIC from 10 ms to 1 s, and Non-RT RIC typically at 1 s or more.Near-RT RIC supports AI-enabled optimization and feedback for UEs and cells; Non-RT RIC releases AI-enabled service policies and runs RAN-wide analytics.Source: §3.2 · p. 8
• Open-source software is described as a major solution for RAN software infrastructure, although these solutions remain in early deployments.The section also identifies MEC research directions including resource management, network-slicing integration, and MEC-embedded RIC.Source: §3.2 · pp. 8–9
• Reports associate Open RAN-related technologies with an average TCO reduction of 20% compared with 4G; savings may surpass 20% when 5G integrates advanced technologies.C-RAN adoption saved 25% compared with D-RAN, with future savings predicted to reach up to 45%. Backhaul costs increased by 55% in some higher Open RAN deployments, but may rise by less in some lower deployments.Source: §3.2 · pp. 9–10

4.1. Projects and Activities

• O-RAN-related efforts include OAI and srsRAN software, TIP OpenRAN, ONAP, SD-RAN, and research testbeds, with differing purposes and standards alignment.The projects passage distinguishes related projects from O-RAN Alliance standards; TIP OpenRAN is closed source, while OAI, srsRAN, ONAP, and SD-RAN are described as open-source efforts.Source: §4 · p. 10, §4.1 · pp. 13–14
• O-RAN Alliance, shortened to O-RAN, is a software community name rather than another short form of Open RAN.The Alliance was formed by five mobile network operators to promote an open and intelligent RAN.Source: §4.1 · p. 10
• O-RAN Alliance’s openness and intelligence principles are pursued through standardization, virtualization, and white-box designs, organized across ten work groups and six focus groups.Its Technical Steering Committee guides and approves specifications; the MVP Committee coordinates priorities and communicates the roadmap.Source: §4.1 · pp. 10–11
• The O-RAN Alliance and OSC work in a recurring loop: specifications are checked and tested, discrepancies and recommendations inform release planning, and OSC produces software releases every six months.OSC aligns its software reference implementation with O-RAN architecture and specifications and also collaborates with other open-source communities.Source: §4.1 · pp. 11–12

4.2. 5G, 3GPP, and Open RAN

• 3GPP’s 5G specifications leave some open-interface details unclear or optional, while O-RAN adds functions and interfaces and retains the need to comply with 3GPP specifications.The paper says O-RAN’s more detailed specifications matter in multivendor environments; Open RAN principles also apply across 2G–5G, although current O-RAN standardization focuses on 5G.Source: §4.2 · pp. 15–16

5. O-RAN Alliance Architecture

• The O-RAN Alliance architecture is supported by OSC, which makes it possible to see how standards are implemented in open-source software.Source: §5 · p. 16
• The architecture comprises eight main parts: SMO, Non-RT RIC, Near-RT RIC, O-CU, O-DU, O-RU, O-eNB, and O-Cloud.Figure 9 shows their interconnections; the reference architecture is intended as a standardized reference system alongside other parties’ architectures.Source: §5 · pp. 16–17, Figure 9 · p. 17
• The reference architecture is described as a foundation for making RAN open, virtualized, and AI-embedded.The paper says it enables next-generation RAN infrastructures.Source: §5 · p. 17

5.1. SMO

• SMO provides FCAPS support, Non-RT RIC, and O-Cloud management, orchestration, and workflow management.Its framework includes the Non-RT RIC and A1, O1, O2, and open FH M-Plane interfaces.Source: §5.1 · p. 17
• O1 supports FCAPS for O-RAN network functions, O2 supports O-Cloud management and orchestration, and open FH M-Plane provides SMO FCAPS functionality to the O-RU.Source: §5.1 · p. 18
• Non-RT RIC supports non-real-time intelligent RAN optimization and intelligent RRM, facilitating Near-RT RIC operation through A1 policies, enrichment information, and ML model management.Its rApps perform RAN optimization, while the framework hosts data management and AI/ML workflow functions.Source: §5.1 · p. 18
• OAM uses O1 to manage O-RAN building blocks and O2 to manage O-Cloud, supporting service provisioning and measurement-data collection for Non-RT RIC optimization.Management can be flat, hierarchical, or hybrid; the SMO standard is still under development.Source: §5.1 · pp. 18–19

5.2. Near-RT RIC

• Near-RT RIC receives policies from Non-RT RIC over A1 and collects data from and acts on E2 nodes to adjust RAN parameters.O1 enables FCAPS from the SMO to Near-RT RIC.Source: §5.2 · p. 19
• The Near-RT RIC platform supports xApps with data storage, subscription management, conflict mitigation, security, lifecycle management, and messaging.Source: §5.2 · p. 19
• Third-party xApps provide specific RAN functions for E2 nodes, including data analysis and control, and are used to enhance O-RAN RRM capabilities.They may be implemented through multiple microservices.Source: §5.2 · p. 20
• An OSC F-release demonstration used E2 to modify RAN parameters and showed report and indication services.The passage also lists eight available xApps and a new HW-Rust xApp in the H release.Source: §5.2 · p. 20

5.3. O-CU

• The O-CU hosts RRC, SDAP, and PDCP functions, divided between O-CU-CP (RRC and PDCP control plane) and O-CU-UP (SDAP and PDCP user plane).Figure 13 presents the O-CU architecture.Source: §5.3 · p. 20, Figure 13 · p. 20
• The O-CU also has E2, O1, X2, and Xn interfaces; X2 and Xn link it to other base stations, with O-RAN interoperability profiles added to their 3GPP specifications.The passage lists the F1, NG, X2, and Xn interfaces as having control and user variants.Source: §5.3 · p. 20
• E1 bridges O-CU-CP and O-CU-UP, while F1 connects the O-CU to the O-DU and NG connects it to the 5GC.The O-RAN Alliance reuses the 3GPP E1 specification.Source: §5.3 · p. 20

5.4. O-DU

• The O-DU hosts RLC, MAC, and high-physical-layer functions, with O-DU high handling L2 and O-DU low handling L1; FAPI links the two parts.The O-DU also handles baseband processing such as segmentation, scheduling, and multiplexing.Source: §5.4 · p. 20, Figure 14 · p. 21
• In OSC H release, O-DU high uses eight threads for utility and common functions, DU_APP, EGTP, SCTP, O1, RLC UL, RLC DL and most MAC functions, and the lower MAC handler.MAC_SCH is detached from the 5G NR scheduler; the lower MAC handler runs in a separate thread.Source: §5.4 · p. 21, Figure 15 · p. 21
• O-DU low comprises channel-processing blocks for PDCCH, PDSCH, PUCCH, and PUSCH, plus separate PBCH, PRACH, uplink and downlink scheduling, FAPI, FHI, FEC-acceleration, and timing blocks.Figure 16 shows the O-DU low processing blocks.Source: §5.4 · p. 22, Figure 16 · p. 22
• Functional Split 7.2x divides processing between resource-element mapping and FFT/iFFT, with 7.2a precoding in the O-DU or 7.2b precoding in the O-RU.The split reflects trade-offs in RU complexity and interface throughput.Source: §5.4 · p. 22, Figure 17 · p. 22
• O-FHI connects the O-DU and O-RU through control, user, synchronization, and management planes carrying commands, IQ data, timing synchronization, and maintenance signals, respectively.Figure 18 depicts the O-FHI data flows.Source: §5.4 · p. 23, Figure 18 · p. 23
• WG8 develops O-DU specifications, while WG4 develops O-FHI specifications.Figure 14 shows the O-DU architecture and interfaces.Source: §5.4 · pp. 21, 23
• Radisys develops O-DU high and Intel develops O-DU low; H release adds multi-scheduler support, Inter-CU Handover, and E2AP V30 enhancements, with integration testing ongoing.Testing with O-DU low is awaiting the RU simulator.Source: §5.4 · p. 23
• OSC's open-source O-FHI library implements the control, user, and synchronization planes, while management-plane development and its specifications remain unfinished.O-RAN adopters can use the library to develop O-RAN-compliant DU and RU components.Source: §5.4 · p. 23

5.5. O-RU

• The O-RU hosts low-physical-layer and radio-frequency processing and connects to the O-DU through O-FHI and to the SMO through O1.An O-RU can have multiple panels, each with one or more transmit or receive antenna arrays.Source: §5.5 · p. 23
• O-RAN specifies digital, analog, and hybrid beamforming, with commands shared between the O-DU and O-RU.The paper lists predefined-beam, weight-based dynamic, attribute-based dynamic, and channel-information-based methods.Source: §5.5 · p. 23
• Predefined-beam uses O-RU-stored weights selected by an O-DU index, whereas weight-based dynamic beamforming has the O-DU generate weights and requires it to know O-RU antenna characteristics.The two methods differ in where weights are stored or generated and what the O-DU must know.Source: §5.5 · pp. 23–24
• Attribute-based and channel-information-based dynamic methods have the O-RU generate weights from attributes or channel information supplied by the O-DU, respectively.The attribute-based method does not require the O-DU to know the O-RU's specific antenna characteristics.Source: §5.5 · p. 24
• Because the RU is primarily hardware-based, O-RAN focuses on software standards to control it, and vendors must follow those specifications for their RUs to qualify as O-RUs.Source: §5.5 · p. 24

5.6. O-eNB

• An O-eNB is an eNB or ng-eNB that supports E2.Source: §5.6 · p. 24
• The O-eNB integrates O-DU and O-RU functions in one node while retaining O-FHI between them.Source: §5.6 · p. 24
• Its listed interfaces are E2, NG, O1, S1, X2, and Xn.Source: §5.6 · p. 24

5.7. O-Cloud

• The O-Cloud hosts O-RAN functions on physical infrastructure nodes and pools computing resources through an abstraction layer.It also hosts supporting software and management and orchestration functions.Source: §5.7 · p. 24
• O2 services divide into infrastructure management for cloud infrastructure and deployment management for virtualized or containerized deployment life cycles.Source: §5.7 · p. 24

5.8. Use Cases

• O-RAN white-box hardware targets low-cost 5G deployment, focusing on O-DU, O-RU, and a fronthaul gateway with O-FHI, open-source O-DU software, and cloud NFV support.Source: §5.8 · p. 24
• Traffic steering uses O1, A1, and E2 interfaces for mobile load balancing intended to improve traffic distribution and reduce network intervention.Source: §5.8 · p. 25
• O-RAN’s QoE framework predicts application-specific QoE and performs real-time closed-loop optimization to allocate resources before QoE declines.It targets high-bandwidth, latency-sensitive applications facing dynamic traffic and fluctuating radio conditions.Source: §5.8 · p. 25
• When dynamic demand and radio conditions defeat default planning, Non-RT RIC analytics can prioritize user groups during congestion when all requirements cannot be met.Source: §5.8 · p. 25
• Massive MIMO optimization targets cell-centric QoS and user-centric QoE across multiple cells, using RIC analytics and O1, A1, and E2 exchanges.The passage notes that 5G massive MIMO increases energy requirements relative to 4G and that multi-vendor deployment depends on specific MNOs.Source: §5.8 · p. 25
• Category II use cases apply AI and ML through Near-RT and Non-RT RICs for slice SLA assurance and use real-time V2X context to predict or prevent anomalous UE situations.Source: §5.8 · pp. 25–26
• UAV use cases combine flight-path, climate, and airspace information for AI-based resource allocation, while Near-RT RIC adapts radio resources to channel conditions and asymmetric video/control needs.The section also lists prioritized cases such as QoS/QoE optimization, slicing and SLA assurance, and massive MIMO, plus newer cases including O-DU pooling and congestion management.Source: §5.8 · p. 26
• RAN sharing can reduce deployment costs while increasing network capacity and coverage, with operators independently controlling VNFs on shared hardware.Separate SMO and Near-RT RIC control is supported through remote O1, O2, and E2 interfaces.Source: §5.8 · p. 26

6.1. O-RAN Alliance Architecture Issues

• O-RAN specifications and OSC implementations remain incomplete, and SMO also faces copyright issues involving 3GPP specifications.Unfinished specifications include SMO’s Non-RT RIC ML, O-FHI M-Plane, O1, and O2; OSC development is incomplete, postponed, or awaiting official releases.Source: §6.1 · p. 27
• Proposed RAN-control approaches include an ANR rApp that sends policies to an xApp and OrchestRAN, which selects algorithms and execution locations for operator objectives.OrchestRAN’s Colosseum prototype instantiated data-driven services on demand with minimal control overhead and latency; cell-splitting research [71] uses LSTM traffic predictions to detect potential congestion.Source: §6.1 · pp. 27–28
• RIC design needs better xApp models and subscriber correlation, while FlexRIC offers service-oriented controllers and RFT targets fault-tolerant xApps.The paper also identifies needs for smaller xApp packages, time-series and message-queue support, scaling, additional AI methods, and hardware acceleration; large-scale heterogeneous testing remains necessary.Source: §6.1 · p. 28
• x86-based vDUs may need accelerators to meet demanding latency and traffic requirements, but accelerator specifications lack implementation details; RISC-based processors are another proposed option.Accelerators can increase vDU cost, while ARM-based processors are described as more cost-efficient than traditional processors.Source: §6.1 · pp. 28–29
• O-FHI research highlights optional TLS/PKI and proposed MACsec security, while O-RU compliance, functional-split flexibility, and beamforming interference and latency requirements remain open concerns.The paper recommends following O-RU standards from the design stage, further research on flexible functional splits, and testing whether channel-state information meets URLLC latency requirements for zero-forcing beamforming.Source: §6.1 · pp. 29–30

6.2. Open RAN Field Issues

• Open RAN still lacks robust, deployable software, while NR and mmWave support, multivendor integration, and shared testing methods remain significant implementation challenges.The paper calls for standard development environments, optimization metrics, and test and validation methodologies, and notes that NR libraries need further development and mmWave testing lacks accessible hardware.Source: §6.2 · pp. 31–33
• Open RAN’s multivendor architecture complicates interoperability and integration, prompting proposals for software-centric integration and staged deployment.Operators may introduce modules incrementally and test localized networks before macro RAN; integration can be led by operators, service providers, vendors, or system integrators.Source: §6.2 · pp. 31–32
• Dynamic resource scheduling for network slices needs more optimized allocation mechanisms as changing demands make slice management increasingly challenging.Network slicing abstracts functionality into logical entities with distinct services and resources, but their dynamic management makes scheduling more difficult.Source: §6.2 · p. 33
• DMUSO improves system resource scheduling by 4.4 to 7.7 times compared with other methods and algorithms; further study should assess how UE mobility affects scheduling across slices.The algorithm learns service demands, data rates, resources, bandwidths, efficiency, transmission rates, and channel-related SLAs; [92] identifies mobility as future work.Source: §6.2 · p. 34
• An O-RAN cell-load prediction workflow uses an LSTM model in Near-RT RIC xApps, but remains incomplete because training data requires offline processing.Current ML limitations include high processing demands and resource-constrained devices; distributed or lightweight models are a research direction for balancing complexity, latency, and reliability.Source: §6.2 · pp. 34, 40
• Hierarchical orchestration separates RAN, transport, and core management under distributed orchestrators coordinated by a hyperstrator, but its protocols and model still need systematic study.Future work includes specifying ontology requirements, classes, and relations and defining, evaluating, and assessing a systematic model translation.Source: §6.2 · p. 34
• The drone control scheme achieves an average 19% network capacity gain over traditional BS-constrained control by jointly optimizing drone location and transmission directionality.AGMEN research also identifies mobile routing, multi-dimension channels, and UAV scheduling as future directions.Source: §6.2 · pp. 34–35
• Open RAN security risks arise from disaggregation, virtualization, interfaces, AI/ML, and open-source code; 35 threats are identified across O-RAN components, including malicious xApps and rApps.Suggested defenses include authentication and access control, cryptography, secure virtualization, and intrusion detection; blockchain research still needs to improve latency, stability, scalability, green mining, and cost [106].Source: §6.2 · pp. 35–37
• Limited open RAN hardware and contributions impede validation of standards, while licensing choices can expose companies to trade-secret or intellectual-property risks.OAI’s public license retains contributor IP rights, and O-RAN Alliance’s Apache License v2.0 and IEEE’s Open RAN activity are presented as steps toward broader collaboration.Source: §6.2 · pp. 37–38
• GBMD can serve up to 90% E2E network delay decrease, while MESON reports service response delay below 40 ms with at least 100 PoPs.Latency remains a concern for URLLC slices and virtualized BBUs; future work should explore backup strategies for different use cases [71].Source: §6.2 · pp. 38–39
• Open RAN scalability remains constrained by cloud DU scaling, reliability and failover needs, uncertain large-scale total cost of ownership, and the cost and complexity of scaling AI/ML operations.Trirematics is proposed as a cloud-native, extensible operator with automation, lifecycle management, and observability features.Source: §6.2 · p. 39
• RRM can allocate resources to reduce interference and support real-time video through link adaptation, while mobility management enables seamless handover across heterogeneous wireless access networks.The passage identifies RRM as a major issue in 5G NR and links it to cooperation between satellite and terrestrial networks.Source: §6.2 · p. 41
• 5G architecture with NTN includes SDN- and NFV-based NTN, IoST, cognitive NTN, and NOMA-based NTN approaches.Source: §6.2 · p. 41

7. Open Source Approaches

• Open-source platforms give researchers access to RAN software, support feedback on platform and specification shortcomings, and inform new O-RAN features; BubbleRAN illustrates commercial use of open-source platforms.BubbleRAN builds products using OAI and Mosaic5G platforms, adding features for customer-specific solutions.Source: §7 · p. 41

7.1. Interoperability and Security Testing

• Open-source testing tools could address the lack of concrete interoperability and security testing systems, while vendors could offer advanced features beyond basic O-RAN test requirements.For interoperability, minimum-requirement tools would not remove the system integrator role; integrators may offer convenience and advanced services.Source: §7.1 · pp. 41–42

7.2. OSC Community Labs

• Three OSC Labs provide O-RAN-specification-aligned hardware and software resources for integration and testing, with distinct sites supporting end-to-end RAN demonstration, O-Cloud interconnection, and O-DU and security testing.The labs are in New Jersey, San Jose, and Taiwan.Source: §7.2 · p. 42

8. Conclusions

• Open RAN seeks to address cellular-industry challenges through disaggregation and interoperability, with flexibility, cost efficiency, and performance improvement among its promised benefits.The conclusion notes that developing and implementing Open RAN still presents many challenges.Source: §8 · p. 42
• The survey covers RAN evolution, the Open RAN movement and technologies, related projects and standards, O-RAN architecture and use cases, and challenges and research directions.It also discusses broader issues including implementation, standardization, performance, cost, and security.Source: §8 · p. 43
• The paper discusses open-source approaches to some Open RAN challenges and presents the survey as a starting reference for further in-depth study.The conclusion identifies academia and industry as intended readers.Source: §8 · p. 43

Abbreviations

• Cellular and network terms include 2G–5G, 3GPP, LTE, NR, 5GC, UE, and QoS.The glossary expands these as generation labels, standards and network terms, user equipment, and quality of service.Source: Abbreviations · pp. 43–44
• RAN architecture abbreviations distinguish centralized, distributed, and virtual RAN, along with baseband, central, distributed, and radio units.Examples include C-RAN, D-RAN, vRAN, BBU, CU, DU, and RU.Source: Abbreviations · pp. 43–44
• The glossary also covers software, orchestration, and computing terms such as AI, ML, SDN, NFV, MEC, RIC, and SMO.It also includes platform and operational terms such as COTS, FPGA, GPU, CapEx, and OpEx.Source: Abbreviations · pp. 43–44