### :school: TEEP 2024_RT LAB_ORAN DPDK

#### :book: Fundamental of OSCRIC and FlexRIC

:::success
List the essential information of this chapter.
1. OSCRIC
2. FlexRIC
3. OSCRIC vs FlexRIC
:::

---

## 1. OSCRIC
### 1.1 What Is a RAN Intelligent Controller (RIC)?

A RAN Intelligent Controller (RIC) is a software component of the Open Radio Access Network (Open RAN) architecture that's responsible for **managing and improving RAN functions**. It plays a crucial role in the Open RAN strategy by promoting compatibility between different vendors, introducing intelligence, flexibility, and programmability to radio access networks. **The RIC allows for the integration of third-party applications that automate and enhance RAN operations on a large scale**, while also supporting innovative use cases that reduce mobile operators, total cost of ownership (TCO) and improve customers, quality of experience (QoE).

### 1.2 What Problems Does RIC Solve?

The RIC helps mobile operators reduce both infrastructure and operational costs, improve network performance, and increase business agility. It also helps them build new revenue streams with personalized services, network slicing, and indoor location tracking capabilities. The O-RAN Alliance, a global community of mobile network operators, vendors, and research and academic institutions focused on open RAN standards and interoperability, has defined a set of use cases and applications that the RIC supports


:::info
Glossary:
**1. Slicing SLA :** According to 5G standardization efforts, a 5G system should support the needs of the business through the specification of several service KPIs such as data rate, traffic capacity, user density, latency, reliability, and availability. These capabilities are specified based on a Service Level Agreement (SLA) between the mobile operator and the business customer, which has resulted in increased interest in mechanisms to ensure slice SLAs and prevent its possible violations.
**2. Governance (ESG) criteria:** ESG stands for Environmental, Social, and Governance. These criteria help assess how a company manages its impact on the environment, how it interacts with its surrounding communities, and how it is managed and overseen internally.
:::

### 1.3 How Does the RIC Work?
The RIC is **divided into non-real-time and near-real-time** components. The **non-RT RIC is an element of** the operator’s centralized Service Management and Orchestration **(SMO) Framework, as defined by the O-RAN Alliance.** Using specialized applications **called rApps**, the **non-RT RIC enables > 1-second control of RAN elements** and their resources. It also uses network data, performance metrics, and subscriber data to provide AI-based recommendations for network optimization and policy guidance to **xApps running on the near-RT RIC**, which in turn provides policy feedback to the non-RT RIC. **The near-RT RIC resides within a telco edge or regional cloud** and typically enables network optimization actions that take between 10 milliseconds to one second to complete

### 1.4 RIC Architecture
This architecture is defined by O-RAN Alliance. the diagram of architecture is shown below:


## 2. FlexRIC
### 2.1 What is FlexRIC

FlexRAN Intelligent Controller (FlexRIC) is a software component developed by OpenAirInterface (OAI). It is part of the Open Radio Access Network (Open RAN) project which aims to create a more open and flexible radio access network by using separate hardware and software.

FlexRIC is responsible for the control and optimization of Radio Access Network (RAN) functions. It makes it possible to manage radio resources more efficiently, improve network performance, and support innovation by enabling automated third-party application integration and optimizing RAN operations.

:::warning
If you want to know more about FlexRIC and its original architecture, you can find more details at: Robert Schmidt, Mikel Irazabal, and Navid Nikaein. 2021.
FlexRIC: an SDK for next-generation SD-RANs. In Proceedings of the 17th International Conference on emerging Networking EXperiments and Technologies (CoNEXT'21). Association for Computing Machinery, New York, NY, USA, 411–425. DOI: https://doi.org/10.1145/3485983.3494870. A pdf copy is available at [Click Here](https://bit.ly/3uOXuCV)
:::

### 2.2 How Does the FlexRIC Works?
Below is the list of features available in FlexRIC divided per component and per service model:


:::info
Glossary:
* KPM (Key Performance Metric): This metric refers to key performance parameters measured in cellular networks, such as throughput, latency, or packet loss.
* RC (Radio Controller): The software component responsible for managing radio resources in the network, including frequency spectrum allocation and transmission power.
* RLC (Radio Link Control): A protocol in the radio control layer that is responsible for organizing reliable data transmission between base stations (BS) and user devices (UE).
* PDCP (Packet Data Convergence Protocol): A protocol in the packet datagram protocol layer responsible for data compression and decompression, as well as providing security functions in mobile networks.
* MAC (Medium Access Control): A protocol in the medium access control layer that regulates access to physical channels in cellular networks, including time and frequency allocation.
* SLICE: This term refers to the concept of network slicing in 5G networks, where the network infrastructure can be divided into virtual chunks that can be organized independently to support different types of services with different qualities.
* TC (Traffic Classifier): A component used to classify network traffic based on certain types or characteristics, such as application or service type.
* GTP (GPRS Tunneling Protocol): A protocol used to transmit data packet traffic between nodes in a mobile network, such as between gateway nodes and base nodes.
:::

## 3. FlexRIC vs OSCRIC

From the references about FlexRIC, i got this : [Click Here for More Details](https://bit.ly/3uOXuCV)

*The reference O-RAN RIC architecture relies on micro-services, containerized through Docker and orchestrated by Kubernetes. Correspondingly, each micro-service’s image uses disk space. Table 2 lists the image sizes of a dockerized FlexRIC for a RTT test (as in Section 5.2) and a statistics use case (as in Section 5.3), and the O-RAN RIC platform (15 platform components) with corresponding O-RAN xApps. It is apparent that due to containerization of all platform components individually, the O-RAN RIC requires much more storage, going contrary the 5G design principle of ultra-leanness,forcing to need resources even for scenarios where the advantages oered by Docker and Kubernetes are not needed.*


*The O-RAN architecture impacts the latency, since it imposes two hops for messages (from xApp via “E2 termination” to agent). In the following experiment, we measured the RTT with two distinct payloads (i.e., 100 B and 1500 B) as in Section 5.2, between (i) a FlexRIC agent and a FlexRIC controller utilizing the E2SM-HW, and (ii) a FlexRIC agent and O-RAN RIC. In FlexRIC, we use a relaying controller to emulate two hops, which, unlike O-RAN RIC, is not imposed by FlexRIC but added to carry out a fair comparison. As it can be observed from Fig. 9a, O-RAN RIC increases the RTT by at least three times for small and two times for medium load compared to FlexRIC.*

*In a second experiment, we consider a monitoring use case similar to Section 5.3, in which 10 dummy agents export MAC statistics (excluding HARQ) for 32 UEs using E2AP indication messages every ms. We measure CPU usage and memory footprint as reported by docker stats, shown in Fig. 9b. (For the O-RAN case, we added the CPU and memory usage of the platform components and xApp.) The design of O-RAN RIC imposes that indication messages are decoded twice, once in the “E2 termination”, and the xApp. The CPU usage of FlexRIC is 83 % lower than O-RAN RIC, the O-RAN xApp alone using as much CPU as FlexRIC, and the rest being used by the “E2 termination”. We attribute this to an inefficient implementation (we used the default “E2 termination” image, version 5.4.8). Also, the O-RAN RIC uses much more RAM, which is due to the high number of platform functions running in separate containers, which are also partially written in higher-level languages, such as Go, as opposed to FlexRIC’s C. These findings confirm that O-RAN RIC imposes additional overhead by design for communication between xApps and agents, even if not required, which might become a bottleneck.*

## 4. Conclusion

| Aspect | ORAN-RIC | FlexRIC |
| -------- | -------- | -------- |
| Storage Requirement | Requires more storage space as each platform component is individually containerized |Requires less storage space as not all components have to be individually containerized |
|Latency |Resulted in increased RTT (Round Trip Time) due to introducing two message hops | Lower RTT (Round Trip Time) as no additional message hops are required|
|CPU Usage| Higher CPU utilization due to message processing involving decryption at "E2 termination" and xApp | Lower CPU utilization due to simpler and more efficient approach to message processing|
|Memory Footprint| Requires a larger memory footprint as it runs many platform functions in separate containers | Requires a smaller memory footprint due to a more lightweight approach and the use of a more efficient programming language