Breaking the shackles of proprietary systems: the open path to 5G networks

As technology continues to change, the era of proprietary radio access networks is gradually disappearing. Operators want to reduce costs while increasing flexibility, and they need networks and network components that are easy to deploy and affordable, which has also led the industry to shift from 4G dedicated hardware and proprietary software to open software stacks installed on COTS hardware platforms.

Proprietary components for 4G

If we look at wireless networks from the perspective of the core network and RAN, the core network includes the backbone network, metropolitan area network, and regional network (Figure 1). In the early days, the network used fixed switches and routers to transmit data. Today, the core network aggregates data at the edge of the RAN, and the RAN transmits the aggregated data to the radio tower.

4G networks operate on frequency bands between 1GHz and 4GHz, and each tower is equipped with a baseband unit (BBU) that collects data from the core network and transmits it to the remote radio unit (RRU).

4G was largely implemented with custom hardware running proprietary software stacks, and this approach was acceptable for 4G networks, but with 5G and the costs involved, operators have moved to develop open source solutions. The goal for 5G is to have interchangeable COTS ARM or x86 servers running open source software stacks.

5G Network

5G networks are fundamentally different from 4G LTE. In terms of frequency bands, 5G covers the frequency band from 6GHz to 300GHz. Since the higher the frequency, the greater the attenuation during signal propagation, the base station density of the 5G network will be higher.

5G splits the 4G BBU into radio units (RU), distributed units (DU), and centralized units (CU) (Figure 2). Decoupling these functions brings great flexibility to operators because they can deploy RU, DU, and CU in different locations as needed. For example, a network that requires low edge latency can deploy RU, CU, and DU together at the edge, which will maximize the performance of remote connected user applications. In addition, one DU can serve multiple RUs, thereby reducing network costs while providing sufficient performance within the acceptable maximum latency range. Operators can deploy different architectures for different markets and regions.

The diagram below provides a closer look at the hardware and interconnections of a 5G network.

The 5G RU contains an RF transmitter and an LO PHY module, usually implemented as an FPGA or ASIC optimized for packet management, which can provide a latency of less than 1 millisecond. The fronthaul is between the RU and the DU.

The wireless data packets of DU are transmitted to and from RU via the fronthaul link. The main components of DU are the radio link controller (RLC), media access controller (MAC), and HI PHY. MAC integrates software for communicating with RLC and hardware modules for communicating with PHY. It can integrate hardware accelerators such as GPU or FPGA and can operate with a latency of less than 5 milliseconds. DU is connected to CU via the F1 midhaul interface. A DU COTS implementation will include a server chassis with a hardware acceleration PCIe card and an open source MAC/RLC stack.

The CU consists of a control plane (CP) and a user plane (UP). This configuration is similar to LTE, making the integration of 5G networks with 4G LTE networks easier, and it also provides flexibility for 5G RAN configuration. The CP and UP are connected in the CU box as part of the CU, and they can operate with a latency of about 10 milliseconds.

The RAN Intelligent Controller (RIC) sits upstream of the CU and virtualizes the radio network into a series of functions that can be accessed by the upstream core controller.

The shift towards openness

The RU, DU, and CU contain all the functions and interfaces required for SDN or virtual RAN (vRAN). However, the core network orchestration and automation layer does require software to manage the process. LTE networks manage this task through proprietary hardware and software. Due to the cost constraints of 5G, operators began to look for standardized open source solutions that utilize COTS hardware. As a result, several key open source projects have emerged: Akraino Edge Stack, O-RAN Alliance, ONAP, and OCP. In addition, a new organization called the OpenRAN Policy Alliance has been established recently.

Akraino Edge Stack

Launched in 2018, Akraino Edge Stack focuses on developing an open software stack for the network edge and is now part of the LF Edge initiative. The organization emphasizes modular design and supports the reuse of software components. These stacks, called Akraino blueprints, serve various subsets of edge cloud infrastructure, including enterprise edge, over-the-top-edge, provider edge, and operator edge. When installed on a "bare metal" server, the blueprint transforms the machine into an application-specific device.

Akraino, which is dedicated to building 5G telecom equipment that accelerates RAN deployments, is currently developing blueprints for multiple operators. The organization recently released the Akraino Radio Edge Cloud (REC) blueprint, which provides the basic components for the management, orchestration, and automation layers to interact with the vRAN.

REC runs on the Linux CentOS distribution and works with management and monitoring software that is included in and managed by Kubernetes. The stack virtualizes bare metal servers so that they can be abstracted as software services. The upper control layer can call these APIs, enabling it to interact with the data plane of the network layer.

O-RAN Alliance

The O-RAN Alliance is committed to achieving an open, intelligent RAN. The Alliance is developing open virtualized network elements such as open DU and open CU. As with Akraino, the focus is on building reusable and standardized modular reference designs. This approach not only speeds up integration and deployment, but also enables developers to skip writing code blocks for common functions, freeing them up to innovate.

The work on O-RAN is closely tied to the development of the Akraino blueprint, with the idea being that the Akraino blueprint abstracts the hardware layer, and then the O-RAN/ONAP software stack runs on top of that layer and interacts with the API (Figure 4).

One of the key software developments addressed by O-RAN is the RAN Intelligent Controller (RIC), which provides an interface between the RAN controller in the 5G core and the access network, enabling policy-driven closed-loop automation. RIC is the interface component that transforms RU, DU, and CU into vRAN, providing faster and more agile service deployment and programmability.

The RIC is co-located with the CU and is connected to the orchestration and automation stack of the core network via backhaul and to the CU and DU via midhaul. It will run on the Akraino REC blueprint, which is optimized to minimize latency between the RIC and DU/CU (Figure 5). The Akraino REC is integrated with a regional controller located at the edge of the core network to fully automate the deployment of the REC to edge sites.

ONAP

5G networks will support a variety of applications with very different requirements. For example, streaming video on mobile devices does not have a great demand for latency, but may need to have high mobility; smart factories will not move, but require the lowest possible latency; self-driving cars face the dual challenges of ultra-high reliability and ultra-low latency. Of course, there are other factors, including bandwidth and cost. Effectively serving these diverse applications requires the ability to virtualize the network so that the network can be used as a collection of network slices, each of which can be dynamically reconfigured to provide the quality of service required by each application.

The building blocks discussed so far provide a way to create network slices, but they require a top-level control structure at the core to orchestrate and manage services. ONAP is an open source networking project hosted by the Linux Foundation that aims to address this need.

ONAP is critical to 5G deployment, supporting orchestration, automation, and end-to-end lifecycle management of network services. It is very complex and computationally intensive, requiring 140 cores and 140 GB of RAM to run just one ONAP instance. The interface between ONAP and RAN is shown in Figure 6.

OCP

Creating interoperability in the networked world requires standardized form factors and interfaces. The OCP was started to establish hardware specifications to achieve this standardization. One of the upcoming specifications from OCP is the openEDGE chassis (Figure 7). Its low power requirements and processing density are optimized for telecom and edge applications.

OpenRAN Policy Coalition

Recently, 31 well-known foreign operators and technology companies established the OpenRAN Policy Coalition in the United States to promote open concept RAN.

Members of the Open RAN Policy Coalition include AT&T, Amazon Web Services, Facebook, Google, IBM, Intel, Microsoft, Qualcomm, Rakuten Mobile, Samsung Electronics America, Telefonica, Verizon and Vodafone.

The goal of the Open RAN Policy Coalition is to provide policy-focused support to other Open RAN organizations working on technical standards, such as the O-RAN Alliance and the TIP Project.

5G is expected to bring huge performance improvements, fundamentally changing global communications and providing telecom operators with opportunities to create new markets and consumer services. To succeed in 5G, operators need to improve network equipment with flexibility, low cost and fast time to market. Open 5G hardware and software can help them achieve these goals.