5GC+: an Experimental Proof of a Programmable Mobile Core for 5G

Abstract

The telecom industry is striving to evolve the current 4G system to the 5th generation of mobile networks, aiming at boosting data rates and performance for the traditional broadband services, as well as supporting a wide range of new use cases with different technical requirements. The first specifications of the 5G system are included in 3GPP's Release 15 and expected to be enhanced in the future Release 16. In order to cater for the diverse network requirements posed by the 5G use cases and in the view of instantiating customized networks that suit the vertical industry, a programmable and flexible data plane is envisioned as a key element of the future system architecture. In this context, this paper presents an advanced core network design underpinned by SDN principles, introducing enhancements to the current mobile networks' functional architecture and leveraging programmatic approaches for the agile provisioning and re-configuration of customized data planes. Our proposal is substantiated and validated by means of an initial experimental prototype, carrying out a functional proof of concepts including commercial 4G cellular base stations and devices.

Full text

5GC+: an Experimental Proof of a
Programmable Mobile Core for 5G
Umberto Fattore, Fabio Giust, Marco Liebsch
NEC Laboratories Europe GmbH, Germany
E-mail: {name.surname}@neclab.eu
Abstract—The telecom industry is striving to evolve the current
4G system to the 5th generation of mobile networks, aiming
at boosting data rates and performance for the traditional
broadband services, as well as supporting a wide range of
new use cases with different technical requirements. The first
specifications of the 5G system are included in 3GPP’s Release
15 and expected to be enhanced in the future Release 16. In order
to cater for the diverse network requirements posed by the 5G use
cases and in the view of instantiating customized networks that
suit the vertical industry, a programmable and flexible data plane
is envisioned as a key element of the future system architecture.
In this context, this paper presents an advanced core network de-
sign underpinned by SDN principles, introducing enhancements
to the current mobile networks’ functional architecture and
leveraging programmatic approaches for the agile provisioning
and re-configuration of customized data planes. Our proposal is
substantiated and validated by means of an initial experimental
prototype, carrying out a functional proof of concepts including
commercial 4G cellular base stations and devices.
I. INTRODUCTION
The incessant demand of Internet-based services has pro-
duced an unprecedented data traffic volume which keeps
growing year after year. Such growth has been shown to be
even more evident in mobile networks, registered to be 18-
fold in the past 5 years [1]. The trend is not supposed to
slow down, given the huge penetration of 4G devices and the
foreseen increasing number of 4G connections, and, in order to
cope with the phenomenon, the telecom industry is constantly
seeking to evolve their infrastructure, catering for higher data
rates and enhanced services to their subscribers.
In line with such evolutionary path, in late 2015, the
International Telecommunication Union (ITU) has finalized
its vision of the 5G mobile broadband connected society, by
setting the requirements and the supported uses cases for the
future 2020 International Mobile Telecommunication (IMT)
system1. Along with the IMT-2020 road map set by ITU,
the 3rd Generation Partnership Project (3GPP) has recently
included 5G system specifications in its recent Release 152.
The 5G system is expected to be very different from the
previous generations. In fact, the proliferation of stationary and
mobile devices with extremely diverse duty cycles, communi-
cation and mobility patterns, as well as energy constraints, is
1Refer to https://www.itu.int/en/ITU-R/study-groups/rsg5/rwp5d/imt- 2020/
Pages/default.aspx
2refer to http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1937-5G
DESCRIPTION
supposed to populate the new 5G ecosystem. This comes in
response to a plethora of novel use cases from unconventional
stakeholders and their associated business models, which pose
a complex set of diverse network requirements, such as low
latency communication, edge computing, as well as support
of energy-constrained stationary and mobile devices [2].
Among the key features of the coming 5G systems, the
industry demands programmability and flexibility: network
operators seek mobile systems that allow faster service pro-
visioning, easier maintenance, improved scalability, as well
as the ability to customize networks and efficiently adapt to
the mentioned vertical customers’ requirements [2]. Software
Defined Networking (SDN) and Network Function Virtualiza-
tion (NFV) go hand in hand for the provisioning, maintenance
and scale of infrastructure, network functions and services.
For such characteristics, SDN/NFV have been employed by
the research community to re-engineer the Evolved Packet
Core (EPC), the current 4th generation for mobile commu-
nications [3] and such effort has been a fundamental path to
build the 5G specifications included in 3GPP’s Release 15.
Taking into account the considerations above, in this paper
we propose our advanced 5G Core (5GC+), a mobile network
core architecture that supports a programmable mobile core.
Such an architecture leverages SDN to treat the data plane
nodes distributed within the mobile network as policy en-
forcement points able to handle and steer user traffic based on
policies such as for QoS, packet encapsulation, path switching,
or charging. By doing so, the proposed data plane nodes
incorporate the functions of today’s mobile network gateways,
introduce a much higher level of flexibility and are able to
serve different radio access technologies (RATs). This work
explores also the control plane counterpart needed to enable
our novel data plane concepts. Our solution is validated by
means of an experimental proof of concept, implementing the
proposed core network design and employing commercial 4G
base stations and devices.
In the rest of the paper, Section II gives an overview of mo-
bile network architectures as specified by standard developing
organizations (SDOs) as well as other related work. Section III
presents our solution, describing the compatibility with 4G and
5G access technologies, the functional architecture and the
operations. The description of the system’s proof of concept
and preliminary experimental results are found in Section IV,
before concluding the paper in Section V.

II. ARCHITECTURES FOR THE MOBILE PACKET CORE
As 5G is still in a preliminary phase, only few deployments
exist, yet targeting field trials. Thus, the state of the art of
mobile network for large scale commercial deployments is
still based on Long Term Evolution (LTE/LTE-A) and on the
EPC [3]. According to the EPC architecture, user data packets
are transported by means of bearers, which consist on a chain
of transport tunnels built with the GPRS Tunneling Protocol
for User Plane (GTP-U) [4] between a Packet Data Network
Gateway (PDN-GW, PGW) and a Serving Gateway (SGW)
and between the SGW and the radio base station (eNB), which
the User Equipment (UE) is currently connected to. Simply
put, a bearer is a point to point connection between a UE and
the PGW associated to the PDN (e.g., Internet) that the UE
aims at connecting to. In order to gain access to additional
PDNs, a new bearer for each PDN is set up, and other PGWs
are associated to the user. A unique IP address is assigned
to the UE for each bearer, and the corresponding PGW acts
as the IP anchor for such address, thus creating a 1-to-1-to-1
mapping between the PDN to be accessed, the PGW for such
PDN, and the UE’s IP address to be used. One of the largest
limitations of such architecture is that all user data packets
between a UE and a PDN must traverse a single PGW, posing
scalability problems and sub-optimal routing. Also, different
PDNs require different PDN connections, thus exacerbating
the complexity of the devices.
The Control/User Plane Separation (CUPS) of the EPC
gateways, specified in [5], aims at introducing more flexi-
bility on the deployment of the EPC functional entities, by
decoupling control plane functions from the data plane ones.
This copes partially with the limitations above, as it allows to
effectively leverage the latest softwarization trends and cloud-
native network functions implementations, but, still it is bound
to the bearer and PDN connection concept.
Besides fully embracing CUPS, by defining the mobile core
gateway as a Session Management Function (SMF) controlling
a User Plane Function (UPF), the 5G system specifications [6]
take a step further towards the above mentioned flexibility.
Specifically, session management in 5G allows two methods
to bind a Packet Data Unit (PDU) session (i.e., the evolution
of a PDN connection) to multiple PDU session anchors, i.e.,
UPFs interfacing the same or different data networks. The first
method is through the SMF inserting one additional UPF in the
data path, acting as uplink classifier able to steer user packets
towards multiple PDU session anchors (UPFs). In the second
method, a PDU session is associated to multiple IPv6 prefixes
(i.e., multi-homed), and each prefix is anchored at a different
UPF. Also in this case, an UPF is inserted at a common point
where all the data paths branch out, and such UPF is said to
support branching point functionalities.
Leveraging multiple anchors based on the IPv6 prefixes
associated to a connection is the baseline concept for the
Distributed Mobility Management (DMM) solution in [7]. The
DMM working group within the Internet Engineering Task
Force (IETF) has pioneered the work towards evolving the
architecture for mobile networks, as documented in [8], [9].
Besides the aforementioned group draft, [10] targets the CUPS
problem space, by defining an abstraction of a forwarding
device’s configuration from the control plane’s perspective,
allowing for instance the latter to program the data plane
through the usage of network controllers.
Beyond those from SDOs, many other ideas have been
proposed, mainly targeting the 4G architecture but still mean-
ingful towards the definition of 5G. The key point of such
proposals is the implementation of the already mentioned
CUPS and the introduction of SDN and NFV technologies, in
order to obtain a flexible data plane programmed by the control
plane. In this way, new scenarios are enabled in the core
network (e.g. data packet routing optimization). The survey
in [11] collects many of those proposals.
Nevertheless, softwarizing-enable technologies (i.e. SDN)
typically lack of native support to GTP-U tunneling in the
mobile core. Despite its recognized drawbacks, the GTP
protocol is still considered in the latest 5G specifications [6] as
the reference transport protocol. SBI (South Bound interface)
protocols (e.g. OpenFlow) then need to be extended in order
to be able to define forwarding rules for GTP-U encapsulated
data packets. Despite some proposals go in this direction
(such as [12], [13] and [14]), many other works argue for the
advantages given by a GTP-less data plane. Advantages mainly
are: (1) reducing the complexity and the overhead given by
tunneling, (2) remove the central anchor node concept which
is tightly related to GTP-U endpoints, (3) remove constrained
options to optimize routing, etc. Some of these results are
highlighted in [15]. In [16] a multi-dimensional aggregation
solution for routing and classifying packets without GTP-U
(and any other tunneling protocol) is also presented.
In our 5GC+ solution, we design a mobile core which
includes all the enhancements introduced by 5G, considering
CUPS and implementing the so craved flexibility with the
introduction of data plane programmability. But, on some
aspects, we even go beyond 5G, enabling the use of a plain
IP data plane (as proposed by [17]) offering deployment
flexibility (e.g. no tunneling anchor) and routing efficiency.
Finally, our system is designed in order to fully support 5G
New Radio (NR) interfaces and at the same time keep strong
backward compatibility with 4G Evolved UMTS Terrestrial
Radio Access Network (E-UTRAN).
III. A SO LU TI ON F OR A N OVE L DATA PLA NE
ARCHITECTURE
A. How to efficiently transition from 4G to 5G networks
As it has happened with past generations of mobile net-
works, transitioning to the next technology requires a costly
network upgrade and equipment roll-out (especially targeting
the Radio Access Network – RAN) that in most cases take
place gradually and in an incremental manner. The reason is
rather obvious, since, on the one hand a mobile operator shall
provide service also to its subscribers who have not upgraded
their devices yet (which usually occur to be the largest part for
yet a long time after the new technology has been deployed),

Fig. 1. 5GC+ supporting both 4G E-UTRAN and 5G New Radio
and, on the other hand, the capacity for investments does not
always cope with a massive equipment roll-out in a short time.
In light of the considerations above, the 5G system spec-
ifications (release 15) include a mechanism for operators
to accelerate the penetration of 5G, called Non-standalone
deployment (NSA). With NSA, the user plane traffic of 5G-
enabled mobile device is routed through the 5G New Radio
base stations (called Next-Generation NodeB - gNB), offering
enhanced data rates, whereas the control plane signaling
transits via the legacy LTE. This way, the NR gNB can be
deployed using the legacy EPC as backend infrastructure both
in the control and in the data planes. On the contrary, with the
5G Standalone (SA) network and device standards and their
evolution devised in 3GPP’s Release 16, NR base stations
as well as future enhancement to LTE base stations will be
connected to the 5G core.
Despite the efforts made by the industry to enable a gradual
switch over to 5G, current LTE and LTE-Advanced radios are
envisioned to yet support a huge traffic growth, and it will
take few years to see meaningful 5G shares of the total traffic
volumes [1]. Nevertheless, the intrinsic EPC’s characteristics
make it poorly adequate to tackle future use cases, such as
those involving edge computing. In order to cope with such
scenario, we propose 5GC+, a unified architecture for the
mobile core that connects the 4G and 5G RANs to a single
and more flexible data plane. The purpose is to make some
of the 5G technology enablers, like SDN and NFV paradigm
also available to 4G access.
B. Functional architecture of a mobile packet core to support
dual RAN
Fig. 1 illustrates the main components of 5GC+, the ar-
chitecture proposed in this paper. The depicted architecture
is designed aiming to support both 4G (E-UTRAN) and 5G
(NR) access networks, using the standard interfaces from
3GPP [3], [6]. In the control plane, the architecture inherits
two fundamental component from 5G, which also map some
4G functions to support E-UTRAN as well. Those entities are:
•an Access Management Function (AMF), taking care
of (1) registration management, (2) access authentication
and authorization and (3) security context management,
through the utilization of repositories storing user infor-
mation. This element exchanges control plane messages
with the NR through interface N2, and also implements
part of functionalities of the 4G Mobility Management
Entity (MME), such as terminating the S1-AP interface,
whereas session management is devolved to the SMF;
•aSession Management Function (SMF), responsible
mainly for (1) session establishment, modification, re-
lease and update, (2) IP address allocation for the mobile
user and (3) data plane elements selection. It incorporates
the MME functions related to session management as
well as the SGW control plane (SGW-C).
Our proposal goes beyond standard 5G core architecture, by
leveraging SDN in order to obtain flexible data path selection
and in data plane network programmability. This enables the
SMF for many new additional data plane operations, such as
(1) selection of edge data plane anchors, (2) flexible reloca-
tions of the said edge anchors, (3) traffic steering between
mobile user and services in order to select optimized routes.
An additional element between the control plane and the
data plane is introduced in order to provide data plane ab-
straction: the Network Controller (NC). It receives traffic
rules and policies from the SMF via a North Bound Interface
(NBI), e.g., [10], and translates them to the data plane via the
SBI, e.g. OpenFlow.
The aforementioned NC, interacts with two different types
of Data Plane Node (DPN):
•the Data Network DPN (DN-DPN), which is a forward-
ing device properly settled with traffic rules to access an
external data network;
•the Anchor DPN (A-DPN), which is a forwarding device
located at or in proximity of the access network, and
equipped with some additional functions.
The A-DPN acts as an IP anchor for the the UE’s traffic. The
A-DPN is deployed at the edge of the network and so, in
our 5GC+ solution, the IP anchor is no longer centralized as
it was in 4G (i.e., the PGW). This allows for traffic routing
optimization in the core network. In mobility scenarios, the
control plane changes the A-DPN associated to the user traffic.
More, the A-DPN terminates the S1-U interface with
E-UTRAN and the N3 interface with NR, so it must support
GTP-U encapsulation protocol for data packet. Despite GTP-
U is still meant to be used in 5G, we quote for a plain IP data
plane in our solution (a possible data plane which achieves this
is the Lean Packet System – LeaPS in [17]), in order to avoid
the encapsulation effort and overhead given by using GTP
or other encapsulation protocols. Therefore, the A-DPN also
acts as an endpoint for GTP-U tunneling, allowing backward
compatibility with the access network (both 4G and 5G). To
establish the GTP-U tunnel towards the access network, the
A-DPN needs some additional information to be forwarded by
the control plane: therefore, the SMF needs to utilize a generic
and extensible semantic and operation in order to support
legacy GTP-U mechanism, at least towards GTP-only RAN
elements.

Fig. 2. Attach and handover procedures in 5GC+
C. A closer look on the operational aspects
In order to illustrate the operational aspects of the proposed
5GC+, Fig. 2 depicts the message sequence describing the UE
attach procedure, and the handover procedure (in which the
A-DPN is changed in order to maintain routing optimization).
During the UE attach:
1) The RAN forwards an Attach Request to the AMF.
This message contains UE subscription information and
identifiers, as well as the service(s) requested by the user.
2) The AMF authenticates the mobile user through the
AUSF (Authentication Server Function).
3) A Session Create Request is forwarded to the SMF,
including all the information in previous message (1).
4) The SMF receives the request for a new session and
allocates one or more IP address(es) for the UE session.
More, the SMF selects the A-DPN node at the edge of
the network based on its proximity to the device, and one
or more DN-DPNs, based on the subscribed services or
operator-specific policies.
5) A Session Create Response message is sent back to the
AMF, containing the UE’s IP address(es) and information
(e.g. IP address, identifiers) to reach the A-DPN.
6) Further messages are exchanged between the AMF and
the RAN to finalize the radio link setup. The latter is now
able to reach the A-DPN, through the A-DPN’s Tunnel
Endpoint Identifier (TEID) and IP address to establish
the GTP-U tunnel. In this exchange, the RAN also sends
back its own identifiers (TEID and IP address) in order
to be reached by the core network.
7) A Session Modify Request is received by the SMF,
which now holds all the needed information to build the
complete data path.
8) With a Path Create Request message, the SMF delegates
the NC to instruct the data plane nodes. Thus, this
message contains indication of (a) the selected A-DPN,
(b) the identifier (e.g. TEID tunnel) the A-DPN must use
to be reachable from the access network, (c) the endpoint
information to reach the access network and (d) the other
DN-DPNs in the data paths.
9) The NC instructs both the A-DPN and the DN-DPNs
with the appropriate traffic rules and policies. How such
rules and policies look like depends on the type of
transport implemented by the DPNs. For instance, in
LeaPS [17], plain IP transport is used, with the traffic
handling methods allowed by OpenFlow, used as SBI.
10) A Path Create Response message is sent back to the SMF
as acknowledgment.
11) A Session Modify Response message is returned to the
AMF. This message could be forwarded to the RAN as
acknowledgment.
During a user session, an handover may occur e.g., due to
user mobility. We consider the case of an handover requesting
the selection of a different A-DPN and so the modification of
the first segment of the data path. When the A-DPN changes,
an important issue is to maintain IP session continuity for the
UE, in order to avoid breaking ongoing device sessions. The
following steps are performed:
12) A notification about the handover (triggered by the UE)
is received from the access network.
13) An Handover Request is forwarded to the SMF, indicating
the user session and the new access point.
14) The SMF selects a new A-DPN for the ongoing session.
Again, this could be based on the proximity from the
device or on other reasons (e.g. load balancing).
15) A Path Modify Request message is sent to the NC,

Fig. 3. Overview of the 5GC+ testbed.
indicating the new selected A-DPN, and (if present) other
data path modification (e.g., QoS policy) requested for the
UE traffic.
16) The NC deletes the rules regarding the specific UE from
the previous anchor element A-DPN1.
17) The NC inserts the traffic rules in the new A-DPN (A-
DPN2) and the parameters to establish the GTP-U tunnel
towards the new RAN element.
18) Finally, the NC modifies the traffic rules in the DN-DPNs,
in order to steer the user packets towards the new A-
DPN. Once again, steering the traffic depends on the
transport implemented by the DPNs. For instance, in case
of LeaPS [17], Network Address Translation (NAT) is
employed to re-direct packets through the new path.
19) A Modify Path Response message is sent back to the SMF
as an acknowledgement.
20) An Handover Response is returned to the AMF, contain-
ing the A-DPN endpoint information (i.e. GTP-U tunnel).
21) The information in (20) are forwarded to the RAN, in
order to allow the data path establishment.
IV. EXPERIMENTAL VALIDATION
A. Testbed and software architecture
The architecture presented in Section III has been im-
plemented using OpenEPC3, which provides a 4G-compliant
software platform with EPC components deployed in different
virtual machines, managed by VMWare Workstation4. The
original EPC components have been modified and extended
in order to obtain the software architecture depicted in Fig. 3.
In the radio part, a commercial eNodeB (NEC Orion eNodeB)
and different commercial mobile devices have been used.
In the control plane, the testbed comprises the following:
•MME’, which is obtained from a legacy MME by
appending a GTP stub that terminates all the GTP-C
signaling triggered by the MME. This way, the data path
selection and session management functions are devolved
to the SMF, trough a set of lightweight messages imple-
3https://www.openepc.com/
4https://www.vmware.com/products/workstation-pro.html
mented with the Google Protocol Buffer5and Protobuf-c6
tools, sent by the stub to the SMF. User authentication is
still performed by the MME’.
•SMF, which is obtained extending the control plane
functions of a legacy PGW, deprived of its data plane
functionalities. The SMF receives from the MME’ the
request for a new UE connection, as well as the UE
information for that connection. Its main roles are: (1)
choosing an IP address for the UE, (2) selecting the
data path for UE traffic, both in case of connection
establishment and of A-DPN relocation, (3) instructing
the NC to establish such data path through an NBI based
on [10].
•NC, which is implemented as an OpenFlow v1.37con-
troller using the Ryu8framework. It provides routing in-
structions to the DPNs, based on the indications received
by the SMF.
•HSS, which is a legacy 4G Home Subscriber Server to
perform user authentication.
In our implementation, we have built the transport network
as a plain IP network, following the principles of LeaPS [17],
and, additionally, we have integrated the cellular access. In or-
der to do so, the A-DPN is obtained from the implementation
of a PGW, from which the control plane has been removed and
an Open vSwitch9instance has been incorporated. DN-DPNs
are plain OpenFlow switches.
Since OpenFlow v1.3 does not support GTP, we imple-
mented a custom interface (using Protobuf-c) from the SMF to
the A-DPN to convey (1) the eNodeB’s TEID and IP address
to establish the downlink GTP-U tunnel towards the eNodeB;
(2) The A-DPN’s TEID and IP address to create the uplink
tunnel from the eNodeB.
Moreover, the A-DPN and the DN-DPNs are instructed by
the NC (after indications from the SMF) with appropriate
OpenFlow rules in order to accept the data packets associated
to the UE’s IP address.
In the testbed, two different data network (DN) deployments
have been considered: a cloud data center deployment, in
which the DN is deployed at a remote location outside of the
mobile network domain, and an edge data center deployment,
in which the DN is deployed at the network edge to enable
edge computing scenarios.
B. Preliminary EPC comparison results
The purpose of our experiments is to carry out a proof of
our novel data plane concepts, supporting the main UE-related
procedures (attachment and detachment) with the available
commercial RAN, and showing the advantages of our 5GC+
solution compared to legacy 4G when handling edge comput-
ing deployments.
5https://developers.google.com/protocol-buffers/
6https://github.com/protobuf-c/protobuf-c
7https://www.opennetworking.org/wp-content/uploads/2014/10/openflow-
spec-v1.3.0.pdf
8https://osrg.github.io/ryu/
9https://www.openvswitch.org/

Fig. 4. Packet delay measurements results.
In order to do so, we used 5GC+ and EPC to connect the
UEs to the cloud data center and edge data center DNs, and we
measured the round trip time (RTT) of the user data packets
traveling from the UE to a web server in each of the two Data
Networks (DNs). We added two artificial delays with the tc
(traffic controller) Linux tool10: (1) 25 ms round trip delay on
the link between the eNodeB and the A-DPN; and (2) 50 ms
round trip delay between the A-DPN and the DN-DPN. In the
EPC case, we used the OpenEPC’s SGW and PGW, placed in
conjunction with the A-DPN and the DN-DPN, respectively.
Fig. 4 depicts the mean values of the measured delays, along
with the 5th and the 95th percentile (represented with can-
dlesticks in the graph). In the cloud data center deployment,
both EPC and 5GC+ have similar delay values. This is due
to the fact that in both cases data packets travel through the
whole transport network to reach DN1. Nevertheless, 5GC+
outperforms EPC in the edge data center deployment, due
to the lack of flexibility of the EPC architecture. Indeed, the
PGW (centrally deployed in the core network and IP anchor
for traffic in the EPC) forces data packets to be routed through
it. This is avoided in the case of 5GC+, where traffic is directly
steered by the A-DNA to the near DN2, with evident benefits
in term of delay.
V. CONCLUSIONS AND FUTURE WORKS
While the 5G definition is proceeding in the standard-
ization track, the transition between 4G and 5G is at its
very beginning. The NSA deployment only partially facilitates
this transition. In this paper, we proposed 5GC+, a 5G-
compliant mobile core which fully supports this transition and
which achieves next generation fundamental goals in terms of
flexibility, as highlighted in some preliminary result. Beyond
this, our 5GC+ enables a plain IP data plane network, allowing
for integration with multiple data plane candidates for next
generation core. The already mentioned LeaPS [17] is one of
this candidates.
The integration of other data plane candidates besides
LeaPS in our system is part of our future works. This requires
10from iproute2 package (https://wiki.linuxfoundation.org/networking/iproute2)
changes in the control plane design as well as in the data
plane implementation. Nevertheless, a comparison between
them would shed a light on potential benefits and drawbacks
of each. More, other open issues have not been discussed in
depth in this paper, which would enrich the functionalities of
our proposed system. Among all, further investigations should
address inter-RAT mobility and inter-RAT QoS support.
ACKNOWLEDGMENT
The research leading to these results has been partially
supported by the H2020-MSCA-ITN-2016 framework under
grant agreement number 722788 (SPOTLIGHT).
REFERENCES
[1] Cisco, “Cisco Visual Networking Index: Global Mobile Data Traffic
Forecast Update,” Cisco, White Paper, March 2017. [Online]. Available:
https://www.cisco.com/c/en/us/solutions/collateral/service-provider/
visual-networking- index-vni/mobile-white-paper-c11- 520862.html
[2] R. El Hattachi, J. e. Erfanian et al., “5G White Paper,”
NGMN, White Paper No. 1, February 2017. [Online].
Available: https://www.ngmn.org/fileadmin/ngmn/content/downloads/
Technical/2015/NGMN 5G White Paper V1 0.pdf
[3] 3GPP, “General Packet Radio Service (GPRS) enhancements for
Evolved Universal Terrestrial Radio Access Network (E-UTRAN) ac-
cess,” 3rd Generation Partnership Project (3GPP), TS 23.401, May 2015.
[4] ——, “General Packet Radio System (GPRS) Tunneling Protocol User
Plane (GTPv1-U),” 3rd Generation Partnership Project (3GPP), TS
29.281, Mar 2017.
[5] ——, “Architecture enhancements for control and user plane separation
of EPC nodes,” 3rd Generation Partnership Project (3GPP), TS 23.214,
September 2016.
[6] ——, “System Architecture for the 5G System; Stage 2,” 3rd Generation
Partnership Project (3GPP), TS 23.501, April 2017.
[7] C. J. Bernardos, A. De La Oliva, F. Giust, J. C. Zuniga, and A. Mourad,
“Proxy Mobile IPv6 extensions for Distributed Mobility Management,”
IETF, I-D draft-ietf-dmm-pmipv6-dlif-00, April 2018.
[8] H. Chan, D. Liu, P. Seite, H. Yokota, and J. Korhonen, “Requirements
for Distributed Mobility Management,” Internet Engineering Task Force
(IETF), RFC 7333, August 2014.
[9] D. Liu, J. C. Zuniga, P. Seite, H. Chan, and C. J. Bernardos, “Distributed
Mobility Management: Current Practices and Gap Analysis,” Internet
Engineering Task Force (IETF), RFC 7429, January 2015.
[10] S. Matsushima, L. Bertz, M. Liebsch, S. Gundavelli, D. Moses, and
C. Perkins, “Protocol for Forwarding Policy Configuration (FPC) in
DMM,” IETF, I-D draft-ietf-dmm-fpc-cpdp-10, March 2018.
[11] V.-G. Nguyen, A. Brunstrom, K.-J. Grinnemo, and J. Taheri, “Sdn/nfv-
based mobile packet core network architectures: a survey,” IEEE Com-
munications Surveys & Tutorials, vol. 19, no. 3, pp. 1567–1602, 2017.
[12] J. Kempf, B. Johansson, S. Pettersson, H. L ¨
uning, and T. Nilsson,
“Moving the mobile evolved packet core to the cloud,” in Wireless and
Mobile Computing, Networking and Communications (WiMob), 2012
IEEE 8th International Conference on. IEEE, 2012, pp. 784–791.
[13] W. Y. Pentikousis Kostas and H. Weihua, “Mobileflow: Toward software-
defined mobile networks,” IEEE Communications magazine, vol. 51,
no. 7, pp. 44–53, 2013.
[14] M. R. Sama, L. M. Contreras, J. Kaippallimalil, I. Akiyoshi, H. Qian,
and H. Ni, “Software-defined control of the virtualized mobile packet
core,” IEEE Communications Magazine, vol. 53, no. 2, pp. 107–115,
2015.
[15] C. Sakshi and S. K. M., “Sdn based evolved packet core architecture
for efficient user mobility support,” in Network Softwarization (NetSoft),
2015 1st IEEE Conference on. IEEE, 2015, pp. 1–5.
[16] X. Jin, L. E. Li, L. Vanbever, and J. Rexford, “Softcell: Scalable and
flexible cellular core network architecture,” in Proceedings of the ninth
ACM conference on Emerging networking experiments and technologies.
ACM, 2013, pp. 163–174.
[17] F. Giust, A. Malik, and M. Liebsch, “Simplification as design principle
for 5g: A native ip data plane for a lean packet system,” in Personal,
Indoor, and Mobile Radio Communications (PIMRC), 2017 IEEE 28th
Annual International Symposium on. IEEE, 2017, pp. 1–7.