Changing usage models such as automated vehicles, smart factories, streaming video, and cloud-based applications has placed more emphasis on higher bandwidth and shrinking latency. To meet these evolving needs, 5G promises a 100X speed boost compared to 4G LTE, along with latencies that are an order of magnitude or lower. In addition, 5G specifications call for the new network to connect one million devices per square kilometer, more than 100 times as many as before.

Meeting these higher performance levels requires big changes, including a new frequency band and a changed radio access network (RAN) architecture. On the heels of building out 4G LTE, carriers must now deploy an entirely new transport technology with greater complexity and significantly more hardware and software components. The rollout itself will take place on a massive scale and carriers need solutions that are not just fast and efficient to deploy, but also economical to buy and operate. These components also need to be reliable and minimize power consumption.

As the industry plans for this 5G build out, it is imperative that capital expenditures (CapEx) and operating expenditures (OpEx) are controlled. This has led to an industry-wide shift from 4G's dedicated hardware and proprietary software to open software stacks installed on open and commercial-off-the-shelf (COTS) hardware platforms.

Why Open Solutions are Key to 5G

Looking back at 4G, these networks were largely implemented with custom hardware running proprietary software stacks. When a carrier chose an equipment vendor, it became a long-term commitment. That approach was tolerable for 4G networks but given the new challenges of 5G and the drive for lower total cost of ownership (TCO), carriers have begun developing open-source solutions. The ultimate goal for 5G is interchangeable COTS Arm or x86 servers, running open-source software stacks.

Figure 1: Top level wireless network architecture

How 5G is different?

The 5G network is almost entirely different from 4G LTE, beginning with frequency band. 5G picks up where 4G leaves off, spanning the spectrum from 6 GHz to 300 GHz. Higher frequencies support significantly smaller cell sizes, enabling 5G cells to provide highly localized coverage in locations such as neighborhoods, manufacturing plants, or even within houses and other structures.

The 5G network architecture breaks the functions of the 4G BBU into a radio unit (RU), distributed unit (DU), and centralized unit (CU). Because 5G decouples the RU, DU, and CU, it provides much more flexibility for carriers. The RU, DU, and CU may be co-located or deployed in separate locations, depending on the network requirements. For example, a network requiring the lowest possible edge latency may be built by deploying the RU, CU and DU together at the edge. This will give excellent performance for far-edge-connected user applications but, adds the expense of environmentally controlled enclosures at each tower. In another approach for applications that can tolerate greater latencies, multiple RUs may be serviced by one DU, lowering network costs while providing adequate performance.

Figure 2: 5G distributes 4G legacy BBU into RU, DU and CU functions.

Better understanding the components of 5G requires a closer look at the architecture. Figure 3 shows a “one click down” view of 5G network hardware and interconnections.

Figure 3 : 5G network software architecture

The 5G RU is hardware-based for the data plane. It consists of an RF transmitter and a LO PHY block, typically implemented as an FPGA or an ASIC optimized for packet management. It operates at wireline speed and can deliver latencies of less than 1 ms. The RU is connected to the DU via a front haul between the LO PHY and HI PHY. The smaller cell sizes in 5G mean that more towers will be required for given coverage area. As a result, RUs and towers will be deployed at a scale of millions across the network.

The DU manages radio packet traffic to and from the RU over the fronthaul link. The primary components of the DU are the radio link controller (RLC), the media access controller (MAC), and the HI PHY. The MAC incorporates software that communicates with the RLC and a hardware module that communicates with the PHY. It can incorporate hardware accelerators such as GPUs or FPGAs and can operate with a latency of less than 5 ms. The DU is connected to the CU via an F1 mid-haul. A DU COTS implementation would consist of a server chassis with hardware acceleration PCIe cards and an open-source MAC/RLC stack.

The CU is split into a control plane (CP) and a user plane (UP). This mimics the configuration of 4G LTE, which makes it easier to integrate a 5G network with a 4G LTE network and also provides flexibility for unique 5G RAN configurations. The CP and the UP are directly connected in the CU box as part of the CU. They can operate with latencies on the order of 10 ms.

Upstream from the CU is the RAN Intelligent Controller (RIC). This function virtualizes the radio network into a series of functions accessible by upstream core controllers. The RIC will be discussed in further detail below.

The shift toward open networks

Although the RU, DU, and CU include all of the functions and interfaces necessary for a software defined network, or virtual RAN (vRAN), the network orchestration and automation layer at the core needs a software tool to manage the process. In 4G LTE, this task was managed by proprietary hardware and software. The need for cost-effective 5G solution has led to a push by carriers for a standardized, open-source solution that would leverage COTS hardware.  

However, the 5G open-source movement can only succeed if hardware is capable of meeting the performance, form factor and cost requirements to run the software. Arm-based server processors are a logical choice since they are architected for high performance, power efficiency and low TCO.

In addition, one of the specifications to come out of OCP is the openEDGE chassis. Its shallow form factor, low power requirements, and processing density are optimized for telco and edge applications.

The openEDGE chassis’ modular design involves standardized server chassis fitted with slots that can be filled with sleds (see figure 4). The sleds are connectorized and designed to slide into place. They can be populated with motherboards and memory modules, etc. OpenEDGE chassis are available in a number of standard frame sizes (2u, 3U, 5U, etc.); each is 19-inch compatible and designed to fit into standard racks.

Figure 4: Wiwynn EP120 openEdge server

Ampere developed the Hawk server motherboard in an openEdge sled to support 5G RU, DU, CU, and RIC in a compact edge form factor with these features in mind:

• Support for 5G RU, DU, CU and RIC in a compact edge form factor
• Arm-based v8 cores at 3.3 GHz with features including 8 DDR-2667 DIMMS, 42 lanes of PCIe Gen 3
• Integrated SATA controller
• OCP NIC
• Power at least at 125W TDP

Figure 5: Wiwynn EP120 processor sled, which contains Ampere Hawk motherboard.

Other 5G core functions such as Open Networking Automation Platform (ONAP), the open source networking project hosted by the Linux Foundation, have different hardware requirements. Core hardware is often racked in traditional data centers, with associated cooling and power infrastructure available. This enables the use of commercial off the shelf server form factors, such as full depth 1U and 2U, with larger power envelopes.

Hardware needs will evolve with 5G advancements to meet the requirements of compute and power efficiency. Telco operators will need their design engineers to evaluate and implement these types of hardware solutions to achieve high-performance core servers while lowering operating costs and reducing capital expenditure per rack.

About the Author

Darrin Vallis is a computing systems architect with over 20 years of experience in hardware and software development. His expertise covers embedded systems, PC client, storage and hyperscale servers. Recently he has been focused on Cloud, Edge and 5G design. Darrin is a Navy veteran, holds ten patents and has been published fourteen times in technical journals. When not at his lab in Austin, Texas, Darrin can usually be found designing and building race cars or somewhere on a racetrack.