# <center>O-RAN Use Cases</center>

# Near-RT RIC Use Cases

## 1 - Traffic Steering

**Goal:**

To interpret A1 policies, utilize A1 enrichment information, and trigger E2 procedures and related controls to achieve balanced traffic distribution and network performance amid rapid traffic growth and utilization of multiple frequency bands in a commercial network.

**Target E2 Node functions:**

- E-UTRAN-NR Dual Connectivity

This is a feature in 5G networks that allows a user equipment (UE) to be connected to both 4G and 5G networks simultaneously. It enables seamless handover and load balancing between the two radio access technologies.

- Carrier Aggregation

This is a technique used in LTE-Advanced and 5G networks where multiple frequency bands (carriers) are combined to increase the overall data transmission capacity and improve user data rates.

- Connected mode mobility

This is to the capability of a mobile device to move and maintain an ongoing connection to the network while actively communicating (e.g., making a call or using data services). The network manages handovers between cells to ensure continuity of the connection as the user moves.

- Idle Mode Mobility

This involves the movement of a mobile device when it is not actively communicating or is in a dormant state (e.g., in standby mode). The network performs cell reselection and handover decisions to ensure that the device connects to the most suitable cell when it becomes active again.

**Control over E2:**

- Mobility Control: serving cell can be chosen based on the resource status and QoS of the UE(s) targeted by an A1 Traffic steering policy. Moreover, load balancing can be achieved to improve the overall network performance. The following procedures can be used for Traffic Steering:
- Handover from the source cell to the target cell
- Configuration/reconfiguration of handover restriction list
- Configuration of idle mode mobility parameters
- Enable, disable, or modify CA
- Enable, disable, or modify Dual Connectivity

**Receive:**

- From OAM Functions in SMO domain:
- TS optimization AI/ML models and their configurations.
- From Non-RT RIC in SMO domain:
- A1 policies.

Near-RT RIC can be flexibly configured to operate in different modes for distinct sets of UEs, allowing it to assume various roles such as non-involvement, exclusive utilization of E2 mechanisms, or adherence to A1-guided behavior specified by Non-RT RIC.

- From E2 Nodes:
- UE (user equipment) context, network measurements, UE measurements, and E2 node Configuration.

**Support:**

- Update of AI/ML models from SMO.
- Inference, such as traffic prediction, using AI/ML models from Non-RT RIC based on network data, e.g. measurement reports from E2 Node.
- Interpretation and execution of A1 policies from Non-RT RIC.

**Send:**

- To E2 Nodes:
- TS resource optimization related policies and commands to influence RRM behavior.
- To Non-RT RIC:
- Relevant A1 policy feedback.

The Non-RT RIC may use this information and information collected from E2 Nodes as policy feedback to assess the performance of TS optimization function in Near-RT RIC, or to assess the outcome of the applied A1 policies. Subsequently, an A1 policy can be updated.

- To OAM Functions in SMO domain:
- Relevant O1 performance data for potential policy updates by Non-RT RIC.

**Key Actions:**

- Near-RT RIC evaluates the performance data from E2 Nodes (including performance data from different E2 Nodes for the same UE) and finds the performance is out of TS targets which are indicated in the A1 policy and/or internal near-RT RIC TS targets.
- Based on the UE context information, E2 measurement metrics (RIC REPORT), and A1 policy, Near-RT RIC may generate new or modify the existing E2 policies and sends them to E2 Nodes. Near-RT RIC may also generate control command(s) and send them to E2 Node(s) to trigger re-allocation of radio resources so that TS indicators can move back to the limits outlined in the A1 policies.
- Near-RT RIC may use available information to assess the performance of TS optimization function in Near-RT RIC, and/or to assess the outcome of the applied A1 policies. Subsequently, Near-RT RIC TS optimization targets can be updated.

### Traffic Steering processing modes

These modes represent the way the Near-RT RIC (or RAN) operates on a given group of UEs, and not the operation of any component as a whole. As such, the Near-RT RIC, could be operating in both modes 1 and 2 concurrently for different sets of UEs. For example, the transition from Mode 0 or 1 to 2 occurs only for a group of UE defined by the A1 policy Scope. At the same time, other UE groups may still be handled in Mode 0 and/or 1.


1. “Baseline” Traffic Steering Behavior: OAM Functions in SMO domain uses O1 configuration on one or more E2 node to set up a desired baseline behavior. This also sets up baseline Performance Monitoring of E2 Node by the SMO. In this mode, Near-RT RIC is not involved.
2. “Background” Near-RT RIC Processing: OAM Functions in SMO domain uses O1 configuration of near-RT RIC to set up a desired “background near-RT RIC behavior”. In this mode the near-RT RIC sets up E2 mechanisms to monitor E2 Node and uses Traffic Steering related E2 mechanisms to achieve the desired background behavior of the set of E2 Nodes connected to the near-RT RIC.
3. “A1-Policy based” Near-RT RIC Processing: This mode may be entered from either Mode 0 or Mode 1.  Non-RT RIC in SMO domain uses A1-P to specify an A1 guided behavior for a targeted subset of E2 Nodes or UEs. If entering this from Mode 1, this will have the effect of modifying the existing near-RT RIC “background” behavior to include a more specific A1 guided behavior. In this mode, the near-RT RIC may either set up or modify E2 mechanisms used to monitor E2 Nodes and will use Traffic Steering related E2 mechanisms to obtain the desired behavior of some targeted sub-set of E2 Nodes or UEs. This mode terminates when the corresponding A1-P Policy Delete message is received from Non-RT RIC in SMO domain and the system returns to either Mode 0 or Mode 1, depending on whether or not OAM Functions in SMO domain had previously configured the optional Near-RT RIC “background” role (Mode 1).

Processing Mode 2 contain an ‘outer loop’ and an ‘inner loop’. In the inner loop, a number of different “E2 mechanism” may be used (Policy, Report/Control or Insert/Control) towards a number of different target RAN functions in order to either exercise existing RAN mechanisms or modifying their ongoing behavior. The appropriate mechanism and target RAN Function would depend upon the RAN Function capabilities to support a given E2 mechanism, the A1-P scope and policy, the O1 configuration of the RIC and the performance observed through E2 monitoring.

## 2 - QoS Based Resource Optimization

**Goal:**

To enable QoS aware resource optimization in E2 Nodes, ensuring smooth achievement of QoS targets by refining radio resource allocation based on varying conditions and traffic demands to meet reliability, latency, and bandwidth requirements simultaneously, while coordinating resource allocation for co-existing multiple services with different priorities to optimize radio resource utilization, and triggering re-allocation when QoS indicators deviate from defined limits.

**Control over E2:**

- DRB (Data Radio Bearer) Control
- Radio Resource Allocation
- Radio Access Control
- Connection Mobility Control

**Receive:**

- From OAM Functions in SMO domain:
- QoS optimization AI/ML models and their configurations.
- From Non-RT RIC in SMO domain:
- A1 policies.
- From E2 Nodes:
- UE context, network measurements, and UE measurements.

**Support:**

- Update of AI/ML models from SMO.
- Inference, such as QoS prediction, using AI/ML models from Non-RT RIC based on network data, e.g. measurement reports from E2 Node.
- Interpretation and execution of A1 policies from Non-RT RIC.

**Send:**

- To E2 Nodes:
- QoS resource optimization related policies and commands to influence RRM behavior.
- To Non-RT RIC:
- Relevant A1 policy feedback for potential policy updates.
- To OAM Functions in SMO domain:
- Relevant O1 performance data for potential policy updates by Non-RT RIC.

**Key Actions:**

- Near-RT RIC evaluates the performance data from E2 Nodes (including performance data from different E2 Nodes for the same UE) and finds the performance is out of QoS targets which are indicated in the A1 policy. If performance is within the targets, Near-RT RIC keeps monitoring.
- Near-RT RIC may generate new or modify the existing E2 policies and sends them to E2 Nodes. Near-RT RIC may also generate control command(s) and send them to E2 Node(s) to trigger re-allocation of radio resources so that QoS indicators can move back to the limits outlined in the A1 policies.

## 3 - RAN Slice SLA Assurance

**Goal:**

To assure RAN Slice SLAs (Service-Level Agreement) and prevent its possible violations.

**Control over E2:**

- Radio Resource Allocation

such as configuration of slice level PRB quota

- Radio Access Control

**Receive:**

- From Non-RT RIC:
- Trained AI/ML models for fast loop optimization.
- A1 policies based on RAN intent and A1 feedback.
- Enrichment information.
- From E2 nodes:
- UE context information and E2 measurements.
- From SMO:
- Slice SLA assurance xApps.

**Support:**

- Near real-time monitoring of slice specific RAN performance measurements.
- Deployment and execution of the AI/ML models from Non-RT RIC.
- Interpretation and execution of policies from Non-RT RIC.
- Performing optimized RAN (E2) actions to achieve RAN slice requirements based on O1 configuration, A1 policy, and E2 reports.

**Send:**

- To E2 Nodes:
- Slice assurance actions such as slice-aware resource allocation, prioritization, etc.
- To Non-RT RIC:
- A1 policy feedback.

**Key Actions:**

- Near-RT RIC evaluates the performance data from E2 Nodes (including performance data from different E2 Nodes for the same UE) and finds the performance is out of Slice SLA targets which are indicated in the A1 policy and/or internal near-RT RIC Slice SLA targets.
- Based on the UE context information, E2 measurement metrics (RIC REPORT), and A1 policy, Near-RT RIC may generate new or modify the existing E2 policies and sends them to E2 Nodes.
- Near-RT RIC may also generate control command(s) and send them to E2 Node(s) to trigger re-allocation of radio resources so that Slice SLA indicators can move back to the limits outlined in the A1 policies.

## 4 - Massive MIMO Optimization

**Goal:**

- **AI/ML-assisted Non-GoB BF mode selection**: To train an AI/ML model to select the best Non-GoB BF modes given wireless conditions and RAN configuration, and to generate Non-GoB control/policy message.
- **Beam-based Mobility Robustness Optimization (bMRO)**: **Goal:** To optimize beam pattern and grouping through ML model training in the context of Grid-of-Beam optimization, and to enhance beam-based mobility performance between neighboring cells by evaluating mobility characteristics, failure reporting, and optimizing mobility settings (e.g., CIO, TTT, T310).

**Receive:**

- From SMO/Non-RT RIC:
- Enrichment information for inference, and associate enrichment information with collected measurements and configurations.
- From E2 Nodes (O-DU and O-CU):
- Necessary performance and failure indicators, UE measurement reports, UE context information, and E2 node Configuration (including RAN configurations).

**Support:**

- AI/ML model deployment from the Non-RT RIC.
- AI/ML model training and inference.
- AI/ML model performance monitoring and re-training.

**Send:**

- To E2 Nodes:
- Control or policy message for massive MIMO optimization.

## 5 - QoE Optimization

**Goal:** To utilize ML algorithms to acquire and process measurement data, including cell level and UE level data, enabling traffic recognition, QoE prediction, and QoS enforcement decisions, while providing RAI service consumers with analytics information such as traffic rate, latency, and packet loss rate to execute logical control.

**Receive:**

- From RAN:
- Network state and UE performance report with required granularity.
- From RAI service consumer:
- Request or subscription messages.
- From E2 Nodes:
- UE context information, measurements.

**Support:**

- Data analysis and executing the AI/ML models to infer RAN analytics information, e.g., QoE prediction, and available bandwidth prediction.

**Send:**

- To RAI service consumer:
- RAN analytics information.

# Non-RT RIC Use Cases

## 1 - Traffic Steering

**Goal:**

To allow operators to flexibly configure the desired optimization policies, utilize the right performance criteria, and leverage machine learning to enable intelligent and proactive traffic management.

**Receive (SMO, including Non-RT RIC):**

- From E2 Nodes:
- Measurement reports with RSRP/RSRQ/CQI information for serving and neighboring cells.
- UE connection and mobility/handover statistics with indication of successful and failed handovers, other metrics including threshold of number of UEs to trigger traffic management at O-DU, O-CU-CP, etc.
- Cell load statistics such as information in the form of number of active users or connections, number of scheduled active users per TTI, PRB utilization, and CCE utilization, bearer metrics such as number of bearers to trigger traffic management at O-DU, O-CU-CP, etc.
- Per user performance statistics such as PDCP throughput, RLC or MAC layer latency, DL throughput thresholds to trigger traffic management at O-DU, O-CU-CP, etc.

**Support:**

- Update of AI/ML models from SMO.
- Inference, such as traffic prediction, using AI/ML models from Non-RT RIC based on network data, e.g. measurement reports from E2 Node.
- Interpretation and execution of A1 policies from Non-RT RIC.

**Send:**

- To RAN nodes (E2 Nodes):
- Measurement configuration parameters.
- To Near-RT RIC:
- Policies.
- Enrichment information to Near-RT RIC, e.g., radio fingerprint information, etc.

## 2 - QoE optimization

**Goal:**

To support QoE optimization within the O-RAN architecture and its open interfaces by acquiring and processing multi-dimensional data through ML algorithms to enable traffic recognition, QoE prediction, and QoS enforcement decisions.

**Receive:**

- From E2 Nodes:
- Network level measurement report.
- From SMO:
- QoE related measurement metrics.
- From existing data collection equipment (currently out of the scope of A1 or E2):
- User traffic data.
- (SMO receive) From RAN:
- Network state and UE performance report with required granularity.

**Support:**

- Training of potential ML models for predictive QoE optimization, which may respectively autonomously recognize traffic types, predict quality of experience, or predict available radio bandwidth.

**Send:**

- To Near-RT RIC:
- AI/ML model to assist in the QoE Optimization function.
- Policies/intents to drive the QoE optimization at RAN level in terms of expected behavior.

## 3 - QoS based resource optimization

**Goal:**

To drive QoS based resource optimization in RAN in accordance with defined policies and configuration.

**Receive:**

- From SMO:
- Necessary QoS related metrics from network function and other SMO functions.
- Resource consumption.
- Detailed reports for individual UEs that the Non-RT RIC is interested in.
- (SMO receive) From RAN:
- Network state and UE performance report with required granularity

**Support:**

- Evaluation of RAN resource utilization for all users in a slice in specific area.
- determination of a dynamic group of users for which QoS target should be changed.

**Send:**

- To Near-RT RIC:
- Policies to drive QoS based resource optimization at RAN level in terms of expected behavior.

## 4 - Context-based dynamic handover management for V2X

**Goal:**

To use AI/ML functionality enabled by Near-RT RIC to customize HO (handover) sequences at the UE level in V2X communication. This aims to avoid and resolve suboptimal handover scenarios that impair V2X application functionality, leading to improved road safety, reduced emissions, and time savings.

**Entities/resources involved in the use case**

1. Non-RT RIC:

a) 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 V2X HO management function. For example, this could be a clustering algorithm that classifies traffic situations and radio conditions that (probably) do or do not lead to HO anomalies.

b) Support deployment and update of AI/ML models into Near-RT RIC xApp.

c) Support communication of intents and policies (system-level and UE-level) from Non-RT RIC to Near-RT RIC.

d) Support communication of Non-RAN data to enrich control functions in Near-RT RIC (enrichment data).

2. Near-RT RIC:

a) Support update of AI/ML models retrieved from Non-RT RIC.

b) Support interpretation and execution of intents and policies from Non-RT RIC.

c) Support necessary performance, configuration, and other data for defining and updating intents and policies for tuning relevant AI/ML models.

d) Support communication of configuration parameters to RAN.

3. RAN:

a) Support data collection with required granularity to SMO over O1 interface.

b) Support Near-real-time configuration-based optimization of HO parameters over E2 interface.

c) Report necessary performance, configuration, and other data for performing real-time V2X HO optimization in the near-RT RIC over E2 interface.

4. V2X Application Server:

a) Support data collection with required granularity from V2X UE over V1 interface.

b) Support communication of real-time traffic related data about V2X UE to Non-RT RIC as enrichment data.

**Proposed solution(s)**

- **Workflow overview**

The use case workflow consists of these main components:

1. Data collection & maintenance: This is required at Non-RT RIC (over O1 and Enrichment Interface (EI)). Required radio measurements and V2X related metrics are collected over a longer period of time (sufficient to facilitate model training). The O1/EI data collection is used for offline training of models, as well as for generating A1 policies for V2X HO optimization. The E2 (and EI) data collection is used for model execution in the Near-RT RIC. Details of the models are described below.
2. Long-term HO analytics & model maintenance: The Non-RT RIC long-term analytics is responsible for providing the relevant models for V2X HO optimization over A1 interface. Based on O-RAN A1 interface specs v1, these policies can be defined at per-UE level, UE group level, cell or xNB level etc. This will provide the optimization scope/objective for the near-RT RIC V2X HO xApp. The xApp hosts two AI/ML-assisted functions: 1. HO anomaly detection & prediction, 2. HO anomaly avoidance. The 1. trained model's input is [E2: HO sequences, UE radio measurements; EI: position, velocity, direction, (O) navigation data, (O) cell load data of cells in the area] of a given time window, while the output is [anomaly likelihoods for possible future HO sequences]. The 2. trained model's input is [E2 report, EI report, output of 1. model, (O) navigation data, (O) cell load data of cells in the area] and its output is [UE-customized NRT sequence for cells that the UE is about to touch, with lower anomaly likelihood, (O) with validity time]. The two models are regularly retrained/updated based on new radio/V2X data.
3. HO anomaly prediction & detection: The navigation information and HO sequence and predicted HO sequence of V2X UE-s in scope are evaluated and HO anomalies are detected or predicted. If any, it is delegated for further consideration for HO sequence optimization.
4. HO sequence optimization: Based on the E2 and enrichment reports and the prediction/detection output, the trained AI/ML model outputs UE-customized NRT-s for the cells that I. are in scope, II. the UE is about to come in touch with.
5. V2X HO optimization execution: The new NRT-s are deployed at xNB-s through E2 policies.
- Overview of ML models

While many combinations and deployments are possible, this proposal outlines one specific set of models and analytics that can be useful to drive such a use case.

1. NonRT_Model1: The Non-RT RIC ML-assisted solution uses the O1-based and EI-based data collection to monitor the V2X UE HO performance metrics and the navigation indicators (position, direction, speed, (O) traffic indicators). Based on the performance monitoring, the model aims to represent navigation and radio environments/conditions and maintain a data base in order to classify HO situations. Input: historical radio, HO, and location, direction, velocity data. Output: Maintained database with locations, directions, velocities and cells, HO situations, HO anomalies, and/or sequences of all these, together with prevalence rates (=estimated probabilities).
2. NearRT_Model1: The first ML-assisted near-RT xApp model in the Near-RT RIC aims to rate/score future/current HO situations (on a UE level) based on real-time radio (E2) and navigation conditions (EI), i.e., predict/detect anomalous HO situations. Input: per-UE current radio parameters, HO history, location, direction, velocity. Output: Predicted HO sequence(s) with probabilities for anomalies at specific cell pairs.
3. NearRT_Model2: The second ML-assisted near-RT xApp model in the Near-RT RIC aims to choose alternative, UE specific NRTs for a set of cells and UEs so as to resolve or avoid anomalous HO situations. Input: input and output of the NearRT_Model1. Output: Alternative, UE specific NRT-s for some cells (e.g., with temporal validity/expiration time).

## 5 - RAN Slice SLA Assurance

**Goal:**

To leverage O-RAN's open interfaces and AI/ML-based architecture to implement mechanisms that ensure SLA adherence and prevent violations, thereby enabling efficient utilization of network slicing capabilities in the 5G era to meet specific business requirements.

**Entities/resources involved in the use case**

1. Non-RT RIC:

a) Retrieve RAN slice SLA target from respective entities such as SMO, NSSMF

b) Long term monitoring of RAN slice performance measurements

c) Training of potential ML models that will be deployed in Non-RT RIC for slow loop optimization and/or Near-RT RIC for fast loop optimization.

d) Support deployment and update of AI/ML models into Near-RT RIC

e) Receive slice control/slice SLA assurance rApps from SMO

f) Create and update A1 policies based on RAN intent and A1 feedback.

g) Send A1 policies and enrichment information to Near-RT RIC to drive slice assurance

h) Send O1 reconfiguration requests to SMO for slow-loop slice assurance

2. Near-RT RIC:

a) Near real-time monitoring of slice specific RAN performance measurements

b) Support deployment and execution of the AI/ML models from Non-RT RIC

c) Receive slice SLA assurance xApps from SMO

d) Support interpretation and execution of policies from Non-RT RIC

e) Perform optimized RAN (E2) actions to achieve RAN slice requirements based on O1 configuration, A1 policy, and E2 reports

3. RAN:

a) Support slice assurance actions such as slice-aware resource allocation, prioritization, etc.

b) Support slice specific performance measurements through O1

c) Support slice specific performance reports through E2

## 6 - NSSI Resource Optimization

**Goal:**

The goal is to utilize network slicing and an AI/ML model to dynamically and efficiently allocate resources among multiple 5G network slices, catering to different service requirements and traffic demand patterns in various times and locations.

**Entities/resources involved in the use case**

1. Non-RT RIC:

a) Receive measurements to monitor the usage of RRM resources (e.g., PRB, RRC, DRB) identified by S-NSSAI from E2 nodes via the O1 interface

b) Perform the model training with input measurements data received from E2 nodes to create the model.

c) Perform the inference function on the model with the input measurements data to determine if any actions should be executed to update the resources on the E2 nodes.

d) Configure the resources at the E2 nodes via O1 interface.

e) Receive notifications from E2 nodes indicating the resource re-configuration was done.

f) Update the O-cloud resources via the O2 interface.

g) Receive notifications from O-Cloud indicating the resource was updated

2. E2 nodes (O-CU-CP, O-CU-UP, D-DU):

a) Support the collections and reporting of measurements that are used to monitor the resource usage on per network slice basis via the O1 interface.

b) Support the re-configuration of attributes to update the resources allocated to each network slice via the O1 interface.

**O-CU-CP:** RRC connected user

**O-CU-UP:** the number of DRB allocated, the number of PDU sessions, the number of PRBs used in the downlink and uplink data traffic, DRB

**D-DU:** PRB

## 7 - Massive MIMO Optimization Use Cases

see Near-RT RIC and the specific file for massive MIMO use case

## 8 - Network Energy Saving Use Cases

### Carrier and Cell Switch Off/On

**Goal:**

To develop a framework that utilizes machine learning techniques to optimize energy efficiency in mobile networks by intelligently switching off/on carriers or cells based on overall network performance, traffic patterns, and resource usage while ensuring minimal impact on user experience.

**Entities/resources involved in the use case**

1. SMO/Non-RT RIC Framework Function

a) Collect the configurations, performance indicators and measurement reports (e.g., cell load related information and traffic information, EE/EC measurement reports) from E2 Node(s), for the purpose of decision making, optionally using training and inference of AI/ML models that assist such EE/ES functions. It is assumed that configurations, performance indicators and measurement reports collected from the O-DU contain the related information for the corresponding O-RU(s).

b) Transfer collected data towards rApp.

c) Signal updated configurations for EE/ES optimization towards E2 Node(s) (O-CU) through O1 Interface

d) (Optionally) Retrain , update, configure EE/ES AI/ML models in Non-RT RIC.

2. rApps
a) Collect the necessary configurations, performance indicators, and measurement reports from SMO/Non-RT RIC framework, for the purpose of training and execution of relevant AI/ML models.

b) (Optionally) ) Retrain , update, configure EE/ES AI/ML model.

c) Infer an optimized O1 configuration for EE/ES based on the data collected using R1 interface .

3. E2 Node

a) Report cell configuration, performance indicators and measurement reports (e.g., cell load related information and traffic information, EE/EC measurement reports) to SMO via O1 interface.

b) Perform actions required for EE/ES optimization

e.g. check ongoing emergency calls and warning messages, perform some preparation actions for Off Switching (e.g., to enable, disable, modify Carrier Aggregation and/or Dual Connectivity, to trigger HO traffic and UEs from cells/carriers to other cells or carriers, informing neighbour nodes via X2/Xn interface etc.) as well as for On Switching (e.g., cell probing, informing neighbour nodes via X2/Xn interface etc.) and make final decision on switch off/on and notify SMO via O1 about performed actions

4. O-RU

a) Report EC and EE related information via Open FH M-Plane interface to O-DU .

b) Support actions required to perform EE/ES optimization. o updated carrier configuration (i.e., activation, deactivation or sleep)

### RF Channel Reconfiguraiton

**Goal:**

To propose a framework that utilizes machine learning techniques to enable flexible RF Channel reconfiguration in mobile networks, allowing operators to enhance energy efficiency and network performance by dynamically adjusting the number of active antennas based on predicted future traffic, user mobility, and resource usage.

**Entities/resources involved in the use case**

1. SMO / Non-RT RIC Framework Function

a) Collect the configurations, performance indicators and measurement reports (e.g., cell load related information and traffic information, EE/EC measurement reports) from E2 Node(s), for the purpose of decision making, optionally using training and inference of AI/ML models that assist such EE/ES functions.

b) Transfer collected data towards rApp. It is assumed that configurations, performance indicators and measurement reports collected from the O-DU contain the related information for the corresponding O-RU(s).

c) Signal updated configurations for EE/ES optimization towards E2 Node(s) (O-CU) through O1 Interface.

d) (Optionally) Retrain , update, configure EE/ES AI/ML models in Non-RT RIC.

2. rApps

a) Collect the necessary configurations, performance indicators, and measurement reports from SMO/Non-RT RIC Framework function, for the purpose of training and execution of relevant AI/ML models.

b) (Optionally) ) Retrain , update, configure EE/ES AI/ML model.

c) Infer an optimized RF Channel configuration for EE/ES based on the data collected using R1 interface .

3. E2 Node

a) Report cell configuration, performance indicators and measurement reports (e.g., cell load related information and traffic information, EE/EC measurement reports) to SMO via O1 interface.

b) Perform actions required to perform RF Channel Reconfiguration (i.e., O-RU Tx/Rx Array selection , modification of the number of SSB beams, modification of the O-RU Antenna Transmit power, modification of the number of SU/MU MIMO data layers or spatial streams) as part of EE/ES optimization.

4. O-RU

a) Report EC and EE related information via Open FH M-Plane interface to O-DU .

b) Perform actions required to be performed due to RF Channel Reconfiguration (i.e., O-RU Tx/Rx Array selection , modification of the number of SSB beams, modification of the O-RU Antenna Transmit power, modification of the number of SU/MU MIMO spatial streams or data layers ) as part of EE/ES optimization.

# General Use Cases

## 1 - Context-Based Dynamic HO Management for V2X

- **Objective:** Prevent anomalous HO and performance degradation for V2Xs, customize HO sequences on a UE level using past navigation and radio statistics.
- **Solution: xApp with two main functionalities**
1. **Non-RT RIC Long-term Analytics**
- **Role:** Identify causes of HO anomalies and discover optimal HO sequences
- **Data Received:**
- UE-based HO events and mobility data from V2X AS
- **Result Sent to:**
- Maintain a database to keep track of resolutions to anomalies based on these feedbacks
- Share Policy + trained model training info with Near-RT RIC
2. **Near-RT RIC Real-time Optimization**
- **Role:** Detect/predict unexpected HO events and generate desired HO sequence to eliminate/avoid HO anomalies
- **Data Received:**
- Enrichment data from V2X AS
- UE-specific real-time mobility context from gNB
- E2 Report: HO source + target cell, HO complete/failure, failure cause, radio cell ID, connection ID, RSRP/RSRQ measurements
- **Result Sent to:**
- Create and update UE-specific NRTs to improve performance of V2X users
- Send E2 Policy: set UE-NRT to gNB

## 2 - Flight Path Based Dynamic UAV Radio Resource Allocation

- **Objective:** Manage resource allocation of UAVs based on Flight Path and reduce unnecessary handover while improving radio resource utilization.
- **Solution:**
1. **Non-RT RIC Retrieval and Training**
- **Data Received:**
- Aerial Vehicles related metrics from network level measurement reports
- Flight path information of Aerial Vehicles, climate information, flight forbidden/limitation area information, and Space Load information from an application (e.g., UTM)
- Aerial Vehicles performance reports from Near-RT RIC for evaluation and optimization of the ML model
- **Result Sent to:**
- AI/ML model for training and construction
2. **Near-RT RIC Resource Allocation**
- **Role:** Perform radio resource allocation for UAVs considering radio channel conditions, flight path information, and other application information with on-demand coverage
- **Data Received:**
- Constructed/trained AI/ML model from Non-RT RIC
- **Result Sent to:**
- Resource allocation decisions for UAVs to CU-CP and CU-UP
- Aerial Vehicles performance reports to Non-RT RIC for evaluation and optimization of the ML model

## 3 - Radio Resource Allocation for UAV Application Scenario

- **Objective:** Enable efficient uplink high-rate data transmission in existing radio resource allocation strategies.
- **Solution:**
1. **Non-RT RIC Retrieval and Generation**
- **Deployed on:** Non-RT RIC (on the cloud or in the control vehicle)
- **Data Received:**
- UE-level radio resource requirements from Application Server
- **Result Sent to:**
- UE based radio resource allocation policies to Near-RT RIC
2. **Near-RT RIC Resource Allocation**
- **Role:** Support execution and interpretation of retrieved policies to create configuration parameters for E2 nodes
- **Deployed on:** Near-RT RIC
- **Data Received:** Retrieved policies from Non-RT RIC
- **Result Sent to:** Configuration parameter to E2 nodes (5G gNB)

## To be supplemented

## 4 - QoE Optimization

## 5 - Traffic Steering

## 6 - Massive MIMO Beamforming Optimization

## 7 - RAN Sharing

## 8 - QoS Based Resource Optimization

## 9 - RAN Slice SLA Assurance

## 10 - Multi-vendor Slices

## 11 - Dynamic Spectrum Sharing (DSS)

## 12 - NSSI Resource Allocation Optimization

## 13 - Local Indoor Positioning in RAN

## 14 - Massive MIMO SU/MU-MIMO Grouping Optimization

## 15 - O-RAN Signalling Storm Protection

## 16 - Congestion Prediction & Management

## 17 - Industrial IoT Optimization

## 18 - BBU Pooling to achieve RAN Elasticity

## 19 - Integrated SON Function

## 20 - Shared O-RU

## 21 - Energy Saving

## 22 - MU-MIMO Optimization

## 23 - Sharing Non-RT RIC Data with the Core

## 24 - Industrial vision SLA Assurance