# 8 July 2020 - Daily Report

## Summary
----
### Expected Outcome :
- [x] What is the use case of Non-RT RIC?
- [x] What is A1 interface?
- [x] What is the function of A1 interface in O-RAN?
___
### Outcome :
* Understand the use case of Non-RT RIC
* Understand the A1 interface function

### Further plan:
* Study about A1 interface Application protocol

___
### Timeline
#### 1. Weekly Meeting <mark> 09:00-10:55 </mark>
#### 2. Read O-RAN Working Group2 (Non-RT RIC & A1 interface) <mark> 11:25 </mark>
#### 3. Read O-RAN A1 interface: General Aspects and Principles (A1 interface) <mark> 15:15 </mark>

---
## Study Notes

### Non-RT RIC Use case
:::info
References : [O-RAN Working Group2 (Non-RT RIC & A1 interface)](https://www.o-ran.org/s/ORAN-WG2UsecaseRequirementsv0100.pdf)
:::
#### Traffic Steering use case
The rapid traffic growth and multiple frequency bands utilized in a commercial network make it challenging to steer the traffic in a balanced distribution. Typical 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:
1. It's Hard to adapt the RRM control to diversified scenarios and optimization objectives
2. The traffic steering/management strategy is usually passive, rarely taking advantage of capabilities to predict network and UE performance.
3. 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.

The Goals of this use case:
Drive traffic management in RAN in accordance with defined intents, policies, and configuration while enabling AI/ML-based solution

##### Entities/Resources involved in the use case
1. Non-RT RIC
* **Retreive** 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
* Retreive 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)
* Retreive 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.
2. 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
3. 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

***Required 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

##### Traffic steering process

#### QoE use case
5G networks is bandwidth consuming and latency sensitive. Current semi-static QoS framework can't efficiently satisfy diversified QoE requirements especially there is potentially significant fluctuation of radio transmission capability.

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

##### Entities/Resource involved in the use case
1. Non-RT RIC
* Retreive necessary QoE related measurement metrics from network level measurement report and NMS for constructing/training relevant AI/ML model that will be deployed in near-RT RIC to assist in the 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
2. Near-RT RIC
* Support update of AI/ML models from non-RT RIC
* Support execution of the AI/ML models from non-RT RIC
* 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
3. 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

##### ML model training

##### Policy generation and performance evaluation

#### 3D-MIMO beamforming optimization use case
M-MIMO or massive multiple input multiple output 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 such as:
1. High inter-cell interference
2. Unbalanced traffic between neighboring cells
3. Low performance of cell edge users
4. Poor handover performance
The objective of this use case 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

##### Entities/Resources involved in the use case
1. Non-RT RIC
* 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

##### 3D-MIMO beamforming optimization

### A1 Interface : General Aspects and Principles
#### What is A1 interface?
A1 is the **interface between the non-RT RIC and the near-RT RIC**. The purpose of the A1 interface is to **enable** the non-RT RIC function to provide **policy-based guideline**, **ML model management** and **enrichment information** to the near-RT RIC funtion so that the RAN can be optimized.

#### A1 interface in policy management
>The A1 interface is used to deliver policies from Non-RT RIC to Near-RT RIC
>The A1 interface also could be used to deliver policies feedback from Near-RT RIC to Non-RT RIC

#### A1 interface in model management
>The model is usually trained in the non-RT RIC than used by the near-RT RIC
>The A1 interface can be used by non-RT RIC to support ML model inferent in the Near-RT RIC by providing enrichment information

#### A1 general principles
* 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

#### A1 interface capabilities
>* 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

#### Functions of the A1 interface (**Policy management**)

##### 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 it does:**
>* The funciton is used to create, update and delete A1 policies in the near-RT RIC.
>* The function is used to query the presence, content and run-time status of an A1 policy in the near-RT RIC
>* The function is supported by A1 policy feedback from the near-RT RIC to the non-RT RIC.

##### Life cycle aspects of A1 policies
The RAN operation can be optimized using A1 policies that, compared to the persistent configuration
>* 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

**Where does A1 policies exist?**
> It exists in the near-RT RIC after it has been created by the non-RT RIC
> It exists in the near-RT RIC until it is deleted by the non-RT RIC using A1 delete policy procedure

##### Identification and scope of A1 policies
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.

:::info
Reference : Ferlinda's note about A1 interfaces, can be accessed [here](https://hackmd.io/@ferlinda/SJBJenqA8)
:::

**Scope Identifiers:**

| Identification | Description |
| -------- | -------- |
| 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**
Policy content consist of policy objectives and policy resources

**Policy objectives**:
>* QoS targets expressed using QoS attributes
>* QoE targets expressed using MOS-like attributes
>* KQI targets expressed using KQI attributes
>* KPI targets expressed using KPI attributes

**Policy Resources**:
>* Traffic steering preferences
>* System efficiency

#### Signalling procedures of the A1 interface
Policy related procedures
>* Policy create procedure
>* Policy query procedure
>* Policy update procedure
>* Policy delete procedure
>* Policy feedback procedure

#### A1 interface protocol structure

___

## Conclusion
* There are three use cases where Non-RT RIC is involved
* Non-RT RIC is connected to the Near-RT RIC using A1 interfaces
* A1 interface is mainly used to send policies from non-RT RIC to near-RT RIC
* A1 interface can also be used to send policies feedback

###### tags: `Daily Report`