How can Energy Saving and Traffic Steering cooperate in O-RAN?

Recently, Energy Efficiency (EE) has become one of the crucial directions for 5G and beyond developments [1]. One of the possibilities to significantly improve the EE of mobile networks is to dynamically switch cells on/off depending on the network traffic conditions (see: O-RAN Network Energy Saving: Cell Switching On/Off). However, to switch off certain cells, first, the users must be offloaded to the neighboring ones. To achieve this one should utilize a Traffic Steering (TS) algorithm. TS is one of the fundamental mechanisms in 5G networks that allows Mobile Network Operators (MNOs) to distribute network traffic between cells, e.g., to equalize load or separate Quality of Service (QoS) flows. As such, it has been defined by O-RAN ALLIANCE as one of the first use cases to be addressed by xApps (see: Policy-based Traffic Steering xApp implementation within O-RAN) [2]. The algorithms aiming to improve EE are usually implemented as rApps, while TS is typically realized as xApps for non-real-time (RT) for near-RT control loops respectively. The challenge is that the TS-xApp must be notified by the ES-rApp that a certain cell would be switched off to offload users to the neighboring cells, taking into account users’ QoS flows and cell loads. One example of such setup is cooperation between Rimedo ES-rApp, and Rimedo TS-xApp discussed in the post: Energy Saving-rApp control over Traffic Steering-xApp.   

This blog post will discuss two options for notification of the TS-xApp on the Energy Saving (ES) actions from the O-RAN specifications perspective. The first option is to utilize the A1 interface to send policies with a “FORBID” clause for cells that will be switched off, to indicate TS-xApp that users should be removed from these cells. It was presented during O-RAN Global Plugfest Fall 2023 in the setup with Juniper Near-RT RAN Intelligent Controller (RIC) and Keysight RICtest. The second approach is to utilize the E2 interface with its Cell Configuration and Control Service Model (E2SM-CCC). This approach was presented during the RIC Forum in Dallas (26-28 March 2024) organized by the U.S. National Telecommunications and Information Administration (NTIA) and the U.S. Department of Defence (DoD). 

Traffic Steering xApp notification through the A1 policy in the Energy Saving use case

Energy Saving Block diagram of TS xApp notification about the cell On/Off switching through the A1 policy
Figure 1 Block diagram of TS xApp notification about the cell On/Off switching through the A1 policy

In Figure 1 we can see a setup with ES-rApp residing in the Non-RT RIC, and TS-xApp deployed in the Near-RT RIC. The ES-rApp utilizes the O1 interface to switch on/off cells based on the observed Key Performance Indicators (KPIs), e.g., user throughput, power consumption, and Physical Resource Block (PRB) usage. The TS-xApp subscribes to E2SM RAN Control (E2SM-RC) to obtain E2 Node, UE information, and measurement reports [3]. The xApp also obtains cell load (PRB usage) from E2SM KPM [4].  Based on this information, the xApp performs TS actions using E2SM-RC. In this setup, the A1 interface is used to provide TS-xApp with notifications about the cells that are subject to be switched off. This is done by formulating the TSP (Traffic Steering Preference) policy that contains a “FORBID” clause (see A1 interface specification for details [5]) for all cells that ES-rApp decides to switch off. After receiving such a policy, TS-xApp starts moving users to other cells. In the meantime, the ES rApp must monitor the number of RRC connections in these cells, and when they reach zero, it can put them into the ES mode. In the opposite direction, the ES-rApp switches the particular cell on, and once all the procedures are finished, it sends a request to delete the “FORBID” policy through the A1 interface, so that TS-xApp can utilize these cells. The evaluation of this procedure using Rimedo TS-xApp deployed at the commercial RIC and connected to RICtest software will be discussed next. 

Plugfest Fall 2023 demonstration 

One of the Rimedo Labs’ activities during the O-RAN Global PlugFest Fall 2023 was the integration of the TS-xApp with Juniper’s Near-RT RIC and Keysight RICtest as depicted in Figure 2. The Rimedo TS-xApp was deployed within the Juniper Near-RT RIC as a docker container. The RIC was a broker between the xApp and Keysight RICtest, responsible for providing the E2 and A1 interface termination for both REPORT and CONTROL actions. The Keysight RICtest realistically emulated E2-Nodes with message exchange fully compliant with the O-RAN specifications. We used E2SM-RC (version 1.03) to: 

  • Retrieve the RSRP using: E2SM-RC REPORT Style 1 Message Copy 
  • Retrieve the Cell Global Identifier (CGI) and Physical Cell ID (PCI) using: E2SM-RC REPORT Style 3 E2 Node Information Change 
  • Retrieve the UE ID using: E2SM-RC REPORT Style 4 UE Information Change 
  • Control Handovers using: E2SM-RC CONTROL Style 3 Connected Mode Mobility 
Block diagram of the setup with Rimedo Labs TS-xApp, Juniper Near-RT RIC, and Keysight RICtest
Figure 2 Block diagram of the setup with Rimedo Labs TS-xApp, Juniper Near-RT RIC, and Keysight RICtest (source [8]) 

One of the presented test cases was offloading the users from the cell based on the A1 policy, which fits the Traffic Steering xApp notification through the A1 policy described in this blog post. The operation is presented in Figure 3. The left part of the figure presents the per-cell number of connected UEs (RRC connections) and handover statistics before the application of the A1 policy that is intended to offload users from Cell #2. We can see 10 UEs connected to Cell #2, and 2 UEs connected to Cell #4. The state of the system after application of the A1 policy with the ‘FORBID’ clause for Cell #2 is depicted on the right side of Figure 3. We can see that UEs were moved from Cell #2 to Cell #4 which now serves 12 UEs. The green bar at the left side indicates 100% success of initiated handovers. Also, the number of handovers from Cell #2 is being updated and currently showing a value of 9. Finally, the number of sent control messages is increased to 21. This then should result in an O1 message sent to the ES-rApp stating that the cell is empty, and can be switched off.

Keysight RICtest dashboard view before and after the application of the A1 policy
Figure 3 Keysight RICtest dashboard view before and after the application of the A1 policy (source [8]) 

Traffic Steering xApp notification through E2SM-CCC in Energy Saving use case 

Energy Saving Block diagram of TS-xApp notification about the cell on/off switching through the E2SM CCC
Figure 4 Block diagram of TS-xApp notification about the cell on/off switching through the E2SM CCC

The previous sections presented the concept of notification of TS-xApp about ES-rApp cell on/off decisions through the A1 interface. This section discusses a different approach that utilizes the E2 interface. The setup depicted in Figure 4 is similar to the one from Figure 1. The difference is that there is no A1 interface utilized. Instead, the TS xApp subscribes to E2SM-CCC to listen to the changes in the O-CES Management Function [6]. E2SM-CCC allows xApps to both receive reports, of the configuration of a cell or E2-Node or to change this configuration using the so-called Configuration Structures originating from the 3GPP specifications. One such structure dedicated to ES functions is the already mentioned O-CES Management Function. It contains parameters that inform an xApp about the ES features of a given cell [7]: 

  • cesSwitch can be TRUE or FALSE to indicate if the ES features are enabled for a given cell. 
  • energySavingState specifies the ES state of the cell. It can be either “isNotEnergySaving” or “isEnergySaving”. The “isNotEnergySaving” state refers to the standard operation of a cell, with all hardware components being active. The “isEnergySaving” state of the cell indicates that the cell is currently providing ES, and most of its hardware is deactivated. Such a cell cannot serve users. 
  • energySavingControl is used to either initialize (“toBeEnergySaving”) or deactivate (“toBENotEnergySaving”) an ES state for a given cell. 

The “toBeEnergySaving” refers to the transition state from “isNotEnergySaving” to “isEnergySaving,” while the “toBENotEnergySaving” refers to the reversed order transition. While utilizing the E2SM-CCC the TS-xApp receives an indication message whenever any of the O-CES Management Function attributes change, and based on this information, it can offload users from certain cells. In this approach, the ES-rApp doesn’t have to be aware of the TS-xApp. It simply triggers cell deactivation, and TS-xApp receives proper notification through the E2 interface. Then, the TS-xApp moves users from cells that are in the “toBeEnergySaving” state. After all users are removed from the cell, its state can be simply changed to “isEnergySaving” by the E2-Node itself to enable significant ES. When the ES-rApp decides to switch on the cell, the TS xApp waits until the cell state is changed to “isNotEnergySaving” and starts to utilize it for receiving the user traffic.  

The TS-xApp notification through E2SM-CCC has been introduced in Rimedo Labs TS-xApp and demonstrated in a multi-vendor setup during the RIC Forum in Dallas organized by the NTIA and U.S. DoD in March 2024. The setup included Rimedo TS-xApp deployed in Juniper Near-RT RIC, Airhop ES-rApp deployed in Juniper Non-RT RIC, and Keysight RICtest emulating the real 5G network and O-RAN interfaces based on the data provided by the Vodafone. This demonstration will be subject to a separate blog post in the future.


In this blog post, we considered the two approaches for the interworking between the TS-xApp and ES-rApp. 

The first approach with the notification about the Energy Saving action through the A1 interface, is easy to implement because it utilizes general mechanisms of policy-based traffic steering within the TS-xApp. The xApp does not have to be aware of the ES state of cells. Moreover, the decision has a nice top-to-bottom flow, i.e., the ES-rApp decides to switch off the cell and notifies the TS-xApp, which first offloads the cell from existing users and once this is completed, executes its action.  However, the ES-rApp must be aware of the fact that there exists a TS-xApp in the Near-RT RIC that can be driven by A1 policies. This usually requires xApp and rApp vendors to be aware of each other to send proper policies and/or to establish a common signaling flow i.e., the ES-rApp sends policy and waits for TS-xApp to offload cells to proceed with turning off cells. 

The second discussed approach that utilizes E2SM-CCC, allows for interaction between ES-rApp and TS-xApp without them knowing about each other, i.e., both xApp and rApp vendors can independently deploy their App and they will simply interwork. Note that in this approach, the xApp’s traffic steering decisions are somehow affected by the RAN.  

The integration of the Rimedo TS-xApp with Juniper’s Near-RT RIC and Keysight RICtest creates an important milestone toward the practical deployment of O-RAN solutions in terms of strict verification of the TS-xApp against the E2 interface specification.  Under this setup the Rimedo TS-xApp is proven to work with both notification options, either utilizing the A1 policy (as demonstrated during Plugfest Fall 2023) or E2SM-CCC (as demonstrated during RIC Forum 2024). 


[1] M. Hoffmann, M. Dryjanski, “The O-RAN Whitepaper 2023 – Energy Efficiency in O-RAN”, 2023,
[2] O-RAN ALLIANCE, “O-RAN Working Group 1 Use Cases Analysis Report” v13.00, February 202
[3] O-RAN ALLIANCE, “O-RAN Working Group 3 Near-Real-time RAN Intelligent Controller E2 Service Model (E2SM), RAN Control” v01.03, October 2021
[4] O-RAN ALLIANCE, “O-RAN Working Group 3 Near-Real-time RAN Intelligent Controller E2 Service Model (E2SM), KPM”, v02.0, October 2021
[5] O-RAN ALLIANCE, “A1 interface: Type Definitions”, v07.00, February 2024
[6] O-RAN ALLIANCE, “O-RAN Work Group 3 (WG-3) Near-Real-Time RAN Intelligent Controller E2 Service Model (E2SM) Cell Configuration and Control”, February 2024
[7] 3GPP, “TS 28.541; 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Management and orchestration; 5G Network Resource Model (NRM); Stage 2 and stage 3 (Release 18)”, v18.2.0, March 2024
[8] O-RAN ALLIANCE, “Verification of Rimedo Labs Traffic Steering xApp and Juniper Near-RT RIC using Keysight RICTest”, Plugfest Fall, November 2023,

See more on these topics in the following Rimedo’s blogs: 

Author Bio

Marcin Hoffmann is a Senior 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 an 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 involvement in both, national and international research projects. His research interests include utilizing machine learning and location-dependent information for network management. In addition to that Marcin works on massive MIMO and advanced beamforming techniques. His scientific articles are published in the top journals like IEEE Journal on Selected Areas in Communications, IEEE Transactions on Intelligent Transportation Systems, or IEEE Access. 

Add a comment

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna jest chroniona przez reCAPTCHA i Google Politykę Prywatności oraz obowiązują Warunki Korzystania z Usługi.