Fig. 1 also depicts the O-Cloud, an O-RAN compliant cloud platform that uses hardware acceleration add-ons when needed (e.g., to speed up fast Fourier transform operations or forward error correction tasks). In the following, we detail the jurisdiction and roles of each functional component.

Service Management and Orchestration. The SMO consolidates several orchestration and management services, which may go beyond pure RAN management, say end-to-end network slice management. In the context of O- RAN, the main responsibilities of SMO are (i) fault, configuration, accounting, performance and security (FCAPS) interface to O-RAN network functions; (ii) large timescale RAN optimization; and (iii) O-Cloud management and orchestration via the O2 interface.

Non-RT RAN Intelligent Controller. As mentioned, this logical function resides within the SMO and provides the A1 interface to the Near-RT RIC. Its main goal is to support large timescale RAN optimization (seconds or minutes), including policy computation, ML model management (e.g., training), and other radio resource management functions within this timescale. Data management tasks requested by the Non-RT RIC should be converted into the O1/O2 interface while contextual/enrichment information can be provided to the near-RT RIC via the A1 interface.

Near-RT RAN intelligent Controller. Near-RT RIC is a logical function that enables optimization, control, and data monitoring of O-CU and O-DU nodes, in near-real-time (between 10 ms and 1s). To this end, Near-RT RIC control is steered by the policies and assisted by models computed/trained by the Non-RT RIC. One of the main operations assigned to the near-RT RIC is radio resource management, but near-RT RIC also supports 3rd party applications (so-called xApps).

This architecture inherently enables three independent—yet with sporadic interactions—control loops:

1. Non-RT RIC control loop: Long timescale operation of the orders of seconds or minutes. The goal is to perform O-RAN specific orchestration decisions such as policy configuration or ML model training.
2. Near-RT RIC control loop:  Subsecond timescale operation with the goal of performing tasks such as policy enforcement or radio resource management.
3. O-DU Scheduler control loop: Real-time operation performing legacy radio operations such as HARQ, beamforming or scheduling—out of O- RAN’s scope.

3. O-RAN Disruption Potential

3.1 AI/ML-driven Joint Orchestration of O-RAN Resources

O-RAN’s disposition towards  software-defined  AI-assisted  RAN  control  fosters different degrees of openness, namely, systems comprised of (i) O-RAN- compliant physical network functions exposing and using O-RAN interfaces so different vendors can interplay (lowest degree of openness); (ii) chassis of servers and racks in a cloud shared  among  multiple  vendors  (higher  degree  of  openness); and (iii) one or multiple O-Clouds, a fabric of generic servers and networking infrastructure hosting O-RAN software that is decoupled from the hardware at different layers.

Such openness enables substantial flexibility to deploy each of the logical functions introduced earlier, e.g., O-DU and O-RU can be collocated or not de-pending on the context and particular needs of the operator and these decisions may be changed over time with minimal cost [2].

Despite the potential benefits of RAN virtualization, dynamic resource orchestration becomes more compounded. Specifically, the problem of optimally allocating computing resources and radio resources is now coupled and requires joint management [3]. Moreover, the virtualized base stations sha3re a pool of computing resources and may or may not share radio spectrum as in [4], which further complicates the orchestration problem.

3.2 O-RAN in Shared Computing Platforms

Due to the computing fluctuations inherent to wireless dynamics and resource contention in shared computing infrastructure, the price to migrate from dedicated to shared platforms may be high. vRANs shall rely on cloud platforms comprised of pools of shared computing resources (mostly CPUs, but also hardware accelerators brokered by an abstraction layer), to host virtualized functions such as the PHY [5]. However, while CUs are amenable to virtualization in regional clouds, virtualized DUs (vDUs)—namely, the vPHY therein—require fast and predictable computation in edge clouds [5-7]. Shared computing platforms provide a harsh environment for DUs because they trade off the predictability supplied by dedicated platforms for higher flexibility and cost-efficiency [8, 9].

Indeed, research has shown that resource contention in shared computing infrastructure, even when placing virtual functions on separate cores, may lead to up to 40% of performance degradation compared to dedicated platforms [9, 10]—the so-called noisy neighbor problem. [11] shows that the baseline architecture of a DU collapses upon moments of deficit in computing capacity. Recent solutions to accelerate some signal processing tasks certainly help but do not tackle the core problem: a DU pipeline that requires predictable computing to provide carrier-grade reliability.

Reference [11] shows that a redesign of the baseline DU pipeline can provide carrier-grade reliability in these platforms. More specifically, the use of (i) a two-stage downlink scheduling approach, (ii) predictive or early HARQ, and (iii) congestion control, allows us to decouple compute-intensive data channel processing tasks from less compute-intensive but critical tasks such as processing control channels or scheduling.

3.3 Smart Surfaces towards Open Environments

The advent of smart surfaces is paving the road towards a highly-dense open environment where the signal propagation is properly disciplined. Reconfigurable intelligent surfaces (RISs) represent a new business opportunity to push for the openness revolution. Indeed, RIS components can be designed to be plugged into a shared O-RAN view, as depicted in Fig. 2. A new network segment is envisioned between the RAN elements and the end-users wherein the elements of the RISs can be automatically triggered and configured by the RIS controller within short timescales (milliseconds) to drive the overall efficiency at the network edge. Such a controller will be interfaced to the orchestration layer by means of a new reference point, namely Rx, which instructs transmitter configurations on longer timescales (minutes) for specific environments or given use cases. In parallel, the RIS controller can adjust the RIS configurations based on the received feedback as well as the desired performance indicators. Additionally, a new interface called R2 can be designed to create a direct link between the near-RT RIC and the RIS Controller. This will allow to simultaneously control the RIS configurations and the BS beamforming in very short timescales. The design of an “Open Environment” interface is also envisioned between the RIS elements and the radio units handling the digital front in order to bring flexibility and programmability into the overall improved picture.

4. O-RAN Pros and Cons

State-of-the-art vRAN solutions applied today in the market, which rely on dedicated hardware acceleration, jeopardize the very reasons that make virtualization appealing for the RAN in the first place: flexibility and cost-efficiency. First, research has shown that cloud RANs require many more resources than legacy RAN platforms to attain similar performance guarantees in real mobile networks. Second, dedicated accelerators make vDUs more expensive and power-hungry than their legacy counterparts—let alone the fact that the much-longed for hardware/software decoupling is not achieved.

O-RAN’s O-Cloud approach strives to address the above issues: while hard- ware acceleration is still required for specialized, compute-intensive and repetitive tasks, such as fast Fourier transform and forward error coding, O-RAN’s approach is to provide pools of shared accelerators, brokered by an abstraction layer. The goal is to preserve the carrier-grade performance that only hardware accelerators can provide without sacrificing the f flexibility and cost-efficiency of RAN virtualization.

O-RAN does not only target virtualized RAN scenarios, but open RAN deployments overall to enable competition in the RAN, traditionally monopolized by a small set of manufacturers. This should accelerate innovation and help reduce costs. However, according to recent market forecasts [13], O-RAN is expected to cover only about 10% of the overall market by 2025. Thus, despite the new business opportunities opened to small and medium-scale vendors (traditionally alien to large-scale RAN deployments) significant hurdles will need to be overcome to reach the economies of scale of major vendors in the RAN ecosystem in order to be competitive. If O-RAN is successful in delivering on the high promises in RAN openness and innovation, it might be actually becoming the predominant market share deployment solution for future 6G networks.