Professional Documents
Culture Documents
M ASTER T HESIS
BY
J ULY 8, 2018
S UPERVISORS
C ÉSAR B ENAVENTE
F INI I RLES
M ARTA DE PABLOS
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
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
A Abbreviations 107
Bibliography 147
Declaration 149
IV
A BSTRACT
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
CHAPTER 1. INTRODUCTION
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
CHAPTER 1. INTRODUCTION
• 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.
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.
6
CHAPTER 2. BUSINESSS PLAN
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.
7
CHAPTER 2. BUSINESSS PLAN
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
CHAPTER 2. BUSINESSS PLAN
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].
9
CHAPTER 2. BUSINESSS PLAN
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.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
CHAPTER 2. BUSINESSS PLAN
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
CHAPTER 2. BUSINESSS PLAN
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.
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
CHAPTER 2. BUSINESSS PLAN
However, Yoigo was in the fourth position with the worst results, and very far from the
third [3], [2].
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
CHAPTER 2. BUSINESSS PLAN
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].
14
CHAPTER 2. BUSINESSS PLAN
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.
15
CHAPTER 2. BUSINESSS PLAN
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.
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
CHAPTER 3. PROJECT PLANNING
Figure 3.1: Gantt Chart: Main Milestone.
19
CHAPTER 3. PROJECT PLANNING
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
CHAPTER 3. PROJECT PLANNING
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 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
CHAPTER 3. PROJECT PLANNING
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]:
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
CHAPTER 3. PROJECT PLANNING
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 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
CHAPTER 3. PROJECT PLANNING
24
CHAPTER 3. PROJECT PLANNING
Figure 3.3: Precedence Diagram
25
CHAPTER 3. PROJECT PLANNING
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.
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
CHAPTER 3. PROJECT PLANNING
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.
27
CHAPTER 3. PROJECT PLANNING
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).
29
CHAPTER 4. TECHNICAL BACKGROUND
4.1.1 NFV
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
CHAPTER 4. TECHNICAL BACKGROUND
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]:
• 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.
31
CHAPTER 4. TECHNICAL BACKGROUND
– 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:
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
CHAPTER 4. TECHNICAL BACKGROUND
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:
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:
2. Service demand.
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]:
33
CHAPTER 4. TECHNICAL BACKGROUND
• Real-Time view and decision making (monitoring, analytics, and optimisation, among
others).
34
CHAPTER 4. TECHNICAL BACKGROUND
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
CHAPTER 4. TECHNICAL BACKGROUND
36
CHAPTER 4. TECHNICAL BACKGROUND
• 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:
* 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).
37
CHAPTER 4. TECHNICAL BACKGROUND
• 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
CHAPTER 4. TECHNICAL BACKGROUND
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
CHAPTER 4. TECHNICAL BACKGROUND
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
CHAPTER 4. TECHNICAL BACKGROUND
41
CHAPTER 4. TECHNICAL BACKGROUND
• 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].
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
CHAPTER 4. TECHNICAL BACKGROUND
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.
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
CHAPTER 4. TECHNICAL BACKGROUND
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
CHAPTER 4. TECHNICAL BACKGROUND
The following list has some of the benefits that network slicing brings to the network:
• Allows selecting specific applications and services by tuning of the network, making
better the user experience.
• 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
CHAPTER 4. TECHNICAL BACKGROUND
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.
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.
• 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:
48
CHAPTER 5. DEPLOYMENT
- 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).
• 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
CHAPTER 5. DEPLOYMENT
• 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:
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.
• 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
CHAPTER 5. DEPLOYMENT
• 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.
51
CHAPTER 5. DEPLOYMENT
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:
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
CHAPTER 5. DEPLOYMENT
53
CHAPTER 5. DEPLOYMENT
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
CHAPTER 5. DEPLOYMENT
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:
In order to implement the connectivity of the IPU VM and being compliant with the load
55
CHAPTER 5. DEPLOYMENT
• 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
CHAPTER 5. DEPLOYMENT
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
CHAPTER 5. DEPLOYMENT
• 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
CHAPTER 5. DEPLOYMENT
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:
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:
• 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
CHAPTER 5. DEPLOYMENT
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
CHAPTER 5. DEPLOYMENT
61
CHAPTER 5. DEPLOYMENT
62
CHAPTER 5. DEPLOYMENT
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
CHAPTER 5. DEPLOYMENT
SET BFD:BFDENABLE=TRUE;
This command enables a BFD session for each of the interfaces of the nodes which
uses BFD.
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 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.
This command allows to add or remove a logical interface and set parameters.
• Modify interfaces:
64
CHAPTER 5. DEPLOYMENT
This command is used to add a new Ethernet sub-interface and associate it with a
VLAN already created.
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.
65
CHAPTER 5. DEPLOYMENT
66
CHAPTER 5. DEPLOYMENT
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.
67
CHAPTER 5. DEPLOYMENT
vUGW #
Operation and Maintenance 29
Routing And Network 10
Basic Services 21
Radius Management 11
Charging Management 3
TOTAL: 74
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:
• Faraday cages.
• 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
CHAPTER 5. DEPLOYMENT
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:
69
CHAPTER 5. DEPLOYMENT
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
CHAPTER 5. DEPLOYMENT
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:
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:
71
CHAPTER 5. DEPLOYMENT
72
CHAPTER 5. DEPLOYMENT
• Activation the license to support for voice, via CS-Fallback (CSFB) with the following
Man-Machine Language (MML) command:
• MME configuration: set SGs links and map TAIs and LAIs
• 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
CHAPTER 5. DEPLOYMENT
Figure 5.24: T01-0201 Combined Attach Traces.
CHAPTER 5. DEPLOYMENT
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.
[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
CHAPTER 5. DEPLOYMENT
[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.
[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
CHAPTER 5. DEPLOYMENT
[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.
[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
CHAPTER 5. DEPLOYMENT
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:
[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.
1 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
2 * vUSN 4 G - Combined Attach
3 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
4
5 -------------------------------------------------------------
6 Frame :
7
78
CHAPTER 5. DEPLOYMENT
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
79
CHAPTER 5. DEPLOYMENT
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
80
CHAPTER 5. DEPLOYMENT
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
112 Element ID : 0 x50
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)
116 Mobile Country Code ( MCC ) : Spain (214)
117 Mobile Network Code ( MNC ) : Vodafone Espana , SAU (01)
118 MME Group ID : 32769
119 MME Code : 192
120 M - TMSI : 0 xe40d21eb
121 Tracking area identity - Last visited registered TAI
122 Element ID : 0 x52
123 Mobile Country Code ( MCC ) : Spain (214)
124 Mobile Network Code ( MNC ) : Vodafone Espana , SAU (01)
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
81
CHAPTER 5. DEPLOYMENT
82
CHAPTER 5. DEPLOYMENT
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
CHAPTER 5. DEPLOYMENT
84
CHAPTER 5. DEPLOYMENT
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 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:
• 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)
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
CHAPTER 5. DEPLOYMENT
Figure 5.27: T01-1101 Online Charging - Interface S11.
CHAPTER 5. DEPLOYMENT
[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
87
CHAPTER 5. DEPLOYMENT
16 IMSI : 214019821668983
17 Mobile Country Code ( MCC ) : Spain (214)
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
CHAPTER 5. DEPLOYMENT
[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 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
2 * vUGW 3 G - T01 -1101 Real - Time Charging User Services
3 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
4
5 -------------------------------------------------------------
6 Frame : 2 - Credit - Control Request - INITIAL_REQUEST
7 -------------------------------------------------------------
89
CHAPTER 5. DEPLOYMENT
90
CHAPTER 5. DEPLOYMENT
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
51 Mobile Country Code ( MCC ) : Spain (214)
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.
The content of this package is in the Trace 5.4:
[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 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
2 * vUGW 3 G - T01 -1101 Real - Time Charging User Services
3 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
4
91
CHAPTER 5. DEPLOYMENT
5 -------------------------------------------------------------
6 Frame : 3 - Credit - Control Answer - INITIAL_REQUEST
7 -------------------------------------------------------------
8
92
CHAPTER 5. DEPLOYMENT
[10] This trace is a GTP respons with a Create PDP Context Response. This packect indicates
that the PDP contect has been created.
The content of this package is in the Trace 5.5:
[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 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
2 * vUGW 3 G - T01 -1101 Real - Time Charging User Services
3 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
4
5 -------------------------------------------------------------
6 Frame : 10 - Credit - Control Respons - INITIAL_REQUEST
7 -------------------------------------------------------------
8
9 Frame 10: 171 bytes on wire (1368 bits ) , 171 bytes ...
captured (1368 bits )
10 Internet Protocol Version 4 , Src : x.x.x.x , Dst : y.y.y.y
93
CHAPTER 5. DEPLOYMENT
94
CHAPTER 5. DEPLOYMENT
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
CHAPTER 5. DEPLOYMENT
Figure 5.28: T01-1101 Online Charging - Interface Gy.
CHAPTER 5. DEPLOYMENT
[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 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
2 * vUGW 3 G - T01 -1101 Real - Time Charging User Services
3 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
4
5 -------------------------------------------------------------
6 Frame : 3 Interface Gy - Credit Control Request - ...
UPDATE_REQUEST
7 -------------------------------------------------------------
8
97
CHAPTER 5. DEPLOYMENT
98
CHAPTER 5. DEPLOYMENT
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:
[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 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
2 * vUGW 3 G - T01 -1101 Real - Time Charging User Services
3 * - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -*
4
5 -------------------------------------------------------------
6 Frame : 5 Interface Gy - Credit Control Answer - ...
UPDATE_REQUEST
7 -------------------------------------------------------------
8
99
CHAPTER 5. DEPLOYMENT
100
CHAPTER 5. DEPLOYMENT
101
CHAPTER 5. DEPLOYMENT
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
CHAPTER 5. DEPLOYMENT
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.
103
CHAPTER 5. DEPLOYMENT
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.
106
A
A BBREVIATIONS
VM Virtual Machine
107
APPENDIX A. ABBREVIATIONS
HW Hardware
SW Software
IP Internet Protocol
WO Web Optimization
VO Video Optimizatin
108
APPENDIX A. ABBREVIATIONS
PB Petabytes
SA Stand-Alone
GA General Available
ES Early Start
LS Late Start
EF Early Finish
LF Late Finish
E2E End-to-End
109
APPENDIX A. ABBREVIATIONS
E/W East-West
NE Network Element
110
APPENDIX A. ABBREVIATIONS
UE User Equipment
CS Circuit Switching
PS Packet Switching
CSFB CS-Fallback
111
APPENDIX A. ABBREVIATIONS
DL Down Link
UL Up Link
112
APPENDIX A. ABBREVIATIONS
113
B
A DDITIONAL I NFORMATION
115
APPENDIX B. ADDITIONAL INFORMATION
116
APPENDIX B. ADDITIONAL INFORMATION
117
APPENDIX B. ADDITIONAL INFORMATION
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
120
APPENDIX C. CASES LIST
121
APPENDIX C. CASES LIST
122
APPENDIX C. CASES LIST
123
APPENDIX C. CASES LIST
T29 ODB
T29-01 Packet Service Barring
T29-0101 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
T38-0101 APN-based Signaling Congestion Control
T39 Null-MSISDN Function Supported by the SGSN
124
APPENDIX C. CASES LIST
125
APPENDIX C. CASES LIST
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
APPENDIX C. CASES LIST
127
APPENDIX C. CASES LIST
128
APPENDIX C. CASES LIST
129
APPENDIX C. CASES LIST
130
APPENDIX C. CASES LIST
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
T18-0101 Packet Service Barring
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
APPENDIX C. CASES LIST
132
APPENDIX C. CASES LIST
133
APPENDIX C. CASES LIST
134
APPENDIX C. CASES LIST
135
APPENDIX C. CASES LIST
vUGW
136
APPENDIX C. CASES LIST
137
APPENDIX C. CASES LIST
138
L IST OF F IGURES
139
LIST OF FIGURES
140
L IST OF TABLES
141
L IST OF T RACES
143
B IBLIOGRAPHY
[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.
[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
report, Huawei Technologies Co.,Ltd, 2018.
[16] Huawei. Cloudugw v100r018c10: Operation guide (ggsn, s-gw, p-gw and rgw-basic part).
Technical report, Huawei Technologies Co.,Ltd, February 2018.
[18] Huawei Hedex Lite. Cu separation solution. Technical report, Huawei Technologies
Co.,Ltd, 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]".
[22] Muhammad Raza. What is software defined networking? sdn explained. "https://www.
bmc.com/blogs/software-defined-networking/", "[Online; Accessed 3-May-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
[32] Balamurali Thekkedath. Network Functions Virtualization for Dummies. Special edition,
2016.
[35] Vodafone and Huawei. High level design for vodafone spain vepc trial project. Technical
report, Huawei Technologies Co.,Ltd, 2016.
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.
149