# Daily Note 13/07/2020
###### tags: `Daily Notes` , `O-RAN`
## Name : Christofel Rio Goenawan
## University : Bandung Institute of Technology (ITB)

---

## Schedule:
1. Study deeper about Non- RT RIC.
2. Study detailed background ( what ? why ? how ? ) of A1 interface.
3. Study works of A1 interface in O- RAN.
## Outcome :
1. Explain the detailed use case of Non- RT RIC.
2. Explain detailed background of A1 interface.
3. Exlain works of A1 interface in O- RAN Architecture.
## Further Plan :
- Study more detailed about AIO Installation in Kubernets
- Study more detailed about Acumos AI architectures in Kubernetes.
- Try to deploy AIO in NTUST server.

---

## Daily Log

### 1. Study deeper about Non- RT RIC. <mark>(9.00)</mark>
- Study more detail explanation in [documentation](https://static1.squarespace.com/static/5ad774cce74940d7115044b0/t/5d56c1f858dd040001fa1b71/1565966861943/ORAN-WG2.UsecaseRequirements.v01.00.pdf) and other resources.

### 2. Study detailed background ( what ? why ? how ? ) of A1 interface. <mark>(12.00)</mark>
- Study more detail explanation in [documentation](https://docs.acumos.org/en/clio/submodules/system-integration/docs/oneclick-deploy/user-guide.html#deployment-notes-for-specific-k8s-distributions) and other resources.

### 3. Study works of A1 interface in O- RAN. <mark></mark>
- Study more detail explanation in [documentation](https://docs.acumos.org/en/clio/submodules/system-integration/docs/oneclick-deploy/user-guide.html#deployment-notes-for-specific-k8s-distributions) and other resources.

---

## Report

### 1. Works of Non- RT RIC

> In this note Writer use [Ferlinda's Notes](https://hackmd.io/@ferlinda/r1R0VVsAB) and [Akmal's Notes](https://hackmd.io/@akmalns/BkktSnfkw) as study sources.

#### Non- RT RIC use case
There are 3 main use case for NON- RT RIC, that is **Trafic Steering Use Case, QoE Use Case and 3D-MIMO beamforming optimization use case**.

1. **Traffic Steering Use Case**

The rapid traffic development and wide range frequency bands utilized in a commercial network make it not easy to adjust the traffic in a balanced distribution. Standard control are limited to **adjusting the cell reselection** and **handover parameters**, and **modifying load calculations and cell priorities**.
This traffic steering control suffer some problem such as:

- It’s not easy to adapt the RRM control to various scenarios and optimization objectives
- The traffic management is usually passive that is rarely taking advantage of capabilities to predict network and UE performance.
- Non-Optional traffic management with slow response time, due to various factors such as inability to select the right set of UEs of control action. It may result in non-optimasl system and UE performance such as reduced throughput and increased handover failures.

This use case aims to **drive traffic management in RAN in accordance with defined intents, policies, and configuration while enabling AI/ML-based solution**.

Systems that works in this process:

- **Non-RT RIC**
- **Retrieve necessary performance, configuration and other data** for **constructing/training relevant AI/ML models that will be deployed in near-RT RIC** to assist in the traffic steering function
- Retrieve **necessary performance, configuration and other data for training models** for non-real-time optimization of configuration parameters related to traffic steering and mobility management in RAN (over O1 interface)
- Retrieve **necessary performance, configuration and other data for defining and updating intents and policies** to guide the behavior of traffic steering function in near-RT RIC.

- **Near-RT RIC**
- Support update of AI/ML models from non-RT RIC
- Support interpretation and execution of intents and policies from non-RT RIC
- Support necessary performance, configuration and other data for defining and updating intents and policies for tuning relevant AI/ML models

- **RAN**
- Support data collection with required granularity to NMS over O1 interface
- Support non-real-time configuration-based optimization of traffic steering parameters over O1 interface

The requiered data:
1. Measurement report with RSRP/RSRQ/CQI information for serving and neighboring cells
2. UE connection and mobility/handover statistics with indication of successful and failed handover etc
3. Cell load statistics
4. Per user performance statistics

The detailed Traddic Steering use case scheme can be shown as below.


2. **QoE Use Case**

The highly demanding 5G native applications are both **bandwidth consuming and latency sensitive**. Current semi-static QoS framework can’t efficiently satisfy diversified QoE requirements especially taking into account potentially significant fluctuation of radio transmission capability.

The main aim is to **ensure QoE optimization be supported within the O-RAN architecture and its open interfaces**. Multi-dimensional data likes user traffic data, QoE measurements, network measurement report, can be acquired and processed via ML algorithms to support traffic recognition, QoE prediction and QoS enforcement decisions. ML models can
be trained offline and model inference will be executed in a real-time manner.

Systems that works in this process:

- **Non-RT RIC**
- **Retrieve necessary performance, configuration and other data** for **constructing/training relevant AI/ML models that will be deployed in near-RT RIC** to assist in QoE optimization function.
- Training of potential ML models for predictive QoE optimization.
- Send policies/intents to near-RT RIC to drive the QoE optimization at RAN level in terms of expected behavior

- **Near-RT RIC**
- Support update of AI/ML models from non-RT RIC.
- Support execution of the AI/ML models from non-RT RIC, e.g. application classification, QoE prediction, and available bandwidth prediction.
- Support interpretation and execution of intents and policies from non-RT RIC to derive the QoE optimization at RAN level in terms of expected behavior.
- Sending QoE performance report to Non-RT RIC for evaluation and optimization

- **RAN**
- Support network state and UE performance report with required granularity to NMS over O1 interface
- Support QoS enforcement based on messages from A1/E2 Which are expected to influence RRM behavior

The AI/ML model and distribution scheme can be seen as below.


The Policy generation and performance evaluation flow diagram can be seen as below.


3. **3D-MIMO beamforming optimization use case**

Massive Multiple Input- Multiple Output ( usually called "M-MIMO" ) is the **key to increase performance and QoS in 5G network**. With the beamforming of the transmitted signal, the user (either Single User or Multi User) will receive a higher SINR and user throughput. Massive MIMO can be deployed in 5G macro-cells as well as in heterogenous network where Macro-cells and 3D-MIMO small cells co-exist and complement each other for better aggregated capacity and coverage.

This solution (M-MIMO) still have some problem as below.

1. High inter-cell interference
2. Unbalanced traffic between neighboring cells
3. Low performance of cell edge users
4. Poor handover performance

The main aim is to **allow the operator to flexibly configure M-MIMO system parameters by means of policies, configuration or machine learning techniques, according to objectives defined by the operator**.

In this case only **Non- RT RIC** system works. The works are:
- **Retreive necessary configurations, performance indicators, measurement reports and other data from NMS and RAN directly for the purpose of constructing/training relevant AI/ML models** that will run in Non-RT RIC.
- **Retreive necessary user location related information** i.e. GPS coordinates, from the applicatioin layer for the purpose of **constructing/training relevant AI/ML models that will run in Non-RT RIC**.
- **Retreive necessary user context information** i.e. mobility pattern prediction, from the near-RT RIC for the purpose of constructing/training relevant AI/ML models that will run in Non-RT RIC
- **The trained AI/ML model to infer the user distribution of multiple cells and predict the optimal configuration of M-MIMO parameters for each cell**.
- **Send the optimal beam pattern configuration and/or policy to NMS** for update
- **Monitor the performance of all the cells. When the optimization objective fails, initiate fall back procedure**. Meanwhile the AI/ML model should be retrained according to the new feedback and input data and the old model is updated.

The 3D MIMO beamforming optimization scheme can be seen as below.


---

### 2. How does A1 Interface Works ?

> In this note Writer use [Ferlinda's Notes](https://hackmd.io/@ferlinda/r1R0VVsAB) and [Akmal's Notes](https://hackmd.io/@akmalns/BkktSnfkw) as study sources.

#### What is A1 Interfaces?

A1 is the **interface between the non-RT RIC and the near-RT RIC system**. The purpose of the A1 interface is to **enable policy-driven guidance of Near-RT RIC applications/functions and support ML model management and enrichment information to the near-RT RIC funtion so that the RAN can be optimized**.

:::success
**RAN Intent** : High-level operational or business goals to be achieved by RAN, allowing operator to specify desired SLAs that RAN needs to fulfill for all or a class of users in a given area over a period of time.
:::


There are 4 general principles of A1 Interface as below.

- It is an **open logical interface within O-RAN architecture between Non-RT RIC in the SMO and Near-RT RIC in the RAN**.
- It **enables policy-based guidance of RRM internal function or aplication** that are part of near-RT RIC.
- It can **provide basic feedback function from near-RT RIC to non-RT RIC for policy monitoring**.
- A1 policies are created, modified and deleted by the non-RT RIC.

The capabilities of A1 Interface can be seen as below.

- **Transfer of policy management information from non-RT RIC to near-RT RIC**.
- **Policy feedback** from near-RT RIC to non-RT RIC.
- **Transfer of enrichment information** from non-RT RIC to near-RT RIC.

#### How A1 Interface works ?

- **A1 Interfaces in Policy Management** : The A1 interface is used to deliver policies from Non-RT RIC to Near-RT RIC and also could be used to deliver policies feedback from Near-RT RIC to Non-RT RIC.

- **AI Interface in Model Management** : The model is usually trained in the non-RT RIC than used by the near-RT RIC and can be used by non-RT RIC to support ML model inferent in the Near-RT RIC by providing enrichment information.

---

### 3. A1 Interfaces in O- RAN Architectures

> In this note Writer use [Ferlinda's Notes](https://hackmd.io/@ferlinda/r1R0VVsAB) as study sources.

#### Policy Management Function
Policy management function is used by the non-RT RIC to provision and manage A1 policies that are enforced by the near-RT RIC. The non-RT RIC is responsible for definition and administration of A1 policies.

**What is does?**
1. Create, update and delete A1 policies in the near-RT RIC.
2. Query the presence, content and run-time status of an A1 policy in the near-RT RIC.

The RAN operation can be optimized using A1 policies that, compared to the persistent configuration as below.

- Is not critical to traffic
- Have temporary validity
- Handle individual UE or dynamically defined groups of UEs
- Acts within and takes precedence over the configuration
- Is non-persistent (won’t survive near-RT RIC restart)

The **A1 Policies Life Cycle** can be shown as below.

1. Created by the non-RT RIC using the A1 Create policy procedure
2. Accepted by near-RT RIC (it is assumed to be enforced until near-RT RIC notifies that it can’t be enforced)
3. Near-RT RIC can provide basic policy feedback to the non-RT RIC (with side notes above)
4. Near-RT RIC continuously evaluates the policy conditions versus the environment
5. Near-RT RIC may notifies the non-RT RIC in case the policy can’t be enforced or in case the environment changes so that the policy can be enforced
6. Can be updated by the non-RT RIC using the A1 Update policy procedure, then will be evaluated and enforced by the near-RT RIC based on the updated policy statements
7. Exists in the near-RT RIC until it is deleted by the non-RT RIC using the A1 Delete policy procedure.

The A1 policy is identified by a **PolicyID** that is assigned by the non-RT RIC. PolicyID is a locally unique within non-RT RIC and sent in the policy request operations that carry representations of A1 policies. A1 policies consist of a scope identifier and one or more policy statements.


The **scope identifier** represents what the policy statements are to be applied on. The policy statements represent the directives to the near-RT RIC annd covers policy objectives an policy resources.

Scope identifiers can be seen in table below.

| **Identification** | **Descroption** |
| -------- | -------- |
| UE identifier (UEid) | UEId identifies a logical UE entity that is known to the RAN and measurements related to it, is also used for correlating O1-PM data with service targets and enables evaluation of the fulfillment of policies. |
| UE group identifier (SPID) | When the near-RT RIC receives the identifier in an A1 policy, it may resolve it into a set of UEids that are present in the nodes controlled by near-RT RIC and it applies the policy statements to each of UEs. |
| Slice Identifier (S-NSSAI) | When the near-RT RIC receives the identifier in an A1 policy, it may resolve it into a set of UE identifiers and a set of QoS flow identifiers in the nodes controlled by the near-RT RIC and it applies the policy statements to each one of the UEs or the QoS flows. |
| Application Group Identifier (5QI) | When the near-RT RIC receives an application group identifier in an A1 policy, it may resolve it into a set of QoS flow identifiers and the set of UEIds for which the near-RT RIC apply policy statements to each one of the UEs and QoS flows. |
| Cell Identifiers (CellId) | When the scope identifier in an A1 policy is a cell identifier, the policy statement may contain policy resources and the policy implicitly has impact on all UEs handled by the specified cell(s). A policy can be applied to all cells (handled by the near-RT RIC) by setting a special value of the CellId. |

**Policy content** consist of **policy objectives** and **policy resources**
1. **Policy objectives**
- QoS targets using QoS attributes
- QoE targets using MOS-like attributes
- KQI targets using KQI attributes
- KPI targets using KPI attributes

2. **Policy Resources**
- Traffic steering preferences
- System efficiency

**Signalling Procedures of A1 Interface**

Policy-related procedures:

1. Policy create procedure
2. Policy query procedure
3. Policy update procedure
4. Policy delete procedure
5. Policy feedback procedure

The simple A1 interface protocol structure can be seen as below.


---

## Reference
1. https://static1.squarespace.com/static/5ad774cce74940d7115044b0/t/5d56c1f858dd040001fa1b71/1565966861943/ORAN-WG2.UsecaseRequirements.v01.00.pdf
2. https://www.programmersought.com/article/3984216951/