5G-EmPOWER

Description

5G-EmPOWER is an open platform for agile 5G service development. The goal of 5G-EmPOWER is to provide an open ecosystem where new 5G services can be tested in realistic conditions. 5G EmPOWER supports both WiFi and LTE networks and can interface with state–the–art SDN controllers using an intent–based interface. A Python–based SDK allows network programmers to write and deploy advanced control tasks as Network Apps.

Fig. 1. The high-level view of the 5G-EmPOWER architecture.

The system architecture of 5G-EmPOWER follows the SDN structure defined and is composed of three layers: user plane, control plane and management plane (Fig. 1). The user plane encompasses the network elements in the RAN, including LTE eNBs, Wi-Fi Access Points (APs), and pos- sibly 5G gNodeBs (gNBs). The control plane consists of the 5G-EmPOWER Operating System (OS), which is connected to the 5G-EmPOWER Agents, one for each network element in the RAN (the reason for using the term operating system will be clarified in the next section). The 5G-EmPOWER Agents receive the commands and configuration instructions issued by the operating system using the OpenEmpower Protocol which acts as southbound API (i.e., like the OpenFlow protocol for wired networks), and provides it with statistics and events from the network elements. Operation, administration and management applications reside at the management plane, which communicates with the control plane through the northbound interface.

The northbound interface provides useful abstractions for RAN management applications allowing them to access and manipulate the state of the network without dealing with the complexity of the underlying radio technology, thus enabling a vertical management design. In addition, it isolates and protects users and applications from each other, offering them a secure and dedicated view of the network. The applications supported by 5G-EmPOWER range from basic monitoring applications that simply gather statistics from the network elements and report them to other applications (e.g., monitoring applications like Prometheus), to full-fledged radio resource management applications implementing complex Self-Organizing Network (SON) features.

5 G-EmPOWER builds upon a set of high-level programming abstractions providing developers with full visibility of the network state and allowing them to dynamically deploy and orchestrate network services, i.e.:

• Centralized Mobility Management for Wi-Fi and LTE Networks;
• Active Slicing, deploying custom resource allocation schemes;
• Lightweight Virtualization managed and orchestrated;
• Edge Computing support thought local breakout.

The 5G-EmPOWER Operating System provides a framework for managing heterogeneous RANs using the OpenEmpower protocol together with a collection of built-in functionalities and services that are useful to write management applications. The high-level view of the architecture is sketched in Fig. 2.

Fig. 2. The 5G-EmPOWER Operating System.

The 5G-EmPOWER Operating System is implemented in Python using the Tornado Web Server as web framework. The main reason for choosing Tornado is its non-blocking network I/O, which allows serving incoming requests while others are being processed. Managed memory, no-compilation time, dynamic typing, and precise error reporting are just some of the reasons that led us to pick Python as language of choice for 5G-EmPOWER to maximize the developers’ productivity. Moreover, the figure depicts three important service modules, namely:

1. Device Manager Service. Tracks the eNBs active in the RAN. This includes the IP address, the identifier, the last seen date, and the list of capabilities. The device manager also exposes an API allowing applications to receive events when new eNBs join or leave the network.
2. Topology Discovery Service. Collection of modules that combines data from UE measurements (RSRP/RSRQ), eNB measurements, and external sources (e.g., spectrum databases) to build the Global Network View that can then be used by applications to implement management policies. Moreover, it allows retrieving network information as a list of links and nodes and registering events to be notified when links are added or removed.
3. Web Service. This module provides the interface that al- lows users to interact with the 5G-EmPOWER Operating System. The module is split into two submodules: the REST server and the front-end Graphical User Interface (GUI). The benefit of this approach is the independence from the GUI given that any client that can consume a REST service can interact with the Operating System.

Application Programming Interface (API). The API defined by the 5G-EmPOWER Operating System has been designed with the express goal of shielding developers from the implementation details of the underlying wireless technology. Domain Specific Languages (DSLs) are known to be particularly suitable in such cases given that are tailored to a specific application domain. Common examples are the Cascade Style Sheet, used for formatting web pages, or SQL, used for relational databases. DSLs enable writing very concise programs. For example, implementing a handover for the UE ue to the cell cell could be a simple assignment operation ue ← cell. DSLs impose a high entrance barrier and may not support the most common programming constructs expected from modern programming languages. Conversely, a language like Python enables certain language features (meta-programming), which allows writing code that resembles the domain-specific DSL syntax (these DSLs are typically called embedded or internal DSLs).

Modular Architecture. With the exception of the logging subsystem (which must be available before any other module is loaded), every task supported by the 5G-EmPOWER Operating System is implemented as a plug-in (i.e., a Python module) that can be loaded at runtime. Modules can be built-in and launched at bootstrap time or started and stopped at runtime. Each module consists of a Manifest file containing the module meta-data (version, dependencies, etc.), and one or more Python scripts. Every module is required to implement a launch method called when the module is loaded in order to perform the initialization tasks. The parameters accepted by the launch method are defined by the module.

Developers are free to decide how their network management applications are deployed. For example, an application can be spread across several modules or can be implemented in a single one. This approach is similar, in principle, to the Network Function Virtualization (NFV) paradigm, where com- plex services can be deployed by combining several Virtual Network Functions (VNFs). Likewise, in the 5G-EmPOWER Operating System, complex network management applications can be designed by instantiating different modules. This allows setting up a network monitoring application to perform a site survey or to roll-out new features at runtime by selecting them from an “app store”. Figure 2 shows a scenario where the 5G-EmPOWER Operating System is running three applications across two network slices with one application (the Mobility Manager) instantiated on both slices.

Slicing. Network slicing enables the creation of logical networks customized with precise network resources and isolation properties, optimized to fulfil diverse performance requirements and to operate independently on a common infrastructure. Following this idea, 5G-EmPOWER leverages network programmability to extend the SDN slicing concept of the wired domain to the wireless access segment in the case of the LTE RAN. The solution aims at ensuring efficient sharing of the physical infrastructure by different services providers. In particular, we assume that an infrastructure provider owns the physical LTE eNBs, which are leased to the service provider. However, details about pricing, although important, are out of the scope of this paper. Finally, notice that although the proto- type focuses on LTE RANs, the design principles are general and easily extensible to other radio access technologies.

The 5G-EmPOWER Operating System can accommodate multiple virtual networks or slices on top of the same physical infrastructure. Our slicing mechanism aims at achieving three goals: (i) performance isolation, (ii) slice customization, and (iii) efficient resource utilization. The first goal means that misbehaving slices should not affect the performance of other slices. The second goal means that slices should be allowed to freely allocate their resources. The third goal means that the slicing operation must efficiently use the radio resources.

Slices are created from a slice descriptor provided by the slice owner to the infrastructure provider, which specifies the Service Level Agreement (SLA) and the list of UEs to be mapped to each slice. The SLA identifies the service level requirements requested by the slice owner (e.g., the aggregated throughput, the number of PRBs, etc.). The 5G-EmPOWER Operating System does not enforce a particular SLA. Instead, a flexible framework is provided in order to allow implementing customized admission control and radio resource allocation mechanisms. A high-level representation of the 5G-EmPOWER slicing model is depicted in Fig. 3. We shall now describe all the components in detail.

Fig. 3. The 5G-EmPOWER slicing model.

The Slice Resource Manager is responsible for the life-cycle management of the slices in a given eNB. Upon receiving a request for creating a new slice, the slice resource manager checks if the slice can be accepted using the admission control mechanism defined by the infrastructure manager. For example, if the resource allocation is done in terms of PRBs, the slice resource manager checks if there are enough PRBs to allocate the new slice. As a result, the slice is either admitted of rejected due to insufficient resources.

The Hypervisor is in charge of allocating the resources to each slice in order to meet their SLA. Specifically, it translates physical resources into virtual resources and hands them to a Slice Specific Scheduler. The decisions made by the Slice Specific Scheduler (which operates on virtual resources) are translated into physical resource commands by the Hypervisor before being delivered to the data plane. Every scheduling window, the Hypervisor computes the resources to be allocated to each slice. The scheduling window is a per-slice configurable parameter with the duration of a Transmission Time Interval (TTI), i.e., 1ms, or any of its multiples (e.g., 10ms or 100ms).

Each slice can use a different policy to schedule its UEs. Slice owners can select the UE scheduler from a list of available schedulers or can provide a new one as a plug-in. Notice that the Hypervisor gives to the Slice Specific Scheduler an abstracted view of the radio resources. This view includes only the resources available to that specific slice and thus omits those that are either allocated to other slices or dedicated to other purposes, e.g., random access, broadcasting, and control channels. The resource distribution of a slice is purely virtual and does not specify where they will be allocated in the physical resource grid. This allows the Hypervisor to re-assign the physical resources allocated to each slice in real-time.

TRL 4 – System Adequacy Validated in Simulated Environment

All the 5G-EmPOWER components are released under an APACHE 2.0 License.

5G-EmPOWER has been partially supported by the following projects:

• 5G-CARMEN – Connected and Automated Road Mobility in the European union https://www.5gcarmen.eu/
• Coherent – Control and Coordination Plane for heterogenous 5G Radio Access Networks https://5g-ppp.eu/coherent/
• SESAME – Management and Orchestration in Multi-access Edge Computing scenarios https://5g-ppp.eu/sesame/
• 5G ESSENCE – Embedded Network Services for 5G Experiences https://5g-ppp.eu/5g-essence/