C-RAN – The Architecture dilemma

C-RAN the Architecture dilemma

From the time of its conceptualization, Long Term Evolution (LTE) has been positioned as a distributed and flat architecture whose strength lies in its simplicity. However, it wasn’t long before tech titans started acknowledging the benefits, perhaps even the need, for centralization in the LTE stack even if it violated the initial premise. This is where Cloud RAN, also referred to as C-RAN or Centralized RAN, brings value to the table. Wikipedia defines C-RAN as “[A] centralized, cloud-based architecture for radio access networks that supports 2G, 3G, 4G and future wireless communication standards”. C-RAN comprises centralized baseband units (BBU) and distributed remote radio heads (RRH) connected through high-capacity, low-latency links. Put more succinctly, the C-RAN architecture involves splitting the baseband processing between RRH and BBU functions, preferably running the latter on commodity servers in a virtualized environment with the intent of optimizing cost while offering easily-scalable solutions.

C-RAN the Architecture dilemma

Functional split

The potential benefits of separating RAN components from radio units and centralizing them on general purpose servers has unfolded various architectural and deployment options. This is because the functional split between distributed and centralized functions can be realized at various points in the protocol stack. Some of the possible configurations are depicted below:

C-RAN the Architecture dilemma

There is an array of configurations in between the fully distributed and fully centralized architectures. In one embodiment, only the PHY layer runs on remote radio heads and the remaining L2/L3 components are centralized on BBUs. In another configuration, L2 is split such that L2-Lower, comprising RLC and MAC, is co-located with PHY layer on radio units whereas PDCP and L3 layers are centralized. In yet another configuration, the whole of L2 layer runs on RRH, and L3 and management components are centralized and virtualized on the BBU. Another school of thought is to run time-critical user plane functions on dedicated boards and virtualize the control plane functions since they are relatively tolerant to delay and bitrate fluctuations. Some solutions have also implemented a MAC split where MAC-upper and MAC-lower are hosted on BBU and RRH respectively.

Supporting multiple cells in an eNodeB can also be realized in more than one way. While some implementations could run separate instances of L2 components for each cell, others could have a single instance handling multiple cells.

Besides the split-architecture variations, scalability requirements may also vary. For instance, there is now a need for highly-scalable RAN solutions that can horizontally scale from a single cell to thousands of cells with millions of connected subscribers. Adding capacity to existing cells so as to support a larger number of subscribers/sessions or higher bitrates is another use case. While some operators would expect their networks to automatically scale up as the number of connected or active subscribers grows, others would expect them to scale up and commit additional resources only if there is a need for higher bandwidth and/or throughput regardless of the number of subscribers.

To make it tougher for solution providers, mobile network operators are contemplating bundling of multi-vendor software components together in a single solution (for example, Layer 3 and Layer 2 stacks from different vendors). This not only impacts system integration efforts, but also necessitates the development of RAN components that support open interfaces or offer standard APIs.

Virtualization and cloud computing are proven concepts and are rightfully the obvious choice for solutions seeking flexibility, scalability and cost optimization. Commoditization and virtualization of Radio Access Networks (RANs) is no exception. However, the timing and synchronization requirements for a wireless system are significantly more stringent as compared to a standard web-based or IT solution. It thus becomes imperative to consider the bandwidth and latency requirement for the fronthaul link between BBUs and RRHs, and the real-time processing requirements for virtualized components while designing a C-RAN solution. In addition, the nature and scale of target deployment needs critical analysis before committing to any seemingly best-fit architecture. For instance, while a particular solution may seem appropriate for a commercial or residential setup, it may likely fare badly if deployed in a stadium-type setup.

One-size-fits-all solution

Mobile Network Operators (MNOs) and Mobile Virtual Network Operators (MVNOs) are, for genuine reasons, demanding solutions that support deployment models and meet scalability requirements which were considered unnecessary or impractical not very long ago. All architecture variants have their own pros and cons and each one may seem to be fit in a particular use case.

Needless to say, network equipment manufacturers and solution providers are struggling to develop bespoke solutions to cater to widely-varying deployment needs and business cases of customers. Hence, they now see a compelling reason to come up with a one-size-fits-all solution, or at the very least, a flexible and programmable architecture that can enable them to quickly deliver RAN solutions meeting specific needs with minimal rework and effort.

In my next blog, we will explore these architectural options in greater detail.

 

Leave a Reply

Your email address will not be published. Required fields are marked *