Abstract
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 [3–5], 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 [7–11] 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.
2. Background and Related 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.
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 1.2.3.4):
#!/bin/bash
./updateVMPortgroup.pl --username usr
--password passwd --server 1.2.3.4
--vmname "UE" --vnic 1 --portgroup "UE-PS"
echo "Interface down"
./intdown.exp
echo "CHANGE TO UE-PS"
./updateVMPortgroup.pl --username usr --
password passwd --server 1.2.3.4
--vmname "UE" --vnic 1 --portgroup "UE-PS"
echo "Interface down is done, wait 5 secs"
sleep 5
echo "CHANGE TO UE-MAG"
./updateVMPortgroup.pl --username usr
--password passwd --server 1.2.3.4
--vmname "UE" --vnic 1 --portgroup "UE-MAG"
echo "Interface up"
./intup.exp
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
fi
echo "Setting UDP for Wifi..."
ip -6 rule add pri 100 fwmark 100 table
table_wifi
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., [55–59]), 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.
Disclosure
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.
Acknowledgments
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.