EB ParallelWireless Open RAN Fact Book 100521

Parallel Wireless
Open RAN
and O-RAN
Fact Book
1
INTRODUCTION:
The Open RAN and O-RAN fact book is a compilation of Parallel Wireless #OpenRANdailyfact posts on LinkedIn which began
in 2021. These posts have exploded with followers and consist of concise Open RAN information and diagrams such as:
Definition of Organizations such as Open RAN Automation and Total Cost of O-RAN Architecture, Deployment
Open RAN O-RAN Alliance and Optimization Cloud-native Ownership (TCO) Components, And Use Cases
Telecom Infra Project (TIP) Interfaces And Much
More
This comprehensive guide aims to simplify Open RAN, which is the movement in wireless telecommunications to
disaggregate hardware and software, to open interfaces, and reduce costs.
Parallel Wireless #OpenRANdailyfact 2

AGENDA
Open RAN Definition
01 and Organizations
04 07 Open RAN Automation 64
02 RAN Functional Splits 10 08 Open RAN Integration 68
Telecom Infra Project

03 O-RAN Alliance 31 09 (TIP)
71
O-RAN Alliance
04 Architecture
38 10 TCO 78
05 RIC 49 11 Use Cases 82
06 Cloud-Native Open RAN 60 12 Operator Views 93

OPEN RAN DEFINITION AND
ORGANIZATIONS

OPEN RAN DEFINITION
AND ORGANIZATIONS
Open RAN is vRAN vRAN Open RAN
with OPEN interfaces,
so components can be COTS-Based
Antennas
mixed and matched for Hardware (SDR)
can be purchased
vendor interoperability. RF
Proprietary from any
Remote ODM/OEM/RAN
Radio Unit Hardware
hardware vendor
(RRU)
• DAC/ADC
• RF
Equipment
Fiber Cabling
CPRI Open Interface
Proprietary Any vendor
Interfaces
software can work
on this hardware
Baseband COTS Server + Proprietary Software With Virtualized Functions

Unit (BBU)
vRAN is not necessarily Open RAN
Contemporary Base Station

• Signal Processing • Network Access • Fiber Optic Cables

WHEN TO SPELL OPEN
RAN WITH A SPACE,
WITHOUT (OPENRAN)
AND WITH A – (O-RAN)?
Open RAN = overall Open RAN
movement of disaggregating
hardware and software and
opening up the interfaces
OpenRAN = TIP group and anything

related to TIP deployments
O-RAN or ORAN = O-RAN

Alliance refers to the organization
itself or interfaces

OPEN RAN VS VRAN VS O-RAN
Open RAN Virtualized RAN (vRAN) O-RAN
• The industry’s generic description of • 3GPP Release 15 introduced CU-DU split RAN • The Open RAN standardized by the O-RAN
an open Radio Access Network architecture ALLIANCE e.V. to enable open interfaces,
(RAN) architecture virtualization, intelligence, and interoperability
• Virtualization of RAN functions: gNB, eNodeB,
• Open interoperable interfaces Distributed Unit (DU) and Centralized Unit (CU) • Enables MNOs to deploy Radio Units (RU) and
Distributed Units (DU) and Centralized Units (CU)
• Virtualized RAN functions • Virtualized RAN components do not necessarily
from different vendors
comply with O-RAN specifications
• CU DU is deployed on a COTS server
• Virtualized components can be mixed and
matched from different vendors unless • Utilizes a Lower Layer Split (LLS) split, Option
interfaces are open or O-RAN compliant 7.2x, transported over eCPRI protocol
“OPEN” & “V” MODELS
Open Fronthaul F1 Interface
Radio Unit (O-RU) Distributed Unit (O-DU) O-CU (CP)

O-CU (UP)
Open Interfaces (“Open”) 4G or 5G Core
White Box Hardware General-Purpose Hardware General-Purpose Hardware
OpenRAN Hardware Acceleration
Hardware Acceleration
Distributed Unit (O-DU) O-CU (CP)

Radio Unit (O-RU) O-CU (UP)
Cloudification Cloud Platform Cloud Platform 4G or 5G Core
vRAN White Box Hardware (VMs or Containers) (VMs or Containers)
Hardware Acceleration General-Purpose Hardware General-Purpose Hardware
Hardware Acceleration
F1 Interface
O-Cloud Interface with Service
Open Fronthaul Management & Orchestration (O2)
O-CU (CP)
Radio Unit (O-RU) Distributed Unit (O-DU)
O-CU (UP)
“Open” + “v” Cloud Platform (O-Cloud) Cloud Platform (O-Cloud) O2 4G or 5G Core
Open vRAN White Box Hardware (VMs or Containers) O2
(VMs or Containers)
Hardware Acceleration General-Purpose Hardware
Hardware Acceleration General-Purpose Hardware
Image Source: Red Hat
THE INDUSTRY ORGANIZATIONS INVOLVED IN O-RAN
3GPP: overall telecom O-RAN ALLIANCE e.V.: GSMA: helps to accelerate Open RAN Policy
01 03 05 07
standards, interfaces development of Open RAN through Coalition: education on
need to be opened by interoperable standards for partnerships with TIP and policies for open and
each vendor white box RAN, software, the O-RAN Alliance interoperable RAN
and RIC
02 Telecom Infra Project: 04 The Linux Foundation: 06 Small Cell Forum:

advancement of global through a partnership with standardization of open
Open RAN deployments the O-RAN Alliance, small cells
from standards to development of open
commercial solution via software for the RAN
self-certification and testing
Telecom standards development. Though Operator – led standardization efforts for Partnership with TIP and O-RAN Alliance
the RAN standards were developed white box RAN and software, RIC and to accelerate the adoption of Open RAN
collaboratively, each vendor has their own testing of those technologies / creation of
flavor hence creating lack of interoperability O-RAN reference designs
Development of open standards for small cells
Advancement of global Open RAN Collaboration with the O-RAN Alliance in

deployments through trials, PlugFests and the O-RAN Software Community to support
creation of reference designs for deployments the creation of open-source for the RAN Education and promotion of policies to advance the
adoption of open and interoperable ran globally

OPEN RAN COMPONENTS
White box hardware:
• History of white box: disrupted enterprise market in 2000
• White box = general purpose vendor-neutral hardware or Commercial off-the-shelf (COTS) hardware for radio and servers
COTS server for DU/CU software:

• Enables decoupling of hardware/software to reduce costs and vendor lock-in
• Opens up the market to new players
• Standardizes telecom infrastructure
O-RAN Alliance white box group (WG7) has released hardware designs, software architecture, and white
box specs for RAN O-DU, O-CU & O-RU (O = #ORAN specs):
• Different split architectures: options 6 (all PHY in O-RU), 7.2 (lower PHY in O-RU, higher PHY in O-DU) and 8 (all PHY in O-DU)
• High performance, spectral and energy efficient white-box base station hardware
• Designs to optimize performance per watt while meeting base station hardware reliability, maintainability and environmental needs
• Can be customized to accommodate more powerful CPUs or additional CPU nodes, additional RAN or storage
• Hardware requirements for different deployment scenarios (indoor pico, outdoor pico, micro, macro) and different architectures (split vs integrated)
• Performance requirements for peak data rate, peak spectral efficiency, bandwidth, latency, mobility
Realizing 5G Open RAN with COTS-Based Appliances
RRU MAC/RLC PDCD/RRC
RRU DU Middlehaul CU Backhaul 5G Core

Fronthaul
Network
RRU
O-RAN Appliance MEC Appliance

Image Source: Lanner Electronics Inc.
9
RAN FUNCTIONAL SPLITS

EVOLUTION TO
OPEN RAN
• 3GPP introduced the DU 4G / 5G 4G / 5G Core
and CU concept as the Core Network Network
evolution path toward
disaggregated RAN
Backhaul
• Introduction of midhaul Backhaul
provides more flexibility for
3GPP Approach
transport options CU
(TR 38.801)
BBU Midhaul
DU
Fronthaul
Fronthaul
RRU RRU

5G RAN
In a 5G RAN architecture,
the BBU functionality is
split into two functional
units: a Distributed Unit
(DU), responsible for real
time L1 and L2
RU (Radio Unit) Hardware = RF Transmitter
scheduling functions, and
a Centralized Unit (CU)
responsible for non-real
time, higher L2 and L3.
DU (Distributed Unit) Software = Real-
Time Processing
Virtual Baseband
Unit (vBBU) on a
Edge CU (Centralized Unit) Software = Non-Real
COTS server
Time Processing
CU could be also deployed in the data center, but gains for
4G are minimal

EVOLUTION TO OPEN RAN
Fronthaul
Connectivity between
the RU and DU
RU
Midhaul Fronthaul
Connectivity between
the DU and CU Virtual Baseband
Unit (vBBU) on a
COTS server Data Center
DU
Edge
Midhaul Backhaul
Backhaul CU Core Network
Connectivity between the CU
and the core network CU could be also deployed in the data center, but gains
for 4G are minimal

O-RAN SPLIT 7.2 RADIO UNIT
The purpose of the RU is to convert radio signals sent to and from the antenna to a digital signal that can be transmitted over
packet networks.
Open RAN RU consists of 3 functional components:
RF Front End (RFFE)

Radio Frequency Digital Front End (DFE)
Functional Block
(RF) function Functional Block
(connects to antenna)
Lower PHY Layer Using the eCPRI fronthaul

Synchronization and
Baseband Processing interface to map/de-map radio
Functional Block to reduce Fronthaul Transport
data into the Ethernet protocol
interface bandwidth Functional Block
and to connect to DU.
RF Front End Digital Front End Low PHY Fronthaul/Transport

eCPRI
PA DAC DPD CFR DUC FFT/IFFT
Ethernet
Filter UDP/IP
Antenna CP Digital Interfaces O-DU
LNA ADC PIMC optional DCC PRACH addition BF Synch
Precoding IEEE1588I
Power Supply RJ-45 LED

EVOLUTION OF RAN IS TOWARD DYNAMIC FUNCTIONAL SPLITS WITH OPEN RAN
RAN functionality is distributed between DUs and CUs The RIC (Non-Real-Time and Near-Real-Time) acts as
a mediator between the RAN and the core network.
Traditional RAN
These elements can be
collapsed together
eNodeB
Non-
Create a single physical RT RIC
entity with different virtual Near-
Open RAN
functionalities (CNF) RT RIC
CU-CP
DU
CU-UP

3GPP 5G RAN specification has defined a basic DU/CU split
design and distributed capability with virtualized functionalities. 3GPP, O-RAN Alliance and Small Cell Forum to continue
O-RAN ALLIANCE e.V. and Small Cell Forum have proposed to develop the specifications and architectures to support
enhancements to this base design with new variants. openness and interoperability in the RAN
MAC/PHY layer split (Small Cell Forum RAN 3GPP

Split functional Split)
gNB-CU
gNB-DU
(PDCP)
6 • MAC, RLC and upper layers are part of the CU
Option-2
(HLS) F1
• The full stack of the PHY layer and the RF are in
the DU/RU
• Best suited for small cell deployment
S-CU 3GPP S-DU SCF S-RU

Low PHY/High PHY split (O-RAN Alliance RAN (PDCP) MAC & RLC PHY & RF
Split functional Split)
Option-2 Option-6
(HLS) F1 (LLS)
7.2x • Supports various fronthaul requirements via eCPRI 5G-nFAPI
• Has been further defined by the O-RAN Alliance into
split 7.2a and split 7.2b
• Comes with fronthaul compression techniques i.e., O-RU
O-CU 3GPP O-DU O-RAN
BFP IQ compression and de-compression to reduce H-PHY, Low-PHY
(PDCP) Option-2
transport bandwidth further MAC, RLC Option- & RF
(HLS) F1 7.2x (LLS)
• Deployment scenarios with an ideal fronthaul for Open-FH
URLLC and carrier aggregation supports use cases
where efficient resource utilization from multi-RAT Image Source: Small Cell Forum
and multi-connectivity is needed

3GPP TS 38.401 decomposed the existing
baseband unit (BBU) into two functional
components, a distributed unit (DU) and
central unit (CU)
RAN functional splits
• Split
01of the functions of the Radio Access Network (RAN)
between centralized and distributed locations Lower-Layer Higher-Layer
Split Split
Protocol Layers
• CU provides support for the higher layers of the protocol RU DU CU 5GC
stack such as SDAP, PDCP and RRC L2 L2/L3 L3
• DU provides support for the lower layers of the protocol
stack such as RLC, MAC and Physical layers Fronthaul Midhaul Backhaul
Interfaces = open
• Lower-layer splits (LLS) = RU to DU connection = fronthaul Access Aggregation Core
• Higher-layer splits (HLS) = DU and CU connection =
midhaul
Image Source: Metaswitch Networks
Deployment options:
• A low latency service might require a CU be co-located with
the DU in the access layer

03
O-RAN FRONTHAUL INTERFACE
O-RAN ALLIANCE e.V. has defined a

01 multi-vendor fronthaul interface between
DU and RU based on Split 7-2x.
Service Management and Orchestration Framework
Non-RT RIC
O1
O2
In O-RAN terminology, RU is denoted as O1 A1
02 O-RU and DU is denoted as O-DU.

Near-RT RAN Intelligent
Controller (RIC)
E2 E2
X2-c
E1
X2-u
O-eNB
The fronthaul specifications include: O-CU-CP
03 • Control E2
E2
F1-c
CU-UP NG-u
Xn-u
Xn-c
NG-c
• User O-DU
F1-u
• Synchronization (CUS) and Open Fronthaul CUS-Plane Open Fronthaul M-Plane

Management (M) plane protocols as in O-RU
Control Plane (C-Plane) data (data

O-Cloud
section info, scheduling info, etc.)
between the O-DU and O-RU.

TRADITIONAL NETWORKS
• Baseband Unit (BBU) is designed as a “black box”
• BBU connects to a proprietary Remote Radio Unit

(RRU) through a vendor-specific implementation of the
Common Public Radio Interface (CPRI) protocol
• CPRI interface is proprietary to the equipment vendor
• CPRI interface is not an open interface: BBUs and
RRUs are required to come from the same vendor Closed Interfaces and
LLS 2 Box Proprietary
HLS 2 Box O-RAN
• CPRI can’t support high bandwidth demand 4G LTE XRAN/WG4 Hardware/Protocols
WG5 Jan 2018
2018
✓ Interoperable
Hardware with Open
3GPP introduced the DU and CU disaggregation as the evolution
PDCP CU O-CU
✓ Protocols
Open Networks
• CU provides support for the higher layers of the protocol
stack such as SDAP, PDCP and RRC F1 F1
• DU provides support for the lower layers of
the protocol stack such as RLC, MAC and Physical layer.
RLC
BBU
Ils-CU
✓
MAC O-DU
Introduction of midhaul provides more flexibility for PHY

DU +
transport options O-RAN FH
RU XRAN O-RAN
✓
eCPRI
PHY Low FH
• Lower-layer splits (LLS) = RU to DU connection = fronthaul
• Higher-layer splits (HLS) = DU and CU connection = midhaul CPRI RU O-RU Tested By:
RF RRH
O-RAN ALLIANCE e.V. expanded on the scope of what was

originally outlined by the 3GPP to ensure interoperability
between different hardware and software vendors Image Source: Keysight Technologies
• eCPRI is standard
• eCPRI enables interoperability through mix and match of
radios from one vendor and DU /CU software from another
deployed on a COTS server
• Supports demand for higher bandwidth

CPRI VERSUS eCPRI CPRI Protocol Overview
Common Public Radio Interface (CPRI): the interface between User Plane
Control and
Sync
the BBU and RU in 4G LTE Management Plane
Vendor Specific
• Proprietary to mobile equipment vendors
L1 Inbound
Ethernet
Protocol
HDLC
Layer 2 IQ Data
• Not an open interface: BBUs and RRHs are required to come
from the same vendor
• Creates a bottleneck as it’s based on transport of digital radio

signals directly over a point-to-point optical fiber Time Division Multiplex
Layer 1
Electrical Transmission Optical Transmission
• Creates a cost issue when a point-to-point fiber connection
needs to be made between multiple microcell RUs to BBUs
installed 20 km away
eCPRI Protocol Overview
• Requires a constant bit rate no matter the load and there is no
possibility for statistical multiplexing Control and
User Plane Sync
Management Plane
Enhanced CPRI (eCPRI)
eCPRI Protocol Layer SNMP PTP or SyncE
• An update to CPRI interface
• Uses Ethernet as the L2 interface
Layer 4 UDP UDP/TCP etc.
• Can use existing solutions for control, management, and synchronization.
• Ethernet allows packet-based switching and statistical multiplexing of
Layer 3 IP IP
several RU connections onto a single backhaul fiber
• Reduced cost of deploying RAN
Layer 2 Ethernet
The industry consensus is that the lower-level interface that connects RU
and DU (fronthaul) should be eCPRI, which delivers the lowest latency at Layer 1 Electrical or Optical Transmission
a lower cost. Specifies a number of RAN functional split options in the
protocol stack.

TRADITIONAL RAN VS OPEN RAN
TRADITIONAL RAN = No Choice, Open RAN = Choice,
No Interoperability, High Cost Interoperability, Lowest Cost
• Baseband Unit (BBU is designed internally as a “black box”) • Disaggregation of the “black box” with CU and DU
• COTS hardware for DU and CU
• BBU implementations vary from vendor to vendor • Any split based on bandwidth and latency between the
DU and RU
• BBU connects to a proprietary Remote Radio Unit (RRU) • Resource pooling as multiple RUs can be served
through a vendor-specific implementation of the Common through a single DU to achieve cost efficiency and power
Public Radio Interface (CPRI) protocol consumption reduction
Many fronthaul options allow operator to design their RAN based on user requirements and site-specific constraints
(i.e. power, space, connectivity, coverage, desired capacity)
PCIe CPRI
CU on COTS HW DU on Low-Cost Outdoor COTS HW RRU
Adapter
RRC PDCP High-RLC Low-RLC High-MAC Low-MAC High-PHY Low-PHY RF
Downlink
Data Option 1 Option 2 Option 3 Option 4 Option 5 Option 6 Option 7 Option 8
Uplink
Data

RAN functional splits 5G Core
• Split of the RAN functions between centralized and
distributed locations
• Protocol layers can reside in different components based
N1/N2/N3 Option 2 Option 7.2
on fronthaul availability/deployment scenarios AUSF UDM F1 Interface eCPRI
• TCO reduction
CU DUs RUs
PCF NRF
How to split NR functions in the architecture depends on
deployment scenarios, constraints/intended supported use cases
AMF SMF UPF
Backhaul Midhaul Fronthaul
• A need to support specific QoS per offered services (low
latency, high throughput for urban areas) and real/non-real
time applications
PCIe CPRI
• Support of specific user density and load demand per given area CU on COTS HW DU on Low-Cost Outdoor COTS HW RRU
Adapter
• Available transport networks different performance levels, from
ideal to non-ideal
Downlink
Higher functional splits = desirable for capacity use cases Data Option 1 Option 2 Option 3 Option 4 Option 5 Option 6 Option 7 Option 8
in dense urban environments with a high dependency on
fronthaul performance
• Option 8 = an alternative by putting all the physical layer (PHY)
functionality into the DUs; ideal for 2G and 3G Uplink
Data
• Option 7.2 = an optimal split between DU and RU (low-PHY in the
RUs and high-PHY in the DUs) with the bandwidth on the fronthaul
interface of 20 Gb for 100 MHz bandwidth with MIMO capabilities. Layer 3 Functions Layer 2 Functions Layer 1 Functions
Ideal for 4G and 5G and uses eCPRI interface.
Lower functional splits = the optimum solutions for rural + less than Image Source: Keysight Technologies
perfect fronthauls

RAN FUNCTIONAL
SPLITS
Split 8 Split 7 Split 6 Split 2
• RAN functional split CU/DU
PDCP PDCP PDCP PDCP
determines where RF
RLC RLC RLC
and digital
To Open RAN
processing happen. MAC MAC MAC
Controller
PHY PHY
RLC
• The higher the split, MAC
RRU
the “dumber” the
PHY PHY PHY
radio is, where it only
RF RF RF RF
processes RF.
CPRI Split PHY MAC/PHY PDCP/RLC
• Digital processing Delay IDEAL DELAY GOOD DELAY NON-IDEAL DELAY

~100us (one way) ~0.5-1ms (One way) ~1-10ms (One way)
happens in the BBU. Requirements
Why? Lower splits BEST PERF. LEAST PERF.

IMPROVEMENT IMPROVEMENT
can handle non-ideal
User Throughput
fronthaul (FH). 5200 Mbps 2600 Mbps 410 Mbps 410 Mbps (Reference):
370Mbps*
BEST FOR 2G, 3G | BEST FOR 4G, 5G | 4G Support of multiple splits on

the same RRU for ALL G

ONLY A SOFTWARE-BASED RAN CAN SUPPORT DYNAMIC AND FLUID RAN
FUNCTIONAL SPLIT OPTIONS
No single RAN functional split is going to fit all use cases.
Different use cases require different RAN functional splits based on fronthaul availability, functionalities, and capacity requirements:
Rural deployments
• Lower splits to handle low

RU CU
user density and lower
Fronthaul Latency
PDCP
capacity needs PDCP PDUs
MAC
PHY
RLC
RF
Split 2
Requirements
• With less than perfect FHs,
MAC PDUs
PDCP
it is logical to push more
MAC
PHY
RLC
RF
Split 6
protocol stack layers to the DU
Dense urban
PHY Low
Symbols/Bits
Fronthaul Capacity
PHY High
PDCP
Number of Users/
MAC
RLC
RF
Split 7.x
Traffic Density
Requirements
• Higher splits can provide
CoMP Effect
more throughput and will
handle higher user density
PDCP
IQ Time Domain
MAC
PHY
Split 8
RLC
RF
(C-RAN)
and higher traffic load
Fronthaul Functionalities Capacity
• With near perfect FH most of
the protocol can be located in
the CU

FUNCTIONAL SPLIT 6
RAN functional split 6 is a split for small cells. The Small Cell Forum (SCF) nFAPI (network FAPI) is an open interface
enabling any small cell DU/CU to connect to any small cell radio unit or S-RU.
Upper Lower
RLC RLC MAC RF
PHY PHY
O-RAN FH
FAPI
Split 7-2x O-CU and O-DU O-RU
nFAPI
FAPI
FAPI
Split 5 S-CU and S-DU S-RU
F1
FAPI
Split 2 CU DU
FAPI
Distributed Small Cell

RAN FUNCTIONAL SPLIT 7
Option 7 Split architecture is where the DU
handles the RRC/PDCP/RLC/MAC and higher
PHY functions, and the RU handles the lower
S1-MME
PHY and RF functions. CU functionality may RRU DU (+CU)
S6a
be embedded with the DU on the same

MME HSS
server, or it can be pushed up the network as
a virtualized aggregation entity.
S11
RRU
Option 7 allows mobile operators to:

S1- U S5/S8 SGi
vBBU
• Handle delay-sensitive services Option 7.2 Split
more efficiently.
(CU+)
RF L-PHY H-PHY MAC RLC PDCP RRC Aggregator S-GW P-GW Internet
• Take advantage of sharing or pooling

• For dense urban areas
gains while maintaining the lowest FEC / FEC-1
Modulation/
Demodulation • 3GPP and ORAN Compliant Split 7.2
processing utilizations on both the DU IFFT/FFT CP Data • RF and Lower-PHY are kept at RRU
Add / remove Layer
and RU resulting in the lowest TCO. (De) Mapping
Pre Coding
• Flexible architecture
• Deployment of 4G solution easy and seamless
Low-PHY High-PHY • Deployment is based on morphology and availability of fronthaul
and can adapt to necessary resources

RAN FUNCTIONAL SPLIT 8
Open RAN needs to support 2G,

3G, 4G, and 5G. What is the best
RAN functional split for 2G and 3G
S1-MME S6a
to run over 7.2 radios? RRU DU (+CU)
MME HSS
With traffic split 8, all functions (from PHY to S11

RRU
RRC layers) except for RF are handled by the
DU, while the RF layer is in the RU. RU runs
S1- U S5/S8 SGi
multiple technologies on the same FH interface
and utilizes eCPRI to connect to the DU
(CU+)
• Highly effective in 2G and 3G, where RF PHY MAC RLC PDCP RRC Aggregator S-GW P-GW Internet
traffic rates are much lower and processing

• 3GPP Compliant Split 8
itself is lower, and can be easily done on an • The baseband resource are centrally pooled/The RF and PHY are decoupled
x86 server Data • Allows to scale the network to accommodate many sectors
• Energy-efficient radio resource management
• Operators can use cost-optimized RUs with Option 8 • Software-centric and commodity h/w reduces cost further lowest TCO
minimal logic and processing split
• Allows for centralized traffic aggregation

from the RUs

DU CU IMPLEMENTATION
Purposes of separating:
• To reduce cost - less intelligent RUs cost less

• Ability to look at a sector of RUs at once (not just an individual RU)
• Resource pooling: processing is done in the DU
• For best latency support requirement, baseband functions DU
and CU software are decoupled from hardware and are deployed
RADIO
on NFVI or as containers Option 8
Option Option Option Option
7.2x 7.2x 7.2x 7.2x
The centralized baseband implementation:

CPRI eCPRI eCPRI eCPRI eCPRI
• Enables load-balancing among different components
• The DU is co-located near one/many RUs and conducts
SITE
DU-Containerized DU+CU-
AT
DU-Bare Metal DU-Bare Metal DU-Containerized
processing tasks such as Fast Fourier Transform/inverse Fast on VNF Containerized
Fourier Transform (FFT/IFFT) Option 2 Option 2 Option 2 Option 2 D-RAN
• Edge-centric baseband processing delivers low latency, local

breakout, seamless mobility with real-time interference
CENTRAL
management, optimal resource optimization CU-Containerized
CU-Bare Metal CU-Bare Metal CU-Containerized
on VNF
DU/CU software co-location on the same COTS server:
Variables:
• The split between DU/RU depends on the specific use case What type of x86 hardware should be used?
• and implementation (O-RAN ALLIANCE e.V. Option-7.2 & What are the key transmission latency & BW, consideration for each type of deployment?
Whether to use Bare Metal or Virtualization?
Small Cell Forum Option-6) System integration & commercial
• As the edge equipment is required to be compact/energy efficient,
co-location of DU and CU on site on one server reduces
deployment cost/complexity
BENEFIT: split architecture delivers interoperability, selection best-of-

breed components, and scalability for 2G, 3G, 4G, 5G baseband functions

DEPLOYMENT MODEL RU/DU/CU CO-LOCATED Use Cases:
AT CELL SITE • Areas with limited FH capacity
• Latency sensitive deployments
O-RAN-based architecture for 2G, 3G, 4G, & 5G
Virtualized cloud-native RAN software (vCU and vDU)
End-to-End Service Orchestration and Management
Open RAN
RU
Non-RT RIC
Ecosystem 2G 4G 2G 4G
DU
3G
DU
5G
CU
3G
CU
5G
Aggregator
DU DU CU CU
Packet Core
Container Container Near-RT RIC
Infrastructure
Virtual
Container Engine
Virtual Virtual
Host OS Infrastructure Infrastructure
vBBU
COTS x86 Server
Cell Site Cloud Edge Cloud Central Cloud

SCENARIO EXAMPLE
Mix and match hardware
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
DATA CENTER
and software components
Core
Use COTS hardware for Transport Network

DU and CU software
Open V2
RAN CU
EDGE
Open V3 V2 V4
RAN DU
Build best-of-breed
interoperable RAN Open C B A C B B C A B C
RAN RU

O-RAN ALLIANCE

O-RAN ALLIANCE TIMELINE
Merger of C-RAN Alliance and xRAN 2019 – O-RAN Software Community
2018 – O-RAN Alliance announced (OSC) is launched
and launched • Founding Operators: AT&T, China Mobile, Deutsche Telekom Global
Business, NTT DOCOMO Inc., Orange • A Linux Foundation project supported by
• Mission: Moving the RAN industry towards more intelligent, open, O-RAN to lead the implementation of the
virtualized and fully interoperable mobile networks O-RAN specifications in Open Source
Software releases
November 2019: Amber June 2020: Bronze

• Represents a consolidated step towards • A1 policy manager / A1 controller that implements the • A Traffic Steering/Quality Prediction use case leveraging an
O-RAN-compliant RAN Commercialization non-RT RIC architecture E2 interface to demonstrate the functionality of RAN traffic
steering w/KPI monitoring
• Initial functionality of the O-RAN unique • O-RAN E2 and A1 specifications with 5 sample xAPPs
Near Real-Time RIC, the O1 interface and • OAM use cases that exercise Health Check call flows
• Initial O-CU and O-DU Low/High
the protocol stack including the Near-RT RIC + O1 and A1 interfaces.
January 2021: Cherry

• New functionalities: the E2, A1 or O1 interfaces, & SMO elements
O-RAN First Amber Cherry E Release

Whitepaper specification Release Release
Released published
Feb 2018 Oct 2018 Apr 2019 June 2020 June/July 2021
Sep 2018 Feb 2019 Dec 2019 Dec 2020 Dec 2021
O-RAN O-RAN Alliance Launch of Bronze Dawn

Alliance Officially O-RAN Software Release Release
Announced Launched Community (OSC)

O-RAN EVOLUTION OF THE
NEXT GENERATION RAN
(NG-RAN) ARCHITECTURE The RIC is based on open standards
Introduced by O-RAN ALLIANCE O-RAN Alliance and helps to avoid vendor lock-in.
GSMA’s 3GPP in e.V. expanded on issues specifications
release 15 (5G the scope of what and releases open-
version 1) technical was originally source software
specification outlined by 3GPP under the The Linux Service Management and Orchestration Framework
TS 38.401 Foundation
Non-RT RIC
O1
Key elements of O-RAN Architecture: O2 O1 A1
• Service Management and Orchestration Framework (SMO) to manage and

orchestrate the O-Cloud from within Near-RT RAN Intelligent
Controller (RIC)
• RAN Intelligent Controller (RIC) software to control and optimize the

E2 E2
elements/resources of O-RAN X2-c
E1
O-CU- X2-u
O-eNB
• O-Cloud: a collection of physical RAN nodes that host the software for E2
CP
CU-UP NG-u
RICs, CUs, and DUs Xn-u
E2 F1-c Xn-c
F1-u NG-c
• O-RAN Central Unit (O-CU) hosts and manages protocols: radio resource O-DU
control (RRC), service data adaptation protocol (SDAP), and packet data Open Fronthaul CUS-Plane Open Fronthaul M-Plane
convergence protocol (PDCP)
O-RU
• O-RAN Distributed Unit (O-DU) hosts and manages: the radio link control
O-Cloud
(RLC) protocol, medium access control (MAC) protocol, and the physical
interface (PHY) that communicate to the RUs
• O-RAN Radio Unit (O-RU) processes radio frequencies received by the
RUs, sends processed frequencies to O-DU and managed by O-DU

O-RAN ALLIANCE
WG1: Use Cases and Overall Architecture
WG2: RIC (Non-RT) Focus on all identifying use cases and requirements, and planning overall WG9: Open X-Haul
and A1 Interface architecture of O-RAN and Proof-of-Concepts
Transport
Specify AI enabled RIC (non-RT) Focus on transport domain -
functionality for the operational consisting of transport equipment,
supervision, intelligent RRM; physical media and control/mgmt.
specify A1 interface Orchestration & Automation (e.g. ONAP); MANO, NMS
protocols associated with the
O-RAN Alliance role Inventory Policy RAN Intelligent Controller (RIC) Non-RT Configuration Design transport network underlying the
assumed Ethernet interfaces (for
• Define requirements O1 A1 O2 fronthaul, mid-haul, and backhaul)
WG3: RIC (Near-RT)
• Specify APIs and interfaces and E2 Interface RAN Intelligence Controller (RIC) Near-RT
• Drive standards for open and Specify RIC (near-RT) Applications Layer
WG10: OAM and O1
architecture that enables control 3rd Party Radio Connection Mobility QoS Interference Trained
intelligent RAN and optimization of RAN App Management Management Management Management Model Interface
Open Front Haul M-Plane

elements and resources via Focus on creating detailed OAM
E2 interface Radio Network Information Base architecture and requirements
E2: btw RIC Near-RT and CU/DU
and has full responsibility for the
O1 interface specifications
Multi-RAT CU Protocol Stack
CU-CP CU-UP
WG8: Stack Reference RRC
E1
SDAP
Design PDCP-C PDCP-U WG5: Open F1, W1,
Focus is to develop the software E1, X2, Xn Interfaces
architecture, design, and F1
Focus on design of Open CU,
O-RAN Alliance structure release plan for the O-RAN
Central Unit (O-CU) and O-RAN
NFVI Platform: Virtualization Layer and COTS Platform
RAN virtualization and splits
with related interfaces that
Distributed Unit (O-DU) based
• 10 work groups, 4 focus groups to on O-RAN and 3GPP O-DU: RLC/MAC/PHY-High
intersect with 3GPP
specifications
specifications
drive the specifications Open Front Haul CUS-Plane
• O-RAN Software Community (OSC) O-RU: PHY-Low/RF
WG6: Cloudification
to drive software contributions WG4: Open FH and Orchestration
• O-RAN Testing and Integration Interface Focus on specifying
Specify open front-haul virtualization layer and HW,
Centers to drive interoperability interface (NGFI-I) between DU WG7: White-Box Hardware decoupling VNF and NFVI
and AAY, based on C-RAN and Specify and release a complete reference design to foster a and MANO Enhancement
• Industry adoption through testing xRAN’s work (IEEE 1914,
decoupled software and hardware platform
eCPRI, CPRI)
and certification
• Global Plugfests
O-RAN ALLIANCE
WORKING & FOCUS GROUPS WG2: RIC (Non-RT) WG1: Use Cases and Overall Architecture
WG9: Open X-Haul
Focus on all identifying use cases and requirements, and planning
The O-RAN Alliance specification is divided into 10 technical and A1 Interface overall architecture of O-RAN and Proof-of-Concepts Transport
workgroups & 4 focus groups, all under the supervision of the Specify AI enabled RIC (non- Focus on transport domain -
RT) functionality for the consisting of transport
Technical Steering Committee. operational supervision, equipment, physical media and
Orchestration & Automation (e.g. ONAP); MANO, NMS
intelligent RRM; specify A1 control/mgmt. protocols
RAN Intelligent Controller
WG1: Use Cases & Overall Architecture Workgroup interface Inventory Policy
(RIC) Non-RT
Configuration Design associated with the transport
01 responsibility for the O-RAN Architecture & Use Cases network underlying the assumed
O1 A1 O2
Ethernet interfaces (for fronthaul,
and working across other O-RAN work groups. WG3: RIC (Near-RT) mid-haul, and backhaul)
RAN Intelligence Controller (RIC) Near-RT
and E2 Interface
Applications Layer
WG2: The Non-real-time RAN Intelligent Controller and A1 Specify RIC (near-RT)
02 Interface Workgroup to support non-real-time intelligent architecture that enables 3rd Party
App
Radio Connection
Management
Mobility
Management
QoS
Management
Interference
Management
Trained
Model
WG10: OAM and O1
control and optimization of Interface
radio resource management, higher layer procedure

RAN elements and resources Radio Network Information Base Focus on creating detailed
optimization, RAN policy optimization and providing AI/ML via E2 interface
OAM architecture and
models to near-RT RIC requirements and has full
responsibility for the O1
WG8: Stack CU-CP
RRC
E1 CU-UP
SDAP
interface specifications
WG3: The Near-real-time RIC and E2 Interface Workgroup
03 Reference Design PDCP-C PDCP-U
to define an architecture based on Near-Real-Time RIC Focus is to develop the
software architecture, design, F1
WG5: Open F1, W1,
NFVI Platform: Virtualization Layer and
and release plan for the O- COTS Platform E1, X2, Xn Interfaces
WG4: The Open Fronthaul Interfaces Workgroup to deliver Focus on design of Open CU,
04 truly open fronthaul interfaces to realize multi-vendor
RAN Central Unit (O-CU) and
O-RAN Distributed Unit (O- RAN virtualization and splits
O-DU: RLC/MAC/PHY-High with related interfaces that
DU) based on O-RAN and
DU-RRU iinteroperability 3GPP specifications Open Front Haul CUS-Plane intersect with 3GPP
specifications
O-RU: PHY-Low/RF
WG5: The Open F1/W1/E1/X2/Xn Interface Workgroup to
05 provide fully operable multi-vendor profile specifications for WG4: Open FH
F1/W1/E1/X2/Xn interfaces Interface WG6: Cloudification
Specify open front-haul and Orchestration
interface (NGFI-I) between WG7: White-Box Hardware Focus on specifying
WG6: The Cloudification/Orchestration Workgroup to drive DU and AAY, based on C- Specify and release a complete reference design to foster a virtualization layer and HW,
06 the decoupling of RAN software from the underlying RAN and xRAN’s work (IEEE decoupled software and hardware platform decoupling VNF and NFVI
1914, eCPRI, CPRI) and MANO Enhancement
hardware and produce technical/reference designs to allow
commodity hardware for RU, DU, CU, RIC.
Image Source: Keysight Technologies

O-RAN SOFTWARE
COMMUNITY IS A
COLLABORATION BETWEEN
THE O-RAN ALLIANCE AND
THE LINUX FOUNDATION Organization Tier
Mission: support the creation of software for the Radio
Access Network
LF Networking Deep Learning
Fund (LFN) Foundation
Initiatives: Project Umbrella /
Funding Tier
• Align a software reference implementation with the O-RAN
• Alliance’s open architecture and specifications.
• Achieve unified solution to accelerate Open RAN adoption
• Promote open source OPNFV ONAP Acumos AI Angel ML O-RAN SC O-RAN SCP
• Address wireless technology support for essential patents
Linux Foundation Open Source Projects
Groups
• The O-RAN Software Community = a Linux Foundation project
supported and funded by O-RAN to lead the implementation of Accelerator
Integration Non-RT RIC Near-RT RIC Adaptation O-CU O-DU
the O-RAN specifications in Open Source. The project Layer (AAL)
leverages the Apache 2.0 License. Development (Sub) Projects
• The O-RAN Specification Code Project = an O-RAN
Alliance project. Objective: allow contributions to
acknowledge essential patents. The project leverages the
O-RAN Software License.
Software Releases:
• Cherry (Dec 2020)
• Bronze (June 2020)
• Amber (Dec 2019)
O-RAN BENEFITS
Network CAPEX and OPEX reduction
01 CAPEX reduction through a multi-vendor ecosystem

delivering scale economics:
• O-RAN ALLIANCE e.V. open interfaces eliminate vendor lock-in
and facilitates multi-vendor
• Deployments for a more competitive and innovative supply chain
• Software hardware reference designs enable faster innovation Reduce Vendor Lock-In 29.7%
through a larger ecosystem
• Cloud-native architecture enables scalability for dynamic capacity,
reliability and availability Optimize Network and Service Costs 25.4%
O-RAN reduces OPEX RAN automation:

02 New Service and Monetization Opportunities 17.8%
• Intelligence in every layer of the RAN with AI/ML to automate
operational network functions, reduce operational activities
Enter New Geographies and Improve Coverage 16.1%
Network efficiency/performance/user experience

03 improvement
Enhance Quality-of-Service in Our Network 8.5%
• With RAN automation for resource management with real-time

monitoring real-time close-loop control with no human intervention. Don’t See a Business Justification for Open RAN 2.5%
• Interactions between Non-RT RIC and Near-RT RIC to optimize
fine-tune control algorithms for load balancing, mobility
management, multi-connection control, QoS management and
Image Source: Heavy Reading
network energy savings.
New capabilities can be deployed faster for network agility

04
• Network upgrades and new features are done via software
upgrade, with CI/CD

O-RAN ALLIANCE
ARCHITECTURE

O-RAN ALLIANCE ARCHITECTURE
O-RAN architecture alignment with 3GPP
3GPP defined in Release 15 and adapted

by O-RAN (hence “O” in front):
• O-RU (O-RAN Remote Unit): a logical node for a low-PHY layer + RF-based Non-RT RIC O1
on Lower-Layer Split
O2 O1 A1
• O-DU (O-RAN Distributed Unit): a logical node for RLC/MAC/ high-PHY
layers based on LLS
• O-CU-CP (O-RAN Central Unit-Control Plane): a logical node for RRC + CP
part of PDCP Controller (RIC)
• O-CU-UP (O-RAN Central Unit-User Plane): a logical node for SDAP + UP
part of PDCP E2 E2
• O-eNB (O-RAN eNodeB): the open evolved NodeB, hardware of 4G RAN X2-c
O-eNB E1 X2-u
O-CU-CP
E2 CU-UP NG-u
O-RAN defined: Xn-u
E2 F1-c Xn-c
NG-c
F1-u
• O-Cloud: a Cloud Compute platform of physical infrastructure for O-RAN
O-DU
logical functions and support software components (i.e., OS, VM, container), Open Fronthaul CUS-Plane Open Fronthaul M-Plane
management, and orchestration O-RU
• Near-RT RIC: a logical node for near-RT control/optimization of RAN
elements and resources via fine-grained data collection and actions over E2 O-Cloud
• Non-RT RIC: a logical node for Non-RT control/optimization of RAN
elements and resources, and policy-based guidance of applications/features
to Near-RT RIC
• SMO (Service and Management Orchestration) : a system supporting Diagram Source: O-RAN Alliance
orchestration of O-RAN components

O-RAN ARCHITECTURE INTERFACES
AND THEIR ALIGNMENT W/ 3GPP
O-RAN ALLIANCE e.V. interfaces:
01 • A1: between Non-Real-Time RIC and Near-Real-Time
RIC for Non-Real-Time RIC to provide Near-Real-Time
RIC with policies, enrichment information and ML
models for Near-Real-Time RIC to take action upon Non-RT RIC O1
in real-time O2 O1 A1
• E2 is between O-RU, O-DU, O-CU to control actions
within the BS, using monitor, suspend, override, control
messages, and execute actions coming from xApps in Near-RT RAN Intelligent
Controller (RIC)
Near-RT RIC, it provides data collection feedback path
from those entities E2 E2
X2-c
• O1 and Open-Fronthaul M-plane interfaces – a regular
FCAPS interface with configuration, reconfiguration, O-eNB E1 X2-u
O-CU-CP
registration, security, performance, monitoring with E2 CU-UP NG-u
logical entities: O-CU-UP, O-CU-CP, O-DU, O-RU,
E2 F1-c Xn-u
Near-real-time RIC NG-c
Xn-c
F1-u
• O2 interface – to manage the platform resources and O-DU
workload (i.e. resource scaling) Open Fronthaul CUS-Plane Open Fronthaul M-Plane
O-RU
Enhanced 3GPP interfaces
02 • F1, W1, E1, X2, Xn -- with O-CU-CP & O-CU- O-Cloud
UP for true multi-vendor interoperability
Diagram Source: O-RAN Alliance

THE TELCO EDGE TO CLOUD
ENABLED BY OPEN RAN
AND O-RAN ALLIANCE Near-RT
RIC
E2
E2
F1
Open
Fronthaul
Key
“O-Cloud” indicates that an O-RAN Cloud

Platform is used to support the RAN
O-CU O-DU O-RU functions. This will use hardware
UPF
accelerator add-ons as required by each
Open FH RAN function, and the software stack is
decoupled from the hardware. Each O-
Open RAN decouples hardware and Scenario A O-Cloud Proprietary Cloud uses open interfaces.
software into 3 vendor-agnostic layers Edge Cloud Cell Site

E2
to enable openness: Scenario B O-Cloud O-Cloud Proprietary Network Functions (e.g. O-CU + O-DU)
Regional Cloud Edge Cloud Cell Site O-Cloud

• COTS merchant silicon (including x86) F1 E2
• A hardware abstraction layer Scenario C O-Cloud O-Cloud Proprietary
Could be 100% proprietary, or a
• An application layer (RAN functions) Regional Cloud Edge Cloud Cell Site proprietary blade in an open chassis.
Scenario Uses open interfaces.
C1 & C2 O-Cloud O-Cloud Proprietary
O-Cloud: O-RAN Alliance to enable Regional Cloud Edge Cloud Cell Site Proprietary
cloudification and automation: Scenario D O-Cloud Proprietary Proprietary
Regional Cloud Edge Location Cell Site

• Specified list of requirements for a
Scenario E O-Cloud O-Cloud
cloud platform
• Support the execution of O-RAN Regional Cloud Cell Site
network functions Scenario F O-Cloud O-Cloud O-Cloud
Regional Cloud Edge Cloud Cell Site
Image Source: O-RAN Alliance

O-RAN ALLIANCE
REFERENCE ARCHITECTURE
Disaggregates RAN hardware from Inventory Policy
RAN Intelligent Controller
Configuration Design
Management
software:
(RIC) Non-RT
RAN software Policy
management
O1 A1 O2 and analytics
STANDARIZES RAN Intelligence Controller (RIC) Near-RT
Applications Layer
Time sensitive
01 RAN elements, including a unified interconnection 3rd Party Radio Connection Mobility QoS Interference Trained software: load
App Management Management Management Management Model
standard for white box RAN hardware balancing,

handover, and
interface
02 Open-source software elements from Radio Network Information Base detection
different vendors E2: btw RIC Near-RT and CU/DU

Time sensitive and management controller
03 CU-CP CU-UP
functionality (RIC) RRC E1 SDAP
PDCP-C PDCP-U
TO DELIVER F1
Modular software
O-DU: RLC/MAC/PHY-High
stacks on COTS
Open Front Haul CUS-Plane Open Front Haul M-Plane
White box radio

O-RU: PHY-Low/RF
hardware
Interoperability Competition Innovation into
the O-RAN
supply chain
O-RAN ALLIANCE INTERFACES
The key interfaces are as follows: The O-RAN Alliance is defining a minimum set of messages and the
range of values the contents of those messages can take, thereby
• Open Fronthaul M-plane or Management plane interface between SMO and O-RU
making RAN architecture intelligent and fully interoperable.
• A1 Interface between the Non-RT RIC in
the SMO and the Near-RT RIC for RAN Optimization Open interfaces:
• O1 Interface between the SMO and the O-RAN Network Functions for FCAPS support. • Benefits MNOs as it avoids vendor lock-in and enables interoperability
• FCAPS is based on the ISO model which defines five conceptual areas for managing • Benefits end-users as MNOs can improve coverage, add more capacity, and
networks: fault, configuration, accounting, performance, and security create new innovative solutions
• O2 Interface between the SMO and the
O-Cloud to provide platform resources and workload management
TYPICAL MOBILE NETWORK ARCHITECTURE
Components of 5G NR Mobile Network – O-RAN Architecture
Service Management and Orchestration (SMO) Framework

Legend
O-RAN Defined Interface
External
3GPP Defined Interface Non-RT RIC
system
Interface out of scope for O-RAN providing
Open A1 O1 O2 enrichment
Fronthaul data to SMO
M-Plane
Scope of O-RAN
Near-RT RIC
Service
E2
E2 VNFs E2
F1-C CU-CP Core Service
D
U
E1 S1/NG Network Service
RU
F1-U CU-UP
Service
COTS Hardware
(O-Cloud)
Image Source: Parallel Wireless
INTERFACES BETWEEN
COMPONENTS
O-RAN architecture integrates modular base station software stacks on
COTS hardware, which enables baseband and RU from different
suppliers to operate seamlessly together by using the following O-RAN
defined interfaces between the components:
Non-RT RIC
O1
The radio-side components and interfaces: O2 A1
• Near-RT RIC: E2 interface to enable near-real-time control

and optimization of O-RAN elements and resources via data
collection and actions Controller (RIC)
• O-CU-CP and O-CU-UP: enhanced 3GPP interfaces (F1, W1, E1,
Infrastructure Management
E2-en E2-cp
X2-c
X2, Xn) for true multi-vendor interoperability E1
Framework
X2-u
• O-DU and O-RU: E2 open fronthaul interface O-eNB O-CU-CP
E2-up O-CU-CP NG-u

Xn-u
E2-du F1-c Xn-c
The management-side components and interfaces: F1-u NG-c
O-DU
• Service Management and Orchestration Framework (SMO) Open Fronthaul Interface
§ O1 Interface between management entities SMO and O-RAN VIM

O-RU
managed elements
Infrastructure - COTS/White Box/Peripheral Hardware and
§ O1* interface between SMO and Infrastructure Management Virtualization Layer
Framework with O-RAN virtual network functions (NGVI)
• Non-RT RIC
§ A1 interface between non-RT RIC and near-RT RIC (modular CU) Image Source: O-RAN ALLIANCE e.V.

O-RAN ALLIANCE INTERFACES
Legend
The key interfaces are as follows: O-RAN Defined Interface
• Open Fronthaul M-plane or Management plane interface between 3GPP Defined Interface
SMO and O-RU Interface out of scope for O-RAN
• A1 Interface between the Non-RT RIC in the SMO and the Near-RT
RIC for RAN Optimization
External
• O1 Interface between the SMO and the O-RAN Network Functions for system
FCAPS support Non-RT providing
RIC enrichment
• FCAPS is based on the ISO model which defines five conceptual areas data to SMO
for managing networks: fault, configuration, accounting, performance, Open A1 O1 O2
and security Frontha
ul M-
• O2 Interface between the SMO and the O-Cloud to provide platform Plane
resources and workload management
Scope of O-RAN
Service
Near-RT
The O-RAN Alliance is defining a minimum set of RIC
Service
messages and the range of values the contents of VNFs E2 Core
Network
those messages can take, thereby making RAN S1 Service
architecture intelligent and fully interoperable.
Service
RU
BBU
Open interfaces deliver benefits: COTS

Hardware
Benefits MNOs as it avoids Benefits end users as MNOs can (O-Cloud)
vendor lock-in and enables improve coverage, add more capacity,

interoperability and create new innovative solutions
E2 NODES
• In a 5G RAN architecture, the BBU functionality is • Each of these CU & DU nodes are • The Near-RT RIC hosts one or more xApps
split into two functional units, the distributed unit considered an E2 node. which uses the E2 interface to collect near
(DU) and a centralized unit (CU). real-time information on a UE basis
• The O-RAN ALLIANCE e.V. define the E2 node as a • The Near-RT RIC control over the E2
• The interfaces between the DU and CU
logical node terminating the E2 interface. Nodes is guided by the policies and the
and between the CU-CP and CU-UP are
✔ For 5G NR, these include O-CU-CP, O-CU-UP, O-DU enrichment data which is provided by
all defined by 3GPP.
✔ 4G LTE, it is the O-eNB. Non-RT RIC via the A1 interface.
TYPICAL MOBILE NETWORK ARCHITECTURE
Components of 5G NR Mobile Network – O-RAN Architecture
Legend
O-RAN Defined Interface
External
3GPP Defined Interface Non-RT RIC
system
Interface out of scope for O-RAN providing
Open A1 O1 O2 enrichment
Fronthaul data to SMO
M-Plane
Scope of O-RAN
Service
Near-RT RIC
E2 VNFs E2
E2 Core Service
F1-C CU-CP
S1/NG Network Service
D E1
U
Service
RU
F1-U CU-UP
COTS Hardware
(O-Cloud)
O-RAN ALLIANCE
WORKING & FOCUS GROUPS O-RAN TECHNICAL STEERING COMMITTEE (TSC) 10 Work Groups (WGs)
10 WGs, 4 FGs, OSC, MVP-C WG1: Use cases and Overall Architecture
Working Groups:
WG2: RIC (Non-RT) and A1 Interface
• WG7: White-box Hardware Workgroup to specify and WG3: RIC (Near-RT) and E2 Interface
RAN Intelligent controller
release a reference design for a decoupled software and Inventory Policy
(RIC) Non-RT
Configuration Design
hardware platform. WG4: Open FH Interface

• WG8: Stack Reference Design Workgroup to develop the O1 A1 O2
software architecture, design, and release plan for O-CU WG5: Open F1, W1, E1, X2, Xn Interfaces
and O-DU based-on O-RAN and 3GPP NR protocol RAN Intelligence Controller (RIC) Near-RT
WG6: Cloudification and Orchestration
stack specs. Applications layer
• WG9: Open X-haul Transport Work Group focuses on 3 rd Party
App
Radio Connection
M anagem ent
M obility
M anagem ent
QoS
M anagem ent
Interference
M anagem ent
Trained
M odel
WG7: White-Box Hardware
transport equipment, physical media & control/management
WG8: Stack Reference Design

protocols of the transport network. Radio Network Inform ation Base
• WG10: OAM Work Group is responsible for the OAM WG9: Open X-Haul Transport
requirements, OAM architecture and the O1 interface.
Multi- RAT CU Protocol Stack WG10: OAM and O1 Interface
Focus Groups: CU-CP E1 CU-UP
RRC SDAP
PDCP-C PDCP-U 4 Focus Groups (FGs)
• SDFG: Standard Development Focus Group works on the
standardization strategies and main interface to other F1
SDFG: Standards Development
NFVI Platform: Virtualization Layer
Standard Development Organizations (SDOs). and COTS Platform
• TIFG: Test and Integration Focus Group defines O-RAN’s TIFG: Test and Integration
approach for testing and integration, including coordination
OSFG: Open Source
of test specifications across various WGs, planning and O-DU: RLC/MAC/PHY-High
coordination of the O-RAN Alliance, Plugfests and SFG: Security
sets guidelines for the 3rd party Open Test and Integration
Centers (OTIC). O-RU: PHY-Low/RF
• OSFG: Open Source Focus Group. Dormant as most Open Source Community (OSC)
activity happens in the software community.
• SFG: Security tackles security challenges on all O-RAN MVP-C: Minimum Viable Plan Committee
Red indicates new
interfaces and components, specifying and recommending
security solutions.

O-RAN ALLIANCE ARCHITECTURE IMPLEMENTATIONS
01 Disaggregated: 02 Aggregated: 03 Near RT RIC combined 04 All the functions (except
with O-CUs SMO) are combined
• All logical elements O-CU and O-DU logical • E2 interface to control • E2 interface is internal
are fully disaggregated functions are combined O-CUs is internal • Only a single O1
• Near-RT RIC has E2 • They form a single E2 • E2 interface towards connection
connections to each Node O-DU only from the • A1 interface is present
O-CU and O-DU • There is only a single E2 combined node
which are separated connection and a single
E2 Nodes. O1 connection
Disaggregated Aggregated
Disaggregated Network Functions Aggregated O-CU-CP, O-CU-CP, O-DU Aggregated Near RT-RIC, O-CU-CP, O-CU-CP All Nodes Aggregated
SMO SMO SMO SMO

O1 Non-RT RIC O2 O1 Non-RT RIC O2 O1 Non-RT RIC O2 O1 Non-RT RIC O2
A1 A1 A1 A1
Near-RT RIC Near-RT RIC Near-RT RIC Near-RT RIC
E2 E2 E2 E2
O-CU-CP O-CU-CP O-CU-CP O-CU-CP
E1
O-CU-UP E2Node
O-CU-UP E2Node O-CU-UP O-CU-UP
F1-c F1-u F1-c F1-u E2
O-DU O-DU O-DU O-DU
Open FH Open FH Open FH Open FH Open FH Open FH

M-Plane M-Plane M-Plane
O-RU O-RU O-RU O-RU
O-Cloud O-Cloud O-Cloud O-Cloud
Image Source: RIMEDO Labs

RIC

THE RAN INTELLIGENT CONTROLLER (RIC) DEFINED BY O-RAN ALLIANCE E.V. IS
SOFTWARE THAT CONNECTS THE APPLICATION LAYER TO THE INFRASTRUCTURE
(RADIOS) AND CONSISTS OF
A Non-Real-Time Controller (supporting tasks
01 that require > 1s latency)
02 A Near-Real-Time controller (latency of 1s)
• Within the SMO framework • Service and policy management

• Controls and optimizes Open RAN • RAN analytics
• Uses AI and ML for automation • Model-training for the Near-RT RIC
• Decides when to enforce policies that control routing and QoS
Latency
for Control
>>1s Wireless Domain Management AI O1 Use Cases

A1 Network Policy Enforcement
RAN Intelligent Controller AI Intelligence Handover Optimization
RAN
QoS Slicing Mobility 3rd Party Intelligent Resource Radio-Link Mgmt
10-100ms Optimization Optimization Optimization Application Assurance Advanced SON
Controller
RAN Data Analytics & AI Platform Resource Load Balancing
Control Slicing Policy
E2
• AI/ML for Programmability
• Platform Made Available in
RAN 3GPP E1 Open Source
Real-Time CU-CP CU-UP
• A1: Intent Based Interface
ORAN NGF-I • E2: RAN Closed Loop
DU RRU
• O1: For Data Collection and Control
Image Source: The Linux Foundation

RIC FEATURES
RAN Intelligent Controller (RIC) = logical function to
control and deliver intelligence in the RAN to optimally
allocate radio resources, implement handovers, manage Orchestration & Automation (e.g. ONAP); MANO, NMS
interference, balance load between cells. RAN Intelligent Controller
Inventory Policy Configuration Design
(RIC) Non-RT
Non real-time RIC = 1 sec or more to execute
(PROVIDES GUIDANCE)
A1
• Exists in the service management and orchestration
(SMO) framework
• Houses the policies that are reinforced the near
real-time RIC
• Manages ML models for the near real-time RIC
Applications Layer
to use for decision-making based on the
network’s condition 3rd Party Radio Connection Mobility QoS Interference Trained
• Provides the policies, data, and machine learning App Management Management Management Management Model Antenna
models necessary for RAN optimization by the
Near-real-time RIC
RAN Database
Near-Real-Time RIC = executes functions between
10 milliseconds and one second Multi-RAT Control Unit (CU) E2 RAN Distributed
Higher Layer Protocol Stack Unit (DU)
(EXECUTES GUIDANCE)
• Communicates between 1. the application layer, 2.
the non-real-time RIC, and 3. the infrastructure NFVI Platform NFVI Platform
layer (O-CU &O-DU) where O-CU has
disaggregated control and user planes to add CU-CP CU-UP F1
flexibility to RRC E1 SDAP PHY- PHY-
RLC MAC Open Fronrhaul RRU
the architecture High Low
PDCP-C PDCP-U
• Directly controls and optimizes the lower levels of
the RAN
• Uses AI and ML for to automate the RAN and to
enforce policies that control routing and quality of
service (QoS) Image Source: Techplayon

RIC BENEFITS O-RAN: OPEN RAN ALLIANCE
80+ Companies: Major Operators, Vendors, Startups
RIC (near-RT and non-RT) puts mobile operators in the
“driver seat” to deploy and manage their Open RAN with: New end-to-end architecture for 5G Robust ecosystem through Unified Operator Driven Standards
• Disaggregation to accelerate standardized interfaces Approach
Interoperability and vendor diversity innovation • Standardize A1, E2, O1, Fronthaul, • Influence and drive 3GPP standards
• Open, standardized, and clearly defined interfaces • Infrastructure ”Cloudification” X2, F1, E1, cloud interfaces • O-RAN-SC: Open source community
between the disaggregated RAN components and • RIC is key architectural element
between RAN control and associated control apps
• Enables third party xApps and rApps hosting
• Separation between RIC platform and xApps / Service Management and Orchestration Framework
rApps helps in enablement of new microservices
Non-RT RIC
Predictive and intelligent resource management Loop3: > 500 msec
• Logically centralized AI/ML driven network control A1 (policies, orchestration,
and global view of radio resources SON)
O2
• Dynamic and efficient resource management using
Near-RT RAN Intelligent Controller (RIC)
a global view of all the resources to minimize
Infrastructure Management Framework

Loop2: 20-500 msec
interference E2 (resource optimization)
• Dynamic load balancing using AI and ML to eliminate O-CU-
network congestion for better subscriber QoS CP O-CU-
F1 CP
• Data driven optimization leveraging RAN data with
AI/ML models for L3-L1 predictive intelligence F1-c F1-u
• Dynamic spectrum sharing among multiple sites
O-DU
Subscriber QoS
Loop1: per TTI/msec resource
• Dynamic integration of performance-based decisions Open Fronthaul Interface scheduling
with policy-based restrictions
• Low latency applications support O-RU
• Granular control and support across L3 to L1 to
VIM Infrastructure - COTS/White Box/Peripheral
dynamically assist with mobility, scheduling, beam Hardware and Virtualization Layer
management, etc.
https://o-ran-sc.org/
Image Source: AT&T and O-RAN ALLIANCE e.V.
O-RAN NON-REAL-TIME RIC
Non-Real-Time RIC logical function supports latency more than 1s
Non-RT RIC
and is a micro-service-based software platform to host micro-service-
based applications called rApps. It’s deployed as a VNF or CNF. A1 A1 A1
Near-RT RIC Near-RT RIC Near-RT RIC
Functionality:
E2 E2 E2 E2 E2 E2 E2 E2
Configuration Device Fault O-CU- O-CU-
O-DU
O-CU- O-CU-
O-DU O-eNB O-eNB
CP UP CP UP
management management management
Type 1: Near-RT RIC Type 2: Near-RT RIC Only Type 3: Near-RT RIC
Only Serving 5G Serving 4G and 5G Only Serving 4G
Performance Lifecycle management for all Source: O-RAN Alliance
management network elements in the network
Provides:
Non-RT RIC
• Non-real-time intelligent radio resource management. Network management
applications in Non-RT RIC receive and act on the data from the DU and CU
in a standardized format over the A1 interface A1 A1 A1 A1

• Higher layer procedure optimization
• Policy optimization in RAN by providing policy-based guidance, model E2 E2 E2 E2
management and enrichment information to the near-RT RIC function so O-CU-CP O-CU-UP O-DU O-eNB
that the RAN can be optimized
• Guidance, parameters, policies and AI/ML models to support the operation of
near-RT RIC. AI-enabled policies and ML-based models generate messages Implementation of one physical Near-RT RIC consisting of one
Source: O-RAN Alliance or more logical Near-RT RICs
in non-RT RIC and are conveyed to the near-RT RIC for the execution.
Image Source: O-RAN ALLIANCE e.V.

NEAR-REAL-TIME RAN NEAR-RT RIC xAPPS (RICAPP)
INTELLIGENT CONTROLLER (RIC): Primary Goals:

• A logical function defined by O-RAN Alliance to help intelligently manage Support Near-RTradio resource management via development and deployment of a
and orchestrate the RAN series of xApps that interact with one another and the external components via A1,
• A near-real-time, micro-service-based software platform O1, and E2 interfaces (O-CU/O-DU)
• Designed for hosting micro-service-based applications (xApps) i.e.,
• SON and ML workloads from any third-party provider
Planned xApps:
Key Functions
(1) Admission Control; (2) Measurement Campaign; (3) UE Manager;
01. Near-real time control and optimization (4) ML xApp; (5) KPI Monitor
• Handover management
• PTL: Matti Hiltunen (AT&T) • Project Documentation and Coordination
• Traffic and radio conditions monitoring in real-time
- Home
• RAN slicing, QoS control, enhanced RRM • Active participation from AT&T, - JIRA
• Enhanced radio resource management (RRM) with embedded AI/ML intelligence Nokia, Samsung - Meetings
• Per UE controlled load balancing, radio database management, interference
detection and mitigation • Status • Project Relations
- 14 epics defined; 5 completed; 8 - Near-RT RIC
02. Collection and maintenance of historical data on traffic, navigation, in-progress; 0 blocked; 1 deferred - Non-RT RIC
radio, and hand over data to REL 8 - OAM
03. Interaction with non-real-time RIC • 5 xApps being worked for Amber:
• Guidance on optimization - Admission Control (AC)
• AI/ML models - Measurement Campaign
- UE Manager
04. Provides xApps cloud-based and interoperable infrastructure - ML-Based AC
• Control of a distributed collection of RAN Infrastructure (eNB, gNB, CU, - KPI Monitor
and DU) via the southbound E2 protocol of the O-RAN Alliance logical
architecture • xApp interaction methods
• A unifying element to help build solutions combining RU/CU/DU - Using RIC Message Router (RMR)
elements with xApps from a mix of vendors - Using Shared Data Layer (SDL)

O-RAN NEAR-REAL-TIME RIC
Near-Real-Time RIC logical function supports latency of 1s Service Management and Orchestration (SMO)
and is a micro-service-based software platform to host micro-
service-based applications called xApps. It’s deployed as a Non-RT RIC
VNF or CNF.
O1 A1
Provides:
• xApps cloud-based infrastructure for controlling a distributed O1 Termination A1 Termination Near-RT RIC APIs for xApp
collection of RAN infrastructure (eNB, gNB, CU, DU) in an
area via the O-RAN Alliance's E2 protocol ("southbound").
• "Northbound" interfaces for operators: the A1 and O1
interfaces to the Non-RT RIC for the management and …
optimization of the RAN. xApp 1 xApp 2 xApp N
API Enablement
Responsible for:
Messaging Infrastructure
• Handover management and traffic monitoring
- AI and ML to detect and predict what’s affecting Subscription Management
Conflict Mitigation Security
Management Services
devices during handover and steer traffic
Shared Data Layer
- Deploying and maintaining real-time applications
capable of predicting, preventing, and mitigating E2 Termination
Database
handover patterns and irregularities
• Collecting and maintaining historical data on RUs, traffic, E2
and handover data
E2 Nodes
• Monitoring, suspension, override or control the node via
Non-RT RIC enabled policies

NEAR-REAL-TIME RIC
IMPLEMENTATIONS
Non-RT RIC
Near-Real-Time RIC = key element in the O-RAN architecture A1 A1 A1
Near-RT RIC Near-RT RIC Near-RT RIC

• A logical function defined by O-RAN Alliance to help intelligently
manage and orchestrate the RAN
• Logical function internal to the SMO in O-RAN architecture that E2 E2 E2 E2 E2 E2 E2 E2
provides the A1 interface to the Near-Real-Time RIC O-CU-
CP
O-CU-
UP
O-DU
O-CU-
CP
O-CU-
UP
O-DU O-eNB O-eNB
• Its functions take one second or more to be completed

Type 1: Near-RT RIC Type 2: Near-RT RIC Only Type 3: Near-RT RIC
• Uses the E2 interface to connect with the O-CU and Only Serving 5G Serving 4G and 5G Only Serving 4G
O-DU Functions
Source: O-RAN Alliance
• Functions include service and policy management, RAN analytics
and model-training for the RIC near-RT functionality
Near-RT RIC can be deployed centralized or distributed

Centralized Near-Real-Time RIC
Non-RT RIC
• Supports 4G and/or 5G
• gNB (O-CUs and O-DU) or eNB are handled by the same near-RT A1 A1 A1 A1
RIC instance
• Makes unified decisions for each base station and the overall RAN
network, across 4G and 5G services E2 E2 E2 E2
• Allows unified optimization across the entire RAN network and

O-CU-CP O-CU-UP O-DU O-eNB
provides 4G and 5G operations
Distributed Near-Real-Time RIC

Implementation of one physical Near-RT RIC consisting of
• Each E2-Node is handled by a logical entity of near-RT RIC Source: O-RAN Alliance one or more logical Near-RT RICs
• Allows optimizing of the individual type of the managed entity
Image Source: Parallel Wireless Architecture: O-RAN ALLIANCE e.V.
NON-REAL-TIME RIC
• Logical function internal to the SMO in O-RAN architecture that
provides A1 interface to the Near-Real Time RIC R-App
OSC Non-RT RIC
Catalog
Control Panel
• Its functions take one second or more to be completed
• Uses the E2 interface to connect with the O-CU and Non-RT RIC Apps/Control Loops
O-DU functions R-Apps
R-Apps E2 Producer
R-Apps
R-Apps Stub
• Functions include service and policy management, RAN
analytics and model-training for the RIC near-RT functionality
A1 Policy API (REST) OMaap A1 F1 API
SDNC Controller (REST)
• Non-RT RIC controls and dynamically optimizes elements and CCSDK A1 F1

A1 Policy Management Service Microservice
resources with detailed data collection: (ONAP CCSDK) Deployed as
(REST)
Part of SDNC
- By using application-level data & information, cross-domain Internal Adapter API
information, UE positions and mobility trajectories and
A1 F1 (REST)
Converged A1 Enrichment
external information. A1 Adapter Information
- By providing policy-based guidance, ML model management A1 Adapter Coordinator
(ONAP CCSDK/SDNC)
and enrichment information to the near-RT RIC function so
that RAN can be optimized and perform intelligent radio
A1 Enrichment
A1 Policy
resource management in non-real-time (O-RAN WG2)
(O-RAN WG2 2.0)
- By assisting with service assurance A1 Interface

A1 gNB/Near-RT RIC
Policy
• Non-RT RIC leverages SMO services such as data collection (OSC)
and provisioning services of the O-RAN nodes to optimize OEM RAN OSC Near- OSC Near-RT OSC Non-RT RIC Apps
the network Function RT RIC RIC/A1 Simulator OSC Near-RT RIC ONAP
Proprietary
RAN Functions RAN Function
• Life Cycle Management Framework (LCM of rApp and xApp
using SMO) is defined in Cherry release

NON-REAL-TIME RIC
01 Non-Real-Time RAN Intelligent Controller
(Non-RT RIC) is the logical function internal to
the SMO in O-RAN architecture that provides
the A1 interface to the Near-Real Time RIC
logical function Other SMO Framework
Non-RT RIC rApp 1 rApp 2 rApps … rApp n
Functions
Inherent SMO Framework Functionality
R1 (Open APIs for rApps)
SMO Internal
02 Non-RT
01 RIC supports intelligent RAN Interface
External EI
optimization by providing policy-based SMO Service Non-RT RIC Framework Service
Sources
External EI
Interface Exposure Function Exposure Function
External EI
guidance, ML model management and External AI/ML Termination
Function 1 rApp Service Exposure Functions
Non-RT RIC Framework

enrichment information to the Near-RT RIC Interface
External AI/ML
External AI/ML Other Non-RT rApp A1 Policy Functions
Function n
Termination
Servers
function so that RAN: RIC Framework
Functions
Management
Functions A1 EI Functions
AI/ML Workflow
• Can be optimized Human-Machine
Implementation
Variability Functions
A1 ML Functions
Interface
• Perform intelligent radio resource Human-Machine Inherent Non-RT RIC Framework Functionality
Local Craft
Terminal
Termination A1 Termination
management in non-real time Inherent SMO Framework Functionality
O2 Termination O1 Termination SMO Framework
Non-RT-RIC leverages SMO services such O2 O1 A1

03 Near-RT RIC
as data collection and provisioning services O-Cloud
E2 Nodes
of the O-RAN nodes to optimize the network
Inherent Non-RT Inherent SMO
Implementation O-RAN
RIC Framework Framework Internal
Variability Defined External Interface
Functionality Functionality Interface
04 Life Cycle Management Framework (LCM of Interface
rApp and xApp using SMO) is defined in

Cherry release Image Source: O-RAN ALLIANCE e.V.

SERVICE MANAGEMENT ORCHESTRATION
The next-gen management and orchestration defined by O-RAN
Alliance e.V. consists of these interworking components:
• Service Management and Orchestration (SMO) framework

• Non-Real Time Radio Intelligent Controller (RIC)
• RAPPs
• Interfaces O1, O2 and A1 allowing for communication between SMO (Orchestrator)
these components. O2
O-RAN Alliance’s Workgroup 6 has been developing a reference

Infrastructure Management Deployment Management
architecture for a cloud platform architecture and the orchestration
Services Services
(SMO) layer.
Deployment Plane
Complete (Network Functions - VNFs/CNFs)
Storage
Acceleration
SMO delivers:
O-Cloud Resource
O-Cloud Instance
• Optimization of capacity costs through infrastructure visibility to scale Pool
compute resources up and down
O-RAN O-Cloud and SMO Relationship
• Fast and automated life cycle management of PNFs, VNFs and CNFs
with CI/CD
• Application performance awareness to place application workloads Image Source: Radisys Corporation.
across multiple distributed cloud resources
• Automation and operational efficiency with AI/ML
• Monitoring and assurance of a specific SLA
• Closed loop of management, control and KPI reporting back to SMOs to
improve network performance

CLOUD-NATIVE OPEN RAN

WHAT IS CLOUD-NATIVE OPEN RAN?
Microservices Cloud-native App

• Modularize Open RAN functions: RU, DU, CU
• Scale up to optimize the RAN performance
• Independent in-service upgrade/downgrade
Containers
• Instantiate/Scale/Heal Open RAN functions
faster
• Increase resource utilization
DevOps Continuous Delivery
Continuous Delivery and Continuous

Integration (CI/CD)
• Faster delivery of any RAN software changes
• Faster time to market
DevOps
• Shorten the systems development lifecycle
• Provide continuous delivery with high software Microservices Containers
quality

OPEN RAN MICROSERVICES AND CONTAINERS
To optimize performance, software implementation evolves from monolithic, self-contained apps on dedicated servers to
microservices deployed in containers
Microservices = decomposition of an app into many, each running A container = a lightweight, standalone, executable package of
in a container software that includes everything needed to run it: code, runtime,
system tools, system libraries, environment
• Microservices are deployed, upgraded, scaled, and restarted
independently of other microservices, using an automated • Multiple containers can run on the same machine/share the
system, enabling updates to live applications without impacting OS kernel
the end-user experience
• A microservice is hosted in a container and exposes APIs to BENEFITS: Containers take less space than VMs, offer
access the service it offers efficiency/speed, can start immediately
BENEFITS:
App App App
• Easy to address any performance issue by
spinning up multiple instances of the Gues Gues Gues
App App App
microservice with an issue t OS t OS t OS
Cont Cont Cont
• Different RAN function components can be VM VM VM
ainer ainer ainer
implemented as separate microservices and
can be scaled up/down to optimize the Application Hypervisor Container Engine
performance Host OS Host OS Host OS

• Upgrades can be pushed without taking
down the entire site (few test cases) Bare metal
Purpose Built COTS x86 Server COTS x86 Server
Hardware
Parallel Wireless #OpenRANdailyfact Image Source: Parallel Wireless. 62

DEVOPS AND CI/CD
DevOps and CI/CD enable fast integration, changes and lifecycle
management of Open RAN software from different vendors to test
under one umbrella to deliver on business needs and end user Code Deploy
Pl
an
needs with: as
e
Build
Operate
DEV ele OPS
R
A more interconnected Less risk through Mo
nito
Test r </>
ecosystem of Open frequent delivery of
RAN vendors that new features and new
PACKAGE
fosters innovation by optimizations while
supporting multi-vendor increasing efficiency Container Registry
CNF onboarding and via automation NPM Registry
VERIFY RELEASE
lifecycle management Maven Repository
GitLab Pages
Canary
Updates are delivered to sites quickly and can be monitored to Feature Flags
determine how they impact end users and whether they meet the CONTINUOUS DELIVERY
✓ ✓ ✓ ✓ ✓ ✓ Click to Deploy to Production
pre-determined business goals with:
✓ ✓ ✓ ✓
Automated validation Updates pushed to CONTINUOUS INTEGRATION
of stack templates for 1,000s of sites to run Automatically Build and Test CONTINUOUS
DEPLOYMENT
containers to host them as a service Automatically Deploy
microservices E Code Quality Deploy to Production
E Performance Testing Review
App
E JUnit Tests GitLab Releases
E Container Scanning Deploy Boards
E Dependency Scanning Auto Deploy
End result: implementing a CI/CD model in the

telecommunications industry helps to migrate the testing, integration,
software release and deployment from manual fieldwork to automated
and remote deployment, eliminating mistakes and shortening the time Image Source: GitLab
window for upgrades.

OPEN RAN AUTOMATION

OPEN RAN AUTOMATION
To make Open RAN automation successful, the architecture
needs to be cloud-native:
• Microservices to push out RAN upgrades to as many sites
as needed with only a few test cases
• Microservices packaged in containers to allow changes Automation

to only a specific microservice in a single container
independently of other microservices Artificial Intelligence and analytics (AI, ML, etc,)
• Automation is used for scaling, testing, and allocating Telco Edge

software and underlying hardware resources as it enables:
• Integration of software and hardware from different Cloudification of core systems (BSS, OSS, ect.)
vendors during the deployment stage with:
Network cloud: NFV, SDN, ect.
• ZTP (zero touch provisioning) avoids performing
any manual tasks as sites get configured
automatically and fast
• Hands free upgrades during the maintenance stage -0.4 -0.2 0.0 0.2 0.4 0.6 0.8 1.0 1.2
• CI/CD enables fast changes to software. The
Weighted score (+ is faster, - is slower)
updates delivered to sites can be monitored to
evaluate how they impact end users, and if they
are achieving the business goals. Other Vendor Telco
• AI/ML: AI will be responsible for analyzing data and
using ML algorithms to adjust network conditions to
ensure the best subscriber experience. To get the weighted score, we weighted respondents choosing ‘major uplift’ = 2,
• Analytics is a visual tool to see and understand ‘minor cut’ uplift = 1, ‘minior cut’ = -1, ‘major cut’ = -2.
patterns or abnormalities in the network, how they
affect the subscriber experience, and what needs
to be corrected to improve network performance
Image Source: STL Partners.

ROLE OF AUTOMATION IN OPEN RAN
Cloudification brings ZTP: zero-touch CI/CD: continuous AI and ML Analytics
operational agility, provisioning integration/continuous • 80% of mobile operator responders stated that they plan to use AI • A tool to see and
enables automation and • No manual tasks development to automate network operations as soon as 2021 (Omdia) understand what’s
to configure the • Helps automate testing, • Responsible for analyzing data and using ML algorithms to adjust going on in the
elasticity
cell sites integration, software network (load balancing, ICIC, managing handoffs seamlessly) network and how
• Cloud-native functions
release, and software • Ensures that the subscriber gets the best experience possible those changes
(containers/microservices)
deployment • ML provides intelligence/response to take different actions on the affect the subscriber
are the foundation of
• Reduces development time network as i.e., scaling experience
Open RAN
from hours to minutes • Delivers operational efficiency, flexibility
• Upgrades 1,000s of sites • Enables proactive action and predicts the future with certain
instantly accuracy. A preventative action can be taken to avoid a similar
situation in the future
Stages of network to automate

SITE
DATA CENTER DATA CENTER
Setting Up Network Testing and Upgrade Optimization

Bringing Up a Site
Environment
ZTP CI/CD AI/ML

Virtual Environment Commissioning + Provisioning: Latest Software Upgrade + SON Analytics Feed into AI/ML
CNF/VNF Service Specific Parameters Automated Testing Analytics Loop
• Eliminates Manual Tasks • Automates Software • Automates Network

Upgrades Parameters Based on Data
• 1,000s of Sites

CI/CD IS A SET OF PRACTICES CU
THAT ENABLE HOW DU
SOFTWARE GETS DELIVERED RT

RIC AGILE DEVELOPMENT CONTINUOUS INTEGRATION
Daily Standup
NRT
RIC Commit Build + Unit Test + Code Quality
2 Weeks
Continuous
CI - Continuous Integration Feedback
Product Stage Backlogs Final Product DEV Code Repository Cl Server
• The practice of merging all developers’
working code to a shared mainline
several times a day
• Validating every merge before merging Process User Code Quality Repository
Flow Chart Inputs Metrics Manager
to uncover any issues Agile
Continuous DevOps Continuous
Feedback Feedback
CD - Continuous Delivery/Deployment
• Deliver software any time on demand CONTINUOUS DELIVERY CONTINUOUS TESTING
• All changes delivered to a
joint environment
Product Infrastucture as Collaboration Test Scripts Test Suite
code
Continuous
Delivering to Open RAN Feedback
Auto Ticket Creation
UAT
• Faster and automated software updates
Provisioning Cl Server Issue Tracking Cl Server
• Webscale application approach Tools
QA
• Ability to roll back
Repository Manager Testing Metrics INT UAT QA
Customer
Satisfaction
OPEN RAN INTEGRATION

OPEN RAN INTEGRATION
There are two levels of integration required when integrating
Open RAN:
• Open RAN ecosystem integration of the hardware and software
with site and data center infrastructure
• System integration of the Open RAN software on COTS hardware =
the same DevOps tools and CD/CI to simplify Open RAN
integration with automation
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Open RAN Integration Models
Model 1 (MNO integrates themselves):
Core
• Requires strong and active operator involvement -- the in-house
vision, skills and capabilities are necessary for integrating new
Transport Network
technologies successfully
• The long-term costs are lower as compared to those of vendors V2 CU Software Vendors
selling proprietary kits Open RAN CU
COTS Vendors
• Benefits from continuous innovation in the hardware and servers,
driven by the openness in the ecosystem V3 V2 V4 DU SoftwareVendors
Open RAN DU
COTS Vendors
Model 2 (a hardware or software vendor integrates):
• Provides support for hardware (radio and antenna integration) and Open RAN RU C B A C B B C A B C RU Vendors
software integration to ensure the radio units and distributed units
are fully interoperable
Model 3 (using a system integrator):

• A system integrator and in-house resources implement
virtualization for DevOps style with continuous development and
continuous integration of the software to enable automation
• Provides the flexibility to change the hardware or software vendors

INTEGRATION OF OPEN RAN
INCLUDES HARDWARE AND
SOFTWARE INTEGRATION Open RAN integration models
FROM MULTIPLE VENDORS. Managed by Operator or SI
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Option 1: System Integrator (SI)
Core
Transport Network Vendors Integration

Management
V2 CU Software
Option 2: Mobile Operator Open RAN CU
COTS
• In-house vision
• Skills V3 V2 V4 DU Software Operator
Open RAN DU or SI
• Capabilities COTS
Open RAN RU C B A C B B C A B C RU Vendors
That is why integration blueprints by Telecom Infra

Project and O-RAN ALLIANCE e.V. can help
accelerate deployments.

TELECOM INFRA PROJECT
(TIP)

TELECOM INFRA PROJECT
Telecom Infra Project leads the advancement of global Open RAN deployments from standards to commercial solutions through self-certification, testing
and badging against common industry requirements and partners on:
Open-Source Software: SD-RAN, Open Test and Validation: TIP and O-RAN
Interface Specs: 3GPP, O-RAN Alliance
Networking Foundation (ONF) ALLIANCE e.V.
OpenRAN an Industry Collaboration

OpenRAN Productization
01 02 03 04 05 06
Interface Common Vendor Test & Field Trials & Adoption &
Specifications Requirements Build Validation Deployments Proliferation
SW A SW A SW A
HW A HW A HW A
TIP Exchange
OTIC
Open Source SW
TELECOM INFRA PROJECT OPEN RAN KEY TENETS
Disaggregation of RAN hardware Multiple architecture options, including Solutions implemented on either
and software on vendor neutral, support of O-RAN Alliance architectures: bare metal or virtualized as VNF or
GPP-based platforms • An all-integrated RAN with containerized platforms as CNFs
disaggregation at the software and
hardware level
Open Interfaces – Implementations • A split RAN with RU, vBBU (consisting Innovation via adoption of new
using open interface specifications of DU/CU software) technologies for automation with
between components (i.e. • A split RAN with RU, DU and CU DevOps (AI/ML, CI/CD)
RU/DU/CU/RIC) with vendor neutral • A split RAN with integrated RU/DU, CU
hardware and software. software
Supply chain diversity for
Flexibility – multi-vendor solutions enabling interoperability and TCO reduction
a diverse ecosystem for operators to
choose best-of-breed options for their
2G/3G/4G and 5G deployments
User Mast EnodeB Cell Site Aggregation Core Mobile Core Internet
Equipment (RRU Gateway Router Router (MSC, MME, HSS,
vBBU or BBU) SGW, PGW…)
Image Source: TIP.

TELECOM INFRA PROJECT OPEN RAN REFERENCE ARCHITECTURE
TIP’s Open RAN program supports the development of disaggregated and interoperable 2G, 3G, 4G, 5G NR Radio Access Network (RAN) solutions based on MNOs’ requirements.
Multiple architecture options, including: Open Interfaces = Flexibility – Multi-vendor Solutions implemented Innovation via
Implementations using open solutions enabling a diverse on either bare metal, adoption of new
• An all-integrated RAN with
interface specifications ecosystem for the operators virtualized, or technologies
disaggregation at the software and
between components to choose best-of-breed containerized platforms (AI/ML, CI/CD) for
hardware level (RU/CU/DU/RIC) with vendor- options for their 2G/3G/4G network automation
• A split RAN with RU, BBU (DU/CU)
neutral hardware and software and 5G deployments
• A split RAN with RU, DU and CU
• A split RAN with integrated RU/DU, CU
Open RAN Reference Architecture

OAM/NMS AI/ML Apps
System Integrator Management Control
APIs APIs APIs
Software Software Software Software
Hardware
Fronthaul Midhaul Backhaul
Image Source: TIP Air interface

TIP OPEN RAN PROJECT SUB-GROUPS
Component Sub-Groups
RU (white box): DU/CU:
Develop RU white box hardware Develop DU/CU white box
built on open and disaggregated hardware built on open and
architecture to offer significant disaggregated architecture and OpenRAN Subgroups
deployment/operational cost reduction requirement docs
COMPONENT SUBGROUPS SEGMENT SUBGROUPS

Radio Intelligence and ROMA (orchestration and
Automation (RIA): lifecycle management):
RU Whitebox(4G/5G)
Enable MNOs & Open RAN Aggregating/harmonizing
ecosystem to collaborate on MNOs’ requirements on Open
Outdoor
RAN use case development, RAN orchestration and lifecycle
testing and deployments that management automation, DU & CU Whitebox(4G/5G)
leverages Data Science and fostering ecosystem partners to
AI/ML and open interfaces develop products/solutions that
based on industry standards meet ROMA requirements
Radio Intelligence & AI/ML use cases for
Automation (RIA) MaMIMO, RRM and SON
Segment Sub-Groups Indoor
• Outdoor: Address the challenges of large-scale, outdoor Open RAN deployments by ROMA OpenRAN orchestration
& life-cycle management
defining requirements, aggregating technology solutions and developing playbooks for automation
outdoor solutions based on macro-Open RAN configuration for various outdoor macro
segments, 1. rural 2. peri-urban and 3. urban
Image Source: Telecom Infra Project
• Indoor: Addresses the challenges of large-scale, indoor 5G NR small cell deployment

TIP OPEN RAN TEST AND INTEGRATION Domains
GROUP (F.K.A. PLUGFESTS)

Core
01 GOAL 1: A Multi-Party Test To
• Help hardware and software vendors improve interoperability between

disaggregated components
• Reduce the need for individual vendors and MNOs to replicate similar
tests = saves cost and effort
• Create deployment blueprints (a collection of documents: a reference Transport
design, use case and associated requirements, an architecture
schematic illustrating the main components and interfaces, as well as list
RAN Access Including RAN
of the components tested) to accelerate deployments
Functional Area
02 GOAL 2: Interoperability and Integration
• Interworking between RU, DU, CU functions to test compatibility with Performance
interfaces already standardized for the DU-CU and RU-DU by 3GPP

and the O-RAN Alliance to enable plug-and-play across vendors
• Overall site solution integration to operationalize site deployment,
Inter – Stability &
including install, power supply, batteries, redundancy, cabling, Opportunity Sensibility
antenna, transport, and switches
Via: TIP community labs or other TIP-authorized labs, collate and release test-
related deliverables as defined independently or in conjunction with other TIP
Project Groups. Security
Parallel Wireless #OpenRANdailyfact Image Source: Telecom Infra Project 76

OPEN RAN AUTOMATION PROJECT
GROUP BY TELECOM INFRA PROJECT
Monitoring & Control
Group Goals
• Design, validate and publish a library of composable automation “building Cellsite

blocks” that support service provider efforts to orchestrate the lifecycle
automation of services deployed across end-to-end multi-domain networks Wireless
• Improve: Backhaul
- User experience
- Operator agility
- The operational economics associated with the planning, deployment Router
Cellsite
and assurance of the end-to-end network services that network
operators sell to their customers
Accomplished Through
Router
DCSG
• Designing and developing the requirements, architectures and workflows to Core
automate the network Router
• Collaboration with existing TIP Project Groups and/or other third parties to
incorporate existing artifacts (processes, workflows, automation blocks, APIs, data Data
models, etc.) to utilize industry standards from O-RAN Alliance and 3GPP Center
• Validating automation designs through implementation in the TIP Community Lab
Image Source: TIP

TCO

O-RAN BENEFITS: NETWORK
CAPEX AND OPEX REDUCTION
01 CAPEX reduction through a multi-vendor ecosystem
delivering scale economics
• O-RAN open interfaces eliminate vendor lock-in and facilitate
multi-vendor interoperability
• Allows for a more competitive and innovative supplier chain
• Open-source software and hardware reference designs enable
faster innovation through a larger ecosystem Reduce Vendor Lock-In 29.7%
• Cloud-native architecture enables scalability for dynamic capacity,
reliability, and availability
Optimize Network and Service Costs 25.4%
O-RAN reduces OPEX with RAN automation

02 New Service and Monetization Opportunities 17.8%
• Intelligence in every layer of the RAN, with AI/ML to automate
operational network functions and reduce operational activities
Enter New Geographies and Improve Coverage 16.1%
Network efficiency/performance/user
03 experience improvement
Enhance Quality-of-Service in Our Network 8.5%
• RAN automation for resource management with real-time

monitoring and real-time close-loop control with no human Don’t See a Business Justification for Open RAN 2.5%
intervention
• Interactions between Non-RT RIC and Near-RT RIC to optimize
and fine-tune control algorithms for load balancing, mobility
management, multi-connection control, QoS management and Image Source: Heavy Reading
network energy saving
New capabilities can be deployed faster for network agility

04
• Network upgrades and new features are done via software
upgrade, with CI/CD

RAN AND TCO
The RAN is at least 60% of any Automation Enhances Network Lifecycle
cellular network’s Total Cost of
Ownership (TCO) when combining SITE
Capital Expenses (CAPEX) and DATA CENTER DATA CENTER
Operating Expenses (OPEX).
• CAPEX (deployment cost itself)
is around 30%
• OPEX (maintaining the
network) is around 70% of the Setting Up Network
Bringing Up a Site Testing and Upgrade Optimization
TCO value Environment
Cloud Automation ZTP CI/CD AI/ML

Reducing OPEX is key for Commissioning/Provisioning: For Latest Software Upgrade + AKA SON Analytics Feed into
Management and Operation
long-term profitability Service Specific Parameters Automated Testing AI/ML Analytics Loop
Of Cloud Infrastructure
Automation is one of the main tools that affects mainly OPEX and lowers overall TCO spending across different phases of the network lifecycle. Phases of the network
lifecycle include:
Building datacenter capabilities that ZTP (Zero Touch CI/CD (Continuous Integration and Continuous Optimization is the last phase in the deployed
support Network Function Provisioning) helps ensure Delivery/Deployment) is purely focused on ongoing network network lifecycle, and it directly affects OPEX costs
Virtualization (NFV) and that any automation will be operation. Successful “CI” means new code changes to an since it deals with remote site/network optimization.
containerization (CNF) is the first as autonomous as possible app are regularly built, tested, and merged to a shared Until the introduction of automation, this task was
phase of building a network. The first with minimal user repository, significantly simplifying the development process. conducted manually by multiple teams – each team
priority is setting up a scalable virtual intervention beyond basic Successful “CD” is about automating additional stages of having expertise in certain domains and requiring
definitions and rules. delivery and deployment. Continuous delivery means that extensive travel and manual labor. Now that this
environment with cloud-native
changes to an application are automatically bug tested and phase utilizes automation, it means not only that it will
network functions to easily scale
uploaded to a shared repository where they can be deployed be done at a fraction of the cost but, more
services from basic to advanced. to a live production environment by the operations team. importantly, it will be done more quickly. This enables
Continuous deployment means that released software the network to react much faster to changes while
updates/versions from a shared repository can be deployed optimizing shared resources and potential savings.
to production with minimal delays.
TCO SAVINGS WITH OPEN RAN
Savings Potential of Network Virtualization Benchmarks
CAPEX savings TCO savings

Savings due to larger choice of vendors
Claims to have 40% savings on OPEX & 30% savings in CAPEX
30-50% with Open RAN vs. vRAN
Reports that Open RAN reduces CAPEX for 5G by up to 50%

37-44% compared to 4G
D-RAN/C-RAN vRAN/oRAN
Reduced OPEX by 53% and CAPEX by 30% with savings in power
consumption (cooling), site rental fees, onsite management an repairs
OPEX savings
Mainly based on site rental and cooling
cost reduction
40-53% ”We have had trials taking commercial traffic for about a year now.
It is a 2G, 3G and 4G trial and it is live and KPI (key performance)
are really good and in some cases better than the incumbent.”
”Cost was the main reason Inland Cellular tuned to an Open RAN
network by Parallel Wireless, Chip Damato said, estimating the
technology has cut the price of each cell site by 40 precent, to about
Image Source: Publicity data: Arthur D. Little analysis $20,000. That is an important consideration as telecom companies
Parallel Wireless #OpenRANdailyfact
build 5G systems, which reqire more cells.” 81
USE CASES

OPEN RAN OPTIMIZATION
Optimization = efficient provisioning of networking Inventory Policy RAN Intelligent Controller (RIC) Non-RT Configuration Design
resources to users and services to maintain quality
of experience (QoE) and quality of service (QoS) O1 A1 O2
Applications Layer
3rd Party Radio Connection Mobility Interference
QoS Management Trained Model
AI to communicate across the network and optimize App Management Management Management
network use:

• AI uses algorithms to recognize traffic and analyzes network Radio Network Information Base
health to determine how to provision resources E2: btw RIC Near-RT and CU/DU

• ML models train AI in a non-real-time RIC as there is no need
CU-CP CU-UP
to respond to anything in real time RRC E1 SDAP
PDCP-C PDCP-U
• Near real-time RIC enforces the decisions made by AI in the
near real-time RIC, as timing affects the QoE F1
Adaptive QoS policies for dynamic resource allocation O-DU: RLC/MAC/PHY-High

used by non-real-time and near real-time RICs:
• Non-real-time RIC takes information on resource demand and
selects users to prioritize for O-RU: PHY-Low/RF

AI AND ML WILL ELIMINATE THE MAJORITY OF MANUAL TASKS AND
OPTIMIZE THE RAN
ML algorithms to adjust AI is responsible for analyzing data AI/ML algorithms will
network conditions from all sources Be responsible for
- Proper load balancing, ICIC, managing - Reinforcement of ML algorithms in real-time - Forecasting parameters
handoffs seamlessly – all to ensure the
subscriber gets the best experience possible - Deployed as an xAPP in the Real-time RIC - Detecting anomalies
- Algorithms and training built in non-real time - Predicting failures
- Deployed as an rAPP in the non-real time RIC - Projecting heat maps
- Classifying components into groups
End result: proactive action and the ability to predict the future with certain accuracy to take preventive actions on the network
Data Results
Data
Knowledge Feedback
Connected Things Future Wireless Machine Learning Artificial Intelligence

Networks
Image Source: CableLabs
OPEN RAN USE CASES
01 Handoffs 03 Traffic Steering

- Consistent connection as users move - AI predicts network conditions (congestion) so the
from base station to base station RIC can find an optimal path to send traffic across
the network
- Automation and intelligence assist in traffic steering
Optimization (QoE, QoS, and

02 Massive MIMO)
04 Resource Sharing
- Networking resources are provisioned and - The operator that owns the deployment offers a
optimized for better QoE and QoS portion of the resources to the hosted network
operator
- O-RAN Alliance standardizes AI to optimize
resources across the network - The hosted operator 1. uses the Near-Real-Time
RIC or remote configuration and control of the VNF
- Non-Real-Time RIC (uppercase) takes controlling the network 2. to monitor the RAN
information on resource demand and selects infrastructure to meet its SLAs
users to prioritize for resource allocation
- Near real-time RIC enforces the resource

allocation in the O-DU and O-CU
Image Source: O-RAN Alliance
OPEN RAN USE CASES Table 1: O-RAN use cases phases and specification support
Impacted Impacted
Interfaces to Interfaces to
Impacted support the use support the
Handoffs Use Case Class Type Impacted Entities
WGs case with use case with
Current O-RAN Future O-RAN
Specs Specs
- Consistent connection as users move from base station to base
station Low Cost Radio Phase I White-box WG7 Open Fronthaul - O-DU, O-RU
Access Network Hardware Interface
- White-box Design
Optimization (QoE and QoS)
Hardware
Traffic Steering Phase I AI-Enabled RAN WG1, WG2, O1/A1 E2 Non-RT RIC, Near-RT
and Open WG3 RIC, O-CU
- Networking resources are provisioned and optimized for better QoE RAN Interfaces
and QoS (O1/A1/E2)
- O-RAN Alliance standardizes AI to optimize resources across the
network QoE Optimization Phase I AI-Enabled RAN WG1, WG2, O1/A1 E2 Non-RT RIC, Near-RT
- Non-real-time RIC takes information on resource demand and select and Open WG3 RIC, O-CU
RAN Interfaces
users to prioritize for resource allocation (O1/A1/E2)
- Near real-time RIC enforces the resource allocation in the O- DU and
O-CU
Massive MIMO Phase I AI-Enabled RAN WG1, WG2, O1 A1/E2 Non-RT RIC, Near-RT
- Traffic Steering Optimization and Open WG3 RIC, O-CU
RAN Interfaces
(O1/A1/E2)
- AI predicts network conditions (congestion) so the RIC can find an QoS Based Phase I AI-Enabled RAN WG1, WG2, A1 O1/E2 Non-RT RIC, Near-RT
optimal path to send traffic across the network Resource and Open WG3 RIC, O-CU
Optimization RAN Interfaces
- Automation and intelligence assist in traffic steering (O1/A1/E2)
- Resource Sharing
RAN Sharing Phase II Virtual RAN WG1, WG2, O1/O2/E2 Non-RT RIC, Near-RT
Network WG3, WG6 RIC, O-CU, O-DU
- The operator that owns the deployment offers a portion of the

resources to the hosted network operator
RAN Slice SLA Phase II AI-Enabled RAN WG2, WG3, O1/O2/A1/E2 Non-RT RIC, Near-RT
- the hosted operator 1. uses the near real-time RIC for remote Assurance and Open WG6 RIC, O-CU
configuration and control of the VNF controlling the network 2. to RAN Interfaces
(O1/A1/E2)
monitor the RAN infrastructure to meet its SLAs
Parallel Wireless #OpenRANdailyfact Image Source: O-RAN Alliance 86

SLICING
3GPP defines Network Slice Management Function (NSMF) & Network Slice
Subnet Management Function (NSSMF).
O-RAN ALLIANCE e.V. architecture provides standardized management

service interfaces for RAN slicing management services
• Supports interoperability
• Enables multi-operator/multi-carrier deployment scenarios Regional
Edge Cloud Call Site
• Supports RAN slices management in multi-operator/multi-carrier scenario Cloud
O-CU
• O-CU-UP can be shared across slices and can be instantiated per slice
• Executes slice specific resource allocation and isolation strategies
• Generates and sends PMs through O1 and E2 interfaces as per the request
from SMO or Near-RT RIC
Network Slica O-CU-
O-DU Subnet #1 UP
• Can be shared between multiple slices S-NSSA1=1 Near- O-CU- O-RU
O-DU
• Supports slice specific resource allocation and PRBs isolation strategies RT RIC CP
• Generates and sends specific PMs through O1 and E2 interfaces as per the
O-CU-
request from SMO or Near-RT RIC Network Slica UP
• PMs are used for performance monitoring and slice SLA assurance Subnet #1
S-NSSA1=2
Non-RT RIC
• Aware of RAN slices, slice configuration and performance
• Feed into AI/ML models for slice assurance and optimization over O1
interface
Near-RT RIC Image Source: O-RAN Alliance

• Dynamic slice optimization over E2 interface
• Collects slice performance metrics
• Applies its algorithms
• Ensures SLAs

RAN SHARING
RAN sharing = an efficient way to reduce the network deployment
costs, while increasing network capacity and coverage.
The open & multi-vendor O-RAN architecture accelerates the

RAN sharing
Edge
“Home” operator owns a deployment and hosts other operators Server
on the network
4G eNode8
• The deployment and configuration of virtual RAN network functions LTE eNode8
on commodity shared hardware
MME SGW PGW
• Each operator configures the shared network resources Edge
independently Server
• “Home” operator makes available its RAN infrastructure and Evolved Packet
computing resources to host the virtual RAN functions (VNF) of a Core IP Network
E-uTRAN
“Host” operator
• Each VNF represents a logic implementation of the O-DU and O-CU
The “Host” operator monitors the network to meet its service

Edge Server
level agreements (SLAs)
BSS/OSS 5GC IMS
• The O-RAN architecture facilitates the remote control and Virtualization Layer
5G RRU DU(vR
configuration of VNFs via E2 interface AN)
• O1/O2 interface is introduced to allow the “Host” to communicate CU(vR

AN)
the configuration for the VNF hosted at the site
RRU DU(vRAN)
• “Host” operator uses the O-RAN Alliance’s near real-time RIC and
interfaces for remote control of the virtual network functions (VNFs) 5G Core
5G NR RAN Cloud
that run the network
• Provides the monitoring of the remote users’ performance and
optimization of the radio allocation process and the remote Legacy Proprietary Hardware Open Hardware Platform
configuration of QoS parameters
Image Source: IEEE ComSoc

TRAFFIC STEERING
Traffic steering = evolution of mobile load balancing to achieve optimal traffic distribution based
on objectives to effectively steer traffic to improve network efficiency/enhance user experience
OSC Bronze at a glance
TRADITIONAL NETWORK
RICAPP (PTL, Traffic Steering Component Interaction
Traffic control optimization requires manual intervention = inefficient/passive Matti Hiltunen) and xApps being developed
- The feedback response is slow
- The RRM (Radio Resource Management) features are cell-centric and do
RMR (QOE-PRED-REQ)
not address the radio environment (coverage of adjacent cells, signal
strength, interference) QP driver
QP xApp
RMR (A1 POLICY: group id)
xApp
- Base stations treat all UEs similarly and are focused on cell-centric
performance, not UE-centric RMR (QOE-PREDICTION)
RMR (TS-UE-
O-RAN ALLIANCE e.V. architecture improves network flexibility/agility: LIST,list)
SDL get SDL get
SDL get
Cell UE TS xApp
RAN automation Metrics Metrics
- RAN intelligence reduces manual intervention and human errors SDL update
- Saves OPEX
KIPMON E2 CONTROL
- Has faster response/more efficient to traffic problems
E2Term
RAN intelligence customizes UE-centric strategies
- Provides proactive optimization by predicting the network condition and E2 REPORTS
UE performance, improving user experience
CU- CU-
- Non-RT RIC and Near-RT RIC control traffic steering strategies through DU
UP CP
- AI/ML learning
- Provides AI models/policies and RAN control/guidance for A1 and E2
interfaces. The data used for ML is collected via the O1 interface from
the O-CUs/O-DUs Image Source: O-RAN Alliance

QOE OPTIMIZATION
Quality of Experience (QoE) is required for bandwidth-
consuming/traffic-intensive applications Orchestration ONAP/OSS
- Dynamic traffic volume is generated by user interactions
- The radio transmission capabilities change fast
Legacy RAN architecture cannot support QoE for these apps A1 O1 FCAPS
- Static QoS framework
- Overprovisioning QoS during the peak traffic demand can
xApp
deliver QoE
RIC xApp
mgmt xApp RMR
messaging xApp
O-RAN ALLIANCE e.V. Architecture supports real-time and high xApp
bandwidth demands LCM
• With RAN Intelligent Controller and open interfaces, AI models

deployed to optimize QoE of these services RIC E2 E2 E2
• Multi-dimensional data is acquired/processed via ML algorithms to
support traffic recognition, QoE prediction and guiding close-loop
QoS enforcement decisions real-time
De-composed RAN RRH
• ML models are trained offline in Non-RT RIC w/ O1 interface RRC
collecting data for training
PDCP-C
• Model inference is executed in Near-RT RIC via A1/E2 interfaces to CU-UP
deliver the policy/intents/AI models and RAN control to enforce the F1 E1
QoS for the QoE optimization
RRH DU CU-UP
• The O-CU supports data provisioning to Near-RT RIC and Non-RT
F1
RIC, and executes QoS enforcement decisions for Near-RT RIC
The radio resources are allocated to the user/services where the radio
resources are urgently required real-time for QoE Image Source: O-RAN Alliance

QOS BASED RESOURCE
OPTIMIZATION IN O-RAN
CHALLENGE: The legacy RAN configuration and planning are
not sufficient to provide the resources needed for services with
Automation and Orchestration
highly demanding coverage and capacity requirements for high NMS, NFV MANO, ONAP, . . .
bandwidth and low latency.
A1 (O-RAN)
O-RAN ALLIANCE e.V provides the QoS based resource policies Near-Real-Time RIC
- To allocate the correct bandwidth and to perform closed loop optimization in Near-Real-Time Control and Optimization Algorithms
real time to allocate radio resources to the UE before the QoS is degraded
RIC-Level RRM Quality of Experience QoS Slices RIC-Level SON
- The Non-RT RIC and Near-RT RIC to optimize how RAN resources are
allocated between users with similar requirements
ML/AI-Based RAN Analytics
- In a congestion situation, Non-RT RIC prioritizes certain user(s) utilizing the

same service in a particular situation using the QoS based resource Radio Network Information Base
optimization policy to ensure that prioritized users can reach a satisfactory
level of QoS
…
… E2 (O-RAN)
- Multi-dimensional data is acquired and processed via ML algorithms to
Disaggregated Open Multi-RAT Protocol Stack
support traffic recognition, QoS prediction, and guiding close-loop QoS
eNB/gNB eNB/gNB eNB/gNB
enforcement decisions
CU
X2/Xn F1 X2/Xn
- The A1 QoS policies re-allocate RAN resources between users utilizing the
DU
same service
F2/Open Fronthaul
RU
- Near-RT RIC can realize these policies on O-CUs/O-DUs through
the E2 interface
Image Source: Research Gate

DEPLOYMENT
USE CASES
Open RAN is NOT just DEPLOYMENT SCENARIOS
for greenfield 5G.
Open RAN is being deployed for:
Does not require expensive towers,
Open RAN can be installed
ANYWHERE
• Coverage/Network
Expansion: providing new Interoperable Open RAN
coverage to areas without approach enables vendor
diversity and cost reduction
mobile service Rural Urban and 4G Expansion and Network Modernization
Dense Urban 5G Readiness and Sharing
Self-configuration and self-
• Urban/Densification: adding optimization with Open RAN
controller and business intelligence
capacity to existing 2G/3G/4G (SON) module
networks
Automated for lower OPEX
• Network Modernization:
replacing legacy technologies Flexible, future-proof backhaul
including satellite and microwave
(i.e.: 2G, 3G) with cloud- Vodafone Turkey removes the expense and complexity
of fiber backhaul
native Open RAN to reduce
TCO/OPEX
Lowest Deployment TCO
IpT Peru

OPERATOR VIEWS

VODAFONE’S VIEW ON OPEN RAN
Why Open RAN?
• Flexibility: Operators can select “best” vendor

as “best” changes over time
• Vendor diversity: Encourage innovation
• Lower cost
• Lower barrier to new entrants 5G 3.5
GHz OPEN RAN
antenna RADIO Unit HW
Can be purchased
from any OPEN O-RAN Open
To Make It Work: RAN HW Vendor interface
2G / 3G /
4G / 5G Any OPEN RAN
• Industry collaboration and alignment Radio unit vendor SW can
• Purchase orders work on this HW
• Disaggregation Baseband OPEN RAN Base
unit COTS server
• Hardware supports software from
(Bare Metal /
any vendor Virtualized)
• GPP
• Open interfaces
• White box solutions
• Product range and performance comparable
Image Source: Vodafone
• with existing vendors

MOU Scope Agreement
OPEN RAN MOU BY DEUTSCHE Article 2
TELEKOM GLOBAL BUSINESS, ORANGE, The signatories individually commit that OPEN RAN will be the technology of choices for RAN.
The signatories commit to an early rollout of OPEN RAN technologies in individually relevant
TELEFONICA, TIM AND VODAFONE quantities to support the development of a healthy ecosystem.
The signatories will collaborate to support OPEN RAN reaching competitive parity with
Goal: support the rollout of Open RAN as the tech for future mobile networks to traditional RAN solutions as soon as possible.
benefit consumer and enterprises in Europe
- Networks can be deployed/operated based on mix-and-match components from Article 3. Scope of the Collaboration
different suppliers based on open standards/specs for hardware and software The signatories agree to jointly work on the following OPEN RAN topics:
- Supplier innovation to drive cost efficiency and flexibility
3.1 Support the continued development and recognition of OPEN RAN specification and standards
through O-RAN Alliance and other standard setting organizations to enable a
Work with ecosystem partners, industry bodies O-RAN ALLIANCE e.V. and true multi-vendors environment.
Telecom Infra Project (TIP), European policy makers to ensure Open RAN 3.2 Support standard setting organizations to resolve missing concepts and specifications in the
quickly reaches competitive parity with traditional RAN area of management, orchestration and operation of OPEN RAN, as required, for example, to
support the O-Cloud medal.
Timeframe: Open RAN ready for large scale network roll-out from 2022 onwards 3.3 Support the unification of the concept of OPEN-RAN technology around the industry approved
O-RAN architecture to avoid ambiguity in the industry and to provide related guidance for rollout
of OPEN-RAN.
Macro deployment is the primary target 3.4 Encourage a competitive European OPEN RAN ecosystem of technology providers and System
Integrators, thus strengthening the European RAN industry.
O-RAN ALLIANCE-based architecture: 3.5 Promote to European policy makers and industry that adopting a competitive OPEN RAN
ecosystem will place Europe and European industry at the front in the race of technological
- O-RU and O-DU/O-CU are interoperable leadership.
- A Cloud Infrastructure (O-Cloud), based on General Purpose Processors (GPPs)
3.6 Inform national authorities and Government on the OPEN RAN ecosystem, benefits, progress
and accelerators, running Containerized Network Functions (CNFs) and timelines (e.g. standardization, R&D development) and seek Policy support.
- A non/near real-time RIC for automation/optimization
3.7 Seek funding from European Governments; to support and develop the OPEN RAN ecosystem,
- A Service Management and Orchestration (SMO) framework managing the RAN
early deployments, R&D activities and test labs, and European suppliers and startups.
nodes, the Transport, and the Cloud Infrastructure in a unified manner
- The Open Fronthaul interface is key to enable a disaggregated, multi-vendor RAN 3.8 Prioritize individually implementing OPEN RAN technology, as well as securing resources for lab
testing and field trials.
Collaboration is the key to success. 3.9 Exchange testing best practices and lessons learnt after tests or deployments.

ORANGE OPEN RAN VISION Virtualisation and Openness can bring unlimited flexibility
and accelerated innovation to mobile networks.
• The rollout of Open RAN as the
technology of choice for the benefit
of consumers and enterprises
• Networks are deployed/operated From
based on mix-and-match traditional
components from different RAN to
suppliers based on open standards O-RAN
• Supplier innovation to drive cost
efficiency & flexibility
• Open RAN to have full
performance and feature "parity" CU
with traditional systems in the next
two to three years L3 RIC
BBU
• Can already be deployed today in F1 E2
rural areas and for indoor coverage L3
• Starting in 2025, Orange will only DU O-CU
deploy equipment that is L2 L2 F1
compatible with specifications
developed by the O-RAN Alliance O-DU
L1 L1
• The Open Fronthaul interface is
key to enable a disaggregated, FH
multi-vendor RAN
RRH RRH O-RU O-RU
Traditional Virtualised Disaggregated
Parallel Wireless #OpenRANdailyfact

Image Source: Orange 96
AT&T O-RAN VISION
Has been involved in a number of standards and
technology groups involved in Open RAN: ONAP, Plans to begin adding open RAN-
Gradual intro to ensure network reliability,
the O-RAN ALLIANCE e.V, Open Networking compliant equipment into its network
integrity, and performance at scale
Foundation (ONF) and Telecom Infra Project "within the next year"
RAN ARCHITECTURE EVOLUTION : DISTRIBUTED TO CENTRALIZED
3GPP 5G (R15) 3GPP 5G (R15) O-RAN

3GPP LTE Consensus Target 5G Target
ONAP
ONAP
A1
CU-CP (H)
A1
CU-CP B1
CU-CP (L)
F1 E1
RU DU
RRH BBU RU DU CU RU DU F1 E1
CU-UP
F1
CU-UP
3GPP
3GPP eNB 3GPP Split Option 2-2 study Option 2-2 study
Split Option 2 (PDCP / RLC split) (control plane / user plane split)
w / interoperable B1
Image Source: ATT

DISH NETWORK DISH’S 5G NETWORK ARCHITECTURE: CLOUD-NATIVE 5G RAN (5G NO-RAN) AND 5G SA CORE ON AWS
O-RAN VISION 01
Public 5G network/Private 5G network (Network Slicing)
5G NF (CNF)
• Open RAN-based 5G
# of AWS Local Zones in the U.S.:
• Cloud-native Thousands of AWS Outposts located in
Currently 4, 15 by the end of the year
# of AWS Regions In the U.S. : 6
Dish’s network
• Network hosting in a public cloud Altiostar OSS BSS
(Amazon Web Services (AWS)) 5G 0-RAN
Altiostar Mavenirz Mavenirz AltiostarNokia
Mavenirz Nokia
• Edge computing to use AWS Local
Nokia
DU CU UPF AMF,
AMF,
SMF..
SMF..
Zones (hubs in population centers) 5G RAN RU 5G RAN DU 5G RAN CU 5G UPF 5G Core CP
Japan Fujitsu (Korea NFVI NFVI NFVI

and AWS Outposts (enterprise HFR) Taiwan MTI AWS Outpost AWS Local Zone AWS Region
location or a base station) to process
In Dish network AWS infrastructure on Internet
workloads at the network edge
Dish’s Public Cloud 5G Network on AWS
• Delivering flexibility and scalability to
Network Slicing (Separation of traffic between companies by allocating slices for each corporates customer)
scale up or down
• Budget: $10 billion for the build out
02 Public 5G network (on-premise)
• A standalone 5G broadband network
available to at least 70% of the US
population by June 2023
• Private use cases are a big part of
Dish’s 5G business 5G 0-RAN
DU/CU 5GC
5G 0-RAN
NFVI
AWS Outpost
Customer on-premise
www.hfrnet.com &www.netmanias.com
Image Source: Hfnet

INTERNET PARA TODOS (IPT)
The world’s largest Open RAN deployment to
date with hundreds of operational sites providing
4G coverage
• A new company launched in May 2019 and

owned by Telefonica, Facebook, IDB Invest
and CAF banks.
• IpT Peru aims to provide internet connectivity to
users in remote regions of Peru.
• Open RAN technology brings flexibility and agility
to the deployment and management of an
access network.
• The Open RAN Controller creates a multi-vendor,
multi-operator, open ecosystem of interoperable
components for the various RAN elements and
from different vendors.
• All new radio units are self-configured by
the software, reducing the need for manual
intervention.
• The self-optimization capability automates
optimization across different RANs in IpT Peru's
network, utilizing available RAN data from all RAN
types (macros and small cells).
• Creates an open business model, where MNOs
can partner with local companies that focus on rural
coverage to enable lean cost structure that fits the
business case of targeting the unconnected and
operational simplicity.
RAKUTEN
Cloud-native 4G RAN & Core, upgradable to 5G
• Simplification of hardware requirements with just four types • CI/CD for software automation
of servers needed across the technology function • A fully-virtualized radio access network that enables to completely
• CNF on COTS servers remove the need for field technicians and manual updates
• Separation of the control plane and user plane • Generates a 45% TCO reduction from traditional RAN deployment
Rakuten views its users as members rather than customers or subscribers.

Cash back is offered as part of the value proposition of buying products/services (including mobile services) on the member platform.
Rakuten Rakuten Rakuten

Edge Cloud Regional Cloud Central Cloud
Japan’s 4th largest NEC

mobile operator (late
comers) MEC NSSF … OSS / BSS
RU
Build the entire 5G UPF PCF UDM Orchestrator

DU
z CU
z
network functions on RU
5G O-RAN
the COTS server. Altiostar NEC
5G RAN RU AMF SMF IMS Nokia
NEC NFVI NFVI
Airspan NFVI
COTS Server COTS Server
COTS Server
Image Source: Netmanias Consulting/HFR

At Parallel Wireless, we believe that software has the power to unleash amazing opportunities for the
world. We disrupt the ways wireless networks are built and operated. We are reimagining how
hardware, software, and the cloud work together to change deployment economics for our customers.
Our ALL G (2G 3G 4G 5G) O-RAN compliant software platform forms an open, secure, and intelligent
RAN architecture to deliver wireless connectivity, so all people can be connected whenever, wherever,
and however they choose. We are deploying with leading global MNOs and have been recognized
with over 80 industry awards. At the core of what we do is our team of Reimaginers who value
innovation, collaboration, openness, and customer success.
For more information, visit: www.parallelwireless.com. Connect with Parallel Wireless on LinkedIn and Twitter.
©2021 Parallel Wireless. All Rights Reserved.

EB ParallelWireless Open RAN Fact Book 100521

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EB ParallelWireless Open RAN Fact Book 100521

Uploaded by

Copyright:

Available Formats

Parallel Wireless

Parallel Wireless #OpenRANdailyfact 2

02 RAN Functional Splits 10 08 Open RAN Integration 68

Telecom Infra Project

05 RIC 49 11 Use Cases 82

06 Cloud-Native Open RAN 60 12 Operator Views 93

Parallel Wireless #OpenRANdailyfact 3

Parallel Wireless #OpenRANdailyfact 4

Baseband COTS Server + Proprietary Software With Virtualized Functions

Contemporary Base Station

Parallel Wireless #OpenRANdailyfact 5

OpenRAN = TIP group and anything

O-RAN or ORAN = O-RAN

Parallel Wireless #OpenRANdailyfact 6

Open Fronthaul F1 Interface

Radio Unit (O-RU) Distributed Unit (O-DU) O-CU (CP)

Distributed Unit (O-DU) O-CU (CP)

02 Telecom Infra Project: 04 The Linux Foundation: 06 Small Cell Forum:

Development of open standards for small cells

Advancement of global Open RAN Collaboration with the O-RAN Alliance in

Parallel Wireless #OpenRANdailyfact 8

COTS server for DU/CU software:

Realizing 5G Open RAN with COTS-Based Appliances

RRU MAC/RLC PDCD/RRC

RRU DU Middlehaul CU Backhaul 5G Core

O-RAN Appliance MEC Appliance

Parallel Wireless #OpenRANdailyfact 10

Parallel Wireless #OpenRANdailyfact 11

Parallel Wireless #OpenRANdailyfact 12

Parallel Wireless #OpenRANdailyfact 13

Open RAN RU consists of 3 functional components:

RF Front End (RFFE)

Lower PHY Layer Using the eCPRI fronthaul

RF Front End Digital Front End Low PHY Fronthaul/Transport

Power Supply RJ-45 LED

Parallel Wireless #OpenRANdailyfact 14

Parallel Wireless #OpenRANdailyfact 15

MAC/PHY layer split (Small Cell Forum RAN 3GPP

S-CU 3GPP S-DU SCF S-RU

Parallel Wireless #OpenRANdailyfact 16

Parallel Wireless #OpenRANdailyfact 17

O-RAN ALLIANCE e.V. has defined a

02 O-RU and DU is denoted as O-DU.

• Synchronization (CUS) and Open Fronthaul CUS-Plane Open Fronthaul M-Plane

Control Plane (C-Plane) data (data

Parallel Wireless #OpenRANdailyfact 18

• BBU connects to a proprietary Remote Radio Unit

Introduction of midhaul provides more flexibility for PHY

O-RAN ALLIANCE e.V. expanded on the scope of what was

Parallel Wireless #OpenRANdailyfact 19

• Creates a bottleneck as it’s based on transport of digital radio

Parallel Wireless #OpenRANdailyfact 20

RRC PDCP High-RLC Low-RLC High-MAC Low-MAC High-PHY Low-PHY RF

RRC PDCP High-RLC Low-RLC High-MAC Low-MAC High-PHY Low-PHY RF

Parallel Wireless #OpenRANdailyfact 21

Parallel Wireless #OpenRANdailyfact 22

• Digital processing Delay IDEAL DELAY GOOD DELAY NON-IDEAL DELAY

Why? Lower splits BEST PERF. LEAST PERF.

BEST FOR 2G, 3G | BEST FOR 4G, 5G | 4G Support of multiple splits on

Parallel Wireless #OpenRANdailyfact 23

• Lower splits to handle low

Parallel Wireless #OpenRANdailyfact 24

Parallel Wireless #OpenRANdailyfact 25

be embedded with the DU on the same