5G NR Channel Widths and Carrier Aggregation

To boost the peak rates and overall cell capacity, 3GPP defined wider channels for 5G NR, ranging from 5 MHz to as wide as 400 MHz, depending on the frequency range used. For sub-7 GHz bands, also known as Frequency Range 1 (FR1), channel widths can be between 5 MHz and 100 MHz.⁵ Channel widths of 50 MHz through 400 MHz are specified for the bands above 24 GHz, known as Frequency Range 2 (FR2).⁶

Not every combination of subcarrier spacing and channel width is supported by 3GPP specifications. For example, 15 KHz subcarrier spacing can be used in channels 5–50 MHz wide but is not supported with wider channels. Moreover, subcarrier spacings of 15 KHz and 30 KHz are not supported in FR2 at all, due to significantly different propagation characteristics of mmWave, as was mentioned in Chapter 2, “Anatomy of Mobile Communication Networks.” Subcarrier spacings of 15 KHz and 30 KHz, with their longer OFDM symbol duration, are effective in combating inter-symbol interference in macrocells covering large areas but would make transceivers unnecessarily complex and expensive in mmWave bands. A comprehensive list of supported subcarrier spacings and channel widths is defined in 3GPP’s “5G; NR; User Equipment radio transmission and reception.”^{7, 8}

Besides the wider channels definition in NR, the width of the guard bands is also optimized, providing a slight increase in the number of usable subcarriers in each channel compared to LTE. For example, a 20 MHz channel with 15 KHz spacing in NR can have 1272 subcarriers, versus 1200 subcarriers in the same 20 MHz LTE channel.⁹ Each of these subcarriers is organized in sets of 12, forming a resource block. Resource blocks were briefly introduced in Chapter 3, “Mobile Networks Today,” but unlike LTE, resource blocks in NR are not defined as a number of subcarriers per subframe. Instead, 5G NR defines a resource block as just 12 OFDMA subcarriers, without relation to time. This allows more flexible use of resource blocks within a slot, as was described in the previous section. Figure 5-2 shows a high-level view of 12 OFDMA subcarriers to a resource block mapping and multiples of resource blocks in a single NR channel. For example, there are 106 resource blocks in a 20 MHz NR channel.¹⁰

When a bandwidth of an individual channel is not sufficient, up to 16 channels can be aggregated using the carrier aggregation (CA) technique, just like in LTE. Individual channels become component carriers in a larger, aggregated channel, also shown in Figure 5-2. To be part of an aggregated channel, component carriers do not need to be consecutive and could belong to different frequency bands. Resulting aggregated channels in CA provide significantly more resource blocks to schedule transmissions, thereby allowing higher data rates for individual mobile devices. The total amount of resulting aggregated bandwidth is dependent on frequency range and subcarrier spacing, as well as the mobile device class.^{11, 12} In a best possible scenario, an LTE-Advanced subscriber can achieve almost 4 Gbps peak data rate using eight MIMO layers and five aggregated channels.¹³ NR, in turn, can offer almost 600 Mbps over a single 100 MHz channel with a single MIMO layer. With 400 MHz channels from the bands above 7 GHz, a single MIMO layer transmission can offer more than 2 Gbps peak data rates.¹⁴ Peak data rates for an individual subscriber can greatly exceed IMT-2020’s requirement of 20 Gbps with 4×4 or 8×8 MIMO and CA.

Beyond Orthogonal Frequency-Division Multiple Access

The work to enhance radio transmission efficiency does not stop with OFDMA. Multiple vendors and academia continue their research on Non-Orthogonal Multiple Access (NOMA) techniques in hopes of adopting it in fifth- or sixth-generation mobile networks. NOMA was introduced under different names in a number of different studies, including LTE releases.¹⁵ As the name implies, NOMA does not rely on orthogonal subcarriers; instead, it leverages interference cancellation techniques at the receiver. In simple terms, a receiver detects one, typically stronger, transmission, constituting a single layer from a composite signal. Once the stronger signal is retrieved, its original form is reconstructed and subtracted or cancelled out from the composite transmission, thereby revealing a weaker signal.¹⁶ Implementing NOMA is challenging but could provide some increase in spectral efficiency. Although the gain in efficiency is moderate, amplified by a high number of layers in multi-user MIMO transmissions, it can provide significant benefits for future air interface implementations.

Active Antennas

Strictly speaking, an antenna is passive hardware designed to emit and receive radio waves. In its simplest form, it is just a piece of wire forming a dipole antenna. Since the early days of mobile communication networks, antennas have undergone phenomenal transformations, and today’s advanced antennas look very different from those simple pieces of wire used a century ago. The ever-increasing demands for efficiency, speed, and reliability of radio communications led to many innovations and ingenious solutions in those recognizable elements of modern life—antennas.

Antennas today are extremely sophisticated pieces of hardware. Virtually all installations today have antennas and radio heads (a.k.a. RRUs) mounted in close proximity on the radio towers, avoiding long spans of RF cables and associated energy losses. Nevertheless, RRUs and antennas are still connected with multiple RF jumper cables. These external cables are susceptible to environmental degradation, introduce losses, and are cumbersome to maintain, especially with a higher number of MIMO layers used in today’s systems. Eliminating these jumpers and putting RRUs inside the antenna enclosure created what is known today as an active antenna. Use of active antennas dramatically reduces the number of cables needed, making installation simpler, cleaner, and less prone to wear and tear. Figure 5-3 depicts a comparison between a passive and active antenna.

Beamforming

Early attempts to adjust antenna radiation patterns without the use of bulky reflector hardware have led to beamforming and null-forming techniques, which facilitate dynamically adjusting the antenna radiation patterns and reusing the frequency spectrum with high efficiency. Coordinated use of beamforming and null-forming by neighboring base stations significantly reduces interference, thereby allowing many individual subscribers to enjoy high data rates. Beamforming is one of the fundamental features empowering 5G NR radio access technology.

Antennas used in today’s radio access are collections of fancy-shaped elements, intricately arranged into patterns inside the antenna’s radio-transparent enclosure called a radome. Nevertheless, the foundational principles of today’s advanced antennas operation are not overly complicated—everything starts with a dipole. The radiation pattern of a simple vertically installed dipole antenna has a donut shape with radio waves propagating in all directions except vertical (although, in the real world, radio waves may scatter in the vertical direction, albeit greatly attenuated). A typical mobile antenna used in previous generation networks had a number of dipole elements, all connected in parallel to a single antenna port. An RF signal from a BBU’s radio transceiver would be radiated by the dipoles, each forming a donut-shaped electromagnetic field around them. The composite signal of multiple dipoles and the steel plate behind them shape the signal, redirecting it perpendicular to this plate and the column of dipoles, effectively forming a horizontal beam. It is said that an antenna has gain in a particular direction. This simple process helps divert otherwise wasted energy in the desired direction, while shielding the space behind the antenna from the unwanted interference. More technically, this beam is called the main lobe of an antenna radiation pattern, and its width is determined by the number, shape, and relative positioning of individual antenna elements. An antenna with many elements can form quite a narrow beam, but unfortunately the narrower the main lobe is, the more complex-shaped side lobes are created at the same time. Radio engineers and antenna designers seek for an optimal balance in antenna radiation patterns, creating a variety of antennas for different implementation scenarios. Figure 5-4 shows an example of a sector antenna with a column of short dipoles, with side and top views of a combined radiation pattern.

Popular antenna design features a vertical column of dipoles, redirecting otherwise wasted energy into a vertically focused beam, while covering a whole sector horizontally. These antennas with narrowly focused beams have to be tilted downward to ensure strong signal reception throughout the cell. Instead of mechanical tilting, the antennas once again rely upon the effect of constructive and destructive interference of radio waves emitted by closely placed antenna elements. Each of these antenna elements is connected to an individual analog phase-shifting device that delays the RF signal by a carefully selected, miniscule amount of time to influence the resulting radio waves’ interference peaks and troughs position in space. In simple terms, the effect of shifting phases for individual antenna elements is the tilt of the radiation pattern in the vertical direction and is displayed in Figure 5-5.

The amount of a phase shift for each antenna element can be adjusted, allowing for a change in the vertical direction, and is commonly referred to as an electric tilt. It is important to note that the whole column of antenna elements is fed by a single RF circuit, which is sometimes also called RF chain. Although the RF chain shown in Figure 5-5 primarily refers to a transmitter, a typical RF chain is composed of both the transmitter and receiver.

The electric tilt is just a way to adjust the vertical angle of an antenna radiation pattern or, more technically, to control the antenna’s gain in the vertical direction. It is also sometimes called analog beamforming, as it steers the beam in a downward direction with the use of analog phase shifters. The use of analog phase shifters, instead of mechanical tilting, might sound like a complex solution for a simple task, but in reality, the phase shifters are rather simple inexpensive devices, usually controlled by a stepped DC motor inside the antenna enclosure.¹⁷ The amount of tilt is typically controlled through the BBU, via a special tilt control circuit on the antenna. Analog beamforming allows for tilting the antenna radiation pattern with great precision post-installation, without touching the antenna physically.

Analog beamforming was instrumental in improving overall energy efficiency of the radio interface, but it provided little utility to segregate different users or user groups. Indeed, the beams formed by most legacy LTE antennas are vertically narrow, but they still have horizontally wide radiation patterns, thereby illuminating the whole sector. As a result, all mobile devices within the sector have to share the limited number of resource blocks assigned to the base station, thus limiting the transmission data rates. In order to achieve a higher reuse of frequency, or rather resource blocks within a sector, 5G NR technology uses more advanced three-dimensional beamforming (3D beamforming) technology.

3D beamforming relies on the same principle of using multiple elements to form the beam, but this time the beams are formed by two-dimensional arrays, or planar arrays, of antenna elements. With the right spacing between antenna elements, it is possible to create a beam narrow in both the vertical and horizontal dimensions. By applying different phase shifts to the antenna elements in such a planar array, the resulting beam can be steered both vertically and horizontally, while illuminating only a small part of the sector occupied by one or more target mobile devices. By controlling the antenna gain and allowing steering in both the vertical and horizontal directions, 3D beamforming allows more independent transmissions using the same frequency, thus providing higher cell capacity and higher data rates. Figure 5-6 provides a simplified view of 3D beamforming.

Antennas supporting beamforming sometimes are also referred to as beamformers. A typical beamformer is a planar antenna with many elements organized in columns and rows. In an ideal scenario, 3D beamforming can be implemented with all individual antenna elements connected to independent RF chains. These RF chains allow each element to act as an independent antenna transmitting the same signal with different phase shifts. The amount of a phase shift for each antenna element is controlled digitally and applied in their respective RF chains. This is in contrast to analog beamforming, where a single RF chain is used to feed multiple antenna elements while the phase shifts are applied by analog circuits. This beamforming technique is called digital beamforming, which offers great precision in beam width and direction and allow beams to follow individual subscribers.

Unfortunately, controlling dozens or hundreds of antenna elements with individual radio chains is often not feasible and might also be cost prohibitive in the case of mmWave bands. Therefore, for a more practical approach, hybrid beamforming is more commonly used. Hybrid beamforming combines analog beamforming to steer beams in vertical direction, while horizontal steering is achieved via digitally controlled phase shifts applied by individual RF chains. In this scenario, an antenna is divided into a number of different vertical subarrays of antenna elements, which might have different, preset vertical tilts. Each subarray, in turn, is controlled by an independent RF chain. A few subarrays with the same vertical tilt are used to create a beam, which can be dynamically steered in a horizontal direction, illuminating a particular spot in the sector, covering a single or a cluster of mobile devices. When the beams are narrow enough and the side lobes of a particular beam do not interfere with other mobile devices, it is possible to reuse OFDMA subcarriers within a single sector for multiple transmissions at once. Figure 5-7 shows different beamformers.

Hybrid beamforming is a cost-effective yet flexible solution for 3D beamforming. Individual mobile devices as well as base stations use special reference signals for sounding purposes, thus probing which beams within the sector are most optimal for a transmission. Sounding signals are transmitted every few dozens of milliseconds over each beam, and based on the feedback from the sounding signal, a mobile device can be switched to another beam, if appropriate.

Massive Multiple Input Multiple Output (mMIMO)

Fundamental for 5G radio technology is the principle of multiple simultaneous data transmissions using the same carrier frequency, known as multiple input multiple output (MIMO), the basics of which were covered in Chapter 3. MIMO technology has been instrumental in increasing spectral efficiency and boosting peak data rates for individual subscribers as well as the entire cell capacity in previous generation mobile networks. 4×4 and 8×8 MIMO systems are commonly used in LTE systems, yet increasing the order of MIMO beyond these numbers is not straightforward. The path to densification of spatial multiplexing collides with the size limitations imposed on the handheld mobile devices. Specifically, the limiting factor is how many antennas can be packed into a single mobile device. Antennas cannot be miniaturized infinitely, and the distance between multiple antennas is determined by the carrier frequency and, therefore, cannot be arbitrary. This limits the number of parallel transmissions in the case of single-user MIMO. Nevertheless, when many mobile devices are served by a cell, it is possible to apply the principles of MIMO and multiplex data streams belonging to different subscribers using the same frequency. This approach is called multi-user MIMO (MU-MIMO), and it helps to significantly increase cell capacity as well as improve data rates for multiple subscribers simultaneously.

MU-MIMO is not limited by the size of an individual mobile device; hence, more antennas can be used at the base station to further increase the order of spatial multiplexing of data streams for different subscribers. When a MU-MIMO system uses a large number of antennas at the base station and more than one antenna is used to communicate with a single antenna at the mobile device, such a system is called massive MIMO (mMIMO).¹⁸ However, there are many other definitions of mMIMO systems used by industry engineers. These definitions might focus on various aspects of technology but, as a rule of thumb, a system with 16 or more independent antennas, each one connected to a respective individual RF chain, is considered a mMIMO system.

Strictly speaking, a mMIMO system can be constructed in many ways (for example, a line of antennas distributed over the roof of a building or even stretched over multiple building roofs). As long as all these antennas illuminate a single sector and are part of the same base station, this would be a mMIMO system. In reality, however, the most common mMIMO implementation is based on planar beamformers with many antenna elements. Use of beamformers in mMIMO systems is so popular that sometimes beamforming is used as a synonym for mMIMO, which, of course, is not technically accurate. Beamforming is just one of the applications of a mMIMO system.

Interestingly enough, modern beamformers (both analog and hybrid) use a clever technique to conserve precious space on the cell tower by reducing antenna size. This technique leverages the electromagnetic phenomenon of polarization, where electric and magnetic fields oscillate in a specific direction. Two polarized radio waves are said to be cross-polarized and do not interfere when their respective electric and magnetic fields oscillate in orthogonal directions. When two antenna elements are cross-polarized, they emit radio waves with little to no interference. Thus, these antenna elements can be placed one behind the other, effectively squeezing two antennas into one.

One important consideration of MIMO transmissions using hybrid and digital beamforming techniques should be noted here. As was explained in Chapter 3, the concept of MIMO transmission is the use of different spatially diverse paths to transmit multiple data streams, with each distinct data stream representing a separate MIMO layer. In digital and hybrid beamforming techniques, however, multiple RF chains are used to form a single beam, and all these RF chains transmit, in fact, the same data. Therefore, the number of independent MIMO layers offered by hybrid and digital beamformers is not equal to the number of RF chains. This can be further exemplified by the antennas shown in Figure 5-8, which shows 4×4 MIMO (often called 4T4R to signify the transmit and receive RF chains respectively) and 16×16 (also called 16T16R) mMIMO antennas.

The legacy 4T4R MIMO antenna shown in Figure 5-8 is used as a four-layer MIMO system—2× columns, 2× different polarizations, creating a total of four independent antennas. Each of these four antennas is connected to an individual RF chain and may transmit or receive distinct data streams. On the other hand, the 16T16R mMIMO antenna shown in the same figure is a hybrid beamformer. In this particular example, the antenna is organized into vertical subarrays of four antenna elements each. There are eight subarrays of each polarization, with a total of 16 independent subarrays. Each subarray relies on analog phase shifters to achieve downward tilt and is connected to an individual RF chain. The total number of RF chains required to drive this antenna is 16, defining its 16T16R mode of operation. However, to implement horizontal beam steering using this antenna, a few individual RF chains, connected to subarrays of the same polarization in a single row, have to transmit the same data, applying various phase shifts digitally. Hence, in the case of four subarrays used in horizontal beam steering, this particular organization of the 16T16R beamformer can offer four independent MIMO layers.

It is possible to use the same beamformer with wider horizontal beams and less precision in horizontal steering by reducing the number of RF chains for each beam to only two. This way, the same antenna can provide up to eight independent MIMO layers. The number of RF chains and MIMO layers is critical for proper radio access network dimensioning. Chapter 10, “Designing and Implementing 5G Network Architecture,” covers the topic of xHaul dimensioning in greater detail.

Some obvious benefits of mMIMO application in 5G networks include improved spectral efficiency, faster and more robust transmission, and energy efficiency among others. On the flip side, it can be challenging to implement with FDD, due to the lack of channel reciprocity, as explained in Chapter 2. Also, it might be expensive and hard to build mMIMO systems in mmWave bands.

Multi-Radio Connectivity

Strictly speaking, the transmission of subscriber data over multiple radios is not a new 5G feature. Ever since the introduction of MIMO, multiple radios are being used to transmit data over spatially diverse paths, but such transmissions normally utilize radios residing on the same cell site/tower and connected to the same BBU. Similarly, the carrier aggregation technique relies on multiple radios, and although it is possible to leverage remote radio units (RRUs) placed on different towers, these have to belong to the same eNodeB or, its 5G equivalent, gNodeB. In other words, there is only one RF scheduler, controlling the allocation of resource blocks over the air interface for a given mobile device.

Another example of multi-radio connectivity introduced in LTE Release 11 is Coordinated Multi-Point (CoMP) transmission.¹⁹ Substantial interference from the neighboring cells near the cell borders is always a serious challenge for mobile radio engineers and is traditionally addressed by using appropriate frequency reuse patterns. Restrictive frequency reuse patterns help to mitigate interference problems but dramatically reduce spectral efficiency. As explained in Chapter 3, LTE networks allowed moving away from strict allocations of frequencies in the whole cell by dividing cells into inner and outer parts. The same frequency channels can be used in the inner parts of the neighboring cells, yet the outer parts still have to follow stringent rules of frequency reuse patterns. One of the goals of the CoMP transmission technique is to solve this challenge. CoMP defines various scenarios ranging from coordination only within a single site, mainly between multiple sectors of the same eNB, to coordination between neighboring cells, which could be a combination of either macro-macro or macro-pico cells.

The basis of CoMP technology is the coordinated scheduling of radio resources used by neighboring radios or, in 3GPP terminology, transmission points (TPs). Multiple TPs can be represented by a collection of RRUs, which can be controlled by the same or different eNBs. In the latter case, the scheduling information must be exchanged over the X2 interface to achieve the desired cooperation across eNBs. Nevertheless, all coordinated transmissions are considered by the mobile device as if they are controlled by a single RF scheduler.

A few different approaches to implement radio resource scheduling by multiple TPs are defined under the CoMP umbrella:

• Joint transmission: Multiple TPs can send the same symbols on the same frequency, for the same subscriber, and if coordinated properly, can greatly improve signal quality received by a mobile device. However, such coherent joint transmission requires very accurate coordination and, thus, is very sensitive to the latency between participating TPs and/or eNBs.

• Coordinated scheduling/coordinated beamforming: Neighboring TPs coordinate scheduling of transmissions using certain beams, where respective low-gain radiation pattern (null) points in the direction of subscriber, attached to a neighboring cell, participating in coordination. The benefit of using this approach is increased spectral efficiency, and it can also be combined with the joint transmission method.

• Dynamic point selection: A transmission point sending the data to the subscriber can change every subframe, with one TP used at a time. Dynamic point selection enables reacting to quickly changing transmission conditions by changing the transmission point, thus improving overall reliability.

Figure 5-9 illustrates these CoMP approaches.

CoMP transmission is an effective way to improve signal quality, reliability, and data rates at the edges of cells and in picocells within macrocells. CoMP techniques can be instrumental in improving signal robustness in 5G URLLC scenarios, preventing potential signal dropouts in complex industrial environments involving mission-critical applications of M2M communications. On the other hand, CoMP techniques impose tight latency and reliability requirements on backhaul for inter-eNBs/gNBs coordination. It is considered that CoMP relies on an ideal backhaul and hence can greatly benefit from C-RAN architectures, where BBUs are co-located and have virtually no latency between them. Application of CoMP in 5G networks is an area of active research among 3GPP members.²⁰

Dual connectivity is another form of multi-radio connectivity that was introduced for LTE in 3GPP Release 12. This approach was further generalized and expanded in Releases 15 and 16 and called Multi-Radio Dual Connectivity (MR-DC).²¹ Unlike CoMP, where coordination and scheduling happen using a single RF scheduler, MR-DC involves higher layers of 5G protocol stack (more details on 5G protocol stack are covered in the upcoming sections), allowing RF schedulers to operate independently in two participating RAN nodes, such as eNB or gNB, which allows operation in non-ideal backhaul environments. However, this connectivity model requires mobile devices to support simultaneous communications with two separate eNBs/gNBs.

It is anticipated that current large mobile network deployments will coexist with 5G networks for quite some time and will require well-defined procedures to transition from previous generation to 5G network. Some of these deployment challenges can be addressed through the use of standalone (SA) and non-standalone (NSA) 5G deployments, where 5G NR can communicate with the previous generation packet core—Evolved Packet Core (EPC).

MR-DC can operate in such heterogeneous environments and use:

• en-gNB: A 5G NR RAN node, which is capable of establishing user-plane communication with EPC and works as a secondary node with the control plane established over the X2 interface via the main eNB.

• ng-eNB: An LTE RAN node, which can establish control- and user-plane communication with 5G Core. These nodes also establish communication with gNB nodes over 5G’s Xn interface.

MR-DC defines two roles for RAN nodes: master node (MN) and secondary node (SN). MN is responsible for all regular tasks of a typical eNB or gNB in a single connectivity deployment; that is, it establishes both control- and data-plane connections with the mobile core, controls data transfers, and schedules radio resources. Additionally, MN establishes a control-plane connection with the SN over the X2 interface in the case of eNB—or its equivalent, Xn interface, in the case of gNB. The secondary node also establishes a user-plane connection with the mobile core, allowing both the MN and SN to schedule their own radio resources separately, through the use of respective radio bearers. However, 3GPP defines another way of delivering user data, through the use of a split bearer. This mechanism allows the bearer to be terminated at the MN, while pooling the radio resources of both the MN and SN. The user data stream is then split between the MN and SN and is transported over the X2/Xn interface between these two RAN nodes. The use of split bearers can result in a significant amount of user-plane data exchanged over X2/Xn interfaces.

A number of different permutations for dual connectivity are specified by 3GPP, such as whether RAN nodes connect to 5G Core or to legacy EPC, if a gNB or an eNB is a master node, and what is being used as a secondary node. Figure 5-10 shows a few options of using MR-DC with EPC and 5G Core (5GC) network.

It is important to note that carrier aggregation can be used along with MR-DC connectivity options; however, the number of component carriers aggregated over two cells or cell groups cannot exceed 32, which is defined as the maximum number of component carriers in 5G NR.²²

Dynamic Spectrum Sharing

Transition to a newer radio access technology is always a challenging and complex endeavor. Thanks to 5G NR capabilities to communicate with EPC, it is possible to implement gradual deployment of 5G NR technology. Yet, this provides little relief to the spectrum repurposing aspect of this transition.

Spectrum repurposing, or reallocation of bands and frequencies from older to newer radio access technology, can be complicated, especially in the areas of high traffic. In a simple and direct approach, the newer radio access technology uses a separate set of frequencies, when coexisting with the older technology. Although it might be a feasible approach to deploy 5G NR using high bands, as these are not used by LTE, it requires much more planning when low and mid bands have to be reused. The low- and mid-band frequencies are typically a very scarce resource, as these provide the sweet spot between capacity and optimal propagation. Providing 5G radios with their own set of mid- and low-band channels typically requires carving those channels out of current LTE allocations. This task requires careful resource planning by radio engineers, as it is not easy to find an optimal balance between 5G and 4G resources. Repurposing spectrum statically could result in an imbalance, where the previous generation users might not get enough RF resources, while resources assigned to another radio access technology are wasted in the absence of a substantial number of subscribers.

Dynamic spectrum sharing (DSS) helps to avoid such suboptimal scenarios and offers flexible distribution of radio resources, adjusting to the fluid ratio between 5G and 4G subscribers in a cell.

DSS leverages the fact that both LTE and NR use OFDM and can be deployed with the same subcarrier frequency spacing and symbol duration. In fact, NR was designed with such interoperability in mind. In DSS setup, LTE and NR radio nodes, serving the same cell, rely on coordination between their radio resource schedulers, such that resource blocks belonging to the same channel can be used by one of these radios, as needed. This allows the use of the same channel on both radios, without subdividing for hard allocations to a particular radio: NR or LTE.

DSS is an area of active research in 3GPP.²³ Most current deployments rely on a proprietary interface between the eNB and gNB for scheduler coordination, thus limiting the choice of RAN node vendors to match those already deployed.²⁴

Vehicle-to-Everything Communication

Originally introduced as an LTE study item, Cellular Vehicle-to-Everything, or C-V2X, became a standard in Release 14 and was adopted for 5G NR implementations in Release 16.^{25, 26} C-V2X communication is aimed at providing additional communication channels between vehicles, and between vehicles and other road users as well as parts of road infrastructure.

C-V2X uses a concept of a sidelink, effectively turning a vehicle into a RAN node by extending connection from nearby eNB/gNB to other mobile devices. It is also possible for a single vehicle to coordinate direct communications between a group of vehicles, thus creating a mesh of direct interconnections, enabling robust communication between multiple vehicles and a network.

The Vehicle-to-Everything communication approach encompasses a number of different use cases: Vehicle-to-Network (V2N), Vehicle-to-Vehicle (V2V), Vehicle-to-Infrastructure (V2I), and Vehicle-to-Pedestrian (V2P). Vehicles communicating with each other and with the road infrastructure may coordinate different parameters, such as speed, lane selection, and even path, based on dynamic conditions on the road. Such communication and coordination make transportation much more effective and safer, especially in the case of self-driving cars. New safety features, such as “Do not pass warning,” can be a result of V2V communication, warning a driver or a self-driving car about the upcoming traffic on non-divided highways.²⁷ All these features require strict coordination and impose new and stringent requirements on the underlying transport network, addressed by the implementation of URLLC-type services. C-V2X communications can also improve safety of pedestrians by warning nearby cars about their presence, complementing obstacle-detection systems currently adopted by some vehicles.

C-V2X communications standards and implementations are still in their infancy, but this is an area of active research and growth. It is anticipated that vehicular communications become a widely adopted phenomenon and enable future innovations in transportation.

Centralized, Cloud, and Virtualized RAN

Network Functions Virtualization (NFV) was initially proposed in 2012 (around the same time as 3GPP Release 11) by a consortium of service providers as a solution for cost and complexities associated with vendor-locked hardware.³⁰ The solution proposed through NFV was to decouple the hardware and software layers and, by using virtualization techniques, remove the vendor lock-in for devices performing network functions. Dynamic scalability, deployment velocity, and easy upgradability through use of orchestration and automation tools were also among the goals of NFV.

General-purpose compute functions were first to be virtualized and decoupled with hardware. Soon after, new networking startups started offering virtual networking functions (VNFs) for various networking roles such as firewall, NAT, and route reflectors. These initial VNF implementations were predominantly focused on functions that relied heavily on software processes; however, the functions that had more dependency on the hardware took longer to be virtualized. BBU functions were also considered for virtualization and dubbed virtual BBU (vBBU).

New RAN equipment vendors such as Altiostar, COTS hardware vendors such as Dell, and silicon providers such as Intel partnered to offer vBBU solutions. Though it was demonstrated that vBBU would offer many benefits over specialized hardware, it was not commonly deployed as a single VNF but rather split into two RAN components—the distributed unit (DU) and the centralized unit (CU), which are discussed in detail in the next section.

The effort to drive RAN architecture toward the use of software-based, virtualized RAN components was given the name Virtual RAN (vRAN). The vRAN architectures gained industry momentum around the time when virtualization of applications was often equated with a transition to cloud-based environment. This perception led to the terms Virtual RAN and Cloud RAN being used interchangeably. Some vendors preferred the term Cloud RAN, whereas others opted to use vRAN terminology. More recently, however, a clear distinction has started to emerge between the two terminologies and the underlying architecture they represent. Virtual RAN (vRAN) now refers to the generic drive towards the use of software-based RAN components instead of physical hardware such as the BBU. On the other hand, Cloud RAN is now considered a subset of vRAN where the software-based RAN components are designed to be cloud-native. Later sections of this chapter will expand on the characteristics of cloud-native applications.

Note that the term Cloud RAN can also be abbreviated as C-RAN, which can easily be confused with Centralized RAN. Due to the similar abbreviations, and a lack of clear definitions, casual industry observers sometimes use the terms Centralized RAN and Cloud RAN interchangeably, which is not accurate. Centralized RAN refers to an architecture where the BBU or its decomposed RAN components (that is, the CU and DU) are moved away from the cell site and placed in one or more central locations. Cloud RAN, as mentioned above, is a subset of vRAN, and refers to an implementation where the RAN components are virtualized to be cloud-native. The virtualized RAN components (whether for vRAN or Cloud RAN) are referred to as virtualized CU (vCU) and virtualized DU (vDU), and could be placed at the cell site (that is, a D-RAN architecture) or in one or more DCs (that is, a Centralized RAN architecture).

It is helpful to think of Distributed/Centralized and Virtual/Cloud RAN architectures as orthogonal dimensions. Distributed or centralized RAN deployments could use physical RAN components (for example, a BBU or CU and DU appliance) or software-based RAN components (that is, a vRAN or Cloud RAN deployment). As mentioned previously, the software-based RAN components are usually decomposed into a vCU and vDU. Similarly, a vRAN deployment (including Cloud RAN deployment) could use a Distributed RAN model (where RAN components are distributed across Cell Sites) or a Centralized RAN model (where RAN components, that is, the CU and/or DU are placed in one or more Data Centers).

This book will use the term vRAN when referring to the architecture pertaining to software-based RAN components, which implicitly covers Cloud-RAN as well. The terms Centralized RAN and Cloud RAN will not be abbreviated from this point on to avoid any confusion. The term decomposed RAN will be used to refer to splitting of BBU into a CU and DU, which may or may not be virtualized and may be placed at the cell site, remotely at a data center, or a combination of the two. The placement of decomposed RAN components is discussed in the next section.

Virtualized RAN (vRAN) Architecture

A BBU performs a lot of specialized digital signal processing, converting radio traffic from RU into IP, and vice versa. The functions performed by BBU could be classified into two broad categories—real-time and non-real-time. Real-time functions would include scheduling, interference coordination, precoding MIMO and beamforming, modulation, and error correction, while non-real-time functions include bearer configuration, connection management, subscriber handovers, data encryption, header compression, and various operations, administration, and maintenance (OAM) tasks. In short, BBU tasks associated with direct traffic processing and forwarding are considered real-time functions, whereas management and control-related functions would classify as non-real-time.

Redesigning a BBU with functions split across two separate entities based on task classification made it easier for BBU to be virtualized. This was further supported by the performance improvements of available COTS hardware. The real-time functions are grouped in the DU, whereas the non-real-time functions were grouped in the CU. The decomposed vRAN architecture, that is, the virtualized CU and DU, is quickly becoming the go-to solution for new RAN deployments.

Given that the DU would be required to perform most real-time functions, it needs to be placed close to the cell sites to ensure low-latency communications with the RRU. Hence, the DUs should be hosted at the far edges of a mobile communication network, closer to the cell sites. The data center hosting the DU functions, depending on the number of cell sites it services, could be composed of just a few servers connected to the aggregation routers or a few racks of equipment. In a vRAN architecture, this DC is referred to as a far-edge data center. The transport network connecting the cell sites and the far-edge DC is still called the fronthaul, with CPRI-based RU to DU communications that could use either packet-based or WDM-based transport, as previously described in Chapter 3. Newer RAN components may use an enhanced version of CPRI, called eCPRI, which is discussed later in this chapter. As such, a fronthaul network might need to carry both CPRI and eCPRI traffic.

CU, on the other hand, is responsible for non-real-time functions and could tolerate higher latency compared to the RU-DU connectivity. So even though CU is part of the RAN infrastructure, it can be placed further from the RU compared to the DU. The CUs could be pooled in edge data centers that are placed farther away from the cell sites in comparison with a far-edge DC, but still much closer than a traditional centralized DC. The network that connects the CUs to DUs is called the midhaul. The umbrella term xHaul, which was previously used for a combination of backhaul and fronthaul networks in Centralized RAN, is also used to refer to midhaul. Figure 5-11 shows the traditional D-RAN, present-day Centralized RAN, and the next generation vRAN architectures and their corresponding xHaul domains.

Table 5-1 outlines the latency requirements and typical distance allowed for fronthaul, midhaul, and backhaul networks.^{31, 32}

* These numbers are guidelines by various standard bodies. Exact latency tolerance between RAN components should be provided by the equipment vendor and must be validated in test labs before deployment.

An xHaul implementation in vRAN can use any combination of fronthaul, midhaul, and backhaul networks, depending on the placement of the CU and DU relative to the RU. For instance, the DU and CU can both be co-located, but away from the cell site, in which case only a fronthaul network exists between the RU and the data center hosting the DU and CU. In other instances, the DU might be placed at the cell site with the RU. In this case, the fronthaul is collapsed within the cell site, while a midhaul network connects the cell site to the CU hosted in the edge DC. Another example of a co-located RU and DU is the Active Antenna System for mmWave bands, where the DU is integrated into the RU and antenna panel. This allows all real-time functions to be performed at the cell site, thus eliminating the need for a fronthaul network. Lastly, deploying the physical or virtual BBU, or its decomposed components (DU and CU), at the cell sites results in a traditional D-RAN-like architecture with a backhaul network connecting the cell site containing both the DU and CU to the 5G Core network. Figure 5-12 illustrates these various deployment models.

When a transformation to vRAN is being planned, there might be instances where a C-RAN hub could be rebranded as either an edge or far-edge DC, depending on its location and distance from existing or newly installed cell sites. In other cases, as cellular networks and cell sites continue to grow, there may be a need for new data centers. In a vRAN environment, edge DCs are typically fewer in number than far-edge DCs and, thus, CUs located in these edge DCs may provide services to cell sites over a larger geographical area. The edge DCs also tend to be larger than far-edge DCs, resembling a traditional data center spine-leaf architecture, and could be used to house additional components, not just the CU. There typically is a one-to-many relationship between the CUs and DUs, and both these functions are part of the 5G base station, known as gNodeB (gNB).

gNodeB

NodeB in 3G and evolved NodeB (eNodeB or eNB) in 4G LTE have been responsible for terminating the subscriber’s air interface and performing baseband traffic processing. In 5G networks, this functionality is performed by a gNodeB (gNB), short for next-generation NodeB, where n is simply omitted for better readability. There are fundamental architectural differences between the gNB and its predecessors, most notable being the decomposition of BBU functions. Next Generation RAN (NG-RAN) architecture, originally introduced in 3GPP Release 14 and refined in subsequent releases, conceptualizes the gNB architecture where the functions of BBU are split into the centralized unit (CU) and distributed unit (DU). 3GPP Release 15 officially named these functions the gNB-CU and the gNB-DU.

As per 3GPP specifications, a gNB can contain one gNB-CU and one or more gNB-DUs. 3GPP does not limit the number of DUs in a gNB but rather leaves it up to individual deployments. The number of gNB-DUs in a gNB is typically a derivative of processing capabilities and resources available on the gNB-CU.

The DUs connect to the CU using an F1 interface, while the CU connects to the 5G Core using NG interfaces, which is a collective name given to interfaces from 5G RAN to 5G Core. Various NG interfaces are discussed in the “5G Core Network” section.

An Xn-C interface, equivalent of an X2 interface in 4G LTE, is used for connectivity between gNBs and terminates on the gNB-CU. It must be reiterated that all these interfaces, like other 3GPP-defined interfaces, are logical in nature and use the underlying network infrastructure to establish connectivity.

For better scale and more granular separation of functions, the gNB-CU can be further decomposed into gNB-CU-CP (control plane) and gNB-CU-UP (user plane). The gNB-CU-CP is primarily responsible for control and management tasks of the gNB-CU’s functions, such as selecting the appropriate gNB-CU-UP for user data and establishing an F1 interface connection between the gNB-CU-UP and gNB-DU. On the other hand, gNB-CU-UP transports user data between the gNB-DU and gNB-CU and provides functions aimed at improving data speed, efficiency, and reliability through data retransmission in case of radio link outage, status reporting, and redundant data discarding.

A gNB-CU can consist of a single gNB-CU-CP instance and one or more gNB-CU-UP instance(s), thus allowing both the control and user planes to scale and operate independently of each other. The gNB-CU-CP and its corresponding gNB-CU-UPs communicate through the E1 interface. The F1 interface between the DU and CU is subdivided into F1-Control Plane (F1-CP) and F1-User Plane (F1-UP) to provide connection from gNB-DU to gNB-CU-CP and gNB-CU-UP, respectively. A gNB-DU could connect to a single gNB-CU-CP and one or multiple gNB-CU-UPs, as long as all those gNB-CU-UPs are managed by the same gNB-CU-CP. Figure 5-13 provides an overview of these various gNB components and interfaces.³⁴

Together, the gNB-DU and the gNB-CU (along with the RRU) make up the gNB in the Next Generation RAN (NG-RAN) architecture. However, exactly how the BBU functions are split between the CU and DU has been a topic of intense discussion in various standardization bodies and organizations. As these splits have significant implications on the overall network architecture, the next section will discuss the various BBU functional split options across the RU, DU, and CU.

5G Protocol Stack Overview

The 5G protocol stack consists of three layers, which can be loosely correlated, though not directly mapped, with the bottom three layers of the OSI model.^{35, 36} Layers in the 5G protocol stack are mostly similar to those in 4G, but the tasks performed at each layer have been enhanced and new functions added to support 5G services. As shown in Figure 5-14, the lowest layer of the 5G protocol stack is called the physical layer (PHY). Layer 2 is further subdivided into the Media Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP), and Service Data Adaptation Protocol (SDAP) layers. The Radio Resource Control (RRC) and IP encapsulated PDCP frames make up Layer 3 of the 5G protocol stack.

The physical layer (PHY) performs functions such as upstream and downstream link adaptation, modulation and encoding, signal power adjustment, and assisting user equipment in initial cell search and signal acquisition. The physical layer defines the frame format based on the FDD or TDD duplexing schema and the use of appropriate encoding—OFDMA in the downlink and SC-FDMA for the uplink—which have previously been discussed in detail. The physical layer is responsible for assisting in advanced antenna functions such as MIMO layer processing, beamforming, and transmission diversity management.³⁷

The MAC layer, which is a sub-layer of Layer 2, is responsible for scheduling, prioritizing, multiplexing, and demultiplexing data to and from the mobile devices. 5G’s MAC layer has also been enhanced to support additional physical layer features such as beamforming and transmission diversity. Data integrity verification and error correction through retransmissions or Forward Error Correction (FEC) are also done at the MAC layer.

The RLC layer, also part of Layer 2, is primarily responsible for segmentation, reassembly, and buffering of protocol data units (PDUs). In certain modes of operation, the RLC sub-layer might require acknowledgment of receipt from the remote device, thereby adding transmission overhead but providing additional capabilities such as duplicate traffic detection and protocol-level error correction.³⁸

The third sub-layer within Layer 2, the PDCP layer, is responsible for the actual data transmission for both the control-plane and user-plane traffic over the radio bearers. This sub-layer also provides data security and integrity through encryption as well as header compression and duplicate traffic detection. The PDCP sub-layer may customize processing for various 5G service types (for example, header compression and decompression may not be implemented for URLLC services to reduce latency).

In 4G LTE implementation, traffic from the PDCP sub-layer is passed on as IP data to the packet core. 5G specifications, however, add another sub-layer called SDAP in the protocol stack. SDAP’s sole purpose is to build upon the existing QoS capabilities. It provides QoS for user-plane traffic by mapping a traffic flow to a radio bearer based on its requirements.³⁹ Layer 3 of the 5G protocol stack is the RRC layer, which is primarily focused on management function and does not explicitly participate in traffic forwarding. RRC is responsible for establishing, maintaining, and releasing radio bearers (both signaling and data bearers). Mobility functions such as mobile device handover and cell-selection functions are managed by the RRC layer as well. RRC also closes the feedback loop with the PHY layer by analyzing measurements of radio signals and ensuring appropriate resources are allocated on the air interface.

Based on the tasks and functions performed by each individual layer, it is easy to infer that lower layers such as physical, MAC, and RLC are responsible for more real-time functions, such as encoding, scheduling, segmentation, and reassembly, that require near constant communication with the RRU. On the other hand, the higher layers—PDCP, SDAP, and RRC—are involved with non-real-time tasks such as data compression, encryption, and configuration management.

This clear distinction forms the basis of the CU-DU functional splits, where the real-time functions (performed by lower layers, that is, PHY, MAC, and RLC) are delegated to the DU, whereas the non-real-time functions of the PDCP and upper layers are assigned to the CU. Given the complexities of the tasks performed by the BBU and the closed nature of the RAN ecosystem, more variations in functional splits were introduced for both the high and low layer split, as explored in the next section.

Split Options

RAN has historically been a closed, proprietary system where RAN equipment vendors would engineer their products as they see fit. There is widespread agreement among standard bodies, equipment vendors, and mobile network operators regarding the benefits of a decomposed vRAN architecture and the need for CU and DU functional split, but there are also different opinions on how to split the BBU functionality between the two. Given the complexities of the tasks performed by the BBU and the closed nature of the RAN ecosystem, 3GPP defined multiple split options in Release 14. This allowed the RAN equipment vendors the flexibility to implement the BBU functional split based on their individual product architecture, while still adhering to the 3GPP specifications. These split options, aptly named Options 1 through 8, provide a possibility to split the BBU functionality into CU and DU at every individual layer in the 5G protocol stack and, in some cases, within the layer itself, as shown in Figure 5-15. It’s worth noting that some split options, such as Options 2, 3, and 7, have multiple sub-split options; however, Figure 5-15 shows only the sub-splits for Option 7, which is more commonly used in the industry.⁴⁰

The BBU functionality is split between the CU and DU based on the split option chosen by the RAN equipment manufacturer. Each of the split options represents a deliberate decision on how processing will be distributed between the CU and DU. If more processing is done on the DU, less processing is needed on the CU, and vice versa. The distribution of functions between the two (that is, the choice of split option) also determines the bandwidth required between the CU and DU. A brief description and typical uses of each split option are mentioned in the list that follows:⁴¹

• Split Option 8: PHY–RF Layer Split: This is not a new split option but rather a formalization of the traditional deployment where the RF processing is done on the RU, while 5G protocol stack processing is performed at a centralized location in the BBU. Option 8 continues to use CPRI transport between the RRU and BBU and is already used in Centralized RAN deployments. This option requires very high amounts of bandwidth across the fronthaul network and has strict latency requirements between the RRU and BBU, limiting the maximum distance to 20 km or less.

• Split Option 7: Intra-PHY Layer Split: This option splits the PHY layer functionality between the DU and CU. Option 7 defines even more granular split choices within the PHY layer called Options 7-1, 7-2, and 7-3. Each of these split options defines a list of PHY layer tasks, such as encoding, modulation, MIMO, and beamforming processing, to be divided between the DU and CU. 3GPP allows the use of different sub-options in uplink and downlink directions for added efficiency. For instance, Option 7-1 or 7-2 could be used for uplink, and at the same time Option 7-3 could be used for downlink. Using any of these split options greatly reduces the bandwidth between the DU and CU, but does not relax latency restrictions between the two. Option 7, along with Option 6, is one of the favored split options by 3GPP.

• Split Option 6: MAC–PHY Layer Split: This is where all MAC and higher layer functions reside in the CU, while PHY layer functions are delegated to the DU. Option 6 further reduces the bandwidth requirements between the CU and DU but does not offer much in terms of relaxing latency requirements.

• Split Option 5: Intra-MAC Layer Split: This option splits the functions performed by the MAC layer into High MAC and Low MAC. CU performs the High MAC functions, such as centralized scheduling and intercell interference coordination, along with RLC and PDCP functions, whereas DU performs the Low MAC, PHY, and RF functions. Option 5 relaxes the latency requirements between the CU and DU, thus allowing longer distances, but is more complex to implement and thus not favored over Split Options 6 and 7.

• Split Option 4: RLC–MAC Layer Split: This option delegates the functions of the RLC, PDCP, and RRC layers to the CU, whereas the DU performs the MAC and lower-layer functions. Option 4 is not used, as it does not offer any discernible advantages over other split options.

• Split Option 3: Intra-RLC Layer Split: This option further divides the RLC layer functions of segmentation, reassembling, buffering, and error correction into High RLC and Low RLC. In this split option, the High RLC, PDCP, and RRC functions reside in the CU, whereas the Low RLC, MAC, PHY, and RF functions reside in the DU.

• Split Option 2: PDCP–RLC Layer Split: This option has been recommended by 3GPP for standardizing the CU–DU split. Using Option 2, the PDCP and RRC layers reside in the CU, whereas the DU performs the functions of the RLC and lower layers. The functionality offered by this split option has previously been finalized in 4G LTE, and, thus, it makes Option 2 much more feasible for standardization with marginal incremental efforts. Option 2 offers much lower bandwidth as compared to its lower-layer counterparts as well as much better latency tolerance between the CU and DU. Option 2 has become the industry standard for implementing the so-called Higher Layer Split (HLS) between the CU and DU. More details on HLS and its counterpart, the Lower Layer Split (LLS), is covered in the next section.

• Split Option 1: RRC–PDCP Layer Split: This option is also allowed by 3GPP. In this split option, only the RRC functions are implemented in the CU while the rest of the functions of the 5G protocol stack are performed by the DU. If implemented, this option results in a complex and bulky DU and thus is typically not used.

Single vs. Dual Split Architecture

The split options can be grouped into two categories: Options 1 and 2 map to the non-real-time functions and are classified as Higher Layer Splits (HLS), while Options 3 through 8, which map to real-time functions, are called Lower Layer Splits (LLS).

In a typical 5G MCN deployment, both the HLS and LLS options are utilized simultaneously, resulting in disaggregating the BBU into the DU and CU, as well as offloading some of the functionality to the RU—all working together to implement a decomposed, virtualized RAN architecture. HLS is used to implement the CU functions, whereas one of the LLS options is used to further disaggregate the functions of lower layers between the DU and RU. For instance, if the RAN equipment vendor chooses to implement HLS Option 2 for CU and LLS Option 6 for DU, then:

• The CU must implement the PDCP and RRC layer functions.

• The DU must implement the MAC and RLC layer functions.

• The RU must implement the PHY layer functions.

Consequently, if Option 7 is used for the DU, which is an intra-PHY split, then the RU must implement some of the PHY functionality, while the DU implements the rest of PHY layer functions, along with the MAC and RLC functions. In other words, depending on the LLS option used, the RU now needs to perform additional processing of the RF signal before sending it over to the DU. The same is true in the reverse direction. The use of dual split options is also documented in the IEEE 1914.1 standards. Figure 5-16 shows various single split and dual split architecture scenarios.

Allowing the DU to offload some of its functionality to the RU through an LLS option serves a few purposes. First, it provides the RAN equipment vendor with the flexibility to distribute the real-time functions of the BBU between the RU and DU as they see fit. Second, offloading some of the DU functions to the RU reduces the bandwidth required in the fronthaul network. Lastly, certain LLS options may be better suited for the latency-sensitive nature of communication between the RU and DU. On the flip side, moving too much processing on the RU may make it bulkier, power-hungry, and more susceptible to overheating. The RUs are typically external, pole-mounted devices, where such changes in the hardware form factor could be undesirable. The key is therefore to choose an LLS option that is best suited to provide an optimal balance between too much or too little processing on the RU. To that end, Options 8 and 7 have emerged as the frontrunners of industry adoption and have also been the focus of standardization by various industry bodies.

Choosing a Suitable Split Option

While 3GPP has standardized the use of Option 2 for HLS, it did not definitively recommend a specific LLS option.⁴² Over the past few years, Option 7 has emerged as the frontrunner of various standardization efforts. To a lesser degree, Option 6 is also discussed, but rarely, if ever, considered for implementation. To better appreciate the feasibility of Option 7, one must recall that Option 8 still uses CPRI traffic, which requires massive amounts of bandwidth in the fronthaul network.

CPRI is uncompressed, digitized RF data and uses constant bitrate (CBR) traffic; that is, the signal is continually transmitted at a predetermined bitrate regardless of whether there is user data present. The amount of traffic carried over a single CPRI interface depends upon the CPRI rate option used to meet RF design. Over the years, as more spectrum is unlocked and wider channels allowed more bandwidth and capacity, higher bitrate CPRI options have been introduced. Both the RU and BBU/DU must agree on one of these CPRI rate options to establish connectivity between the two. These rate options are a measure of the line bitrate supported by CPRI implementation and must not be confused with the BBU functional split options that define how the BBU functionality is split between the CU and DU. The CPRI rate options, as defined in the CPRI specifications, are as follows:⁴³

• CPRI Rate Option 1: 614.4Mbps

• CPRI Rate Option 2: 1228.8Mbps (1.22 Gbps)

• CPRI Rate Option 3: 2457.6Mbps (2.45 Gbps)

• CPRI Rate Option 4: 3072.0Mbps (3.07 Gbps)

• CPRI Rate Option 5: 4915.2Mbps (4.91 Gbps)

• CPRI Rate Option 6: 6144.0Mbps (6.14 Gbps)

• CPRI Rate Option 7: 9830.4Mbps (9.83 Gbps)

• CPRI Rate Option 7a: 8110.08Mbps (8.11 Gbps)

• CPRI Rate Option 8: 10137.6Mbps (10.13 Gbps)

• CPRI Rate Option 9: 12165.12Mbps (12.16 Gbps)

• CPRI Rate Option 10: 24330.24Mbps (24.33 Gbps)

CPRI bandwidth has not been an issue in traditional D-RAN deployments, where the RRU and the BBU both reside at the cell site and are connected through dedicated fiber optic cables. However, with each individual CPRI interface in excess of 10 or 20 Gbps of CBR traffic, as is the case with CPRI rate 8 and higher, transporting raw CPRI traffic over the fronthaul access network presents a significant challenge. This challenge is compounded in cases where multiple sectors are used on the cell site or if multiple frequency bands are used, each of which might require a dedicated CPRI interface. In these cases, the cumulative bandwidth requirement from a single cell site location may exceed tens or sometimes hundreds of gigabits per second. Additionally, with the availability of mmWave frequencies in 5G and advanced antenna features such as mMIMO, the sheer amount of bandwidth required to transport CPRI traffic over fronthaul makes Option 8 bandwidth-prohibitive. However, Split Option 8 will continue to be useful for both 4G and some 5G deployments. It is expected to coexist alongside Option 7-x for vRAN deployments.

eCPRI

To deal with the challenges presented by traditional CPRI transport in the fronthaul network, the coalition of Huawei, Nokia, Ericsson, and NEC proposed the evolution of CPRI standards called eCPRI in 2017.⁴⁴ The drivers for creating a new eCPRI standard were multifold; chief among them was the need for significant reduction in CPRI bandwidth overall, use of flexible bandwidth scale based on user data instead of CBR, and the adoption of packet-based transport using Ethernet and IP technologies with advanced networking and OAM features.

A critical distinction between CPRI and eCPRI is the lack of control, management, and synchronization traffic in the latter. Control and management of the RU (for example, initialization and configuration) make up a small portion of the overall traffic and could be implemented independently of user data transport. As defined the by CPRI forum, eCPRI carries only the user data, or the U-plane traffic, and some real-time traffic control information, whereas the control and management traffic, referred to as the C-plane and M-plane, is implemented independently over Ethernet (VLANs or L2 VPNs) or IP (L3 VPNs). Additionally, eCPRI does not carry embedded synchronization information between the RU and DU. Synchronization between the two is achieved by implementing the S-plane using an external clock source and propagating timing information through the fronthaul network. The concepts of timing and synchronization are discussed in Chapter 9, “Essential Technologies for 5G-Ready Networks: Timing and Synchronization.”

Just like CPRI, the eCPRI implementations continued to lack cross-vendor interoperability and stayed a closed, proprietary system. In alignment with 3GPP, eCPRI encourages the use of the popular intra-PHY Option 7 due to its advantages in implementing antenna functions such as MIMO, multipoint connectivity, and carrier aggregation, but does not explicitly restrict the vendors from implementing other split options. The following split options are supported in the eCPRI specifications:⁴⁵

• eCPRI Split Option A: The equivalent of 3GPP Split Option 1

• eCPRI Split Option B: The equivalent of 3GPP Split Option 2

• eCPRI Split Option C: The equivalent of 3GPP Split Option 4

• eCPRI Split Option D: The equivalent of 3GPP Split Option 6

• eCPRI Split Option ID: The equivalent of 3GPP Split Option 7-3

• eCPRI Split Options IID and IIU: The equivalent of 3GPP Split Option 7-2

• eCPRI Split Option E: The equivalent of 3GPP Split Option 8

The choice of split option has an impact on the overall fronthaul bandwidth requirements. When more processing is done on the RU, signifying a higher split option, the bandwidth requirements for the fronthaul network go down proportionally. While the actual fronthaul bandwidth requirements will vary based on the individual deployment scenario, Figure 5-17 highlights the significant bandwidth savings based on the choice of split option implemented. The use case shown in the picture assumes an aggregated RF bandwidth of 500 MHz, with 64T64R mMIMO, but 4×4 MIMO layers and 64 QAM modulation. This implementation would require more than 1Tbps (terabits per second) for Split Option 8, 600 Gbps with Split Option 7-1, and 38 Gbps for Split Option 7-2. If Split Option 2 or 3 is used, the bandwidth requirement falls below 10 Gbps, similar to traditional backhaul.⁴⁶

The introduction of eCPRI helped modernize legacy CPRI transport by utilizing Ethernet and IP for transport as well as lowered the bandwidth requirements between the RU and DU. However, it did nothing to provide open interfaces and interoperability across vendors. While new entrants in the vRAN space were looking to take advantage of virtualization and revolutionize the RAN networks, mobile networks were still subject to vendor lock-in with limited to no interop between RU and DU provided by different RAN vendors. Mobile network operators, wanting to drive interoperability in vRAN, created the Open RAN (O-RAN) Alliance in an effort to collectively influence the industry and speed up the pace of their 5G deployment.

O-RAN Architecture and Use Cases

The O-RAN Alliance was founded on the basic principles of creating an intelligent, smart RAN network by virtue of automation, analytics, machine learning (ML), and artificial intelligence (AI), along with the use of standardized, open interfaces across the various virtualized RAN network components. As such, the overall O-RAN reference architecture uses a multifaceted approach in addition to Open Fronthaul nodes and interfaces. Figure 5-18 provides an overview of the building blocks of the overall O-RAN architecture, and the interfaces between them, as specified by ORAN WG1: Use Cases and Overall Architecture Workgroup.⁵⁰

As Figure 5-18 illustrates, Open Fronthaul (and its components) is just one part of the overall O-RAN reference architecture, while automation, orchestration, Network Function Virtualization Infrastructure (NFVI) framework, and RAN controller make up the rest of this architectural framework. Different WGs within the O-RAN Alliance define specifications for each of these individual components.

Open Fronthaul Nodes and Interfaces

One of O-RAN Alliance’s primary goals is to standardize the LLS option and accelerate the use of open, interoperable fronthaul RAN nodes. With input from both vendors and operators, WG4 (the Open Fronthaul Interfaces Group) defined the use of Split Option 7-2x between the RU and DU for what is known as Open Fronthaul.⁵¹ Option 7-2x is another PHY layer split, which should not be confused with 3GPP Option 7-2. It is logically placed between 3GPP Split Options 7-1 and 7-2, and assigns pre-coding, modulation, RF resource element mapping, and other higher-layer functions to the DU and allocates lower-layer functions like analog-to-digital conversion, inverse fast Fourier transform (iFFT), and certain beamforming management functions to the RU. Split Option 7-2x is focused on making it easier to implement the DU functions to run in a virtualized environment using generic COTS hardware. The RUs and DUs that support Open Fronthaul (that is, the O-RAN-compliant implementation of fronthaul through the use of Split Option 7-2x) are called Open RU (O-RU) and Open DU (O-DU), respectively.⁵²

The interface used between the O-RU and O-DU is still called eCPRI, which uses Ethernet or IP encapsulations. However, this 7-2x O-RAN-compliant eCPRI must be distinguished from the eCPRI interface defined by the CPRI forum. The two specifications do share the same naming convention (that is, Evolved or Enhanced CPRI, or eCPRI) and the use of Ethernet for transport, but they differ on the split options used. As mentioned in the previous section, the CPRI forum’s eCPRI implementation allows 3GPP-defined LLS Options 6, 7-1, 7-2, and 8, but mapped to eCPRI’s naming conventions of Option D, ID, IID/IIU, and E. In comparison, O-RAN-compliant eCPRI uses Split Option 7-2x and mandates open interfaces and interoperability between the O-RU and O-DU. Figure 5-19, included in the next section, provides a pictorial mapping of various split options defined by 3GPP, CPRI Forum, and O-RAN Alliance.

In addition to the Open Fronthaul specification through WG4, the O-RAN Alliance also defines open specifications for various other RAN interfaces through WG5 (Open F1/W1/E1/X2/Xn Workgroup), as well as the use of a Fronthaul Gateway (FHGW) through WG7 (Whitebox Working Group). The use of various RAN interfaces was showcased previously in Figure 5-18. More details on Fronthaul Gateway and its applications in the fronthaul transport network are discussed later in the “Transporting Radio Traffic over Packet-Based Fronthaul” section.

RAN Intelligent Controller (RIC)

The past several years have seen a significant increase in the use of software-defined, analytics-driven networks, and the mobile communication networks (MCNs) are no exception. RAN Intelligent Controller (RIC) is the software platform that can be considered the brain of the RAN domain. Using advanced analytics, artificial intelligence (AI), and machine learning (ML), a RIC utilizes the usage data generated in the RAN to provide performance visualization, perform predictive analysis, and create actionable intelligence. These capabilities can then be used to enforce or modify RAN policies to improve resource management, increase RAN efficiency, and optimize overall performance with little to no human interaction. Two different flavors of RIC are defined in an O-RAN architecture: near real-time (near-RT) RIC and non-real-time (non-RT) RIC.

A near-RT RIC interacts with the O-RAN nodes (O-DU and O-CU) and performs near-real-time monitoring and optimization of the radio access network resources. While a near-RT RIC controls the O-DU and O-CU behavior, in reality it acts as an enforcer for the policies defined by the non-RT RIC.

As shown in Figure 5-18 earlier, a non-RT RIC is part of the overall Services Management and Orchestration (SMO) framework, which uses ML/AI and analytics to provide policy guidelines to the near-RT RIC using the A1 interface. A non-RT RIC uses complex algorithms on the usage data and directs near-RT RIC to enforce policies, thus creating an intelligent and smart RAN network.

RIC is not just a single piece of software; it is rather a platform that allows extensibility through hosting third-party apps. Apps hosted on near-RT RIC are called xApps, whereas non-RT RIC apps are referred to as rApps. The use of third-party apps fosters an innovation-based ecosystem using RAN algorithms from various sources instead of being tied only to the software provided by the RIC vendor. Suggested use cases for xApps and rApps include QoS-based resource optimization, mMIMO and beamforming optimization, DSS, dynamic resource allocation for unmanned aerial vehicle, and handover in Vehicle-to-Everything (V2X) scenarios, among others.

RIC is an active area of research and development in the industry and is one of the critical foundations of the O-RAN reference architecture with two working groups (WG2 and WG3) defining non-RT and near-RT RIC specifications. At the time of this writing, there have not been any large-scale production deployments of RIC, but multiple mobile network operators such as AT&T, Deutsche Telekom, KDDI, and China Mobile have publicly commented on production trials for RIC.^{53, 54}

Cloud and Orchestration

Radio access networks have been moving toward a cloud-based architecture for some time. Centralized RAN architecture pioneered the concept of BBU pooling in a central cloud, even though, in most cases, this cloud was an offsite data center hosting specialized BBU hardware. vRAN changes this concept with virtualized RAN nodes (that is, the CU and DU). To ensure that future RAN networks take full advantage of the virtualization, the O-RAN WG6 (the Cloudification and Orchestration Workgroup) provides design guidelines to leverage and drive adoption of generic COTS hardware for virtualized RAN nodes.

Virtualization and cloudification typically go hand in hand, with some virtual functions being moved offsite to an application-hosting facility (that is, a cloud). O-RAN introduces the concept of an O-Cloud, a cloud platform composed of hardware and software components capable of providing RAN functions. An O-RAN-compliant MCN might contain multiple O-Cloud instances, where each instance is a collection of resource pools. These resource pools are essentially servers that contain CPU, memory, storage, network interface cards (NICs), and so on, which can host various individual O-Cloud network functions such as O-DU and O-CU. Given that these O-RAN nodes are typically distributed in multiple locales, a comprehensive automation, orchestration, and management framework is required to ensure consistent and efficient deployment. The Service Management and Orchestration Framework (SMO) defined by WG6 provides a general structure to accomplish just that.⁵⁵

In order to efficiently operate this distributed, diverse network spread across a vast geography, the use of a robust orchestration and automation framework, such as the one defined by WG6, is vital. While the detailed automation framework is out of scope for this book, the use of automation for 5G transport network deployment and continued operation will be discussed as needed.

O-RAN xHaul Network Architecture

O-RAN WG9 (the Open X-haul Transport Workgroup) has been focused on defining a baseline transport network architecture that encompasses the fronthaul, midhaul, and backhaul domains. As part of this objective, WG9 provides guidance on best practices and design strategies for the xHaul network using two primary transport mechanisms: WDM-based transport for fronthaul and the packet switched transport architectures for fronthaul, midhaul, and backhaul.^{56, 57} WDM-based fronthaul transport was briefly covered in Chapter 3; however, more details on WDM are out of scope for this book.

The WG9’s xHaul Packet Switched Architecture and Solution Specification outlines various 5G xHaul deployment scenarios, transport network technologies, VPN services implementations, quality of service guidelines, timing and synchronization architectures, as well as other details critical to the transport domain of an MCN. The specification and guidelines put forth by WG9, and the newly formed WG10 (the OAM Workgroup), are useful for data network engineers and architects tasked with designing and deploying a 5G mobile transport network. Later parts of this chapter, and the rest of this book, will exclusively focus on the technologies required to architect these smart, open, scalable, and programmable 5G transport networks.

Multi-Access Edge Compute (MEC)

CUPS architecture can address the latency challenge by using special-purpose compute resources deployed at the same data centers where the mobile core’s user plane is implemented. These compute resources, called Multi-Access Edge Compute (MEC), can be used to process and locally terminate the time-sensitive traffic. Termination of traffic flows closer to the edge significantly reduces latency compared to transporting this traffic over data networks to remote servers. Therefore, the use of MEC in the CUPS architecture makes it possible to fulfill the goal of 5G URLLC applications.

As data is consumed at the edge locations instead of being sent toward the data network, MEC also offers an additional benefit of fog computing by consuming and analyzing data at a location close to the source. This also benefits mMTC-type applications where IoT-generated traffic is best suited to be processed, analyzed, and reacted upon locally and closer to the data sources.

Although the term coined for the compute resources placed close to the (mobile) network edge was Mobile Edge Compute, in 2017, ETSI decided to give it a more generic name and rebrand it to Multi-Access Edge Compute.⁶⁰ Even though MEC has gained popularity as a 5G capability, its architecture is defined to be independent of 5G and can be implemented in 4G-based networks as well.⁶¹ The placement of MEC is further discussed in the “What’s Hosted at the Data Centers” section.

Placement of the 5GC User Plane

The vRAN architecture benefits by placing the disaggregated RAN components deeper into the mobile network, closer to the 5GC—as much as latency and other constraints allow. Similarly, deploying the 5GC user plane close to the cell sites offers the benefits of reduced latency, especially in the case of MEC and local content delivery network (CDN) servers, and lower bandwidth requirement for the backhaul network. Therefore, a mobile network architect would want to place the 5GC user-plane devices and functions as close to the cell site as possible. That makes the far-edge data center, with a typical distance of 10–20 km from the cell site and boasting a one-way latency of under 150 usec, ideally suited for the 5GC user plane, MEC and CDN server, and PDN connectivity. However, more commonly it’s the edge data center that is the optimal choice instead.

There are two main constraints that limit how close to the mobile network’s periphery the user plane can be deployed:

• The packet core functions can’t be placed before the disaggregated RAN components, or more specifically the CU. Placement of the CU will be influenced by the RAN design (with the aim to move it as far away from the edge as possible). Hence, an optimal choice has to be made between the RAN and packet core design to place the O-CU and user-plane 5GC functions; this criterion favors the edge data center as the best choice.

• The location that hosts these 5GC devices should also be able to host services or compute, such as MEC, CDN, or peering routers connecting to an Internet service provider or corporate intranet (in the case of Private 5G). Providing these services may not be practical at each far-edge data center due to their smaller serving area, high deployment density, and typically miniature design. Therefore, the edge data centers are once again the preferred choice. In certain cases, it may not be feasible for even edge data centers to meet these requirements, and in such cases traffic is routed to the user-plane functions in the main data center instead.

What’s Hosted at the Data Centers

With the decomposition of RAN and implementation of CUPS for the packet core, the building blocks of mobile networks are now sprinkled across a larger number of data centers spread across the entire MCN. Figure 5-20 represents the composition of these various data centers and the parts of RAN and 5GC that are hosted there.

As the figure shows, the devices and functions hosted at the main data center are not much different from EPC—that is, devices implementing the control plane of the mobile network, PDN connectivity to IMS servers (which then connect to PSTN and PLMN), PDN connectivity to reach the Internet (with CDN servers often hosted on the same premises), and connectivity to GRX/IPX exchanges for handling roaming scenarios. Note that even though the data plane is also deployed separately as a result of CUPS, the main DC continues to host data-plane functions. This is meant to handle data traffic that wasn’t offloaded at the edge of the network—either because it wasn’t feasible to do so, the content is latency tolerant, the content is available through the mobile provider’s own servers, or any combination of these. Such data traffic is expected to be only a fraction of the total user traffic and, hence, may not strain the entire xHaul network.

The edge data center, in addition to hosting the CU functionality from the decomposed RAN, will likely also host the 5GC data plane. To send or source this data from the Internet, these edge DCs will also require Internet peering. Additionally, CDN servers can be deployed to reduce the amount of traffic exchanged over this peered network through content caching. Even if Internet peering is not available at an edge DC, CDN servers could still be beneficial. Though MEC is more likely to be hosted at the far-edge data center or even at the cell sites where lower latency can be achieved, it can also be deployed at the edge DC.

The far-edge DC typically hosts only the DU; however, there might be circumstances where it’s required to process or offload the user data even closer than what the edge DC can offer. In that case, the far-edge DC will also host the CU as well as the 5GC user plane and MEC. Examples of such deployment are scenarios where far-edge and edge DCs are collapsed into one location.

Virtualization, Containerization, and Docker

In the initial days of server virtualization—to achieve isolation, application security, and resource sharing—hardware-assisted virtualization through a hypervisor was the commonly used implementation. Hypervisor functionality running in a host operating system allows for instantiation of a virtual machine (VM), where a guest operating system (OS) and virtualized applications can independently run. Hence, initial implementations of NFV followed the same model, and the VNFs included an operating system ready to be instantiated as a VM. vEPC followed the same path.

Even though this technique provided great isolation and security, there was a cost to it in the form of slight wastage of hardware resources and longer instantiation time. For deployments where the balance is more toward agility and resource optimization than a high level of isolation, the alternate approach of OS-level virtualization became attractive. This type of virtualization, also referred to as containerization, leverages the capabilities built into the OS to provide some degree of separation, resource sharing, and independence. This segregated environment is referred to as a container.

Compared to VMs, containers have a smaller footprint and make better utilization of the host’s resources while providing a relatively less amount of security and isolation. For example, containers do not require a guest OS, thus making them light on system resource requirements. However, because they share the host’s OS with other containers, they aren’t fully isolated from each other. Most importantly, because containers use built-in OS capabilities, they are free of additional software overhead and resource emulation that would have been required for VMs. This makes containers the preferred choice for dynamic and agile environments.

However, additional capabilities are needed for packaging, porting, maintaining, and managing the containerized applications. Docker is a definite frontrunner among the tools that offer these capabilities and has been the most popular choice. Today, the words Docker and container are used interchangeably, almost completely overlooking the fact that a container is a virtualized application while Docker is an application to package, build, manage, instantiate, version-control, and ship a containerized application.

Microservices Architecture

Virtual machines have their benefits, but they are better suited to a monolithic virtual environment that contains the entire ecosystem of the application. However, the low overhead of containers brings a high level of modularity when virtualizing a set of intertwined applications. The individual applications, or even the individual functions within them, can be containerized. With carefully defined interactions between these applications or functions as well as facilitating these communications through APIs, the containers can easily interact with each other and work cohesively as intended, without knowledge of each other’s inner structure. Thus, each one of these can be independently developed, maintained, spun-up, scaled, upgraded, and patched.

Such an implementation of the software function by breaking it down into individual services-oriented, self-contained, independent, and isolated virtualized building blocks is called a microservices-based implementation. This architecture offers all the benefits of virtualization for each building block (typically a container) that implements a part (service) of the entire application, and through its modularity brings additional benefits such as independent scalability, upgradability, and resiliency of each of these services.

Orchestration and Kubernetes

Managing, orchestrating, instantiating, monitoring, and ensuring the availability of the virtualized functions are best suited for applications designed for these tasks—commonly known as orchestrators.

Management and orchestration (MANO) has always been a critical part of the NFV-based implementation.⁶² With a microservices-based approach resulting in a high number of individual containers, along with the networking connecting them together, the need for sophisticated orchestrators becomes even more significant. Various orchestrator choices (many of which are open source) have been available for this purpose, but the most popular and predominantly preferred and used choice at the time of this writing is Kubernetes.

Developed originally by Google engineers, Kubernetes is now an open source container orchestration tool. Often abbreviated as Kube or K8s, Kubernetes offers everything that’s expected of an orchestrator. Some of the popular Kubernetes distributions include RedHat’s OpenShift, VMware’s Tanzu, Amazon’s Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), and so on. It’s worth noting that in addition to container orchestration, additional tools and functions may be required to orchestrate and/or automate services and networking. These functions are performed by tools such as Cisco’s Network Services Orchestrator (NSO), RedHat’s Ansible Automation Platform, Juniper Network’s Contrail, and Nokia’s Nuage, among others.

Cloud-Native Applications

A cloud environment, in its simplest form, is any data center that is designed to host applications, provide storage, enable interconnectivity, and offer tools and means to orchestrate, deploy, monitor, and manage these services. This could be a commercially available public cloud (such as AWS, GCP, Azure, and many others), a private cloud (owned and managed on-premises by a corporation), or a combination of the two (called a hybrid cloud). The choice of the cloud environment typically comes down to the cost factor, security considerations, and latency limitations. The capital cost of using a public cloud are very low; however, the operating costs of that might be significantly higher than a privately hosted cloud infrastructure. Cloud platforms have made significant strides in meeting security requirements through the use of sophisticated encryption techniques for storing and transferring data, to an extent that governments are starting to feel comfortable moving their data to the cloud.^{64, 65} Latency limitations create a requirement of deploying the applications within a certain distance from the users. Deployment of DU is an example of such a restriction, where it has to be within 20 km of the RU. To solve this challenge, most major public cloud providers also offer on-premises versions of their cloud environment, thus extending their cloud to on-premises privately owned locations, while still offering the same orchestration tools and experience as their regular public cloud environment. Some examples of this are AWS Outpost, Azure Stack, and GCP Anthos.

Irrespective of the type of cloud environment, and whether it’s on-premises or publicly hosted, the concept of this ecosystem stays the same. Such an ecosystem with virtualized and containerized applications implemented as a microservices architecture, along with orchestration capabilities, is colloquially referred to as a cloud-native implementation.

Automation capabilities are implied for any cloud-native orchestrator. It’s generally assumed that the containers and their networking in a cloud-native environment have predefined instantiation and deployment templates, lifecycle rules, availability and scalability criteria, and are being actively monitored for failure detection and recovery. The orchestrator is expected to use these and seamlessly run the entire environment with high availability and performance.

Cloud-Native 5G Core

5GC is conceived as a microservices-based architecture ready for cloud-native implementation. The use of Service-Based Architecture (SBA), discussed next, is an essential part to realize this goal. The use of virtualization had already started to remove the dependency on specific vendor hardware, and now the cloud-native nature of 5GC implies that it doesn’t need to be hosted at a data center owned and operated by the mobile provider. Rather, such a cloud-native core could be deployed and run on any type of cloud infrastructure. Of course, the developer of the application or service containers claiming cloud-native capability will need to ensure flawless integration into any cloud environments they are being deployed in and can be managed by the orchestrator and tools being used in that environment.

The 5GC adoption of the industry trend toward open and standards-based APIs means that the individual containers implementing 5GC functions can be from any vendor that the mobile operator finds to be most suitable for that particular service. Hence, 5G Core is ripe to be a multi-vendor, cloud-hosted, highly scalable, and resilient mobile core.

5GC User Plane Network Function

The User Plane Network Function (UPF) is the cornerstone of CUPS and is responsible for the routing and forwarding of mobile user’s traffic to an external network. To achieve low latency, UPF may be placed in the edge or far-edge data centers, in addition to the main DC, as previously discussed in the placement considerations for the 5GC user plane. Additionally, to provide ultra-reliability, either redundant UPF or redundant traffic paths to the same UPF may be used.⁶⁹

Just like 4G, the 5G packet core also makes use of GTP-U protocol over IP to encapsulate data traffic between the RAN and gateway to the external network, simply referred to as Data Network (DN) in 5G terminology. This GTP-U tunnel is established between the gNB and UPF over the N3 reference interface (thus sometimes referred to as N3 GTP-U). The UPF terminates this GTP-U tunnel and forwards the user traffic to the DN. The UPF (like other cloud-native implementations) is meant to be scalable to meet traffic demands, and multiple UPFs can be spun up when needed.

The mobile device and the UPF use a construct called a protocol data unit session (PDU session) for traffic forwarding. This is similar in concept to the EPS bearer that was defined in 4G networks, but it has some subtle differences—the most important being the granularity of the QoS mechanism. Unlike the EPS bearer, where a single QoS treatment is applied to all traffic, a PDU session can apply different QoS behaviors to individual traffic flows.⁷⁰

In contrast to the EPS bearer, the PDU session doesn’t carry any signaling information and is composed of a data radio bearer (DRB) between the UE and gNB, coupled with a GTP-U tunnel between the gNB and UPF. The UPF inherits the SGW functionality of anchoring the GTP-U tunnel, and hence when a user moves across the gNB (but within the service area of the UPF), the GTP-U tunnel destination stays unchanged and traffic continues to flow to the same UPF. If the mobile user moves outside of the UPF’s service area, the control-plane functions trigger the procedure to select a new suitable UPF.

5GC Control Plane Network Functions

As of 3GPP Release 17, around 30 control-plane NFs have been currently defined, and this might continue to evolve as 5GC matures further. Some of these functions are optional and are not required in all 5GC implementations. Diving into the detailed description of each of these control plane NFs is beyond the scope of this book; instead, the NFs will be described by logically grouping them together based on their roles. Some studies⁷¹ have classified these roles into the nine groups depicted in Figure 5-21.

This section will describe each of these groups, with more emphasis on the groups with higher significance, while only briefly describing the rest.

Communication Interfaces Between 5GC Network Functions

3GPP defines two different nomenclatures to represent the interfaces between the Network Functions. The first nomenclature, called service-based representation, is defined only for the Control Plane NF. The service-based representation calls out an exposed interface for every NF (for example, Namf for AMF and Nsmf for SMF). These are general-purpose exposed interfaces open for any Control Plane NF to communicate with any other Control Plane NF using the common SBA connectivity bus. The other nomenclature is defined for point-to-point communication between two NFs, similar to the concept of interfaces in previous generations. The point-to-point interfaces were previously called “S” interfaces in the case of EPS, “G” interfaces for GPRS, “I” interfaces for UMTS, and now in 5GC they are defined as “N” interfaces to signify the next generation nature of 5G. For example, the interface between AMF and SMF is called N11; however, it uses the common Namf and Nsmf interfaces of AMF and SMF, respectively, and is often not shown explicitly. Figure 5-22 shows a graphical representation of common 5GC interfaces using both nomenclatures.⁷²

For the control functions, SBA chose Representational State Transfer API (REST-API)–based messaging for communication between these function, with JavaScript Object Notion (JSON) as the encoding format.⁷³ The reference interfaces related to user plane functions, RAN, and the mobile device use other IP-based protocols such as GTP-U.

Radio over Ethernet (RoE)

As the name implies, the Radio over Ethernet (RoE) standard, defined by the IEEE 1914.3 specification, describes CPRI transport over a packetized fronthaul using Ethernet. To encapsulate CPRI within Ethernet frames, IEEE RoE standard defines a new Ethertype (0xFC3D), frame format, and introduces the concept of an RoE Mapper and deMapper. Network equipment vendors can implement this RoE Mapper and deMapper functionality on their fronthaul CSR (FH CSR) and the far-edge DC routers to create a bookended solution across a packet-based fronthaul. In this case, the FH-CSR mapper function receives the constant bitrate CPRI traffic, converts it into a packet stream using RoE, and transports over the fronthaul network to the far-edge DC, where the router connected to the DU or BBU re-creates the CPRI stream using the RoE deMapper function, thus enabling RU-to-DU/BBU communication. Traffic from the DU/BBU to the RU follows a similar process.

The IEEE 1914.3 RoE standard defines multiple mapper types for implementation flexibility. Different modes of RoE operations with commonly used mapper types in a packet-based fronthaul are as follows:

• RoE Mapper Type 0: This is the structure-agnostic tunneling mode, where CPRI traffic is simply encapsulated within Ethernet frames without any further processing. In this mode of operation, Ethernet traffic rates in the fronthaul mimic those of CPRI rate options. For instance, CPRI Rate Option 7 (9.83 Gbps) would require slightly more than 9.83 Gbps Ethernet bandwidth to accommodate additional bits added by the Ethernet header. Similarly, transportation of CPRI Rate Option 10 over a packet-based fronthaul would require more than 24.4 Gbps of Ethernet bandwidth. Various CPRI rate options are covered earlier in this chapter.

• RoE Mapper Type 1: This is the structure-agnostic line-code-aware mode. In this mode of operation, the RoE mapper function removes the line-coding from CPRI traffic. CPRI Rate Options 1 through 7 use 8b/10b line-coding, which puts 10 bits on the wire for every 8 bits of data for redundancy. Stripping 8b/10b line-coding ensures the transport of 8 bits of CPRI over Ethernet instead of encoded 10 bits, saving up to 20% fronthaul bandwidth. CPRI Rate Options 8 through 10, however, use 64b/66b line-coding and hence save only 3% of the bandwidth in the fronthaul (2 bits of Ethernet savings for every 64 bits of CPRI traffic).

  RoE Mapper Type 1 is often preferred over Type 0 by network operators due to substantial fronthaul bandwidth savings, especially with CPRI Rate Options 7 and below, but it requires some level of interoperability between network equipment and RRU vendors as the fronthaul transport network element would need to remove and then add back the 8b/10b line-coding on either side of the CPRI connection. This often represents a challenge because RAN equipment vendors may use special characters and messaging between the RU and DU/BBU in their CPRI implementation, thus making RoE Type 1 harder to implement. Both RoE Types 0 and 1 are still CBR in nature.

• RoE Mapper Type 2: This is the structure-aware mode where the router implementing this function deconstructs and reconstructs the CPRI stream. Structure-aware mode requires the network equipment vendor to acquire significant knowledge of radio implementation by the RAN equipment vendor, including any proprietary information.

  When implemented, however, RoE Type 2 could take advantage of statistical multiplexing of CPRI traffic, allowing the network element (that is, a fronthaul CSR) to receive a constant bitrate CPRI stream, identify useful data (that is, the actual data being sent by the radio or DU/BBU), and convert only this data into Ethernet frames. In essence, this process converts the constant bitrate CPRI stream into variable bitrate Ethernet traffic. This data is converted back into a CBR CPRI stream using a deMapper on the remote end. While highly desired by mobile network operators due to massive amounts of bandwidth savings, the real-life implementation of structure-aware RoE mappers remains scarce because it requires the RAN equipment vendors to open their CPRI stack for the networking equipment vendors to be able to deconstruct and reconstruct the CPRI stream.

RoE represents a significant step toward the adoption of a packet-based fronthaul. However, its usefulness is limited to scenarios where both the RU and DU/BBU use legacy CPRI interfaces. As mentioned earlier, newer radios have started using eCPRI, where the RU and DU both transmit/receive CPRI traffic using Ethernet framing. It must be mentioned that in both these cases—that is, CPRI over RoE and vendor-specific eCPRI—the RU and BBU/DU have to be provided by the same RAN vendor. Interoperability between RAN nodes from different vendors is only possible if O-RU and O-DU are used that adhere to the O-RAN Alliance’s defined Split 7-2x-based eCPRI.

Fronthaul Gateway (FHGW)

With virtualization taking root in mobile network deployments through vRAN, it’s likely to have scenarios where the traditional BBU could be replaced by a CU+DU pairs, where the DU supports eCPRI only, while legacy RUs continue to be used. In those cases, a Fronthaul Gateway (FHGW) could be used to provide conversion between legacy CPRI and eCPRI. FHGW provides an interworking function (IWF) between a traditional RU (which uses CPRI) and a newer DU or vDU that uses eCPRI. This is done through a RAN logic function embedded in the FHGW device, likely to be a cell site router. In essence, the CPRI traffic received from the RU is converted to eCPRI through this RAN processing function and sent to the DU through the uplink interfaces. Similarly, the eCPRI traffic received on the uplink Ethernet interfaces from the DU is converted into CPRI before being sent to the RU. Figure 5-24 shows the FHGW concept as define by the O-RAN Alliance.⁷⁷

As one can infer, the radio signal processor is an indispensable component of an FHGW, without which the device concept shown in Figure 5-24 is effectively an Ethernet router. Any network equipment vendor looking to implement FHGW functionality on its CSRs must implement this radio signal processor to convert traditional CPRI into eCPRI. It has been previously mentioned that CPRI implementation is proprietary; as such, RAN equipment vendors with a networking equipment portfolio have an inherent advantage in embedding this functionality into their current CSR offerings. Examples of such vendors include Ericsson and Nokia, both of which have an extensive RAN and networking equipment portfolio and have FHGW functionality available on their networking products geared toward 5G xHaul.^{78, 79} It must be noted that many of these FHGW products provide conversion between traditional CPRI and vendor-specific eCPRI and thus require both the RU and DU from the very same vendor.

This poses a challenge for networking equipment manufacturers such as Juniper and Cisco that have a limited RAN portfolio and are thus dependent on the RAN equipment manufacturers to implement the radio signal processing functions needed to create an FHGW product offering. As one can expect, incumbent RAN equipment manufacturers, which in many cases are direct or indirect competitors of networking equipment manufacturers, might be reluctant to share their intellectual property (that is, their proprietary CPRI/eCPRI structure) to protect and expand their market share. Networking equipment manufacturers realize this challenge and are working on a two-pronged strategy to carve out a place for their products (such as CSR or aggregation nodes) and protect their market share in this transforming landscape. First, they are working with the O-RAN Alliance to define not only the Open Fronthaul Interfaces (that is, Option 7-2x eCPRI) but also the hardware specifications for an Open Fronthaul Gateway.⁸⁰ Additionally, the network equipment manufacturers are forging partnerships with new entrants in the RAN market, such as Altiostar (now acquired by Rakuten), to create joint go-to-market strategies and products for 5G networking.⁸¹

All of these CPRI adaptation mechanisms are expected to be deployed in mobile networks for CPRI transport over a packetized fronthaul. Figure 5-25 summarizes various scenarios for transporting radio traffic across a packet-based fronthaul network.

At the time of this writing, virtually all packet-based fronthaul products use either CPRI over RoE or vendor-specific eCPRI, both of which requires all RAN nodes (RU, DU, CU) to be provided by the same RAN vendor. A handful of new entrants also have O-RU and O-DU available but with limited real-life deployments so far. This is expected to change as mobile network operators demand more openness from RAN vendors and new entrants trying to capture RAN market share from incumbents. FHGW is also a relatively new concept, with the first O-RAN specification defining FHGW being made available in 2021 as part of Working Group 7’s “Hardware Reference Design Specification for Fronthaul Gateway.”⁸² FHGWs, however, is likely be an interim solution, geared toward the reuse of legacy RUs with newer DUs. Over time, as traditional RUs gradually get upgraded and replaced, the FHGWs will be phased out.

Optical Fiber-Based xHaul Transport

Fiber-based transport networks have long been considered the gold standard of network connectivity due to their flexibility regarding bandwidth capacity, speed, and distances they could cover. While the cost of deployment continues to be a concern, fiber-based transport technologies like WDM, passive optical network (PON), and Ethernet continue to be the leading choices for all xHaul domains, including fronthaul networks.

As mentioned earlier, WDM has already been in use for fronthaul in 4G Centralized RAN deployments and provides ample capacity to meet bandwidth-intensive FH deployment scenarios. Although it’s expected that it will continue to be useful in 5G xHaul, WDM lacks the flexibility offered by packet switched transport networks.

PON is another fiber-based transport technology that has and will continue to provide xHaul connectivity. Lower-bandwidth PON solutions like GPON, NG-PON, and XGPON may be suitable for midhaul and backhaul but may not satisfy the bandwidth requirements for fronthaul. Innovations like NG-PON2 using WDM technology to provide speeds as high as 40 Gbps are needed to fulfill the high-bandwidth requirements of transporting radio traffic over fronthaul. In fact, some network operators already have 5G transport deployed using PON-based technologies.⁸⁴ The PON ONTs and OLTs are typically equipped with Ethernet Interfaces, which can be used to connect to RU and DU/BBU, respectively, provided the RU and DU/BBU use eCPRI. If the RU and DU/BBU use CPRI, then additional processing will be required to adapt the CPRI traffic to Ethernet for transport over PON based Fronthaul.

Ethernet-based packetized fronthaul, however, is where most of the innovation has been taking place with respect to the 5G transport. The introduction of RoE and eCPRI has made it possible to transport radio traffic using Ethernet, allowing the fronthaul network to benefit from the same features and functionalities as midhaul and backhaul (for example, MPLS VPN, traffic engineering, and rapid restoration). The packet-based xHaul concept, while new and thus limited in adoption at the time of this writing, is expected to grow in the coming years.

The O-RAN “xHaul Packet Switched Architectures and Solutions” specification focuses on the use of packet-based fronthaul, midhaul, and backhaul and documents the use of innovations such as Segment Routing (SR) and Segment Routing v6 (SRv6), both of which are discussed in the next chapter.

Wireless xHaul

As mentioned in Chapter 2, the microwave-based backhaul constitutes a majority of all backhaul links, courtesy of large-scale deployments in developing countries. The unlocking of new and higher frequency bands has opened new possibilities for wireless xHaul. For instance, in addition to microwave allocations in the traditional 6–42 GHz range, more spectrum, particularly in E-Bands (71–86 GHz), W-Bands (75–110 GHz), and D-Bands (110–170 GHz), has been allocated for use for wireless xHaul. Higher frequency band translates into higher capacity, which can provide needed bandwidth for the fronthaul. However, as mentioned in Chapter 2, higher frequencies are best suited for shorter distances.

3GPP has also standardized the use of wireless technology for xHaul transport through the use of the Integrated Access Backhaul (IAB) architecture. In short, IAB allows a RAN node (such as gNB) to act as a donor cell that provides services to mobile users in its coverage area, simultaneously connecting other cell sites to the rest of the network. These IAB-connected cell sites can, in turn, provide services to mobile subscribers in their own coverage zone or act as a donor site for other sites, thus creating a cascading mesh of wirelessly connected cell sites.⁸⁵ The combination of microwave and IAB technologies allows a mobile operator to mix wired and wireless technologies to create an xHaul deployment suited to its requirements. Figure 5-26 illustrates a sample xHaul deployment using MW, IAB, and wired connectivity.