---
# System prepended metadata

title: <center><i class="fa fa-edit"></i> Near Real Time RIC (RAN Intelligent Controller) </center>
tags: [RIC]

---

# <center><i class="fa fa-edit"></i> Near Real Time RIC (RAN Intelligent Controller) </center>
###### tags: `RIC`
:::
:::warning
**References:**
- [Near-RT RIC Training Coursee](https://hackmd.io/@Nick-Bowei/H1wx1kMld)
- [Open RAN RIC](https://www.thefastmode.com/expert-opinion/18213-the-ultimate-guide-to-open-ran-open-ran-intelligent-controller-ric-part-1)
- [Near Real Time RIC](https://wiki.o-ran-sc.org/download/attachments/3604819/RICnon-RT_OSC_project_proposal.pdf?api=v2)
:::

## 
Before we talking about Near Real Time RIC, we need to understand the concept of RIC. RIC provides advanced control functionality, which delivers increased efficiency and better radio resource management. These control functionalities leverage analytics and data-driven approaches including advanced ML/AI tools to improve resource management capabilities. So, the goal of RIC is it passes information from RAN and use machine learning model to control RAN.

![](https://i.imgur.com/eeK08VP.png)
>source: Linux Foundation

The separation of functionalities on southbound and northbound interfaces enables more efficient and cost-effective radio resource management for real-time and non-real-time functionalities, as the RIC customizes network optimization for each network environment and use case.

::: warning
The main takeaway: RIC is a key element to enable best-of-breed Open RAN to support interoperability across different hardware (RU, servers) and software (DU/CU) components, as well as ideal resource optimization for the best subscriber QoS.
:::
--- 
Look at the following figure.

![](https://i.imgur.com/gMF2uU1.png)

There are 4 groups in the O-RAN Alliance that help define RIC architecture, real-time and non-real-time functionality, what interface to use and how the elements are supposed to work with each other.

- **Working Group 1** looks after overall use cases and architecture across not only the architecture itself, but across all of the working groups.
-  **Working group 2** is responsible for the Non-real-time RAN Intelligent Controller and A1 interface, with the primary goal that Non-RT RIC is to support non-real-time intelligent radio resource management, higher layer procedure optimization, policy optimization in RAN, and providing AI/ML models to near-RT RIC.
-  **Working group 3** is responsible for the Near-real-time RIC and E2 interfaces, with the focus to define an architecture based on Near-Real-Time Radio Intelligent Controller (RIC), which enables near-real-time control and optimization of RAN elements and resources via fine-grained data collection and actions over the E2 interface. 
-  **Working group 5** defines the Open F1/W1/E1/X2/Xn interfaces to provide fully operable, multi-vendor profile specifications that are compliant with 3GPP specifications.

--- 
RIC (RAN Intelligence Controller) can be split into two :
- **Non-Real Time RIC** (Supporting tasks that require > 1s latency)
Non-RT functions include service and policy management, RAN analytics and model-training for the Near-RT RIC.

- **Near-Real Time RIC** (Latency of 1s)
    The Near-Real Time RIC leverages embedded intelligence and is responsible for per-UE controlled load-balancing, RB management, interference detection and mitigation.

The following image shows the relationship between Non-RT RIC and Near-RT RIC
![](https://i.imgur.com/g6zfCEi.png)

---
## Where is Near-RT RIC?
![](https://i.imgur.com/9EEMBuQ.png)

Near-RT RIC sits in the middle of Non-RT RIC and other internal components. As can be seen from the image above, Near-RT RIC is connected to:
- Non-RET RIC by A1
- O-CU-CP by E2-cp
- O-CU-UP by E2-up
- O-DU by E2-du
- O-eNB by E2-en
- ALl component via O1
> CU-CP : Centralized Unit - Control Plane
> CU-UP : Centralized Unit - User Plane
> eNB : The hardware that's' connected to the mobile phone network that communicates directly wirelessly with mobile handsets (UEs). Simply, Access Network.

---
## Why Near-RT RIC?
Near-RT RIC is very needed since as the technology develop, in the future there will be more and more RAN, as such a controller to manage resources is needed for the network to be more intelligent.
The following list is the operation and funcitonality of Near-RT RIC:
- Network Intelligence
    - Policy Enforcement
    - Handover Management
- Resource Assurance
    - Radio-Link Management
    - Advanced SON (Self Organizing Network)
- Resource Control
    - Load Balancing
    - BAN Slicing

---

## The Architecture of Near-RT RIC
![](https://i.imgur.com/gWHy15q.png)

The Architecture of Near-RT RIC includes:
### 1. xApps
- Provide Data monitoring
- Provide Parameter adjustment
- 2 Important part in xApp:
    - Image : Docker Image
    - Descriptor : Contains configuration data for xApp


### 2. Messaging Infrastructure
- Message interaction in Near-RT RIC
- Feature : Low Latency, POint-to-point
- Use RMR (RIC) Mesage Router
    - Library that allows applications to send message to other application.


### 3. Conflict Mitigation
- Resolve Potential overlapping or conflicting situations.
- Direct Conflicts
    - Two/more xApps request different settings to control target.
        - ex : Person A and B is xApps A and B, person A request person C to go left, but person B request person C to go right. 
        - Conflict mitigtion will resolve which actin to take.
- Indirect Conflicts
    - Two/more parameters that affect the same result will potentially have conflict.
        - ex : xApps A contain antenna angle parameter, xApps B contain measurement deviations. Both affect the size of boundary and have a potential conflict when apllied.


### 4. xApp subscription management
![](https://i.imgur.com/tTcZJxd.png)
- Manages subscription from the xApps to the E2 Nodes.
- When two or more xApss subscribe to the same E2 node, the subscription management will merge the identical subscription from different xApp into a single subscription.

### 5. Management Services
- To achieve LCM (Life-Cycle Management) of xApp
- FCAPS Management of Near-RT RIC.
    - FCAPS = Fault, Configuration Accounting Performance Security

### 6. Security
- Prevent malicious third-party xApps from abusing radio network information.
- This is needed since O-RAN is an open interface, everyone can create their own third-party xApps.

### 7. SDL (Share Data Layer)
- It is an API related to database.
- Used to store and show any data to database.
- Enable stateless application processes.
    - ex : In some process, server won't recall states of the user, it will reduce resource consumption.

---
## Interfaces
![](https://i.imgur.com/PeOl91b.png)

1. A1
- Located between Near-RT RIC & Non-RT RIC


![](https://i.imgur.com/isgpdYj.png)
- The message carried includes Policy-based guidane and Machine Learning model management.


2. E2
- Located between Near-RT RIC and E2 Nodes.
- E2 Nodes Includes: 
    - O-DU
    - O-CU CP/UP
    - O-eNB
- The messages sent are: 
![](https://i.imgur.com/LImmkpr.png)


3. O1
Between Non-RT RIC & other components
Supports Non-RT RIC to :
	- FCAPS management
	- Software management
	- File management

### Interface - Comparation
![](https://i.imgur.com/ng9fPmz.png)

---
## Near-RT RIC Components
- Consist of : 
    - RIC Platform (RICPLT)
    - xApps (RICAPP)

![](https://i.imgur.com/gd3GLAT.png)
### Components-Platform : Interface Terminations

#### O1 Mediator
- Communicates Near-RT RIC to O1 Interface.
- Report faulst and events.
- Report real-time Performance management data.

#### A1 Mediator
- Receive A1 policies issued by Non-RT RIC (via HTTP).
- Send A1 policy feedback to Non-RT RIC (via HTTP).
- In Near-RT RIC, will communicate payload to certain xApp via RMR messaging.

#### E2 termination
- Responsible for routing messages from xApps through the SCTP connection to E2 Node.
- Communicate payload to certain xApp via RMR messaging.

### Components-Platform : Managers
#### E2 manager
- Support and records sattes for each RAN.
- Include 5 states : **Null** (not run in database), **Disconnected** (initialized but connection failed or e2 termination uninitialized), **Connected** , **Shutting Down**, **Shut Down**.


#### Routing manager
- Responsible for distributing touring policies among the other components and xApps.
#### Subscription Manager
- Manages subscription and message routing of the subscribed message between E2 termination and xApps.
#### xApp Manager
- Used to deploy/undeploy xApps, will record xApps status and support helath check

---

## Current xApps (Cherry Release)
![](https://i.imgur.com/wIGWyQA.png)

### Traffic Steering Use Case
Purpose : To maximize the QoE improvement (handover).
- Step by step subscription : 
    ![](https://i.imgur.com/EDSzZ0u.png)
    - Setup will be send from E2 Node to Near RT RIC let Near-RT RIC know it's alive.
    - If some xApps wants to use the E2 node, Near-RT RIC will feedback E2 Subscription.
    - If the E2 node accept that, it will transmit some information called E2 Indication.

- Mesage Flow : 

    ![](https://i.imgur.com/E15DMMs.png)
    
