### :school: TEEP 2024_RT LAB_ORAN DPDK

#### :book: Learn about E2 Interface and xApp

:::success
List the essential information of this chapter.
1. E2 Interface
2. xApp
:::
---
## 1. E2 Interface
### 1.1 What is E2 Interface?
E2 is the interface between NearRealtime-RIC (NR-RIC) and E2Node (CU and DU). DU control RU, E2 does not connect RU directly. Protocol specifications are being worked on by the O-RAN alliance. WG3 (working group 3) works on E2. WG2 on A1.

**The simplify diagram about E2 Interface:**


**The wide diagram of E2 position in ORAN Architecture:**


### 1.2 Workflow between NR-RIC and E2 Node


* E2AP：first step , setup the connection
* E2SM-KPM：second step. NR-RIC request KPI counters from E2 node and E2 node responses answer
* E2SM-RC：third step , NR-RIC request configuration change to CU,DU, RU via DU

The workflow explanation above is still in general terms that make it easy for you to understand and of course it will be very complex if you directly explain the workflow.

before proceeding to a more detailed workflow, it is better if you understand what E2AP, E2SM, and E2T are. after understanding these 3 things, I will try to explain the workflow in E2.

### 1.3 What is E2AP, E2SM, E2T
**E2AP (E2 Application Protocol)**
* E2AP is a protocol that defines the common communication method between non-real-time RAN Intelligent Controllers (RIC) and disaggregated E2 nodes in a 5G network.
* In the context of E2AP, there are four types of actions defined: Report, Insert, Policy, and Control. These indicate the types of messages or instructions that can be sent between RIC and E2 nodes.

**E2SM (E2 Service Model)**
* E2SM is a "contract" between external applications (xApp) and E2 nodes in a 5G network.
* E2SM defines specific function protocols implemented on top of the E2AP specification. This means that E2SM details how an xApp should communicate with E2 nodes to perform its functions.
* Implementing a specific E2SM on the gNodeB (gNodeB) side requires explicit feature development and specific interface/stack enhancements.
* More detailed E2SM (Service model) specifications define the function specific protocol that is implemented on top of the E2AP specification. Typical functions are X2AP, F1AP, E1AP, S1AP, NGAP interfaces and RAN internal functions UE, Cell, Node.

E2AP & E2SM KPM support added to OAI

**E2T (E2 Terminator)**
Purpose of E2 Terminator (E2T):
* E2T is part of the RAN Intelligent Controller (RIC) aimed at providing additional services and collecting near real-time information through the E2 interface.
* RIC hosts one or more "xApps" that utilize the E2 interface to gather near real-time information and provide value-added services.

E2 Terminator Architecture:
* E2T acts as the termination point for the E2 interface and facilitates message exchange between xApps and the RAN.
* The RIC Platform, which runs E2T, provides shared services and common functions that do not play a role in RAN functionality.

Methods Supported by E2 Terminator:
* E2T supports opening or removing SCTP connections during E2/EN-DC setup or removal.
* E2T maintains its own repository to map RAN to SCTP connections.
* It listens to all its SCTP connections and sends messages to relevant xApps via RMR(Routing Message Router).
* E2T also listens to RMR connections and converts requests to E2AP, then sends them to the appropriate SCTP.

High-Performance Function of E2 Terminator:
* For high performance and multiple connections, E2T uses epoll, a Linux kernel system call for a scalable I/O event notification mechanism.
* E2T is a single thread that listens (using epoll()) for events from E2 or RMR, and handles messages accordingly.

:::info
RMR stands for "RIC Message Routing". It is a mechanism used in telecommunication network architectures to transmit messages between different entities in the network, such as between xApps and E2 Terminator (E2T) in the previously described case.

Specifically, in the previously described context of E2T, RMR is used as an intermediary to send messages between E2T and xApps. When xApps sends a request or message to E2T, the message is sent through RMR. Then, E2T receives the message from RMR, performs the necessary processing, and provides the corresponding response back through RMR to xApps.

:::

**Diagram of E2T, E2AP, and E2SM on O-RAN Architecture**


### 1.4 E2AP v01.00 Elementary procedures

#### 1.4.1 E2AP v01.00 Elementary procedures – Implementation Status

E2AP elementary procedure can be grouped into two class. Class 1 means that RAN will response. Class 2 Means that RAN will not response. Elementary procedures for E2AP could be seen in the figures below.

**Class 1 Elementary Procedures**


**Class 2 Elementary Procedures**


**Relationship Between RIC Services and E2AP Procedures**


#### 1.4.2 E2AP functional procedures





#### 1.4.3 Changes in E2AP connection setup


* E2 nodes instead of RIC initiate SCTP and first message (RIC creates E2 SETUP RESPONSE)
* E2 SETUP REQUEST carries RAN E2SM Function List and so no need to wait for RIC Service Update
* RAN configuration information not supported. Coming back in later spec and post-Cherry

#### 1.4.6 Update E2AP for v01.01

E2 Node Configuration Update
* • Provides basic RAN configuration to near-RT RIC for each E2 Node
* • Added to support RIC-174

TNL (Transport network layer) for E2 for scalability
* Provides support for E2 interface to use multiple SCTP connections
* Added to support RIC-173

OID in E2AP
* Assists E2SM RAN function description decoding

For more details about workflow between NR-RIC and E2 Node, you can read this reference documentation. [Click Here](https://hackmd.io/@muhammadfadlin/SJfCrENad#-Global-Procedures)

## 2. xApp

### 2.1 Definition of xApp
An xApp (eXtended application) is a software application used by the RAN Intelligent Controller (RIC) in the O-RAN architecture to implement certain functions or services in near- or real-time. These functions include radio resource management, mobility management, and security. The xApp is typically implemented on top of the Radio Intelligent Controller (RIC) and communicates with other components through the E2 interface in an O-RAN architecture.

**Does SON and xApps same ?**

SON is Self Organizing Networks, in our point of view xApps functions are similar and can be augment as the next generation of SON for Open RAN. xApps are repackage SON to provide a flexible, standards based, interoperable, multivendor, programmable feature applications for RAN optimization.

### 2.2 Key Technology of xApps

* xApps supports cloud-native microservice based deployment
* xApps are host on Near-RT RAN Intelligent Controller usually at networks edge
* xApps are responsible for controlling and optimizing RAN functions and enhance the spectrum efficiency
* xApps provides “northbound” interfaces A1 and O1 interfaces toward the Non-RT RIC
* xApps collects data from RAN functions (CUs,DUs) on “southbound” interface as E2 Interface
* xApps also have an internal messaging framework to handle conflict mitigation, subscription management, app lifecycle management functions and security


### 2.3 RICAPP
RICAPP is subproject of the ORAN software community with the focus on developing open source xApps to:
* Demonstrate how to utilize the features of the xApp SDK and
* Support O-RAN SC end-to-end use cases: Traffic steering, life cycle management, and health checks.
* Source code in https://gerrit.o-ran-sc.org/ (in “ric-app” repos).
* Code contributors: AT&T, Samsung, and HCL and others under discussion.
* xApp source code under the Apache 2 or O-RAN software licenses.
* xApps written in C++, Python, and Go.

Examples of ric app:
* ric-app/ad - Anomaly Detection xApp (C-D release –HCL， HCL Technologies India) • ric-app/bouncer - xApp for RIC performance benchmarking (D release -HCL)
* ric-app/hw - HelloWorld C++ demo xApp including a demo E2 SM (HelloWorld SM) (B-D releases -AT&T) • ric-app/hw-go - HelloWorld go demo xApp (D release -Samsung) • ric-app/hw-python - HelloWorld python demo xApp (D release -Samsung) • ric-app/lp - Load Prediction xApp (D release -CCMC)
* ric-app/mc - Measurement Campaign xApp (B-D release -AT&T) -note: This xApp depends on input feed (X2 events in protobuf format) that is currently not provided by any open source xApp. (Note: com/gs-lite contains the GS-Lite stream processing library used by MC).
* ric-app/qp - QoE Prediction xApp (trivial versions in earlier releases, real ML in D release -AT&T, HCL)
* ric-app/ts - Traffic Steering xApp (B-E releases -AT&T, UTFPR)
* ric-app/kpimon-go - KPI Monitor xApp uses an extended version of the E2 KPM SM to collect metrics from E2 Node (C-D releases -
* Samsung
* scp/ric-app/ssp - Signal Storm Protection xApp (on hold due to patent issue-Samsung)

**xApp frameworks provide high-level interfaces**

**Goals:** Make it easy to write xApps – identify common code, abstract where possible

**Approach:** Identify what is xApp specific and what is generic in handling E2, O1, A1, and inter-xApp communication.
* **Configuration management (O1-CM):** xApp simply provides a function that processes the configuration data (JSON) – it does not need to worry about how and when the configuration data gets to the xApp.
* **Reporting (O1-PM,FM):** Simple intuitive libraries for reporting metrics and alarms – xApp does not need to worry how this data is communicated to OAM.
* **Policy (A1-P):** xApp declares which policy types it supports and provides a function for processing policy instance creation/deletion payloads (JSON) – it does not need to worry about how to get them.
* **E2:** Initial steps in abstracting E2 subscription handling.
* **Messaging:** xApp simply constructs a message and sends it – RIC’s policy-based routing will take care of delivering to the required destinations.