20 radio access network (RAN) terms to know

The terminologies around radio access network (RAN) technology are exhaustive and sometimes—OK, most of the time—very confusing. Our previous article described the evolution of RAN in mobile networks, culminating in what is today called Cloud RAN. This blog will explain some essential RAN terminologies and acronyms and provide clear and concise descriptions of them.

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

3rd Generation Partnership Project (3GPP)

The very first acronym to be aware of is 3GPP. The 3rd Generation Partnership Project (3GPP) started as a consortium of mobile networking vendors working together to define specifications for mobile networking. This consortium released its first set of specifications (called Release 99, even though it was released in 2000) as part of 3G specifications. Although the group initially formed with 3G in mind (hence the name), it has continued to exist and define specifications for further development and enhancements in mobile communication.

Subsequent 3GPP specification releases were numbered sequentially (starting at Release 4) with Release 18 in progress as of December 2022. It is important to understand that while each release of 3GPP defines specifications and enhancements, the releases are not associated with a specific generation of mobile communication. Also, note that each mobile generation implements features and specifications across multiple releases as the technology matures and features evolve. Hence, the terms 3G, 4G, 5G, and so forth are not directly mapped to but associated with one or more 3GPP releases.

---

Read other articles in this series:

• The road to Cloud RAN from 1G to 5G
• What is Open RAN?
• What does Red Hat OpenShift have to do with Cloud RAN?
• Comparing Red Hat OpenShift models for Cloud RAN deployments

---

RAN disaggregation vs. RAN decomposition

Disaggregation and decomposition may sound similar, but they describe distinct aspects of the next-generation Cloud RAN architecture.

RAN disaggregation refers to the separation of RAN software from specialized hardware, eventually leading to the virtualization of RAN software, thus enabling RAN functions to be hosted on general-purpose, commercial-off-the-shelf (COTS) hardware

In contrast, RAN decomposition describes breaking down RAN's functions into Radio Unit (RU), Distributed Unit (DU), and Central Unit (CU) components. The distribution of the RAN functions across these decomposed components is defined by the RAN functional split option used. RAN functional splits are discussed in the next section.

The figure below captures the contrast between these two concepts.

Image

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

RAN functional split options

RAN decomposition distributes the baseband unit's (BBU's) and remote radio unit's (RRU's) functionality into three separate components: RU, DU, and CU. Multiple options are defined by 3GPP to determine the BBU functions that go into the Radio Unit (RU), Distributed Unit (DU), and Central Unit (CU).

There are eight possible options defined by 3GPP for RAN functional split, simply called "split options," from split option 1 through split option 8. Effectively, these split options refer to where the functions defined by the 5G protocol stack layers—the physical (PHY), media (or medium) access control (MAC), radio link control (RLC), Packet Data Convergence Protocol (PDCP), and Radio Resource Control (RRC) layers—are split between the RU, DU, and CU. The figure below shows split options 1 through 8 defined by 3GPP.

Image

Other standards bodies (such as Small Cell Forum and eCPRI forum) have defined their own split options, which in most cases, align with 3GPP-defined split options. Huber+Suhner's 5G functional split overview diagram is a very good and concise reference for comparing the split options defined by 3GPP, Small Cell Forum, eCPRI, and others.

The split options can be further classified into Higher Layer Split (HLS) and Lower Layer Split (LLS) options.

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

Higher Layer Split (HLS) and Lower Layer Split (LLS)

The split options determine the distribution of the 5G protocol stack (originally implemented by the BBU and RRU) between the RU, DU, and CU. The split that determines the functions between the DU and CU is called Higher Layer Split (HLS), while the Lower Layer Split (LLS) defines the RU and DU responsibilities. You may implement RAN with one or both of these splits.

The following figure shows some examples of split options. Note that using LLS option 8 without HLS is analogous to using traditional remote radio unit (RRU) and BBU, similar to 4G/LTE.

Image

Distributed Unit (DU) and Centralized Unit (CU) 

The terms Distributed Unit (DU) and Centralized Unit (CU) describe a subset of functionalities that BBU previously performed. Despite their names, in real-world deployments, the CU is typically (but not necessarily) placed centrally, and the DU implementation doesn't have to be geographically distributed. The Centralized RAN and Distributed RAN definitions in the next section provide more details about that.

The exact distribution of functions between the DU and CU depends on the split option—specifically, the HLS—that is being implemented. 3GPP has defined multiple options with a recommendation in favor of option 2 for HLS, and therefore it has been adopted as the industry standard. The 3GPP didn't come to consensus on the LLS option, so it was left to the discretion of industry players. The O-RAN Alliance (discussed later) has defined split option 7-2x for LLS, which has become the industry favorite for RU-DU functional splits for traditional cell sites—at least for now.

[Learn more about edge architecture. ]

Centralized and Distributed RAN (C-RAN and D-RAN)

In most 4G RAN deployments, the RAN components (Antenna, RRU, and BBU) were placed near each other at the cell site. Each site was self-contained as a RAN entity (called evolved NodeB, or eNB in 4G jargon) and didn't rely on any central RAN component (such as Radio Network Controller, or RNC, in 3G). This was the only deployment model in initial 4G implementations.

However, in the latter 4G era and now in 5G, the concept of pooling the BBU devices at a central location was introduced. The term Centralized RAN (C-RAN) was coined to represent the deployment model of pooling BBUs at a central location serving multiple cell sites. The earliest use of this term was in 2010 by China Mobile Research Institute, along with some mobile hardware vendors such as Nokia and ZTE. In contrast with C-RAN, the RAN deployment model with the BBU residing at the cell site was labeled as Distributed RAN (D-RAN).

In the C-RAN model, there are still multiple (geographically dispersed) locations for hosting the pooled (and hence Centralized from the perspective of the cell sites they are serving) BBU functions. The C-RAN model also gave birth to the fronthaul network, the network that provides RU-BBU connectivity.

Splitting BBU functions into DU and CU gives a new perspective to the C-RAN definition. In a decomposed RAN, the location of the DU determines whether the deployment can be classified as C-RAN or D-RAN. When the DU is collocated with the RU, it is considered D-RAN, and if the DU is deployed away from the cell site, then it's a C-RAN deployment model. To summarize:

• If both CU and DU are on the cell site: This is a D-RAN deployment, similar to when the BBU is placed at the cell site in traditional 4G LTE scenarios.
• If the CU is at a remote data center but the DU is at the cell site: This is also considered a D-RAN deployment because DU is collocated with the RU.
• If the DU and CU are collocated but implemented in a datacenter away from the cell site: That is considered a C-RAN deployment due to DU being away from RU.
• If the DU and CU are implemented away from the cell site in separate datacenter locations: This is also considered C-RAN with two C-RAN hubs—one to host the DUs (also called a far edge datacenter), the other to host the CUs (also referred to as an edge datacenter).

A visualization of a C-RAN design, where the DU is away from the RU, either with or without a collocated CU, is shown below.

Image

A D-RAN design, where the DU is collocated with the RU, either with or without CU, is shown below.

Image

Open RAN, O-RAN, and OpenRAN

Although O-RAN, Open RAN, and OpenRAN (without the space) are often used in the same context, they are not the same.

Open RAN is the big-picture industry movement that encompasses any RAN solution focused on achieving interoperable RAN components through open interfaces between RU, DU, and CU. This allows operators to break free of vendor lock-in and implement these functions using a diversified set of vendors.

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

To influence the industry towards Open RAN, a consortium of mobile operators formed an industry alliance named O-RAN to define a RAN solution that supports open interfaces between the RAN components. Many networking, mobility, test equipment vendors, and academic institutions have joined the alliance and now collaborate with the operators to collectively achieve a fully open RAN. Today, the term O-RAN refers to the architecture and specifications produced by the O-RAN Alliance.

Another effort towards Open RAN is defined by the Telecom Infra Project (TIP). TIP is a group that includes operators and equipment manufacturers with the sole goal of providing connectivity solutions. When it comes to mobile communication, an open RAN architecture paves the path toward cheaper and more versatile RAN, as well as faster time to market. Hence, TIP started a project group called (confusingly!) OpenRAN (Open RAN but without the space).

OpenRAN is not an alternate approach to O-RAN. Instead, it takes specifications from O-RAN and implementations of RAN functions based on the Cloud Native Container Foundation (CNCF), another organization advocating for software openness, and then evaluates their integration, interoperability, and functional validation.

The following figure shows the relationship between O-RAN, OpenRAN, and Open RAN.

Image

vRAN

One of the initial use cases envisioned by the drive toward network functions virtualization (NFV) was the virtualization of RAN, more specifically BBU, at that time. Virtual BBU (vBBU) never really took off, but with more mature technologies in the 5G era, its decomposed components, DU and CU, are now virtualized. A RAN deployment that uses virtualized CU (vCU) and/or virtualized DU (vDU) is called a vRAN deployment.

Note that the term "virtualization" is used in a generalized manner, referring to both virtualization through virtual machines and virtualization using containers (sometimes called "containerization" to differentiate).

Virtualization of RAN is an orthogonal concept compared to the Centralization of RAN. A vRAN implementation can also be Centralized-RAN (when the vDU is implemented away from the RU, with CU either at the same location as DU or in a different place). Similarly, a vRAN implementation can also be D-RAN with the vDU (and possibly even the vCU) implemented at the cell site, collocated with the RU. We discussed and visualized both of these concepts in the C-RAN and D-RAN section of this article

Cloud RAN

Cloud RAN is an evolution of the vRAN architecture. Though often equated with vRAN, strictly speaking, Cloud RAN implies using vDU and vCU that are implemented in a cloud-native manner. Being cloud native, these vDU and vCU applications are generally implemented using lightweight containers, are well suited for both public and private clouds, and are DevOps friendly through automation and orchestration.

[ How to explain orchestration in plain English ]

Note that Cloud RAN can also be abbreviated as C-RAN, which may be confused with Centralized RAN. However, as explained earlier, the virtualization of RAN and the centralization of its components are two orthogonal and independent concepts. The following figure shows the relationship and overlap (where applicable) between Cloud RAN, vRAN, and traditional RAN.

Image

Common Public Radio Interface (CPRI)

The Common Public Radio Interface (CPRI) is the specification that defines the communication between the RRU and BBU. This specification was needed when RRU was detached from the rest of the radio processing equipment (called the BBU) and moved to the top of the cell tower alongside the antennas. We explained this process in our previous article. Even though major radio equipment vendors got together and agreed on the basic CPRI specifications, the actual implementation of CPRI may be proprietary. Hence you can't expect the RRU from one vendor to work seamlessly with another vendor's BBU due to possible incompatibility between the CRPI implementations the two vendors are using.

CPRI was defined to use constant bit rate (CBR) traffic (a fixed amount of traffic regardless of the traffic load of the radio service), so it consumes a high amount of bandwidth. Different rate options have been defined for CPRI, and depending on the radio signal's bandwidth, the appropriate rate option may be used for CPRI traffic from/to an RRU.

CPRI rate options are specified using numbers and range from 614.4Mbps (rate option 1) to 24.33Gbps (rate option 10). Though not a requirement, given its high (and constant) bandwidth consumption and sensitivity to signal degradation, CPRI is always carried over fiber links.

[ Automating the last mile for consistency and scalability at the edge ]

Radio over Ethernet (RoE)

Radio over Ethernet (RoE) is an effort by engineering organization IEEE to allow CPRI transport over an Ethernet/IP network, as defined by IEEE specification 1914.3. Using Ethernet/IP transport opens the doors for packetized fronthaul networks that could provide the same benefits and feature-richness of traditional backhaul networks.

While RoE was a step towards IP-based fronthaul, it still required a massive amount of bandwidth due to the CBR nature of the CPRI traffic encapsulated within Ethernet headers.

eCPRI

eCPRI is the evolution of the CPRI specifications that enables communication between the RU and BBU/DU using Ethernet or IP encapsulation. As a result, unlike CPRI, eCPRi traffic can be sent over the ubiquitous Ethernet interfaces. As mentioned above, CPRI uses serialized CBR traffic that requires an always-on, high-bandwidth connection between the RU and BBU/DU. However, eCPRI shifts away from CBR communication and sends traffic between the RU and BBU/DU only when there is user data to send.

The eCPRI specification also pushes some radio data processing to the RU by defining its own LLS options, including a sub split to split option 7. Combined, these enhancements reduce the bandwidth required between the RU and BBU/DU and allow for statistical multiplexing across users. Another benefit of eCPRI is the native Ethernet transport without the explicit use of encapsulation technology such as RoE.

Here's a fun fact—no one knows what e in eCPRI stands for, as it was never spelled out in the eCPRI specifications. But seeing as eCPRI was meant to be an evolution or enhancement to the original CPRI specification, the term eCPRI usually refers to evolved CPRI or enhanced CPRI. Both are commonly used and generally accepted industry terminologies. What is not true, however, is to equate eCPRI with Ethernet CPRI!

Similar to CPRI, the eCPRI specifications were agreed upon, but vendor implementations added proprietary features and optimizations, creating the same issue of vendor interoperability between RU and BBU/DU. Industry efforts such as the Open RAN movement tackled this issue, as we will discuss in the next article.

eNodeB (eNB) and gNodeB (gNB)

The term NodeB was introduced in 3G to collectively refer to the RAN components that are collocated at the cell site; more specifically, the antenna and the radio processing equipment. With 4G, the word "evolved" was added to it, making it eNodeB (eNB) to represent a 4G-based cell site. In common terms, eNB can encompass all the components at the cell site—the Antenna, Remote Radio Unit (RRU), and Baseband Unit (BBU).

Another fun fact: It is more technically correct to associate the term eNodeB with Long Term Evolution (LTE), which is the appropriate terminology representing RAN evolution with 4G. But most people don't differentiate between 4G and LTE terminologies, so it's acceptable to call eNB a part of 4G.

With 5G, the same RAN functions may or may not be implemented on the cell site (D-RAN vs. C-RAN). Regardless of where they are located, the collection of these functions is called gNB in 5G. The "g" here represents "next generation," just like the "e" in eNB represents "evolved." A 5G gNB comprises Antenna, Radio Unit (RU), Distributed Unit (DU), and Centralized Unit (CU).

[ Boost security, flexibility, and scale at the edge with Red Hat Enterprise Linux. ]

Wrap up

The "RAN word soup" is a messy collection of acronyms and  terminologies, where each acronym may refer to a protocol specification, a product or a function, a deployment model, or even an industry movement. We hope this article cleared up some concepts and provided a background on common RAN terminologies. Watch for additional articles in this series to continue learning more.

---

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

---