Policy-based Traffic Steering xApp implementation within O-RAN

Overview

The state-of-the-art approach to Traffic Steering (TS) is that all users are treated in the same way, which means that handover or cell reselection decisions are taken based on average KPI values. As a result, TS rules are limited to setting e.g., general handover thresholds, cell priorities. To overcome this issue, O-RAN Alliance identified TS as one of the use cases to be addressed by the xApps [1]. The main idea is to deploy xApps that will support custom UE-centric TS strategies dedicated for various mobile traffic scenarios, e.g., User assignment to Base Stations (BSs) that takes into account traffic types: e.g., voice or Mobile BroadBand (MBB), cell types, radio technology type, slice type, etc. This idea served as the motivation for Rimedo Labs to deploy TS xApp.  The high-level diagram of TS xApp within O-RAN architecture is depicted in the figure below.

The Rimedo TS xApp is deployed as an extension to the Near-Real-Time RAN Intelligent Controller (Near-RT RIC). It is responsible for the interpretation and enforcement of policies defining cell association preferences under various scenarios. The policies are defined in Non-Real Time RAN Intelligent Controller (Non-RT RIC) e.g., on the basis of the statistical analysis, and are subject to machine learning schemes. The policies are then communicated to Rimedo TS xApp through the A1 interface. When the xApp performs actions on the basis of the current policy, the proper control messages are sent to E2 Nodes through the E2 interface (e.g., handover command). At the same time, Rimedo TS xApp gathers required data (e.g., received signal power, cell type, UE identity, RRC state, and QoS indicator) from the reports sent by E2 Nodes through the E2 interface. For this purpose, xApp must be equipped with some storage unit, e.g., database, proper data structures. In the potential future development, the Rimedo TS xApp can utilize the enrichment info sent by the non-RT RIC in order to improve performance with the use of Machine Learning (ML) techniques or RF fingerprints.

Triggers for Traffic Steering

Although Traffic Steering functionality is implemented by Rimedo as xApp, which in theory should work in near-real-time conditions (>=10 ms, <1 s) it is still an open question how often/under what conditions should the traffic steering be invoked. Below there is a list of several potential triggers for the Rimedo TS xApp (see an example of HO decisions in Fig. 2 below):

1. Periodic – the most straightforward approach is to launch traffic steering at some constant, or dynamically changing time intervals. The open issue is how often should it be? Short time intervals can provide good load balancing, but can potentially result in conflicts with other xApps using Handover procedure.  On the other hand, long time intervals can reduce conflicts with other xApps, but also under such conditions Traffic Steering cannot adapt to changing traffic characteristics fast enough.
2. Event Driven – another approach that can be implemented is to launch Traffic Steering when some special events occur. These events can potentially be deduced on the basis of the E2 interface messages. Some examples are listed below:
   • upon High Resource Utilization – the Traffic Steering may be launched when resource utilization in some cells is high. It is an open question, if an xApp should monitor resource utilization itself and decide to perform Traffic Steering on its own, or non-RT RIC should notify the xApp that it should perform Traffic Steering decision. Maybe xApp should request new policy under high resource utilization case, when following the current policy is not effective.
   • upon Handover – it might be beneficial to launch Traffic Steering in cooperation with handover mechanisms e.g., after handover (or several handovers) is performed, the Traffic Steering is launched. In this case, the challenge arises to resolve conflicts of cell preferences between Traffic Steering and handover mechanism.
   • upon traffic characteristic change – the Traffic Steering should be also launched after detection of significant change in the traffic characteristics, e.g., a lot of new users that were requesting voice connections now request MBB. Here also question arise if xApp should determine the neccesity of a new policy request.
3. Hybrid – it is possible that the best approach would be to combine periodic launch of Traffic Steering with Event Driven approach. I.e., Traffic Steering is being launched in some constant time intervals, and additionally, when specific event occurs.
4. Policy based – upon policy change – the Traffic Steering adapts its behavior, should the new policy be received via A1 interface from non-RT RIC.

Rimedo Labs’ Traffic Steering xApp in the context of ONF’s SD-RAN

Traffic Steering (TS) application (xApp) for µONOS RIC – associates the users with the eNB/gNB taking into account user radio conditions, cell types, and service type/QoS profile. It can be controlled by policies from non-RT RIC (A1 interface).

Key features of the TS xApp:

• Suitable for heterogeneous network scenarios;
• Per-user association decision taking into account radio conditions (e.g. RSRP), service type (e.g. 5QI), cell type;
• Optimizes user-throughput and cell-outage.

The Rimedo TS xApp is implemented with the use of go-SDK and is fully integrated with the ONF’s SD-RAN environment (see the press release here: Rimedo Labs to Integrate and Open Source TS xApp with ONF’s SD-RAN). The network parameters that are necessary for Traffic Steering are taken directly through the E2 interface (realized by onos-e2t). The policy files are received by Rimedo TS xApp through the A1 interface (realized by onos-a1t), which represents the functionality of the A1 interface. The next parts of this section describe the data required by the Rimedo TS xApp:

1. Input Data Required by Rimedo TS xApp from the E2 interface: 
   • User Equipment Identity (UE ID) – International Mobile Subscriber Identity (IMSI) [2].
   • Cell Global Identity (CGI) – the combination of Public Land Mobile Network Identity (PLMN ID) and E-UTRAN Cell Identity (ECI) or New Radio Cell Identity (NCI) [2].
   • Radio Resource Control (RRC) state – defines certain specific states that a UE may be present in. In the RAN simulator, there are only the two RRC states are specified: CONNECTED and IDLE [3, 4].
   • Received power (RSRP) for each UE for each (possible) Cell – usage of MHO service model – E2SmMhoMeasurementReportItem, which contains CGI and RSRP [4].
   • 5G QoS Identifier (5QI) – according to [5], the 5QI is associated with a particular 5G QoS characteristic. These characteristics can be understood as a guideline for setting node specific parameters for each QoS Flow, e.g., for 3GPP radio access link layer protocol configurations.
2. Traffic Steering Policy required by the Rimedo TS xApp from the A1 interface

The A1 interface is described in O-RAN.WG2.A1AP-v03.01 document [6]. The service model defined therein seems proper for the Rimedo TS xApp.  It is depicted in the Figure below.

A1-P Consumer is residing in the Non-RT RIC and the A1-P Producer is residing in the Near-RT RIC. Both the A1-P Consumer and the A1-P Producer contain an HTTP Client and an HTTP Server. In the future, A1-ML or A1-EI service models can be necessary when extending xApp with Machine Learning models.

A1 Termination (A1T) component communication proposed by the ONF in A1T Design Notes [7] is used for the Rimedo TS xApp to provide policy operations through A1T, i.e., A1 policy setup, A1 policy update, A1 policy delete, A1 policy query, A1 policy status.

According to O-RAN.WG2.A1AP-v03.01, the policy corresponds to the resource in the REST sense and is represented by a JSON file. The general definition of the JSON File containing Traffic Steering Policy (TSP) is as follows (the below shows the policy schema used by Rimedo TS xApp).

{ 
  "$schema": "http://json-schema.org/draft-07/schema#",
  "description": "O-RAN standard Traffic Steering Preference policy",
  "type": "object",
  "properties": {
    "scope": {
      "anyOf": [
        { "type": "object",
          "properties": {
            "ueId": {"$ref": "#/definitions/UeId"},
            "sliceId": {"$ref": "#/definitions/SliceId"},
            "qosId": {"$ref": "#/definitions/QosId"},
            "cellId": {"$ref": "#/definitions/CellId"}
          },
          "additionalProperties": false,
          "required": ["ueId"] },
        { "type": "object",
          "properties": {
            "sliceId": {"$ref": "#/definitions/SliceId"},
            "qosId": {"$ref": "#/definitions/QosId"},
            "cellId": {"$ref": "#/definitions/CellId"}
          },
          "additionalProperties": false,
          "required": ["sliceId"] }
      ]
    },
    "tspResources": {
      "type": "array",
      "items": {"$ref": "#/definitions/TspResource"},
      "minItems": 1
    }
  },
  "additionalProperties": false,
  "required": ["scope", "tspResources"], 
  … 
}

It is important to note that the Traffic Steering Policies can be defined per single UE, per group of UEs, per Slice, per QoS, or per Cell. This gives an opportunity to define policies that contain some general rules applied to most of the UEs under common radio conditions, and specific UE-centric rules for the UEs being under challenging radio conditions. Cell preferences are set by setting one of the „preference” type: „SHALL”, „PREFER”, „AVOID” or „FORBID” [6]. The preferences can be realized in the xApps differently, as per vendor-specific implementation. In our case, the weight corresponds to the weights used for Cell Range Extension (CRE) and can be defined as follows.

{
  "DEFAULT": 0,
  "PREFER": 16,
  "AVOID": -16,
  "SHALL": 1000,
  "FORBID": -1000
}

If we don’t use any policy (i.e. no policy is provided through A1) for the TS xApp, the handover operation of the UE between the cells is performed based on the RSRP level (i.e. threshold-based HO procedure is used). This mechanism considers measuring the RSRP level in dBm from each cell in the range of the UE to choose this one, for which the received signal is the strongest. In the below figure, such HO behavior is visualized.

Now we provide an example of a policy that influences a single UE. The Traffic Steering is realized by direct indication of the user subject to action, by the policy scope that contains „ueId”. It is worth noting the UE association at different points in time.

Per UE policy example (PREFER)

{
  "scope": {"ueId": "0000000003064635"},
  "tspResources": [
    {
      "cellIdList": [
        {
          "plmnId": {"mcc": "314", "mnc": "628"},
          "cId": {"ncI": 470106432}
        }
      ],
      "preference": "PREFER"
    }
  ]
}

Per UE policy example (AVOID)

{
  "scope": {"ueId": "0000000003064635"},
  "tspResources": [
    {
      "cellIdList": [
        {
          "plmnId": {"mcc": "314", "mnc": "628"},
          "cId": {"ncI": 470106432}
        }
      ],
      "preference": "AVOID"
    }
  ]
}

Per UE policy example (FORBID)

{
  "scope": {"ueId": "0000000003064635"},
  "tspResources": [
    {
      "cellIdList": [
        {
          "plmnId": {"mcc": "314", "mnc": "628"},
          "cId": {"ncI": 470106432}
        }
      ],
      "preference": "FORBID"
    }
  ]
}

QoS-based policy example (SHALL)

Now, let’s look at another example for a policy that could influence one or multiple UEs. In this case, the traffic steering acts based on the user’s service type. The policy scope contains „qosId” field. In this case, „5qI” value is used. Therefore, the handover is invoked differently for users having different services. This can be applied for offloading purposes to move MBB users to small cells and utilize macro sites for voice users.

{
  "scope": {
    "sliceId": {
      "sst": 1,
      "sd": "456DEF",
      "plmnId": {"mcc": "314", "mnc": "628"}
    },
    "qosId": {"5qI": 1}
  },
  "tspResources": [
    {
      "cellIdList": [
        {
          "plmnId": {"mcc": "314", "mnc": "628"},
          "cId": {"ncI": 470106432}
        }
      ],
      "preference": "SHALL"
    }
  ]
}

Installation

To use the TS xApp there should be the Kubernetes, Docker, Helm, and SD-RAN (by ONOS) installed and deployed. You can use the SDRAN-in-a-Box (RIaB) project to install everything at once or install all the items manually and deploy SD-RAN from the SD-RAN Helm charts repository (see sdRan-in-a-Box for installation guide).

Requirements

TS xApp was tested under the following version of SD-RAN modules.

µONOS module	Version
onos-a1t	v0.1.11
onos-cli	v0.9.10
onos-config	v0.10.27
onos-e2t	v0.10.11
onos-topo	v0.9.2
ran-simulator	v0.9.6
e2sm_mho_go	v0.8.7

Deployment

There are two ways for the TS xApp deployment and both have to be performed from the sdran-helm-charts repository:

• Installation with the sdran

helm upgrade --install -n riab sdran sdran/sd-ran  
--set import.ran-simulator.enabled=true --set import.rimedo-ts.enabled=true

• Installation using the helm charts

helm install -n riab rimedo-ts ./rimedo-ts --values ./rimedo-ts/values.yaml

Useful tips

• <ip_address>:31963/policytypes/ORAN_TrafficSteeringPreference_2.0.0/policies/<policy_id> – the policies are send to A1 interface on address (set in REST Client)
• kubectl logs -n riab rimedo-ts-<id> rimedo-ts – observe logs of TS xApp
• watch onos uenib get ues -v – observe RSRP of UE (type in onos-cli)

Video demonstration

You can check a short demo of the TS xApp usage under the following link: Rimedo Labs Traffic Steering xApp on ONF’s SD-RAN (DEMO) – YouTube

References

[1] https://rimedolabs.com/blog/o-ran-use-cases-traffic-steering/
[2] 3GPP TS 23.003 V12.9.0 (2015-12)
[3] 3GPP TS 38.331 V15.3.0 (2018-10)
[4] 3GPP TS 36.214 V9.1.0 (2010-04)
[5] 3GPP TS 23.501 v17.3.0 (2018-09)
[6] O-RAN.WG2.A1AP-v03.01
[7] ONF A1T Design Notes (onos-a1t — SD-RAN Docs 1.4.0 documentation)

Acknowledgements

The author would like to thank Marcin Hoffmann and Łukasz Kułasz for their support in creating this blog post.

Łukasz Kułacz is a research and teaching assistant at PUT’s Institute of Radiocommunications, Poland, and he is a Senior R&D Engineer and Technical Team Leader at Rimedo Labs. He is currently pursuing a Ph.D. in the field of communication technologies with the Institute of Radiocommunications. He is involved in both, national and international research projects. His research interests include the software-defined radio and utilization of context information for radio network operation improvement, in particular the radio resource allocation process improvement. His scientific works are already published in well-recognized international journals like IEEE Access, IEEE Vehicular Magazine, or MDPI Sensors. At Rimedo Labs he leads the R&D team developing xApps and realizing dedicated software and simulations for the company’s customers.

Marcin Hoffmann is an R&D engineer at Rimedo Labs working on O-RAN software development solutions and spectrum sharing-related projects. Marcin is a Graduate Student Member, at IEEE and received the M.Sc. degree (Hons.) in electronics and telecommunication from Poznań University of Technology, in 2019, where he is currently pursuing a Ph.D. degree with the Institute of Radiocommunications. He is gaining scientific experience by being involved in both national and international research projects. His research interests include the utilization of machine learning and location-dependent information for the purpose of network management. In addition to that Marcin works on massive MIMO and advanced beamforming techniques. His scientific articles are published in top journals like IEEE Transactions on Intelligent Transportation Systems or IEEE Access.

RIMEDO Labs Resources

• The O-RAN Whitepaper: Sign up for our newsletter to download: The O-RAN Whitepaper
• Blog posts: Other blog posts regarding the O-RAN:  1. Introduction to O-RAN: Concept and Entities, 2. O-RAN Architecture, Nodes, and Interfaces, 3. near-Real-Time RIC (RAN Intelligent Controller), 4. O-RAN Use Cases: Traffic Steering
• Webinar: A video recording from a webinar discussing the above aspects, and architecture, RIC internals, use cases, with a special focus on traffic steering: O-RAN Architecture and Use Cases – YouTube
• Slides: Sign up for our newsletter to get a free copy of slides on O-RAN Architecture and Use Cases
• Training: Sign up for our O-RAN System Overview Course.
• Poster (High quality, printer-friendly, A3): Subscribe to get your O-RAN Poster copy.

Author Bio