This work has been submitted to the IEEE for possible publication.

Copyright may be transferred without notice, after which this version may no longer be accessible.
1

A Comprehensive Overview and Survey of O-RAN:

Exploring Slicing-aware Architecture, Deployment
Options, and Use Cases
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)

Abstract—Open-radio access network (O-RAN) seeks to es- with an emphasis on its slicing aspects. Further, the paper
arXiv:2405.03555v3 [[Link]] 8 May 2024

tablish principles of openness, programmability, automation, explores deployment scenarios for network slicing within O-RAN,
intelligence, and hardware-software disaggregation with inter- examining options for the deployment and orchestration of O-
operable interfaces. It advocates for multi-vendorism and multi- RAN and TN network slice subnets. It discusses the slicing of the
stakeholderism within a cloudified and virtualized wireless in- underlying infrastructure, encompassing both TNs and compute
frastructure, aimed at enhancing the deployment, operation, and resource slicing. Finally, the paper provides a summary of various
maintenance of RAN architecture. This enhancement promises use cases related to O-RAN slicing.
increased flexibility, performance optimization, service innova- Index Terms—5G, 6G, Disaggregation, Management and Or-
tion, energy efficiency, and cost efficiency in fifth-generation chestration, Intelligence, Near-RT RIC, Network Slicing, NFV-
(5G), sixth-generation (6G), and future networks. One of the key MANO, Non-RT RIC, O-Cloud Site, O-RAN, Open Interfaces,
features of the O-RAN architecture is its support for network Openness, RAN Architecture, RAN Slicing, RIC, SMO Frame-
slicing, which entails interaction with other slicing domains work, TN Slicing
within a mobile network, notably the transport network (TN)
domain and the core network (CN) domain, to realize end-to- I. I NTRODUCTORY R EMARKS
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
T HE radio access network (RAN) serves as a critical do-
main within a cellular network, responsible for enabling
wireless connectivity between the user equipment (UE) and
efforts, the research and standardization communities have yet to base station across a specified geographical footprint. It em-
comprehensively address network slicing in O-RAN. To address ploys heterogeneous radio access technologies (RATs) to en-
this gap, this survey paper provides a comprehensive exploration sure efficient data transmission both in the upstream and down-
of network slicing in O-RAN through an in-depth review of
specification documents from O-RAN Alliance and research stream directions [1]. The RAN’s architectural evolution was
papers from leading industry and academic institutions. The shaped by several key factors, including the ever-increasing
paper commences with an overview of the ongoing standard- number of UEs, the growing complexity and diversity of
ization efforts and open-source contributions associated with O- wireless access technologies, the relentless pursuit of enhanced
RAN, subsequently delving into the latest O-RAN architecture network performance (such as higher data rates, lower latency,
broader coverage, etc.), embracing emerging trends such as
This manuscript was received on DD MM 2024; revised on DD MM 2024; virtualization and cloudification, and the escalating demand for
and accepted for publication by Associate Editor on DD MM 2024. Date of
publication DD MM 2024; date of current version DD MM 2024. diverse communication and beyond-communication services
Khurshid Alam , Dennis Krummacker , and Hans D. Schotten are with over the past decades [2]–[5]. This continuous evolution,
the Intelligent Networking (IN) Research Group, German Research Center for exemplified by its transformation from fourth-generation (4G)
Artificial Intelligence (DFKI), 67663 Kaiserslautern, Germany.
Mohammad Asif Habibi , Matthias Tammen , and Hans D. Schotten to fifth-generation (5G) and now towards sixth-generation
are with the Division of Wireless Communications and Radio Navigation (6G), has been instrumental in enabling a wide range of
(WiCoN), Department of Electrical and Computer Engineering (EIT), Uni- transformative applications, services, and use cases [6]–[8].
versity of Kaiserslautern (RPTU), 67663 Kaiserslautern, Germany.
Walid Saad is affiliated with the Department of Electrical and Computer Introduced in 4G, the distributed RAN (D-RAN) archi-
Engineering, Virginia Tech, 22203 Virginia, United States of America. tecture proposed a separation of the radio and baseband
Marco Di Renzo is associated with Université Paris-Saclay, CNRS, processing functionalities into two distinct entities: the base-
CentraleSupélec, Laboratoire des Signaux et Systèmes, 3 Rue Joliot-Curie,
91192 Gif-sur-Yvette, France. band unit (BBU) and remote radio head (RRH) [9]. How-
Tommaso Melodia is affiliated with the Institute for the Wireless Internet ever, these components were situated at the same location
of Things, Northeastern University, Boston, MA 02115 United States of within the same cellular network site and connected via an
America.
Xavier Costa-Pérez is affiliated with the 6G Networks R&D Department, internal interface within the corresponding base station [2].
NEC Laboratories Europe, 69115 Heidelberg, Germany. He is also with the Subsequently, the centralized RAN (C-RAN) architecture has
i2CAT Research Center and the Catalan Institution for Research and Advanced emerged, introducing a significant departure from traditional
Studies (ICREA), 08034 Barcelona, Spain.
Mérouane Debbah is with Khalifa University of Science and Technology, RAN architectures by decoupling the BBU and RRH [1],
P. O. Box 127788, Abu Dhabi, United Arab Emirates. [2]. In this approach, the BBU is physically relocated to a
Ashutosh Dutta is affiliated with the Applied Physics Laboratory, Johns centralized data center (DC), enabling centralized control and
Hopkins University, 20723 Maryland, United States of America.
The corresponding authors are Khurshid Alam ([Link]@[Link]) optimization of multiple RRHs through a high-speed fronthaul
and Mohammad Asif Habibi (asif@[Link]). (FH) interface utilizing the common public radio interface
 2

(CPRI) technologies [9], [10]. The emergence of D-RAN and NG-RAN components as well as to adopt software-defined
C-RAN architectures marked significant advancements in the networking (SDN) and network function virtualization (NFV)
development and deployment of numerous RAN architectures [26], [27]. In addition, the O-RAN architecture paves the
and RATs, paving the way for further innovations in 4G and way for realizing groundbreaking services and applications in
beyond [1], [11]. cellular networks, enabling the deployment of network slicing,
The advent of 5G heralded a paradigm shift in RAN dynamic spectrum sharing, and resource sharing [20], [28]–
architecture, driving substantial transformations to harness the [30].
diverse demands of a wide range of use cases and industrial Empowered by the O-RAN architecture, network slicing
applications [2]. The goal was to establish a distributed, enables the creation of open slices, effectively partitioning
programmable, and adaptable RAN architecture, equipped a physical network into multiple virtualized networks that
to seamlessly accommodate the evolving needs of emerg- can operate simultaneously and independently [17]. Each
ing vertical markets [12]. Aiming to enhance flexibility and virtualized network can be configured to match the specific
adaptability, the 3rd Generation Partnership Project (3GPP) requirements of diverse use cases, catering to the unique
proposed the next-generation RAN (NG-RAN) as the 5G demands of 5G and beyond applications [31]. This specifically
RAN architecture [13]. The NG-RAN comprises a number means that dedicated virtual network slices can be tailored
of base stations known as the next generation NodeB (gNB). to fulfill specific user needs [28], enabling the simultaneous
The NG-RAN introduces a split of the gNB, placing higher provisioning of a diverse range of services while dynamically
protocol layers under the control of the centralized unit (CU) allocating network resources to match the individualized re-
and delegating responsibility for lower protocol stacks to the quirements of each slice [32]. In contrast to the rigid and
distributed unit (DU) [14], [15]. Building upon the 3GPP- inflexible one size fits all architectural solution, network slicing
defined gNB, the Open RAN (O-RAN) Alliance proposed introduces a paradigm shift towards a more dynamic, flexible,
a further distribution of DU functionalities into two distinct and efficient approach to network optimization and resource
entities: DU and radio unit (RU). With this approach, the gNB allocation [33], [34].
now encompasses CU, DU, and RU [16]. This architectural Notwithstanding the above features of traditional RANs slic-
improvement introduced significant scalability, enabling a sin- ing, O-RAN brings several advantages to slicing. (a) With lim-
gle CU to effectively manage multiple DUs, while each DU ited ability to customize resource allocation for specific slices,
could seamlessly connect to multiple RUs, responsible for the O-RAN’s disaggregated architecture allows for more granular
efficient transmission and reception of radio signals to and control. Different vendors can provide special hardware and
from 5G UEs. software optimized for specific slice requirements. This allows
One of the features of the NG-RAN is its seamless integra- for a more tailored approach to slicing. (b) Traditionally,
tion with cloud-native and virtualized environments, enabling creating slices with specific performance characteristics might
the deployment of CU and DU on commercial off-the-shelf require specific vendor equipment. O-RAN’s open interfaces
(COTS) hardware within a cloudified and virtualized infras- make it possible to mix and match components from different
tructure [16]. Despite the increasing momentum towards virtu- vendors as long as they comply with O-RAN standards. This
alization and disaggregation in NG-RAN, the architecture has allows operators to choose the best-in-breed solutions for each
predominantly maintained a closed and proprietary approach, slice, potentially leading to cost savings and innovation. (c) To
thereby constraining the flexibility and innovation potential it facilitate automated closed-loop control of the RAN, O-RAN
could otherwise provide [17], [18]. The NG-RAN components introduces two RICs [22], [35]. The non-real-time RIC (Non-
often embody complex proprietary designs developed and tai- RT RIC) and near-real-time RIC (Near-RT RIC) in O-RAN
lored by the respective network equipment manufacturers [19]. enable the deployment of intelligent applications (rApps and
The interfaces connecting these components are engineered for xApps) tailored for slicing. These applications dynamically
peak performance, but they are exclusively compatible with the handle resources and enhance performance for slices in real-
proprietary hardware of the specific manufacturer, hindering time, a task challenging with traditional RAN architectures
the prospects of multi-vendor interoperability [14], [20]. [36]. (d) O-RAN facilitates automation in slicing through
To foster open interfaces and facilitate multi-vendor in- its open interfaces and standardized protocols. This allows
teroperability, the O-RAN Alliance has proposed a ground- for automated slice creation, configuration, and management,
breaking industry initiative, the O-RAN architecture, aiming making the process faster and less error-prone compared to
to revolutionize traditional NG-RAN [21]. This initiative seeks manual configuration in traditional RANs.
to replace closed and proprietary NG-RAN with open, in- In addition, network slicing empowers mobile network op-
teroperable, and cloud-driven systems. The O-RAN Alliance erators (MNOs) to deliver services tailored to exacting require-
establishes the development of open standards and specifica- ments, facilitating the fulfillment of service level agreements
tions, fostering compatibility and innovation amidst a diverse (SLAs) with tenants [46]. This approach specifically addresses
landscape of network equipment vendors [17]. Simultaneously, the heterogeneity of performance requirements and network
it embraces artificial intelligence (AI) and machine learning functionalities by introducing standardized service types, de-
(ML) to revolutionize network automation and optimization fined by the 3GPP. These standardized service types, as of
through the RAN intelligent controller (RIC) [22]–[25]. To this writing, encompass enhanced mobile broadband (eMBB),
achieve an open and intelligent NG-RAN architecture for 5G ultra reliable low latency communication (URLLC), massive
and beyond, there is a need to deploy open interfaces between machine type communication (mMTC), high-performance ma-
 3

TABLE I
C OMPARING 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)

chine type communication (HMTC), and vehicle to everything intricate challenges and complexities associated with RAN
(V2X) [16]. The number of these standardized service types slicing across various domains of the two standards.
is anticipated to expand significantly with the continuous It is noteworthy that, while the O-RAN Alliance and 3GPP
advancement and deployment of communication and non- frameworks enable slicing in O-RAN, they do not directly
communication services in 5G, 6G, and beyond [6]. address the virtualization aspects in O-RAN. To holistically
Despite the significant contributions of the 3GPP in RAN encompass both the virtualized and physical dimensions of
slicing, the O-RAN Alliance has also played a pivotal role slicing within the O-RAN architecture, it is essential to
in the intelligentization of open interfaces and components to establish harmonization among the 3GPP, O-RAN Alliance,
support intelligent slicing within O-RAN [47]. The RIC [22], and European Telecommunications Standards Institute (ETSI)
which serves as a robust platform for hosting slicing-aware frameworks. This harmonization of these three standardized
applications, can train, host, and execute the AI/ML models to frameworks is anticipated to pave the way for unified solutions
achieve intelligent O-RAN slicing. These models can predict for the realization of slicing within the O-RAN [48], enabling
and optimize traffic fluctuations based on a comprehensive seamless delivery of various types of O-RAN slices.
set of defined metrics [12]. To fully realize the potential of
slicing within an O-RAN, it is essential to foster a seamless A. Review of Survey and Overview Papers on O-RAN
unification between O-RAN and 3GPP standards at various Despite the remarkable progress and growing interest in
levels [48]. This unification is crucial for addressing the 3GPP-defined RAN architectures and their slicing [49], [50],
 4

realizing slicing in the O-RAN Alliance-defined architecture

presents escalating challenges due to the stringent require- Introduction
- Review of Survey Papers
ments of supporting open interfaces, seamless interoperability Sec.I - Survey Gap in Literatures
among components from diverse vendors, and the intricate - Our Goals and Contributions
interplay of multiple stakeholders within the management and - The Structure of the Paper
network domains [17], [51]. Consequently, O-RAN slicing has
O-RAN Standards and Open Source Efforts
recently emerged as a focal point of intense research interest
- Key Feates of O-RAN
within both the standardization and research communities. [Link] - O-RAN Standards and Activities
Within the standardization community, the O-RAN Alliance - Open Source Projects
is spearheading the role as a leading SDO that has been defin- - Open Access Testbeds

ing standards for O-RAN slicing. The specifications related

O-RAN Slicing-aware Architecture
to the network slicing have been published within the various - Major Components of O-RAN
working groups (WGs) of the O-RAN Alliance. We will delve [Link] - The O-gNB and Interfaces
into the pertinent specifications and contributions to O-RAN - The SMO Framework and Interfaces
- The Underlying Infrastructures
slicing in the subsequent chapters. However, the most recent
specifications that lay the groundwork for O-RAN slicing,
O-RAN Deployment Scenario
published by the WG 1, are accessible in [31], [52]. - O-RAN NF Deployment Scenarios
Within the research community, we have witnessed signifi- [Link] - Network Slicing Deployment Scenarios
cant contributions to diverse research challenges. This encom- - SMO Framework Deployment Options
- 3GPP and NFV-MANO based SMO Deployment
passes aspects related to the management and orchestration - 3GPP and ONAP based SMO Deployment
of O-RAN slicing, designing xApps and rApps for O-RAN
slices, and numerous optimization problems. Furthermore, Slicing the Underlying O-RAN Infrastructure
several survey and overview papers related to the subject - O-RAN Cellular Site
- O-RAN Cloud Platform
have been published by leading academic institutions. We Sec.V
- Xhaul Transport Network
present an up-to-date list of these papers, summarizing their - Xhaul Transport Network Slicing
major contributions to the O-RAN architecture (and, where - Mapping of NSIs to Physical Infrastructure
applicable, to O-RAN slicing) in Table I.
Network Slicing Use Cases in O-RAN
B. The Primary Survey Gap in the Literature - Slice Subnet Management & Provisioning
[Link] - Slice SLA Assurance
Notwithstanding the fact that some of the earlier mentioned - Multi-vendor Slices
papers address network slicing and highlight its impact on - Advantages of Multi-vendor Slices
- NSSI Resource Allocation Optimization
the O-RAN, they lack a thorough analysis of O-RAN slicing.
Specifically, there is a deficiency in presenting an accurate
Conclusions and Future Works
portrayal of the current scenario, exploring various proposed [Link] - Background & Concluding Remarks of O-RAN
deployment options, and offering sufficient information on - Summary of the Content Covered in the Paper
tightly integrating the different O-RAN components. In addi- - Future Research Directions

tion, there is a lack of literature on the seamless unification and

interoperability among the O-RAN’s components to ensure the Fig. 1. Overview of the organization and structure of this survey paper. Each
successful development and deployment of various types of O- box represents one of the seven chapters of the paper, encapsulating their
respective contributions and themes.
RAN slices. Therefore, according to our current understanding,
there exists no comprehensive survey or overview paper in the • Delving into the deployment scenarios of O-RAN slicing
literature that delves into the intricacies of network slicing in and the SMO Framework, we provide insights into a
O-RAN in a comprehensive and thorough manner. number of high-level use cases expected to be served by
O-RAN’s slicing-aware architecture.
C. Goals and Contributions
• Discussing the NFs and TN elements, along with their
To address the identified literature gap, this paper makes
a significant contribution by offering a comprehensive survey management and orchestration, such as FH and mid-
and overview of network slicing in O-RAN. Specifically, the haul (MH), which constitute the O-RAN slice subnet.
key contributions of this paper are as follows: Additionally, this paper is addressing the aspects of the
underlying infrastructure associated with TN slicing.
• Exploring open-source initiatives, standardization actives,
and the design of experimental platforms for O-RAN. In Table I, we present a comparison between the contribu-
• Focusing on the latest O-RAN architecture outlined by
tions made in this article and those found in state-of-the-art
the O-RAN Alliance, with an additional emphasis on survey articles on the subject.
theoretical contributions from academic research and D. The Organization of the Article
practical deployment from various leading industries. The rest of this survey paper is structured as follows: We
• Providing a holistic view of the network slicing paradigm begin with an overview of the open-source projects, activities,
within O-RAN, we introduce the functional components and their contributions, as well as the standardization efforts
and interfaces necessary for implementing network slic- associated with O-RAN architecture in Section II. We then in-
ing within the O-RAN architecture. troduce the architectural components and open interfaces of O-
 5

RAN slicing-aware architecture and highlight the features for The integration of AI/ML models into the O-RAN facilitates
O-RAN slicing in Section III. This section further includes dis- the design of data-driven RICs, supporting service providers,
cussions on O-RAN interactions with 3GPP-defined network vendors, and third parties with the onboarding of applications
components, service management, and service orchestration. and use cases in an inteligent manner [48]. These applications
In Section IV, we explain the various deployment scenarios for and use cases aid in automating and optimizing O-RAN
O-RAN deployment, O-RAN slicing, and SMO proposed by operations, reducing the total cost of ownership (TCO) for
the O-RAN Alliance in relation to different use cases. Moving mobile carriers, and enhancing the quality of experience (QoE)
forward, Section V delves into the underlying infrastructure and quality of service (QoS) of RAN services [57], [58].
slicing within the O-RAN architecture, elaborating on the con- The following bullet points sum up the main principles and
cepts of O-RAN cloud platform (O-Cloud) slicing, TN slicing, characteristics of the O-RAN that service providers, network
and TN slice orchestration. Section VI outlines high-level use operators, and other stakeholders may find relevant.
cases that are expected to be prioritized and defined with
• Intelligent and Programmable Network: O-RAN is
support from the O-RAN community, particularly in relation
designed to be intelligent and programmable, allowing
to RAN slicing. Finally, Section VII offers a summary of our
for dynamic adjustments and optimizations in network
work, draws conclusions, and suggests potential directions for
operations. This flexibility enables the network to adapt
future research. To improve readability, an overview of the
to varying demands and scenarios efficiently [59].
organization of this survey paper is illustrated in Figure 1.
• Data Center Economics to RAN: O-RAN brings the
economic principles of DC to RAN, optimizing resource
II. O NGOING S TANDARDIZATION E FFORTS AND O PEN utilization and operational expenditure (OPEX) [54]. This
S OURCE C ONTRIBUTIONS TO THE O-RAN A RCHITECTURE approach enhances the efficiency of RAN infrastructure,
In this section, we explore, in detail, the fundamental aligning it with the cost-effective practices seen in DCs.
features, characteristics, and implications of the O-RAN ar- • Lower TCO: By leveraging DC economics and promot-
chitecture. Additionally, we delve into ongoing open-source ing efficiency, O-RAN aims to significantly reduce the
initiatives within the O-RAN ecosystem, alongside openly overall TCO. This cost-effectiveness is achieved through
accessible experimental platforms specifically designed for de- streamlined operations and resource utilization [60].
veloping the O-RAN components and interfaces. Furthermore, • Automation and Manageability: O-RAN emphasizes
we provide an overview of state-of-the-art standardization con- automation and manageability, reducing the manual effort
tributions across various de facto and de jure SDOs associated required for network operations. This not only improves
with the O-RAN architecture. Our primary objective is to efficiency but also enhances the reliability and consis-
equip the inquisitive reader with a comprehensive understand- tency of network management tasks [59].
ing of the ongoing advancements associated with O-RAN. • Faster Time to Market: O-RAN facilitates a quicker
time to market for deploying network solutions, enabling
A. Key Features and Principles of O-RAN operators to roll out new services and features more
The primary motive behind O-RAN architecture for service rapidly. This speed in implementation is crucial for stay-
providers is to diversify their vendor partnerships and avoid ing competitive in the rapidly evolving telecommunica-
vendor lock-in, allowing the utilization of non-proprietary tions landscape [61].
software and hardware components from various vendors • Agility of Innovation: The architecture of the O-RAN
[53]. Traditionally, RAN has been a proprietary and vertically fosters innovation agility, allowing for the swift develop-
integrated part of a mobile network, with tightly coupled ment and integration of new technologies and features.
hardware and software from a single vendor [17]. O-RAN This adaptability ensures that the network can keep pace
seeks to change this paradigm by advocating for open in- with advancements and changing industry requirements
terfaces and interoperability among RAN components. The [61].
O-RAN architecture prioritizes interoperability and flexibility • Vendor Diversity: O-RAN promotes vendor diversity,
through open standards, enabling network operators to choose allowing network operators to choose from a variety
equipment and software from different suppliers [40], [54]. of equipment and service providers. This flexibility en-
This flexibility facilitates greater customization in network hances competition, encourages innovation, and provides
configuration, encouraging the involvement of second- and network operators with options to tailor their networks
third-tier equipment manufacturers [53]. according to specific requirements and preferences [60].
• Open Source Software: O-RAN leverages open-source
O-RAN not only establishes open interfaces but also enables
software to provide reference implementations and en-
unrestricted access to NG-RAN through AI-based control
courage collaboration among industry participants [60].
mechanisms, enhancing real-time sensing, proactive manage-
ment, and dynamic responsiveness to radio resources [55], The O-RAN Alliance – a consortium of telecom operators,
[56]. It supports programmable, disaggregated, virtualized, vendors, and academic institutions – plays a crucial role in
and interoperable tasks [16], enabling service providers to developing and promoting O-RAN standards. By adopting
transition to a fully programmable, intelligent, autonomous, these principles, the industry aims to accelerate innovation,
and multi-vendor RAN architecture for 5G, 6G, and beyond reduce deployment costs, and create a more dynamic and
[53]. competitive marketplace for RAN solutions towards 5G, 6G,
 6

and beyond mobile communication systems [17]. 1, Layer 2, or medium access control (MAC)-based approaches
for implementing RAN slicing [49], [71]. In addition, they
B. Network Slicing also specify a management and orchestration framework for
Network slicing stands as a groundbreaking architectural the efficient life cycle management of RAN slices over the
solution. It facilitates the creation of multiple distinct virtual NG-RAN architecture, as well as its interaction with other
networks, or ”slices,” operating atop a shared physical infras- standardized frameworks for the realization of E2E network
tructure. This approach, heralded as a pivotal element of 5G, slicing [16].
6G, and beyond, introduces a wealth of possibilities to address
diverse service demands and fully realize the capabilities of C. O-RAN Standards and Activities
next-generation communication systems. As of the present writing, numerous de facto and de jure
At its essence, network slicing involves partitioning the organizations are actively engaged in establishing a software
underlying physical network into discrete virtual networks, and hardware ecosystem in alignment with the principles
each finely configured to specific service requirements and of the O-RAN paradigm. These organizations participate in
performance criteria [62]. Each slice operates autonomously, collaborative efforts within various SDOs. In this subsection,
offering tailored configurations of bandwidth, latency, security, we delve into an exploration of these organizations and their
and so forth [63]. This departure from traditional mono- contributions toward the realization of O-RAN.
lithic networks to a multi-sliced architecture empowers ser- 1) 3GPP: 3GPP does not directly establish standards for
vice providers to cater comprehensively, spanning from ultra- O-RAN. Nevertheless, various architectural components, NFs,
responsive industrial automation to high-throughput mobile management and orchestration frameworks, functional splits,
broadband [64], [65]. interfaces, and other elements within the 3GPP-based RAN
An E2E network slice seamlessly traverses through all net- architecture have been extended by other SDOs to formulate
work domains, comprising RAN, TN, and core network (CN) standards for the O-RAN architecture. The 3GPP standards
segments [66]. Each slice is meticulously crafted to address provide a comprehensive system definition for RAN architec-
the distinct needs and attributes of various services, ensuring ture, distributed across several technical specification groups
logical separation. This isolation safeguards the integrity of (TSGs).
individual network slices, preventing errors or malfunctions During the 5G evolution, 3GPP considered eight different
in one slice from impacting communication in others. Such split variants and reached a consensus to establish two NG-
isolation fosters the autonomy and reliability of each virtual RAN split architectures. We discussed these split options
network [67]. in our previous work in detail [16]. One of the two split
For every network slice, operators confidently commit ded- architectures is high layer split (HLS), equivalent to option 2
icated resources, including computing power, bandwidth, QoS from the 5G study, which involves dividing the BBU into CU
provisions, and other critical elements, guaranteeing optimal and DU along with the separation of CP and UP functions
performance and service quality [68]. This assurance under- for CU [40]. 3GPP further introduced the F1 interface that
scores the commitment to meeting the diverse demands of connects the CU to the DUs and the E1 interface to enable
modern communication services while ensuring robustness and coordination between the CP and UP [72], [73].
efficiency across the network landscape. The 3GPP-defined functional splits were established to
Despite the substantial progress made in E2E network promote the concept of disaggregating the standard protocol
slicing, persistent challenges remain in NG-RAN slicing [30], stack. This involves separating the processing of a specific
[64]. The complexity of NG-RAN slicing stems from the layer within the protocol stack from the computing entity.
intricate task of balancing varying levels of isolation and re- This movement within the 3GPP framework is seen as the
source sharing while tailoring the user plane (UP) and control foundational step toward achieving genuine cellular interface
plane (CP) for individual slices [69]. More specifically, these and processing openness [41]. It has served as a pivotal cata-
complexities stem from factors such as the need to balance the lyst for the development of subsequent O-RAN specifications
trade-off between utilization ratio and isolation level, establish which will be elaborated upon later in this section.
harmonization among inter-RAN and intra-RAN slice resource 2) O-RAN Alliance: The O-RAN Alliance, established in
allocation algorithms, and effectively manage inter-RAN and 2018, is dedicated to the ambitious task of modernizing RAN
intra-RAN slice priorities [16]. In addition, the limited avail- architecture globally. The alliance’s central mission revolves
ability of radio resources demands highly efficient resource around steering the wireless communication industry towards
management to optimize network performance. Moreover, the a future characterized by openness, intelligence, virtualization,
introduction of features like bandwidth partitioning (BWP) and and seamless interoperability within the RAN. This transfor-
physical numerology in 5G new radio (NR) amplifies these mative journey is underpinned by a shift towards virtualized
complexities [70]. network components, the adoption of white-box hardware,
To address the aforementioned challenges, the 3GPP has and the implementation of open interfaces facilitating com-
provided guidelines in Release 17 for realizing RAN slicing munication between various RAN’s software and hardware
in NG-RAN architecture. These guidelines encompass various components [74].
aspects, including support for various QoSs, resource segrega- To execute its vision, the O-RAN Alliance employs a struc-
tion, enforcement of SLA, and more [49]. 3GPP specifications tured approach outlined in the O-RAN specification, which
further enhance flexibility by presenting options such as Layer is meticulously organized into several groups overseen by the
 7

technical steering committee (TSC). The TSC plays a pivotal RAN framework of the TIP. The primary focus of Release 3
role in decision-making and provides essential guidance on O- is to advance requirements related to SMO and RIC, with
RAN technical matters. It assumes the crucial responsibility of significant enhancements in underlying cloud infrastructure,
approving specifications before they undergo board approval O-CU, O-DU, and O-RU.
and subsequent publication. Currently, the TSC comprises Notably, this release places a heightened emphasis on se-
eleven technical WGs, five focus groups (FGs), a research curity considerations and challenges, consolidating security
group, an open-source community, and a minimum viable requirements in a dedicated section. It also explores energy
plan - committee (MVP-C). These diverse entities within the efficiency topics in more detail, identifying new requirements
TSC collaborate to focus on specific aspects of the O-RAN across various streams. The goal is to accelerate the devel-
architecture, contributing collectively to its development and opment of competitive Open RAN solutions in Europe and
deployment. For a concise overview of the objectives and areas globally, promoting widespread technology adoption [76]–
of focus within these divisions, refer to Table II. [78].
3) Telecom Infra Project: The telecom infra project (TIP) is 4) Small Cell Forum: The small cell forum (SCF) is
a global collaboration involving businesses and organizations a global organization focused on developing technical and
dedicated to accelerating the development and implementation commercial tools to accelerate the adoption of flexible,
of open, disaggregated, and standards-based technology and cost-effective, and scalable cellular network infrastructure.
network infrastructure solutions within the telecommunica- Throughout its existence, SCF has played a key role in stan-
tions sector. The organization has over 500 members, and its dardizing essential elements of mobile network technology,
work has resulted in the development of a number of open including functional API (FAPI), network FAPI (nFAPI), and
standards and specifications. The TIP’s projects have also been the enhancement of the X2 interface. These specifications
adopted by a number of major operators around the world. The enable an open, multi-vendor platform, thereby reducing the
TIPs work outlines end products that meet specific commercial barriers to the densification of stakeholders in the wireless
use cases that operators need. The TIP organizes multiple communication industry [79].
project groups (PGs) that concentrate on products, solutions, The SCF has established its own Open RAN ecosystem with
and software across various network domains, including RAN, a particular emphasis on small cells. The introduction of the
TN, and CN, as well as various management layers. nFAPI protocol by SCF marks the pioneering of split option 6
Within the various PGs, the OpenRAN is an initiative for [59], which divides the MAC layer and physical layer (PHY),
enabling an open ecosystem for building the 3GPP-defined housing the PHY in the small cell RU (S-RU). The SCF
NG-RAN architecture based on the principles of open com- nFAPI is pivotal in empowering the Open RAN ecosystem
ponents and interfaces for existing 4G, 5G, and beyond mobile by facilitating interoperability, allowing a small cell CU/DU
networks. The primary goal of OpenRAN PG within the TIP is to connect seamlessly with an S-RU [80].
to develop end products and solutions, foster vendor diversity The SCF promotes openness and interoperability in small
for network service providers, and introduce innovative plat- cell networks in order to allow diverse architectures while
forms for network management. The group collaborates with maintaining a common platform. To simplify integration,
operators, vendors, system integrators, and global stakeholders SCF provides tools, deployment blueprints, and support for
to align requirements for different components of OpenRAN testing, including the SCF disaggregated RAN transport study
networks, including O-RUs, O-DUs, and O-CUs. OpenRAN (DARTs) [81]. Emphasizing open testing and certification
PG concentrates on building, testing, and validating Open is crucial to instilling confidence among operators and fa-
RAN products at scale [75]. The solutions developed undergo cilitating the widespread adoption of Open RAN. SCF, O-
thorough testing and validation in laboratory environments RAN Alliance, and TIP have dedicated considerable efforts
through TIP Community Labs and PlugFest. to support standardized testing processes across the industry,
The OpenRAN PG is organized into the following two main including actively participating in plugfests [79].
work streams [76]: The SCF collaborates with O-RAN Alliance, 3GPP, Ope-
• Component Subgroups: These subgroups are dedicated nAirInterface (OAI), and many other organizations across
to enhancing the performance of individual OpenRAN technical, commercial, and regulatory eras. SCF aims to drive
components, encompassing software and hardware such Open RAN adoption in all domains, resulting in significant
as RU, DU, CU, radio intelligence automation (RIA), growth in the deployment of virtualized open RAN. The
and OpenRAN orchestration and management automation combination of open systems, open-source code, and shared
(ROMA). spectrum has the potential to empower numerous new deploy-
• Segment Subgroups: These subgroups are concentrating ers, particularly in crucial areas like enterprise and smart city
on integrated RAN solutions tailored for specific network environments where small cells are indispensable [79], [81].
use cases to enhance deployment scenarios, both outdoor
and indoor. D. O-RAN-Related Open Source Projects
The OpenRAN PG released a technical priorities docu- The software community is dedicated to seamlessly aligning
ment, Release 3, in April 2023, presenting their prioritized software reference implementations with the O-RAN archi-
requirements for Open RAN. This document comprehensively tecture and specifications. In this context, the OSC assumes
covers main scenarios, radio configurations, and hardware and various responsibilities, including the development of open-
software requirements for each building block within the Open source software, collaboration with other open-source commu-
 8

TABLE II
S UMMARY OF CONTRIBUTIONS AND FOCUS AREAS ACROSS MULTIPLE WG S SUPERVISED BY THE TSC WITHIN THE O-RAN A LLIANCE .
Group Title Principal Areas of Focus and Notable Contributions
WG1 Use Cases and Overall • Exploring and defining use cases, system-level requirements, deployment scenarios, and a
Architecture WG 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
WG2 Non-RT RIC and A1 • Defining an architecture for Non-RT RIC, incorporating the R1 interface to connect the Non-
Interface WG 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
WG3 Near-RT RIC and E2 • Specifying E2 interface between the Near-RT RIC and the E2 nodes
Interface WG • 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
WG4 Open Fronthaul Inter- • Establishing specifications for an open fronthaul (O-FH) interface between O-RAN DU (O-
faces WG 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
WG5 Open • Providing interoperable multi-vendor specifications aligned with 3GPP standards for F1, W1,
F1/W1/E1/X2/Xn E1, X2, and Xn interfaces, enhancing O-RAN architecture
Interface WG • 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
WG6 Cloudification and Or- • Specifying cloud-native and virtualized infrastructure for hosting O-CU and O-DU, focusing
chestration WG 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
WG7 White-box Hardware • Specifying standards for comprehensive reference design of high-performance, spectral efficient
WG 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
WG8 Stack Reference De- • Developing software architecture, design, and release plan for O-CU and O-DU, tailored for
sign WG NR protocol stack
• Providing specifications for interoperability testing of O-CU and O-DU deployment scenarios
with other O-RAN components and interfaces
WG9 Open X-haul Transport • Designing an open TN within O-RAN, meeting FH, MH, and BH service requirements
WG • Concentrating on the open transport domain, including transport equipment, physical media,
and associated control/management protocols within the TN
WG10 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
WG11 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 • Leading in formulating standardization strategies for the O-RAN Alliance and serve as the
Focus Group primary interface to other relevant SDOs
• Managing coordination of both incoming and outgoing liaison statements
IEFG Industry Engagement • Engaging with leading industry players and members of the O-RAN Alliance to drive adoption,
Focus Group spread, and ongoing innovation of O-RAN-based technologies and solutions
OSFG Open Source Focus • Managing O-RAN Alliance’s open-source activities, including establishing the O-RAN soft-
Group ware 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

 9

TABLE II
Continued from previous page.

Group Title Principal Areas of Focus and Notable Contributions

TIFG Test & Integration Fo- • Defining testing and integration approaches, coordinating specifications across WGs, including
cus Group 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 • Focusing on enhancing energy efficiency and reducing environmental impact in O-RAN
Group • Collaborating with MVP-C to align initiatives across all WGs and FGs
nGRG next Generation Re- • Researching intelligent O-RAN principles for 6G and beyond standards
search Group • Driving network evolution towards greater intelligence and performance through new technolo-
gies
MVP- Minimum Viable Plan • Providing roadmap for implementing comprehensive O-RAN solutions in commercial networks
C – Committee • 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 • Leading the development of open-source software for O-RAN architecture in collaboration
Community 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

nities, and promotion of related projects and activities. As of intent-driven closed-loop autonomous networks [86]. ONAP
this writing, multiple open-source platforms compliant with O- includes modeling and orchestration functionality of a slice
RAN are accessible for use by academics and research institu- including 5G RAN, core, and transport network slice sub-
tions, providing valuable tools for their work. In the following nets. More specifically, ONAP includes workflows and user
section, we will delve into some of the key contributors and interfaces for the communication service management function
participants in O-RAN implementations. (CSMF) and network slice management function (NSMF) with
1) ONAP: The open network automation platform (ONAP) an interface to an external network slice subnet management
is an LF open-source project launched in 2017. It serves as a function (NSSMF). This functionality allows the design, or-
comprehensive platform designed for orchestrating, managing, chestration, and termination of an network slice [87].
and automating network and edge computing services. To 2) OpenAirInterface: The OpenAirInterface software al-
address the needs of network operators, cloud providers, and liance (OSA) is a nonprofit organization founded by a French
enterprises, ONAP employs real-time and policy-driven or- research institute, EURECOM, that supports a global commu-
chestration and automation for both physical and virtual NFs. nity of researchers and industry contributors to the develop-
This capability facilitates swift automation of new services ment of open-source software for the CN and RAN of 3GPP
and the essential lifecycle management crucial for 5G and cellular networks. The Alliance supports the advancement of
next-generation networks [75]. The project uses SDN and the 3GPP 5G cellular stack, which is included in the OAI
NFV technologies to automate 5G networks. ONAP contains software packages and deployed utilizing COTS hardware.
complete management and orchestration (MANO) layer func- The roadmap creation, quality assurance, and marketing of
tionality that is consistent with the NFV architecture of ETSI. the OAI software packages used by the academic and business
In addition to fault, configuration, accounting, performance, communities for various use-cases are all tasks that fall under
security (FCAPS) features, ONAP also contains a framework the purview of the OSA. The goal of the OSA is to speed up
for designing network services [82]. OAI adoption.
There exist robust relationships and interdependencies be- In 5G, the OAI community and software assets are expand-
tween ONAP and OSC, deploying a SMO Framework and ing at the quickest rate. Currently, OAI has the following
incorporating the Non-RT RIC functions [83]. The ONAP is projects: OAI 5G RAN, OAI 5G CORE, MOSAIC5G, and
collaborating with the OSC to enhance coordination, minimize CI/CD. The newly created MOSAIC 5G (M5G) PG aims to
redundant efforts, and streamline work. A compilation detail- transform RAN and CN into agile and open network-service
ing shared areas of interest where ONAP and OSC intersect delivery platforms. The primary emphasis of M5G PG is
are available at [84]. The ongoing study of the use case, “ON- producing software implementations of the O-RAN E2 proto-
AP/3GPP & O-RAN Alignment-Standards Defined Notifica- col, a flexible RIC called FlexRIC, a flexible Core controller
tions over VES” serves to facilitate alignment between ONAP, namely FlexCN, an intelligent RAN and CN operator [88].
3GPP, and O-RAN. This contribution aims to empower ONAP Northeastern University has also integrated OAI with the OSC
to adhere to O-RAN Alliance and 3GPP standards, potentially RIC [89].
encouraging participation from companies aligned with O- 3) Open Networking Foundation: open networking foun-
RAN Alliance and 3GPP [85]. dation (ONF) is a consortium led by several network op-
The Kohn release of ONAP further focus on O-RAN erators, playing a pivotal role in driving radical transfor-
integration, cloud-native NF orchestration improvements, and mation within network infrastructure. The ONF’s software-
 10

defined RAN (SD-RAN) project actively contributes open- • A softwarized RAN utilizing open protocol stacks like
source components to enhance Open RAN, by creating and srsRAN and OAI for cellular networks.
testing O-RAN compliant network elements, fostering multi- • A data collection and control framework, such as SCOPE,
vendor RAN solutions, and showcasing the potential of mixing providing key performance indicators (KPIs) to extract
components for innovation [90]. key performance measurements (KPMs) from the RAN
In close collaboration with the O-RAN Alliance and OSC, and dynamically control it at runtime.
the primary goal of the platform is to develop open-source • An O-RAN control architecture like ColO-RAN, capable
components for the O-CU CP, O-CU UP, and O-DU [40]. of connecting to the RAN through standardized interfaces
SD-RAN features a cloud-native uONOS-RIC (pronounced like E2 termination, receiving runtime KPMs, and con-
as micro-ONOS-RIC), a Near-RT RIC, an xApp development trolling it through AI/ML solutions like xApps/rApps.
environment, and exemplary xApps for controlling Open RAN
elements [91]. Deutsche Telekom has deployed a fully dis-
aggregated 5G field trial, integrating components from more E. Open Testbeds
than 8 vendors using SD-RAN open-source uONOS-RIC. As In addition to the aforementioned open-source projects,
the initial complete realization of the O-RAN architecture, several testbeds are available to aid in the implementation of
encompassing O-RU, O-DU, O-DU, RIC, and xApps sourced softwarized 5G networks by leveraging certain open-source
from various providers, this marks a significant milestone in components. We elaborate on some of these testbeds below.
the advancement of the Open RAN movement. On January 1) Colosseum: Colosseum is an open-access and publicly
9, 2024, ONF officially announced its merger with the LF. available extensive wireless testbed designed for experimental
Subsequently, ONF’s work is being introduced as distinct research, utilizing virtualized and softwarized waveforms and
independent projects under the LF [91]. protocol stacks on a fully programmable ”white-box” platform.
4) srsRAN: The srsRAN project, developed by software Colosseum, with 256 state-of-the-art software-defined radios
radio system (SRS), is an open-source RAN solution support- (SDRs) and a substantial channel emulator core, has the
ing both 4G and 5G technologies, featuring an ORAN-native capability to simulate almost any scenario. This allows for the
gNB. This comprehensive RAN solution adheres to standards comprehensive design, development, and testing of solutions
set by both the 3GPP and the O-RAN Alliance, covering the at scale across various deployments and channel conditions. It
L1/L2/L3 protocol stack with minimal dependencies [92]. achieves high-fidelity reproduction of radio frequency scenar-
The srsRAN-based gNB offers flexibility for users to deploy ios through FPGA-based emulation employing finite-impulse
a monolithic gNB on a single machine or distribute RAN func- response filters. These filters accurately model the taps of
tionalities across multiple machines and geographic locations. desired wireless channels, applying them to signals generated
This flexibility enables easy integration with third-party RICs, by the radio nodes to faithfully replicate real-world wireless
PHY solutions, and other O-RAN compliant hardware and environments [95], [97]. OpenRAN Gym has been intricately
software applications and use cases. developed within Colosseum, facilitating experimentation with
The project follows the 3GPP 5G architecture, implement- E2E O-RAN compliant networks, as well as enabling data
ing functional splits between DU and CU, with further dis- collection and AI-driven model development, among other
aggregation into CU CP and CU UP. srsRAN supports third- functionalities [35].
party Near-RT RIC and xApp through the FlexRIC framework, 2) POWDER: Platform for Open Wireless Data-driven
with the ultimate goal of fully supporting the E2 interface [93]. Experimental Research (POWDER) is a versatile infrastruc-
5) OpenRAN Gym: OpenRAN Gym, spearheaded by ture tailored to support a wide range of software-defined
Northeastern University, is a collaborative open-source initia- experiments. It is a city-scale wireless testbed, infrastruc-
tive crafted to facilitate AI-driven and experimental research ture spanning outdoor areas incorporating multiple SDRs,
within the Open RAN ecosystem [35], [94]. The primary goal an indoor laboratory setup for over-the-air experiments, and
is to bring together researchers from academia and industry, a wired attenuator matrix [97]. The principal objective of
creating a dynamic and cooperative environment to advance POWDER is to foster experimental research in heterogeneous
cutting-edge solutions and innovations for Open RAN through technologies, with a particular emphasis on areas such as 5G
vibrant collaboration. OpenRAN Gym builds on frameworks cellular technologies and network orchestration. POWDER is
for data collection and RAN control enabling E2E design and equipped with integrated features that streamline the setup
testing of data-driven xApps by providing an O-RAN compli- of an O-RAN, facilitating quick implementation. Conducting
ant Near-RT RIC and E2 termination [35]. Users can conduct experiments in POWDER involving the Near-RT RIC, xApps,
data collection campaigns, prototype, and evaluate solutions the O-CU Subsystem, and open software for the SMO is a
across a variety of wireless environments and deployments straightforward process [98], [99].
before transitioning them to production networks. 3) COSMOS: The Cloud enhanced Open Software defined
The OpenRAN Gym architecture provided in [94] consists MObile wireless testbed for city-Scale deployment (COS-
of following key components: MOS) testbed is being deployed in West Harlem, New York
• The publicly and remotely accessible experimental wire- City, as a component of the POWDER initiative. The COS-
less platforms like Colosseum, Arena, and PAWR pro- MOS is focused on creating, developing, and implementing
gram platforms for data collection, prototyping, and test- an advanced wireless testbed at a city-scale level. Its purpose
ing solutions in diverse environments [94]–[97]. is to facilitate real-world experimentation with next-generation
 11

wireless technologies and applications. It has been certified by facility, which serves as a versatile hub for validating KPIs,
the O-RAN Alliance as an OTIC [97], [100]. conducting additional demonstrations, and evaluating pivotal
The COSMOS architecture prioritizes ultra-high bandwidth 5G and beyond use cases. The trials conducted within the
and low-latency wireless communication, tightly integrated facility focus on confirming essential 5G-PPP KPIs, thereby
with edge cloud computing. Deployed in upper Manhattan, inherently assessing the capabilities and performance of each
the COSMOS testbed comprises 40-50 advanced software- constituent platform [102].
defined radio nodes, complemented by fiber-optic front-haul
and back-haul networks, as well as edge and core cloud III. I N - DEPTH A NALYSIS OF O-RAN A RCHITECTURE
computing infrastructure. Through a web-based portal, re- WITH A PARTICULAR E MPHASIS ON N ETWORK S LICING
searchers can remotely conduct experiments on the COSMOS The O-RAN architecture is composed of various open
testbed, accessing various facilities for experiment execution, interfaces, protocols, transport links, NFs, and management
measurements, and data collection [100]. functions (MFs); collectively referred to as O-RAN compo-
4) Arena: Arena stands as an innovative open-access wire- nents. The grand objective of such an open and programmable
less testing platform, revolutionizing research in sub-6 GHz architecture is to decrease the need for proprietary hardware
5G and beyond spectrum exploration. Anchored by a grid and software implementations and to create a multi-vendor
of ceiling-mounted antennas within a spacious office environ- and standard-compliant wireless network infrastructure [63].
ment, each antenna seamlessly interfaces with programmable By employing open interfaces and open-source software, the
SDRs. This amalgamation of 12 computational servers, 24 control plane is isolated from the user plane within the O-
symbol-level synchronized SDRs, and a total of 64 antennas RAN architecture [44]. The openness also creates a modu-
imbues Arena with unparalleled computational prowess and lar base station software stack that is deployable on COTS
scalability, ideal for pioneering technology development within hardware [37]. Through these groundbreaking innovations, the
densely populated spectrum bands [96]. Operating on a metic- quintessential goals of the O-RAN Alliance namely, fostering
ulously crafted three-tier design, Arena strategically allocates openness, promoting vendor independence, and enhancing
servers and SDRs within a dedicated room, while antennas programmability are not just achievable but exquisitely real-
elegantly adorn the office ceiling, linked to radios via extensive ized [54], [103]. The openness of the O-RAN components
100 ft-long cables. This configuration guarantees a dynamic, expedites the provisioning of new services for end-users. The
scalable, and reproducible real-time experimental environment, openness of the interfaces in O-RAN architecture brings ser-
faithfully replicating real-world wireless scenarios [96], [97]. vice agility and cloud-scale economics to smaller vendors and
5) X5G: X5G, a pioneering private 5G network testbed network operators, allowing them to introduce new services or
at Northeastern University, Boston, merges open-source and customize the network to meet their specific needs [61]. Open
programmable components from PHY to CN. Notably, it interfaces also enable multi-vendor deployments, making the
stands as the first fully programmable multi-vendor and O- supplier ecosystem more competitive and vibrant [104]–[106].
RAN compliant testbed, a collaborative endeavor involving In addition to openness and vendor diversity, certain ML-
Northeastern, NVIDIA, and OAI. Accelerated by NVIDIA based and AI-assisted features, components, and architectural
graphics processing units (GPUs) at Layer 1 and built on OAI solutions have been introduced by the O-RAN Alliance [104],
for layers 2 and 3, this integration leverages the SCF FAPI [107]. The goal is to integrate intelligence and automation into
for seamless interaction between the MAC and PHY layers. the operations and maintenance of the O-RAN architecture
Such integration enables the inline acceleration of demanding [48], [108]. The integration of automation and intelligence can
PHY tasks on the GPU, fostering scalability and facilitating be achieved by the utilization of state-of-the-art ML-assisted
AI/ML integration within the RAN. The NVIDIA aerial RAN algorithms, including supervised learning, unsupervised learn-
CoLab (ARC) platform operates on a specialized multi-vendor ing, deep learning, reinforcement learning, and many others
infrastructure, featuring 8 servers for the CU and DU, along [104]. These algorithms can be deployed both at the network
with 4 RUs suitable for lab installations. Additionally, it layer and the management layer [108]. The deployment of
incorporates O-RAN 7.2x FH and timing hardware, as well these algorithms makes the operation and maintenance of
as a dedicated 5G CN. NVIDIA ARC and OAI collaborate to O-RAN simpler, resulting in a reduction in OPEX [109].
provide enhanced performance while upholding the openness Moreover, the automation and intelligentization of the O-RAN
and accessibility characteristic of open-source systems, mark- architecture can also reduce human intervention in the loop
ing a significant stride forward in the realm of intelligent 5G and increase the accuracy to handle the network complexity
and beyond use cases [101]. [110].
6) 5GENESIS: The 5GENESIS initiative, backed by the In this section, we will explore the latest O-RAN archi-
European Union, aims to authenticate 5G KPIs across various tecture in a detailed manner, with a special emphasis on the
applications, spanning controlled environments and large-scale network slicing aspects. We will describe its components and
events. It consolidates insights from multiple European Union interfaces that comprise the O-RAN architecture and further
projects and internal research and development efforts of its study the features designed for network slicing. Additionally,
partners to establish a unified, E2E 5G infrastructure across we will discuss MFs related to network slicing defined by the
five experimentation platforms in Europe. These platforms, 3GPP, ETSI, and ONAP. Moreover, we will provide an insight
while possessing unique capabilities, seamlessly interface and into the underlying infrastructure, including the O-Cloud sites,
operate cohesively with one another within the 5GENESIS open transport network, and open cellular sites.
 12

A. Major Components of the O-RAN Architecture configuration parameters related to network slicing in order to
The O-RAN architecture is founded on the disaggregation further enhance the capabilities of the O-RAN architecture.
paradigm of a cellular base station, featuring multiple logical The O-CU is also expected to carry out slice-specific resource
and physical units responsible for different components and allocation and isolation measures using slice awareness capa-
interfaces within the radio network protocol stack. Figure 2 bilities. These nodes are first configured using the O1 interface
illustrates that the O-RAN architecture is composed of four according to the requirements of the individual slices, and
major components: the O-RAN gNodeB (O-gNB), the RIC, they are subsequently modified for different slicing use-cases
the SMO Framework, and the underlying infrastructure. The dynamically by the Near-RT RIC through the E2 interface.
O-gNB part includes the radio functionalities of an O-RAN The O-CU may need to create and send certain performance
slice. These functionalities perform tasks associated with mod- metrics (PMs) across the O1 and E2 interfaces in response to
ulation, coding, resource scheduling, and many others in both requests for PMs from the SMO Framework and the Near-
upstream and downstream directions. The O-gNB consists of RT RIC. These PMs can be utilized for slice performance
the O-CU, O-DU, and O-RU. The RIC comes in two types: monitoring and slice SLA assurance [52], [115].
the Non-RT RIC and the Near-RT RIC, each designed to 2) O-RAN Distributed Unit: The O-DU is a logical node
handle specific control loop and latency constraints [12]. The that hosts the lower layer protocols of the RAN stack and
SMO Framework includes the Non-RT RIC, slice MFs, and serves as a baseband processing unit that handles the high
other SMO functions [22]. The SMO Framework serves as PHY, MAC, and radio link control (RLC) layers [116]. The
an automation platform dedicated for the management and O-DU can be provided in the form of a virtualized network
orchestration of O-RAN radio resources and RAN slices [111]. function (VNF) that can be hosted within a virtual machine or
The underlying infrastructure is responsible for hosting the a container at the edge cloud [16]. It terminates the E2, F1,
components of an O-RAN slice. It includes O-Cloud sites and and O-FH interfaces. In addition, it terminates the RLC, MAC,
transport links. and high-PHY functionalities of the radio interface towards the
In the remaining parts of this section, we discuss each of the UE and the O1 interface towards the SMO Framework [22],
three major components in a detailed manner. We also explain [52]. The O-DU is meant to link with numerous O-RUs. It
how they contribute to the implementation of network slicing terminates the Open FH M-Plane interface towards the O-RU,
in the Release 3 O-RAN architecture. allowing for hierarchical or hybrid O-RU administration within
O-RAN.
B. O-gNB (E2 Nodes) and its Corresponding Interfaces The O-DU supports slice-specific resource allocation strate-
Figure 2 illustrates that each O-gNB is divided into several gies in the O-RAN slicing-aware architecture. The MAC layer
logical nodes within the O-RAN architecture. These nodes needs to allocate and isolate the relevant physical resource
include the O-CU, the O-DU, and the O-RU, or a combined blocks (PRBs) to specific network slices according to the O1
O-RAN eNB (O-eNB). They are collectively referred to as configuration of a PRB allocation along with O-CU directives
the E2 nodes in O-RAN Alliance terminology [112]. In the over the F1 interface and the dynamic guidance received from
following, we provide their detailed overview, along with a the Near-RT RIC through the E2 interface [117]. Similar to the
detailed description of their respective open interfaces. O-CUs, the O-DUs must also generate and send specific PMs
1) O-RAN Centralized Unit: The O-CU is a logical node through the O1 and E2 interfaces according to the requests
that implements the higher layer protocols of the RAN stack, from the SMO Framework and the Near-RT RIC, respectively.
including the radio resource control (RRC) layer, which These PM can be used for the purpose of network slice
controls the life cycle of the connection; the service data performance monitoring and slice SLA assurance [52].
adaptation protocol (SDAP) layer, which controls the QoS 3) O-RAN Radio Unit: The O-RU is a physical node
of traffic flows of bearers; and the packet data convergence that houses the low-PHY layer and radio frequency (RF)
protocol (PDCP), which, among other things, handles packet processing functionalities within an O-gNB, considering the
reordering, packet duplication, and encryption for the air lower layer functional split option [12]. The O-RU serves as
interface [16], [113]. The O-CU terminates the E2 interface the endpoint for both the O-FH interface and the low-PHY
to the Near-RT RIC and the O1 interface towards the SMO functionalities of the radio interface that connect to the UEs.
Framework [22]. The O-CU includes one O-CU control plane It also terminates the O-FH M-Plane interface towards the
(O-CU-CP) and possibly multiple O-CU user plane (O-CU- O-DU and/or the SMO Framework based on the deployment
UP), which communicate with each other through the E1 options. A single O-RU is supposed to serve multiple network
interface [44], as shown in Figure 2. slice instances [118].
According to the 3GPP specifications, the O-CU shall 4) O-eNB: The O-RAN architecture also incorporates the
support functionalities associated with network slicing. The ability to integrate long term evolution (LTE) base stations,
O-CU-UP may either be built as a single instance for each referred to as O-eNB within the O-RAN Alliance terminology.
network slice or it can be shared across many slices depending The O-eNB can take the form of either an evolved NodeB
on the individual requirements of each slice [16]. The O- (eNB) or an next generation eNB (ng-eNB). The correspond-
RAN architecture extends network slicing functionalities and ing interfaces and protocols must also be supported by the
features beyond those defined by the 3GPP by leveraging the O-RAN architecture. To ensure O-RAN compatibility, it is
E2 interface and dynamic slice optimizations provided by the essential to support both the E2 and O1 interfaces to the O-
Near-RT RIC [114]. Moreover, the O1 interface supports more eNB [22].
 13

Service Management and Orchestration (SMO) Framework

Non-RT RIC rApp #1

Other SMO Other M&O Non-RT RIC R1

3GPP MFs ONAP M&O
NFV-MANO Functions Framework Framework rApp #n
Functions
Functions

A1
Y1
Y1 Consumers
xApp #1 Subscription
management
E2 O1
Conflict
xApp #n mitigation
E2

NG-C O-CU
O1 O1
E2 O-CU-CP
O-eNB
X2-C, Xn-C
E1

NG-U
O1
E2 O-CU-UP
Uu X2-U, Xn-U

F1-C F1-U
Uu E2 O1
O-DU
UE

Open FH CUS-Plane Open FH M-Plane

O1
O-FH
O-RU
O2 M-Plane

O-Cloud Notification

Backhaul Midhaul Fronthaul

Regional Cloud Edge Cloud Cellular Sites

Fig. 2. O-RAN Release 3 Slicing-aware Reference Architecture

5) E1 Interface: The E1 interface acts as a control interface, b) F1-U: The F1-U interface is responsible for the actual
linking the O-CU-CP and O-CU-UP entities within an O-gNB user data transmission. It handles the transfer of user data
or O-eNB [119]. This interface is standardized by the 3GPP between the O-CU-UP and the O-DU, playing a critical role
and plays a pivotal role in the O-RAN architecture, promoting in the efficient and reliable transport of user data between the
efficient communication and operation. The utilization of O-RAN components.
standardized interfaces not only ensures the efficiency of the 7) W1 Interface: The W1 interface for the functional split
O-RAN architecture but also offers flexibility and scalability of the eNB is specified in 3GPP Release 15. An ng-eNB com-
for future developments and advancements [120]. prises ng-eNB-CU and ng-eNB-DUs. These components, ng-
6) F1 Interface: The F1 interface is used to connect the O- eNB-CU and ng-eNB-DU, are linked through the W1 logical
CU and O-DU within an O-gNB [119]. The O-RAN employs interface, which enables the separation of control plane and
the principles and protocol stack defined by the 3GPP for user plane functionalities with W1-C, and W1-U, respectively
the F1 interface, as well as the formulation of interoperability [121].
profile specifications. Mirroring the O-CU’s division into user 8) X2 Interface: The O-RAN has inherited the X2 interface
plane and control plane, the F1 interface also comprises two from the 3GPP for the definition of interoperability profile
distinct components: F1-C and F1-U [22]. specification and used to connect the O-CU with other eNBs
a) F1-C: The F1-C interface handles control and sig- in an E-UTRA NR dual connectivity (EN-DC) configuration.
naling functions. It manages the exchange of control infor- The X2-C and X2-U are two parts of the X2 interface for
mation between the O-CU-CP and the O-DU. Control plane transmitting the control plane and user plane information,
functions typically involve activities such as setting up and respectively [22].
releasing connections, managing handovers, and coordinating 9) Xn Interface: The O-RAN has adopted the principles
radio resource allocation. and protocol stack of Xn interface, defined by 3GPP, for
 14

the definition of interoperability profile specification. The Xn b) U-Plane: User Plane pertains to the transfer of in-
interface contains separate components Xn-C and Xn-U to phase and quadrature (IQ) sample data between O-DU and O-
connect the O-CU-CP and O-CU-UP, respectively, to other RU. To ensure coordination of C-Plane and U-Plane timing,
gNBs [22]. the FH interface specifies that C-Plane messages must reach
10) NG Interface: The NG interface is also an interface the O-RU ahead of the latest possible time for the first
adopted by the O-RAN from the 3GPP to connect the O- corresponding U-Plane messages. U-Plane messages will be
CU and the 5G Core (5GC). The NG interface also has two encapsulated using a two-layered header approach, where the
components, NG-C and NG-U, for the control and user planes, first layer includes an evolved CPRI (eCPRI) or IEEE 1914.3
respectively. The NG-C interface connects the O-CU-CP with common header indicating the message type, and the second
the access and mobility management function (AMF), while layer is an application layer containing essential fields for
the NG-U provides a link between the O-CU-UP and the user control and synchronization [122], [124].
plane function (UPF) in the 5GC [22]. c) S-Plane: Synchronization Plane is concerned with the
11) Uu Interface: The 3GPP designates the interface be- communication between the O-RU or O-DU and a synchro-
tween the UE and the e/gNB as the Uu interface. The Uu in- nization controller, typically an IEEE 1588 Grand Master,
terface encompasses a comprehensive protocol stack spanning that may be integrated into the O-DU. O-RAN encompasses
from Layer 1 to Layer 3, constituting a complete entity that the synchronization of frequency, phase, and time across all
terminates within the NG-RAN architecture. When the NG- network elements O-DUs, intermediate switches, and O-RUs
RAN is decomposed, various protocols conclude at distinct for both time division duplexing (TDD) and frequency division
reference points, none of which has been explicitly defined by duplexing (FDD) features [124].
the O-RAN Alliance. Since the Uu messages still continue to d) M-Plane: Management Plane refers to non-real-time
travel from the UE to the targeted e/gNB managed function, management operations between the O-DU and the O-RU.
the O-RAN architecture does not represent it as a distinct Different modes of network connectivity between the O-RU
interface directed to a specific managed function [22]. and the O-DU, as well as the SMO Framework, are possible
12) Y1 Interface: The Near-RT RIC offers RAN analytics based on the transport topology. The fundamental requirement
information services through the Y1 service interface to an for the M-Plane is to establish E2E connectivity between
authorized third party, called the Y1 consumer. These services the O-RU and the entities responsible for its management,
are accessible to Y1 consumers upon mutual authentication including the O-DU, SMO Framework, or entities referred to
and authorization. To access RAN analytics information, Y1 as the O-RU Controllers.
consumers within a public land mobile network (PLMN) The Open FH M-Plane employs a NETCONF/YANG-based
trusted domain can subscribe to or request services via the Y1 system to manage various features such as installation, soft-
service interface. Entities outside the PLMN trusted domain, ware, configuration, performance, fault, and file management
acting as Y1 consumers, can securely utilize Y1 services for the O-RU. Two architectural models are supported for this:
through a standardized exposure function. Y1 consumers, First, the hierarchical model, where one or more O-DUs man-
unlike the other network elements as shown in Figure 2, are age the O-RU via a NETCONF-based interface. Second, the
not denoted as logical O-RAN functions [22]. hybrid model, which allows direct logical interfaces between
the management systems, such as the SMO Framework and the
13) Open Fronthaul Interface: The O-RAN FH Specifica-
O-RU, in addition to the logical interface between the O-DU
tion outlines the splitting and virtualizing the conventional cell
and the O-RU. For Multi-Operator O-RU, various architecture
site, transforming it into an efficient system for the FH, MH,
models involving different Shared Resource Operators are
and BH with enhanced capacity, speed, and latency in the next-
supported. In the hybrid model, the O-RU establishes E2E
generation cellular networks. The physical layer is separated
connectivity with the SMO, either through the O-DU or with
into high-PHY and low-PHY components, employing the
direct logical communication. Importantly, there is no explicit
functional split to outline the architecture of a disaggregated
signaling indicating hierarchical or hybrid configuration, and
and virtualized gNB. The low-PHY resides in the O-RU while
all NETCONF servers supporting the M-Plane specification
the high-PHY is hosted in O-DU [122]. The Open FH Interface
must handle multiple sessions, with all the O-RUs capable of
establishes a connection between the O-DU and O-RU logical
supporting both hierarchical and hybrid deployment [123].
nodes, encompassing both the CUS-Plane and M-Plane [123],
[124].
a) C-Plane: Control Plane specifically refers to the real- C. RAN Intelligent Controller
time control interactions between the O-DU and O-RU. C- The RAN intelligent controller (RIC) stands out as a
Plane messages facilitate the exchange of data-associated significant advancement within the O-RAN architecture [125].
control information necessary for processing user data, such as It epitomizes a software-defined NF to handle aspects of the
scheduling and beamforming commands, if such information eNB or gNB functionality, such as mobility management,
is not supplied via M-Plane. These messages are transmitted traditionally confined to the base stations. By offering real-
for downlink and uplink commands independently. To enhance time visibility and control over O-RAN resources, the RIC
flexibility, C-Plane messages may be sent collectively or plays pivotal role in the O-RAN disaggregation strategy,
individually, depending on the relevant channel for conveying introducing essential features like multivendor interoperability,
the information [124]. intelligence, agility, and programmability, thereby reshaping
 15

the O-RAN landscape [125], [126]. Its integration into the O- within the O-RAN architecture. Several notable examples can
RAN architecture empowers network operators to manage and be found in [132], [108], and [135], where authors present an
optimize O-RAN resources in a flexible and intelligent manner array of xApps tailored to specific applications.
[127], which is also very essential to realize the network The xApps leverage AI/ML models guided by A1 policies
slicing. and generated by the Non-RT RIC [26], [57]. These policies
In addition, it configures network slices, orchestrates net- serve as a foundation for intelligent decision-making within
work operations, checks network performance, and instantly the network. When O-RAN slices are operational, slice-
optimizes the RAN resources in real time by utilizing the open specific PMs are gathered from the E2 nodes and subsequently
interfaces [126], [128]. As depicted in Figure 2, the RIC mani- transmitted to the Near-RT RIC. The Near-RT RIC integrates
fests in two distinct forms, each meticulously designed to cater this information with slice configuration data, facilitating dy-
to specific control loop dynamics and latency requirements. namic optimization of the slices. This collaborative approach
These two variants, namely the Non-RT RIC and the Near-RT between the Non-RT RIC and Near-RT RIC associated with
RIC, play critical roles within the O-RAN architecture [122]. AI/ML is aimed at enhancing the overall efficiency of network
In the subsequent sections, an exhaustive exploration of both slicing within the O-RAN architecture [5], [130].
types of RIC will be provided, elucidating their functionalities, 2) Non-Real-Time RAN Intelligent Controller: The Non-RT
applications, and significance within the broader context of RIC stands as a core component of the O-RAN architecture. It
network optimization and management. is responsible for non-real-time management and optimization
1) Near-Real-Time RAN Intelligent Controller: The Near- of the O-RAN components and resources [112]. As illustrated
RT RIC serves as a logical entity, facilitating precise and in Figure 2, the Non-RT RIC also facilitates the execution
close-to-real-time control and optimization of the E2 nodes of third-party applications known as rApps. These modular
and resources. The Near-RT RIC resides close to the O-gNB software applications are designed to use the capabilities
and interacts with them to optimize its functionalities [129]. offered by the Non-RT RIC Framework’s R1 interface to
It achieves this through meticulous data collection and actions provide additional value services related to O-RAN operation
performed via the E2 interface [127]. Operating seamlessly [54]. Examples include driving the A1 interface and suggesting
within a near-real-time control loop, the Near-RT RIC adheres values and actions for potential implementation via the O1 and
to a time span ranging from 10 milliseconds to 1 second the O2 interfaces [22].
[130]. It functions as a software framework tailored for hosting The Non-RT RIC autonomously configures all O-RAN
xApps, which are intelligent, autonomous, and microservice- components, eliminating the need for network operator inter-
based applications [131]. vention. The MNOs can leverage the Non-RT RIC to gain
During onboarding, these xApps can identify the data they insights into network operations and optimize them in real-
collect, process, consume, and provide [22]. The Near-RT RIC time [129]. Its functionality is intrinsic to the SMO Framework
assumes the responsibility of managing and optimizing O- within the O-RAN architecture and offers an A1 interface to
RAN resources in near-real-time to meet the dynamic and the Near-RT RIC. The Non-RT RIC can employ data analytics
diverse requirements of various applications and services [17]. and AI/ML model training to develop RAN optimization
This optimization is achieved by integrating xApps, deployable actions, leveraging SMO services like data gathering and
to the Near-RT RIC as needed, to offer specific functionalities provisioning services provided by O-RAN nodes [136]. The
such as radio resource management (RRM) [60], [131]. These Non-RT RIC distributes trained models to the Near-RT RIC
xApps leverage UE and cell-specific metrics collected through for runtime execution. The Non-RT RIC is responsible for
the E2 interface to optimize O-RAN resources and function- applying the AI/ML algorithms to deliver innovative use-cases
alities in real time, ensuring efficient utilization of network within the O-RAN architecture [137]. Therefore, the Non-RT
resources and an enhanced user experience [112], [132]. RIC is a key component in O-RAN, delivering highly complex
Furthermore, the Near-RT RIC gains direct control over the functionalities related to the O-RAN slicing.
E2 nodes and their resources through policies and information The Non-RT RIC retrieves slice-specific PM and config-
transmitted via the A1 interface from the Non-RT RIC [130], uration parameters, along with optional internal information,
[133]. In specific scenarios, the Near-RT RIC has the authority from the servers. The learning capabilities of AI/ML models
to monitor, suspend, stop, override, or control an E2 node can tackle complex problems, such as applying RRM policies
based and its resources on rules associated with a function [112]. Training models enable non-real-time optimization of
exposed in the E2 service model [22], [134]. slice-specific parameters over the O1 interface. The collected
The Near-RT RIC plays a crucial role in facilitating net- information and performance metrics are sent to the Near-RT
work slicing within the O-RAN architecture. Specifically, it RIC. The Near-RT RIC can use this PM, configuration, and
empowers near-real-time optimization of O-RAN slice subnets other data for dynamic slice optimization to prevent potential
through the utilization of xApps. This optimization involves SLA violations between network slices [31]. Furthermore, the
communication with O-CU and O-DU via the E2 interface. Near-RT RIC controls the network resources through the E2
To ensure efficient operation, xApps must possess awareness interface, and the Non-RT RIC controls the cloud resources
of O-RAN slices, allowing them to employ slice-aware al- through the O2 interface based on decision made by the
gorithms for the assurance of network slice SLA [52]. In collected information [138].
response to this challenge, a growing body of research has 3) R1 Interface: The R1 interface resides within the in-
emerged proposing xApps for various optimization problems ternal structure of the Non-RT RIC. Through this interface,
 16

the Non-RT RIC framework provides services that empower components are executed by the SMO Framework. The SMO
rApps to access data for initiating intelligent policy decisions Framework is a set of integrated MFs and services presented
and optimizing O-RAN operations. Additionally, rApps utilize within the O-RAN architecture [48], as shown in Figure 2.
the R1 interface to exchange authorized enrichment data with It encompasses the management systems and functions of
the Near-RT RIC and to share services and analytics within various SDOs. The SMO Framework utilizes standardized
the Non-RT RIC framework [138], [139]. service-based management interfaces to enable interoperability
4) A1 Interface: The A1 interface, defined by the O-RAN among the MFs of various SDOs within the SMO Framework
Alliance, serves to link the Near-RT RIC with the Non-RT [48]. Operating on the principle of services based architecture
RIC. Through the A1 interface, the Non-RT RIC can provide (SBA), the SMO Framework facilitates the provision and
policy guidance to the Near-RT RIC, referred to as A1 policies consumption of services such as authentication, authorization,
[45]. The Near-RT RIC components communicate with the A1 service registration and discovery, data management, and
policy functions implemented over the A1 interface. These trained model sharing, among others [22].
A1 policy functions utilize the A1 interface to facilitate the The SMO Framework manages the FCAPS operations for
provisioning of policies for specific UE or groups of UEs, O-RAN components via the O1 interface. It enables intelligent
monitor policy states, provide basic feedback from the Near- optimization and RRM via the Non-RT RIC, administers
RT RIC, offer enrichment information as required by the O-Cloud functionalities via the O2 interface, and provides
RICs, and streamline the training, distribution, and inference platform resources and workload management. To execute
of ML models [45], [140]. Slicing use-cases, such as slice SLA functionalities associated with FCAPS, particularly from the
assurance, can utilize these services. For example, the Non-RT SMO Framework to O-RU, an Open FH M-Plane interface is
RIC can employ policy management via the A1 interface to employed. The interface linking the Non-RT RIC and Near-RT
transmit slice-specific policies, guiding the Near-RT RIC in RIC is denoted as the A1 interface. The Non-RT RIC acquires
slice resource allocations and slice-specific control activities, data from various components of O-RAN, develops or selects
while also receiving slice-specific policy feedback [52]. ML models, and transmits them to the Near-RT RIC via the
5) E2 Interface: The E2 interface serves as the connection A1 interface. The A1 interface is capable of supporting three
point between the Near-RT RIC and E2 nodes, offering support service types: policy management, information enhancement,
for E2 primitives such as Report, Insert, Control, and Policy. and ML model management [10], [52], [143].
These primitives empower both RICs to manage the services
provided by the E2 nodes, enabling control over procedures The design of the SMO Framework, particularly the Non-
and functionalities. Specifically, the Near-RT RIC, with a RT RIC, allows for flexibility in implementation. This signifies
focus on xApps, manages specific operations within E2 nodes, that operators will have the ability to select which features
necessitating the deployment of an E2 agent at the node [130]. to include or exclude in a Non-RT RIC implementation. The
E2 nodes communicate information to the Near-RT RIC SMO Framework can also be connected to an E2E multi-
via the E2 interface, notifying it about functions that xApps domain service orchestrator, which connects domain-specific
may handle [31], [133]. Furthermore, the E2 node’s interface modules used by the SMO Framework to coordinate the
facilitates the collection of measurements from the O-RAN network slices in each subnet (e.g., RAN, TN, and CN).
to the Near-RT RIC, either periodically or in response to This E2E Framework enables the on-demand creation and
predetermined trigger events. This interface connects one or E2E management of network slices across a distributed 5G
more cells, slices, QoS classes, or specific UEs to both control infrastructure. The SMO Framework can include and shall also
and data collection operations [141]. meet the architectural requirements of the 3GPP, ETSI, and
Slice-specific xApps utilize these primitives to influence the ONAP for network slicing using a set of MFs based on their
configurations and behaviors of E2 nodes related to slices. respective specifications.
Examples include RRM, radio resource allocations, MAC The MFs of these SDOs within the SMO Framework
scheduling policies, and other configuration parameters em- perform tasks such as creating, operating, modifying, and
bedded in various O-RAN protocol stacks. The RIC employs terminating an network slice, as well as scaling the under-
the E2 interface for configuring and receiving slice-specific lying resources. The O-RAN Alliance preserves the network
reports and performance data from the E2 nodes [52], [136]. slicing concepts, procedures, and functionality of architectural
components defined by the 3GPP, ETSI, and other related
D. The SMO Framework and its Corresponding Interfaces SDOs. The O-RAN architecture keeps consistency with 3GPP
In alignment with the primary objectives of the O-RAN in terms of the architectural design and positioning of network
Alliance, the 5G RAN architecture is expected to be highly functions to the most possible extent but defines some general
flexible, reliable, scalable, and interoperable across multiple principles on top of the network slicing principles of the
vendors for diverse deployment scenarios. It operates on aforementioned SDOs. For instance, interface specifications
COTS white box hardware in a cloud-native and virtualized shall be compatible with 3GPP, standardized management
infrastructure, leveraging automation mechanisms as well as service interfaces for O-RAN slicing management services
AI and ML algorithms [104]. Therefore, the automation and shall be provided, multi-vendor interoperability shall be given,
intelligentization of the management and orchestration of the various network operator deployment options shall be sup-
O-RAN architecture take up the utmost significance [142]. ported, as well as management of slice subnets in multi-
The autonomous management and orchestration of the O-RAN operator scenarios shall be provisioned.
 17

1) O1 Interface: The O-RAN managed elements and the slicing, can be achieved through a collection of functional
management entities within the SMO Framework are logically blocks as illustrated in Figure 3.
connected through the O1 interface, as shown in Figure 2. The
goal of utilizing the O1 interface is to guarantee the opera- NSMF NSSMF

tion and management of the O-RAN components, including ....

MnS .... MnS MnS .... MnS
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 MnS .... MnS MnS .... MnS
CSMF ....
according to the service requirements of an network slice. NFMF NF
The 3GPP has defined a slice-specific information model
that includes RRM policy attributes to provide the ratio of Fig. 3. 3GPP Management Architecture within the SMO Framework
PRBs among slices [34]. These models can be extended with In the following, we elaborate on the previously mentioned
additional information models to capture slice profiles and 3GPP MFs and their role in the realization of management
slice-specific configuration parameters to support the O-RAN and orchestration of O-RAN slices.
slicing use-cases that also carry over the O1 interface. The
interface may be further used for the collection of slice-specific • Communication service management function
performance metrics and faults from the O-RAN nodes [52]. (CSMF): This MF translates the communication service
2) O2 Interface: The O2 interface serves as an open logical requirements received from third parties – such as
interface that enables secure communication between the SMO operations support system (OSS)/business support
Framework and O-Cloud sites, as introduced in [145]. It system (BSS), network slice as a service (NSaaS)
enables the life cycle management of VNFs that operate on tenants, and others – into network slicing requirements
O-Cloud infrastructure. The O-RAN functionalities within the [147].
network are hosted by the O-Cloud infrastructure, utilizing • Network slice management function (NSMF): The
the O2 interface in SMO Framework to facilitate cloud in- NSMF is in charge of managing an E2E network slice
frastructure management and deployment processes. The O2 after the CSMF determined its required requirements. It
interface supports the orchestration of O-Cloud infrastructure manages the resources required for hosting the communi-
resource management, such as inventory, monitoring, provi- cation services and interacts with the NSSMFs responsi-
sioning, software management, and life cycle management. It ble for managing the Network Slice Subnet in that domain
also facilitates the deployment of O-RAN NFs, offering logical [147], [148].
services for controlling the deployment life cycle that make use • Network slice subnet management function (NSSMF):
of cloud resources. While the Non-RT RIC may be instantiated The NSSMF in each network domain (i.e., RAN, trans-
with other SMO functions as part of the SMO Framework, port, and core) instantiates the required resources based
the O2 interface is not expected to be utilized for the life on the instructions of the NSMF. Each NSSMF orches-
cycle management of the Non-RT RIC. The O2 interface is trates the domain-specific resources on its subnet to meet
designed to be expandable, so new data or features can be the service requirements in that subnet. For example,
introduced without necessarily altering the protocol or the the RAN NSSMF is responsible for orchestrating the
processes. This interface supports a multi-vendor environment RAN portion of a network slice, such as life-cycle man-
and is unaffected by particular SMO Framework and O- agement, configuration management, performance man-
Cloud implementations. By rearranging network components, agement, and fault management of RAN slice subnets.
updating the system, or upgrading the system, operators who Furthermore, the RAN NSSMF interfaces with the RIC
are linked to the O-Cloud may then manage and run the for control plane operations related to O-RAN slices
network using the O1 or/and O2 interfaces [146]. within the O-RAN architecture [147], [148].
3) 3GPP Network Slicing MFs within the SMO Framework: • Network function management function (NFMF): The
The 3GPP-defined MFs for the management and orchestration NFMF offers NF management services within the NF
of network slicing are the CSMF, NSMF, NSSMF, and management model. It manages multiple NFs and handle
network function management function (NFMF). These MFs the application-level management of both VNF and physi-
can be employed within the SMO Framework, considering the cal network function (PNF) [48]. Additionally, it produces
requirements defined by the 3GPP for network slicing. Further- the NF provisioning service, which includes configuration
more, several functional and non-functional requirements for management, Fault management, and performance man-
network slicing architecture have also been defined by the O- agement. At the same time, the NFMF consumes the NF
RAN Alliance in [52]. Both sets of requirements defined by the provisioning service provided by VNFs and PNFs [148].
3GPP and O-RAN Alliance are critical for the realization of To provide seamless management and orchestration solu-
network slicing in O-RAN architecture and the functionalities tions, the SMO Framework can be customized to incorporate
of the 3GPP MFs. The provision of management service either all or some of the 3GPP-defined MFs mentioned earlier.
(MnS) for a mobile network, which encompasses network The decision regarding the inclusion of these MFs pertains to
 18

deployment considerations, which we discuss in Section IV. one or more VNF instances within an network slice [150].
4) NFV-MANO within the SMO Framework: The network The VNFs can be of the same type or different types. The
functions virtualization management and orchestrierung (NFV- VNFM is also responsible for the FCAPS of the VNFs,
MANO) Framework is specified by the ETSI industry speci- and scaling up and down the VNFs in its service region
fication group (ISG) on NFV. The SMO Framework can also [149].
include the NFV-MANO [27]. Within the context of the SMO • NFV infrastructure (NFVI): The NFV considers soft-
Framework, the NFV-MANO is responsible for the manage- ware or hardware accelerators as supplementary resources
ment and orchestration of the VNFs and virtual resources of capable of virtualization, which can be exposed as virtual
an O-RAN slice. The NFV-MANO originally consisted of accelerators within the VNF layer [151]. The NFVI
three functional blocks: the network function virtualization includes all the underlying components of the infrastruc-
orchestrator (NFVO), the virtual network functions manager ture, comprising both the hardware and software neces-
(VNFM), and the virtualized infrastructure manager (VIM). sary for hosting VNFs. It presents infrastructure resources
It also included an element management (EM). In Release in a virtualized form for utilization by VNFs and network
4, the ETSI ISG NFV added five new MFs in order to services, encompassing virtual compute, virtual storage,
manage the containerized and transport aspects within the and virtual network resources [149]. Nevertheless, it is
NFV-MANO Framework [149], [150]. Figure 4 illustrates all essential to note that existing NFV-MANO specifications
these functional blocks as well as the newly added MFs. do not comprehensively address NFVI management as-
pects, especially concerning the management of physical
Or-Or
infrastructure within the cellular network. As a result,
NFVO OSS/BSS
complete support for full infrastructure management ser-
Os-Ma-nfvo vice (IMS) functionality is not achievable under the
Or-Vnfm
current specifications [151].
VNFM EM
• Virtualized infrastructure manager (VIM): The VIM
is tasked with controlling and managing the computing,
CCM
VNF storage, and network resources of the NFVI within the
CISM underlying telecommunication infrastructure [150]. It is
WIM important to note that the actual deployment and mainte-
NFVI
nance of the VIM falls outside the scope of NFV-MANO.
CIR CIS
Nevertheless, the interfaces provided by VIM are within
the scope [149]. Hence, the NFV-MANO utilizes this in-
VIM WAN terface to influence the decisions made regarding the three
types of resources within the underlying infrastructure
layer.
Fig. 4. NFV-MANO Architecture within the SMO Framework • Element management (EM): The EM, which is equia-
In the following, we discuss these MFs and functional lent to the NFMF within the 3GPP management system,
blocks (FBs), as well as the application within the SMO manages the FCAPS of a VNF from a functional and ap-
Or-Vi

Framework, in a detailed manner. plication points of view. It is worth noting that the VNFM
• Network function virtualization orchestrator (NFVO): also manages the FCAPS of a VNF, but exclusively from
The NFVO has two primary responsibilities: Firstly, it a virtualization perspective [149].
Or-Wi

orchestrates NFV infrastructure (NFVI) resources across • Container infrastructure service (CIS): In the
multiple VIMs fulfilling resource orchestration functions. container-based NFV-MANO, the CIS is the execution
Vi-Vnfm

Secondly, it manages the lifecycle of network services environment for a container cluster where the container-
by performing network service orchestration functions, based services run [149]. As ETSI NFV Release 4 pro-
which include coordinating groups of VNF instances to motes enhanced functionalities, CIS is becoming increas-
collectively achieve a more complex function. The NFVO ingly crucial for efficient and agile containerized network
facilitates joint instantiation and configuration of these in- deployments.
stances, establishes required connections between differ- • CIS management (CISM): The CISM is responsible
ent VNFs, and manages dynamic configuration changes, for the management and orchestration of CIS instances
such as scaling the capacity of the network service. The and CIS archival within the NFV-MANO. It interacts
network service orchestration function relies on services with other NFV-MANO components like the VNFM and
provided by both the VNFM function and the resource Orchestrator, providing an abstraction layer for CIS func-
orchestration function. The NFVO uses resource orches- tionalities. Its capabilities encompass container network,
tration functionality to offer services that allow abstracted workload, compute, and storage management, along with
access to the NFVI resources independently of specific container configuration executed by CIS [149].
VIMs. Additionally, it governs VNF instances sharing • CIS cluster management (CCM): The CCM function
resources within the underlying NFVI [148], [149]. is responsible for handling the lifecycle and operation, as
• Virtual network functions manager (VNFM): The well as configuration, performance, fault, and resource
VNFM is responsible for the lifecycle management of management, of the CIS cluster within the NFV-MANO
 19

[149]. It acts as the bridge between the orchestrator introducing scalability and resiliency enhancements to the
(overall NFV service provisioning) and the underlying components under its management.
CIS instances within the cluster. • Use case user interface (UUI): The UUI operations
• Container image registry (CIR): The CIR is responsible facilitate a broader spectrum of lifecycle management
for container image management [149]. It is an internal actions using a simple point-and-click interface, enabling
repository used by the NFV-MANO to store and manage operators to execute tasks more easily [153].
container images specific to their containerized network • Service orchestrator (SO): The SO automates sequences
functions (CNFs) deployments. The CIR is also responsi- of activities, tasks, rules, and policies to execute specified
ble for implementing security measures to control access processes required for the on-demand creation, modifica-
and ensure image integrity, version control and lifecycle tion, or removal of network, application, or infrastructure
management of container images, and integration with services and resources. Operating at a high level, the SO
continuous integration (CI)/continuous deployment (CD) offers orchestration with a comprehensive view of the
pipelines for building and pushing new images. infrastructure, network, and applications [87].
• WAN infrastructure manager (WIM): The WIM pro- • ONAP optimization framework (OOF): The OOF of-
vides management and orchestration services for multi- fers a declarative and policy-driven method for devel-
site connectivity service (MSCS). It establishes connec- oping and executing optimization applications such as
tivity between the NFVI-point-of-presences (PoPs) using homing/placement and change management scheduling
MSCS which abstracts the details of the connections on optimization [87].
the transport network [149]. The NFVI-PoP is an ETSI’s • Service design and creation (SDC): The SDC offers
terminology, which is a synonym for O-Cloud O-RAN. tools, methods, and repositories for defining, simulating,
5) ONAP Architecture within the SMO Framework: ONAP and certifying system assets along with their correspond-
provides a comprehensive platform to network operators, ing processes and policies. These assets are categorized
cloud service providers, and businesses for the orchestration, into four groups: resources, services, products, or offers.
management, and automation of network and edge computing The SDC environment caters to a variety of users through
services and resources. Faster automation of new services and shared services and utilities. Within the design studio,
full lifecycle management, which are essential for 5G and designers of products and services can onboard, extend,
beyond, are made possible by real-time, policy-driven orches- or retire resources, services, and products [154].
tration and automation of PNFs and VNFs [152]. Figure 5 • Active and available inventory (AAI): The AAI offers
illustrates a simplified ONAP architecture from a functional real-time and historical views of a system’s resources, ser-
perspective. The ONAP design time environment facilitates vices, products, and their interrelationships. It integrates
the onboarding of services and resources into ONAP, along data from multiple ONAP instances, BSS, OSS, and
with the design of necessary services. On the other hand, the network applications, providing a comprehensive ”top to
ONAP runtime environment operates as a model- and policy- bottom” view from end-user products to the underlying
driven orchestration and control framework, automating the resources. AAI serves as a dynamic registry, continu-
instantiation and configuration of services and resources. ously updated by controllers in real-time to support the
The components of the ONAP architectural framework are flexibility of SDN/NFV. The metadata-driven nature of
briefly discussed in the following. AAI allows for the rapid addition of new inventory types
through SDC catalog definitions, eliminating the need for
OSS/BSS lengthy development cycles.
• Common controller software development kit
Northbound Interface (NBI)
(CCSDK)/ SDN controller (SDN-C): The CCSDK/
Design Run Time Manage ONAP OOM
SDN-C handle specific configurations for both the RAN
Time
and transport subnets of a network slice. When requested
Interfaces
Portal-NG UUI External APIs CLI
by SO from TN NSSMF, it sets up and configures the
new transport network slice subnet instance (NSSI),
Shared including updating the transport network during network
Policy Correlation
SO AAI Services slice instances (NSI) reuse, activation/deactivation, and
Framework Engine

SDC termination. Similarly, when invoked by the SO from

Data Movement as a RAN NSSMF, it configures/re-configures the existing
Microservice Bus (MSB) Platform (DMaaP) OOF
RAN NFs for RAN NSSI or NSI reuse. Additionally,
CCSDK VFC
Logging when policy triggers closed loop actions in RAN for
DCAE CDS SDN-C Framework
RAN NSSIs, it sends relevant configuration updates to
the Near-RT RICs [87], [154].
Fig. 5. ONAP Architecture: Microservices Interaction Diagram • Controller design studio (CDS): The CDS framework
• ONAP operations manager (OOM): The OOM is re- provides blueprint definitions and archives for configu-
sponsible for the complete life cycle management and ration management processes. It comprises a graphical
orchestration of ONAP components. Furthermore, OOM user interface (GUI) and run time components. The GUI
contributes to the advancement of ONAP maturity by manages user input and displays both design time and
 20

run time activities. It facilitates the creation of controller structure as the O-RU or situated at the base. Typically, the
blueprints, including selecting design guidelines, incor- cellular network site is designed to accommodate multiple
porating artifact templates, and adding components. For sectors, thereby supporting several O-RUs. These sites play a
run time, it allows user to direct the system to resolve pivotal role in the O-RAN architecture, serving as the points
the unresolved elements in the blueprint and downloads of connection between the O-RAN architecture and the core
the resulting configuration into a VNF. It also enables network infrastructure. They facilitate the transmission of data,
the creation of data dictionaries, capabilities catalogs, and control signals, and synchronization information between the
controller blueprints. The primary role of the Controller radio units and the O-DU. The cellular network sites are
Design Studio is to generate and populate a controller distributed uniformly or non-uniformly based on parameters
blueprint, create a configuration file, and download it to such user density, network topology, and others. They are
a VNF/PNF [153], [154]. classified as Macro, Micro, Pico, and Nano cellular network
• Data collection, analysis and event (DCAE): DCAE, in sites.
collaboration with other ONAP runtime components, pro- 2) Cloud Site: A Cloud Site denotes a tangible location
vides closed control loop automation, delivering FCAPS equipped with Cloud Infrastructure resources, suitable for
functionality. DCAE plays a key role in gathering perfor- O-Clouds, and possibly accommodating other non-O-Cloud
mance, usage, and configuration data, conducting analyt- resources. O-Clouds are deployed at both Regional Cloud and
ics computations, aiding in troubleshooting, and dissem- Edge Cloud locations. These sites serve as centralized points
inating events, data, and analytics to entities like policy, for hosting VNFs, SDN controllers, and other cloud-native
orchestration, and the data lake. Working with the policy applications within the O-RAN architecture. The Regional
framework and closed loop automation management plat- Cloud provides broader coverage and higher capacity, while
form (CLAMP), these components detect network issues the Edge Cloud brings computational resources closer to
and suggest appropriate remediation. Actions can be the network edge, enabling low-latency and high-bandwidth
automatic or trigger notifications to the SO or controllers services.
for intervention, as configured by the operator. The policy a) Edge Cloud: Edge Cloud refers to a site that facil-
framework is expanded to include additional decision itates virtualized RAN functions for numerous cellular sites,
capabilities through adaptive policy execution [153]. offering centralized functions for those sites. Depending on the
• Policy Framework: The Policy Creation component operators use case, an Edge Cloud may cater to a vast physical
focuses on handling policies, encompassing rules, con- area or a relatively small one in proximity to its cellular sites.
ditions, requirements, constraints, attributes, or needs Nevertheless, the sites served by the Edge Cloud must be
that require provision, maintenance, and enforcement. sufficiently close to the O-RUs to meet the network latency
At a granular level, policies involve machine-readable requirements of the O-DU functions. This proximity ensures
rules for executing actions based on triggers or requests, that communication between the radio units and the O-DUs
considering specific conditions. This enables the rapid occurs with minimal delay, enabling efficient and responsive
modification of policies by updating rules, facilitating the network operations and service delivery.
adjustment of technical behaviors without rewriting soft- b) Regional Cloud: Regional Cloud designates a site
ware code. Policy simplifies the management and control supporting virtualized RAN functions for numerous cellular
of complex mechanisms through abstraction [153]. sites across multiple Edge Clouds, offering extensive central-
• External API: The External API offers northbound ization of the functionality. The sites served by the Regional
interoperability for the ONAP platform, serving as an Cloud need to be sufficiently close to the O-DUs to fulfill the
access point for third-party frameworks and facilitating network latency requirements of both the O-CU and the Near-
interactions between operator BSS and relevant ONAP RT RIC. This proximity ensures that communication between
components. This abstracted view of the platform within the O-CU and O-DU, as well as the Near-RT RIC, occurs
the existing BSS/OSS environment eliminates the need within the required latency thresholds. It enables effective co-
for lengthy and high-cost infrastructure integration [87]. ordination and optimization of RAN resources across a broader
geographical area while maintaining operational efficiency and
E. The Underlying O-Cloud and O-Transport Infrastructure responsiveness.
The underlying infrastructure of O-RAN comprises the O- 3) O-RAN Cloud Platform: A cloud computing platform
Cloud sites, the cellular sites (which include the Regional known as O-Cloud consists of physical infrastructure nodes
Cloud and Edge Cloud Sites), and the transport network. The that are compatible with O-RAN and may host Near-RT RIC,
two cloud sites and cellular sites are used to host the O- O-CU, and O-DU, along with supporting software and nec-
CU, O-DU, and O-RU of an O-RAN slice, respectively. The essary management and orchestration services. An O-Cloud
transport network is responsible for providing connectivity node is composed of a group of central processing units
between several virtual or physical NF of an O-RAN slice (CPUs), random access memory (RAM), storage, network
deployed at cellular and/or cloud sites. In this section, we interface cards (NICs), basic input and output system (BIOS),
provide a brief overview of these major components of the baseboard management controllers (BMCs), and accelerators,
underlying infrastructure in the O-RAN architecture. which collectively handle computationally intensive tasks [22].
1) Cellular Site: A cellular network site refers to the Depending on the deployment scenario selected within an O-
locations of O-RUs, which may be colocated on the same Cloud instance, the O-Cloud platform can virtualize various
 21

NFs and thus take over RAN functions within the overall O-Clouds and/or cellular network sites. The O-Cloud is an O-
architecture. Further details on these aspects are provided in RAN Cloud Platform comprising both hardware and software
Section V. components designed for executing O-RAN NFs in cloud
4) O-Cloud Notification API: The O-Cloud notification computing environments. The hardware includes compute, net-
interface facilitates event subscription for consumers like the working, and storage components, possibly incorporating ac-
O-DU, deployed within the O-Cloud environment. Through celeration technologies to optimize performance for hosting O-
this interface, event consumers can subscribe to receive notifi- RAN NFs. The software component of the O-Cloud provides
cations and statuses from the O-Cloud. Additionally, the cloud open and well-defined APIs, facilitating the life cycle of an
infrastructure offers event producers, allowing cloud work- O-RAN slice and its associated NFs. It is worth noting that the
loads to access notifications and statuses that may otherwise software is independent of the hardware, allowing flexibility
only be accessible within the infrastructure itself [22], [139]. and openness in vendor selection and ensuring compatibility
5) Transport Network: In disaggregated O-RAN deploy- with O-RAN NFs from various software suppliers.
ments, the O-CU and O-DU may be deployed in two dif- In either scenario, whether the NFs are virtual or physical,
ferent distributed O-Cloud sites. To enable communication they must be mapped onto appropriate hosts within the O-
between O-CU, O-DU and O-RU, networking infrastructure RAN infrastructure. The mapping of NFs onto underlying
must extend across the cellular site and distributed O-Cloud infrastructure is a crucial decision in the implementation of
sites through open and highly-reliable transport networks. The logical network functionalities of an O-RAN slice, especially
transport network and services encompass a broad spectrum, in cloud computing environments. The deployments can range
involving FH, MH, and BH, as well as NR, legacy LTE, and anywhere from fully distributed to maximally centralized
legacy universal mobile telecommunications system (UMTS) configurations based on Edge and Regional O-Cloud sites (or
technologies. These services span the CP, UP, and manage- the so-called PoP in ETSI terminology). The decision entails
ment plane (MP), and are designed to support the opera- determining the optimal execution location for each logical
tional needs of different operators and various E2E services function, with potential impacts on performance, scalability,
or applications such as URLLC and eMBB. The transport cost, and other crucial factors. In this regard, the O-RAN
network must exhibit high flexibility to accommodate various Alliance has introduced the O-Cloud architecture and outlined
use cases and RAN designs. Each segment of the physical several deployment scenarios for O-RAN NFs within the
transport network may need to support multiple slices, diverse cloud-native architecture in [145]. Moreover, the document
5G services, and different 3GPP interfaces based on specific highlights numerous considerations essential for deploying
requirements. logical NFs across different O-Clouds. The diverse slicing
a) Fronthaul: FH in O-RAN is defined as the connec- and NF deployment options within O-RAN require a range
tivity in the RAN infrastructure between the O-DU and O- of management and orchestration solutions, leading to the
RU. Mobile interfaces associated for the FH include Control, multiple deployment options for the SMO Framework.
User, Synchronization, and Management planes. O-RUs and In the subsequent subsections, we delve into multiple de-
the corresponding serving O-DUs are positioned in close ployment alternatives for O-RAN NFs, aligning them with the
proximity to satisfy the delay criteria linked with FH [155]. underlying infrastructure. Furthermore, we examine diverse
b) Midhaul: The MH network represents a logical seg- network slicing deployment possibilities within the O-RAN
ment within the transport network, enabling communication architecture. Additionally, we shed light on various deploy-
between O-DU and O-CU and facilitating the transport of ment choices concerning the SMO Framework, emphasizing
3GPP F1/W1/E1 interfaces. In cases where O-DU and O-CU the significance of network slice MFs.
function as a unified entity, these interfaces remain inacces-
sible, and the transport network lacks a MH component. Ad-
ditionally, it provides inter O-CU communication supporting A. O-RAN NF Deployment Scenario
the transport of the 3GPP Xn interface. In situations where The O-RAN Alliance has considered various options for
MNOs havent implemented a split O-DU and O-CU RAN virtualizing the O-RAN NFs in Regional and Edge Clouds
architecture, these interfaces must be supported in the BH. proposing different deployment scenarios that can be sup-
c) Backhaul: In the O-RAN architecture, the BH con- ported by the O-RAN specifications. These deployment sce-
nects the O-CU to the 5G mobile core. It has a CP and UP narios can be distinguished by a particular grouping of func-
component to ensure a clear demarcation between customer tionality at different key locations, such as cellular sites, edge
user data and the 3GPP 5G CP. The associated CP interfaces clouds, and regional clouds, as well as by an indication of
N1, N2, N4 and Xn-c are multipoint interfaces between O- whether the functionality is provided at a particular location by
CU-CP, UPF and other 5G CN components. The UP interface an O-RAN PNF based solution, where software and hardware
is provided by N3 between O-CU-UP and UPF, N9 between are tightly integrated and share a single identity, or by cloud
UPF and UPF, and Xn-u between O-CU-UP and O-CU-UP. services. In Figure 6, we illustrate several NF deployment
scenarios presented in [145], [156], [157], where on the top,
IV. O-RAN NF S , N ETWORK S LICING , AND SMO it shows the NFs and each scenario exhibits how these NFs
D EPLOYMENT O PTIONS are deployed, as cloudified NFs on O-Cloud or as PNFs at
The NFs in the O-RAN architecture can be implemented the cellular site. Each of these deployment scenarios will be
as VNFs and/or PNFs that can be hosted by the underlying explained below in detail.
 22

also considered for future use for a similar reason.

E2 E2 E2 O-FH In the context of O-RAN deployment, the Open FH plays
O-CU
Near-RT RIC O-CU-CP F1
O-DU O-RU
a pivotal role, delineating the separation between VNFs de-
O-CU-UP ployed within the O-Cloud and the Cellular network sites.
Open FH O-RUs always occupy the Cellular site, while O-DU can be
A O-Cloud O-RAN located at the Edge Cloud site. It is feasible to relocate O-
PNF
Edge Cloud
DU closer to the Cellular site to adhere to maximum delay
E2 Cellular Site
requirements, but extending their placement farther from the
B O-RAN
O-Cloud O-Cloud
PNF Cellular sites could potentially violate RAN internal and/or
Regional Cloud Edge Cloud
F1, E2
Cellular Site RAN service-specific timing constraints [156]. A common
O-RAN deployment scenario involves moving O-DU instances towards
C O-Cloud O-Cloud
PNF or even to the Cellular site together with O-RU, especially
Regional Cloud Edge Cloud Cellular Site
when the Edge Cloud site must be closer to the Cellular
D O-Cloud O-RAN PNF O-RAN Site due to factors like fiber availability or other constraints.
PNF
Regional Cloud Edge Location Cellular Site
However, such adjustments may compromise the advantages
associated with centralization and pooling [122].
Scenarios

E O-Cloud O-Cloud
The placement of O-CU and its associated UPF is deter-
Regional Cloud Cellular Site mined by the lower latency of the F1 interface or service-
F O-Cloud O-Cloud O-Cloud
specific constraints. For example, the placement of O-CU-UP
and UPF for URLLC services would have to be limited to
Regional Cloud Edge Cloud Cellular Site
the Edge Cloud site while for eMBB it is viable to place
Cellular at Regional Cloud site. Further, for services without specific
Regional Cloud Edge Cloud
Site latency targets, the corresponding O-CU-UP and UPF can be
situated even in the Core Cloud site [145]. It is observed that
Fig. 6. O-RAN NFs deployment scenarios onto the underlying O-Cloud sites centralizing O-DU proves most beneficial in densely populated
and ceullular network sites networks where multiple Cellular network sites fall within the
a) Scenario A: In this scenario, the Near-RT RIC, O- latency limits between O-RU and O-DU. On the other hand,
CU, and O-DU are deployed at the Edge Cloud as VNFs, sparsely populated areas are more likely to be handled by
whereas the O-RUs are deployed on cellular network sites. centralizing the O-CU alone.
This scenario is ideal for dense urban deployments with ample
FH capacity, enabling the pooling of BBU functionalities at a B. Network Slicing Deployment Options in O-RAN
central location. It reduces latency but comes with potentially The concept of network slicing revolves around establishing
higher deployment costs compared to other scenarios. a logical E2E virtual connections between end users or vertical
b) Scenario B: In this deployment scenario, the O-CU customers and their desired applications and services [65].
and O-DU are deployed at the edge cloud site in order to This is achieved by allocating sufficient network resources to
reduce latency, while the Near-RT RIC is deployed at the ensure that the services or applications can function properly
regional cloud site in order to gain a wider network perspective and meet the specified QoS and predefined SLA requirements
for performance optimization. [67]. Network slicing provides the benefits of flexibility and
c) Scenario C: In this deployment scenario, the O-CU scalability, enabling the creation of multiple secure logical
is co-located with the Near-RT RIC in the Regional O-Cloud networks that are isolated from each other but utilize the
site, and the O-DU is positioned at the Edge O-Cloud site. same physical network infrastructure [158], [159]. By utilizing
This scenario is tailored to support deployments in areas with the software and hardware disaggregation concepts with NFV
limited remote Open FH capacity, imposing restrictions on the technology, network slicing in O-RAN architecture enables
number of O-RUs. Two additional variations, C.1 and C.2, service providers to maximize the usage of network resources
have been introduced to address the specific requirements of and service flexibility [160].
certain network slice instances [145], [157]. The slicing architecture is structured into three distinct
d) Scenario D: This deployment scenario is akin to layers: the infrastructure layer (IL), network function layer
Scenario C (see above). However, the O-DU is deployed as (NFL), and service layer (SL) [64], [161]. The IL encompasses
PNF at the Edge O-Cloud site in this scenario. the entirety of the physical network infrastructure, comprising
e) Scenario E: This deployment scenario mirrors Sce- both RAN, CN, and transport network components. This layer
nario D, with the key distinction that all components, including is responsible for the deployment, control, and management
both O-DU and O-RU, are fully virtualized within the same of the infrastructure, as well as the allocation of computing,
Edge Cloud. This approach is being considered for future use, storage, network, and radio resources to network slices. Ad-
acknowledging that the virtualized versions of the low-PHY ditionally, it manages how these allocated resources are made
layer and other O-RU aspects are not currently available. available to higher layers. The NFL encompasses all activities
f) Scenario F: This deployment scenario involves the associated with configuring and managing the lifecycle of NFs
virtualization of both O-DU and O-RU, but they are hosted including both physical and virtual. These functions are placed
on separate O-Cloud sites. Like Scenario E, this scenario is on the virtual infrastructure and interconnected to deliver an
 23

E2E service that adheres to specific constraints and require- experience personalized QoS management and independent
ments defined in the service design of an network slice. The flow control through an individual SDAP/PDCP stack within
SL deals with the description of services and their mapping its dedicated O-CU-UP [52].
onto the underlying network components. It also encompasses Within the O-RAN slicing-aware architecture, the SMO
the architectural aspects of slicing managers and orchestrators. Framework accommodates a Slice MF block containing 3GPP-
This layer plays a critical role in defining how services defined NSMF, NSSMF, and NFMF. It also incorporates ad-
should be articulated and connected to the underlying network ditional MFs specified by the ETSI ISG NFV and/or the MFs
elements, facilitating efficient network slicing operations [10]. from the ONAP. In the following section, we will thoroughly
explore different deployment options for SMO Framework
E2 E2
within the context of network slicing management.
E1 F1-U
E2
O-CU-UP C. SMO Framework Deployment Options
O-FH As we discussed in Section III, the SMO Framework is
E1 F1-U responsible for the management and orchestration of O-RAN
O-CU-UP
components and resources [22]. We also discussed in Section
F1-C III that the SMO Framework can consist of management
E2 E2 components and systems of various SDOs. To this date,
various SMO Frameworks have been available in the market,
Regional Cellular
Cloud
Edge Cloud
Site
claiming that they are compliant with the latest specifications
of the O-RAN Alliance. However, their internal architectural
frameworks and operational mechanisms are not accessible
Fig. 7. O-RAN Reference Slicing Deployment Option
to the general public and hence they lack transparency and
Deciding how to allocate specific logical functions to partic-
openness in terms of their features and functioning [19].
ular O-Cloud platforms, and consequently determining which
The O-RAN Alliance proposed two open-source solutions,
functions should be co-located with other logical functions, is
the ONAP and the NFV-MANO, as comprehensive platforms
essential for the implementation of network slicing in O-RAN
intended to autonomously manage and orchestrate tasks as-
architecture [136]. The O-RAN components that can be shared
sociated with virtualized and software-driven elements and
with multiple slices are the Near-RT RIC, O-CU-CP, O-DU,
resources within the O-RAN architecture. The ONAP stands
and O-RU. The components which is meant to be dedicated
out as a prominent project that is in development and main-
for each network slice is the O-CU-UP. The method by which
tenance by the LF. Its association with the LF enables the
the NF are mapped to the same or distinct cloud platforms
ONAP to seamlessly integrate with significant projects like
must be taken into consideration in order to build agreements
Kubernetes, Akraino, Acumos, and OpenDaylight [152]. The
with requirements for each deployment scenario [31].
ONAP is already in use by the OSC as the preferred SMO
One of the many potential deployment methods proposed platform for open-source O-RAN code releases [162].
by the O-RAN Alliance for O-RAN slicing is represented in On the flip side, the open source MANO (OSM), based
Figure 7, where the O-RU is deployed at a cellular network on the NFV-MANO, is defined by the ETSI and follows the
site as a PNF. A Regional cloud site virtualizes the Near-RT ISG on NFV specifications. The OSM offers comparable SMO
RIC. The O-CU, and the O-DU are virtualized on a location- services in a more lightweight framework than the ONAP.
independent Edge cloud site. The O-CU and the O-DU are Additionally, it is notable that in May 2021, the ETSI initiated
connected to the Near-RT RIC with the E2 interface, and a cooperation agreement with the O-RAN Alliance, indicating
the O-CU and O-DU are connected through the F1 interface. the early stages of efforts to integrate the OSM framework
The Near-RT RIC, O-CU, and O-DU may be virtualized within the O-RAN architecture [163].
in several ways in the Regional and Edge cloud sites, as In the rest part of this subsection, we examine the deploy-
shown in Figure 6. For instance, an individual dedicated O- ment scenarios and their potential effects of NFV-MANO and
DU could be created for all network slices instead of sharing ONAP on network slicing architecture, as elaborated in [52].
a common O-DU for all network slices in the deployment 1) 3GPP and NFV-MANO-based SMO Deployment: The
scenario illustrated in Figure 7. deployment options of the SMO Framework, in harmonization
It is important to note that the application requirements for with both the 3GPP and NFV-MANO frameworks, emphasize
the PNFs, cloudified network services, or O-Cloud platform the fundamental principles and prerequisites of network slic-
might vary depending on the situation. However, the needs ing. This encompasses the virtualization and softwarization
for the logical network functions will always remain the same of RAN resources and components, alongside the seamless
[52], [145]. For Example, in this specific scenario, a single integration of AI/ML capabilities and programmability within
O-CU-CP instance governs the control of both network slices, the SMO Framework.
while each network slice has its distinct O-CU-UP instance. This deployment option combines the slice MFs and net-
If the UE is connected to both network slices, there will be work MFs defined by the 3GPP with those functional blocks
only one RRC connection responsible for handling handover defined by the ETSI ISG NFV. The NFV-MANO is re-
procedures and cell assignments through the shared O-CU- sponsible for managing and orchestrating VNFs, defining the
CP. However, each service belonging to a different NSI can processes such as the automation, management, and operation
 24

of virtualized functions running on top of a virtualization and an optional slice differentiator (SD) field, which differentiates
multi-tenancy-supporting infrastructure. Figure 8 illustrates among slices with the same SST field and consists of 24 bits.
the proposed deployment scenario incorporating 3GPP-defined According to [164], the list can include at most 8 S-NSSAIs,
slice MFs (such as the NSMF, NSSMF, and NFMF) alongside which means a single UE can be connected to at most eight
the NFVO and VNFM functional blocks defined within the RAN slice subnet instances at a given time.
NFV-MANO. These MFs and functional blocks of both the 2) 3GPP and ONAP-based SMO Deployment: In Sec-
3GPP and ETSI have been described in Section III. tion III, it is elaborated that the ONAP framework provides the
necessary management, orchestration, and automation capabil-
ities to an E2E network architecture. The OSC employs the
NSMF Service Management and Orchestration
SMO Framework based on ONAP in conjunction with other
OSC components [165]. Particularly noteworthy is the fact that
Os-Ma-Nfvo
RAN NSSMF NFVO Non-RT RIC, functioning at a parallel level with SMO, can uti-
Non-RT RIC
lize ONAP components for efficient A1 policy management in
Ve-Vnfm-Em
NFMF VNFM its implementations [83]. The ONAP encompasses workflows
and user interfaces tailored for the network slice orchestration
Open FH
O2 O1 A1 functions defined by the 3GPP notably CSMF and NSMF,
M-Plane
along with an additional interface to an external NSSMF for
Fig. 8. The 3GPP and NFV-MANO-based SMO deployment option with a the RAN, CN, and TN subnets. These slice MFs empower the
particular emphasis on O-RAN slicing ONAP framework to allocate an E2E NSI comprising suitable
Furthermore, the O-RAN study group proposed four differ- instances for RAN, CN, and TN NSSIs to meet the service-
ent possibilities in [31] for the deployment of the SMO Frame- specific requirements [87].
work with respect to network slice management topology and The ONAP-based architecture suggests two possible de-
their possible effects on O-RAN slicing-aware architecture. ployment options in the Kohn release, emphasizing enhanced
These four possible options for the deployment of the SMO integration with the O-RAN architecture, improvements in
Framework are explained in the following: cloud-native NF orchestration, and the advancement of intent-
driven closed-loop autonomous networks [86].
• Deployment Option 1: In this option, the network slice
In the first deployment option, the RAN NSSMF is placed
MFs (i.e., the NSMF and NSSMF) are deployed within
within the SMO Framework, which is responsible for the
the SMO Framework, as shown in Figure 8.
management and orchestration of the RAN network slice
• Deployment Option 2: In this option, both the NSMF and
subnet, including the O-RAN NFs and the related O-RAN
NSSMF are deployed outside the SMO Framework.
TN components. This includes the FH between O-RU and
• Deployment Option 3: This deployment option deploys
O-DU and the MH interface between O-DU and O-CU. The
the NSMF within the SMO Framework and the NSSMF
RAN NSSMF determines the slice-specific configuration of O-
outside the SMO Framework.
RAN NFs based on the slice profile received from the NSMF
• Deployment Option 4: This deployment option involves
and determines the necessary slice-specific requirements for
positioning the NSMF out of the SMO Framework, while
the FH and MH interface, triggering TN management domain
the NSSMF is implemented inside the SMO Framework.
(MD) to execute the actual configuration of the FH and MH
The above-mentioned deployment options solely vary in the interface. For TN management and orchestration, the ETSI
placement of the slice MFs as defined by the 3GPP. Within the zero touch network and service management (ZSM) based MD
scope of the O-RAN architecture, the RAN NSSMF, including approach is adopted [52], [87].
its interactions with the SMO Framework, is the primary focus In the second deployment option, the NSMF is responsible
of the O-RAN Alliance [31]. During the creation and provi- for the determination of a slice profile of the FH, MH,
sioning of RAN NSSI, the RAN NSSMF, in collaboration with and RAN NFs. The NSMF is also responsible for stitching
the SMO Framework, triggers the instantiation of essential O- together E2E network slice instances, including the FH and
RAN functions, such as the Near-RT RIC, O-CU-CP, O-CU- MH. Additionally, for both deployment options of RAN and
UP, and O-DU, according to slice requirements. Following TN subnets, separate RAN network slice subnet templates
the establishment of RAN NSSI, RAN NSSMF can execute (NSSTs) are designed [87].
procedures for NSSI modification and deletion in coordination Figure 9 illustrates an expanded iteration of ONAP, as we
with the SMO Framework [52]. showed in Figure 5 and discussed in Section III, incorporating
Each RAN NSSI is identified through the use of the network O-RAN network slicing functions. The 5G E2E network
slice selection assistance information (NSSAI). The NSSAI slicing scenario requires the integration of several modules
includes one or a list of single NSSAIs (S-NSSAIs) that within ONAP, including the SDC, SO, AAI, UUI, EXT-API,
provide a distinct identifier to each RAN slice [164]. A S- OOF, and Policy Framework. In the following, we provide
NSSAI is a combination of two values. The first value is detailed explanations for each of these modules.
a mandatory slice/service type (SST) field, which identifies The UUI offers a range of functionalities to users. In the
the slice type and consists of 8 bits within the range of 0- CSMF portal, users can create communication service forms
255. The SST may have a standard value such as eMBB, to establish network services that use a network slice, view
URLLC, or a network-specific value. The second value is these services in a list, and perform operations like activation,
 25

deactivation, or termination. Within the NSMF portal, network for the RAN, CN, and TN domains. The specialized workflows
operators can find and manage slicing-related tasks initiated by of the domain-specific NSSMF handle the essential tasks
customers, execute appropriate actions based on task status, involved in creating or updating the NSSI according to the
and verify or modify slice options suggested by the OOF. guidance provided by the OOF, particularly for NSSI creation
Additionally, the NSMF portal enables users to display and or reuse [87].
process existing network slices, NSIs, and NSSIs through its The AAI module introduces three additional nodes, namely
slicing resource management feature [166]. Communication-service-profile, Service-profile, and Slice-
Ext-API produces a Service Order ID and transmits it profile, along with modifications to the service-instance nodes.
within the response, which can subsequently be utilized to Three new nodes have been incorporated as attributes of the
monitor the order. Following this, Ext-API activates the API service-instance node. To align with SDC templates such
of SO to initiate the service creation process. This action as communication service template (CST), Service Profile
represents progress in establishing uniform external interfaces Template, Slice Profile Template, NST , and NSST, the run-
for network slice orchestration [87], [166]. time instances include communication service instance (CSI),
Service Profile Instance, Slice Profile Instance, NSI, and NSSI.
The Slice Profile Instance for the all three subnets: RAN, CN,
UUI CSMF Portal NSMF Portal SMO Framework
and TN are distinct [86], [87].
The AAI offers query APIs to CSMF and NSMF, enabling
EXT-API Service LCM APIs CDS
them to retrieve various information such as communication
SO OOF Policy
service instances, service profile instances, NSI, and NSSI.
CSMF, NSMF, Additionally, AAI provides creation APIs to SO, allowing the
CSMF NST, NSI, NSSI Selection
NSSMF Policies creation of communication service profiles, service profiles,
NSMF Slice Profile determination slice profiles, and establishing relationships between service
and decompositions SDC
instances [87].
NSSMF Adapter CST, NST, NSST,
AAI Service & Slice The CCSDK/ SDN-C configures the RAN NFs when in-
Profile Templates
NSSMF Service Instance, voked by RAN NSSMF for RAN NSSI creation or reuse
(RAN, TN, CN) Service Profile, Slice Profile,
NST, NSST, NSI, NSSI
more details are provided in ONAP architecture subsection
CSDK/SDN-C in Section III. The details of RAN configuration are obtained
DCAE Non-RT RIC from the Config DB/configuration persistence service (CPS).
RAN & Transport
DES, AI/ML & Analysis MS
Specific Configs The DCAE introduces two new micro-services [166]:
O-FH
a) Data exposure service (DES): This micro-service of-
O2 O1 A1
M-Plane fers a simplified interface for network operators, slice tenants,
or any other ONAP component to query both current and
Fig. 9. 3GPP and ONAP-based SMO Deployment Option with a particular
emphasis on O-RAN Slicing historical PM/KPI data.
Within the SO, distinct business process management no- b) Slice Analysis MS: This micro-service carries out
tation (BPMN) workflows are established for the CSMF and two distinct functions. Analyze PM received from the RAN
NSMF. The CSMF workflow manages service requests origi- through the PM-Mapper micro-service to detect any updates.
nating from the CSMF portal and stores order information in When it receives configuration updates, it initiates a Control
a communication service instance within the AAI. The CSMF Loop by transmitting a suitable data movement as a platform
workflow then interacts with the NSMF workflow to initiate (DMaaP) message to Policy Framework.
network slice requests. Subsequently, the NSMF generates
service profiles, NSI, and NSSI. Both the NSI and NSSI can V. S LICING THE U NDERLYING I NFRASTRUCTURE IN
be shared [87]. O-RAN A RCHITECTURE
The SO interacts with the OOF for the selection of network The evolving landscape of cellular network architectures,
slice template (NST) and NSI/NSSI. The OOF may recom- especially the transition from traditional D-RAN to C-RAN
mend either creating new instances or reusing the existing paradigms, signifies a fundamental shift in how underlying
ones. Regarding NSI/NSSI selection, the OOF could return wireless infrastructures are conceived and deployed within
an existing NSI if it is shareable and a suitable one exists, an the context of O-RAN architecture. The emergence of O-
existing NSSI if shareable and no NSI exists but a suitable RAN architectures marks a significant departure from the
NSSI does, or a slice profile if the service request is non- conventional RAN model, emphasizing a centralized approach
shareable or no suitable NSI or NSSI exists. The recalibration to key processing functions, notably the O-CU [167], which
of NSI and NSSI selection is managed by the orchestration currently resides within centralized DCs. The decision regard-
task, which allows network operators to intervene manually ing the placement of the O-DU, whether at the cellular site
through the NSMF portal in UUI [166]. or further within a centralized DC, highlights the intricate
An NSSMF adapter incorporated in SO interacts with inter- considerations driven by network operators’ preferences and
nal or external NSSMFs for NSSI orchestration. The NSSMF operational needs [22], [42], [168].
functionality includes a common part for subnet capability At the heart of this architecture’s efficiency lies the TN,
queries from SO, invoking domain-specific NSSMF functions responsible for ensuring seamless connectivity between the
 26

cellular network site hosting the O-RU and the DCs on O- ative of low-latency data processing. Strategically relocating
Cloud sites housing the VNFs (i.e., O-CU and O-DU) and processing functions to the edge cloud while retaining only the
service applications such as the RICs. Leveraging a diverse O-RU at the cellular site achieves a harmonious equilibrium
array of forwarding devices grounded in different technologies between minimizing latency and optimizing cost-effectiveness.
like the segment routing (SR) [169], dense WDM (DWDM), For services with less stringent time requirements, trans-
and microwave, the TN operates across various aggregation ferring the Near-RT RIC and O-CU to a regional cloud
levels [170]. This facilitates the establishment of data paths may result in increased latency, extending into the range of
encompassing different RAN and CN functions, thereby de- 50 milliseconds. However, this strategy optimizes resource
lineating distinct TN segments such as the FH, MH, and BH processing capabilities across a network’s various cellular
[51]. sites. By centralizing these functions, a single Near-RT RIC
In this dynamic environment, the concept of network slicing can efficiently manage resource allocation while ensuring that
emerges as a pivotal element within the underlying infrastruc- critical processing units remain in closer proximity to users,
ture of O-RAN. Integrated intricately into the disaggregated, enhancing overall network performance and responsiveness.
virtualized, and open architecture of O-RAN, network slic-
ing empowers operators to effectively manage resources and B. O-RAN Cloud Platform
optimize performance in response to evolving demands [171]. One of the major objectives of the O-RAN Alliance is to
Proficiency in network slicing within the O-RAN infrastructure enhance the flexibility and deployment speed of the RAN
not only ensures heightened operational efficiency and agility architecture while simultaneously lowering both capital and
but also unlocks unprecedented opportunities for innovation operating costs through the implementation of the underlying
and service differentiation [36]. This places the network op- cloud architectures. The logical architecture of the O-RAN
erators at the forefront of the ongoing network evolution, with the O-Cloud platform provides a fully open solution
spanning across 5G, 6G, and beyond, driving transformative where software is decoupled from hardware.
changes in the wireless telecommunications industry. Decoupling hardware and software within the O-RAN ar-
In the rest of this section, we delve into the underlying chitecture entails a three-tiered approach: a hardware layer,
infrastructure within the O-RAN architecture, including the an intermediary layer housing Cloud stack and acceleration
components of the O-RAN cellular network site, the O-Cloud abstraction functions, and a top layer dedicated to virtual
platform, and the Xhaul TN, examining the network slicing RAN functions. These layers are capable of being supplied
aspects of these critical elements. by different vendors, and this decoupling guarantees interoper-
ability between a cloud stack and numerous hardware suppliers
A. O-RAN Cellular Site while also accommodating virtualized RAN functions from
In wireless communications networks, a cellular network various software providers, thus defining it as an O-RAN
site serves as a stationary stronghold where the complex Cloud platform or O-Cloud [145].
interplay of radio signals takes place. It serves as a designated An O-Cloud platform, can automate and autonomously
locus for transmitting and receiving radio signals, ensuring manage tasks with a certain level of complexity such as
seamless coverage over a specified area. It encompasses two placing NF Deployment workloads on suitable O-Cloud nodes,
primary components: firstly, one or more antennas responsible executing self-repair, and auto-scaling based on deployment
for transmitting and receiving radio signals, and secondly, a artifacts, and policies, without SMO intervention. An O-
supply unit housing essential switching and control elements Cloud includes O-Cloud Resources, Resource Pools, and O-
critical for managing the operation of the antennas [172]. Cloud Services across multiple sites. It manages resource
In the usual course of design, cellular network sites are provisioning, Nodes, Clusters, and Deployments for both user-
structured to support numerous sectors, thus inherently associ- plan and management services, providing a unified reference
ated with multiple O-RUs. The O-RU serves as a fundamental point for all the elements within its boundary.
element in establishing seamless PHY layer connections with An O-Cloud Site refers to a collection of O-Cloud Re-
the UEs [22], [145]. Seamlessly, it brings together antenna sources at a specific geographical location, ranging from a
elements and important RF components like transceivers and single resource to thousands. These resources are intercon-
amplifiers. In addition, the O-RU also handles lower-level nected through O-Cloud Site Network Fabrics, which serve as
PHY tasks such as digital beamforming and fast fourier the demarcation for direct internal switching at the O-Cloud
transform (FFT) operations [61]. The Open FH interface plays Site level. Multiple O-Cloud Sites can be interconnected to
a crucial role in linking the O-RU with the O-DU to ensure form a distributed O-Cloud, that requires bridging, routing,
smooth communication within the O-RAN architecture. or stitching at the networking layer between each site and its
As detailed in Section IV, the process of optimizing the respective external transport network attachment point [145].
deployment of O-RAN entails navigating a delicate balance The O2 interfaces serve as the conduit for connecting to a
between FH latency and cost considerations. While consoli- range of O-Cloud services offered by the O-Cloud platform
dating all elements of the O-gNB at the cellular site minimizes in conjunction with the SMO Framework. These services are
latency, it also represents the most financially demanding categorized into two main groups, each tailored to address
option. Conversely, relocating control and connection anchors specific functionalities and requirements within the O-Cloud
towards a centralized edge cloud facilitates resource manage- ecosystem [128], [145]. Figure 10 depicts the primary com-
ment across multiple sites, all the while preserving the imper- ponents that constitute an O-Cloud site within the O-RAN
 27

similar capabilities and traits within an O-Cloud environment.

Service Management and Orchestration (SMO) Framework It comprises one or more such resources, each equipped
with network connections and, optionally, internal hardware
O2ims O2dms
accelerators and storage devices. Additionally, it may include
O-Cloud
standalone servers lacking an associated O-Cloud Site Net-
Infrastucture Management Services (Logical and Distributed) work Fabric, like infrastructure deployed at a cell site.
c) Unspecified O-Cloud Resource Pool: It refers to a
Diployment Managment Services (Logical and Distributed) collection of O-Cloud Resources listed in the O-Cloud IMS
inventory but not yet categorized or allocated to any specific
Diployment Plane (Logical) NF Deployment NF Part Deployment
O-Cloud Resource Pool.
d) O-Cloud Site Network Fabric: It serves as an inter-
Node Node Node Node Node Node
connecting resource within O-Cloud, linking various resources
Node Group Node Group within a site to enable seamless communication and data
Node Group Network Node Group Network exchange between them, enhancing overall functionality and
Node Cluster Network resource utilization.
Node Cluster
e) O-Cloud Site Network: It epitomizes a meticulously
provisioned Network Resource, showcasing its defined capa-
bilities and characteristics derived from an intricately config-
Compute HW-Acc Storage Compute
Compute Including
-Disks HW-Acc Storage Compute ured O-Cloud Site Network Fabric.
-PCI cards Compute
Resource Pool-2 Resource Pool-3 Resource Pool-3
2) Deployment Management Services: The deployment
Resource Pool-1
management service (DMS) efficiently handles various tasks
ComputeCompute
1 Site Network VRF
ComputeCompute
1
2
Site Network VRF
by leveraging information received over O2dms. These tasks
1 Site Network
Unspecified
VRF encompass the strategically placing O-RAN NF Deployment
Resource Pool Site Network Fabrik Gateway workloads within O-Cloud Node Clusters. Additionally, DMS
O-Cloud Site manages the entire lifecycle of these workloads, including re-
source allocation, configuration adjustments, and the executing
Fig. 10. Key components in an O-Cloud site with the O-RAN architecture essential lifecycle management operations like autonomous
scaling, self-healing, and workload relocation within the same
architecture. We now elaborate on each components in detail.
O-Cloud Node Cluster to meet service level expectation (SLE).
1) Infrastructure Management Services: Within the intri-
It also supervises the cessation of NF Deployments based
cate framework of O-Cloud operations, infrastructure man-
on directives from the SMO. Furthermore, the DMS ensures
agement service (IMS) form a pivotal subset of O2 functions,
the O-Cloud inventory is regularly updated with the latest
entrusted with the deployment and governance of cloud in-
status information on resources dedicated to NF Deployment
frastructure. The IMS assumes an important role, facilitating
workloads.
provisioning by meticulously allocating and configuring re-
Below are the conceptual insights related to O-Cloud DMS
sources for O-Cloud Node Clusters.
and its interaction with O-Cloud Resources generated or
It manages fault and performance aspects, identifying issues
modified via IMS provisioning as demonstrated in [145].
and providing measurements through the O2ims interface.
IMS exposes O-Cloud inventory that includes details on Sites, a) O-Cloud Deployment Plane: It refers to a conceptual
Deployment Management Services, Node Clusters, and Re- framework comprising O-Cloud Nodes, O-Cloud Networks,
sources, aiding SMO in understanding allocation fulfillment and O-Cloud Node Clusters, which are pivotal components
and available capacities. The O-Cloud life cycle management in constructing NF Deployments. This framework is estab-
involves registering, structuring, and configuring infrastructure lished by leveraging O-Cloud Resources provisioned via IMS,
services and resources. Additionally, it executes maintenance derived from O-Cloud Resource Pools and O-Cloud Site
operations, such as switching O-Cloud Nodes to maintenance Network Fabrics.
mode, autonomously or on demand, ensuring seamless com- b) O-Cloud NF Deployment: NF Deployment refers to
munication with SMO Framework. deploying software on O-Cloud resources to implement cloudi-
In the following, we delve into the concepts and perspectives fied NFs, either fully or partially, facilitating NFV within cloud
entwined with O-Cloud IMS and the Cloud Infrastructure as environments.
elucidated in [145]: c) O-Cloud Node: It is a network connected computer
a) O-Cloud Resource: This is a defined unit comprising or function, that can be provisioned into O-Cloud Node
capabilities such as compute, hardware acceleration, storage, Clusters by IMS. The nodes comprises physical and/or logical
and gateway within O-Cloud. These resources are provisioned components, and expose IMS-assigned resources to form O-
and utilized for the O-Cloud deployment plane, enabling Cloud Deployment Plane constructs. Additionally, an O-Cloud
efficient allocation and management of computing resources Node may operate independently as a standalone entity.
in cloud-based network infrastructure. d) O-Cloud Node Cluster: It consists of a set of O-Cloud
b) O-Cloud Resource Pool: The O-Cloud Resource Pool Nodes operating together via interconnected O-Cloud Node
consists of a grouping of O-Cloud Resources possessing Cluster Networks. The Operating System and Cluster software
 28

of these nodes identify their capabilities and characteristics and delay projections within the 5G network, as well as the
managed by IMS. logical transport connectivity needs across FH, MH, and BH
e) O-Cloud Node Cluster Network: It denotes a ded- components and even the N6 portions of 5G.
icated network infrastructure tailored for an O-Cloud Site In O-RAN Xhaul TN architecture, FH connects the O-DU
Network allocated to an O-Cloud Node Cluster. and O-RU with a latency models based on eCPRI reference
f) O-Cloud Node Group: It refers to a subset of O-Cloud points [37]. MH enables communication between O-DU and
Nodes in an O-Cloud Node Cluster treated equally, particularly O-CU with 3GPP defined F1/W1/E1 interfaces. While the BH
by the O-Cloud Node Cluster scheduler. These nodes are network connects the O-CU to core network [170].
interconnected through O-Cloud Node Cluster Networks and The deployment of an E2E Open Xhaul TN, which relies on
optionally through O-Cloud Node Group Networks. packet switched transport solutions, is influenced by various
g) O-Cloud Node Group Network: It refers to the O- factors. These factors encompass the extent of packet switch-
Cloud Site Network designated for a specific grouping of O- ing components, spanning from cell sites to the transport core,
Cloud Nodes within an O-Cloud Node Cluster. as well as the potential integration with other technologies
in the FH to establish an E2E network [175]. Considerations
C. Xhaul Transport Network also extend to the nature of the underlying Layer 0/Layer 1
The Xhaul TN in O-RAN encompasses diverse TN seg- transport, the network protocols implemented at the packet
ments across the RAN and CN functions such as FH, MH, and switching layer, and the framework for constructing overlay
BH. The Xhaul acts as the unified TN facilitating connectivity services on the Xhaul transport infrastructure.
within and between the RAN and CN components. The Illustrated in Figure 11 is a unified E2E packet switched
TN, particularly the access TN like FH and MH, possesses infrastructure, structured upon a dual split TN architecture that
the capability to concurrently handle diverse transport flows, spans from cellular sites positioned at the edge of the access
particularly evident when operators integrate mixed-use cases layer to the core of the transport layer. The packet switching
into their RAN deployments. transport network equipments (TNEs) exhibit QoS capabilities,
Efficiently managing network resources becomes paramount boasting high capacity and low latency, interconnected via
due to the varied nature of these transport flows, each present- point-to-point Ethernet interfaces. Additionally, it integrates
ing distinct requirements in terms of latency, throughput, and strategically distributed DCs throughout the transport network
transmission reliability [21]. This is essential to mitigate com- infrastructure to facilitate both virtual and physical NFs es-
plexity and uphold optimal performance across the network. sential for mobile and fixed services. Furthermore, it offers
An astute strategy entails categorizing these transport flows the potential for hosting Application Functions geared towards
into transport slices according to shared service prerequisites, providing value-added services and custom applications tai-
thereby enabling more methodical and efficient management lored to individual customers.
of the transport network. Subsequently, these slices may be The diagram presents a conceptual depiction of the network,
subdivided into additional sub-slices as needed, tailored to acknowledging that the actual physical implementation may
accommodate a diverse array of E2E user applications or vary. For instance, an O-DU could be linked to a single TNE
specific operator demands pertaining to priority, latency, or port yet facilitate two logical connections to a second TNE
bandwidth allocations [170]. in the FH network and a third TNE in the MH network.
Embarking on the journey of seamless integration, the In contrast, some operators might opt to utilize packet-based
discussions within the 5G domain, especially in O-RAN, technology solely in the MH and BH, while employing
focus on incorporating network slicing into existing transport straightforward physical networking to connect O-DU ports
infrastructures [173]. Key questions arise regarding which with O-RUs. In such scenarios, the physical network between
mobile interfacesFH, MH, BH, and N6require slicing, the O-RU and O-DUs might consist of simple dark fiber links,
forms these slices will take, and the optimal number of slices or alternatively, operators may choose to implement a passive
needed at the transport level. wavelength division multiplexing (WDM) system for added
In the subsequent sections, we will delve deeper into the simplicity [170], [176], [177].
architecture of the TN, exploring the complexities of TN Within the O-RAN framework, the FH network plays a
slicing. This exploration aims to provide insights into the pivotal role in facilitating the remote transmission of signals
fundamental principles and practical considerations essential from O-RU to O-DU. The O-RAN architecture brings forth
for the effective deployment and operation of Xhaul TNs in novel requirements for FH networks, including considerations
O-RAN environments. such as FH latency and data rate. WDM has emerged as
1) Xhaul Transport Network Architecture: The Xhaul TN a solution for addressing these challenges, offering various
must exhibit a high degree of adaptability, as it needs to architectural approaches such as passive WDM, active WDM,
cater to different requirements based on the specific use case and semi-active WDM. For more details on WDM, please refer
and RAN design. This could involve accommodating multiple to [176]
network slices [28], numerous 5G services, and diverse 3GPP It is imperative to differentiate between the underlay/fabric
interfaces [170] across various segments of the physical trans- of the transport infrastructure and the services that rely on
port network. O-RAN Alliance in WG9 transport requirements it. The primary objective of the underlay is to establish a
document [174] has meticulously outlined a multitude of scalable environment capable of meeting the diverse service
prerequisites for the O-RAN TN, encompassing bandwidth requirements of a 5G infrastructure. In contrast, the services
 29

Transport SDN / Orchestration and Telemetry

Mobile Services: MP-BGP EVPN and L3VPN

Underlay Transport Fabric: MPLS / SRv6, QoS, Timing

Hub RRs Edge RRs Regional RRs National RRs

CSR
Access Pre-Aggregation Aggregation 5G and/or
(Fronthaul) (Midhaul) (Backhaul) Transport Core

Hub Site Edge DC Regional DC Central DC

O-RU
O-DU O-CU UPF UPF SMO

Dark Fibre / WDM Dark Fibre / Switched WDM

Cellular
IMS DMS O-Cloud
Site

Fig. 11. Packet switched TN for Mobile Xhaul in O-RAN architecture

infrastructure, or overlay, operates above the underlay of the routing, traffic engineering, packet-based QoS, and precise
transport network, facilitating various components of the 5G timing mechanisms [170].
infrastructure such as FH, MH, and BH [46], [170]. b) Xhaul TN Overlay/Services Infrastructure: Overlay
a) Xhaul TN Underlay/Fabric Technologies: The un- networks utilize network virtualization principles to create
derlay networks encompass the physical infrastructure of a virtualized networks, consisting of overlay nodes like routers.
network, comprising DWDM equipment, ethernet switches, These networks leverage technologies such as ethernet VPN
routers, and the fiber optic cabling that interconnects these (EVPN) and multi-protocol border gateway protocol (MP-
components into a network topology. To support an Xhaul BGP) based layer 3 VPNs (L3VPNs) for tunneling encap-
transport environment, the packet switched network must sulation within the overlay service layer. This encapsulation,
handle both layer 2 (L2) and layer 3 (L3) services. Presently, facilitates the transmission of data packets over the underlying
L2 underlay networks predominantly rely on Ethernet, often physical network while maintaining logical separation and
utilizing virtual LANs (VLANs) for segmentation. Within isolation between different virtual networks or segments [170].
O-RAN, following two prevalent packet switched underlay Both MPLS and SRv6 packet switched underlays utilize
technologies are explained in [170]. EVPN for L2 support and MP-BGP for L3VPNs. In the MP-
BGP architecture, the protocol is configured with suitable
• Multi-protocol label switching (MPLS): MPLS em-
address-family support for both EVPN and L3VPN, facilitat-
ploys label switching in the data plane with multiple
ing the transmission of service connectivity information among
control plane technologies including SR an extension
provider edge (PE) equipment [178].
to interior gateway protocol (IGP) and border gateway
Ethernet services will be provided by EVPN, where EVPN
protocol (BGP). Regardless of the MPLS control plane
virtual private wire service (VPWS) acts as a transport service
used, the service layer is independent and supports native
for Open FH and radio over ethernet (RoE), ensuring redun-
Ethernet and L3 services [178].
dancy for Open FH interfaces. BGP L3VPNs support internet
• SR over IPv6 (SRv6): SRv6 is based on the SR archi-
protocol (IP)v4 and IPv6, presenting flexible connectivity
tecture and utilizes an IP version 6 (IPv6) data plane,
models with default shortest path routing, along with the
where segments are identified by segment IDs (SIDs)
option for automatic steering into SR policy [169].
embedded in the IPv6 header [179]. While sharing some Mobile IP services are set to be facilitated by MP-BGP
similarities with SR-MPLS, there are key differences in based L3VPNs. These L3VPN services serves in establishing
requirements, especially concerning the critical aspect of L3 connectivity among various mobile components. With the
scaling the underlay infrastructure in the context of a 5G BGP L3VPN support, operators gain access to both IPv4 and
environment. IPv6 virtual private networks (VPNs), thereby enabling the
The underlay is anticipated to offer a comprehensive set of adoption of flexible connectivity models to address a wide
tools necessary to deliver essential network services, encom- array of network requirements.
passing functionalities such as universal connectivity, prioriti- 2) Xhaul Transport Network Slicing: In packet switched
zation, isolation, scalability, rapid convergence, shortest path networks, there exists a robust framework poised to support
 30

the intricacies of network slicing. Within the Xhaul transport customized to suit the distinct forwarding behaviors asso-
infrastructure lies the inherent capacity to cater to the diverse ciated with different services. These specialized transport
transport demands of various interfaces. This extends not only planes are open for use by multiple customers who
to O-RAN but also encompasses interfaces defined by 3GPP, implement VPNs and traffic steering techniques.
necessitating bespoke solutions for the control, management, Depending on various criteria, such as service require-
and user plane interfaces. This entails the implementation of ments and network conditions, these transport planes can
5G transport segmentation from a mobile standpoint, wherein adopt unique topologies and optimizations. For instance,
slicing at the FH, MH, and BH interfaces becomes indis- for URLLC service types, the focus may be on relia-
pensable [62], [180]. Slicing allows for the customization of bility, utilizing the most dependable links and selecting
resources to precisely match the specific latency, bandwidth, optimal paths based on link delay metrics. In contrast,
and traffic characteristics associated with each interface [181]. eMBB service types may prioritize cost-effective, high-
In the domain of TN, the concepts of hard slicing and bandwidth links, determined by paths calculated with IGP
soft slicing delineate the degree of isolation between network metrics correlated with link capacity. For narrowband IoT
slices [182]. Hard slicing entails the allocation of resources (NB-IoT) service types, which do not necessitate low
exclusively to a particular NSI, ensuring stringent assignment latency or high capacity, a separate transport plane could
and limited resource sharing. Conversely, soft slicing preserves be designated, with paths established based on traffic
the attributes of a transport slice but permits shared and engineering (TE) metrics, favoring links suitable for these
reusable resources across different NSIs [62], [183]. This ap- specific services.
proach offers heightened flexibility and efficiency in resource • Transport plane per slice customer: In this alternative
utilization. Essentially, while hard slicing prioritizes exclusive approach, rather than allocating a transport plane for each
dedication to individual slices, soft slicing fosters shared and 5G service type, a separate transport plane is assigned
reusable resources, thereby enhancing overall flexibility in to individual customers. While similar techniques are
resource management. employed, scalability is now contingent on the number of
The functional architecture displayed in Figure 12 illustrates customers utilizing the network, as opposed to the diver-
Xhaul TN slicing, incorporating orchestration infrastructure sity of 5G service types. To tackle scaling challenges, a
and encompassing the RAN, CN, and Xhaul TN. It seamlessly combination of mapping per customer and per 5G service
integrates NSSIs overlay and TN underlays, thus showcasing type can be implemented. As an illustration, the primary
the system’s comprehensive design. approach might entail mapping according to 5G service
Ensuring the flexibility of mapping NSIs to physical or log- types, where only a selected group of premium customers
ical transport network instances is paramount. This guarantees receive dedicated mappings to individual transport planes.
seamless alignment between the transport network and the • Transport plane per 5QI group: In this setup, the TN
unique requirements of each network slice, thus creating a allows for the integration of traffic streams characterized
dynamic and responsive infrastructure. The process of map- by different 5G QoS identifier (5QI) values into specific
ping NSIs to logical networks within an Xhaul TN heavily slices. This configuration enables the straightforward al-
depends on the available deployment options [184]. Below, location of a significant number of 5QIs to a limited
we elucidate some of these concepts as outlined in O-RAN pool of transport resources, such as queues located within
WG9 documents. TNEs. As a result, the network can efficiently manage
a) Transport Plane: Within the O-RAN transport infras- and prioritize various types of traffic within these defined
tructure, both L2 EVPN and L3VPNs leverage MP-BGP to slices.
establish individual NSIs. These VPNs provide exceptional
scalability, supporting numerous instances and endpoints while E2E Service Orchestrator
offering diverse connectivity models. Additionally, four ap-
CSMF NSMF
proaches are detailed for constructing the underlay transport
plane/planes, each tailored to enhance network performance
and meet specific requirements [170].
• Single transport plane for all slices: In this configu-
RAN NSSMF TN NSSMF CN NSSMF
ration, a single transport plane serves as the backbone
for all network slices, facilitating a uniform distribution
of traffic paths among them. Consequently, each slice TN NSSIs TN NSSIs
Overlay Overlay
traverses identical routes between network endpoints, TN NSSI Underlay
fostering cohesion and consistency across the network
TN NSSI Underlay
infrastructure. This strategy is often considered the softest
NSSIs DCGW TNE TNE TNE DCGW NSSIs
form of slicing within the underlay transport plane, as it
prioritizes shared resources and harmonious coexistence
among slices.
Fig. 12. Functional Architecture of TN Slicing
• Transport plane per 5G service type: Tailoring the
underlay network to accommodate each 5G service type b) Quality of Service: In TN, QoS plays a critical role
involves constructing dedicated transport planes, each in ensuring that different types of traffic receive appropriate
 31

levels of service, such as bandwidth, latency, and packet promised.

loss, to meet specific performance requirements. When it • DC management network: Distributed across the trans-
comes to slicing a transport infrastructure to accommodate port network, DC necessitate centralized management to
different types of traffic or services, the significance of QoS effectively support a plethora of Network Functions and
becomes even more pivotal. Just as in the transport plane, Application Functions. Some of these functions are intri-
different strategies can be used to provide varying levels of cately tied to the provision of 5G and O-RAN capabilities
isolation between slices. These strategies may include traffic and services.
prioritization, bandwidth allocation, traffic shaping, and con- The management network of these DCs aligns with the
gestion management techniques [184]. When contemplating O2 interface as defined by O-RAN, catering to a variety
QoS within the context of TN slicing, it’s crucial to consider of DC management, monitoring, and orchestration needs.
both edge QoS solutions and core QoS solutions. Each DC seamlessly hands off its management network
• Edge QoS: Edge interfaces within packet transport net- to a TNE via a logical Ethernet interface, which is
works often experience delays and frequent congestion. seamlessly integrated into an MP-BGP L3VPN on the
In the context of network slicing, it’s essential to enable TNE. This VPN serves as the conduit connecting all DCs
traffic conditioning at the network’s edge upon entry to the central MFs.
and scheduling upon exit to ensure each slice maintains • O-RAN FH Management network: The FH M-Plane
its allocated bandwidth. Moreover, when mobile clients interface serves as a specialized VPN spanning the TN,
present traffic through VLANs, the PE router needs separate from the O-RAN Management and Control VPN
hierarchical QoS capabilities to effectively manage both that supports interfaces like O-RAN A1, E2, and O1.
the overall allocated bandwidth at the VLAN level and Mobile elements accessing the M-Plane are directed to
the designated class bandwidth within each VLAN. link with the FH Management VPN via a logical Ethernet
• Core QoS: In the core network, various QoS strategies interface.
manage bandwidth allocation and queue sharing among • O-RAN Control and Management network: The A1,
different network slices, ensuring optimal performance E2, and O1 interfaces are seamlessly integrated into a
and resource utilization. singular VPN infrastructure spanning the entire transport
network. Leveraging MP-BGP L3VPN technology, the
c) Service Models: In addition to the physical compo- O-RAN Control and Management network operates in
nents of the infrastructure, there is a necessity for establish- alignment with the default routing algorithm of the un-
ing separate networks dedicated to managing and controlling derlying infrastructure. This network is imperative across
various aspects of the 3GPP and O-RAN frameworks. These all TNEs, established through VLAN attachment circuits
networks, known as management and control plane networks, (ACs), to provide support for O-RAN components utiliz-
play crucial roles in managing and regulating the functionality ing the A1, E2, or O1 interfaces.
and performance of the networks [170]. Within the architecture • 3GPP Control Plane network: A consolidated 3GPP
designed for transport network slices, certain management core infrastructure functions within a specialized 3GPP
networks operate as independent VPN entities. On the other control plane VPN across the TN. This VPN efficiently
hand, there are instances where multiple MFs are integrated handles all 3GPP control plane traffic concerning MH
within a single VPN entity. This consolidation allows for more and BH operations, incorporating protocols like F1-C, E1,
efficient management and control by centralizing various tasks Xn-C, N1, N2, and N4 across various slices. Accessible
and functionalities within a unified network structure. on all TNEs through VLAN ACs, the 3GPP control
• TN management network: Each TNE is equipped with plane VPN guarantees seamless connectivity for mobile
a local network management interface, complete with its components reliant on the 3GPP control plane.
unique IP address, facilitating day-to-day administrative • O-RAN and 3GPP User Plane networks: In the latest
tasks. This interface serves as the originating point for O-RAN slicing scenarios, the transport architecture has
management protocols, seamlessly integrated into a trans- been refined to accommodate slicing in MH, distributed
port management network utilizing an MP-BGP L3VPN, UPFs, and the relocation of the N6 network nearer to
meticulously aligned with the default routing algorithm. radio cellular sites. Each slice is now linked with a
The architecture of the TN management network is dedicated L3VPN, effectively managing both MH and
typically configured in an any-to-any topology, enabling BH user plane traffic. Moreover, the extension of the
seamless connectivity between all entities within L3VPN N6 network deeper into the transport infrastructure is
[185]. However, a more prevalent configuration involves essential to empower distributed and centralized UPFs,
a hierarchical structure where central network MFs main- allowing access to shared applications and the utilization
tain bidirectional communication with TNEs, while TNEs of local breakout functionalities.
themselves are isolated from direct communication with • FH C/U Plane network: The FH components of O-
each other. RAN do not yet support slicing, resulting in O-RUs
Furthermore, Service Providers have the option to estab- and O-DUs being utilized universally across all slices.
lish an out-of-band network in addition to the primary A dedicated 7.2x eCPRI stream connects the O-RU and
in-band management network, providing redundancy in O-DU, overseeing all control and user plane traffic for
situations where in-band network connectivity is com- each slice. The 7.2x C/U interface must be compatible
 32

with Ethernet encapsulation and may optionally support use cases will be integrated into O-RAN as network slicing
Ethernet/IP encapsulation. requirements. Prioritizing and specifying support for these use
• MH U-Plane network (F1-U, Xn-U): To segregate F1-U cases by the O-RAN community are essential, as not all of
traffic, individual VLANs are assigned to each user plane them have been realized in the O-RAN specifications yet.
slice on both O-DUs and O-CU-UPs. QoS is maintained TABLE III
by these components, as they allocate a differentiated ACTORS AND THEIR ROLES IN DIFFERENT STAGES OF O-RAN S LICE
services code point (DSCP) value customized to the im- S UBNET M ANAGEMENT AND P ROVISIONING USE CASES

Feasibility Check
portance of the user payload within the GPRS tunneling
protocol user plane (GTP-U) packet.

Configuration
Modification

Deactivation

Termination
The user plane traffic for MH and BH, linked to a slice,

Activation
utilizes a unified MP-BGP L3VPN, offering seamless

Actors
any-to-any connectivity. Should an operator prefer to
segregate MH and BH traffic, they have the option to
employ distinct MP-BGP L3VPNs for each slice, ensur-
ing separate routing for both types of traffic NSMF Yes Yes Yes Yes Yes Yes
• BH U-Plane networks (N3 and N9): User plane slicing
in the BH network assumes that traffic associated with NSSMF Yes Yes Yes Yes Yes Yes
distinct slices originates from separate logical Ethernet SMO OAM Yes Yes Yes No Yes Yes
interfaces on the BH interfaces of O-CU-UPs and UPFs.
NFMF Yes Yes Yes No Yes Yes
To maintain these slice mappings throughout the TN,
VLAN ACs are allocated to different L3VPNs on the Near-RT RIC Yes Yes Yes Yes Yes Yes
TNEs or DC-TNEs. Within the TN, MP-BGP L3VPNs O-CU-CP Yes Yes Yes Yes Yes Yes
can be established per slice or shared among slices,
depending on how the mobile component presents the O-CU-UP Yes Yes Yes Yes Yes Yes
slice traffic to the TN. These L3VPNs are aligned with the O-DU Yes Yes Yes Yes Yes Yes
underlay’s default routing algorithm or flex-algo, and TE
can be employed to map L3VPNs to different underlay O-RU Yes Yes Yes Yes Yes Yes
transport planes. O-Cloud M&O No Yes No Yes No Yes
• Data Network: The N6 data network, although beyond
Non-RT RIC No Yes No Yes No Yes
the context of RAN, requires consideration for TN slic-
ing, especially as it expands closer to the radio infrastruc-
ture with multiple breakout points. The methodologies A. Slice Subnet Management and Provisioning Use Cases
discussed for BH and MH user plane slicing are largely The aspects related to the management and orchestration of
applicable when establishing data networks over a shared network slicing, including NSI and NSSI, are provided by the
packet switched transport infrastructure. When incor- 3GPP. The NSI refers to an instance of an E2E network slice,
porating multiple breakout points in the data network, while the NSSI represents a part of an NSI, such as NSSI for
meticulous planning is essential to ensure the traffic exits the RAN domain or NSSI for the CN domain. For a compre-
and re-enters the network at designated locations. This hensive detailed discussion on the lifecycle management and
entails strategic management of UPF addresses within the provisioning of both the NSI and NSSI, interested readers may
data network, as well as determining how these routes refer to [186]. In the use cases discussed in this subsection, we
are externally propagated by routers at peering points, outline the most essential procedures for O-RAN Slice Subnet
and how external routes are disseminated within the data Management Provisioning, ensuring alignment with the 3GPP
network. Slice Management framework and requirements [187]. The use
cases further outline the steps involved in the different stages
VI. E XPLORING U SE C ASES R ELATED TO N ETWORK of the use case. These steps encompass Creation, Activation,
S LICING IN O-RAN A RCHITECTURE Modification, Deactivation, Termination, Configuration, and
The exploration of network slicing within O-RAN encom- Feasibility Check for O-RAN architecture. The use cases
passes deploying network slices for various use cases while encompass a diverse array of actors, including O-RAN NFs
also highlighting the diverse requirements of business cus- and MFs designated as NFMS provider (NFMS P), NSSMS
tomers seeking to realize their specific needs. These require- provider (NSSMS P), NSSMS cunsumer (NSSMS C) at each
ments may encompass ultra-reliable services, high-bandwidth stage with their respective roles [52]. Table III presents a
communication, and low latency, among many others. The O- comprehensive list of actors alongside the specific use cases
RAN Alliance has identified specific use cases for network requiring their involvement.
slicing to showcase its potential in meeting the demands of a) Creation: The objective of this phase is to establish
business customers. In this section, we delve into several use the O-RAN NSSI (O-NSSI) or initialize the existing one to
cases outlined in O-RAN Alliance specifications, expected meet the RAN slice subnet requirements. This phase begins
to be supported within the O-RAN slicing-aware architecture when the request for an NSSI is received by the NSSMS P.
discussed in Section III. The requirements derived from these It assesses the feasibility of the request by considering the
 33

received requirements for the network slice subnet. NSSMS P ments and O-NSSI details by the NSSMS P. Subsequently,
decides whether an existing O-NSSI can be used, which may akin to instances where initial requirements cannot be fulfilled,
trigger the modification phase, or a new slice subnet will be it notifies the NSSMS C regarding the process status, along
created. The VNFs within O-RAN will then be instantiated with pertinent O-NSSI information. This phase culminates
by a service request from NSSMS P to O-Cloud management with adjustments made to the O-RAN O-NSSI and associated
& orchestration (M&O). The response will then be forwarded O-RAN NFs, alongside the configuration of the Non-RT RIC
to O-NSSI, which configures its constituents of O-NSSI using with the updated slice requirements and O-NSSI specifics.
O-RAN NF provisioning service. After that, the NSSMS P TABLE IV
activates TN Manager to establish necessary links such as T HE O-RAN NF S , ALONG WITH THEIR CURRENT STATE , ARE REQUIRED
A1, E2, as well as FH and MH connectivity. The network TO SATISFY THE PREREQUISITES FOR ACTIVATION

slice subnet requirements are forwarded to the Non-RT RIC, NF Installed Activated
and NSSMS C will be informed about the resulting status
of this process. This phase reaches its conclusion upon the Near-RT RIC Yes Yes
establishment of the necessary O-RAN NFs and O-NSSI, O-CU-CP Yes No
alongside the configuration of the Non-RT RIC [52].
b) Activation: The goal of this phase is to activate the O-CU-UP Yes No
O-NSSI. This use-case has the pre-condition that an O-NSSI O-DU Yes No
has already been created but is an inactive status. This means
that several O-RAN NFs may be contained in the O-NSSI O-RU Yes (as PNF) No
but not yet have been activated. To begin the procedure, d) Deactivation: This scenario involves deactivating a
NSSMS C sends a request to NSSMS P to activate the O- currently active O-NSSI. When NSSMS C decides to de-
NSSI. The NSSMS P then identifies and decides to activate activate the O-NSSI, it sends a deactivation request to the
the parts that are inactive. For example, consider the elements NSSMS P, initiating the process. Subsequently, the NSSMS P
listed in Table IV, where all the NFs are inactive since they identifies the active components of the NSSI and proceeds to
are not shared with other O-NSSI, but Near-RT RIC is only deactivate those components that are not shared. Below are
activated for other services. NFMS P makes sure that all the examples of active, non-shared O-RAN NFs:
constituents of NSSI are installed and activated on request
of NSSMS P. When all are activated, NSSMS P receives a • The O-CU-CP NF constituent: To terminate the connec-
notification from NFMS P and notifies NSSMS C about the tion with the Near-RT RIC, the E2 interface connection
activation of the O-NSSI. It also changes the administrative will be deactivated. The E1 interface connection between
state of the O-NSSI to unlocked. This process ends after the the O-CU-CP and the O-CU-UP will be released.
activation of O-NSSI or if one of the steps fails [52], [186]. • The O-CU-UP NF constituent: The E2 interface connec-
c) Modification: The objective of this use case is to tion with the Near-RT RIC is scheduled for termination.
ensure compliance with O-RAN slice subnet requirements by • The O-DU NF constituent: The process of terminating the
refining the existing O-NSSI. The only prerequisite of this F1 interface connection with O-CU and the E2 interface
phase is that the VNF packages for virtualized O-RAN NFs, connection with Near-RT RIC has commenced.
slated for incorporation into the O-NSSI, have been previously • The O-RU constituent: The M-Plane interface connection
incorporated [52]. The process initiates upon receiving a with O-DU is initialized for the termination.
request to modify an existing O-NSSI along with new require- Once the NSSMS P identifies the mentioned components,
ments by the NSSMS P. Subsequently, feasibility is assessed, it requests the NFMS P to deactivate them. The NFMS P
leading to two potential outcomes. Should the requirements proceeds to set the administrativeState of each item to locked,
prove unattainable, the NSSMS P informs the NSSMS C of thereby deactivating them accordingly. Upon deactivation of
the status along with O-NSSI details. Conversely, the provided all active, non-shared NSSI constituents, the NSSMS P is
information is segmented into modification requests for each notified. To conclude the process, the NSSMS P sets the
constituent of the O-NSSI. If there are additional O-NSSIs administrativeState of the O-NSSI to locked. The process
managed by other NSSMS Ps, their respective NSSMS Ps concludes with the deactivation of the O-NSSI.
are notified of the modification via the primary NSSMS P, e) Termination: This use case involves ending or dis-
thereby activating their O-NSSIs. Additionally, the NSSMS P sociating an existing but inactive O-NSSI when it is no
can sequentially initiate various required aspects as below: longer required. Upon receiving the termination request, the
• A service modification request to O-Cloud M&O, if the NSSMS P has two options: Firstly, if the O-NSSI is shared,
O-NSSI contains virtualized parts. it will be dissociated via the modification use-case described
• NF provisioning service to reconfigure the O-NSSI con- earlier. Secondly, if the O-NSSI is non-shared, it will be
stituents, if the O-NSSI contains NF instances. terminated. If there are constituent NSSIs within the O-NSSI
• O-RAN TN Manager coordination, if the NSSI contains that are not directly managed by the NSSMS P, it sends a
TN part to establish or modify necessary links and request to other respective NSSMS Ps, indicating that they are
interfaces, such as A1, E2, FH, and MH. no longer needed. The NSSMS P also requests termination
Upon completion of the aforementioned steps, the Non-RT from the O-Cloud M&O for the non-shared virtual O-RAN
RIC is informed of the revised network slice subnet require- NFs that are no longer required. Additionally, it initiates the
 34

coordination procedure with the TN manager and informs the customer, defining responsibilities and performance standards
Non-RT RIC about the termination of the O-NSSI. Finally, and setting clear service expectations [188].
the NSSMS P notifies the NSSMS C of the resulting status, Leveraging the open interfaces of O-RAN and cutting-
successfully concluding the termination process. edge AI/ML-assisted architecture offers promising avenues for
f) Configuration: This use case involves configuring or implementing these mechanisms, paving the way for network
re-configuring an existing O-NSSI. The configuration of the operators to capitalize on the myriad opportunities presented
O-NSSI and its constituents is initiated by the NSSMS C by by network slicing [187]. This groundbreaking innovation has
triggering the configuration process. Subsequently, the slice the potential to fundamentally reshape how network operators
subnet configuration/re-configuration information is sent to the conduct their business operations and introduce revolutionary
NSSMS P, which breaks down the reconfiguration data. Each new business models [160]. For instance, the O-RAN archi-
constituent undergoes configuration management preparation, tecture and interfaces empower network operators to optimize
and if managed by the NSSMS P directly, it is config- spectrum resource utilization by dynamically allocating spec-
ured accordingly. If the constituents are managed by other trum resources across slices in response to evolving usage
NSSMS Ps, they get activated. Configuration requests are also patterns, thereby maximizing spectrum resource efficiency.
sent through the NFMS Ps for O-NSSI with constituent O- The various stages of the use case are delineated as follows:
RAN NFs. The NSSMS P then sends the outcome, which is a) Creation and Deployment of RAN slice SLA Assurance
based on the results received from configuration management, Models and Control Apps: In this phase, the training and
to the NSSMS C, which may receive additional results from deployment of the model begin with the activation of an O-
other configuration management service providers. RAN slice. A prerequisite is that the connection between the
g) Feasibility Check: This use case assesses the pos- Near-RT RIC and the Non-RT RIC must be established via
sibility of provisioning an O-NSSI and confirms whether the A1 interface, while the O1 interface is configured between
its requirements are attainable. The precondition is that the the SMO and the Near-RT RIC. This phase involves multiple
NSSMS C has acquired or received the necessary require- steps executed by the Non-RT RIC. Initially, it retrieves a RAN
ments for the network slice subnet. To commence the process, slice SLA from the SMO Framework, specifically the NSSMF,
if an O-NSSI meets the network slice subnet requirements, a and then proceeds to collect performance measurements and
request must be sent to the NSSMS P from the NSSMS C. enrichment information from external applications via the
The NSSMS P then identifies the involved constituents and O1 interface. Following this, the Non-RT RIC performs a
can seek information from the SMO and the Non-RT RIC thorough analysis of the accumulated PMs and/or enrichment
regarding the fulfillment of requirements. Subsequently, it information through extended periods of monitoring, which
checks the availability of network constituents by submitting significantly contributes to the model training process [160].
reservation requests to the O-Cloud M&O. The NSSMS P The Non-RT RIC takes charge of model training and
may also request the TN Manager gather information regard- procures RAN slice SLA assurance models. There exist two
ing the feasibility of the TN links. The results, including options for model training: either utilizing an AI/ML model or
information about reserved resources, are then provided to the employing a control app. Should an AI/ML model be selected,
NSSMS C and hence conclude the process. it can be deployed internally for slow loop optimization or
conveyed to the Near-RT RIC via the O2 interface for fast
loop optimization. Conversely, if a control app is opted for,
B. RAN Slice SLA Assurance it can be deployed by the SMO to the Non-RT RIC for slow
The 3GPP standards have laid the groundwork for a highly loop optimization or transferred to the Near-RT RIC for fast
adaptable 5G infrastructure, facilitating the establishment and loop optimization. Finally, the updates to the model or control
management of bespoke networks tailored to meet specific apps are implemented upon the Non-RT RIC receiving updates
service demands across a wide spectrum of applications, internally or from the Near-RT RIC via the A1 interface. This
services, and business verticals. These requirements, metic- process culminates upon the deactivation of the RAN slice.
ulously outlined through standardization endeavors, encom- b) Slow Loop RAN Slice SLA optimization: The grand
pass critical performance metrics such as throughput, energy objective of this phase is to achieve slow loop RAN slice SLA
efficiency, latency, and reliability [118]. Network slicing, an optimization. The preconditions for this phase mirror those of
all-encompassing feature that extends across the CN, TN, the Creation and Deployment phases, with the added condition
and RAN, must consistently uphold these stringent criteria that the RAN slice SLA assurance model or control apps have
throughout the entire lifecycle of a network slice, with a already been deployed.
particular emphasis placed on the RAN architecture [160]. In this phase, the Non-RT RIC is presented with two
However, the dynamic nature of the RAN architecture poses options for slow loop optimization. It may opt to adjust
a considerable challenge in maintaining consistent service the RAN configuration in accordance with long-term trends,
quality for each RAN slice within the complex multi-vendor utilizing data collected via the O1 interface. Alternatively, it
O-RAN environment [36], [129]. Addressing this challenge may choose to develop A1 policies tailored to the specific
necessitates further in-depth investigation and rigorous stan- requirements of the RAN slice SLA, incorporating inputs such
dardization efforts to establish the requisite mechanisms and as A1 feedback, O1 long-term trends, and operator-defined
parameters for the RAN slice SLA assurance [115]. The SLA RAN intents.
is a contract between the network service provider and the In the next step of this phase, the SMO Framework updates
 35

the slice configuration of the Near-RT RIC or the RAN nodes via the X2 and F1 interfaces, following provisioning through
based on the instructions received from the AI/ML model the O1/E2/A1 interface. The negotiation period is extended to
or control app. Following this update, there are two possible several seconds, influenced by the periodic exchange of the
outcomes: either the Near-RT RIC and the RAN nodes proceed X2 and F1 messages between the vO-CUs.
to implement and execute the updated slice configuration, or Case 3: A tight coordination through a new interface
the Near-RT RIC receives the updated A1 policies, enabling between the vO-DUs for adaptive resource allocation, which
it to take control of the RAN nodes and provide feedback via needs a more frequent negotiation.
the A1 interface to the Non-RT RIC. The utilization of multi-vendor slices is applicable in sce-
c) Fast Loop RAN Slice SLA optimization: In this phase, narios involving RAN sharing. In such cases, two operators,
similar preconditions to those of the slow loop RAN slice labeled A and B, possess their respective vO-DU and vO-CU
SLA optimization are applicable. The Non-RT RIC evaluates components from distinct vendors while jointly utilizing the
the necessity of formulating a policy to ensure slice SLA O-RU component. However, the scenario involving the use of
assurance for the Near-RT RIC slice. This evaluation is based O-DU and O-CU components from different vendors within a
on the RAN slice SLA requirements and/or operator-defined single slice requires further examination [189].
RAN intents. It also considers feedback from the Near-RT RIC Adopting a multi-vendor approach cultivates a resilient and
via the A1 interface or long-term trends observed through the adaptable network ecosystem, benefiting operators and end-
O1 interface, as well as enrichment information from external users alike. Upon the successful implementation of multi-
application servers. vendor scenarios, the anticipated benefits include:
Afterwards, the Near-RT RIC is furnished with slice-specific a) Flexibility and time-to-market deployment: Numerous
O1 configurations from the SMO Framework and A1 policies vendors offer virtualized RAN components like the vO-DU,
from the Non-RT RIC. It proceeds to collect PMs information vO-CU, and schedulers for different network slices. Network
via the E2 interface. These gathered PMs, combined with the operators can thus select the most suitable components for
A1 policies from the Non-RT RIC, undergo analysis by either each network slice, whether they prioritize high data rates or
the AI/ML model or the control app to direct the RAN nodes low latencies. This flexibility also enables network operators
towards meeting the slice SLA. This sequence concludes upon to introduce new services effortlessly, with the option to
the deactivation of the RAN slice subnet. implement additional functions from different vendors without
changing their existing setups and configurations [40].
C. Multi-vendor Slices b) Flexible deployment for RAN equipment sharing: In
This use case involves orchestrating multiple network slices, scenarios where multiple vendors aim to share RAN equip-
each incorporating the RAN components sourced from diverse ment and resources, challenges may arise concerning vendor
vendors. For instance, network slice 1 utilizes O-DU and O- selection and the placement of RAN functions. However, by
CU from vendor A, while network slice 2 employs components addressing these challenges through collaborative use-cases,
from vendor B, with O-RU from vendor C being shared network operators can reach agreements on shared RAN
between both slices [189]. This allows for the utilization equipment and resources, thereby optimizing capital expendi-
of different slices tailored to distinct application scenarios, ture (CAPEX) and OPEX [190] and potentially opening doors
as each component offers unique specifications. While the to further business investment opportunities.
implementation of this use case can vary, they all involve the c) Supply chain risks reduction: In scenarios where a
utilization of a single O-RU, which may be connected to one vendor discontinues support for certain vO-DU and vO-CU
or more O-DUs. To support multiple slices, the schedulers of functions due to business circumstances, network operators
the virtualized O-DU (vO-DU) and virtualize O-CU (vO-CU) retain the ability to implement substitute vO-DU and vO-
must manage each NSI individually [129]. CU functions from different vendors within a multi-vendor
The vendor supplying vO-DU and vO-CU functionalities framework. This proactive approach serves to alleviate poten-
must possess a robust customized scheduler tailored for spe- tial risks to network operators’ ongoing business operations,
cific services. Moreover, effective coordination between the bolstering their resilience amidst market dynamics [189].
vO-DU and vO-CU is essential to allocating radio resources
seamlessly in multi-vendor slices, ensuring conflict-free op- D. NSSI Resource Allocation Optimization
eration. The necessary coordination can be assessed based The increasing complexity of 5G networks, marked by
on service objectives and their implications for the O-RAN the proliferation of millimeter-wave small cells and diverse
architecture [118]. For instance, the following three potential services like eMBB, URLLC, and mMTC, poses challenges
coordination strategies could be explored: in dynamically and efficiently allocating resources among
Case 1: The resource allocation between the vO-DU and network nodes [12]. These services, realized as NSIs, exhibit
vO-CU is provisioned with loose coordination through the varying characteristics such as high-speed data, ultra-low
O1/A1/E2 interface; each pair of the vO-DU and vO-CU latency, and sporadic traffic patterns influenced by factors such
is responsible for allocating radio resources to individual as time, location, UE distribution, and application types.
customers within the radio resources allocated by the Near- To tackle the aforementioned challenges, the optimization
RT RIC and/or the Non-RT RIC. of resources allocated to NSSI is crucial. Various scenarios,
Case 2: A moderate coordination where the resource allo- such as internet of things (IoT) applications running during
cation can be negotiated among slices or the vO-DU/vO-CUs off-peak hours or weekends and large events causing a surge
 36

in data flow, are considered. The data collected from the updating the O-Cloud resources via the O2 interface. The co-
O-RAN nodes serves as input to train an AI/ML model ordination of these steps is managed by the SMO Framework
embedded within the NSSI, enabling proactive determination following recommendations from the Non-RT RIC.
of traffic demand patterns for different times and locations
across network slices. This approach facilitates the automatic VII. C ONCLUDING R EMARKS AND F UTURE O UTLOOK
reallocation of resources ahead of network issues, optimizing In conclusion, the exploration of O-RAN architecture illu-
resource utilization, and ensuring flexibility in responding to minates its transformative potential in the context of wireless
diverse service requirements [129]. network infrastructure. As the telecommunications landscape
Implementing resource quota policies within RAN NFs, evolves to meet the demands of 5G, 6G, and beyond wireless
notably E2 nodes within their respective NSSIs, facilitates systems, O-RAN emerges as a promising paradigm shift,
efficient management of resource allocation across diverse offering flexibility, interoperability, and cost-efficiency in net-
slices [118]. This flexibility enables the prioritization of re- work deployment and management. Through our analysis in
source distribution based on service importance, fostering this survey paper, it becomes evident that O-RAN’s disag-
effective resource sharing during periods of both abundance gregated approach to network elements, enabled by open
and scarcity. Premium service slices within an NSSI may interfaces, automation, intelligence, and software-defined net-
receive a more substantial allocation of resources compared to working principles, fosters innovation and competition among
standard or best-effort service slices, while emergency services vendors while reducing vendor lock-in. This not only spurs
also benefit from additional resource allocation during critical the development of diverse and specialized network functions
situations [68]. Acting as constraints for resource allocation, but also empowers operators to tailor their networks to specific
these policies aim to optimize resource utilization across slices. use cases and environments with greater agility and granularity
They are adaptable and can be tailored to specific require- through the deployment of network slicing at both network and
ments, such as analyzing past resource allocation failures management domains. In essence, while the journey towards
evident in RAN node measurements. This ensures optimal realizing the full potential of network slicing in O-RAN may
utilization, mitigates historical trends, and minimizes resource be fraught with challenges, the destination promises a network
inefficiencies. landscape that is more open, agile, and responsive to the
The O-RAN entities involved in this use case are the SMO evolving needs of wireless communication in the next decade.
Framework, the Non-RT RIC, and the O-RAN nodes. The To explore the topic of network slicing within the O-RAN
SMO Framework establishes the default NSSI resource quota architecture in a detailed manner, we presented its several
policy, which acts as a parameter for optimizing resource aspects in this paper, including the architectural framework,
allocation. Meanwhile, the Non-RT RIC gathers performance network slice deployment options, management and orchestra-
metrics from the O-RAN nodes, employs the AI/ML models to tion procedures, and underlying infrastructure, among many
analyze historical data, predicts traffic demand patterns, and others. We began by exploring the ongoing standardization
determines appropriate resource adjustments for each NSSI activities within various SDOs and the efforts of the OSC
[52], [118]. Subsequently, the Non-RT RIC optimizes the with respect to the realization of O-RAN. Then, we discussed
NSSI resource allocation by adjusting attributes and updating the O-RAN architecture with a special emphasis on network
cloud resources through the O1 and O2 interfaces, respectively. slicing, covering its SMO Framework, O-gNB functionalities,
The O-RAN nodes facilitate performance data collection and and underlying infrastructure. Next, we studied a number of
configuration updates regarding the NSSI resource allocation deployment options for NFs and network slices within O-
via the O1 interface. They also facilities management data RAN, as well as several deployment options for the MFs
collection. and management systems within the SMO Framework. We
The process of the NSSI Resource Allocation Optimization then surveyed network slicing associated with the underlying
on the Non-RT RIC may encompass the following steps: infrastructure within the O-RAN architecture, covering slicing
a) Monitoring: The Non-RT RIC monitors the RAN in the cellular network sites, O-Cloud sites, and transport
to collect data through the O1 interface and gathers RAN networks. Finally, we addressed several use cases related to
performance measurements from the RAN nodes. the deployment of O-RAN slicing.
b) Analysis & decision: The Non-RT RIC leverages Looking ahead, future research endeavors could extend the
an appropriate AI/ML model to analyze measured data and current work by exploring the potential of xApps and rApps
forecast future traffic demand for each NSSI within a specified within the O-RAN framework, delving into their capabilities
time interval and geographical location. Based on this analysis, for enhancing network intelligence, service orchestration, and
it determines the necessary actions to adjust resources such as resource optimization. The envisioned xApps and rApps may
the VNF resources and slice subnet attributes for the RAN employ advanced ML algorithms to dynamically allocate
NFs specifically the E2 Nodes within their respective NSSI at resources, predict traffic patterns, and optimize performance
the designated time and location. for each network slice. Additionally, integrating AI and ML
c) Execution: The Non-RT RIC executes operations models into various optimization functions within O-RAN
through two sequential steps guided by model inference. networks presents a promising avenue for improving network
Firstly, it adjusts slice subnet attributes via the OAM functions efficiency, performance, and user experience. By harnessing
in SMO Framework, utilizing O1 interface to configure the E2 the power of advanced analytics and automation, future re-
nodes. Secondly, it initiates a request to the O-Cloud M&O for search initiatives can further unlock the transformative poten-
 37

tial of O-RAN, propelling the evolution of telecommunications DES data exposure service
infrastructure into a new era of connectivity and innovation. DL deep learning
We hope that the insights, together with the deep dive into DMaaP data movement as a platform
the O-RAN slicing specifications, architecture, and interfaces, DMS deployment management service
will provide more flexibility for O-RAN slicing deployment DSCP differentiated services code point
by using AI and ML models and xApps and rApps. DU distributed unit
DWDM dense WDM
L IST OF ACRONYMS E2E end-to-end
3GPP 3rd Generation Partnership Project eCPRI evolved CPRI
4G fourth-generation EM element management
5G fifth-generation eMBB enhanced mobile broadband
5GC 5G Core EN-DC E-UTRA NR dual connectivity
5QI 5G QoS identifier eNB evolved NodeB
6G sixth-generation ETSI European Telecommunications Standards In-
AAI active and available inventory stitute
AC attachment circuit EVPN ethernet VPN
AI artificial intelligence FAPI functional API
AMF access and mobility management function FB functional block
API application programming interface FCAPS fault, configuration, accounting,
ARC aerial RAN CoLab performance, security
BBU baseband unit FDD frequency division duplexing
BGP border gateway protocol FFT fast fourier transform
BH backhaul FG focus group
BIOS basic input and output system FH fronthaul
BMC baseboard management controller gNB next generation NodeB
BPMN business process management notation GPU graphics processing unit
BSS business support system GTP-U GPRS tunneling protocol user plane
BWP bandwidth partitioning GUI graphical user interface
C-RAN centralized RAN HLS high layer split
CAPEX capital expenditure HMTC high-performance machine type communica-
CCM CIS cluster management tion
CCSDK common controller software development kit IGP interior gateway protocol
CD continuous deployment IL infrastructure layer
CDS controller design studio IMS infrastructure management service
CI continuous integration IoT internet of things
CIR container image registry IP internet protocol
CIS container infrastructure service IPv6 IP version 6
CISM CIS management IQ in-phase and quadrature
CLAMP closed loop automation management plat- ISG industry specification group
form KPI key performance indicator
CN core network KPM key performance measurement
CNF containerized network function L2 layer 2
COTS commercial off-the-shelf L3 layer 3
CP control plane L3VPN layer 3 VPN
CPRI common public radio interface LF linux foundation
CPS configuration persistence service LTE long term evolution
CPU central processing unit M5G MOSAIC 5G
CSI communication service instance M&O management & orchestration
CSMF communication service management func- MAC medium access control
tion MANO management and orchestration
CST communication service template MD management domain
CU centralized unit MF management function
D-RAN distributed RAN MH midhaul
DARTs disaggregated RAN transport study ML machine learning
DC data center mMTC massive machine type communication
DCAE data collection, analysis and event MNO mobile network operator
 38

MnS management service OTIC open testing and integration center

MP management plane PDCP packet data convergence protocol
MP-BGP multi-protocol border gateway protocol PE provider edge
MPLS multi-protocol label switching PG project group
MSCS multi-site connectivity service PHY physical layer
MVP-C minimum viable plan - committee PLMN public land mobile network
NB-IoT narrowband IoT PM performance metric
Near-RT RIC near-real-time RIC PNF physical network function
NF network function PoP point-of-presence
nFAPI network FAPI PRB physical resource block
NFL network function layer QoE quality of experience
NFMF network function management function QoS quality of service
NFMS P NFMS provider RAM random access memory
NFV network function virtualization RAN radio access network
NFV-MANO network functions virtualization management rApp Non-RT RIC application
and orchestrierung RAT radio access technology
NFVI NFV infrastructure RF radio frequency
NFVO network function virtualization orchestrator RIA radio intelligence automation
ng-eNB next generation eNB RIC RAN intelligent controller
NG-RAN next-generation RAN RLC radio link control
NIC network interface card RoE radio over ethernet
Non-RT RIC non-real-time RIC ROMA OpenRAN orchestration and management
NR new radio automation
NSaaS network slice as a service RRC radio resource control
NSI network slice instances RRH remote radio head
NSMF network slice management function RRM radio resource management
NSSAI network slice selection assistance informa- RU radio unit
tion S-NSSAI single NSSAI
NSSI network slice subnet instance S-RU small cell RU
NSSMF network slice subnet management function SBA services based architecture
NSSMS C NSSMS cunsumer SCF small cell forum
NSSMS P NSSMS provider SD slice differentiator
NSST network slice subnet template SD-RAN software-defined RAN
NST network slice template SDAP service data adaptation protocol
O-Cloud O-RAN cloud platform SDC service design and creation
O-CU O-RAN CU SDN software-defined networking
O-CU-CP O-CU control plane SDN-C SDN controller
O-CU-UP O-CU user plane SDO standards development organization
O-DU O-RAN DU SDR software-defined radio
O-eNB O-RAN eNB SID segment ID
O-FH open fronthaul SL service layer
O-gNB O-RAN gNodeB SLA service level agreement
O-NSSI O-RAN NSSI SLE service level expectation
O-RAN Open RAN SMO service management and orchestration
O-RU O-RAN RU SO service orchestrator
OAI OpenAirInterface SR segment routing
OAM operations and maintenance SRS software radio system
ONAP open network automation platform SRv6 SR over IPv6
ONF open networking foundation SST slice/service type
OOF ONAP optimization framework TCO total cost of ownership
OOM ONAP operations manager TDD time division duplexing
OPEX operational expenditure TE traffic engineering
OSA OpenAirInterface software alliance TIP telecom infra project
OSC O-RAN software community TN transport network
OSM open source MANO TNE transport network equipment
OSS operations support system TSC technical steering committee
 39

TSG technical specification group [11] J. L. Frauendorf and É. Almeida de Souza, The Evolution of RAN (Ra-
UE user equipment dio Access Network), D-RAN, C-RAN, V-RAN, and O-RAN, pp. 139–
UMTS universal mobile telecommunications system 154. Cham: Springer International Publishing, 2023.
[12] L. Bonati, S. D’Oro, M. Polese, S. Basagni, and T. Melodia, “Intelli-
UP user plane gence and learning in o-ran for data-driven nextg cellular networks,”
UPF user plane function IEEE Communications Magazine, vol. 59, no. 10, pp. 21–27, 2021.
URLLC ultra reliable low latency communication [13] 3GPP, “5g; ng-ran; architecture description,” tech. rep., 3rd Generation
Partnership Project (3GPP), 09 2020. 3GPP TS 38.401 version 15.2.0
UUI use case user interface Release 15.
V2X vehicle to everything [14] W. Rouwet, Open Radio Access Network (O-RAN) Systems Architecture
VIM virtualized infrastructure manager and Design. Elsevier Science, 2022.
VLAN virtual LAN [15] L. Bonati, M. Polese, S. d’oro, S. Basagni, and T. Melodia, “Open,
programmable, and virtualized 5g networks: State-of-the-art and the
VNF virtualized network function road ahead,” Computer Networks, vol. 182, p. 107516, 08 2020.
VNFM virtual network functions manager [16] M. A. Habibi, F. Z. Yousaf, and H. D. Schotten, “Mapping the vnfs and
vO-CU virtualize O-CU vls of a ran slice onto intelligent pops in beyond 5g mobile networks,”
IEEE Open Journal of the Communications Society, vol. 3, pp. 670–
vO-DU virtualized O-DU 704, 2022.
VPN virtual private network [17] M. A. Habibi, B. Han, A. Fellan, W. Jiang, A. G. Snchez, I. L.
VPWS virtual private wire service Pavon, A. Boubendir, and H. D. Schotten, “Toward an open, intelligent,
and end-to-end architectural framework for network slicing in 6g
WDM wavelength division multiplexing communication systems,” IEEE Open Journal of the Communications
WG working group Society, vol. 4, pp. 1615–1658, 2023.
WIM WAN infrastructure manager [18] X. Krasniqi, E. Hajrizi, and B. Qehaja, “Challenges and lessons learned
during private 5g open ran deployments,” in 2023 3rd International
xApp Near-RT RIC application Conference on Electrical, Computer, Communications and Mechatron-
ZSM zero touch network and service management ics Engineering (ICECCME), pp. 1–6, 2023.
[19] M. Polese, L. Bonati, S. DOro, S. Basagni, and T. Melodia, “Under-
ACKNOWLEDGMENT standing o-ran: Architecture, interfaces, algorithms, security, and re-
search challenges,” IEEE Communications Surveys & Tutorials, vol. 25,
This research was partially supported by the German Fed- no. 2, pp. 1376–1411, 2023.
eral Ministry of Education and Research (BMBF) through [20] A. S. Abdalla, P. S. Upadhyaya, V. K. Shah, and V. Marojevic, “Toward
next generation open radio access networks: What o-ran can and cannot
the project 6G-Terafactory under Grant no. 16KISK186 and do!,” IEEE Network, vol. 36, no. 6, pp. 206–213, 2022.
partially within the project Open6GHub under Grant no. [21] Keysight, “The essential guide for understanding o-ran,” 2023.
16KISK003K & 16KISK004. The authors are grateful to the [22] O-RAN Alliance, “Ts: O-ran wg1 (use cases and overall architecture)
o-ran architecture description,” 04 2023.
anonymous reviewers for their insightful comments and valu- [23] S. Niknam, A. Roy, H. S. Dhillon, S. Singh, R. Banerji, J. H. Reed,
able remarks, which have significantly improved the quality N. Saxena, and S. Yoon, “Intelligent o-ran for beyond 5g and 6g
of this article. wireless networks,” in 2022 IEEE Globecom Workshops (GC Wkshps),
pp. 215–220, 2022.
[24] C. K. Thomas, C. Chaccour, W. Saad, M. Debbah, and C. S. Hong,
R EFERENCES “Causal reasoning: Charting a revolutionary course for next-generation
[1] V. S. Pana, O. P. Babalola, and V. Balyan, “5G radio access networks: ai-native wireless networks,” 2024.
A survey,” Array, vol. 14, p. 100170, 2022. [25] M. Chen, U. Challita, W. Saad, C. Yin, and M. Debbah, “Artificial
[2] M. A. Habibi, M. Nasimi, B. Han, and H. D. Schotten, “A Comprehen- neural networks-based machine learning for wireless networks: A
sive Survey of RAN Architectures Toward 5G Mobile Communication tutorial,” IEEE Communications Surveys & Tutorials, vol. 21, no. 4,
System,” IEEE Access, vol. 7, pp. 70371–70421, 2019. pp. 3039–3071, 2019.
[3] S. K. Singh, R. Singh, and B. Kumbhani, “The evolution of radio [26] A. Giannopoulos, S. Spantideas, N. Kapsalis, P. Gkonis, L. Sarakis,
access network towards open-ran: Challenges and opportunities,” in C. Capsalis, M. Vecchio, and P. Trakadas, “Supporting intelligence
2020 IEEE Wireless Communications and Networking Conference in disaggregated open radio access networks: Architectural principles,
Workshops (WCNCW), pp. 1–6, 2020. ai/ml workflow, and use cases,” IEEE Access, vol. 10, pp. 39580–
[4] C. Chaccour, W. Saad, M. Debbah, Z. Han, and H. V. Poor, “Less data, 39595, 2022.
more knowledge: Building next generation semantic communication [27] A. U. Rehman, R. Aguiar, and J. Barraca, “Network functions virtu-
networks,” 2022. alization: The long road to commercial deployments,” IEEE Access,
[5] W. Azariah, F. Asisi Bimo, C.-W. Lin, R.-G. Cheng, R. Jana, and pp. 1–1, 05 2019.
N. Nikaein, “A survey on open radio access networks: Challenges, [28] M. A. Habibi, B. Han, F. Z. Yousaf, and H. D. Schotten, “How should
research directions, and open source approaches,” Submitted to IEEE network slice instances be provided to multiple use cases of a single
Communications Surveys and Tutorials, 19 August 2022, 2022. vertical industry?,” IEEE Communications Standards Magazine, vol. 4,
[6] W. Jiang, B. Han, M. A. Habibi, and H. D. Schotten, “The road no. 3, pp. 53–61, 2020.
towards 6g: A comprehensive survey,” IEEE Open Journal of the [29] Ericsson, White Paper; 5 Key Facts About 5G Radio Access Networks.
Communications Society, vol. 2, pp. 334–366, 2021. Ericsson, 2020.
[7] N. P. Kuruvatti, M. A. Habibi, S. Partani, B. Han, A. Fellan, and H. D. [30] C.-Y. Chang and N. Nikaein, “Ran runtime slicing system for flexible
Schotten, “Empowering 6G Communication Systems With Digital and dynamic service execution environment,” IEEE Access, vol. 6,
Twin Technology: A Comprehensive Survey,” IEEE Access, vol. 10, pp. 34018–34042, 2018.
pp. 112158–112186, 2022. [31] O-RAN Alliance, “Tr: O-ran wg1 study on o-ran slicing,” 04 2020.
[8] B. Han, M. A. Habibi, B. Richerzhagen, K. Schindhelm, F. Zeiger, [32] M. A. Habibi, A. G. Snchez, I. L. Pavn, B. Han, P. Serrano, J. Prez-
F. Lamberti, F. G. Prattic, K. Upadhya, C. Korovesis, I.-P. Belikaidis, Valero, A. Virdis, and H. D. Schotten, “The architectural design of
P. Demestichas, S. Yuan, and H. D. Schotten, “Digital twins for industry service management and orchestration in 6g communication systems,”
4.0 in the 6g era,” IEEE Open Journal of Vehicular Technology, vol. 4, in IEEE INFOCOM 2023 - IEEE Conference on Computer Communi-
pp. 820–835, 2023. cations Workshops (INFOCOM WKSHPS), pp. 1–2, 2023.
[9] M. Kassi and S. Hamouda, “Ran virtualization: How hard is it to fully [33] O. Sallent, J. Perez-Romero, R. Ferrus, and R. Agusti, “On radio access
achieve?,” IEEE Access, vol. 12, pp. 38030–38047, 2024. network slicing from a radio resource management perspective,” IEEE
[10] P. K. Thiruvasagam, C. T, V. Venkataram, V. R. Ilangovan, M. Pera- Wireless Communications, vol. 24, no. 5, pp. 166–174, 2017.
palla, R. Payyanur, S. M. D, V. Kumar, and K. J, “Open ran: Evolution [34] B. Khodapanah, A. Awada, I. Viering, A. n. Barreto, M. Simsek, and
of architecture, deployment aspects, and future directions,” 2023. G. Fettweis, “Framework for slice-aware radio resource management
 40

utilizing artificial neural networks,” IEEE Access, vol. 8, pp. 174972– F. Darema, “Artificial intelligence and machine learning,” in 2022 IEEE
174987, 2020. Future Networks World Forum (FNWF), pp. 1–70, 2022.
[35] L. Bonati, M. Polese, S. d’oro, S. Basagni, and T. Melodia, “Openran [57] Q. Sun, N. Li, C.-L. I, J. Huang, X. Xu, and Y. Xie, “Intelligent
gym: An open toolbox for data collection and experimentation with ran automation for 5g and beyond,” IEEE Wireless Communications,
ai in o-ran,” in 2022 IEEE Wireless Communications and Networking vol. 31, no. 1, pp. 94–102, 2024.
Conference (WCNC), pp. 518–523, 04 2022. [58] Juniper, “What is open ran?.”
[36] W. Wu, N. Chen, C. Zhou, M. Li, X. Shen, W. Zhuang, and X. Li, [59] 5G Americas, “The evolution of open ran — 5g americas white paper,”
“Dynamic ran slicing for service-oriented vehicular networks via 02 2023. [Accessed 28-02-2024].
constrained learning,” 2020. [60] L. Gavrilovska, V. Rakovic, and D. Denkovski, “From Cloud RAN to
[37] D. Wypir, M. Klinkowski, and I. Michalski, “Open RAN - Radio Open RAN,” Wireless Personal Communications, vol. 113, pp. 1523–
Access Network Evolution, Benefits and Market Trends,” Applied 1539, Aug. 2020.
Sciences, vol. 12, no. 1, 2022.
[61] Parallel Wireless, “Everything you need to know about open ran,” 2020.
[38] A. Arnaz, J. Lipman, M. Abolhasan, and M. Hiltunen, “Toward
integrating intelligence and programmability in open radio access [62] S. Bhattacharjee, K. Katsalis, O. Arouk, R. Schmidt, T. Wang, X. An,
networks: A comprehensive survey,” IEEE Access, vol. 10, pp. 67747– T. Bauschert, and N. Nikaein, “Network slicing for tsn-based transport
67770, 2022. networks,” IEEE Access, vol. 9, pp. 62788–62809, 2021.
[39] B. Brik, K. Boutiba, and A. Ksentini, “Deep learning for b5g open [63] A. S. Abdalla and V. Marojevic, “End-to-end o-ran security architec-
radio access network: Evolution, survey, case studies, and challenges,” ture, threat surface, coverage, and the case of the open fronthaul,” IEEE
IEEE Open Journal of the Communications Society, vol. 3, pp. 228– Communications Standards Magazine, vol. 8, no. 1, pp. 36–43, 2024.
250, 2022. [64] X. Li, R. Ni, J. Chen, Y. Lyu, Z. Rong, and R. Du, “End-to-end network
[40] M. Q. Hamdan, H. Lee, D. Triantafyllopoulou, R. Borralho, A. Kose, slicing in radio access network, transport network and core network
E. Amiri, D. Mulvey, W. Yu, R. Zitouni, R. Pozza, B. Hunt, H. Bagheri, domains,” IEEE Access, vol. 8, pp. 29525–29537, 2020.
C. H. Foh, F. Heliot, G. Chen, P. Xiao, N. Wang, and R. Tafazolli, [65] P. muoz, . Adamuz-Hinojosa, J. Navarro-Ortiz, O. Sallent, and J. Prez-
“Recent advances in machine learning for network automation in the Romero, “Radio access network slicing strategies at spectrum planning
o-ran,” Sensors, vol. 23, no. 21, 2023. level in 5g and beyond,” IEEE Access, vol. 8, pp. 79604–79618, 2020.
[41] M. Alavirad, U. Hashmi, M. Mansour, A. Esswie, R. Atawia, G. Poitau, [66] GSMA, “Official document ng.135 - e2e network slicing requirements
and M. Repeta, “O-ran architecture, interfaces, and standardization: v3.0,” 06 2023.
Study and application to user intelligent admission control,” Frontiers [67] P. Wyszkowski, J. Kienig, K. Zieliski, . Czekierda, and M. Zawadzki,
in Communications and Networks, vol. 4, 03 2023. “Comprehensive tutorial on the organization of a standards-aligned net-
[42] M. Liyanage, A. Braeken, S. Shahabuddin, and P. Ranaweera, “Open work slice/subnet design process and opportunities for its automation,”
ran security: Challenges and opportunities,” Journal of Network and IEEE Communications Surveys & Tutorials, pp. 1–1, 2023.
Computer Applications, vol. 214, p. 103621, 2023. [68] L. U. Khan, I. Yaqoob, N. H. Tran, Z. Han, and C. S. Hong, “Network
[43] Y. Huang, Q. Sun, N. Li, Z. Chen, J. Huang, H. Ding, and C.- slicing: Recent advances, taxonomy, requirements, and open research
L. , “Validation of current o-ran technologies and insights on the challenges,” IEEE Access, vol. 8, pp. 36009–36028, 2020.
future evolution,” IEEE Journal on Selected Areas in Communications, [69] R. Schmidt and N. Nikaein, Radio Access Network Slicing System,
vol. 42, no. 2, pp. 487–505, 2024. pp. 1–32. John Wiley & Sons, Ltd, 05 2020.
[44] M. Polese, M. Dohler, F. Dressler, M. Erol-Kantarci, R. Jana, R. Knopp, [70] K. Boutiba, A. Ksentini, B. Brik, Y. Challal, and A. Balla, “Nrflex: En-
and T. Melodia, “Empowering the 6g cellular architecture with open forcing network slicing in 5g new radio,” Computer Communications,
ran,” IEEE Journal on Selected Areas in Communications, vol. 42, vol. 181, 10 2021.
no. 2, pp. 245–262, 2024. [71] S. Kukliski, L. Tomaszewski, and R. Koakowski, “On o-ran, mec, son
[45] S. Marinova and A. Leon-Garcia, “Intelligent o-ran beyond 5g: Archi- and network slicing integration,” in 2020 IEEE Globecom Workshops
tecture, use cases, challenges, and opportunities,” IEEE Access, vol. 12, (GC Wkshps, pp. 1–6, 12 2020.
pp. 27088–27114, 2024.
[72] C. Harper and S. Sirotkin, NG-RAN Architecture, pp. 123–234. John
[46] I. Afolabi, T. Taleb, K. Samdanis, A. Ksentini, and H. Flinck, “Network
Wiley & Sons, Ltd, 2021.
slicing and softwarization: A survey on principles, enabling tech-
nologies, and solutions,” IEEE Communications Surveys & Tutorials, [73] NGMN Alliance, “Ngmn overview on 5 g ran functional decomposi-
vol. 20, no. 3, pp. 2429–2453, 2018. tion,” 2018.
[47] N. Sen and A. F. A, “Intelligent admission and placement of o-ran slices [74] “O-RAN Alliance Overview Presentation Whitepaper,” 2024.
using deep reinforcement learning,” in 2022 IEEE 8th International [75] Adrian Kliks, Marcin Dryjaski, Vishnu Ram, Leon Wong, and Paul
Conference on Network Softwarization (NetSoft), pp. 307–311, 2022. Harvey, “Towards autonomous open radio access networks,” ITU
[48] M. A. Habibi, G. M. Yilma, X. Costa-Prez, and H. D. Schotten, Journal on Future and Evolving Technologies, vol. 4, pp. 251–268,
“Unifying 3GPP, ETSI, and O-RAN SMO Interfaces: Enabling Slice May 2023.
Subnets Interoperability,” in IEEE FNWF, 2023. Baltimore, MD, USA, [76] D. Mavrakis, “The road to open ran productization.” Whitepaper,
pp. 1-8. abiresearch, TIP. Available Online (accessed on 24 Jan. 2024)., 04
[49] 3GPP, “Nr; study on enhancement of radio access network (ran) 2021.
slicing,” tech. rep., 3rd Generation Partnership Project (3GPP), 06 2021. [77] TIP, “Open ran mou group,” 2023.
3GPP TR 38.832 Release 17. [78] G. Brown, “Tip openran: Toward disaggregated mobile networking a
[50] 3GPP, “Study on management and orchestration of network slicing for heavy reading white paper produced for the telecom infra project.”
next generation network,” tech. rep., 3rd Generation Partnership Project Online (accessed on 24 Jan. 2024)., 06 2020.
(3GPP), 01 2018. 3GPP TR 28.801 Release 15. [79] P. Chitrapu, “Small cell open ran: A catalyst for new 5g business
[51] J. Ordonez-Lucena, P. Ameigeiras, L. M. Contreras, J. Folgueira, and models.” Small Cell Forum. Online (accessed on 24 Jan 2024)., 04
D. R. Lpez, “On the rollout of network slicing in carrier networks: A 2023.
technology radar,” Sensors, vol. 21, no. 23, 2021. [80] Small Cell Forum, “5g nfapi specifications document scf225.3.0.”
[52] O-RAN Alliance, “Ts: O-ran wg1 slicing architecture,” 10 2022. Online, 07 2022.
[53] M. A. Habibi, B. Han, M. Nasimi, N. P. Kuruvatti, A. Fellan, and H. D. [81] H. Kadia, “Small cell networks will pave the way for growth in many
Schotten, Towards a Fully Virtualized, Cloudified, and Slicing-Aware open ran scenarios.” Technexus, 5G Magazine Aug 2023 Edition, 08
RAN for 6G Mobile Networks, pp. 327–358. Springer International 2023.
Publishing, 2021. [82] ONAP, “Onap 5g blueprint overview,” 2021.
[54] AG, Deutsche Telekom, “Deutsche Telekom and partners demonstrate
[83] H. Lee, J. Cha, D. Kwon, M. Jeong, and I. Park, “Hosting ai/ml
non-real time RAN optimization in a multi-vendor environment,” Sept.
workflows on o-ran ric platform,” in 2020 IEEE Globecom Workshops
2023.
(GC Wkshps, pp. 1–6, 2020.
[55] C.-X. Wang, M. D. Renzo, S. Stanczak, S. Wang, and E. G. Larsson,
“Artificial intelligence enabled wireless networking for 5g and beyond: [84] ONAP, “Common area between onap and osc,” 2023.
Recent advances and future challenges,” IEEE Wireless Communica- [85] ONAP, “Onap/3gpp & o-ran alignment,” 2020.
tions, vol. 27, no. 1, pp. 16–23, 2020. [86] ONAP, “Onap release document,” 2022.
[56] D. Kataria, A. Walid, M. Daneshmand, A. Dutta, M. A. Enright, R. Gu, [87] ONAP, “Onap e2e network slicing technical overview.” Online, 2020.
A. Lackpour, P. Ramachandran, H. Wang, C.-M. Chen, B. Chng, and [88] “About mosaic5g.”
 41

[89] M. Polese, L. Bonati, S. D’Oro, P. Johari, D. Villa, S. Velumani, closed-loop service automation in o-ran based network slicing,” IEEE
R. Gangula, M. Tsampazi, C. P. Robinson, G. Gemmi, A. Lacava, Communications Standards Magazine, vol. 6, no. 3, pp. 8–14, 2022.
S. Maxenti, H. Cheng, and T. Melodia, “Colosseum: The open ran [111] Ericsson, White Paper; An intelligent platform: The use of O-RANs
digital twin,” 2024. SMO as the enabler for openness and innovation in the RAN domain.
[90] ONF, “Sd-ran: Onfs software-defined ran platform consistent with the Ericsson, 11 2021.
o-ran architecture.” ONF White Paper, 2020. [112] M. Dryjaski, L. Kulacz, and A. Kliks, “Toward modular and flexible
[91] “About sd-ran.” open ran implementations in 6g networks: Traffic steering use case and
[92] P. S. Upadhyaya, A. S. Abdalla, V. Marojevic, J. H. Reed, and V. K. o-ran xapps,” Sensors, vol. 21, no. 24, 2021.
Shah, “Prototyping next-generation o-ran research testbeds with sdrs,” [113] M. K. Motalleb, V. Shah-Mansouri, and S. N. Naghadeh, “Joint power
arXiv preprint arXiv:2205.13178, 2022. allocation and network slicing in an open ran system,” arXiv preprint
[93] “About srsran,” 2023. arXiv:1911.01904, 2019.
[94] L. Bonati, M. Polese, S. D’Oro, S. Basagni, and T. Melodia, “Open- [114] R. Wiebusch, N. A. Wagner, D. Overbeck, F. Kurtz, and C. Wietfeld,
RAN Gym: AI/ML Development, Data Collection, and Testing for O- “Towards open 6g: Experimental o-ran framework for predictive uplink
RAN on PAWR Platforms,” Computer Networks, vol. 220, pp. 1–11, slicing,” in ICC 2023 - IEEE International Conference on Communi-
01 2023. cations, pp. 4834–4839, 2023.
[95] L. Bonati, P. Johari, M. Polese, S. D’Oro, S. Mohanti, M. Tehrani- [115] E. Moro, M. Polese, A. Capone, and T. Melodia, “An open ran
Moayyed, D. Villa, S. Shrivastava, C. Tassie, K. Yoder, A. Bagga, framework for the dynamic control of 5g service level agreements,”
P. Patel, V. Petkov, M. Seltser, F. Restuccia, A. Gosain, K. R. Chowd- in 2023 IEEE Conference on Network Function Virtualization and
hury, S. Basagni, and T. Melodia, “Colosseum: Large-Scale Wireless Software Defined Networks (NFV-SDN), pp. 141–146, 2023.
Experimentation Through Hardware-in-the-Loop Network Emulation,” [116] A. Ndao, X. Lagrange, N. Huin, G. Texier, and L. Nuaymi, “Optimal
in Proc. of IEEE Intl. Symp. on Dynamic Spectrum Access Networks placement of virtualized dus in o-ran architecture,” in 2023 IEEE 97th
(DySPAN), (Virtual Conference), 12 2021. Vehicular Technology Conference (VTC2023-Spring), pp. 1–6, 2023.
[96] L. Bertizzolo, L. Bonati, E. Demirors, A. Al-shawabka, S. DOro, [117] M. Silva, J. P. Fonseca, D. P. Abreu, P. Martins, P. Duarte, R. Barbosa,
F. Restuccia, and T. Melodia, “Arena: A 64-antenna sdr-based ceiling B. Mendes, J. Silva, A. Goes, M. Arajo, B. Sousa, M. Curado, and
grid testing platform for sub-6 ghz 5g-and-beyond radio spectrum J. Santos, “O-ran and ric compliant solutions for next generation
research,” Computer Networks, vol. 181, p. 107436, 2020. networks,” in IEEE INFOCOM 2023 - IEEE Conference on Computer
[97] “Profiles of u.s. open ran research and testing facilities.” Open Radio Communications Workshops (INFOCOM WKSHPS), pp. 1–7, 2023.
Access Network Advisory Group; National Spectrum Consortium, [118] O-RAN Alliance, “Ts: O-ran wg1 use cases detailed specification
2023. v12.00,” 10 2023.
[98] POWDER, “Oran on powder,” 2022. [119] L. M. Larsen, H. L. Christiansen, S. Ruepp, and M. S. Berger, “The
[99] D. Johnson, D. Maas, and J. K. V. der Merwe, “Nexran: Closed-loop evolution of mobile network operations: A comprehensive analysis of
ran slicing in powder - a top-to-bottom open-source open-ran use case,” open ran adoption,” Computer Networks, vol. 243, p. 110292, 2024.
in WiNTECH ’21, 2022. [120] 3GPP, “5g; ng-ran; e1 general aspects and principles,” tech. rep., 3rd
[100] D. Raychaudhuri, I. Seskar, G. Zussman, T. Korakis, D. Kilper, T. Chen, Generation Partnership Project (3GPP), 12 2020. 3GPP TS 38.460
J. Kolodziejski, M. Sherman, Z. Kostic, X. Gu, H. Krishnaswamy, version 16.1.0 Release 16.
S. Maheshwari, P. Skrimponis, and C. Gutterman, “Challenge: Cosmos: [121] 3GPP, “Lte; 5g; w1 interface; general aspects and principles,” tech.
A city-scale programmable testbed for experimentation with advanced rep., 3rd Generation Partnership Project (3GPP), 12 2019. 3GPP TS
wireless,” in Proceedings of the 26th Annual International Conference 37.470 version 16.2.0 Release 16.
on Mobile Computing and Networking, vol. 14 of MobiCom ’20, p. 13, [122] AG, Deutsche Telekom, “Bundled in a white book - Learnings from
Association for Computing Machinery, 2020. O-RAN Town,” Feb. 2023.
[101] D. Villa, I. Khan, F. Kaltenberger, N. Hedberg, R. S. da Silva, [123] O-RAN Alliance, “O-ran wg4 open fh interfaces: Management plane
A. Kelkar, C. Dick, S. Basagni, J. M. Jornet, T. Melodia, M. Polese, specification,” 10 2023.
and D. Koutsonikolas, “An Open, Programmable, Multi-vendor 5G O- [124] O-RAN Alliance, “O-ran wg4 open fh interfaces: Control, user and
RAN Testbed with NVIDIA ARC and OpenAirInterface,” in IEEE synchronization plane specification,” 2023.
INFOCOM 2024 - IEEE Conference on Computer Communications, [125] C. Adamczyk, “Challenges for conflict mitigation in o-rans ran in-
05 2024. telligent controllers,” in 2023 International Conference on Software,
[102] H. Koumaras, D. Tsolkas, G. Gardikis, P. Merino, V. Frascolla, Telecommunications and Computer Networks (SoftCOM), pp. 1–6,
D. Triantafyllopoulou, M. Emmelmann, V. Koumaras, M. Garcia Osma, 2023.
D. Munaretto, E. Atxutegi, J. Puga, O. Alay, A. Brunstrom, and A.-M. [126] G. Brown, “The Role of the RAN Intelligent Controller in Open
Bosneag, “5genesis: The genesis of a flexible 5g facility,” in 2018 IEEE RAN Systems.” A Heavy Reading white paper produced for Sterlite
23rd International Workshop on Computer Aided Modeling and Design Technologies Limited, 10 2020.
of Communication Links and Networks (CAMAD), pp. 1–6, IEEE, 09 [127] “Open Radio Access Network Architecture on AWS - Open Radio
2018. Access Network Architecture on AWS,” 2022.
[103] AG, Deutsche Telekom, “Easy and simple: Network Disaggregation,” [128] S. Kpsell et al., “Open RAN Risk Analysis.” A Study in Cooperation
Feb. 2020. with secunet, 02 2022.
[104] S. Kumar, “Ai/ml enabled automation system for software defined [129] B. Brik, H. Chergui, L. Zanzi, F. Devoti, A. Ksentini, M. S. Siddiqui,
disaggregated open radio access networks: Transforming telecommuni- X. Costa-Prez, and C. Verikoukis, “A survey on explainable ai for 6g o-
cation business,” Big Data Mining and Analytics, vol. 7, no. 2, pp. 271– ran: Architecture, use cases, challenges and research directions,” 2023.
293, 2024. [130] O-RAN Alliance, “Tr: O-ran wg3 near-rt ric architecture v01.01,” 04
[105] J. Groen, S. D’Oro, U. Demir, L. Bonati, D. Villa, M. Polese, 2020.
T. Melodia, and K. Chowdhury, “Securing o-ran open interfaces,” IEEE [131] S.-Y. Lien, Y.-C. Huang, C.-C. Tseng, S.-C. Lin, C.-L. I, X. Xu,
Transactions on Mobile Computing, pp. 1–13, 2024. and D.-J. Deng, “Universal vertical application adaptation for o-ran:
[106] “Transformation and 5g o-ran, vmware white paper,” 2021. Low-latency ric and autonomous intelligent xapp generation,” IEEE
[107] J. Zhang, C. Yang, R. Dong, Y. Wang, A. Anpalagan, Q. Ni, and Communications Magazine, pp. 1–7, 2023.
M. Guizani, “Intent-driven closed-loop control and management frame- [132] M. Hoffmann, S. Janji, A. Samorzewski, . Kuacz, C. Adamczyk,
work for 6g open ran,” IEEE Internet of Things Journal, vol. 11, no. 4, M. Dryjaski, P. Kryszkiewicz, A. Kliks, and H. Bogucka, “Open ran
pp. 6314–6327, 2024. xapps design and evaluation: Lessons learnt and identified challenges,”
[108] M. Polese, L. Bonati, S. D’Oro, S. Basagni, and T. Melodia, “Colo- IEEE Journal on Selected Areas in Communications, vol. 42, no. 2,
ran: Developing machine learning-based xapps for open ran closed-loop pp. 473–486, 2024.
control on programmable experimental platforms,” IEEE Transactions [133] M. Dryjaski, “O-ran near-real-time ric,” 07 2022. Rimedolabs.
on Mobile Computing, vol. 22, no. 10, pp. 5787–5800, 2023. [134] O-RAN Alliance, “Ts: O-ran wg3 near-real-time ran intelligent con-
[109] P. H. Masur, J. H. Reed, and N. K. Tripathi, “Artificial intelligence in troller and e2 interface e2 service model (e2sm) v03.00,” 03 2023.
open radio access network,” IEEE Aerospace and Electronic Systems [135] S. D’Oro, M. Polese, L. Bonati, H. Cheng, and T. Melodia, “dapps:
Magazine, vol. 37, pp. 6–15, 09 2022. Distributed applications for real-time inference and control in o-ran,”
[110] J. Thaliath, S. Niknam, S. Singh, R. Banerji, N. Saxena, H. S. IEEE Communications Magazine, vol. 60, no. 11, pp. 52–58, 2022.
Dhillon, J. H. Reed, A. K. Bashir, A. Bhat, and A. Roy, “Predictive [136] M. Dryjaski, “Network slicing in o-ran,” 07 2022. Rimedolabs.
 42

[137] H. Lee, Y. Jang, J. Song, and H. Yeon, “O-ran ai/ml workflow [170] O-RAN Alliance, “Ts: O-ran open xhaul transport wg9; xhaul packet
implementation of personalized network optimization via reinforcement switched architectures and solutions v05.00,” 02 2023.
learning,” in 2021 IEEE Globecom Workshops (GC Wkshps), pp. 1–6,
2021. [171] F. Salahdine, Q. Liu, and T. Han, “Towards secure and intelligent
[138] O-RAN Alliance, “Tr: O-ran wg2 non-rt ric architecture,” 04 2020. network slicing for 5g networks,” IEEE Open Journal of the Computer
[139] 5G Americas, “Open ran update — 5g americas white paper,” 11 2023. Society, vol. 3, pp. 23–38, 2022.
[Accessed 28-02-2024]. [172] “Types of Cell Sites.”
[140] O-RAN Alliance, “Ts: O-ran wg2 a1 interface: General aspects and
principles,” 03 2023. [173] H. Baba, T. Nakamura, A. Fukuda, H. Tanaka, T. Yamazaki, N. Ya-
[141] O-RAN Alliance, “Ts: O-ran wg3 near-real-time ran intelligent con- mazaki, and N. Abe, “5g xhaul sharing as slice implementation with
troller and e2 interface e2 service model (e2sm),” 03 2023. inter- and intra-operator orchestration,” in 2020 6th IEEE Conference
[142] T.-H. Wang, Y.-C. Chen, S.-J. Huang, K.-S. Hsu, and C.-H. Hu, on Network Softwarization (NetSoft), pp. 356–358, 2020.
“Design of a network management system for 5g open ran,” in 2021 [174] O-RAN Alliance, “Ts: O-ran open xhaul transport wg9; xhaul transport
22nd Asia-Pacific Network Operations and Management Symposium requirements,” 11 2020.
(APNOMS), pp. 138–141, 2021.
[143] ETSI, “Management and orchestration; architectural framework speci- [175] D. Camps-Mur, J. Gutierrez, E. Grass, A. Tzanakaki, P. Flegkas,
fication, etsi nfv isg, group specification.” Network Functions Virtual- K. Choumas, D. Giatsios, A. F. Beldachi, T. Diallo, J. Zou, P. Legg,
isation (NFV) Release 3, 06 2022. J. Bartelt, J. K. Chaudhary, A. Betzler, J. J. Aleixendri, R. Gonzalez,
[144] O-RAN Alliance, “Ts: O-ran wg1 o-ran operations and maintenance and D. Simeonidou, “5g-xhaul: A novel wireless-optical sdn transport
interface specification,” 04 2020. network to support joint 5g backhaul and fronthaul services,” IEEE
[145] O-RAN Alliance, “O-ran wg6 cloud architecture and deployment Communications Magazine, vol. 57, no. 7, pp. 99–105, 2019.
scenarios for o-ran virtualized ran,” 10 2022.
[146] O-RAN Alliance, “Ts: O-ran wg6 o2 interface general aspects and [176] O-RAN Alliance, “Ts: O-ran open xhaul transport wg9 wdm-based
principles,” 03 2023. fronthaul transport v03.00,” 03 2023.
[147] J. Networks, “Unlock innovation and fuel business transformation with [177] S. Mondal and M. Ruffini, “Optical front/mid-haul with open access-
network slicing,” 2022. edge server deployment framework for sliced o-ran,” IEEE Transac-
[148] 3GPP, “Management and orchestration; architecture framework; 3gpp tions on Network and Service Management, vol. 19, no. 3, pp. 3202–
ts 28.533 r17,” 2022. 3219, 2022.
[149] ETSI, “Network functions virtualisation (nfv) release 4; management
and orchestration; architectural framework specification.” Group Spec- [178] Y. Rekhter and E. C. Rosen, “RFC4346 – BGP/MPLS IP Virtual Private
ification, 12 2022. Networks (VPNs),” tech. rep., Internet Engineering Task Force (IETF),
[150] C. Rotsos, D. King, A. Farshad, J. Bird, L. Fawcett, N. Georgalas, 02 2006.
M. Gunkel, K. Shiomoto, A. Wang, A. Mauthe, N. Race, and D. Hutchi-
[179] G. Dawra, K. Talaulikar, R. Raszuk, B. Decraene, S. Zhuang, and
son, “Network service orchestration standardization: A technology
J. Rabadan, “RFC 9252 – BGP Overlay Services Based on Segment
survey,” Computer Standards & Interfaces, vol. 54, pp. 203–215, 2017.
Routing over IPv6 (SRv6),” tech. rep., Internet Engineering Task Force
SI: Standardization SDN & NFV.
(IETF), July 2022.
[151] ETSI, “Network functions virtualisation (nfv) release 5; architectural
framework; report on nfv support for virtualisation of ran.” Group [180] R. Rokui, H. Yu, L. Deng, D. Allabaugh, M. Hemmati, and C. Janz,
Report, 2023. “A standards-based, model-driven solution for 5g transport slice au-
[152] ONAP, “Open network automation platform (onap).” tomation and assurance,” in 2020 6th IEEE Conference on Network
[153] ONAP, “Onap architecture overview white paper,” 2019. Softwarization (NetSoft), pp. 106–113, 2020.
[154] ONAP, “Onap architecture,” 2023.
[155] Keysight, “Ixnetwork test solution for oran fronthaul transport network; [181] 5G Americas, “Transport networks for 5g — 5g americas white paper,”
enable 5g success with robust xhaul transport infrastructure,” 2022. 08 2023. [Accessed 04-05-2024].
[156] M. Dryjaski, “O-RAN Deployment Scenarios.” RIMEDO Labs, July [182] ITU, “GSTR-TN5G - Transport network support of IMT-2020/5G,” 02
2023. 2018.
[157] A. Garcia-Saavedra and X. Costa-Prez, “O-ran: Disrupting the vir-
tualized ran ecosystem,” IEEE Communications Standards Magazine, [183] O-RAN Alliance, “Ts: O-ran open xhaul transport wg9; management
vol. 5, no. 4, pp. 96–103, 2021. interfaces for transport network elements v06.00,” 03 2023.
[158] 3GPP, “Technical specification group services and system aspects;
system architecture for the 5g system (5gs),” tech. rep., 3rd Generation [184] K. G. Szarkowicz, R. Roberts, J. Lucek, M. Boucadair, and L. M.
Partnership Project (3GPP), Mar. 2023. 3GPP TS 23.501 Release 18. Contreras, “A Realization of RFC XXXX Network Slices for 5G
Networks Using Current IP/MPLS Technologies,” Internet-Draft draft-
[159] 3GPP, “Management and orchestration concepts, use cases and require-
ments,” tech. rep., 3rd Generation Partnership Project (3GPP), 09 2018. ietf-teas-5g-ns-ip-mpls-02, Internet Engineering Task Force (IETF),
3GPP TS 28.530 Release 15, June 2017. Nov. 2023. Work in Progress.
[160] K. Park, S. Sung, H. Kim, and J.-i. Jung, “Technology trends and [185] A. Farrel, J. Drake, R. Rokui, S. Homma, K. Makhijani, L. M.
challenges in SDN and service assurance for end-to-end network Contreras, and J. Tantsura, “A Framework for Network Slices in
slicing,” Computer Networks, vol. 234, p. 109908, 2023. Networks Built from IETF Technologies,” Internet-Draft draft-ietf-teas-
[161] I. Badmus, A. Laghrissi, M. Matinmikko-Blue, and A. Pouttu, “End-to- ietf-network-slices-25, Internet Engineering Task Force (IETF), Sept.
end network slice architecture and distribution across 5g micro-operator 2023. Work in Progress.
leveraging multi-domain and multi-tenancy,” EURASIP Journal on
Wireless Communications and Networking, vol. 2021, 04 2021. [186] 3GPP, “5G; Management and orchestration; Provisioning,” tech. rep.,
[162] O-RAN Software Community, “Non-realtime ric (nnonrtric).,” 2024. 3rd Generation Partnership Project (3GPP), 08 2020. 3GPP TS 28.531
[163] “OSM #10 Ecosystem Day OSM for 5G O-RAN - PDF Free Down- Release 16.
load,” 2020. [187] GSMA, “Official document ng.127 - e2e network slicing architecture,
[164] 3GPP, “Nr and ng-ran overall description; stage-2,” tech. rep., 3rd whitepaper,” 06 2021.
Generation Partnership Project (3GPP), 01 2018. 3GPP TS 38.300
version 16.4.0 Release 16. [188] N. Aryal, F. Ghaffari, E. Bertin, and N. Crespi, “Moving towards
[165] “O-RAN SC Projects NONRTRIC, OSC,” 2024. open radio access networks with blockchain technologies,” in 2023
[166] “E2E Network Slicing Use Case onap master documentation,” 2024. 5th Conference on Blockchain Research & Applications for Innovative
[167] M. S. Dimitris Mavrakis, “Open ran: Market reality and misconcep- Networks and Services (BRAINS), pp. 1–9, 2023.
tions.” ABIresearch and Qualcomm, 06 2020.
[168] C. SA, “Open ran , an interoperable, innovative, and sovereign archi- [189] O-RAN Alliance, “Ts: O-ran wg1 use cases analysis report v12.00,”
tecture,” 01 2023. 10 2023.
[169] C. Filsfils, K. Talaulikar, D. Voyer, A. Bogdanov, and P. Mattes, [190] J. Groen, S. DOro, U. Demir, L. Bonati, M. Polese, T. Melodia, and
“RFC 9256 - Segment Routing Policy Architecture,” tech. rep., Internet K. Chowdhury, “Implementing and Evaluating Security in O-RAN:
Engineering Task Force (IETF), July 2022. Interfaces, Intelligence, and Platforms,” Dec. 2023. arXiv:2304.11125
[cs, eess].
 43

K HURSHID A LAM received his [Link]. degree in WALID S AAD (Fellow, IEEE) received the Ph.D. de-
Computer and Communication Engineering from gree from the University of Oslo, Norway, in 2010.
IIUC, Bangladesh, in 2008. He attained his M. He is currently a Professor with the Department
Sc. degree in Applied Computer Science from the of Electrical and Computer Engineering, Virginia
University of Kaiserslautern (RPTU) in 2018. Since Tech, where he leads the Network Science, Wireless,
then, he has been a researcher with the Intelligent and Security Laboratory. He is also the Next-G
Networks research group at the German Research Wireless Faculty Lead with Virginia Techs Innova-
Center for Artificial Intelligence GmbH (DFKI). tion Campus. His research interests include wireless
From 2010 to 2012, he worked as a teaching as- networks (5G/6G/beyond), machine learning, game
sistant in Pokhara University, Nepal. From 2012 to theory, security, UAVs, semantic communications,
2015, he worked as an IT consultant for multiple cyberphysical systems, and network science. He is
companies in Doha, Qatar. His research interests include industrial wireless also the recipient of the NSF CAREER Award in 2013, the AFOSR Summer
communication, software defined networking, radio access network archi- Faculty Fellowship in 2014, and the Young Investigator Award from the Office
tecture, radio resource management, artificial intelligence, network function of Naval Research in 2015. He was the (co)author of 11 conference best paper
virtualization, and network slicing. awards at IEEE WiOpt in 2009, ICIMP in 2010, IEEE WCNC in 2012, IEEE
PIMRC in 2015, IEEE SmartGridComm in 2015, EuCNC in 2017, IEEE
M OHAMMED A SIF H ABIBI received his [Link]. GLOBECOM in 2018 and 2020, IFIP NTMS in 2019, and IEEE ICC in 2020
degree in Telecommunications Engineering from and 2022. He is the recipient of the 2015 and 2022 Fred W. Ellersick Prize
Kabul University, Afghanistan, in 2011. He ob- from the IEEE Communications Society, the IEEE Communications Society
tained his [Link]. degree in Systems Engineering Marconi Prize Award in 2023, and the IEEE Communications Society Award
and Informatics from the Czech University of Life for Advances in Communication in 2023. He was also a coauthor of the
Sciences, Czech Republic, in 2016. Since January papers that received the IEEE Communications Society Young Author Best
2017, he has been working as a research fellow Paper Award in 2019, 2021, and 2023. Other recognitions include the 2017
and Ph.D. candidate at the Division of Wireless IEEE ComSoc Best Young Professional in Academia Award, the 2018 IEEE
Communications and Radio Positioning, University ComSoc Radio Communications Committee Early Achievement Award, and
of Kaiserslautern (RPTU), Germany. From 2011 to the 2019 IEEE ComSoc Communication Theory Technical Committee Early
2014, he worked as a radio access network engineer Achievement Award. From 2015 to 2017, he was named the Stephen O.
for HUAWEI. His main research interests include network slicing, network Lane Junior Faculty Fellow at Virginia Tech and, in 2017, he was named
function virtualization, resource allocation, machine learning, and radio access the College of Engineering Faculty Fellow. He received the Deans Award for
network architecture. Research Excellence from Virginia Tech in 2019. He has been annually listed
in the Clarivate Web of Science Highly Cited Researcher List since 2019. He
currently serves as an Area Editor for the IEEE Transactions on Network
M ATTHIAS TAMMEN received the [Link]. degree Science and Engineering and the IEEE Transactions on Communications.
in media and communication technology from the He is the Editor-in-Chief for the IEEE Transactions on Machine Learning
University of Kaiserslautern (RPTU) in 2019. Since in Communications and Networking. He was also an IEEE Distinguished
then, he has been working as a Research Fellow Lecturer from 2019 to 2020.
at the Division of Wireless Communications and
Radio Positioning (WiCoN), Department of Electri-
cal Engineering (EIT), University of Kaiserslautern
(RPTU). His main research interests include private
campus networks, nomadic networks, media tech-
nology, and video transmission in 5G and beyond
mobile communication networks.

D ENNIS K RUMMACKER received the [Link]. degree

in Electrical and Computer Engineering from the
University of Kaiserslautern (RPTU) in 2016. Since
2016, he has been a Researcher at the German
Research Center for Articial Intelligence GmbH
(DFKI) in the Department of Intelligent Networks,
where he is coordinating the research areas regarding
Industrial Communication and Intelligent Infrastruc-
tures. His main research interests include Network
Management and Orchestration, Softwarization, Vir-
tualization, Software-defined Network (SDN), and
Network Function Virtualization (NFV).
 44

M ARCO D I R ENZO (Fellow, IEEE) received the X AVIER C OSTA -P ÉREZ (M’06–SM’18) is Head
Laurea (cum laude) and Ph.D. degrees in electrical of 6G Networks R&D at NEC Laboratories Eu-
engineering from the University of LAquila, Italy, rope, Scientific Director at the i2Cat R&D Center,
in 2003 and 2007, respectively, and the Habilitation and Research Professor at ICREA. His team con-
Diriger des Recherches (Doctor of Science) degree tributes to products roadmap evolution as well as to
from University Paris-Sud (currently Paris-Saclay European Commission R&D collaborative projects
University), France, in 2013. Currently, he is a and received several awards for successful technol-
CNRS Research Director (Professor) and the Head ogy transfers. In addition, the team contributes to
of the Intelligent Physical Communications group related standardization bodies: 3GPP, ETSI NFV,
in the Laboratory of Signals and Systems (L2S) at ETSI MEC, and IETF. Xavier has been a 5GPPP
Paris-Saclay University CNRS and CentraleSupelec, Technology Board member, served on the Program
Paris, France. Also, he is an elected member of the L2S Board Council and Committee of several conferences (including IEEE Greencom, WCNC, and
a member of the L2S Management Committee, and is a Member of the INFOCOM), published at top research venues, and holds several patents.
Admission and Evaluation Committee of the Ph.D. School on Information He also serves as Editor of IEEE Transactions on Mobile Computing and
and Communication Technologies, Paris-Saclay University. He is a Founding Transactions on Communications journals. He received both his [Link]. and
Member and the Academic Vice Chair of the Industry Specification Group Ph.D. degrees in Telecommunications from the Polytechnic University of
(ISG) on Reconfigurable Intelligent Surfaces (RIS) within the European Catalonia (UPC) in Barcelona and was the recipient of a national award for
Telecommunications Standards Institute (ETSI), where he served as the his Ph.D. thesis.
Rapporteur for the work item on communication models, channel models,
and evaluation methodologies. He is a Fellow of the IEEE, IET, EURASIP, M ÉROUANE D EBBAH (Fellow, IEEE) is Professor
and AAIA; an Academician of AIIA; an Ordinary Member of the European at Khalifa University of Science and Technology
Academy of Sciences and Arts, an Ordinary Member of the Academia in Abu Dhabi. He received the [Link]. and Ph.D.
Europaea; an Ambassador of the European Association on Antennas and degrees from the Ecole Normale Suprieure Paris-
Propagation; and a Highly Cited Researcher. Also, he holds the 2023 France- Saclay, France. He was with Motorola Labs, Saclay,
Nokia Chair of Excellence in ICT, he holds the Tan Chin Tuan Exchange France, from 1999 to 2002, and then with the
Fellowship in Engineering at Nanyang Technological University (Singapore), Vienna Research Center for Telecommunications,
and he was a Fulbright Fellow at City University of New York (USA), a Vienna, Austria, until 2003. From 2003 to 2007, he
Nokia Foundation Visiting Professor (Finland), and a Royal Academy of was an Assistant Professor with the Mobile Com-
Engineering Distinguished Visiting Fellow (UK). His recent research awards munications Department, Institut Eurecom, Sophia
include the 2021 EURASIP Best Paper Award, the 2022 IEEE COMSOC Antipolis, France. Since 2007, he is Full Professor
Outstanding Paper Award, the 2022 Michel Monpetit Prize conferred by at CentraleSupelec, Gif-sur-Yvette, France. From 2007 to 2014, he was the
the French Academy of Sciences, the 2023 EURASIP Best Paper Award, Director of the Alcatel-Lucent Chair on Flexible Radio. From 2014 to 2021,
the 2023 IEEE ICC Best Paper Award, the 2023 IEEE COMSOC Fred W. he was Vice-President of the Huawei France Research Center. He was jointly
Ellersick Prize, the 2023 IEEE COMSOC Heinrich Hertz Award, the 2023 the director of the Mathematical and Algorithmic Sciences Lab as well as the
IEEE VTS James Evans Avant Garde Award, and the 2023 IEEE COMSOC director of the Lagrange Mathematical and Computing Research Center. From
Technical Recognition Award from the Signal Processing and Computing for 2021 to 2023, he was Chief Researcher at the Technology Innovation Institute
Communications Technical Committee. He served as the Editor-in-Chief of and leading the AI & Digital Science Research centers at the Technology
IEEE Communications Letters during the period 2019-2023, and he is now Innovation Institute. He was also Adjunct Professor with the Department
serving in the Advisory Board. He is currently serving as a Voting Member of Machine Learning at the Mohamed Bin Zayed University of Artificial
of the Fellow Evaluation Standing Committee and as the Director of Journals Intelligence in Abu Dhabi. Since 2023, he is Professor at at Khalifa University
of the IEEE Communications Society. of Science and Technology in Abu Dhabi and founding director of the
6G center. He has managed 8 EU projects and more than 24 national and
T OMMASO M ELODIA (Fellow, IEEE) received the international projects. His research interests lie in fundamental mathematics,
Ph.D. degree in electrical and computer engineering algorithms, statistics, information, and communication sciences research. He
from the Georgia Institute of Technology in 2007. holds more than 40 patents. He is an IEEE Fellow, a WWRF Fellow, a
He is the William Lincoln Smith Chair Professor Eurasip Fellow, an AAIA Fellow, an Institut Louis Bachelier Fellow and a
with the Department of Electrical and Computer Membre mrite SEE. He was a recipient of the ERC Grant MORE (Advanced
Engineering, Northeastern University, Boston. His Mathematical Tools for Complex Network Engineering) from 2012 to 2017.
research on modeling, optimization, and experimen- He was a recipient of the Mario Boella Award in 2005, the IEEE Glavieux
tal evaluation of Internet of Things and wireless Prize Award in 2011, the Qualcomm Innovation Prize Award in 2012, the 2019
networked systems has been funded by the National IEEE Radio Communications Committee Technical Recognition Award and
Science Foundation, the Air Force Research Labora- the 2020 SEE Blondel Medal. He received more than 30 best paper awards,
tory, the Office of Naval Research, DARPA, and the among which the 2007 IEEE GLOBECOM Best Paper Award, the Wi-Opt
Army Research Laboratory. He is also the Founding Director of the Institute 2009 Best Paper Award, the 2010 Newcom++ Best Paper Award, the WUN
for the Wireless Internet of Things and the Director of Research for the CogCom Best Paper 2012 and 2013 Award, the 2014 WCNC Best Paper
PAWR Project Office. He is a recipient of the National Science Foundation Award, the 2015 ICC Best Paper Award, the 2015 IEEE Communications
CAREER Award. He has served as an Associate Editor for IEEE Transactions Society Leonard G. Abraham Prize, the 2015 IEEE Communications Society
on Wireless Communications, IEEE Transactions on Mobile Computing, and Fred W. Ellersick Prize, the 2016 IEEE Communications Society Best Tutorial
Computer Networks (Elsevier). He has served as the Technical Program Paper Award, the 2016 European Wireless Best Paper Award, the 2017 Eurasip
Committee Chair for IEEE Infocom 2018, and the General Chair for IEEE Best Paper Award, the 2018 IEEE Marconi Prize Paper Award, the 2019 IEEE
SECON 2019, ACM Nanocom 2019, and ACM WUWnet 2014. He is the Communications Society Young Author Best Paper Award, the 2021 Eurasip
Director of Research for the Platforms for Advanced Wireless Research Best Paper Award, the 2021 IEEE Marconi Prize Paper Award, the 2022 IEEE
(PAWR) Project Office, a $100M publicprivate partnership to establish 4 city- Communications Society Outstanding Paper Award, the 2022 ICC Best paper
scale platforms for wireless research to advance the U.S. wireless ecosystem Award, the 2022 IEEE GLOBECOM Best Paper Award, 2022 IEEE TAOS
in years to come. He is a Distinguished Member of the ACM. TC Best GCSN Paper Award, the 2022 IEEE International Conference on
Metaverse Best Paper Award, the 2023 IEEE Communications Society Fred
W. Ellersick Prize, the 2023 ICC best paper award as well as the Valuetools
2007, Valuetools 2008, CrownCom 2009, Valuetools 2012, SAM 2014, and
2017 IEEE Sweden VT-COM-IT Joint Chapter best student paper awards. He
is an Associate Editor-in-Chief of the journal Random Matrix: Theory and
Applications. He was an Associate Area Editor and Senior Area Editor of the
IEEE TRANSACTIONS ON SIGNAL PROCESSING from 2011 to 2013 and
from 2013 to 2014, respectively. From 2021 to 2022, he served as an IEEE
Signal Processing Society Distinguished Industry Speaker.
 45

A SHUTOSH D UTTA (Fellow, IEEE) is currently

Chief 5G Strategist and JHU/APL Sabbatical Fellow
at Johns Hopkins University Applied Physics Labs
(JHU/APL), USA. He also serves as Chair for Elec-
trical and Computer Engineering for Engineering
Professional Program at JHU. His career, spanning
more than 30 years, includes Director of Technology
Security and Lead Member of Technical Staff at
AT&T, CTO of Wireless at a Cybersecurity com-
pany NIKSUN, Inc., Senior Scientist in Telcordia
Research, Director of Central Research Facility at
Columbia University, adjunct faculty at NJIT, and Computer Engineer with
TATA Motors. Ashutosh is author of more than 100 technical papers and 31
issued patents. Ashutosh is co-author of the book, titled, Mobility Protocols
and Handover Optimization: Design, Evaluation and Application published by
IEEE and John & Wiley. As a Technical Leader in 5G and security, Ashutosh
has been serving as the founding Co-Chair for the IEEE Future Networks
Initiative that focuses on 5G standardization, education, publications, testbed,
and roadmap activities. Ashutosh is IEEE Communications Society’s Dis-
tinguished Lecturer for 2017-2020 and as an ACM Distinguished Speaker
(2020-2022). Ashutosh currently serves as the founding co-chair for IEEE
Future Networks Initiative and Member-At-Large for IEEE Communications
Society. He co-founded the IEEE STEM conference (ISEC) and helped to
implement EPICS (Engineering Projects in Community Service) projects in
several high schools. Ashutosh has served as the general Co-Chair for the
IEEE STEM conference for the last 10 years. Ashutosh served as the Director
of Industry Outreach for IEEE Communications Society from 2014-2019. He
was recipient of 2009 IEEE MGA Leadership award. Ashutosh is recipient of
IEEE-USAs 2010 Professional Leadership Award, 2022 IEEE-USA George
F. McClure Citation of Honor. He also received 2022 IEEE North American
Region Exceptional Service Award. Ashutosh served as Member-At-Large
for IEEE Communications Society for 2020-2022. Ashutosh has served as the
founding Co-Chair for the premier IEEE 5G World Forums and has organized
85 5G World Summits around the world. Ashutosh currently serves as the
Chair for IEEE Industry Connections O-RAN activities and IPv6. Ashutosh is
a Distinguished Alumnus of NIT Rourkela with BS in Electrical Engineering,
MS in Computer Science from NJIT, and Ph.D. in Electrical Engineering from
Columbia University under the supervision of Prof. Henning Schulzrinne.
Ashutosh is a Fellow of IEEE and Distinguished member ACM.

H ANS D. S CHOTTEN (S’93-M’97) received the

Ph.D. degree from the RWTH Aachen University
of Technology, Germany, in 1997. From 1999 to
2003, he worked for Ericsson. From 2003 to 2007,
he worked for Qualcomm. He became manager of a
R&D group, Research Coordinator for Qualcomm
Europe, and Director for Technical Standards. In
2007, he accepted the offer to become a full pro-
fessor at the University of Kaiserslautern (RPTU).
In 2012, he - in addition - became the scientific
director of the German Research Center for Artificial
Intelligence (DFKI) and head of the Department for Intelligent Networks.
Professor Schotten served as dean of the Department of Electrical Engineering
of the Rheinland-Pfälzische Technische Universität Kaiserslautern-Landau
from 2013 until 2017. Since 2018, he is chairman of the German Society
for Information Technology and a member of the Supervisory Board of the
VDE. He is the author of more than 200 papers and participated in 30+
European and national collaborative research projects.