O-RAN Use Cases: Traffic Steering

The previous post in our series discusses the RAN Intelligent Controller in great detail (O-RAN near-Real-Time RIC). One of the key elements of having RIC (and the overall O-RAN concept for the management of radio networks) is to be able to efficiently manage and optimize the radio network. By using the concept of open interfaces and xApps, O-RAN enables tailored algorithms for specific use cases. O-RAN Alliance [1] specifies preliminary use cases [2, 3] and defines the policy framework by which the algorithms to support the use cases can be controlled. This post provides an overview of the use cases, which is followed by a detailed discussion of one of them, namely Traffic Steering. We discuss the use case requirements, operation of the O-RAN nodes with the specified interfaces and provide some description of the scenario as described in O-RAN Alliance specifications [2].

O-RAN Use Cases

Fig. 1, shows the different use cases that are defined by O-RAN Alliance [3] and which are split into two phases as per the organization members’ preference [3]. This means that the use cases specified within Phase I shall be developed earlier to solve the most immediate needs of the operators.

The split between phases is rather natural. Phase I use cases deal mostly with the relatively generic items like white box hardware, traffic steering or QoS/QoE optimization, or massive MIMO. Those are of high priority, as they are related to most of the scenarios that will be treated by most operators. Phase II, in turn, is related to specialized applications, like slicing/RAN sharing or UAV (Unmanned Aerial Vehicles)/V2X (Vehicular to Anything) aspects that require specific requirements (which are highly demanding) for some networks that serve specific/rare type of applications.

Traffic Steering Use Case

Let’s now take a look at one of the use cases, namely Traffic Steering (TS). Fig. 2. shows the aspects related to this use case to setup the scene as per [2].

Let’s start with what is actually TS. It specifies how to steer traffic and in mobile network’s case, i.e., to what cell or to what base station (BS) the user is connected to. It may be more general, so if we have multiple Radio Access Technologies (RATs), like 4G, 5G, Wi-Fi, and others, we have to decide, to which RAT, then to which cell and then to which band, and in that band to which component carriers the UE is connected to. In addition to that, we may have dual connectivity (DC), and so it might be a decision of what is the primary and secondary base station (or more specifically, Primary and Secondary Cell Group) that the user is having a connection to. Furthermore, once we decide which cells and base stations, the UE is connected to, there may be different traffic types that the UE may be having, like voice connection and MBB connection, and they may be treated differently by different cells.

Now, what’s the problem with this? The problem is that the typical TS schemes treat all the users in the same way and they take the average values of e.g. signal power. They are also typically limited to cell selection or handover parameters updates, based on which the UE is moved between cells. Those schemes don’t take into account that a specific user is a V2X user and that it may not be switched to another cell at the same time that a nomadic MBB user (e.g. it might make sense to change the cell of V2X UE earlier than for MBB UE due to specific requirements). This is specifically a challenge within 5G, where the network is very heterogeneous: there is slicing, and there are various architectural options, like Non-Standalone (i.e., LTE with 5G)/Standalone (5G only), there are different types of cells, and a multitude of frequency bands. Therefore, in such a HetNet the TS is very complicated and at the same very important to properly assign connections to cells to utilize the resources efficiently.

So, the purpose of this particular use case as per O-RAN Alliance is that we want to have a customization possibility where the operators might have different strategies for specific types of users. Then, depending on the type of services or slice types assigned to a specific user, we might treat them in a different way. So we want to have the possibility to allow flexibility or configuration of the different optimization policies. According to the O-RAN Alliance concept, in this aspect, ML can be „hired” to enable intelligent traffic steering control. What the O-RAN Alliance specifies is the required data that we would like to have to take that particular decision, e.g. RSRP/RSRQ (the typical measures), handover, cell load, and UE performance statistics. Now, if you gather them all, you have a lot of data from different sources saying different things. When taken collectively, they can be used to have a specific user being treated individually, and as a result of its specific characteristics, obtains a unique allocation.

To realize the above, we use the O-RAN Alliance concept of RIC, where through ML schemes we can learn that this is e.g. a street where the users are moving in a specific direction and if they are in a car and have a specific slice type, they may be moving and they may be treated one way, while the learning mechanism can say to the xApp controlling the handover that it does that in a certain way for one type of user and does that in a different way for another user.

Traffic Steering Use Case Operation within O-RAN Architecture

Let us now look into the specific entity responsibilities within the O-RAN Alliance architecture for handling that use case, as shown by Fig. 3.

The following are the responsibilities of the different elements shown in Fig. 3:

• Non-RT RIC:
  • Defines and updates policies – to guide the behavior of TS xApp in near-RT RIC (e.g. optimization objectives to guide carrier/band preferences for UE/UE-group);
  • Performs statistical analysis to provide enrichment info for near-RT RIC to assist TS function (e.g., RF fingerprint based on UE measurement report like RSRP/RSRQ/CQI info for serving/neighboring cells);
  • Communicates policies and enrichment info (e.g. RF fingerprints) to near-RT RIC & measurement configuration parameters to RAN nodes.
• near-RT RIC:
  • Interprets and enforces policies from Non-RT RIC;
  • Uses enrichment info to optimize control function, e.g., near-RT RIC can use RF fingerprint to predict inter-frequency cell measurement based on the intra-frequency cell measurement to speed up the TS;
• E2-Node (here being O-CU):
  • Collects and transmits data with required granularity to SMO over O1;
  • Executes actions.

The information provided at the related interfaces, is as follows:

• A1 is used to provide near-RT RIC with: A1 policy – declarative policy to enable Non-RT RIC to guide near-RT RIC on steering the behavior of RAN functions towards stated objectives; A1 enrichment info – additional info used by near-RT RIC collected at SMO/non-RT RIC from non-network data or from NFs;
• E2 is used to deliver to the E2-Nodes control messages, like handover execution or Secondary Cell activation / SecondaryCell Group addition, etc.

So, to sum up. The Non-RT RIC defines and updates the policies to guide the behavior of the TS xApp that is sitting in the near-RT RIC. It also performs the statistical analysis of the data and provides policies and enrichment information (like RF fingerprints). Here is also where the learning happens and setting up policies that are sent over the A1. The policy can be for example, „prefer/forbid/allow cell X for user Y for a particular service/slice/QoS profile”. The implementation of the policy is within the near-RT RIC, which takes the specific decision (e.g., that a specific user needs to move from one cell to another), and sends that over the E2 interface via control messages, while E2 nodes execute those actions by means of RRC procedures (e.g. Handover command, Secondary Node addition, etc.)

Example TS Use Case

Fig. 4 shows the example scenario for the TS use case.

In this example, there are:

• macro BS (denoted as gNB1) that controls cells (A and B), located on low bands (e.g. 700/800 MHz) with 10 MHz carrier bandwidths and allow low latency (due to FDD case)
• small BS (denoted as gNB2), with wide BW/high throughput cells (C and D), using high frequency (e.g. 3.8/4.5 GHz) with a lot of available resources, by which the UE can obtain all the data it needs very quickly.

Cells C/D are treated as MBB cells, while for the voice service, we don’t need that much BW and we rather focus on high coverage, to avoid frequent handovers and providing a reliable connection. The UE under consideration is having two services, voice and MBB (belonging to slice ID 1). The UE is entering the area covered by the four cells mentioned above. If we now look at the situation from the O-RAN perspective, the Non-RT RIC understands the requirements and characteristics of that services. It decides that due to having a voice and Control Plane (CP) connection, we need to put those on a low band (basing its decisions on measurements, or ML algorithm, or operator settings) on the largest cell, which will be cell B. On contrary, for MBB connection when the user moves to the coverage of small cells, we can add a second transmission leg and offload this traffic type to cell C/D, and try to avoid consuming resources from the cells A/B. This shall be sent to near-RT RIC, through several policies as described below.

To achieve that behavior, the non-RT RIC sends two policies to near-RT RIC as shown in Fig. 5. One of them steers voice services to be served by cell B (basically saying that for CP we are setting the cell B with „shall” and that it’s a primary cell, whereas we may have for the voice also cell B, and it might be secondary cell), whereas second policy is for MBB service, which states, that UE shall avoid cell B and A, (because it would consume a lot of resources, required by CP traffic and voice users), and it should prefer cells C and D (which are dedicated for MBB).

After receiving the messages, the near-RT RIC needs to locate that UE and enforce the assigned policy, by telling the base station to execute specific RRC commands (like handover, relocation, SCG addition/change, etc.) as shown in Fig. 6. The control messages, are as follows:

• perform handover to cell B, which becomes then PCell and handles CP traffic;
• add cell A to the Carrier Aggregation set for voice service;
• and add secondary gNB (SCG) to be used for handling MBB service.

So the end of the story is that the UE has connections to two BSs and has each service being delivered to it from different cells.

Summary

This post closes the bracket of our O-RAN discussion with respect to the architecture, design, and application scenarios. We went from the overall description of use cases as per O-RAN Alliance specifications finalized by showing a particular example of Traffic Steering. Each of the use cases described in the first part of this post is detailed in [2] with similar elaboration. Traffic Steering, discussed in this post is an important element of the current mobile systems due to the multitude of options for cell assignment and multi-node transmission, and as such is addressed by O-RAN Alliance in the so-called „Phase I”. The conclusions taken from this use case elaboration of using O-RAN are that it allows:

• adding intelligence to network with external entities, namely xApps and both RICs;
• control of RAN behavior by declarative policies;
• combination of various applications (like xApps/rApps) to realize certain objectives of network performance optimization;
• a hierarchical and modular approach to resource management;
• defining RRM applications (xApps) on per use case basis.

RIMEDO Labs Resources

• The O-RAN Whitepaper: Sign up for our newsletter to download: The O-RAN Whitepaper
• Blog posts: Check out other blog posts in this series: 1. Introduction to O-RAN: Concept and Entities, 2. O-RAN Architecture, Nodes, and Interfaces, 3. O-RAN near-Real-Time RIC
• 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.

References

[1] O-RAN ALLIANCE (o-ran.org)
[2] O-RAN.WG2.Use-Case-Requirements-v02.01, „Non-RT RIC & A1 Interface: Use Cases and Requirements”, O-RAN Alliance, Nov. 2020
[3] „O-RAN Use Cases and Deployment Scenarios”, O-RAN Alliance Whitepaper

Author Bio