The radio access network (RAN) is a critical part of a mobile network as it provides connectivity between end-user devices (like cellphones, computers or any remotely controlled devices) and the rest of a Communication Service Provider's (CSP) core network.
RANs represent significant CAPEX & OPEX (>60% of the overall network expenses), perform intensive and complex processing, and currently are facing rapidly increasing demand as more 5G and edge computing use cases emerge for telco customers.
A typical RAN network is composed of remote cell sites and each of them includes collocated the following three major RAN components:
Until recently, RAN held out in the virtualization process because of its heavy and strict performance requirements. Actually, the RAN cannot be fully virtualized, unlike many other network domains. Antennas and RUs will remain physical and will continue to provide their functionality over dedicated hardware.
However, exactly as network functions virtualization enables CSPs to transform and modernize their core packet network, similar principles and methodologies are now applied to virtualize the most crucial and complicated part of the RAN, the BBU.
Virtualized RAN decouples the software from hardware by virtualizing Network Functions. It uses virtualization technologies like virtual machines or containers to deploy the disaggregated BBU software components (Central and Distributed Units - CUs and DUs), on top of a Kubernetes based cloud-platform over COTS (commercial off-the-shelf) servers.
Virtualized RANs allow CSPs to separate the BBU functions and run them as virtualized network functions on general-purpose Hardware. In this way, the RAN becomes more cost-effective, flexible, agile, scalable, and resource-friendly, making it easier to introduce new features and innovations through regular software updates. Furthermore, it allows getting full advantage of BBU pooling (one BBU to serve many cell sites). Centralization of the BBU processing reduces the equipment required at the cell sites as well as their power, cabling, space, cooling, and maintenance requirements.
The trend toward virtual, containerized, and cloud-native network implementations inspired standardization entities like O-RAN Alliance to specify standards for more intelligent, open, virtual, and fully interoperable “Open RAN” implementations.
“Open RAN” makes the RAN open within all aspects and components, building a modular BBU software stack that operates on commodity hardware, with open and standard north- and south-bound interfaces. This standard-based “Open RAN” architecture enables to mix and match “white box” RAN hardware, meaning that BBU units (CUs and DUs), radio units and remote radio heads can be assembled from any vendor and managed by “Open RAN” software to form a truly interoperable and open “best of breed” RAN.
This way, the underlying hardware layer (radios from vendor A, CUs from vendor B, DUs from vendor C and COTS servers) enables CSPs to select and integrate the best RAN components avoiding vendor-lock at the same time.
On the other hand, “Open RAN” introduces a number of challenges like the integration and ongoing management of a complex multi-vendor RAN, automation of multi-vendor RAN components, accountability for issue resolution and ensuring that network performance is comparable to an optimized single-vendor solution.5G architecture defined by the 3GPP, brings the promise of new and diverse use cases across multiple industries taking advantage of enhanced mobile broadband (eMBB), massive machine type communications (mMTC), and ultra-reliable low latency communications (uRLLC) services defined in the standard.
Either a single-vendor virtualized RAN or a multi-vendor Open RAN implementation enable the disaggregation and integration of RAN components, allowing the flexibility to efficiently accommodate the new 5G use cases. In fact, the ongoing 5G network transformation depends on the virtualization of RAN and increasing demands for a container-based and cloud-native RAN that runs over a common cloud infrastructure and uses common cloud infrastructure management approaches.
However, virtualized RAN is not a panacea. The number of 5G network-configurable parameters will reach the thousands, especially when the orchestration of multiple network slices and beamforming from massive-MIMO antennas are taken into consideration. Manual configuration and optimization will no longer be manageable or cost-efficient and CSPs should rely on RAN Intelligent Controllers (RICs) that will provide the required levels of automation together with AI/ML tools to better control the RAN complexity.
A RAN Intelligent Controller (RIC) is a software-defined component of the RAN architecture that is responsible for controlling, managing and optimizing the radio resources and functions. The RIC is a critical part of the RAN disaggregation strategy, bringing intelligence, agility and programmability to radio access networks. It provides advanced control functionality, which delivers increased efficiency and better radio resource management. These control functionalities leverage analytics and data-driven approaches including advanced ML/AI tools to improve resource management capabilities.
The RIC enables the onboarding of third-party applications (rApps & xApps) that automate and optimize the RAN operations at scale. Use cases include traffic steering, energy efficiency, quality of experience optimization, quality of service-based resource optimization and MIMO optimization.
rApps and xApps are tools to automate the RAN and maximize the radio network’s operational efficiency. rApps are specialized microservices operating on the non-Real-time RIC, usually handling the non-real-time functions that may need more than 1 second to be executed (e.g. may take minutes or hours). Typically, rApps are single-purpose AI/ML applications that provide policy-based guidance for RAN elements and their resources to xApps. For example, an rApp can predict the utilization of every cell in a network in the near future (e.g. next 30’) taking as input the current utilization, the mobility of subscribers, historic patterns, etc.
xApps are hosted on the near Real-time RIC and are targeted for functions running between 10 milliseconds and 1 second, like those focusing on optimizing the radio spectrum efficiency, performing handover actions, etc. Either working independently or together, rApps and xApps provide essential control and management features and functionality.
The RAN can account for 50%-60% of the total network energy consumption for an operator, with the largest part of it (50%) being attributed to the main equipment of a base station (radio unit, baseband unit and main control). To help CSPs address the RAN energy efficiency challenges and meet their sustainability goals, Intracom Telecom has conceived an rApp for intelligent management of 5G cell energy consumption based on Deep Reinforcement Learning (DRL), and driven by Quality of Experience (QoE) as perceived by the end users.
In Deep Reinforcement Learning (DRL) a cognitive agent learns by itself to make optimal decisions in an initially unknown environment, by interacting with it in a trial-and-error fashion. During training, the agent takes random actions to learn which ones will lead to bigger reward. During inference, the agent has already learned what the best actions in each different state are and leverages this knowledge to maximize the reward gathered.
In the context of the specific rApp, a DRL agent is trained to activate the ideal type of power saving mode for each cell, to reduce overall RAN energy consumption, but always under the premise of maintaining the QoE within acceptable levels. In DRL’s terms, the agent is trained to earn bigger reward when minimizing the energy consumed by a cell, and at the same time minimizing the QoE degradations experienced by its subscribers (e.g., SLA violations).
To train the agent, the rApp uses as input several metrics and KPIs from every cell that are indicative of its local traffic and neighbouring conditions, such as:
For example, a cell with low subscriber activity and good coverage overlap with neighbouring cells will be put more easily into a deep power saving mode (e.g., shutdown and handover), as opposed to a busy cell or an isolated cell without much overlap with neighbouring cells.
The outcome of the training process is a DRL model able to determine the ideal power saving action for every different state. While the DRL model is built and maintained centrally in the context of the rApp, its actual use takes place locally and independently on each cell, according to the cell’s current conditions, using the underlying interfaces of the corresponding xApp.
An advantage of the rApp is that it offers the flexibility to the CSP to adapt it to whatever power-saving actions are available on his RAN, without being tightly coupled to a specific RAN implementation. Different RAN implementations may feature different power-saving actions, but the rApp is generalizable enough so that the CSP can configure it with whatever actions are considered most proper or applicable. This abstraction is possible because every power-saving action can be in principle associated with a particular level of QoE, and therefore the rApp decision logic can be trained upon the costs & benefits associated with those actions, without being dependent on the actions per se.
For example, a complete cell shutdown suggests the most energy-efficient mode a cell can be driven into, but can be potentially associated with the largest QoE impact, because of the subsequent handovers, or because of the need to reactivate the cell at the longest possible latency, if handovers are not an option. Conversely, deactivating a few components of the base station (e.g., the RU power amplifier) may incur minimum QoE impact due to the low wakeup latency, but will lead to limited energy gains.
Finally, the rApp is designed to offer flexibility to the CSP to employ differentiated policies on every cell of his network. It allows multiple DRL models to be trained according to different policies (e.g., energy-oriented, QoE-oriented, balanced, etc.), which the CSP may then apply selectively on each cell, depending on its geographical region, time of the day, seasonality, and other criteria. For example, the operator can opt for more energy-oriented DRL models at sparsely populated areas or during quiet periods, or to opt for more QoE-oriented DRL models during busy hours or at dense cells.
To deliver competitive performance on COTS hardware, the virtualized components of RAN, i.e. vCU and vDU, often employ high-performance packet-processing frameworks like DPDK or VPP. These frameworks enable accelerated packet processing, providing high packet rates, deterministic performance, low latency, and zero packet drops, but on the other hand they keep the servers constantly running at a high power-up state, as if the servers are always operating at peak demand. The reason is that DPDK and VPP rely on polling mechanisms to achieve these stringent KPIs, which keep CPUs at the highest utilization at all times, even during idle periods, thus consuming the maximum possible power and elevating operational expense (OpEx).
To overcome the power waste associated with DPDK and VPP virtualized network functions (VNFs) constantly running at a high-power state, even when not necessary, Intracom Telecom has added the frequency feedback loop (FFL) workflow to its NFV-RI™ solution. The FFL uses machine learning to predict VNF traffic levels to enable reduced power usage during light or off-peak traffic periods, without compromising performance. The solution can dynamically adjust the frequencies of CPUs processing DPDK and VPP VNFs according to their incoming load, while helping meet the goal of zero packet drops, in a fully automated way. FFL has a real-time, closed-loop mechanism that adapts the frequency of the cores the VNF is running on to match their actual traffic load, while helping ensure that frequency is high enough to support zero packet drops. This means that VNFs are operating at maximum CPU frequencies during peak hours, and moderate or minimum frequencies during off-peak or light traffic hours.
In several PoCs and demos conducted over the last two years involving a variety of packet-processing VNFs, NFV-RI has demonstrated an impressive potential to reduce the total energy consumed on a COTS server running such functions by 15-35% on average (during a 24-hour period), while maintaining the service level objectives (SLOs) and ensuring zero packet drops. These savings are significant, especially since the solution is entirely transparent to the existing network architecture and operation, and can quickly bring operators closer to their sustainability goals.
The OpenRAN architecture promises great agility and flexibility, but to get the most out of it CSPs must combine it with AI & ML technologies to guarantee optimized operation of the network and energy efficiency, while meeting the performance demands for their subscribers. Intracom Telecom, leveraging the deep expertise in the underlying technologies of telco networking, Network Function Virtualization, Artificial Intelligence & Machine Learning, is in position to offer such advanced solutions and customize them to its CSP’s special needs.