How to get the most out of 5G mid-band in Cloud RAN
Head of Product Line, Cloud RAN
Head of Technology, Cloud RAN
Head of Product Line, Cloud RAN
Head of Technology, Cloud RAN
Head of Product Line, Cloud RAN
Head of Technology, Cloud RAN
Starting a new exciting journey
To provide a great customer experience, most of today’s 5G deployments rely on mid-band and it is critical for communications service providers to optimize these deployments to get maximum benefits.
In this blog post we will show how Ericsson addresses the 5G mid-band challenges leveraging cloud infrastructure, giving service providers some food for thought and discuss necessary considerations required for a successful solution:
- What are the challenges on mid-band deployment and how could they be solved in a cloud infrastructure?
- How can we leverage the design philosophy and in-depth experience from the Ericsson Radio System into Cloud RAN?
- What are the implications of differences in processing need between low-band and mid-band?
- How can we reflect cloud infrastructure aspects into total cost of ownership (TCO) evaluations?
Contemplating the questions above, let us begin the journey together: mid-band using cloud infrastructure – the beginning of a fascinating journey.
Solving the mid-band coverage challenge
5G mid-band runs on wide band Time Division Duplex (TDD) spectrum below 6GHz delivering the high capacity promised by 5G. However, due to shorter wavelengths, it provides less coverage compared to low-band. The limiting factor is the uplink and Ericsson has two main solutions to address this challenge – Uplink Booster and 5G carrier aggregation.
Uplink Booster
Uplink Booster is an innovative solution available in Ericsson Radio System today, that increases coverage on 5G mid-band by moving the uplink beamforming processing from the baseband to the massive MIMO radios, where it runs on Ericsson Many-Core Architecture (EMCA). This creates up to 10dB gain, equivalent to a 3.7x extension of coverage area, improved uplink throughput and higher spectral efficiency.
Technically, Uplink Booster is based on the Ericsson lower layer split (E-LLS) which makes it possible to split the processing of the protocol stack and offload a big part of the layer 1 processing to the radio unit, in particular the instantaneous channel estimation and the full interference rejection combining (IRC). In addition, we use the evolved common packet radio interface (eCPRI), which significantly reduces the fronthaul data requirements by 90 percent. This is an example of a key advantage in our solution, which applies for both Ericsson Radio System and Cloud RAN.
Coverage extension with 5G carrier aggregation
Carrier aggregation in 5G is another powerful solution in the Ericsson portfolio. Our resolution is to decouple the downlink from the uplink, keeping the downlink data on the mid-band while the uplink data, and the control plane, are moved to the low-band. In simple words, when combining mid-band with low-band, the uplink, which is normally weaker, will reach the base station on low-band 5G, which travels longer. And the 5G mid-band signal will travel as far as the base station allows, ensuring also an extended coverage, without any limitation from a weaker signal from the user equipment.
This has two primary benefits:
- Coverage increases with low-band’s longer reach, adding 7dB gain, translating to extend the coverage area by 2.5x, compared to dual connectivity deployments.
- The overall network capacity increases about 27 percent, due to the extended mid-band coverage, so we can also offload traffic on to the mid-band.
As we look to bring 5G carrier aggregation to Cloud RAN, we build on the in-depth knowledge, experience and innovations gained in Ericsson Radio System. Always building for the future, our comprehensive portfolio of Ericsson Radio System and future Cloud RAN solutions works seamlessly together.
Another value of our portfolio is the high output power radios for mid-band, designed to cope with the challenge of the high-demanding processing and coverage in mid-band. Typically, each megahertz (MHz) of bandwidth requires 2 watts (W) in output power. With the 100MHz bandwidth in the mid-band, this translates to radios which can deliver at least 200W. With our portfolio service providers have a one stop-shop with high output power radios and high performance for both Ericsson Radio System and Cloud RAN deployments.
Processing for mid-band compared to low-band
In previous blogposts we have discussed the processing power needed for 5G mid-band compared to low-band. Below, we examine how a combination of cloud infrastructure and accelerators can tackle this processing challenge.
The processing needed for a fully loaded, low-band cell on a commercial-off-the-shelf (COTS) server, excluding processing for operating system and common functions, is roughly 1 core. Comparing to a fully loaded, mid-band cell without any accelerator this would be about 16 cores. The difference in processing volume comes from the amount of data produced and consumed in the mid-band system, differences in bandwidth, layers and traffic models. It is roughly 20 times larger in downlink compared to a low-band cell (see figure 1 for rough calculation).
| Bandwidth | Layers in DL | Layers in UL | Total DL bandwidth (Bandwidth x layers) | Total UL bandwidth (Bandwidth x layers) | |
| Low-band | 20 MHz | 4 | 1 | 80 MHZ | 20 MHz |
| Mid-band | 100 MHz | 16 | 8 | 1600 MHz | 800 MHz |
| -20x processing need | -40x processing need |
Figure 1. Comparing mid-band versus low-band processing needs
A pure soft x86 based implementation for mid-band is not commercially viable in a deployment scenario in line with expected traffic growth due to this massive processing need. However, offloading processing of certain layer 1 functions to more specialized hardware, so-called accelerators, will make RAN on cloud infrastructure viable also for mid-band.
It is vital to consider the complete picture when dimensioning your cloud infrastructure. Communications service providers need to consider processing requirements for radio functions but also the processing required for management, orchestration, fronthaul and backhaul termination and handling the life cycle of the components in the system.
In these kinds of disaggregated systems, there is a thin line between over and under dimensioning. A strategic choice must be made to either create processing head room for new features and users in the system or to have a tighter dimensioning of hardware which would limit physical footprint and power consumption. Either way, it is important to take careful consideration of target deployment scenarios and expected traffic growth.
Choice of accelerators
One important aspect of accelerators is programmability. In general, a fully programmable solution is the best and most versatile solution for scalability, which could be automated based on traffic load and current communications service providers’ needs. That said, in the end there will be a trade-off between programmability and compute efficiency – a more hardened solution will always be more efficient at the cost of less flexibility. There are different propositions in the market when it comes to acceleration architecture and hardware. The accelerator hardware typically used are Field Programmable Gate Arrays (FPGA), Graphics Processing Units (GPUs), or Application-Specific Integrated Circuits (ASICs).
Looking at the architecture for layer 1 acceleration, there are two fundamental approaches - look-aside acceleration and inline acceleration.
The principal difference between them is that in look-aside acceleration, only selected functions are sent to the accelerator, and then back to the CPU while in inline acceleration parts of or the whole data flow and functions are sent through the accelerator (see figure 2).
Figure 2. Illustrating look-aside versus inline acceleration
Look-aside acceleration
In the case of look-aside acceleration, the CPU is free to use its cycles to process other useful tasks, while the accelerator is working on the data to be accelerated. Once the CPU receives processed data back from the accelerator, it can switch back to the original processing context and continue the pipeline execution until the next function to be accelerated comes up.
The look-aside acceleration requires massive data transfer between CPU and accelerator and therefore a tight integration is preferred.
Inline acceleration
In the inline acceleration case, a part of or the entire layer 1 pipeline can be offloaded to the accelerator, potentially allowing for a less data heavy interface between CPU and accelerator. The acceleration solution can in this case be a mix of programmable and “hard” blocks, again there is a trade-off between flexibility and efficiency.
The importance of openness
The market for Cloud RAN is still in its early days and acceleration solutions will evolve over time. Ericsson believes that, it is important to ensure a range of available acceleration options in the ecosystem. The ideal state in a truly disaggregated system is complete independence of software and hardware selection. In practice, the differences in architecture between look-aside and inline acceleration require software adaptation to maximize performance. Therefore, Ericsson is actively contributing to O-RAN Alliance´s working group 6 (WG6) with the ambition to allow for specification of many accelerator profiles and open capability negotiation between hardware and software.
Optimizing TCO with container deployments on bare metal
The usage of accelerators reduces significantly the number of CPU cores needed in the cloud infrastructure. To further reduce footprint, increase processing efficiency and achieve lower TCO, we believe, the current best approach is using Kubernetes containers on bare metal. Kubernetes has emerged as the platform of choice for deploying cloud-native applications. To run this on bare metal, which essentially means removing the virtualization layer (see figure 3), is a natural development of the industry.
Figure 3. Comparing Kubernetes on virtual machines versus on bare metal
Ericsson has compared deploying our cloud-native applications on virtual machines or on bare metal. The analysis shows that it’s possible to achieve TCO savings of at least 30% in the bare metal scenario. The savings impact both the CAPEX and OPEX side.
From a CAPEX perspective, there are three main savings. Firstly, a more efficient hardware utilization, leading to a reduced footprint. Secondly, a higher application efficiency, translating into a 10-20% performance advantage over virtual machines. Finally, the elimination of virtual machine specific fee with simplified cost structure.
From an OPEX perspective, there are also three main savings. Firstly, the software upgrades are faster and simplified, as virtual machine layer and associated upgrade complexities are eliminated. Secondly, there is a unified competence across applications, since the system is less diversified. Finally, the life-cycle management of the system is simplified, as the application onboarding is unified.
Checklist for communications service providers considering a Cloud RAN deployment in mid-band
We have now exposed the main perspectives of 5G mid-band deployments using cloud infrastructure. In summary, we see six key points, which service providers should keep in mind.
- Extending coverage on 5G mid-band by leveraging the low-band is vital to meet the needs and expectations of users.
- A high-performing mid-band deployment requires high output power radios with high demands on processing.
- Dimensioning of the cloud infrastructure should take the whole picture into account and consider processing needs for future scenarios.
- Cloud infrastructure is a feasible option for mid-band with the addition of hardware accelerators.
- Choice of accelerators is a strategic decision and depends on communications service provider´s deployments and traffic scenarios.
- Cloud-native deployments on bare metal versus virtual machine deployments will increase efficiency and lower TCO.
Ericsson’s powerful portfolio brings Cloud RAN to 5G mid-band
5G mid-band will be a critical building block for any service provider. We stand by communications service providers as a guide in their future mid-band journey towards Cloud RAN, supporting in strategic decision making and delivering a comprehensive and powerful portfolio in line with time frames required by leading customers.
In order to solve the 5G mid-band coverage challenge, we build on our in-depth radio knowledge to develop high-performing future Cloud RAN solutions, leveraging our design philosophy and feature set for Ericson Radio System, such as Uplink Booster and 5G carrier aggregation. Adding an extra boost, our high output powered radios enable communications service providers to fully utilize the larger bandwidth for maximum performance. By using Kubernetes on bare metal, we can also reduce the TCO for Cloud RAN significantly.
Ericsson stands ready to guide its customers to get most out of mid-band 5G on Cloud RAN.
Watch the Mid-band considerations for Cloud RAN video
