Master Thesis Electrical Engineering

February 2018

Generation and Validation of Network

Configuration for Evolved Packet Core

Rohith Reddy Jonnalagadda

Faculty of Computing
Blekinge Institute of Technology
SE-371 79 Karlskrona Sweden
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:
Rohith Reddy Jonnalagadda
E-mail: roja16@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 Internet : www.bth.se

Blekinge Institute of Technology Phone : +46 455 38 50 00
SE-371 79 Karlskrona, Sweden Fax : +46 455 38 50 57

i
i
 ABSTRACT

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 and network management tools. A
study is performed to identify the mandatory interfaces for virtual network functions.

Keywords: NFV, virtual-EPC, VNF’s, EPG, SGSN-MME, SAPC

 ACKNOWLEDGEMENT

Firstly, I would like to thank my parents Ram Reddy Jonnalagadda, Sunitha and my
sister Harini, 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 Shiva Sai Sunkari for all the help
and support.

I also extend my great gratitude and appreciation to Shruti, Shanmukh, Robin,

Rajashekar, Bharath, Vignesh, Omsri, Vaishnavi, Pavitra, Renuka, Varma for their
moral support during my period of study in Sweden.

1
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

2
Table of Contents
ABSTRACT ...........................................................................................................................................I
ACKNOWLEDGEMENT ................................................................................................................... 1
LIST OF ABBREVIATIONS .............................................................................................................. 2
LIST OF FIGURES .............................................................................................................................. 4
LIST OF TABLES ................................................................................................................................ 5
1 INTRODUCTION ....................................................................................................................... 6
1.1 MOTIVATION ..................................................................................................................... 9
1.2 AIM & OBJECTIVES ......................................................................................................... 10
1.3 SCOPE OF THESIS ............................................................................................................ 10
1.4 RESEARCH QUESTIONS ................................................................................................. 10
1.5 RESEARCH METHODS .................................................................................................... 11
1.6 EXPECTED OUTCOMES.................................................................................................. 11
1.7 SPLIT OF WORK ............................................................................................................... 12
2 RELATED WORK .................................................................................................................... 14
3 BACKGROUND ........................................................................................................................ 16
3.1 LTE ..................................................................................................................................... 16
3.2 EVOLVED PACKET CORE .............................................................................................. 16
3.2.1 Serving Gateway ............................................................................................................ 18
3.2.2 Packet Data Network Gateway ...................................................................................... 18
3.2.3 Mobility Management Entity ......................................................................................... 18
3.2.4 Policy and Charging Rules Function ............................................................................ 19
3.2.5 Service Aware Policy Controller.................................................................................... 19
3.3 NETWORK FUNCTIONS VITUALIZATION .................................................................. 19
3.4 EPC-IN-A-BOX .................................................................................................................. 20
3.5 BCAT .................................................................................................................................. 21
4 METHODOLOGY .................................................................................................................... 22
4.1 METHODS TO CONFIGURE NETWORK ................................................................................... 22
4.2 EXPERIMENT TEST-BED ....................................................................................................... 23
4.2.1 Fuel VM ......................................................................................................................... 24
4.2.2 Fuel Setup ...................................................................................................................... 26
4.2.3 Server Setup ................................................................................................................... 26
4.2.4 Deployment..................................................................................................................... 26
5 RESULTS AND ANALYSIS..................................................................................................... 28
5.1 ANALYSIS OF NETWORK CONFIGURATION METHODS AND IMPLEMENTATION ....................... 28
5.2 VALIDATION OF PARAMETERS (WITHOUT BCAT) ................................................................ 29
5.3 INVESTIGATION OF MANDATORY INTERFACES FOR SGSN-MME ......................................... 30
5.4 DEPLOYING VNFS ON CEE USING CONFIGURATION FILES FROM UI .................................... 32
6 CONCLUSION AND FUTURE WORK ................................................................................. 34
6.1 ANSWERS TO RQS ................................................................................................................ 34
6.2 FUTURE WORK ................................................................................................................ 37
REFERENCES ................................................................................................................................... 38

3
 LIST OF FIGURES
FIGURE 1 : ARCHITECTURE DOMAINS BY 3GPP .................................................................................................. 7
FIGURE 2 : BASIC EPC ARCHITECTURE FOR LTE ................................................................................................. 8
FIGURE 3 : LTE SAE EVOLVED PACKET CORE .................................................................................................... 9
FIGURE 4 : FLOW FROM UE TO EPC.............................................................................................................. 16
FIGURE 5 : HIGH END ARCHITECTURE OF EPC, RAN ......................................................................................... 17
FIGURE 6 : NFV ARCHITECTURE .................................................................................................................... 20
FIGURE 7 : COMPONENTS OF EPC-IN-A-BOX................................................................................................... 21
FIGURE 8 : EXPERIMENTAL SETUP .................................................................................................................. 24
FIGURE 9 : FUEL VM ARCHITECTURE ............................................................................................................. 26
FIGURE 10 : DELL R630 PORTS .................................................................................................................... 26
FIGURE 11 : HARDWARE FLAVORS IN CEE ...................................................................................................... 27
FIGURE 12 : UI FOR THE USERS TO FILL DATA .................................................................................................. 28
FIGURE 13 : ENTRY OF SSH KEYS .................................................................................................................. 28
FIGURE 14 : ENTRY OF IPV4 ENTITY .............................................................................................................. 29
FIGURE 15 : VALIDATION OF PLMN PARAMETER ............................................................................................. 29
FIGURE 16 : VALIDATION OF IPV4 PARAMETER................................................................................................ 29
FIGURE 17 : VALIDATION OF SSH KEYS .......................................................................................................... 30
FIGURE 18 : EPG NODE .............................................................................................................................. 32
FIGURE 19 : MME NODE ............................................................................................................................ 33
FIGURE 20 : SAPC NODE ............................................................................................................................ 33
FIGURE 21 : SIMPLIFIED SOLUTION USING USER INTERFACE ............................................................................... 35
FIGURE 22 : ENTRY OF DATA FOR NTP_SERVERS, DNS_SERVERS, SNMP_SERVERS .............................................. 35
FIGURE 23 : ENTRY OF DATA FOR ROUTING DOMAINS, SUBNETS ........................................................................ 35
FIGURE 24 : ENTRY OF DATA FOR DEPLOYMENT............................................................................................... 36
FIGURE 25 : WRONG ENTRY OF DATA IN PLMN FIELD. ..................................................................................... 36
FIGURE 26 : CORRECT ENTRY OF DATA IN PLMN FIELD. .................................................................................... 37
FIGURE 27 : LTE EPC MME NETWORK INTERFACES ........................................................................................ 31

4
 LIST OF TABLES
TABLE 1 SPLIT OF WORK.............................................................................................................................. 13
TABLE 2 : INTERFACES FOR SGSN-MME ....................................................................................................... 32

5
1 INTRODUCTION

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
provided by other standardization bodies like 3GPP2, IEEE. All four domains are
connected to packet core domain (EPC). The core domain also consists of four basic
7
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 core
network. It performs basic tasks like authentication, establishment of bearers,
8
internetworking support, handover support, supporting traditional services like voice
and messages.

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
current 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. As a part of the thesis work, EPC-in-a-box test
case has been chosen. EPC is a framework for providing converged voice and data on

9
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 functions such as EPG, SGSN-MME.
The aim of the thesis is to provide a good method and develop a solution to customers
to configure EPC-in-a-box with Ericsson’s limitations. The generated configuration files
cannot be made visible due to the rules and regulations proposed by Ericsson. This
solution is designed only with respect to Ericsson’s specifications. Due to the timing
constraints, the developed solution cannot be commercialized. It still needs more
developments and improvements. The developed GUI is a prototype.

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?
10
 RQ addressed by Rohith Reddy Jonnalagadda

2.) How to handle faulty input parameters for their validation without using BCAT?
3.) How to investigate mandatory interfaces for deploying the SGSN-MME virtual
network function in EPC-in-a-box?

RQ addressed by Shiva Sai Sunkari

4.) How to detect faulty input parameters and their dependencies based on BCAT
internal validation of parameters?
5.) How to investigate mandatory interfaces for deploying the EPG virtual network
function?

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 softwares 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 are answered through experimentation, involving following steps:

• Scripts are written for the implemented method to detect faulty input
parameters and handle the parameters before deploying the services.
• The developed solution is tested on cloud environments to verify the
deployment of network functions.

RQ3 will be answered by performing a study on the SGSN-MME and analyzing the
mandatory interfaces required to deploy a validated EPC on the server.

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.
• A GUI is developed for the customer’s ease of use to configure the services.
• Mandatory interfaces needed to deploy EPG, SGSN-MME virtual network
functions in EPC-in-a-box are identified through literature study.
• The output of the GUI should be a functional YAML file and is used as an
input to the BCAT script (with BCAT’s own validation of the file internally)
with the parameters given by the customer.
• From the validation and testing stage, the behavior and compatibility of the
output of GUI for EPC-in-a-box are observed.

11
 1.7 SPLIT OF WORK

Section Topic Section Contributor

1 Introduction Rohith Reddy

Jonnalagadda
Shiva Sai Sunkari

2 Related Work Rohith Reddy

Jonnalagadda
Shiva Sai Sunkari

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 Rohith Reddy

Jonnalagadda
Shiva Sai Sunkari

4 Methodology 4.1 Methods to Configure Network Rohith Reddy

Jonnalagadda
4.2 Experiment Test-bed Shiva Sai Sunkari

5 Results and 5.1 Analysis of network configuration Rohith Reddy

Analysis methods and implementation Jonnalagadda
Shiva Sai Sunkari

5.2 Validation of parameters (without Rohith Reddy

BCAT) Jonnalagadda

5.3 Investigation of mandatory Rohith Reddy

interfaces for SGSN-MME Jonnalagadda

5.4 Deploying VNFs on CEE using Rohith Reddy

configuration files from UI Jonnalagadda
Shiva Sai Sunkari

12
6 Conclusion and Rohith Reddy
Future Work Jonnalagadda
Shiva Sai Sunkari
Table 1 Split of work

13
2 RELATED 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. This paper has shown the importance of EPC over different cloud
environments.

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. This paper helped us to
know the importance of network configuration and also provided the processing of network
configuration files.

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 paper has given us the information related to the interfaces involved and the
importance of each LTE components.

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 paper provided the
information related to the interfaces involved in EPC network and also provided a way to carry
out our research work.

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.

This paper [14], states the deployments of modular virtual network functions in software
defined infrastructure which enables cloud and network providers to deploy integrated
network services across different resource domains. This paper presented an approach to check
the consistency between the VNF description described from a set of structural models and
flowchart models and a proposed deployment on a real SDN infrastructure with its own
configuration manager.

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
14
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 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
which has given the support to opt this method in carrying out the research work.

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 BACKGROUND
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 [3] 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 [1] 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 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. This helps

16
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 [3] must be a high-performance, high-capacity, all-IP core network 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.

Figure 5 : High end architecture of EPC, RAN

17
 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 [5] 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. 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 [5] 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. 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 [5] 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. 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 eNode Bs – one of the key differences between
2G/3G networks based on RNC/SGSN platforms.

18
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.

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) [7] 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.

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.
19
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

Ericsson adopted the principles of NFV and virtualized all the packet core
components. The benefits of Ericsson virtual EPC includes all the benefits of NFV.
Ericsson has developed solution based on single server and the solution is called EPC-in-
a-box which contains all the evolved packet core components and this solution is for
systems with few subscribers, low throughput.

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.

20
 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).

3.5 BCAT
BCAT is a toolbox of scripts which are written in Python 2.7 for creating solution specific
hardware flavors for the cloud environment, to generate templates for VNFs (OVF/HOT),
Scale-out/Scale-in of solutions, Decommission VNF’s and to validate the network
configuration for VNFS. BCAT scripts are provided to the customer along with the vEPC
software.

21
4 METHODOLOGY

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.

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. The 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 [10], 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
22
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 [9]. 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.

To analyze the mandatory interfaces for the VNFs, A Thorough literature study
is performed on all the components of EPC and the interfaces are identified. Data
traffic can be established between the VNFs only when these interfaces are
configured and enabled. The main motive was to develop a GUI in such a way that
Users cannot pass the validation [2] unless these interfaces are configured. So,
literature study was chosen as a research method to identify the mandatory interfaces
for each VNF.

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.

v-FUEL
• Installation of Host OS and virtualization components

23
 • 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)
• 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 M collective. 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
24
 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.
• 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.
25
 › 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

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 updated. 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
26
(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 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 Flavors 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 config
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.

27
5 RESULTS AND ANALYSIS

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 those parameters are validated, and they are shown in
the following figures. 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 13 : Entry of SSH keys

28
 Figure 14 : Entry of IPv4 entity

The above figures describe that the user can enter the parameters needed for
deployment of VNF’s and these parameters are used in generating the configuration files
for each VNF.

5.2 Validation of parameters (without BCAT)

Figure 15 : Validation of PLMN parameter

In Figure 15, Here PLMN is a field which accepts number as an input, but in the
figure letters are entered, so an error message popped out asking for to enter a valid
number.

Figure 16 : Validation of IPv4 parameter

29
 In Figure 16, Here IPv4 is a field which accepts certain pattern as an input, but in
the figure random numbers are entered, so an error message popped out asking for to
enter a valid pattern for IPv4.

Figure 17 : Validation of SSH keys

In Figure 17, Here SSH keys is a field which accepts certain pattern as an input, but
in the figure random letters are entered, so an error message popped out asking for to
enter a valid pattern for SSH keys.

From the above figures, the validation of parameters is performed while entering
them on the user interface. So, that the proper configuration files are obtained as outputs
and can be used further to deploy VNF’s on Cloud Execution Environment. This sought
of indication helps the user to know what pattern is defined for each field, the way to fill
in the field and check whether the entered field passes the validation. Hence, continuous
monitoring done on the parameters entered so that it makes the work easier.

5.3 Investigation of mandatory interfaces for

SGSN-MME
The main component of the SAE architecture is the Evolved Packet Core (EPC). Mobility
Management Entity (MME) plays an important role in LTE EPC architecture. In fact, MME
is the main signaling node in the EPC. According to LTE University, LTE MME is responsible
for initiating paging and authentication of the mobile device. MME retains location
information at the tracking area level for each user and then selects the appropriate gateway
during the registration process. MME connects to the evolved node b (eNB) through the S1-
MME interface and connects to S-GW through the S11 interface. Multiple MMEs can be
grouped together in a pool to meet increasing signaling load in the network. MME also pays a
vital part in handover signaling between LTE and 2G/3G networks.

The mandatory interfaces used by SGSN-MME to communicate with other VNF’s based on
the literature study are show in the table below. 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 research 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.

30
Figure 18 : LTE EPC MME Network Interfaces

LTE EPC Description

Interface

S1 MME Interface for control application protocol between E-UTRAN and MME

S1 U Interface for S1 user plane data for each bearer between the E-UTRAN and serving
gateway. It enables serving gateway to another inter-eNB handover.

S3 Connection between SGSN and MME is provided by S3 interface. It enables

information exchange for mobility between inter-3GPP access networks.

S4 Interface between SGSN and serving gateway is referred as S4 interface. It

provides user plane support for mobility support between GPRS core and the
serving gateway. It also enables serving gateway to anchor the inter-3GPP
handover.

31
 S5 S5 interface provides user pane tunneling and tunnel management function
between the serving gateway and PDN gateway. It enables serving gateway to
connect to multiple PDN gateways for providing different IP services to the LTE
UE also used for serving gateway relocation associated with the UE mobility.

S6a Interface between MME and HSS is S6a. it is used for transfer of subscription,
authentication and authorization of users.

Gx This Gx interface provides transfer of QoS policy and charging rules from PCRF
to the policy and Charging Enforcement Function in the PDN gateway.

S11 This control plane interface S11 is used between MME and serving gateway for
EPS management.

SGi This SGi interface is used between PDN gateway and intranet or internet. This
interface is equivalent to Gi interface of GPRS.

Table 2 : Interfaces for SGSN-MME

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 19 : EPG node

32
 Figure 20 : MME node

Figure 21 : SAPC node (removed)

Figures 18, 19 & 20 shows that VNFs are successfully deployed and users can SSH
into the nodes.

33
6 CONCLUSION AND FUTURE WORK

As we know that our research work is based on customer’s ease of use to configure the network
for which EPC-in-a-box is taken as a case study. 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, CLI and Configuration Management Tools. CLI is
not adopted because as there are lot of parameters involved, 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. Since EPC-in-a-box has limited resources, and these provisioning
tools must be installed and run extra software on every server leads to complexity and these
tools are used for large scale deployments. Hence this method is not adopted. Therefore, a user
interface is developed through which all parameters which are mandatory to establish EPC
solution are entered and these parameters are validated. The data filled is also again validated
by using Box Cloud Automation Tools developed by Ericsson and errors are shown on the
GUI. Once the validation is passed, scripts in the backend build VNF specific configuration
file which is used as an input to build HOT templates for the VNF which include network
configuration, so that when the templates are deployed it automatically creates all the network
interfaces so that virtual network functions can form the communication among themselves.
The mandatory interfaces related to SGSN-MME are found out using the literature study and
made sure that they are configured properly to get validated EPC network. Since for
customer’s ease of use, control and speed plays an important role in order them to configure
the network. The developed GUI is a prototype and it is an application. We can conclude that
this approach helps customer to generate and validate network configuration for EPC-in-a-box
to minimize the manual interference as much as possible, and it makes easier for customers to
build a validated EPC network.

6.1 Answers to RQs

RQ1: How to simplify the generation and validation of customer network configuration
to deploy EPC-in-a-box?

The generation and validation of network configuration to deploy EPC-in-a-box is simplified

by developing a GUI which does validation, detect faulty input parameters, can interact with
BCAT tools for internal validation. Once the validation is passed and a valid configuration file
is generated which can be used to deploy the EPC-in-a-box. Even though there are many
methods to configure the network like CLI, configuration management tools etc., cannot be
adopted because of lack of validation, not user friendly and take up a lot of time to configure
the network. EPC-in-a-box has parameters such as routing domains, subnets, routing policies,
ssh keys and apn which are customer specific and needed to be configured accordingly so that
VNFs can communicate with each other and this method of configuring the network makes
the customer feel feasible and flexible since it reduces lot of manual interferences and saves a
lot of time. Hence, GUI way of deploying EPC-in-a-box is considered as the suitable and
simplified solution for the generation and validation of network configuration for customers
ease of use.

This is how the faulty input parameters are recognized and corrected to generate flavors of
each VNF, so that they can be deployed properly on the cloud execution environment.

34
 Figure 22 : Simplified Solution using User Interface

Figure 23 : Entry of data for NTP_servers, DNS_Servers, SNMP_Servers

Figure 24 : Entry of data for Routing Domains, Subnets

35
 Figure 25 : Entry of data for Deployment

All the above figures, shows that a simplified solution is presented for generation and
validation of network configuration for EPC-in-a-box. All the parameters needed to deploy
each VNF are entered and validated. And a proper configuration file is generated as output.

RQ2: How to handle faulty input parameters for their validation without using BCAT?

There is a user interface created with the help of tool Alpaca. The user interface interacts with
the data entered. If there is wrong data being entered an error message is popped out and gives
the user an indication about which field is entered wrongly. With this way input parameters
are monitored, and correct data related to the specific fields is being entered. The term faulty
input means that the entered parameters must follow specific pattern while inputting into the
GUI. There are some limitations and can be implemented in future solutions. For example, the
IP address like 127.0.0.1 can be recognized as correct IP but the checking of the IP entered is
not implemented in the current solution and can be done in future while making the GUI more
interactive to the users.
Here comes the figure which shows how the solution works when data is entered.

Figure 26 : Wrong entry of data in PLMN field.

36
 Figure 27 : Correct entry of data in PLMN field.

In Figure 26, PLMN field is filled with a number and there is no error message being popped
out. This is how the scripts are designed and implemented such that valid input parameters
are only accepted, and a configuration file is generated that is useful to deploy virtual
network functions in cloud execution environments

RQ3: How to investigate mandatory interfaces for deploying the SGSN-MME virtual
network function in EPC-in-a-box?

SGSN-MME 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
used by SGSN-MME to communicate with other VNFs based on literature study are shown in
the table above in Results section. In SGSN-MME these interfaces need to be configured and
enabled, so that the data traffic between the VNFs can be established. The main motive behind
this research is to analyze and identify the mandatory interfaces and develop a GUI in such a
way that Users cannot pass the validation unless these parameters are configured. The
mandatory interfaces which are needed to deploy SGSN-MME are S1-MME, S1-U, S3, S4,
S5, S6a, Gx, S11, SGi which are identified based on the literature study.

6.2 FUTURE WORK

The research work can be extended by making the GUI more interactive to the user’s. The
process of deploying network configuration on real cloud environments can be implemented
with help of a GUI. Since the thesis work focuses on customer’s ease of use to configure the
network, we can analyze the GUI in detail and can make it more user friendly to the customers.

37
REFERENCES
[1] T. Taleb et al., “EASE: EPC as a service to ease mobile core network deployment
over cloud,” IEEE Netw., vol. 29, no. 2, pp. 78–88, Mar. 2015.

[2] “BuchmannD.pdf.” .

[3] “LTE_Alcatel_White_Paper.pdf.” .

[4] “What are LTE Interfaces?” [Online]. Available: http://4g5gworld.com/ltefaq/what-

are-lte-interfaces. [Accessed: 07-Jan-2018].

[5] B. Barton, “Functions of main LTE packet core elements - MME, SGW, PGW.” .

[6] V.-G. Nguyen, T.-X. Do, and Y. Kim, “SDN and Virtualization-Based LTE Mobile
Network Architectures: A Comprehensive Survey,” Wirel Commun, vol. 86, no. 3, pp. 1401–
1438, Feb. 2016.

[7] A. Tawbeh, H. Safa, and A. R. Dhaini, “A hybrid SDN/NFV architecture for future
LTE networks,” in 2017 IEEE International Conference on Communications (ICC), 2017, pp.
1–6.

[8] A. Isabella and E. Retna, “Study Paper on Test Case generation for GUI Based
Testing,” ArXiv12024527 Cs, Feb. 2012.

[9] “2.3. Using NetworkManager with the GNOME Graphical User Interface - Red Hat
Customer Portal.” [Online]. Available: https://access.redhat.com/documentation/en-
us/red_hat_enterprise_linux/7/html/networking_guide/sec-
using_networkmanager_with_the_gnome_graphical_user_interface. [Accessed: 07-Jan-
2018].

[10] “Introduction to the Network Administration Graphical User Interface - Connecting

Systems Using Reactive Network Configuration in Oracle Solaris 11.1.” [Online]. Available:
https://docs.oracle.com/cd/E26502_01/html/E28988/introgui-1.html#scrolltoc. [Accessed:
07-Jan-2018].

[11] A. Patel, M. Vutukuru, and D. Krishnaswamy, “Mobility-aware VNF placement in

the LTE EPC,” in 2017 IEEE Conference on Network Function Virtualization and Software
Defined Networks (NFV-SDN), 2017, pp. 1–7.

[12] M. Liebsch and F. Z. Yousaf, “Virtualized EPC #x2014; Runtime offload for fast data-
plane scaling,” in 2016 IEEE 27th Annual International Symposium on Personal, Indoor, and
Mobile Radio Communications (PIMRC), 2016, pp. 1–6.

[13] H. M. Nguyen, S. H. Kim, D. T. Le, S. Heo, J. Im, and D. Kim, “EPCloud Flow: Load
Prediction and Migration Optimizations for EPC Network on Cloud,” in 2015 IEEE 8th
International Conference on Cloud Computing, 2015, pp. 981–984.

[14] J. Pelay, F. Guillemin, and O. Barais, “Verifying the configuration of virtualized

network functions in software defined networks,” in 2017 IEEE Conference on Network
Function Virtualization and Software Defined Networks (NFV-SDN), 2017, pp. 223–228.
[15] F. Graur, “Dynamic network configuration in the Internet of Things,” in 2017 5th
International Symposium on Digital Forensic and Security (ISDFS), 2017, pp. 1–4.

38
[16] N. Pitaev, M. Falkner, A. Leivadeasy, and I. Lambadarisy, “Multi-VNF performance
characterization for virtualized network functions,” in 2017 IEEE Conference on Network
Softwarization (NetSoft), 2017, pp. 1–5.

[17] S. Baucke, J. Kempf, R. B. Ali, A. Ramachandran, and S. Seetharaman, “Cloud API

support for self-service Virtual Network Function (VNF) deployment,” in 2015 IEEE
Conference on Network Function Virtualization and Software Defined Network (NFV-SDN),
2015, pp. 40–46.

[18] C. G. Bernardo, C. B. Donadel, J. F. Fardin, and L. F. Encarnação, “Distribution

networks automatic generation tool to perform statistical validations of technical planning
methodologies,” in 2017 IEEE URUCON, 2017, pp. 1–4.

[19] S. Meyer, P. Healy, T. Lynn, and J. Morrison, “Quality Assurance for Open Source
Software Configuration Management,” in 2013 15th International Symposium on Symbolic
and Numeric Algorithms for Scientific Computing, 2013, pp. 454–461.

[20] H. Takahashi and Y. Katsuno, “Optimizing Schedule for Parallel Software

Deployments Based on Profiles of Network Activity and Installation Time in Cloud
Environments,” in 2016 IEEE 9th International Conference on Cloud Computing (CLOUD),
2016, pp. 742–749.

[21] “System Architecture Evolution,” Wikipedia. 08-Nov-2017.

[22] S. Lee, T. Wong, and H. S. Kim, “To Automate or Not to Automate: On the
Complexity of Network Configuration,” in 2008 IEEE International Conference on
Communications, 2008, pp. 5726–5731.

39