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

« Evolution of a CSP into a DSP | Main | vRAN Progression in 5G Part-2 »

vRAN Progression in 5G Part-1

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

 

At MWC Barcelona 2019, more than 90% of demonstrations and use case conceptualizations were around 5G. The emergence of 5G unlocks significant disruption in the radio access network (RAN) space on top of the existing 4G LTE networks, thanks to non-standalone mode dual-connectivity architecture. However, a key application is the potential to move RAN to the cloud in what is called virtualized RAN (vRAN). This 2-part blog shall cover various solution aspects of vRAN with respect to evolving standards and their relevance to the 5G landscape.

 

Evolution of vRAN architecture

The main driver for vRAN is the tremendous savings achieved in operational and capital expenditure for network service providers (NSPs) and network equipment providers (NEPs). But, before examining the pros and cons of vRAN, it is important to understand how vRAN-based architecture has evolved by focusing on RAN components.

 

 

Fig 1: Basic vRAN architecture network

 

A conventional radio access network or base station is comprised of two parts:

 

  1. Baseband unit (BBU) - BBU is the brain of RAN. It runs the complete protocol stack software that is responsible for allocating radio resources to the connected UE (User Equipment) in both downlink and uplink directions. It also controls mobility like basic attach, handover, etc., and exposes connectivity to the backhaul core network for internet access.

 

  1. Radio remote unit (RRU) - The RRU comprises of the actual radio frequency (RF) hardware along with transmitting and receiving antennas. It is responsible for broadcasting the electromagnetic radio signals. RRU is known as the front-haul network for RAN.

 

Traditionally, deploying RAN base stations is a distributed process wherein BBUs and RRUs are physically installed across every cell site. This involves considerable costs to provision and run the hardware. The emergence of 4G led to some improvements as a result of which the BBU could be centralized at one location while RRUs were installed at physical cell sites. Now, the next phase of improvement brought about by 5G involves creating a 'BBU hotel' where a group of BBUs are housed together on a single hardware while exposing multiple ethernet/fibre links to connect to multiple RRUs.

 

The challenge here is the steep cost of the fibre cables that connect to RRUs, which are responsible for transporting data signals using Common Public Radio Interface (CPRI) protocol. Another challenge is supporting the high bandwidth needed for 5G and ensuring low latency (to the tune of tens of milliseconds in 5G) over the current interface.

 

vRAN architecture proposes to move the 'BBU hotel' to centralized data sites using network functions virtualization (NFV) platforms and virtual network function (VNF) software that run on industry-standard silicon like Intel x86, Cavium, Freescale, etc. Such a model can also use optimized servers to scale baseband capabilities as well as AI/ML-based cloud orchestrators to intelligently build high processing capabilities for smart radio resource allocation algorithms.

 

 

Fig 2: Different types of RAN field deployment scenarios

 


 

Upgrading RAN to vRAN architecture and its impact

Typically, a 5G RAN protocol stack shall comprise of L3+ (OAM, RRM, SON, RRC, X2, S1, Ng, Xn), L2+ (PDCP, RLC, MAC) and L1 (physical layer + RF) components and protocols. These components and protocol layers support control plane (CP) as well as user plane (UP) traffic. While the signaling and user plane traffic flows from backhaul to RAN through S1-SCTP and GTP protocol, the fronthaul traffic towards the UE goes over the air (OTA).

In order to maximize the output of vRAN systems, considerable design changes in the RAN architecture are required. 3GPP, the global standards organizations for mobile telephony, has introduced many concepts to address this by defining several split architecture options in RAN. For instance, it has defined the centralized unit (CU) and distributed unit (DU) as two logical entities (see Fig 3). The idea is that all the protocol layers and components that are mounted on the CU can be virtualized using different cloud options. In contrast, all the protocol layers that are mounted on the DU can run at physical sites along with the RRU. CU is further segregated as CU-CP (Centralized Unit Control Plane) hosting signaling plane protocol entities and CU-UP (Centralized Unit User Plane) hosting data plane protocol entities. Another new standard interface, E1 has been defined as an interface between CU-CP and CU-UP which is SCTP based protocol in-line with existing interfaces (S1/X2 etc.). Moreover, both the CU and DU are connected through a standard F1 interface with F1-C and F1-U acting as control and user plane interfaces. F1 interface is also SCTP based for transport.

 

Fig 3: DU/CU-level segregation in RAN

 

The whole idea of having a centralized unit is to run most of the non-real-time processes that may not require strict latency timelines. Therefore, the radio resource manager (RRM), which is responsible for dynamically allocating common and dedicated radio resources to the UE along with admission and bearer control functionalities, can run its resource allocation algorithms here. Designers also have the options to use machine learning, artificial intelligence and predictive analytics tools to design the most optimized algorithms for the RRM. For example, the RRM can support the MAC (Medium Access Control) scheduler for allocating the correct resource blocks for a particular UE. It does this by finding the most accurate UE radio conditions within the cell, based on multiple CQI/PMI/RI feedback reports that may use AI-based logics for processing large chunk of reports efficiently. There is a one to many mapping supported between CU and DU where one CU entity (possibly hosted on cloud or virtualized) shall be able to control multiple DU entities (hosted on actual physical cell sites). The size of this mapping shall be driven from multiple factors like software design, physical link used to connect CU-DU as well as hardware & processing capabilities of Linux/DSP/FPGA based platforms hosting these entities.

This concludes the first part of this blog which explained the terminologies and recent augmentations in standards helping to evolve a virtualized RAN solution. The next part shall explain the approaches proposed for vRAN deployment and their challenges.

 


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


Categories