Orchestrating 5GC in Distributed Cloud Networks
Anwer Al-Dulaimi, EXFO, Canada and Qiang Ni, Lancaster University, UK
IEEE 5G Tech Focus: Volume 2, Issue 1, March 2018
The network function virtualization (NFV) is a concept to virtualize mobile network appliances from proprietary hardware to run as guest software applications on standard commercial servers. In the cloud environment, a hypervisor is computer software that provides guest applications with the necessary virtual resources and interfaces to function at performance. The orchestrator platform provides the workflow engine that automates hypervisor operations and integration with third-party tools. In this article, we identify scenarios for orchestrating the fifth-generation core network (5GC) to manage network services in distributed cloud architecture. We show how orchestrators and hypervisors can support sliced and scalable virtual 5GC at both core and edge network sites.
The NFV is a paradigm shift from known mobile networks to cloud-based networks, where all network clusters are chained through a series of datacenters in the form of the distributed cloud. Similarly, the emergence of software defined networking (SDN) transforms the network topology from physically connected entities to software-controlled connectivity that adapts in response to traffic fluctuations. The NFV/SDN is one of the significant solutions to improve the resource allocation and system scalability in future 5G networks. However, there is a strong need to dive more at the system level to investigate the migration process from hardware equipment and embedded software to native cloud environment. The first component for virtualizing mobile network architectures is the large datacenters that host tenant applications . A datacenter consists of many commercial servers with diverse specifications and a connection to the Internet. These datacenters can be owned by the mobile operators to improve security of information or cab even be provided by 3rd party suppliers as a cloud service: Software as a Service (SaaS), Platform as a Service (PaaS), or Infrastructure as a Service (IaaS). The second component is the hypervisors that abstract system hardware into virtual resources and assign them to cloud tenants . Hypervisors may be classified into two types: hypervisors that run directly on the system hardware known as bare metal and hypervisors that run on top of operating systems (OSs). A bare metal hypervisor manages server hardware with simple configuration of CPUs, RAMs, and storage into scalable virtual resources . On the other hand, hypervisors that run on top of a host OS will scale computational resources offered by underlaying Linux OS . Hypervisors are likely to comply with the European Telecommunications Standards Institute (ETSI) NFV standard . This standard specifies various components of computing clouds and orchestration functionalities. The ETSI NFV management and organization (MANO) defines orchestration layers that can automate service catalogs and workflows.
There is a strong need to employ different hypervisor types due to ultra-dense network (UDN) architecture and rapid increase in service requests. Therefore, operators are developing innovative orchestrators that manage computing resources and report faults, alarms, or cyberattacks with any dependency on hypervisors functions. The new Open Network Automation Platform (ONAP) provides an example of an orchestrator that employs a set of various application programming interfaces (APIs) that can automate the physical and virtual network functions. This platform will provide an open standard for a unified cloud architecture that will speed up the virtualization of network functions . To this end, what does an automated distributed cloud mean for mobile network architecture? To answer this question, we need to define the network entities that are being targeted for NFV migration. From a core network perspective, all core network entities are considered for virtualization. This includes current fourth-generation (4G) Evolved Packet Core (EPC), IP Multimedia Subsystem (IMS), and 5GC. The key advantage of this technique is to be able to scale various processes subject to arrival traffic. From radio access network (RAN) perspective, these clouds are referred to as “Mobile Edge Computing (MEC)” that deploys MEC application server to process baseband signals of multiple neighboured RAN elements. In addition, the MEC application server supports multitenancy run-time for 5G UDN that generates high volumes of load.
Therefore, orchestrating the distribution of load between cloud servers enables more reliable and scalable services for cloud-based networks. The SDN platform can manage the traffic forwarding between various physical and virtual switches to install necessary flows on network elements. Therefore, orchestrators provide users the ability to provision lifecycle and resource assignment throughout network architecture. The span of network control requires precise and real time network telemetry information to perform the next scalability actions. To this end, orchestration features stretch beyond tenant and data management to network architecture control. Therefore, network structure and clusters interworking may be orchestrated in the form of service catalogs for efficient coordination of resources. A network service catalog can be launched as a tenant system that orchestrates network silos with predefined connectivity schemes and computational resources.
2. 5GC as a Service (5GCasS)
The 5GC will be mainly deployed as a package of software that runs on a datacenter. This means that various entities will be built with elasticity features to scale functions/modules considering incoming processed requests. The 5GC can be a reference point type or service-based type considering request type or standard slice type (SST). These slices refer to 5G enabled service types: enhanced Mobile Broadband (eMBB), ultra-reliable low latency communications (URLLC) and massive Internet of Things (MIoT). The different 5GC system architectures may run concurrently in the same datacenter. Therefore, it is necessary to be able to forward relevant traffic between various core types and dynamically onboard committed services. There is a strong need to automate the service assignment between various core types in cloud environment. Since all 5GC entities and frontend hardware are interfaced to the orchestrator, instantiating services and overlaying virtual tenant networking becomes more visible for support on fly. The key feature here is the integration of the SDN controller with the orchestrator platform to configure topologies considering the network policy enforced.
Figure 1: Orchestrating 5GC types for network cluster operations.
The densification of 5G networks with various types of RAN elements and the deployment of distributed geo-datacenters at different network sites motivate restructuring the whole network into a clustered network model. In this network model, a geo-datacenter can handle all calls locally and operate as the local core network for its associated cluster. This requires installing different 5GC types in that geo-datacenter while maintaining interworking with the main core network 5GC. Obviously, there is a need to define the functionality and interfacing requirements between different cores in a hierarchical order. In one example scenario, there will be a main network orchestrator and core network to manage operator operations centrally. We anticipate that this main orchestrator will govern all central cloud resources and will be able to manage all 5GC types. This orchestrator will support routing flows and requests between virtual entities using SDN features. Similarly, there will be a service type orchestrator that manages resource control for each slice type. In the distributed cloud, all geo-datacenters will have their own orchestrators to manage interworking and service assignment and also deploy service-based orchestrators to manage individual service type cores. In such network structure, it looks like there are too many orchestrators that are distributed across network sites and they require computational resources to operate. However, those orchestrators are deployed with a certain hierarchy to enforce efficient utilization of resources tied into service workflow. Assigning the necessary virtual resources to the corresponding 5GC types in an automated fashion to orchestrate a service defines a new concept of “5GC as a Service” (5GCaaS).
The virtual appliances are normally dependent on the underlying hardware. Therefore, network performance remains dependent on two main factors: 1) achieving hyper automation for real-time mobilization/utilization of resources in NFV domain and 2) hypervisor-built hardware implementations that access physical connectivity with higher capacities. The model shown in Fig. 1 assumes one geo-datacenter with multiple orchestrators and 5GC types. In this model, the SDR controller defines catalogs of service for each SST considering the service request by the end-user. The 5GC within this datacenter will perform the ultimate destination for all calls that happen within the cluster itself. 5GC can be chained (slave-master model) to other 5GCs at other datacenters when callers are located in associated clusters. This will reduce the burden on computational resources by allocating single 5GC to handle calls between multiple sites. This also means that one orchestrator can be interfaced to different virtual network functions (VNFs) at different datacenters within the same operator. To perform such operation, cloud platforms must employ the same APIs to be able to connect to each other.
3. Provisioning Network Transmissions
The MEC provides the very frontend computational resources of the network that connect to RAN elements. This implies that those geo-datacenters will also employ orchestrators and hypervisors to instantiate the necessary virtual resources that can handle arrival requests. Although those orchestrators are performing a very limited type of orchestration that is related to resource acquisition, they still have all orchestration features enabled on platforms. The connected RAN elements can also be interfaced to VNFs using virtual networks. In reality, this means that all RAN elements are governed by the MEC orchestrator that can enforce certain transmission profiles through predefined polices. For example, a VNF that is connected to multiple RAN elements can provide backward connectivity between physically separated elements, persistent storage for shared access to data, and orchestration of dual-/multi- transmissions to a single end-user . This scenario does not require any major changes to current orchestrator features; oppositely, it complements the current platform design with new use cases that align with 5G networks. In such a model, the network architecture will be completely controlled and driven by a NFV layer, allowing the execution of dynamic flow forwarding using a priority queue and/or capacity changes in the underlying network . The VNFs can instantiate direct interfaces through network ports/gateways to access RAN and adapt transmission schemes, as shown in Fig. 2. The datacenter can support SDN features to enable higher configurability and integration between physical cards and virtual layer in the form of Software-defined Datacenter (SDDC).
Figure 2: MEC Orchestrator enforces policies for dual-/multi- connectivity schemes at the RAN side.
The SDDC can be defined as a hardware-accelerated datacenter that can access all sorts of infrastructure appliances using SDN enhanced APIs. This indicates a leveraged entity that can manage underlying network architecture subject to the changes in traffic load. Since computational resources in MEC datacenters are very limited limitations, elasticity can help to improve dynamic resource assignment subject to RAN needs.
- A. Basta, A. Blenk, K. Hoffmann, H. J. Morper, M. Hoffmann and W. Kellerer, "Towards a Cost Optimal Design for a 5G Mobile Core Network Based on SDN and NFV," in IEEE Transactions on Network and Service Management, vol. 14, no. 4, pp. 1061-1075, Dec. 2017.
- A. Blenk, A. Basta, M. Reisslein and W. Kellerer, “Survey on Network Virtualization Hypervisors for Software Defined Networking,” in IEEE Communications Surveys & Tutorials, vol. 18, no. 1, pp. 655-685, Firstquarter 2016.
- VMware, “VMware vSphere Basics,” EN-000586-00, 2011.
- FusionSphere, “Optimize Business with Data Center Virtualization,” 2013.
- ETSI GS NFV-MAN, Network Functions Virtualisation (NFV); Management and Orchestration, 001 V1.1.1 (2014-12).
- A. Al-Dulaimi, S. Al-Rubaye, Q. Ni and E. Sousa, "5G Communications Race: Pursuit of More Capacity Triggers LTE in Unlicensed Band," in IEEE Vehicular Technology Magazine, vol. 10, no. 1, pp. 43-51, March 2015.
- B. Naudts, W. Tavernier, S. Verbrugge, D. Colle, and M. Pickavet, “Deploying SDN and NFV at the Speed of Innovation: Toward a New Bond between Standards Development Organizations, Industry Fora, and Open-source Software Projects,” IEEE Communications Magazine, vol. 54, no. 3, pp. 46–53, March 2016.
Anwer Al-Dulaimi received his Ph.D. degree in electrical and electronic engineering from Brunel University, London, UK in 2012. Currently, he is a System Engineering Specialist in the R&D department at EXFO, Toronto, Canada. Dr Al-Dulaimi is the editor of IEEE 5G Initiative Series in IEEE Vehicular Technology Magazine, associate editor of IEEE Communication Magazine, and editor of vehicular networking series in IEEE Communication Standards Magazine. He is the chair of IEEE 1932.1 Working Group “Standard for Licensed/Unlicensed Spectrum Interoperability in Wireless Mobile Network”.
Qiang Ni is a Professor and Head of the Communication Systems Research Group, School of Computing and Communications, Lancaster University, UK. He received his Ph.D. degree in 1999 from Huazhong University of Science and Technology, China. His research interests include 5G, Green Communications, Ultra-Dense Networks, Cognitive Radio, SDN, UAV, IoT, Smart City and VANETs. He is a Voting Member of IEEE 1932.1 standard. He was an IEEE 802.11 Standard Voting Member and contributor to various wireless standards.
Editor: Siming Zhang
Subscribe to Tech Focus
Join our free IEEE Future Networks Technical Community and receive IEEE Future NetworksTech Focus.
Article Contributions Welcome
If you wish to have an article considered for publication, please contact Amine Maaref, Managing Editor, at email@example.com or Siming Zhang, Associate Managing Editor at firstname.lastname@example.org.
Geoffrey Li, Editor-in-Chief
Amine Maaref, Managing Editor
Siming Zhang, Assoc. Managing Editor
Imran Shafique Ansari
Zhi Ning Chen