Energy Saving-rApp control over Traffic Steering-xApp

Introduction

Energy consumption is a critical aspect of any service in these modern times. In telecommunications, a flexible approach to network planning, control, and management is extremely beneficial in this aspect. The concept of an open radio access network (O-RAN) enables the creation of algorithms that allow energy saving in a manner independent of the equipment or RAN software solution used. In this blog post, we present an innovative approach to energy saving using the RIC, which is based on the direct cooperation of Traffic Steering xApp (TS-xApp) and Energy Saving rApp (ES-rApp).

Notes:

Traffic Steering xApp (TS-xApp) and Energy Saving rApp (ES-rApp)

TS-xApp is responsible for broadly understood network traffic management. Through the xApp it is possible to achieve one of many goals, such as load balancing, where each node of the network is similarly loaded. The goals (or objectives) can be defined by the operators and the xApp can be controlled with the use of policy delivered from the A1 interface. It is also possible to minimize handovers, delays, separation of services, or minimization of energy consumption. ES-rApp controls the operation of TS-xApp by creating appropriate traffic control policies. The simplest energy-saving situation can be illustrated as a situation when there is a very small load in the network and ES-rApp decides to redirect traffic from one of the cells to the rest of the network. Then, it is possible to turn off (or enable sleep mode) a temporarily redundant cell, which in turn reduces the energy consumed in the network.

Note: The TS-xApp was the winner of the rAppathon RIC application developer competition hosted by VMware and Intel at MWC Barcelona 2023. A panel of expert judges selected the xApp ahead of six other competing applications as the one that delivered the greatest business and network impact, showed the most innovation, and fostered higher levels of sustainability. You can find more about the event and the xApp in the following blog post: Rimedo Labs Integrated the TS-xApp with VMware dRIC

Testbed Setup

The solution was evaluated in a scenario with several distributed units (O-DU) connected to one Central Unit (O-CU) in the O-RAN network. These nodes are connected to the Near-RT RIC, which in turn works with the Non-RT RIC. Two applications are installed in the considered network (see Fig. 1):

  • TS-xApp – which works as an application on top of the Near-RT RIC and through the E2 interface obtains information about cells and network users. In addition, it receives A3 events, on the basis of which (and the operation of the appropriate traffic control algorithm) it makes decisions about the user’s handover between cells. TS-xApp is able to apply policies, which are compliant with ORAN_TrafficSteeringPreference_2.0.0. [1]
  • ES-rApp – which works as an application inside the Non-RT RIC and monitors the necessary metrics through the O1 interface – in this case, the network load. As a result of the implemented algorithm, rApp can generate appropriate traffic control policies and send them to TS-xApp via the A1.
Fig. 1 Coordination of ES-rApp and TS-xApp (Architecture)

About Energy Saving rApp (ES-rApp)

ES-rApp aims at minimizing the overall energy consumption by switching off cells that are not loaded too much, and turning on the cells if the traffic load goes high. At the same time, the performance shall be assured for the remaining users. The rApp operates continuously and monitors the performance of the network by analyzing various parameters (e.g., O-DU Physical Resource Block, PRB usage) via the O1 interface.

When the load is low in some analyzed areas, the algorithm implemented inside the rApp verifies the load of the potential neighboring servers. If the shift of all the users from a given cell is possible (i.e., if the performance requirements of already served users can be guaranteed), it generates the appropriate policy and sends it via the A1 interface using A1-P to the Near-RT-RIC. Near-RT RIC in turn, delivers it to the TS-xApp. In this case, when the traffic increases, the rApp – after denoting this fact – sends a control message to turn on cell/O-RU and then modifies the policy triggering indirectly the Near-RT RIC to allow UEs association with just turned on cell/O-RU.

ES-rApp Testing with TS-xApp

To test the functionality of the proposed ES-rApp, the as-found state of the network was analyzed. Here it is worth noting that the current version of ES-rApp assumes that TS-xApp works with the Load Balancing feature enabled. During the ES-rApp operation, it gets information from the O1 interface about cells available in the network, their type (macro cell or small cell), and the PRB usage of each cell. ES-rApp collects such data during predefined times and calculates average O-DU PRB usage in the time domain. Periodically, the rApp can make decisions about enabling or disabling one of the cells. ES-rApp will enable a cell in case of congestion (high PRB usage) observed in at least one cell that is currently enabled. ES-rApp will disable a cell in case of average PRB usage below some threshold. If none of the situations occurs, the ES-rApp continues observation.

ES-rApp prepares the network for disabling a cell by the creation of a policy. Such policy should be created in such a way that every UE has a preference called „forbid” for the selected cell, and a preference called „shall” for other cells (cells that are not taken into account in terms of switching off cells). As a result, all UEs should be served by different cells (based on received power and different policies) than „forbidden” ones.

ES-rApp after enabling a cell will delete a set of the abovementioned policies, which should affect the possibility of any UEs association to a cell with a particular ID.

In this simulation, the initial high UE number is distributed among all cells (a macro cell and small cells) using the load-balancing feature of TS-xApp. The network state with a high UE number was presented in the form of a map in Fig. 2, and some network parameters in Fig. 3. UEs traffic demand is fulfilled by the network which can be observed in the figure with PRB usage (no congestion).

Fig. 2 Simulation scenario (1 macro site, 4 small cells): All cells ON, high load/user density
Fig. 3 Simulation results for high load scenario (left – PRB usage per cell, right – achieved bitrate per cell)

In the following steps of simulation, the number of UEs decreases. The network state with a low UE number was presented in the form of a map in Fig. 4, and some network parameters in Fig. 5. When the number of UEs is low enough, the ES-rApp decides about turning off small cells. To achieve this, a policy is created and sent through the A1 interface to TS-xApp, and it reflects the forbidden association of any UE to any small cell. The result can be found below – all UEs are connected to the macro cell and their traffic demand is fulfilled.

Fig. 4 Simulated scenario: Small cells – OFF, low load/user density
Fig. 5 Simulation results for low load scenario (left – PRB usage per cell, right – achieved bitrate per cell)

In the case of an increasing number of UEs, ES-rApp removes previously created policy (by DELETE request) which results in reverting the possibility of UE association to any small cell (based on received power and load balancing feature of TS-xApp).

Conclusions

The presented simulation results confirm the possibility of energy saving in the considered network. The application (ES-rApp) operating in Non-RT RIC, through long-term observation of the network load (O1 interface), effectively made decisions to turn off individual cells in the network (via A1 interface). An essential element of the energy-saving system here is the application (TS-xApp) running in the Near-RT RIC, which has a direct impact on the assignment of users to cells (taking into account the policies received via the A1 interface). As a result, it was possible to reduce energy consumption in the analyzed case in the considered network by 30%.

You can watch the explainer video on this use case by VMware here: Energy Savings through Policy Controlled Traffic Steering || ES-rApp and TS-xApp at VMware RIC – YouTube

You can watch the technical video demonstrating this use case here: Energy Saving rApp control over Traffic Steering xApp for Open RAN (Demo) – YouTube

About the plugfest

Rimedo Labs successfully took part in the O-RAN Global PlugFest Spring 2023 in i14y Lab in Berlin. The demonstrations included Rimedo Labs Energy Saving rApp control over Traffic Steering xApp integrated with VMware’s distributed RIC. The conducted tests included A1 policy control, energy-saving and load-balancing features, and coordination between rApp and xApp.

You can find more details about the activity in the following post by VMware: Demonstrating Dynamic Energy Reductions – VMware Telco Cloud Blog

References

[1] O-RAN ALLIANCE WG2, „A1 Interface: Type Definitions, v02.00”

Related Rimedo Labs Resources

Author Bio

Łukasz Kułacz received a Ph.D. in telecommunications from Poznan University of Technology in 2022. He is employed as a research and teaching assistant at PUT’s Institute of Radiocommunications, Poland, and he is an R&D Expert at Rimedo Labs. 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 in the radio resource allocation process improvement. His scientific works are already published in well-recognized international journals like IEEE Access, IEEE Vehicular Magazine, and MDPI Sensors. At Rimedo Labs he leads the R&D team developing xApps/rApps and realizing dedicated software and simulations for the company’s customers.

2 odpowiedzi na “Energy Saving-rApp control over Traffic Steering-xApp”

  1. Which components of RAN are turned off in this scenario? I have a confusion about this because we know in O-RAN we disaggregate the BBU in CU and DU that runs on COTS hardware, so I think there is no need to turn off the components of CU and DU as in traditional RAN we have sleep mode techniques in different components of BBU also go to sleep mode. I think the scenario that you discussed in the video will only turn off the RU.

    • Thanks for your question and comment. In this use case the O-RU is switched off.

      In O-RAN O-CU and O-DU are virtual entities to be run on O-Cloud platform resources. Thus, intelligent management and orchestration of O-CU/O-DU HW and O-Cloud SW platform resources, coordinated by SMO, are required for the sake of EE.

      For this purpose, in O-RAN NES Technical Report, there is also a feature called „O-Cloud Resource Energy Saving Mode”. The aim of this use case is to enable energy savings in the O-Cloud by reducing the power consumption of various O-Cloud components without impairing the network performance. Given the network status, the O Cloud components’ power consumption can be optimized through actions such as adaptive shutdown of hardware, scaling out Network Functions, and optimization of CPU/FPGA power, memory usage, CPU frequency, etc. This use case targets e.g., optimization of workload placement and automated scale-in / scale-out processes help to dynamically adapt the pool of active hardware resources to the actual workload needs and allow to free up HW resources which could be shut down in idle times. However, in our scenario, we are not considering this item.

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.