5 reasons why 5G needs flexible runtimes
By Tomas Hedqvist
By Tomas Hedqvist
When operators start deploy 5G networks, flexibility is key to keep CapEx low and shorten time-to-deployment. 5G deployments are far more complex than earlier network generations, and we have to meet this with more flexibility in how to design, deploy and configure networks and network equipment. The runtime platform and the underlying hardware are key components to enable this flexibility.
Here are five reasons why you need a flexible runtime platform for 5G RAN applications.
While 4G was designed in a monolithic fashion with both radio and core networks defined and deployed together from day one, 5G is specified for both stand-alone (SA) scenarios and non-standalone (NSA) scenarios where RAN and core from different generations interwork. This gives us a number of different deployment options, which have been specified and studied by for example 3GPP (a good summary is available here).
Most operators will use the possibility for interworking to leverage existing investments, saving CapEx and gaining time-to-market, while being able to add 5G NR capabilities to improve capacity and data rates in densely populated areas, and to pave the way for new use cases. Then they can successively connect a 5G core and add more 5G NR capacity.
It will require flexibility to enable a step-wise approach, adding 5G capabilities to existing infrastructure without major redesigns for every step.
Increased densification and new technologies add to the complexity in the RAN. More hot spots and small cells, multi-hop technologies, and device-to-device communication creates highly heterogeneous networks with diversified resource needs, and new technologies for the air interface like massive MIMO, coordinated multipoint, and beamforming provides a significantly more complex control plane with need for more processing.
With highly shifting needs for the various deployment scenarios and possible air interface technologies, a single, hardwired, solution will not fit all. While it is quite possible to use different platforms for each case, it will be far from economically sound. A well-designed platform needs to scale and be flexible so it can be used in any type of deployment and handle a broad range of connection density and throughput scenarios.
5G adds new use cases that are fundamentally different from each other. Besides Enhanced Mobile Broadband, 5G should also accommodate Ultra-reliable and Low Latency Communications and Massive Machine Type Communications (this was detailed in ITU IMT-2020). Within these three, there are many service scenarios, each with fundamentally different combinations of requirements for connection density, throughput, latency, and reliability.
Depending on where the gNB is deployed, it needs to be configured and optimized for its context. For example, a deployment in an IoT context will need a different configuration from a deployment in a residential area. Ultra-reliable machine type communication moves the need for strict real-time processing up the stack, and shifts the need for resources from the non-real-time domain to the real-time domain.
A solution that relies on a specific hardware implementation for the real-time critical functions will be difficult to adapt to different real-time needs, but a solution that allows resource assignment for both high performance real-time and non-real-time domains to be configured using software only, will be flexible and cost-efficient.
The functional split between the Central Unit (CU) and the Distributed Unit (DU) is a trade-off between throughput, latency, complexity, and flexibility. With a non-ideal fronthaul, operators need to consider factors such as how the distance between DU and CU affects latency, and what the bandwidth need is, before deciding on which split options can be used.
As we can expect advances in fronthaul technology to reduce latency and increase bandwidth, it will enable a move of functionality from the radio site to the central office and eventually into the cloud. This means that runtimes at the radio site and the central office may need to change their balance between real-time and non-real-time functionality.
Again, having a solution with a hardwired real-time domain will not be a cost-effective solution.
Mobile networks are constantly evolving and the first phase of 5G is not the end station. 4G continues to evolve even when 5G is starting to get ready for deployment, so we can expect 5G to continue to evolve for a long time. We do not know what future specifications will look like, or what the requirements on runtimes will be, but we do know that mobile networks will continue to evolve. The work on 3GPP release 16 is ongoing and after that, we will see new releases add new functionality and new requirements. Exactly how specifications and functionality not yet on the drawing board will affect runtimes in the future is of course impossible to know, but when they do, and we can be sure that they will, flexibility is a good insurance for investments in 5G networks.
So how do you achieve this flexibility? There are of course as many answers as there are engineers, but some general guidelines should apply.
A solution that relies heavily on hardware implementations will always be much less flexible than a software solution, especially if it that runs on a general-purpose multicore CPU. Nevertheless, software solutions can be very different in terms of flexibility and sometimes performance requirements will trade off flexibility.
Linux is the "need-to-have" runtime for higher layers in the software stack and to many it is the epitome of runtime flexibility, but it is not capable of providing a deterministic runtime with the required performance in terms of response times and low jitter for time-critical functions in the baseband and radio. This also includes real-time patched versions of Linux. A POSIX compliant RTOS on the other hand can provide a flexible runtime environment for time-critical functions, but it does not provide the ecosystem, familiarity and in most cases also functionality as Linux. It also has to scale well over many cores to be useful in the 5G RAN equipment. Unfortunately, most operating systems only scale up to four cores before performance per core starts to drop drastically. A bare metal loop may be able to provide the performance needed and should be possible to scale (provided it does need to make any system calls), but it will lack the flexibility, portability, and debuggability you get with a proper OS.
There is no silver bullet here, but a software-based Linux acceleration could be the closest thing to it. In essence, an accelerated Linux solution allows both time-critical and non-time-critical functions to share a homogenous multicore SoC. A real-time executive running on a partitioned set of cores provides a deterministic runtime for time-critical functions and Linux provides a runtime for functions with relaxed timing requirements. With dynamic assignment of cores to real-time and Linux domains, it allows a very flexible resource allocation for functions with different real-time requirements.