This blog is for Communication Services professionals to discuss and share perspectives, point of views and best practices around key trending topics.

« vRAN Progression in 5G Part-1 | Main

vRAN Progression in 5G Part-2


vRAN progression in 5G - Is it worth the effort? (PART-2)


This blog, in continuation of first part, further elucidates different standard and non-standard approaches adopted by telecom industry to make vRAN concept a reality. It also touches upon what realistic challenges lie ahead with adoption of multiple line approaches.


Different approaches for 3GPP-defined split RAN


3GPP has defined eight different functional split options, which creates additional distribution of protocol layer options run on the CU and DU. This allows splitting at RRC, PDCP, RLC, MAC, and L1 levels by creating a lower and a higher version of each layer as separate modules. Each of these options have their advantages and disadvantages in terms of bandwidth and latency-related impact.


Higher L1RFOptions in Green are accepted as reference solutions in 5G NROp:1 Split at L3-PDCPLower L1Lower MACFig 1: Functional split diagram


The concept of numerology, introduced in 5G, can support over-the-air latency of as low as 62.5 microseconds. This is the minimal time at the subframe level in 5G compared to 1ms in LTE, which implies it has to be honored at MAC-PHY interface for DL/UL resource allocation of UE by the RAN scheduler. Due to this very low latency, any spilt at lower layer level makes physical layer processing (precoding, channel and layer mapping) and scheduling decisions at MAC very complex. Because of this, the most favored approach is option 2 (see details in Fig 2). This has already been adopted in dual connectivity solutions with PDCP-RLC split. Here, the CU consists of L3+PDCP and the DU consists of the remaining L2+L1+RF modules. Most of the initial 5G commercial deployments across the world have adopted this option currently.



Fig 2: vRAN split option 2 detailed at the protocol stack level



To unlock maximum value from vRAN solutions, many protocol stack developers have adopted different approaches, which are illustrated below.


Benefits and disadvantages of different vRAN options


  • Software and hardware remodeling: This option creates a multi-threaded software model for lower layers (MAC/PHY) where threads are carefully segregated and mounted on compatible kernel versions (RT/non-RT). It is bound to dedicated or shared CPU cores based on the real-time and non-real-time operations to be executed. For example, in a typical MAC layer solution, the MAC-PHY interface thread or resource scheduler thread should be real-time and running on a dedicated core while the MAC-L3 interface thread can be non-real-time which can run on a shared CPU core. This also engenders the need for using kernel RT-enabled patches for such threads or utilizing a data plane development kit (DPDK) with fast-path mechanisms that bypass the kernel to user space transfer of data during user plane packet processing or hyperthreading on x86-based platforms. These options can accelerate the packet-level processing in the lower layers. Any 5G commercial RAN software requires several hardware CPU cores to run the multi-threaded software. Binding the processes/threads to the right affinity and priority is also important for efficient software performance. However, complexity and costs are high to ensure these software and hardware options comply with the above requirements.


  • Entity-level segregation: Some architectures propose a two-level split at the RAN level by introducing an additional entity in between. This is possible by having additional signal processing units (SPUs) that may host the DU components of RLC, MAC and higher L1 based on design and requirements (Fig 3). All L3+PDCP components are run on the CU as virtualized baseband units (vBBUs) that are connected through ethernet to SPU. Further, the SPU is connected to the RRU that hosts lower L1 along with RF and antenna parts, which leverage ethernet connectivity between the nodes. This type of architecture provides latency benefits at the fronthaul interface, which is important when using URLLC-based applications in the future (in 3GPP Rel-16). However, it also requires an extra node to be designed at both hardware and software levels, which can increase cost. Another overhead in this type of arrangement could be connectivity cost between all physical and remote (virtual) nodes which could go considerably high if dark fibre is used to connect them together.



           Fig 3: Addition SPU Approach to Cater RAN Components


Open RAN (O-RAN) impact: Another aspect of segregation comes from O-RAN-defined architecture. This further breaks down RAN into five logical parts and standardizes some of the newly-proposed interfaces with the aim of creating a complete and open (or proprietary agnostic) RAN solution. O-RAN is an initiative by a consortium of companies to create open RAN solutions across interfaces, thereby reducing dependencies on the same vendor for end-to-end solutions. O-RAN defines a RAN intelligent controller (RIC) where real-time and near real-time functions are connected through a defined A1 interface (Fig 4). Most of the AI/ML application-level and L3+(RRM) protocol-level data processing functionalities lie in these two logical entities. Further, near real-time RICs are connected to conventional CU and DU nodes through another proposed interface called E2. O-RAN also advocates having an open white-box fronthaul interface between O-DU (Open Distributed Unit) hosting L2+ entities and O-RU (Open Radio Unit) hosting L1+RF entities. Theoretically, with this kind of standardization, it should be possible for an operator to connect BBUs from one vendor with RRUs from another vendor. However, in reality, these interfaces are connected through a common public radio interface (CPRI) using fibre cables. Most of the time, this option is highly customized according to the L1 design and mount architecture. Thus, standardizing these interfaces can be a real challenge for the O-RAN consortium.


Fig 4: O-RAN Architecture pic


To summarize, implementing virtualized RAN comes with its own challenges as well as benefits. It is most useful as a conventional macro base station solution where baseband units and radio remote units are separate entities. However, the advent of the millimeter waves frequency spectrum with its very low wavelengths that can travel very small distances is enabling most 5G base stations to be designed as dense in-building solutions or small cell (femto/pico) deployments where baseband, radio and antenna units are all integrated into a single box. With such miniature hardware presenting a one-stop solution, the significance of vRAN may diminish. Nevertheless, I believe the evolution of RAN architecture will remain quite dynamic in the near future thanks to innovation in 5G, wireless and virtualization technologies that will simplify complexity and improve performance.






Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter