Doing the splits: How an open RAN is leading to self-organizing networks
The application of artificial intelligence to 5G radio frequency technologies, employing models built using modern machine learning algorithms, is quickly being recognized as the only way to efficiently manage increasingly complex and diverse mobile access infrastructures. The promise of high bandwidth and low latency can only be truly realized using millimeter wave (mmWave) frequencies. However, the dramatic path loss experienced by radio waves in the high band spectrum range results in the need for far more base stations – aka network densification – and the adoption of advanced techniques for boosting antenna efficiencies, such has MIMO and beamforming.?Even then, network planners must continue to support low and mid band spectrum – especially for suburban and rural mobile endpoints or when serving users who have the audacity to reside within or move inside a solid structure, of any kind.
Supporting this intricate web of resources and managing these complex transmission techniques will require continuous innovations in control plane technologies and the ability to dynamically assign compute resources to them. This has meant fundamentally rethinking radio access network (RAN) architectures, how their functional components are deployed, and how these network functions are delivered.
Introducing O-RAN
An Open Radio Access Network (O-RAN) is a totally disaggregated approach to deploying mobile fronthaul and midhaul networks built entirely on cloud native principles. O-RAN is an evolution of the Next Generation RAN (NG-RAN) architecture, first introduced by the GSMA’s 3GPP in their release 15 (5G version 1) technical specification TS 38.401. Formed in 2018 under the auspices of the Linux Foundation and currently touting over 200 member companies, the O-RAN Alliance expands on the scope of the NG-RAN specifications and standards originally outlined by the 3GPP. It was formed through the consolidation of the Cloud RAN Alliance, comprising Chinese vendors and operators, and the xRAN Forum that was primarily made up of Japanese and American companies. This is a hot area and getting hotter as interest in decoupling RAN functions has accelerated, in the last few years, as governments scramble to ensure supplier diversity in their increasingly critical national telecom infrastructures.
TS 38.401 decomposed the LTE Baseband Unit (BBU) into two functional components, a Distributed Unit (DU) and Central Unit (CU). Following control and user plane separation (CUPS) principles we have seen across the communications industry in the last decade, the CU can be further decomposed into CU-CP and CU-UP components. Providing consistent terminology, the antenna arrays downstream of the DUs are called Radio Units (RU). It takes at least one RU, one DU and one CU to make a gNodeB (gNB), but DUs and CUs may be shared across RUs.?This technical reference document broke down the operation of the radio access network into granular functional components and defined open interfaces at select points in the physical (PHY), medium access control (MAC) and packet layer hierarchy. These are described as either lower-layer splits (LLS) or higher-layer splits (HLS).
Generally speaking, a LLS represents the connection between an RU and DU while an HLS is between the DU and CU. Exactly where this division takes place directly dictates the features of each functional element (RU/DU/CU). It will also have a dramatic effect on how these functions are deployed and the infrastructure required to support them, so picking where in the upstream and downstream pipeline to perform the splits is particularly important. Not satisfied with the 10 distinct functional RAN splits defined within the 3GPP standards, the O-RAN Alliance opted for employing an 11th LLS option. Along with selecting option 2 for its higher-level split, it defined an additional lower-level split (7.2x). 7.2x splits the difference (pun intended) between the high PHY (7.2) and low PHY (7.1) layer splits, putting beamforming and port expansion functionality in the RU while leaving the resource element mapper in the DU.
O-RAN lower-layer and higher-layer splits on the downstream pipeline
Employing split 7.2x dramatically simplified the fronthaul interface, better enabling interoperability between RUs and DUs from different suppliers. This interface is being standardized using the enhanced Common Public Radio Interface (eCPRI) protocol, under the guidance of the CPRI Industry Initiative (CII). ?There is also less bandwidth required and higher latency (delay) tolerances between RU and DU than with a 7.1 split. Plus, with real-time beamforming computations embedded in the RU, the DU is better suited for virtualization – an important technical and business goal of O-RAN. Unlike the 7.2 split, however, the resource element mapping functionality resides within the DU, paving the way for applications that can intelligently identify and assign traffic to available spectrum capacity.
Taking control
The question of where and how these applications are deployed is currently getting a lot of attention in both the O-RAN Alliance and within a new initiative that was kicked-off in 2020 by the Open Networking Foundation (ONF).
The goal of the ONF’s SD-RAN project is to take their SDN controller framework – the Open Network Operating System (ONOS) – and develop a reference model for applying it as the Near Real-Time RAN Intelligent Controller (Near-RT RIC), defined within the O-RAN specifications. In the same way that the RU/DU/CU represents the decoupling of the classic baseband unit (BBU), the RIC is opening up the radio resource manager (RRM), which is currently tied to the individual base station hardware and manufacturer. The RIC centralizes RRM functionality withing geographic regions and exposes this intelligence through open interfaces. This allows for independent software vendors to develop unique applications that can holistically apply radio resource logic across a large number of gNBs. It is this approach that is forming the foundation of self-organizing networks (SON) by enabling automation technologies that reduce labor-intensive and error-prone deployment and ongoing optimization of mobile networks.
The Near-RT RIC and Non-RT RIC within the O-RAN architecture
The Near-RT RIC is where classic RRM and advanced SON applications are instantiated. While RRM functions such as handover have been implemented only as part of proprietary monolithic systems, to date, the Near-RT RIC enables any trusted independent software vendor (ISV) or systems integrator to develop these software services. Referred to as xApps or RICAPPs in O-RAN specifications, this is enabled by open applications programming interfaces (APIs) exposing and abstracting every aspect of the RAN operation and standardized deployment infrastructures like ONOS. The ONFs SD-RAN platform is based on the Micro ONOS (μONOS) microservices architecture and is completely cloud native. Along with providing an execution environment for xApps, the RIC includes a Radio-Network Information Base (R-NIB), a granular database which stores the (near) real time connections and subscriber states of the underlying RAN. This information is employed by xApps when making anything from basic RRM decisions to training machine learning models for SON.
Although the Near-RT RIC delivers the most significant functionality, it is supported by a higher-layer Non-Real Time RIC (Non-RT RIC). Part of the O-RAN Service Management and Orchestration (SMO) framework, the Non-RT RIC holds information employed by the Near-RT RIC but, as is probably obvious, is not needed for any near real time decision making processes. This includes things like policy, configuration, and inventory management. Whereas the Near-Real Time RIC must be located at the network edge - alongside CUs or 5G Core (5GC) user plane functions (UPFs) - the Non-Real Time RIC has higher latency tolerances and can be centrally located with 5GC control plane components.
领英推荐
Naturally, subscriber resource management, such as radio resource scheduling and beamforming, require decisions to be made in real time within a control loop of sub 1ms latency. For this reason, there is a need for a third RIC element - a Real Time Control function located within the Distributed Units. Like every other O-RAN function, the Real Time Control component exposes open interfaces, thereby allowing it to be configured by the Near-Real Time RIC. This inherent openness enables network operators to adopt DevOps practices of continuous integration and continuous delivery for even the most low-level logic functions, tuning RF algorithms and mobility functions that were once under the strict control of individual RAN vendors.
Because the Near-RT RIC communicates southbound to the RAN network functions over a common E2 reference interface, the CUs and DUs are often collectively referred to as E2 nodes.?The E2 Application Protocol (E2AP) is a request-response protocol that uses the ITU’s Abstract Syntax Notion One (ASN.1) message structure. For resilience and reliability, it employs the Steam Control Transport Protocol (SCTP), rather than TCP.?The E2AP collects cell or UE-level data and updates the R-NIB, accordingly. Combining that with the policy information, etc. acquired from the Non-RT RIC over the A1 reference interface, the E2AP can publish coarse (cell) for fine grained (UE/subscriber) commands to one or more CU Packet Data Convergence Protocol (PDCP) processes or a DUs Real-Time Control function.
Enter edge compute
For O-RAN to deliver on its promise, it needs the scalable compute resources and dynamic service delivery architectures afforded by cloud infrastructures. These will likely comprise a combination of public and private (hybrid) cloud offerings, with a telco far edge extending multi-access edge compute (MEC) capabilities to support DUs serving the remote units deployed within operator cell sites. While combining RU and DU functionality on closed hardware is optional, for environments where backhaul bandwidth is limited or wireless Integrated Access and Backhaul (IAB) is employed, virtualizing the DU is critical to realizing O-RANs full potential. The standardization of GPUs within commercial-off-the-shelf cloud compute hardware is one factor that will accelerate this development, providing more baseband (PHY-layer) processing power without the need for specialized white boxes or hardware acceleration using proprietary NICs.?
O-RAN components within a telco hybrid compute cloud infrastructure
Applying intelligence
The combination of O-RAN, SD-RAN and edge compute clouds are the enablers for applying the type of ML-based AI that will power 5G new radio deployments and meet the demands of new high bandwidth, low-latency, service offerings. At first, the algorithms employed by the Near-RT RIC and pushed to the DUs Real Time Control component will likely remain non-adaptive in nature, using fixed rulesets with predetermined and well-understood outcomes. However, the adoption of machine learning principles will ultimately be the only way to realize the spectral efficiencies required to meet 5G business goals while delivering on the service expectations of new radio. These ML techniques can fall into the three classic categories:
All three methods are applicable in RAN operation the goal of self-organizing networks. For example, supervised learning may be the optimal solution for RAN algorithms continuously updating layer 1 / layer 2 transmission and connection parameters of the kind being pushed to DUs real time controller. Unsupervised learning is expected to play a role in network optimization at the cell or cell cluster level while reinforcement learning techniques will likely be invaluable for network design.
There are already startups entering the xApp market, developing superior RF control and optimization solutions that are running on 3rd party Near-RT RICs. The platforms, themselves, are completely decoupled from the RAN, delivered by vendors who are not typically associated with supplying core network functions. Those xApp software vendors can build ML-driven algorithms or AI engines that serve not only classic mobile network operators but private 5G enterprise infrastructures supporting ultra-low latency services for industrial automation. And that's really the cherry on top. While there has certainly been pressure at the highest levels of global governments, this is a true testimonial to an emerging open ecosystem where everyone ultimately benefits.?
Disclaimer:
None of the ideas expressed in this blog post are shared, supported, or endorsed in any manner by my employer. Or Baskin Robbins.