Part 2: Opening the 5G Radio Interface

With cost-effective and reliable 5G Radio Unit (RU) whitebox implementations

By Comcores

Carriers are now deploying 5G across the globe driven by the need to keep up with relentless mobile data growth. 5G New Radio (NR) operates at higher frequencies to increase bandwidth, but at the expense of range. There will therefore be a need for a much larger number of 5G RUs to provide the same coverage. The availability of cost-effective, reliable and open 5G radio units is therefore critical.

Comcores is leading the way with implementations of critical 5G RU functionality. Comcores is an active participant in the O-RAN Alliance and the specification of 5G virtual Radio Access Network (RAN) Open RU (O-RU) whitebox solutions. Developed together with Analog Devices, Intel®, Radisys and Whizz Systems, the first version of an O-RAN compliant O-RU whitebox is now available for testing.

In this whitepaper, we will take a closer look at the new virtualized 5G RAN, the O-RAN Alliance architecture and open fronthaul interfaces as well as an overview of the O-RAN O-RU whitebox solution.

5G Virtual RAN overview

Carriers around the globe are now pushing forward with 5G deployments. First as a supplement to existing 4G Long-Term Evolution (LTE) networks and later in stand-alone configurations.

The non-stand-alone configuration relies on the existing 4G LTE Evolved Packet Core (EPC), but takes advantage of the new 5G RAN and 5G NR to enhance the capabilities of existing mobile networks. See Figure 1 for an overview of the deployment options referencing the 4G evolved NodeB (eNB) and 5G Next Generation NodeB (gNB).

While the business case for 5G is still under discussion, the sheer growth in data consumption is enough to justify deployment of additional micro-cells to keep up with demand, as shown in Figure 2. The challenge for carriers is meeting this demand cost-effectively.

Studies by Ericsson have shown that deploying new 5G NR micro-cells is a more cost-effective means of increasing bandwidth capacity than adding additional 4G LTE micro-cells. This is because 5G NR micro-cells consume much less power than 4G LTE micro-cells.

Figure 1: 5G RAN deployment options

Figure 2 provides a comparison of different combinations of macro and micro cells. Even with the deployment of 5G NR micro-cells in existing 4G macro-cells, a significant reduction in power usage can be achieved.

Figure 2: Power usage for micro cell deployments (source: https://www.ericsson.com/en/blog/2019/9/energy-consumption-5g-nr)

However, as we move to higher frequencies capable of supporting higher data rates, such as millimeter-wave (mmWave), the coverage area is reduced. Network planners mix cells of different frequencies to match projected coverage and data traffic needs.

For a scenario requiring high-bandwidth connectivity in a dense urban area, up to 400 5G mmWave micro-cells are required to cover the same area covered by a single 4G LTE macro-cell today.

This is one of the reasons why carriers expect the 5G RAN to cost more to deploy and operate than 4G LTE and previous mobile generations. Studies by GSMA¹ have shown that the Total Cost of Ownership (TCO) for 5G RAN is expected to increase by 65% compared to current mobile networks, while associated energy costs are expected to rise by 140%. These same studies also show that by virtualizing the RAN and adopting architectures like those proposed by the O-RAN Alliance, it is possible to reduce costs by 25% and enable network sharing that can reduce carrier costs by a further 40%.

But this also requires cost-effective and powerefficient implementations of key, high-volume equipment, such as RUs. The O-RAN Alliance is providing whitebox specifications to address this very issue.

Before taking a closer look at the O-RAN Alliance and O-RAN whitebox solutions, it’s important to understand the motivations and requirements for the new 5G virtual RAN architecture and how O-RAN whitebox solutions directly support these requirements.

Figure 3: Mobile data traffic growth (source: Ericsson mobile data traffic outlook Nov 2019)

Figure 4: Higher frequency but lower range 5G NR

5G Virtual RAN architecture

In 4G LTE, the functions in the eNB are split so that the Baseband Unit (BBU) and the Remote Radio Head (RRH) can be separated physically. This allows the RRH to be located closer to the antenna, while the BBU can be located more centrally. It effectively enables the deployment of 4G LTE micro-cells.

The 5G RAN architecture has taken this concept a step further by splitting the 4G LTE BBU equivalent into a Central Unit (CU) and a Distributed Unit (DU) and allowing packet-based networks to connect multiple DUs to a single CU.

One of the objectives with this additional functional separation is to move more data processing functions closer to the edge particularly real-time functions. More intelligence at the edge enables the RAN to cope with mobile data growth, the billions of connections expected from Internet of Things (IoT) devices as well as provide lower latency connections closer to the user.

As shown in Figure 5, some user plane functions in the 4G LTE core have been moved to the CU and DU, layer 2 (L2) non-real-time and layer 3 (L3) functions have been moved from the BBU to the CU, L2 real-time functions to the DU and layer 1 (L1) functions split between the DU and RU. The mapping of functions to devices results in different “split options” with regard to which layers of the protocol stack are mapped to which device. While the split between CU and DU is now formally defined by 3GPP, there are a number of split options still to be considered for the DU/RU interface, which we will explore later.

Figure 5: Function migration from 4G to 5G

As shown in Figure 6, this new architecture makes it possible to deploy the CU and DU functions related to a specific service either centrally or at the edge close to the RU depending on latency and backhaul bandwidth requirements. This provides greater flexibility in meeting diverse service needs with the same RAN architecture.

The functional split also provides flexibility in managing space, power and cooling challenges in edge datacenters. Many of the datacenters at the edge of the network are old central offices, some over a century old, that have been upgraded to mini-datacenters. Traffic from these edge or tier 1 data centers are aggregated in larger tier 2 regional data centers and then in more central tier 3 data centers.

But there is a limit to how much space, power and cooling is available in old central office buildings. The ability to move functions to a higher tier datacenter with more capacity can lift the burden on these locations under high-load conditions.

To fully exploit the flexibility that the new split function architecture provides, 5G RAN is fully virtualized. This allows CU and DU functions to be implemented as virtual software functions that can run on standard Commercial Off-The-Shelf (COTS) hardware and be deployed in any of the tiered datacenters in the RAN.

Because the functions are virtual, several independent instances can share the same physical resources. This allows several services to be deployed on the same hardware, each with their own requirements and resource needs fulfilled. A service can thus be defined by “chaining” virtual functions together. In 5G, these are referred to as “network slices”, which are a key concept in meeting the diverse end-to-end requirements of several services at the same time.

In Figure 6, three different network slices are shown meeting services with different bandwidth and latency needs. The service chain includes User Plane Functions (UPF), which are responsible for tasks such as packet routing and forwarding, policy enforcement and data buffering. In some instances, the UPF provides access to Multi-Access Edge Computing (MEC) resources, which are virtual compute and storage resources that can be located where required.

Figure 6: CU/DU functions can be deployed at different locations to meet specific service needs

Enabling 5G open interfaces

While the CU/DU split adds a lot of extra flexibility in how services are deployed, there is still an area of cost that needs to be optimized, namely the RU. Today, the interface between the BBU and RU in 4G LTE is proprietary to mobile equipment vendors. It is based on the Common Public Radio Interface (CPRI²) interface, but this is not an open interface today as there are dependencies in the implementation of BBUs and RRHs that require both to be sourced from the same vendor. In addition, it is a costly bottleneck as it is based on transport of digital radio signals directly over a point-to-point optical fiber.

CPRI is adequate when RAN architectures are based on macro-cells alone, but becomes a major cost when a point-to-point fiber connection needs to be made between multiple micro-cell RUs to BBUs installed 20 km away. As the amount of data to be transmitted increases, the cost of the interface also increases. This is because the CPRI interface requires a constant bit rate no matter the load and there is therefore no possibility for statistical multiplexing.

In 2017/18 an update to this interface called enhanced CPRI (eCPRI³) was introduced. The eCPRI interface uses Ethernet as the L2 interface, which allows existing solutions for control, management and synchronization to be used. Ethernet allows packet-based switching and statistical multiplexing of several RU connections onto a single backhaul fiber. This vastly improves the cost of deploying micro-cells.

eCPRI specifies a number of split options in the protocol stack and, as can be seen in Figure 8, these correspond with similar proposals from 3GPP and the O-RAN Alliance.

The lower layer split option 8/E between the radio and PHY interface is the current CPRI fronthaul interface between the BBU and RRU. With eCPRI, it was proposed that a split be made within the L1 PHY interface, known as option 7 or option D, with a number of different “sub-split” options depending on which functionality should be located at the RU or at the DU. This split was proposed as it would reduce bandwidth requirements. However, it is a trade-off as some L1 functionality must be implemented in the RU. The various sub-split options seek the right balance between cost, bandwidth, latency and efficiency.

Figure 7: Comparing CPRI and eCPRI

3GPP has also considered various split PHY interface options, but has not formally adopted an option for the Fronthaul-I interface between the DU and RU.

This means that the fronthaul interface between the DU and RU is still proprietary to the vendor. Carriers are therefore interested in ways to open the Fronthaul-I interface and allow competition on both the DU and RU to improve costs and encourage innovation.

O-RAN and the O-RAN O-RU reference solution

The O-RAN Alliance is directly addressing the carrier need for an open Fronthaul-I interface. The objective of the O-RAN Alliance is to clearly define requirements for an open, virtualized and interoperable RAN. It has defined two core principles to guide this mission, namely openness and intelligence.

In the case of intelligence, the O-RAN architecture has introduced a new type of Software Defined Network (SDN) controller called the RAN Intelligent Controller (RIC), which is responsible for automating the deployment of RAN functions in response to service needs. This includes a nearreal- time (near-RT) RIC and a non-near-real-time (non-RT) RIC. Both RICs make decisions based on analysis of data collected in the network using deep learning and artificial intelligence. See Figure 9 for an overview of the O-RAN architecture.

In the case of openness, the O-RAN architecture is based on well defined, open interfaces to enable interoperability between implementations from multiple vendors. This includes the fronthaul interface between the O-DU and O-RU based on split option 7.2x in Figure 8.

Figure 8: Option 7 sub-splits

Openness is critical to the carrier business case as the fronthaul interface until now has been proprietary to the mobile equipment vendor. This creates a vendor lock-in that carriers want to avoid. By opening the fronthaul interface, it is possible to source DU and RU equipment from different suppliers leading to more competition, more innovation and ultimately, lower costs. For carriers with outsourced turn-key solutions it enables better bargaining power at the next contract renewal. In addition, it allows a DU from one carrier to interface with RUs from other carriers and thus share RAN infrastructure and cost.

There are nine workgroups active in the O-RAN Alliance. Workgroup 7 is responsible for specifications for whitebox implementations of the O-DU and O-RU. Comcores is collaborating with Analog Devices, Intel®, Radisys and Whizz Systems to develop the first open O-RAN O-RU.

Figure 9: O-RAN Architecture

The goal is not just to make an O-RU reference design, but a whitebox implementation that meets stringent carrier requirements and can be deployed today. The first release of the O-RU is now available and will be closely followed by an O-DU whitebox implementation.

The purpose of the RU is to convert radio signals sent to and from the antenna to a digital signal that can be transmitted over packet networks. The three major elements of the RU are the Radio Frequency (RF) function, the lower PHY processing to reduce interface bandwidth and the eCPRI fronthaul interface to map/de-map radio data into the Ethernet protocol. Comcores provides the Intellectual Property (IP) implementation of the partial L1 processing and eCPRI interface as well as a SW API enabling system configuration. For a split 7.2x implementation, the partial L1 processing includes functions for In- Phase/Quadrature (IQ) modulation / demodulation, Fast Fourier and Inverse Fast Fourier Transforms (FFT and iFFT), Physical Random Access Channel (PRACH) filtering as well as Cyclic Prefix (CP) addition and removal. Beamforming is an optional function that can be added.

The eCPRI implementation supports aggregated bandwidth up to 100G. Figure 10 provides an overview of the FPGA design and the Comcores IP.

Figure 10: O-RU FPGA design and Comcores IP

Figure 11 provides an overview of the O-RAN ORU whitebox implementation indicating the contribution from different partners. The O-RAN O-RU implementation is based on the Intel® Arria 10® SoC, which is an FPGA chip with embedded ARM cores and hardened Digital Signaling Processing (DSP) blocks. Analog Devices provides both the Digital Front-End (DFE) and Radio Frequency Front-End (RFFE). Radisys provides protocol stack implementation software. Whizz Systems provides a whitebox integration of the platform that is now available.

Figure 11: O-RAN O-RU whitebox

O-RAN 10/20G Optical Interface Arria® 10 SoC / eASIC SoC ADI ADV902x O-RU Board 3D Rendering of Demo Only Enclosure Demo Only Enclosure Developed in collaboration between

O-RU solution now ready for testing

The O-RAN O-RU whitebox is not just a reference design, but a cost-effective, reliable whitebox implementation that can be tested today. It will enable carriers to begin deployments, safe in the knowledge that the fronthaul interface is open and can be supported by multiple vendors.

At the same time, the whitebox platform provides equipment vendors with a reliable reference design for their own implementations where the availability of hardware and software, such as Comcores IP, can accelerate development efforts dramatically.

Comcores is committed to supporting the O-RAN Alliance and O-RU whitebox development with carrier-grade, reliable implementations that are thoroughly tested. This includes interoperability testing with compatible implementations. In addition, we continue to enhance the solution in anticipation of future needs. This provides both carriers and vendors with a reliable and futureproof platform for their developments and deployments saving development, test and integration time and resources.

Comcores is committed to supporting the O-RAN O-RU roadmap with several releases planned during 2020. The first O-RAN O-RU release is based on Orthogonal Frequency Division Multiplexing (OFDM) numerology 1, which is based on 30 kHz channel width and 2 slots per subframe supporting 4x4 Multiple Input-Multiple Output (MIMO) implementations, also known as 4T4R, without beamforming. This is ideal for small and medium sized cell deployments at sub 6 GHz frequencies. This will be followed by a version supporting 8T8R MIMO configurations and OFDM numerologies 0, 1, 2 and 3. Beamforming and support for up to 16 slots per subframe will then be introduced allowing support of 64T64R MIMO configurations and ODFM 4 for micro-cells based on mmWave spectrum.

OFDM Num	Channel width	Slots per subframe	Slots per frame	Slot duration
0	15 kHz	1	10	1 ms
1	30 kHz	2	20	0.5 ms
2	60 kHz	4	40	0.25 ms
3	120 kHz	8	80	0.125 ms
4	240 kHz	16	160	0.0625 ms

Comcores committed to enabling open 5G interfaces

5G New Radio provides the capacity to support significantly higher data rates and satisfy the relentless growth in mobile data. However, it will require an order of magnitude increase in the number of radio units that need to be deployed. The O-RAN O-RU whitebox developed by Comcores in collaboration with Analog Devices, Intel®, Radisys and Whizz Systems provides the first open implementation of a 5G RU that is costefficient, reliable and ready for deployment.

Comcores is committed to supporting the development of open O-RAN O-RU whitebox implementations. This places Comcores at the forefront of 5G innovation with cutting-edge IP implementations that are now available for vendors who need to accelerate development of their own RU implementations. Using Comcores IP as a foundation for your development ensures that you will stay one step ahead of market requirements with implementations that are thoroughly interoperability tested.

For more information on Comcores IP solutions and access to O-RAN RU IP please contact: sales@comcores.com

1 https://www.gsma.com/futurenetworks/wiki/5g-eramobile-network-cost-evolution/

2 http://www.cpri.info/spec.html Enabling 5G open interfaces

3 http://www.cpri.info/spec.html

If you wish to download a copy of this white paper, click here