Received 1 May 2024; revised 21 June 2024; accepted 15 July 2024.

Date of publication 18 July 2024; date of current version 8 January 2025.

Digital Object Identifier 10.1109/OJCOMS.2024.3430823

Open RAN: A Concise Overview

MOHAMAD SAALIM WANI 1 , MATHIAS KRETSCHMER 1 , BERND SCHRÖDER 2,

ANDREAS GREBE 3 (Member, IEEE), AND MICHAEL RADEMACHER 4,5

1 Department of Cooperation Systems, Fraunhofer FIT, 53757 Sankt Augustin, Germany
2 Department of Industrial Communication & Data Research, brown-iposs GmbH, 53229 Bonn, Germany
3 Institute on Computer and Communication Technology, Technische Hochschule Köln, 50679 Cologne, Germany
4 Department of Computer Science, Hochschule Bonn-Rhein-Sieg, 53757 Sankt Augustin, Germany
5 Department of Cyber Analysis & Defense, Fraunhofer FKIE, 53177 Bonn, Germany

CORRESPONDING AUTHOR: M. S. WANI (e-mail: [Link]@[Link])

This work was supported by the Federal Ministry for Digital and Transport of the Federal Republic of Germany (Förderkennzeichen, IndustrieStadtpark:
5G-Anwendungen im Projektgebiet IndustrieStadtpark Troisdorf) under Grant 165GU054B.

ABSTRACT Open RAN has emerged as a transformative approach in the evolution of cellular networks,
addressing challenges posed by modern applications and high network density. By leveraging disaggregated,
virtualized, and software-based elements interconnected through open standardized interfaces, Open RAN
introduces agility, cost-effectiveness, and enhanced competition in the Radio Access Network (RAN)
domain. The Open RAN paradigm, driven by the O-RAN Alliance specifications, is set to transform the
telecom ecosystem. Despite extensive technical literature, there is a lack of succinct summaries for industry
professionals, researchers, and policymakers. This paper addresses this gap by providing a concise, yet
comprehensive overview of Open RAN. Compared to previous work, our approach introduces Open RAN
by gradually splitting up different components known from previous RAN architectures. We believe that
this approach leads to a better understanding for people already familiar with the general concept of mobile
communication networks. Building upon this general understanding of Open RAN, we introduce key
architectural principles, interfaces, components and use-cases. Moreover, this work investigates potential
security implications associated with adopting Open RAN architecture, emphasizing the necessity of robust
network protection measures.

INDEX TERMS Open RAN, 5G, security, mobile networks.

I. INTRODUCTION Recently, the Core Network has seen significant changes

ELLULAR networks are becoming ever more complex
C with the advent of innovative technologies such as
Network Slicing [1], [2], Massive Multiple-Input Multiple-
with the advent of Software Defined Networking (SDN) and
Network Functions Virtualization (NFV) [8], [9], enabling
the operators to build a more agile and less expensive
Output (MIMO) [3], Multi-Band and Multi-Technology core [10]. However, the Radio Access Network (RAN)
support, Millimeter wave, and Machine Learning-based which involves major costs in building mobile networks, has
developments [4], [5], [6]. Additionally, the expected surge remained relatively untouched in terms of achieving cost-
in both data volume and diversity further contributes to effectiveness, despite experiencing notable advancements. It
the growing complexity of these networks [7]. Network is estimated that approximately 65–70% of the total cost of
operators are under pressure to keep up with the market owning and operating a mobile network is attributed to the
trends by encompassing newer technologies, continuously RAN [7]. Thus, there is a clear and pressing need for a
upgrading and maintaining their networks while keeping the similar revolution in the RAN domain to establish a well-
cost per bit as low as possible. To reduce expenses and balanced and economically sustainable network ecosystem.
simultaneously roll out more advanced technology solutions, Most RAN deployments worldwide still rely on monolithic
mobile operators have begun to investigate new revenue- integrated solutions based on proprietary hardware and soft-
generating services. ware. These systems typically feature undisclosed interfaces,


c 2024 The Authors. This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 License.
For more information, see [Link]
VOLUME 6, 2025 13
WANI et al.: OPEN RAN: A CONCISE OVERVIEW

leading to vendor lock-in where operators must continue One comprehensive survey paper [14] on Open RAN
with the same vendor’s equipment throughout their network development covers a wide range of topics, including its evo-
deployment. This dependency on specific vendors poses lution, state-of-the-art technologies, related projects, ongoing
supply chain risks; disruptions or stagnations in procurement activities, and future research directions. It also delves
can render services inoperable. into the O-RAN architecture components and discusses
The RAN equipment domain is currently dominated by security in the O-RAN architecture. Another in-depth tutorial
a few vendors [11] and seen by the network operators paper [15] explores O-RAN specifications, describing its
as black boxes lacking transparency. These systems often architecture, design principles, and interfaces, and addressing
lack advanced data-driven optimization and closed-loop innovations and challenges, including AI and ML work-
control capabilities needed to manage complex, heteroge- flows, security threats, and standardization issues. A third
neous networks effectively. Even vendor-specific closed-loop tutorial [10] covers topics such as O-RAN architecture,
optimization techniques provide minimal operator control, use cases, deployment aspects, open-source projects, open
impacting service quality for customers. issues, challenges, and future research directions, with a
In order to overcome these limitations, research and brief discussion on O-RAN security. Other research articles
standardization initiatives have envisioned Open RAN as focus on specific facets of Open RAN, such as machine
the RAN of the future. Open RAN deployments are built learning aspects [16], security concerns [11], [12], [17], [18],
on disaggregated, virtualized, software-based elements that [19], [20], [21], capabilities and limitations [22], open-source
are linked by open standardized interfaces and could be software suitable for deploying Open RAN [23], [24], and
orchestrated using intelligent controllers. It envisions to bring use-cases of Open RAN [25], [26], [27], [28], [29], [30],
cloud-scale economics and introduce agility in the RAN. [31], [32], [33], [34], [35], [36], [37], [38]. Additionally,
Virtualization and disaggregation allow for flexible deploy- companies involved in Open RAN have released numerous
ments based on cloud-native concepts. This improves the white papers on the subject [39], [40], [41], [42], [43], [44],
RAN’s resilience and reconfigurability. Open standardized [45], [46], [47], [48], [49].
interfaces would allow RAN deployments to be multi-vendor Despite these extensive studies, there is a lack of a
and allow small-scale vendors to enter the RAN development short, concise introduction aimed at readers with a general
market, enabling a more competitive and vibrant supplier understanding of mobile networks, in particular providing
system. Intelligent controllers leveraging open interfaces a comprehensive overview of the security landscape. While
can significantly enhance network automation, making RAN the existing survey papers focus on O-RAN risks, they do
optimization more efficient, self-driven, cost-effective, and not compare these risks with those of traditional RAN. To
accessible for network operators. gain a broader understanding of O-RAN risks, it is essential
In order to benefit most from this work, it is important to contrast them with those associated with traditional RAN,
to distinguish between the following terms: Open RAN, thus broadening the perspective offered by the existing
O-RAN, and OpenRAN. The term Open RAN refers to the survey papers.
movement in mobile networks towards building a disag- This article aims to address these gaps by offering a
gregated RAN functionality by employing open interfaces concise yet comprehensive overview of Open RAN, sys-
between its elements. O-RAN, the second term, is affiliated tematically introducing the O-RAN concept and its security
with the O-RAN Alliance, the organization responsible aspects. Unlike most papers that present O-RAN without
for the development of the O-RAN architecture [12]. The contextualizing it within the 5G RAN framework, this paper
architecture developed by O-RAN Alliance serves as the demystifies Open RAN by illustrating how additional compo-
fundamental framework for this paper. In contrast, the term nents integrate with the 5G architecture to form the O-RAN
OpenRAN (written as one word) is associated with a project architecture. We also provide information about security
group established by TIP (Telecom Infra Project1 ) but holds protocols implemented in each new O-RAN interface, which
no relevance in the context of this work. is often missing in the literature and the aforementioned
survey papers. Regarding security, we first present the
II. RELATED WORK security risks of the O-RAN architecture, including those
Open RAN has garnered significant attention in the mobile common to 5G RAN, then briefly compare O-RAN with
networks industry in recent years, with numerous private 5G RAN in terms of security, and finally provide insights
companies and research groups actively advancing the idea. into risks unique to O-RAN due to the introduction of novel
The rising interest in Open RAN has facilitated numerous components and interfaces.
real-world deployments, which continue to expand over
time [13]. Moreover, the growing interest in Open RAN III. BACKGROUND
has also resulted in several research articles. Some of these A. MOBILE NETWORK ARCHITECTURE
publications provide detailed tutorials on various aspects of A mobile network architecture can be divided into three
Open RAN. components: User Equipment (UE)s, the RAN, and the Core
Network as shown in Fig. 1. Those three main components
1 [Link] of a mobile network are briefly described below.

14 VOLUME 6, 2025
 Virtualized-RAN (vRAN) is an enhanced version of
C-RAN. In vRAN, proprietary BBU hardware is replaced
with COTS servers, and software is decoupled from hardware
using NFV principles. This enables network functions to run
FIGURE 1. A simple overview about the basic components of a mobile network.
This overview will be further specified in the following.
on virtual machines or containers on top of COTS hardware,
although the interface between COTS-based BBUs and RRUs
remains proprietary [51]. Virtualizing BBU pools allows for
resource sharing among multiple sites, potentially reducing
data processing needs by approximately 50% [14]. However,
the increased network complexity makes resource sharing
FIGURE 2. An overview of the evolution of the RAN in mobile networks.
among radio nodes challenging.

IV. OPEN RAN

The UE is a device the end-user uses to communicate
The transition from vRAN to Open RAN involves standardiz-
with the mobile network (e.g., a smartphone).Typically, it is
ing interfaces between RAN components while incorporating
authenticated into the network using a Subscriber Identity
cloud-based aspects from vRAN. One of the key interfaces
Module (SIM) Card.
standardized/opened by Open RAN is the Open FH between
The RAN consists of Base Stations (BSs) and is used
RRU and BBU [51]. This framework also enables the
to facilitate communication between the UE and the core
separation of the traditional Baseband Unit into Distributed
network via radio connectivity. The main task of the RAN
Unit (DU) and Central Unit (CU). By adopting standardized
is radio resource management. Each BS typically includes a
interfaces, Open RAN promotes multi-vendor deployments,
Radio Unit (RU) with RF circuitry for signal transmission
empowering operators to mix and match components such
and reception, and a Baseband Unit (BBU) which handles
as RUs, DUs, and CUs to tailor solutions for diverse
computational tasks like radio management and resource
deployment scenarios [40]. Additionally, Open RAN sup-
allocation.
ports replacing proprietary RRU hardware with COTS-based
The Core Network is the central component of a mobile
Software Defined Radio (SDR) [51]. Moreover, it enables
network, responsible for a wide range of functions, including
decoupling the RAN control plane from the user plane
access management, mobility support, and the provision of
and integrating data-driven intelligence to automate complex
essential services such as interconnectivity.
RAN management tasks [7].

B. EVOLUTION OF THE RAN A. KEY OPEN RAN GROUPS

Over the past three decades, base stations have transformed The following section briefly introduces the working of two
from being monolithic devices with proprietary hardware, main groups leading the Open RAN movement.
software, and interfaces to disaggregated instanciations using The O-RAN Alliance was founded in 2018 with the
Commercial Off-the-Shelf (COTS) hardware. The following intention of promoting openness and intelligence in the
section briefly explains various types of Base Stations (BSs). RAN after the two organizations C-RAN alliance and the
Decentralized RAN (D-RAN): In the D-RAN concept, both X-RAN forum joined forces [52]. Since its launch, the O-
the RU and BBU are co-located at the cell site, with all RAN alliance has quickly scaled up and currently has more
processing done locally. The BBU is typically placed in than 300 members and contributors. The major goal of the
an air-conditioned shelter, while the RU (or Remote Radio O-RAN alliance is to standardize an architecture and set of
Unit (RRU) when near the antenna) is either in the same interfaces for the Open RAN paradigm. The alliance defines
room or at the top of the tower. The BBU functions as the O-RAN architecture and specifications to extend the
proprietary software on specialized hardware, and the RRU RAN standards to include openness and intelligence. It also
is also proprietary. As the number of UEs increases, more focuses on developing reference open-source software and
BS are required, raising costs for space and cooling. hardware for various O-RAN components. Additionally, it
Centralized-RAN (C-RAN): To reduce overall expendi- provides guidance to the members of the alliance to test
tures, the C-RAN architecture was introduced. In C-RAN, the inter-working of O-RAN solutions they develop. The
BBUs from several base stations are centralized, mini- O-RAN alliance is more focused on 4G and 5G networks
mizing site rental and Operation and Maintenance (OAM) compared to Telocom Infra Project (TIP) which also covers
efforts [50]. New RRUs can be added without setting up new aspects beyond the RAN [51].
BBU at the cell site, thus addressing growing traffic demands The specification tasks of the O-RAN Alliance are divided
without significantly increasing costs. Similar to D-RAN, the into several Working Groups (WG)s as shown in Table 2. As
BBU, RRU, and Fronthaul (FH) interface remain proprietary. discussed earlier, this paper is focused towards the O-RAN
However, C-RAN’s limitations include high FH capacity architecture.
requirements, single points of failure, and vendor lock-in, TIPs was founded in 2016 with the objective of providing
making it suitable primarily for urban scenarios. universal Internet access. It follows an engineering-oriented

VOLUME 6, 2025 15
WANI et al.: OPEN RAN: A CONCISE OVERVIEW

TABLE 1. Comparison of different types of RAN.

TABLE 2. O-RAN working groups and their main focus.

Disaggregation allows splitting the BS into several func-
tional units. In the case of 5G networks, the BS can be
split into three logical units, RU, DU and CU. The CU can
be additionally separated into two logical nodes, with one
handling the control plane (CU-CP) and the other managing
the user plane (CU-UP). Such a logical separation facilitates
the deployment of diverse functionalities across various
network locations and hardware platforms.
Open Interfaces refer to the standardized interfaces
between different components of a RAN, which allow for
interoperability between equipment from different vendors.
This enables the mixing and matching of RAN equipment
from various vendors [54], thereby combining the most
suitable equipment for a given deployment scenario, taking
into account factors such as performance, required features,
schedule, and costs.
approach with a collaborative methodology that is focused The RAN Intelligent Controller (RIC) is a key element
on building and deploying global telecom network infras- of the O-RAN architecture that provides a platform for
tructure. TIP is more focused on deployments and execution optimization of the RAN elements and resources. The RIC
of Open RAN than designing its specifications. It promotes comes in two forms: Non-Real-Time RIC (Non-RT RIC),
plugfests and live deployments in the field. It is also involved designed for non-real-time control and optimization, and
in training and the implementation of Open RAN solutions the Near-Real-Time RIC, tailored for near-real-time control
around the world. and optimization. Both RICs provide a platform to host
To enhance their collaboration in the development of third-party applications that could be powered by Machine
interoperable Open Radio Access Network solutions, the Learning (ML)/Artificial Intelligence (AI) to orchestrate the
O-RAN Alliance and TIP have announced a liaison RAN for a given use case [55]. These apps serve as use-
agreement [53]. This agreement will facilitate referencing, case tailored algorithms for performing tasks such as Radio
information exchange, and validation activities between the Resource Management (RRM) and functionalities associated
two organizations, thereby reinforcing their shared commit- with Self-Organizing Network (SON). The infusion of the
ment to the Open RAN cause. external controller in RAN can be considered to efficiently
manage and orchestrate network services in an intelligent
manner with reduced cost [10].
B. O-RAN KEY ARCHITECTURAL PRINCIPLES
Overall, the Key architectural principles of Open RAN can be
identified as Virtualization, Disaggregation, Open Interfaces, C. 5G RAN ARCHITECTURE
and Intelligence, which are briefly discussed below. The O-RAN architecture designed by the O-RAN alliance
Virtualization of the RAN refers to the concept of is built on top of the NG-RAN architecture proposed by the
decoupling the hardware and software used to build the 3rd Generation Partnership Project (3GPP). Therefore, we
RAN. Virtualization makes it possible to run the RAN first discuss the NG-RAN architecture and then follow with
functionality as (open) software running on generic hardware the O-RAN architecture.
platforms, rather than using proprietary hardware. One of the NG-RAN is the “new generation” RAN for 5G [50]. The
benefits of virtualization is that it allows companies to use NG-RAN configuration can support Non-Stand-Alone (NSA)
best-of-breed and cost-efficient hardware. Secondly, it will and Stand-Alone (SA) modes. In NG-RAN with 5G SA, the
enable companies to address changing network demands by 5G Next Generation Next Generation NodeB (gNB) connects
scaling the resources elastically. Virtualization also holds the directly to the 5G Core (5GC), as shown in Fig. 3. The gNB
potential to simplify the orchestration of the RAN through connects to the core network via the NG interface and to the
layered abstraction, thereby contributing to a significant other gNBs using the Xn interface The Uu interface exists
reduction in operational costs. between an UE and the gNB [56].

16 VOLUME 6, 2025
FIGURE 3. A basic 5G Stand-Alone network architecture. FIGURE 5. NG-RAN split options [59].

FIGURE 6. NG-RAN gNB-CU further split into gNB-CU-CP and gNB-CU-UP.

FIGURE 4. NG RAN split into gNB-DU and gNB-CU.

the DU and the CU brings better scalability according to

In NSA mode, both 4G and 5G base stations are used to User Plane traffic load.
exchange traffic with the UE and connect to the same core CU-UP Split: The 3GPP specifications further allow the
(Evolved Packet Core (EPC)). Note that the scope of this split of the gNB-CU (introduced in Fig. 4) into gNB-
paper focuses on the adoption of 5G SA architectures within CU-Control Plane (gNB-CU-CP) and gNB-CU-User Plane
the O-RAN architecture. (gNB-CU-UP), connected by the E1 logical interface, as
In the 5G RAN architecture, the gNB can disaggre- shown in Fig. 6. The gNB-CU-CP hosts RRC and the control
gated into three main building blocks: RU, DU, and CU. plane part of the PDCP protocol, while the gNB-CU-UP
Traditionally, the base station comprises of RU and BBU, hosts the SDAP and the user plane part of the PDCP
but this division further separates BBU into DU and protocol. As shown in Fig. 6, gNB-CU-CP terminates the
CU. This disaggregation divides base station functionality control plane part of the F1 interface towards the gNB-DU,
into three logical components, each hosting parts of the while gNB-CU-UP terminates the user plane part of the
5G protocol stack. Additionally, CU can be partitioned F1 interface towards the gNB-DU. This further split allows
into CU-CP (Control Plane) and CU-UP (User Plane), the gNB to be composed of one gNB-CU-CP, one or more
further segmenting the 5G gNB protocol stack layers. The gNB-CU-UPs, and one or more gNB-DUs [50].
subsequent section provides a brief explanation of this 5G By adopting this split, mobile network operators gain the
RAN split architecture. advantage of independently scaling the user plane without
CU-DU Split: The 3GPP specifications [17] supports affecting the control plane, providing them with enhanced
the possibility of splitting a gNB (introduced in Fig. 3) flexibility in network dimensioning [17]. Moreover, this seg-
into a gNB-Central Unit (gNB-CU) and gNB-Distributed regation allows for customizable user plane configurations,
Units (gNB-DUs) [50], often referred to as CU and DU, catering to specific application requirements and reducing
respectively. These logical nodes are connected via the F1 data transport delays to meet higher latency demands.
interface. The functional division between CU and DU is DU-RU Split: The 3GPP specifications have not standard-
termed as the horizontal functional split [14]. Fig. 4, shows ized the RU functionality, i.e., they have not standardized
the NG-RAN architecture, with the CU-DU split visible for a split between the DU and the RU, its implementation is
the gNB. Note that, regardless of whether a gNB is split into left to the vendors. For instance, a split option supported by
several units or not, it should always appear and behave to the O-RAN alliance is 7.2x, which involves using Split 7
all other gNBs and the 5GC‘ as a single unit. between the RU and the DU, and Split 2 between the CU
In order to distribute functionality between gNB-CU and and the DU. Similarly, the Small Cell Forum supports split
gNB-DU, 3GPP evaluated several optional splits as shown option 6 as the Lower Layer Split (LLS) Split.
in Fig. 5. Each of these functional splits offers a trade-
off [57], [58]. They finally standardized the split option 2 V. O-RAN: ARCHITECTURE AND INTERFACES
for the general 5G architecture [50]. This split makes the The O-RAN architecture shown in Fig. 7 is based on the
gNB-CU host the Radio Resource Control (RRC), Service NG-RAN design put forth by the 3GPP, as already discussed.
Data Adaptation Protocol layer (SDAP), and Packet Data Therefore, consistent with the NG-RAN architecture (dis-
Convergence Protocol (PDCP) layers, while the gNB-DU cussed in Section IV-C), it also splits the RAN into RU,
hosts the Radio Link Control (RLC), Media Access Control DU, and CU (CU-CP and CU-UP). In O-RAN language,
(MAC), and Physical layer (PHY) layers. This split between these components are pre-fixed with O-, namely O-CU-UP,

VOLUME 6, 2025 17
WANI et al.: OPEN RAN: A CONCISE OVERVIEW

Low-Phy layer and RF processing layers of the gNB protocol

stack.
Based on the location of the precoding function O-RUs are
classified into two types: Category A and Category B [61].
Category A O-RUs don’t perform precoding rather it is done
on O-DU, while Category B O-RUs execute the precoding
operation themselves.

B. O-DU
O-DU is a logical node that hosts the RLC, MAC
and High-Phy layer according to the 7.2x functional
split option. The operations of the O-DU are con-
trolled by O-CU. Data segmentation/integration, scheduling,
multiplexing/demultiplexing, and other baseband processing
FIGURE 7. Logical O-RAN architecture [60] tasks are performed in the O-DU.

C. O-CU
O-CU is a logical node that hosts RRC, PDCP, and SDAP
protocols and provides layer 3 functions such as connection
and mobility management. It is divided into O-CU-UP for user
plane processing and O-CU-CP for control plane processing.
Within this structure, O-CU-CP handles the RRC and control
plane part of the PDCP protocols, while the O-CU-UP handles
the user plane segment of PDCP and SDAP.
Additionally, the O-DU establishes connections with
O-CU-CP and O-CU-UP through F1-C and F1-U interfaces,
respectively. O-CU-CP connects to the Access and Mobility
Management Function (AMF) in the 5GC, while O-CU-UP
FIGURE 8. O-CU, O-DU, O-RU function split 7.2x.
establishes a connection with the User Plane Function (UPF).

D. O-CLOUD
O-CU-CP, O-DU, and O-RU, to refer to the fact that they are
The O-Cloud is a cloud computing platform that consists
3GPP-based functionalities adapted to O-RAN architecture.
of a number of physical infrastructure nodes that meet the
Besides the functional split of a gNB, O-RAN introduces
O-RAN requirements to host the O-RAN functions such as
the concept of RAN Intelligent Controller (RIC), abstracting
Near-RT RIC, O-CU-CP, O-CU-UP, and O-DU [62]. It also
out RAN control and monitoring from a base station. It also
houses their supporting software elements (e.g., Operating
defines Service Management and Orchestration (SMO) for
System, Virtual Machines, Container Runtime, etc.), and the
network function management and O-Cloud (O-RAN Cloud)
corresponding management and orchestration functions.
to host cloudified network functions. The architecture’s
The hardware infrastructure of the O-Cloud platform
components are interconnected through 3GPP interfaces as
includes compute, networking, and storage components,
well as new open interfaces defined by the O-RAN alliance.
potentially incorporating acceleration technologies essential
For their reference architecture, the O-RAN Alliance has
for RAN network functions to meet performance objec-
chosen split option 7.2x. This architecture aligns with the
tives [63]. Moreover, the O-Cloud platform software exposes
3GPP recommendation of implementing split option 2 for the
open and well-defined Application Programming Interfaces
high-level split (HLS) between the CU and DU. Furthermore,
(APIs), facilitating the seamless orchestration and manage-
this decision incorporates split option 7 for the lower layer
ment of both the Network Function deployment life cycle
split (LLS) between the RU and DU. Fig. 8 shows the
as well as the broader O-Cloud infrastructure.
division of the NR protocol stack layers using the 7.2x split.
The main elements in the O-RAN architecture shown in
Figure 7 are briefly described below. E. SMO
In a Service Provider’s Network, various domains such as
RAN, Core, Transport, and Slice Management coexist [62].
A. O-RU Among the various domains SMO specifically manages the
O-RU is the radio unit of the O-RAN architecture (physical RAN domain [64] in the O-RAN architecture. SMO basically
node) [17]. The O-RU is connected to the O-DU using the serves as the Orchestration and Management framework in
Open FH interface. According to the split 7.2x, it hosts the O-RAN architecture [14]. The SMO framework encompasses

18 VOLUME 6, 2025
 The Non-RT RIC is designed for control loops with
durations exceeding one second, focusing on establishing
policies for higher network layers. This enables the deduction
of trends in the network over various time intervals (e.g.,
hour, week), optimizing the overall RAN behavior.
The Non-RT RIC consists of Non-RT RIC Applications
(rApps) and the Non-RT RIC Framework. The Non-RT RIC
Framework is responsible for logically terminating the A1
interface and exposing a set of R1 services to rApps via the
R1 interface (defined in next section) [66].
rApps are modular third-party applications tailored for the
Non-RT RIC, delivering value-added services by leverag-
ing the functionalities available in the SMO/Non-RT RIC
Framework. The rApps communicate with the Non-RT
RIC platform via the open R1 interface. Operating on the
management plane, rApps contribute to providing value-
FIGURE 9. Near-RT RIC and Non-RT RIC. added services related to RAN operation and optimization.
The rApps encompass a wide array of functionalities,
spanning radio resource management, data analytics, deliv-
several components and interfaces, including, O1, O2, Open ery of enriching information, provisioning of policy-based
FH M-Plane, A1, and Non-RT RIC. guidance, and AI/ML training. These rApps are designed
The O1, O2, and O-FH M-Plane serve as manage- to run on any vendor’s Non-RT RIC because they are
ment interfaces (including Fault, Configuration, Accounting, based on the open interface [67]. Additionally, rApps can
Performance, Security (FCAPS)) [65] in the O-RAN archi- be independently developed by different companies than
tecture and are controlled by the SMO. The SMO uses the O1 the SMO/Non-RT RIC platform vendors and can receive
interface to manage all RAN elements but the O-RU. It uses upgrades separately from the SMO platform. Some examples
the O2 interface to manage O-Cloud platform resources and of rApps are energy saving management, QoE prediction
workload (e.g., scaling up/down resources). O-FH M-Plane and assurance, coverage, and capacity management [65].
acts as a management interface for the O-RU. The Non-RT The Near-RT RIC is a software platform that enables
RIC (described below) interacts with the Near-RT-RIC via xApps to control the RAN [68], [69]. This platform allows
the A1-interface, e.g., for RRM. near real-time control of E2 nodes via actions sent over
the E2 interface. The term E2 nodes refer to all units
controlled by the Near-RT RIC such as O-DU, O-CU-
F. RAN INTELLIGENT CONTROLLER (RIC) CP, and O-CU-UP. The control of E2 nodes via xApps is
The RIC in the O-RAN architecture provides an environ- supported by the Near-RT Framework that hosts a database
ment for programmable components capable of running storing network state and supports functionalities such as
optimization routines to monitor and control the RAN. xApp management, conflict resolution as well as security.
The RIC serves as the host for functionalities traditionally Additionally, it supports AI/ML workflows and offers APIs
found at the base station (Evolved NodeB (eNB) or gNB), for xApp integration [68]. An overview of the Near-RT RIC
including mobility management, admission control, and is shown in Fig. 10.
interference management [65]. These functionalities are The Near-RT RIC control is steered by the policies
accessible as applications on the controller within the RIC. and assisted by models provided by the Non-RT RIC
The decisions made by these applications are subsequently via the A1 interface. The Near-RT RIC operates within
enforced through open interfaces. These applications shall a near-real-time control loop, with a latency between ten
operate based on network state, traffic conditions, and goals milliseconds and one second. This time-frame corresponds to
of the Mobile Network Operator (MNO) and could be the execution of xApps, making decisions on control actions,
implemented using AI/ML algorithms. generating policy updates, and collecting key performance
The O-RAN architecture includes two types of RICs: Non- measurements.
real-time (Non-RT) RIC and Near-real-time (Near-RT) RIC, xApps are microservice-based applications tailored to
depicted in Fig. 9. operate on the Near-RT RIC. These applications are hosted
The Non-RT RIC is a logical function of the SMO that in the RAN domain and could be provided by third-party
supports control and optimization of RAN resources and software companies. The xApps are required to follow a
elements on a non-real time basis. Its primary purpose is to specified open API definition to be able to communicate
provide policy-based guidance, enrichment information, and with other parts of the RIC [65]. Upon registration with the
management of the ML models to complement the Near-RT Near-RT RIC platform, the xApp informs the Near-RT RIC
RIC in optimizing the RAN [62]. platform about the type of data it wants to consume and the

VOLUME 6, 2025 19
WANI et al.: OPEN RAN: A CONCISE OVERVIEW

O-DU and O-RU. The M-Plane [71] facilitates initialization,

configuration, and management of the O-RU.
The existing specifications lack provisions for encryption
and integrity protection of C-Plane, U-Plane, and S-Plane
messages (also referred as CUS Plane). However, the U-plane
is already protected using higher layer protection provided
by PDCP [72] protocol. The PDCP protocol provides both
confidentiality and integrity protection to the U-Plane data.
Additionally, the specifications advocate for the use of IEEE
802.1X [73] to facilitate authentication and authorization in
CUS planes. However, its implementation is mandatory in
O-RU, while it remains optional in O-DU [61].
For the M-Plane, end-to-end security is mandatory.
The security measures for the M-Plane include sup-
port for NETCONF/SSHv2 [74], [75] and NETCONF/TLS
1.2/1.3 [71].

B. A1 INTERFACE
In the O-RAN architecture, the A1 interface is an open
logical interface between the Near-RT RIC and the Non-RT
RIC [76]. This interface enables the Non-RT RIC to provide
policy-based guidelines, manage the ML models (e.g., in
FIGURE 10. Near-RT RIC Architecture Overview.
xApps), and transfer enrichment information to the Near-RT
RIC to facilitate the optimization of RAN functions. The data
outputs it will produce [55]. Some examples of xApp include transferred over the A1 interface can be associated with a
mobility management, traffic steering, load balancing, and single UE or a group of UEs. Typically, a mechanism based
admission control. on JSON is used to express information such as policies and
intent. The A1 interface relies on the A1AP protocol, which
VI. O-RAN INTERFACES FUNCTIONALITY AND combines REST APIs over HTTP for the transfer of JSON
SECURITY objects [15].
In the following section, we briefly discuss the func- The A1 policy management service is used by the Non-RT
tionalities associated with the interfaces involved in the RIC to guide the functionalities of Near-RT RIC towards the
O-RAN architecture. Additionally, we discuss the required fulfillment of the goal expressed in RAN intent [76]. RAN
security measures. A comprehensive summary of the security intent refers to the expression of high-level operational or
requirements pertaining to each interface can be found in business objectives for a radio access network, enabling an
Table 3. operator to define the targeted Service Level Agreements
(SLAs) that the RAN needs to fulfill for all or a class of
A. OPEN FRONTHAUL (FH) INTERFACE users in a given area over a period of time. The policies
The Open Fronthaul interface connects O-DU to O-RU are evaluated by the Non-RT RIC using the reporting
[70], [71]. It divides the physical layer functionalities functionalities of the O1 interface and the feedback received
between O-RU and O-DU. The Open FH interface facilitates over the A1 interface. Based on the evaluation of the policies
interoperability between various implementations of O-DU towards the fulfillment of RAN intent and some internal
and O-RU. conditions, the Non-Real-RIC can then decide if it needs to
The Open FH interface removes the traditional vendor- issue/update the goals expressed in the A1 policies.
specific Common Public Radio Interface (CPRI) protocol The A1 enrichment information service function enables
and instead implements a newer and open eCPRI (enhanced the Near-RT RIC to improve the RAN optimization
CPRI) protocol. The information carried over the Open FH performance by providing information typically inacces-
interface can be divided into four data planes: Control Plane sible to the RAN, such as data from non-network data
(C-Plane), User Plane (U-Plane), Synchronization Plane (S- sources. This information can be communicated to the
Plane), and Management Plane (M-Plane). The C-Plane xApps via A1EI or directly accessed by Near-RT from the
carries real-time control information to the O-RU over eCPRI Enrichment Information (EI) source. The Non-RT RIC will
to define how U-Plane traffic should be handled. It should be responsible for the source authentication and security
not be confused with UE’s Control plane. The U-Plane of the connection for the data provided by the external
refers to the real-time IQ sample data transferred between sources.
O-DU and O-RU. The S-Plane is used to achieve time, Regarding security, the A1 interface shall support confi-
frequency, and phase synchronization between the clocks of dentiality, integrity, and replay protection using TLS. It shall

20 VOLUME 6, 2025
TABLE 3. O-RAN interfaces security requirements. Light green cells represent mandatory security controls, gray cells represent optional security controls, and white cells
represent no security control specified.

also support mTLS for mutual authentication between the and near-RT RIC). Its main purpose is to facilitate the
Non-RT RIC and one or more Near-RT RICs and use OAuth operation and management of O-RAN components, covering
2.0 [77] to support authorization [78]. aspects such as FCAPS management, software management,
and file management [17]. Essentially, the O1 interface
C. E2 INTERFACE enables the orchestration and management of all rele-
The E2 interface is an open interface between the Near- vant O-RAN components and their associated network
RT RIC and the E2 nodes [79]. The E2 nodes maintain functions.
a one-to-one relationship with the Near-RT-RIC, while The O1 interface supports a range of Management
the Near-RT-RIC has a one-to-many relationship with the Services (MnS) [85], including Provisioning, Fault
E2 nodes. The E2 interface allows the RIC to control Supervision, Performance Assurance, Trace Management,
functionalities and procedures related to E2 nodes. It also File Management, Software Management, Communication
enables xApps to periodically gather data and metrics from Surveillance, and more. It commonly links a MnS provider
the RAN or in response to specific trigger events. These (usually the node managed by the SMO) to a MnS consumer
data collection and control processes can pertain to single (i.e., the SMO).
or multiple cells, slices, QoS classes, or UEs. The O- Regarding security [78], the O1 interface will enforce
RAN alliance uses a variety of identifiers to support these confidentiality, integrity, and authenticity using TLS 1.2 or
operations, e.g., the UE ID for a specific UE. An E2 node higher. Additionally, it uses NACM [86] to enforce least
can expose a variety of RAN functions based on the available privileged access.
adjustable parameters. These supported RAN functions can
then be published by the E2 Node, and the xApps can E. O2 INTERFACE
subscribe to some of these functions. In the O-RAN architecture, O2 is an open logical interface,
The E2 interface has been logically divided into two that provides secure communication between SMO and the
protocols: E2 Application Protocol (AP) and E2 Service O-Cloud [87]. This interface enables the management of
Model (SM). The E2AP protocol acts as a basic procedural O-Cloud infrastructure and workload.
protocol that [79] coordinates how E2 nodes communicate The services associated with the O-Cloud are catego-
with the Near-RT-RIC. rized by O2 interfaces into two groups: Infrastructure
An E2AP message can encapsulate different types Management Services (IMS) and Deployment Management
of E2SMs, that implement specific functionalities [80]. Services (DMS). IMS encompasses a subset of O2 functions
Examples of these service models developed by O-RAN responsible for deploying and managing cloud infrastructure,
include, Key Performance Measurement (KPM) [81], RAN including O-Cloud infrastructures, Scale-In and Scale-Out,
Control (RC) [82], and Cell Configuration and Control FCAPS, and Platform Software Management. On the other
(CCC) [83]. hand, DMS includes a subset of O2 functions responsible for
Regarding security, the O-RAN security requirements [78] overseeing the life-cycle of virtualized/containerized deploy-
specifies that traffic on the E2 interface shall be protected ments on the cloud infrastructure, such as Deployment,
using the IPsec [84] protocol. The IPsec protocol provides Termination, Scaling, and Healing of Network Function,
confidentiality, integrity, data origin authentication, and anti- along with their FCAPS.
reply protection. Regarding security, the security specifications docu-
ment [78] states that the O2 interface shall support
D. O1 INTERFACE confidentiality, integrity, replay protection, and data origin
The O1 Interface is an open interface between SMO authentication. The interface would employ TLS to support
framework and O-RAN managed elements (RAN nodes these security requirements.

VOLUME 6, 2025 21
WANI et al.: OPEN RAN: A CONCISE OVERVIEW

F. R1 INTERFACE like O1 reconfiguration or A1 policy creation. Moreover,

The R1 interface is an Open Interface between rApps and the Non-RT RIC can deploy trained models to the Near-RT
Non-RT RIC Framework that allows R1 Services to be RIC for ML inference. The Near-RT RIC, in turn, executes
produced and consumed [66]. The R1 services are typically AI/ML models in near-real-time, optimizing RAN operations
available as APIs. based on O1 configurations, A1 policies, and slice-specific
These APIs are being developed to help rApp developers E2 measurements. The Near-RT also monitors slice specific
implement RAN automation loops more quickly and easily RAN performance measurements [90].
by shielding low-level details. The R1 services includes [88],
but not limited to, registration and discovery services, B. THE CONTEXT-BASED DYNAMIC HANDOVER (HO)
authentication and authorization services, AI/ML workflow MANAGEMENT
services, and A1, O1, and O2 related services. The Context-Based Dynamic HO Management use case
In terms of security, the R1 interface shall support for Vehicle-to-everything (V2X) communication aims to
TLS for protecting data at the transport layer, mTLS for optimize radio resource allocation, enhance road safety and
mutual authentication between Non-RT RIC and rApps, and reduce emission. V2X UEs, which are devices attached
OAuth 2.0 for authorization [78]. to vehicles, communicate with the V2X Application
Server (V2X AS) to exchange critical information such
VII. O-RAN USE CASES as Cooperative Awareness Messages (CAMs) and radio
The introduction of RICs, open interfaces, and AI/ML measurements. As vehicles move, frequent and sometimes
workflows enables the realization of advanced use cases and suboptimal handovers occur, leading to issues like short
scenarios for RAN control and deployment optimization. stays and ping-pong effects. To address these, this use
The O-RAN Alliance has compiled an extensive catalog case leverages AI/ML models deployed in the Near-RT
of 25 exemplary use cases for Open RAN deployment RIC, based on data and policies from the Non-RT RIC, to
in [89], [90], with further high level details found in pertinent customize handover sequences. Key entities involved include
literature [22]. In this section, we provide a high level the Non-RT RIC for AI/ML model training and policy
overview of a three important use cases defined by O-RAN communication, the Near-RT RIC for model execution and
Alliance, namely RAN Slicing, Context-Based Dynamic policy enforcement, the RAN for configuration updates, and
Handover and Energy Saving taken from the official O-RAN the V2X AS for data provision.
use case documentation. In particular, these use cases have
been selected since they take advantage of the key features C. ENERGY SAVING (ES)
of O-RAN compared to monolithic solutions. Energy Saving is a critical issue for network operators,
especially with 5G networks. Due to varying traffic loads and
A. RAN SLICING user mobility, optimizing RAN Energy Consumption (EC)
Network slicing in 5G leverages a single physical infras- is complex and requires application across different network
tructure to create multiple virtual networks, each tailored layers and timescales. The energy saving use case aims
to specific requirements or tenants, enabling customized to leverage O-RAN AI/ML services and open interfaces to
service provisioning. Performance requirements such as introduce optimized EC and energy efficiency (EE) solutions
throughput, energy efficiency, latency, and reliability are by switching network components on and off at various
detailed in Service Level Agreementss (SLAs) between timescales. The ES use cases are divided into several sub-
operators and customers to ensure compliance and minimize cases based on the control timescale and the system involved.
violations [91]. Beyond the core network, the RAN must The first sub-case, Carrier and Cell Switch Off/On, oper-
also be slice-aware, managing resource isolation, availability, ates on a non-real-time scale and involves turning off cells or
and resource selection through RRM. O-RAN leverages carriers with no load or connected users, while neighboring
open interfaces and ML platforms to support protective cells manage the additional load. AI/ML-assisted solutions
mechanisms and life cycle management for network slices in the Non-RT RIC can be used to control the traffic load
within the RAN. Ensuring RAN slice service quality is of the carriers and the cell, and to automatically decide
challenging, but O-RAN’s AI/ML architecture and open when to switch off/on one or more carriers or a cell using
interfaces can enable effective SLA assurance, transforming O1 and/or Open fronthaul M-plane parameter configurations.
network operations and business models [89]. Off/on switching is accompanied by adequate traffic steering,
The RAN slice SLA assurance use case involves interac- guided by policies, to ensure service continuity and Quality
tions among the Non-RT RIC, Near-RT RIC, E2 nodes, and of Service (QoS).
SMO. The use case starts with retrieval of RAN specific The second sub-case, RF Channel Switch Off/On, aims
slice SLA/requirements (possibly within SMO). The Non- to reduce power consumption of O-RU with massive MIMO
RT RIC performs long-term monitoring, trend analysis, and deployment by switching certain RF channels on and off.
pattern recognition for RAN slice subnet performance. It This can operate at both non-real-time and near-real-time
also facilitates MLOps for tasks from data processing to scales. AI/ML-assisted solutions via rApp or xApp can
model training and validation, enabling corrective actions trigger this switching based on traffic information such as

22 VOLUME 6, 2025
load, user location, and mobility. For example, the algorithm Threats against O-Cloud: The security threats
can switch off 32 out of 64 RF channels in a digital M-MIMO that are pertinent to virtualization and containeriza-
architecture to save energy. The O-RU reconfiguration can tion [97], [98], [99] are of significant concern to
be performed using the Open fronthaul M-plane from the the O-Cloud. Common category of threats related to
E2 node or SMO. There is additional literature available on virtualization includes exploitation of Virtual Network
energy-saving strategies in O-RAN [35], [36], [37], [38]. Function (VNF), Container Network Function (CNF) images
and their corresponding covert data; malicious usage of
VIII. O-RAN SECURITY LANDSCAPE VM/CN to target other VM/CN, hypervisor/container engine.
The O-RAN architecture introduces potential security risks O-Cloud’s vulnerability extends to threats associated with
beyond those in the 3GPP architecture [92]. These risks the O2 interface, where an attacker on the SMO layer
result from the inclusion of new functions, additional may exploit the O2 interface to gain unauthorized access
interfaces, and the Lower Layer Split. Additionally, the to O-Cloud, and conversely, an attacker on O-Cloud may
disaggregation of hardware and software, virtualization, utilize the O2 interface to launch an attack on the SMO [92].
increased automation, and the incorporation of open-source Additionally, API security threats are also shared by O-cloud
components introduces extra security challenges that need or O-RAN in general.
to be addressed. Threats related to open-source code: The usage of open-
To address such security risks, the O-RAN Alliance source code in software development can be used as an attack
has established a dedicated working group, WG 11, that vector to perform malicious activities [100], [101]. Potential
concentrates on the security aspects of the open RAN attack vectors include, implanting intentional backdoors
ecosystem [92]. This group is tasked with examining and by malicious developers, spreading vulnerabilities through
defining threat models specific to O-RAN networks [92]. code reuse, leveraging publicly disclosed vulnerabilities, and
Additionally, WG 11 is responsible for specifying security human error [18]. Although O-RAN open-source compo-
requirements for each O-RAN interface and component [78], nents but is not strictly open-source.
establishing implementation requirements for security proto- Physical Threats: If a malicious actor gains physical
cols used by O-RAN [93], and documenting security tests to access to the hardware, O-RAN components could be
validate O-RAN implementations of security functions, con- sabotaged, or sensitive data could be accessed. O-RAN’s
figurations, and protocol requirements [94]. The overarching hardware can be rendered vulnerable due to issues such
goal is to implement a robust zero-trust model. as improper security protection of data centers, insufficient
protection against power outages, improper monitoring and
A. THREATS AGAINST O-RAN maintenance of hardware parameters, and hardware back-
Threats related to O-RAN architecture can be broadly doors [92].
classified into seven categories which are briefly described Physical access to O-RAN components becomes a
below. The threat categories are taken from the O-RAN significant concern due to issues such as unsecured
official O-RAN threat modeling documentation [92]. management ports and consoles, relaxed administrator
Threats against O-RAN elements credentials, and unsecured hardware/software configura-
This category includes threats related to the components tion/management. Such issues can allow an adversary to
and interfaces standardized by the O-RAN alliance. The inject malware, manipulate existing software, steal unpro-
elements included in this category are: Open FH interface, tected private keys and certificates, and turn off security
A1 interface, R1 interface, O1 interface, SMO, O-RU, and features.
RIC. These components may be subject to various types of Threats against 5G radio networks: An adversary could
attacks which could compromise the availability, integrity, use the readily available wireless channel to perform
and confidentiality of the network [92]. active and passive attacks. In active attacks [102], the
For example, the O-FH interface is vulnerable to Layer 2 adversary could actively transmit signals to influence what
threats [95]. An attacker who gains access to this interface a UE or network would receive. Active attacks can be
can eavesdrop on all traffic. The lack of a security mechanism performed mainly using three techniques: Radio Jamming,
for this interface can allow an attacker to identify hosts, Signal Overshadowing, and Message attacks [103]. In Radio
packet content, and traffic types. These actions could lead Jamming, the adversary increases the noise on the wireless
to the injection of a false message while impersonating a channel to perform attacks such as DoS or Downgrade a
legitimate node, delay or reply of a legitimate message, UE to a lower mobile network generation. Signal over-
or corrupting original messages, especially for the CUS shadowing is a new attack technique where an adversary
plane [95]. Similarly, SMO also faces several potential overshadows a legitimate message without interfering with
threats. These include the importation of poisoned external the synchronization between the BS and the victim UE. It
data to influence decision-making processes, introducing can be used to perform attacks such as DoS, Signal Storming,
corrupted data to execute remote code, exploiting weak Downgrade [104], [105]. In message attacks, the adversary
authentication and authorization mechanisms, and targeting uses fake devices such as a fake BS, MITM relay, or fake UE
vulnerabilities in the APIs [96]. to perform the attacks. The attacks in this category span from

VOLUME 6, 2025 23
WANI et al.: OPEN RAN: A CONCISE OVERVIEW

downgrading to lower generations (e.g., 4G or 2G) [106], elements only contributes to 4 percent of the total threats
DoS attacks [107], sending fake emergency messages [108], against O-RAN discussed in the O-RAN threat modeling
location spoofing [107], DNS spoofing [109], and more. report [92]. While risks related to AI/ML have already been
Passive attacks usually involve a passive sniffer and can discussed in the section above, we briefly discuss the threats
used to fingerprint devices [110], [111] or to decrypt phone related to newly introduced elements in the next section.
calls [112].
Threats related to ML/AI: The application of AI/ML C. THREATS UNIQUE TO OPEN RAN
for O-RAN control can expose it to AI/ML-related As discussed above, unique to O-RAN are components such
attacks [113]. Possible threat categories against AI/ML as Non-RT RIC, Near-RT RIC, interfaces R1, E2, and A1,
are Model Alteration, ML Model Corruption, Evasion, along with the integration of AI/ML. The threats associated
Membership Inference, Data Property Inference, Data with these components are briefly discussed below.
Reconstruction (theft), Model Extraction or Resource
Exhaustion. [114], [115], [116]. 1) THREATS RELATED TO NEAR-RT RIC
Threats to Protocol Stack: The O-RAN alliance reveals The incorporation of Near-RT RIC, utilizing xApps to control
the underlying protocol stack utilized within the O-RAN the RAN in the O-RAN architecture, introduces potential
architecture. While this transparency is beneficial, it also threats outlined below.
creates opportunities for potential attacks across its layers Malicious xApps can be deployed on the Near-RT RIC
due to factors such as improper implementation, utilization due to missing security measures around the deployment
of weak ciphers, and zero-day exploits. These attacks may of xApps on the Near-RT RIC [92]. The malicious xApps
involve injection, cross-site scripting, denial of service, could exploit the weakness to gain unauthorized access to
unauthorized exposure of object identifiers, and exploitation E2 nodes, misuse radio network information, and control
of Web tokens through REST APIs, JSON, or HTTP capabilities over the RAN functions [117]. Consequently, it
exploits [15]. can adversely impact the services of a particular subscriber
or a dedicated area. These malicious xApps can also exploit
B. COMPARISON OF TRADITIONAL RAN AND O-RAN UE identification, monitor UE location, and alter UE priority.
THREAT SURFACE For instance, if a malicious xApp receives an order via A1
Although the O-RAN architecture introduces new interfaces policy to prioritize a specific UE, then the xApp owner
and components on top of the 3GPP RAN architecture and knows an important person it wants to monitor in a particular
standardizes some existing elements, these additions do not area [97]. Based on this information, the adversary can
fundamentally differentiate O-RAN from the more traditional track the rough location of the UE or alter the order from
3GPP RAN regarding its internal operations. Some of the prioritize to de-prioritize. Note that the O-RAN specifications
components and interfaces in the O-RAN are not entirely have proposed a Security function to prevent xApps from
new to the RAN architecture; instead, they have been present performing malicious activities.
in the RAN for a long time but were implemented in a Conflicting xApps The xApps in the Near-RT can be
vendor-specific manner (e.g., management and orchestration provided by different vendors and can make conflicting
systems, front haul interface). Some of the components and decisions if they are not coordinated properly [97]. These
interfaces were introduced in the RAN more recently due to conflicts can be unintentional or malicious and could
the introduction of functional splits in the 3GPP RAN and impact system functions such as mobility management,
the proliferation of Cloud RAN. While other components load-balancing, and admission control to degrade network
have been directly inherited from the 3GPP architecture. availability or performance. For instance, xApps for Mobility
Due to these similarities, the security risks associated with Management and Load-balancing can issue different han-
the O-RAN architecture closely align with those of the 3GPP dover decisions for the same UE at the same instance, leading
RAN. These risks include design flaws, software security to the risk of triggering a radio link failure. Additionally,
considerations, network security risks, and risks related to there is a possibility of xApp’s decision conflicting with the
existing RAN components like O-RU, O-DU, or O-CU. internal decisions of the O-gNB. The O-RAN WG3 [68]
Among the elements present in the O-RAN (discussed in lists three types of conflicts between xApps:
Section VI) only some of the elements are unique to O-RAN. • Direct conflict: Change of the same parameter is
According to a recent security report [20], a component or requested by different xApps.
interface is not considered unique to O-RAN architecture, if • Indirect conflict: Change of different parameters is
its functionality already exists in more traditional (non-open) requested by different xApps but creates opposite
RANs, regardless of whether it has been newly specified by effects. E.g., antenna tilts and measurement offsets
the O-RAN standards or not. Based on the above criteria, represent distinct control points, but both influence the
Non-RT RIC and Near-RT RIC, R1, E2, and A1 interfaces handover boundary [97].
along with rApps, xApps, and their associated Machine • Implicit conflicts: Change of different parameters is
Learning (ML) models, are considered unique to O-RAN. requested by different xApps that do not create obvious
The report further states that the introduction of these new opposite effects but result in the degradation of the

24 VOLUME 6, 2025
 overall network performance. Implicit conflicts are most data inspection capabilities to identify malicious content.
difficult to mitigate since the correlations can hardly be For example, ingeniously crafted data might give rise to
observed. attacks such as buffer-overflow or SQL injection [17].
These conflicts can lead to performance degradation and Additionally, in the presence of weak mutual authenti-
instabilities, potentially introducing vulnerabilities that threat cation, a malicious E2 node could exploit vulnerabilities
actors could exploit to compromise system security to communicate with the Near-RT RIC, allowing for the
An optional Conflict Mitigation function (E2 Guidance monitoring or modification of messaging across the E2
Request Procedure) can mitigate conflicts arising from interface [92].
new xApps [68], [117]. It allows new xApps to obtain Threats related to R1 interface The R1 interface employs
guidance from the Conflict Mitigation function to resolve TLS, mTLS, and OAuth to safeguard against potential
potentially overlapping or conflicting requests from multiple threats [78]. However, the presence of weak mutual authen-
xApps. It is possible to resolve direct conflicts using this tication can introduce vulnerabilities that may lead to a
procedure. However, since indirect and implicit conflicts spectrum of potential threats. The threats include mali-
cannot be observed directly, they may or may not be cious actors gaining unauthorized access to R1 services,
resolved, depending upon the relationship between the manipulating Service Heartbeat to cause DoS, bypassing
xApps [15]. authorization to discover sensitive data, and comprising
data delivery to consumers, possibly leading to erroneous
2) THREATS RELATED TO NON-RT RIC decisions [92].
The introduction of Non-RT RIC in the O-RAN architecture Threats related to A1 interface TLS and OAuth contribute
brings about potential threats outlined below. robust security to this interface [78]. However, the presence
Threats against Non-RT RIC: Attackers can exploit SMO of weak mutual authentication poses a risk, potentially
channels to launch DoS attacks, track UE, or degrade enabling a malicious Non-RT RIC to connect with Near-
performance due to unspecified security measures [92]. RT, allowing for unauthorized monitoring or manipulation
This could hinder crucial functions like A1 policy analysis, of messages across the A1 interface [92]. Additionally, there
updates, and secure data delivery to Near-RT RIC. is also a possibility of intelligent availability attacks on the
Conflicting rApps can disrupt O-RAN functions, leading A1 interface that can reduce the quality of service offered
to performance degradation or triggering a Denial of Service by the RAN [17].
(DoS). The rApps in the Non-RT RIC can be provided
by different suppliers that can introduce the potential for IX. SUMMARY
these applications to make conflicting decisions, leading to Open RAN represents an innovative technology poised to
contradictory policies. These conflicts, encompassing direct, disrupt the cellular industry ecosystem by addressing current
indirect, and implicit types, are challenging to mitigate due challenges. Open RAN deployments are characterized by dis-
to unobservant dependencies [92]. aggregated, virtualized, software-based elements connected
Malicious rApps can be deployed and exploited by attack- via open standardized interfaces, and can be managed using
ers. These rApps may originate from untrusted sources or third-party applications. This approach promises to foster a
seemingly trusted sources that intentionally insert backdoors multi-vendor ecosystem, enhanced flexibility, improved cost
into the applications. Exploitable rApps can enable an efficiency, and increased performance.
attacker to disrupt network services and potentially take over This paper provided a concise overview of Open RAN
other rApps or the entire Non-RT RIC. The malicious rApps and its associated security considerations. Initially, we traced
can impact Non-RT RIC functions such as AI/ML model the evolution of RAN from traditional to virtualized forms
training, A1 policy management, enrichment information to highlight the differences and advancements in RAN
control, and Network Configuration Optimization. The objec- technology. Subsequently, we delved into the Open RAN
tive behind these malicious activities includes performance movement, outlining its key architectural principles and the
degradation, initiating DoS attacks, and gaining unautho- primary groups involved.
rized access to data such as UE location and navigation Furthermore, we elaborated on the interfaces within the
details [92]. architecture and the implemented security features. The
security landscape section provides insights into various
3) THREATS RELATED TO NEW INTERFACES threat categories associated with Open RAN. A comparative
The introduction of new interfaces in the O-RAN architecture analysis with traditional RAN architecture identifies unique
brings about potential threats outlined below: elements introduced by Open RAN, such as Non-RT RIC,
Threats to E2 interface The E2 interface uses IPsec Near-RT RIC, R1, E2, A1 interfaces, as well as rApps,
to protect the traffic on the interface [78]. Despite this xApps, and their associated Machine Learning (ML) models.
security measure, there remains a potential vulnerability The paper then delves into specific threats related to these
where end users may generate data that appears legitimate novel elements in the RAN, offering a comprehensive
but is, in fact, malicious. This introduces a risk of potential examination of the additional potential security challenges
attacks, particularly when the system lacks robust deep introduced.

VOLUME 6, 2025 25
WANI et al.: OPEN RAN: A CONCISE OVERVIEW

REFERENCES [23] P. S. Upadhyaya, A. S. Abdalla, V. Marojevic, J. H. Reed, and

[1] S. D’Oro, L. Bonati, F. Restuccia, and T. Melodia, “Coordinated 5G V. K. Shah, “Prototyping next-generation O-RAN research testbeds
network slicing: How constructive interference can boost network with SDRs,” 2022, arXiv:2205.13178.
throughput,” IEEE/ACM Trans. Netw., vol. 29, no. 4, pp. 1881–1894, [24] L. Bonati, M. Polese, S. D’Oro, S. Basagni, and T. Melodia,
Aug. 2021. “OpenRAN gym: An open toolbox for data collection and exper-
[2] S. D’Oro, F. Restuccia, and T. Melodia, “Toward operator-to- imentation with AI in O-RAN,” in Proc. IEEE Wireless Commun.
waveform 5G radio access network slicing,” IEEE Commun. Mag., Netw. Conf. (WCNC), Apr. 2022, pp. 518–523. [Online]. Available:
vol. 58, no. 4, pp. 18–23, Apr. 2020. [Link]
[3] T. L. Marzetta, “Noncooperative cellular wireless with unlimited [25] M. Dryjański, Ł. Kułacz, and A. Kliks, “Toward modular and flexible
numbers of base station antennas,” IEEE Trans. Wireless Commun., open ran implementations in 6G networks: Traffic steering use case
vol. 9, no. 11, pp. 3590–3600, Nov. 2010. and O-RAN xApps,” Sensors, vol. 21, no. 24, p. 8173, 2021.
[4] X. Lin, “Artificial intelligence in 3GPP 5G-advanced: A survey,” [26] E. Coronado, S. Siddiqui, and R. Riggio, “Roadrunner: O-RAN-
presented at Global Commun., 2024. based cell selection in beyond 5G networks,” in Proc. IEEE/IFIP
[5] Y. Azimi, S. Yousefi, H. Kalbkhani, and T. Kunz, “Applications Netw. Oper. Manage. Symp., 2022, pp. 1–7.
of machine learning in resource management for RAN-slicing [27] B. H. Prananto, Iskandar, and A. Kurniawan, “O-RAN intelli-
in 5G and beyond networks: A survey,” IEEE Access, vol. 10, gent application for cellular mobility management,” in Proc. Int.
pp. 106581–106612, 2022. Conf. ICT Smart Soc. (ICISS), Bandung, Indonesia, 2022, pp. 1–6,
[6] T. O’Shea and J. Hoydis, “An introduction to deep learning for the doi: 10.1109/ICISS55894.2022.9915221.
physical layer,” IEEE Trans. Cogn. Commun. Netw., vol. 3, no. 4, [28] D. Johnson, D. Maas, and J. Van Der Merwe, “NexRAN: Closed-loop
pp. 563–575, Dec. 2017. RAN slicing in POWDER-a top-to-bottom open-source open-RAN
[7] O-RAN: Towards an Open and Smart RAN, O-Ran Alliance, Bonn, use case,” in Proc. 15th ACM Workshop Wireless Netw. Testbeds,
Germany, Oct. 2018. Exp. Eval. Characterization, 2022, pp. 17–23.
[8] V.-G. Nguyen, A. Brunstrom, K.-J. Grinnemo, and J. Taheri, [29] R. Smith, C. Freeberg, T. Machacek, and V. Ramaswamy, “An O-
“SDN/NFV-based mobile packet core network architectures: A RAN approach to spectrum sharing between commercial 5G and
survey,” IEEE Commun. Surveys Tuts., vol. 19, no. 3, pp. 1567–1602, government satellite systems,” in Proc. IEEE Mil. Commun. Conf.
3rd Quart., 2017. (MILCOM), 2021, pp. 739–744.
[9] “Network functions virtualization—Network operator perspectives on [30] M. W. Akhtar, A. Mahmood, S. F. Abedin, S. A. Hassan, and
NFV priorities for 5G,” ETSI, Sophia Antipolis, France, White Paper, M. Gidlund, “Exploiting NOMA for radio resource efficient traffic
Feb. 2017. steering use-case in O-RAN,” in Proc. IEEE Global Commun. Conf.,
[10] P. K. Thiruvasagam et al., “Open RAN: Evolution of archi- 2022, pp. 5771–5776.
tecture, deployment aspects, and future directions,” Jan. 2023, [31] A. Samorzewski, A. Kliks, and M. Dryjański, “QoS-based RRM
arXiv:2301.06713. procedure for O-RAN systems,” in Proc. 29th Annu. Int. Conf. Mobile
[11] “‘Open’ telecom networks (open RAN): Towards the reconfiguration Comput. Netw., 2023, pp. 1–3.
of international relations,” IFRI, 2022. [Online]. Available: https:// [32] L. Baldesi, F. Restuccia, and T. Melodia, “ChARM: NextG spectrum
[Link]/en/publications/notes-de-lifri/open-telecom-networks- sharing through data-driven real-time O-RAN dynamic control,” in
open-ran-towards-reconfiguration-international Proc. IEEE INFOCOM Conf. Comput. Commun., 2022, pp. 240–249.
[12] F. Klement et al., “Open or not open: Are conventional radio access [33] P. Sroka, U. Kulacz, S. Janji, M. Dryjański, and A. Kliks,
networks more secure and trustworthy than open-RAN?” 2022, “Policy-based traffic steering and load balancing in O-RAN-based
arXiv:2204.12227. vehicle-to-network communications,” IEEE Trans. Veh. Technol.,
[13] “Current state of open RAN.” TeckNexus. 2022. Accessed: Mar. 3, early access, May 13, 2024, doi: 10.1109/TVT.2024.3399924.
2023. [Online]. Available: [Link] [34] M. M. Qazzaz, Ł. Kułacz, A. Kliks, S. A. Zaidi, M. Dryjanski, and
state-of-open-ran-countries-operators-deploying-trialing-open-ran/ D. McLernon, “Machine learning-based xApp for dynamic resource
[14] W. Azariah, F. A. Bimo, C.-W. Lin, R.-G. Cheng, N. Nikaein, allocation in O-RAN networks,” 2024, arXiv:2401.07643.
and R. Jana, “A survey on open radio access networks: [35] L. Wang, J. Zhou, M. Ma, and X. Niu, “Minimizing energy
Challenges, research directions, and open source approaches,” consumption of IoT devices for O-RAN based IoT systems,” Energy
Sensors, vol. 24, no. 3, p. 1038, 2024. [Online]. Available: https:// Rep., vol. 9, pp. 379–388, Nov. 2023.
[Link]/1424-8220/24/3/1038 [36] Ö. T. Demir, M. Masoudi, E. Björnson, and C. Cavdar, “Cell-
[15] M. Polese, L. Bonati, S. D’oro, S. Basagni, and T. Melodia, free massive MIMO in O-RAN: Energy-aware joint orchestration of
“Understanding O-RAN: Architecture, interfaces, algorithms, secu- cloud, fronthaul, and radio resources,” IEEE J. Sel. Areas Commun.,
rity, and research challenges,” IEEE Commun. Surveys Tuts., vol. 25, vol. 42, no. 2, pp. 356–372, Feb. 2024.
no. 2, pp. 1376–1411, 2nd Quart., 2023. [37] L. Wang, J. Zhou, Y. Wang, and B. Lei, “Energy conserved
[16] B. Brik, K. Boutiba, and A. Ksentini, “Deep learning for B5G computation offloading for O-RAN based IoT systems,” in Proc.
open radio access network: Evolution, survey, case studies, and IEEE Int. Conf. Commun., 2022, pp. 4043–4048.
challenges,” IEEE Open J. Commun. Soc., vol. 3, pp. 228–250, 2022. [38] M. Dryjański, The O-RAN Whitepaper 2023—Energy Efficiency in
[17] Open RAN Risk Analysis, Bundesamt für Sicherheit in der O-RAN, O-RAN Alliance, Alfter, Germany, 2023.
Informationstechnik, Bonn, Germany, 2022. [39] “Accelerating 5G virtual RAN deployment,” Comcores.
[18] Open Radio Access Network Security Considerations, Nat. Security 2020. [Online]. Available: [Link]
Agency (NSA) Cybersecurity Infrastruct. Security Agency (CISA), content/uploads/2020/07/[Link]
Washington, DC, USA, Sep. 2022. [40] “5G open RAN ecosystem Whitepaper,” NTT Docomo, Tokyo, Japan,
[19] Report on the Cybersecurity of Open RAN, NIS Group, North Liberty, White Paper, 2021. [Online]. Available: [Link]
IA, USA, 2022. jp/orec/5gopenranecosystem/whitepaper/OREC [Link]
[20] Open RAN Security Report, Quad Crit. Emerg. Technol. Working [41] “Open RAN security white paper,” Deutsche Telekom, Bonn,
Group, Nat. Telecommun. Inf. Admin., Washington, DC, USA, Germany, Orange, Paris, France, Telefonica, Madrid, Spain,
May 2023. Vodafone, Berkshire, U.K., White Paper, 2022. [Online]. Available:
[21] M. Liyanage, A. Braeken, S. Shahabuddin, and P. Ranaweera, “Open [Link]
RAN security: Challenges and opportunities,” J. Netw. Comput. Appl., Open RAN MoU Security White [Link]
vol. 214, May 2023, Art. no. 103621. [Online]. Available: https:// [42] M. Dryjanski and R. Lundberg, “The O-RAN Whitepaper 2021—
[Link]/science/article/pii/S1084804523000401 Rimedo labs,” 2021. [Online]. Available: [Link]
[22] A. S. Abdalla, P. S. Upadhyaya, V. K. Shah, and V. Marojevic, com/blog/the-o-ran-whitepaper/
“Toward next generation open radio access networks: What [43] T. Nolle, “Transformation and 5G O-RAN—VMWare,”
O-RAN can and cannot do,” IEEE Netw., vol. 36, no. 6, 2021. [Online]. Available: [Link]
pp. 206–213, Nov./Dec. 2022. [Online]. Available: [Link] dam/digitalmarketing/vmware/en/pdf/microsites/telco/vmware-
10.1109/MNET.108.2100659 [Link]

26 VOLUME 6, 2025
 [44] “Dell technologies, VMware, and Mavenir 5G O-RAN reference [66] “O-RAN non-RT RIC architecture 4.0,” O-RAN Working Group 2,
architecture,” 2021. [Online]. Available: [Link] O-RAN Alliance, Alfter, Germany, Rep. [Link]-RT-RIC-
[45] “O-RAN: An open ecosystem to power 5G applications.” VIAVI ARCH-R003-v04.00, Oct. 2023.
Solutiuons. 2021. [Online]. Available: [Link] [67] “An intelligent platform: The use of O-RAN’s SMO as the enabler for
com/en-us/literature/o-ran-open-ecosystem-power-5g-applications- openness and innovation in the RAN domain,” Ericsson, Stockholm,
[Link] Sweden, White Paper BDGS-21:031169 Uen, Nov. 2021. [Online].
[46] “OpenRAN RAN intelligence and automation,” TIP, 2021. Accessed: Available: [Link]
Dec. 2022. [Online]. Available: [Link] papers/white-papers/[Link]
at/xq2qrcwgszxpb49zt93bwt/RIA/OpenRANataglance_Glossy_v08_ [68] “O-RAN near-RT RIC architecture 5.0,” WG3: Near-real-time RIC
2021_06_16.pdf and E2 Interface Workgroup, O-RAN Alliance, Alfter, Germany,
[47] G. Brown, “TIP OpenRAN: Toward disaggregated mobile Rep. [Link]-R003-v05.00, 2023.
networking,” 2020. [Online]. Available: [Link] [69] M. Hoffmann et al., “Open RAN xApps design and evaluation:
D8DI15S7/as/qc19tk-54bsw-305 Lessons learnt and identified challenges,” IEEE J. Sel. Areas
[48] “Security in open RAN.” Altiostar, Jan. 2021. [Online]. Commun., vol. 42, no. 2, pp. 473–486, Feb. 2024.
Available: [Link] [70] “O-RAN control, user and Synchronization plane specification 14.0:
[Link] WG4: Open Fronthaul interfaces workgroup,” O-RAN Alliance,
[49] S. P. J. S. Boswell, “Security considerations of open RAN,” Ericsson, Alfter, Germany, Rep. [Link].0-R003-v13.00, 2023.
Stockholm, Sweden, White Paper, Aug. 2021. [Online]. Available: [71] “O-RAN management plane specification 14.0: WG4: Open fronthaul
[Link] interfaces workgroup,” O-RAN Alliance, Alfter, Germany, Rep. O-
insights/doc/[Link] [Link].0-R003-v14.00, 2024.
[50] X. Lin and N. Lee, Eds., 5G and Beyond: Fundamentals and [72] NR; Packet Data Convergence Protocol (PDCP), Release 16,
Standards, 1st ed. Cham, Switzerland: Springer Nat., 2021. [Online]. V16.6.0, 3GPP Standard TS 38.323, Dec. 2021. [Online]. Available:
Available: [Link] [Link]
[51] “Everything you need to know about open RAN.” [73] IEEE Standard for Local and Metropolitan Area Networks–
ParallelWireless. 2020. [Online]. Available: [Link] Port-Based Network Access Control, IEEE Standard
[Link]/wp-content/uploads/Parallel-Wireless-e-Book- 802.1X-2020, Feb. 2020. [Online]. Available: https://
[Link] [Link]/document/9035631
[52] “xRAN forum merges with C-RAN alliance to form [74] “Network configuration protocol (NETCONF),” IETF, RFC 6241,
ORAN alliance.” 2018. [Online]. Available: [Link] 2011. [Online]. Available: [Link]
[Link]/news/home/20180227005673/en/ [75] T. Ylonen and C. Lonvick, “The secure shell (SSH) authentication
protocol,” IETF, RFC 4252, Jan. 2006. [Online]. Available: https://
[53] A. Weissberger, “TIP OpenRAN and O-RAN alliance: Liaison
[Link]/rfc/[Link]
and collaboration for open radio access networks,” Feb. 2020.
[Online]. Available: [Link] [76] “O-RAN working group 2 (non-RT RIC and A1 interface WG) A1
openran-and-o-ran-alliance-liaison-and-collaboration-for-open-radio- interface: General aspects and principles,” WG2: Non-real-time RAN
access-networks/ intelligent controller and A1 interface workgroup, O-RAN Alliance,
Alfter, Germany, Rep. o-RAN.WG2.A1GAP-R003-v03.01, 2023.
[54] “O-RAN empowering vertical industry: Scenarios, solutions and best
[77] D. Hardt, “The OAuth 2.0 authorization framework,” IETF, RFC
practice white paper,” O-RAN Alliance e.V., Alfter, Germany, White
6749, 2012. [Online]. Available: [Link]
Paper, Dec. 2023.
[78] “O-RAN security protocols specifications 7.0,” WG11: Security
[55] “The O-RAN Whitepaper 2022—RAN intelligent controller,”
Work Group, O-RAN Alliance, Alfter, Germany, Rep. O-
Rimedo Labs, Poznań, Poland, White Paper, Feb. 2022.
[Link].0-R003-v07.00, Oct. 2023.
[56] “NG-RAN; architecture description,” 3GPP, Sophia Antipolis, [79] “O-RAN E2 general aspects and principles (E2GAP) 4.01,” WG3:
France, Rep. TS 38.401, Apr. 2022. [Online]. Available: Near-real-time RIC and E2 interface workgroup, O-RAN Alliance,
[Link] Alfter, Germany, Rep. O-RAN.WG3.E2GAP-R003-v4.01, 2023.
[57] “5G functional splits.” Parallel Wireless. 2022. Accessed: Jan. [80] “O-RAN E2 service model (E2SM) 4.0,” WG3: Near-real-time RIC
2, 2024. [Online]. Available: [Link] and E2 interface workgroup3, O-RAN Alliance, Alfter, Germany,
content/uploads/[Link] Rep. O-RAN.WG3.E2SM-R003-v04.00, Oct. 2023.
[58] D. Wypiór, M. Klinkowski, and I. Michalski, “Open RAN—Radio [81] WG3: Near-real-time RIC and E2 interface workgroup, “O-RAN
access network evolution, benefits and market trends,” Appl. Sci., E2 service model (E2SM) KPM 4.0,” O-RAN Alliance, Alfter,
vol. 12, no. 1, p. 408, 2022. [Online]. Available: [Link] Germany, Rep. O-RAN.WG3.E2SM-KPM-R003-v04.00, 2023,
[Link]/2076-3417/12/1/408 [82] “O-RAN E2 service model (E2SM), RAN control 4.0,” WG3: Near-
[59] “Technical specification group radio access network—Study on new real-time RIC and E2 Interface Workgroup, O-RAN Alliance, Alfter,
radio access technology: Radio access architecture and interfaces Germany, Rep. O-RAN.WG3.E2SM-RC-R003-v04.00, 2023.
(release 14), version 14.0.0,” 3GPP, Sophia Antipolis, France, [83] “O-RAN E2 service model (E2SM) cell configuration and control
Rep. 38.801, Mar. 2017, 2.0,” WG3: Near-real-time RIC and E2 Interface Workgroup, O-RAN
[60] “O-RAN Software Community: O-RAN architecture,” Nov. 2022. Alliance, Rep. O-RAN.WG3.E2SM-CCC-R003-v02.00, 2023.
Accessed: Apr. 17, 2023. [Online]. Available: [Link] [84] K. Seo and S. Kent, “Security architecture for the internet pro-
[Link]/en/latest/architecture/[Link] tocol,” RFC 4301, Dec. 2005. [Online]. Available: [Link]
[61] “O-RAN control, user and synchronization plane specification 13.0,” [Link]/info/rfc4301
WG4: Open Fronthaul Interfaces Workgroup, O-RAN Alliance, [85] “O-RAN operations and maintenance interface specification 11.0,”
Alfter, Germany, Rep. [Link].0-R003-v13.00, 2023. O-RAN Alliance, Alfter, Germany, Rep. O-RAN.WG10.O1-
[62] “O-RAN architecture description 10.0,” O-RAN Alliance, Alfter, Interface.0-R003-v11.00, 2023.
Germany, Rep. [Link]-R003-v10.00, Oct. 2023. [86] “Network configuration access control model,” IETF, RFC 8341,
[63] “O-RAN cloud architecture and deployment scenarios for O-RAN 2018, [Online]. Available: [Link]
virtualized RAN 5.0,” WG6: Cloudification and Orchestration [87] “O-RAN O2 interface general aspects and principles 5.0,” O-
Workgroup, O-RAN Alliance, Alfter, Germany, Rep. O- RAN Working Group 6, O-RAN Alliance, Alfter, Germany, Rep.
[Link]-v05.00, 2023. O-RAN.WG6.O2-GA&P-R003-v05.00, 2023.
[64] “O-RAN operations and maintenance architecture 10.0,” O-RAN [88] “O-RAN R1 interface: General aspects and principles 7.0,” O-RAN
Alliance, Alfter, Germany, Rep. WG10: OAM for O-RAN, Rep. Working Group 2,O-RAN Alliance, Alfter, Germany, Rep. O-
[Link]-Architecture-R003-v10.00, 2023. RAN.WG2.R1GAP-v06.00, 2023.
[65] A. Kliks, M. Dryjanski, V. Ov, L. Wong, and P. Harvey, “Towards [89] “O-RAN use cases analysis report 13.0: WG1: Use cases and overall
autonomous open radio access networks,” ITU J. Future Evolv. architecture workgroup,” O-RAN Alliance, Rep. [Link]-
Technol., vol. 4, pp. 251–268, May 2023. Cases-Analysis-Report-R003-v13.00, Feb. 2024.

VOLUME 6, 2025 27
WANI et al.: OPEN RAN: A CONCISE OVERVIEW

[90] “O-RAN use cases detailed specification 13.0: WG1: Use cases and [105] S. Erni, M. Kotuliak, P. Leu, M. Roeschlin, and S. Capkun,
overall architecture workgroup,” O-RAN Alliance, Alfter, Germany, “AdaptOver: Adaptive overshadowing attacks in cellular networks,”
Rep. [Link]-Cases-Detailed-Specification-R003-v13.00, in Proc. 28th Annu. Int. Conf. Mobile Comput. And Netw.,
2024. Oct. 2022, pp. 743–755. [Online]. Available: [Link]
[91] S. Marinova and A. Leon-Garcia, “Intelligent O-RAN beyond 5G: 10.1145/3495243.3560525
Architecture, use cases, challenges, and opportunities,” IEEE Access, [106] B. Karakoc, N. Fürste, D. Rupprecht, and K. Kohls, “Never let
vol. 12, pp. 27088–27114, 2024. me down again: Bidding-down attacks and mitigations in 5G
[92] O-RAN Security Threat Modeling and Remediation Analysis 6.0, and 4G,” in Proc. 16th ACM Conf. Security Privacy Wireless
O-RAN Alliance, Alfter, Germany, Jun. 2023. Mobile Netw., 2023, pp. 97–108. [Online]. Available: https://
[93] “O-RAN security test specifications 5.0: WG11: Security [Link]/10.1145/3558482.3581774
work group,”O-RAN Alliance, Alfter, Germany, Rep. [107] S. R. Hussain, O. Chowdhury, S. Mehnaz, and E. Bertino,
[Link]-Test-Specifications.O-R003-v05.00, 2023. “LTEInspector: A systematic approach for adversarial
[94] “O-RAN security requirements and controls specification 7.0: testing of 4G LTE,” in Netw. Distrib. System Security
WG11: Security work group,” O-RAN Alliance, Alfter, Germany, Symp., 2018, pp. 1–15. [Online]. Available: [Link]
Rep. [Link]-Requirements-Specification.O-R003- [Link]/CorpusID:3387805
v07.00, 2023. [108] G. Lee et al., “This is your president speaking: Spoofing alerts in
[95] D. Dik and M. S. Berger, “Open-RAN Fronthaul transport 4G LTE networks,” in Proc. 17th Annu. Int. Conf. Mobile Syst.,
security architecture and implementation,” IEEE Access, vol. 11, Appl., Services, 2019, pp. 404–416. [Online]. Available: https://
pp. 46185–46203, 2023. [Link]/10.1145/3307334.3326082
[96] “Zero trust architecture for evolving radio access networks.” Ericsson. [109] D. Rupprecht, K. Kohls, T. Holz, and C. Pöpper, “Breaking LTE on
Nov. 2023. [Online]. Available: [Link] layer two,” in Proc. IEEE Symp. Security Privacy (SP), May 2019,
assets/local/reports-papers/further-insights/doc/[Link] pp. 1121–1136.
[97] “Security considerations of open RAN.” Ericsson. 2020. Accessed: [110] A. Shaik, R. Borgaonkar, S. Park, and J.-P. Seifert, “New
Dec. 2023. [Online]. Available: [Link] vulnerabilities in 4G and 5G cellular access network proto-
assets/local/security/[Link] cols: Exposing device capabilities,” in Proc. WiSec, May 2019,
[98] Threat Analysis of Container-as-a-Service for Network Function pp. 221–231.
Virtualization, Fraunhofer Institute for Applied and Integrated [111] M. Kotuliak, “LTE monitoring,” M.S. thesis, ETH Zürich, Zürich,
Security (AISEC), München, Germany, 2024. Switzerland, 2020.
[99] M. Souppaya, J. Morello, and K. Scarfone, “Application container [112] D. Rupprecht, K. S. Kohls, T. Holz, and C. Pöpper, “Call me
security guide,” NIST, Gaithersburg, MD, USA, Rep. SP 800-190, maybe: Eavesdropping encrypted LTE calls with ReVoLTE,” in
2024. [Online]. Available: [Link] Proc. USENIX Security Symp., 2020, pp. 73–88. [Online]. Available:
[100] M. Ohm, H. Plate, A. Sykosch, and M. Meier, “Backstabber’s knife [Link]
collection: A review of open source software supply chain attacks,” [113] B. Biggio and F. Roli, “Wild patterns: Ten years after
in Detection of Intrusions Malware, Vulnerability Assessment, the rise of adversarial machine learning,” Pattern Recognit.,
C. Maurice, L. Bilge, G. Stringhini, and N. Neves, Eds. Cham, vol. 84, pp. 317–331, Dec. 2018. [Online]. Available: [Link]
Switzerland: Springer 2020, pp. 23–43. [Link]/science/article/pii/S0031320318302565
[101] P. Ladisa, H. Plate, M. Martinez, and O. Barais, “SoK: Taxonomy [114] “Adversarial machine learning: A taxonomy and terminology
of attacks on open-source software supply chains,” in Proc. IEEE of attacks and mitigations,” U.S. Dept. Commerce, NIST,
Symp. Security Privacy (SP), 2023, pp. 1509–1526. Gaithersburg, MD, USA, Rep. NIST AI 100-2e2023, Mar. 2023,
[102] Study on 5G Security Enhancement Against False Base Stations [Online]. Available: [Link]
(FBS), Version 0.17.0, Release 17, 3GPP Standard 36.331, 2021. [Link]
[103] M. S. Wani, M. Rademacher, T. Horstmann, and M. Kretschmer, [115] N. N. Sapavath, B. Kim, K. Chowdhury, and V. K. Shah,
“Security vulnerabilities in 5G non-stand-alone networks: A sys- “Experimental study of adversarial attacks on ML-based xApps in
tematic analysis and attack taxonomy,” J. Cybersecurity Privacy, O-RAN,” 2023, arXiv:2309.03844.
vol. 4, no. 1, pp. 23–40, 2024. [Online]. Available: [Link] [116] E. Habler et al., “Adversarial machine learning threat analysis
[Link]/2624-800X/4/1/2 and Remediation in open radio access network (O-RAN),” 2023,
[104] H. Yang, S. Bae, M. Son, H. Kim, S. M. Kim, and Y. Kim, “Hiding arXiv:2201.06093.
in plain signal: Physical signal overshadowing attack on LTE,” in [117] WG11: Security Work Group, “Study on security for near
Proc. 28th USENIX Security Symp. (USENIX Security), Santa Clara, real time RIC and xApps,” O-RAN Alliance, Rep. O-
CA, USA, Aug. 2019, pp. 55–72. [Online]. Available: [Link] [Link]-Near-RT-RIC-xApps-TR.0-R003-v04.00,
[Link]/conference/usenixsecurity19/presentation/yang-hojoon 2023.

28 VOLUME 6, 2025