{%hackmd @ninoagus/rkG8Y3Mfp %}

# Master Topics YMA (TIP Lab & OSC Lab)

## 1. Introduction

Here I detailed the research topic I would like to pursue on my Master program at NTUST, that I hope can benefit both TIP Community Lab of Indonesia and OSC Lab of Taiwan.

Term used in Telecom Infra Project and O-RAN Alliance used in this document are as the following :

| Telecom Infra Project | O-RAN Alliance | Context |
| ------------------------------------------------------ | ---------------------------------------------------- | ---------- |
| RIA (RAN Intelligence and Automation) | RIC (RAN Intelligence Controller) (WG2 & WG3) | RAN |
| ROMA (OpenRAN Orchestration and Management Automation) | Service Management and Orchestration Framework (SMO) | Cloud |
| rApps | rApps | Non-RT RIC |
| XApps | xApps | NearRT RIC |

### TIP & O-RAN Alliance Comparison

**O-RAN Alliance's SMO**

- 

**TIP's ROMA**
- 

## 2. Topics

### 2.1 ROMA (Cloudification and Orchestration)

#### 2.1.1 RAN Orchestrator Platform

1. **Goal**

Develop ROMA Rel. 2.0 Compatible Cloud RAN Based on Opensource CNFs (OAI, OSC, etc.) components and Orchestration Platform (Openshift OKD, Rancher, K8s , etc.).

2. **Minimum Requirements**

> 1. Web Interface for Management
> 2. CNFs images management features
> 3. Diagnostic tools
> - CNF logs viewer
> - Traffic Sniffer
> - Orchestrator fault detection on the platform
> 4. CNFs configuration managements
>

2. **Test Cases**

| TIP Case | TIP Use Case ID | O-RAN SMO Use Case (WG6 v08.00) |
|:---------------------------------------------------------------------------------------------------------- |:---------------:|:-------------------------------:|
| Software Image Management | TC1 | UC 3.2.1 |
| VNF Life Cycle Management (LCM) : Instantiate VNF (vCU/vDU) | TC3 | UC 3.2.1 |
| VNF Life Cycle Management (LCM) : Terminate VNF (vCU/vDU) | TC4 | UC 3.2.5 |
| Modify VNF Configuration | TC5 | UC 3.5 |
| Design and Instantiate NS (OpenRAN CNFs - CU, DU) instance with UE attach | TC6 | - |
| Run Data Throughput (DL + UL) | TC7 | - |
| Terminate OpenRAN NS (CNFs)instance | TC8 | - |
| Reinstantiate OpenRAN NS (CNFs) instance , Attach UE (1UE / Cell) and Run TPut(DL + UL) | TC9 | - |
| Delete OpenRAN NS (CNFs) instance | TC10 | - |
| Support of Multiple Version of Helm Chart as CNF packaging/ Manage multiple applications at the same time | TC11 | - |
| CNF config modification (replace old config by new config) | TC12 | - |
| Unified COTS hardware to deploy ROMA Orchestrator and RAN elements | TC13 | UC 3.11 |
| Security communication between ROMA Orchestrator and RAN elements | TC14 | - |
| Configuration Management of day0 | TC15 | - |
| Configuration Management of day1 | TC16 | - |
| Registration and inventory of newly activated NSs | TC17 | - |
| Upgrading CNF software using CNCF compliant Kubernetes API | TC18 | UC 3.2.4 |
| Fault Management data for OpenRAN NFs | TC19 | UC 3.7 |
| Performance Management data for OpenRAN NFs | TC20 | UC 3.8 |
| Alarm Notifications from OpenRAN NFs | TC21 | UC 3.7.1 |
| VNF and CNF Scale In | TC22 | UC 3.2.3 |
| VNF and CNF Scale Out | TC23 | UC 3.2.2 |
| VNF/CNF Auto Healing | TC24 | UC 3.6.2 |

### 2.2 RIA/RIC (rApps)
#### 2.2.1 Power Saving by Load-Adaptive Mode

:::warning
⚠️ **T️o Dos:**
- [x] ️*Contact NTUST Phd. candidate Bimo who already worked on this topic.*
:::

1. **Goal**

To reduce energy consumption of the network using machine learning (ML) and artificial intelligence (AI) learning and optimization techniques.

2. **Description**

A very effective method of reducing energy consumption of mobile networks is by adapting the number of active elements (especially, by switching OFF power hungry ones) according to the load of the network, which is a function of customer QoS demand (e.g., throughput, delay, call drops). During off-peak times, some elements (e.g., transceivers, base-band units etc.), can be switched OFF or put into sleep mode. This so-called load-adaptive operation requires reliable forecasts of user QoS demand and network power consumption.

3. **Data Requirements**

> **Configuration Management (CM)**
> - Cell and site configuration data
> - List of essential radios, base-band units (not to be switched OFF)
> - Cell/Radio to base-band unit association
> - Neighbor lists (cells/sites to which users can be handed over in the event of cell-switch OFF)
> - Available resources (PRBs, base-band units and their capacity, fronthaul capacity)
>

> **Performance Management (CM)**
>
> - Call drop rate
> - PRB utilization in the radio, resource utilization in the base band pool, fronthaul capacity utilization
> - Radio energy consumption, base-band energy consumption, fronthaul energy consumption
> - Cell PDCP throughput (uplink and downlink)
> - Number of active users, active connections
> - Cell/Radio and base-band unit activity status (ON, OFF, Sleep mode)

4. **Impacted Component**

- Resource Control (RC) xApp
- NearRT RIC

#### 2.2.2 Coverage and Capacity Optimization

1. **Goals**

To improve network coverage and capacity in a well-balanced way using Artificial Intelligence (AI) and Machine Learning (ML) algorithms

2. **Description**

Coverage and Capacity Optimization (CCO) automatically identify weak coverage & interference problem and high traffic load cells. After problems are identified, root causes are analyzed, and optimization solutions provided. The coverage optimization can be antenna tilting optimization or coverage related network parameters optimization (e.g. TX power). The capacity optimization will identify high traffic load cells and balance traffic load among their neighbouring cells in the cluster with the final objective of enhanced network performance and users QoE.

3. **Data Requirements**

> **Configuration Management (CM)**
>
> - Cell and site configuration data, including tilt
> - Geo-location data
> - Neighbour lists for each cell segregated by neighbour type (Inter-frequency, Inter-RAT, etc.)
> - Whitelists/Blacklists if any
> - Load balancing feature, feature flags and feature configuration parameters
>

> **Performance Management (PM)**
>
> - Measurement reports at a cell-neighbour pair granularity - DL: RSRP, RSRQ and CQI, UL: SINR
> - UE or UE group measurement reports - DL: RSRP, RSRQ and CQI, UL: SINR
> - Number of active users, active connections
> - Number of scheduled users, PRB utilization
> - QCI (QFI) specific traffic allocations at a PRB and TTI granularity
> - Per UE, cell and sector aggregate PDCP throughput
> - Per UE, PCDP or RLC layer packet/scheduling latency metrics

4. **Related Component**

> - RRC
> - NearRT RIC
> - DU
> - Interface E2

#### 2.2.3 Dis-aggregated RAN Fault Prediction

1. **Goal**

Define a method of predicting faults on OpenRAN equipments – RU/DU/CU/SMO

2. **Description**

By analysing the internal counters of each node component (legacy RAN names: exception logs, UEH, runtime_syslogs), along with temperature, it is possible to predict node failure. For example continual DSP resets on legacy RAN was done by hand after a report was ran each day to check for failing nodes. This can easily be automated, and done across a range of internal counters, with an algorithm finding continual outliers, which can then be analysed, corrective actions taken, and this data fed back in as a training sequence to develop individual failure types/use cases, along with either an automated or alarm response produced by the OSS.

3. **Data Requirements**

> **Performance Management:**
>
> - Exception logs,
> - temperature data (component),
> - temperature data (ambient, inside enclosure),
> - temperature data (locality),
> - @15 Minute aggregation. For 1) Max, Mean and Min values are required
> - Configuration Management data:
> - Geo-location data,
> - Hardware version data
> - Software version data
> - Fault Management Data:
> - Trouble ticketing data relating to component failure
> - Trouble ticketing closure codes (to verify that the component did actually fail)

> **ML Requirements:**
>
> - Training sequence data
> - Historical performance data for model tuning

4.

#### 2.2.4 Traffic Steering and Predictive Load Balancing

1. **Goal**

To use AI and ML algorithms to improve network performance and user experience in a predictive manner instead of reactive

2. **Description**

Mobility load balancing among neighbouring cells in a cluster is triggered using predicted cell traffic load, thus cell congestion is avoided, and user experience is improved. Benefit of this feature is to use AI and appropriate ML algorithms to improve network performance and user experience in a predictive manner instead of a reactive one. Prediction horizon is expected to be 30 minutes to 1 hour (final period will be decided in collaboration with the developing partner).The prediction algorithms have to take into consideration the load balancing and load equalization methods that are required when multiple frequency bands and carriers each with disparate bandwidths are present in a network. As 5G traffic demands grow and systems continue to support multiple technologies (5G, LTE, 3G) with 5G deployments extending from low-band to mid-band (FR1) to high-band (FR2), the need to improve utilization of all deployed spectrum assets becomes a prime requirement for CSPs.

3. **Data Requirements**

> **Configuration Management (CM)**
> - Cell and site configuration data
> - Neighbour lists for each cell segregated by neighbour type (Inter-frequency, Inter-RAT, etc.)
> - Whitelists/Blacklists if any
> - Load balancing feature, feature flags and feature configuration parameters
>

> **Performance Management (PM)**
>
> - Measurement reports at a cell-neighbour pair granularity - DL: RSRP, RSRQ and CQI, UL: SINR
> - UE or UE group measurement reports - DL: RSRP, RSRQ and CQI, UL: SINR
> - Number of active users, active connections
> - Number of scheduled users, PRB utilization
> - QCI (QFI) specific traffic allocations at a PRB and TTI granularity
> - Per UE, cell and sector aggregate PDCP throughput
> - Per UE, PCDP or RLC layer packet/scheduling latency metrics

## References

| Remarks | Title | Type |
| ------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------- |
| O-RAN Load Balancing | [Connection Management xAPP for O-RAN RIC: A Graph Neural Network and Reinforcement Learning Approach](https://arxiv.org/pdf/2110.07525.pdf) | IEEE Papper |
| O-RAN WG6 SMO Technical Specification | [O-RAN Working Group 6 Cloudification and Orchestration Use Cases and Requirements for O-RAN Virtualized RAN](https://orandownloadsweb.azurewebsites.net/specifications) | Technical Specification |