Applying SDN/OpenFlow in Virtualized LTE to Support Distributed

Mobility Management (DMM)

Morteza Karimzadeh, Luca Valtulina and Georgios Karagiannis

Department of Computer Science and the Electrical Engineering, University of Twente, Enschede, The Netherlands

Keywords: Virtualized LTE, DMM, IP Address Continuity, OpenFlow Switches.

Abstract: Distributed Mobility Management (DMM) is a mobility management solution, where the mobility anchors

are distributed instead of being centralized. The use of DMM can be applied in cloud-based (virtualized)

Long Term Evolution (LTE) mobile network environments to (1) provide session continuity to users across

personal, local, and wide area networks without interruption and (2) support traffic redirection when a

virtualized LTE entity like a virtualized Packet Data Network Gateway (P-GW) running on an virtualization

platform is migrated to another virtualization platform and the on-going sessions supported by this P-GW

need to be maintained. In this paper we argue that the enabling technology that can efficiently be used for

supporting DMM in virtualized LTE systems is the Software Defined Networking (SDN)/OpenFlow

technology.

1 INTRODUCTION

Long Term Evolution (LTE) is the fourth generation

(4G) technology which is standardized by the 3

Generation Partnership Project (3GPP), see e.g.,

(3GPP Release 10, 2013). It is capable of providing

high data rates as well as support of high speed

mobility. In the LTE system two main network parts

can be identified which are called Evolved UMTS

Terrestrial Radio Access Network (e-UTRAN) and

the Evolved Packet Core (EPC). The e-UTRAN

consist of base stations that are denoted as Evolved

Node-Bs (eNodeBs). Each of these eNodeBs are

controlling different cells which provide radio

coverage and connectivity between the User

Equipment (UE) and the EPC. The EPC is composed

of several network elements. The main important

ones are the Serving Gateway (S-GW), the Packet

Data Network Gateway (P-GW) and the Mobility

Management Entity (MME). The P-GW, that is the

main mobility EPC anchor point, connects the EPC

to other external networks. A mobility anchor point

is mainly in charge of mobility related user data

forwarding. Moreover, the P-GW also performs

various functions such as IP address/IP prefix

allocation or policy control and charging. The S-GW

supports the transport of the user data between the

UE and the external networks. The MME is the

control node that processes the mobility

management signaling, (i.e., handover) between the

UE and the EPC.

Mobility management provides the mechanisms

for maintaining active and seamless session

continuity to users across personal, local, and wide

area networks without interruption. Most of the

current IP mobility solutions standardized by both

IETF (Internet Engineering Task Force) and 3GPP

rely on a centralized mobility anchor entity which is

in charge of both mobility-related control plane and

user data forwarding. The presence of this

centralized network node makes mobility

management prone to several problems and

limitations such as: (1) suboptimal routing, (2) low

scalability, (3) signaling overhead, (4) more

complex network deployment, (5) security and

reliability issues due to the existence of a potential

single point of failure, and (6) a lack of granularity

on the mobility management service, see e.g. (Bertin

et al, 2009), (Chan et al, 2011). Currently, operators

and research communities are investigating

alternative mobility solutions that are more

distributed in nature, by using distributed mobility

anchors, denoted as Distributed Mobility

Management (DMM). The use of DMM allows a

cheaper and more efficient network deployment

capable to meet their customer requirements. As

shown in Figure 1, DMM implements a flatter

system in which the mobility anchors are placed

639

karimzadeh M., Valtulina L. and Karagiannis G..

Applying SDN/OpenFlow in Virtualized LTE to Support Distributed Mobility Management (DMM).

DOI: 10.5220/0004946106390644

In Proceedings of the 4th International Conference on Cloud Computing and Services Science (CLOSER-2014), pages 639-644

ISBN: 978-989-758-019-2

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

closer to the user, distributing the control and data

infrastructures among the entities located at the edge

(access) of the network. DMM may be partially or

fully distributed, where in the former the distribution

scheme is applied only to the data plane while in the

latter to both the data and control planes. It is

important to notice that in the fully distributed

approach data and control planes needs to be

decoupled although they are both handled by the

distributed anchor points.

Figure 1: Generic DMM approach scheme.

The Mobile Cloud Networking (MCN) project

0(EU FP7 MCN, 2013), as one of the EU FP7

projects, integrates the use of cloud computing

concepts in LTE mobile networks in order to

increase LTE’s performance. This is accomplished

by building a shared distributed LTE mobile

network that can optimize the utilization of

virtualized computing, storage and network

resources and minimize communication delays. In

particular, the integration of cloud computing

concepts in a LTE system, can be realized by: (1)

extending the cloud computing concept beyond the

typical (macro) data centers towards new smaller

(micro) data centers that are distributed within the e-

UTRAN and the EPC, and (2) deploying and

running cloud-based (virtualized) e-UTRAN,

denoted as RAN as a Service (RANaaS), and EPC,

denoted as EPC as a Service (EPCaaS). This trend is

also in line with the emerging ETSI activities in

Network Functions Virtualization (NFV). The use of

DMM can be applied in such environments not only

to enhance the LTE mobility management

performance and provide session continuity to users

across personal, local, and wide area networks

without interruption, but also to support traffic

redirection when a virtualized LTE entity, like the P-

GW running on an virtualization platform (i.e.,

originating data centre) is migrated to another

virtualization platform (i.e., destination data centre)

and ongoing sessions supported by this P-GW need

to be maintained. In (Chan, 2013), the main IETF

requirements for DMM solutions in IPv6 networks

deployments are defined as follows:

 Distributed Deployment: IP address mobility

and routing solutions provided by DMM must

enable distributed processing for mobility

management so that traffic does not need to

traverse centrally deployed mobility anchors and

thereby avoid non-optimal routes.

 Transparency: DMM solutions must provide

transparent mobility support above the IP layer

when needed.

 IPv6 Deployment: DMM solutions should target

IPv6 as the primary deployment environment and

should not be tailored specifically to support

IPv4, in particular in situations where private

IPv4 addresses and/or NATs (Network Address

Translations) are used.

 Co-existence: The DMM solution must be able

to co-exist with existing network deployments

and end hosts. For instance, depending on the

environment in which DMM is deployed, DMM

solutions may need to be compatible with other

deployed mobility protocols or may need to

interoperate with a network or mobile hosts/

routers that do not support DMM protocols.

 Security Considerations: A DMM solution

must not introduce new security risks or amplify

existing security risks against which the existing

security mechanisms/protocols cannot offer

sufficient protection.

 Flexible Multicast Distribution: DMM should

consider multicasting. So the solutions can be

developed that, not only to provide IP mobility

support when it is needed, but also to avoid

network inefficiency issues in multicast traffic

delivery (

e.g., duplicate multicast subscriptions

towards the downstream tunnel entities).

In the context of this paper also the following

additional requirements are defined:

 Dynamicity: The dynamic use of mobility

support by allowing the split of data flows along

different paths that may travel through either the

mobility anchor or non-anchor nodes, even

though no specific route optimization support is

available at the correspondent node. This

requirement will tackle the lack of fine

granularity of the centralized mobility

management approaches.

 Separating Control and Data Planes: Keeping

the control plane centralized while distributing

the data plane is a possible solution to minimize

the signaling overhead between the mobility

anchors due to the lack of knowledge that a

distributed anchor point has of its peers and their

connected UEs.

 Network-based: Not burdening the UE with

extra signaling and keeping the user unaware of

the on-going handoff procedure within the same

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

640

domain are fundamental aspects that need to be

provided by the DMM solutions deployed in

LTE networks.

Several DMM solutions have been proposed in the

IETF and 3GPP contexts. However, it is not yet

clear whether these DMM solutions can be applied

in virtualized LTE network systems. In this paper we

argue that the best candidate enabling technology

that can efficiently be used for supporting DMM in

virtualized LTE systems is the SDN/OpenFlow

technology. In particular, this paper answers the

following research question:

“Can SDN/OpenFlow be used efficiently for

DMM support in virtualized LTE systems?”

This paper is organized as follows. Section 2 is

providing a brief overview of the SDN/OpenFlow

technology and explains how it could be exploited to

support DMM in virtualized LTE systems. In

Section 3 a brief introduction of other possible

candidate technologies is provided. Moreover

Section 3 analyses and compares these technologies

with the SDN/OpenFlow approach. Section 4 shows

in an example how the SDN/OpenFlow concept can

be applied in the virtualized LTE system.

Furthermore, Sections 3 and 4 are answering the

research question listed above. Finally, Section 5

concludes and provides recommendations for future

work.

2 SDN/OpenFlow

SDN (ONF, 2103) is an architecture that decouples

forwarding functions and network control, which

become directly programmable. This enables the

underlying infrastructure to be abstracted for

applications and network services. In particular,

SDN capable switches and routers can be configured

and programmed using a centralized management

entity, denoted as SDN controller. Several SDN

based protocols are being developed, such as the

IETF FORCES (Forwarding and Control Element

Separation) and OpenFlow. OpenFlow (OpenFlow,

2013) is the most commonly used SDN based

protocol which carries signalling message between

SDN controllers and the underlying network

infrastructure, bringing network applications to

life. With OpenFlow, the forwarding plane of a

SDN/OpenFlow capable switch or router can be

accessed over the network and reconfigured

according to the needs of applications and network

services. The vast majority of Ethernet switches and

routers used nowadays contain flow-tables to

implement firewall, NAT, QoS (Quality of Service)

and other functionalities. A flow-table of

SDN/OpenFlow capable switches or routers can be

remotely programmed partitioning the network’s

traffic into separated flows. Features offered by

OpenFlow protocol can be used to deploy a DMM

solution offering IP address continuity and traffic

redirection in the operator’s transport network. This

can be achieved by treating each traffic path from

the Internet PoPs (point of presence) to the mobility

anchor points (e.g., P-GWs) as a separated flow. In

this way traffic redirection can be supported without

involving any IP address translation or modification,

when for example a virtualized LTE entity, like the

P-GW, running on an virtualization platform (i.e.,

originating data centre) is migrated to another

virtualization platform (i.e., destination data centre)

and ongoing sessions supported by this P-GW need

to be maintained. Alternatively SDN/OpenFlow

switches contain a list of actions that can be applied

on every transiting packet that belongs to a specific

flow. Example of these actions are: Drop, Push-Tag,

Pop-Tag, Group and Set-Field. The optional Set-

Field action is the most interesting for the purpose of

this proposal providing to SDN/OpenFlow switches

the possibility to modify headers of packets and

frames, used by e.g., Ethernet, VLAN, and IP. Both

flow tables and action lists are added, modified or

removed by the SDN/OpenFlow Controller which

has a dedicated secure connection with each

SDN/OpenFlow switches and routers. The

procedures and messages used to support and

perform such modifications are specified in the

OpenFlow specification document 0.

3 MOTIVATION: WHY SDN/

OpenFlow SHOULD BE USED

FOR DMM SUPPORT IN

VIRTUALIZED LTE SYSTEMS

This section introduces other possible candidate

DMM enabling technologies and analyses and

compares them with the SDN/OpenFlow approach

in order to verify whether they can be applied for

DMM support in a virtualised LTE system.

3.1 IETF Based DMM Enabling

Technologies

The IETF DMM working group charter addresses

two complementary aspects of mobility management

procedures: the distribution of mobility anchors

ApplyingSDN/OpenFlowinVirtualizedLTEtoSupportDistributedMobilityManagement(DMM)

641

towards a more flat network and the dynamic

activation/deactivation of mobility protocol support

as an enabler to distributed mobility management

(Chan, 2013). The following DMM solutions are

specified within the context of IETF.

3.1.1 Double NAT (D-NAT)

Double NAT DMM solution proposed in (Liebsch,

2012) adopts the concept of an identifier-locator

split to solve the routing in the transport network

above the mobility anchors. Forwarding downlink

packets to the mobile nodes’s current mobility

anchor can be achieved using tunnels as already

done in both Mobile IP and Proxy Mobile IP (PMIP)

solutions. To avoid encapsulation overhead

introduced by tunnelling the use of NAT is proposed

at both ends of the operator's transport network. Two

new entities, performing address translation from

identifier address to locator address and vice-versa,

need to be introduced in the network. These entities

are referred to as Ingress NAT router and Egress

NAT router. Using NAT functionality is required

only in the case of downlink traffic, where the

Ingress NAT router performs translation of the

identifier address into the locator address and it

forwards the packets down into the operator's

transport network. The Egress NAT router, on the

other hand, translates the locator address back to the

identifier address in order to forward the packet to

the mobile node. The Egress NAT routers will

therefore always be placed closer to the southern

edge of the operator's transport network than the

Ingress NAT routers.

3.1.2 Distributed Mobility Anchoring

(DMA)

P. Seite (Seite et al, 2103) proposed a distributed

mobility traffic management with dynamic user’s

traffic anchoring in the networks’ access routers

(ARs). It relies on a flat architecture where a new

entity named Mobility capable Access Router

(MAR) is introduced to provide mobility

management functions. The MAR has both mobility

anchoring and location update functional capabilities

and can acts as a Home-MAR (H-MAR) or as a

Visited-MAR (V-MAR) for a given mobile node. A

H-MAR is responsible for the allocation of Home

Network Prefix (HNP), used in this solution instead

of HoA, to mobile node. On the one hand, when a

mobile node moves away from the home network,

the H-MAR is responsible for tracking the mobile

node’s location and forwarding packets to the V-

MAR where the mobile node is currently attached

to. On the other hand a V-MAR manages the

mobility-related signalling for a mobile node that is

attached to its access link. The architecture of this

solution relies on a centralized database storing

ongoing mobility sessions for the MNs.

3.1.3 Inter-domain DMM

J.C. Zuniga et al. in (Bernardos and Zuniga, 2103)

proposed a method which aims to ensure session

continuity in an inter-domain roaming scenario. It is

based on the partial distributed single operator

scenario that uses an entity called Distributed

Gateway (D-GW) placed at the edge of the network.

The D-GW supports two roles: Anchoring D-GW

and Serving D-GW. The control plane relies on a

central entity called Central Mobility Database

(CMD). The inter-domain solution uses a centralized

Local Mobility Anchor (LMA), usually located in the

home domain, as top-level anchor to guarantee

session continuity when crossing operator borders. It

is assumed that the necessary roaming agreement are

in place in order to support setting up tunnels

between the LMA located at the home domain of the

mobile node (MN) and the visited D-GWs, which in

a 3GPP EPC scenario may correspond to the

eNodeBs or Home eNodeBs (HeNBs) used for

femtocells.

3.2 3GPP Based Solutions IETF Based

DMM Enabling Technologies

Currently, in the 3GPP EPC architecture, the

mobility management solutions mostly rely on a

centralized mobility anchor entity, i.e., P-GW, which

is in charge of the control of the network entities

involved in the mobility management and the user

data forwarding. There are however, two solutions

specified by 3GPP that are already introducing the

concept of DMM into the 3GPP EPC architecture,

i.e., LIPA and SIPTO.

3.2.1 Local IP Access (LIPA) / Selected IP

Traffic Offload (SIPTO)

LIPA and SIPTO 0 have been introduced by 3GPP

in LTE Release 10. They enable data traffic offload

at appropriate points in the Radio Access Network

(RAN) in a highly cost-efficient manner leading to

an increased system scalability and enhance the

operators flexibility to cope with the growing mobile

data traffic demanded. LIPA allows a UE, connected

in a residential or corporate deployment via a HeNB,

to directly connect to other devices and services in

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

642

the local network, relieving this portion of data

traffic from the mobile operator’s core network.

LIPA breakout takes always place at the newly

introduced Local GW entity located in the

local/home or enterprise femtocell network. SIPTO,

on the other hand, offloads selective IP traffic to the

Internet at the local gateway (L-GW), similar to

LIPA, or above HeNB such as the HeNB gateway

located in home and enterprise networks. When the

UE is connected to a macro-cellular network, SIPTO

offload takes place at or above the RAN. By

breaking out selected traffic closer to the edge of the

network, operators may avoid overloading their

scarce resources, i.e. P-GWs and S-GWs, as well as

avoid inefficient routing in the mobile backhaul

network.

3.3 Analysis and Comparison

In order to provide DMM support in virtualised LTE

systems, the selected DMM enabling technology

needs to support the DMM requirements listed is

Section 1. Table 1 analyses and compares

SDN/OpenFlow technology with the other candidate

DMM enabling technologies that were briefly

described in the previous subsections, by using the

DMM requirements listed in Section 1.

Table 1: Comparison ( Y:Yes, N:No, P: Partial, N.c:Not

considered, N.s:Not specified, C:Considered, O.l:Only

local, without support for IP address continuity).

Requirements

SDN/

OpenFlow

D-NAT

DMA

Inter-

domain DMM

LIPA/

SIPTO

Distributed

deployment

Y Y Y P

O.l

Transparency

Y Y Y Y O.l

IPv6 deployment

Y Y Y Y Y

Co-existence

N N P Y P

Security

considerations

N.c

Flexible

multicast

distribution

N.s

Dynamicity

Y N Y N N

Separating

control and data

planes

Network-based

Y Y Y Y Y

Based on the analysis and comparison given in

Table 1, it can be deduced that the SDN/OpenFlow

based DMM technology can satisfy most of the

DMM requirements introduced in Section 1. The

Co-existence requirement is not satisfied due to the

fact that SDN/OpenFlow requires the introduction

of new entities and features, i.e., SDN/OpenFlow

Controller and switches, in the operator’s transport

network. However, due to the ongoing activities in

the SDN area, see (ONF, 2103), it can be assumed

that operators will probably introduce and deploy

SDN/OpenFlow Controllers and switches in their

operator’s transport networks. Therefore, it can be

deduced that the SDN/OpenFlow technology is a

promising candidate that can efficiently be used for

DMM support in virtualized LTE systems.

4 EXAMPLE OF INTEGRATING

SDN/OpenFlow IN

VIRTUALIZED LTE SYSTEMS

In this section, an example is provided on how the

SDN/OpenFlow enabling technology could be

applied in virtualized LTE systems to support

DMM. In a virtualized LTE system, the S/P-GWs

are running on Virtual Machines (VMs) that are

hosted on one or more micro data centres. The

DMM framework described in (Liebsch et al, 2013)

can be used for this purpose. In particular, 0(Liebsch

et al, 2013) defines 4 new functional entities: FE_I:

Ingress for DMM indirection (redirection), FE_E:

Egress for DMM indirection, FE_IEC: Control to

establish states for DMM indirection and

FE_MCTX: Function to transfer/establish context for

IP address continuity. In Figure 2, it is considered

that: OF1 supports FE_I and OF4 and OF3 support

FE_E. The FE_IEC and FE_MCTX are supported by

the SDN/OpenFlow Controller (OC), in cooperation

with MME. DMM can be used to provide (1)

session continuity to users (UEs) that are moving

from one mobility anchor, e.g., S/P-GW to another

mobility anchor, and (2) traffic redirection when a

virtualized LTE entity, like the P-GW running on an

virtualization platform is migrated to another

virtualization platform and ongoing sessions

supported by this P-GW need to be maintained. In

this example, DMM is used to provide session

continuity to users that are moving from one

virtualized S/P-GW to another virtualized S/P-GW.

In such an architecture, SDN/OpenFlow switches

and SDN/OpenFlow Controllers may be

implemented in VMs and the functions can be

remotely configured and upgraded using soft-EPC

components based on the end-users requirements.

With OpenFlow the forwarding plane of a

ApplyingSDN/OpenFlowinVirtualizedLTEtoSupportDistributedMobilityManagement(DMM)

643

SDN/OpenFlow switch or router can be accessed

over the network and modified according to the

service requirements. As shown in Figure 2, a

simple OpenFlow network is used as transport

network above the EPC. All the routers are

OpenFlow capable and their flow tables are

managed by the same OC.

Internet

OF1

OF2

OF3

OF4

OpenFlow

Contro ller

Source

S/P‐GW

Target

S/P‐GW

Source

eNodeB

Target

eNodeB

Internet

OF1

OF2

OF3

OF4

Source

S/P‐GW

Target

S/P‐GW

Source

eNodeB

Target

eNodeB

Activeflowusing

IPaddress10.0.0.1

Activeflowusing

IPaddress10.0.0.1

Handov er

OpenFlow

Contro ller

Figure 2: OpenFlow approach to support DMM in a

virtualized LTE system.

In this example, when a UE changes his EPC

mobility anchor point, flow tables of all

SDN/OpenFlow switches will be updated by OC to

re-route the downlink traffic (i.e., arriving from

Internet), from the original S/P-GW, see Figure 2(a),

to the new S/P-GW, see Figure 2(b). Due to the fact

that no modifications will be performed on the data

packets, traffic redirection can be performed only if

all routers and switches in the operator’s transport

network are OpenFlow capable. For uplink traffic

(i.e., sent towards Internet), a static forwarding path

will be setup when a flow is created. If a path to the

specific destination hosts already exists, for instance

in case of widely visited end-hosts, no changes will

be needed to the setup paths. This static path will be

used throughout the whole life of a flow in the

operator’s transport network.

5 CONCLUSIONS AND FUTURE

WORK

In this paper several DMM enable technologies have

been analysed and compared. In particular, this

paper argued and verified that the SDN/OpenFlow

technology is a promising candidate that can

efficiently be used for the support of DMM in

virtualized LTE systems. In order to further validate

this statement, the use of the SDN/OpenFlow

technology for the support of DMM in the

virtualized LTE system will be prototyped and

evaluated within the context of the EU FP7 project

0(EU FP7 MCN, 2013).

ACKNOWLEDGEMENTS

This work is accomplished in the context of the

MCN project. We therefore, would like to

acknowledge the European Commission, since the

MCN project is an EC funded Integrated Project

under the 7th RTD Framework Programme, FP7-

ICT-2011-8-grant agreement number 318109.

REFERENCES

3GPP Release 10, 2103.Overview of 3GPP Release 10

V0.1.7, <www.3gpp.org/Release-10>.

Bertin, P., Bonjour, S., Bonnin, J., 2009. Distributed or

centralized mobility. In Proc. of IEEE Global

Telecommunications Conference, (GLOBECOM

2009). pp. 1–6. IEEE.

Chan, H. A., Yokota, H., Xie, J., Seite, P., Liu, D., 2011.

Distributed and Dynamic Mobility Management in

Mobile Internet: Current Approaches and Issues.

Journal of Communications, Vol. 6, Iss, 1, pp. 4–15.

Academy Publisher.

EU FP7 MCN, (visited in September 2013)

<http://www.mobile-cloud-networking.eu/site/>.

Chan, H. (editor), December 2013. Requirements for

Distributed Mobility Management. IETF Internet draft

(work in progress). IETF.

ONF, (visited in December 2013) <https://

www.opennetworking.org/>.

OpenFlow, 2013. The OpenFlow Specification.Version

1.3.0, (visited December) <http://

archive.openflow.org>.

Liebsch, M., 2012. Per-Host Locators for Distributed

Mobility Management . IETF Internet draft (work in

progress). IETF.

Seite, P., Bertin, P., Lee, J. H., 2013. Distributed Mobility

Anchoring. IETF Internet draft (work in progress).

IETF.

Bernardos, C. J., Zuniga, J. C., 2013. PMIPv6-based

distributed anchoring. IETF Internet draft (work in

progress). IETF.

Liebsch, M., Seite, P., Karagiannis, G., 2013. Distributed

Mobility Management-Framework & Analysis. IETF

Internet draft (work in progress). IETF.

(a) before handover

(b) after handover

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

644