<style>
.title {
color: #009933;
font-weight:bold;
}
.highlight {
color: #ff4d4d;
font-weight:bold;
border-bottom:2px red solid; padding-bottom:2px;
}
</style>
<!-- <font class="highlight"> -->
<!-- <font class="title"> -->
<!-- 縮寫提示 -->
<!-- *[O-RAN]:Open Radio Access Network -->
:::warning
# <center><i class="fa fa-book"></i> Introduction to Near-RT RIC </center>
:::
###### tags: `study` `Near-RT RIC`
:::success
**🎯 Goals:**
- [x] - <a href="#Module-1-Characteristic-of-Near-RT-RIC">To know the characteristic of Near-RT RIC</a>
- [x] - <a href="#Module-2-Overall-architecture-of-Near-RT-RIC">To know the overall architecture of Near-RT RIC</a>
- [x] - <a href="#Module-3-Functions-Description">Take notes on Functions Description</a>
- [x] - <a href="#Module-4-APIs">Take notes on APIs</a>
- [x] - <a href="#Moudle-5-FCAPS">To notes the FCAPS</a>
- [x] - <a href="#Module-6-Summary">Summary</a>
:::
:::info
:bookmark: **Reference:**
- [O-RAN ALLIANCE](https://www.o-ran.org/)
- [O-RAN Architecture Description](https://www.o-ran.org/specifications)
- [WG3: Near-real-time RIC and E2 Interface Workgroup:](https://orandownloadsweb.azurewebsites.net/specifications#:~:text=O%2DRAN%20Near%2DRT%20RAN%20Intelligent%20Controller%20Near%2DRT%20RIC%20Architecture%202.01%0AO%2DRAN.WG3.RICARCH%2Dv02.01)
- O-RAN Near-RT RAN Intelligent Controller Near-RT RIC Architecture 2.01
(O-RAN.WG3.RICARCH-v02.01)
- [RESTful API](https://medium.com/itsems-frontend/api-%E6%98%AF%E4%BB%80%E9%BA%BC-restful-api-%E5%8F%88%E6%98%AF%E4%BB%80%E9%BA%BC-a001a85ab638)
:::
[toc]
# Module 1: Characteristic of Near-RT RIC
## 1.1 The interface between Non-RT RIC & Near-RT RIC
## 1.2 Purpose of Near-RT RIC
- The Near-RT RIC architecture and internal interfaces shall be open to support 3rd party xApps. Near-RT RIC shall consist of multiple xApps and a set of platform functions that are commonly used to support the specific functions hosted by xApps.
<!-- ## 1.3 The near RT RIC can be deployed centrally or on the network edge.
-  -->
# Module 2: Overall architecture of Near-RT RIC
*[up-to-date]:最新
## 2.1 Platform
- **Near-RT RIC shall** provide a ==database== that stores an up-to-date RAN information:
- history of time-varying network state
- configurations related to E2 Nodes, Cells, Bearers, Flows, UEs, etc.
> **This information shall be provided as a service to any xApp that requests it**
- provide ==AI/ML== tools that support for data pipelining, training, and performance monitoring;
> Artificial Intelligence，AI
> Machine Learning，ML
- provide logging, tracing and metrics collected from Near-RT RIC platform and xApps toward ==SMO==;
- support resolution of ==potential conflicts or overlaps of controls== from xApps toward an **E2** node;
> point: 控制的潛在衝突或重疊
- provide an **O1** interface;
- be able to route **A1** policy management messages to **the registered xApps** based on A1 policy type and operator policies;
- control access of **A1-EI** types for xApps based on operator policies.
> A1-EI: A1-Enrichment Information，A1-濃縮訊息
*[RRM]:Radio resource management
*[E2SMs]:E2 service models
## 2.2 xApp
- **xApp** may enhance the ==RRM== capabilities of Near-RT RIC;
- be associated with zero, one or more E2SMs;
- E2SMs without any intermediary xApp;
- **receive event-triggered** information and time-varying network state.
- **collected information** to Near-RT RIC;
- provide a descriptor that includes the following basic information of the xApp:
- Configuration: It includes a data dictionary for configuration data
- Control: xApp URL, parameters, input/output type;
- Metrics: metric name, type, unit and semantics.
- be capable of discovering the Near-RT RIC ==APIs== they consume.
## 2.3 API
- The hosting of ==3rd party xApps==;
- the Near-RT RIC control loop of execution time from ==10 milliseconds to 1 second==;
- Near-RT RIC shall provide APIs decoupled from specific implementation solutions, including a Shared Data Layer (SDL) that works as an overlay for underlying databases and enables simplified data access;
- An API ==repository/registry== for the services provided by the Near-RT RIC platform and/or xApps;
- Near-RT RIC shall provide means to ==restrict== xApps from discovering some published APIs based on configured policies;
- Near-RT RIC shall provide APIs enabling all xApps to directly use the information elements of E2SMs with which they are associated;
- programming languages (e.g. **C, C++, Python, Go**)
- Near-RT RIC APIs shall support xApp subscription management based on operators’ policies. An xApp may be restricted to interface with only a subset of E2 Nodes by such policies. Near-RT RIC shall be responsible for routing messages between this xApp and the subset of E2 Nodes.
# Module 3: Functions Description
## 3.1 Summary Figure
## 3.2 Database and SDL (Share Data Layer)
*[UE]: User Equipment
*[NIB]: Network Information Base
### 3.2.1 UE-NIB (Database)
maintains ==tracking and correlation== of the UE identities associated with the connected E2 Nodes.
### 3.2.2 R-NIB (Database)
==stores== the configurations and **near real-time information** relating to connected E2 Nodes and the mappings between them.
### 3.2.3 SDL
- The SDL (Shared Data Layer) is used by xApps to subscribe to database notification services and to **read, write and modify** information stored on the database.
- UE-NIB, R-NIB and other use case specific information may ==be exposed== using the SDL services.
## 3.3 xApp Subscription Management
- manages subscriptions ==from xApps to E2== Nodes;
- enforces authorization of policies controlling xApp access to messages;
- enables merging of identical subscriptions ==from different xApps into a single subscription== toward an E2 Node.
## 3.4 Conflict Mitigation
> point: 衝突緩解
An application will typically ==change one or more parameters== with the objective of optimizing a specific metric.
**Conflict Mitigation is necessary** because xApps objectives may be chosen/configured such that they result in conflicting actions.
### 3.4.1 <span style="color:#FFF;background:#33cc33; border-radius:8px; padding: 3px 9px;"> Direct Conflicts </span>
- Two or more xApps request different settings for the **very same configuration** of one or more parameters of a Control Target.
- The new request from an xApp may conflict **with the running** configuration resulting from a previous request of another or the same xApp.
- The total requested resources from different xApps may ==exceed the limitation of the RAN== system.
:::success
Approaches:
  The xApps or a Conflict Mitigation component needs to make the final determination on whether any specific change is made, or in which order the changes are applied.
:::
### 3.4.2 <span style="color:#FFF;background:orange; border-radius:8px; padding: 3px 9px;"> Indirect Conflicts </span>
- some **dependence** among the parameters and resources that the xApps target can be observed
> E.g., antenna tilts and measurement offsets are different control points, but they both impact the handover boundary.
:::success
Approaches:
 **Based on the observations**, the system has to decide on potential corrections
 e.g., rolling back one of the xApp actions.
:::
### 3.4.3 <span style="color:#FFF;background:red; border-radius:8px; padding: 3px 9px;">Implicit Conflicts </span>
- optimizing one metric may have **implicit, unwanted, and maybe adversary** side effects on one of the metrics optimized by another xApp.
> E.g., protecting throughput metrics for GBR users may degrade non-GBR metrics or even cell throughput.
*[GBR]: Guaranteed Bit Rate
> point: Guaranteed Bit Rate (GBR)
:::success
Approaches: <span style="color:red">**(most difficult)**</span>
- In some cases, it may be possible to design around such conflicts by ensuring that use cases (xApps) target different parameters, thus falling back to approach Indirect conflicts)
- But preferably, **a generic approach** to managing such conflicts is established.
:::
### 3.4.4 Approaches
- The individual xApp goals are defined by A1 policies, but it is also important to define utility metrics that incorporate the relative importance of each of **the metrics targeted** by the xApps as well as the importance of the optimization (use case).
- A Conflict Mitigation function may also use ==ML approaches==
> e.g., Reinforcement Learning, to a-priori assess, for each proposed change, the likely probability of degrading a metric versus the potential improvement.
## 3.5 Messaging Infrastructure
> point: 訊息交互 in RIC
- **low-latency** message delivery service
- **`Registration`**: Endpoints register themselves to the messaging infrastructure;
- **`Discovery`**: Endpoints are discovered by the messaging infrastructure initially and registered to the messaging infrastructure;
- **`Deletion`**: Endpoints are deleted once they are not used anymore.
- ==APIs:==
- For **sending** and **receiving** messages;
- **point-to-point mode** (e.g. message exchange among endpoints)
- **publish/subscribe mode** (e.g. real-time data dispatching from E2 termination to multiple subscriber xApps)
## 3.6 Security
*[malicious]:惡意的
- To prevent malicious xApps from abusing radio network information
(e.g. exporting to unauthorized external systems)
- Control capabilities over RAN functions.
> point: 避免惡意的xAPPs過度使用無線網路的資訊
## 3.7 Management Services
*[MnS]:management services
- <u>**OAM Management**</u>:
- Operations
- Administration
- Maintenance
- O1 related
- <u>**Fault & Configuration Management**</u>:
  provides Near-RT RIC platform **Fault Supervision & Provisioning (MnS)** over the O1 interface;
- <u>**Logging**</u>: To **capture information** needed to operate, troubleshoot and **report** on the performance of the Near-RT RIC platform and its constituent components.
- <u>**Tracing**</u>: tracing mechanisms are needed to **monitor the transactions or a workflow**. Individual traces can be analysed to understand timing latencies as the workflow traverses a particular Near-RT RIC component.
- <u>**Metrics collection**</u>: metrics for performance and fault management specific to each xApp logic and other internal functions are collected and published for authorized consumer (e.g., SMO)
## 3.8 Interface Termination
### 3.8.1 E2 Termination
*[SCTP]:Stream Control Transmission Protocol，串流控制傳輸協定
*[TCP]: Transmission Control Protocol，傳輸控制協定
*[UDP]: User Datagram Protocol，使用者資料包協定
> point: E2 介面負責將 xAPP 做成的指令傳達至對應的 E2 Node,進行相對應的工作.
- terminates SCTP connection from each E2 Node;
- routes messages from xApps through the **SCTP** connection to an E2 Node;
- **decodes** the payload of an incoming ASN.1 message enough to determine message type;
- **receives** and **respond** to the E2 Setup Request from an E2 Node;
- notifies xApps of the list of RAN functions supported by an E2 Node based on information derived from the E2 Setup and RIC Service Update procedures;
- notifies the **newly connected** E2 Node of the list of accepted functions.
:::info
**(SCTP) Stream Control Transmission Protocol，串流控制傳輸協定：**
  As a transport layer protocol, SCTP can be understood as similar to TCP and UDP. It provides services a bit like TCP, while combining some of the advantages of UDP. It is a protocol that provides a ==reliable, efficient and ordered data transfer==. In contrast, TCP is byte-oriented, while SCTP is for framed messages.
**(TCP) Transmission Control Protocol，傳輸控制協定：**
 It is a connection-oriented, reliable, byte stream-based transport layer communication protocol.
**(UDP) User Datagram Protocol，使用者資料包協定：** is a simple packet-oriented communication protocol.
:::
### 3.8.1 A1 Termination
> point: A1 介面透過 RESTful API 的方式, 以 1-to-1 對應方式，使 rAPP 提供 xAPP 支援
- A1 policies and enrichment information **received** from Non-RT RIC
- Or A1 policy feedback **sent** towards Non-RT RIC.
- A1 execution steps
- step 1: Get information from RAN
- step 2: Create or select a training module
- step 3: Put the information obtained by training module & RAN into A1 policy, and transmit A1 policy from Non RT-RIC to Near RT-RIC
- step 4: Near RT-RIC receives A1 policy and confirms whether the values are within the range
- step 5: Near RT-RIC adjusts RAN parameters
### 3.8.1 O1 Termination
> point: O1 主要是讓 xAPP 統合 E2 Node 資訊後, 向 non-RT RIC 提供錯誤與效能資訊
**Near-RT RIC** is the MnS ==producer== and **SMO** is the MnS ==consumer==:
- Exposes provisioning management services from Near-RT RIC to O1 provisioning management service consumer;
- Exposes FM & PM services to report faults and events from Near-RT RIC to O1 FM & PM service consumer;
- Exposes file management services to download ML files, software files, etc. and upload log/trace files to/from file MnS consumer;
- Exposes communication surveillance services to O1 communication surveillance service consumer.
:::info
**(FM) faults and events information management** `提供錯誤資訊`
**(PM) performance management** `提供效能資訊`
:::
## 3.9 API Enablement
 E2, A1, Management, and Database services
- **Repository / Registry** services for the Near-RT RIC APIs.
- Services that allow discovery of the registered Near-RT RIC APIs.
- Services to **authenticate** xApps for use of the Near-RT RIC APIs.
- Services that **enable** generic subscription and event notification.
The API enablement services can be accessed by the xApps via one or more enablement APIs.
> <font style="color:red">**NOTE:**</font> The provided enablement APIs may need to consider the level of trust related to the xApp (e.g. 3rd party xApp, RIC-owned xApp, etc.).
## 3.10 AI/ML Support
### 3.10.1 Data Pipeline
- Input
- E2 interface
- A1 interface
- Output
- training capability
### 3.10.2 Training
generic and use case-independent capabilities
## 3.11 xApp Repository Function
- **selection of xApps for A1 message routing** based on policy type and operator policies;
- xApp Repository Function provides the **policy types** supported in Near-RT RIC to the A1 termination function.
(The supported policy types are based on policy types supported by the <u>registered xApps and operator policies</u>);
- xApp Repository Function enforces xApp access control to requested A1-EI type based on operator policies.
## 3.12 xApps
The xApps collaborate with the Near-RT RIC platform functions to support various specialized use cases.
# Module 4: APIs
## 4.1 OverView
The Near-RT RIC APIs are essential to host 3rd party xApps in an inter-operable way on different Near-RT RIC platforms.
- **A1 related APIs**
- **E2 related APIs:** associated xApp Subscription Management and Conflict Mitigation functionality;
- **Management APIs:** APIs allowing to access management related functionality. They are used for services such as **O1** Termination and management services (logging, tracing, metrics collection, etc.);
- **SDL APIs:** APIs allowing to access Shared Data Layer related functionality;
- **Enablement APIs:** APIs between xApps and API enablement functionality.
  
## 4.2 API approaches
### 4.2.1 Network API approach:
**Each relevant Near-RT RIC endpoint exposes a network endpoint** and specifies a particular data encoding protocol and a network transport protocol that should be used to communicate with it. A different network API may be specified for each RIC API reflecting a trade-off between different service requirements.
### 4.2.2 SDK approach:
This SDK is a ==software library== which handles all connection management and exposes a simple API for the xApp to interact with the Near-RT RIC. The interface between the SDK library embedded in the xApp and the Near-RT RIC Platform may be either vendor proprietary or aligned to the specified Network API.
 
# Moudle 5: FCAPS
FCAPS is the ISO Telecommunications Management Network model and framework or network management.
FCAPS concept ++in Near-RT RIC++ is responsible for **fault management**, **configuration** management and performance management as a service producer of ==SMO==.
         
> 故障、配置、審計、性能、安全
# Module 6: Summary
In the architecture design of near-RT, it is simpler than non-RT RIC, and introduces virtualization and resource sharing. Its architecture uses container-based computing architecture (for example: kubernetes), and provides a common data access layer to Separate computing (xAPP) and data storage, and provide **data access management, security management and service management** between various xAPPs
----
:::spoiler Detail
*[FM]: faults and events information management
*[PM]: performance management
*[REST]: Representational State Transfer
*[RMS]: RIC Message Router
*[SDK]: software development kit
> **(FM) faults and events information management**: `向 non-RT RIC 提供錯誤資訊`
> **(PM) performance management**: `提供效能的資訊`
> **(REST) Representational State Transfer**: `一種軟體架構、無狀態(獨立運作每次請求)`
> **(RRM) Radio resource management**
> **(E2SMs) E2 service models**
> **(UE) User Equipment** `用戶設備`
> **(NIB) Network Information Base**
> **(RMS) RIC Message Router**
> **(SCTP) Stream Control Transmission Protocol** `串流控制傳輸協定`
> **(TCP) Transmission Control Protocol** `傳輸控制協定`
> **(UDP) User Datagram Protocol** `使用者資料包協定`
> **(SDK) software development kit** `軟體開發工具包`
> **(GBR)** Guaranteed Bit Rate
:::
Sign in with Wallet
Connect another wallet