Content uploaded by Abhishek Gupta
Author content
All content in this area was uploaded by Abhishek Gupta on Jan 19, 2018
Content may be subject to copyright.
Virtual-Mobile-Core Placement for Metro Network
This is a preprint electronic version of the article submitted to IEEE NetSoft 2018
Abhishek Gupta∗, Massimo Tornatore∗ ‡, Brigitte Jaumard†, and Biswanath Mukherjee∗
∗University of California, Davis, USA †Concordia University, Canada ‡Politecnico di Milano, Italy
Email: ∗{abgupta,mtornatore,bmukherjee}@ucdavis.edu †bjaumard@cse.concordia.ca ‡massimo.tornatore@polimi.it
Abstract—Traditional highly-centralized mobile core networks
(e.g., Evolved Packet Core (EPC)) need to be constantly upgraded
both in their network functions and backhaul links, to meet
increasing traffic demands. Network Function Virtualization
(NFV) is being investigated as a potential cost-effective solution
for this upgrade. A virtual mobile core (here, virtual EPC,
vEPC) provides deployment flexibility and scalability while
reducing costs, network-resource consumption and application
delay. Moreover, a distributed deployment of vEPC is essential for
emerging paradigms like Multi-Access Edge Computing (MEC).
In this work, we show that significant reduction in network-
resource consumption can be achieved as a result of optimal
placement of vEPC functions in metro area. Further, we show
that not all vEPC functions need to be distributed. In our
study, for the first time, we account for vEPC interactions
in both data and control planes (Non-Access Stratum (NAS)
signaling procedure Service Chains (SCs) with application latency
requirements) using a detailed mathematical model.
I. INTRODUCTION
Mobile network operators are experience increase in traffic
as result of new and emerging bandwidth-intensive applica-
tions. This creates challenges for the Evolved Packet Core
(EPC) (i.e., the current state-of-the-art mobile core network)
where the complex dependencies among various EPC elements
lead to scalability issues for increasing traffic demand and
result in frequent upgrades of costly proprietary hardware.
Network Function Virtualization (NFV) virtualizes network
functions (called Virtual Network Functions, VNFs) and runs
them on commodity hardware. Also, EPC functions can be
virtualized into VNFs to provide cost savings, flexibility, and
ease of deployment of EPC. We refer to EPC implemented
using VNFs as virtual EPC (vEPC). In order to understand the
possible VNF inter-dependencies and interactions in vEPC, we
must discuss what a traditional EPC is and how it functions.
Evolved Packet Core (EPC) is the end-to-end IP-based
mobile core network infrastructure. Fig. 1 shows an EPC,
its functional entities and interfaces. Delineation between
control and data planes is an important aspect of EPC and
will be discussed further in the paper. Mobility Management
Element (MME), Policy and Charging Rules Function (PCRF),
and Home Subscriber Server (HSS) are EPC control plane
elements. Serving Gateway (SGW) and Packet Data Network
Gateway (PGW) are EPC data plane elements but also have
tightly coupled control plane functions. In this work, we
consider vEPC to have VNFs for MME, PCRF, HSS, SGW
and PGW.
UE connects to Internet (or in general to an external
network) through EPC. The data path (bearer) to the Internet
Fig. 1: Evolved Packet Core (EPC).
for a UE is setup as a result of control plane signaling
procedures called Non-Access Stratum (NAS) procedures.
NAS is a layer-3 protocol for mobile networks, responsible
for management and modification of bearers. The types of
EPC functions involved in a NAS procedure depend on the
UE signaling event. Thus, there are different NAS procedures,
such as Attach, Dedicated bearer setup, X2-based handover,
S1-based handover etc. as detailed in [1]. It has been shown
that it is very important to consider NAS procedures in the
control plane, as a slight increase (e.g.,1%) in the control
plane signaling can result in a significant decrease (70%) in
data plane capacity [2]. This happens because SGW while
handling all data plane traffic is also involved in 33% [2] of all
control plane transactions. A highly-loaded SGW can become
a bottleneck which affects data path throughput and increases
control plane latency.
Figure 2(a) shows the NAS Attach Procedure, where all EPC
functions are involved in control signaling. Here, signaling
proceeds to next function only after it has been processed by
current function. So, control plane signaling can be charac-
terized as a chained sequence of interactions between EPC
functions. We refer to this chained sequence of interactions in
the control plane as a Control Service Chain (CSC)1. Fig. 2(b)
shows the corresponding CSC for attach procedure.
NAS attach procedure completion results in a data path
1The term “Service Chain”(SC)[3] is usually used for value-added services
(Firewall, Video Optimization etc.). We use “Service Chain” here since an
ordered sequence of functions is similar to chained sequence of interactions
between functions.
arXiv:1801.05537v1 [cs.NI] 17 Jan 2018
(a) Simplified NAS Attach Procedure[1]
(b) Attach Control Service Chain (CSC)
(c) Data Service Chains (DSCs) (d) Stateful VNFs in Attach CSC
Fig. 2: NAS Procedure, control and data Service Chains (SCs)
(bearer) for UE to Internet. Note that control-plane latency
requirements for each NAS procedure depends on whether a
default or dedicated bearer is setup which is used for upload
and download. The UE upload traffic reaches eNodeB and is
directed to SGW. SGW is the mobility anchor for eNodeB’s,
and hence, upload traffic has to traverse SGW first, then PGW
to reach Internet as shown in Fig. 1. If a UE downloads data,
SGW and PGW are traversed in reverse order. Fig. 2(c) shows
the Data Service Chains (DSCs) for upload and download.
An important aspect of EPC functions is that they are
stateful. They need to maintain session information, i.e., UE
and bearer state and internal database states, which might be
different between instances of the same function. For example,
there could be two VNF instances for MME, where the first
MME (MME(1)) holds session information for a different set
of UE from the second MME (MME(2)). For NAS Attach
procedure shown in Fig. 2(a) the EPC function interactions
happen with the same instance of EPC functions as seen
in Fig. 2(d) (1 indicating a single instance). The required
number of instances of a function will depend on the NAS
procedure. This is an important distinction between EPC
SCs and traditional (e.g., value-added) SCs where the VNFs
are stateless. In this work, we solve vEPC placement with
stateful VNFs unlike previous works (e.g., our work in [4])
for traditional SCs. We account for stateful VNFs by tracking
the VNF instance in our model.
In this paper, we propose an Integer Linear Program (ILP)
to reduce network-resource consumption in metro core while
accounting for control and data plane interactions of UEs and
satisfying application latency requirements through the optimal
placement of vEPC function replicas. This model allows us to
show that having distributed vEPC replicas reduces network-
resource consumption and not all vEPC functions need to be
distributed.
The rest of this study is organized as follows. Section II
describes our network architecture. Section III summarizes
existing literature on vEPC placement problem and remarks
on the novelty of this study. Section IV provides details on
problem definition, input parameters and ILP model. Section
V details illustrative examples.
II. NE TWORK ARCHITECTURE
We assume a metro-core mesh connected to 2 aggregation
rings to be our network architecture as shown in Fig. 4(a).
Traffic from UEs is aggregated at Traffic Aggregation Points
(TAPs) (shown in green). Aggregated UE traffic forms traffic
flows that originate at a TAP and terminate at a application
gateway or vice-versa. Application gateways in our architec-
ture are peering points of the mobile core with other networks.
For example, video traffic will go to application gateway that
peers with the network that has the video content.
If all applications require traffic to be routed to mobile
core to reach desired application gateway, network-resource
consumption will increase with traffic demand. To avoid
routing to mobile core, we need to host applications closest
to the edge, i.e., in aggregation rings. So, in Fig. 4(a) we
include two Multi-Access Edge Computing (MEC)2[5] nodes
for hosting applications.
III. REL ATED WO RK S
A few studies already exist for the vEPC-placement prob-
lem. Ref. [6] were the first to address the vEPC placement
problem. They model vEPC functions as service chains but
do not account for NAS procedures in control plane and
upload and download in data plane, modeling service chaining
explicitly, stateful nature of vEPC elements and application
latency. Ref. [7] proposes combined network function and
vEPC placement while accounting for vEPC function mapping
to eNodeB. A mathematical model and heuristic are proposed,
however this work also has same set of limitations as Ref. [6].
Other works, while not solving vEPC placement directly,
provide useful insights. Ref. [2] emulates vEPC functions and
shows that SGW is a bottleneck in EPC, and proposes a better
functional design for vEPC. Ref. [8] demonstrates virtual
SGW and PGW placement using a simulation framework,
but do not provide details of algorithm for VNF placement.
Ref. [9] focuses on minimizing SGW relocations without
considering control and data plane interactions of other EPC
network functions.
2MEC is an emerging paradigm which aims to reduce network-resource
consumption and improve application latency by deploying cloud-based IT
services at network edge.
Fig. 3: Application flow requesting upload with NAS procedure
To the best of our knowledge, this is the first attempt to
account for control and data plane interactions and application
latency for optimal placement of vEPC replicas in a metro
network.
IV. PROBLEM DESCRIPTION
A mobile network operator requires an EPC for connecting
UE to Internet and to provide these services EPC network
functions have to engage in control signaling (chained requests
or Control SC (CSC)) for data path (Data SC (DSC)) setup.
We develop a Integer Linear Programming (ILP) model for
optimal placement of vEPC functions which accounts for
latency requirements of applications, control and data plane
interactions and statefulness of EPC VNFs, number of VNF
replicas available and nodes allowed to host VNFs.
A. Problem Statement
Given a network topology, capacity of links, a set of network
nodes with NFV support (NFV nodes), compute resources
at NFV nodes, number of NFV nodes that can be used,
aggregated traffic flows using a NAS procedure and requesting
an application, and latency requirements for application and
control signaling, we determine the placement of vEPC VNFs
and traffic routing to minimize network-resource (bandwidth)
consumption.
B. Input Parameters
GPhysical topology of backbone network
G= (V, L)with V: node set and L: link set
SD Set of source-destination (vs, vd)pairs
VNFV ⊆VSet of nodes that can host VNFs (NFV nodes)
nCOR E Number of CPU cores present in a NFV node
FSet of VNFs, indexed by f
RfMaximum number of replicas of VNF f
nCOR E
fNumber of CPU cores per Gbps for function f
CSet of chains, indexed by c
ncNumber of VNFs in SC c
χc
fNumber of instances of VNF frequired by c
SDcSource-destination (vs, vd)pair for SC c
fc
sVNF for vsin SC c
fc
dVNF for vdin SC c
DcTraffic demand for SC c
σi(c)ID of ith VNF in SC c,
where fσi(c)∈F
Tci
fVNF ID (f) of the ith VNF in SC c
∆PRO C
fProcessing latency for function f
∆PRO G
`Propagation latency for link `
θi(c)Instance used for ith VNF with ID fin SC c,
where θi(c)∈ {1,2, . . . , χc
f}
βc
iFraction of Dcbetween iand (i+ 1)th VNF
for SC c
LcLatency requirement for SC c
C. Variables
xcj
vi 1 if instance jof ith function fiof c is located
in v∈VNFV (responsible for stateful VNFs)
1 if ith function fi∈ {fc
s, f c
d}is located in v∈ SDc
0 otherwise
xvf 1 if function fis located in v∈VN F V ; 0 otherwise
yc
i` 1 if `is on the path from location of fi
to location of fi+1, 0 otherwise.
D. Problem Modeling
We consider aggregated traffic at Traffic Aggregation Points
(TAPs) in G. For upload vsis a TAP and vdis a application
gateway (opposite for download).
We consider that application flows request upload or down-
load for an application and may or may not require a NAS
procedure. To simplify formulation, we define a SC cin
our ILP as consisting of (vs, vd)pairs, NAS Control SC,
Upload/Download Data SC and application as shown in Fig.
3. Our ILP considers SC cas a sequence of VNFs. This also
includes (vs, vd)which are source-destination nodes and are
not VNFs. To mitigate this challenge, we create functions fc
s
and fc
dto represent source vsand destination vdrespectively.
VNFs fc
sand fc
dhave the only requirement of being located
at vsand vdrespectively.
Fig. 3 shows a application flow for upload with NAS
procedure. Here, control traffic originates from VNF fc
s(which
represents source node vs) and traverses NAS CSC. After the
traversal, control traffic reaches fc
sto notify that data path
is setup. Since application traffic requests upload, the upload
DSC is to be traversed on data path to destination (here,
application gateway). Total latency requirement Lcfor SC c
is “control plane latency + application latency”. When chas
no NAS procedure, Lcequals application latency.
Our formulation of the vEPC placement problem results in
an Integer Linear Program (ILP) as detailed in the following.
Objective: Minimize bandwidth consumed:
X
c∈C
X
`∈L
nc−1
X
i=1
Dcβc
iyc
i` (1)
Give total network-resource consumed in routing multiple SCs.
xcj
vi = 1 c∈C, v ∈ SDc, j =θi(c)
(a) Network topology [8]
(b) Bandwidth vs. number of vEPC replicas
(c) Bandwidth vs. number of VNF replicas
Fig. 4: Simulation topology and results
i∈ {1,2, . . . , nc}:fi∈ {fc
s, f c
d}(2)
xcj
vi = 0 c∈C, v ∈ SDc:v /∈VNFV , j =θi(c),
i∈ {1,2, . . . , nc}:fi/∈ {fc
s, f c
d}(3)
X
v∈VNFV
xcj
vi = 1 c∈C, j =θi(c),
i∈ {1,2, . . . , nc}:fi/∈ {fc
s, f c
d}(4)
Eq. (2) enforces VNFs (fc
s, f c
d)be placed on (vs, vd)respec-
tively while Eq. (3) avoids placing vEPC VNFs on (vs, vd)if
they are not NFV nodes. Eq. (4) ensures that all vEPC VNFs
in care placed at exactly one node.
The next constraints are flow conservation ones and are
responsible for explicit service chaining.
X
`∈ω+(v)
yc
i` −X
`∈ω−(v)
yc
i` =xcj
vi −xcj
v,i+1
c∈C, v ∈ {VNFV ∪ S Dc}, j =θi(c),
i= 1,2, . . . , nc−1(5)
X
`∈ω+(v)
yc
i` −X
`∈ω−(v)
yc
i` = 0
c∈C, v ∈V\ {VNFV ∪ S Dc},
i= 1,2, . . . , nc−1(6)
Mxvf ≥X
c∈C:f∈c
X
i∈{1,2,...,nc}:
fi=f,j=θi(c)
xcj
vi ≥xvf
v∈VNFV , f ∈F(7)
X
v∈VNFV
xvf ≤Rff∈F(8)
Eqs. (7) and (8) keep track of VNF replicas.
X
c∈C
Dc
nc
X
i=1,j=θi(c)
βc
i−1xcj
vi Tci
f:fi/∈{fc
s,fc
d}nCOR E
f≤nCOR E
v∈VNFV (9)
X
c∈C
Dc
nc−1
X
i=1
βc
iyc
i` ≤CA P``∈L(10)
X
`∈L
nc−1
X
i=1
∆propag
lyc
i` +
nc
X
i=1
βc
i−1Dc∆proc
fTci
f:fi/∈{fc
s,fc
d}
≤Lcc∈C. (11)
Eq. (9) bounds total CPU resource consumption by VNFs at a
node. Eq. (10) constrains total network-resource consumed in
routing SCs at a link. Eq. (11) enforces that the total latency
incurred in propagation across links and processing by VNFs
for each SC does not exceed latency bounds.
Application Traffic %
Progressive video (buffered streaming) 71.19%
Video conferencing 4.56%
VoIP 1.50%
Media downloads 13.3%
Non-real-time application (web,email) 9.45%
TABLE I: Application traffic [10]
NAS procedure Flows Bearer Latency (ms)
Attach 10 Default 500
Dedicated bearer request 45 Dedicated 250
X2-based handover 5 Default 500
S1-based handover 10 Default 500
TABLE II: Traffic flow NAS procedure requirements [10]
V. I LL US TR ATIV E NUMERICAL EXAMPLES
We run our simulations on the 19 node topology shown
in Fig. 4(a). The application gateways shown in Fig. 4(a)
are selected based on Table I and are shown in red, green
nodes are TAPS and black nodes are switches. We add Multi-
Access Edge Computing (MEC) sites at node 12 and 8 for
progressive video. This decision is taken as progressive video
has highest traffic load which MEC can reduce. Table II shows
application traffic flows for NAS procedures ( aggregated from
1000 to 5000 UEs). These traffic flows are associated with a
upload or download DSC. We split the application traffic in
Table I over the flows shown in Table II and 50 flows with
no NAS procedure requirements (i.e., only upload/download).
We consider the upload to download traffic ratio as 1:4 [11].
Latency requirements for applications are taken from [12] and
for NAS procedures depends on bearer type, seen in Table II.
Total traffic is 224 Gb [10]. All nodes are allowed to host
VNFs. Each node is allocated 2400 CPUs. Link capacity is set
to 60 Gbps. Control plane traffic is 5% of data plane traffic i.e.
Bc
i= 0.05 for control plane signaling. For data path Bc
i= 1.0
since all traffic is data traffic. All links are considered optical
fibers of length 50km. Processing latency is 132 µs per Gbps
[13] for each VNF. All VNFs require 2 CPUs per Gbps of
throughput [14].
We run our experiments 10 times and the mean results are
plotted. Fig. 4(b) shows the reduction in bandwidth consump-
tion as the number of allowed vEPC replicas (Eq. (8)) are
increased. We find the largest reduction occurs from 1 to 2
vEPC replicas. This happens because vEPC gets distributed
across aggregation rings which reduces routing to the core,
thereby, resulting in reduction of bandwidth consumption. It
should be noted MEC is a significant factor in bandwidth
usage reduction since applications become available at the
edge. vEPC without MEC would always require routing to
the core and reduction in bandwidth consumption would not
be significant. We find that as the number of replicas are
increased beyond 4, the reduction is not significant as we
reach almost optimal bandwidth consumption by 4 replicas.
Having 2 vEPC replicas reasons to be the best tradeoff between
bandwidth reduction and the overhead and capital expenditure
of deploying more replicas and making more nodes NFV
compatible.
Figure 4(c) shows bandwidth consumption for different
number of VNF replicas. Here, all VNFs have 2 replicas
unless specified on the Y-axis. This tells us that having 1
replica of MME, HSS and PCRF has a negligible effect on
bandwidth consumption in comparison to having 2 replicas of
each (All=2). Hence, we only need to deploy 2 replicas of
PGW and SGW to achieve the same bandwidth reduction as 2
vEPC replicas in Fig. 4(b). This demonstrates that we do not
need to replicate all VNFs to achieve bandwidth reduction.
VI. CONCLUSION
We introduce the problem of vEPC placement while ac-
counting for VNF interactions in control plane and data plane
and application latency. We develop an Integer Linear Program
(ILP) for placement of EPC VNFs and route traffic along
service chains. We demonstrate that there is reduction in
network-resource consumption with increase in number of
VNF replicas. Further, we show that not all EPC VNFs need
to be replicated and that SGW and PGW replication gives
almost the same network resource consumption as replicating
all vEPC VNFs.
ACK NOW LE DG ME NT
This work was supported by NSF Grant No. CNS-1217978.
REFERENCES
[1] 3GPP, “3GPP TS 24.301: 3GPP Non-Access-Stratum (NAS) protocol
for Evolved Packet System (EPS).” [Online]. Available: http:
//www.3gpp.org/DynaReport/24301.htm.
[2] A. S. R. et al., “Understanding the bottlenecks in virtualizing cellular
core network functions,” in IEEE Workshop on LANMAN, 2015.
[3] IETF, “Network service chaining problem statement,” https://tools.ietf.
org/html/draft-quinn-nsc-problem-statement-00, 2013.
[4] A. Gupta, B. Jaumard, M. Tornatore, and B. Mukherjee, “Service chain
(SC) mapping with multiple SC instances in a wide area network,”
CoRR, 2017. [Online]. Available: http://arxiv.org/abs/1704.06716
[5] ETSI, “Mobile-Edge Computing - Introductory Technial White Paper.”
[Online]. Available: https://portal.etsi.org/portals/0/tbpages/mec/docs/
mobile-edge computing - introductory technical white paper v1%
2018-09- 14.pdf
[6] A. Baumgartner, V. S. Reddy, and T. Bauschert, “Mobile core network
virtualization: A model for combined virtual core network function
placement and topology optimization,” in IEEE NetSoft 2015.
[7] D. Dietrich, C. Papagianni, P. Papadimitriou, and J. S. Baras, “Network
function placement on virtualized cellular cores,” in COMSNETS 2017.
[8] F. Z. Yousaf, J. Lessmann, P. Loureiro, and S. Schmid, “SoftEPC
- Dynamic instantiation of mobile core network entities for efficient
resource utilization,” in IEEE ICC 2013.
[9] T. Taleb and A. Ksentini, “Gateway Relocation Avoidance-aware Net-
work Function Placement in Carrier Cloud,” in Proceedings of the 16th
ACM MSWiM ’13.
[10] B. H. et al., “High-performance evolved packet core signaling and bearer
processing on general-purpose processors,” IEEE Network, vol. 29, no. 3,
pp. 6–14, 2015.
[11] ITU, “Report ITU-R M.2370-0: IMT traffic estimates for the years
2020 to 2030.” [Online]. Available: https://www.itu.int/dms pub/itu- r/
opb/rep/R-REP- M.2370-2015- PDF-E.pdf
[12] 3GPP, “3GPP TR23.401 V8.1.0: General Packet Radio Service (GPRS)
enhancements for Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access.”
[13] A. Basta, W. Kellerer, M. Hoffmann, H. J. Morper, and K. Hoffmann,
“Applying NFV and SDN to LTE mobile core gateways, the functions
placement problem,” in ACM Proceedings of the 4th workshop on All
things cellular: operations, applications, & challenges 2014, pp. 33–38.
[14] Brocade, “Brocade vEPC.” [Online]. Available:
https://www.brocade.com/content/dam/common/documents/
content-types/datasheet/brocade- vepc-ds.pdf
