ETSI White Paper No.

24

MEC Deployments in 4G
and Evolution Towards 5G
First edition – February 2018

ISBN No. 979-10-92620-18-4

Authors:
Fabio Giust, Gianluca Verin, Kiril Antevski, Joey Chou, Yonggang Fang, Walter Featherstone,
Francisco Fontes, Danny Frydman, Alice Li, Antonio Manzalini, Debashish Purkayastha, Dario
Sabella, Christof Wehner, Kuo-Wei Wen, Zheng Zhou

ETSI
06921 Sophia Antipolis CEDEX, France
Tel +33 4 92 94 42 00
info@etsi.org
www.etsi.org
 About the authors
Fabio Giust
NEC - Editor

Gianluca Verin
Athonet - Editor

Kiril Antevski
UC3M

Joey Chou
Intel

Yonggang Fang
ZTE

Walter Featherstone
Viavi Solutions

Francisco Fontes
Altice Labs

Danny Frydman
Saguna

Alice Li
Vodafone

Antonio Manzalini
TIM

Debashish Purkayastha
InterDigital

Dario Sabella
Intel

Christof Wehner
Artesyn

Kuo-Wei Wen
ITRI

Zheng Zhou
Huawei

MEC Deployments in 4G and Evolution Towards 5G 2

 Contents
About the authors 2
Contents 3
Introduction 4
Deploying MEC in 4G networks: scenarios and challenges 5
Bump in the wire 5
Distributed EPC 6
Distributed S/PGW 8
Distributed SGW with Local Breakout (SGW-LBO) 8
Control/User Plane Separation (CUPS) 9
Challenges in the different approaches 9
Session management 9
Mobility management 10
Lawful interception 11
Security 11
Charging 12
Identifying specific subscribers at the MEC platform 13
MEC as driver to 5G adoption 14
Deploying MEC in the 5G system architecture 14
Management and Orchestration of Cloud vs Edge resources 16
MEC and NFV 17
Support to third party service providers 17
Management of MEC applications 18
Conclusions 19
List of abbreviations 20
References 22

MEC Deployments in 4G and Evolution Towards 5G 3

 Introduction
Multi-access Edge Computing is regarded as a key technology to bring application-oriented capabilities
into the heart of a carrier’s network, in order to explore a wide range of new use cases, especially those
with low latency requirements. When it comes to deploying MEC, there are many potential scenarios
where MEC can fit in, and – as the name clearly spells out – these are not limited to 4G or 5G at all! As a
universal access technology, MEC offers itself to any application that has locality requirements like a
shopping mall or a sports arena, or wherever low latency is required such as 5G V2X or autonomous
vehicle applications.
Nevertheless, starting from the fact that the MEC’s original target was the mobile network, when it comes
to its deployment, MEC is often considered as a 5G-only feature. However, 4G is expected to still be
successful in the years to come, thus a large part of the industry is working towards running MEC in
existing 4G networks. In fact, the MEC reference architecture, defined in ETSI GS MEC 003 [1], is agnostic
to the mobile network evolution, so that a MEC host deployed in a 4G network can be reused to support
5G services as well.
Therefore, understanding the impact of deploying an ETSI MEC system into current 4G and future 5G
systems is crucial for mobile network operators (MNOs) in order to carefully plan their network upgrades.
This way, MEC can be not only a technology ready for 4G, but also a driver to motivate 5G adoption, as it
can allow operators to retain the investment made in 4G deployment. Indeed, from a mobile evolution
perspective, products based on current MEC specifications can be smoothly migrated to support 5G
networks through software update. This way, flexibility in the deployment architecture allows planning
for the introduction of MEC services as the milestone to build the edge cloud, which is key for the success
of 5G services such as URLLC (Ultra Reliable Low Latency Communications).
In light of the considerations above, the purpose of this white paper is to show the compatibility of an
ETSI MEC system with 3GPP 4G and 5G architectures, aiming at:
 shedding some light on the potential deployment options available for operational 4G systems;
 providing a technical insight of MEC operations under such scenarios;
 showing how the creation of the mobile edge infrastructure in 4G can pave the way for 5G
deployment and therefore protect investments and smoothly transit to future and more advanced
service offerings.
The present document will first showcase different options to cast the MEC system into a running 4G
system, maintaining backward compatibility with the 3GPP-specified architecture. In other words, such
options explore how the “MEC box” can be drawn into the 4G system architecture, showing the
challenges associated to each choice.
Moreover, a section devoted to the transition to 5G will demonstrate how and why deploying MEC in 4G
can accelerate network transformation, leveraging on compliance to 3GPP standards and use of the cloud
computing paradigm to bring future-proof added value to service providers.

MEC Deployments in 4G and Evolution Towards 5G 4

 Deploying MEC in 4G networks: scenarios and
challenges
As per the GS MEC 011 [2] specification, a key baseline functionality of the MEC platform is to route IP
packets to MEC applications which are meant to handle the traffic in the following different ways:
 In Breakout mode, the session connection is redirected to a MEC application which is either hosted
locally on the MEC platform or on a remote server. Typical breakout applications include local CDN,
gaming and media content services, and enterprise LAN.
 In In-line mode, the session connectivity is maintained with the original (Internet) server, while all
traffic traverses the MEC application. In-line MEC applications include transparent content caching
and security applications.
 In Tap mode, specified traffic is duplicated and forwarded to the tap MEC application, for example,
when deploying virtual network probes or security applications.
 In Independent mode, no traffic offloading function is needed, but still the MEC application is
registered in the MEC platform and will receive other MEC services, such as DNS, Radio Network
Information Service (RNIS), etc.
Steering traffic to/from MEC applications is achieved by configuring the MEC’s local DNS and the MEC
host’s data plane accordingly. From the list above, it appears straightforward that the implementation-
specific details of the data plane within the MEC host (as per the MEC architecture in GS MEC 003 [3]) and
the MEC platform, which is meant to program the data plane through Mp2 interface, are impacted by the
point where the MEC host is installed in the 4G architecture. Many choices are possible, but all in all they
can be condensed down into some base scenarios discussed in the following sections.

Bump in the wire

The expression “bump in the wire” encompasses all the scenarios in which the MEC platform installation
point ranges in locations between the base station itself and the mobile core network. These options
were first proposed in the MEC Introductory White Paper [1] and reproduced in Figure 1.

When the eNB implementation bundles the MEC platform into a single implementation, this latter is able
on the one hand to route plain IP packets to/from the MEC applications (i.e., local switching mode), and
on the other hand to route GTP-encapsulated packets to/from the Serving Gateway (SGW) for regular
traffic as per the operator-configured Packet Data Networks (PDNs - i.e., the legacy S1-U mode). This
deployment is very convenient e.g., in enterprise scenarios to allow intranet traffic to breakout to local
services (similar to Local IP Access - LIPA), and also when MEC is co-located with a CRAN deployment (see
the ETSI white paper “Cloud RAN and MEC: a Perfect Pairing” [4].)
In all the other locations, either in proximity of the radio node or at an aggregation point, the MEC
platform sits on the S1 interface of the 4G system architecture. In this scenario, the MEC host’s data plane
has to process user traffic encapsulated in GTP-U packets, thus requiring the appropriate handling of
these tunnels. This non-trivial operation poses some challenges, as a portion of the data may be
generated or manipulated internally in the MEC hosts or may come from a local breakout, without
passing through the core of the network. For this traffic, a dedicated solution may be required (e.g., the
MEC GW in Figure 1) to handle operations such as lawful interception and charging. This solution can
support CUPS, which ensures a 3GPP-compliant solution (see sections below). Also, in this solution, low

MEC Deployments in 4G and Evolution Towards 5G 5

 latency is supported by installing the MEC platform all the way down to the eNB, or in locations that
ensure minimal latency. Additionally, it offers the capability to steer traffic on a per session and/or packet
granularity, with flexible filtering support.

Figure 1: MEC deployment using the "Bump in the wire" approach.

Distributed EPC
Unlike the “bump in the wire” approach, in this deployment the MEC host logically includes all or part of
the 3GPP Evolved Packet Core (EPC) components, as specified in the 4G system architecture in ETSI TS
123.401 [5], and the MEC data plane sits on the SGi interface. By doing so, in order to steer U-plane traffic
towards the MEC system, two elements, the local DNS of MEC and the PDN Gateway (PGW) of a
distributed EPC, play critical roles. In fact, as the UE subscribes to the distributed EPC co-located with the
MEC host, the PGW thereupon terminates the PDN connection and assigns the IP address and local DNS
information to resolve the MEC applications’ IP address. This scenario requires less changes to the
operator’s network as standard 3GPP entities and interfaces are leveraged for operations such as session
management, charging, etc.
This type of deployment can well serve Mission Critical Push to Talk (MCPTT), and M2M communications,
where the communication with the operator’s core site is optional (see for example the upper diagram in
Figure 2). In this case, the Home Subscriber Server (HSS) is co-located with the EPC as well, and there is no
need for a working backhaul to keep the local service running. This type of deployment is typically used by
first responders, public safety, and mission critical industrial sites.
In some other cases, the HSS is unique and centrally managed by the operator at the core site and the
operator’s core site PGW can be used for some selected APNs (e.g. IMS or roaming). This allows the local
management of the entire subscriber database and the use of the local EPC in the MEC to offload the
entire APN traffic. Additionally, the distributed EPC offers the ability to deliver exactly the QoS and

MEC Deployments in 4G and Evolution Towards 5G 6

 configurability features that, e.g. an enterprise customer requests from the particular network service
purchased (see the lower diagram in Figure 2).
The MEC applications can be co-located with the evolved packet core (EPC) functions in the same MEC
host. This option can reduce costs as the EPC and its components can run e.g. as Virtual Network
Functions (VNFs) on the same Network Functions Virtualisation (NFV) platform with the MEC components
in order to improve scalability and better utilize network resources (see the example in Figure 3).

Figure 2: MEC deployment with distributed EPC

Figure 3: MEC deployment with EPC and MEC application on the same NFV platform (same MEC host).

MEC Deployments in 4G and Evolution Towards 5G 7

 Distributed S/PGW
The distributed S/PGW deployment option is similar to the previous one, except that only SGW and PGW
entities are deployed at the edge site, whereas the control plane functions such as the Mobility
Management Entity (MME) and HSS are located at the operator’s core site. Still, the MEC host’s data
plane connects to the PGW over the SGi interface.
Similarly to the previous option with the whole distributed EPC, the SGW and PGW can also run as VNFs
together with the MEC application on the NFV platform as part of the same MEC host. The local SGW
selection is performed by the central MME according to the 3GPP standard DNS procedures and based on
the Tracking Area Code (TAC) of the radio where the UE attaches to. This architecture allows offloading
the traffic based on the APN, which means, for example, that the IMS for VoLTE APN and roaming APNs
may not be offloaded.

Figure 4: S-GW and P-GW MEC deployment

The diagram above shows the deployment with the SGW and PGW co-located at the network edge, which
requires the operator to extend the S5 interface to the MEC site. This type of deployment allows the
operator to retain full control over the MME.

Distributed SGW with Local Breakout (SGW-LBO)

Local breakout at the SGWs is a new architecture for MEC that originates from operators’ desire to have a
greater control on the granularity of the traffic that needs to be steered. This principle is dictated by the
need to have the users able to reach both the MEC applications and the operator’s core site application in
a selective manner over the same APN.
With the Distributed SGW deployment, one of the optional MEC deployment scenarios is to co-locate
MEC hosts with the SGW. Both the SGW-LBO and the MEC application may be hosted as VNFs in the same
MEC platform. The following figure describes co-locating MEC hosts with the SGW in a mobile network
where the MEC system and the distributed SGW are co-located at the edge.

MEC Deployments in 4G and Evolution Towards 5G 8

 Figure 5: SGW-LBO MEC deployment
The traffic steering uses the SGi - Local Break Out interface which supports traffic separation and allows
the same level of security as the operator expects from a 3GPP-compliant solution. This solution allows
the operator to specify traffic filters similar to the uplink classifiers in 5G, which are used for traffic
steering. This architecture also supports MEC host mobility, extension to the edge of CDN, push
applications that requires paging and ultra-low latency use cases.

The SGW selection process performed by MMEs is according to the 3GPP standard and based on the
geographical location of UEs (Tracking Areas) as provisioned in the operator’s DNS.

The SGW-LBO offers the possibility to steer traffic based on any operator-chosen combination of the
policy sets, such as APN and user identifier, packet’s 5-tuple, and other IP level parameters including IP
version and DSCP marking.

Control/User Plane Separation (CUPS)

The deployment options above which distribute the EPC gateways at the edge, either co-located with or
within the MEC host, can also be built using the CUPS paradigm standardized in 3GPP Release 14 and have
the new User Plane built in the MEC host.
Local User Plane (UP) distribution allows the use of the CUPS architecture to locally steer the traffic. SGW-
C and PGW-C are the end points that populates the UP routing tables.

Challenges in the different approaches

From the deployment scenarios outlined above, a clear distinction emerges of two major categories,
depending on whether the MEC host leverages the EPC packet gateways’ functionalities or not. This
section examines the impact of the different types of deployment scenario with respect to session and
mobility management, security, charging and Lawful Interception. As expected, approaches that use
standard 3GPP NFs to support MEC show the least impact.

Session management
In the bump in the wire scenario, MEC is located on the S1-U reference point. The eNB and SGW are not
MEC-aware as MEC components are not involved in the standard 3GPP procedures of session
management, including PDN connection setup, deletion and paging. However, it is necessary for MEC to
get the UE context for the right traffic routing, which makes it more challenging. There are at least two
feasible approaches to manage the UE context for MEC:
1. User plane packet inspection: MEC creates the UE context according to the S1-U tunnel IP
addresses and Tunnel Endpoint Identifiers (TEID-Us) learned from the user plane packets (see also

MEC Deployments in 4G and Evolution Towards 5G 9

 the section below “Identifying specific subscribers at the MEC platform”). For the traffic that needs
to be offloaded, MEC routes specific packets to specific applications by a traffic offload function.
For traffic flows that do not need to be offloaded, MEC behaves as a transparent device. In
addition, a dedicated yet not standard mechanism is necessary to trigger paging from the MEC
application, e.g., for push notifications.

Figure 6: User plane packets inspection

2. Controlled by the PGW: The enhanced PGW controls the session management of MEC to create,
update, delete the UE context and delivers the charging characteristics/LI information. Although a
new reference point needs to be created between PGW and MEC, charging and LI are supported
and it can be easily upgraded to the CUPS deployment mode and then evolved smoothly to 5G. The
reference point between PGW and MEC will be Sx in CUPS deployment mode and N4 in 5G.

Figure 7: PGW-Controlled MEC

In the other MEC deployment options which make use of EPC co-location, there is much less impact on
session management, as it is handled by the EPC functions installed along with the MEC host. In particular
we observe the following
 EPC MEC, SGW+PGW MEC: Session management is not impacted, even for inter-MEC handover
since the standard 3GPP procedures are used to keep the original PGW as anchor. This assures
session continuity as well as paging idle UEs. Application level mobility is achieved by reassigning
the IP address to the user or enforcing a breakout policy into the target SGW. Charging and lawful
interception are supported natively by the solution.
 SGW-LBO MEC: The connectivity to the standard PGW assures the creation and deletion of the UE
context similarly to the approach above.
 CUPS MEC: All the MEC options can incorporate the CUPS solution which requires a UP capable of
performing traffic offload in order to steer traffic to/from the MEC applications.

Mobility management
Mobility is concerned with service continuity when the UE is moving intra or inter MEC. MEC needs to be
aware of the handover of the UE in the underlying network and updates the UE context to keep the
service continuity. Two scenarios appear relevant:

MEC Deployments in 4G and Evolution Towards 5G 10