Wireless Communications and Mobile Computing

Wireless Communications and Mobile Computing / 2019 / Article

Research Article | Open Access

Volume 2019 |Article ID 4567317 | 21 pages | https://doi.org/10.1155/2019/4567317

A Flow-Based and Operator-Centric Dynamic Mobility Management Scheme for Proxy Mobile IPv6

Academic Editor: Kumudu S. Munasinghe
Received17 Oct 2018
Revised13 Feb 2019
Accepted20 Mar 2019
Published14 Apr 2019


The continuous increase of mobile data traffic volume creates new challenges for telecommunication network operators. As a possible solution, many traffic offloading techniques have been proposed. In parallel, there is a trend to handle all the access techniques under the umbrella of IP, including non-3GPP networks (e.g., Wi-Fi), mainly with the help of IPv6. In this paper we provide a new architectural proposal in Evolved Packet Core (EPC) described as flow-based and operator-centric dynamic mobility management with Proxy Mobile IPv6 (PMIPv6). This new approach is supported by current EPC entities including Policy and Charging Rules Function (PCRF), Access Network Discovery and Selection Function (ANDSF), and Local Mobility Anchor (LMA) and by defining a novel communication scheme between them. The proposal was evaluated in a virtual testbed environment, and measurements based simulations were carried out where the solution showed significant benefits by enhancing operator flexibility, increasing user experience, and decreasing signaling overhead due to its highly dynamic operation and optimized flow-level behavior.

1. Introduction

Mobile Network Operators (MNOs) must deal with increased traffic but the cost of capacity expansion is very high: buying new nodes and frequencies. Thus, using better existing equipment may be a cheaper approach. On the one hand MNOs can use their devices smarter, i.e., having new software and technics; on the other hand, they can make smart use of existing (not necessarily their own) deployments, i.e., using available Wi-Fi networks for extending frequency spectrum. To see these approaches on a high level, these are all about connecting heterogeneous access networks to the 3GPP core in standardized way. The goal is to introduce intelligent traffic management with the minimal equipment impact relying on only software modification if needed at all. Our approach tries to stick the introduced procedures to IP level as much as possible (however, some control function should be put to upper layers as well).

Mobile IPv6 (MIPv6) [1] was one of the first IP level solutions which made it possible to deploy efficient mobile communication infrastructures in heterogeneous access environments. This technology is a very flexible, mobile-end-user-centric method that demands active participation from the user’s equipment to ensure locator-identifier splitting in IP addresses and managing IP level mobility. However, operators need a more network-centric way of operation to deploy such services in real-life infrastructures. PMIPv6 [2] was developed to satisfy this need. PMIPv6 moves mobility management functions from the mobile nodes to the edge of the network (the architecture is depicted in Figure 1). Therefore, an important advantage of using PMIPv6 is that it does not call for any modifications in the network protocol stack of the mobile end-terminal.

With the help of the evolving MIPv6 protocol family [35], it started to be possible to separate and manage the mobility of IP flows one by one. PMIPv6 also adopted the method of Flow Bindings. The PMIPv6 extension requires software modifications in the network stack of the mobile node though, in order to always forward the flows towards their assigned interfaces and networks [6].

However, not all applications (i.e., flows) need to go through mobility management procedures. There are applications which maintain short-lived connections (e.g., browsing, online messaging) where network changes do not cause problems in the Quality of Service/Experience (QoS/QoE); therefore they do not require IP address preservation, and so mobility management can be omitted or ignored. With this approach the number of signaling messages can be decreased and optimal transport routes can be easily established for each application with the price of session termination and reestablishment in case of handover situations. In spite of this, the QoE of voice calls, video calls, and VPN connections can only be kept at a high level if network changes do not require session reestablishment and applications can preserve previous states (e.g., based on globally available IP addresses and appropriate mobility management mechanisms) during any handover scenario. Dynamic mobility management [711] schemes deal exactly with the above problem: they provide suggestions to decide which flow needs to be handled and how and tools to execute mobility management functions.

PMIPv6 could also implement the above approach. When the user equipment is connected to a network and then moves to a new one, the mobility management system could examine whether there are flows which require mobility management procedures or whether native IP connection without additional mobility functions is good enough. A typical use-case is when a user’s current VoIP or real-time video session actually traversed through the 3GPP network is handed over to a newly available Wi-Fi network due to offloading, but those other sessions which do not require mobility management (P2P file sharing, web-browsing, etc.) will be terminated and reestablished to use the newly appearing Wi-Fi access. In a 3GPP core network there must be a functional entity to decide whether a flow needs to be offloaded or needs to be handed over by the mobility management subsystem. This role fits perfectly into the MME (Mobility Management Entity) or the PCRF-PCEF (Policy and Charging Rules Function - Policy and Charging Enforcement Function) nodes.

In this work we propose a scheme to integrate the above introduced advanced dynamic mobility management paradigm into a 3GPP network using PMIPv6 and analyze some important open performance questions of dynamic PMIP flow mobility.

The rest of the paper is organized as follows. In Section 2 we take a look at the background of dynamic mobility management and the considered use-cases in EPC environments. In Section 3 we propose a novel architecture and signaling framework for dynamic mobility management in LTE/EPC systems. Section 4 is about introducing a virtual testbed environment for evaluation purposes, while in Section 5 the measurement scenarios and results are detailed. In the last two sections we discuss potential 5G applications and other issues and then conclude the paper and draw our future work.

IP-based mobility management started during the 1990s while the first RFC was published (RFC 2002) in 1996 [12]. The requirement for mobility support in IP comes from the emerging number mobile nodes (MNs). As MNs modify their point of attachment (PoA), they receive new IP address(es) and their reachability no longer exists for their clients. The idea is to solve this problem on IP level, not involving any higher layer interaction or at least minimizing it.

Mobile IPv4 has its drawbacks because it defines two agents: a Home Agent and a Foreign Agent. Thus, it possesses high impact on the network design. After the advent of IPv6 in 1995, mobility management was rethought with the assets of IPv6 [13], IPv6 Stateless Autoconfiguration [14], and Neighbour Discovery Protocol (1996) [15]. By 2004, the first RFC was born for mobility support in IPv6 (RFC 3775, [16]). Mobile IPv6 gets rid of Foreign Agent, puts this functionality into end-users, and fully relies on IPv6 and its build-in services. This leads to another problem: some of the network functionalities are not under the supervision of the network operator. This is the point when PMIPv6 comes into the picture as introduced previously, and network related end-user functions are moved to the edge of the network, mainly as close to the end-user as possible (e.g., into the edge routers). At least one of the benefits of this is that MNs do not require modifications because network nodes will deal with mobility management procedures.

In 2008, 3GPP standardized PMIPv6 [17] and paved the way to start using PMIPv6 as a non-3GPP access provider protocol, e.g., for Wi-Fi access. As typical MNs started having multiple network interfaces, at this case LTE and Wi-Fi, several proposals had emerged to use them in offloading scenarios and extending mobile network reachability through Wi-Fi. There are several existing techniques dealing with one or more subtopics of the previously introduced problem space in the LTE/EPC context.

Multiaccess PDN Connection (MAPCON) [18, 19] makes a UE able to build up several Packet Data Network (PDN) connections through different access techniques (i.e., LTE, Wi-Fi, etc.). The Access Point Names (APNs) identifying these different PDNs are independent of each other. Furthermore, the UE and the mobile service provider are able to load-balance their traffic: it is possible to have multiple connections, one for a VoLTE/IMS [20, 21] and another one for pure data communication through non-3GPP access networks.

Selected IP Traffic Offload (SIPTO) [18, 22, 23] was designed to reduce the traffic that can reach the core network by performing flow-based offloading as close to the UE as possible. MME helps to select the (geographically) nearest SGW and PGW in order to minimize traffic load at the core segment. SIPTO can be used for offloading typically with the help of Home (e)NodeB entities.

Local IP access (LIPA) [18, 22] is a technique for reaching local resources via 3GPP interface without passing through the 3GPP core network. A new network element is introduced: Local Gateway (LGW) combined with the H(e)NodeB.

SIPTO needs to be performed close to the UE’s point of attachment. Thus, offload can be executed as close as possible to the source of traffic with mobility support called “SIPTO above RAN” (Figure 2). As LIPA, SIPTO for H(e)NodeB Subsystem enables breakout in enterprise networks [23]. Table 1 summarizes the main SIPTO and LIPA use-cases using the comparison of [24] as a basis.

Offload From
LGW collocated with eNodeBLGW separeted from eNodeB

Offload ToInternetSIPTO @LN (Figure 2 purple)SIPTO @LN (Figure 2 purple)SIPTO Above RAN (Figure 2 red)

Coordinated Selected IP Traffic Offload (CSIPTO) [25, 26] was introduced in order to coordinate SIPTO change of PGW and preserve IP address when required based on UE knowledge of different established IP flow types.

The coordinated SIPTO brings dynamic (or on-demand) flow-based mobility management into the EPC architectures. In case of SIPTO PGW switching the address on the UE’s 3GPP interface will be usually changed. Of course, not all the applications require hiding and/or seamlessly handling the effects of such IP address configuration (i.e., not every application needs mobility management).

Based on the lifetime of flows, short-lived and long-lived flows can be decoupled. Short-lived flows are web-browsing and instant messaging typically where connection breaking is not disturbing at all. In case of long-lived flows (e.g., flows of real-time and VPN services) a temporal gap in the connection can cause easily recognizable service outage and results in the reinitialization of many flows.

The above-mentioned differentiation also requires optimization relying on IP address preservation and routing. Certain applications need to have a constantly assigned IP address where only the change of IP address influences service performance. From the core network point of view, the path of traffic is also important in order to decrease its load.

There are three different use-cases regarding the optimization in CSIPTO scenarios [25, 27].(1)After SGW change, two PDN connections are maintained (Figure 3). The previous PDN connection is used by those applications which require IP address preservation even though the path has become suboptimal. As the traffic ceases on the first connection, the network will terminate it.(2)Two PDN connections are initialized, one with IP address preservation and one without this function (Figure 4). Each flow is directed to the proper connection based on the need of IP address preservation.(3)The architecture (Figure 5) is the same as in the second use-case (Figure 4), but by default only LGW connection is maintained. The PDN connection is on-demand based on the need of IP address preservation.

There are several other PMIPv6 flow mobility techniques in the literature dealing with resource efficiency optimization [28], distributed operation [29], or policy-based approach of mobility [30]. These detailed schemes are out of the scope of this current paper but worth mentioning as they acted as thought-provoking techniques that inspired our work.

A lot of papers also present concepts of PMIPv6 integration into 3GPP networks which fit into the proposal of the paper. Authors of [31] present decision algorithms for PMIPv6-based offloading, which also enables this paper to move forward. On the other hand, [32] discusses the dynamic mobility management concept. M. Kalyanaraman et al. propose an algorithm and an architecture where user preferences are taken into consideration by a network initialized handover. In this paper we rather deal with the integration part of PMIPv6 into EPC centralized around PCRF and examine a solution for control messages where we are supposed to run an offloading algorithm. They proposed a collection about the possible inputs for selecting the best interface for an application (such as user preferences, terminal capability, network conditions, operator triggers, application characteristics, and policy triggers).

Our recommendation for the introduced important use-cases (and others) is a flow-centric and operator-based solution. With the help of PMIPv6 the amount of required modifications at UE side can be mitigated. Moreover, we provide a novel point of view where dynamic mobility handling meets PMIPv6 based EPC instruments. In our experiments and analysis we discuss the advantage of dynamic mobility management in specific scenarios and calculate the amount of control messages.

There are existing publications in the literature which try to minimize the overhead of PMIPv6-based technologies. Byunghun et al. [33] proposed a technique to have a dynamic role assignment for PMIPv6 nodes from the LMA and MAG point of view. The role of a node could be changed to LMA or MAG in a distributed mobility environment. Their goal was to optimize the number of mobility management functions in order to minimize signaling overhead. Seil Jeon et al. [34] investigated flat architectures for PMIPv6-based networks. The main field of their paper is to optimize data plane and delivery cost. They conclude that DMM is effective for improving packet delivery in a network where IP-based mobility is used. These architectures do not deal with flow handling. In our paper, we involve the flow-based approach and this paper does not only work with individual mobile nodes; IP flows are separated and handled individually.

For supporting handovers and dealing with offloads there are also some proposals available in the literature [35, 36]. Also Chin-Yu-Liu et al. [37] proposed an ANDSF assisted PMIPv6 inter-MAG handover. Joseph Orimolade et al. [35] also propose more dynamic usage of ANDSF, similar to what we propose in this paper. However, these papers do not deal with the flow mobility concept we pursue.

Independently of the applied optimization scheme, one of the key aspects of any mobility management is to preserve IP addresses while mobile nodes are on the move. PMIPv6 has its own standardized way to do so also for multiaccess use-cases [6]. RFC 7864 [6] defines “Multiple Proxy Care-of-Address Registration” procedure. It reports that LMA can have multiple Binging Cache Entries (BCE) for one MN to differentiate between flows of MNs using Binding Identifier and priority, depicted on Table 2.



Specification of RFC 7864 [6] allows even having multiple Home Network Prefixes (HNPs) for a MN. In a real implementation on Unix systems flow handling can be performed via policy routing using iptables marking and multiple routing tables technics [38, 39]. The server side (at this case, the LMA) and the client side (MNs) should make their routing decisions besides ordinary routing based on (1) where the traffic comes from (from which interface) and (2) what type of traffic it is (e.g., TCP 80). This is what we are relying on in our scheme and what we have used during our measurements as well.

3. The Proposed Architecture

In this section we describe our architecture proposal for a PCRF-centric dynamic mobility management solution in LTE/EPC networks using PMIPv6 and present our recommendations on the signaling procedures and control message definitions.

In a typical operator scenario most of the user traffic is routed through PGWs independently of access networks. PCRF uses this advantage to create and enforce traffic rules. Policy and Charging Enforcement Function (PCEF) is the enforcer part of PCRF and could be colocated with PCRF or could be located on a different node [40, 41]. Regarding the functionality of any flow-based mobility management, PCRF is the potential node where UE related flow-based information can be maintained in the EPC. Furthermore, PCRF in EPC architecture has user specific rules which pertain, e.g., to shaping user traffic because of user quota overload for mobile Internet. So we believe it is easier to extend PCRF user rule database than to introduce new rule services and rules database on other elements in the architecture.

From the dynamic mobility management point of view, the main goals are to decrease the number of control messages, achieve lower latency, and create optimal path for different types of traffic. In our proposal we focus on use-cases where the UE has at least two interfaces, and the 3GPP interface is always connected. We use Wi-Fi connection as a new point of attachment which triggers the processing chain in our scheme to set up a new forwarding mechanism. PCRF can be considered as the main mobility enabler for flow-based dynamic mobility management where service allowance for UEs can be granted.

As related works like [6] conclude, active UE interaction is needed for PMIPv6-based flow mobility management. Flow rules have to be transported from the PCRF to UEs. These flow rules can be implemented as firewall settings and/or Policy-Based Routing (PBR) setups. The S14 interface is a possible way for sending the required control packets from the operator network to UEs in a form of an ANDSF message for example. To achieve connection between PCRF and ANDSF, a new interface needs to be defined between them. Reaching proper authentication, a HSS-PCRF interface may be recommended but it is out of the scope of this paper. New type of messages must also be applied for supporting mobility related decisions.

In this work we focus on the above signaling and architectural issues. Figure 6 introduces our suggested modifications. Red lines present our newly proposed interfaces between the existing components. PCRF is the node, which has a global view on all flow policies of all users in the infrastructure. Connecting PCRF with LMA means that PCRF acts as a flow enabler for specific UEs. PCRF requires an interface with MME so as to perform location-based user policies. The interface between PCRF and OAM ensures network level decisions from the operator perspective. Through ANDFS, PCRF can push the user policies to UEs.

3.1. Proposal for Mobility Management Procedures in Case of UE Initiated Mobility Scenarios

Figure 7 shows the detailed procedures of our scheme designed for managing scenarios of UE mobility. The initiator Router Solicitation (RS) message is triggered when UE reaches a new network during its movement. A particular Mobile Access Gateway (MAG), which manages this part of the network, sends a Proxy Binding Update (PBU) message to the Local Mobility Anchor (LMA) and in parallel allocates a Care of Address (CoA) for UE. The LMA sends a Flow Update Request (FUR) packet to the PCRF, asking permission for accepting PBU with a Proxy Binding Acknowledgment (PBA). Then the PCRF checks whether UE is allowed to connect and what kind of restrictions need to be enforced. PCRF with the help of the Current Flow Information Request (CFR) message asks ANDSF about the current active flows on the UE. ANDSF sends a Flow Discover Request (FDR) message for asking the UE about its flows. The UE replies with a Flow Discover Response (FDP) where all the IP flows are counted and detailed in the form of 5-tuples. ANDSF forwards this information to the PCRF in a Current Flow Information Response (CFP) message. After processing the new information, PCRF can decide whether there are flows which are worth offloading (i.e., to be moved between available access networks) or not. If yes, the PCRF sends a Mobility Update Request (MUR) message that triggers the ANDSF to discover the current radio environment of UE based on [42, 43] (i.e., whether it is capable of a handover from the radio resources point of view). This radio discovery is done by the Handover Discover Request (HDR) message in our proposal. After UE has collected enough information about its radio layer perspectives, it replies with a Handover Discover Response (HDP) message through the S14 interface. ANDSF will decide if the handover can be performed or not. If it is possible, ANDSF sends a Mobility Update Accept (MUA) message to the PCRF (for negative results, a Mobility Update Reject (MUR) is transferred). The PCRF sends new PBR setup to ANDSF with the help of Mobility Policy Update (MPU) message, and then the ANDSF forwards it in a PBR Update (PBRU) through the S14 interface to the UE. If a new PBR is accepted, PBR Update Success (PBRS) is the answer from the UE. The ANDSF sends the acknowledgment of MPU as a Mobility Policy Acknowledgment (MPA). The UE can reject new PBR settings with a PBR Reject (PBRR) message. The PCRF replies to the LMA with a Flow Update Accept (FUA) message, which triggers LMA to accept the PBU with a PBA. Finally, the MAG sends the Home Address (HoA) which was allocated previously by LMA to UE in a Router Advertisement (RA) message.

In case of a new valid attachment of a UE which does not have flows to be offloaded, the PCRF sends predefined PBR rules. When the PCRF rejects new attachments for some reason, it sends a Flow Update Reject message to the LMA. The LMA does not reply to PBU, and then the MAG timer expires and no mobility management will happen. Therefore, packets from the UE are forwarded according to the current routing table of the MAG. However, the PCRF sends default PBR settings to UE, so MPU-PBRU-MPA control messages can be originated.

3.2. Proposal for Mobility Management Procedures in Case of Operator-Initiated Mobility Scenarios

Motivated by the continuous fluctuation of network load in current and future mobile architectures, we also propose a new procedure for network initialized flow-redistribution (Figure 8). A typical use-case is when in a Tracking Area (TA) some eNodeB-s become overloaded (e.g., during a major sport event). The Operation and Management (O&M) system of the mobile network monitors all the elements of the telco environment. According to these signals, efficient offloading can be performed in order to handle peak traffic periods. Continuing our previously introduced message flow, a new PCRF-based scenario is suggested to handle offloading control signals from the O&M. (Note that this paper does not consider details of O&M mechanisms; we handle it as a “black box” which defines an interface towards the PCRF.)

In this situation ongoing flows are offloaded in spite of having been newly initialized. As the PCRF does not store any user-related location information, it needs to set up a connection with the MME in the form of the novel PCRF-MME interface. A requirement for MME is to be able to answer questions on which users are connected through a specific eNodeB or TA.

After getting triggered by the O&M (Offload trigger), PCRF sends a Location Discover Request (LDR) message to MME, which includes ID of eNodeB in order to query which UEs are located in that specific area. MME responds with a Location Discover Response (LDP), including the ID of the UE. The procedure then continues in the same way that we introduced in the previous section.

3.3. S14 Signaling

ANDSF uses Managed Object (MO) tree [44] for sending its signaling messages through the IP network. In our proposal we use several types of new messages belonging to S14 interface (Figures 7 and 8 summarize these message flows). In order to keep the S14 signaling simple in our architecture we use this “FDR-FDP, HDR-HDP, and PBRU-PBRS” naming convention for the specific parts of standardized ANDSF messages. 3GPP TS 24.312 [44] defines structures for IP flow and routing rule description (see chapters 5.7.38-5.7.59). We suggest using these structures for FDR-FDP and PBRU-PBRS exchange. M. Nahas et al. describe a MO tree for handling UE physical related data in [45] which can be used for the HDR-HDP signaling message pair also in our scheme (Figure 9).

4. Virtual Testbed Design and Implementation

4.1. Main Assumptions

In order to define a framework for verification, functional, and performance evaluation of network-based mobility management schemes in general, we designed a virtual testbed architecture with the main goal of getting an overall picture about the behavior of end-to-end IP level connections in PMIPv6-based mobility extensions with emulated EPC network elements during handovers. On the other hand, we also aimed to measure how many handovers can be performed without service degradation. As we assume that UE has at least two interfaces with different access types, we specified three types of access networks:(i)LTE(ii)Wi-Fi(iii)Ethernet (for referential point)

For simplicity we spared the very detailed implementation of the above-mentioned wireless connections and we just emulate their usual latency, jitter, and other QoS parameters; channel parameter values for emulating the radio link of LTE and Wi-Fi networks are detailed in [46] and can be enforced by TC program [47], while iPerf [48] and D-ITG [49] are used as traffic generators. Server parts of the mentioned synthetic traffic injectors take place at Correspondent Node (CN) intended as the destination of end-to-end measurement and introduced in RFC 6275 [1].

4.2. Building Blocks

Our testbed infrastructure relies on VMware ESXi, but also KVM or other virtualization environments could be applied for running the virtual machines which are associated with different LTE/EPC network elements.

Furthermore, a proper PMIPv6 implementation is needed. Eurecom has an open solution called Open Air Interface (OAI) PMIPv6 [50]. We applied this implementation and its collocated FreeRadius server in order to enable and efficiently support authentication procedures. By default, this radius service uses UE MAC addresses.

PCRF-PCEF functionalities are implemented with the integration of the open PCRF solution by University of Cape Town [51].

4.3. Testbed Design

The testbed environment was implemented on VMware ESXi managed virtual machines where Ubuntu 12.04 Linux operating systems were running with Linux Kernel 3.16.3 (see Figure 10 for details).

UE systems possess at least two interfaces for emulating multiaccess behavior in the testbed architecture.

For artificial handover initialization we used the Perl-based Application Programming Interface (API) of VMware; through this we can automate network selection as switching between Portgroups, or an interface can be shut down entirely regardless of the current state of the interface in the OS.

The OAI PMIPv6 implementation does not contain flow mobility implementation, but it is applicable for testing even advanced flow mobility extensions because it does not recognize whether PBUs come from the same UE or not. This behavior allows all the interfaces to be handled separately in the virtual testbed and PBUs can be triggered on every interface. With the help of a PBR on the UE regarding the type of L4 protocol we can specify the interface where the packet needs to be sent out. Our flow offloading test concept assumes that Wi-Fi and LTE have overlapping coverages while flow-based handovers are performed. In those cases, where the new attachment of UE needs to be tested, the Wi-Fi interface can be shut down and turned back on; thus a Router Solicitation (RS) message can initiate the attachment procedure.

The Management Node takes place in the centre of the proposed architecture (Figure 10). The main task of it is to emulate the context of inter-technology handovers. There are several basic scripts in the literature (e.g., [52]) which helped us to develop a specific controller software artificially executing network changes (i.e., connect a VM’s vNIC to another vSwitch, and update Portgroup). Other tasks of the Management Node is to create PBR rules and transport them to UEs. In practice, the Netfilter kernel module is used with ip6tables to set up Mangle table rules for identifying and directing flows to the right routing table where default routes are configured according to the destination interface of the packets. This is the scheme we propose for emulating control packets between UE and ANDSF at S14 interface. Of course, these rules can be transported in several other ways (e.g., Expect scripts). As an orchestration script that is also needed for synchronizing handovers and PBR updates, Bash Unix shell and command language was our choice to do so.

The PS Core node represents a 3GPP network (the packet transmission path from eNodeB to SGW), while the MAG acts as a non-3GPP access network (from a Wi-Fi access point, furthermore optionally through Wireless Controllers).

As it can be seen in the proposed logical architecture (Figure 11), in the test environment PCRF and PCEF functions are also embedded with LMA for limiting the number of the required VMs. The dotted lines represent the appropriate 3GPP logical interfaces:(i)Green dotted line: S14 interface between ANDFS and UE(ii)Yellow dotted line: Proposed new logical interface between ANDSF and PCRF(iii)Red dotted line: S2a interface between PGW and MAG(iv)Purple dotted line: SGi interface as a gateway to other networks, primary direction of CN

4.4. Control Script Examples

As we introduced above, we applied the VMware Perl API with certain Bash extensions to control our virtual environment. Below you can find an example basic handover manager script (VMware ESXi IP address needs to be used in place of


./updateVMPortgroup.pl --username usr

--password passwd --server

--vmname "UE" --vnic 1 --portgroup "UE-PS"

echo "Interface down"



./updateVMPortgroup.pl --username usr --

password passwd --server

--vmname "UE" --vnic 1 --portgroup "UE-PS"

echo "Interface down is done, wait 5 secs"

sleep 5


./updateVMPortgroup.pl --username usr

--password passwd --server

--vmname "UE" --vnic 1 --portgroup "UE-MAG"

echo "Interface up"


echo "Interface up is done"

sleep 5

Example Bash script to modify the UE PBR rules in order to proceed with an offload:

function set_udp_for_wifi

    check=ip -6 rule show | grep -cw 0x64

  if [  check -ge 1  ]; then

       echo "Existing UDP rule, deleting


       ip -6 rule del pri 100


  echo "Setting UDP for Wifi..."

ip -6 rule add pri 100 fwmark 100 table


ssh UE " (typeset -f); set_udp_for_wifi"

5. Evaluation and Results

The evaluation of our scheme was focused on both testbed performance measurements and calculations using mathematical models.

The two main performance indicators of the testbed measurements were (1) UDP packet loss ratio and (2) TCP throughput. With appropriate settings of the QoS variables we could emulate the increasing UE distance from radio base stations and model the degradation of radio signals. All the below scenarios assume that the UE has two active interfaces (LTE and Wi-Fi). In every step 40 measurements have been performed, so in one scenario there were 270 executions. All the flows were one minute long.

The applied mathematical model is based on [53, 54] and operates with session holding time. It examines the ratio, i.e., whether the current preinitialized flow is terminated at a femtocell or not. From this ratio it tries to give a prediction of the handover probability. It has also parameters like the ratio of vehicular (e.g., car) and nonvehicular (e.g., pedestrian) users. The base environment has a femtocell and it is covered by a macrocell as an umbrella. In such a model one can distinguish between two different scenarios: (1) when a user moves through it without stopping while maintaining its session and (2) when a user goes inside the femtocell, stops there, and halts its session. We use the second scenario as a base to calculate control message overhead for the mathematical model inherited from [53].

5.1. TCP Throughput Depending on the Number of Network Changes
5.1.1. Scenario Description

The goal is to conclude the extent of the TCP throughput degradation in function of the number of handovers in our scheme.

5.1.2. Procedure (Figure 12)

Packet loss ratio is increased by 0.1%, and the expected value of latency is increased by 10 ms in every step of the measurement where a parameter is changed on the 3GPP (initial parameters for 3GPP interface: 77 ms delay with 21 ms deviation with normal distribution, packet loss ratio: 0,13%; initial parameters for Wi-Fi interface: 40 ms delay with 16 ms deviation with normal distribution, packet loss ratio: 0,25%); 0-4 network changes (i.e., handover situations) happen in every case, and 1-1 UDP and TCP flow run simultaneously. The measurement starts with the two flows bound to the 3GPP interface, and then with the help of policy-based routing, the TCP flow is continuously moved between the interfaces. It means that only the TCP flow is offloaded. Tunnel is used in the direction of Wi-Fi.

5.1.3. Diagram Conclusion (Figure 13)

In cases where there are no handovers, the system behaves even worse than in case of four network changes, meaning that the offloading could increase throughput even when the ping-pong effect occurs.

5.2. UDP Packet Loss Depending on the Number of Network Changes
5.2.1. Scenario Description

The goal is to conclude the amount of the UDP packet loss ratio during different numbers of network changes.

5.2.2. Procedure (Figure 14)

packet loss ratio is increased by 0.1%, and the expected value of latency is increased by 10 ms in every step on the 3GPP interface (initial parameters for 3GPP interface: 77 ms delay with 21 ms deviation with normal distribution, packet loss ratio: 0,13%; initial parameters for Wi-Fi interface: 40 ms delay with 16 ms deviation with normal distribution, packet loss ratio: 0,25%); 0-4 network changes happen in every case and 1-1 UDP and TCP flow run simultaneously. The measurement starts with the two flows bound to the 3GPP interface, and then with the help of policy-based routing, the UDP flow is continuously moved between the interfaces. It means that only the UDP flow is offloaded. Tunnel is used in the direction of Wi-Fi.

5.2.3. Diagram Conclusion (Figure 15)

In those cases where nothing happens with the flow, the worst-case scenario occurs. Even having four handovers within one minute is better than leaving flow alone (untouched) within degrading transmission circumstances on the 3GPP link.

5.3. Tunnel-Usage Overhead and TCP Throughput
5.3.1. Scenario Description

The goal of the measurement is to examine how tunnelling overhead of mobility management techniques modifies TCP throughput of user plane traffic. The key benefit of dynamic mobility management comes with decreasing the tunnel initialization and usage overhead.

5.3.2. Procedure (Figure 16)

Packet loss ratio is increased by 0.1%, and the expected value of latency is increased by 10 ms in every step on the 3GPP interface (initial parameters for 3GPP interface: 77 ms delay with 21 ms deviation with normal distribution, packet loss ratio: 0,13%; initial parameters for Wi-Fi interface: 40 ms delay with 16 ms deviation with normal distribution, packet loss ratio: 0,25%); 0 and 1 network changes happen in every case and 1-1 UDP and TCP flow run simultaneously. The measurement starts with the two flows bound to the 3GPP interface, and then then with the help of policy-based routing, the TCP flow is continuously moved between the interfaces. It means that only the TCP flow is offloaded. In the scenario, where tunnel is not used, no PMIPv6 mobility processes run.

5.3.3. Diagram Conclusion (Figure 17)

In case of standard mobility management the useful payload was decreased; unnecessary tunnel header causes overhead as it was expected before.

5.4. Tunnel-Usage Overhead and UDP Packet Loss
5.4.1. Scenario Description

The goal of the measurement is to examine how tunnelling overhead of mobility management techniques affects UDP packet loss.

5.4.2. Procedure (Figure 18)

Packet loss ratio is increased by 0.1%, and the expected value of latency is increased by 10 ms in every step on the 3GPP interface (initial parameters for 3GPP interface: 77 ms delay with 21 ms deviation with normal distribution, packet loss ratio: 0,13%; initial parameters for Wi-Fi interface: 40 ms delay with 16 ms deviation with normal distribution, packet loss ratio: 0,25%). 0 network changes and 1 network change happen in every case and 1-1 UDP and TCP flow run simultaneously. The measurement starts with the two flows bound to the 3GPP interface, and then with the help of policy-based routing, the UDP flow is continuously moved between the interfaces. It means that only the UDP flow is offloaded.

5.4.3. Diagram Conclusion (Figure 19)

Practically there is no difference between the standard and dynamic mobility solutions.

5.5. Control Message Overhead
5.5.1. Scenario Description

the goal of this calculation is to highlight the overhead of control or signaling messages of mobility management.

Figure 20 shows a diagram created using the models and calculations based on [53] to show probability of handover based on the ratio of vehicular and nonvehicular users. The scenario sets a femtocell inside a macrocell: a user goes through it and then terminates its session inside the femtocell. A vehicular user can be considered as a car while a nonvehicular user is usually a pedestrian. The model shows that if a pedestrian goes through the macrocell-femtocell path, it is more likely to have a handover as the network has time to drop the user from the macrocell to femtocell to offload the macrocell. There are two corner cases which can also be seen in Figure 20 diagram: even though every user is a pedestrian, that does not mean 100% have a handover; on the contrary, when everyone is a fast mover, who can just run through this macrocell-femtocell scenario, it is not 0% not having any handover, as network can decide for some reason to put some users into the femtocell even for a short time.

We evaluated a scenario when 1,000,000 users are moving with 30 sessions per each, and we counted the number of PBU/PBA messages with respect to the ratio of vehicular and nonvehicular UEs. The x-axis shows the ratio of user sessions which require mobility handling (i.e., the ratio of user sessions causing mobility control message overhead). The sizes of the PBU and PBA messages are considered 76 bytes [9].

5.5.2. Diagram Conclusion

We reach the biggest benefit when the ratio of the nonvehicular users is high but the number of sessions requiring mobility handling is low. The diagram in Figure 21 shows the overhead is at the 108 byte range, and it increases to the 109 byte range within diagrams through Figure 22 till Figure 23. The more nonvehicular users we have in this scenario, the more time the network has preparing handovers. The less mobility required sessions the users have, the more overhead is caused as there is no need for mobility handling. Figure 24 summarizes diagrams of Figures 21, 22, and 23 by composing aggregated and compared results.

6. Discussion on 5G Application Possibilities and Other Issues

As 5G is on the corner with its service-based architecture approach, Software Defined Networking (SDN) and Network Function Virtualization (NFV) paradigms are feeding the cellular evolution; the PMIPv6 application possibilities and dynamic mobility management within this context are worth talking about.

Our approach mainly focuses on offloading specific traffic from mobile network radio interfaces to the available Wi-Fi connection on a dynamic way driven by the network side. This capacity saving effort is also valid for 5G networks but in a different way. 5G natively brings SDN with it and OpenFlow is one of the most common approaches to implement SDN, and it also operates with flows. Thus, observing similarities between OpenFlow and our flow-based approach makes sense.

OpenFlow stores its flow tables “inside” the operator network in SDN Controllers and OpenFlow-capable switches, and flow identification takes place on those switches at the operator side. In our approach flows are identified at the mobile end-user side (UE) with the practical iptables/Netfilter toolset, and the first routing decision takes place on the UE side as it chooses which interface the traffic has to be routed to by receiving the proper Netfilter ruleset through ANDSF S14 interface. This is a kind of breakpoint where the native authority of SDN ends and operator-side flow rules have to be converted to iptables user-side rules via ANDSF-based control channel communication. But if an OpenFlow-capable software switch, i.e., Open vSwitch, is built into the UE, then OpenFlow rules can be directly applied at the user side. This approach creates a “virtual switched link” on radio interfaces between the last edge device of the network and the UE. The PMIPv6 approach is still valid as IP address preservation and maintenance should be handled to avoid session disruption. But it is really needed to be aligned with OpenFlow and SDN concepts in general. There are several proposals to integrate PMIPv6 with OpenFlow (e.g., [5559]), but it is still not defined how to move forward with it, and even it leads to a bigger question, how to do (IP-based) mobility management in an SDN-based infrastructure? Furthermore, examining whether the usage of softswitch or iptables is better on the UE side is an interesting future work of this topic. Concluding the control channel location is a future work proposal as well, because it could extend current ANDSF or dedicate a new control channel next to S1 interface which also makes sense from some perspective. To insert here the details of ongoing proposals for integrating OpenFlow and PMIPv6 is outside the scope of this paper as it is a different topic.

Beyond SDN, NFV also has impact on existing 4G networks and the upcoming 5G infrastructures will definitely be built on it. PMIPv6 LMAs and MAGs are kinds of servers, and they handle traffic. So “cloudifying” PMIPv6 to make them scalable and adjustable to the current traffic requirements has a valid research value. But with scaling more and more executors (new LMAs and MAGs are instantiated) they need a common control logic, at least a common database where flow rules are stored, and consistent decisions can be made individually. Distributed mobility management is the topic which deals with multiple numbers of LMAs and MAGs on the same network. Distributed mobility management is also far beyond the scope of this paper, but it has valid approaches for cloud-based usage of mobility management technics.

At the end of the day, our goal is to create a “Mobility Management as a Service” (MMaaS) solution where MIPv6- and PMIPv6-based mobility management schemes can be offered even in an on-demand way. The above-mentioned directions and our proposal introduced and analyzed above are keen on going to this direction. Let us mention at this point that another challenge is to make the codebase of PMIPv6 cloud-native, so relying on intensive usage of containers and container orchestrators is on the page, even having control interface with Virtual Infrastructure Managers (VIM) like OpenStack.

In such a MMaaS solution ANDSF could play an important information provider function. ANDSF is not so static right now as it is regarded in this paper. But if we stick to that view, the proposed approach in this paper is rather a 4G evolutionary step, and then ANDSF could also fit into these architectural changes. During this new feature introduction, the first step could be just to use some predefined rules; for example, if Wi-Fi is available and with good quality, then offload on-demand video there. Dynamism could come at the second step when every flow is identified, and dynamic traffic offloading could start. Of course, we see that there is a significant amount of time needed to move forward from step 1 to step 2 as a lot of testing should be involved in a real network. Furthermore, novel ways of ANDSF operation might be possible as applications require more and more dynamism from networks. The ANDSF usage proposal in this paper might lead to new ANDSF standardization processes.

As a conclusion for the discussion we can state that at this stage our proposal is a 4G extension and not a 5G centric approach, but with the above-mentioned thoughts the scheme can be applied to 5G contexts and pave the way to a huge amount of further researches. However, from backward compatibility point of view, lifting mobility management into the SDN and NFV context is also important because existing 2G/3G/4G physical equipment will be cloudified no matter how and when 5G arrives exactly. Furthermore, offload problems and approaches will be still valid in 5G networks, and IP-based mobility management with our offload proposal may be easily applied. Spectrum saving and mobile traffic increasing will be a trend in the near future and smart ways of resource usage will be beneficial. Our proposal could be one of the applicable approaches.

7. Conclusions and Future Work

Extrapolated from the measurement result, the flow-based and dynamic mobility management shows significant advantages considering its efficient offloading capabilities from the operator’s point of view. According to the results from the test environment and calculations, offloading from the continuously degrading 3GPP interface to the stable Wi-Fi network is beneficial. Furthermore, if the handover is not smooth enough and 3GPP interface is used again, proceeding with handovers, rather than leaving the traffic alone on the 3GPP interface, is still worthy. Of course, the higher the number of handovers performed, the more the degradation of Quality of Service expected, and therefore optimal decision schemes must be applied.

The real benefits of dynamic mobility management are realized in decreasing the signaling message overhead. On the other hand, the cost of data plane can be eliminated. There is a further possible optimization when traffic is offloaded next to the MAG directly where traffic does not reach the core network.

Flow-based and operator-centric mobility management combined with dynamic mobility can create benefits regarding the user experience and operators’ point of view as well. These methods may be profitable for those service providers who run wired and wireless services too. This technology also enables extending the coverage area as Wi-Fi networks could play an integrated part of 3GPP network services. New means of services can be deployed (Voice over Wi-Fi) where cost reduction could be achieved. Heterogeneous architectures, where several types of access networks are placed, can benefit from the research of offloading as it could ensure a smother handover procedure and enable a new level of integration.

Future research plans are about developing an offloading algorithm regarding the dynamic mobility management schemes based on our findings described in this paper.

Data Availability

The data used to support the findings of this study are included within the article.


An early version of the hereby presented proposal and some details on the applied virtual testbed design and implementation were published by the same authors during the “Mesterpróba 2015” student conference at Budapest University of Technology and Economics [60]. Special thanks are due to Norbert Varga for supporting conversations and valuable comments.

Conflicts of Interest

The authors declare that they have no conflicts of interest.


This work was performed in the frame of FIEK_16-1-2016-0007 project, implemented with the support provided from the National Research, Development and Innovation Fund of Hungary, financed under the FIEK_16 funding scheme.


  1. C. Perkins, RFC 6275, Mobility Support in IPv6, D. Johnson and J. Arkoo, Eds., 2011.
  2. S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B. Patil, RFC 5213, Proxy Mobile IPv6, 2008.
  3. R. Wakikawa, RFC 5648, Multiple Care-of Addresses Registration, V. Devarapalli, G. Tsirtsis, T. Ernst, and K. Nagami, Eds., 2009.
  4. G. Tsirtsis, G. Giaretta, H. Soliman, and N. Montavont, RFC 6088, Traffic Selectors for Flow Bindings, 2011.
  5. G. Tsirtsis, H. Soliman, N. Montavont, G. Giaretta, and K. Kuladinithi, RFC 6089, Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support, 2011.
  6. C. J. Bernardos, RFC 7864 - Proxy Mobile IPv6 Extensions to Support Flow Mobility, 2016.
  7. C. J. Bernardos, A. de la Oliva, and F. Giust, “A PMIPv6-based solution for distributed mobility management,” 2018, https://tools.ietf.org/html/draft-bernardos-dmm-pmipv6-dlif-01. View at: Google Scholar
  8. H. A. Chan, H. Yokota, J. Xie, P. Seite, and D. Liu, “Distributed and dynamic mobility management in mobile internet: current approaches and issues,” Journal of Communications, vol. 6, no. 1, pp. 4–15, 2011. View at: Publisher Site | Google Scholar
  9. J.-K. Lee and T.-M. Chung, How Much Do We Gain by Introducing Route Optimization in Proxy Mobile IPv6 Networks? Institut TELECOM and Springer-Verlag, 2009.
  10. Y. Li, Z. Zhao, H. Li, H. Tang, and S. Ci, “A novel dynamic mobility management scheme in LISP architecture,” in Proceedings of the 2012 18th Asia-Pacific Conference on Communications (APCC), pp. 67–72, Jeju, Korea (South), October 2012. View at: Publisher Site | Google Scholar
  11. N. Kumareshan and P. Poongodi, “Dynamic mobility management architecture to improve quality of experience (QoE) in wireless networks,” in Proceedings of the 10th International Conference on Intelligent Systems and Control, ISCO 2016, India, January 2016. View at: Google Scholar
  12. C. Perkins, RFC 2002 - IP Mobility Support, 1996.
  13. S. Deering and R. Hinden, “RFC 1883 - Internet Protocol, Version 6 (IPv6) Specification, 1995”. View at: Google Scholar
  14. S. Thomson and T. Narten, Narten: RFC 1971 - IPv6 Stateless Address Autoconfiguration, 1996.
  15. T. Narten, E. Nordmark, and W. Simpson, “Neighbor discovery for IP version 6 (IPv6),” RFC Editor RFC1970, 1996. View at: Publisher Site | Google Scholar
  16. D. Johnson, C. Perkins, and J. Arkko, “RFC 3775 - Mobility Support in IPv6, 2004”. View at: Google Scholar
  17. TS 29.275: Proxy Mobile IPv6 (PMIPv6) based Mobility and Tunnelling, 2008.
  18. C. B. Sankaran, “Data offloading techniques in 3GPP Rel-10 networks: a tutorial,” IEEE Communications Magazine, vol. 50, no. 6, pp. 46–53, 2012. View at: Publisher Site | Google Scholar
  19. 3GPP TR 23.861 V1.12.0, Network based IP flow mobility (Release 13), Section 7: Solutions for multi access PDN connectivity and IP flow mobility, December 2014.
  20. IMS: 3GPP 23228: IP Multimedia Subsystem (IMS); Stage 2, 15.3.0, September 2018.
  21. Voice over LTE via Generic Access; Requirements Specification; Phase 1. VoLGA Forum, VoLGA Requirements V1.3.1., June 2009.
  22. 3GPP TR 23.829 V10.0.1 Local IP Access and Selected IP Traffic Offload (LIPA-SIPTO), March 2011.
  23. 3GPP TS 22.101 V13.6.0: Service aspects; Service principles (Release 13), March 2014.
  24. NEC, Mobile Traffic Offload: NEC’s Cloud Centric Approach to Future Mobile Networks, NEC Whitepaper, 2013.
  25. A. Yegin, 3GPP CSIPTO Presentation, Samsung Electronics, 2019, https://slideplayer.com/slide/10146319/.
  26. 3GPP TR 22.828 V13.0.0, Study on co-ordinated Packet data network GateWay (PGW) Change for Selected IP Traffic Offload (CSIPTO) (Release 13), June 2014.
  27. 3GPP TS 22823 v13: Study on co-ordinated Packet data network GateWay (PGW) Change for Selected IP Traffic Offload (CSIPTO), 2014.
  28. J. Jang, S. Jeon, Y. Kim, and J. Park, “Resource-efficient class-based flow mobility support in PMIPv6 domain,” in Proceedings of the Seventh International Conference on Networking and Services (ICNS’11), pp. 166–169, 2011. View at: Google Scholar
  29. K. Sun and Y. Kim, “Flow mobility management in PMIPV6-based DMM (Distributed mobility management) networks,” Journal of Wireless Mobile Networks, Ubiquitous Computing, and Dependable Applications, vol. 5, no. 4, pp. 120–127, 2014. View at: Google Scholar
  30. K. Sun and Y. Kim, “Policy-based flow mobility management in PMIPv6 networks,” in Proceedings of the 2012 International Conference on ICT Convergence (ICTC), pp. 724-725, Jeju, Korea (South), October 2012. View at: Publisher Site | Google Scholar
  31. M. Kalyanaraman, S. Seetharaman, and S. Srikanth, “Integrated approach for proxy-mobile-IPv6 (PMIPv6) based IP Flow Mobility and offloading,” in Proceedings of the 2015 21st National Conference on Communications, NCC 2015, pp. 1–6, India, March 2015. View at: Google Scholar
  32. M. Kalyanaraman, S. Seetharaman, and S. Srikanth, “Dynamic and integrated approach for proxy-Mobile-IPv6 (PMIPv6) based IP flow mobility and offloading,” in Proceedings of the International Conference on Computing and Communications Technologies, ICCCT 2015, pp. 356–361, India, February 2015. View at: Google Scholar
  33. B. Song, J. Shin, S.-H. La, and J. Jeong, “On minimizing signaling costs for PMIPv6-based distributed dynamic mobility management,” in Proceedings of the 7th IEEE Annual Ubiquitous Computing, Electronics and Mobile Communication Conference, UEMCON 2016, USA, October 2016. View at: Google Scholar
  34. S. Jeon, S. Figueiredo, and R. L. Aguiar, “On the impacts of distributed and Dynamic Mobility Management strategy: a simulation study,” in Proceedings of the 6th IFIP/IEEE Wireless Days Conference, WD 2013, November 2013. View at: Publisher Site | Google Scholar
  35. J. Orimolade and N. Ventura, “Intelligent access network selection for data offloading in heterogeneous networks,” in Proceedings of the 12th IEEE AFRICON International Conference, AFRICON 2015, Ethiopia, September 2015. View at: Google Scholar
  36. F. Leu, P. Tsai, I. You, and H. Chen, “IP-based seamless handover scheme using ANDSF in an untrusted environment,” in Proceedings of the 2017 IEEE Conference on Computer Communications: Workshops (INFOCOM WKSHPS), pp. 595–600, Atlanta, GA, USA, May 2017. View at: Publisher Site | Google Scholar
  37. C. Liu, F. Leu, J. Liu, A. Castiglione, and F. Palmieri, “Heterogeneous network handover using 3GPP ANDSF,” in Proceedings of the 2015 IEEE 29th International Conference on Advanced Information Networking and Applications (AINA), pp. 171–175, Gwangiu, South Korea, March 2015. View at: Publisher Site | Google Scholar
  38. Linux Policy Routing: 2019. https://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.simple.html.
  39. Chapter 11. Netfilter & iproute - marking packets. 2019. https://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.netfilter.html.
  40. PCRF and PCEF in LTE | Functions of PCRF and PCEF in LTE: http://www.rfwireless-world.com/Terminology/LTE-PCRF-vs-PCEF.html.
  41. 3GPP TS 23.203: Policy and Charging Control Architecture, 15.4.0, 2018.
  42. IEEE Standard for Local and metropolitan area networks- Part 21: Media Independent Handover. IEEE Std 802.21-2008.
  43. O. Khattab and O. Alani, “A survey on MIH vs. ANDSF: who will lead the seamless vertical handover through heterogeneous networks?” International Journal of Future Generation Communication and Networking, vol. 6, no. 4, 2013. View at: Google Scholar
  44. 3GPP TS 24.312 V15.0.0, Access Network Discovery and Selection Function (ANDSF) Management Object (MO), (Release 15), May 2018.
  45. M. Nahas, M. Mjalled, Z. Zohbi, Z. Merhi, and M. Ghantous, “Enhancing LTE - WiFi interoperability using context aware criteria for handover decision,” in Proceedings of the 2013 25th International Conference on Microelectronics, ICM 2013, pp. 1–4, (Fig. 2: ANDSF-MO structure updated with the inserted parameters), Lebanon, December 2013. View at: Google Scholar
  46. I. Grigorik, High Performance Browser Networking, Chapter 7. Mobile Networks, 2019, https://hpbn.co/mobile-networks/.
  47. TC, Traffic Control in Linux Kernel, 2019, https://linux.die.net/man/8/tc.
  48. iPerf, “The network bandwidth measurement tool,” 2019. https://iperf.fr/. View at: Google Scholar
  49. Distributed Internet Traffic Generator, 2019. http://traffic.comics.unina.it/software/ITG/.
  50. Eurecom, Open Air Interface PMIPv6 Implementation, 2019, http://openairinterface.eurecom.fr/openairinterface-proxy-mobile-ipv6-oai-pmipv6.
  51. R. Good and N. Ventura, “An evaluation of transport layer Policy Control in the IP multimedia subsystem,” in Proceedings of the 2008 IEEE 19th International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC), pp. 1–5, Cannes, France, September 2008. View at: Publisher Site | Google Scholar
  52. W. Lam, http://www.engineering.ucsb.edu/~duonglt/vmware/ Original code based on: http://communities.vmware.com/message/840944#840944.
  53. H. Zhang, W. Ma, W. Li, W. Zheng, X. Wen, and C. Jiang, “Signalling cost evaluation of handover management schemes in LTE-Advanced femtocell,” in Proceedings of the 2011 IEEE 73rd Vehicular Technology Conference, VTC2011-Spring, pp. 1–5, Hungary, May 2011. View at: Google Scholar
  54. A. Hasib and A. O. Fapojuwo, “Mobility model for heterogeneous wireless networks and its application in common radio resource management,” IET Communications, vol. 2, no. 9, pp. 1186–1195, 2008. View at: Publisher Site | Google Scholar
  55. S.-M. Kim, H.-Y. Choi, P.-W. Park, S.-G. Min, and Y.-H. Han, “OpenFlow-based proxy mobile IPv6 over software defined network (SDN),” in Proceedings of the 2014 IEEE 11th Consumer Communications and Networking Conference, CCNC 2014, pp. 119–125, Las Vegas, NV, USA, January 2014. View at: Google Scholar
  56. S. Chourasia and K. M. Sivalingam, “SDN based Evolved Packet Core architecture for efficient user mobility support,” in Proceedings of the 1st IEEE Conference on Network Softwarization, NETSOFT 2015, pp. 1–5, London, UK, April 2015. View at: Google Scholar
  57. A. Aissioui, A. Ksentini, and A. Gueroui, “PMIPv6-based follow me cloud,” in Proceedings of the 58th IEEE Global Communications Conference, GLOBECOM 2015, San Diego, CA, USA, December 2015. View at: Google Scholar
  58. K. Tantayakul, R. Dhaou, and B. Paillassa, “Impact of SDN on mobility management,” in Proceedings of the 30th IEEE International Conference on Advanced Information Networking and Applications, AINA 2016, pp. 260–265, Crans-Montana, Switzerland, March 2016. View at: Google Scholar
  59. S. M. Raza, D. S. Kim, D. Shin, and H. Choo, “Leveraging proxy mobile IPv6 with SDN,” Journal of Communications and Networks, vol. 18, no. 3, pp. 460–475, 2016. View at: Publisher Site | Google Scholar
  60. A. Leiter and L. Bokor, “A virtual testbed for analysis and design of advanced network-based mobility extensions,” in Proceedings of the Mesterpróba 2015: Tudományos konferencia végzős MSc és első éves PhD hallgatóknak Távközlés és infokommunikáció témakörében, pp. 37–40, Budapest, Hungary, 2015. View at: Google Scholar

Copyright © 2019 Ákos Leiter and László Bokor. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

More related articles

989 Views | 311 Downloads | 1 Citation
 PDF  Download Citation  Citation
 Download other formatsMore
 Order printed copiesOrder

Related articles

We are committed to sharing findings related to COVID-19 as quickly and safely as possible. Any author submitting a COVID-19 paper should notify us at help@hindawi.com to ensure their research is fast-tracked and made available on a preprint server as soon as possible. We will be providing unlimited waivers of publication charges for accepted articles related to COVID-19. Sign up here as a reviewer to help fast-track new submissions.