O-RAN Webinar CaFeTele

2022 CafeTele Author Abhijeet Kumar

Module
O-RAN
 Introduction to O-RAN
Split Architecture 3GPP vs O-RAN
O-RAN architecture Principle
Logical architecture of O-RAN
O-RAN Control Loops

Module High Level architecture of O-RAN

" O-RAN Interface (A1,O1,O2,E2,Open Front-haul
interface)"
Outline Near RT RIC
Non-RT RIC
Service Management and Orchestration (SMO)
4O-Cloud Management, Orchestration and
Workflow Management
Non-RT RIC Function architecture
Non -RT RIC service-based view
4

Introduction to O-RAN
BTS Architecture Evolution From Traditional to current version

Digital Radio
Fronthaul connectivity
Radio Unit PHY
Radio Unit
RF Interface

Fronthaul

• RU run the Lower layer protocol stakc

RLC , MAC and parts of PHY layers,
DU
• Multiple DU connect to each CU.

Baseband Midhaul

CU
L2+L3+control, Higher layer processing,
A CU with multiple Dus will support multiple
gNBs
Backhaul

CORE NETWORK CORE NETWORK

Current Network OPEN RAN

 Architecture of 5G

gNB-CU-UP
gNB-CU-UP
CU-CP CU-UP ▪ A gNB may consist of a CU-CP, multiple CU-
E1 UPs and multiple Dus.
▪ The CU-CP is connected to the DU through the
F1-C interface
▪ The CU-UP is connected to the DU through the
F1-U interface.
▪ The CU-UP is connected to the CU-CP through
F1-C F1-U
the E1 interface
▪ One DU is connected to only one CU-CP

gNB-DU gNB-DU

• gNB
• Central unit –control Plane (CU-CP)
• Central unit-User plane (CU-UP)
• Distributed Unit (DU)
7

Split Architecture 3GPP vs O-RAN

How to Split to RAN

High Low High Low High Low

RRC PDCP RF
RLC RLC MAC MAC PHY PHY

Downlink
Data Option 1 Option 2 Option 3 Option 4 Option 5 Option 6 Option 7 Option 8

Uplink

High Low High Low High Low

RRC PDCP RF
RLC RLC MAC MAC PHY PHY

Data

RAN Split Options (Source: NGNM 2018)

How to Split to RAN
Option 1 (1A-like split)
- The function split in this option is similar as 1A architecture in DC. RRC is in the central unit. PDCP, RLC, MAC, physical layer and RF are in the
distributed unit.
Option 2 (3C-like split)
- The function split in this option is similar as 3C architecture in DC. RRC, PDCP are in the central unit. RLC, MAC, physical layer and RF are in the
distributed unit.
Option 3 (intra RLC split)
- Low RLC (partial function of RLC), MAC, physical layer and RF are in distributed unit. PDCP and high RLC (the other partial function of RLC) are in the
central unit.
Option 4 (RLC-MAC split)
- MAC, physical layer and RF are in distributed unit. PDCP and RLC are in the central unit.
Option 5 (intra MAC split)
- RF, physical layer and some part the MAC layer (e.g. HARQ) are in the distributed unit. Upper layer is in the central unit.
Option 6 (MAC-PHY split)
- Physical layer and RF are in the distributed unit. Upper layers are in the central unit.
Option 7 (intra PHY split)
- Part of physical layer function and RF are in the distributed unit. Upper layers are in the central unit.
Option 8 (PHY-RF split)
- RF functionality is in the distributed unit and upper layer are in the central unit.
How to Split to RAN
Option 2 (3C-like split) Option 4 (RLC-MAC split) Option 6 (MAC-PHY split) Option 8 (PHY-RF split)

High Low High Low High Low

RRC PDCP RF
RLC RLC MAC MAC PHY PHY

Downlink
Data Option 1 Option 2 Option 3 Option 4 Option 5 Option 6 Option 7 Option 8

Uplink

High Low High Low High Low

RRC PDCP RF
RLC RLC MAC MAC PHY PHY

Data

Option1 ( 1A-Linke Split) Option 3 (intra RLC split) Option 5 (Intra MAC split) Option 7 (Intra PHY split)
RAN Split Options (Source: NGNM 2018)
How to Split to RAN
High Low High Low High Low
RRC PDCP RF
RLC RLC MAC MAC PHY PHY

Downlink
Data Option 1 Option 2 Option 3 Option 4 Option 5 Option 6 Option 7 Option 8

Uplink

High Low High Low High Low

RRC PDCP RF
RLC RLC MAC MAC PHY PHY

Data

• Option 1 (RRC/PDCP, 1A-like split)

• Central Unit: RRC
• Distributed Unit: PDCP, RLC, MAC, physical layer and RF
• User Plane: Entire UP is in the distributed unit
RAN Split Options (Source: NGNM 2018)
Option 1(RRC/PDCP, 1A-Like Split)
High Low High Low High Low
RRC PDCP RF
RLC RLC MAC MAC PHY PHY

Downlink
Data Option 1 Option 2 Option 3 Option 4 Option 5 Option 6 Option 7 Option 8

Uplink

High Low High Low High Low

RRC PDCP RF
RLC RLC MAC MAC PHY PHY

Data

• Description • Benefits • Cons:

• Option 1 (RRC/PDCP, 1A-like split)
• Central Unit: RRC
• Distributed Unit: PDCP, RLC, MAC,
physical layer and RF
• User Plane: Entire UP is in the
distributed unit
• Allow a separate U-plane
• CU have RRC and RRM
• Handling edge computing or low
latency user cases
• RRC and PDCP separation
affect security.
RAN Split Options (Source: NGNM 2018)
Option 2 (PDCP/RLC Split)

High Low High Low High Low

RRC PDCP RF
RLC RLC MAC MAC PHY PHY

Downlink
Data Option 1 Option 2 Option 3 Option 4 Option 5 Option 6 Option 7 Option 8

Uplink

High Low High Low High Low

RRC PDCP RF
RLC RLC MAC MAC PHY PHY

Data

• Description • Cons:
• Benefits
• Option 2-1Split U-plane only (3C like a
• Allow traffic aggregation from NR and • Coordination of security
split) configuration between different
E-UTRA transmission points to be
• RRC PDCP are in the central unit PDCP instances for option 2-2
centralized
• RLC MAC physical layer and RF in DU need to be ensured
• 2-2 allow a separate U-Plane while
• Option 2-2
having a centralized RRC/RRM
• RRC PDCP are in CU RAN Split Options (Source: NGNM 2018)
• RLC MAC PHY and RF in DU
Option 3 (High RLC/Low RLC Split)
High Low High Low High Low
RRC PDCP RF
RLC RLC MAC MAC PHY PHY

Downlink
Data Option 1 Option 2 Option 3 Option 4 Option 5 Option 6 Option 7 Option 8

Uplink

High Low High Low High Low

RRC PDCP RF
RLC RLC MAC MAC PHY PHY

Data

Option 3-2 Spit based on TX RLC and RX

Option 3-1 (Split Based on ARQ)
RLC
• Low RLC may be composed of segmentation function • Low RLC may be composed of TM RLC entity,TM UL RLC entity,TRM
Descriptions • High RLC may be composed of ARQ and other RLC AM
• Highly may be composed of receiving TM,UM,AM Entity
functions
• Traffic aggregation • Traffic aggregation from NR and EUTRA
Benefits • Better control across the split • Flow control in the CU and for that a buffer in the CU is
• Centralization gain needed
• Comparatively, the split is more latency sensitive than the • Due to performing flow control
RANinSplit
the Options
CU and(Source:
RLC Tx in the2018)
NGNM
Cons
split with ARQ in DU DU two buffers are needed for transmission,
Option 4 ((RLC-MAC split))
High Low High Low High Low
RRC PDCP RF
RLC RLC MAC MAC PHY PHY

Downlink
Data Option 1 Option 2 Option 3 Option 4 Option 5 Option 6 Option 7 Option 8

Uplink

High Low High Low High Low

RRC PDCP RF
RLC RLC MAC MAC PHY PHY

Data

• Description: In this split option, RRC, PDCP and RLC are in the central unit.MAC, physical layer and RF are in
the distributed unit.

• Benefits and Justification: In the context of the LTE protocol stack a benefit is not foreseen for option 4. This
might be revised with NR protocol stack knowledge

RAN Split Options (Source: NGNM 2018)

Option 5 (intra MAC split)
High Low High Low High Low
RRC PDCP RF
RLC RLC MAC MAC PHY PHY

Downlink
Data Option 1 Option 2 Option 3 Option 4 Option 5 Option 6 Option 7 Option 8

Uplink

High Low High Low High Low

RRC PDCP RF
RLC RLC MAC MAC PHY PHY

Data

• Option 5 assumes the following distribution:

• RF, physical layer and lower part of the MAC layer (Low-MAC) in the Distributed Unit
• Higher part of the MAC layer (High-MAC), RLC and PDCP in the Central Unit

RAN Split Options (Source: NGNM 2018)

 Benefits • This option will allow traffic aggregation from NR and E-UTRA transmission points to be
centralized. Additionally, it can facilitate the management of traffic load between NR and
E-UTRA transmission points.

and • Reduce the bandwidth needed on fronthaul, dependent on the load of RAN-CN interface;
• Reducing latency requirement on fronthaul (if HARQ processing and cell-specific MAC
functionalities are performed in the DU);

Justification • Efficient interference management across multiple cells and enhanced scheduling
technologies such as CoMP, CA, etc., with multi-cell view

• Complexity of the interface between CU and DU;

• Difficulty in defining scheduling operations over CU and DU;

Cons • Scheduling decision between CU and DU will be subject to

fronthaul delays, which can impact performances in case of
non-ideal fronthaul and short TTI;
• Limitations for some CoMP schemes (e.g. UL JR).
Option 6 (MAC-PHY split)
High Low High Low High Low
RRC PDCP RF
RLC RLC MAC MAC PHY PHY

Downlink
Data Option 1 Option 2 Option 3 Option 4 Option 5 Option 6 Option 7 Option 8

Uplink

High Low High Low High Low

RRC PDCP RF
RLC RLC MAC MAC PHY PHY

Data

• Description:
• The MAC and upper layers are in the central unit (CU).
• PHY layer and RF are in the DU. The interface between the CU and DUs carries data, configuration, and
scheduling-related information (e.g. MCS, Layer Mapping, Beamforming, Antenna Configuration, resource
block allocation, etc.) and measurements.

RAN Split Options (Source: NGNM 2018)

 Benefits Concs
This option will allow traffic aggregation from NR and
E-UTRA transmission points to be centralized.
Additionally, it can facilitate the management of traffic
load between NR and E-UTRA transmission points
This option is expected to reduce the fronthaul
requirements in terms of throughput to the baseband
bitrates as the payload for Option 6 is transport block This split may require subframe-level timing
bits interactions between MAC layer in CU and PHY
layers in DUs. Round trip fronthaul delay may affect
Joint Transmission is possible with this option as MAC
HARQ timing and scheduling.
is in CU.
Centralized scheduling is possible for Option 6 as
MAC is in CU.

It allows resource pooling for layers including and

above MAC.
Option 7 (intra PHY split)
High Low High Low High Low
RRC PDCP RF
RLC RLC MAC MAC PHY PHY

Downlink
Data Option 1 Option 2 Option 3 Option 4 Option 5 Option 6 Option 7 Option 8

Uplink

High Low High Low High Low

RRC PDCP RF
RLC RLC MAC MAC PHY PHY

Data

Description:
Multiple realizations of this option are possible, including asymmetrical options which allow to obtain benefits of
different sub-options for UL and DL independently (e.g. Option 7-1 is used in the UL and Option 7-2 is used in the
DL). A compression technique may be able to reduce the required transport bandwidth between the DU and CU.

RAN Split Options (Source: NGNM 2018)

Benefits and Justification (common among Option 7-1, 7-2 and 7-3):
▪ This option will allow traffic aggregation from NR and E-UTRA transmission points to be centralized.
Additionally, it can facilitate the management of traffic load between NR and E-UTRA transmission points.
▪ These options are expected to reduce the fronthaul requirements in terms of throughput.
▪ Centralized scheduling is possible as MAC is in CU. e.g. CoMP
▪ Joint processing (both transmit and receive) is possible with these options as MAC is in CU.

▪ Cons:
▪ This split may require subframe-level timing interactions between the part of PHY layer in CU and part of PHY
layer in DUs.
2

O-RAN architecture Principle

Architecture Principle
The O-RAN architecture and interface specifications shall be consistent with 3GPP architecture and
interface specifications to the extent possible.

External
System
Service Management and orchestration Framework providing
enrichment
High Level Architecture of O-RAN

data to the
Non-RT RIC SMO

O2 A1 O1 Open Fronthaul M-Plane

Near-RT RIC
0-RAN Network Functions

NG-CORE
NG

0-Cloud O-RU

O-RAN Defined interface 3GPP Defined Interface Interface out of scope for O-RAN
O-RAN Interface
• O1
• Interface between SMO frameworks and O-RAN managed elements
• Operation & Management by Which FCAPs management, Physical network
function software management

• O2 • A1
• Interface between SMO framework • Interface between Near RT RIC and
and the O-Cloud for supporting O- Non-RT RIC
RAN Virtual networks functions
Blocks for O-RAN
NF Description
SMO • A Service Management and Orchestration system

• O-RAN Near-Real-Time RAN Intelligent Controller

• A logical function that enables near-real-time control and optimization of RAN elements and
Near-RT RIC resources via fine-grained data collection and actions over E2 interface.
• It may include AI/ML workflow including model training, inference and updates

• O-RAN Non-Real-Time RAN Intelligent Controller

• A logical function within SMO that drives the content carried across the A1 interface
Non-RT RIC
• It is comprised of the Non-RT RIC Framework and the Non-RT RIC Applications (rApps)

• O-Cloud is a cloud computing platform comprising a collection of physical infrastructure nodes that
meet O-RAN requirements to host the relevant O-RAN functions (such as Near-RT RIC, O-CU-CP,
O-Cloud
O-CU-UP, and O-DU)

NG-Core 5GC Core for 5G and LTE

• O-RAN Radio Unit: a logical node hosting Low-PHY layer and RF processing based on a lower layer
O-RU functional split
Blocks for O-RAN
NF Description
• O-RAN Central Unit – Control Plane
O-CU-CP
• A logical node hosting the RRC and the control plane part of the PDCP protocol
• O-RAN Central Unit –user plane
O-CU-UP • a logical node hosting the user plane part of the PDCP protocol and the SDAP
protocol

O-eNB • An eNB or ng-eNB that supports E2 interface

• O-RAN Distributed Unit: a logical node hosting RLC/MAC/High-PHY layers based on a

O-DU
lower layer functional split
• Modular applications that leverage the functionality exposed via the Non-RT RIC 40
(rApps) Framework’s R1 interface to provide added value services relative to RAN operation,
such as driving the A1 interface
• An application designed to run on the near-RT RIC.
xApp • Such an application is likely to consist of one or more microservices and at the point of
on boarding will identify which data its consumes and which data is provided
Logical Architecture of O-RAN
Legend
O1 3GPP
Service Management and Orchestration framework O-RAN interface
Non-Real Time RIC SMO

O2 A1

Near-Real Time RIC

E2 X2-C
E2
X2-U
O-CU-CP
O-eNB E2 E1
E2 O-CU-UP NG-U

F1-U Xn-U
Open FH M-lane F1-C Xn-C
NG-C

O-DU
Open FH CUS-Plane Open FH M-Plane
O-RU

O-Cloud
8

A1 Interface
A1 Architecture

Non-RT RIC

A1

near-RT RIC

• The O-RAN architecture includes a non-Real Time (RT) RAN Intelligent Controller
(RIC) and a near-RT RIC which are connected through the A1 interface.
 • The purpose of A1 policies is to guide the RAN
A1 in the O-RAN Architecture performance towards the overall goal expressed
in RAN Intent.
• The non-RT RIC manages the A1 policies based
RAN intent
on A1 policy feedback, and on the network, status
provided over O1.
O-RAN
external
Expression of high-level SMO information
sources
operational or business
Non-RT RIC
goals to be achieved by the Information
radio access network

• A1 policy: Type of declarative policies
expressed using formal statements that
enable the non-RT RIC function in the
SMO to guide the near-RT RIC function,
and hence the RAN, towards better
fulfilment of the RAN intent.
A1 • Information provided by an
O-RAN external information
Delivery of External source through a direct and
O1 Enrichment Information secure connection with
near-RT RIC near-RT RIC.

O-RAN internal
E2
information
sources
E2 nodes
1

O2 Interface
O2 Interface
SMO
Service FOCOM NFO
Provider
Functionality

Separation of
concern
OAM Function
boundary

o2dms
o2dms
o2ims o2dms
DMS
DMS
IMS DMS

• Federated O-Cloud Orchestration and Management (FOCOM)

• Network Function Orchestrator (NFO)
• OAM Functions
• Infrastructure Management Services (IMS)
• Deployment Management Services (DMS)
O2 Interface
• NF Deployment:
• An O-Cloud NF Deployment is a deployment of a cloud native Network Function (all or partial), resources
shared within a NF Function, or resources shared across network functions. The NF Deployment configures
and assembles user-plane resources required for the cloud native construct used to establish the NF
Deployment and manage its life cycle from creation to deletion.
• NF Deployment Descriptor:
• A completed data model which provides an O-Cloud the necessary information to create a deployment.
• Deployment ID:
• Correlation Identity created by the O-Cloud for the SMO to relate to its inventory and manage.
• Deployment Management Services (DMS):
• The DMS are the logical services provided by the O-Cloud providing for managing the life cycle of
deployments which use cloud resources.
• Federated O-Cloud Orchestration and Management (FOCOM):
• The SMO treats the collection of O-Clouds as a single federated cloud. The FOCOM are the logical services
provided by the SMO to manage the distribution of O-Cloud software and provides orchestration for O-Cloud
life cycle processes.
• Infrastructure Management Services (IMS):
• The IMS are the logical services provided by the O-Cloud which provides the interface to orchestrate O-Cloud
life cycle processes with the network functions it may be hosting and other operational procedures.
• Network Function Orchestration (NFO):
• The NFO are the logical services of the SMO which coordinates between the O-Cloud for managing
deployment life cycle events, open loop, and closed loop operational procedures.
4

O-Cloud Planes
O-Cloud Planes

• Management Plane: O-Cloud Nodes in this plane

host the software which is responsible for managing
the O-Cloud.

• Control Plane: O-Cloud Nodes in this plane are

responsible for hosting the software which manages
the resources assigned in the deployment plane to
specific deployment instances.

• Deployment Plane: O-Cloud Nodes in this plane are

used to host "Service Model" Deployments
 O-Cloud
• O-RAN clouds are described in as a distributed cloud composed of O-Cloud [Resource] Pools (as shown as
white clouds in the diagram above) where each pool is a collection of O-Cloud Nodes at a specific location.
• An O-Cloud Node is the basic computational resource designator and can be commonly thought of as a
server. An Operator may have several O-Clouds from different vendors but will manage them as a single
entity. These O-Clouds are viewed by the Service Management and Orchestration (SMO) Framework as a
Federated O-Cloud.

• O-Cloud Nodes are provisioned into resources which are assigned for a specific use by the O-Cloud
Management Software according to a blueprint. As a general concept the cloud is divided into three planes,
however the control and management plane described below may be merged or use common tools and
therefore may act as or be one plane.

• O-Cloud Nodes in this plane host the software which is responsible for managing the
Management Plane: O-Cloud

• O-Cloud Nodes in this plane are responsible for hosting the software which manages
Control Plane: the resources assigned in the deployment plane to specific deployment instances

Deployment Plane: • O-Cloud Nodes in this plane are used to host "Service Model" Deployments
7

Near RT RIC
What is RIC?

• Ran Intelligent Controller

• Near-RT RIC
• Non-RT RIC

Non-RT RIC Near-RT RIC

A1
Enable policy-driven
guidance of Near-RT RIC
applications/functions, and
support AI/ML workflow
Purpose of Near-RT RIC

Near-RT RIC

Network RAN Intelligent Resource Assurance Resource Control

Policy Handover Load

Radio Link SON RAN Slicing
Enforcement Management Balancing
Near-RT RIC Internal Architecture
Service Management and Orchestration(SMO)
Interface Description

Non-RT RIC
A1 Interface between Non-RT RIC and near RT RIC

O1 A1
Interface between orchestration and
O1 management entities and O-RAN ME.
O1 Termination A1 Termination
Near-RT RIC APIs for xAPPs
xAPP Application designed to run on the near-RT RIC

API Enablement
xAPP 1 xAPP 2 xAPP N
E2 Node Logical node termination E2 interface

Messaging Infrastructure
SMO Service Management and orchestration system
Conflict Subscription Mgmt.
Mitigation Security
Mgmt. Services
Conflict resolves potentially overlapping or conflicting
Shared Data Layer E2 Mitigation requests from multiple xApps
Termination
Database
E2 Messaging enables message interaction amongst Near-RT
E2 Nodes infrastructure RIC internal functions;
Database

• UE-NIB
• Some xApps may generate UE related information to be stored in the UE-NIB database.
• UE-NIB maintains a list of UEs and associated data.
• UE-NIB maintains tracking and correlation of the UE identities associated with the connected E2
Nodes

• R-NIB
• Some xApps may generate radio access network related information to be stored in the R-NIB database.
• The R-NIB stores the configurations and near real-time information relating to connected E2 Nodes
and the mappings between them.
xAPP Subscription Management

xApp subscription
xApp subscription
xApp subscription management enables merging
management enforces
management manages of identical subscriptions from
authorization of policies
subscriptions from xApps to different xApps into a single
controlling xApp access to
E2 Nodes. subscription toward an E2
messages.
Node
Conflict Mitigation

Conflict
Mitigation

Direct Indirect Implicit

Conflict Conflicts conflicts
Messaging Infrastructure
• Messaging infrastructure provides low-latency message delivery service between
Near-RT RIC internal endpoints.

Registration Discovery Deletion

Management Services

Resource
Onboarding Deployment Termination of
management
xApps of xApps xApps
(RM)
6

Near RT RIC
Non-RT RIC in O-RAN Overall Architecture
Legend
O1 3GPP
Service Management and Orchestration framework O-RAN interface
Non-Real Time RIC SMO

O2 A1

Near-Real Time RIC

E2 X2-C
E2
X2-U
O-CU-CP
O-eNB E2 E1
E2 O-CU-UP NG-U

F1-U Xn-U
Open FH M-lane F1-C Xn-C
NG-C

O-DU
Open FH CUS-Plane Open FH M-Plane
O-RU

O-Cloud
Non-RT RIC Architecture Functional View Diagram
Other SMO Framework
Function Non-RT RIC rApp 1 rAPP 2 rAPP n
Inherent SMO framework functionality
R1 (open API for rAPPs
SMO Internal
Interface
External EI
sources

Authentication and Service registration and

External EI authorization function discovery function
interface A1 policy
External EI termination R1 Services exposure function
function
External
AI/ML A1 E1 A1 policy
External AI/ML

interface External AI/ML function Other Non-RT function

rAPP management
Services

termination RIC framework

function
function A1 E1
AI/ML Workflow function
Implementatio function
Human AI/ML Monitoring function
A1 ML
n variability function
Machine
interface Human Machine
A1
Local Craft

termination Inherent Non-RT RIC

Terminal

framework functionality termination

Non-RT RIC Framework
Inherent SMO framework functionality

O2 O1
Termination Termination SMO Framework A1
O2 O1
Near-RT RIC
O-Cloud
E2 Nodes
Non-RT RIC Architecture

Non-RT RIC (O-RAN Functions anchored Functions anchored

Non-anchored
Non-Real-Time RAN inside the Non-RT outside the Non-RT
functions:
Intelligent Controller): RIC framework: RIC framework:
• A logical function • Logical functions in • Logical functions in • Logical functions in
within SMO that the SMO framework the SMO framework the SMO framework
enables non10 real- that are part of the that are not part of that may or may not
time control and Non-RT RIC the Non-RT RIC be part of the Non-
optimization of RAN framework. framework. RT RIC framework
elements and
resources, AI/ML
workflow including
model training and
updates, and policy-
based guidance of
applications/features
in Near-RT RIC.
Non-RT RIC in O-RAN Overall Architecture
• Non-Real Time RAN Intelligent Controller (Non-RT RIC) is the functionality internal
to the Service Management and Orchestration (SMO) framework in O-RAN overall
architecture.

• Non-RT RIC represents a subset of functionality of the SMO framework.

• Non-RT RIC supports intelligent RAN operation and optimization.

• Non-RT RIC logically terminates the A1 interface, and it provides policy-based

guidance, enrichment information, and AI/ML model management [FFS] to the
Near-RT RICs.

• Non-RT RIC can access other SMO framework functionalities, for example
influencing what is carried across the O1 and O2 interface.
Non-RT RIC Composition

• Non-RT RIC Applications (rApps) –

Non-RT RIC Applications that leverage the functionalities
available in the Non-RT RIC Framework /
SMO Framework to provide value added
services related to RAN operation and
Non-RT RIC optimization. The scope of rApps includes, but
Non-RT RIC is not limited to, radio resource management,
Applications
Framework data analytics, and providing enrichment
(rApps) information.

• Non-RT RIC Framework – Functionality internal to the SMO Framework that:

o Logically terminates the A1 interface to the Near-RT RIC.

o Exposes set of R1 services to Non-RT RIC Applications (rApps).

NON_RT RIC
• There are three categories of logical functions in Non-RT RIC framework and SMO framework:

• Functions anchored inside the Non-RT RIC framework.

• Functions anchored outside the Non-RT RIC framework
• Non-anchored functions, which are indicated in dashed line box
Thanks