Traffic Steering in O-RAN: Migration from xApp to rApp

O-RAN standard development continues to drive innovation in intelligent RAN management. Currently, real-world networks seem much closer to adopting the Service Management and Orchestration (SMO)/Non-RT RIC, and operators consider rApps deployments before xApps [1]. To address this, we have rethought some of our algorithms that currently served as xApps and packaged them into an rApp. One example of such work was undertaken in a project with TietoEvry, Aether, and VIAVI under the SMaRT-5G initiative in collaboration with an operator [6].

Traffic Steering (TS) xApp has proven highly effective for near-real-time network optimization [2][3][4][5]. However, certain TS functions can be successfully migrated from an xApp to an rApp, which aligns with the current focus on the SMO/Non-RT RIC development. This redesign encompasses a different time scale, interfaces, and algorithmic approach.

In this blog, we discuss the results of the collaborative project focused on developing an rApp for traffic steering in 4G/5G heterogeneous RANs, leveraging an open-source O-RAN architecture [6]. The SMaRT-5G initiative, involving industry partners like Intel Labs,  TietoEvry, Aether, VIAVI, and Rimedo Labs, experiments with SMO and Non-RT RIC hosting rApps that operate solely via the O1 interface – avoiding A1/E2 interfaces – for coordinated network optimization. Here, we focus on migrating the TS function, originally designed as an xApp (Near-RT RIC), to an rApp (Non-RT RIC). The article covers the ideas, differences, the actual process of migration, and the integration and final performance testing of the TS-rApp. We address the architectural, algorithmic, and practical aspects of this migration.

Traffic Steering Functionalities

Traffic steering is a fundamental Radio Resource Management (RRM) function in mobile networks that determines which cell or base station (BS) a user equipment (UE) connects to. It can involve decisions for single or multiple connections, often using advanced features like Dual Connectivity or Carrier Aggregation to meet diverse user and application needs, while optimizing the use of available radio resources. Modern TS goes beyond simple, uniform rules. For example, the Rimedo Labs’ TS-xApp integrated with different RIC platforms offers: service-based traffic steering, A1 interface integration, cooperation with energy saving functions, and Load Balancing (LB) features. Ultimately, the traffic steering is a multidimensional optimization process essential for delivering the best user experience in today’s complex, heterogeneous mobile networks.

Precise control of user allocation to cells requires low latency, so the default and most appropriate choice is to place the TS algorithm in the xApp form. However, considering the operators’ current preferences and the stages of RIC implementation in response to market needs, let us see how TS can be implemented differently. More specifically, to what extent the features of TS within Near-RT RIC available over the E2 interface could be translated to the O1 interface and Non-RT RIC.

Feasibility of E2 and O1 Interfaces for Traffic Steering

The key determinant for the xApp-rApp migration is the availability of the input data and the possibility of controlling the RAN. Let’s look at the differences between the E2 interface (used by TS-xApp) and the O1 interface (used by TS-rApp), summarized in Table 1 (data reporting) and Table 2 (RAN control capabilities). Further, Table 3 highlights the main differences between TS-xApp and TS-rApp.

For monitoring of RAN performance, both O1 and E2 interfaces rely on the Performance Metrics (PM) defined by 3GPP in TS 28.552 [10]. However, as can be seen in Table 1, there are two major differences:

• Scope: While the O1 interface can expose the PM data, for E2 Node, cell, network slices, and 5QI. The E2 interface offers more flexibility by extending the scope of some PM data even to the UE-level.
• Report Interval: Although,in theory, the Non-RT RIC control loop might be as low as tens of seconds, in practice, the PM data exposed over the O1 interface are reported within intervals of minutes or even tens of minutes [14]. Instead, over the E2 interface, the reporting interval can be as low as tens or hundreds of milliseconds. This enables fast reaction to the changes in RAN performance.

In addition, the E2 interface provides a RAN Control (RC) Service Model (SM) [11], which can be used to directly copy some messages from the RAN. For example, in the traffic steering case, this could be measurement reports containing the RSRP of individual UEs. This is not possible over the O1 interface.

For obtaining the configuration of cells, the O1 interface Configuration Management (CM) relies on the Information Object Class (IOC) according to 3GPP TS 28.541 [12]. Some of these IOCs are also exposed over the E2 interface through the Cell Configuration and Control (CCC) SM (e.g., O-CES Management Function for cell on/off switching). Based on our experience, in both cases, notifications to the xApp or rApp are sent upon the configuration change, and have a similar delay.

Table 1. Monitoring data available through E2 and O1 interfaces

Service	Scope	Report Interval	Reported Data
O1 – PM	Plmn ID, E2Node, Cell, Slice, 5QI*	Order of minutes (cyclic)	Performance Metrics according to 3GPP TS 28.552
O1- CM	gNB, O-CU, O-DU	on configuration change**	Information Object Class according to 3GPP TS 28.541
E2SM – RC	E2Node, Cell, Slice, 5QI, UE	Order of milliseconds (on configuration change/message copy)	RAN Control data according to the REPORT Service style from ORAN.WG3.E2SM-RC
E2SM – KPM	Plmn ID, E2Node, Cell, Slice, 5QI, UE*	Order of milliseconds	Performance Metrics according to O-RAN.WG3.E2SM-KPM (based on 3GPP TS 28.552)
E2SM-CCC	E2Node, Cell, O-CU, O-DU	Order of milliseconds (on configuration change)	Cell Configuration according to O-RAN.WG3.E2SM-CCC

As mentioned above, we identified the differences between the O1 and E2 interfaces concerning the data reporting. On the other hand, the means to control the RAN are crucial for the xApps and rApps design. To this end, there are two major differences (see Table 2):

• Controlled parameter: The E2 interface provides two major approaches to influence the RAN behavior in the context of traffic steering. One is a direct control of the handover command. An alternative is to define the policies, to create flexible rules when a handover should be triggered, e.g., by setting proper A1-A6 thresholds [13]. In contrast, over the O1 interface, it is only possible to control the cell individual offset (CIO). This reduces the flexibility and potential use cases for performing load balancing.
• Scope: The E2 interface offers a much more flexible scope of control actions. For example, both the handover commands and the policies can be defined for a cell, network slice, 5QI, or even for an individual UE. In contrast, the O1 interface allows only the CIO between a pair of neighboring cells to be defined.

Table 2. Control and configuration possibilities available through E2 and O1 interfaces

Service	Controlled Parameter	Scope	Use Case
O1- CM	Cell Individual Offset	Cell	LB (only long-term due to PM report delay)
E2SM – RC (CONTROL)	Handover command	Cell, Slice, 5QI, UE	LB, Service-Based Traffic Steering, UE offloading for cell shutdown
E2SM – RC (POLICY)	A1,A2,…,A6 thresholds	Cell, Slice, 5QI, UE	LB, Service-Based Traffic Steering, UE offloading for cell shutdown

Table 3 summarizes the main differences between the xApp and rApp variants of the TS algorithm implementation in terms of the above-mentioned interface limitations and features.

Table 3. Comparison of TS-xApp and TS-rApp

Aspect	xApp (Near-RT RIC)	rApp (Non-RT RIC)
Timescale	10ms – 1s	≥1s (typically minutes-hours)
Interface	E2 (direct RAN control)	O1 (config) + A1 (policy)
Control	Direct UE-to-cell decisions	Configuration management
Algorithms	Real-time A3 events, RSRP handling	Offset for handovers
Deployment	Near-RT RIC	Non-RT RIC

Traffic Steering Integration Options

Taking into account differences between interfaces for data reporting and RAN control, Fig. 1 presents three approaches to the TS algorithm placement in the network.

Fig. 1. Traffic Steering integration variants

First, the TS function can be used as an xApp in Near-RT RIC (see left part of Fig. 1). In this option, it operates by continuously monitoring real-time metrics from the RAN, and through dynamic reassignment of user traffic between cells, bands, or network slices based on factors such as radio conditions, cell load, user profiles, and KPI triggers, aiming to maximize throughput, ensure efficient resource utilization, and balance load across cells. As indicated in the previous section, the E2 interface can expose PM data in short intervals and within a narrow scope, e.g., per UE, or per 5QI. Moreover, the RAN control capabilities allow control of individual handovers. This makes Near-RT RIC a straightforward choice for TS-xApp, especially for scenarios requiring rapid optimization, such as high user mobility or fluctuating traffic patterns in heterogeneous networks.

The broadest and most universal TS operation can be achieved by the joint usage of the TS-xApp with another rApp (see the central part of Fig. 1). In such an approach, the TS-xApp makes an immediate UE-related decision, and the rApp, through policies, optimizes TS-xApp operation to match a larger-scale objective. This tandem uses the handover control offered by the E2 interface and the policy mechanism available through the A1 interface. In such a setup, the TS-xApp is cooperating with other applications. This is possible, due to the A1 policies it can receive from various rApps (e.g., Traffic Management rApp, or Energy Saving rApp [7], [8]). Such an app-tandem in the form of TS-xApp and Traffic Management rApp (TM-rApp) could be used for various advanced scenarios. In [7], we considered the TM-rApp and TS-xApp tandem, where xApp operation is optimized according to emergencies detected in the network in a V2X scenario.

Finally, (as shown on the right part of Fig. 1), using TS as an rApp focuses on higher-level network optimization within the Non-RT RIC, operating on longer timescales, namely, minutes to hours. It steers the network by directly adjusting configurations through the O1 interface, rather than issuing policies via the A1 interface. As mentioned earlier, the O1 interface is characterized by long report intervals (e.g., a few minutes). Thus, the TS-rApp can analyze aggregated network data and performance metrics over a longer timescale. Moreover, its control capabilities are limited to modifying certain thresholds per cell (e.g., CIO), instead of the explicit handover trigger for a given UE. Therefore, in this case, the TS-rApp using O1 indirectly influences UE association by modifying cell parameters. The O1-driven approach is enough for gradual, system-wide adaptations, but does not provide rapid, per-UE responsiveness found in near-RT control. As a result, TS as an rApp with its limitations is best suited for scenarios focused on long-term network operational efficiency, like load balancing of the network traffic.

Traffic Steering rApp Algorithm

Considering all the above discussion, our implementation of the TS-rApp enables an LB feature.

As LB focuses on long-term network optimization, the O1 interface can be used for monitoring purposes by observing aggregated performance metrics (on a minute-level scale). Using O1 configuration management, the effective cell coverage area (regarding the handover region) can be adjusted by setting CIO. The typical LB operation is visualized in Figure 2. When the coverage cell is overloaded, the LB feature moves some users to the capacity cell. Increasing the CIO of the capacity cell increases its effective coverage area, which makes additional users move from the coverage cell.

Fig. 2. Load-balancing feature of traffic steering

Now that the general concept is known, let’s move to the algorithm of the TS-rApp operation. The high-level TS-rApp operation is shown in Fig. 3.

Fig. 3 Simplified signalling for Traffic Steering rApp operation

TS-rApp starts with the subscription to the relevant O1 PM. In this case, the requested information is:

• Information about cell configuration is available through Configuration Management (CM) [12], including
  • arfcnDL/UL (for 5G)earfcnDL/UL (for 4G)
  • bsChannelBwDL/UL (for 5G)
• Observed cell load is available through Performance Metric (PM) [10], including
  • DL/UL Total PRB Usage (RRU.PrbDl/Ul)

When the indicated metrics are collected, they are transmitted through SMO to the TS-rApp. Next, the internal TS algorithm can calculate a new set of CIOs to match objectives (in this case, to balance load among cells). Using O1 CM, the following cell configuration can be set:

• TS-rApp controls indirect handovers through Cell Individual Offset (CIO) using CM [12], including
  • rsrpOffsetSSB/CSI-RS
  • rsrqOffsetSSB/CSI-RS
  • sinrOffsetSSB/CSI-RS

Such a set of CIO values is sent to SMO and subsequently to relevant cells. Finally, the CIO is updated, which, in fact, changes handover regions and balances the load in the network.

To realize the abovementioned idea, the TS algorithm was adjusted by Rimedo Labs for O1 operation as described therein and integrated by Tietoevry into the OSC Non-RT RIC as an rApp. The algorithm operation was tested using the VIAVI network emulator. The simplified architecture of the solution is presented in Figure 4.

Fig. 4. Simplified architecture for the Traffic Steering use case

Traffic Steering rApp Testing

To verify the TS-rApp implementation, the following network setup was prepared in the VIAVI RAN emulator:

• Network topology: 17 cells, 80 UEs
• Carrier frequencies: 3.6 GHz for coverage cells and 28 GHz for capacity cells.
• Simulation duration: 40 minutes of the network operation.

LB improvement is visible in Fig. 5. Network traffic (represented in the form of PRB usage) from the highly loaded cells (IDs: 4, 6, 14) is offloaded to other neighboring cells.

Capacity cells typically use higher carrier frequencies; thus, larger path loss results in fewer UEs associated with these cells in the cell selection process. Correctly set, the CIO can prioritize capacity cell selection. The traffic offload operation (from coverage to capacity cells) lowers the RSRP of UEs, as some of them connect to not the strongest cell. However, as a result of such a transition, more resources are available for those UEs, thus not only is the high path-loss compensated, but also higher throughput is achieved for them.

Fig. 5. Average number of used PRBs per cell in DL (with TS-rApp – blue, without TS-rApp – orange)

The simulation results presented in Fig. 6 show that in DL, around 13% improvement in average UE throughput can be observed, mostly for the cell-edge and median users. Most importantly, during the whole simulation, despite the selection of not the strongest cells by some of the users, the achieved throughput is high compared to the baseline without TS-rApp. This leads to higher spectrum efficiency.

Fig. 6. Average UEs DL throughput (with TS-rApp: blue, without TS-rApp: orange)

Summary

Recently, MNOs and vendors have been prioritizing the deployment of SMO/Non-RT over the Near-RT RIC and xApps. To address this market trend, Rimedo Labs investigated how to move our flagship TS-xApp, widely tested under various Near-RT RIC platforms, to TS-rApp in Non-RT RIC. For this purpose, we analyzed the capabilities of E2 and O1 interfaces and transferred part of the TS functionality operating on a longer timescale, namely load-balancing based on the adjustment of CIO. The redesigned TS-rApp has been integrated by Tietoevry into the OSC-Non RT RIC and effectively validated using the VIAVI RAN simulator. The TS-rApp demonstrated a throughput improvement of approximately 13% when evaluated in a setup with 17 cells and 80 emulated UEs. This performance boost was primarily noticeable for cell-edge and median users, who experienced the greatest gains. The TS-rApp intelligently redistributed traffic, even directing some users to cells with slightly worse radio conditions, but greater available radio resources, maximizing overall network efficiency.

Overall, although the O1 interface has some limitations compared to the E2, the TS-rApp delivers tangible improvements in throughput and user performance under realistic network scenarios.

Let us know if you are interested in performing a PoC with any of our rApps, designing a customized rApp, or redesigning other xApps in our portfolio.

References

1. https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/docs/vmw-oran-ric-thought-leadership-report.pdf
2. https://rimedolabs.com/blog/policy-based-traffic-steering-xapp-implementation-within-o-ran/
3. https://rimedolabs.com/blog/the-oran-whitepaper-2024-traffic-steering-in-oran/
4. https://plugfestvirtualshowcase.o-ran.org/2023/O-RAN_Global_PlugFest_hosted_by_Deutsche_Telekom_EANTC_EURECOM_Orange_Vodafone
5. https://rimedolabs.com/blog/how-can-energy-saving-and-traffic-steering-cooperate-in-o-ran/
6. https://aetherproject.org/press-release/2025/03/aether-rakuten-mobile-and-rakuten-symphony-collaborate-to-address-key-energy-savings-and-traffic-steering-challenges-for-heterogeneous-mobile-networks/?linkId=100000348042001
7. https://rimedolabs.com/blog/v2x-traffic-management-adv-emergency-cybersecurity/
8. https://rimedolabs.com/blog/es-rapp-control-over-ts-xapp-in-oran/
9. https://www.i14y-lab.com/article/cricac-cross-ric-app-collaboration-for-open-ran-energy-efficiency
10. https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3413
11. O-RAN WG3, “ Near-Real-time RAN Intelligent Controller; E2 Service Model (E2SM), RAN Control”, ORAN.WG3.TS.E2SM-RC-R004-v08.00, Jun 2025
12. https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3400
13. ETSI, „5G; NR; Radio Resource Control (RRC); Protocol specification”, ETSI TS 138 331 V15.3.0, Oct 2018
14. A. Akman, P. Oliver, M. Jones, P. Tehrani, M. Hoffmann and J. Li, „Energy Saving and Traffic Steering Use Case and Testing by O-RAN RIC xApp/rApp Multi-vendor Interoperability,” 2024 IEEE 100th Vehicular Technology Conference (VTC2024-Fall), Washington, DC, USA, 2024, pp. 1-6, doi: 10.1109/VTC2024-Fall63153.2024.10757839

Author Bio