The road to Cloud RAN from 1G to 5G

Cloud radio access network (RAN) is an important enabler in achieving the goals of 5G, the 5th Generation of mobile technology. The terms Cloud RAN, vRAN, and Open RAN are often used interchangeably (and sometimes incorrectly) in the context of 5G. Although all have evolved from previous generations of RAN, they represent different (yet intertwined) attributes of a modern RAN implementation.

[ Check out three Portfolio Architectures for 5G RAN, on-premises, or hyperscaler telecom designs. ]

This article explains the road to Cloud RAN and its relationship with other RAN terminologies used today.

---

Read other articles in this series:

• 20 radio access network (RAN) terms to know
• What is Open RAN?
• What does Red Hat OpenShift have to do with Cloud RAN?
• Comparing Red Hat OpenShift models for Cloud RAN deployments

---

Early RANs

RANs have been an integral part of mobile networks from the very beginning. Even though the first generation of mobile networks (1G) did not define it as an independent entity, the RAN in that era consisted of combinations of base stations (BS) and antennas mounted on cell towers. The following figure shows a typical 1st Generation cellular network.

Image

2G RAN: The base station subsystem

2G introduced the base station subsystem (BSS), comprising the base transceiver station (BTS) and the base station controller (BSC), which evolved into today's RAN.

2G contained the following three domains in a mobile network:

• The mobile call processing and switching functions were deployed at the central sites, which 2G called a mobile core.
• The radio components, dubbed the BSS, comprised a mesh of BTSes (or cell towers) and a BSC for a group of cell towers.
  • Each tower contained two very visible components:
    • The antennas mounted on top of the tower
    • The radio signal processing equipment in a temperature-controlled enclosure at the tower's base
  • BSC introduced a modular, extensible, and scalable RAN architecture to address growing concerns.
    • Collectively, this equipment formed a network that performed all the radio-related functions of the mobile service, such as channel allocation, signal modulation and demodulation, multiplexing, signal processing, and handoff.
• The transport network predominantly comprised serial point-to-point links between the RAN and mobile core.

As the following figure shows, the two main pieces of equipment at the 2G cell tower—the antennae and the radio processing gear—were connected using a coaxial cable that carried the signal from the passive antennas at the top of the tower to the equipment at its base. However, coaxial cable caused attenuation and signal degradation, resulting in suboptimal RAN coverage and performance, an issue that 3G addressed with the introduction of the remote radio head (RRH).

Image

[ Learn more about modernizing 5G operational and business support systems for the cloud. ]

3G RAN: NodeB and RNC

3G formally laid the foundation for RAN by introducing the term NodeB. 3G's NodeB separated the radio unit, which was previously implemented with the radio processing equipment, and moved it as a standalone device to the top of the tower closer to the antennas. This made it remote from the radio equipment at the tower's base.

Aptly referred to as a remote radio unit (RRU) or remote radio head (RRH), this device was connected to the antenna using a short jumper cable. This solved the signal degradation challenge of using a long coaxial cable running the tower's length.

The BTS's other functions were performed by a device called the baseband unit (BBU) residing at the base of the cell tower. The RRU processed the modulated radio signals from the antenna and then passed the baseband (unmodulated) traffic to the BBU, which then processed both control and data traffic.

An optical interface running a protocol called Common Public Radio Interface (CPRI) communicated between RRU and BBU. Another significant change was the shift towards Ethernet-based data networks to carry traffic from cell sites. In early 3G networks, a Layer 2 switch was typically co-located with the BBU at the cell site and provided connectivity between the BBU and the rest of the mobile network.

As the technology evolved, low-end routers replaced this switch at the cell site, thus giving birth to the term cell site router (CSR). CSRs would eventually use multiprotocol label switching (MPLS) virtual private networks (VPNs) (or L3VPN) for backhauling mobile traffic from cell sites to the mobile core. The BSC's functions in 2G (such as call handoff and coordination between cell sites) were performed by the radio network controller (RNC) in 3G. Each RNC managed multiple NodeBs in its region.

The following figure outlines the RAN components and their placement in 3rd Generation mobile networks, including the RRU and the antenna at the top of the tower, the jumper cables between the antenna and the RRU, NodeB components (RRH, fiber, BBU, and CSR), the mobile transport network, RNC, and mobile core.

Image

[ Learn why open source and 5G are a perfect partnership. ]

4G RAN: Introduction to Distributed-RAN and Centralized-RAN

These transitions paved the path for 4G, which brought significant innovations in the mobile core (called Evolved Packet Core, or EPC) and radio technology (referred to as long-term evolution, or simply LTE). A fundamental change from the RAN's perspective was eliminating the RNC as a separate entity and absorbing its role into the BBU. Now, every cell site was a self-contained RAN entity comprising the antenna, RU, and BBU, referred to as an evolved NodeB or eNB.

In the later stages of 4G, virtualization made its way into mobile network equipment and functions, including the virtualization of EPC (vEPC) and BBU. The latter presented an attractive use case when coupled with the possibility of moving BBU functionality away from cell sites and pooling them at a small datacenter called the BBU hotel. It was theoretically attractive to have BBUs for multiple cell sites at a central location, optimizing physical footprint while using BBU virtualization for elasticity and resource pooling. However, there were some practical challenges with centralization of BBU. For example:

• The BBU could not be too far away from cell sites. The CPRI traffic's latency sensitivity allowed for a theoretical maximum of 20km between RRU and BBU. The practical distance would be much less.
• Laying down multiple fiber links from each cell site to the BBU hotel wasn't practical. Each BBU could serve multiple RRUs. Thus, even a three-sector cell site (a very common configuration) will have at least three RRUs and hence would require multiple fiber cables. Techniques such as optical multiplexing could be used, but those introduced additional components to the RAN network.

Despite the challenges, the centralization of BBU did see real-world implementation, albeit severely limited. Owing to the technical difficulties with the real-time processing of the radio signals, the idea of a virtualized BBU did not materialize—not in its original form, at least.

This implementation, where BBUs were centralized in contrast to distributed (BBU on each cell site), introduced the terms Centralized-RAN and Distributed-RAN. Over the years, these terms' definitions have slightly evolved and matured. Another term coined as a result of this was "fronthaul." It contrasted the part of the network between RRU and BBU with the network that provides connectivity from BBU to the mobile core (called backhaul). The topology diagram below shows these concepts:

Image

5G RAN: vRAN and Cloud RAN

5G took these ideas forward and made some adjustments looking to benefit from virtualization across the mobile core and RAN. For instance, instead of hypervisor-based virtualization in the mobile core, it introduced lightweight containers and microservices. Instead of repackaging previously physical functions like the services gateway (SGW) into individual virtual machines, the microservices approach distributed the mobile core into multiple independent containers based on their roles.

Similarly, the BBU functionality was split into separate groups in the RAN. For newer radios, some functionality was moved into the RRU (called RU for simplicity). At the same time, the BBU's other functions were split into the distributed unit (DU) and the centralized unit (CU). This functional split is generally referred to as RAN decomposition.

[ Read Expanding 5G with the 5G Open HyperCore architecture. ]

Although the standardizing bodies (specifically 3GPP) clearly defined and recommended the functionality split between the CU and DU, the distribution of functions between RU and DU was left for the industry to determine. Over the past several years, the industry has gravitated towards the so-called Split Option 7-2x, defined by the O-RAN Alliance for the RU-DU functional split, while using Split Option 2 (defined by the 3GPP) for the CU-DU functional split.

In summary, the real-time functions that processed the CPRI traffic from the RU were kept in the DU, while the latency-tolerant functions were considered fit for the CU. Therefore, the CU part of the BBU was free of the 20km distance limit and eligible to be implemented in a centralized location. This latency restriction, however, still applied to the functions in the DU. Hence, the DU had to be close to (or at) the cell site, just like the BBU.

The resulting architecture now looks like the following:

• The cell sites could comprise just the antenna and RU. DU and CU (collectively forming the BBU) can be on the same site but don't have to be. The RU, DU, and CU collectively comprise the 5G version of NodeB, called gNB.
• The DUs for multiple sites can be pooled within about 20km of these cell sites. The small datacenter hosting these DUs is called the far edge datacenter. These DUs can still be physical devices, but with virtualization and containerization technologies catching up, most vendors and operators lean towards using containerized DUs running on bare-metal servers, commonly referred to as vDUs.
• The CUs can be hosted at the far edge datacenter, but when logically possible, it is more feasible to pool them at a location farther away from the cell site than the DU sites. Thus, the CUs serving multiple cell sites in a given radius could be at the edge datacenter. The edge datacenter materialized the concept of a BBU hotel. These CUs could also be virtualized or containerized applications running on commercial off-the-shelf servers. Given the not-so-strict latency requirements, the virtual implementation of CU (vCU) could also be hosted on a public cloud environment instead of a DC owned by a mobile service operator.

The network between the far edge and edge datacenters (to connect the CU and DU) didn't exist when the BBU was a single entity. To distinguish this network from fronthaul and backhaul, the term midhaul was used. The fronthaul, midhaul, and backhaul networks are collectively called xHaul. Significant consideration and planning are needed to design these networks properly.

A disaggregated and decomposed RAN architecture comprising the RU, DU, and CU in geographically diverse locations is shown in the following figure.

Image

These architectural changes resulted in the following RAN terminologies:

• From a deployment and placement perspective, when the DU and RU are collocated at the cell site, it is referred to as Distributed RAN (D-RAN). In contrast, if the DU moves to a far edge or edge datacenter, the RAN implementation is called centralized RAN (C-RAN). The implementation of RAN functions, specifically the CU and DU, as virtual functions (VMs or containers) running on general-purpose hardware is called virtualized RAN (vRAN).
• When the CU and DU are implemented as cloud-native functions (typically as containers), the deployment is called Cloud RAN.
• Last but not least is O-RAN. This refers to the use of open interfaces between the RAN components (the RU, DU, and CU), as specified by the O-RAN alliance.

These terms are not mutually exclusive. A RAN can be O-RAN-compliant (using open interfaces), Cloud RAN (using cloud-native DU/CU), and D-RAN (DU and RU co-located at the cell site) at the same time. Similarly, an O-RAN-compliant implementation can be deployed using special-purpose hardware (not vRAN). However, O-RAN-compliant Cloud or Virtual RAN is the path the industry is taking.

In short, RAN has evolved significantly over the past several decades across multiple mobile generations leading up to the disaggregated, decomposed Cloud RAN that is quickly becoming the industry norm.

[ Learn how to design a 5G Core platform that scales well. ]

The figure below summarizes fundamental changes and enhancements in RAN across the mobile generations.

Image

The image shows the history of mobile communications, with an emphasis on RAN evolution. It started with 1G in the 1980s by offering analog voice, and 1G's RAN was simply base stations and cells. 2G emerged in the 1990s by providing digital voice with RAN and introducing the concept of BSS. The industry transitioned to 3G in the 2000s offering voice and data, with a RAN infrastructure that separated the BBU and RRH while introducing CPRI and OBSAI for communication between the two. It also introduced the concept of NodeB and RNC. In the 2010s, IP took center stage in 4G mobile networks. 4G RAN enhancements included the evolved NodeB (eNB) and centralized RAN concepts. Today in the 2020s, we are moving forward with 5G networks that use gNodeB with a disaggregated and decomposed RAN.

---

This article originally appeared on the Cloudify{ing}.Network{ing} blog and is republished with permission.