Master Thesis
Electrical EngineeringFebruary 2018
Faculty of Computing
Blekinge Institute of Technology
SE-371 79 Karlskrona Sweden
Generation and Validation of Network
Configuration for Evolved Packet Core
Shiva Sai Sunkari
ii
This thesis is submitted to the Faculty of Computing at Blekinge Institute of Technology in
partial fulfillment of the requirements for the degree of Master of Science in Electrical
Engineering with emphasis on Telecommunication Systems. The thesis is equivalent to 20
weeks of full time studies.
Contact Information:
Author(s):
Shiva Sai Sunkari
E-mail: shsu16@student.bth.se
External advisor:
1. Martin C Svensson,
Manager, PDG VNS, Ericsson.
2. Eric Alexanderson,
Solution Verification Engineer, Ericsson.
University advisor:
Adrian Popescu
Department of Communication Systems (DIKO)
Faculty of Computing
Blekinge Institute of Technology
SE-371 79 Karlskrona, Sweden
Internet : www.bth.se
Phone : +46 455 38 50 00
Fax : +46 455 38 50 57
A BSTRACT
Context: In the recent times, Industries are employing network function virtualization (NFV) for improved deployment flexibility, built for the most demanding environments. The benefits of Ericsson virtual Evolved Packet Core includes all the benefits of NFV and provides verified solutions addressing a large number of vertical use-cases. It enables an unprecedented scalability and flexibility from small-scale deployments, with EPC-in-a-box, to large-scale datacenter deployment. It includes virtual network services like Internet of Things, Distributed Mobile Broadband, Communication (VoLTE and Wi-FI calling), Mobile Virtual Network Operator(MVNO), Mobile Broadband.
Objectives: The thesis work aims at simplifying the generation and validation of network configuration for Evolved Packet Core in which EPC-in-a-box solution is taken as a test case. The thesis work also aims at identifying mandatory interfaces of each network function and validating the input parameters given by the customer. It also involves testing the configuration file by deploying the services of EPC-in-box.
Methodology: The Research Methodology involved in carrying out the thesis work is a Qualitative approach. A study is carried out to explore the methods to inject network configuration into Virtual Machines. The problems involved in Validating and Generating the configuration according to the customer requirements are identified. A suitable method is developed to simplify the process.
Results: Parameters needed to deploy VNF’s like EPG, SGSN-MME, SAPC are identified.
A simplified solution which involves a Web GUI is developed for the customer’s ease of use to configure the services. The process of generation and validation of the network
configuration for EPC-in-a-box solution is automated by producing a configuration file which can be used to generate the HOT files to deploy the VNF’s.
Conclusions: From the results and analysis, the new users in both telecom and non-telecom feels that GUI way of approach is an easier process for generating the configurations of network functions rather than the command line process. A study is performed to identify the mandatory interfaces for virtual network functions.
Keywords: NFV, virtual-EPC, VNF’s, EPG, SGSN-MME, SAPC
1
ACKNOWLEDGEMENT
Firstly, I would like to thank my parents Raja Ram Sunkari, Jyothi and my sister Divya, for all the support and encouragement they have given me. They made me who I am today. They have always been an inspiration to me and I am always indebted to them.
I sincerely express my gratitude to my supervisor Dr. Adrian Popescu for all his support, suggestions and guidance throughout this thesis study.
I thank my Industrial supervisors, Martin Svensson C, Eric Alexanderson for providing all the necessary guidance, support, and feedback that helped me in completing the thesis. It was a great experience working with them.
I would like to especially thank my thesis partner Rohith Reddy Jonnalagadda for all the help and support.
I also extend my great gratitude and appreciation to Vaishnavi, Shruti, Shanmukha Sai, Robin, Rajashekar, Bharath, Vignesh, Omsri, Pavitra, Renuka, Varma for their moral support during my period of study in Sweden.
2
LIST OF ABBREVIATIONS
NFV Network Function Virtualization
EPC Evolved Packet Core
EPG Evolved Packet Gateway
SGSN Serving GPRS Support Node
MME Mobility Management Entity
SAPC Service Aware Policy Controller
LTE Long Term Evolution
VoLTE Voice over LTE
MVNO Mobile Virtual Network Operator
VNF Virtual Network Function
GUI Graphical User Interface
CLI Command Line Interface
CEE Cloud Execution Environment
GSM Global System for Mobile Communications
CDMA Code Division Multiple Access
BW Bandwidth
3GPP 3rd Generation Partnership Project
UMTS Universal Mobile Telecommunications System
SAE System Architecture Evolution
EPS Evolved Packet System
GPRS General Packet Radio Services
RAN Radio Access Network
WLAN Wireless Local Area Network
HSPA High Speed Downlink Packet Access
IMS IP-based Multimedia Services
QoE Quality of Experience
SGW Serving Gateway
PGW Packet Gateway
HSS Home Subscribe Server
vEPC virtual EPC
BCAT Box and Cloud Automation Tool
E-UTRAN Evolved Universal Terrestrial Radio Access Network
PCRF Policy and Charging Rules Function
3
LIST OF FIGURES
Figure 1: Architecture domains by 3GPP………..06
Figure 2: Basic EPC architecture for LTE………...07
Figure 3: LTE SAE Evolved Packet Core………..08
Figure 4: Flow from UE to EPC……….13
Figure 5: High end architecture of EPC, RAN………...17
Figure 6: NFV architecture……….19
Figure 7: Components of EPC-in-a-box……….20
Figure 8: experimental setup………...23
Figure 9: Fuel VM architecture………...25
Figure 10: Dell R630 ports………..25
Figure 11: Hardware Flavours in CEE………26
Figure 12: UI for the users to fill data Figure 13: Validate with BCAT…..………29
Figure 14: Error messages…….……….29
Figure 15: EPG node………..30
Figure 16: MME node………31
Figure 17: SAPC node………31
Figure 18: LTE EPC Network Interfaces………...32
Figure 19: Save and Validate with BCAT………34
Figure 20: Error message validating with BCAT………...34
LIST OF TABLES
Table 01 Split of Work……….……...11Table 02 Interfaces………...36
4
C ONTENTS
ABSTRACT ...I
ACKNOWLEDGEMENT ... 1
LIST OF ABBREVIATIONS ... 2
CONTENTS ... 4
1 INTRODUCTION ... 5
1.1 MOTIVATION ... 8
1.2 AIM&OBJECTIVES ... 9
1.3 SCOPEOFTHESIS ... 9
1.4 RESEARCHQUESTIONS ... 9
1.5 RESEARCHMETHODS ... 10
1.6 EXPECTEDOUTCOMES ... 10
1.7 SPLITOFWORK ... 11
2 RELATED WORK ... 13
3 BACKGROUND ... 15
3.1 LTE ... 15
3.2 EVOLVEDPACKETCORE ... 15
3.2.1 Serving Gateway ... 17
3.2.2 Packet Data Network Gateway ... 17
3.2.3 Mobility Management Entity ... 18
3.2.4 Policy and Charging Rules Function ... 18
3.2.5 Service Aware Policy Controller... 18
3.3 NETWORKFUNCTIONSVITUALIZATION ... 19
3.4 EPC-IN-A-BOX ... 20
3.5 BCAT ... 20
4 METHODOLOGY ... 21
4.1 METHODS TO CONFIGURE NETWORK ... 22
4.2 EXPERIMENT TEST-BED ... 23
4.2.1 Fuel VM ... 25
4.2.2 Fuel Setup ... 27
4.2.3 Server Setup ... 27
4.2.4 Deployment... 27
5 RESULTS AND ANALYSIS... 29
6 CONCLUSION AND FUTURE WORK ... 29
6.1 ANSWERS TO RQS ... 32
6.2 FUTUREWORK ... 36
REFERENCES ... 37
5
1 I NTRODUCTION
These days, millions of consumers and businesses are connected to a network in one form or another. As a result, the systems and datacenters used to transport, and house content are getting bigger, more pervasive, and increasingly complex. Add to this the explosive amount of data crossing the network, and it quickly becomes apparent that companies and service providers face a daunting challenge.
Network functions virtualization (NFV) promises to ease the burden by granting service providers the flexibility to move network functions from dedicated appliances to generic servers. Using standard IT virtualization technology, NFV aims to consolidate many network equipment types on to industry-standard, high-volume servers, switches, and storage; doing so makes the networks more agile and efficient.
NFV also is flexible, cost-effective, scalable, and secure. With these benefits, NFV addresses several trends shaping service provider networks.
Flexibility: Operators looking to quickly deploy new services require a much more flexible and adaptable network -- one that can be easily and quickly installed and provisioned.
Cost: Cost is a top consideration for any operator or service provider these days, even more so now that they see Google and others deploying massive datacenters using off-the-shelf merchant silicon (commoditized hardware) as a way to drive down cost. Cost is also reflected in opex -- how easy it is to deploy and maintain services in the network.
Scalability: To adapt quickly to user's changing needs and provide new services, operators must be able to scale their network architecture across multiple servers, rather than being limited by what a single box can do.
Security: Security has been, and continues to be, a major challenge in networking.
Operators want to be able to provision and manage the network while allowing their customers to run their own virtual space and firewall securely within the network.
Virtualization in another service provider network: To meet customers' needs better, service providers want the ability to substantiate their service anywhere in the world using virtualization.
Let's take a closer look at how NFV addresses these trends. By its very nature, NFV makes network and service provisioning more flexible. That allows operators and service providers to scale services up or down quickly to address changing demands.
Those services are delivered via software applications on any industry-standard server hardware, one of the most important of which is expected to be security gateways.
Rather than buying a hard asset, service providers can simply take the function associated with the asset and instantiate it as a virtual machine on a server.
Because the network functions are implemented in software, they can be easily moved to various locations in the network without having to install new equipment.
That means operators and service providers won't need to deploy as many hard assets.
Instead, inexpensive, high-volume server infrastructure can be deployed with virtual machines running on top. That's where the cost savings comes in, but NFV's use of virtual machines (software) also makes it scalable. That is why Ericsson adopted and
6
implemented its functionalities on Packet Core by Virtualizing all evolved packet core components.
Background of development of EPC
In 1990’s the various standards of the cellular system e.g. GSM, CDMA etc. were based on circuit switching and the services developed were specifically concentrated on the typical applications of telecommunications. But the introduction of mobile internet in early 1990’s brought a huge change, or we can say the revolution in telecommunication world. But at that time the mobile equipment was not designed enough to support the services. Another reason was the bandwidth; the BW of radio was not enough to support the services.
Now the trend has been changed with the evolution of new mobile broadband access technologies and developments in semiconductor chips made it possible to support the mobile internet services.
In November 2004, 3GPP (Third generation partnership project) started its work on 4G technologies that was like a successor of Universal mobile telecommunication system (UMTS), particularly a work item names system architecture evolution (SAE) along with LTE which is responsible for evolution of packet core network(EPC), which will support the high bandwidth services at high data rate. 3GPP wanted to create a global standard for 4G technologies.
Before we will go into the details of the architecture of the EPC, we will briefly see the high-level perspective of the complete system as defined in the SAE work item.
It is called EPS architecture. EPS stands for Evolved Packet System, which represents all IP network and contains both EPC and LTE. It consists of different domains and each domain again consists of logical nodes. These nodes are interworked with each other to perform any specific set of functions. The basic network which implements the 3GPP specification is shown below in the figure.
Figure 1: Architecture domains by 3GPP
As shown in the figure, there are four domains. First, GSM/GPRS represents 2G technology domain whereas second, WCDMA/HSPA (Wide CDMA/ High speed packet access) represents 3G or 3.5G RAN (Radio access network). Third, LTE (Long term evolution) is the latest domain specified by 3GPP and the fourth, Non-3GPP consists of access networks, e.g. WiMAX and WLAN, which are not specified by 3GPP but actually provided by other standardization bodies like 3GPP2, IEEE. All four domains are connected to packet core domain (EPC). The core domain also
7
consists of four basic domains. These are circuit core domain, user domain, IMS (IP multimedia subsystem) and packet core domain. The circuit core domain is linked to GSM/GPRS and WCDMA/HSPA. It supports and provides the circuit switch services in 2G and 3G technologies. The packet core domain provides IP services over GSM, WCDMA/HSPA, LTE and Non-3GPP technologies while the user domain provides the complete updated information of users on request. It maintains the database to support roaming mobility of the subscriber whether they are moving in a single network or in between different network. The IMS provides support to services based on Session initiation protocol (SIP). Since IMS supports IP services so it uses the IP connectivity with packet core domain to use its function provided by its node.
Now we will turn out attention to the EPC architecture. The EPC architecture consists of packet core domain and user domain. The following figure is showing the basic architecture of the EPC for LTE.
Figure 2: Basic EPC architecture for LTE
EPC (Evolved Packet Core) is the latest evolution of the 3GPP core network architecture. EPC is the next-generation multimedia core network for 4G access and is required to deploy LTE radio technology. EPC addresses LTE requirements to provide advanced real-time and media-rich services with enhanced Quality of Experience(QoE). EPC improves network performance by the separation of control and data planes and through a flattened IP architecture which reduces the hierarchy between mobile data elements.
In packet domain it consists of:
• Mobility management Entity(MME)
• Serving Gateway(SGW)
• Packet data network gateway (PDN-GW)
In user domain, it has only one node named Home subscriber server (HSS).
The role and function of each component of EPC is as follows:
Mobility Management Entity: it is the node responsible for the signal exchanges between base stations and core networks and between the subscriber and
8
core network. It performs basic tasks like authentication, establishment of bearers, internetworking support, handover support, supporting traditional services like voice and messages [6].
Serving Gateway: The basic function of serving gateway is to manage the user IP tunnels between eNodeB and packet data network gateway.
Packet data network gateway(PDN-GW): This is the gateway to internet and is responsible for assigning IP addresses to the mobile devices. It plays an important role in case of international roaming scenarios.
Home subscriber server(HSS): it is a database that stores the information of every user in the network. It also does the authentication and authorization of users and services provided to them.
Figure 3: LTE SAE Evolved Packet Core The above described entities are called network functions. Ericsson’s virtual Evolved Packet Core (vEPC) provides tested and validated solutions addressing many vertical use-cases thereby opening new operator opportunities. The benefits of Ericsson’s virtual EPC include all the benefits of NFV, but with the Ericsson differentiation—a complete end-to-end solution, meaning virtualization of all EPC components (i.e., virtual network functions). There are two deployment techniques employed called EPC-in-a-box (not scalable, limited to a single server) and cloud (scalable) for virtual evolved packet core. The VEPC provides a package of scripts that is known as Box & Cloud Automation Tools(BCAT). BCAT scripts are used to generate network configuration, templates for VNF’s, instantiate, scale out, decommission VNFs. BCAT is also used to create and generate hardware flavors in a cloud environment. The implemented method of generating the configurations for VNFs is too complex. Our concern is regarding the box deployment which is taken as a case study of LTE EPC where virtualization technology is used to make it possible fit multiple vepc VNFs onto a single server. The developed solution can simplify the complexity and reduce the time taken to generate the configuration files for VNFs.
1.1 MOTIVATION
The main reason for choosing this study is to generate and validate network configuration for customer’s ease of use. If more is the complexity of the network more will be the complexity in configuring the network, to handle that level of complexity automation of network configuration is introduced. As a part of the thesis work, EPC-in-box test case has been chosen. EPC is a framework for providing
9
converged voice and data on 4G LTE network. It is the core component of Service Architecture Evolution (SAE), 3GPP’s flat LTE architecture.
EPC plays an important role in the guaranteed delivery of service with the best quality of experience (QoE) and mobile network operators adopt virtualized evolved packet core architecture in their network for a more concrete software-controlled programmable environment. It has key components like EPG, SGSN-MME, and SAPC serving as virtual network functions and each component has its own importance. But setting up the vEPC configuration is difficult since it contains many internal parameters like NTP servers, SNMP servers, Subnets, Routing Domains etc., and also an internal validation of parameters is a bit difficult task. Since valid configuration is necessary for effective use of resources, hence the motive of the thesis work is to automate the process of generating the configurations of the virtual network functions and validating the parameters and the generated configuration file of the virtual network functions get properly deployed in cloud execution environments.
1.2 AIM & OBJECTIVES
The aim of this thesis is to simplify the generation and validation of customer network configuration to deploy VNF’s in EPC-in-a-box.
The objectives of this thesis include the following:
• Analyzing the methods for configuring Virtual network functions in Cloud Environment.
• Implementing a method for the customers ease-of-use to validate and configure the network configuration for VNFs.
• Performing a study to identify the mandatory interfaces to deploy VNF’s in EPC-in-a-box.
• Validating the input parameters given by the customers.
• Testing the generated configuration from the implemented method by deploying the services in EPC-in-a-box.
1.3 SCOPE OF THESIS
This thesis work simplifies the generation and validation of customer network configuration to deploy VNF’s in EPC-in-a-box which is taken as a test case. This study deals with the methods used to configure the network and a study to identify the mandatory interfaces to deploy virtual network function EPG.
1.4 RESEARCH QUESTIONS
Following are the Research Questions (RQ) associated with EPC-in-a-box will be addressed by both the students:
1.) How to simplify the generation and validation of customer network configuration to deploy EPC-in-a-box?
2.) RQ addressed by Shiva Sai Sunkari
• How to investigate mandatory interfaces for deploying the EPG virtual network function
• How to detect faulty input parameters and handle them based on BCAT internal validation of parameters?
3.) RQ addressed by Rohith Reddy Jonnalagadda
10
• How to handle faulty input parameters without using existing back- end (BCAT) for the developed solution?
• How to investigate mandatory interfaces for deploying the SGSN- MME virtual network function in EPC-in-a-box?
1.5 RESEARCH METHODS
In general, research may be carried out by literature survey, through simulation, experimentation or by consulting mathematical models of the elements being investigated. Since, the tools being analyzed are themselves software and hence difficult to be analyzed by simulation or mathematical models. Literature review is also not feasible since there is no previous work done in this area. Therefore, experimentation is the most appropriate research method to carry out the thesis.
RQ1 will be answered by analyzing the network configuration methods and selecting a User-friendly method for the customers by accounting the resources consumed by the method and Implementing the selected method for EPC-in-a-box.
RQ2 will be answered by performing a study on the EPG and analyzing the mandatory interfaces required to deploy a validated EPC on the server.
RQ3 are answered through experimentation, involving following steps:
• Scripts are written for the implemented method to detect the faulty parameters and handle the parameters before deploying the services.
• Network Configuration is tested by deploying EPC-in-a-Box on the server to make sure that the faulty parameters are handled beforehand.
1.6 EXPECTED OUTCOMES
The following are the expected outcomes from the thesis work.
• Through the literature study, related works, product solutions descriptions and studying the functionality of EPC-in-a-box service, the objectives of the thesis are identified.
• Network configuration methods for a cloud environment are analyzed and implemented based on the requirements.
• Mandatory interfaces needed to deploy EPG virtual network function in EPC-in-a-box are identified.
• Faulty parameters should be handled by the implemented solution before the services are deployed.
• In the testing stage, the services are deployed to make sure that the faulty parameters are handled, and a validated EPC is deployed on CEE.
11
1.7 SPLIT OF WORK
Section Topic Section Contributor
1 Introduction Shiva Sai Sunkari
Rohith Reddy Jonnalagadda
2 Related Work Shiva Sai Sunkari
Rohith Reddy Jonnalagadda
3 Background 3.1 LTE Shiva Sai Sunkari
3.2 Evolved Packet Core Rohith Reddy Jonnalagadda 3.2 Network Function
Virtualization Shiva Sai Sunkari
3.4 EPC-in-a-box Shiva Sai Sunkari Rohith Reddy Jonnalagadda 4 Methodology 4.1 Methods to Configure
Network
4.2 Experiment Test-bed
Shiva Sai Sunkari Rohith Reddy Jonnalagadda
5 Results and
Analysis 5.1 Analysis of network configuration methods and implementation
Shiva Sai Sunkari Rohith Reddy Jonnalagadda 5.2 Validation of parameters
(with BCAT) Shiva Sai Sunkari
5.3 Investigation of mandatory
interfaces for EPG Shiva Sai Sunkari 5.4 Validation of parameters
(without BCAT) Rohith Reddy
Jonnalagadda 5.5 Investigation of mandatory
interfaces for SGSN-MME Rohith Reddy Jonnalagadda 5.6 Deploying VNFs on CEE Shiva Sai Sunkari
12
using configuration files from UI Rohith Reddy Jonnalagadda
6 Conclusion and
Future Work Shiva Sai Sunkari
Rohith Reddy Jonnalagadda
13
2 R ELATED WORK
This section deals with the literature work that has been done previously which motivated and guided us towards implementing and completing this thesis work.
Tarik et. Al [1] described the key elements to realize the architectural vision of EPC as a service, an implementation option of the Evolved Packet Core, as specified by 3GPP, which can be deployed in cloud environments. To meet several challenging requirements associated with the implementation of EPC over cloud infrastructure implementation options is also presented.
David Buchmann [2] has evaluated the general concepts of network management and the prototype implementation of a network management system software. Verified Network Configuration can validate correctness before configuring the devices. The configuration is described with the markup language XML. It is abstracted from specific implementations of devices or services. XML technologies are used to translate the
abstracted configuration into implementation-specific formats. The translated configuration is automatically distributed using existing remote administration protocols. This avoids errors when applying the tested configuration to the actual network devices.
Alcatel-Lucent in [3] has provided the comprehensive overview of the network architecture of a Long Term Evolution system according to release 8 version of the
specifications. It consists of main principles of the LTE network architecture. It involved in the design of LTE interfaces and network equipment. It provides a straightforward
introduction to the definitive but complex specifications defined by the Third-Generation Partnership Project (3GPP), but it also particularly highlights aspects of the network
architecture interfaces that enable LTE networks to be deployed in an optimized and efficient manner.
This article [4] provides the importance of interfaces for the LTE network. It also describes the interface function and its importance. It also specifies the different kinds of interfaces present in each network function of LTE architecture.
This article [5], states the functions of main LTE packet core elements- MME, SGW, PGW. It also states the different features of each Network Function and their importance in today’s scenario.
Van- giang Nyugen et. al [6] stated in the paper that software defined networking (SDN) features the decoupling of the control plane and data plane, a programmable network and virtualization, which enables network infrastructure sharing and the “softwarization” of the network functions. By analyzing and categorizing a wide range of the latest research works on SDN and virtualization in LTE mobile networks, they presented a general architecture for SDN and virtualization in mobile networks (called SDVMN) and then propose a hierarchical taxonomy based on the different levels of the carrier network. They specified a list of use cases and applications that benefit from SDVMN.
Ali Tawbeh et.al [7] presented an extended study of the network entities and interfaces that have to be maintained and updated regularly and also the hardware that must be integrated in the LTE EPC. So, to address these challenges, the EPC can be moved to the cloud using two modern technologies: SDN and NFV. In this paper, they have studied the impact of integrating these novel technologies on LTE networks and proposed a hybrid approach fro selecting whether to apply SDN or NFV on each gateway at a given time while minimizing the network load taking into consideration and key parameters such as the
14
number of active datacenters, the deployment city population, the QoS class identifier (QCI) and the delay budget.
Isabella et.al [8] stated that testing the software became a major concern. Due to importance of the testing phase in a software development life cycle, testing has been divided into graphical user interface (GUI) based testing, logical testing, integration testing et., this paper stated that GUI testing has become very important as it provides more sophisticated way to interact with the software. The testing needs to be performed in a way that it provides effectiveness, efficiency, increased fault detection rate and good path coverage. Intent of this paper is to study some techniques used for test case generation and process for various GUI based software applications.
This article [9] provides the importance of a GNOME GUI for network
management. Network settings configuration tool is provided as part of the new GNOME control-center GUI. It has provided two ways to access the network settings and it shows the network configuration status. There are many advantages in using GUI are described in this article.
This article [10], stated that the network administration GUI is the graphical
equivalent to the network command-line interface (CLI). It says that network administration GUI enables to view and monitor the status of your network from the desktop, as well as interact with reactive network profiles to manage your Ethernet and wireless configuration. It includes the basic capabilities such as network status notification and detection of hot- plugged events. It makes the work easier for a new user who is not familiar with CLI way of configuring the network.
15
3 B ACKGROUND
This chapter briefly describes the basic concepts needed to understand the thesis.
Concepts covered include LTE (Long Term Evolution), Network Functions Virtualization, Evolved Packet Core and EPC-in-a-Box.
3.1 LTE
LTE stands for Long Term Evolution and it was started as a project in 2004 by telecommunication body known as the Third Generation Partnership Project (3GPP).
SAE (System Architecture Evolution) is the corresponding evolution of the GPRS/3G packet core network evolution. The term LTE is typically used to represent both LTE and SAE.
LTE evolved from an earlier 3GPP system known as the Universal Mobile
Telecommunication System (UMTS), which in turn evolved from the Global System for Mobile Communications (GSM). Even related specifications were formally known as the evolved UMTS terrestrial radio access (E-UTRA) and evolved UMTS terrestrial radio access network (E-UTRAN). First version of LTE was documented in Release 8 of the 3GPP specifications.
A rapid increase of mobile data usage and emergence of new applications such as MMOG (Multimedia Online Gaming), mobile TV, Web 2.0, streaming contents have motivated the 3rd Generation Partnership Project (3GPP) to work on the Long-Term Evolution (LTE) on the way towards fourth-generation mobile.
The main goal of LTE is to provide a high data rate, low latency and packet optimized radio access technology supporting flexible bandwidth deployments. Same time its network architecture has been designed with the goal to support packet-switched traffic with seamless mobility and great quality of
service.
Figure 4: Flow from UE to EPC
3.2 EVOLVED PACKET CORE
EPC is the latest evolution of the 3GPP core network architecture.Evolved Packet Core solutions are designed to provide reliability and scalability, giving the flexibility needed
16
to meet the growing demand for new services and expand into new markets. Evolved Packet Core (EPC) is a framework standardized in Release 8 of the 3GPP for giving data and converged voice on a network based on 4G LTE. Evolved Packet Core is based on a constant network connection or an always-on connection. Evolved Packet Core helps in combining voice and data on an Internet Protocol service architecture [6]. This helps service operators in operations as well as deploying one packet network for 2G, 3G, LTE, WLAN or fixed access such as cable or DSL.The LTE architecture defines the Evolved Packet System (EPS) as a combination of the LTE access system (radio part) and an IP-based core network, the Evolved Packet Core (EPC).All EPS transactions are IP-based: from the mobile handsets, over eNode Bs, across the EPC, and throughout the application domain, for both IMS and non-IMS. The EPC is a multi-access core IP-based network that enables operators to deploy and operate one common packet core network for 3GPP radio access (LTE, 3G, and 2G) and non-3GPP radio access (HRPD, WLAN, and WiMAX), and fixed access (Ethernet, DSL, cable and fiber).
The EPC not only provides a simpler, flatter, and cheaper network infrastructure, but also adheres to new, stringent LTE requirements for high bandwidth, reduced latency, and 2G/3G interoperability. Therefore, the enforcement of control of quality of service (QoS)- related parameters, such as jitter and delay, is critical. This will allow the EPS to support a TDM-like deterministic behavior for delivery of real-time, performance- sensitive services, such as voice and video.
The EPS must be a high-performance, high-capacity, all-IP core network in order to aggregate many eNode Bs with significantly increased peak data rates – up to 300 Mbps downlink per sector when operating at 20 MHz with 4x4 MIMO.
Load requirements will vary depending on several factors, including:
• Number of sectors used. A typical configuration will range from 3 to 6 sectors.
• Number of UEs per sector and their relative velocities, since higher speeds lend themselves to increased transmission errors.
• Radio conditions.
• Types of voice, video, and data applications used by each UE. Some chatty applications, such as instant messaging, tend to keep the signaling level of the radio fairly busy with large numbers of short transactions, although they present a light load for the core.
The EPC must also match LTE latency and QoS requirements by providing superior real-time
and media-rich services with improved QoE. The EPC increases network performance by using a streamlined IP architecture in which the control and data planes are separated at the edge of the core network. Data connections from eNode Bs traverse EPC gateways, while user mobility is addressed by the MME.
17
Figure 5: High end architecture of EPC, RAN Although the EPC is composed of a number of components that provide IP connectivity for multiple access technologies, the key node elements are:
• Serving Gateway (SGW)
• Packet Data Network (PDN) Gateway (GW)
• Mobility Management Entity (MME)
• Policy and Charging Rules Function (PCRF)/Service Aware Policy Controller(SAPC)
3.2.1 Serving Gateway
The SGW is a user-plane node providing data paths between eNode Bs and the PDN gateway. One of the essential functionality of the SGW, beside routing and forwarding packets, is as a local mobility anchor point for inter-eNode B handovers as well as managing mobility between LTE and 2G/GSM and 3G/UMTS networks. The SGW also provides charging for user equipment, PDN, and service classes. The SGW is connected to the PDN-GW via the S5 interface, which can support two distinct protocols, either the GPRS tunneling protocol (GTP) or the proxy mobile IPv6 (PMIPv6) protocol. When using PMIP, the SGW also has a direct connection with the PCRF via the Gxc interface to supplement the lack of event reporting not available in the PMIPv6 protocol [5].
PMIPv6 maintains IP connectivity instead of a requiring an EPS bearer. The EPS bearer goes from the UE to the PDN-GW with appropriate QoS.
3.2.2 Packet Data Network Gateway
The PDN-GW is the termination point of the packet data interface. It provides the anchoring function for sessions with external packet data networks. A critical function of the PDN-GW is enforcement of per-user-based packet filtering, allowing gating and rate enforcement policies as well as service level charging. User-plane LTE traffic is carried over service data flows (SDFs), which are aggregated over a set of virtual connections that match a specific filter policy or template. SDFs are in turn carried over EPS bearers
18
[5]. An EPS bearer uniquely identifies data flows that receive a common QoS treatment between a UE and a PDN GW.
3.2.3 Mobility Management Entity
The MME has a key role in the handling of mobile users. It performs the signaling and control functions that manage the mobile users’ access to LTE, assigns network
resources, and manages mobility states that support roaming, paging, and handovers [5].
The MME oversees all control plane functions related to subscriber and session
management. Additionally, the MME performs the inter-core network node signaling for mobility between 3GPP access networks and provides bearer management control functions to establish the bearer paths that the mobile user will use.
The MME supports the following functions:
• Security procedures: End-user authentication as well as initiation and negotiation of ciphering and integrity protection algorithms.
• Terminal-to-network session handling: All signaling procedures used to set up packet data context and negotiate associated parameters, such as QoS.
• Idle terminal location management: The tracking area update process used to enable the network to join terminals for incoming sessions.
An MME typically manages thousands of eNodeBs – one of the key differences between 2G/3G networks based on RNC/SGSN platforms.
3.2.4 Policy and Charging Rules Function
Defined in 3GPP Release 7 as the union of the policy decision function (PDF) and the charging rules functions (CRF), the PCRF was further enhanced in Release 8 by
broadening the scope of the policy and charging control (PCC) functionality to ease non- 3GPP access to the network, for example for Wi-Fi or fixed IP broadband access.
In the 3GPP policy and charging control model, the policy and charging enforcement function (PCEF) is the generic name for the functional entity that supports service data flow detection, policy enforcement and flow-based charging. This functionality is the responsibility of the PDN-GW, which hosts the rules sent by the PCRF using the Gx interface.
At the application level, i.e. within IMS, the PCRF also communicates with the proxy call
charging session control function (P-CSCF), providing support for applications that require dynamic policy and/or charging control via the Rx interface.
3.2.5 Service Aware Policy Controller
The Ericsson Service-Aware Policy Controller (SAPC) product is conceived based on 3GPP Policy and Charging Rules Function (PCRF). SAPC is responsible for the policy control and charging rules that define the services and applications supported in mobile, fixed and converged telecom networks. SAPC is key to secure the network behavior when users access data services, such as, authorizing the services, assigning the QoS of the data-session and the Charging that shall be applied; and performs a business-critical role for monetization and differentiation of operator’s mobile and converged broadband commercial packages.
19
The Ericsson SAPC product is an important component of Ericsson’s solutions for Broadband Networks as Evolved Packet Core (EPC), Mobile Telephony Evolution with VoLTE and Wi-Fi Calling, and BSS to name some.
3.3 NETWORK FUNCTIONS VITUALIZATION
The NFV initiative is intended to address the operational challenges and high costs of managing the closed and proprietary appliances presently deployed throughout telecom networks. By virtualizing and consolidating network functions traditionally implemented in dedicated hardware, using cloud technologies, network operators expect to achieve greater agility and accelerate new service deployments while driving down both operational (OpEx) and capital costs (CapEx).
Network functions virtualization (NFV) is an initiative to virtualize network services traditionally run on proprietary, dedicated hardware. With NFV, functions like routing, load balancing and firewalls are packaged as virtual machines (VMs) on commodity hardware. Individual virtual network functions, or VNFs, are an essential component of NFV architecture [7].
Multiple VNFs can be added to a standard x86 server and then can be monitored and controlled by a hypervisor. NFV's mission to use commodity hardware is important because network managers no longer need to purchase and manually configure dedicated hardware devices to build a service chain that links certain functions to perform a desired sequence. Each dedicated device, by comparison, needs to be manually cabled together accordingly, which is a time-consuming process.
Because NFV architecture virtualizes network functions and eliminates specific hardware, network managers can add, move or change network functions at the server level in a simplified provisioning process.
If a VNF running on a virtual machine requires more bandwidth, for example, the administrator can move the VM to another physical server or provision another virtual machine on the original server to handle part of the load. Having this flexibility allows an IT department to respond in a more agile manner to changing business goals and network service demands.
Figure 6: NFV architecture
20
3.4 EPC-IN-A-BOX
EPC-in-a-box is a validated deployment that fulfills the requirements for small systems with few subscribers, low throughput, and minimal footprint. It is a further evolution of the VNF single server deployment enabling multiple VNFs on a single server. The deployment contains EPG, SGSN-MME and SAPC. EPC-in-a-box is designed for CEE 16A and can use either HDS 8000 CRU or Dell 630 as Hardware.
NM Node Manager CP Control Plane UP User Plane LB Load Balancer FS File Server DB Database
CEE Cloud Execution
Environment
Figure 7: Components of EPC-in-a-box EPC-in-a-box is tuned to be as efficient as possible when all VNFs are running at the same time. However, there is no requirement that all VNFs must be deployed. For example, it is possible to only deploy vEPG.
Virtualization technology is used to make it possible to fit multiple vEPC VNFs onto a single server. This deployment has the following specific properties:
• No HW redundancy
• Limitations in application SW redundancy
• Not scalable (i.e. capacity is limited to what the single server can handle).
• Cannot be deployed on one server in a Cloud region consisting of multiple servers (CEE single server configuration is one region in itself).
3.5 BCAT
BCAT is a toolbox of scripts which are written in Python 2.7 for creating solution specific hardware flavours for the cloud environment, to generate templates for VNFs (OVF/HOT), Scale-out/Scale-in of solutions, Decommision VNF’s and to validate the network
configuration for VNFS. BCAT scripts are provided to the customer along with the vEPC software.
21
3.6 CEE
Ericsson Cloud Execution Environment provides economy of scale and deterministic performance while securing an always available cloud and NFVi environment. It is based on OpenStack with added features not yet available in open source, to meet the carrier grade needs of telecom service providers. As open source matures for telecom applications, the need for Ericsson designed functionality is reduced. These features, among others, include;
• Continuous end-user access to services through redundancy and high availability capabilities
• High throughput with low latency, through an enhanced vSwitch and support for SR-
• IOV Rapid and controlled deployment
• A unified cloud infrastructure operations & maintenance through fault and performance management
• Tenant network management through cloud SDN controller
• Simplified security administration
• Trusted tenant isolation
Ericsson Cloud Execution Environment supports applications including virtual network functions from Ericsson and third parties. In addition, it is completely open for orchestration and infrastructure products from third parties.
Ericsson is a platinum member of OpenStack and OPNFV, with the aim of simplifying and speeding up the adoption of network functions virtualization.
3.7 HOT TEMPLATES
HOT is a new template format meant to replace the Heat CloudFormation- compatible format (CFN) as the native format supported by the Heat over time.HOT is considered reliable, supported, and standardized as of our Icehouse (April 2014) release. The Heat core team may make improvements to the standard, which very likely would be backward compatible.
Heat provides a template-based orchestration for describing a cloud application by executing appropriate Openstack API calls to generate running cloud applications. A Heat template describes the infrastructure for a cloud application in text files which are readable and writable by humans and can be managed by version control tools.Templates specify the relationships between resources (e.g. this volume is connected to this server). This enables Heat to call out to the OpenStack APIs to create all your infrastructure in the correct order to completely launch your application. The software integrates other components of OpenStack. The templates allow creation of most OpenStack resource types (such as instances, floating ips, volumes, security groups, users, etc), as well as some more advanced functionality such as instance high availability, instance autoscaling, and nested stacks. Heat primarily manages infrastructure, but the templates integrate well with software configuration management tools such as Puppet and Ansible. Operators can customise the capabilities of Heat by installing plugins.
22
4 M ETHODOLOGY
The method used to carry out the research work is known as Research Method.
Research methods and research data in psychology can be placed into two basic categories: quantitative or qualitative.
Qualitative Research is primarily exploratory research. It is used to gain an understanding of underlying reasons, opinions, and motivations. It provides insights into the problem or helps to develop ideas or hypotheses for potential quantitative research. Qualitative Research is also used to uncover trends in thought and opinions, and dive deeper into the problem. Qualitative data collection methods vary using unstructured or semi-structured techniques. Some common methods include focus groups (group discussions), individual interviews, and participation/observations. The sample size is typically small, and respondents are selected to fulfil a given quota.
Quantitative Research is used to quantify the problem by way of generating numerical data or data that can be transformed into usable statistics. It is used to quantify attitudes, opinions, behaviors, and other defined variables – and generalize results from a larger sample population. Quantitative Research uses measurable data to formulate facts and uncover patterns in research. Quantitative data collection methods are much more structured than Qualitative data collection methods. Quantitative data collection methods include various forms of surveys – online surveys, paper surveys, mobile surveys and kiosk surveys, face-to-face interviews, telephone interviews, longitudinal studies, website interceptors, online polls, and systematic observations.
Review of related literature is a requirement for every robust research whether qualitative or quantitative study approach because it is the review of related literature that offers a solid theoretical foundation for the research. A researcher creates the academic vacuum his/her research is intended to fill by craftily reviewing the related literature, justifying the need and essence of the research.
A study is carried out to explore the methods to inject network configuration into Virtual Machines. The problems involved in configuring and validating network configuration are identified based on customers requirement. The motive behind this study is to provide a solution to eliminate the manual interference to configure the virtual network functions such as EPG (Evolved Packet Gateway), SGSN-MME (Serving GPRS Support Node- Mobile Management Entity) and SAPC(Service Aware Policy Controller). The methods that can be adopted by the customer to configure based on the experience of the customer, Hence Qualitative approach is the suitable methodology.
The research Methodology adopted to carry out the thesis involves Qualitative approach.
4.1 Methods to Configure Network
In a EPC network, every Virtual machine requires a specific configuration of EPC related parameters, a specific configuration for network parameters and interfaces towards the Orchestration and Management systems. User Specific Configuration includes Routing Domains, Subnets, Interfaces, DNS servers, NTP Servers, SSH keys, Node IP’s which varies from customer to customer. The
23
configuration is varied for each virtual network functions. Every running VM requires a specific configuration of EPC-related parameters (e.g. GPRS timers, access point name (APN) definitions, Routing Domains, Subnets and pre-emption policies), a specific configuration of networking parameters (i.e. IP addresses on the virtual interfaces), and interfaces toward the O&M systems.:
1.Command Line Interface (CLI): In this method all the customer specific network parameters are configured by giving the commands in the virtual machines to configure the interfaces between the virtual network functions so that a valid network can be established. challenge. Each virtual component must be configured with a different set of 3GPP-specific parameters, and when the SIC needs more capacity and more virtual components are instantiated, scalability problems may arise in managing and maintaining the configuration of a high number of VMs. As there are a lot of parameters this method requires a lot of manual interference and there is a greater chance to make errors which results in waste of human efforts and time. Hence this method is not adaptable and there is a need for a simpler automation.
2. Configuration Management tools: The tools evaluated are puppet and chef. These tools can be used to configure and manage the network but the downside for these provisioning tools are that you have to install and run extra software on every one of your servers. Since EPC-in-a-box has limited resources for the virtual network functions it won’t be feasible to install on our server. The parameters configured have a lot of conditional dependencies which can’t be validated using these tools and it takes a lot of time to establish a validated EPC solution. Hence there is a need more simpler method to configure customer specific parameters for EPC-in-a-box.
3. Script Driven Automation: A tool is developed which resolves the validation of the network parameters which has a Graphical User Interface with structured error messages. This tool has a Graphical User Interface through which you can enter all the parameters which are mandatory to establish the EPC solution. The data filled is validated by using the Box Cloud Automation Tools developed by Ericsson and errors in the configuration are shown on the GUI. If the validation is passed the scripts in the back end build a VNF specific configuration file which used as an input to build the HOT templates for the VNF which includes the network configuration, so that when the templates are deployed it automatically creates all the interfaces so that the virtual network functions can communicate with each other. This approach helps the Customers to automate the generation and validation of network configuration tasks and to minimize the manual interference as much as possible, it was made easier for the customers to build a validated EPC network.
4.1.1 Implementation of Network Configuration Method:
In this section we explain how the GUI is implemented and the technologies used to implement the GUI.
User Interface is designed to validate the input parameters by developing a JSON Schema where the structure and parameters entered in the GUI is defined. We have used alpaca JSON forms module to develop the GUI, we used apache as our web browser, We used PHP script in the background which takes the data filled in the GUI and Validates it with the BCAT scripts in the background.
24
As shown in the picture above all the parameters entered in the GUI are validated against JSON SCHEMA in the front end with a real time validation. Once all the parameters are filled the back-end script takes all the data filled in the GUI and generates a config file which can be used as an input to generate the HOT templates. If validation is failed the tools shows the error messages for the customers to fill in the data.
4.2 Experiment Test-bed
The hardware used for this process is HDS 800 CRU/ Dell 630 server. 1Gbit interface for controlling the CEE and 10 Gbit interface for VNF traffic.
The virtual network functions are deployed on the Dell 630 server which has 36 cores and 72 hyper-threads, memory 256GB and Disk capacity of 2 * 1.2 TB. The interfaces are connected via a switch or directly to BGW. The CEE provides the following functions for EPC-in-a-box.
vFUEL
• Installation of Host OS and virtualization components
• If required Fuel function can be disabled after EPC-in-a-box installation.
Atlas
› Used for deploying/installing vEPC VNFs
› Atlas GUI provides Fault Management for HW, Host OS and Virtualization layer
vCIC
• Performance Management (Zabbix) for HW, host OS and Virtualization Layer towards external OSS (SNMP)
25
• Fault Management for HW, host OS and Virtualization layer towards external OSS (SNMP)
• Management of Virtualization Layer Hypervisor (KVM/QEMU)
Host OS (Ubuntu) Virtual Switch (OVS)
Figure 8: experimental setup
4.2.1 Fuel VM
Fuel is not monolithic, it consists of several independent components. Some of those components are Fuel specific components, while others are third-party services, such as Cobbler, Puppet, or Mcollective. Some components can be reused separately from Fuel without any modifications, some require minor changes. Fuel components are described as follows:
• User Interface (UI) - Single page application written in JavaScript. It uses bootstrap and backbone frameworks underneath.
• Nailgun - The heart of a Fuel project. Nailgun is written in Python programming language. It implements REST APIs and deployment of data management, and manages disk volume configuration data, network configuration data, and other environment-specific data necessary for deployment. It uses orchestration logic to build instructions for provisioning and deployment in a right order. Nailgun uses SQL DBs to store its data and Advanced Message Queuing Protocol (AMQP) service to interact with workers. Fuel CLI provides even more possible actions than UI.
26
• Astute - It represents Nailgun workers and runs certain actions according to instructions provided by Nailgun. Astute is a layer, which encapsulates all the details about interaction with various services, such as Cobbler, Puppet, shell scripts. Nailgun provides a universal asynchronous interface to these services. Services can be managed directly through the native protocol, for example, the XML Remote Procedure Call (RPC) protocol is used for Cobbler. Services can also be managed by the use of Mcollective agents to perform specific tasks, such as launching "puppet apply" on a remote node or running a script. Astute exchanges the data with Nailgun using AMQP.
• Cobbler - It is used as a provisioning service.
• Puppet - The deployment service that is used to install OpenStack core components, while Ericsson component deployment and configuration are based on Ansible and run right after Puppet deployment.
• Mcollective agents - They allow the performance of specific tasks, such as hard drives clearing and network connectivity probing.
• OpenStack Testing Framework - OSTF or Health Check, is a separated component, which can be removed and reused without Fuel. OSTF implements post-deployment verification of OpenStack, and its main goal is to verify the maximum functionality taking minimum time.
› vFuel is an Ericsson component based on Fuel, running as a Virtual Machine (VM), providing the runtime environment for Fuel services
› vFuel manages the CEE infrastructure life cycle and is responsible for the following – Maiden software installation of the CEE software
– Updates of the CEE software
– Adding and removing hardware resources
› vFuel runs as a VM on a compute host. Depending on the capacity of the compute host, vFuel and one of the vCIC nodes can run on the same compute host. vFuel uses CentOS Linux as its OS. Not applicable for Box deployment.
› Fuel is an open source deployment and management tool for OpenStack developed by Mirantis. Fuel runs as a VM at installation time on an external machine and is migrated to one of the compute nodes. Mirantis OpenStack is delivered and deployed through Fuel, which implies a tight connection between Mirantis OpenStack and Fuel.
› Fuel is delivered as an image that is used to boot a Fuel master node. The node uses CentOS as operating system and runs the Fuel logic inside Docker containers.
› Fuel automatically discovers any bare metal and virtual nodes configured to boot from network. When they are identified and bootstrapped, Fuel installs the operating system, OpenStack components with dependencies and other services or processes that must be running on each node. After that, Ericsson added components and services are installed. When the system has been installed, Fuel is needed when a compute node is added, HW is replaced, or the system is updated.
› Fuel provides CLIs and APIs for management. The installation procedure is automated (scripted) in CEE and controlled by configuration files. Hence, the operator is not directly exposed to Fuel during installation
27
4.2.2 Fuel Setup
Figure 9: Fuel VM architecture
Fuel VM is installed using Virt manager using the fuel ISO image which is Linux red hat enterprise and it has 2048 RAM ,2 CPUs and 70 GB disk and install the Fuel VM.
4.2.3 Server Setup
For Dell R630, these are the ports and their use
– S2P1 (Slot 2 Port 1) is used for tenant traffic data – Eth0 is used for CEE control
– iDRAC is used to access the server during CEE installation and is the console interface for the server
Figure 10: Dell R630 ports
The Fuel VM needs access to three networks in the Box through the physical switch, eth0(Created by default) is bridged to the physical interface of the Vfuel Host server.
4.2.4 Deployment
The IP ranges used to allocate IP addresses for different interfaces are configured in the subnet section. IP ranges used for VNF services IP addresses are udpdated.
The different type of interfaces (linknet, loopback and service interfaces) are defined in routing domains. The routing domain can be seen as a VRF but at the network level (covers multiple network entities). In one routing domain interfaces and other network related settings are specified for multiple VNFs and BGWs.
Each interface must be allocated to an owner which the id of VNF or BGW which will use the interface. The validated configuration files for the VNF’s from the GUI are used to generate HOT templates by using box cloud and automation tools.
SAPC, SGSN-MME and EPG configuration files which include Common EVR
28
specific networking, the external connectivity configuration and application level configuration.
Flavors are added that defines the compute, memory and storage capacity of a virtual server as shown in the figure below.
Figure 11: Hardware Flavours in CEE
Images(.qcow) provided in the package are uploaded to the openstack using atlas.
Templates are generated using the configuration files for the VNFs such as EPG, MME and SAPC as an input to the BCAT script name bcat_create_hot.py which is takes this configuration as an input and the templates are generated from inputs and jina templates.
EPG is installed using atlas by uploading the respective HOT file generated from the previous step in the atlas under the STACKS section and the launch the stack by providing the stack name and password, wait for the process to complete. If the installation is successful you will be able to ssh using the IP provided in the cfg file from the FUEL VM to epg node using the credentials provided earlier. The same process is repeated for MME node and SAPC node.
After the deployment it has been observed that the configuration generated from the GUI provided a valid solution with which all the nodes are properly installed in the CEE.
29
5 R ESULTS AND A NALYSIS
5.1 Analysis of network configuration methods and
implementation
This chapter discusses the methods considered to configure the Virtual Network function in EPC-in-a-box, a study to identify mandatory interfaces required for the intercommunication of VNFs, Implementation of an appropriate method for generating the configuration files for the VNFs.
The implemented method has a user interface to fill the network parameters which are required to deploy VNFs and to validate the network parameters. These parameters are also validated by interacting with BCAT to detect faulty inputs. If the validation is passed it generates a configuration file which is used to build HOT templates for deploying them in CEE.
Figure 12: UI for the users to fill data
Figure 12 describes that a user can input the data required for network configuration.
5.2 Validation of parameters (with BCAT)
30 Figure 13: Validate with BCAT
Figure 14: Error messages
Figure 13. describes validation with respect to BCAT. Figure 14 displays the error message once the validation is failed, so that users can correct them.
5.3 Investigation of mandatory interfaces for EPG
The mandatory interfaces used by EPG to communicate with other VNFs based on the literature study. In EPC these Interfaces need to be configured and enabled, so that the data traffic between the VNFs can be established. The main motive behind this study is to analyze and identify the mandatory interfaces and develop our GUI in such a way that Users cannot pass the validation unless these parameters are configured.
EPG as a service there are mandatory interfaces needed which are being known upon the study and investigation of 4G lte network architecture. The mandatory interfaces which are needed to deploy EPG are S1-U, S4, S5, S12, Gx, Rx, S11, SGi and their responsibilities are described in detail in the Conclusion section.
31
5.4 Deploying VNFs on CEE using configuration files
from UI
The configuration file generated from the User Interface is tested by deploying the virtual network functions in a cloud environment. After installing the virtual machines user can ssh into EPG, MME and SAPC. The images below depicted as the virtual network functions are successful installed and the user can ssh into the nodes from the fuel VM.
Figure 15: EPG node
Figure 16: MME node
Figure 17: SAPC node
Figures 16, 17 & 18 shows that VNFs are successfully deployed and users can SSH into the nodes.
32
6 C ONCLUSION AND F UTURE W ORK
As we know that our research work is based on customer’s ease of use to configure the network. We found that the network configuration can be done in many ways of which the most familiar one’s are taken as our case study to carry out the research work and they are GUI and CLI. Users who are not familiar with a command line interface or graphical user interface may want to know the pros and cons of each to help determine what works best for them. Others may be curious to know about the differences between them. With a heavy focus on file commands and manipulation, the following categories illustrates which interface has the advantage in certain categories and why.
Ease: GUI is much more visually intuitive, users typically pick up on how to use a GUI faster than a command line interface. Due to higher degree of memorization and familiarity needed for operation and navigation, new users find operating a command line interface more difficult than a GUI.
Control: since GUI is being more user friendly than a command line. For new or novice users, a GUI is utilized by more users.
Speed: in a GUI, using mouse and keyboard to control file system or setting up the network parameters is going to be slower than using the command line.
Diversity: after you have learned how to navigate and use a command line, it’s not going to change as much as a new GUI. Although new commands may be introduced, the original commands almost always remain the same. Each GUI has a different design and structure when it comes to performing different tasks.
Strain: A command line interface is often very basic and can be more of a strain on a user’s vision. Whereas the use of shortcut keys in GUI and more frequent movement of hand positions, reduces the strain.
With all the discussed above categories, we can find trade-off between GUI and CLI way of deploying network configuration. But, we can say that for new user’s i.e., for both telecom and non-telecom, GUI way of deploying the network configurations becomes easier, since GUI acts user friendly compared to CLI. But to the end, it’s user’s choice to use a GUI or CLI.
6.1 Answers to RQs
RQ1: How to simplify the generation and validation of customer network configuration to deploy EPC-in-a-box?
In EPC-in-a-box there are few parameters such as Routing domains, Subnets, routing polices, ssh keys and apn which are customer specific and needed to be configured accordingly so that VNFs can communicate with each other. We have analyzed certain network configuration methods and selected a method which is more suitable to the customers. Here are the analyzed methods:
CLI: Network Configuration can be injected to the Virtual Machines by entering the commands on the CLI. Each virtual component must be configured with a different set of 3GPP-specific parameters, and when the SIC needs more capacity and more virtual components are instantiated, scalability problems may arise in managing and maintaining the configuration of a high number of VMs. As there are many parameters that needs to be
