Towards building Cloud-Native Radio Access Network using OpenAirInterface

Towards building Cloud-Native Radio Access Network using OpenAirInterface

Navid Nikaein, Christian Bonnet, Raymond Knopp, Adlen Ksentini, Florian Kaltenberger, Rohit Gupta

1467471996

Abstract:

Commoditization and virtualization of wireless networks are changing the economics of mobile networks to help network providers, e.g. Mobile Network Operator (MNO), Mobile Virtual Network Operator (MVNO), move from proprietary and bespoke hardware and software platforms towards an open, cost-effective, and flexible cellular ecosystem. In addition, rich and innovative local services can be efficiently materialized through cloudification by leveraging the existing infrastructure. In this whitepaper, we present a Radio Access Network as a Service (RANaaS), in which a Cloudified Centralized Radio Access Network (C-RAN) is delivered as a service. RANaaS describes the service life-cycle of an on-demand, elastic, and pay as you go RAN instantiated on top of the cloud infrastructure. We describe an example of real-time cloudifed LTE network deployment using the OpenAirInterface (OAI) LTE implementation and OpenStack running on commodity hardware.

Introduction:

It is possible today to run LTE RAN functions of software implementation over General Purpose Processors (GPPs) on Intel/ARM, rather than the traditional implementation over Application-Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), or Field-Programmable Gate Arrays (FPGAs). Different software implementations of the LTE base station, which is referred to as evolved Node (eNB), already exist:

  1. OpenAirInterface (OAI) developed by EURECOM, which is an open-source Software Defined Radio (SDR) implementation of both the LTE RAN and the Evolved Packet Core (EPC) [1].
  2. Amarisoft LTE solution, which is a pure-software featuring a fully-functional LTE eNB [3],
  3. Intel solutions featuring energy efficiency and high computing performance using a hybrid GPP-accelerator architecture and load-balance algorithms among a flexible IT platform [2] and

This whitepaper describes recent developments within OpenAirInterface community towards running fully open source RAN/Core Network solution based on different cloud environments, for example (KVM, LXC, Docker). We also show some of our recent work towards integration of OpenAirInterface with other open source tools like JuJu service modeling tool  [4] for remote orchestration and deployment over OpenStack and other private cloud service providers such as VMWare, Amazon AWS, Microsoft Azure, etc.

Deployment Challenges of Cellular RAN within Virtualized environments:

A typical general purpose operating system (GPOS) is not designed to support real-time applications with hard deadline. For instance, Linux is not a hard real-time operating system as the kernel can suspend any task when a desired runtime has expired. The kernel uses a scheduling policy that decides on the allocation of processing time to tasks. A scheduler that always guarantees the worst case performance (or better if possible) and also provides a deterministic behavior (with short interrupt-response delay of 100 µs) for the real-time applications is required. Recently, a new scheduler, named SCHED DEADLINE [6], is introduced in the Linux mainstream kernel that allows each application to set a triple of (runtime [ns]; deadline [ns]; period [ns]), where runtime ≤ deadline ≤ period. The scheduler is able to preempt the kernel code to meet the deadline and allocates the required runtime (i.e., CPU time) to each task period. A good deadline scheduler can simplify C-RAN deployment, because Software-based Radio providing RAN in software is a real-time application that requires hard deadlines to maintain frame and subframe timing. In the C-RAN setting, the software radio application runs on a virtualized environment, where the hardware is either fully, partially, or not virtualized. Two main approaches exist to virtualization:

  1. Virtual machines (e.g., Linux KVM, Xen): In a virtual machine (VM), a complete operating system (guest OS) is used with the associated overhead due to emulating virtual hardware, whereas containers use and share the OS and device drivers of the host. VMs rely on the hypervisor to requests for CPU, memory, hard disk, network and other hardware resources; containers exploit the OS-level capabilities.
  2. Containers (e.g. LXC, Docker): Containers preserve the advantage of virtualization in terms of flexibility (containerize a system or an application), resource provisioning, decoupling, management and scaling. Thus, containers are lightweight as they do not emulate a hardware layer (share the same kernel and thus application is native with respect to the host) and therefore have a smaller footprint than VMs, start up much faster, and offer near bare metal runtime performance. This comes at the expense of less isolation and greater dependency on the host kernel.

Fig. 1: Comparison of a virtual machine and container virtualized environments

Fig. 1: Comparison of a virtual machine and container virtualized environments

 

Two other important aspects when targeting RAN virtualization are:

  • I/O Virtualization: I/O access is a key for a fast access to the fronthaul interface and to the hardware accelerators that might be shared among BBUs. In hypervisor approach to virtualization (i.e., VM), IO virtualization is done through the hardware emulation layer under the control of hypervisor, where as in a container this is materialized through device mapping.
  • Service composition of the software radio application: A radio application can be defined as a composition of three types of service [7], atomic service that executes a single business or technical function and is not subject to further decomposition, composed service that aggregates and combines atomic services together with orchestration logic, and support service that provides specific (often common) functions available to all types of service. An atomic service in RAN can be defined on per carrier, per layer, per function basis. For instance, a radio application could be defined as a composition of layer 1 and layer 2/3 services supported by a monitoring as a service.

New trends in C-RAN signal processing

There are several critical issues in processing radio access network functions in the cloud. We outine some of the ky industry trends below:

New functional splits between BBU and RRH:

To reduce the fronthaul data rate requirements, optimal functional split is required between BBU and RRH. This depends on the deployment of the cell load, spatial multiplexing (number of UEs / RE / RRH, e.g. MU detection and CoMP), and scenario and can be dynamically assigned between RRH and BBU. In addition some non-time critical function may be performed at a remote cloud. Three principles must be considered while retaining the benefit of coordinated signal processing and transmission, namely:

  • minimize the FH data rate,
  • minimize the split on the time-critical path,
  • no split of the deterministic functions.

The proposed split is shown in Fig. 2. Recently, IEEE has formed NGFI working group to standardize 5G fronthaul architecture and interfaces [8]. We also recently published a whitepaper recently on the work done by OpenAirInterface Software Alliance (OSA) around implementation of IEEE NGFI [12] within the context of an alliance project led by our community.

Fig. 2: Functional split between BBU and RRH

Fig. 2: Functional split between BBU and RRH

 

What are the processing requirements for SISO LTE 20 MHz?

Based, on studies conducted within OAI, we have estimated that LTE-FDD 20 MHz cell can fit easily on single-core of current generation data-center Intel CPU with AVX2/AVX3 capabilities running at 3GHz. With investments from Intel to place FPGAs inside their data-center CPU, the CPU requirement to run RAN in data center will go down significantly thus making cloudified RAN a reality [13].

Potential Architectures of C-RAN

While from the operators’ perspective such architecture have to meet the scalability, reliability/resiliency, cost-effectiveness requirements, from the software-defined RAN, two key requirements have to be satisfied:

  • Real-time deadline to maintain both protocol, frame and subframe timing, and
  • Efficient and elastic computational and I/O resources (e.g. CPU, memory, networking) to perform intensive digital signal processing required, especially for different transmission schemes (beamforming, MIMO, CoMP, and Massive MIMO).

Broadly, three main choices are possible to design a RAN, each of which provide a different cost, power, performance, and flexibility trade-offs.

  • Full GPP: where all the processing (L1/L2/L3) functions are software-defined. According to China Mobile, the power consumption of the OAI full GPP LTE modem is around 70W per carrier [9].
  • Accelerated: where certain computationally-intensive functions, such as turbo decoding and encryption/decryption are offloaded to a dedicated hardware such as FPGA, GPU, and/or DSP. The remaining functions are software-defined and performed on the host/guest OS. In this case, the power consumption can be reduced to around 13–18W per carrier [9]. Recently, Intel has been touting integration of Alterra FPGA in its next generation data center chips [13].
  • System-on-Chip: where the entire Layer 1 is performed in a dedicated hardware (e.g. a SoC), and the layer 2 functions are run on the host/guest OS. This can reduce the power consumption to around 8W per carrier [9].

As shown in Fig. 3, the hardware platform can either be a full GPP or a hybrid. However, full GPP approach to RAN brings the required flexibility in splitting, chaining, and placement of RAN functions while meeting the real-time deadlines along with the following principles:

  • NFV and Micro service Architecture: breaks down the network into a set of horizontal functions that can be bundled together, assigned with target performance parameters, mapped onto the infrastructure resources (physical or virtual), and finally delivered as a service. Micro-service architecture is in opposition to the so-called “monolithic” architecture where all functionality is offered by a single logical executable. It has to be noted that the micro-service architecture supports the ETSI NFV architecture [10], where each VNF can be seen as a service.
  • Scalability: monitors the RAN events (e.g. workload variations, optimization, relocation, or upgrade) and automatically provision resources without any degradation in the required/agreed network performance (scale out/in).
  • Reliability: shares the RAN contexts across multiple replicated RAN services to keep the required redundancy, and distribute the loads among them.
  • Placement: optimizes the cost and/or performance by locating the RAN services at the specific area subjected to performance, cost, and availability of the RF front-end and cloud resources.
  • Multi-tenancy: shares the available spectrum, radio, and/or infrastructure resources across multiple tenants (MNOs, MVNOs) of the same cloud provider,
  • Real-time Service: allows opening the RAN edge service environment to authorized third-parties to rapidly deploy innovative application and service endpoints. It provides a direct access to real-time radio information for low-latency and high-bandwidth service deployed at the network edge.

Fig. 3: Potential C-RAN architectures

Fig. 3: Potential C-RAN architectures

 

OpenStack based cloud architecture for the LTE RAN

In cloudified C-RAN, the BBU becomes software-based, hence the concept of C-RAN cloudification in which the BBU life-cycle is managed through a cloud operating system and run over the cloud infrastructure. This approach may become an important business connection between mobile telephony operators and cloud providers. Generally, a cloud provider delivers their (publicly available) service in the form of three different flavors, namely Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS) [14]. To this end, we show in Fig. 4, how OpenStack can be used to deploy LTE RAN with modifications to allow real-time execution to meet hard deadlines of RAN. In order to automate deployment, we can employ JuJu [4] and Metal As a Service (MAAS) [11] to program physical cloud compute nodes and provide the concept of programmable cloud that dynamically adjusts the cloud region size.

Fig. 4: OpenStack management architecture

Fig. 4: OpenStack management architecture

C-RAN prototype based on OpenStack/JuJu

We demonstrate here RANaaS proof-of-concept (PoC) (c.f., the architecture presented in Fig. 5). Our cloud infrastructure consists of the OpenStack orchestrating software with appropriately designed compute servers. For cloud orchestration, OpenStack developed a Heat module that provides a human and machine accessible service for the management of the entire life-cycle of a virtual infrastructure and applications. This orchestration engine relies on text-based templates, called Heat Orchestration Templates (HoTs), to manage multiple composite cloud applications and organize them as a stack of virtualized entities (e.g. network, LXCs) called the Heat stack. Our demonstration has to instantiate an EUTRAN part, evolved packet core (EPC), and home subscriber server (HSS). The EPC consists of a mobility management entity (MME) as well as a Serving and Packet data network Gateway (S/P-GW). Mobile Operators (e.g., MNO, MVNO) use the User Interface (UI) to manage the life-cycle of RANaaS. The Service Manager (SM) component receives user queries from the UI and manages the cloud execution through the Service Orchestrator (SO) component, which leverages the use of the Heat API for cloud orchestration. In the demonstrated scenario, a HoT file describes the whole virtual infrastructure including the LTE network elements as well as the required network setup tailored to a specific business case.

Fig. 5: RANaaS prototype (left) and hardware setup (right)

Fig. 5: RANaaS prototype (left) and hardware setup (right)

Fig. 6 shows the RANaaS life cycle management within OpenStack cloud. In this figure, SM/SO indicates Service Manager/Service Orchestrator, while Keystone and Heat Orchestrator are OpenStack services; the box OpenStack refers to other OpenStack services such as Compute, Storage, Networking, etc. With the help of the UI, the MNO first designs the HoT and spawns other actions such as Deploy, Provision, Manage, and Disposal, which is then managed by the SM/SO that communicates with the Heat Orchestrator.

Fig 6: The RANaaS life-cycle management

Fig 6: The RANaaS life-cycle management

Conclusions

In this whitepaper, we have shown several architectural challenges for future C-RAN for 5G and how we are building an open source C-RAN reference platform using OpenAirInterface along with other open source projects, like OpenStack and JuJu,. C-RAN is a cost effective, scalable, energy efficient, and flexible service for MNOs and MVNOs. The current generation LTE standard requirements can be translated in terms of various requirements for C-RAN including fronthaul properties, processing software latencies, and real-time capabilities of the operating system. OpenAirInterface also allows evaluation of C-RAN in various execution environments such as dedicated Linux, LXC, and KVM. We also described the properties of RANaaS focusing on the radio-processing organization and micro-service, multitenant architecture. The whitepaper also describes the cloud architecture for LTE RAN and focused on the C-RAN prototype and its life-cycle management. As we move towards 5G, we intend to mature OpenAirInterface towards future 3GPP releases and work closely with different chip vendors Intel/ARM and other open source communities (OSM, OpNFV, ONOS) and drive their requirements to natively run 5G RAN/Core Networks in the cloud. And all this is driven by community effort which leads to industry convergence on best practices and right architecture for deploying 5G networks in the cloud.

References:

[1] OpenAirInterface, http://www.openairinterface.org

[2] http://www.slideshare.net/opennetsummit/ons2013-rose-schoolerintel-corporation

[3] Amarisoft, http://amarisoft.com/

[4] JuJu, www.ubuntu.com/cloud/jujuok

[5] Towards Cloud-native RAN, Book Chapter of “Studies in Big data”; Springer 2016. http://www.eurecom.fr/en/publication/4843/detail/towards-a-cloud-native-radio-access-network

[6] http://www.kernel.org/doc/Documentation/scheduler/sched-deadline.txt

[7] Mobile Cloud Networking (MCN): an FP7 IP project co-funded by the European Commission. http://www.mobile-cloud-networking.eu.

[8] IEEE NGFI, 1913. https://standards.ieee.org/develop/wg/NGFI.html

[9] China Mobile Research Institute: C-RAN White Paper: The Road Towards Green RAN. http://labs.chinamobile.com/cran

[10] ETSI: Network Functions Virtualisation (NFV), White paper. Tech. rep., ETSI (2014)

[11] http://www.ubuntu.com/cloud/maas

[12] OpenAirInterface (OAI) NGFI Whitepaper. http://www.openairinterface.org/?page_id=1695

[13] Intel Next Generation Datacenter chips with FPGAs, http://www.enterprisetech.com/2016/03/23/intel-facebook-accelerate-datacenters-fpgas/

[14] Oracle: Oracle Cloud, Enterprise-Grade Cloud Solutions: SaaS, PaaS, and IaaS. https://cloud.oracle.com/home

[15] Intel DPDK, http://dpdk.org/