ORAN Fundamental from basics to advance.

O_RAN _5G
Doc Owner :
Ashish B
17/12/20
© 2019-2020 Sterlite Technologies Limited

Click icon to add picture
2
Outline
o 5G Logical Split Options
o Overview Of 7.2x
o VRan Vs Oran
o 5G Open RAN Deployment
o O_RAN Logical Architecture
o Interfaces in O-RAN Architecture
o Implementation Options of O-RAN
o ORan OAM Deployment Senarios
o O_RAN Technical Work Groups
o O-RAN FH CUSM Planes and Protocol Stack
o O-RAN – Radio Unit (O-RU) Reference Architecture
o O-RU Types/Operation Mode
o Setup for O-RU testing

5GFunctional Split
3

7.2 Spilt
4

ORAN Logical Architecture
8
.

ORAN Logical Architecture continue………
SMO :
FCAPS interface to O-RAN Network Functions
• Non-RT RIC for RAN optimization
• O-Cloud Management, Orchestration and Workﬂow Management
A.Non-RT RIC : Non-Real Time RAN Intelligent Controller (Non-RT RIC) is the functionality internal
to the SMO in O-RAN 15 architecture that provides the A1 interface to the Near-Real Time RIC
The primary goal of Non-RT RIC is to support intelligent RAN optimization by providing policy-
based guidance,
The Non-RT RIC is comprised of two sub-functions:
• Non-RT RIC Framework – Functionality internal to the SMO Framework that logically terminates
the A1 interface and exposes the required services to rApps through its R1 interface.
• Non-RT RIC Applications (rApps) – Modular applications that leverage the functionality exposed
by the Non- RT RIC Framework to perform RAN optimization and other functions via the A1, O1,
O2 and R1 interfaces.
B. Near-RT RIC : It is a logical function that enables near real-time control and optimization of E2
Nodes functions and resources via ﬁne-48 grained data collection and actions over the E2
interface with control loops in the order of 10 ms-1s.
For a function exposed in the E2 Service Model [20] , the near RT RIC may e.g. monitor, suspend/
stop, override or control via 7 policies the behavior of E2 Node.

Relevant Interfaces in O-RAN Architecture
The following interfaces are deﬁned and maintained by O-RAN:
• A1 interface
• O1 interface
• O2 interface
• E2 interface
• Open Fronthaul interface
following interfaces are deﬁned and maintained by 3GPP, but seen also as part of the O-RAN
architecture
E1 interface
• F1-c interface
• F1-u interface
• NG-c interface
• NG-u interface
• X2-c interface
• X2-u interface
• Xn-c interface
• Xn-u interface
• Uu interface

Implementation Options of O-RAN
1.Centralized Near-RT RIC Serving 4G and 5G Simultaneously
2. Distributed Near-RT RIC
3.Aggregation of the O-CU-CP and O-CU-UP
4. Shared Cell
5.Cascade Mode

Shared Cell
Shared cell [22] is deﬁned as the operation for the same cell by several O-RUs with one or multiple
component carriers. 4 It can be deployed in either FHM (Fronthaul Multiplexer) or Cascade mode
In FHM mode, the shared cell may be realized by placing an FHM function between an O-DU and several O-
RUs that 6 may have one or multiple component carriers from these O-RUs. FHM function may be
modelled as an O-RU with LLS 7 Fronthaul support (same as normal O-RU) along with the copy and
combine function (additional to normal O-RU), but 8 without radio transmission/reception capability.

Cascade Mode
In Cascade mode, the shared cell is realized by several O-RUs
cascaded in chain. In this case, one or more O-RUs are 14
inserted between the O-DU and the O-RU. The O-RUs in the
cascaded chain except for the last O-RU shall support 15
Copy and Combine function.

ORan OAM Deployment Senarios
Thanks

O_RAN Technical Work Groups Structure
O-RAN ALLIANCE is on the mission to re-shape the RAN industry towards more intelligent, open, virtualized
and interoperable networks. The O-RAN standards are working to enable a more competitive and vibrant RAN
supplier ecosystem with faster innovation to improve user experience, improve the efficiency of RAN
deployments and network operations.
To achieve above, O-RAN ALLIANCE is active in following 3 main streams:
• Specifications: New standards for open and intelligent RAN
• O-RAN Software Community: Open software development for the RAN in cooperation with the Linux
Foundation
• Test and Integration: Supporting O-RAN member companies for testing and integrating of their O-RAN
implementations
1

O_RAN Technical Work Groups Structure
1

• WG1 has overall responsibility for O-RAN Architecture and Use Cases
• It identifies the tasks to be completed within the scope of the Architecture and Use Cases and assigns task group leads to
drive these tasks to completion while working across other O-RAN work groups.
• Workgroup#2: Non-real-time RIC and A1 Interface Workgroup
• WG#2 focus includes both the non-RT RIC and the A1 interface.
• The A1 interface supports communication and information exchange between the Orchestration/NMS layer
containing non-RT RIC and the eNB/ gNB containing near-RT RIC.
• A key objective of the A1 interface is to support policy-based guidance of near-RT RIC functions/use-cases,
transmission of enrichment information in support of AI/ML models into near-RT RIC, and basic feedback
mechanisms from near-RT RIC
• Workgroup#3: Near-Real-time RIC and E2 Interface Workgroup
• WG#3 focus is to specify near-RT RIC open architecture and its functionalities, the Radio-Network Information Base
and Network Topology, and modular on-boarding of new control applications
• WG3 also specifies the E2 interface between near-RT RIC and CU/DU protocols stack
• Workgroup#4: Open Fronthaul Interfaces Workgroup Work Group
• WG#4 specifies the Open Fronthaul Interface between O-DU and O-RU.
• WG#4 provided open fronthaul interface specifications for the lower layer split, including Control, User and
Synchronization (CUS) plane protocols, Management (M) plane protocols, and Multivendor IOT specifications,
supporting both LTE and 5G NR
• Workgroup#5: Open F1/W1/E1/X2/Xn Interface Workgroup
• WG#5 is refining the definition of 3GPP’s F1 interface for supporting the Higher layer Split for 5G NR.
• It is ensuring that the 3GPP split interfaces remains truly inter-operable between vendors, the focus is on F1, W1, E1,
X2, and Xn interfaces
• Workgroup#6: Cloudification and Orchestration Workgroup
• “Cloudified” or “Virtualized” of RAN provides the flexibility of deploying multiple software implementations from
different vendors on a common CPU-based (e.g., x86/ARM) platform with hardware accelerators (e.g., FPGA/DSP/
ASIC/ GPU) for specific functions, and conversely, allows multiple physical deployment scenarios in terms of
centralizing or distributing each element with the same software implementation

• Workgroup#7: White-box Hardware Workgroup
• WG#7 specify and release the complete hardware reference design of a high performance, spectral and
energy efficient white box base station
• Within this scope, any kind of design material is included, such as documentation of reference hardware and
software architectures, detailed schematic of reference designs and POC hardware, as well as test cases for
verification and certification of all base station types and usage scenarios.
• Component selection for the implementation of example white box hardware is allowed for WG7 but is not
mandatory in any specification
• Workgroup#8: Stack Reference Design Workgroup
• WG#8 goal is to develop the software architecture, design, and release plan for the O-CU and ODU based on
O-RAN and 3GPP specifications for the NR protocol stack
• WG#8 first deliverable introduces RAN deployment scenarios and requirements, describing RAN features and
various functional blocks for O-RU, O-DU and O-CU.
• Workgroup#9: xHaul Transport Workgroup
• WG#9 focus is on the transport domain consisting of transport equipment, physical media, and control/
management protocols associated with the transport network underlying the assumed Ethernet interfaces
(utilized for fronthaul, mid-haul and backhaul)

1
O-RAN Fronthual C-U/Sync/Mgmt Planes and Protocol Stack
The interface between DU and RU is known as Fronthaul. When this interface allows to connect any vendor DU to any
vendor RU, know as Open Fronthaul. To enable this multi vendor DU and RU interconnection some signaling formats and
control messaging is required are detailed by Open Standard i.e. O-RAN Alliance as part of O-RAN fronthaul specification.
O-RAN Fronthaul defines following planes of operations:
• C-Plane (Control Plane): Control plane messages define the scheduling, coordination required for data transfer, beam-
forming etc.
• Scheduling and beam-forming commands
• DL precoding configuration
• Mixed numerology and PRACH handling
O-RAN Fronthual CUSM Planes and Protocol Stack

O-RAN Fronthual CUSM Planes and Protocol Stack
continue....
2
• U-Plane (User Plane): User plane messages for efficient data transfer within the strict time limits of 5G numerologies.
• Support Data Compression
• I/Q data transfer
• DL data precoding
• S-Plane (Synchronization Plane) : Synchronization plane is responsible for the timing and sync aspects between the O-DU and O-RU.
In Cloud RAN deployments, a high accurate synchronization is required between O-DU and O-RUs to achieve controlled linking for inter-O-
RU sync operation for TDD, Carrier Aggregation using multiple O-RUs, MIMO, and similar processes. Using S-Plane, O-RAN fronthaul
specifications support protocols such as PTP and SyncE to achieve high-accuracy synchronization on the O-RU side by synchronizing with the
clock high-performance available at O-DU side.
• Synchronization Typologies
• PTP and SyncE profiles for Synchronization
• Time and Frequency Sync guidelines
• M-plane (Management Plane) : Management plane messages are used to manage the radio unit. M-Plane provides a variety of O-RU
management functions to set parameters on the O-RU side as required by the C/U-Plane and S-Plane , e.g. manage O-RU software, perform
fault management, etc. O-RAN fronthaul specification for M-Plane provides various parameters as data models to FCAPS functions. This data
models eliminates dependence on each O-RU vendorʼs implementation and makes a real multi-vendor Open RAN possible
• Support Hierarchical/Hybrid Model
• C/U Plane IP and Delay management
• FCAPS including sync configuration and status

2
The O-RAN fronthaul specifications protocol stack of each above mentioned plane is shown in below picture.
• C/U-Plane, the O-RAN fronthaul specifications support a protocol stack that transmits data used by eCPRI or Radio over
Ethernet (RoE) directly over Ethernet and an optional protocol stack that transmits the signals over UDP/IP
• S-Plane in O-RAN fronthaul support a protocol stack that transmits data used in Precision Time Protocol (PTP) and SyncE over
Ethernet
• M-Plane support a protocol stack that transmits signals used in NETCONF over Ethernet with IP transported using TCP with Secure
SHell (SSH)

O-RAN – Radio Unit (O-RU) Reference Architecture
The Radio Unit (RU) purpose is to convert radio signals sent to and from the antenna to a digital signal that can
be transmitted over the fronthaul to Distributed Unit (DU). Considering O-RAN Split 7-2, at high level an O-RU
has following components.
• Synchronization and Fronthaul Transport
• Lower PHY Layer Baseband Processing
• Digital Front End (DFE)
• RF Front End (RF FE)
2
Massive MIMO illustration – advanced 3D
beamforming

O-RAN – Radio Unit (O-RU) Reference Architecture Continue……….
• Synchronization and Fronthaul Transport: GPS/PTP (IEEE 1588) modules are used synchronization. For fronthaul connection. The
fronthaul connectivity between O-RU and O-DU is eCPRI can be established using Fiber or Ethernet
• Lower PHY Baseband Processing: The lower PHY layer processing can be implemented by using FPGAs or ASICs. It includes
functions of FFT/iFFT, CP addition and Removal, PRACH filtering and digital beamforming (Optional).
• Digital Front End (DEF): The digital front end consists of Digital Up Converter (DUC), Digital Down Converter (DDC), Digital Pre-
Distortion (DPD) and Crest Factor Reduction (CFR).
• Radio Front End (RFEF): The RF front end is composed of antenna element arrays, bandpass filters, Power Amplifiers (PA), Low
Noise Amplifiers (LNA), Digital Analog Converters (DAC), and Analog Digital Converters (ADC)
• Other Subsystems:
• Power Supply is the heart of O-RU as it drives all the subsystem, Power supply can be AC or DC but recommendation says
power supply shall be –48 VDC
• In O-RU, LED can be used for local on/off display Status for Fronthaul transport interface, Power
supply and Radio transmission
• RJ45 Connection can be provided for local access and debug purpose

ORAN Fundamental from basics to advance.

More Related Content

What's hot

Similar to ORAN Fundamental from basics to advance.

Recently uploaded

ORAN Fundamental from basics to advance.