Tesis Master Andrea Vallejo Puigvert PDF

Trabajo Fin de Máster
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA Y SISTEMAS DE TELECOMUNICACIÓN

DESIGN, DEPLOYMENT AND SW VALIDATION
TO VIRTUALIZE A MOBILE DATA CORE
NETWORK TO USE 5G TECHNOLOGY IN
VODAFONE
M ASTER T HESIS
BY
A NDREA VALLEJO P UIGVERT
J ULY 8, 2018
S UPERVISORS
C ÉSAR B ENAVENTE
F INI I RLES
M ARTA DE PABLOS
U NIVERSIDAD P OLITECNICA DE M ADRID
I NTERNET T ECHNOLOGY AND A RCHITECTURE
EIT D IGITAL M ASTER S CHOOL

A CKNOWLEDGEMENTS
I would particularly like to single out my supervisor and mentor Marta de Pablos, who always
was willing to help me not only with her patient, dedication, enthusiasm, and immense
knowledge but also with her motivating speeches which have helped me overcome any
difficulty. I could not have imagined having a better advisor and mentor for this master thesis.
I would like to sincerely thank my internship supervisor Fini Irles of the Data Core depart-
ment at Vodafone, for making this thesis possible and for her valuable support and guidance
during my internship with her.
I also like to thank all the Vodafone, Altran and Huawei experts who were involved in this
project and who helped me with their advice and explanations: Mario Pérez, Sergio Carretero,
María Jesús Jiménez, Raquel Perdiguero, Luisfer Bartolomé, César Antón, Fran Pariente, Juan
Manuel Temprado, Jorge Salas, Patricia Sánchez, Jesús Rodríguez, and Ángel Báez. Without
their passionate participation and input, this project would not have been successfully made.
I would also like to acknowledge César Benavente of the Department of Signal Theory and
Communications at the Polytechnic University of Madrid for having his office door always
open whenever I had a question about how to focus my research. Furthermore, I am gratefully
indebted to him for his very valuable comments on this thesis.
And last but not least, I must express my very profound gratitude to my parents and to my
sister for providing me with unfailing support and continuous encouragement throughout
my years of study and through the process of researching and writing this thesis. This accom-
plishment would not have been possible without them.
Thank you.
I
C ONTENTS
Acknowledgements I
Contents II
Abstract V
1 Introduction 1
1.1 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Businesss Plan 5
2.1 Executive Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Company Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Business Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Value Proposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 Market Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5.1 Competitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5.2 Customer Segmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.7 Go to the Market Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Project Planning 17
3.1 Time plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Precedence diagram method (PDM) . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4 Technical Background 29
4.1 Techniques for virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.1 Network Function Virtualization (NFV) . . . . . . . . . . . . . . . . . . . . 30
4.1.2 Software Defined Networking (SDN) . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Virtualized Network Architecture and Services . . . . . . . . . . . . . . . . . . . . 34
4.2.1 Virtual Evolved Packet Core (vEPC) Elements . . . . . . . . . . . . . . . . 34
4.2.2 vEPC Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 5G Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.1 Mobile Edge Computing (MEC) . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.2 Control Plane - User Plane Separation (CUPS) . . . . . . . . . . . . . . . . 42
III
CONTENTS
4.3.3 Non Stand-Alone and Stand-Alone Networks . . . . . . . . . . . . . . . . 44

4.3.4 Network Slicing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5 Deployment 47
5.1 Network Funtion Virtualization Infrastructure . . . . . . . . . . . . . . . . . . . . 47
5.1.1 Network Function Virtualization Infrastructure (NFVI) Physical Compo-
nents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1.2 NFVI Virtual Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2 NFVI Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.3 Connectivity Desing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.3.1 Low Level Design (LLD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.4 Installation and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.5 Software (SW) Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.5.1 Cases Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.5.2 Environment Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.5.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6 Conclusion and Future Work 105

6.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
A Abbreviations 107
B Additional Information 115
C Cases List 119
List of Figures 139
List of Tables 140
List of Traces 141
Bibliography 147
Declaration 149
IV
A BSTRACT
The world of telecommunications is constantly changing. Customers expectations are con-

stantly growing, pushing the market to adapt in order to meet new customers needs. In this
environment, new business models are created mainly focused on boosting data transfer,
turning into an aggressive growth of data in mobile networks. In fact, only during last year,
data consumption increased by 70%. On the other hand, customers want to enjoy this data
at any moment, in any place, and through a real-time experience. Due to this digital revolu-
tion, mobile communication is now one of the key essential services that society needs and
demands.
Within this framework, all mobile phone operators and in particular Vodafone Spain
are facing a great challenge. Vodafone needs to cope with this new scenario, increasing its
network capacity and its speed in data transfer. However, expanding the legacy network
without increasing tariffs is no longer profitable. It is time to introduce new technologies
suitable for this huge and constant data growth. Replacing the old bare metal network with a
new virtualized one is something that becomes necessary for Vodafone in order to continue
being a leading company in its sector. The advantages of virtualization will bring economic
benefits for the company and will help Vodafone to be prepared for this new paradigm
change.
On top of this, Vodafone wants to be the leader in innovation and it is constantly develop-
ing new technologies that will help to create new products and services for this new digital
society. The new virtualized network is the perfect scenario to take the first steps beyond
the implementation of the new 5G mobile generation in Spain. The digital transformation is
already changing the industry and society and Vodafone is already working to change our
daily life.
The future is exciting, are you
V
1
I NTRODUCTION
Since the market and the needs of people are constantly changing, mobile phone operators
have many new challenges to face, as well as new opportunities to take advantage of.
One of the main changes that the market is experiencing, is the growing penetration
of smartphones. This growth is resulting in a higher demand for mobile data. Users are
demanding better and faster quality services at any time and in any place.
In this context, new Over the Top (OTT)s are trying to break into the market to offer new
applications and services to customers.
This situation has created more competitiveness among them and has brought new
innovative ideas and business models. Nowadays, OTTs like Netflix or Amazon can generate
revenues from their services faster than in the past. And this is thanks to the fact that they are
growing and changing continuously, following the consumer demand.
In addition, OTTs are also responsible for causing an exponential increase in data con-
sumption, and more specifically the ones that offer high-definition video. Therefore, for the
optimal functioning of all these applications and services, new and better data core network
resources are required.
What does this mean for mobile operators? if they want to support these services and
applications, they should move fast to adapt all their infrastructures, according to the new
requirements imposed by consumers and OTTs. This is why Vodafone decided to renovate its
data core network by virtualizing it.
However, these are not the only reasons that are pushing mobile operators to change.
There are also other factors such as the new competitors that are emerging in the market
through the Mobile Virtual Network Operator (MVNO). This new concept of operators is
shaking the market by decreasing the prices of their services. This fact is impacting all the
consolidated operators in the Spanish market. In fact, the most impacted one in the past few
months is Vodafone, losing a large customer base due to the high customer churn rate.
Virtualization is not only the enabler for this quick adaptation but also a new source of
revenues because the user is allowed to consume more. So, the higher the consumption, the
greater the benefit. Furthermore, virtualization allows the implementation of new network
architectures, such as MEC or network slicing, that are the main enablers for new subscription
services key to monetizing customers relationships.
Vodafone wants to stop being just the data access pipe for customers to become also a
1
CHAPTER 1. INTRODUCTION
company that offers added value services to its users through the new technologies.
In order to virtualize the network, some tools are needed. NFV is a method which allows
virtual instances of physical networks to be separated in virtual resources. These resources
can work in independent sections or combining them with the objective of providing network
services. The aim of network virtualization is to improve the productivity and efficiency of
legacy networks by performing tasks automatically. Moreover, this kind of networks can be
managed in a central way through a single physical site.
SDN is a set of techniques whose goal is to facilitate the implementation of network
services in a deterministic, scalable and dynamic way. Thanks to SDN, it is possible to
avoid the network administrator to manage such services at a low level, improving network
performance and monitoring.
NFV and SDN are the best allies to quickly adapt the network to the different changes
since they can virtualize the network functions of the traditional network. This is made
by dynamically adapting, arranging and distributing the available resources according to
the demand. Hence, any modification is fast and easy, reducing costs and improving the
time-to-market. In addition, using virtualization over the network brings the opportunity to
obtain new revenues:
- On one hand, SDN allows the network to direct the data traffic flows, without the need
to rely on the Hardware (HW). Therefore, all decisions are taken by SW and there is no
need to provision or configure the network in a manual way. This brings benefits to
the network, such as: Increase automation, enhance security, reduce operating costs,
cloud-ready infrastructure.
- On the other hand, NFV can modify the services and features of the applications on
demand to better suit the needs of the consumers. In addition, it also works without
needing to make any changes in the HW since all the modifications are made on the SW.
Another advantage of NFV is that it is possible to rapidly scale services and applications
up or down and place it wherever is needed over the network. For instance, centralizing,
distributing, or placing it closer to the consumer by using MEC, or creating layers with
specific functionalities according to each service or application by using Slicing.
As a conclusion, thanks to NFV and SDN, there is no need to have one HW per function,
as it was before since the functions are virtualized. As a result, there is a reduction in the
Capital Expenditures (CAPEX) and Operating Expenses (OPEX) of the company. Moreover,
thanks to these two tools, the network can not only be virtualized but also facilitates the
support of future 5G technologies.
Furthermore, virtualization is the first step that brings closer the reality of 5G in the
data core networks by using Non Stand-Alone (NSA) architectures. Once this step will be
done, the following phases will consist of adapting the data core to the new architecture,
called Stand-Alone (SA), standardized by the Third Generation Partnership Project (3GPP)
organization. 5G will brings more innovation and new business ideas based on low latency
applications. Furthermore, the areas of use are very broad, for instance: health and wellbeing,
automotive and mobility, security and surveillance, industry and manufacturing, energy,
smart city, education, learning, or entertainment, among others.
2
However, not all are advantages in the virtualized environment since there is a long
journey to get there and a lot of challenges to face. First of all, there are new Network
Element (NE)s that need to be developed, following the already established 3GPP standard.
Another challenge is the adaptation to services on-demand, which will need to be a dynamic
and policy-based. Besides, for managing all this, it is necessary to integrate an infrastructure
with a real-time analytics.
In order to implement all this, it is necessary to carry out several tasks, such as: Integra-
tion and dimensioning, connectivity desing, NEs instalations, NEs configuration, SW , and
production deployment. All these steps need to be done fast, always taking into account the
time-to-market.
The objective of this thesis is to show the reader all the necessary steps to virtualize the
data core network of Vodafone. To do this, all activities that were carried out will be explained,
covering business and technical areas.
Therefore, this master thesis is mainly divided into two parts:
- The first part has a more business approach. Here, there will be explained the prob-
lems that Vodafone had to face, and for which Vodafone had to make the decision to
modernize its network. It will also expose in detail its value proposition, detailing the
services that Vodafone will offer to their clients.
Besides, the results of the market studies will be indicated, showing which are the
direct competitors of Vodafone, as well as its customer segmentation. Additionally,
the Vodafone’s go-to-market strategy will be exposed, on which the company wants to
attract more customers.
Finally, the management part of the project will be detailed. The intention of this
section is to give the reader a general view of how a project of this type can be structured
in scope, time and cost.
- The second part of the thesis, is more focused on the technical approach. It will start
with the legacy network overview and it will cover all the steps needed to virtualize the
network, deep diving on the NEs design and implementation. Specifically, this thesis
will be mainly focused on the following platforms: Virtual Unified Packet Gateway
(vUGW) and Virtual Unified Serving Node (vUSN), which could be considered the two
most important nodes to ensure the proper functioning of the network. Both platforms
are provided by Huawei company since Vodafone has opted to renew its network
with products of this company. Additionally, the NEs Centralized Gateway (CGW) and
Distributed Gateway (DGW)which conforms the vUGW in 5G networks (NSA), will be
introduced to the reader.
Therefore, all the technical activities involved in carrying out this project will be ex-
plained in detail. For instance, Integration and dimensioning, connectivity desing, NEs
instalations, NEs configuration, and SW validation.
Finally, the results of the tests carried out in the platforms vUSN, vUGW, CGW, and
DGW will be exposed and commented.
3
1.1 T HESIS O UTLINE

This thesis is structured in six chapters, as follows:
• Chapter 1: First chapter is the introduction, where is a summary of the subject of this
thesis, as well as the motivations.
• Chapter 2: Second chapter presents the business plan of this project on virtualization
of the network and 5G. The company description, value proposition, goals, market
analysis, strategy, are shown in this chapter.
• Chapter 3: Third chapter introduces the project planning, with all the schedules and
activities performed during the project, as well as the and budget used.
• Chapter 4: This chapter gives an overview of the technical background. Here, topics
like techniques for virtualization, virtualized network architecture, and 5G networks
are explained.
• Chapter 5: Chapter five has the technical deployment description. Furthermore, this
chapter will give details about the virtual infrastructures used during the deployment
of the virtual network. Besides, the connectivity design will be discussed. Moreover,
the procedure used to install and configure all the platforms is shown, as well as the
use cases, SW Validation and its results.
• Chapter 6: The final chapter gathers the conclusions that have been reached after
carrying out this thesis, as well as possible future works.
4
2
B USINESSS P LAN
This chapter gathers all the parts that make up the business plan for this project. It is divided
into seven parts:
First, a brief summary of the business plan will be presented to have an overview of the
chapter.
Second, a company description will be provided to know what was the beginning of
Vodafone, and how it has managed to be one of the best mobile operators in the world.
Furthermore, in the third section, the Business Drivers section is presented. The idea is to
provide the reader with all the reasons why Vodafone has decided to modernize its data core
network, and what they want to achieve with it.
The value proposition is the fourth part of this chapter. Here, it is explained why the
customer should buy the products and services that Vodafone provides with its new data core
network.
In the fifth section, there are two studies which analyze the market status: One to deep
dive into the main competitors and another to be aware of the customer segmentation.
Following, it is exposed the main steps necessary to validate the services and products
offered by Vodafone. This section will be more developed in Chapter 5, where all the details
of how this implementation was made are presented.
Finally, the seventh section gathers information about which is the Vodafone’s pricing
strategy, as well as its promotion strategy to sell their products and services.
2.1 E XECUTIVE S UMMARY

During the last years, the situation of the mobile telephony market has changed radically.
On one hand, Vodafone has lost around 243,900 users because of very aggressive marketing
campaigns carried out by Orange, and also due to the low prices strategy of MásMóvil. This
places Vodafone as the third mobile phone company in Spain behind Movistar and Orange.
On the other hand, there is more and more data consumption and more applications that
demand high performance from operators’ data core networks.
For those reasons, Vodafone has decided to bet on virtualizing its data network in order to
be able to increase resilient capabilities and network performance, improving user experience
and increasing profitability, that in the end comes into loyalty.
5
CHAPTER 2. BUSINESSS PLAN
The main competitors of Vodafone are Movistar, Orange and MásMóvil but currently
main one is MásMóvil due to its powerful price campaign that is increasingly, attracting users
of other operators.
The new services that can be implemented thanks to the Vodafone data core network
virtualization, are mainly focused on people from Europe, who are individual clients between
18 to 30 year old, and who are located in urban and semi-urban areas.
Moreover, the pricing strategy will be based on the quality of service offered. The higher
the quality of the service, the higher the pricing. However, these prices will be adapt depend-
ing also on the competitors pricing strategy.
All these will be promoted by an aggressive campaign, where all the products and services
will be advertised through as many channels as possible, like TV, radio, press, and social
media, among others.
2.2 C OMPANY D ESCRIPTION

Vodafone is a telecommunications operator with headquarters in Newbury, United Kingdom.
It was initially known as Racal Telecom in 1983, but in 1991 it was finally founded as Vodafone.
Vodafone has subsidiaries spread all over the world, and all these countries are part of
the association called Vodafone Group. It provides mobile services in 26 countries, fixed
broadband services in 17 countries and it has agreements with another 49 [34].
The economic benefits and the number of customers of Vodafone have consolidated the
company as one of the most important telecommunication operators in the word. In fact, at
the end of June 2017, Vodafone had more than 518 million mobile telephony customers, as
well as more than 15 million fixed broadband customers. These numbers place Vodafone as
the second bigger telecommunications operator in the world.
One of the fourth big markets of Vodafone Group is Spain. Vodafone started there by
buying Airtel’s shares in 1999, until taking control of the entire company. In addition, with
the intention of continuing to grow, in 2014 Vodafone Spain bought the Corporative Group
ONO, S.A., and went to the market with its first MVNO called Lowi.
Nowadays, Vodafone Spain has about the 25% of the market share, with large numbers
of consumers in the different services offered: 14.4 million mobile telephony customers,
7,5 million in 4G services, 3,2 million fixed broadband, 2,3 fibre, 1,3 Vodafone TV, and 2,3
Vodafone ONE. Figure 2.1 shows what has been the growth of the company in terms of
customers, from 2014 to 2017. All these numbers, place Vodafone Spain in the third position,
behind Movistar and Orange [37], [27].
The successes achieved by Vodafone Group and Vodafone Spain are the keys to consoli-
date this company as one of the most important in Spain. These achievements can be divided
into several major milestones, where Figure 2.2 holds the most significant ones.
All this could not have been achieved without having the best network infrastructure.
Actually, Vodafone Spain is able to provide Global System for Mobile comunications (GSM)
(2G) services at 900 and 1800 MHz, Universal Mobile Telecommunications System (UMTS)
(3G) at 900 and 2100 MHz and Long Term Evolution (LTE) (4G) at 800, 1800, 2100 and
2600 MHz. Besides, the data core network of 4G is compatible with 4G+ which provides
6
Figure 2.1: Customer Key Indicators (2016-2017) [34].
Figure 2.2: Milestones and Launches: Vodafone in Spain (1994-2016) [34].
a download high speed. Moreover, Vodafone’s network can cover around the 94% of the
Spanish population with its coverage, being the best mobile operator in terms of coverage.
In addition, it was selected as the winner of the P3 testing carry out in Spain [3]. For more
information, see Subsection 2.5.1.
2.3 B USINESS D RIVERS

The objective of this project is to change the Vodafone’s data core network to adapt and cover
the new needs of the market and the users. Furthermore, the other main objective is to obtain
new revenues stream thanks to the use of new technologies such as virtualization and 5G.
Nowadays, people spend around 30 minutes per day watching videos on mobile devices,
when in 2013 it was just 10 minutes every day. Besides, people also spend a lot of time
with the phone to send messages to their friends. In fact, there are two main messaging
applications: WhatsApp, Facebook Messenger, which have almost one billion monthly active
users. In addition, around 60% of all payment transactions are now made digital. Moreover,
it is estimated that there are more than 30 million Amazon devices in the homes of users,
compared to 10 million at the end of 2016.
All these show that there is an exponential increase in the consumption of data in the last
two years, and more especially since the appearance of applications such as Instargram, or
7
platforms such as Netflix.

To have a broader vision of the consumption that can be generated daily, Figure 2.3 has
represented the most important OTTs currently and their Gbps per day consumed. The
image shows that the applications that have a higher data consumption per day are YouTube
and Instagram with their "Instagram Stories".
Youtube has been consolidated as favourite channel of users to watch videos. But Insta-
gram follows it closely, and it is expected to increase its numbers. The third application of
video consumption is Netflix, although it still has enough to reach the other two previously
mentioned. Video and audio download applications, such as BitTorrent, are losing strength.
This is because more and more multimedia content is consumed through applications, and
not by downloading files directly.
Figure 2.3: Top Apps – Daily Data Volume (GB/Day) [25].
Although the data consumption today is quite high, it is expected to increase even more.
In fact, this traffic forecast is another factor for which Vodafone has decided to renew its
network. In order to face this new situation, capacity, and data upload and download speeds
will need to improve.
Below, in Figure 2.4 is the traffic forecast of data that Vodafone expects to have in the
coming months. In black, the demand that would be presented without considering the
increase in data consumption is represented, while red line represents the new demand.
It should be noted that there is a considerable peak in the month of August, and more
specifically from 15t h of August, where the traffic forecast peak is 347 Gbps. This is due to the
fact that as of that date there is a greater consumption of data for the summer holidays. In
this month an increase of 25% is expected, and 7% in the following months.
The solution found by Vodafone to deal with these new situation, is virtualization. Thanks
to the use of virtualization, it is expected to cover this increase in data consumption and pro-
vide enough capacity to face unforeseen large spikes of data. Figure 2.5 has a representation
of network capacity evolution. The traffic forecast expected is the line in red, and the resilient
capacity in the future month, the line in blue. As it is possible to see, the resilient capacity is
more than enough to cover these needs.
The virtualization of Vodafone network will be done gradually. Lines carrying more data
traffic will be virtualized first. After, it will be virtualized the rest of the lines. Figure 2.6 has
8
Figure 2.4: Traffic forecast - Vodafone Spain [25].
represented how the scenario will be for March 2019, where a 45% of the network will be
virtualized using Virtual Network Functions (VNF). In order to see more information about
what is virtualization, go to Section 4, where there are explained the main concepts of this
solution as well as some tools which are needed in order to implement it.
Figure 2.5: Traffic forecast vs. Capability Figure 2.6: Forecast: VNF and Legacy in
[25]. 2019 [25].
2.4 VALUE P ROPOSITION

The main objective of Vodafone is to connect people worldwide, allowing the users to en-
joy communications across different mediums convenient & secure. Therefore, the client
experience is one of the keys within the value proposition.
To achieve this, Vodafone offers an improvement in its data core network, with which
it manages to improve the resilient capacity of the network, as well as its performance.
Therefore, it will be able to provide higher speed data transmission, and greater bandwidth,
which will make the data user much faster than they have ever been.
With this, Vodafone aims to surpass all its competitors and offer the user the opportunity
9
to use the best services from one of the best networks in the world. Vodafone also aims to
reach more and more consumers, and therefore expand its market.
2.5 M ARKET A NALYSIS
2.5.1 C OMPETITORS
There are two types of competitors among mobile operators: Operators which have their own
network called Mobile Network Operator (MNO), and operators called MVNO. The MVNO
does not have its own infrastructure, so it uses the network of others in order to provide
coverage to their customers.
In the Spanish market, the operators with their own network are Vodafone, Movistar,
Orange and Yoigo (recently adquired by MásMóvil). They have their own infrastructure and
because of this reason, they are able to provide more and better services than the MVNO.
However, the MVNO are in general cheaper than the MNO and they have been very well
received by users. This is why it has increased the number of this kind of operators in the
last years. These companies have been so successful that some MNO have created their own
low-cost brands in order to compete with the MVNO. For instance, Vodafone has had created
Lowi, which offers rates at lower prices. However, other mobile operators instead to create
other brands, they have bought companies that already existed. Figure 2.7 has a map of how
is the current situation of the relationships that exist between mobile operators in Spain.
Figure 2.7: Map of the main unions between mobile telephony operators in Spain.
The study of the competitors will be carried out, taking into account the four main
operators with its own infrastructure, and the main competitor of the virtual operators. These
are: Vodafone, Movistar, Orange and MásMóvil.
In this first part, there is a more business approach where the situation in the market
of all the operators will be evaluated. However, the second part will have a more technical
10
approach, where the technical features of each company will be compared.

The following Figure 2.8, shows the market share of the main mobile telephony operators
in Spain in December 2017. These statistics are related to the number of lines registered by
each operator. The three main operators are Movistar, Orange and Vodafone, respectively,
which have 80% of the total market. The rest of the market is for the set formed by the MVNO.
Figure 2.8: Market share of mobile telephone companies in Spain (December 2017) [29].
As seen in the image, Movistar is in the lead, followed closely by Orange in the second
position, and Vodafone in the third position with a 24.9% share. Last year, Vodafone occupied
the second position in this ranking, so it can be said that the results have worsened for them.
It should also be noted the percentage of shares that MásMóvil has achieved in less than a
year.
These results are mainly due to two factors. The first is the appearance of the operator
MásMóvil, which has made offers at a very low price, causing users migrations from other
companies to MásMóvil. Secondly, there are the marketing campaigns carried out during 2017
by Orange. These campaigns were specially prepared to capture Vodafone users. Therefore,
Vodafone has experienced large amounts of portability in this last year for these two causes.
Figure 2.9 gives more details about this situation. On the left side of the image, the
variation of registrations and portabilities that have been produced since January 2017 is
represented. In this graph, it is clear that the company that has achieved the highest number
of registrations is MásMóvil, with numbers that are much higher than the rest.
As soon as Másmóvil appeared, Vodafone experienced an increase in portability. And
after some months, Movistar and Orange have been affected as well. The main difference is
that both Movistar and Orange, have almost maintained their number of customers, thanks
to the fact that they also had an increase in registrations, which offset their high number of
portabilities. But this is not the case with Vodafone, which, although also had high, these
have not been enough to end the year in positive.
On the right side of the image, the total number of users who have won or lost these four
mobile telephony operators are represented. MásMóvil managed to end the year with 403,750
11
more users than at the beginning of the year 2017. This amount is very high and shows that
this company has earned a place in the Spanish market for mobile telephony. However,
observing the other three companies, it is clear that all have lost users. So, it is possible to
affirm that these users made their portabilities to the operator of MásMóvil. Among these
three companies, Vodafone has the worst results, with a loss of 243.900 users in one year.
These results are the worst numbers they have ever had. Although Movistar also has losses of
129,235 and Orange of 145,650, the user losses of Vodafone are still significantly bigger.
Figure 2.9: Registrations and portabilities of 2017 in Spain [4].
Although Vodafone finished in the third position in a number of lines in 2017, it has been
the company with the best results in the tests carried out by companies specializes in wireless
coverage mapping. This thesis will discuss the results in particular of one of these companies:
P3 Connect Mobile Benchmark.
It measures network quality and identifies potential areas for improvement. The reason
why this company is commented here and not other it is because its results are highly
objective and it is considered authoritative.
The tests were carried out in cars that travelled through 17 large cities of Spain (with more
than 100,000 inhabitants each), as well as in small towns. In total, P3 Connect Mobile Bench-
mark ended up covering 11,520 kilometres in October 2017. The measurements were made
using mobile phones that perform measurements of the voice and data services configured
with 4G.
For voice tests, test calls were made between vehicles and the quality of the audio was
evaluated using broadband algorithms. And for the measurement of data tests, the maximum
data volume was evaluated in uplink and downlink. Measurements were also made in video
streaming, adapting the resolution of the video depending on the available bandwidth.
The results show that all Spanish mobile operators have improved their networks com-
pared to the previous year. But only Vodafone has managed to stand out above its competitors,
remaining in the first position for the third consecutive year. Figures 2.10 and 2.11 have the
results of these tests.
Vodafone has the highest scores, both in voice and data, although it was not in the first
position in crowd score. Movistar has the second best results, followed closely by Orange.
12
However, Yoigo was in the fourth position with the worst results, and very far from the
third [3], [2].
Figure 2.10: P3 Measurements Results [3].
Figure 2.11: P3 Overal Results [3].
Looking more closely at the results in Figure B.1, it is possible to see the most representa-
tive values of voice measurements. They show the percentage of success in the calls, the time
of configuration of the call (in seconds), as well as the average quality of the voice call.
Vodafone continues to occupy the first place followed by Orange with regards the voice
quality during calls. In addition, with respect to the success rate, Movistar ranks second,
approaching Vodafone, which is again the first with an average success rate of 98.5% in all
13
measured areas. However, in the time necessary to establish a call, Orange occupies the first
position being the fastest operator with an average of 3.3 seconds per call. In the case of
Yoigo, the results obtained place them in the fourth position in all fields.
Moreover, the results of the measurements made for evaluate the data transmissions,
are in Figures B.2, B.3 and B.4. These images have the drive-tests in Cities Towns and road,
respectively. The measures were carried out in the 4G networks of the operators (although it
should be noted that, in the case of Yoigo, they still do not have the full deployment of LTE
network). The results show that Vodafone is the clear winner over its competitors in all the
comparative analysis that were made. Movistar obtained the second position and Orange
the third. Yoigo, although it was in the last position, showed a remarkable improvement with
respect to the previous results of P3 connect Mobile Benchmark [2].
2.5.2 C USTOMER S EGMENTATION

Vodafone is well diversified geographically. Actually, it has subsidiaries spread all over the
world: Albania, Australia, Czech Republic, Egypt, Faroe Islands, Germany, Ghana, Greece,
Hungary, Iceland, India, Ireland, Italy, Malta, Netherlands, New Zealand, Portugal, Romania,
Spain, Turkey, Qatar, UK, and Ukraine.
However, the highest amount of Earnings Before Interests, Taxes, Depreciations and Amor-
tizations (EBITDA), was achieved in Europe. Figure 2.12 has represented this distribution.
This is closely related to the number of mobile users in each country. That is because, in
Europe, there are many more mobiles per person than in other continents as in Africa, Asia
or the Pacific. This is why the difference between continents is so big.
Figure 2.12: Geographical market segmentation [23].
Vodafone’s customers consist of retail customers, third-party resellers and corporate

companies. Actually, 92% of its customers are individuals and families while an 8% are
enterprises.
Within the individual clients, their main target is people from 13 to 65 years old, and most
of them are located in urban, semi-urban and rural areas. Although more specifically, the
Vodafone’s target would be, youth and people located in urban and semi-urban areas, where
there are more people who are willing to pay more for a premium service. Actually, the largest
data consumption is among people aged 18 to 30 located in urban areas, [33], [8].
14
2.6 VALIDATION
Once the decision to virtualize the network was made, many studies and manuals were made
in order to know the theory of how to implement this solution. However, it is not a good idea
to start virtualizing the whole data core network based only on these manuals since many
failures can occur during the implementation and many users may be affected.
For this reason, during the validation phase, a testbed line was created, which was smaller
compared to the production lines, but large enough to validate the entire virtualization
process. All the testbed line was created by using Huawei HW.
First of all, the entire HW infrastructure was placed to form the testbed line, which was
formed by three clusters. Then, on this HW, the SW needed to implement all the NFVs, such
as vUSN, vUGW, DGW and CGW, was installed through virtualization tools. Subsequently,
these NFVs were tested to validate its correct functioning. The tests that are used for SW
validation, are listed in the Appendix C. To see more information about how the process of
implementing this testbed line was, go to Chapter 5.
The next step after validating the SW is to migrate a small number of users to this testbed
line to ensure that everything works well without incident. During this process, the testbed
line is continuously monitored, and analyzes are taken to check its performance. Once this
validation has been carried out successfully. The rest of Vodafone’s production lines can be
virtualized following the same steps mentioned above.
Chapter 3 has more detailed information about how was the entire process of the virtual-
ization project.
2.7 G O TO THE M ARKET S TRATEGY

Vodafone deals in vertical business called Mobile Telephony. One of main Vodafone’s objec-
tives is to ensure the loyalty of its customers by providing high-quality services.
Vodafone will price its future products and services in a competitive way in order to beat
its competitors. The main products and services are pre-paid, post-paid and Value-Added
Service (VAS).
The pricing strategy will be done differently for each segment that Vodafone targets,
depending on its necessities. Therefore, each customer segments will be charged depending
on the type of tariff that they have contracted. Besides, Vodafone will add products like
mobile phones, to make the tariffs more attractive to the customer.
Base on the quality of service, such as high speed, bandwidth, type of data traffic, the
tariff price will be one or another, where the higher the quality of the service, the higher the
pricing. However, the price campaign will also be adjusted taking into account the prices of
the products and services of its competitors.
Their services an products are sold through customer care centers, physical shops, online
shop, and independent retailer shops. Furthermore, they have distributed across the country
thanks to its strong distribution network.
The way that Vodafone wants to sell these products and services are mainly based on
advertising it. The idea is to make an aggressive marketing campaign, promoting the brand
15
through TV, press, prints, online, radio (Vodafone Yu program), and social media advertise-
ments, among other channels. Additionally, Vodafone will promote its services and products
through sports stars and celebrities in their advertisements to attract all kind of audiences. In
fact, associate the brand with such stars, it is already demonstrated that increase the brand
value.
Once launched this campaign, Vodafone will keep track of the development of the cam-
paign and it will investigate to determine how the campaign is perceived by consumers. As
well as to know how is the satisfaction of the users using their products and services.
For Vodafone, its highest priority is its customers, that is why it is very important for them
to know how their customers’ satisfaction is. So, they can modify and improve their services
as soon as possible, and thus always guarantee the best experience for their customers [19].
16
3
P ROJECT P LANNING
In this section, all the project plan is explained. The purpose of this part of the thesis is to
provide the reader with an overview of which were the activities that were carried out during
the project. For it, the activities and their schedules will be described below, using the method
Project Management Professional (PMP) of the Project Management Institute (PMI), which
uses different tools, such as: Precedence Diagram Method (PDM) and Gantt chart.
Moreover, the last part of the section will describe the budget scheme used, including
some of the elements which are part of the CAPEX and OPEX of the project.
3.1 T IME PLAN

In this section, the time plan of the project will be shown by using a type of bar chart called
Gantt. The Gantt chart is a graphical tool used in project management, which uses bars to
illustrate the expected dedication in time of different tasks over a given total time.
First of all, the activities were listed in a generic way. That is not in indivisible activities, but
in tasks that host other activities, see Figure 3.1. For example, let’s consider the duties involved
in this proyect, which are: Test bed preparation, 5Tth Gi Line Legacy, vUSN and vUGW testing,
Virtual Mobile Subscriber Equipement (vMSE) testing, vUSN and vUGW deployment, vUGW
traffic migration, vMSE deployment, acvUSN and vUGW traffic migration, and vMSE traffic
migration.
Besides, to have more complete information, the most important milestones achieved
during the realization of the project have been also added to this chart. The milestones are
represented by starts, as it is possible to see in the right corner of the Figure 3.1.
Although not all the activities mentioned above are going to be explained by this thesis, it
is important to mention all of them. The idea is to provide the reader with an overview of
the type of activities necessary to virtualize a core data network. For example, although this
thesis will mainly talk about the vUSN and vUGW, vMSE was also developed in parallel. This
node was not included in the thesis for lack of time, since, as it is possible to see in the time
plan, most of its activities were planned to take place between August and October 2018.
Below is a brief explanation of the most relevant activities of the project, indicating why
the duration of each of them:
17
CHAPTER 3. PROJECT PLANNING
Test Bed Preparation: Before virtualizing the production lines of the Vodafone network,
tests were first carried out on a test bed line. For that reason, this testbed line had to be
built, practically from the beginning. So, the number of activities that had to be done
during this process were many: HW purchase, HW delivery, connectivity design, and
HW installation and configuration. In addition, all the bureaucratic processes involved
in each of the mentioned sub-tasks took also time into account. Therefore, taking into
account all these reasons, the Test Bed Preparation was organized to finalize it into 16
weeks. To know information about the technical development of this activity go to
Section 5.1 and 5.3.
Testing vUSN & vUGW: During this duty, both nodes were tested in order to validate
its software. The assigned time for this task was 9 weeks. To do all these tests it would
be enough in 6 weeks. Nevertheless, taking into account that it was the first time the
network was virtualized, it was decided to increase this number of weeks to 9. So, it
would be enough time any unexpected in the case of finding errors.
Deployment vUSN & vUGW: Once the correct functioning of the software has been
verified, it is time to deploy these NEs in other locations in Spain to cover the en-
tire Vodafone production network. This activity took one month. Two weeks for the
deployment, and two weeks to check that everything worked well.
Traffic migration: This last activity consisted of migrating all the users of the Vodafone
legacy lines, to the new virtualized lines. This step is one of the most critical since any
failure in the system is noticed by the users.
All these activities mentioned above will have an explanation in greater detail, in Section 3.2.
18
Figure 3.1: Gantt Chart: Main Milestone.
19
3.2 P RECEDENCE DIAGRAM METHOD (PDM)

In order to develop a schedule network diagram, which tracks all the activities involved in the
project, it was carried out the table 3.2. This table was built using the PDM method based on
the PMP certification. Each task or activity has their own duration and dates with their Early
Start (ES), Late Start (LS), Early Finish (EF) and Late Finish (LF). All these dates are in weeks,
taking as week 0 the first week of the project, right after the kickoff ended.
Once the dates were determined, it was taking into account the delays that each task of
the project can tolerate before the project comes in late. These delays are called Float, and it
is calculated by subtracting the value from the LF with the value of the EF or by subtracting
the value from the LS with the value of the ES. In both cases, the result should be the same
value.
Once the table was finished, it was constructed the diagram which was made using
boxes/nodes and arrows. Here, each task was represented by boxes. In addition, each arrow
showed the dependencies among these activities.
Furthermore, the Duration and the Float of each task, are also represented. Thanks to this,
after doing the representation, it is easy to realize which is the critical path of the project (in
red), as well as the nearest path to the critical one (in grey). The resulting schedule network
diagram is shown in Figure 3.3.
Next, there are listed all the activities involved in the project, with a brief explanation of
their aims:
Task 1: Service Investigation. During this task, a broad investigation was carried out
internally, as well as with the vendor. In it, some of the main topics where discussed:
Design, elements, functionalities, Internet Protocol (IP)/Virtual Local Area Network
(VLAN)s configurations, connectivity. Moreover, in order to introduce and share the
solutions agreed upon at this stage, a kickoff was carried out, where both the vendor
and the operator were part of this event. However, all this information was gathered in
different manuals, so people could consult them at any time (it should be noted that not
everything that was agreed at this stage was completed later. This was because during
the project different decisions were made that caused changes in these previously
agreed solutions).
Task 2: High Level Design (HLD). In this step, a manual called HLD was created
by Vodafone’s members. It explains the preliminary stages of the End-to-End (E2E)
architecture that should be followed in order to develop the software products. Inside
this manual, there is a NFV Overview, connectivity solutions, Virtual Evolved Packet
Core (vEPS) details, and explanations of the different functionalities of the nodes
involved in the project.
Task 3: Connectivity Design. During this stage, several meetings were held in order
to find out which connectivity option was the most suitable for the data core network
of Vodafone Spain. The decisions were made mainly keeping into account the HLD
previously developed, as well as features of the data core network.
20
Task 4: Connectivity Demand. Once the connectivity design was done, the following
step was to make the demand for the different IPs and VLANs necessary to carry out
this design.
Task 5: IP Configuration. After having the IPs and VLANs required, they were config-
ured in each of the blades on its location. This configuration was carried out following
the implementation manuals provided by Huawei.
Task 6: LLD. Here, it was written the LLD, which describes the process step-by-step
required by the software architecture of each of the nodes. It is based on the previous
HLD design. This particular step was made by the Huawei, the vendor in charge of the
virtualized elements.
Task 7: Integration&Comissioning CSM (TR5). During this phase, the CSM was inte-
grated and commissioned. This step is a critical task since the CSM is in charge of the
management system for Huawei virtualization devices. It is important because, it is
used to create, configure, activate and hang up the Virtual Machine (VM)s. Therefore, if
this step fails, there is no way to continue with the project.
Task 9: Integration&Comissioning VNF: vUGW & vUSN (TR5). Once the CSM was
ready, the infrastructure was ready to do the integration and commissioning of the
vUGW and vUSN. This task was carried out, following step by step the Huawei manuals
for integration of the different elements of the network. In addition, it was taking into
account the middleware to succeed between communications among applications.
Task 10: TR5 Testing. This step is the first stage of tests that are performed on the
nodes for their approval. In TR5, the performance of each node is tested, and with the
results, the necessary changes are made to the software to improve it.
Task 10.1: vUSN with release 18.1 TR5 Testing

Task 10.2: vUGW with release 18.1 TR5 Testing
Task 10.3: vMSE with release 18.1 TR5 Testing
Task 11: TR6 Upgrade & Test. Once the nodes have passed the TR5 phase, several tests
are carried out again to guarantee the correct functioning of each element. Some of the
TR5 tests are repeated at this stage of TR6, with the purpose of placing the last patches
on the nodes before launching them into production.
Task 11.1: vUSN with release 18.1 TR6 Upgrade & Test
Task 11.2: vUGW with release 18.1 TR6 Upgrade & Test
Task 11.3: vMSE with release 18.1 TR6 Upgrade & Test
Task 12: General Available (GA) Upgrade & Test. This is the GA phase where it is
decided if the release of the nodes is ready to go into production or not. In the case of
deciding that it is not ready, the last patches are made.
21
Task 12.1: vUSN 18.1 GA Upgrade & Test.

Task 12.2: vUGW 18.1 GA Upgrade & Test
In order to understand better the different phases of testing, the following Figure 3.2 has
represented in a visual way the different phases of the test, as well as certain activities that
form them (notice that the VM1/Charter is the kickoff’s releases). In addition, Table 3.1 shows
which kind of features and functions are available for test in the consolidated vUGW-Traffic
Management Function (TMF) [13]:
Figure 3.2: Test availability CE18.1 TR5 vs.TR6 vs. GA [13].
CE18.1 TR5 CE18.1 TR6 CE18.1 GA

• TCP Optimization • TrafficSteering • TrafficSteering
• MW3 • MSP(VO,WO) • IWF
• CUBIC • CleanPipe • IWF function
• Header Enrichment • ACRheaderenrichment • Static Function
• Normal header enrichment • CloudPRS • Dynamic function (TBC)
• Vodafone start • TCP Optimization
• BRB
Table 3.1: Huawei Testeing Phases for vUGW-TMF.
Task 13: vBOM & pBOM. These two activities consist of elaborating documents where
all the technical features of the elements that will be necessary for the implementation
of the nodes will be detailed. The Virtual Bill of Materials (vBOM) is the first to be
made. It contains the specifications of the virtual elements, such as the VM types, the
number of VMs required, the number of interfaces for each VM, vCPU, RAM, affinity
rules, among others. Once this document is done, the Physical Bill of Materials (pBOM)
is implemented, where the physical elements necessary to contain all the parameters
indicated in the vBOM are found. For example, the number of blades per node.
Task 14: Hardware Purchase. To carry out this duty, a document with detailed infor-
mation about the purchase has to be prepared. In it, the prices of each HW element
that is going to be purchased are broken down, as well as the total price of the purchase.
This document is sent to Vodafone members in charge of evaluating the budget, and
22
therefore accepting or rejecting it. In the case of being accepted, the purchase of the
HW can begin, directly by contacting the suppliers.
Task 15: Hardware Delivery. This phase consists of the time necessary to receive the
previously purchased HW.
Task 16: Hardware Integration. Once the HW has been received, it can be installed.
This procedure is done by integrating the new HW to the old infrastructure already
installed.
Task 17: TR6 First of All First Offial Application (FOA). Once the HW was integrated, it
is initiated the FOA of each of the NEs. This phase consists in migrating a small number
of users to the line, from a small area of Spain. The performance of the network will be
monitored for two weeks. If all goes well, the rest of the users will be migrated after this
trial period.
Task 17.1: vUSN 18.1 TR6 FOA

Task 17.2: vUGW 18.1 TR6 FOA
Task 18: vUGW Traffic Migration. This is the last activity before considering the node
is completely integrated with the core. This step consists in migrating all the users who
were using the legacy data core network, to the new virtualized data core network. This
is a critical process since any failure could be noticed by users. That is why, it is done
step by step in two weeks, to avoid errors in the network and control their behaviour.
Once all the migration of the users has been completed, it just left maintaining and
monitoring the node to avoid anomalous behaviour or solve possible incidents.
23
Activity Dedcription Duration ES LS EF LF

(weeks)
Task 1 Service Investigation 2 0 0 2 2
Task 2 HLD 3 2 2 5 5
Task 3 Connectivity Design 4 5 5 9 9
Task 4 Connectivity Demand 2 9 9 11 11
Task 5 IP Configuration 2 11 11 13 13
Task 6 LLD 1 13 13 14 14
Task 7 I&C CSM (TR5) 2 14 14 16 16
Task 8 I&C U2000 (TR5) 3 14 14 16 20
Task 9 I&C VNF: vUGW & vUSN (TR5) 1 16 16 17 17
Task 10.1 vUSN 18.1 TR5 Testing 6 17 17 23 23
Task 10 Task 10.2 vUGW 18.1 TR5 Testing 6 17 17 23 23
Task 10.3 vMSE 18.1 TR5 Testing 6 17 17 23 23
Task 11.1 vUSN 18.1 TR6 Upgrade & Test 2 23 23 25 25
Task 11 Task 11.2 vUGW 18.1 TR6 Upgrade & Test 2 23 23 25 25
Task 11.3 vMSE 18.1 TR6 Upgrade & Test 2 23 23 26 26
Task 12.1 vUSN 18.1 GA Upgrade & Test 1 25 25 26 26
Task 12
Task 12.2 vUGW 18.1 GA Upgrade & Test 1 25 25 26 26
Task 13 vBOM & pBOM 3 9 10 12 13
Task 14 Hardware Purchase 4 12 13 16 17
Task 15 Hardware Delivery 4 16 17 20 21
Task 16 Hardware Integration 4 20 21 24 25
Task 17.1 vUSN 18.1 TR6 FOA 2 27 27 29 29
Task 17
Task 17.2 vUGW 18.1 TR6 FOA 2 26 26 28 28
Task 18 vUGW Traffic Migration 2 28 28 30 30
Table 3.2: PDM activities schedule.
24
Figure 3.3: Precedence Diagram
25
3.3 B UDGET
This section will expose the most important economic factors that were taken into account
to make the decision to virtualize the Vodafone’s data core network. The data shown below
comes from the budget proposal offered by Huawei to Vodafone. Since the data core network
was virtualized with products of this company.
In order to keep confidentiality, note that all the data that is going to be exposed below is
not the real one but approximations.
First, the budget of a hypothetical project scenario will be presented. In this scenario,
the data core network is not virtualized. Secondly, a scenario with the data core network
virtualized will be shown. So, knowing both scenarios, it will be very easy to compare them to
see which is better.
Figure 3.4 shows the cumulative values for the next five years of the two scenarios men-
tioned above. In this graph, it is possible to see that as the years go by, the difference between
"Doing nothing" and virtualizing, is increasingly noticeable. In fact, this difference reaches
10 million euros in the fifth year.
Furthermore, after these first five years, the forecast is that this budget difference will
continue to increase, saves a lot of money in Vodafone.
This big difference is mainly due to the fact that the initial investment that has to be
made in HW and SW for virtualization, is much less than what should be done in HW in the
"Do nothing" scenario. Besides, the maintenance required by this HW equipment is very
expensive, so that having less amount of HW in the virtualization scenario, these OPEX costs
are very low.
Figure 3.4: Comparison between “Do nothing” scenario vs. Virtualization.
All the data shown in the previous graph, are taking into account all the elements of the
data core network necessary to implement all its functionalities. However, the following data
will show only those values that are related to this master thesis, ignoring the rest. Therefore,
the total costs will be lower.
26
In order to have more details of how the budgets of the previous scenarios are composed,
Figure 3.6 and Figure 3.5 show the CAPEX of "Do nothing" scenario and Virtualized scenario,
respectively.
The first detail that can be highlighted is that for the "Do nothing" scenario, more elements
have to be contemplated than for the virtualized one. This is mainly due to the HW that is
used, as well as the complementary elements that this HW needs.
Another fact to take into account, is that in the virtualized scenario, although the costs of
professional services are more expensive at the beginning, with the years are cheaper, being a
value well below than the other scenario.
In addition, in virtualized environments, there are no added costs for Operation Support
System (OSS) licenses, when in the other scenario there are.
With all this, the costs generated by a non-virtualized scenario would amount to 21.474
k". Nevertheless, virtualizing the network would be 16.492 k".
The difference that exists between the two cases, as it was shown previously, will be
increasing. So it is clear that use a virtualized environment is much more economical.
Figure 3.5: CAPEX Virtualization detailed - Unitary cost k".
27
Figure 3.6: CAPEX "Do Nothing" detailed - Unitary cost k".
28
4
T ECHNICAL B ACKGROUND
Vodafone’s legacy network is a non-centralized network, where each of its NEs are built in
different HW, see Figure 4.1. Although this HW is very sophisticated, every time it is needed
to add a new functionality to the network, a big investment in HW has to be made. As a
result, this kind of networks have a high cost and in the long term, they are not profitable.
Besides, the nodes do just one function per entity, which makes the network less flexible and
inefficient.
As it was shown in previous chapters, the world of telecommunications is constantly
evolving and customers expectations are constantly growing. Therefore, it is necessary to
adapt the network to these new needs.
This chapter will give an overview of some key concepts to understand how important is
to use virtualization for future 5G networks.
The chapter is divided into three parts. First, The techniques needed for virtualization
will be explained in detail (e.g. NFV and SDN).
Secondly, the new virtual network architecture in Vodafone will be introduced by explain-
ing the most important elements and services.
And finally, an introduction to the 5G networks will be made, where the most significant
technologies will be explained (e.g. MEC, CUPS, NSA and SA networks, and network slicing).
Figure 4.1: Old Vodafone’s Topology
29
CHAPTER 4. TECHNICAL BACKGROUND
4.1 T ECHNIQUES FOR VIRTUALIZATION

Virtualization is the technology that allows sharing capabilities of physical storage, comput-
ing and network by dividing these resources among different VMs. The first time that the
concept of VM appeared was in 1964 [24] with IBM. Nowadays, there are many virtualization
techniques that all to support the execution of operating systems in VMs (e.g. NFV and
SDN), [24].
Following, two techniques used for virtualization will be presented in this chapter.
4.1.1 NFV
Figure 4.2: NFV Basic Architecture [7].
In general terms, NFV is a new network architecture concept which uses technologies
to virtualize NEs and connect them in order to create network services an applications.
Therefore, thanks to NFV it is possible to redefine the way of delivering and operating the
network functions.
Some of the technologies used by NFV are standards IT and cloud technologies. With
them, NFV can create a new architecture, where network functions, as well as the applications,
are entities create by only using SW. In addition, these SW entities are independent of the
HW and use resources like, network, compute and storage elements as the HW platform.
Moreover, with this new architecture, it is possible to develop new SW functions and
applications in an easy way. Hence, there are more vendors which can implement new
functions and application. This translates into a more diverse ecosystem of vendors in
30
comparison with the legacy architecture. Besides, NFV brings innovation and with this, new
business opportunities through the new services that can be provided to the customers.
Furthermore, NFV is able to optimize the resources of the network, so there is a reduction of
the CAPEX and OPEX needed.
All the advantages that NFV provides, made Vodafone decide to use this new technology
and modernize its data core network. Therefore, Vodafone is consolidating functions of
its NEs, reducing the number of HW platforms. For instance, if it is compared to the old
Vodafone’s architecture (Figure 4.1) and the new one (Figure 4.4), the number of nodes has
decreased. This is because the new vUGW has integrated more functions as the old Unified
Packet Gateway (UGW) had (see more information regarding this topic by going to the fol-
lowing Subsection 4.2.1). With this, Vodafone is improving its cash flow and providing better
services to their customers, [12], [7].
Figure 4.2 has the NFV architectural framework, with its four main areas, [32]:
• OSS and Business Support System (BSS)

These two systems work together in order to support network services. In previous
versions, OSS and BSS were entities more separates. However, since the services are
more and more complex, these two entities have needed a closer liaison between them.
OSS and BSS are structures with technology-oriented to include new services into
the network. These services are built using Service Fulfillment Functions (SFF) that
is in charge of the service design and resources provisioning, and Service Assurance
Functions (SAF) that handle the assurance processes (e.g troubleshooting).
Nowadays, these new processes carried out in the OSS, are compatible with the new
NFV and SDN technologies.
• VNFs
A VNF is a virtualized version of a traditional network function which is implemented
by SW simulating functions built in HW. Some examples of VNF are the vEPC and the
components that form it: Mobility Management Entity (MME), vUSN, vUGW (formed
by Packet Data Network Gateway (P-GW) and Serving Gateway (S-GW) platforms), and
firewalls, among other elements.
The main idea is to implement this virtual platforms in the core by using the lowest
possible number of HW and running it over the NFVI. This is possible since VNF can
be implemented as a VM or multiple VMs, or even as a function implemented within a
shared VM.
• Virtual Network Functions Infrastructure (VNFI)

This subsystem consists of all the HW (e.g. physical servers, storage, and networking)
and also SW (e.g. virtual servers, storage, and networking) components on which VNFs
are deployed. In addition, it includes the compute, storage, and networking resources,
as well as the associated virtualization layer called hypervisor and the container which
holds the VMs.
31
The hypervisor is an operating system, which provides a level of abstraction. It abstracts

the host infrastructure and allows to use it as a pool of virtual resources. Therefore, all
the virtual resources can be consumed by VMs. Therefore, the hypervisor is one of the
most important components in virtualization.
• Management and Orchestration (MANO)

It provides orchestration and lifecycle management for the virtualized resources of the
NFVI and the VNFs. Inside this subsystem, there are three functional blocks together,
which are: Virtualized Infrastructure Manager (VIM), NFV Orchestrator (NFVO), and
VNF Manager (VNFM). All these blocks allow communication between NFV and
MANO.
– VIM is a management system which controls and manages the compute, storage,
and network resources of the NFVI. The following description gathers some of the
main VIM activities:
Resource management, where it is included in the management of the SW inven-
tory, hypervisors, and the virtual compute, storage and network resources. In
addition, it allocates resources, as well as assigns dynamic resources and power.
Another key activity is the operations management to visualize and manage the
NFVI, and data collection.
– NFVO manages networks services that include multiple VNFs. It is able to create
end-to-end services using several VNFs. In addition, it also manages the lifecycle
of Network Services. During this VNFs lifecycle, there are some key activities like:
Onboarding a network service, instantiating a network service, scaling up or down
a network service, and updating a network service.
– The VNFM is an entity which is in charge of the management and operation of the
individual VNFs. Normally, this management is focused on Fault, Configuration,
Accounting, Performance, and Security (FCAPS). However, currently with the
network virtualization, there are more features of managing the lifecycle of the
VNFs. Some of its tasks are the following:
* Creation of VNFs by the use of templates and parameters.

* Increase or decrease the capacity of these VNFs by scaling up or scaling down.
* Update and upgrade VNFs.
* Finalize the VNFs and returning them to the NFVI resoruces pool.
4.1.2 SDN
SDN is a set of techniques used for network transformation since it can face the new chal-
lenges and changes that are appearing in the network area. Thanks to SDN, it is possible to
manage, control, optimize, arrange and distribute the network resources. In addition, one
of the basic ideas of SDN is the separation of the architecture in two traffic planes: One for
signalling and another for data. This makes SDN a centralised network architecture.
32
Another basic idea with regard SDN, is the capacity it has of abstract the network infras-
tructure from the applications. Thanks to this, SDN allows having a new logical-centralised
control system which is programmable and makes the network architecture more dynamic
and scalable.
Besides, it is not necessary to buy new HW, since the existing one can be configured and
programmed. Hence, SDN is also cost-effective, reducing the overall costs.
In general terms, the principles of SDN are:
• Separate user plane from control plane.
• Standard protocols for interoperability.
• Create an open platform.
• Apply network wide.
SDN can be divided in two main areas, as it is shown on Figure 4.3: SDN Application layer,
SDN Controller.
The most important part of those mentioned above is the Software Defined Network
Controller (SDNC) cluster, which is the controller in charge of deciding where and when
sending the control flow and data flow. These flows which go through the SDNC, can be
divided into three sections:
1. Real-time network status.
2. Service demand.
3. Automated provisioning of physical network nodes.
SDN provides a visibility of the real-time status of the traffic-flows as well as the network
resources. When the SDN controller notices there is a new service demand, it can automati-
cally provision the whole network resources E2E. Furthermore, the centralised controller is
able to optimise the paths for all the services and compute the network taking account the
optimal view that it as calculated, [22].
Vodafone has introduced SDN in theIP/Multiprotocol Label Switching (MPLS), Optical
and Microwave transport domain. For it, Vodafone had to define the SDN for single Transport
Network architecture. In addition, Vodafone is currently introducing SDN over the NFV
network. As a result, it was obtained an improvement in the current network assets thanks to
automation and resource optimization. In addition, it has also facilitated the design, delivery
and operation being dynamic and scalable.
To summarize, the following list has an overview of the main reasons why Vodafone is using
this SDN technique, [7]:
• Introduce programmability and maximise automation.
• Optimise transport resources usage.
33
Figure 4.3: SDN general structure [7].
• Dynamic centralized decisions based on the E2E network view.
• Full coordination among the inter-layers.
• Dynamic establishment of various services according to demand.
• Better performances and resiliency.
• Real-Time view and decision making (monitoring, analytics, and optimisation, among
others).
• Easy and fast way to add new features and capabilities.
4.2 V IRTUALIZED N ETWORK A RCHITECTURE AND S ERVICES

This section is aimed at describing the new Vodafone virtualized network elements, as well as
its functionalities. Besides, there will also be a brief introduction to the services that Vodafone
offers to its users, to better understand how the Vodafone network works.
4.2.1 V EPC E LEMENTS

The new vEPC brings the possibility of consolidating functions in the same NE. Therefore,
the final network architecture has less number of NEs than the old Evolved Packet Core (EPC),
Figure 4.4 has represented the new vEPC. Specifically the vEPC is composed by two new
nodes, vUSN and vUGW, which will be presented later.
34
Figure 4.4: New Vodafone’s Topology
Although vUGW and vUSN are new virtual platforms with new functionalities, no inter-
face changes with respect to the legacy architecture. Furthermore, they are based on the
same 3GPP standard in which was based on the old network.
Figures 4.5 and 4.6 have the structure of how is the vUSN and vUGW integration with the
rest of the network, as well as their interfaces.
Moreover, the Table 4.1 gather not only the NEs which are integrated with the vUSN and
vUGW, but also the application layer protocol and the transport layer protocol, that each
interface uses.
• vUSN:
In the current virtual network architecture, the vUSN is a triple access node, and it
carries out the functionalities of the old Serving GPRS Support Node (SGSN) and the
MME. The following VMs are needed to implement this NFV:
– Operating and Management Unit (OMU)s: which are in charge of operations and
management of the NFV. (Scheme 1+1).
– Session Data Unit (SDU)s: which implements session context storage functions.
(Redundancy scheme N-way).
– Service Processing Unit (SPU)s: which carries out processing and GPRS Tunnel-
ing Protocol (GTP)-U transfer functions. (Redundancy scheme N-way).
– I/O Processing Unit (IPU), which deploys IP routing and session dispatching
functions. (Redundancy scheme N-way).
– Gb Interface Processing Unit (GBU): which deploys protocol functions in 2G.
(Redundancy scheme N-way).
– Signal Interface Process Unit (SIU): which implements processing and GTP-C
functions. (Redundancy scheme N-way).
35
Figure 4.5: vUSN (SGSN/MME) Stan- Figure 4.6: vUGW (GGSN/S-GW/P-GW)

dard Interfaces. Standard Interfaces.
NE Peer NE Interface Application Transport layer

layer protocol protocol
HLR Gr SS7 M3UA/SCTP
HSS S6a Diameter SCTP
eNodeB S1-MME S1AP SCTP
BSC Gb BSSGP IP
IuPS-CP RANAP M3UA/SCTP
RNC
vUSN IuPS-UP GTP UDP
CG Ga GTP UDP
vUSN/Legacy USN S10/Gn GTP UDP
vUGW/Legacy UGW S11/Gn GTP UDP
SGs SGsAP SCTP
MSC
Sv GTP UDP
eNodeB S1-U GTP UDP
IuPS-UP
RNC GTP UDP
(Direct Tunnel)
CG Ga GTP UDP
vUGW PCRF Gx Diameter TCP/SCTP
OCS Gy Diameter TCP/SCTP
AAA Gi/SGi Radius UDP
vUSN/Legacy USN S11/Gn GTP UDP
vUGW/Legacy UGW S5 GTP UDP
Table 4.1: vEPS Network Element Interconnect Relationship [35].
36
• vUGW:
This NE is a consolidation of the old nodes Gateway GPRS Support Node (GGSN), S-GW,
and P-GW, now called Virtual Multi-Services Platform (vMSP) and vMSE. In the new
architecture, the functionalities that have to be implemented by the vUGW are the
following:
– Deep Packet Inspection (DPI).

– vMSE:
* Header enrichment.
* TMF steering, redirection to Vodafone Start and Secure Net.
* Transmission Control Protocol (TCP) optimization.
– vMSP:
* Web optimization.
* Video optimization.
In order to implement all these functionalities, were used the following VM [12]:
– OMU: which provides the daily maintenance and lifecycle management. (Redun-
dancy scheme 1+1).
– IPUs: which are dedicated to managing signalling interfaces, such as: Gx, Gy, and
Radius, among others (Redundancy scheme N-way).
– Assambly-Service Process Unit (APU)s. (Redundancy scheme N-way).
* This VM contains interfaces and service units.

* It is dedicated to managing just data plane IP traffic as received in the Gi-LAN.
* If it is required, this service unit can be able to manage all data plane traf-
fic. In particular GTP encapsulation and decapsulation, and steering traffic
enforcement.
– Service Function Management Unit (SFMU): This VM is responsible to control
the service chain and provide to steering capability. (Redundancy scheme N-way).
– SDU: This VM provides the Cloud Session Database to support resilient and
scalable service. (Redundancy scheme N-way).
– Video Optimizatin (VO)/Web Optimization (WO)-Front end: These VMs are pro-
vided by the company OpenWave. They support both interface and service logic
for VO and WO. (Redundancy scheme N+1).
– VO/WO OWM Operation And Maintainance (OAM). This VM is also from Open-
Wave. It supports Huawei functionalities to provide the daily maintenance and
VNF Lifecycle Management. (Redundancy scheme 1+1).
37
4.2.2 V EPC S ERVICES

Below, some services that Vodafone provides to its users will be explained. Note that the
services that have been chosen are the ones which offer the greatest challenge with regards
the network virtualization. Therefore, they have been taken into account in the network
implementation:
• Vodafone Pass is the name of a new Vodafone’s monthly service, which brings new
functionalities into the network. Vodafone Pass is divided in four different areas: Video
Pass, Social Pass, Music Pass, Maps Pass (or Super Pass, in the case of having the four
contracted).
In order to implement Vodafone Pass, it is necessary to know the type of traffic that each
user consumes at any time (traffic based on application). Knowing this, it is possible to
charge consumers depending on the type of subscription they have. For example, if
a user has only a Video Pass subscription, all the video content that he consumes will
go at maximum speed, and it will not be discounted from the data allowance (i.e. 3GB
monthly), so the customer is able to consume this traffic without limit. However, the
rest of the traffic generated will be charged and will go at lower speeds.
So, once the traffic is identified, it is processed and goes through a data traffic setting
rules, in combination with Policy and Charging Control (PCC) rules. The service chain
is selected based on the user profile information received by the Policy and Charging
Resource Function (PCRF). The decisions normally are taken in the Mobile Subscriber
Equipement (MSE) and after, the traffic proceeds to its optimization.
In order to implement this promotion, the technical functions that were needed to
include in the network were:
– DPI: Data processing that identifies the type of data that is inside the traffic flow.
– TCP Optimization: Since TCP was not created keeping in mind mobile networks,
sometimes it causes congestion and slows down the performance in data transfers.
This is why it was created processes through which TCP can be optimized and
avoid these congestions.
– VO: It is a process which improves the video performance by reducing re-buffering
events, enhancing customer viewing experience.
– WO: Set of technologies used to improve the performance of web pages, enhanc-
ing the user experience.
Figure 4.4 has represented all the components involved in this process [12], [28].
• Vodafone Start is an intelligent redirection for subscribers with new smartphones. The
aim is to improve subscriber engagement with Vodafone and its products and services.
Once a subscriber tries to browse the internet with his new smartphone for the first
time, the TMF redirects the traffic to a Vodafone Welcome website. This page offers the
user different services and products tailored to the customer and its device.
38
After the user has been redirected to Vodafone Start, the page is displayed and TMF
sends a notification to the PCRF to confirm that the user has been redirecting cor-
rectly [12].
• Secure Net is another service offered by Vodafone. It provides safe browsing, antimal-
ware and antivirus protection to the users.
All the users that are subscribed to this service, every time they surf the Internet, their
data will pass through the Secure Net platform. This platform will identify the traffic
and select which content is allowed to pass and which does not.
Therefore, for this process, TMF is requested to steer traffic to the Secure Net platform,
keeping into account the PCRF rules [12], [26].
4.3 5G N ETWORKS
5G is the fifth generation of mobile phone technology. This new technology brings great
advances with respect to its predecessor 4G. However, 5G is more than an evolution of
LTE. This technology has new radio and core, as well as, a wider available bandwidth and
lower latency. Furthermore, 5G brings new perspectives which are capable of changing the
demands of consumers and business markets. These new demands and business markets
will bring new applications based on 5G, which are going to change the digital. For instance,
Remote control for robots or machines, Augmented reality, Gaming, Education and Training,
Tele-operated driving and Autonomous driving-self-guided vehicles, among others.
The key technical characteristics which 5G needs in order to carry out all the changes
mentioned above are listed below:
• Radio upgraded to reduce latency by 1 to 10ms. This will be very important for low
latency services. For instance, Gaming, Augmented Reality, and Self-guided vehicles,
among others.
• 5G spectrum deployed (700 and 35000MHz) and massive Multiple Input Multiple
Output (MIMO) antennas added to increase speed and capacity.
• A Peak data rare of 1 to 20 Gbps, bringing a better user experienced data rate of 10 to
100 Mbps.
• Applications moved into the network to further reduce latency by many 10’s of ms
• Network slices to enable new services (e.g. s slice for "advanced gaming" or "con-
nected cars"). Network slicing separates the user plane and the control plane providing
higher flexibility in configuration and reconfiguration of networks based on SDN.
• New devices supporting 4G Evo and 5G which can have a battery life of 10 years.
39
In order to implement all these new features, it is necessary to create 5G Radio and Packet
Core. For this goal, SDN and NFV are used, being the main enablers for 5G. They are the ones
in charge of decoupling SW form HW and HW virtualization.
As it was explained before, 5G network will be able to support new technologies, use cases,
business solutions and delivery models. For it, 3GPP is developing interworking scenarios
between vEPC and 5G.
The planning of 3GPP is represented in Figure 4.7, where there is an overview of the
present status and future plans of 3GPP. The first part of this diagram shows that the first
release (Rel-14) has been finished by the end of 2007. These advances have allowed the first
5G tests to be carried out. In fact, Vodafone Spain with Huawei made the first 5G call in the
world by February 2018. And now, they are continuing with the first NSA tests (low latency,
slicing, MEC). Although the last releases will not be ready earlier than 2019.
Figure 4.8 has the steps and enablers needed to reach the deployment of a 5G Packet Core.
As it is shown in the image, the first step is to implement NFV (this mechanism was already
explained in Section 4.1). With this network architecture, it was possible to virtualize the EPC
and have a network ready to use CUPS, which is in charge of speed up the user plane services.
After implementing CUPS in the vEPC, it is time to use the 3GPP standard called NSA.
With it is not necessary to have a 5G core since the radio goes through 5G, but the data
through the virtualized 4G core.
Once the scenario is ready, is the time to introduce the concepts of MEC and slicing. Both
concepts enable the network to have lower latency and create slices per service to use the
network in a more efficient way.
Although it is getting closer to use 5G cores with the SA standard, it will not be until 2020
when we can make real use of it, as it is shown in Figure 4.7.
In the next subsections, it will be made a more detailed explanation of all the elements
previously mentioned, for a better understanding of them.
4.3.1 MEC
MEC is a network architecture concept that brings cloud computing capabilities and IT
services environment closer to the Radio Acces Network (RAN). Therefore, with MEC, is
possible to host services at the edge of the network placing them closer to the end-user, and
therefore decreasing the latency significantly.
Thanks to this concept, it is possible to do specific tasks that before not possible to be
done using traditional mobile networks. Actually, the main idea with regard MEC, is that is
able to run applications and performs tasks closer to the User Equipment (UE). Thanks to
this, network congestion is reduced significantly, getting better the application performance.
Moreover, MEC allows deploying new applications and services in a more flexible and faster
way.
40
Figure 4.7: 3GPP Standard Progress [9].
Figure 4.8: 5G in Packet Core - Steps and Enablers [9].
Figure 4.9: 5G NSA architecture [9]. Figure 4.10: 5G SA architecture [9].
41
MEC is able to create new environments with the following features:
• Higer proximity to the user, which allows gathering information for analytics and big
data.
• Ultra-low latency allows creating services that need to react fast improving the user
experience.
• Higher bandwidth permit to deploy application and services which can not be applied
to legacy networks.
• The Location awareness lets to locate devices with a high degree of precision. Besides,
this feature allows devices to have a large set of applications only dedicated to specific
geographic areas.
• The Real time access offers context-related services which are able to differentiate the
broadband experience.
Combining all these elements, mobile operators are able to create networks which can
provide: Low latency, better flexibility, agility and faster delivery. This gives the opportunity
of increasing the quality of the services and make the user having a better experience, see
Figure 4.11. Furthermore, it makes network operation more cost-efficient and competitive.
In addition, thanks to this service environment, the access to new content and application it
is faster and more interactive [9], [31], [36].
Figure 4.11: MEC network architecture [31].
4.3.2 CUPS
CUPS is one of the most important pillars of 5G core network architecture. Although the
separation of the control and user plane has already been implemented in the EPC, in 5G
architecture has a completely new definition.
42
CUPS was created with the purpose of handle scenarios which have several traffic flows
that involve remote and geographically distributed systems. In order to control these traffics
flows, a large number of small gateways were needed. These gateways are in charge of
forwarding the IP packest and placed it near the radio access.
The control plane and user plane are separated, where it is processed signalling and
service data respectively. On one hand, the control plane provides unified signalling interfaces
that make it simplify the network deployment. On the other hand, the user plane is deployed
at the regional network, so it shortens the service access path.
Furthermore, the planes can be established in different sites. For instance, the control
plane can be placed in a central location. This central placement allows to manage and con-
trol traffic flows with less complexity. User plane can be distributed over different locations,
closer to the user and the RAN.
Thanks to this new organization of the network, latency is reduced and the paths of the
user traffic are optimized.
Besides, with CUPS, it is possible to manage all the functions needed to forwards these
packets by using a limited number of centralized control nodes.
To sum up below is shown some of the most important CUPS architecture features:
• The separation between the control plane and user plane that CUPS provides makes
the resources to be scaled independently.
• Path optimization and reduction of latency since the user plane is deployed at the
regional network or even lower to shorten these paths. This feature makes better the
service experience.
• Large number of small gateways, which forwards IP packets and placed it near the
access.
• Limited number of centralized control nodes.
• CUPS is able to handle traffic-flows in remote and geographically distributed systems.
Currently, Vodafone is using Huawei NEs to renew its networks, and Huawei has bet very
strongly for the use of CUPS in its products. Actually, the Huawei solution for 5G core network
is completely based on this concept. Figure 4.12 has represented the before and after of an
vUGW node.
On the left side of the image is the vUGW with control and user planes together. So, all
the traffic goes through the same centralized node. However, on the right side of the image,
there are two nodes instead of one: CGW which is in charge of the control planes, and DGW
which manages the user plane.
This new architecture is the one that was used for the testing in 5G of this master thesis,
see more information going to Section 5.5.3.
43
Figure 4.12: Huawei Separation Solution [18].
4.3.3 N ON S TAND -A LONE AND S TAND -A LONE N ETWORKS
NSA and SA are two types of 5G networks defined on the standard 3GPP Release 15. As it was
shown in Figure 4.7, the first class of network to be implemented is NSA and after SA.
NSA allows the use of 5G in the Radio Access without the need of having great upgrades
in the vEPC. This means that it is possible to use the virtualized 4G network infrastructure
without the need of having the complete 5G core.
With NSA, smartphones can connect to 5G frequencies and transmit and receive data
using the user plane. However, the control plane and some parts of the user plane, still going
through the 4G radio access and core [20]. Figure 4.9 has represented this scenario.
SA network it has not been implemented yet, and the 3GPP standard does not have either
information with regard to it. However, the general idea is well known, see Figure 4.10. In this
case, both control plane and user plane, use the 5G radio access and core, without the need
of 4G infrastructure.
This type of network is expected to arrive by the end of 2019 or by 2020 when there are
smartphones that support this type of 5G technology.
SA will bring mainly simplification and improved efficiency. As a result, it is expected
to have, lower latency communications, lower costs, and a performance improvement in
throughput [20].
During this thesis, a NSA 5G tests have been carried out. In order to see the results, go
to Subsection 5.5.3.
44
4.3.4 N ETWORK S LICING

Network slicing is one of the most important drivers of 5G. It is a powerful virtualization tool
which is fundamentally a partition of the network resources and network functions. This new
virtual network architecture is based on the same principles used in fixed networks: SDN
and NFV. These technologies allow to divide the NEs into new customizable elements, where
putting together some of them, can be used to provide specific services to the customer.
All this, by using just the necessary resources of the network for this specific application or
service. Figure 4.13 has represented how is the slicing network structure.
Therefore, with network slicing it is possible to run multiple logical networks, using it as
independent business operations, and all this in the same physical infrastructure. Hence,
slicing introduces flexibility into the network, and makes easier to manage it [9], [17].
The following list has some of the benefits that network slicing brings to the network:
• Eliminates complexity in the interaction between services and applications.
• Allows selecting specific applications and services by tuning of the network, making
better the user experience.
• Facilitates fault controls without affecting other slices.
• Allows independent upgrades and downgrades for each service and application.
Slicing is one of the main technical and business challenges that mobile operators and
service providers will face soon. Some of the principal technical parameters to keep in mind
are the following: data rate, latency, Quality of Service (QoS), availability, and security among
others elements. Moreover, in the business area, the parameters to keep into account are the
next: revenues per service, flexibility, cost-optimization and performance-optimization [11].
45
Figure 4.13: Slices for different applications and environments [9].
46
5
D EPLOYMENT
This technical chapter is divided into four parts. First of all, the physical and virtual elements
that have been used to improve Vodafone’s network infrastructure are explained. Secondly,
the design of the connectivity is shown, as well as all the options that were discussed before
selecting the final design. Thirdly, the steps required to instal and configure the NEs are
described. And finally, the tests carried out for the SW validation of the platforms and their
results, are explained.
Every decision that has been made in this chapter, has been based on the forecast for the
upcoming months. As it was shown in Section 2.3, data traffic is constantly increasing, and
therefore the network has to adapt to these forecasts.
In order to cover this needs, the first step is to create the vBOM that contains all the
parameters necessary to model and dimension virtual hardware needs. In it, the number of
VMs, Virtual Central Processing Unit (vCPU) per VM, RAM in GB per VM and the storage per
VM are defined. Figures 5.1 and 5.2 have the details of these vBOMs for the vUSN and vUGW
respectively.
Figure 5.1: vUSN vBOM. Figure 5.2: vUGW vBOM.
5.1 N ETWORK F UNTION V IRTUALIZATION I NFRASTRUCTURE

During this section, an overview of the NFV architecture will be exposed. With this purpose, it
will be presented the NFV infrastructure components that were used to virtualize the network.
47
CHAPTER 5. DEPLOYMENT
The section is divided into three parts: physical elements, virtual elements, and the NFVI
management necessary to handle the whole virtual infrastructure.
As it was shown in Section 4.1, the network architecture that has been chosen to improve
the legacy one, is based on the use of technologies, such as NFV and SDN. NFV consist on
running several VMs in parallel on a cloud computing infrastructure, instead of using one
HW infrastructure per each network function. This means that the necessary number of HW
in a virtualized network decrease. In order to deploy this, it needs a NFV architecture which
is represented in Figure 4.2. There are three main parts, the NFVI working domain, the VIM,
and the FCAPS.
All these information is gathered in the pBOM document which is based on the vBOM,
shown in previous lines.
5.1.1 NFVI P HYSICAL C OMPONENTS

The NFVI Physical Components are divided into three parts: Physical compute, physical
network, and physical storage [12]:
• Physical Compute
In order to run a VNF and its management components, it is needed physical compute.
This physical compute is obtained by physical servers which provides resources like
Central Processing Unit (CPU) and Random Access Memory (RAM). These servers are
hosted in clusters, where each of them has its own workload type as well as its own
configuration.
Vodafone has chosen to use HP technology for the computing domain. In particular,
they have been chosen the HPE c7000 Blade System since it has the best balance between
costs and performance in the market.
Each enclousre is composed by the following elements, see Figure 5.3:
- HP BLc7000 Configure to order Platinum Enclosure with ROHS Trial Insight Con-
trol License.
- HP BLc7000 Single Phase FIO Intelligent Power Module.
- HP 6X 2650W Platinum Hot Plug FIO Power Supply Kit.
- Six HP BLc Active Cool 200 Factory Integrated Fan Option.
- HP BLc7000 On-board Administrator with KVM Option (redundancy).
- Two HP Virtual Connect FlexFabric 20Gb/40 F8 Module.
- Two HP 6125XLG Ethernet switch to enable non-blocking network topology.
In addition, each enclousure is eqquiped with blades called HP ProLiant BL460c Gen9,
see Figure 5.3. Each blade was configureted with the following specifications:
- CPU: Two CPUs (2.2 Ghz/20 cores per CPU).
48
Figure 5.3: C7000 compute enclosure [12].
- RAM: Between eight and sixteen 32GB RAM, which means a total between 256GB
or 512GB.
- Storage: It does not have a local Hard Disk Drive. The ESXi hypervisor is booted
from Storage Area Network (SAN).
Figure 5.4: HP ProLiant DL360p Gen9 [12].
• Physical Network
The physical network is divided into several layers: access, core and aggregation. The
access layer has switches, which provide network access to the blade servers which
are inside the enclosure. It interconnects blade servers, plugged in the enclosures, to
the external network via uplinks to aggregation layer. The core and aggregation layers
provide intra-track connectivity and aggregation for the access layer to the IP backbone.
For these layers, the HW used is the HPE 6125XLG Ethernet switches, see Figure 5.5. It
is used for VNFs workload traffic. The total number of HPE 6125XLG Ethernet switches
depend on the configuration. In the case of a standard configuration, two HPE 6125XLG
Ethernet switches plugged in each enclosure is needed. However, in the case of using a
high-performance configuration, four HPE 6125XLG Ethernet switches plugged in each
enclosure would be needed.
49
Figure 5.5: HPE 6125XLG Ethernet switch [21].
• Physical Storage
In order to provide block storage to both physical and virtual infrastructures, it is
necessary to have a shared SAN. Each host that belongs to a hypervisor, is connected
to the same SAN infrastructure. Moreover, with the objective of providing optimum
performance, scalability and physical I/O separation, the Storage Area Network make
use of a state of the art underlying infrastructure.
Due to the importance of having redundancy in storage, two separate Fabrics have
been included. Each physical host has at least two FC HBAs (application programming
interface for host bus adapters), connected to two separate SAN switches.
Storage resources correspond to several Logical Unit Number (LUN)s, where each LUN
has 4 TB of size. This size was chosen keeping in mind the compromise between the
simplicity of management and the resilience requirements.
Following are listed the different layers of the Storage Area Network that were deployed:
– Fabric and SAN Switches

– Storage Array
– Storage Virtualization Layer
For optimal storage operation, all hosts in VIM management cluster should have access
to the same Datastore Cluster. Besides, in order to provide storage anti-affinity, all
hosts in application management cluster and service cluster needs access to Datastore
Cluster.
5.1.2 NFVI V IRTUAL C OMPONENTS

As mentioned before, in the NFVI there are also virtual components, which are going to be
explained below [12]:
• Virtual Compute
Vodafone decided to virtualize its data core network by using VMware vSphere stack. It
has two core components of vSphere which are ESXi and vCenter Server.
50
ESXi is the hypervisor of the virtualized platform and it is in charge of abstracting

physical compute resources, into virtual resources. Furthermore, it allows to create and
execute VMs.
vCenter Server is the principal management element. It belongs to the VIM layer, and
it is able to manage multiple hosts at the same time and connected it in a network.
All the physical compute hosts are gathering into vSphere cluster. This cluster is formed
by ESXi hosts and VM with HW resources and a shared management interfaces.
• Virtual Network
Thanks to the combination between vSphere and VMware NSX, it is possible to obtain
virtual network resources. This is because, vSphere is able to provide the basic con-
structs of virtual network interface cards and virtual switches, in order to achieve layer
2 connectivity and switching.
VMware NSX can create, delete and restore SW based virtual network. The aim of
these networks is it to provide communication between VNF components and to give
dynamic control of their services.
NSX for vSphere gives a layer of abstraction by supporting an overlay network with
standards-based protocols. Thanks to this, the old network limitations are avoided.
Furthermore, NSX is composed of three independent layers: data plane, control plane,
and management plane.
• Virtual Storage
In order to provide virtual storage, external storage arrays are needed. vSphere supports
third-party storage and provides enough capabilities to configure datastores out of
physical storage LUNs.
5.2 NFVI M ANAGEMENT

Figure 5.6 has an overview of the NFVI cluster management structure. In it, there are repre-
sented three main clusters which are in charge of handling the NFVI, and the communications
that exist between them:
• Infrastructure Managemente Cluster: This cluster hosts the foundation components.

Inside this cluster, two vCenter Server instances are running on NFV Infrastructure:
– The Management vCenter Server manages the Management Clusters, where

is the VNF manager called Cloud Service Manager (CSM). This VNF manager
handles the life cycle of VMs, and it can create, configure, and activate VMs, such
as vUSN, and vUGW among others VNFs.
– The Service vCenter Server manages the Resource Clusters, where is the vCloud
Director (vCD), which provides the interface, automation, and management fea-
ture set to deliver vSphere resources to be consumed as a service.
51
The reason why these two entities are separated is that it is easier to troubleshoot and
to ensure the availability of the core management products in a dedicated cluster at all
times.
• Application Management Cluster: This cluster hosts the analytics and element man-
ager system components, such as PRS, U2000 and Virtual OSS Self-Maintenance
Unit (vOSMU).
• Data Service Cluster: Once the CSM creates the data plane components, such as vUSN,
vUGW and Charging Gateway, among other, they are holded inside this cluster.
The following table gathers more information about these three clusters:
Cluster Workload vCPU Managed vCD alloca- Huawei VNFs

type res. by tion mode
Infrastructure Infra Mgmt 60% Mgmt N/A CSM
Management vCenter
Application VNF Mgmt 60% vCD PAYG PRS, U2000,
Management OSMU
Data Service VNF Data 100% vCD Reservation USN, UGW,
Cluster Plane Pool CG
Table 5.1: vUGW and vUSN Connectivity Options [12].
Once the reader is familiar with all the parts of the NFVI and its elements in charge of
the management, it is time to put them together and have a global vision of how they are
structured. Figure 5.7 represents how all the physical and virtual elements would be placed
in their respective clusters and their connections with their respective switches.
52
Figure 5.6: NFVI Clusters Management [12].
Figure 5.7: NFVI Physical and Virtual view [12].
53
5.3 C ONNECTIVITY D ESING

This subsection provides a wide vision of the connectivity between the VNFs and the vEPC.
Moreover, the VNF architecture of the most outstanding elements of the network are ex-
plained, as well as the possible techniques for the routing of the input and output interfaces
of the vEPC. In addition, possible problems and their solutions are identified for the design
of connectivity.
Initially, two possible solutions were considered for the network architecture. These two
options were focused mainly on the vUGW and vUSN nodes since these are the first nodes to
be virtualized and they have functionalities with important roles in the network.
Figure 5.8 shows the vUGW architecture in the Huawei vEPC (release 18.1). In it, it is
possible to differentiate two flows: One for Control Plane and the other for User Plane.
Therefore, it is worthy to note that there are different VMs for each plane. For Control Plane,
it is used the IPU interfaces and for User Plane, the APU interfaces.
On the right side of the frame, the green arrows represent the path that the signalling
traffic follows. This type of traffic leaves the IPU, and goes to the element that manages the
Control Plane. Besides, IPU is responsible for the load balance of this flow. However, in this
release, it is within the VM managing the User Plane. Therefore, the user traffic is forwarded
to VM which have the Control Plane related information. If the packets do not have the
required information of the Control Plane on the first VM that reaches, they will be sent to
the correct one, generating East-West (E/W) traffic.
Figure 5.8: vUGW Architecture [12].
In the case of the vUSN, there are only IPU VMs for managing the connectivity, since
this node just forwards signalling traffic. The differences between vUGW and vUSN for
connectivity are reflected in the Figure 5.9. The image shows the inside of the HW HPC700
where the nodes are configured. In it, there are the Virtual Network Interface Controller
(vNIC)s used for both nodes, as well as the name of the logical interfaces connected to each
of them.
54
Figure 5.9: vUGW and vUSN Interfaces [12].
The amount of mobile data plane traffic that these VMs have to handle is huge. This
is why one single APU VM would not be enough. Hence, it is compulsory to use many of
them working in parallel. However, the traffic in the Control Plane is quite lower, since the
signalling traffic has less amount of information.
Therefore, the number of APU boards needed is much higher than the number of IPU
boards. For the first one, it can scale up to 100 VMs, while for the second would be enough
just using 2 VMs.
In order to ensure that all these packets are forwarded to the vEPC, it has to be used a
traffic load balancing between the APU and IPU. The VMs have different logical interfaces,
for instance, S1-MME, S11, S5/S8, Gx, Gy, Gi, among others. Each of these interfaces has
different scalability requirements. So, it is possible to implement several networking options,
taking into account these scalability requirements [30].
The Table 5.2 lists the association of networking options and their possible logical inter-
faces, as well as VM applicable:
VNF VM Number of Logical interfaces Type of Traffic Network

Type VMs Protocol
IPU 2 S1-MME Control OSPF/Static
IPU 2 Gb Control OSPF/Static
vUSN
IPU 2 S11/S10, Gn, Gp, Iu-U Control OSPF/Static
IPU 2 Gr, S6a, SGs, Ga, Iu-C Control OSPF/Static
APU N S1-U Data OSPF/BGP
APU N S11, S5/S8, Gn, Gp, IuPS Data OSPF/BGP
vUGW
APU N Gi Data OSPF/BGP
IPU 2 Gx, Gy, Ga, Radius Control OSPF/Static
Table 5.2: vUGW and vUSN Connectivity Options [12].
In order to implement the connectivity of the IPU VM and being compliant with the load
55
balancing requirements, two possibilities were evaluated:
• The first option is reflected in Figure 5.10, where, to simplify the scheme, it is repre-
sented by a single logical interface and two examples of routers, R1 and R2. For this
scenario, is required a common VLAN which joins routers and the IPU using Open
Shortest Path First (OSPF). This option uses service IP addresses, which are announced
by OSPF (this service IP addresses, are logical interfaces which correspond to destina-
tion addresses). Hence, the router knows them, since the traffic comes from both IPU.
So, the routers implement two ways Equal-Cost Multi-Path (ECMP) routes. The strategy
using ECMP is to forward the packets to a single destination over multiple possible best
paths, which have the same values in the calculation of routing metrics. This provides
more bandwidth thanks to load-balancing the traffic over these multiple best paths.
However, OSPF has some limitations in terms of scalability that have to be taken into
account [6].
Figure 5.10: Option One. Implementa- Figure 5.11: Option Two. Implementa-
tion of Connectivity for the IPU VM type tion of Connectivity for the IPU VM type
[12]. [12].
• The second option has the same principle but using static routes to forward the traffic
to the IPU. Figure 5.11 represents the scheme of this alternative. There are two routers
with static routes for each service IP address. The main problem with this option is that
it requires manual configuration. In addition, it does not have an automatic scalability
in case of needing more IPU in the future. This would limit the growth of the network
for future applications.
In order to ensure not to sent traffic to a black-hole next-hop after one IPU fails,Bidirectional
Forwarding Detection (BFD) protocol has to be used in both options. This protocol can detect
forwarding path failures fast enough so that the efficiency of the network is not affected [5].
After evaluating the pros and cons of each of the possibilities, the first options was chosen.
Even though OSPF brings some limitations that make not be possible to use it in some situa-
tions, option two has more disadvantages that in the long term, would affect seriously the
expansion of the network.
56
In the following lines, it will be evaluated the connectivity options for the data plane
interfaces. As was explained before, the traffic is quite higher through the APU VM than for
the IPU VM. In order to manage this traffic, it can be done by implementing two options
shown below in Figures 5.12 and 5.13.
Figure 5.12: Option One. Implementa- Figure 5.13: Option Two. Implementa-
tion of Connectivity for the APU VM type tion of Connectivity for the APU VM type
[12]. [12].
In order to simplify the scheme, these images have only four APUs. However, a real
deployment would have a higher number of these interfaces. The quantity would depend on
the amount of traffic to be managed. In addition, two routers are represented as an example,
R1 and R2.
In both cases, it is possible to use OSPF routing protocol, since it provides enough scalabil-
ity and deployment automation. Therefore, it would be necessary to adapt the configuration
on the router side, when a change in the network topology occurs. Hence, this is a feature
that must be taken advantage of.
• In the first option that was raised, each of the vNICs used for each APU, was associated
with the same common VLAN, as it is shown in Figure 5.12. This VLAN is in the
middle of the application and the routers. In addition, it was considered that the
vEPC could have a loopback IP (Lo_vEPC), so a Border Gateway Protocol (BGP) session
could be implemented. This would allow the routers to see the IP of the Access Point
Name (APN) pool addresses and the GTP Tunnel endpoints. Hence, the routes can
know the destination IP as BGP routers with a next hop to the vEPC (Lo_vEPC). In this
option, it is used OSPF to propagate the loopback IP, instead of using static routes. In
addition, OSPF is used to implement the load balancing for the APU by using (ECMP).
This is due to the routers have a set of OSPF ECMP routes equal to the number of APU.
However, although this solution may seem optimal, it must bear in mind that there
are some situations where OSPF cannot be used. The solution would be the use of
static routes, so the routers need to be manually configured with a set of static routes.
All these routes would have the same destination address, which is, in this case, the
loopback IP on the vEPC. Furthermore, the next-hop would be each IP address of the
APU on the common VLAN. Therefore, the load balancing would be made by ECMP
57
instead of OSPF. Nevertheless, implementing a manual configuration is not the best

approach, since there may be a large number of these routes making it not scalable
since the number of routers follows the following equation:
Number o f Rout es = Number o f Log i cal I nt er f aces § Number o f APU (5.1)
• Second option is simpler than the first one, since the BGP session is removed and the
service IP addresses are announced directly by OSPF. This allows the routers to see
these IPs coming as OSPF routes from the APU as next-hop. All these routes would
have the same metric. The implementation of load balancing is done by OSPF ECMP,
as it happens in the option number one.
One of the failure cases that should be considered is the down of a VM or interfaces
associated to any vNIC of a IPU. During this scenario, the router could not forward the traffic
to the next-hop. Thanks to the use of OSPF it is possible to fix the problem in around 1 minute
since this protocol has its own convergence mechanism which can remove or add neighbours.
However, the time needed by OSPF to solve the failure is not always acceptable. This is why
in some situations is more optimal using BFD protocol which is able to faster recalculating
the new routes to reach the next-hop. To do this, it is assumed that it is possible to bind a
single BFD session to all the interfaces and vNIC of an IPU. If not, there is a scalability issue
because it would need to have a BFD session per each interface.
With the intention of understanding better which option is the most successful, the
following Table 5.3 has some general considerations of scalability to take into account.
Paremeter Value
Where:
VLAN x+y
ECMP routes per UP interface n - 2: is the number of IPU
ECMP routes per CP interface 2
Total ECMP routes n*x +2*y - n: is the Number of APU
TotalBGP session (option 1) x+y - x: is the Number of Logical User
Total BFD session (one per interface) n*x +2*y Plane Interfaces
OSPF neighbours per UP interface n
Total OSPF neigbours n*x +2*y - y: is the Number of Logical Con-
trol Plane Interfaces
Table 5.3: Network parameters dimensioning [12].
After considering the two options, option number two was chosen. The main reasons
were that it does not need so much configuration since BGP session is not used. In addition,
it is not using a routing reverse lookup, so the implementation is easier.
Once the design of the connectivity has been chosen, it was necessary to consider other
possible limitations in vUGW. For instance, one of the main issues that were taken into
account, was the topic of: How many neighbours could support OSPF?.
58
As we have seen previously, the more capacity the vUGW has, the greater number of APUs
are necessary. Therefore, OSPF would have to support a greater number of neighbours. But
there are limitations, these neighbours cannot be too many since the load has to be balanced
between them. This reasoning can be explained with the following formula:
OSP F nei g hbour s + B F D sessi ons = Number o f APU s § Number o f user pl aneV RF
(5.2)
Now, let’s consider a more concrete example:
90APU s § 3V RF s(Gi ,Gn, S1 °U ) = 270 (5.3)
Which means, there would be 270 OSPF neighbours per router. This amount is not contem-
plated by the manufacturers, so it would be a risk to implement it. Therefore, the decision was
made to lower the number of APUs, and this results in less capacity in the vUGW. Specifically,
it was agreed to reduce the number of APUs to 70, which translates the throughput to 70%
instead of 90%, as was originally intended.
However, although the capacity is reduced, it is not a problem taking into account the
architecture of the rest of the data core network. Actually, there are 8 APUs of redundancy:
62+8. Although these 8 VMs will not work correctly, all the traffic that is estimated to have
inside the node could go through the remaining 62 APUs without problems. In order to see
more information about the traffic estimation, go to Section 2.3.
5.3.1 LLD
In this part, it is presented the LLD, where are shown in a technical way the connectivity
decisions that have been taken in section 5.3.
Note, that for reasons of confidentiality, in this project it has been preferred not to include
IP addresses, masks or any other data that could be sensitive to the security of the Vodafone
network.
As already shown in previous sections, the vUSN is a node which has just IPU VMs. On the
contrary, the vUGW not only has IPUs for signalling but also has to use APU VMs to manage
data traffic. Each of these VMs has a vNIC assigned that, at the same time, has an allocated
interface. In order to know how to carry out these relationships, the following list contains
the rules which relate vNICs to their respective interfaces:
• vNICs 0,1 and 2: Internal traffic.
• vNIC 3: Access interfaces. Gb, lu, S1-MME for vUSN and S1-U and Gn/S11 for vUGW.
• vNIC 4: Interfaces to the data core network, or Internet. Gn/S11 and S1-U for vUSN
and Gi for vUGW.
• vNIC 5: Signaling interfaces and others. Rest of interfaces for vUSN and signaling
interfaces for vUGW.
59
To avoid possible failures, the same vNIC is assigned to two VM: IPU1-IPU2, APU1-APU2.
Thanks to using this redundancy, if one of the two VMs fails, there would always be another
that would replace it. So the data traffic would not be affected.
Once these relationships are done, it remains to assign sub-ports to each vNIC, as well as
VLAN ID and VPN Routing and Forwarding (VRF). All these information is reflected in Figure
5.14 for the vUSN and 5.15 for the vUGW. There, it is shown not only their VM, ports and
sub-ports but also the logical interfaces and the networking that has been chosen for each of
them.
These two figures are very useful when configuring the NEs, since the tables have data
that must be entered in each of the nodes to integrate them into the data core network. In
order to know more information about configuration, go to the following section 5.4.
60
Figure 5.14: vUSN IP Desing.
61
Figure 5.15: vUGW and vMSE IP Desing.
62
5.4 I NSTALLATION AND C ONFIGURATION
This section describes the steps carried out in order to make the installation and configura-
tions of several NEs that were introduced in Section 4.2, and 5.2. All the stages were made in
the laboratory at Vodafone Plaza, in Madrid.
As it has been explained in section 4 and 5.2, there are three types of clusters in a virtual
environment. One is the Infrastructure Management Cluster, and it holds the CSM and vCD.
Another one is the Application Management Cluster, which gathers elements for analytics,
such as vOSMU, U2000 and PRS. Furthermore, there is the Data Service Cluster, where are
the VNF.
To virtualize the network, it is necessary to create and apprropriately manage all these
elements. With this purpose, all of them have to be installed following a strict order, marked
by the manuals of VMware and Huawei.
First of all, it has to be created the CSM by using descriptor files. This element is very
important since it is in charge of the creation of the VNFs. For this reason, it should be verified
that after its creation, it has communications with the other components as, vOSMU, vCD
and vCenter. In order to carry out this check, a computer network software called ping was
used. This software tool allows testing the reachability of a host on a IP network.
During this step, it was found that the CSM and the services cluster did not have commu-
nication. So, the LLD of the vUSN and vUGW (see Figures 5.14 and 5.15) were first checked
to verify that the connectivity was correct.
Once it was ruled out that it was a connectivity problem, the next step was to check the
firewall rules. This checkup showed that there were some rules missing from the Management
and the Services vCenters. In order to solve this fault, the firewall rules were reconfigured,
taking into account the IPs that had not been added from the beginning.
After solving this problem, the next step was to transfer the descriptor CSM files, which
have the VNFs. This transfer is made through a File Transfer Protocol (FTP) session, from the
CSM in the Management vCenter to the vCloud in the Service vCenter. After these descriptor
files were installed there, the NFVs can start to be created.
The installation is made with a Huawei SW, where it is possible to place all the features of
each node that were agreed in previous steps in the vBOM and LLD, in Sections 5.1 and 5.3.1
respectively.
During this process, the redundancy of the VMs was taken into account. Hence, for each
VM required, it was created two of them. One as VM master and the other as VM slave. Notice
that each of them have a different IP address.
During the creation of the vUSN, it was found that there were several master and slave
VMs with the same IP address. This issue was solved stopping the creation process and
starting it again.
For the configuration of the NEs, it is necessary to differentiate between its internal, and its
external part. The configuration that will be shown next, refers to the external part which
has the interfaces that are used for the integration of the nodes with the rest of the data core
network. (It has been decided to show only the external configuration since this part has
63
more relation whit the topic of this thesis).

Then several commands used in the configuration will be listed. These commands are in
their most generic form to not show data that could be confidential. Note that only the most
relevant commands have been included since the configuration files are very large and not
all could be displayed:
• Set global BFD attributes:
SET BFD:BFDENABLE=TRUE;
This command enables a BFD session for each of the interfaces of the nodes which
uses BFD.
• Add an Layer 3 Virtual Private Networks (L3VPN) instance:
ADD L3VPNINST:VRFNAME="vrf1";
This step adds a dedicated Virtual Private Network (VPN) for each of the interfaces.
Althoutg a VPN cannot share resources with other VPNs on the same network, it is able
to protect internal information, this is why add this element is important.
• Add IP address family:
ADD VPNINSTAF:VRFNAME="vrf1", AFTYPE=ipv4uni;
This command is used to add an IP address family to each L3VPN instance.
• Add associations between interfaces:
ADD IPBINDVPN:IFNAME="Loopback1",VRFNAME="vrf1";
This command is used to associate an interface connecting to the VPN with the VPN
instance. So, this interface is used as a private network interface on which a private
network address and a private network routing protocol can be configured.
• Create or remove an interface:
ADD INTERFACE: IFNAME="LoopBack4", IFADMINSTATUS= “up/down";
This command allows to add or remove a logical interface and set parameters.
• Modify interfaces:
MOD INTERFACE: IFNAME="LoopBack4", IFADMINSTATUS= “up/down";
64
With this command, it is possible to modify the configurations of a logical or physical

interface already added.
• Add Ethernet sub-interface
ADD ETHSUBIF: IFNAME="Ethernet64/0/X.X", VLANTYPEVID=XX;
This command is used to add a new Ethernet sub-interface and associate it with a
VLAN already created.
• Configuration of IPv4 addresses:
ADD IFIPV4ADDRESS: IFNAME="LoopBack4", IFIPADDR="XX.XXX.XX.XXX",

SUBNETMASK="255.255.XXX.X", ADDRTYPE=main;
This command is used to configure an IPv4 address for a logical or physical interface.
5.5 SW VALIDATION
In this section it is shown how to validate different NEs: vUSN, vUGW, and its homonyms in
5G: CGW and DGW.
The section is divided into two parts. First, a case guide with a generic list with the most
relevant uses cases that were tested and a brief explanation of it. And after, it will be presented
the result of these tests.
Although all these tests were carried out and are part of the technical section of this
project, notice that just three cases will be presented. The idea is to give the reader a clear
picture of how are these tests, without adding more cases lengthening the content of this
thesis.
5.5.1 C ASES G UIDE

During the NEs’ validation, a series of tests were carried out to verify the correct functioning
of each element. Below is a list of all the tests that were performed on the vUSN in 3G [14],
vUSN in 4G [15], and vUGW [16]. Furthermore, the use case for the 5G tests is also briefly
explained.
The following cases guide was proposed by Huawei and is based on the 3GPP possible
scenarios that each NE could face in the future. The idea is to test all these scenarios putting
more emphasis on those more important and critical. With this, it pretends to ensure the
correct functioning of each node and validate it.
Notice that for each test it was necessary to reconfigure each node in such a way that they
were ready for each of the tests.
65
vUSN uses cases in 3G # vUSN uses cases in 4G #
Basic Services 1 Subscription Management 2

Mobility Management 8 Mobility Management 12
Security Management 8 Security Management 9
Subscriber Data Management 3 Session Management 10
Session Management 8 Interface Management 7
Charging Function 3 Handover 2
QoS and Flow Management 3 MME Pool 3
QoS Control 3 QoS Mapping 1
QoS Conversion 1 IMSI Based QoS Control 1
HSPA 11 QoS Control Enhancement 1
3G Subscriber Access Control 1 Auto-Configuration of the X2 Inter- 1
face
Area Roaming 1 NE Selection 8
Network Reselection between LTE 1 Access Control 2
and UMTS
PS Handover Between LTE and 1 GUL Interworking 3
UMTS
Multi-HPLMN Function 1 Non-EPS Alert 1
Detach of Inactive Subscribers 1 Telecom Service 15
Idle PDP Context Deactivation 1 CSFB with MSC Pool 1
Iu-PS Interface 1 Requested APN Correction 1
SS7 Interface 2 Multiple HPLMNs 1
Ga Interface 1O peration and Maintenance 9
Gn Interface 1Emergency Call 1
Gateway Route Selection 6 Accurate Paging 1
Requested Information Correction 1 Interoperation Between the LTE 1
and WiFi Networks
IMS 1 Voice Policy Control for User Group 3
Gs Interface 3 Location Information Query in 1
Voice Service
Subscriber Migration in MSC 1 Local QoS Policy in PCC Mode 1
POOL
Iu-Flex 3 Category Function 4
SGSN Pool 1 IP Function 6
ODB 1 Support eNodeB Coverage Level 1
Based Paging
Multi-IMSI Function Test 1 LTE M2M Terminal Power Saving 1
Direct Tunnel 1 Presence Reporting Area Support 1
NACC 1 Low-Priority Access Control 1
Network Share MOCN 1 Signaling Congestion Control 1
Based on the Back-off Timer
66
IMEI Check for Gf Interface 1 Equivalent NE Selection Based on 1

Location
vUSN Life Cycle Management 2 LTE PTT 1
CHR 1 Network Interoperation Between 1
CDMA2000 and LTE
Extended Periodic RAU/TAU Timer 1 PDN Re-Activation to Local P-GW 1
for M2M
APN-based Signaling Congestion 1 HeNB’s Access to the MME 1
Control Through an HeNB Gateway
Null-MSISDN Function Supported 1 LTE UE Signaling Control 1
by the SGSN
S4 SGSN Project Acceptance 2 End-to End Subscriber Trace 1
Service-based Handover 1 CBS 1
Multi-Signaling 1 Network Identity Selection Based 1
on RAN Area
Smartphone Control 3 Service Guarantee for High- 1
Mobility User
GWCN Network Sharing 1 EPC LCS 1
MVNO 1 Real-time Location-based Policy 1
Control
SMS 1 UE Cell Location Reporting to the 1
UIC
Alias APN 1 T56 Multi Time Zone Service 1
Network Identity Selection Based 1 Network Share (GWCN) 1
on RAN Area
Intelligent Policy for VIP Sub- 1 Null-MSISDN 1
scribers
ARP-based Differential Services 1 VoLTE Disaster Tolerance 2
SuperCharger 1 IPv6-based UE Attach 1
TOTAL: 107 TOTAL: 132
Table 5.4: vUSN uses case [14], [15].
For the validation of 5G in NSA, as it has never been tested before, there is no list of
evidence to follow. For this reason, the tests that were carried out were with the simplest
scenarios, checking the correct functioning of the Basic Services and Mobility Management
test. See more details about the testing phase, going to Appendix C.
5.5.2 E NVIRONMENT S ETUP

To make the SW validation of the different NEs, it was previously necessary to make a setup
of the environment. So, the procedure that was carried out for the validation of the vUSN and
67
vUGW #
Operation and Maintenance 29
Routing And Network 10
Basic Services 21
Radius Management 11
Charging Management 3
TOTAL: 74
Table 5.5: vUGW uses cases [16].
vUGW nodes will be explained, and later it will be shown how the environment was adapted
for the NSA tests.
For the vUSN and vUGW the tests were carried out in the laboratory, at Vodafone Plaza in
Madrid. The elements that were used are:
• Smartphone compatible with 2G/3G/4G technologies.
• Subscriber Identity Module (SIM) cards compatible with 2G/3G/4G technologies.
• Faraday cages.
• Cables with 2G/3G/4G signals.
• Laptops with the operative system: Windows 10.
• SW to trace messages: Wireshark and TraceViewer (SW from Huawei).
• Remote access from the PC to the nodes through browsers.
• Laptop and smartphone chargers.
• 2G/3G/4G antennas placed in Vodafone Plaza, pointing to the testbed Gi-LAN (where
are placed all the platforms).
Once all the material have been gathered, we need to place the SIM card in the smart-
phone. Both SIM and smartphone should be compatible with 2G/3G/4G technologies to
avoid problems in any of the tests.
The first step is to initiate the SW from Huawei with which the messages sent between
the device and the network are traced to control its operation. To do this, once this SW has
been initialized, certain parameters must be entered. For instance, the International Mobile
Subscriber Identity (IMSI) of the UE, so that it only traces the messages sent from that device
and does not mix with others.
After that, the smartphone is powered on, and it checks that it works correctly. In addition,
the smartphone is placed in the Faradays’ cage, see Figure 5.16. The device is placed there,
because thanks to the effect of the Faraday cage, the electromagnetic field inside is zero. So
68
the effect of external fields is cancelled. Therefore, there are connected to the cage cables
with 2G/3G/4G signals pointing to the testbed line, forcing the phone to connect to one of
them, without being affected by external signals. This is very important since the vUSN and
vUGW nodes are only located in the testbed line. Hence, if the mobile is connected to another
signal that is not the testbed, tests could not have been carried out. Figure 5.17 shown the
connections of the Faraday cage where they are connected in that case, cables with 3G and
4G signals.
Once the Faraday cage is provisioned with signal pointing to the testbed, it is time to
activate the Airplane Mode to the phone. This is done to avoid being connected to other
signals. After this, it is closed almost completely the door of the cage, leaving a small space for
the hand, which will deactivate the Airplane Mode, and subsequently close the cage quickly,
see Figure 5.18.
Later, a small interval of time is left for the mobile to be attached to the network that has
more power in the cage. Then, in order to check that the phone is attached to the correspond-
ing network, it is possible to look through the metal mesh and verify that everything works
properly. Figure 5.19 has an image with the mobile inside the cage, where the network with
which the UE is attached, is LTE.
Finally, the SW validation can start. Go to Subsection 5.5.3 to see more information about
the procedure to follow and some of the tests carried out, as well as its results.
Figure 5.16: Step One - Placement of the Figure 5.17: Step Two - Cables provision-
test mobile in the Faraday cage. ing 4G and 3G signals to the Faraday
cage.
In the case of the NSA testing, the environmental setup was different. The elements
needed, were the following:
• Huawei Radio Access Network: 4G antenna.
• Huawei Radio Access Network: 5G antenna.
• Huawei Customer Premises Equipment (CPE), Figure 5.22.
• Laptops with operative system: Windows 10.
• Laptop and CPE chargers.
69
• SW to trace messages: Wireshark and TraceViewer (SW from Huawei).
Figure 5.18: Step Three - Cage of Faraday Figure 5.19: Step Four - Monitoring of
closed, with the mobile test inside, ready the test mobile signal through the mesh
to begin the tests. of the Faraday cage.
The equipment was placed outdoor, in Vodafone Plaza installations. First of all, two
antennas were installed in one of the corners of the building. One transmitting and receiving
4G signals, and the other for 5G transmissions. Figure 5.20 has a photography of these
antennas. Both antennas are needed since it was a NSA test, where the data goes through 5G
but signalling through 4G. See more information about this topic in Subsection 4.3.3 .
In addition, the CPE was also placed in Vodafone Plaza, as it is shown in Figure 5.21. In
order to achieve the best results in the test, several measurements of coverage were carried
out inside the courtyard. Once the place with the best coverage values was found, the tests
were started. See Section 5.5.3 to find more information about this tests.
Figure 5.20: 5G and 4G antennas for NSA Figure 5.21: NSA Testing - Huawei CPE
testing, in Vodafone Plaza. side, in Vodafone Plaza.
70
Figure 5.22: Huawei CPE: First Commercial 5G Modem, [10].
5.5.3 R ESULTS
Following, three results of the tests based on the previous section will be presented. Being so
many tests, and with very long visual results, it has been decided to put only the most relevant
cases of each node and each technology. This is why the results shown below are from vUSN
using 3G technology, vUGW in 4G, and the nodes DGW and CGW using 5G technology, in the
architecture NSA:
T01-02 Combined Attach
T01-0201 UE Initiating a Combined Attach Procedure
A combined attach is a double attach used for Evolved Packet System (EPS) and for non-EPS
(e.g. Short Message Service (SMS) only). Moreover, it is also used by UE in Circuit Switch-
ing (CS) and Packet Switching (PS) to attach for EPS services when the IMSI it is already
attached for non-EPS services. The purpose of doing this test is to verify that the MME
supports the combined attach procedure. In addition, it is also used to see if the MME can
map a Tracking Area Identity (TAI) and a Location Area Identity (LAI) to the Mobile switching
center (MSC)/Visitor Location Register (VLR). With this, the idea is to find the MSC/VLR
configuration which is based on the LAI since it can be used to provide CS services for the
subscribers.
The following diagram, in Figure 5.23, represents the normal behaviour of a combined
attach based on the 3GPP standards. In it, there are all the messages that are needed to be
sent between the NEs, in order to complete with success the combined attach. Therefore, to
be sure that everything was working properly during the test, the results were compared with
this procedure.
Before start the testing, it is necessary to preset some parameter conditions:
• The UE should be subscribed in the EPS and CS services.
71
Figure 5.23: T01-0201 Combined Attach Diagram [15].
72
• Activation the license to support for voice, via CS-Fallback (CSFB) with the following
Man-Machine Language (MML) command:
SET LICENSESWITCH: LICITEM="LKV2CSFBGU02", SWITCH=ENABLE;
• MME configuration: set SGs links and map TAIs and LAIs
• To check if the subscriber information is already registred in the MME:
DSP MMCTX: QUERYOPT=BYIMSI, IMSI="<IMSI>";
• Creation of user, S6a interface, S1 interface, SGs, and GTP-C tracing tasks in the MME.
Once these preset conditions were covered, the UE was powered on. Besides, it was
placed in the Faraday’s cage, with a 4G coverage by following the environment setup, already
explained in Subsection 5.5.2.
The resulting traces of this test, are displayed in Figure 5.24. In this image, there are all
the messages which were sent between the platforms. It is indicated the traces number, the
time, the position, and the message body length. In addition, it is also indicated from which
node comes the message, as well as which is its the destination. Another important data that
is in this image, it is the message type.
The three most important data are time, message type and message direction. Therefore,
in order to identify if the test was carried out correctly, these three fields were checked out by
comparing it with the expected behaviour, Figure 5.23.
73
74
Figure 5.24: T01-0201 Combined Attach Traces.
In this particular case, the test was successful. In the following lines, there is a list with all
the messages forwarded with a brief explanation of each of them (the messages corresponding
to the internal traffic of every node have not been evaluated). Notice that the numbers of
each listing element correspond to the number of each message represented in Figure 5.24:
[442 ] After powered on the UE, the device sent a Attach Request message to the MME. This
message had the attach type IE whose value is "combined attach".
[443 ] The next message is a Identity Request. Here, the UE is identified in the MME.
[444 ] The UE sends a Identity Responds to the MME, with its identification.
[445 ] In the following trace, the MME ask to the Home Subscriber Server (HSS) about the
user profile of the specific UE to request security vectors. Therefore, inside this message,
it is send an Authentication Information Request, with the IMSI of the UE .
[446 ] After, the HSS returns to the MME an Authentication Information Answer message,
that holds the EPS security vectors.
[447 ] As a result, the MME sends its Authentication Request message to the UE, with the
AUTH and RAND IEs.
[450 ] In responds, the UE sends an Authentication Response message to the MME.
[451 ] The next trace is the MME sending a Security Mode Command message to the UE. In
it, there is a negotiation about the key and algorithm to be used.
[454 ] As a consequence of this last message, the UE sends a Security Mode Complete message
to the MME.
[455 ] Once this last exchanges of messages end, it is time to send an Update Location
Request message, from the MME to the HSS. Thanks to this message, it is possible to
update the location of the UE since it holds the ULR-Flags IE. These flags indicate to
the HSS that has to include a subscription data in the next Update Location Answer
message to be returned.
[456 ] Then, the HSS brings back an Update Location Answer message, where it is included
the subscription data required.
[461 ] Later, the update process is complete. Hence, the MME is ready to starts a default
bearer establishment procedure. For it, it is sent a Create Session Request message to
the S-GW. Inside this message, there is the P-GW IP address to which the S-GW points
and the Evidence-Based Intervention (EBI) IEs. In response, the S-GW takes care of
forwarding the Create Session Request message to the P-GW.
[462 ] So, as a consequence, the P-GW returns a Create Session Response message to the
S-GW. This message contains the control and user plane IPs, as well as the Tunnel
Endpoint Identifier (TEID) and charging ID of the P-GW. This last message is forwarded
by the S-GW to the MME.
75
[465 ] Finally, the MME forwards, a Initial Context Setup Request message, which contaisn an
Attach Accept message, to the eNodeB. This Attach Accept message carries an Activate
Default EPS Bearer Context Request message. The UE returns an Attach Complete
message and the eNodeB forwards an Initial Context Setup Response message. With
this message, it is indicated the setup of the default bearer.
[443 ] The next message is a Identity Request. Here, the UE is identified in the MME.
[444 ] The UE sends a Identity Responds to the MME, with its identification.
[445 ] In the following trace, the MME ask to the HSS about the user profile of the specific UE
to request security vectors. Therefore, inside this message, it is send an Authentication
Information Request, with the IMSI of the UE .
[446 ] After, the HSS returns to the MME an Authentication Information Answer message,
that holds the EPS security vectors.
[447 ] As a result, the MME sends its Authentication Request message to the UE, with the
AUTH and RAND IEs.
[450 ] In responds, the UE sends an Authentication Response message to the MME.
[451 ] The next trace is the MME sending a Security Mode Command message to the UE. In
it, there is a negotiation about the key and algorithm to be used.
[454 ] As a consequence of this last message, the UE sends a Security Mode Complete message
to the MME.
[455 ] Once this last exchanges of messages end, it is time to send an Update Location
Request message, from the MME to the HSS. Thanks to this message, it is possible to
update the location of the UE since it holds the ULR-Flags IE. These flags indicate to
the HSS that has to include a subscription data in the next Update Location Answer
message to be returned.
[456 ] Then, the HSS brings back an Update Location Answer message, where it is included
the subscription data required.
[461 ] Later, the update process is complete. Hence, the MME is ready to starts a default
bearer establishment procedure. For it, it is sent a Create Session Request message to
the S-GW. Inside this message, there is the P-GW IP address to which the S-GW points
and the EBI IEs. In response, the S-GW takes care of forwarding the Create Session
Request message to the P-GW.
[462 ] So, as a consequence, the P-GW returns a Create Session Response message to the
S-GW. This message contains the control and user plane IPs, as well as the TEID and
charging ID of the P-GW. This last message is forwarded by the S-GW to the MME.
76
[465 ] Finally, the MME forwards a Initial Context Setup Request message to the eNodeB,
which contains an Attach Accept message. This Attach Accept message carries an Acti-
vate Default EPS Bearer Context Request message. The UE returns an Attach Complete
message and the eNodeB forwards an Initial Context Setup Response message. With
this message, it is indicated the setup of the default bearer.
After having seen the exchange of packages between the different NEs that are involved
in a combined attach, it is time to analyze one of these packages to verify that its content has
all the parameters and their correct values.
Since the information that a trace holds it is quite large, it was decided to simplify and
explain just one of them to have a general vision about its structure, parameters and values.
The message number [442] with an Attach Request, is the packet which contains the
largest amount of information during the combined attach. This is why it was selected as the
message to be explained coming up next.
Trace 5.1 has part of the content of this message. Coming up next, there is a brief explana-
tion about the content of this trace. Since each line of the trace is assigned to a number on
the left side, this reference will be used to comment on that line:
[28-48 ] Indicates that the Internet Protocol used is in Version 4. In addition, the most relevant
parameters used for IPv4 are shown. For instance, header length, checksum, time to
live, and the Stream Control Transmission Protocol (SCTP) protocol used.
[51-59 ] The S1 Application Protocol have parameters between the MME and eNodeB. Inside,
there is the EPS mobile identity field which has information with regards the Mobile
Country Code (MCC) and the Mobile Network Code (MNC). Both parameters have
data about the UE location (e.g. MCC equal to 214, means that the UE is in Spain. In
addition, if the MNC is equal to 01, means that the mobile operator used is Vodafone).
Moreover, there are also data about the MME group ID, MME Code and M Temporary
Mobile Subscriber Identity (M-TMSI), which gather values that indicates in which MME
was attached the UE for last time. All these information has relation with the Global
Unique Temporary Identityl (GUTI).
[60-93 ] Inside the UE network capability there are several parameters which indicate the
encryption that the UE supports. When the bits are set to 1, means that the service is
supported. However, if it is set to 0, it is not supported by the device.
[95-106 ] EPS Session Management (ESM) message container:
[97-100 ] ESM message container content gathers information about the EPS bearer iden-
tity.
[101-103 ] In addition, there are Non-Access Stratum (NAS) EPS session management
messges. Here, there are information about the Packet Data Network (PDN)
connectivity.
The reason for the existence of this field is a need in LTE to have an open context
whenever it is being attached. When the device receives a call on LTE, it must
77
change the network to one of 3G/2G, doing CSFB. Once the call has finished, the
UE must go back to 4G. And for this whole process, it is necessary to have an open
context all the time.
The disadvantage of using this technology is that the battery of the device is spent
much more easily. But the advantage is that the UE is connected all time, receiving
instant notifications.
[101-103 ] In the ESM information transfer flag, there are information about the APN. When
the bit is set to 1, it is the network which select the APN by default: airtelwap.es.
However, if the bit it is 0, the APN is selected by the UE.
[121-125 ] Tracking area identity. The elements inside this packet, indicate to the MME the last
location of the UE. The idea is to know where was the last connection of the device.
If the MME wants to get in touch with the device, it has to paging the UE eNodeB. But if
the device does not answer, the MME will send paging messages to all the eNodeB of
the TAI where the UE was connected for the last time, until finding it.
[126-131 ] The DRX Parameters are in charge of saving battery. These values indicate how much
time the radio bearer can be on.
Here it is important to differentiate between context and bearer. The context anchors
the device in a unique way. However, the bearer can be assembled and disassembled
according to the needs required by the UE. Therefore, in order to save energy, when the
radio carrier is not necessary, it is dismantled. And the parameter that indicates when
to deactivate it is:
[128] SPLIT PG CYCLE CODE: 10 (10)
[133-159 ] The MS Network capability indicates the capabilities via dedicated channels of the
terminal to do handover and Single Radio Voice Call Continuity (SRVCC).
[161-164 ] Temporary Mobile Subscriber Identity (TMSI) Status. The TMSI is used in paging
situations and it is incharge of protect subscribers of being identificated. TMSI is hold
by VLR and is not passed to Home Location Register (HLR). Besides, The TMSI is stored
in the SIM.
R code 5.1: T01-0201 Combined Attach Traces
1 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
2 * vUSN 4 G - Combined Attach
3 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
4
5 -------------------------------------------------------------
6 Frame :
7
8 Initial UE Message , Attach request , PDN connectivity request
78
10 -------------------------------------------------------------
11
12 Frame 308: 178 bytes on wire (1424 bits ) , 178 bytes captured ...
(1424 bits )
13 Encapsulation type : Ethernet (1)
14 Arrival Time : May 30 , 2018 16:51:21 .964000000 CEST
15 [ Time shift f or this packet : 0 .000000000 seconds ]
16 Epoch Time : 1527691881 .964000000 seconds
17 [ Time ¢ from previous captured frame : 246 .255000000 seconds ]
18 [ Time ¢ from previous displayed frame : 246 .255000000 ...
seconds ]
19 [ Time since reference or first frame : 2210 .256000000 ...
seconds ]
20 Frame Number : 308
21 Frame Length : 178 bytes (1424 bits )
22 Capture Length : 178 bytes (1424 bits )
23 [ Frame is marked : False ]
24 [ Frame is ignored : False ]
25 [ Protocols in frame :
26 eth : ethertype : ip : sctp : s1ap : s1ap : s1ap : s1ap : nas - eps : s1ap : s1ap : s1ap ]
27
28 Internet Protocol Version 4 , Src : 2 .2.2.2 , Dst : 1 .1.1.1

29 0100 . . . . = V e r s i o n : 4
30 ... . 0101 = Header Len gth : 20 bytes (5)
31 Differentiated Services Field : 0 x00 ( DSCP : CS0 , ECN : ...
Not - ECT )
32 0000 00 .. = Differentiated Services Codepoint : ...
Default (0)
33 . . . . . . 0 0 = E x p l i c i t C o n g e s t i o n N o t i f i c a t i o n : N o t ...
ECN - C a p a b l e T r a n s p o r t ( 0 )
34 Total Length : 164
35 Identification : 0 x0000 (0)
36 Flags : 0 x00
37 0 ... .... = Reserved bit : Not set
38 .0.. . . . . = Don ' t f r a g m e n t : N o t s e t
39 ..0. . . . . = M o r e f r a g m e n t s : N o t s e t
40 Fragment offset : 0
41 Time to live : 62
42 Protocol : SCTP (132)
43 Header checksum : 0 x0000 [ validation disabled ]
44 [ Header checksum status : Unverified ]
45 Source : 2 .2.2.2
46 Destination : 1 .1.1.1
47 [ Source GeoIP : Unknown ]
48 [ Destination GeoIP : Unknown ]
49
79
50 S1 Application Protocol
51 EPS mobile identity
52 Length : 11
53 ... . 0 ... = Odd / even i n d i c a t i o n : Even numb er of i d e n t i t y digit s
54 ... .110 = Type of i d e n t i t y : GUTI (6)
55 Mobile Country Code ( MCC ) : Spain (214)
56 Mobile Network Code ( MNC ) : Vodafone Espana , SAU (01)
57 MME Group ID : 12741
58 MME Code : 193
59 M - TMSI : 0 xce017831
60 UE network capability
61 Length : 4
62 1 ... .... = EEA0 : Supported
63 .1.. . . . . = 1 2 8 - E E A 1 : S u p p o r t e d
64 ..1. . . . . = 1 2 8 - E E A 2 : S u p p o r t e d
65 ... 0 .... = 128 - EEA3 : Not s u p p o r t e d
66 ... . 0 ... = EEA4 : Not supported
67 ... . .0.. = EEA5 : Not supported
68 ... . ..0. = EEA6 : Not supported
69 ... . ...0 = EEA7 : Not supported
70 0 ... .... = EIA0 : Not supported
71 .1.. . . . . = 1 2 8 - E I A 1 : S u p p o r t e d
72 ..1. . . . . = 1 2 8 - E I A 2 : S u p p o r t e d
73 ... 0 .... = 128 - EIA3 : Not s u p p o r t e d
74 ... . 0 ... = EIA4 : Not supported
75 ... . .0.. = EIA5 : Not supported
76 ... . ..0. = EIA6 : Not supported
77 ... . ...0 = EIA7 : Not supported
78 1 ... .... = UEA0 : Supported
79 .1.. . . . . = U E A 1 : S u p p o r t e d
80 ..0. . . . . = U E A 2 : N o t s u p p o r t e d
81 ... 0 .... = UEA3 : Not supported
82 ... . 0 ... = UEA4 : Not supported
83 ... . .0.. = UEA5 : Not supported
84 ... . ..0. = UEA6 : Not supported
85 ... . ...0 = UEA7 : Not supported
86 0 ... .... = UCS2 support ( UCS2 ) : The U E h a s a p r e f e r e n c e ...
for the default alphabet
87 .1.. . . . . = U M T S i n t e g r i t y a l g o r i t h m UIA1 : Supported
88 ..0. . . . . = U M T S i n t e g r i t y a l g o r i t h m UIA2 : Not supported
89 ... 0 .... = UMTS integrity algorithm UIA3 : Not supported
90 ... . 0 ... = UMTS integrity algorithm UIA4 : Not supported
91 ... . .0.. = UMTS integrity algorithm UIA5 : Not supported
92 ... . ..0. = UMTS integrity algorithm UIA6 : Not supported
93 ... . ...0 = UMTS integrity algorithm UIA7 : Not supported
94
95 ESM message container
80
96 Length : 5
97 ESM message container contents : 0205 d011d1
98 0000 . . . . = E P S b e a r e r i d e n t i t y : N o E P S b e a r e r i d e n t i t y ...
assigned (0)
99 . . . . 0 0 1 0 = P r o t o c o l d i s c r i m i n a t o r : E P S s e s s i o n m a n a g e m e n t ...
m e s s a g e s (0 x2 )
100 Procedure transaction identity : 5
101 NAS EPS session management messages : PDN connectivity ...
request (0 xd0 )
102 0001 . . . . = P D N t y p e : I P v 4 ( 1 )
103 ... . 0001 = Request type : Initial request (1)
104 ESM information transfer flag
105 1101 . . . . = E l e m e n t I D : 0 xd -
106 ... . 000 . = Spare bit ( s ) : 0 x00
107 . . . . . . . 1 = E I T ( E S M i n f o r m a t i o n t r a n s f e r ) : S e c u r i t y ...
protected ESM information transfer required
108 P - TMSI Signature - Old P - TMSI Signature
109 Element ID : 0 x19
110 P - TMSI Signature : 0 xa0d73b
111 EPS mobile identity - Additional GUTI
113 Length : 11
114 . . . . 0 . . . = O d d / e v e n i n d i c a t i o n : E v e n n u m b e r o f i d e n t i t y ...
digits
115 ... . .110 = Type of i d e n t i t y : GUTI (6)
118 MME Group ID : 32769
119 MME Code : 192
120 M - TMSI : 0 xe40d21eb
121 Tracking area identity - Last visited registered TAI
125 Tracking area code ( TAC ) : 264
126 DRX Parameter
127 Element ID : 0 x5c
128 SPLIT PG CYCLE CODE : 10 (10)
129 0000 . . . . = C N S p e c i f i c D R X c y c l e l e n g t h c o e f f i c i e n t : C N ...
S p e c i f i c D R X c y c l e l e n g t h c o e f f i c i e n t / v a l u e n o t ...
s p e c i f i e d by the MS (0)
130 . . . . 0 . . . = S P L I T o n C C C H : S p l i t p g c y c l e o n C C C H i s n o t ...
s u p p o r t e d by the mobile s t a t i o n
131 . . . . . 0 0 0 = Non - D R X t i m e r : n o non - D R X m o d e a f t e r ...
transfer state (0)
132
133 MS Network Capability
81

135 Length : 3
136 1 ... .... = GEA /1: Encryption algorithm available
137 .1.. . . . . = S M c a p a b i l i t i e s v i a d e d i c a t e d c h a n n e l s : M o b i l e ...
s t a t i o n s u p p o r t s m o b i l e t e r m i n a t e d p o i n t t o p o i n t S M S ...
via dedicated signalling channels
138 ..1. . . . . = S M c a p a b i l i t i e s v i a G P R S c h a n n e l s : M o b i l e ...
s t a t i o n s u p p o r t s m o b i l e t e r m i n a t e d p o i n t t o p o i n t S M S ...
via GPRS packet data channels
139 . . . 0 . . . . = U C S 2 s u p p o r t : T h e M E h a s a p r e f e r e n c e f o r t h e ...
d e f a u l t a l p h a b e t ( d e f i n e d in 3 GPP TS 23 .038 [8 b ]) over UCS2
140 . . . . 0 1 . . = S S S c r e e n i n g I n d i c a t o r : c a p a b i l i t y o f h a n d l i n g ...
of e l l i p s i s n o t a t i o n and phase 2 error h a n d l i n g (0 x1 )
141 ... . ..0. = SoLSA C a p a b i l i t y : The ME does not s u p p o r t SoLSA
142 . . . . . . . 1 = R e v i s i o n l e v e l i n d i c a t o r : U s e d b y a m o b i l e ...
s t a t i o n s u p p o r t i n g R99 or later v e r s i o n s of the p r o t o c o l
143 1 . . . . . . . = P F C f e a t u r e m o d e : M o b i l e s t a t i o n d o e s s u p p o r t ...
BSS packet flow procedures
144 .110 000 . = Extended GEA bits : 0 x30
145 .1.. . . . . = G E A / 2 : E n c r y p t i o n a l g o r i t h m a v a i l a b l e
146 ..1. . . . . = G E A / 3 : E n c r y p t i o n a l g o r i t h m a v a i l a b l e
147 ... 0 .... = GEA /4: Encryption algorithm not available
148 ... . 0 ... = GEA /5: Encryption algorithm not available
149 ... . .0.. = GEA /6: Encryption algorithm not available
150 ... . ..0. = GEA /7: Encryption algorithm not available
151 . . . . . . . 0 = L C S V A c a p a b i l i t y : L C S v a l u e a d d e d l o c a t i o n ...
request notification capability not supported
152 0 . . . . . . . = P S i n t e r - R A T H O f r o m G E R A N t o U T R A N I u m o d e ...
c a p a b i l i t y : PS inter - RAT HO to UTRAN Iu mode not s u p p o r t e d
153 .0.. . . . . = P S i n t e r - R A T H O f r o m G E R A N t o E - U T R A N S 1 m o d e ...
c a p a b i l i t y : P S i n t e r - R A T H O t o E - U T R A N S 1 m o d e n o t ...
supported
154 ..1. . . . . = E M M C o m b i n e d p r o c e d u r e s c a p a b i l i t y : M o b i l e ...
station supports EMM combined procedures
155 ... 1 .... = ISR support : The mobile station supports ISR
156 . . . . 0 . . . = S R V C C t o G E R A N / U T R A N c a p a b i l i t y : S R V C C f r o m ...
UTRAN HSPA or E - UTRAN to GERAN / UTRAN not s u p p o r t e d
157 ... . .1.. = EPC capability : EPC supported
158 . . . . . . 0 . = N F c a p a b i l i t y : M o b i l e s t a t i o n d o e s n o t s u p p o r t ...
the notification procedure
159 . . . . . . . 0 = G E R A N n e t w o r k s h a r i n g c a p a b i l i t y : M o b i l e ...
station does not support GERAN network sharing
160
161 TMSI Status

162 1001 . . . . = E l e m e n t I D : 0 x9 -
163 ... . 000 . = Spare bit ( s ) : 0
164 ... . ...0 = TMSI flag : no valid TMSI a v a i l a b l e
82
T01-11 Gy Interface Online Charging on the P-GW
T01-1101 Real-Time Charging for User Services
Online charging is a real-time mechanism which is an extension of call accounting. This

mechanism enables to apply rules for user rating and control the network resources. So,
depending on the services that are consumed, the user will have a rate or another, including
promotions and discounts. The goal of using online charging is to better personalize the
telecom experience of the customers.
It is very important for Vodafone that this test is approved successfully, since a large part
of its services with Vodafone Pass, are based on the user rating: Video Pass, Music Pass, Maps
Pass, Social Pass. See more details in the Section 4.2.1.
The technical aim doing this test, is to verify that the vUGW, functioning as a P-GW,
supports the volume-based Call Detail Record (CDR) generation function. For it, the scenario
depicted in Figure 5.25 has been recreated in the lab. The elements involved in this scenario
are: MME, vUGW, PCRF, Online Charging Service (OCS).
Figure 5.25: T01-1101 Online Charging Network Scenario.
In order to verify after the tests, that the results obtained are adequate, these are compared
with the behaviour expected by the 3GPP standard represented in the diagram of the Figure
5.26.
With the aim of having a broader view of this scenario, it has been traced three interfaces
instead of one: S11, Gx and Gy. As it is shown in Figure 5.25, S11 is the interface which links the
MME with the vUGW. Through this interface, it will be created the Packet Data Protocol (PDP)
context, necessary to do the rest of the charging test. In addition, as it is wanted to do an
Online Charging test, the traffic is also viewed through the Gy and Gx interfaces. Gy connects
the vUGW with OCS and allows online credit control for service data flow based charging.
Moreover, Gx allows communication between the vUGW and PCRF, and it is also responsible
for the Online Charging, provisioning and removing PCC [1].
Following, the results from the three interfaces are going to be explained: Figure 5.27 has
the information gathered by S11 and Gy, as well as Figure 5.28 has the data from Gy.
83
Figure 5.26: T01-1101 Online Charging Diagram.
84
Before testing the scenario created in the lab, it is necessary to present some conditions
in the NEs involved:
• Check that the LTE/EPC or General Packet Radio Service (GPRS)/UMTS network is
functioning properly
• Check that the vUGW is functioning properly
• Check that the OCS server is communicating with the vUGW properly
• Check that the signature database has been correctly loaded, and there is no related
alarm. To view the status of the database:
DSPSIGNATUREDB:; and DSP PARSERDB:;
• Set up a local address pool and bound it to an APN. To see the binding relationship:
LST POOLBINDAPN:;
• Enable the licenses for online charging and Flow-Based Charging (FBC). To view the
status of the licenses:
LST LICENSESWITCH:;
• Check that the U2000 and vUGW are communicating with each other properly (logged
in to the U2000)
• Create a user tracing task
Once these preset conditions were done, the network was ready to be tested. Figure 5.27
has the traces of this first part of the test. The first and the tenth traces are from the interface
S11. And the rest of the traces are from Gx.
85
86
Figure 5.27: T01-1101 Online Charging - Interface S11.
Next, it is explained the meaning of each of these packets:
[1] The vUGW receives from the MME a Create PDP Context Request through GTP. This
trace has a lot of parameters with data to take into account for the future PDP session.
The content of this package is in the Trace 5.2. Next, the content of this trace will be
explained:
[12-15 ] Inside the GPRS Tunneling Protocol, there is information with regards the mes-
sage type "Create PDP context request", its sequence number, and its lenght.
[16-18 ] The field IMSI, has information about the MCC and MNC, which indicates that
the UE is located in Spain, and that Vodafone España is its mobile operator.
[19-21 ] The Acces Point Name is airtelwap.es, which means that UE has configurated the
device for surfing the Internet.
[22-52 ] QoS has all the parameters which indicates the type of services that are required
for this PDP session. For instance, the traffic class, the delivery order, QoS delay,
maximun and minimum bit rate, and the guaranteed bit rate uplink/donwlink,
among other parameters. All these parameters are sent to receive confirmation
whether they can be used or not.
[53-56 ] One of the last fields refers to the Radio Access Technology (RAT) Type, which
is UMTS Terrestrial Radio Access Network (UTRAN). This radio access network
allows UEs to have access to the UMTS network core using 3G.
[53-56 ] Finally, the last parameter is the User Location Information. As happend for the
IMSI, this field also gather information about the location, adding to the MCC and
MNC information about the geographic location type, and the cell Location Area
Code (LAC).
R code 5.2: T01-1101 Online Charging - Interface S11: Create PDP context Request Trace
1 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
2 * vUGW 3 G - T01 -1101 Real - Time Charging User Services
3 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
4
5 -------------------------------------------------------------
6 Frame : 1 GTP - Create PDP Context Request
7 -------------------------------------------------------------
8
9 Frame 1: 240 bytes on wire (1920 bits ) , 240 bytes ...

captured (1920 bits )
10 Internet Protocol Version 4 , Src : x.x.x.x , Dst : y.y.y.y
11 User Datagram Protocol , Src Port : xxxx , Dst Port : xxxx
12 GPRS Tunneling Protocol
13 Message Type : Create PDP context request (0 x10 )
14 Length : 190
15 Sequence number : 0 x3161
87
16 IMSI : 214019821668983
18 Mobile Network Code ( MNC ) : Vodafone Espana , SAU ...
(01)
19 Access Point Name : AIRTELWAP.ES
20 APN length : 13
21 APN : AIRTELWAP.ES
22 Quality of Service
23 Length : 15
24 Allocation / Retention priority : 1
25 00 .. . . . . = S p a r e : 0
26 ..00 1 . . . = Q o S d e l a y : D e l a y c l a s s 1 ( 1 )
27 . . . . . 0 1 1 = Q o S r e l i a b i l i t y : U n a c k n o w l e d g e d ...
G T P / LLC , A c k RLC , P r o t e c t e d d a t a ( 3 )
28 1001 . . . . = Q o S p e a k : U p t o 2 5 6 0 0 0 o c t / s ( 9 )
29 ... . 0 ... = Spare : 0
30 ... . .001 = QoS precedence : High priority (1)
31 000 . . . . . = S p a r e : 0
32 ... 1 1111 = QoS mean : Best effort (31)
33 011 . . . . . = T r a f f i c c l a s s : I n t e r a c t i v e c l a s s ( 3 )
34 . . . 1 0 . . . = D e l i v e r y o r d e r : W i t h o u t d e l i v e r y ...
o r d e r ( ' no ' ) ( 2 )
35 . . . . . 0 0 1 = D e l i v e r y o f e r r o n e o u s S D U : N o d e t e c t ...
( ' - ') ( 1 )
36 Maximum SDU size : 1500 octets
37 Maximum bit rate uplink : 8000 kbps
38 Maximum bit rate downlink : 8640 kbps
39 0100 . . . . = R e s i d u a l B E R : 1 / 2 5 0 = 4 x 1 0 ^ -3 ( 4 )
40 . . . . 0 1 0 0 = S D U E r r o r r a t i o : 1 / 1 0 0 0 0 = 1 x 1 0 ^ -4 ( 4 )
41 1111 10 .. = Transfer delay : 4000 ms (62)
42 . . . . . . 0 1 = T r a f f i c h a n d l i n g p r i o r i t y : P r i o r i t y ...
level 1 (1)
43 Guaranteed bit rate uplink : 16 kbps
44 Guaranteed bit rate downlink : 64 kbps
45 . . . . 0 0 0 0 = S o u r c e S t a t i s t i c s D e s c r i p t o r : ...
unknown (0)
46 . . . 0 . . . . = S i g n a l l i n g I n d i c a t i o n : N o t o p t i m i s e d ...
signalling traffic
47 Ext Maximum bit rate downlink : 42 Mbps
48 Use the value indicated by the Guaranteed bit ...
rate downlink in octet 13
49 [ Expert Info ( Note / Protocol ) : Use the value ...
indicated by the Guaranteed bit rate ...
downlink in octet 13]
50 [ Use the value indicated by the ...
Guaranteed bit rate downlink in octet ...
13]
88
51 [ Severity level : Note ]

52 [ Group : Protocol ]
53 RAT Type : UTRAN
54 Length : 1
55 RAT Type : UTRAN (1)
56 User Location Information
57 Length : 8
58 Geographic Location Type : 1
60 Mobile Network Code ( MNC ) : Vodafone Espana , SAU ...
(01)
61 Cell LAC : 0 x31c5 (12741)
62 SAC : 0 x9412 (37906)
[2] Coming back to the general traces of the Online Charging, there is the Credit-Control
Request. This packet is the type of: INITIAL_REQUEST.
The content of this package is in the Trace 5.3:
[13-14 ] In this line, it is indicated the ApplicationId, which is 3GPP Gx with a code of 263
for the Session-Id.
[19 ] Inside the Credit-Control Request type, there is the type of message that is, which
has already been mentioned above: INITIAL_REQUEST.
[21-29 ] Here, in QoS Information there is the confirmation of the parameters of the QoS
were previously asked in frame 1. In it, the most importan information is the
APN-Aggregate-Max-Bitrate Up Link (UL) and Down Link (DL).
[30-40 ] The field Called-Station-Id has data with regard the APN needed, that as it was
shown before, it is airtelwap.es. In addition, there is also information about the
Online Charging, where it is said that this field it is enable with its respective code.
Moreover, there is also the code to identify the Access-Network-Charging through
the interface Gx.
[41-45 ] The RAT-Type is UTRAN since the test is being done in 3G
[46-52 ] The Subscription-Id indicates some data from the subscriptions. For instance,
the ID data, the IMSI of the UE, and its location.
R code 5.3: T01-1101 Online Charging - Interface Gx: INITIAL Credit Control Request Trace
1 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
3 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
4
5 -------------------------------------------------------------
6 Frame : 2 - Credit - Control Request - INITIAL_REQUEST
7 -------------------------------------------------------------
89

11 Stream Control Transmission Protocol , Src Port : XXXX , ...
Dst Port : XXXX
12 Diameter Protocol
13 ApplicationId : 3 GPP Gx (16777238)
14 AVP Code : 263 Session - Id
15 AVP : Auth - Application - Id (258) l =12 f = -M - val =3 GPP Gx ...
(16777238)
16 Auth - Application - Id : 3 GPP Gx (16777238)
17 AVP : CC - Request - Type (416) l =12 f = -M - ...
val = INITIAL_REQUEST (1)
18 AVP Code : 416 CC - Request - Type
19 CC - Request - Type : INITIAL_REQUEST (1)
20 AVP : CC - Request - Number (415) l =12 f = -M - val =0
21 AVP : QoS - Information (1016) l =44 f = VM - vnd = TGPP
22 AVP Code : 1016 QoS - Information
23 QoS - Information : ...
0000041180000010000028 af007a12000000041080000010 . . .
24 AVP : APN - Aggregate - Max - Bitrate - UL (1041) l =16 ...
f =V - - vnd = TGPP val =8000000
25 AVP Code : 1041 APN - Aggregate - Max - Bitrate - UL
26 APN - Aggregate - Max - Bitrate - UL : 8000000
27 AVP : APN - Aggregate - Max - Bitrate - DL (1040) ...
l =16 f =V - - vnd = TGPP val =42000000
28 APN - Aggregate - Max - Bitrate - DL : 42000000
29 AVP : Default - EPS - Bearer - QoS (1049) l =88 f =V - - vnd = TGPP
30 AVP : Called - Station - Id (30) l =20 f = -M - val = airtelwap.es
31 AVP Code : 30 Called - Station - Id
32 Called - Station - Id : airtelwap.es
33 AVP : Online (1009) l =16 f = VM - vnd = TGPP ...
val = ENABLE_ONLINE (1)
34 AVP Code : 1009 Online
35 Online : ENABLE_ONLINE (1)
36 AVP : Access - Network - Charging - Identifier - Gx (1022) ...
l =28 f = VM - vnd = TGPP
37 AVP Code : 1022 ...
Access - Network - Charging - Identifier - Gx
38 Access - Network - Charging - Identifier - Gx : ...
000001 f7c0000010000028afb3dbb50d
39 AVP : ...
Access - Network - Charging - Identifier - Value (503) ...
l =16 f = VM - vnd = TGPP val = b3dbb50d
40 AVP Code : 503 ...
Access - Network - Charging - Identifier - Value
90
41 AVP : RAT - Type (1032) l =16 f =V - - vnd = TGPP val = UTRAN (1000)
42 AVP Code : 1032 RAT - Type
43 AVP Length : 16
44 AVP Vendor Id : 3 GPP (10415)
45 RAT - Type : UTRAN (1000)
46 AVP : Subscription - Id (443) l =44 f = -M -
47 Subscription - Id : ...
000001 c 2 4 0 0 0 0 0 0 c 0 0 0 0 0 0 0 1 0 0 0 0 0 1 b c 4 0 0 0 0 0 1 7 3 2 3 1 3 4 3 0 . . .
48 AVP : Subscription - Id - Data (444) l =23 f = -M - ...
val =214019821668983
49 Subscription - Id - Data : 214019821668983
50 IMSI : 214019821668983
52 Mobile Network Code ( MNC ) : Vodafone ...
Espana , SAU (01)
53 Padding : 00
[3] The next trace is a Credit-Control Answer which comes from the PCRF to the vUGW.
This packet is also an INITIAL_REQUEST type, and it is the response of packet 2. Inside,
there are allocated information about the charging rules that are going to be applied
during the PDP session.
[17 ] This line refers to the ApplicationId that is being used, which is 3GPP Gx.
[20 ] Result-Code, this is the resolution of the request made by package number 2. As
it is possible to see, this request has been accepted, since the resulting message
which was obtained is: DIAMETER_SUCCESS.
In the following lines of this trace, there are the charging rules that have been installed
after accepted the request of package 2. Below is explained one of these charging rules,
to better understand what kind of information they may contain:
[27-40 ] Each Charging-Rule-Install has its own code, in this case: 2345. Inside this packet,
the most important parameter to keep into account is the Charging-Rule-Name,
which in this case is: em_im_wap. This name it is registered in the configuration
of the nodes, so when em_im_wap appears, each NE looks in its configuration to
know what rules correspond to this name. After, these rules will be applied to the
rating of the user.
R code 5.4: T01-1101 Online Charging - Interface Gx: INITIAL Credit Control Answer Trace
1 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
3 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
4
91
5 -------------------------------------------------------------
6 Frame : 3 - Credit - Control Answer - INITIAL_REQUEST
7 -------------------------------------------------------------
8

10 Internet Protocol Version 4 , Src : X.X.X.X , Dst : Y.Y.Y.Y
11 Stream Control Transmission Protocol , Src Port : XXXX , ...
Dst Port : XXXXX
13 Version : 0 x01
14 Length : 764
15 Flags : 0 x40 , Proxyable
16 Command Code : 272 Credit - Control
17 ApplicationId : 3 GPP Gx (16777238)
18 AVP : Session - Id (263)
19 AVP : Auth - Application - Id (258) l =12 f = -M - val =3 GPP Gx ...
(16777238)
20 AVP : Result - Code (268) l =12 f = -M - ...
val = DIAMETER_SUCCESS (2001)
val = INITIAL_REQUEST (1)
23 AVP : Bearer - Control - Mode (1023) l =16 f = VM - vnd = TGPP ...
val = UE_NW (2)
24 AVP : Event - Trigger (1006) l =16 f = VM - vnd = TGPP ...
val = PLMN_CHANGE (4)
25 AVP : Event - Trigger (1006) l =16 f = VM - vnd = TGPP ...
val = REVALIDATION_TIMEOUT (17)
26 AVP : Charging - Rule - Install (1001) l =36 f = VM - vnd = TGPP
28 AVP Code : 2345 Charging - Rule - Install
29 AVP Flags : 0 xc0
30 AVP Length : 36
32 Charging - Rule - Install : ...
000003 e d c 00 0 00 1 50 0 00 2 8a f 65 6 d5 f 69 6 d 5f 7 76 1 70 0
33 AVP : Charging - Rule - Name (8905) l =21 f = VM - ...
vnd = TGPP val = em_im_wap
34 AVP Code : 1005 Charging - Rule - Name
35 AVP Flags : 0 xc0
36 AVP Length : 21
38 Charging - Rule - Name : 656 d5f696d5f776170
39 [ Charging - Rule - Name : em_im_wap ]
40 Padding : 000000
92

46 AVP : Online (1009) l =16 f = VM - vnd = TGPP ...
val = ENABLE_ONLINE (1)
47 AVP : Offline (1008) l =16 f = VM - vnd = TGPP ...
val = ENABLE_OFFLINE (1)
48 AVP : QoS - Information (1016) l =44 f = VM - vnd = TGPP
49 AVP : Revalidation - Time (1042) l =16 f = VM - vnd = TGPP ...
val = Mar 20 , 2018 18:36:30 UTC
50 AVP : Default - EPS - Bearer - QoS (1049) l =88 f = VM - vnd = TGPP
51 AVP : Supported - Features (628) l =56 f =V - - vnd = TGPP
52 AVP : Bearer - Usage (1000) l =16 f =V - - vnd = TGPP ...
val = GENERAL (0)
53 AVP : Origin - Host (264) l =31 f = -M - val = pcrf.vodafone.com
54 AVP : Origin - Realm (296) l =20 f = -M - val = vodafone.com
[10] This trace is a GTP respons with a Create PDP Context Response. This packect indicates
that the PDP contect has been created.
[12-19 ] In the GPRS Tunneling Protocol field, there is the information about the message
type: Create PDP context response. In addition, in the following lines, it is also
reflected that the request was accepted: Request accepted
[20 ] The Charging ID indicates what pricing rules should be applied for this UE. This
code is searched in the configuration of the nodes and the charge is applied.
[22-48 ] The last line of Quality of Service has the data which has been requested in
previous packets. Here, there are accepted parameters as: QoS delay, Traffic class,
Delivery order, Maximum bit rate UL/DL and Transfer delay, among others.
R code 5.5: T01-1101 Online Charging - Interface S11: Create PDP context Response Trace
1 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
3 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
4
5 -------------------------------------------------------------
6 Frame : 10 - Credit - Control Respons - INITIAL_REQUEST
7 -------------------------------------------------------------
8
93
11 User Datagram Protocol , Src Port : xxxx , Dst Port : xxxx

12 GPRS Tunneling Protocol
13 Flags : 0 x32
14 Message Type : Create PDP context response (0 x11 )
15 Length : 121
16 Sequence number : 0 x3161
17 Cause : Request accepted (128)
18 Reordering required : False
19 Recovery : 252
20 Charging ID : 0 xb3dbb50d
21 Protocol configuration options
22 Quality of Service
23 Length : 15
24 Allocation / Retention priority : 1
25 00 .. . . . . = S p a r e : 0
26 ..00 1 . . . = Q o S d e l a y : D e l a y c l a s s 1 ( 1 )
27 . . . . . 0 1 1 = Q o S r e l i a b i l i t y : U n a c k n o w l e d g e d ...
G T P / LLC , A c k RLC , P r o t e c t e d d a t a ( 3 )
28 1001 . . . . = Q o S p e a k : U p t o 2 5 6 0 0 0 o c t / s ( 9 )
29 ... . 0 ... = Spare : 0
30 ... . .001 = QoS precedence : High priority (1)
31 000 . . . . . = S p a r e : 0
32 ... 1 1111 = QoS mean : Best effort (31)
33 011 . . . . . = T r a f f i c c l a s s : I n t e r a c t i v e c l a s s ( 3 )
34 . . . 1 0 . . . = D e l i v e r y o r d e r : W i t h o u t d e l i v e r y ...
o r d e r ( ' no ' ) ( 2 )
35 . . . . . 0 0 1 = D e l i v e r y o f e r r o n e o u s S D U : N o d e t e c t ...
( ' - ') ( 1 )
36 Maximum SDU size : 1500 octets
37 Maximum bit rate uplink : 8000 kbps
38 Maximum bit rate downlink : 8640 kbps
39 0100 . . . . = R e s i d u a l B E R : 1 / 2 5 0 = 4 x 1 0 ^ -3 ( 4 )
40 . . . . 0 1 0 0 = S D U E r r o r r a t i o : 1 / 1 0 0 0 0 = 1 x 1 0 ^ -4 ( 4 )
41 1111 10 .. = Transfer delay : 4000 ms (62)
42 . . . . . . 0 1 = T r a f f i c h a n d l i n g p r i o r i t y : P r i o r i t y ...
level 1 (1)
43 Guaranteed bit rate uplink : 0 kbps (255)
44 Guaranteed bit rate downlink : 0 kbps (255)
45 . . . . 0 0 0 0 = S o u r c e S t a t i s t i c s D e s c r i p t o r : ...
unknown (0)
46 . . . 0 . . . . = S i g n a l l i n g I n d i c a t i o n : N o t o p t i m i s e d ...
signalling traffic
47 Ext Maximum bit rate downlink : 42 Mbps
48 Use the value indicated by the Guaranteed bit ...
rate downlink in octet 13
49 Bearer Control Mode
94
Once the PDP context has been established, the user can begin to browse the Internet
and consume data. These data packages are represented in black in Figure 5.27.
As soon as the consumption has begun, UPDATE_REQUEST packets are sent through the
Gy interface, from the vUGW to the OCS, and vice versa. This kind of traces have the aim of
control consumption and correctly charge the user. Each 20MB consumed by the user, the
vUGW request another 20MB to OCS.
Notice that the assigned value of 20MB is not a random value. Prior to its application,
several tests were carried out until the most adequate value was found. On one hand, if a
value is set too small, the number of signalling packets between the nodes could saturate the
network. On the other hand, if the value is too large, this means that customers cannot be
priced accurately, making them pay for data they have not yet consumed.
This exchange of packages, updating the consumption, occurs until the user reaches his
data CAP (restriction imposed on the data transfer over the network). At that moment, the
speed of the UE decreases, from the maximum speed contracted to 256 kbps (e.g. Bandwidth
throttling).
All this new packet flow is represented in Figure 5.28. The first two packages are the same
as those received through the Gx interface in traces 5.3, and 5.4, so they will not be explained
again. However, there are two new traces, which are the UPDATE_REQUEST and TERMINA-
TION_REQUEST, which will be explained in detail below. Note that these traces are repeated
twice since one is Credit-Control-Request, and the other is its answer. Considering that the
answers have practically the same information as the requests, it will be explained only the
Credit Control Request of both traces UPDATE_REQUEST and TERMINATION_REQUEST.
95
96
Figure 5.28: T01-1101 Online Charging - Interface Gy.
[3 ] Inside this packet there is information with regards the Credit Control Request -
UPDATE_REQUEST. The information of this package is gathered in the Trace 5.6:
[16-17 ] The Command Code and ApplicationId, indicates that the acction in this packet
is to control the credit of the user.
[21 ] Here it is possible to distinguish that the trace goes from the GGSN (inside the
vUGW) to the OCS.
[28 ] With this line, it is confirmed that this is a trace of the type: Contro Credit
-Request, with a value of: UPDATE_REQUEST
[20 ] The Called-Station-Id shows that the APN used is: airtelwap.es
[35- 47 ] Inside the Multiple-Service-Credit-Control there is a field called Rating-Group.
As it was explained in previous traces, Vodafone has a service called "Vodafone
Pass". This service allows users to consume all the data they want of some services
(e.g. video, music, maps, social...) paying a fixex price. Therefore Vodafone has to
be able to identify which traffic it is being consuming by the user. For it, is used
the Rating-Group fiel previously mentioned, where there is a code to identify the
type of traffic. In this case, the traffic that the UE is generating is video.
R code 5.6: T01-1101 Online Charging - Interface Gy: UPDATE Credit Control Request Trace
1 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
3 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
4
5 -------------------------------------------------------------
6 Frame : 3 Interface Gy - Credit Control Request - ...
UPDATE_REQUEST
7 -------------------------------------------------------------
8

11 Transmission Control Protocol , Src Port : 111 , Dst Port : ...
222 , Seq : 913 , Len : 760
13 Version : 0 x01
14 Length : 760
15 Flags : 0 xc0 , Request , Proxyable
17 ApplicationId : Diameter Credit Control Application (4)
18 Hop - by - Hop Identifier : 0 x0007f8b5
19 End - to - End Identifier : 0 xc6ea9693
20 [ Answer In : 4]
21 AVP : Session - Id (263) l =64 f = -M - ...
val = ggsn - OCS ;850;460;5 d4a -202
97
22 AVP : Origin - Host (264) l =32 f = -M - val = ggsn - OCS

24 AVP : Destination - Host (293) l =13 f = -M - val = OCG21
25 AVP : Destination - Realm (283) l =20 f = -M - val = vodafone.com
26 AVP : Auth - Application - Id (258) l =12 f = -M - ...
val = Diameter Credit Control Application (4)
27 AVP : Service - Context - Id (461) l =38 f = -M - ...
val = version 2.clci.ipc@voda fone.com
val = UPDATE_REQUEST (2)
31 AVP : User - Name (1) l =36 f = -M - ...
val =3763243 @post.wap.nopi.es
32 AVP : Origin - State - Id (278) l =12 f = -M - val =13671216
33 AVP : Event - Timestamp (55) l =12 f = -M - val = Jan 15 , 2014 ...
09:39:24 UTC
35 AVP : Multiple - Services - Credit - Control (456) l =60 f = -M -
36 AVP Code : 456 Multiple - Services - Credit - Control
37 AVP Flags : 0 x40
38 AVP Length : 60
39 Multiple - Services - Credit - Control : ...
001 b5400 000800 0b040 000c00 07d000 107 . . .
40 AVP : Requested - Service - Unit (437) l =8 f = -M -
41 AVP : Rating - Group (432) l =12 f = -M - val =2000
42 AVP Code : 235 Rating - Group
44 AVP Length : 12
45 Rating - Group : 432
46 AVP : Framed - IP - Address (8) l =12 f = -M - val =100 .88.128.73
47 AVP : 3 GPP - IMSI (1) l =27 f = VM - vnd = TGPP ...
val =214010100057808
48 AVP : 3 GPP - Charging - Id (2) l =16 f = VM - vnd = TGPP ...
val =05 c3436b
49 AVP : 3 GPP - PDP - Type (3) l =16 f = VM - vnd = TGPP val = IPv4 (0)
50 AVP : 3 GPP - GPRS - Negotiated - QoS - Profile (5) l =35 f = VM - ...
vnd = TGPP val =08 -44060002666700026667
51 AVP : 3 GPP - SGSN - Address (6) l =16 f = VM - vnd = TGPP ...
val =62 .87.113.11
52 AVP : 3 GPP - GGSN - Address (7) l =16 f = VM - vnd = TGPP ...
val =62 .87.113.12
53 AVP : 3 GPP - IMSI - MCC - MNC (8) l =17 f = VM - vnd = TGPP val =21401
54 AVP : 3 GPP - GGSN - MCC - MNC (9) l =17 f = VM - vnd = TGPP val =21401
55 AVP : 3 GPP - NSAPI (10) l =13 f = VM - vnd = TGPP val =5
56 AVP : 3 GPP - Selection - Mode (12) l =13 f = VM - vnd = TGPP val =0
98
57 AVP : 3 GPP - Charging - Characteristics (13) l =16 f = VM - ...

vnd = TGPP val =0 A00
58 AVP : User - Location - Information (267) l =25 f = VM - ...
vnd = Vodafone val =8212 f410011a12f410045a8b02
59 AVP : Radio - Access - Technology (260) l =16 f = VM - ...
vnd = Vodafone val = Unknown (6)
60 AVP : Bearer - Usage (1000) l =16 f = VM - vnd = TGPP ...
val = GENERAL (0)
61 AVP : 3 GPP - IMEISV (20) l =28 f = VM - vnd = TGPP ...
val =3577370571644201
62 AVP : Vodafone - Rulebase - Id (262) l =15 f = VM - ...
vnd = Vodafone val = wap
Once the PDP session has ended, the vUGW tells to the OCS not to charge more data to
the user. For this purpose the fifth and last packet of this sequence is sent:
[5 ] Credit Control Request - TERMINATION_REQUEST. The content of this package is in

the Trace 5.7:
[29 ] Here, the parameters shown the type of message was sent Control Credit Request:
TERMINATION_REQUEST
[30 ] Inside this line, there is information about the Called-Station-Id, which, of course
is again: airtelwap.es
[36 ] The Termination-Cause has the value of DIAMETER_LOGOUT, which means that
the PDP session has finished and it is time to logout to the session.
[46-63 ] The field Used-Service gathers information with regards the Total Credit con-
sumed, which is 33640 MB or 4,2 GB (8368 in hexadecimal). In particular, the data
which have been consumed is 1,76 GB for UL (3700 in hexadecimal), and 2,25 GB
for DL (4668 in hexadecimal).
The rest of the frame, has information about the parameters that were agreed at the
beginning of the PDP session and now must be eliminated.
R code 5.7: T01-1101 Online Charging - Interface Gy: TERMINATION Credit Control Request
Trace
1 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
3 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
4
5 -------------------------------------------------------------
6 Frame : 5 Interface Gy - Credit Control Answer - ...
UPDATE_REQUEST
7 -------------------------------------------------------------
8
99

10 Ethernet II , Src : Send_00 (20:53:45:4 e :44:00) , Dst : ...
Receive_00 (20:52:45:43:56:00)
12 Transmission Control Protocol , Src Port : 111 , Dst Port : ...
222 , Seq : 1921 , Len : 880
14 Version : 0 x01
15 Length : 880
16 Flags : 0 xc0 , Request , Proxyable
18 ApplicationId : Diameter Credit Control Application (4)
19 Hop - by - Hop Identifier : 0 x0007f8c1
20 End - to - End Identifier : 0 xc6ea969f
21 [ Answer In : 6]
22 AVP : Session - Id (263) l =64 f = -M - ...
val =0018 - sessmgr.ggsn109 - OCS ;86000;4060;52 d64a -1202
23 AVP : Origin - Host (264) l =32 f = -M - ...
val =0018 - sessmgr.ggsn109 - OCS
25 AVP : Destination - Host (293) l =13 f = -M - val = OCG21
26 AVP : Destination - Realm (283) l =20 f = -M - val = vodafone.com
27 AVP : Auth - Application - Id (258) l =12 f = -M - ...
val = Diameter Credit Control Application (4)
28 AVP : Service - Context - Id (461) l =38 f = -M - ...
val = version 2.clci.ipc@voda fone.com
val = TERMINATION_REQUEST (3)
32 AVP : User - Name (1) l =36 f = -M - ...
val =34610512433 @post.wap.nopi.es
33 AVP : Origin - State - Id (278) l =12 f = -M - val =1386671216
34 AVP : Event - Timestamp (55) l =12 f = -M - val = Jan 15 , 2014 ...
09:39:39 .00 UTC
36 AVP : Termination - Cause (295) l =12 f = -M - ...
val = DIAMETER_LOGOUT (1)
37 AVP : Multiple - Services - Credit - Control (456) l =152 f = -M -
38 AVP Code : 456 Multiple - Services - Credit - Control
40 AVP Length : 152
41 Multiple - Services - Credit - Control : ...
001 be40050001a44000c0000f001a5 . . .
42 AVP : Used - Service - Unit (446) l =84 f = -M -
43 AVP Code : 446 Used - Service - Unit
100

45 AVP Length : 84
46 Used - Service - Unit : ...
001 a44000c0000f001a5400000100000 . . .
47 AVP : CC - Time (420) l =12 f = -M - val =15
48 AVP : CC - Total - Octets (421) l =16 f = -M - ...
val =8368
49 AVP Code : 421 CC - Total - Octets
51 AVP Length : 16
52 CC - Total - Octets : 8368
53 AVP : CC - Input - Octets (412) l =16 f = -M - ...
val =3700
54 AVP Code : 412 CC - Input - Octets
56 AVP Length : 16
57 CC - Input - Octets : 3700
58 AVP : CC - Output - Octets (414) l =16 ...
f = -M - val =4668
59 AVP Code : 414 CC - Output - Octets
61 AVP Length : 16
62 CC - Output - Octets : 4668
63 AVP : CC - Service - Specific - Units (417) ...
l =16 f = -M - val =0
64 AVP : Rating - Group (432) l =12 f = -M - val =2000
65 AVP : Vodafone - Reporting - Reason (261) l =16 ...
f = VM - vnd = Vodafone val = FINAL (2)
66 AVP : Vodafone - Time - Of - First - Usage (263) l =16 ...
f = VM - vnd = Vodafone val = Jan 15 , 2014 ...
09:39:24 UTC
67 AVP : Vodafone - Time - Of - Last - Usage (264) l =16 ...
f = VM - vnd = Vodafone val = Jan 15 , 2014 ...
09:39:34 UTC
68 AVP : Framed - IP - Address (8) l =12 f = -M - val =100 .88.128.73
69 AVP : 3 GPP - IMSI (1) l =27 f = VM - vnd = TGPP ...
val =214010100057808
70 AVP : 3 GPP - Charging - Id (2) l =16 f = VM - vnd = TGPP ...
val =05 c3436b
71 AVP : 3 GPP - PDP - Type (3) l =16 f = VM - vnd = TGPP val = IPv4 (0)
72 AVP : 3 GPP - GPRS - Negotiated - QoS - Profile (5) l =35 f = VM - ...
vnd = TGPP val =08 -44060002666700026667
73 AVP : 3 GPP - SGSN - Address (6) l =16 f = VM - vnd = TGPP ...
val =62 .87.113.11
74 AVP : 3 GPP - GGSN - Address (7) l =16 f = VM - vnd = TGPP ...
val =62 .87.113.12
75 AVP : 3 GPP - IMSI - MCC - MNC (8) l =17 f = VM - vnd = TGPP val =21401
101
76 AVP : 3 GPP - GGSN - MCC - MNC (9) l =17 f = VM - vnd = TGPP val =21401
77 AVP : 3 GPP - NSAPI (10) l =13 f = VM - vnd = TGPP val =5
78 AVP : 3 GPP - Session - Stop - Indicator (11) l =13 f = VM - ...
vnd = TGPP val =\377
79 AVP : 3 GPP - Selection - Mode (12) l =13 f = VM - vnd = TGPP val =0
80 AVP : 3 GPP - Charging - Characteristics (13) l =16 f = VM - ...
vnd = TGPP val =0 A00
81 AVP : User - Location - Information (267) l =25 f = VM - ...
vnd = Vodafone val =8212 f410011a12f410045a8b02
82 AVP : Radio - Access - Technology (260) l =16 f = VM - ...
vnd = Vodafone val = Unknown (6)
83 AVP : Bearer - Usage (1000) l =16 f = VM - vnd = TGPP ...
val = GENERAL (0)
84 AVP : 3 GPP - IMEISV (20) l =28 f = VM - vnd = TGPP ...
val =3577370571644201
85 AVP : Vodafone - Rulebase - Id (262) l =15 f = VM - ...
vnd = Vodafone val = wap
102
5G Testing
As it was mentioned before, data core functionalities for 5G are still under the definition
as the 3GPP standard is not ready yet. This is why this test has been conducted using the
commercial standard NSA approved by 3GPP. So, 5G testing was more focused on the RAN
testing in order to test the low latency and the high speed that 5G can offer.
Therefore, an infrastructure of a 4G network was needed for traffic control and manage-
ment during the test. So the terminals, as well as the base stations, had to establish a dual
connectivity to 4G and 5G networks at the same time. The subbands which were used during
data transmission are 3,7 GHz and 6 GHz.
The first step was to set up the real scenario for testing. After the setup, several tests were
made until finding the location that was most optimate for the transmission. Once this area
was found, the CPE was placed there, and the first data transmissions were made in 5G with
NSA.
The best results obtained in these tests are reflected in Figures 5.29 and 5.30, where
the results are shown with respect to the throughput, as well as the transmission speed,
respectively.
In the case of the Figure 5.29, the behaviors of some protocols, such as Physical Layer
(PHY), Media Access Control (MAC), Radio link control (RLC), and Packet Data Convergence
Protocol (PDCP), are represented. The best values obtained were 480,000 Kbps for acMAC,
RLC, and PDCP, and 520,000 Kbps for PHY protocol.
Furthermore, in the speed measurements reflected in Figure 5.30, a latency of just 12 ms
was obtained, with a data upload speed of 83,47 Mbps.
The results showed that discharge speeds were reached which multiplied by 8 the standard
speeds of 4G. All the improvements that were made, will be incorporated into the future
commercial deployment of the new Vodafone 5G technology.
Figure 5.30: Speed measurements in 5G.
103
Figure 5.29: Total throughput in 5G measurements.
104
6
C ONCLUSION AND F UTURE W ORK
This chapter concludes the work done in this master thesis and gives an overview of possible
future work.
6.1 C ONCLUSIONS
In this master thesis, the current challenges that mobile operators in Spain are facing and its
possible solutions were addressed.
The first goal was to provide enough arguments to explain that the best way to renew
Vodafone’s data core network was through virtualization. These arguments were supported
by market analysis and validations, which showed that the market situation needed this
solution.
In addition, the importance of having a robust project management to control any unfore-
seen events and changes has been reflected. Thanks to PMP methodology the project was
executed properly according to scope, time, cost and quality initially defined. Furthermore,
thanks to this planning, the reader will have been able to make a broad idea of which are the
activities and times schedules necessary to carry out a project of this type.
The second goal of this master thesis was to provide a technical solution by creating a
testbed line with which to test different phases of this project until finding the most optimal
solution. Later this solution would be incorporate to all production lines of Vodafone.
For this purpose, firstly, a discussion on different connectivity design was addressed in
order to solve any network limitation or constraint. For this topic, the number of IPU and
APU VMs were evaluated. Due to the network has limitations, the number of neighbours was
reduced, placing fewer virtual machines. This decreased the throughput inside the network,
but even so, the final network implementation has enough capacity to face all the data traffic
forecast for the coming years.
It should also be noted that the connectivity option used in the case of the IPU VMs
was the one which had a common VLAN which joins routers and the IPU, using OSPF. In
addition, for the APU VMs the option selected was the one which the service IP addresses
was announced directly by OSPF and do not use any BGP session.
During the installation and configuration stage, the main difficulty was the troubleshoot-
ing. Both the installation and the configuration were made following instructions from
105
CHAPTER 6. CONCLUSION AND FUTURE WORK
Huawei manuals. However, at the time when there was a failure, there was no manual to
follow, and therefore it has had to do a thorough study to find the root of the problem. This
stage was probably the one that caused a higher delay in the project execution. In fact, the
PDM of the project plan had to be modified several times in order to accommodate the delays
in building a new plan.
Due to the fact that the main objective of this master thesis is to optimize the data core
network, one of the most important topics was the SW validation. During this stage, it was
aimed to validate the NFVs correct functioning. After validating it, it was possible to verify
that the network reacted in a more efficient way to scenarios where before there was not such
a good performance.
Concerning the results for the SW validation, 60% of the tests were successful from the
beginning and just for a 25% cases were needed to do troubleshooting. In the case of the 5G
scenario, the results were quite successful, although it was not obtained the maximum bitrate
expected. This was due to the fact that the 3GPP standard is not yet finished so there are
many improvements to face during the following months before reaching the target results.
6.2 F UTURE W ORK

It could be interesting to continue working on the virtualization of other NEs, such as PCRF,
OCS, databases as HSS, and RANs, among other elements. Doing this, it would be possible to
validate these components and integrate it with the rest of the network already virtualized.
Therefore, having the whole architecture virtualized it would be possible to facilitate the
complete introduction of the NSA architectures in a close future.
Keeping in mind that the future is 5G networks, might be exciting to focus new research
on developing new NEs, compatible with NSA and SA, to optimize the operation of these
architectures. So far, there are some elements that are already created by Huawei, such as
CGW and DGW, already shown in this theses. However, there is still a need to develop new
elements to compose the complete 5G network in SA.
Another idea that could be interesting to work on, is to go deeper into MEC. Reducing
latency in applications more and more is the future, and MEC is one of the best tools to
achieve this goal. Therefore, it could be done research to specify how it is the best way to use
MEC in current networks, as well as in NSA and SA.
Finally, Slicing is also another subject with which future research could be carried out.
Although this is a concept that is already quite clear, there is still much to investigate and
improve, especially when it comes to entering this concept into the data core networks.
106
A
A BBREVIATIONS
PCRF Policy and Charging Resource Function
PCC Policy and Charging Control
EPC Evolved Packet Core
vEPC Virtual Evolved Packet Core
EPS Evolved Packet System
vEPS Virtual Evolved Packet Core
VNF Virtual Network Functions
VNFI Virtual Network Functions Infrastructure
NFVO NFV Orchestrator
VNFM VNF Manager
HLD High Level Design
LLD Low Level Design
vUGW Virtual Unified Packet Gateway
UGW Unified Packet Gateway
vUSN Virtual Unified Serving Node
VM Virtual Machine
VLAN Virtual Local Area Network
OSPF Open Shortest Path First
107
APPENDIX A. ABBREVIATIONS
ECMP Equal-Cost Multi-Path
IPU I/O Processing Unit
APU Assambly-Service Process Unit
vNIC Virtual Network Interface Controller
HW Hardware
SW Software
IP Internet Protocol
BFD Bidirectional Forwarding Detection
BGP Border Gateway Protocol
APN Access Point Name
GPRS General Packet Radio Service
GTP GPRS Tunneling Protocol
vBOM Virtual Bill of Materials
pBOM Physical Bill of Materials
FOA First of All First Offial Application
MEC Mobile Edge Computing
PDM Precedence Diagram Method
MNO Mobile Network Operator
MVNO Mobile Virtual Network Operator
WO Web Optimization
VO Video Optimizatin
TMF Traffic Management Function
LTE Long Term Evolution
DPI Deep Packet Inspection
108
vMSP Virtual Multi-Services Platform
MSP Multi-Services Platform
TCP Transmission Control Protocol
MSE Mobile Subscriber Equipement
vMSE Virtual Mobile Subscriber Equipement
PB Petabytes
NFV Network Function Virtualization
NFVI Network Function Virtualization Infrastructure
OTT Over the Top
CAPEX Capital Expenditures
OPEX Operating Expenses
SDN Software Defined Networking
SDNC Software Defined Network Controller
NSA Non Stand-Alone
SA Stand-Alone
GA General Available
ES Early Start
LS Late Start
EF Early Finish
LF Late Finish
PMP Project Management Professional
E2E End-to-End
vOSMU Virtual OSS Self-Maintenance Unit
OSS Operation Support System
109
BSS Business Support System
MPLS Multiprotocol Label Switching
E/W East-West
RFS Ready for Service
NE Network Element
VPN Virtual Private Network
VRF VPN Routing and Forwarding
CSM Cloud Service Manager
3GPP Third Generation Partnership Project
FTP File Transfer Protocol
CGW Centralized Gateway
DGW Distributed Gateway
CPU Central Processing Unit
vCPU Virtual Central Processing Unit
RAM Random Access Memory
SAN Storage Area Network
MME Mobility Management Entity
SGSN Serving GPRS Support Node
GGSN Gateway GPRS Support Node
P-GW Packet Data Network Gateway
S-GW Serving Gateway
GSM Global System for Mobile comunications
UMTS Universal Mobile Telecommunications System
LTE Long Term Evolution
110
VIM Virtualized Infrastructure Manager
FCAPS Fault, Configuration, Accounting, Performance, and Security
MANO Management and Orchestration
SFF Service Fulfillment Functions
SAF Service Assurance Functions
TAI Tracking Area Identity
LAI Location Area Identity
MSC Mobile switching center
UE User Equipment
VLR Visitor Location Register
CS Circuit Switching
PS Packet Switching
SMS Short Message Service
IMSI International Mobile Subscriber Identity
MCC Mobile Country Code
MNC Mobile Network Code
CSFB CS-Fallback
HSS Home Subscriber Server
MML Man-Machine Language
EBI Evidence-Based Intervention
PCC Policy and Charging Control
TEID Tunnel Endpoint Identifier
SCTP Stream Control Transmission Protocol
GUTI Global Unique Temporary Identityl
111
M-TMSI M Temporary Mobile Subscriber Identity
TMSI Temporary Mobile Subscriber Identity
ESM EPS Session Management
NAS Non-Access Stratum
PDN Packet Data Network
SRVCC Single Radio Voice Call Continuity
SIM Subscriber Identity Module
HLR Home Location Register
CPE Customer Premises Equipment
CDR Call Detail Record
OCS Online Charging Service
PDP Packet Data Protocol
FBC Flow-Based Charging
QoS Quality of Service
RAT Radio Access Technology
RAN Radio Acces Network
UTRAN UMTS Terrestrial Radio Access Network
LAC Location Area Code
DL Down Link
UL Up Link
MIMO Multiple Input Multiple Output
CUPS Control Plane - User Plane Separation
IoT Internet of Things
OMU Operating and Management Unit
112
SDU Session Data Unit
SPU Service Processing Unit
GBU Gb Interface Processing Unit
SIU Signal Interface Process Unit
OAM OWM Operation And Maintainance
SFMU Service Function Management Unit
L3VPN Layer 3 Virtual Private Networks
LUN Logical Unit Number
vCD vCloud Director
EBITDA Earnings Before Interests, Taxes, Depreciations and Amortizations
VAS Value-Added Service
PHY Physical Layer
MAC Media Access Control
RLC Radio link control
PDCP Packet Data Convergence Protocol
113
B
A DDITIONAL I NFORMATION
Figure B.1: P3 Overal Results for Voice - Drivetest [3].
115
APPENDIX B. ADDITIONAL INFORMATION
Figure B.2: P3 Overal Results for Data in Cities - Drivetest [3].
116
Figure B.3: P3 Overal Results for Data in Towns - Drivetest [3].
117
Figure B.4: P3 Overal Results for Data on Roads - Drivetest [3].
118
C
C ASES L IST
vUSN 3G
T01 Basic Services
T01-01 IP Bearer Services
T01-0101 Web Services
T02 Mobility Management
T02-01 Attach
T02-0101 GPRS Attach Initiated by a Normal Subscriber Using P-TMSI
T02-02 Detach
T02-0201 Detach Initiated by Switching Off a Normal Subscriber
T02-0202 Detaching a Normal Subscriber from the SGSN
T02-03 Service Request
T02-0301 Service Request of Signaling Type
T02-0302 Service Request of Data Type
T02-04 Paging
T02-0401 Paging Initiated by Downlink Signaling
T02-0402 Paging Initiated by Downlink Data
T02-05 Serving RNC Relocation
T02-0501 Intra SGSN Soft Handover
T03 Security Management
T03-01 Authentication
T03-0101 USIM Authentication
T03-02 Subscriber Data and Signaling Encryption
T03-0201 USIM Subscriber Encryption
T03-0202 SIM Subscriber Encryption
T03-03 Data Integrality
T03-0301 Data Integrality
119
APPENDIX C. CASES LIST
T03-04 Subscriber Identity

T03-0401 Obtaining USIM Subscriber ID
T03-0402 Obtaining SIM Subscriber ID
T03-05 Flexible Authentication Based on Subscriber Group
T03-06 3G 1/N IMEI Check
T03-0601 1/N IMEI Check During 3G Attach
T04 Subscriber Data Management
T04-01 Inserting Mobile Subscriber Data
T04-02 Modifying Mobile Subscriber Data
T04-0201 Modifying Mobile Subscriber Data
T04-03 Purge
T04-0301 purge
T05 Session Management
T05-01 PDP Context Activation
T05-0101 PDP Context Activation with a Dynamic Address Initiated by a
Subscriber
T05-02 PDP Context Deactivation
T05-0201 PDP Context Deactivation Initiated by a Subscriber
T05-0202 PDP Context Deactivation Initiated by SGSN
T05-03 PDP Context Modification
T05-0301 SGSN-initiated PDP Context Modification
T05-04 IPv6 PDP Context
T05-0401 IPv6 PDP Context
T05-05 IPv4v6 Dual Stack Access
T05-0501 SGSN Supporting Dual Stack Access
T05-06 Secondary PDP Context Activation
T05-0601 Secondary PDP Context Activation
T05-07 SGSN Supporting Network-initiated Secondary Activation
T05-0701 SGSN Supporting Network-initiated Secondary Activation
T06 Charging Function
T06-01 S-CDR Generation
T06-0101 S-CDR Generation
T06-02 Configuration of Sending CDRs to CG
T06-0201 Active/Standby CG
T06-03 S-CDR Generation for Hot-Billing Subscribers
120
T06-0301 S-CDR Generation for Hot-Billing Subscribers

T07 QoS and Flow Management
T07-01 QoS Service Bearer of Interactive Type
T07-0101 PDP Context Activation with the QoS of Interactive Type
T07-02 QoS Service Bearer of Streaming Type
T07-0201 PDP Context Activation with the QoS of Streaming Type
T07-03 QoS Service Bearer of Conversational Type
T07-0301 PDP Context Activation with the QoS of Conversational Type
T08 QoS Control
T08-01 IMSI Based QoS Control
T08-02 Roaming Subscriber QoS Restriction
T08-0201 Roaming Subscriber QoS Restriction
T08-03 Local QoS Policy in PCC Mode
T09 QoS Conversion
T09-01 QoS Conversion
T09-0101 Conversion from R5 QoS to R7 QoS When the Subscriber Sub-
scribes to R5 QoS
T10 HSPA
T10-01 HSDPA
T10-0101 HSDPA: 2–4 Mbit/s
T10-0102 HSDPA Extended Package 1: 4–8 Mbit/s
T10-02 HSUPA
T10-0201 HSUPA: 2–4 Mbit/s
T10-0202 HSUPA Extended Package 1: 4–8 Mbit/s
T10-0203 HSUPA Extended Package 2: 8-12 Mbit/s
T10-0204 HSUPA Extended Package 3: 12-24 Mbit/s
T11 3G Subscriber Access Control
T11-01 3G Subscriber Access Control
T11-0101 3G Subscriber Access Control
T12 Area Roaming
121
T12-01 Zone Code Roaming Restriction

T12-0101 Zone Roaming Restriction
T13 Network Reselection between LTE and UMTS
T13-01 Network Reselection Between LTE and UMTS
T13-0101 Network Reselection from LTE to UMTS
T14 PS Handover Between LTE and UMTS
T14-01 PS Handover between LTE and UMTS
T14-0101 PS Handover from LTE to UMTS
T15 Multi-HPLMN Function
T15-01 Successful Attach and Activation Initiated by UEs of Two HPLMNs
T15-0101 Successful Attach and Activation Initiated by UEs of Two HPLMNs
T16 Detach of Inactive Subscribers
T16-01 Detach of Inactive Subscribers
T16-0101 Detach of Inactive Subscribers
T17 Idle PDP Context Deactivation
T17-01 Idle PDP Context Deactivation
T17-0101 Idle PDP Context Deactivation
T18 Iu-PS Interface
T18-01 Iu over IP
T18-0101 Iu over IP
T19 SS7 Interface
T19-01 Gr over IP
T19-0101 Location Update Procedure
T19-0102 Cancel Location Procedure
T20 Ga Interface
T20-01 Ga Interface
T20-0101 Ga Interface Transmits CDRs
T21 Gn Interface
T21-01 Gn Interface Supporting GTPv1
T21-0101 Gn Interface Supporting GTPv1
T22 Gateway Route Selection
T22-01 Gateway Route Selection
T22-0101 UE Activation and SGSN Gateway Route Selection
T22-02 RAI-based GGSN Selection
T22-0201 RAI-based GGSN Selection in the Case that the MS Activates a
PDP Context
122
T22-03 GGSN Selection Based on IMSI

T22-0301 GGSN Selection Based on IMSI
T22-04 CC-based GGSN Selection
T22-0401 CC-based GGSN Selection in the Case that the MS Activates a
PDP Context
T22-05 UE-CAP-based GGSN Selection
T22-0501 UE-CAP-based GGSN Selection in the Case that the MS Acti-
vates a PDP Context
T22-06 Category 6 Gateway Selection
T22-0601 High-speed Gateway Selection for a Category 6 UE Accessing
the Network from the UTRAN
T23 Requested Information Correction
T23-01 Requested APN Correction
T23-0101 SGSN Can Use the Default APN if no APN Is Contained in the
Activation Request
T24 IMS
T24-01 IMS
T24-0101 IMS
T25 Gs Interface
T25-01 Initiating GPRS Detach from MSC/VLR
T25-0101 GPRS Detach
T25-02 Combined LAU/RAU
T25-0201 Normal Subscriber Originates Combined Intra-SGSN Updating
T25-03 CS Paging
T25-0301 CS Paging
T26 Subscriber Migration in MSC POOL
T26-01 Subscriber Migration in MSC POOL
T26-0101 After VLR Offload Is Started, the SGSN Chooses another MSC in
the Pool When Combined Attach Is initiated
T27 Iu-Flex
T27-01 Iu-Flex
T27-0101 Assigning P-TMSI with NRI
T27-0102 UE Attach in Pool
T27-0103 UE Intra-RAU in the Pool
T28 SGSN Pool
T28-01 SGSN Pool
T28-0101 Subscriber Migration in the SGSN Pool
123
T29 ODB
T29-01 Packet Service Barring
T30 Multi-IMSI Function Test
T30-01 Multi-IMSI Function
T30-0101 SGSN Supporting the Multi-IMSI Function
T31 Direct Tunnel
T31-01 Direct Tunnel
T31-0101 PDP Context Activation with Basic DT Condition
T32 NACC
T32-01 NACC
T32-0101 NACC Procedure When the RNC and BSS Are Under the Same
SGSN
T33 Network Share MOCN
T33-01 Network Share MOCN
T33-0101 SGSN Supporting Network Share MOCN
T34 IMEI Check for Gf Interface
T34-01 IMEI Check for Gf Interface
T34-0101 Authorized Subscriber Obtaining IMEI Through Authentication
Procedure and Carrying Out IMEI Check
T35 vUSN Life Cycle Management
T35-01 Scaling
T35-0101 Manually Adding an SPU Through the EMS
T35-0102 Manually Deleting an SPU Through the EMS
T36 CHR
T36-01 CHR
T36-0101 CHR
T37 Extended Periodic RAU/TAU Timer for M2M
T37-01 Extended Periodic RAU/TAU Timer for M2M
T37-0101 Extended Periodic RAU/TAU Timer for M2M Supported by the
SGSN
T38 APN-based Signaling Congestion Control
T38-01 APN-based Signaling Congestion Control
T39 Null-MSISDN Function Supported by the SGSN
124
T39-01 Null-MSISDN Function Supported by the SGSN

T39-0101 Null-MSISDN Function Supported by the SGSN
T40 S4 SGSN Project Acceptance
T40-01 PDP Activation on the S4 SGSN
T40-0101 Activation on the S4 SGSN
T40-02 PDP Deactivation Supported by the S4 SGSN
T40-0201 PDP Deactivation Initiated by the UE
T41 Service-based Handover
T41-01 Service-based Handover
T41-0101 Service-based Handover
T42 Multi-Signaling
T42-01 Gr Interface
T42-0101 Multiple Subscribers Initiating GRPS Attach Procedures
T43 Smartphone Control
T43-01 Smartphone Control Base Function
T43-0101 Smartphone Control Base Function
T43-02 Abnormal Signaling Control for Repeated PDP Activations
T43-0201 Abnormal Signaling Control for Repeated PDP Activations
T43-03 Smartphone Traffic Model Statistics
T43-0301 Smartphone Traffic Model Statistics
T44 GWCN Network Sharing
T44-01 Attach Function under GWCN
T44-0101 selectplmn of Supported UE attach
T45 MVNO
T45-01 MVNO
T45-0101 MVNO of 3G Networks
T46 SMS
T46-01 Standard Gd Interface Connected with SMC-C
T46-0101 SMS Initiated by UE and Terminated by UE
T47 Alias APN
T47-01 Alias APN
T47-0101 Alias APN
T48 Network Identity Selection Based on RAN Area
T48-01 Network Identity Selection Based on RAN Area
T48-0101 Support by the SGSN for Network Identity Selection Based on
RAN Area
125
T49 Intelligent Policy for VIP Subscribers

T49-01 Data Service Restriction on Non-VIP Subscribers
T49-0101 Data Service Restriction on Non-VIP Subscribers Supported by
the SGSN During UE Activation
T50 ARP-based Differential Services
T50-01 ARP-based Differential Services
T50-0101 ARP-based Differential Services
T51 SuperCharger
T51-01 SuperCharger
T51-0101 SuperCharger Function
T52 IM Service Resource Management
T52-01 IM Service Resource Management
T52-0101 IM Service Resource Management
T53 LCS
T53-01 SGSN Supporting LCS
T53-0101 SGSN Supporting the LCS MT-LR Procedure
T54 Real-time Location-based Policy Control
T54-01 Real-time Location-based Policy Control
vUSN 4G
T01 Mobility Management
T01-01 Attach
T01-0101 UE Initiating an Attach Procedure Using the IMSI
T01-0102 UE Initiating an Attach Procedure Using the GUTI
T01-02 Combined Attach
T01-0201 UE Initiating a Combined Attach Procedure
T01-03 Detach
T01-0301 UE Initiating a Detach Procedure
T01-0302 MME Initiating a Detach Procedure
T01-04 Combined Detach
T01-0401 UE Initiating a Combined Detach Procedure
T01-05 Tracking Area Update
T01-0501 UE Initiating a Periodic TAU Procedure
T01-0502 UE Initiating a Normal TAU Procedure
126
T01-06 Service Requests

T01-0601 UE Initiating a Service Request
T01-07 Paging
T01-0701 Downlink Data Triggering a Paging Procedure
T01-0702 Downlink Signaling Triggering a Paging Procedure
T01-08 S1 Interface Resource Release
T01-0801 eNodeB Initiating a S1 Connection Releasing Procedure
T02 Subscription Management
T02-01 Location Data Management
T02-0101 Supporting Purge UE
T02-02 Subscription Data Processing
T03 Session Management
T03-01 Bearer Activation
T03-0101 Default Bearer Activation During an Attach Procedure
T03-0102 Network-initiated GBR Dedicated Bearer Activation
T03-0103 Network-initiated Non-GBR Dedicated Bearer Activation
T03-02 Bearer Modification
T03-0201 HSS-initiated Bearer Modification
T03-03 Bearer Deactivation
T03-0301 MME-initiated Bearer Deactivation
T03-0302 UE-initiated Bearer Deactivation
T03-04 Supporting Multiple PDNs
T03-0401 UE-initiated PDN Connection
T03-0402 UE-Requested PDN Disconnection
T03-05 Supporting PDP Dual-stack
T03-0501 Default Bearer Activation with an IPv6 Address During an Attach
Procedure
T03-0502 Default Bearer Activation with an IPv4/IPv6 Address During an
Attach Procedure
T04 Interface Management
T04-01 S1 Interface
T04-0101 Viewing the Status of S1AP Links
T04-02 S6a Interface
T04-0201 Viewing the Information About Peer Entities
T04-0202 Viewing the Status of Diameter Links
T04-0203 Diameter Load Sharing Based on Priority
127
T04-03 DNS/S10/S11 Interfaces

T04-0301 Viewing the Configuration of DNS Servers
T04-0302 Communication with DNS Servers
T04-0303 Viewing the Status of GTP-C Paths
T05 Security Management
T05-0101 Supporting EPS-AKA Authentication
T05-02 Subscriber Identity Confidentiality
T05-0201 Reassigning GUTIs
T05-03 NAS Security
T05-0301 Negotiation over the NAS Security Mode Using AES
T05-0302 Negotiation over the NAS Security Mode Using SNOW 3G
T05-04 Identity Authentication
T05-0401 Supporting the Identity Procedure
T05-0402 Supporting the Identification Procedure
T05-05 CHECK IMEI
T05-0501 Initiating IMEI Check and Accepting the Attach Requests of
UEs in the white list
T05-07 4G 1/N IMEI Check
T05-0701 1/N IMEI Check During 4G Attach
T06 Handover
T06-01 X2-based Handover
T06-0101 X2-based Handover with the S-GW Unchanged
T06-02 S1-based Handover
T06-0201 S1-based Handover with the MME and S-GW Unchanged
T07 MME Pool
T07-01 MME Load Balancing
T07-0101 Delivering the Configuration of the MME Pool by Sending S1
Setup Response Messages
T07-02 Subscribers Migration in MME POOL
T07-0201 Migration of UEs in the ECM-IDLE State
T08 QoS Mapping
T08-01 DSCP Configuration for Each Logical Interface
T08-0101 DSCP Configuration for Each Logical Interface
T09 IMSI Based QoS Control
128

T09-0101 MME Controls UE AMBR and APN AMBR Based on Local MME
Policy for Roaming Subscriber During Attach
T10 QoS Control Enhancement
T10-01 Supporting Extended QCIs
T10-0101 Supporting Extended QCIs During UE-initiated PDN Connec-
tion Establishment Procedures
T11 Auto-Configuration of the X2 Interface
T11-01 Auto-Configuration of the X2 Interface
T11-0101 Auto-Configuration of the X2 Interface
T12 NE Selection
T12-01 Gateway Route Selection
T12-0101 Gateway Route Selection During Attach
T12-02 Intelligent NE Selection During Attach Procedures
T12-0201 Intelligent Gateway Selection During Attach Procedures: Inte-
gration Policy
T12-03 Gateway Selection Based on UE Access Capability
T12-0301 Gateway Selection Based on UE Access Capability During At-
tach
T12-04 Gateway Selection Based on Charging Characteristics
T12-0401 Gateway Selection Based on Charging Characteristics During
Attach
T12-05 S-GW Selection Anchored on P-GW
T12-0501 S-GW Selection Anchored on P-GW
T12-06 Gateway Selection Based on Location
T12-0601 Gateway Selection Based on Location During Attach
T12-07 Category 6 Gateway Selection
T12-0701 High-speed Gateway Selection for a Category 6 UE Accessing
the Network from the E-UTRAN
T12-08 Alias APN
T12-0801 APN Mapping During Attach Procedures
T13 Access Control
T13-01 Access Control Based on Subscribed ARD
T13-0101 Access Control Based on Subscribed Access Restriction Data
T13-02 Access Control Based on the Regional Configuration
T13-0201 Access Control Based on the Regional Configuration
T14 GUL Interworking
129
T14-01 GUL Interworking

T14-0101 Location Update Procedure from a UMTS Network to an LTE
Network
T14-0102 Location Update Procedure from a GSM Network to an LTE
Network
T14-0103 PS Handover from a UMTS Network to an LTE Network
T15 Non-EPS Alert
T15-01 Non-EPS Alert
T15-0101 MSC-initiated Non-EPS Alert
T16 Telecom Service
T16-01 CSFB Voice Service
T16-0101 MO Call Initiated by the UE in the ECM-CONNECTED State
T16-02 SRVCC Voice Service
T16-0201 SRVCC Handover of a UE from an E-UTRAN to a UTRAN With-
out a PS Handover
T16-03 Data/Voice Switch within SRVCC
T16-0301 Data and Voice Service Switch to the Target Gn/Gp SGSN in an
SRVCC Procedure with Direct Forwarding Enabled
T16-04 SMS Service
T16-0401 Short Message Sent by the UE in the ECM-CONNECTED State
T16-0402 Short Message Received by the UE in the ECM-CONNECTED
State
T16-05 SRVCC Enhancement
T16-0501 MME Reporting the SRVCC Capability of a UE Correctly
T16-06 CSFB Enhanced
T16-0601 Multi PLMN CSFB
T16-0602 One-shot LA Selection CSFB
T16-07 VIP Voice CSFB
T16-0701 VIP Voice CSFB
T16-08 CSFB Emergence Call
T16-0801 CSFB Emergence Call
T16-09 Flash CSFB
T16-0901 Flash CSFB Triggered by a Voice Service Request
T16-10 Always Reachable CSFB
T16-1001 Support for Always Reachable CSFB When the MSC Is Faulty
T16-11 IMS-based VoLTE
T16-1101 IMS-based VoLTE
T16-12 Default MSC Selection over the SGs Interface
130
T16-1201 Default MSC Selection Using the Default Mapping Between TAI
and LAI
T16-13 eMPS
T16-1301 Support for eMPS Paging and Re-paging
T17 CSFB with MSC Pool
T17-01 Subscriber Migration in MSC Pool
T17-0101 Manual Offload in MSC Pool During a Periodic TAU Procedure
T18 ODB
T18-01 ODB
T19 Multi-IMSI Function
T19-01 Multi-IMSI VoLTE Function
T19-0101 MME Supporting the Multi-IMSI VoLTE Function
T20 Requested APN Correction
T20-01 Requested APN Correction
T20-0101 APN Correction for Inconsistent Subscribe APN and Request
APN
T21 NACC
T21-01 NACC
T21-0101 NACC Procedure When the Target eNodeB and Source Cell Are
Under the Same vUSN
T22 Network Share MOCN
T22-01 Network Share MOCN
T22-0101 MME Supporting Network Share MOCN
T23 Multiple HPLMNs
T23-01 Successful Attach and Activation of UEs with Different HPLMNs
T23-0101 Successful Attach and Activation of UEs with Different HPLMNs
T24 Operation and Maintenance
T24-01 Performance Management
T24-0101 Supporting LTE Mobility Management
T24-0102 LTE Session Management Measurement
T24-02 Fault Management
T24-0201 Viewing vUSN Alarms on the vU2000
T24-03 Security Management
T24-0301 Operator Permission Management
T24-0302 Operator Login/Logout
131
T24-04 DST Configuration

T24-0401 DST Configuration
T24-05 Trace Management
T24-0501 User Tracing Based on IMSI
T24-06 NTP
T24-0601 NTP
T24-07 Reliability
T24-0701 Supporting SPU_B VM Resetting
T25 Emergency Call
T25-01 Emergency Call
T25-0101 Emergency Attach
T26 Accurate Paging
T26-01 Accurate Paging
T26-0101 Accurate Paging
T27 Interoperation Between the LTE and WiFi Networks
T27-01 Handover Between WiFi and LTE
T27-0101 Handover from a WiFi Network to an LTE Network and Address-
ing Based on Subscribed P-GW Information
T28 Voice Policy Control for User Group
T28-01 Voice Policy Control for User Group
T28-0101 MME Support Voice Policy Control for User Group
T28-02 Voice Policy Control Based on IMEI
T28-0201 MME Support Voice Policy Control Based on IMEI
T28-03 Voice Policy Control Based on Location
T28-0301 MME Support Voice Policy Control Based on Location
T29 Location Information Query in Voice Service
T29-01 Location Information Query in Voice Service
T29-0101 Location Information Query in Voice Service
T30 Local QoS Policy in PCC Mode
T30-0101 Support Local QoS Policy in PCC Mode
T31 Category Function
T31-01 Supporting UE Category 2/3/4 Access Basic Function
T31-0101 MME Supporting the Access of UEs in Category 2/3/4
T31-02 Supporting UE Category 2/3/4 Access, 150M
T31-0201 MME Supporting the Access of Category 4 UEs and the Estab-
lishment of PDN Connections
132
T31-03 Supporting UE Category 6 Access Basic Function

T31-0301 MME Supporting the Access of Category 6 Ues
T31-04 Supporting UE Category 6 Access, 300M
T31-0401 MME Supporting the Access of Category 6 UEs and the Estab-
lishment of PDN Connections
T32 vUSN Life Cycle Management
T32-01 Scaling
T32-0101 Manually Adding an SPU Through the EMS
T32-0102 Manually Deleting an SPU Through the EMS
T33 IP Function
T33-01 Ethernet Interface
T33-0101 Supporting Sub-interfaces
T33-02 BFD
T33-0201 Supporting a Static Route Associated with a BFD Session
T33-03 Static Route
T33-0301 Supporting Static Routes
T33-04 Dynamic Route
T33-0401 Supporting OSPF Routes
T33-05 VPN
T33-0501 Supporting VRF
T33-06 IPv6-base Ping Function
T33-0601 IPv6-base Ping Function
T34 CHR
T34-01 CHR
T34-0101 CHR
T35 Support eNodeB Coverage Level Based Paging
T35-01 Support eNodeB Coverage Level Based Paging
T35-0101 Support eNodeB Coverage Level Based Paging
T36 LTE M2M Terminal Power Saving
T36-01 LTE M2M Terminal Power Saving
T36-0101 LTE M2M Terminal Power Saving
T37 APN-based Signaling Congestion Control
T38 Presence Reporting Area Support
T38-01 Presence Reporting Area Support
133
T38-0101 Support for PRA Status Reporting in an Attach Procedure

T39 Low-Priority Access Control
T39-01 Low-Priority Access Control
T39-0101 Low-Priority Access Control
T40 Signaling Congestion Control Based on the Back-off Timer
T40-01 Signaling Congestion Control Based on the Back-off Timer
T40-0101 Signaling Congestion Control Based on the Back-off Timer
T41 Extended Periodic RAU/TAU Timer for M2M
T42 Equivalent NE Selection Based on Location
T42-01 Equivalent NE Selection Based on Location
T42-0101 Selection of a Peer MME Using a Domain Name Customized
Based on a TAI Range During a Handover Procedure
T43 LTE PTT
T43-01 LTE PTT
T43-0101 LTE PTT
T44 Network Interoperation Between CDMA2000 and LTE
T44-01 Non-Optimized Handover Between CDMA2000 and LTE
T44-0101 Handover from a non-3GPP Network to a 3GPP Network and
Addressing Based on Subscribed P-GW Information
T45 PDN Re-Activation to Local P-GW
T45-01 Support of PDN Re-Activation to Local P-GW
T45-0101 Time-based Reattach
T46 HeNB’s Access to the MME Through an HeNB Gateway
T46-01 HeNB’s Access to the MME Through an HeNB Gateway
T46-0101 HeNB’s Access to the MME Through an HeNB Gateway During
an S1-based Handover
T47 LTE UE Signaling Control
T47-01 LTE UE Signaling Control
T47-0101 LTE UE Signaling Control for Service Request Messages
T48 MVNO
T48-01 MVNO
T48-0101 MVNO of LTE Networks
T49 End-to End Subscriber Trace
134
T49-01 U2000 Delivering an End-to-End Subscriber Trace Session to the MME

T49-0101 U2000 Delivering an End-to-End Subscriber Trace Session to
the MME Before an Attach Procedure Starts
T50 CBS
T50-01 CBS
T50-0101 Write-Replace Warning Procedure
T51 Network Identity Selection Based on RAN Area
T51-01 Network Identity Selection Based on RAN Area
T51-0101 Support by the MME for Network Identity Selection Based on
RAN Area
T52 Service Guarantee for High-Mobility User
T52-01 Service Guarantee for High-Mobility User
T52-0101 Service Guarantee for High-Mobility User Supported by the
MME
T53 EPC LCS
T53-01 MT-LR Function
T53-0101 4G UE Supporting the MT-LR Function
T54 Real-time Location-based Policy Control
T55 UE Cell Location Reporting to the UIC
T55-01 UE Cell Location Reporting to the UIC
T55-0101 UE Cell Location Reporting to the UIC
T56 Multi Time Zone Service
T56-01 Multi Time Zone Service
T56-0101 Selection of a Time Zone Based on the Location Area
T57 Network Share (GWCN)
T57-01 Network Share (GWCN)
T57-0101 Network Share (GWCN) Supported by the MME
T58 Null-MSISDN
T58-01 Null-MSIDN
T58-0101 Null-MSISDN
T59 VoLTE Disaster Tolerance
T59-01 Service Restoration Upon S-GW/P-GW Failure
T59-0101 S-GW Reselection by the MME Upon an S-GW Failure When
the S/GW and P-GW Are Separately Deployed
135
T59-0102 Detach of UEs Affected by a P-GW Failure to Enable the UEs to

Reattach to a Functional P-GW When the S/GW and P-GW Are Separately
Deployed
T60 IPv6-based UE Attach
T60-01 IPv6-based UE Attach
T60-0101 IPv6-based UE Attach
vUGW
T01 Operation and Maintenance

T01-01 Performance Management
T01-0101 Measurement Object Creation
T01-0102 Online Session Count
T01-0103 Current Throughput Measurement
T01-02 Alarm Management
T01-0201 Alarm Generation in the Case of VM Failures
T01-0202 Alarm Log Query
T01-03 Real-Time Monitor
T01-0301 Real-Time CPU Usage Monitoring
T01-0302 Real-Time Memory Usage Monitoring
T01-04 Configuration Management
T01-0401 Batch Configuration Import/Export
T01-0402 Configuration Restoration After vUGW Restart
T01-05 Log Management
T01-0501 Operation Log Query
T01-06 Remote Maintenance
T01-0601 U2000 Help Query
T01-0602 WebLMT Help Query
T01-0603 Remote U2000 Maintenance
T01-0604 Remote WebLMT Maintenance
T01-07 Time Management
T01-0701 DST
T01-0702 Network Time Synchronization with an NTP Server
T01-08 Tracing Management
T01-0801 vUGW User Tracing
T01-0802 Gx Interface Tracing
T01-0803 Gy Interface Tracing
T01-0804 E2E User Tracing
136
T01-09 Software Management

T01-0901 Software Upgrade
T01-0902 Patch Loading
T01-0903 Patch Rollback
T01-0904 Patch Deletion
T01-10 Security Management
T01-1001 Management Plane Isolation
T01-1002 Data Plane Isolation
T01-1003 Signaling Plane Isolation
T01-1004 SFTP Service
T01-1005 STelnet Services
T01-11 Gy Interface Online Charging on the P-GW
T01-1101 Real-Time Charging for User Services
T02 Routing And Network
T02-01 Network
T02-0101 MTU Configuration
T02-0102 VLAN 24 T02-0103 ARP Probe
T02-0104 APN and VRF Binding
T02-0105 Pa Interface Supporting the Single IP Feature
T02-0106 Sa Interface Supporting the Single IP Feature
T02-0107 BFD
T02-02 Routing
T02-0201 OSPF Route
T02-0202 Static Route
T02-0203 Direct Route
T02-0204 IP Routing Policy
T03 Basic Services
T03-01 Basic Services
T03-0101 Internet Browsing
T03-0102 UMTS Access
T03-0103 LTE Access
T03-0104 Supporting the S4 Interface
T03-0105 Supporting the S12 Interface
T03-02 Session Management
T03-0201 Activation/Deactivation for UMTS Subscribers
T03-0202 P-GW Supporting Default Bearer Establishment/Deletion
T03-0203 S-GW Supporting Default Bearer Activation/Deactivation
137
T03-0204 Multiple PDN Connections for a UMTS Subscriber

T03-0205 Multiple PDN Connections for an LTE Subscriber
T03-0206 Obtaining PLMN IDs
T03-0207 Multi-HPLMN Access
T03-03 Idle Bearer Reclaiming Management
T03-0301 Deactivation of Idle PDP Contexts
T03-0302 Deactivation of PDP Contexts That Persist for Specific Time
T03-0303 Manual Context Deactivation
T03-04 Path Management
T03-0401 GGSN Supporting GTP Path Detection
T03-0402 P-GW Supporting GTP Path Check
T03-0403 S-GW Supporting GTP Path Detection
T03-05 Address Management
T03-0501 Access Using Static IP Addresses
T03-0502 Local Dynamic Address Assignment
T03-0503 Address Assignment by a RADIUS Server
T04 Radius Management
T04-0101 Local Authentication
T04-0102 Non-Transparent Authentication
T04-0103 Authentication Using an MSISDN as the User Name
T04-0104 Authentication Using an APN as the User Name
T04-0105 Anonymous Access
T04-02 Radius Accounting
T04-0201 Real-Time Volume-based RADIUS Accounting
T04-0202 Real-Time Time-Based RADIUS Accounting
T04-0203 RADIUS Accounting Triggered by ULI Updates
T04-0204 Carbon-Copy of RADIUS Accounting Messages
T04-0205 Carbon-Copy of RADIUS Authentication Messages
T04-0206 RADIUS Load Sharing
T05 Charging Management
T05-01 Offline Charging
T05-0101 Volume-based CDR Generation in Normal Charging with a CG
T05-0102 Tariff Switch
T05-0103 CDR Generation for Hot Billing
138
L IST OF F IGURES
2.1 Customer Key Indicators (2016-2017) [34]. . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Milestones and Launches: Vodafone in Spain (1994-2016) [34]. . . . . . . . . . . 7
2.3 Top Apps – Daily Data Volume (GB/Day) [25]. . . . . . . . . . . . . . . . . . . . . 8
2.4 Traffic forecast - Vodafone Spain [25]. . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 Traffic forecast vs. Capability [25]. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6 Forecast: VNF and Legacy in 2019 [25]. . . . . . . . . . . . . . . . . . . . . . . . . 9
2.7 Map of the main unions between mobile telephony operators in Spain. . . . . . 10
2.8 Market share of mobile telephone companies in Spain (December 2017) [29]. . 11
2.9 Registrations and portabilities of 2017 in Spain [4]. . . . . . . . . . . . . . . . . . 12
2.10 P3 Measurements Results [3]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.11 P3 Overal Results [3]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.12 Geographical market segmentation [23]. . . . . . . . . . . . . . . . . . . . . . . . 14
3.1 Gantt Chart: Main Milestone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Test availability CE18.1 TR5 vs.TR6 vs. GA [13]. . . . . . . . . . . . . . . . . . . . . 22
3.3 Precedence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Comparison between “Do nothing” scenario vs. Virtualization. . . . . . . . . . . 26
3.5 CAPEX Virtualization detailed - Unitary cost k". . . . . . . . . . . . . . . . . . . . 27
3.6 CAPEX "Do Nothing" detailed - Unitary cost k". . . . . . . . . . . . . . . . . . . . 28
4.1 Old Vodafone’s Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2 NFV Basic Architecture [7]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3 SDN general structure [7]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4 New Vodafone’s Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5 vUSN (SGSN/MME) Standard Interfaces. . . . . . . . . . . . . . . . . . . . . . . . 36
4.6 vUGW (GGSN/S-GW/P-GW) Standard Interfaces. . . . . . . . . . . . . . . . . . . 36
4.7 3GPP Standard Progress [9]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.8 5G in Packet Core - Steps and Enablers [9]. . . . . . . . . . . . . . . . . . . . . . . 41
4.9 5G NSA architecture [9]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.10 5G SA architecture [9]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.11 MEC network architecture [31]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.12 Huawei Separation Solution [18]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.13 Slices for different applications and environments [9]. . . . . . . . . . . . . . . . 46
139
LIST OF FIGURES
5.1 vUSN vBOM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2 vUGW vBOM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3 C7000 compute enclosure [12]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.4 HP ProLiant DL360p Gen9 [12]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.5 HPE 6125XLG Ethernet switch [21]. . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.6 NFVI Clusters Management [12]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.7 NFVI Physical and Virtual view [12]. . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.8 vUGW Architecture [12]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.9 vUGW and vUSN Interfaces [12]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.10 Option One. Implementation of Connectivity for the IPU VM type [12]. . . . . . 56
5.11 Option Two. Implementation of Connectivity for the IPU VM type [12]. . . . . . 56
5.12 Option One. Implementation of Connectivity for the APU VM type [12]. . . . . . 57
5.13 Option Two. Implementation of Connectivity for the APU VM type [12]. . . . . . 57
5.14 vUSN IP Desing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.15 vUGW and vMSE IP Desing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.16 Step One - Placement of the test mobile in the Faraday cage. . . . . . . . . . . . 69
5.17 Step Two - Cables provisioning 4G and 3G signals to the Faraday cage. . . . . . . 69
5.18 Step Three - Cage of Faraday closed, with the mobile test inside, ready to begin
the tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.19 Step Four - Monitoring of the test mobile signal through the mesh of the Faraday
cage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.20 5G and 4G antennas for NSA testing, in Vodafone Plaza. . . . . . . . . . . . . . . 70
5.21 NSA Testing - Huawei CPE side, in Vodafone Plaza. . . . . . . . . . . . . . . . . . 70
5.22 Huawei CPE: First Commercial 5G Modem, [10]. . . . . . . . . . . . . . . . . . . 71
5.23 T01-0201 Combined Attach Diagram [15]. . . . . . . . . . . . . . . . . . . . . . . 72
5.24 T01-0201 Combined Attach Traces. . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.25 T01-1101 Online Charging Network Scenario. . . . . . . . . . . . . . . . . . . . . 83
5.26 T01-1101 Online Charging Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.27 T01-1101 Online Charging - Interface S11. . . . . . . . . . . . . . . . . . . . . . . 86
5.28 T01-1101 Online Charging - Interface Gy. . . . . . . . . . . . . . . . . . . . . . . . 96
5.30 Speed measurements in 5G. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.29 Total throughput in 5G measurements. . . . . . . . . . . . . . . . . . . . . . . . . 104
B.1 P3 Overal Results for Voice - Drivetest [3]. . . . . . . . . . . . . . . . . . . . . . . . 115

B.2 P3 Overal Results for Data in Cities - Drivetest [3]. . . . . . . . . . . . . . . . . . . 116
B.3 P3 Overal Results for Data in Towns - Drivetest [3]. . . . . . . . . . . . . . . . . . 117
B.4 P3 Overal Results for Data on Roads - Drivetest [3]. . . . . . . . . . . . . . . . . . 118
140
L IST OF TABLES
3.1 Huawei Testeing Phases for vUGW-TMF. . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 PDM activities schedule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1 vEPS Network Element Interconnect Relationship [35]. . . . . . . . . . . . . . . . 36
5.1 vUGW and vUSN Connectivity Options [12]. . . . . . . . . . . . . . . . . . . . . . 52

5.2 vUGW and vUSN Connectivity Options [12]. . . . . . . . . . . . . . . . . . . . . . 55
5.3 Network parameters dimensioning [12]. . . . . . . . . . . . . . . . . . . . . . . . 58
5.4 vUSN uses case [14], [15]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.5 vUGW uses cases [16]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
141
L IST OF T RACES
5.1 T01-0201 Combined Attach Traces . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.2 T01-1101 Online Charging - Interface S11: Create PDP context Request Trace . 87
5.3 T01-1101 Online Charging - Interface Gx: INITIAL Credit Control Request Trace 89
5.4 T01-1101 Online Charging - Interface Gx: INITIAL Credit Control Answer Trace 91
5.5 T01-1101 Online Charging - Interface S11: Create PDP context Response Trace 93
5.6 T01-1101 Online Charging - Interface Gy: UPDATE Credit Control Request Trace 97
5.7 T01-1101 Online Charging - Interface Gy: TERMINATION Credit Control Re-
quest Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
143
B IBLIOGRAPHY
[1] Bart Barton. Lte and beyond. "http://www.lteandbeyond.com", "[Online; Accessed

18-June-2018]".
[2] P3 Connect Mobile Benchmark. Testing networks for a better mobile experience. "http:
//p3-networkanalytics.com", "[Online; Accessed 18-April-2018]".
[3] P3 Connect Mobile Benchmark. The 2017 mobile network test in spain. Technical report,
P3 Connect Mobile Benchmark, November 2017.
[4] Mikel Cid. Portabilidades 2017: Masmovil no es el unico ganador

del inicio de una nueva era. "https://www.xatakamovil.com/mercado/
portabilidades-2017-masmovil-no-es-el-unico-ganador-del-inicio-de-una-nueva-era",
"[Online; Accessed 12-May-2018]".
[5] CISCO. Bidirectional forwarding detection. "https://www.cisco.com/c/en/us/td/docs/

ios/12_0s/feature/guide/fs_bfd.html", "[Online; Accessed 31-Mar-2018]".
[6] CISCO. Ecmp load balancing. "https://www.cisco.com/c/en/us/td/docs/ios-xml/

ios/mp_l3_vpns/configuration/xe-3s/asr903/mp-l3-vpns-xe-3s-asr903-book/
mp-l3-vpns-xe-3s-asr903-book_chapter_0100.pdf", "[Online; Accessed 31-Mar-2018]".
[7] Vodafone Corporation. Vodafone ocean. Technical report, Vodafone, 2017.
[8] Ja Deep. The vodafone story. "http://jdforvodafone.blogspot.com/2014/09/

vodafones-segmentation-targeting-and.html", "[Online; Accessed 28-June-2018]".
[9] Data Core: Planning Design and Dimensioning. 5g packet core - whitepaper. Technical
report, Vodafone, 2017.
[10] dmsoftstudio About every stuff. Huawei launches the first commercial 5g device. "https:
//www.dmsoftstudio.com/huawei-launches-the-first-commercial-5g-device/", "[On-
line; Accessed 29-May-2018]".
[11] Ericsson. Network slicing - learn how network slicing can be a piece of cake. "https:
//www.ericsson.com/digital-services/trending/network-slicing", "[Online; Accessed
12-June-2018]".
145
BIBLIOGRAPHY
[12] Natalia Barbu Walter Berardi Dimitris Mamatsis Ioanna Markak Mario Guido Giovanni
La Medica, Joao Ribas. E2e solution architecture - high level design. Technical report,
Vodafone, February 2018.
[13] Huawei. Feature test availability ce18.1 tr5 vs.tr6 vs. ga vs. ce19.1. Technical report,
HUAWEI Technologies Co.,Ltd.
[14] Huawei. Acceptance manual 3g: Huawei cloudusn unified serving node 3g. Technical
report, Huawei Technologies Co.,Ltd, 2018.
[15] Huawei. Acceptance manual 4g: Huawei cloudusn unified serving node. Technical
[16] Huawei. Cloudugw v100r018c10: Operation guide (ggsn, s-gw, p-gw and rgw-basic part).
Technical report, Huawei Technologies Co.,Ltd, February 2018.
[17] Sacha Kavanagh. What is network slicing? "https://5g.co.uk/guides/

what-is-network-slicing/", "[Online; Accessed 12-June-2018]".
[18] Huawei Hedex Lite. Cu separation solution. Technical report, Huawei Technologies
Co.,Ltd, 2018.
[19] MbaSkool. Vodafone marketing mix. "https://www.mbaskool.com/marketing-mix/

services/16863-vodafone.html", "[Online; Accessed 28-June-2018]".
[20] Mediatek. 5g: What is standalone (sa) vs non-standalone (nsa) networks? "https:
//www.mediatek.com/blog/5g-what-is-standalone-sa-vs-non-standalone-nsa", "[On-
line; Accessed 21-May-2018]".
[21] NSIGHT. Hpe 6125xlg ethernet blade switch - switch - 8 ports -

managed - plug-in module. "https://www.insight.com/en_US/buy/
product/737220-B21/HEWLETT%20PACKARD%20ENTERPRISE/737220-B21/
HPE-6125XLG-Ethernet-Blade-Switch--switch--8-ports--managed--plugin-module/",
"[Online; Accessed 29-May-2018]".
[22] Muhammad Raza. What is software defined networking? sdn explained. "https://www.
bmc.com/blogs/software-defined-networking/", "[Online; Accessed 3-May-2018]".
[23] Market Realist. Anlyzing vodafone’s value proposition in the

global telecom market. "https://marketrealist.com/2016/02/
anlyzing-vodafones-value-proposition-global-telecom-market", "[Online; Accessed
28-June-2018]".
[24] Navarro Moldes Hernández Sánchez Farías Mendoza Juan Antonio Rodríguez Haro,
Fernando Freitag. A summary of virtualization techniques. "https://upcommons.upc.
edu/handle/2117/19378", "[Online; Accessed 3-May-2018]".
[25] Vodafone Sapin. Mobile demand assessement and impact. Technology, April 2018.
146
BIBLIOGRAPHY
[26] Vodafone Spain. Bienvenido a vodafone secure net. "https://securenet.vodafone.es",

"[Online; Accessed 18-June-2018]".
[27] Vodafone Spain. Historia de vodafone. "https://www.vodafone.es/c/conocenos/es/

vodafone-espana/quienes-somos/historia/", "[Online; Accessed 19-April-2018]".
[28] Vodafone Spain. ¿qué es vodafone pass y qué aplicaciones incluye?

"https://ayudacliente.vodafone.es/particulares/tarifas/vodafone-pass/
que-es-vodafone-pass-y-que-aplicaciones-incluye/", "[Online; Accessed 27-June-
2018]".
[29] Statista. Cuota de mercado de las empresas de telefonia movil en es-

pana a diciembre de 2017. "https://es.statista.com/estadisticas/553819/
cuota-de-mercado-de-los-operadores-de-telefonia-movil-en-espana-en-2015/",
"[Online; Accessed 15-April-2018]".
[30] Tecnocom. Interfaces lógicos. Technical report, Tecnocom, March 2013.
[31] Comba Telecom. Mec mobile edge computing. "http://slideplayer.com/slide/

11834236/", "[Online; Accessed 17-March-2018]".
[32] Balamurali Thekkedath. Network Functions Virtualization for Dummies. Special edition,
2016.
[33] Vodafone Vodacom. Segmented proposition. "http://www.vodacom-reports.co.za/

integrated-reports/ir-2017/segmented-propositions.php", "[Online; Accessed 28-June-
2018]".
[34] Vodafone. Integrated report 2016-17 vodafone spain. 2018.
[35] Vodafone and Huawei. High level design for vodafone spain vepc trial project. Technical
[36] Wikipedia. Mobile edge computing. "https://en.wikipedia.org/wiki/Mobile_edge_

computing", "[Online; Accessed 18-March-2018]".
[37] Wikipedia. Vodafone. "https://es.wikipedia.org/wiki/Vodafone", "[Online; Accessed

29-May-2018]".
147
D ECLARATION
I declare that this thesis does not incorporate without acknowledgment any material previ-
ously submitted for a degree or diploma in any university and that to the best of knowledge
it does not contain any materials previously published or written by another person except
where due reference is made in the text.
Andrea Vallejo Puigvert

Madrid, July 8, 2018
149

Tesis Master Andrea Vallejo Puigvert PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tesis Master Andrea Vallejo Puigvert PDF

Uploaded by

Copyright:

Available Formats

Trabajo Fin de Máster

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA Y SISTEMAS DE TELECOMUNICACIÓN

A NDREA VALLEJO P UIGVERT

U NIVERSIDAD P OLITECNICA DE M ADRID

I NTERNET T ECHNOLOGY AND A RCHITECTURE

EIT D IGITAL M ASTER S CHOOL

4.3.3 Non Stand-Alone and Stand-Alone Networks . . . . . . . . . . . . . . . . 44

6 Conclusion and Future Work 105

B Additional Information 115

C Cases List 119

List of Figures 139

List of Tables 140

List of Traces 141

The world of telecommunications is constantly changing. Customers expectations are con-

The future is exciting, are you

1.1 T HESIS O UTLINE

2.1 E XECUTIVE S UMMARY

2.2 C OMPANY D ESCRIPTION

Figure 2.1: Customer Key Indicators (2016-2017) [34].

Figure 2.2: Milestones and Launches: Vodafone in Spain (1994-2016) [34].

2.3 B USINESS D RIVERS

platforms such as Netflix.

Figure 2.3: Top Apps – Daily Data Volume (GB/Day) [25].

Figure 2.4: Traffic forecast - Vodafone Spain [25].

2.4 VALUE P ROPOSITION

2.5 M ARKET A NALYSIS

approach, where the technical features of each company will be compared.

Figure 2.9: Registrations and portabilities of 2017 in Spain [4].

Figure 2.10: P3 Measurements Results [3].

Figure 2.11: P3 Overal Results [3].

2.5.2 C USTOMER S EGMENTATION

Figure 2.12: Geographical market segmentation [23].

Vodafone’s customers consist of retail customers, third-party resellers and corporate

2.7 G O TO THE M ARKET S TRATEGY

3.1 T IME PLAN

3.2 P RECEDENCE DIAGRAM METHOD (PDM)

Task 10.1: vUSN with release 18.1 TR5 Testing

Task 12.1: vUSN 18.1 GA Upgrade & Test.

Figure 3.2: Test availability CE18.1 TR5 vs.TR6 vs. GA [13].

CE18.1 TR5 CE18.1 TR6 CE18.1 GA

Table 3.1: Huawei Testeing Phases for vUGW-TMF.

Task 17.1: vUSN 18.1 TR6 FOA

Activity Dedcription Duration ES LS EF LF

Table 3.2: PDM activities schedule.

Figure 3.4: Comparison between “Do nothing” scenario vs. Virtualization.

Figure 3.5: CAPEX Virtualization detailed - Unitary cost k".

Figure 3.6: CAPEX "Do Nothing" detailed - Unitary cost k".

Figure 4.1: Old Vodafone’s Topology

4.1 T ECHNIQUES FOR VIRTUALIZATION

Figure 4.2: NFV Basic Architecture [7].

• OSS and Business Support System (BSS)

• Virtual Network Functions Infrastructure (VNFI)

The hypervisor is an operating system, which provides a level of abstraction. It abstracts

• Management and Orchestration (MANO)

* Creation of VNFs by the use of templates and parameters.

• Separate user plane from control plane.

• Standard protocols for interoperability.

• Create an open platform.

• Apply network wide.

1. Real-time network status.

3. Automated provisioning of physical network nodes.

• Introduce programmability and maximise automation.

• Optimise transport resources usage.