# <center>Near-RT RIC</center>

# Near-RT RIC Architecture

The Near-RT RIC architecture and internal interfaces should 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.

## Near-RT RIC Internal Architecture

From OAIC:

### 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.

## Near-RT RIC Requirements

- Near-RT RIC shall provide a database that stores an up-to-date RAN information, history of time-varying network state, as well as configurations related to E2 Nodes, Cells, Bearers, Flows, UEs, etc., and the mapping between them. This information shall be provided as a service to any xApp that requests it;
- Near-RT RIC shall provide AI/ML tools that support for data pipelining, training, and performance monitoring;
- Near-RT RIC shall provide a messaging infrastructure;
- Near-RT RIC shall provide logging, tracing and metrics collected from Near-RT RIC platform and xApps toward SMO;
- Near-RT RIC shall provide security functions;
- Near-RT RIC shall support ==resolution of potential conflicts or overlaps of controls from xApps== toward an E2 node;
- Near-RT RIC shall ==communicate with xApp(s) via Near-RT RIC APIs==;
- Near-RT RIC shall register the Near-RT RIC APIs it produces;
- Near-RT RIC shall be capable of discovering the Near-RT RIC APIs it consumes;
- Near-RT RIC shall provide means to resolve compatibility clashes between xApps and the Near-RT RIC services they access;
- Near-RT RIC shall support subscription merging from multiple xApps to avoid unnecessary network load;
- Near-RT RIC shall provide an O1 interface;
- Near-RT RIC shall be able to route A1 policy management messages to the registered xApps based on A1 policy type and operator policies;
- Near-RT RIC shall control access of A1-EI types for xApps based on operator policies.

## Implementation Options

Centralized Near-RT RIC Serving 4G and 5G Simultaneously:

Distributed Near-RT RIC:

# Near-RT RIC Functions Description (partial)

## xApp Subscription Management

- xApp subscription management manages subscriptions from xApps to E2 Nodes;
- xApp subscription management enforces authorization of policies controlling xApp access to messages;
- xApp subscription management enables merging of identical subscriptions from different xApps into a single subscription toward an E2 Node.

### In O-RAN SC

Refer to: https://docs.o-ran-sc.org/projects/o-ran-sc-ric-plt-submgr/en/latest/user-guide.html

==Subscription Manager== is a basic platform service in RIC. It is responsible for managing E2 subscriptions from xApps to the E2 Node (eNodeB or gNodeB).

xApp can make subscriptions to E2 Node through Subscription Manager. xApp can subscribe REPORT, INSERT, CONTROL and POLICY type services from E2 Node. For some of those subscription types E2 Node sends E2 Indication messages back to xApp. For those messages there need to be created route between E2 Termination and xApp. Subscription Manager manages E2 subscriptions and message request routing of the subscribed messages from Routing Manager. If one xApp has already made a subscription and then another xApp initiates identical subscription, Subscription Manager does not forward the subscription to E2 Node but merges the subscriptions internally and request Routing Manager to create route also for the second xApp and sends response to xApp. xApp can indicate in the request should Subscription Manager send request for Routing Manager to create route for the E2 subscription in the request.

Interface between xApp and Subscription Manager is HTTP based REST interface. Interface codes are generated with help of Swagger from a yaml definition file. REST interface is used also between Subscription Manager and Routing Manager. Subscription Manager and E2 Termination interface is based on RMR messages. xApp should use also Swagger generated code when it implements subscription REST interface towards Subscription Manager.


One xApp generated REST subscription request message can contain multiple E2 subscriptions. For every E2 subscription in the message there must be also xApp generated xApp instance id. In E2 interface there can be only one ongoing E2 subscription or subscription delete procedure towards E2 Node at any time. That is because Subscription Manager is able to merge new E2 subscriptions only which those it has already received successful response from E2 Node. E2 subscriptions and delete subscriptions may be therefore queued for a moment in Subscription Manager.

Subscription Manager may need to do reties towards E2 Node during subscribe or subscription delete procedure. Retries will increase completion time of the procedure. This needs to be considered in xApp’s implementation. Subscription Manager sends REST notification to xApp for every completed E2 subscription procedure. That is regardless was the E2 subscription successful or not. Notification is not sent for E2 subscription delete procedures. Subscription Manager allocates globally unique REST request id for each new REST subscription request. That is returned to xApp in response. When xApp wants to delete REST subscription, xApp need to use the same id in deletion request.

Subscription Manager allocates also unique id for every E2 subscriptions (E2 instance id). The id called ‘InstanceId’ in E2 specification. In successful case the REST notification contains the id generated for the REST request, xApp instance id and E2 instance id. From xApp point of view xApp instance id identifies response REST notification for the E2 subscription in the REST request. REST notification contains also Subscription Manager generated E2 instance id. xApp can use that to map received E2 Indication message to E2 subscription. If E2 subscription procedure is unsuccessful then E2 instance id is 0 and the notification contains non-zero error cause string and source of that error information.

xApp need to be able preserve Subscription Manager allocated REST request id over xApp restart. The id is needed for deletion of the REST subscription and if there is need to resend the same REST request.

Three different type subscriptions are supported. REPORT, POLICY and INSERT. REPORT and INSERT works the same way from subscription point of view. REPORT and INSERT type REST subscription request can contain multiple E2 subscriptions. POLICY subscription can also contain multiple E2 subscriptions but using it in that way may not be feasible. REPORT, POLICY and INSERT type subscriptions in the same REST request are not supported supported in Subscription Manager.

REPORT and INSERT type subscription can contain multiple E2 subscriptions. If xApp needs to resend the same REST request, the request must contain Subscription Manager allocated id for the REST request, which was returned to xApp when the request was sent first time. The request must also contain the same content as first time. Reason for xApp to resend the same request could be timeout or some failure which is not permanent like E2 interface connection break or xApp restart. In retry case Subscription Manager retries the E2 subscriptions towards to E2 Node in the request message which it does not have record. For subscriptions which record is found Subscription Manager returns successful REST notification to xApp without forwarding request to E2 Node. One REST Subscription request can contain E2 subscriptions only for one E2 Node.

Subscription Manager indicates to xApp in response notification if there has happened any error or timeout. xApp can send retry based on that information but resending should happen after Subscription Manager has processed the previous request completely, otherwise xApp will get successful response for the new request without that the request is actually retried. If timeout happens, response notification contains information where it happened. Timeout can happen in E2, Routing Manager and SDL interface.

If there is need to change REPORT or INSERT type subscription then previously made subscription need to be deleted first. If there are any REPORT or INSERT type E2 subscription which need to change frequently, it is not good idea to bundle them with other REPORT or INSERT type E2 subscriptions in the same REST subscription request.

POLICY type subscription can contain multiple E2 subscriptions but it may not be feasible as POLICY subscription may change. Idea in POLICY subscription is that xApp can send changed contend to E2 Node without making new subscription but just send update. Message contend can be changed frequently. In such case it may not be good idea to bundle the POLICY type E2 subscription with any other POLICY type E2 subscriptions in the same REST subscription request.

xApp must be able to preserve is the Subscription Manager allocated REST requests ids over restart or send the same request as was sent restart. If xApp is able to send exactly the same requests then Subscription manager can identify the request and send same responses back to xApp. This way xApp can restore the identifies related to existing subscriptions. Another alternative is store needed information in database. Subscription manager calculates md5 sum over the REST Subscription request message. That is how it can detect identical request coming from a specific xApp.

xApp can set in the request how many times Subscription Manager will retry subscription in E2 interface if there is timeout. xApp can also set time Subscription Manager Will wait response from E2 Node. xApp may need to update POLICY type subscription frequently. In such case it is not necessary feasible that Subscription Manager retries outdated subscription. By default Subscription Manager retries twice and response waiting time is two seconds.

In error case REST notification contains source of error. Source of error can be Subscription Manager, Routing Manager, E2 Node, ASN1 encoding/decoding and DBAAS/SDL. The error information received from these sources is directly copied in the response.

#### Architecture

Message routing

Subscribed messages from E2 Node are transported to RIC inside RIC Indication message. RIC Indication message is transported to xApp inside RMR message in Payload field of the RMR message. RMR message is routed to xApp based on SubId field (E2 instance id) in the RMR header.

Subscription Manager allocates unique E2 instance id for every E2 subscription during subscription procedure. Subscription Manager puts allocated E2 instance id to InstanceId field in the ASN.1 packed RIC Subscription Request message which is sent to E2 Node. That E2 instance id is then used for the E2 subscription in RIC and E2 Node as long the E2 subscription lives. xApp gets the allocated E2 instance id in REST notification message when E2 subscription procedure is completed.

Subscribed messages are routed to xApps based on InstanceId in E2 Indication message. InstanceId is placed in the SubId field of the RMR message header when E2 Termination sends the subscribed message to xApp.

RIC Subscription Request and RIC Subscription delete Request messages are pre configured to be routed to E2 Termination and responses to those messages back to Subscription Manager.

Subscription Manager allocates RIC Requestor Id for E2 interface communication. Currently the id value is always 123. E2 Node gets the Request of the xApp who makes the first subscription. E2 Node uses Subscription Manager allocated RIC Requestor ID in all RIC Indication messages it sends to RIC for the subscription. In merge case subscription in E2 Node is created only for the first requestor.

More information about Routing manager, how routes are created and related signaling can be found from here (Note that there is still RMR based interface between xApp and Subscription Manager in the pictures on those pages):

https://wiki.o-ran-sc.org/display/RICP/Routing+Manager+Architecture

https://wiki.o-ran-sc.org/display/RICP/Routing+Manager+and+Subscription+Manager

REST Subscription Request message


REST Subscription Response message


REST Subscription Notification message


Routing Manager REST interface messages


Subscription procedure

Successful case


## Conflict Mitigation

In the context of Near-RT RIC, Conflict Mitigation is about addressing conflicting interactions between different xApps. 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.

The control target of the radio resource management can be a cell, a UE or a bearer, etc. The control contents of the radio resource management can cover access control, bearer control, handover control, QoS control, resource assignment and so on. The control time span indicates the valid control duration which is expected by the control request.

# xApp

An xApp is an application designed to run on Near-RT RIC. It may consist of one or more microservices and at the point of on-boarding it identifies which data it consumes and which data it provides. It is independent of Near-RT RIC and may be provided by any third party. The ==E2 interface== enables a direct association between xApp and RAN functionalities.

## xApp Requirements

- xApp may enhance the RRM capabilities of Near-RT RIC;
- xApp may be associated with zero, one or more E2SMs;
- xApp shall use Near-RT RIC APIs to make use of the Information Elements (IEs) of E2SMs that are associated with it;
- xApp that is associated with a given E2SM shall be able to interface with any E2 Node that supports that E2SM without any intermediary xApp;
- xApp shall be able to receive event-triggered information on RAN information and time-varying network state.
- xApp shall provide collected logging, tracing and metrics information to Near-RT RIC;
- xApp shall provide a descriptor that includes the following basic information of the xApp:
- Configuration: It includes a data dictionary for configuration data, i.e., meta data such as a YANG definition or a list of configuration parameters and their semantics. It may also include an initial configuration of xApp;
- Control: It includes the types of data that an xApp consumes and generates, in order to perform control capabilities (e.g., xApp URL, parameters, input/output type);
- Metrics: It includes a list of metrics (e.g., metric name, type, unit and semantics) provided by the xApp.
- The xApp descriptor shall also provide the necessary data to enable management and orchestration of the xApp, aligned with [4];
- xApps shall communicate with Near-RT RIC platform via Near-RT RIC APIs;
- xApp shall register the Near-RT RIC APIs it produces;
- xApp shall be capable of discovering the Near-RT RIC APIs they consume.

# Near-RT RIC APIs

The Near-RT RIC APIs are a collection of well-defined interfaces providing Near-RT RIC platform services. These APIs need to explicitly define the possible types of information flows and data models. The Near-RT RIC APIs are essential to host 3rd party xApps in an inter-operable way on different Near-RT RIC platforms.
Near-RT RIC provides the following Near-RT RIC APIs for xApps as shown in Figure 7.1-1:
- A1 related APIs: APIs allowing to access A1 related functionality;
- E2 related APIs: APIs allowing to access E2 related functionality and associated xApp Subscription Management and Conflict Mitigation functionality;
- Management APIs: APIs allowing to access management related functionality;
- SDL APIs: APIs allowing to access Shared Data Layer related functionality;
- Enablement APIs: APIs between xApps and API enablement functionality.


# AI/ML workflow


## Types of Machine Learning algorithms

### Supervised learning


In supervised learning (seeFigure 3-1), Non-RT RIC is part of the SMO and thus is part of the management layer. ML training host and ML model host/actor can be part of Non-RT RIC or Near-RT RIC.

### Unsupervised learning

(same picture)

In unsupervised learning (seeFigure 3-2), ML training host and ML model host/actor can be part of Non-RT RIC or Near-RT RIC.

### Reinforcement learning


For reinforcement learning (seeFigure 3-3a), ML training host and ML model host/actor shall be co-located as part of NonRT RIC . For online RL in the Near-RT RIC (see Figure 3-3b), ML training host and ML model host/actor shall be co-located as part of Near-RT RIC. For offline RL (see Figure 3-3c), ML training host is located as part of Non-RT RIC, and ML model host/actor is located as part of Near-RT RIC. The offline trained model is updated based on the performance monitoring of the interaction between the ML model host/actor (RL agent) and the RAN environment.

### Mapping AI/ML functionalities into O-RAN control loops

There are three types of control loops defined in O-RAN. ML assisted solutions fall into the three control loops.


Figure 3-4 shows the three control loops in O-RAN architecture. AI/ML related functionalities can be mapped into the three loops. The location of the ML model training and the ML model inference for a use case depends on the computation complexity, on the availability and the quantity of data to be exchanged, on the response time requirements and on the type of ML model. For example, online ML model for configuring RRM algorithms operating at the TTI time scale could run in O-DU, while the configuration of system parameters such as beamforming configurations requiring a large amount of data with no response time constraints can be performed using the combination of Non-RT RIC and SMO where intensive computation means can be made available.
In the first phase of O-RAN, ML model training will be considered mainly in the Non-RT RIC and ML model inference will be considered in loops 2 and 3. For loop2, the ML inference is typically running in Near-RT RIC. For Loop 1, the ML model inference is typically running in an O-DU. ML workflow on loop 1 is not covered by this version of the technical report. While ML model implementation in O-RU could be envisaged, it is presently not supported in O-RAN.

### Federated learning

In O-RAN architecture, since both Non-RT RIC and Near-RT RIC are capable of AI/ML training, the Non-RT RIC can serve as the central server in the federated learning, and its connected Near-RT RICs can serve as distributed AI/ML entities as illustrated in Figure 3-5.

Note: Other federated learning deployment scenarios are FFS.


The procedure of federated learning among Non-RT RIC and Near-RT RICs can be summarized into following steps:
Step 1: The Non-RT RIC distributes the AI/ML model to its connected Near-RT RICs.
Step 2: The ML training host in the Near-RT RIC trains local model using training data collected locally. Note that training data collected locally are not required to be transferred to the Non-RT RIC.
Step 3: Local model weights or gradients are uploaded to the Non-RT RIC.
Step 4: The training host in the Non-RT RIC update the AI/ML model (e.g., using FedSGD, FedAvg, etc.).
Step 5: The updated model is downloaded to the Near-RT RICs.
Step 6: If the model training converges, then the model is deployed for inference in the Near-RT RIC.

## ML Model Lifecycle Implementation Example


## Deployment Scenarios


# A1 interface

## Functions

### Policy management

The policy management function is used by the Non-RT RIC to provision and manage A1 policies in the Near-RT RIC. The Non-RT RIC is responsible for definition and administration of A1 policies.


**Identification and scope of A1 policies**


Identification of UEs, groups of UEs, slices, QoS flows, cells

**A1 policy content:** General, Policy objectives, Policy resources

### A1 enrichment information

The purpose of A1 enrichment information is to enable the Near-RT RIC to improve its RAN optimization performance by utilising information that is not available within the RAN. The information sources can be O-RAN internal and O-RAN external, and the derived A1 enrichment information can be provided by the Non-RT RIC over the A1 interface.

**A1 enrichment information format and delivery:** Push based delivery