An Example Non-RT RIC Use Case

Bhanu Chandra K.


In my previous two blogs in this three-part series, I covered O-RAN Architecture and SMO and Non-Real-Time Radio Intelligent Controller (non-RT RIC) : Data driven RAN optimizer topics. In this last blog of the series, we will look at a traffic steering example Non-RT RIC use case that deals with optimizing traffic management or achieving balanced cell load.


Traffic management Use case

The Non-RT RIC configures the desired optimization policies, utilizes the right performance criteria, and leverages machine learning to enable intelligent and proactive traffic steering control. This use case is primarily based on the O-RAN architecture and its constituent entities.


Roles

As a refresher from the first blog in this series, here are the roles of each of the entities from a traffic steering use case point of view:


SMO/Non-RT RIC

1. Retrieve necessary performance, configuration, and related data for defining and updating policies to guide the behavior of traffic steering function in the near-RT RIC.

2. Support communication of policies and enrichment information to the near-RT RIC and measurement configuration parameters to RAN nodes.


Near-RT RIC

1. Support interpretation and enforcement of policies from non-RT RIC.

2. Use enrichment information to optimize control function.


CU/DU/RU Nodes

1. Send FM/PM/other data with required granularity to SMO.


The Non-RT RIC platform resides inside the SMO, collects the data, and derives analytics information which is used in the traffic steering use case and same can be extended to other use cases as well.


Policy Management

This section deals with the traffic management in RAN according to defined policies and configuration.


Prerequisites:

  • All the RAN components (CU, DU, Near-RT RIC etc.) and SMO are deployed

  • A1 and O1 interfaces are configured correctly

  • SMO collects the data and send it to the Non-RT RIC platform that derives analytics out of this data

Trigger:

The Non-RT RIC platform monitors the performance data and different counters from the various E2 nodes. Based on the trigger (defined by operator) or a generated event, the Non-RT RIC initiates a change.


Operations:

  1. The Non-RT RIC decides upon an action and communicates relevant policies to the Near-RT RIC over the A1 interface. The example policies may include:

  2. QoS targets

  3. Preferences on which cells to allocate control plane and user plane

  4. The Near-RT RIC receives relevant information from Non-RT RIC over A1 interface, interprets the policies and enforces them.

  5. The Non-RT RIC decides that conditions to continue the policy are no longer valid.

  6. The Non-RT RIC deletes the policy.

  7. The Non-RT RIC continues to monitor the performance data (events and counters from E2 nodes).

Ladder Diagram Showing the Operational Flow


Example:

Let us look at an example scenario to describe the use of A1 for traffic steering, where the Non-RT RIC sends policies for allocation of the control plane (RRC) and the user plane for different services, identified by their 5QI (5G Quality Service Indicator).

Policy Dictating the Allocation of RRC and User Plane


Cell A & B:

  • Low band, narrow bandwidth, low latency

  • Ideal for voice and control plane

Cell C & D:

  • High band, wide bandwidth, high latency

  • Ideal for data connection

In the scenario a UE with UEid=9999999999, belonging to a subnet slice identified by S-NSSAI=10, having a Voice (5QI=1) and an MBB (5QI=9) connection established, enters an area covered by four frequency bands.


The Non-RT RIC understands the requirements and characteristics of the services and decides to let the Voice and RRC connection reside on the low band (here covered by a macro cell B becoming the PCell), while the MBB (MobileBroadBand) connection should preferably use the higher band (here provided by small cells C and D becoming the SCells) and avoid the low band if possible. Cell A is used for MBB if required for coverage reasons.


NonRTRIC policy change directs control pane and voice on cell B:

{
"policy_id": "1",
"scope": {
  "ue_id": "9999999999",
  "slice_id": "10",
  "qos_id": "1",
  "cell_id": "X" // Policy for Cell X, where X is A, B, C or D
  },
"statement": {
  "cell_id_list": "B",
  "preference": "Shall",
  "primary": true 
  // Control plane on Cell B (becoming PCell)
  },
"statement": {
  "cell_id_list ": "B",
  "preference": "Shall",
  "primary": false 
  // Voice on Cell B
  }
}

Policy change from NonRTRIC related to MBB:

{
 "policy_id": "2",
 "scope": {
   "ue_id": "9999999999",
   "slice_id": "10",
   "qos_id": "9",
   "cell_id": "X" // Policy for Cell X, where X is A, B, C or D
   },
 "statement": {
   "cell_id_list ":   {"B", "A"},
   "preference": "Avoid",
   "primary": false
   // Avoid MBB on Cell A and Cell B
   },
 "statement": {
   "cell_id_list":   {"C", "D"},
   "preference": "Prefer",
   "primary": false
   // Prefer MBB on Cell C and Cell D
   }
}

Summary

We have seen how the Non-RT RIC can take decisions on pushing the optimal policies to the Near-RT RIC based on the cell characteristics. This use case explains this capability of the Non-RT RIC in the traffic steering example and the same principles can be applied to various other scenarios as well.


References: O-RAN specification documents

Images credit: O-RAN-SC

347 views0 comments