[acronym]long-short hidelinks

# A Comprehensive Overview and Survey of O-RAN: Exploring Slicing-aware
Architecture, Deployment Options, and Use Cases ††thanks: This manuscript was
received on DD MM 2024; revised on DD MM 2024; and accepted for publication by
Associate Editor on DD MM 2024. Date of publication DD MM 2024; date of
current version DD MM 2024. ††thanks: Khurshid Alam, Dennis Krummacker, and
Hans D. Schotten are with the Intelligent Networking (IN) Research Group,
German Research Center for Artificial Intelligence (DFKI), $\mathrm{67663}$
Kaiserslautern, Germany. ††thanks: Mohammad Asif Habibi, Matthias Tammen, and
Hans D. Schotten are with the Division of Wireless Communications and Radio
Navigation (WiCoN), Department of Electrical and Computer Engineering (EIT),
University of Kaiserslautern (RPTU), $\mathrm{67663}$ Kaiserslautern, Germany.
††thanks: Walid Saad is affiliated with the Department of Electrical and
Computer Engineering, Virginia Tech, 22203 Virginia, United States of America.
††thanks: Marco Di Renzo is associated with Université Paris-Saclay, CNRS,
CentraleSupélec, Laboratoire des Signaux et Systèmes, 3 Rue Joliot-Curie,
91192 Gif-sur-Yvette, France. ††thanks: Tommaso Melodia is affiliated with the
Institute for the Wireless Internet of Things, Northeastern University,
Boston, MA 02115 United States of America. ††thanks: Xavier Costa-Pérez is
affiliated with the 6G Networks R&D Department, NEC Laboratories Europe,
$\mathrm{69115}$ Heidelberg, Germany. He is also with the i2CAT Research
Center and the Catalan Institution for Research and Advanced Studies (ICREA),
$\mathrm{08034}$ Barcelona, Spain. ††thanks: Mérouane Debbah is with Khalifa
University of Science and Technology, P. O. Box 127788, Abu Dhabi, United Arab
Emirates. ††thanks: Ashutosh Dutta is affiliated with the Applied Physics
Laboratory, Johns Hopkins University, 20723 Maryland, United States of
America. ††thanks: The corresponding authors are Khurshid Alam
<EMAIL_ADDRESS>and Mohammad Asif Habibi (asif@eit.uni-kl.de).

Khurshid Alam, Mohammad Asif Habibi, Matthias Tammen, Dennis Krummacker,
Walid Saad (Fellow, IEEE), Marco Di Renzo (Fellow, IEEE), Tommaso Melodia
(Fellow, IEEE), Xavier Costa-Pérez (Senior Member, IEEE), Mérouane Debbah
(Fellow, IEEE), Ashutosh Dutta (Fellow, IEEE), and Hans D. Schotten (Member,
IEEE)  0009-0003-3344-8629 0000-0001-9874-0047 0009-0005-4599-8876
0000-0001-9799-4870 0000-0003-2247-2458 0000-0003-0772-8793
0000-0002-2719-1789 0000-0002-9654-6109 0000-0001-8941-8080
0000-0002-6182-9395 0000-0001-5005-3635

###### Abstract

Open-radio access network (O-RAN) seeks to establish principles of openness,
programmability, automation, intelligence, and hardware-software
disaggregation with interoperable interfaces. It advocates for multi-vendorism
and multi-stakeholderism within a cloudified and virtualized wireless
infrastructure, aimed at enhancing the deployment, operation, and maintenance
of RAN architecture. This enhancement promises increased flexibility,
performance optimization, service innovation, energy efficiency, and cost
efficiency in fifth-generation (5G), sixth-generation (6G), and future
networks. One of the key features of the O-RAN architecture is its support for
network slicing, which entails interaction with other slicing domains within a
mobile network, notably the transport network (TN) domain and the core network
(CN) domain, to realize end-to-end (E2E) network slicing. The study of this
feature requires exploring the stances and contributions of diverse standards
development organizations (SDOs). In this context, we note that despite the
ongoing industrial deployments and standardization efforts, the research and
standardization communities have yet to comprehensively address network
slicing in O-RAN. To address this gap, this survey paper provides a
comprehensive exploration of network slicing in O-RAN through an in-depth
review of specification documents from O-RAN Alliance and research papers from
leading industry and academic institutions. The paper commences with an
overview of the ongoing standardization efforts and open-source contributions
associated with O-RAN, subsequently delving into the latest O-RAN architecture
with an emphasis on its slicing aspects. Further, the paper explores
deployment scenarios for network slicing within O-RAN, examining options for
the deployment and orchestration of O-RAN and TN network slice subnets. It
discusses the slicing of the underlying infrastructure, encompassing both TNs
and compute resource slicing. Finally, the paper provides a summary of various
use cases related to O-RAN slicing.

###### Index Terms:

5G, 6G, Disaggregation, Management and Orchestration, Intelligence, Near-RT
RIC, Network Slicing, NFV-MANO, Non-RT RIC, O-Cloud Site, O-RAN, Open
Interfaces, Openness, RAN Architecture, RAN Slicing, RIC, SMO Framework, TN
Slicing

##  I Introductory Remarks

The radio access network (RAN) serves as a critical domain within a cellular
network, responsible for enabling wireless connectivity between the user
equipment (UE) and base station across a specified geographical footprint. It
employs heterogeneous radio access technologies (RATs) to ensure efficient
data transmission both in the upstream and downstream directions [1]. The
RAN’s architectural evolution was shaped by several key factors, including the
ever-increasing number of UEs, the growing complexity and diversity of
wireless access technologies, the relentless pursuit of enhanced network
performance (such as higher data rates, lower latency, broader coverage,
etc.), embracing emerging trends such as virtualization and cloudification,
and the escalating demand for diverse communication and beyond-communication
services over the past decades [2, 3, 4, 5]. This continuous evolution,
exemplified by its transformation from fourth-generation (4G) to fifth-
generation (5G) and now towards sixth-generation (6G), has been instrumental
in enabling a wide range of transformative applications, services, and use
cases [6, 7, 8].

Introduced in 4G, the distributed RAN (D-RAN) architecture proposed a
separation of the radio and baseband processing functionalities into two
distinct entities: the baseband unit (BBU) and remote radio head (RRH) [9].
However, these components were situated at the same location within the same
cellular network site and connected via an internal interface within the
corresponding base station [2]. Subsequently, the centralized RAN (C-RAN)
architecture has emerged, introducing a significant departure from traditional
RAN architectures by decoupling the BBU and RRH [2, 1]. In this approach, the
BBU is physically relocated to a centralized data center (DC), enabling
centralized control and optimization of multiple RRHs through a high-speed
fronthaul (FH) interface utilizing the common public radio interface (CPRI)
technologies [9, 10]. The emergence of D-RAN and C-RAN architectures marked
significant advancements in the development and deployment of numerous RAN
architectures and RATs, paving the way for further innovations in 4G and
beyond [1, 11].

The advent of 5G heralded a paradigm shift in RAN architecture, driving
substantial transformations to harness the diverse demands of a wide range of
use cases and industrial applications [2]. The goal was to establish a
distributed, programmable, and adaptable RAN architecture, equipped to
seamlessly accommodate the evolving needs of emerging vertical markets [12].
Aiming to enhance flexibility and adaptability, the 3rd Generation Partnership
Project (3GPP) proposed the next-generation RAN (NG-RAN) as the 5G RAN
architecture [13]. The NG-RAN comprises a number of base stations known as the
next generation NodeB (gNB). The NG-RAN introduces a split of the gNB, placing
higher protocol layers under the control of the centralized unit (CU) and
delegating responsibility for lower protocol stacks to the distributed unit
(DU) [14, 15]. Building upon the 3GPP-defined gNB, the Open RAN (O-RAN)
Alliance proposed a further distribution of DU functionalities into two
distinct entities: DU and radio unit (RU). With this approach, the gNB now
encompasses CU, DU, and RU [16]. This architectural improvement introduced
significant scalability, enabling a single CU to effectively manage multiple
DUs, while each DU could seamlessly connect to multiple RUs, responsible for
the efficient transmission and reception of radio signals to and from 5G UEs.

One of the features of the NG-RAN is its seamless integration with cloud-
native and virtualized environments, enabling the deployment of CU and DU on
commercial off-the-shelf (COTS) hardware within a cloudified and virtualized
infrastructure [16]. Despite the increasing momentum towards virtualization
and disaggregation in NG-RAN, the architecture has predominantly maintained a
closed and proprietary approach, thereby constraining the flexibility and
innovation potential it could otherwise provide [17, 18]. The NG-RAN
components often embody complex proprietary designs developed and tailored by
the respective network equipment manufacturers [19]. The interfaces connecting
these components are engineered for peak performance, but they are exclusively
compatible with the proprietary hardware of the specific manufacturer,
hindering the prospects of multi-vendor interoperability [14, 20].

To foster open interfaces and facilitate multi-vendor interoperability, the
O-RAN Alliance has proposed a groundbreaking industry initiative, the O-RAN
architecture, aiming to revolutionize traditional NG-RAN [21]. This initiative
seeks to replace closed and proprietary NG-RAN with open, interoperable, and
cloud-driven systems. The O-RAN Alliance establishes the development of open
standards and specifications, fostering compatibility and innovation amidst a
diverse landscape of network equipment vendors [17]. Simultaneously, it
embraces artificial intelligence (AI) and machine learning (ML) to
revolutionize network automation and optimization through the RAN intelligent
controller (RIC) [22, 23, 24, 25]. To achieve an open and intelligent NG-RAN
architecture for 5G and beyond, there is a need to deploy open interfaces
between NG-RAN components as well as to adopt software-defined networking
(SDN) and network function virtualization (NFV) [26, 27]. In addition, the
O-RAN architecture paves the way for realizing groundbreaking services and
applications in cellular networks, enabling the deployment of network slicing,
dynamic spectrum sharing, and resource sharing [20, 28, 29, 30].

Empowered by the O-RAN architecture, network slicing enables the creation of
open slices, effectively partitioning a physical network into multiple
virtualized networks that can operate simultaneously and independently [17].
Each virtualized network can be configured to match the specific requirements
of diverse use cases, catering to the unique demands of 5G and beyond
applications [31]. This specifically means that dedicated virtual network
slices can be tailored to fulfill specific user needs [28], enabling the
simultaneous provisioning of a diverse range of services while dynamically
allocating network resources to match the individualized requirements of each
slice [32]. In contrast to the rigid and inflexible one size fits all
architectural solution, network slicing introduces a paradigm shift towards a
more dynamic, flexible, and efficient approach to network optimization and
resource allocation [33, 34].

Notwithstanding the above features of traditional RANs slicing, O-RAN brings
several advantages to slicing. (a) With limited ability to customize resource
allocation for specific slices, O-RAN’s disaggregated architecture allows for
more granular control. Different vendors can provide special hardware and
software optimized for specific slice requirements. This allows for a more
tailored approach to slicing. (b) Traditionally, creating slices with specific
performance characteristics might require specific vendor equipment. O-RAN’s
open interfaces make it possible to mix and match components from different
vendors as long as they comply with O-RAN standards. This allows operators to
choose the best-in-breed solutions for each slice, potentially leading to cost
savings and innovation. (c) To facilitate automated closed-loop control of the
RAN, O-RAN introduces two RICs [22, 35]. The non-real-time RIC (Non-RT RIC)
and near-real-time RIC (Near-RT RIC) in O-RAN enable the deployment of
intelligent applications (rApps and xApps) tailored for slicing. These
applications dynamically handle resources and enhance performance for slices
in real-time, a task challenging with traditional RAN architectures [36]. (d)
O-RAN facilitates automation in slicing through its open interfaces and
standardized protocols. This allows for automated slice creation,
configuration, and management, making the process faster and less error-prone
compared to manual configuration in traditional RANs.

TABLE I: Comparing the contributions of our paper to the most recent state-of-the-art overview and survey papers related to the O-RAN. Ref. | Year | Summary of Key Contributions
---|---|---
[15] | 2020 |  • Overview of architectures for open and programmable 5G networks, with a particular focus on O-RAN • Extensive collection of recent open-source software and frameworks developed for the O-RAN architecture
[5] | 2022 |  • Evolution of O-RAN through deployments, advancements, current initiatives, and standards activities • Exploration of O-RAN components, proposal of open-source solutions, and identify research challenges
[37] | 2022 |  • Detailed exploration of O-RAN architecture, outlining its components and interfaces • Illumination of potential benefits and burgeoning market trends of O-RAN adoption in 5G and beyond
[26] | 2022 |  • Presenting the deployment of O-RAN and the integration of AI/ML models into O-RAN architecture • Introducing an architecture that enables seamless end-to-end (E2E) data collection and real-time analytics
[38] | 2022 |  • Exploration of AI applications in O-RAN components and interfaces, as well as associated use cases • Examination of potential AI deployment scenarios and diverse use cases across various sectors
[39] | 2022 |  • Showcasing the deployment of deep learning (DL) in O-RAN architecture by demonstrating two use cases • Identification of critical challenges, open issues, and future research directions for AI-enabled O-RAN
[20] | 2022 |  • Discussing constraints in O-RAN architecture and exploring technologies to overcome these limitations • Exploring security, latency, real-time control at the physical layer, and testing of AI-based RAN control
[19] | 2023 |  • Exploring O-RAN design principles, standardization, and RIC’s implementation for O-RAN management • Discussing experimental platforms, performance optimizations, challenges, and future research in O-RAN
[40] | 2023 |  • Providing a survey and overview on O-RAN architecture, as well as its automation and intelligentization • Highlighting crucial research areas where ML can provide substantial benefits to O-RAN
[41] | 2023 |  • Conducting a survey on integrating AI/ML in O-RAN and outlining associated standardization activities • Discussing AI-based modeling, model inference performance, challenges, and future research directions
[42] | 2023 |  • Discussing the security and privacy risks as well as challenges linked to O-RAN’s security • Exploring potential solutions for enhancing O-RAN security and discussing related standardization efforts
[17] | 2023 |  • Proposing an architecture for the realization of an E2E open network slicing in 6G • Introducing a standard-compliant O-RAN architecture for 6G, delving into its various layers
[10] | 2023 |  • Delving into O-RAN deployment, examining the disaggregation of its functions and interfaces • Shedding light on latest standardization efforts spearheaded by the O-RAN Alliance
[43] | 2024 |  • Presenting deployment options and diverse test results encompassing Open FH, cloud platforms, and RIC • Demonstrating the robustness of O-RAN and sharing insightful perspectives on its future evolution
[44] | 2024 |  • Adopting O-RAN for 6G, emphasizing on increased agility, cost-effectiveness, energy efficiency, etc. • Discussing O-RAN’s impact in 5G and proposing a system-level approach for integrating O-RAN in 6G
[45] | 2024 |  • Discussing O-RAN architecture, emphasizing on RICs and AI/ML integration for autonomous optimization • Exploring E2E network slice orchestration architecture for realizing O-RAN use cases
This paper | 2024 |  • Offers a detailed exploration of the latest O-RAN architecture, open-source activities, and standardization efforts made by various standards development organizations (SDOs), with an emphasize on network slicing • Provides insights into the deployment scenarios for service management and orchestration (SMO) Framework to effectively manage and orchestrate O-RAN slice subnets and their corresponding resources • Explores the underlying infrastructure that hosts O-RAN network functions (NFs) and transport networks (TNs)

In addition, network slicing empowers mobile network operators (MNOs) to
deliver services tailored to exacting requirements, facilitating the
fulfillment of service level agreements (SLAs) with tenants [46]. This
approach specifically addresses the heterogeneity of performance requirements
and network functionalities by introducing standardized service types, defined
by the 3GPP. These standardized service types, as of this writing, encompass
enhanced mobile broadband (eMBB), ultra reliable low latency communication
(URLLC), massive machine type communication (mMTC), high-performance machine
type communication (HMTC), and vehicle to everything (V2X) [16]. The number of
these standardized service types is anticipated to expand significantly with
the continuous advancement and deployment of communication and non-
communication services in 5G, 6G, and beyond [6].

Despite the significant contributions of the 3GPP in RAN slicing, the O-RAN
Alliance has also played a pivotal role in the intelligentization of open
interfaces and components to support intelligent slicing within O-RAN [47].
The RIC [22], which serves as a robust platform for hosting slicing-aware
applications, can train, host, and execute the AI/ML models to achieve
intelligent O-RAN slicing. These models can predict and optimize traffic
fluctuations based on a comprehensive set of defined metrics [12]. To fully
realize the potential of slicing within an O-RAN, it is essential to foster a
seamless unification between O-RAN and 3GPP standards at various levels [48].
This unification is crucial for addressing the intricate challenges and
complexities associated with RAN slicing across various domains of the two
standards.

It is noteworthy that, while the O-RAN Alliance and 3GPP frameworks enable
slicing in O-RAN, they do not directly address the virtualization aspects in
O-RAN. To holistically encompass both the virtualized and physical dimensions
of slicing within the O-RAN architecture, it is essential to establish
harmonization among the 3GPP, O-RAN Alliance, and European Telecommunications
Standards Institute (ETSI) frameworks. This harmonization of these three
standardized frameworks is anticipated to pave the way for unified solutions
for the realization of slicing within the O-RAN [48], enabling seamless
delivery of various types of O-RAN slices.

###  I-A Review of Survey and Overview Papers on O-RAN

Despite the remarkable progress and growing interest in 3GPP-defined RAN
architectures and their slicing [49, 50], realizing slicing in the O-RAN
Alliance-defined architecture presents escalating challenges due to the
stringent requirements of supporting open interfaces, seamless
interoperability among components from diverse vendors, and the intricate
interplay of multiple stakeholders within the management and network domains
[51, 17]. Consequently, O-RAN slicing has recently emerged as a focal point of
intense research interest within both the standardization and research
communities.

Within the standardization community, the O-RAN Alliance is spearheading the
role as a leading SDO that has been defining standards for O-RAN slicing. The
specifications related to the network slicing have been published within the
various working groups (WGs) of the O-RAN Alliance. We will delve into the
pertinent specifications and contributions to O-RAN slicing in the subsequent
chapters. However, the most recent specifications that lay the groundwork for
O-RAN slicing, published by the WG 1, are accessible in [52, 31].

Within the research community, we have witnessed significant contributions to
diverse research challenges. This encompasses aspects related to the
management and orchestration of O-RAN slicing, designing xApps and rApps for
O-RAN slices, and numerous optimization problems. Furthermore, several survey
and overview papers related to the subject have been published by leading
academic institutions. We present an up-to-date list of these papers,
summarizing their major contributions to the O-RAN architecture (and, where
applicable, to O-RAN slicing) in Table I.

###  I-B The Primary Survey Gap in the Literature

Notwithstanding the fact that some of the earlier mentioned papers address
network slicing and highlight its impact on the O-RAN, they lack a thorough
analysis of O-RAN slicing. Specifically, there is a deficiency in presenting
an accurate portrayal of the current scenario, exploring various proposed
deployment options, and offering sufficient information on tightly integrating
the different O-RAN components. In addition, there is a lack of literature on
the seamless unification and interoperability among the O-RAN’s components to
ensure the successful development and deployment of various types of O-RAN
slices. Therefore, according to our current understanding, there exists no
comprehensive survey or overview paper in the literature that delves into the
intricacies of network slicing in O-RAN in a comprehensive and thorough
manner.

Figure 1: Overview of the organization and structure of this survey paper.
Each box represents one of the seven chapters of the paper, encapsulating
their respective contributions and themes.

###  I-C Goals and Contributions

To address the identified literature gap, this paper makes a significant
contribution by offering a comprehensive survey and overview of network
slicing in O-RAN. Specifically, the key contributions of this paper are as
follows:

  * •

Exploring open-source initiatives, standardization actives, and the design of
experimental platforms for O-RAN.

  * •

Focusing on the latest O-RAN architecture outlined by the O-RAN Alliance, with
an additional emphasis on theoretical contributions from academic research and
practical deployment from various leading industries.

  * •

Providing a holistic view of the network slicing paradigm within O-RAN, we
introduce the functional components and interfaces necessary for implementing
network slicing within the O-RAN architecture.

  * •

Delving into the deployment scenarios of O-RAN slicing and the SMO Framework,
we provide insights into a number of high-level use cases expected to be
served by O-RAN’s slicing-aware architecture.

  * •

Discussing the NFs and TN elements, along with their management and
orchestration, such as FH and midhaul (MH), which constitute the O-RAN slice
subnet. Additionally, this paper is addressing the aspects of the underlying
infrastructure associated with TN slicing.

In Table I, we present a comparison between the contributions made in this
article and those found in state-of-the-art survey articles on the subject.

###  I-D The Organization of the Article

The rest of this survey paper is structured as follows: We begin with an
overview of the open-source projects, activities, and their contributions, as
well as the standardization efforts associated with O-RAN architecture in
Section II. We then introduce the architectural components and open interfaces
of O-RAN slicing-aware architecture and highlight the features for O-RAN
slicing in Section III. This section further includes discussions on O-RAN
interactions with 3GPP-defined network components, service management, and
service orchestration. In Section IV, we explain the various deployment
scenarios for O-RAN deployment, O-RAN slicing, and SMO proposed by the O-RAN
Alliance in relation to different use cases. Moving forward, Section V delves
into the underlying infrastructure slicing within the O-RAN architecture,
elaborating on the concepts of O-RAN cloud platform (O-Cloud) slicing, TN
slicing, and TN slice orchestration. Section VI outlines high-level use cases
that are expected to be prioritized and defined with support from the O-RAN
community, particularly in relation to RAN slicing. Finally, Section VII
offers a summary of our work, draws conclusions, and suggests potential
directions for future research. To improve readability, an overview of the
organization of this survey paper is illustrated in Figure 1.

##  II Ongoing Standardization Efforts and Open Source Contributions to the
O-RAN Architecture

In this section, we explore, in detail, the fundamental features,
characteristics, and implications of the O-RAN architecture. Additionally, we
delve into ongoing open-source initiatives within the O-RAN ecosystem,
alongside openly accessible experimental platforms specifically designed for
developing the O-RAN components and interfaces. Furthermore, we provide an
overview of state-of-the-art standardization contributions across various de
facto and de jure SDOs associated with the O-RAN architecture. Our primary
objective is to equip the inquisitive reader with a comprehensive
understanding of the ongoing advancements associated with O-RAN.

###  II-A Key Features and Principles of O-RAN

The primary motive behind O-RAN architecture for service providers is to
diversify their vendor partnerships and avoid vendor lock-in, allowing the
utilization of non-proprietary software and hardware components from various
vendors [53]. Traditionally, RAN has been a proprietary and vertically
integrated part of a mobile network, with tightly coupled hardware and
software from a single vendor [17]. O-RAN seeks to change this paradigm by
advocating for open interfaces and interoperability among RAN components. The
O-RAN architecture prioritizes interoperability and flexibility through open
standards, enabling network operators to choose equipment and software from
different suppliers [54, 40]. This flexibility facilitates greater
customization in network configuration, encouraging the involvement of second-
and third-tier equipment manufacturers [53].

O-RAN not only establishes open interfaces but also enables unrestricted
access to NG-RAN through AI-based control mechanisms, enhancing real-time
sensing, proactive management, and dynamic responsiveness to radio resources
[55, 56]. It supports programmable, disaggregated, virtualized, and
interoperable tasks [16], enabling service providers to transition to a fully
programmable, intelligent, autonomous, and multi-vendor RAN architecture for
5G, 6G, and beyond [53].

The integration of AI/ML models into the O-RAN facilitates the design of data-
driven RICs, supporting service providers, vendors, and third parties with the
onboarding of applications and use cases in an inteligent manner [48]. These
applications and use cases aid in automating and optimizing O-RAN operations,
reducing the total cost of ownership (TCO) for mobile carriers, and enhancing
the quality of experience (QoE) and quality of service (QoS) of RAN services
[57, 58].

The following bullet points sum up the main principles and characteristics of
the O-RAN that service providers, network operators, and other stakeholders
may find relevant.

  * •

Intelligent and Programmable Network: O-RAN is designed to be intelligent and
programmable, allowing for dynamic adjustments and optimizations in network
operations. This flexibility enables the network to adapt to varying demands
and scenarios efficiently [59].

  * •

Data Center Economics to RAN: O-RAN brings the economic principles of DC to
RAN, optimizing resource utilization and operational expenditure (OPEX) [54].
This approach enhances the efficiency of RAN infrastructure, aligning it with
the cost-effective practices seen in DCs.

  * •

Lower TCO: By leveraging DC economics and promoting efficiency, O-RAN aims to
significantly reduce the overall TCO. This cost-effectiveness is achieved
through streamlined operations and resource utilization [60].

  * •

Automation and Manageability: O-RAN emphasizes automation and manageability,
reducing the manual effort required for network operations. This not only
improves efficiency but also enhances the reliability and consistency of
network management tasks [59].

  * •

Faster Time to Market: O-RAN facilitates a quicker time to market for
deploying network solutions, enabling operators to roll out new services and
features more rapidly. This speed in implementation is crucial for staying
competitive in the rapidly evolving telecommunications landscape [61].

  * •

Agility of Innovation: The architecture of the O-RAN fosters innovation
agility, allowing for the swift development and integration of new
technologies and features. This adaptability ensures that the network can keep
pace with advancements and changing industry requirements [61].

  * •

Vendor Diversity: O-RAN promotes vendor diversity, allowing network operators
to choose from a variety of equipment and service providers. This flexibility
enhances competition, encourages innovation, and provides network operators
with options to tailor their networks according to specific requirements and
preferences [60].

  * •

Open Source Software: O-RAN leverages open-source software to provide
reference implementations and encourage collaboration among industry
participants [60].

The O-RAN Alliance – a consortium of telecom operators, vendors, and academic
institutions – plays a crucial role in developing and promoting O-RAN
standards. By adopting these principles, the industry aims to accelerate
innovation, reduce deployment costs, and create a more dynamic and competitive
marketplace for RAN solutions towards 5G, 6G, and beyond mobile communication
systems [17].

###  II-B Network Slicing

Network slicing stands as a groundbreaking architectural solution. It
facilitates the creation of multiple distinct virtual networks, or ”slices,”
operating atop a shared physical infrastructure. This approach, heralded as a
pivotal element of 5G, 6G, and beyond, introduces a wealth of possibilities to
address diverse service demands and fully realize the capabilities of next-
generation communication systems.

At its essence, network slicing involves partitioning the underlying physical
network into discrete virtual networks, each finely configured to specific
service requirements and performance criteria [62]. Each slice operates
autonomously, offering tailored configurations of bandwidth, latency,
security, and so forth [63]. This departure from traditional monolithic
networks to a multi-sliced architecture empowers service providers to cater
comprehensively, spanning from ultra-responsive industrial automation to high-
throughput mobile broadband [64, 65].

An E2E network slice seamlessly traverses through all network domains,
comprising RAN, TN, and core network (CN) segments [66]. Each slice is
meticulously crafted to address the distinct needs and attributes of various
services, ensuring logical separation. This isolation safeguards the integrity
of individual network slices, preventing errors or malfunctions in one slice
from impacting communication in others. Such isolation fosters the autonomy
and reliability of each virtual network [67].

For every network slice, operators confidently commit dedicated resources,
including computing power, bandwidth, QoS provisions, and other critical
elements, guaranteeing optimal performance and service quality [68]. This
assurance underscores the commitment to meeting the diverse demands of modern
communication services while ensuring robustness and efficiency across the
network landscape.

Despite the substantial progress made in E2E network slicing, persistent
challenges remain in NG-RAN slicing [30, 64]. The complexity of NG-RAN slicing
stems from the intricate task of balancing varying levels of isolation and
resource sharing while tailoring the user plane (UP) and control plane (CP)
for individual slices [69]. More specifically, these complexities stem from
factors such as the need to balance the trade-off between utilization ratio
and isolation level, establish harmonization among inter-RAN and intra-RAN
slice resource allocation algorithms, and effectively manage inter-RAN and
intra-RAN slice priorities [16]. In addition, the limited availability of
radio resources demands highly efficient resource management to optimize
network performance. Moreover, the introduction of features like bandwidth
partitioning (BWP) and physical numerology in 5G new radio (NR) amplifies
these complexities [70].

To address the aforementioned challenges, the 3GPP has provided guidelines in
Release 17 for realizing RAN slicing in NG-RAN architecture. These guidelines
encompass various aspects, including support for various QoSs, resource
segregation, enforcement of SLA, and more [49]. 3GPP specifications further
enhance flexibility by presenting options such as Layer 1, Layer 2, or medium
access control (MAC)-based approaches for implementing RAN slicing [49, 71].
In addition, they also specify a management and orchestration framework for
the efficient life cycle management of RAN slices over the NG-RAN
architecture, as well as its interaction with other standardized frameworks
for the realization of E2E network slicing [16].

###  II-C O-RAN Standards and Activities

As of the present writing, numerous de facto and de jure organizations are
actively engaged in establishing a software and hardware ecosystem in
alignment with the principles of the O-RAN paradigm. These organizations
participate in collaborative efforts within various SDOs. In this subsection,
we delve into an exploration of these organizations and their contributions
toward the realization of O-RAN.

####  II-C1 3GPP

3GPP does not directly establish standards for O-RAN. Nevertheless, various
architectural components, NFs, management and orchestration frameworks,
functional splits, interfaces, and other elements within the 3GPP-based RAN
architecture have been extended by other SDOs to formulate standards for the
O-RAN architecture. The 3GPP standards provide a comprehensive system
definition for RAN architecture, distributed across several technical
specification groups (TSGs).

During the 5G evolution, 3GPP considered eight different split variants and
reached a consensus to establish two NG-RAN split architectures. We discussed
these split options in our previous work in detail [16]. One of the two split
architectures is high layer split (HLS), equivalent to option 2 from the 5G
study, which involves dividing the BBU into CU and DU along with the
separation of CP and UP functions for CU [40]. 3GPP further introduced the F1
interface that connects the CU to the DUs and the E1 interface to enable
coordination between the CP and UP [72, 73].

The 3GPP-defined functional splits were established to promote the concept of
disaggregating the standard protocol stack. This involves separating the
processing of a specific layer within the protocol stack from the computing
entity. This movement within the 3GPP framework is seen as the foundational
step toward achieving genuine cellular interface and processing openness [41].
It has served as a pivotal catalyst for the development of subsequent O-RAN
specifications which will be elaborated upon later in this section.

####  II-C2 O-RAN Alliance

The O-RAN Alliance, established in 2018, is dedicated to the ambitious task of
modernizing RAN architecture globally. The alliance’s central mission revolves
around steering the wireless communication industry towards a future
characterized by openness, intelligence, virtualization, and seamless
interoperability within the RAN. This transformative journey is underpinned by
a shift towards virtualized network components, the adoption of white-box
hardware, and the implementation of open interfaces facilitating communication
between various RAN’s software and hardware components [74].

To execute its vision, the O-RAN Alliance employs a structured approach
outlined in the O-RAN specification, which is meticulously organized into
several groups overseen by the technical steering committee (TSC). The TSC
plays a pivotal role in decision-making and provides essential guidance on
O-RAN technical matters. It assumes the crucial responsibility of approving
specifications before they undergo board approval and subsequent publication.
Currently, the TSC comprises eleven technical WGs, five focus groups (FGs), a
research group, an open-source community, and a minimum viable plan -
committee (MVP-C). These diverse entities within the TSC collaborate to focus
on specific aspects of the O-RAN architecture, contributing collectively to
its development and deployment. For a concise overview of the objectives and
areas of focus within these divisions, refer to Table II.

TABLE II: Summary of contributions and focus areas across multiple WGs supervised by the TSC within the O-RAN Alliance. Group | Title | Principal Areas of Focus and Notable Contributions
---|---|---
WG 1 |  Use Cases and Overall Architecture WG |  • Exploring and defining use cases, system-level requirements, deployment scenarios, and a comprehensive architecture for O-RAN • Investigation into network slicing within O-RAN, including defining use cases, requirements, and introducing slicing-aware architecture with interface extensions • Coordination of proof of concepts to demonstrate O-RAN products to the market
WG 2 |  Non-RT RIC and A1 Interface WG |  • Defining an architecture for Non-RT RIC, incorporating the R1 interface to connect the Non-RT RIC framework with Non-RT RIC applications (rApps) • Expanding R1 services within Non-RT RIC and integrating interfaces with the management components of the SMO Framework • Proposal and coverage of the A1 interface between the Non-RT RIC and the Near-RT RIC, including associated use cases and applications
WG 3 |  Near-RT RIC and E2 Interface WG |  • Specifying E2 interface between the Near-RT RIC and the E2 nodes • Defining the Near-RT RIC architecture and introducing application programming interfaces (APIs) for the Near-RT RIC platform and the Near-RT RIC applications (xApps) • Defining use cases, requirements, and management specifications for the Near-RT RIC, and contributing to service models for E2 interface and E2 nodes
WG 4 |  Open Fronthaul Interfaces WG |  • Establishing specifications for an open fronthaul (O-FH) interface between O-RAN DU (O-DU) and O-RAN RU (O-RU) • Setting standards for Control, User, Synchronization, and Management Plane protocols with corresponding YANG models for O-FH link • Developing specifications for transport interfaces and conducting O-FH interoperability tests
WG 5 |  Open F1/W1/E1/X2/Xn Interface WG |  • Providing interoperable multi-vendor specifications aligned with 3GPP standards for F1, W1, E1, X2, and Xn interfaces, enhancing O-RAN architecture • Defining specifications for O1 interface, covering O-RAN CU (O-CU) and O-DU, including operations and maintenance (OAM) functions • Developing open MH and backhaul (BH) interoperability test specifications
WG 6 |  Cloudification and Orchestration WG |  • Specifying cloud-native and virtualized infrastructure for hosting O-CU and O-DU, focusing on hardware-software decoupling • Providing technology and reference designs for leveraging commodity hardware platforms • Identifying use cases, deployment scenarios, and requirements for cloud resource hosting, and defining high-level orchestration architecture for SMO Framework and O-Cloud interaction
WG 7 |  White-box Hardware WG |  • Specifying standards for comprehensive reference design of high-performance, spectral efficient and energy efficient white box base stations • Promoting decoupled software and hardware platform for O-RAN components • Addressing outdoor and indoor cells with various split options, along with O-FH interface
WG 8 |  Stack Reference Design WG |  • Developing software architecture, design, and release plan for O-CU and O-DU, tailored for NR protocol stack • Providing specifications for interoperability testing of O-CU and O-DU deployment scenarios with other O-RAN components and interfaces
WG 9 |  Open X-haul Transport WG |  • Designing an open TN within O-RAN, meeting FH, MH, and BH service requirements • Concentrating on the open transport domain, including transport equipment, physical media, and associated control/management protocols within the TN
WG 10 |  OAM for O-RAN |  • Specifying OAM architecture for O-RAN and management services for O1 interface, including unified operation and notification mechanisms • Developing information models and data models for OAM architecture in O-RAN
WG 11 |  Security WG |  • Establishing specifications for O-RAN’s security, including its NFs, interfaces, xApps, and rApps • Defining requirements, use cases, architectures, and protocols to ensure security and privacy of stakeholders within the O-RAN paradigm
SDFG |  Standard Development Focus Group |  • Leading in formulating standardization strategies for the O-RAN Alliance and serve as the primary interface to other relevant SDOs • Managing coordination of both incoming and outgoing liaison statements
IEFG |  Industry Engagement Focus Group |  • Engaging with leading industry players and members of the O-RAN Alliance to drive adoption, spread, and ongoing innovation of O-RAN-based technologies and solutions
OSFG |  Open Source Focus Group |  • Managing O-RAN Alliance’s open-source activities, including establishing the O-RAN software community (OSC) and developing open-source related strategies • Collaborating with other open-source communities to drive innovation and adoption of O-RAN
Continued on the next page
TABLE II: Continued from previous page. Group | Title | Principal Areas of Focus and Notable Contributions
---|---|---
TIFG |  Test & Integration Focus Group |  • Defining testing and integration approaches, coordinating specifications across WGs, including E2E test specifications and productization profiles • Planning PlugFests and offering guidelines for third-party open testing and integration centers (OTICs), facilitating integration and verification processes
SuFG |  Sustainability Focus Group |  • Focusing on enhancing energy efficiency and reducing environmental impact in O-RAN • Collaborating with MVP-C to align initiatives across all WGs and FGs
nGRG |  next Generation Research Group |  • Researching intelligent O-RAN principles for 6G and beyond standards • Driving network evolution towards greater intelligence and performance through new technologies
MVP-C |  Minimum Viable Plan – Committee |  • Providing roadmap for implementing comprehensive O-RAN solutions in commercial networks • Managing definition of O-RAN features, including creation, prioritization, and tracking documents • Approving feature creation and inclusion in relevant releases; collaborating and coordinating with all WGs and FGs
OSC |  O-RAN Software Community |  • Leading the development of open-source software for O-RAN architecture in collaboration with the linux foundation (LF) • Focusing on aligning with the open architecture and criteria of the O-RAN Alliance to deliver a solution suitable for commercial deployment

####  II-C3 Telecom Infra Project

The telecom infra project (TIP) is a global collaboration involving businesses
and organizations dedicated to accelerating the development and implementation
of open, disaggregated, and standards-based technology and network
infrastructure solutions within the telecommunications sector. The
organization has over 500 members, and its work has resulted in the
development of a number of open standards and specifications. The TIP’s
projects have also been adopted by a number of major operators around the
world. The TIP’s work outlines end products that meet specific commercial use
cases that operators need. The TIP organizes multiple project groups (PGs)
that concentrate on products, solutions, and software across various network
domains, including RAN, TN, and CN, as well as various management layers.

Within the various PGs, the OpenRAN is an initiative for enabling an open
ecosystem for building the 3GPP-defined NG-RAN architecture based on the
principles of open components and interfaces for existing 4G, 5G, and beyond
mobile networks. The primary goal of OpenRAN PG within the TIP is to develop
end products and solutions, foster vendor diversity for network service
providers, and introduce innovative platforms for network management. The
group collaborates with operators, vendors, system integrators, and global
stakeholders to align requirements for different components of OpenRAN
networks, including O-RUs, O-DUs, and O-CUs. OpenRAN PG concentrates on
building, testing, and validating Open RAN products at scale [75]. The
solutions developed undergo thorough testing and validation in laboratory
environments through TIP Community Labs and PlugFest.

The OpenRAN PG is organized into the following two main work streams [76]:

  * •

Component Subgroups: These subgroups are dedicated to enhancing the
performance of individual OpenRAN components, encompassing software and
hardware such as RU, DU, CU, radio intelligence automation (RIA), and OpenRAN
orchestration and management automation (ROMA).

  * •

Segment Subgroups: These subgroups are concentrating on integrated RAN
solutions tailored for specific network use cases to enhance deployment
scenarios, both outdoor and indoor.

The OpenRAN PG released a technical priorities document, Release 3, in April
2023, presenting their prioritized requirements for Open RAN. This document
comprehensively covers main scenarios, radio configurations, and hardware and
software requirements for each building block within the Open RAN framework of
the TIP. The primary focus of Release 3 is to advance requirements related to
SMO and RIC, with significant enhancements in underlying cloud infrastructure,
O-CU, O-DU, and O-RU.

Notably, this release places a heightened emphasis on security considerations
and challenges, consolidating security requirements in a dedicated section. It
also explores energy efficiency topics in more detail, identifying new
requirements across various streams. The goal is to accelerate the development
of competitive Open RAN solutions in Europe and globally, promoting widespread
technology adoption [77, 76, 78].

####  II-C4 Small Cell Forum

The small cell forum (SCF) is a global organization focused on developing
technical and commercial tools to accelerate the adoption of flexible, cost-
effective, and scalable cellular network infrastructure. Throughout its
existence, SCF has played a key role in standardizing essential elements of
mobile network technology, including functional API (FAPI), network FAPI
(nFAPI), and the enhancement of the X2 interface. These specifications enable
an open, multi-vendor platform, thereby reducing the barriers to the
densification of stakeholders in the wireless communication industry [79].

The SCF has established its own Open RAN ecosystem with a particular emphasis
on small cells. The introduction of the nFAPI protocol by SCF marks the
pioneering of split option 6 [59], which divides the MAC layer and physical
layer (PHY), housing the PHY in the small cell RU (S-RU). The SCF nFAPI is
pivotal in empowering the Open RAN ecosystem by facilitating interoperability,
allowing a small cell CU/DU to connect seamlessly with an S-RU [80].

The SCF promotes openness and interoperability in small cell networks in order
to allow diverse architectures while maintaining a common platform. To
simplify integration, SCF provides tools, deployment blueprints, and support
for testing, including the SCF disaggregated RAN transport study (DARTs) [81].
Emphasizing open testing and certification is crucial to instilling confidence
among operators and facilitating the widespread adoption of Open RAN. SCF,
O-RAN Alliance, and TIP have dedicated considerable efforts to support
standardized testing processes across the industry, including actively
participating in plugfests [79].

The SCF collaborates with O-RAN Alliance, 3GPP, OpenAirInterface (OAI), and
many other organizations across technical, commercial, and regulatory eras.
SCF aims to drive Open RAN adoption in all domains, resulting in significant
growth in the deployment of virtualized open RAN. The combination of open
systems, open-source code, and shared spectrum has the potential to empower
numerous new deployers, particularly in crucial areas like enterprise and
smart city environments where small cells are indispensable [79, 81].

###  II-D O-RAN-Related Open Source Projects

The software community is dedicated to seamlessly aligning software reference
implementations with the O-RAN architecture and specifications. In this
context, the OSC assumes various responsibilities, including the development
of open-source software, collaboration with other open-source communities, and
promotion of related projects and activities. As of this writing, multiple
open-source platforms compliant with O-RAN are accessible for use by academics
and research institutions, providing valuable tools for their work. In the
following section, we will delve into some of the key contributors and
participants in O-RAN implementations.

####  II-D1 ONAP

The open network automation platform (ONAP) is an LF open-source project
launched in 2017. It serves as a comprehensive platform designed for
orchestrating, managing, and automating network and edge computing services.
To address the needs of network operators, cloud providers, and enterprises,
ONAP employs real-time and policy-driven orchestration and automation for both
physical and virtual NFs. This capability facilitates swift automation of new
services and the essential lifecycle management crucial for 5G and next-
generation networks [75]. The project uses SDN and NFV technologies to
automate 5G networks. ONAP contains complete management and orchestration
(MANO) layer functionality that is consistent with the NFV architecture of
ETSI. In addition to fault, configuration, accounting, performance, security
(FCAPS) features, ONAP also contains a framework for designing network
services [82].

There exist robust relationships and interdependencies between ONAP and OSC,
deploying a SMO Framework and incorporating the Non-RT RIC functions [83]. The
ONAP is collaborating with the OSC to enhance coordination, minimize redundant
efforts, and streamline work. A compilation detailing shared areas of interest
where ONAP and OSC intersect are available at [84]. The ongoing study of the
use case, “ONAP/3GPP & O-RAN Alignment-Standards Defined Notifications over
VES” serves to facilitate alignment between ONAP, 3GPP, and O-RAN. This
contribution aims to empower ONAP to adhere to O-RAN Alliance and 3GPP
standards, potentially encouraging participation from companies aligned with
O-RAN Alliance and 3GPP [85].

The Kohn release of ONAP further focus on O-RAN integration, cloud-native NF
orchestration improvements, and intent-driven closed-loop autonomous networks
[86]. ONAP includes modeling and orchestration functionality of a slice
including 5G RAN, core, and transport network slice subnets. More
specifically, ONAP includes workflows and user interfaces for the
communication service management function (CSMF) and network slice management
function (NSMF) with an interface to an external network slice subnet
management function (NSSMF). This functionality allows the design,
orchestration, and termination of an network slice [87].

####  II-D2 OpenAirInterface

The OpenAirInterface software alliance (OSA) is a nonprofit organization
founded by a French research institute, EURECOM, that supports a global
community of researchers and industry contributors to the development of open-
source software for the CN and RAN of 3GPP cellular networks. The Alliance
supports the advancement of the 3GPP 5G cellular stack, which is included in
the OAI software packages and deployed utilizing COTS hardware. The roadmap
creation, quality assurance, and marketing of the OAI software packages used
by the academic and business communities for various use-cases are all tasks
that fall under the purview of the OSA. The goal of the OSA is to speed up OAI
adoption.

In 5G, the OAI community and software assets are expanding at the quickest
rate. Currently, OAI has the following projects: OAI 5G RAN, OAI 5G CORE,
MOSAIC5G, and CI/CD. The newly created MOSAIC 5G (M5G) PG aims to transform
RAN and CN into agile and open network-service delivery platforms. The primary
emphasis of M5G PG is producing software implementations of the O-RAN E2
protocol, a flexible RIC called FlexRIC, a flexible Core controller namely
FlexCN, an intelligent RAN and CN operator [88]. Northeastern University has
also integrated OAI with the OSC RIC [89].

####  II-D3 Open Networking Foundation

open networking foundation (ONF) is a consortium led by several network
operators, playing a pivotal role in driving radical transformation within
network infrastructure. The ONF’s software-defined RAN (SD-RAN) project
actively contributes open-source components to enhance Open RAN, by creating
and testing O-RAN compliant network elements, fostering multi-vendor RAN
solutions, and showcasing the potential of mixing components for innovation
[90].

In close collaboration with the O-RAN Alliance and OSC, the primary goal of
the platform is to develop open-source components for the O-CU CP, O-CU UP,
and O-DU [40]. SD-RAN features a cloud-native uONOS-RIC (pronounced as micro-
ONOS-RIC), a Near-RT RIC, an xApp development environment, and exemplary xApps
for controlling Open RAN elements [91]. Deutsche Telekom has deployed a fully
disaggregated 5G field trial, integrating components from more than 8 vendors
using SD-RAN open-source uONOS-RIC. As the initial complete realization of the
O-RAN architecture, encompassing O-RU, O-DU, O-DU, RIC, and xApps sourced from
various providers, this marks a significant milestone in the advancement of
the Open RAN movement. On January 9, 2024, ONF officially announced its merger
with the LF. Subsequently, ONF’s work is being introduced as distinct
independent projects under the LF [91].

####  II-D4 srsRAN

The srsRAN project, developed by software radio system (SRS), is an open-
source RAN solution supporting both 4G and 5G technologies, featuring an ORAN-
native gNB. This comprehensive RAN solution adheres to standards set by both
the 3GPP and the O-RAN Alliance, covering the L1/L2/L3 protocol stack with
minimal dependencies [92].

The srsRAN-based gNB offers flexibility for users to deploy a monolithic gNB
on a single machine or distribute RAN functionalities across multiple machines
and geographic locations. This flexibility enables easy integration with
third-party RICs, PHY solutions, and other O-RAN compliant hardware and
software applications and use cases.

The project follows the 3GPP 5G architecture, implementing functional splits
between DU and CU, with further disaggregation into CU CP and CU UP. srsRAN
supports third-party Near-RT RIC and xApp through the FlexRIC framework, with
the ultimate goal of fully supporting the E2 interface [93].

####  II-D5 OpenRAN Gym

OpenRAN Gym, spearheaded by Northeastern University, is a collaborative open-
source initiative crafted to facilitate AI-driven and experimental research
within the Open RAN ecosystem [94, 35]. The primary goal is to bring together
researchers from academia and industry, creating a dynamic and cooperative
environment to advance cutting-edge solutions and innovations for Open RAN
through vibrant collaboration. OpenRAN Gym builds on frameworks for data
collection and RAN control enabling E2E design and testing of data-driven
xApps by providing an O-RAN compliant Near-RT RIC and E2 termination [35].
Users can conduct data collection campaigns, prototype, and evaluate solutions
across a variety of wireless environments and deployments before transitioning
them to production networks.

The OpenRAN Gym architecture provided in [94] consists of following key
components:

  * •

The publicly and remotely accessible experimental wireless platforms like
Colosseum, Arena, and PAWR program platforms for data collection, prototyping,
and testing solutions in diverse environments [95, 96, 94, 97].

  * •

A softwarized RAN utilizing open protocol stacks like srsRAN and OAI for
cellular networks.

  * •

A data collection and control framework, such as SCOPE, providing key
performance indicators (KPIs) to extract key performance measurements (KPMs)
from the RAN and dynamically control it at runtime.

  * •

An O-RAN control architecture like ColO-RAN, capable of connecting to the RAN
through standardized interfaces like E2 termination, receiving runtime KPMs,
and controlling it through AI/ML solutions like xApps/rApps.

###  II-E Open Testbeds

In addition to the aforementioned open-source projects, several testbeds are
available to aid in the implementation of softwarized 5G networks by
leveraging certain open-source components. We elaborate on some of these
testbeds below.

####  II-E1 Colosseum

Colosseum is an open-access and publicly available extensive wireless testbed
designed for experimental research, utilizing virtualized and softwarized
waveforms and protocol stacks on a fully programmable ”white-box” platform.
Colosseum, with 256 state-of-the-art software-defined radios (SDRs) and a
substantial channel emulator core, has the capability to simulate almost any
scenario. This allows for the comprehensive design, development, and testing
of solutions at scale across various deployments and channel conditions. It
achieves high-fidelity reproduction of radio frequency scenarios through FPGA-
based emulation employing finite-impulse response filters. These filters
accurately model the taps of desired wireless channels, applying them to
signals generated by the radio nodes to faithfully replicate real-world
wireless environments [95, 97]. OpenRAN Gym has been intricately developed
within Colosseum, facilitating experimentation with E2E O-RAN compliant
networks, as well as enabling data collection and AI-driven model development,
among other functionalities [35].

####  II-E2 POWDER

Platform for Open Wireless Data-driven Experimental Research (POWDER) is a
versatile infrastructure tailored to support a wide range of software-defined
experiments. It is a city-scale wireless testbed, infrastructure spanning
outdoor areas incorporating multiple SDRs, an indoor laboratory setup for
over-the-air experiments, and a wired attenuator matrix [97]. The principal
objective of POWDER is to foster experimental research in heterogeneous
technologies, with a particular emphasis on areas such as 5G cellular
technologies and network orchestration. POWDER is equipped with integrated
features that streamline the setup of an O-RAN, facilitating quick
implementation. Conducting experiments in POWDER involving the Near-RT RIC,
xApps, the O-CU Subsystem, and open software for the SMO is a straightforward
process [98, 99].

####  II-E3 COSMOS

The Cloud enhanced Open Software defined MObile wireless testbed for city-
Scale deployment (COSMOS) testbed is being deployed in West Harlem, New York
City, as a component of the POWDER initiative. The COSMOS is focused on
creating, developing, and implementing an advanced wireless testbed at a city-
scale level. Its purpose is to facilitate real-world experimentation with
next-generation wireless technologies and applications. It has been certified
by the O-RAN Alliance as an OTIC [97, 100].

The COSMOS architecture prioritizes ultra-high bandwidth and low-latency
wireless communication, tightly integrated with edge cloud computing. Deployed
in upper Manhattan, the COSMOS testbed comprises 40-50 advanced software-
defined radio nodes, complemented by fiber-optic front-haul and back-haul
networks, as well as edge and core cloud computing infrastructure. Through a
web-based portal, researchers can remotely conduct experiments on the COSMOS
testbed, accessing various facilities for experiment execution, measurements,
and data collection [100].

####  II-E4 Arena

Arena stands as an innovative open-access wireless testing platform,
revolutionizing research in sub-6 GHz 5G and beyond spectrum exploration.
Anchored by a grid of ceiling-mounted antennas within a spacious office
environment, each antenna seamlessly interfaces with programmable SDRs. This
amalgamation of 12 computational servers, 24 symbol-level synchronized SDRs,
and a total of 64 antennas imbues Arena with unparalleled computational
prowess and scalability, ideal for pioneering technology development within
densely populated spectrum bands [96]. Operating on a meticulously crafted
three-tier design, Arena strategically allocates servers and SDRs within a
dedicated room, while antennas elegantly adorn the office ceiling, linked to
radios via extensive 100 ft-long cables. This configuration guarantees a
dynamic, scalable, and reproducible real-time experimental environment,
faithfully replicating real-world wireless scenarios [96, 97].

####  II-E5 X5G

X5G, a pioneering private 5G network testbed at Northeastern University,
Boston, merges open-source and programmable components from PHY to CN.
Notably, it stands as the first fully programmable multi-vendor and O-RAN
compliant testbed, a collaborative endeavor involving Northeastern, NVIDIA,
and OAI. Accelerated by NVIDIA graphics processing units (GPUs) at Layer 1 and
built on OAI for layers 2 and 3, this integration leverages the SCF FAPI for
seamless interaction between the MAC and PHY layers. Such integration enables
the inline acceleration of demanding PHY tasks on the GPU, fostering
scalability and facilitating AI/ML integration within the RAN. The NVIDIA
aerial RAN CoLab (ARC) platform operates on a specialized multi-vendor
infrastructure, featuring 8 servers for the CU and DU, along with 4 RUs
suitable for lab installations. Additionally, it incorporates O-RAN 7.2x FH
and timing hardware, as well as a dedicated 5G CN. NVIDIA ARC and OAI
collaborate to provide enhanced performance while upholding the openness and
accessibility characteristic of open-source systems, marking a significant
stride forward in the realm of intelligent 5G and beyond use cases [101].

####  II-E6 5GENESIS

The 5GENESIS initiative, backed by the European Union, aims to authenticate 5G
KPIs across various applications, spanning controlled environments and large-
scale events. It consolidates insights from multiple European Union projects
and internal research and development efforts of its partners to establish a
unified, E2E 5G infrastructure across five experimentation platforms in
Europe. These platforms, while possessing unique capabilities, seamlessly
interface and operate cohesively with one another within the 5GENESIS
facility, which serves as a versatile hub for validating KPIs, conducting
additional demonstrations, and evaluating pivotal 5G and beyond use cases. The
trials conducted within the facility focus on confirming essential 5G-PPP
KPIs, thereby inherently assessing the capabilities and performance of each
constituent platform [102].

##  III In-depth Analysis of O-RAN Architecture with a Particular Emphasis on
Network Slicing

The O-RAN architecture is composed of various open interfaces, protocols,
transport links, NFs, and management functions (MFs); collectively referred to
as O-RAN components. The grand objective of such an open and programmable
architecture is to decrease the need for proprietary hardware and software
implementations and to create a multi-vendor and standard-compliant wireless
network infrastructure [63]. By employing open interfaces and open-source
software, the control plane is isolated from the user plane within the O-RAN
architecture [44]. The openness also creates a modular base station software
stack that is deployable on COTS hardware [37]. Through these groundbreaking
innovations, the quintessential goals of the O-RAN Alliance namely, fostering
openness, promoting vendor independence, and enhancing programmability are not
just achievable but exquisitely realized [54, 103]. The openness of the O-RAN
components expedites the provisioning of new services for end-users. The
openness of the interfaces in O-RAN architecture brings service agility and
cloud-scale economics to smaller vendors and network operators, allowing them
to introduce new services or customize the network to meet their specific
needs [61]. Open interfaces also enable multi-vendor deployments, making the
supplier ecosystem more competitive and vibrant [104, 105, 106].

In addition to openness and vendor diversity, certain ML-based and AI-assisted
features, components, and architectural solutions have been introduced by the
O-RAN Alliance [107, 104]. The goal is to integrate intelligence and
automation into the operations and maintenance of the O-RAN architecture [48,
108]. The integration of automation and intelligence can be achieved by the
utilization of state-of-the-art ML-assisted algorithms, including supervised
learning, unsupervised learning, deep learning, reinforcement learning, and
many others [104]. These algorithms can be deployed both at the network layer
and the management layer [108]. The deployment of these algorithms makes the
operation and maintenance of O-RAN simpler, resulting in a reduction in OPEX
[109]. Moreover, the automation and intelligentization of the O-RAN
architecture can also reduce human intervention in the loop and increase the
accuracy to handle the network complexity [110].

In this section, we will explore the latest O-RAN architecture in a detailed
manner, with a special emphasis on the network slicing aspects. We will
describe its components and interfaces that comprise the O-RAN architecture
and further study the features designed for network slicing. Additionally, we
will discuss MFs related to network slicing defined by the 3GPP, ETSI, and
ONAP. Moreover, we will provide an insight into the underlying infrastructure,
including the O-Cloud sites, open transport network, and open cellular sites.

###  III-A Major Components of the O-RAN Architecture

The O-RAN architecture is founded on the disaggregation paradigm of a cellular
base station, featuring multiple logical and physical units responsible for
different components and interfaces within the radio network protocol stack.
Figure 2 illustrates that the O-RAN architecture is composed of four major
components: the O-RAN gNodeB (O-gNB), the RIC, the SMO Framework, and the
underlying infrastructure. The O-gNB part includes the radio functionalities
of an O-RAN slice. These functionalities perform tasks associated with
modulation, coding, resource scheduling, and many others in both upstream and
downstream directions. The O-gNB consists of the O-CU, O-DU, and O-RU. The RIC
comes in two types: the Non-RT RIC and the Near-RT RIC, each designed to
handle specific control loop and latency constraints [12]. The SMO Framework
includes the Non-RT RIC, slice MFs, and other SMO functions [22]. The SMO
Framework serves as an automation platform dedicated for the management and
orchestration of O-RAN radio resources and RAN slices [111]. The underlying
infrastructure is responsible for hosting the components of an O-RAN slice. It
includes O-Cloud sites and transport links.

In the remaining parts of this section, we discuss each of the three major
components in a detailed manner. We also explain how they contribute to the
implementation of network slicing in the Release 3 O-RAN architecture.

Figure 2: O-RAN Release 3 Slicing-aware Reference Architecture

###  III-B O-gNB (E2 Nodes) and its Corresponding Interfaces

Figure 2 illustrates that each O-gNB is divided into several logical nodes
within the O-RAN architecture. These nodes include the O-CU, the O-DU, and the
O-RU, or a combined O-RAN eNB (O-eNB). They are collectively referred to as
the E2 nodes in O-RAN Alliance terminology [112]. In the following, we provide
their detailed overview, along with a detailed description of their respective
open interfaces.

####  III-B1 O-RAN Centralized Unit

The O-CU is a logical node that implements the higher layer protocols of the
RAN stack, including the radio resource control (RRC) layer, which controls
the life cycle of the connection; the service data adaptation protocol (SDAP)
layer, which controls the QoS of traffic flows of bearers; and the packet data
convergence protocol (PDCP), which, among other things, handles packet
reordering, packet duplication, and encryption for the air interface [16,
113]. The O-CU terminates the E2 interface to the Near-RT RIC and the O1
interface towards the SMO Framework [22]. The O-CU includes one O-CU control
plane (O-CU-CP) and possibly multiple O-CU user plane (O-CU-UP), which
communicate with each other through the E1 interface [44], as shown in Figure
2.

According to the 3GPP specifications, the O-CU shall support functionalities
associated with network slicing. The O-CU-UP may either be built as a single
instance for each network slice or it can be shared across many slices
depending on the individual requirements of each slice [16]. The O-RAN
architecture extends network slicing functionalities and features beyond those
defined by the 3GPP by leveraging the E2 interface and dynamic slice
optimizations provided by the Near-RT RIC [114]. Moreover, the O1 interface
supports more configuration parameters related to network slicing in order to
further enhance the capabilities of the O-RAN architecture. The O-CU is also
expected to carry out slice-specific resource allocation and isolation
measures using slice awareness capabilities. These nodes are first configured
using the O1 interface according to the requirements of the individual slices,
and they are subsequently modified for different slicing use-cases dynamically
by the Near-RT RIC through the E2 interface. The O-CU may need to create and
send certain performance metrics (PMs) across the O1 and E2 interfaces in
response to requests for PMs from the SMO Framework and the Near-RT RIC. These
PMs can be utilized for slice performance monitoring and slice SLA assurance
[52, 115].

####  III-B2 O-RAN Distributed Unit

The O-DU is a logical node that hosts the lower layer protocols of the RAN
stack and serves as a baseband processing unit that handles the high PHY, MAC,
and radio link control (RLC) layers [116]. The O-DU can be provided in the
form of a virtualized network function (VNF) that can be hosted within a
virtual machine or a container at the edge cloud [16]. It terminates the E2,
F1, and O-FH interfaces. In addition, it terminates the RLC, MAC, and high-PHY
functionalities of the radio interface towards the UE and the O1 interface
towards the SMO Framework [22, 52]. The O-DU is meant to link with numerous
O-RUs. It terminates the Open FH M-Plane interface towards the O-RU, allowing
for hierarchical or hybrid O-RU administration within O-RAN.

The O-DU supports slice-specific resource allocation strategies in the O-RAN
slicing-aware architecture. The MAC layer needs to allocate and isolate the
relevant physical resource blocks (PRBs) to specific network slices according
to the O1 configuration of a PRB allocation along with O-CU directives over
the F1 interface and the dynamic guidance received from the Near-RT RIC
through the E2 interface [117]. Similar to the O-CUs, the O-DUs must also
generate and send specific PMs through the O1 and E2 interfaces according to
the requests from the SMO Framework and the Near-RT RIC, respectively. These
PM can be used for the purpose of network slice performance monitoring and
slice SLA assurance [52].

####  III-B3 O-RAN Radio Unit

The O-RU is a physical node that houses the low-PHY layer and radio frequency
(RF) processing functionalities within an O-gNB, considering the lower layer
functional split option [12]. The O-RU serves as the endpoint for both the
O-FH interface and the low-PHY functionalities of the radio interface that
connect to the UEs. It also terminates the O-FH M-Plane interface towards the
O-DU and/or the SMO Framework based on the deployment options. A single O-RU
is supposed to serve multiple network slice instances [118].

####  III-B4 O-eNB

The O-RAN architecture also incorporates the ability to integrate long term
evolution (LTE) base stations, referred to as O-eNB within the O-RAN Alliance
terminology. The O-eNB can take the form of either an evolved NodeB (eNB) or
an next generation eNB (ng-eNB). The corresponding interfaces and protocols
must also be supported by the O-RAN architecture. To ensure O-RAN
compatibility, it is essential to support both the E2 and O1 interfaces to the
O-eNB [22].

####  III-B5 E1 Interface

The E1 interface acts as a control interface, linking the O-CU-CP and O-CU-UP
entities within an O-gNB or O-eNB [119]. This interface is standardized by the
3GPP and plays a pivotal role in the O-RAN architecture, promoting efficient
communication and operation. The utilization of standardized interfaces not
only ensures the efficiency of the O-RAN architecture but also offers
flexibility and scalability for future developments and advancements [120].

####  III-B6 F1 Interface

The F1 interface is used to connect the O-CU and O-DU within an O-gNB [119].
The O-RAN employs the principles and protocol stack defined by the 3GPP for
the F1 interface, as well as the formulation of interoperability profile
specifications. Mirroring the O-CU’s division into user plane and control
plane, the F1 interface also comprises two distinct components: F1-C and F1-U
[22].

##### F1-C

The F1-C interface handles control and signaling functions. It manages the
exchange of control information between the O-CU-CP and the O-DU. Control
plane functions typically involve activities such as setting up and releasing
connections, managing handovers, and coordinating radio resource allocation.

##### F1-U

The F1-U interface is responsible for the actual user data transmission. It
handles the transfer of user data between the O-CU-UP and the O-DU, playing a
critical role in the efficient and reliable transport of user data between the
O-RAN components.

####  III-B7 W1 Interface

The W1 interface for the functional split of the eNB is specified in 3GPP
Release 15. An ng-eNB comprises ng-eNB-CU and ng-eNB-DUs. These components,
ng-eNB-CU and ng-eNB-DU, are linked through the W1 logical interface, which
enables the separation of control plane and user plane functionalities with
W1-C, and W1-U, respectively [121].

####  III-B8 X2 Interface

The O-RAN has inherited the X2 interface from the 3GPP for the definition of
interoperability profile specification and used to connect the O-CU with other
eNBs in an E-UTRA NR dual connectivity (EN-DC) configuration. The X2-C and
X2-U are two parts of the X2 interface for transmitting the control plane and
user plane information, respectively [22].

####  III-B9 Xn Interface

The O-RAN has adopted the principles and protocol stack of Xn interface,
defined by 3GPP, for the definition of interoperability profile specification.
The Xn interface contains separate components Xn-C and Xn-U to connect the
O-CU-CP and O-CU-UP, respectively, to other gNBs [22].

####  III-B10 NG Interface

The NG interface is also an interface adopted by the O-RAN from the 3GPP to
connect the O-CU and the 5G Core (5GC). The NG interface also has two
components, NG-C and NG-U, for the control and user planes, respectively. The
NG-C interface connects the O-CU-CP with the access and mobility management
function (AMF), while the NG-U provides a link between the O-CU-UP and the
user plane function (UPF) in the 5GC [22].

####  III-B11 Uu Interface

The 3GPP designates the interface between the UE and the e/gNB as the Uu
interface. The Uu interface encompasses a comprehensive protocol stack
spanning from Layer 1 to Layer 3, constituting a complete entity that
terminates within the NG-RAN architecture. When the NG-RAN is decomposed,
various protocols conclude at distinct reference points, none of which has
been explicitly defined by the O-RAN Alliance. Since the Uu messages still
continue to travel from the UE to the targeted e/gNB managed function, the
O-RAN architecture does not represent it as a distinct interface directed to a
specific managed function [22].

####  III-B12 Y1 Interface

The Near-RT RIC offers RAN analytics information services through the Y1
service interface to an authorized third party, called the Y1 consumer. These
services are accessible to Y1 consumers upon mutual authentication and
authorization. To access RAN analytics information, Y1 consumers within a
public land mobile network (PLMN) trusted domain can subscribe to or request
services via the Y1 service interface. Entities outside the PLMN trusted
domain, acting as Y1 consumers, can securely utilize Y1 services through a
standardized exposure function. Y1 consumers, unlike the other network
elements as shown in Figure 2, are not denoted as logical O-RAN functions
[22].

####  III-B13 Open Fronthaul Interface

The O-RAN FH Specification outlines the splitting and virtualizing the
conventional cell site, transforming it into an efficient system for the FH,
MH, and BH with enhanced capacity, speed, and latency in the next-generation
cellular networks. The physical layer is separated into high-PHY and low-PHY
components, employing the functional split to outline the architecture of a
disaggregated and virtualized gNB. The low-PHY resides in the O-RU while the
high-PHY is hosted in O-DU [122]. The Open FH Interface establishes a
connection between the O-DU and O-RU logical nodes, encompassing both the CUS-
Plane and M-Plane [123, 124].

##### C-Plane

Control Plane specifically refers to the real-time control interactions
between the O-DU and O-RU. C-Plane messages facilitate the exchange of data-
associated control information necessary for processing user data, such as
scheduling and beamforming commands, if such information is not supplied via
M-Plane. These messages are transmitted for downlink and uplink commands
independently. To enhance flexibility, C-Plane messages may be sent
collectively or individually, depending on the relevant channel for conveying
the information [124].

##### U-Plane

User Plane pertains to the transfer of in-phase and quadrature (IQ) sample
data between O-DU and O-RU. To ensure coordination of C-Plane and U-Plane
timing, the FH interface specifies that C-Plane messages must reach the O-RU
ahead of the latest possible time for the first corresponding U-Plane
messages. U-Plane messages will be encapsulated using a two-layered header
approach, where the first layer includes an evolved CPRI (eCPRI) or IEEE
1914.3 common header indicating the message type, and the second layer is an
application layer containing essential fields for control and synchronization
[124, 122].

##### S-Plane

Synchronization Plane is concerned with the communication between the O-RU or
O-DU and a synchronization controller, typically an IEEE 1588 Grand Master,
that may be integrated into the O-DU. O-RAN encompasses the synchronization of
frequency, phase, and time across all network elements O-DUs, intermediate
switches, and O-RUs for both time division duplexing (TDD) and frequency
division duplexing (FDD) features [124].

##### M-Plane

Management Plane refers to non-real-time management operations between the
O-DU and the O-RU. Different modes of network connectivity between the O-RU
and the O-DU, as well as the SMO Framework, are possible based on the
transport topology. The fundamental requirement for the M-Plane is to
establish E2E connectivity between the O-RU and the entities responsible for
its management, including the O-DU, SMO Framework, or entities referred to as
the O-RU Controllers.

The Open FH M-Plane employs a NETCONF/YANG-based system to manage various
features such as installation, software, configuration, performance, fault,
and file management for the O-RU. Two architectural models are supported for
this: First, the hierarchical model, where one or more O-DUs manage the O-RU
via a NETCONF-based interface. Second, the hybrid model, which allows direct
logical interfaces between the management systems, such as the SMO Framework
and the O-RU, in addition to the logical interface between the O-DU and the
O-RU. For Multi-Operator O-RU, various architecture models involving different
Shared Resource Operators are supported. In the hybrid model, the O-RU
establishes E2E connectivity with the SMO, either through the O-DU or with
direct logical communication. Importantly, there is no explicit signaling
indicating hierarchical or hybrid configuration, and all NETCONF servers
supporting the M-Plane specification must handle multiple sessions, with all
the O-RUs capable of supporting both hierarchical and hybrid deployment [123].

###  III-C RAN Intelligent Controller

The RAN intelligent controller (RIC) stands out as a significant advancement
within the O-RAN architecture [125]. It epitomizes a software-defined NF to
handle aspects of the eNB or gNB functionality, such as mobility management,
traditionally confined to the base stations. By offering real-time visibility
and control over O-RAN resources, the RIC plays pivotal role in the O-RAN
disaggregation strategy, introducing essential features like multivendor
interoperability, intelligence, agility, and programmability, thereby
reshaping the O-RAN landscape [125, 126]. Its integration into the O-RAN
architecture empowers network operators to manage and optimize O-RAN resources
in a flexible and intelligent manner [127], which is also very essential to
realize the network slicing.

In addition, it configures network slices, orchestrates network operations,
checks network performance, and instantly optimizes the RAN resources in real
time by utilizing the open interfaces [126, 128]. As depicted in Figure 2, the
RIC manifests in two distinct forms, each meticulously designed to cater to
specific control loop dynamics and latency requirements. These two variants,
namely the Non-RT RIC and the Near-RT RIC, play critical roles within the
O-RAN architecture [122]. In the subsequent sections, an exhaustive
exploration of both types of RIC will be provided, elucidating their
functionalities, applications, and significance within the broader context of
network optimization and management.

####  III-C1 Near-Real-Time RAN Intelligent Controller

The Near-RT RIC serves as a logical entity, facilitating precise and close-to-
real-time control and optimization of the E2 nodes and resources. The Near-RT
RIC resides close to the O-gNB and interacts with them to optimize its
functionalities [129]. It achieves this through meticulous data collection and
actions performed via the E2 interface [127]. Operating seamlessly within a
near-real-time control loop, the Near-RT RIC adheres to a time span ranging
from 10 milliseconds to 1 second [130]. It functions as a software framework
tailored for hosting xApps, which are intelligent, autonomous, and
microservice-based applications [131].

During onboarding, these xApps can identify the data they collect, process,
consume, and provide [22]. The Near-RT RIC assumes the responsibility of
managing and optimizing O-RAN resources in near-real-time to meet the dynamic
and diverse requirements of various applications and services [17]. This
optimization is achieved by integrating xApps, deployable to the Near-RT RIC
as needed, to offer specific functionalities such as radio resource management
(RRM) [131, 60]. These xApps leverage UE and cell-specific metrics collected
through the E2 interface to optimize O-RAN resources and functionalities in
real time, ensuring efficient utilization of network resources and an enhanced
user experience [132, 112].

Furthermore, the Near-RT RIC gains direct control over the E2 nodes and their
resources through policies and information transmitted via the A1 interface
from the Non-RT RIC [130, 133]. In specific scenarios, the Near-RT RIC has the
authority to monitor, suspend, stop, override, or control an E2 node based and
its resources on rules associated with a function exposed in the E2 service
model [134, 22].

The Near-RT RIC plays a crucial role in facilitating network slicing within
the O-RAN architecture. Specifically, it empowers near-real-time optimization
of O-RAN slice subnets through the utilization of xApps. This optimization
involves communication with O-CU and O-DU via the E2 interface. To ensure
efficient operation, xApps must possess awareness of O-RAN slices, allowing
them to employ slice-aware algorithms for the assurance of network slice SLA
[52]. In response to this challenge, a growing body of research has emerged
proposing xApps for various optimization problems within the O-RAN
architecture. Several notable examples can be found in [132], [108], and
[135], where authors present an array of xApps tailored to specific
applications.

The xApps leverage AI/ML models guided by A1 policies and generated by the
Non-RT RIC [57, 26]. These policies serve as a foundation for intelligent
decision-making within the network. When O-RAN slices are operational, slice-
specific PMs are gathered from the E2 nodes and subsequently transmitted to
the Near-RT RIC. The Near-RT RIC integrates this information with slice
configuration data, facilitating dynamic optimization of the slices. This
collaborative approach between the Non-RT RIC and Near-RT RIC associated with
AI/ML is aimed at enhancing the overall efficiency of network slicing within
the O-RAN architecture [5, 130].

####  III-C2 Non-Real-Time RAN Intelligent Controller

The Non-RT RIC stands as a core component of the O-RAN architecture. It is
responsible for non-real-time management and optimization of the O-RAN
components and resources [112]. As illustrated in Figure 2, the Non-RT RIC
also facilitates the execution of third-party applications known as rApps.
These modular software applications are designed to use the capabilities
offered by the Non-RT RIC Framework’s R1 interface to provide additional value
services related to O-RAN operation [54]. Examples include driving the A1
interface and suggesting values and actions for potential implementation via
the O1 and the O2 interfaces [22].

The Non-RT RIC autonomously configures all O-RAN components, eliminating the
need for network operator intervention. The MNOs can leverage the Non-RT RIC
to gain insights into network operations and optimize them in real-time [129].
Its functionality is intrinsic to the SMO Framework within the O-RAN
architecture and offers an A1 interface to the Near-RT RIC. The Non-RT RIC can
employ data analytics and AI/ML model training to develop RAN optimization
actions, leveraging SMO services like data gathering and provisioning services
provided by O-RAN nodes [136]. The Non-RT RIC distributes trained models to
the Near-RT RIC for runtime execution. The Non-RT RIC is responsible for
applying the AI/ML algorithms to deliver innovative use-cases within the O-RAN
architecture [137]. Therefore, the Non-RT RIC is a key component in O-RAN,
delivering highly complex functionalities related to the O-RAN slicing.

The Non-RT RIC retrieves slice-specific PM and configuration parameters, along
with optional internal information, from the servers. The learning
capabilities of AI/ML models can tackle complex problems, such as applying RRM
policies [112]. Training models enable non-real-time optimization of slice-
specific parameters over the O1 interface. The collected information and
performance metrics are sent to the Near-RT RIC. The Near-RT RIC can use this
PM, configuration, and other data for dynamic slice optimization to prevent
potential SLA violations between network slices [31]. Furthermore, the Near-RT
RIC controls the network resources through the E2 interface, and the Non-RT
RIC controls the cloud resources through the O2 interface based on decision
made by the collected information [138].

####  III-C3 R1 Interface

The R1 interface resides within the internal structure of the Non-RT RIC.
Through this interface, the Non-RT RIC framework provides services that
empower rApps to access data for initiating intelligent policy decisions and
optimizing O-RAN operations. Additionally, rApps utilize the R1 interface to
exchange authorized enrichment data with the Near-RT RIC and to share services
and analytics within the Non-RT RIC framework [139, 138].

####  III-C4 A1 Interface

The A1 interface, defined by the O-RAN Alliance, serves to link the Near-RT
RIC with the Non-RT RIC. Through the A1 interface, the Non-RT RIC can provide
policy guidance to the Near-RT RIC, referred to as A1 policies [45]. The Near-
RT RIC components communicate with the A1 policy functions implemented over
the A1 interface. These A1 policy functions utilize the A1 interface to
facilitate the provisioning of policies for specific UE or groups of UEs,
monitor policy states, provide basic feedback from the Near-RT RIC, offer
enrichment information as required by the RICs, and streamline the training,
distribution, and inference of ML models [140, 45]. Slicing use-cases, such as
slice SLA assurance, can utilize these services. For example, the Non-RT RIC
can employ policy management via the A1 interface to transmit slice-specific
policies, guiding the Near-RT RIC in slice resource allocations and slice-
specific control activities, while also receiving slice-specific policy
feedback [52].

####  III-C5 E2 Interface

The E2 interface serves as the connection point between the Near-RT RIC and E2
nodes, offering support for E2 primitives such as Report, Insert, Control, and
Policy. These primitives empower both RICs to manage the services provided by
the E2 nodes, enabling control over procedures and functionalities.
Specifically, the Near-RT RIC, with a focus on xApps, manages specific
operations within E2 nodes, necessitating the deployment of an E2 agent at the
node [130].

E2 nodes communicate information to the Near-RT RIC via the E2 interface,
notifying it about functions that xApps may handle [31, 133]. Furthermore, the
E2 node’s interface facilitates the collection of measurements from the O-RAN
to the Near-RT RIC, either periodically or in response to predetermined
trigger events. This interface connects one or more cells, slices, QoS
classes, or specific UEs to both control and data collection operations [141].

Slice-specific xApps utilize these primitives to influence the configurations
and behaviors of E2 nodes related to slices. Examples include RRM, radio
resource allocations, MAC scheduling policies, and other configuration
parameters embedded in various O-RAN protocol stacks. The RIC employs the E2
interface for configuring and receiving slice-specific reports and performance
data from the E2 nodes [136, 52].

###  III-D The SMO Framework and its Corresponding Interfaces

In alignment with the primary objectives of the O-RAN Alliance, the 5G RAN
architecture is expected to be highly flexible, reliable, scalable, and
interoperable across multiple vendors for diverse deployment scenarios. It
operates on COTS white box hardware in a cloud-native and virtualized
infrastructure, leveraging automation mechanisms as well as AI and ML
algorithms [104]. Therefore, the automation and intelligentization of the
management and orchestration of the O-RAN architecture take up the utmost
significance [142]. The autonomous management and orchestration of the O-RAN
components are executed by the SMO Framework. The SMO Framework is a set of
integrated MFs and services presented within the O-RAN architecture [48], as
shown in Figure 2. It encompasses the management systems and functions of
various SDOs. The SMO Framework utilizes standardized service-based management
interfaces to enable interoperability among the MFs of various SDOs within the
SMO Framework [48]. Operating on the principle of services based architecture
(SBA), the SMO Framework facilitates the provision and consumption of services
such as authentication, authorization, service registration and discovery,
data management, and trained model sharing, among others [22].

The SMO Framework manages the FCAPS operations for O-RAN components via the O1
interface. It enables intelligent optimization and RRM via the Non-RT RIC,
administers O-Cloud functionalities via the O2 interface, and provides
platform resources and workload management. To execute functionalities
associated with FCAPS, particularly from the SMO Framework to O-RU, an Open FH
M-Plane interface is employed. The interface linking the Non-RT RIC and Near-
RT RIC is denoted as the A1 interface. The Non-RT RIC acquires data from
various components of O-RAN, develops or selects ML models, and transmits them
to the Near-RT RIC via the A1 interface. The A1 interface is capable of
supporting three service types: policy management, information enhancement,
and ML model management [143, 10, 52].

The design of the SMO Framework, particularly the Non-RT RIC, allows for
flexibility in implementation. This signifies that operators will have the
ability to select which features to include or exclude in a Non-RT RIC
implementation. The SMO Framework can also be connected to an E2E multi-domain
service orchestrator, which connects domain-specific modules used by the SMO
Framework to coordinate the network slices in each subnet (e.g., RAN, TN, and
CN). This E2E Framework enables the on-demand creation and E2E management of
network slices across a distributed 5G infrastructure. The SMO Framework can
include and shall also meet the architectural requirements of the 3GPP, ETSI,
and ONAP for network slicing using a set of MFs based on their respective
specifications.

The MFs of these SDOs within the SMO Framework perform tasks such as creating,
operating, modifying, and terminating an network slice, as well as scaling the
underlying resources. The O-RAN Alliance preserves the network slicing
concepts, procedures, and functionality of architectural components defined by
the 3GPP, ETSI, and other related SDOs. The O-RAN architecture keeps
consistency with 3GPP in terms of the architectural design and positioning of
network functions to the most possible extent but defines some general
principles on top of the network slicing principles of the aforementioned
SDOs. For instance, interface specifications shall be compatible with 3GPP,
standardized management service interfaces for O-RAN slicing management
services shall be provided, multi-vendor interoperability shall be given,
various network operator deployment options shall be supported, as well as
management of slice subnets in multi-operator scenarios shall be provisioned.

####  III-D1 O1 Interface

The O-RAN managed elements and the management entities within the SMO
Framework are logically connected through the O1 interface, as shown in Figure
2. The goal of utilizing the O1 interface is to guarantee the operation and
management of the O-RAN components, including FCAPS, software management, and
file management, among many others. The O-CU, O-DU, and Near-RT RIC are among
the major components managed by the O1 interface and enable the SMO Framework
to access O-RAN NFs [144].

In O-RAN slicing, the O1 interface may be used for the configuration of O-RAN
nodes with slice-specific parameters according to the service requirements of
an network slice. The 3GPP has defined a slice-specific information model that
includes RRM policy attributes to provide the ratio of PRBs among slices [34].
These models can be extended with additional information models to capture
slice profiles and slice-specific configuration parameters to support the
O-RAN slicing use-cases that also carry over the O1 interface. The interface
may be further used for the collection of slice-specific performance metrics
and faults from the O-RAN nodes [52].

####  III-D2 O2 Interface

The O2 interface serves as an open logical interface that enables secure
communication between the SMO Framework and O-Cloud sites, as introduced in
[145]. It enables the life cycle management of VNFs that operate on O-Cloud
infrastructure. The O-RAN functionalities within the network are hosted by the
O-Cloud infrastructure, utilizing the O2 interface in SMO Framework to
facilitate cloud infrastructure management and deployment processes. The O2
interface supports the orchestration of O-Cloud infrastructure resource
management, such as inventory, monitoring, provisioning, software management,
and life cycle management. It also facilitates the deployment of O-RAN NFs,
offering logical services for controlling the deployment life cycle that make
use of cloud resources. While the Non-RT RIC may be instantiated with other
SMO functions as part of the SMO Framework, the O2 interface is not expected
to be utilized for the life cycle management of the Non-RT RIC. The O2
interface is designed to be expandable, so new data or features can be
introduced without necessarily altering the protocol or the processes. This
interface supports a multi-vendor environment and is unaffected by particular
SMO Framework and O-Cloud implementations. By rearranging network components,
updating the system, or upgrading the system, operators who are linked to the
O-Cloud may then manage and run the network using the O1 or/and O2 interfaces
[146].

####  III-D3 3GPP Network Slicing MFs within the SMO Framework

The 3GPP-defined MFs for the management and orchestration of network slicing
are the CSMF, NSMF, NSSMF, and network function management function (NFMF).
These MFs can be employed within the SMO Framework, considering the
requirements defined by the 3GPP for network slicing. Furthermore, several
functional and non-functional requirements for network slicing architecture
have also been defined by the O-RAN Alliance in [52]. Both sets of
requirements defined by the 3GPP and O-RAN Alliance are critical for the
realization of network slicing in O-RAN architecture and the functionalities
of the 3GPP MFs. The provision of management service (MnS) for a mobile
network, which encompasses network slicing, can be achieved through a
collection of functional blocks as illustrated in Figure 3.

Figure 3: 3GPP Management Architecture within the SMO Framework

In the following, we elaborate on the previously mentioned 3GPP MFs and their
role in the realization of management and orchestration of O-RAN slices.

  * •

Communication service management function (CSMF): This MF translates the
communication service requirements received from third parties – such as
operations support system (OSS)/business support system (BSS), network slice
as a service (NSaaS) tenants, and others – into network slicing requirements
[147].

  * •

Network slice management function (NSMF): The NSMF is in charge of managing an
E2E network slice after the CSMF determined its required requirements. It
manages the resources required for hosting the communication services and
interacts with the NSSMFs responsible for managing the Network Slice Subnet in
that domain [148, 147].

  * •

Network slice subnet management function (NSSMF): The NSSMF in each network
domain (i.e., RAN, transport, and core) instantiates the required resources
based on the instructions of the NSMF. Each NSSMF orchestrates the domain-
specific resources on its subnet to meet the service requirements in that
subnet. For example, the RAN NSSMF is responsible for orchestrating the RAN
portion of a network slice, such as life-cycle management, configuration
management, performance management, and fault management of RAN slice subnets.
Furthermore, the RAN NSSMF interfaces with the RIC for control plane
operations related to O-RAN slices within the O-RAN architecture [148, 147].

  * •

Network function management function (NFMF): The NFMF offers NF management
services within the NF management model. It manages multiple NFs and handle
the application-level management of both VNF and physical network function
(PNF) [48]. Additionally, it produces the NF provisioning service, which
includes configuration management, Fault management, and performance
management. At the same time, the NFMF consumes the NF provisioning service
provided by VNFs and PNFs [148].

To provide seamless management and orchestration solutions, the SMO Framework
can be customized to incorporate either all or some of the 3GPP-defined MFs
mentioned earlier. The decision regarding the inclusion of these MFs pertains
to deployment considerations, which we discuss in Section IV.

####  III-D4 NFV-MANO within the SMO Framework

The network functions virtualization management and orchestrierung (NFV-MANO)
Framework is specified by the ETSI industry specification group (ISG) on NFV.
The SMO Framework can also include the NFV-MANO [27]. Within the context of
the SMO Framework, the NFV-MANO is responsible for the management and
orchestration of the VNFs and virtual resources of an O-RAN slice. The NFV-
MANO originally consisted of three functional blocks: the network function
virtualization orchestrator (NFVO), the virtual network functions manager
(VNFM), and the virtualized infrastructure manager (VIM). It also included an
element management (EM). In Release 4, the ETSI ISG NFV added five new MFs in
order to manage the containerized and transport aspects within the NFV-MANO
Framework [149, 150]. Figure 4 illustrates all these functional blocks as well
as the newly added MFs.

Figure 4: NFV-MANO Architecture within the SMO Framework

In the following, we discuss these MFs and functional blocks (FBs), as well as
the application within the SMO Framework, in a detailed manner.

  * •

Network function virtualization orchestrator (NFVO): The NFVO has two primary
responsibilities: Firstly, it orchestrates NFV infrastructure (NFVI) resources
across multiple VIMs fulfilling resource orchestration functions. Secondly, it
manages the lifecycle of network services by performing network service
orchestration functions, which include coordinating groups of VNF instances to
collectively achieve a more complex function. The NFVO facilitates joint
instantiation and configuration of these instances, establishes required
connections between different VNFs, and manages dynamic configuration changes,
such as scaling the capacity of the network service. The network service
orchestration function relies on services provided by both the VNFM function
and the resource orchestration function. The NFVO uses resource orchestration
functionality to offer services that allow abstracted access to the NFVI
resources independently of specific VIMs. Additionally, it governs VNF
instances sharing resources within the underlying NFVI [148, 149].

  * •

Virtual network functions manager (VNFM): The VNFM is responsible for the
lifecycle management of one or more VNF instances within an network slice
[150]. The VNFs can be of the same type or different types. The VNFM is also
responsible for the FCAPS of the VNFs, and scaling up and down the VNFs in its
service region [149].

  * •

NFV infrastructure (NFVI): The NFV considers software or hardware accelerators
as supplementary resources capable of virtualization, which can be exposed as
virtual accelerators within the VNF layer [151]. The NFVI includes all the
underlying components of the infrastructure, comprising both the hardware and
software necessary for hosting VNFs. It presents infrastructure resources in a
virtualized form for utilization by VNFs and network services, encompassing
virtual compute, virtual storage, and virtual network resources [149].
Nevertheless, it is essential to note that existing NFV-MANO specifications do
not comprehensively address NFVI management aspects, especially concerning the
management of physical infrastructure within the cellular network. As a
result, complete support for full infrastructure management service (IMS)
functionality is not achievable under the current specifications [151].

  * •

Virtualized infrastructure manager (VIM): The VIM is tasked with controlling
and managing the computing, storage, and network resources of the NFVI within
the underlying telecommunication infrastructure [150]. It is important to note
that the actual deployment and maintenance of the VIM falls outside the scope
of NFV-MANO. Nevertheless, the interfaces provided by VIM are within the scope
[149]. Hence, the NFV-MANO utilizes this interface to influence the decisions
made regarding the three types of resources within the underlying
infrastructure layer.

  * •

Element management (EM): The EM, which is equialent to the NFMF within the
3GPP management system, manages the FCAPS of a VNF from a functional and
application points of view. It is worth noting that the VNFM also manages the
FCAPS of a VNF, but exclusively from a virtualization perspective [149].

  * •

Container infrastructure service (CIS): In the container-based NFV-MANO, the
CIS is the execution environment for a container cluster where the container-
based services run [149]. As ETSI NFV Release 4 promotes enhanced
functionalities, CIS is becoming increasingly crucial for efficient and agile
containerized network deployments.

  * •

CIS management (CISM): The CISM is responsible for the management and
orchestration of CIS instances and CIS archival within the NFV-MANO. It
interacts with other NFV-MANO components like the VNFM and Orchestrator,
providing an abstraction layer for CIS functionalities. Its capabilities
encompass container network, workload, compute, and storage management, along
with container configuration executed by CIS [149].

  * •

CIS cluster management (CCM): The CCM function is responsible for handling the
lifecycle and operation, as well as configuration, performance, fault, and
resource management, of the CIS cluster within the NFV-MANO [149]. It acts as
the bridge between the orchestrator (overall NFV service provisioning) and the
underlying CIS instances within the cluster.

  * •

Container image registry (CIR): The CIR is responsible for container image
management [149]. It is an internal repository used by the NFV-MANO to store
and manage container images specific to their containerized network functions
(CNFs) deployments. The CIR is also responsible for implementing security
measures to control access and ensure image integrity, version control and
lifecycle management of container images, and integration with continuous
integration (CI)/continuous deployment (CD) pipelines for building and pushing
new images.

  * •

WAN infrastructure manager (WIM): The WIM provides management and
orchestration services for multi-site connectivity service (MSCS). It
establishes connectivity between the NFVI-point-of-presences (PoPs) using MSCS
which abstracts the details of the connections on the transport network [149].
The NFVI-PoP is an ETSI’s terminology, which is a synonym for O-Cloud O-RAN.

####  III-D5 ONAP Architecture within the SMO Framework

ONAP provides a comprehensive platform to network operators, cloud service
providers, and businesses for the orchestration, management, and automation of
network and edge computing services and resources. Faster automation of new
services and full lifecycle management, which are essential for 5G and beyond,
are made possible by real-time, policy-driven orchestration and automation of
PNFs and VNFs [152]. Figure 5 illustrates a simplified ONAP architecture from
a functional perspective. The ONAP design time environment facilitates the
onboarding of services and resources into ONAP, along with the design of
necessary services. On the other hand, the ONAP runtime environment operates
as a model- and policy-driven orchestration and control framework, automating
the instantiation and configuration of services and resources.

The components of the ONAP architectural framework are briefly discussed in
the following.

Figure 5: ONAP Architecture: Microservices Interaction Diagram

  * •

ONAP operations manager (OOM): The OOM is responsible for the complete life
cycle management and orchestration of ONAP components. Furthermore, OOM
contributes to the advancement of ONAP maturity by introducing scalability and
resiliency enhancements to the components under its management.

  * •

Use case user interface (UUI): The UUI operations facilitate a broader
spectrum of lifecycle management actions using a simple point-and-click
interface, enabling operators to execute tasks more easily [153].

  * •

Service orchestrator (SO): The SO automates sequences of activities, tasks,
rules, and policies to execute specified processes required for the on-demand
creation, modification, or removal of network, application, or infrastructure
services and resources. Operating at a high level, the SO offers orchestration
with a comprehensive view of the infrastructure, network, and applications
[87].

  * •

ONAP optimization framework (OOF): The OOF offers a declarative and policy-
driven method for developing and executing optimization applications such as
homing/placement and change management scheduling optimization [87].

  * •

Service design and creation (SDC): The SDC offers tools, methods, and
repositories for defining, simulating, and certifying system assets along with
their corresponding processes and policies. These assets are categorized into
four groups: resources, services, products, or offers. The SDC environment
caters to a variety of users through shared services and utilities. Within the
design studio, designers of products and services can onboard, extend, or
retire resources, services, and products [154].

  * •

Active and available inventory (AAI): The AAI offers real-time and historical
views of a system’s resources, services, products, and their
interrelationships. It integrates data from multiple ONAP instances, BSS, OSS,
and network applications, providing a comprehensive ”top to bottom” view from
end-user products to the underlying resources. AAI serves as a dynamic
registry, continuously updated by controllers in real-time to support the
flexibility of SDN/NFV. The metadata-driven nature of AAI allows for the rapid
addition of new inventory types through SDC catalog definitions, eliminating
the need for lengthy development cycles.

  * •

Common controller software development kit (CCSDK)/ SDN controller (SDN-C):
The CCSDK/ SDN-C handle specific configurations for both the RAN and transport
subnets of a network slice. When requested by SO from TN NSSMF, it sets up and
configures the new transport network slice subnet instance (NSSI), including
updating the transport network during network slice instances (NSI) reuse,
activation/deactivation, and termination. Similarly, when invoked by the SO
from RAN NSSMF, it configures/re-configures the existing RAN NFs for RAN NSSI
or NSI reuse. Additionally, when policy triggers closed loop actions in RAN
for RAN NSSIs, it sends relevant configuration updates to the Near-RT RICs
[87, 154].

  * •

Controller design studio (CDS): The CDS framework provides blueprint
definitions and archives for configuration management processes. It comprises
a graphical user interface (GUI) and run time components. The GUI manages user
input and displays both design time and run time activities. It facilitates
the creation of controller blueprints, including selecting design guidelines,
incorporating artifact templates, and adding components. For run time, it
allows user to direct the system to resolve the unresolved elements in the
blueprint and downloads the resulting configuration into a VNF. It also
enables the creation of data dictionaries, capabilities catalogs, and
controller blueprints. The primary role of the Controller Design Studio is to
generate and populate a controller blueprint, create a configuration file, and
download it to a VNF/PNF [154, 153].

  * •

Data collection, analysis and event (DCAE): DCAE, in collaboration with other
ONAP runtime components, provides closed control loop automation, delivering
FCAPS functionality. DCAE plays a key role in gathering performance, usage,
and configuration data, conducting analytics computations, aiding in
troubleshooting, and disseminating events, data, and analytics to entities
like policy, orchestration, and the data lake. Working with the policy
framework and closed loop automation management platform (CLAMP), these
components detect network issues and suggest appropriate remediation. Actions
can be automatic or trigger notifications to the SO or controllers for
intervention, as configured by the operator. The policy framework is expanded
to include additional decision capabilities through adaptive policy execution
[153].

  * •

Policy Framework: The Policy Creation component focuses on handling policies,
encompassing rules, conditions, requirements, constraints, attributes, or
needs that require provision, maintenance, and enforcement. At a granular
level, policies involve machine-readable rules for executing actions based on
triggers or requests, considering specific conditions. This enables the rapid
modification of policies by updating rules, facilitating the adjustment of
technical behaviors without rewriting software code. Policy simplifies the
management and control of complex mechanisms through abstraction [153].

  * •

External API: The External API offers northbound interoperability for the ONAP
platform, serving as an access point for third-party frameworks and
facilitating interactions between operator BSS and relevant ONAP components.
This abstracted view of the platform within the existing BSS/OSS environment
eliminates the need for lengthy and high-cost infrastructure integration [87].

###  III-E The Underlying O-Cloud and O-Transport Infrastructure

The underlying infrastructure of O-RAN comprises the O-Cloud sites, the
cellular sites (which include the Regional Cloud and Edge Cloud Sites), and
the transport network. The two cloud sites and cellular sites are used to host
the O-CU, O-DU, and O-RU of an O-RAN slice, respectively. The transport
network is responsible for providing connectivity between several virtual or
physical NF of an O-RAN slice deployed at cellular and/or cloud sites. In this
section, we provide a brief overview of these major components of the
underlying infrastructure in the O-RAN architecture.

####  III-E1 Cellular Site

A cellular network site refers to the locations of O-RUs, which may be
colocated on the same structure as the O-RU or situated at the base.
Typically, the cellular network site is designed to accommodate multiple
sectors, thereby supporting several O-RUs. These sites play a pivotal role in
the O-RAN architecture, serving as the points of connection between the O-RAN
architecture and the core network infrastructure. They facilitate the
transmission of data, control signals, and synchronization information between
the radio units and the O-DU. The cellular network sites are distributed
uniformly or non-uniformly based on parameters such user density, network
topology, and others. They are classified as Macro, Micro, Pico, and Nano
cellular network sites.

####  III-E2 Cloud Site

A Cloud Site denotes a tangible location equipped with Cloud Infrastructure
resources, suitable for O-Clouds, and possibly accommodating other non-O-Cloud
resources. O-Clouds are deployed at both Regional Cloud and Edge Cloud
locations. These sites serve as centralized points for hosting VNFs, SDN
controllers, and other cloud-native applications within the O-RAN
architecture. The Regional Cloud provides broader coverage and higher
capacity, while the Edge Cloud brings computational resources closer to the
network edge, enabling low-latency and high-bandwidth services.

##### Edge Cloud

Edge Cloud refers to a site that facilitates virtualized RAN functions for
numerous cellular sites, offering centralized functions for those sites.
Depending on the operator’s use case, an Edge Cloud may cater to a vast
physical area or a relatively small one in proximity to its cellular sites.
Nevertheless, the sites served by the Edge Cloud must be sufficiently close to
the O-RUs to meet the network latency requirements of the O-DU functions. This
proximity ensures that communication between the radio units and the O-DUs
occurs with minimal delay, enabling efficient and responsive network
operations and service delivery.

##### Regional Cloud

Regional Cloud designates a site supporting virtualized RAN functions for
numerous cellular sites across multiple Edge Clouds, offering extensive
centralization of the functionality. The sites served by the Regional Cloud
need to be sufficiently close to the O-DUs to fulfill the network latency
requirements of both the O-CU and the Near-RT RIC. This proximity ensures that
communication between the O-CU and O-DU, as well as the Near-RT RIC, occurs
within the required latency thresholds. It enables effective coordination and
optimization of RAN resources across a broader geographical area while
maintaining operational efficiency and responsiveness.

####  III-E3 O-RAN Cloud Platform

A cloud computing platform known as O-Cloud consists of physical
infrastructure nodes that are compatible with O-RAN and may host Near-RT RIC,
O-CU, and O-DU, along with supporting software and necessary management and
orchestration services. An O-Cloud node is composed of a group of central
processing units (CPUs), random access memory (RAM), storage, network
interface cards (NICs), basic input and output system (BIOS), baseboard
management controllers (BMCs), and accelerators, which collectively handle
computationally intensive tasks [22]. Depending on the deployment scenario
selected within an O-Cloud instance, the O-Cloud platform can virtualize
various NFs and thus take over RAN functions within the overall architecture.
Further details on these aspects are provided in Section V.

####  III-E4 O-Cloud Notification API

The O-Cloud notification interface facilitates event subscription for
consumers like the O-DU, deployed within the O-Cloud environment. Through this
interface, event consumers can subscribe to receive notifications and statuses
from the O-Cloud. Additionally, the cloud infrastructure offers event
producers, allowing cloud workloads to access notifications and statuses that
may otherwise only be accessible within the infrastructure itself [139, 22].

####  III-E5 Transport Network

In disaggregated O-RAN deployments, the O-CU and O-DU may be deployed in two
different distributed O-Cloud sites. To enable communication between O-CU,
O-DU and O-RU, networking infrastructure must extend across the cellular site
and distributed O-Cloud sites through open and highly-reliable transport
networks. The transport network and services encompass a broad spectrum,
involving FH, MH, and BH, as well as NR, legacy LTE, and legacy universal
mobile telecommunications system (UMTS) technologies. These services span the
CP, UP, and management plane (MP), and are designed to support the operational
needs of different operators and various E2E services or applications such as
URLLC and eMBB. The transport network must exhibit high flexibility to
accommodate various use cases and RAN designs. Each segment of the physical
transport network may need to support multiple slices, diverse 5G services,
and different 3GPP interfaces based on specific requirements.

##### Fronthaul

FH in O-RAN is defined as the connectivity in the RAN infrastructure between
the O-DU and O-RU. Mobile interfaces associated for the FH include Control,
User, Synchronization, and Management planes. O-RUs and the corresponding
serving O-DUs are positioned in close proximity to satisfy the delay criteria
linked with FH [155].

##### Midhaul

The MH network represents a logical segment within the transport network,
enabling communication between O-DU and O-CU and facilitating the transport of
3GPP F1/W1/E1 interfaces. In cases where O-DU and O-CU function as a unified
entity, these interfaces remain inaccessible, and the transport network lacks
a MH component. Additionally, it provides inter O-CU communication supporting
the transport of the 3GPP Xn interface. In situations where MNOs haven’t
implemented a split O-DU and O-CU RAN architecture, these interfaces must be
supported in the BH.

##### Backhaul

In the O-RAN architecture, the BH connects the O-CU to the 5G mobile core. It
has a CP and UP component to ensure a clear demarcation between customer user
data and the 3GPP 5G CP. The associated CP interfaces N1, N2, N4 and Xn-c are
multipoint interfaces between O-CU-CP, UPF and other 5G CN components. The UP
interface is provided by N3 between O-CU-UP and UPF, N9 between UPF and UPF,
and Xn-u between O-CU-UP and O-CU-UP.

##  IV O-RAN NFs, Network Slicing, and SMO Deployment Options

The NFs in the O-RAN architecture can be implemented as VNFs and/or PNFs that
can be hosted by the underlying O-Clouds and/or cellular network sites. The
O-Cloud is an O-RAN Cloud Platform comprising both hardware and software
components designed for executing O-RAN NFs in cloud computing environments.
The hardware includes compute, networking, and storage components, possibly
incorporating acceleration technologies to optimize performance for hosting
O-RAN NFs. The software component of the O-Cloud provides open and well-
defined APIs, facilitating the life cycle of an O-RAN slice and its associated
NFs. It is worth noting that the software is independent of the hardware,
allowing flexibility and openness in vendor selection and ensuring
compatibility with O-RAN NFs from various software suppliers.

In either scenario, whether the NFs are virtual or physical, they must be
mapped onto appropriate hosts within the O-RAN infrastructure. The mapping of
NFs onto underlying infrastructure is a crucial decision in the implementation
of logical network functionalities of an O-RAN slice, especially in cloud
computing environments. The deployments can range anywhere from fully
distributed to maximally centralized configurations based on Edge and Regional
O-Cloud sites (or the so-called PoP in ETSI terminology). The decision entails
determining the optimal execution location for each logical function, with
potential impacts on performance, scalability, cost, and other crucial
factors. In this regard, the O-RAN Alliance has introduced the O-Cloud
architecture and outlined several deployment scenarios for O-RAN NFs within
the cloud-native architecture in [145]. Moreover, the document highlights
numerous considerations essential for deploying logical NFs across different
O-Clouds. The diverse slicing and NF deployment options within O-RAN require a
range of management and orchestration solutions, leading to the multiple
deployment options for the SMO Framework.

In the subsequent subsections, we delve into multiple deployment alternatives
for O-RAN NFs, aligning them with the underlying infrastructure. Furthermore,
we examine diverse network slicing deployment possibilities within the O-RAN
architecture. Additionally, we shed light on various deployment choices
concerning the SMO Framework, emphasizing the significance of network slice
MFs.

###  IV-A O-RAN NF Deployment Scenario

The O-RAN Alliance has considered various options for virtualizing the O-RAN
NFs in Regional and Edge Clouds proposing different deployment scenarios that
can be supported by the O-RAN specifications. These deployment scenarios can
be distinguished by a particular grouping of functionality at different key
locations, such as cellular sites, edge clouds, and regional clouds, as well
as by an indication of whether the functionality is provided at a particular
location by an O-RAN PNF based solution, where software and hardware are
tightly integrated and share a single identity, or by cloud services. In
Figure 6, we illustrate several NF deployment scenarios presented in [145,
156, 157], where on the top, it shows the NFs and each scenario exhibits how
these NFs are deployed, as cloudified NFs on O-Cloud or as PNFs at the
cellular site. Each of these deployment scenarios will be explained below in
detail.

Figure 6: O-RAN NFs deployment scenarios onto the underlying O-Cloud sites and
ceullular network sites

##### Scenario A

In this scenario, the Near-RT RIC, O-CU, and O-DU are deployed at the Edge
Cloud as VNFs, whereas the O-RUs are deployed on cellular network sites. This
scenario is ideal for dense urban deployments with ample FH capacity, enabling
the pooling of BBU functionalities at a central location. It reduces latency
but comes with potentially higher deployment costs compared to other
scenarios.

##### Scenario B

In this deployment scenario, the O-CU and O-DU are deployed at the edge cloud
site in order to reduce latency, while the Near-RT RIC is deployed at the
regional cloud site in order to gain a wider network perspective for
performance optimization.

##### Scenario C

In this deployment scenario, the O-CU is co-located with the Near-RT RIC in
the Regional O-Cloud site, and the O-DU is positioned at the Edge O-Cloud
site. This scenario is tailored to support deployments in areas with limited
remote Open FH capacity, imposing restrictions on the number of O-RUs. Two
additional variations, C.1 and C.2, have been introduced to address the
specific requirements of certain network slice instances [145, 157].

##### Scenario D

This deployment scenario is akin to Scenario C (see above). However, the O-DU
is deployed as PNF at the Edge O-Cloud site in this scenario.

##### Scenario E

This deployment scenario mirrors Scenario D, with the key distinction that all
components, including both O-DU and O-RU, are fully virtualized within the
same Edge Cloud. This approach is being considered for future use,
acknowledging that the virtualized versions of the low-PHY layer and other
O-RU aspects are not currently available.

##### Scenario F

This deployment scenario involves the virtualization of both O-DU and O-RU,
but they are hosted on separate O-Cloud sites. Like Scenario E, this scenario
is also considered for future use for a similar reason.

In the context of O-RAN deployment, the Open FH plays a pivotal role,
delineating the separation between VNFs deployed within the O-Cloud and the
Cellular network sites. O-RUs always occupy the Cellular site, while O-DU can
be located at the Edge Cloud site. It is feasible to relocate O-DU closer to
the Cellular site to adhere to maximum delay requirements, but extending their
placement farther from the Cellular sites could potentially violate RAN
internal and/or RAN service-specific timing constraints [156]. A common
deployment scenario involves moving O-DU instances towards or even to the
Cellular site together with O-RU, especially when the Edge Cloud site must be
closer to the Cellular Site due to factors like fiber availability or other