1

SIFM: A network architecture for seamless flow

mobility between LTE and WiFi networks –
Analysis and Testbed Implementation
Dhathri R. Purohith and Krishna M. Sivalingam, Fellow, IEEE

Abstract—This paper deals with cellular (e.g. LTE) networks network for traffic offload. Many ISPs such as AT&T and
that selectively offload the mobile data traffic onto WiFi (IEEE networking companies like Cisco and Qualcomm have studied
802.11) networks to improve network performance. Several architectures to offload the 3G/4G traffic to the WiFi [1], [2].
architectures that are proposed based on the IETF Proxy Mobile
IPv6 (PMIPv6) framework to support seamless data offloading In data offloading, maintaining the user sessions and offloading
lacks flow-level mobility support and have a single point of of selective flows provides the best user experience in addition
failure. Recently, IETF has proposed extensions to PMIPv6 to balancing the load on the networks.
to support flow-mobility, in which the mobility decisions are The main challenge faced in maintaining the user sessions
done at the Packet Gateway (PGW). This adds complexity at across networks is that connecting to a different network
the edge of the LTE core network. We propose the Seamless
Internetwork Flow Mobility (SIFM) architecture that overcomes changes the IP address of the user, resulting in loss of the
these drawbacks and provides seamless flow-mobility support IP session. The reason for this is, originally Internet Protocols
using concepts of Software Defined Networking (SDN). The were designed such that the IP address was used to define both
SDN paradigm decouples the control and data plane, leading the identifier and the location of an entity at the same time in
to a centralized network intelligence and state. The SIFM order to reduce the size of the headers. As a result, TCP/IP
architecture utilizes this aspect of SDN and moves the mobility
decisions to a centralized Flow Controller (FC). This provides depends on retaining the same IP address at both endpoints
a global network view while making mobility decisions and after the movement in order to maintain the session. Therefore,
also reduces the complexity at the PGW. We implement and in order to provide seamless user session mobility, the locator
evaluate both basic PMIPv6 and the SIFM architectures by and the identifier properties of the IP must be decoupled,
incorporating salient LTE and WiFi network features in the which is achieved by IP mobility. Hence, to facilitate seamless
ns-3 simulator. Performance experiments validate that seamless
mobility is achieved. Also, the SIFM architecture shows an data offload, we require the network to efficiently support IP
improved network performance when compared to the base mobility.
PMIPv6 architecture. A proof-of-concept prototype of the SIFM IP mobility provides an option to move either all or no
architecture has been implemented on an experimental testbed. flows of a given user across the networks. To better balance
The LTE network is emulated by integrating USRP B210x with the load, we need an option to move selective flows of a given
the OpenLTE eNodeB and OpenLTE EPC. The WiFi network
is emulated using hostapd and dnsmasq daemons running on user, i.e. to enable flow mobility. Flow mobility provides the
Ubuntu 12.04. An off-the-shelf LG G2 mobile phone running user with the flexibility of choosing the most suitable network
Android 4.2.2 is used as the user equipment. We demonstrate for a given application. For example, consider a user on a
seamless mobility between the LTE network and the WiFi heavily loaded LTE network who is watching a video and also
network with the help of ICMP ping and a TCP chat application. downloading a file. Since video traffic is considered as flexible
real-time traffic due to buffering available at the user end, it
Index Terms—WiFi networks, LTE networks, Inter-RAT Flow can be offloaded on to WiFi network. The file download is
mobility, Software Defined Networking, OpenFlow, PMIPv6. served with a higher priority on the LTE network itself. The
movement of video traffic to the WiFi network frees up more
I. I NTRODUCTION resources on the LTE network for the HTTP data session. This
The trend in traffic generation pattern of mobile devices has level of freedom in choosing the flows to be moved across the
shifted from text-only data to audio/video data that require networks cannot be provided only by IP mobility. Thus, flow
high bandwidth. To deal with this, Internet Service Providers mobility becomes important in achieving a better distribution
(ISP) tend to offload some traffic onto other networks to of load on the networks along with providing better quality of
improve performance. IEEE 802.11 (WiFi), a cost effective experience to the users.
and widely deployed wireless technology, is the most popular There exist several protocol standards for providing IP
mobility, namely, Mobile IP (MIP) [3], Dual Stack Mobile
The authors are with the Department of Computer Science and Engineering, IP (DSMIPv6) [4] and Proxy Mobile IPv6 (PMIPv6) [5].
Indian Institute of Technology Madras, Chennai India and
India-UK Advanced Technology Centre of Excellence in Next Generation Proxy Mobile IPv6 is a Network-Based Localized Mobility
Networks, Systems and Services (IU-ATC) Management Solution (NetLMM) [6]. MIP and DSMIPv6 are
Email: prdhathri@gmail.com, skrishnam@iitm.ac.in, host-based protocols, where the user initiates the mobility and
krishna.sivalingam@gmail.com
Part of this paper was presented at IEEE WoWMoM 2015 conference in thereby requiring significant changes in the mobile node. In
Boston, MA, USA, held during June 2015. PMIPv6, all the mobility related implementations are done
 2

at the network and do not require many changes in the tion II presents the necessary background and related work on
mobile node. The 3GPP standard TS 23.261 v12.0.0 proposes mobility protocols. Section III presents the proposed Seamless
a DSMIPv6 based interface for IP flow mobility (IFOM) Internetwork Flow Mobility (SIFM) architecture. Section IV
and seamless Wireless Local Area Network (WLAN) offload presents the simulation based performance study of the pro-
[7]. The 3GPP standard TS 24.327 v12.0.0 describes General posed architecture and comparison to the existing PMIPv6
Packet Radio System (GPRS) and WLAN inter-networking architecture. Section V presents the details of the prototype
aspects [8]. The 3GPP TS standard 23.402 v13.1.0 proposes testbed implementation, and Section VI the testbed based
architecture enhancements for non-3GPP access [9]. The spec- experimental results. Section VII presents the conclusions.
ification defines interfaces to support network based mobility
using PMIPv6. Recently, IETF has proposed extensions for II. R ELATED W ORK
PMIPv6 to support flow mobility [10]. This section presents the related work on inter-network
In this paper, we propose a new mobility architecture named mobility protocols.
Seamless Internetwork Flow Mobility (SIFM), that overcomes
the drawbacks of existing architectures by utilizing the con-
cepts of PMIPv6 and Software Defined Networking (SDN) A. Network Architecture
[11]. The SDN architecture is based on decoupling the data The wireless network considered in this paper consists of
plane from the control plane. It introduces two components, two types of networks: cellular service provided by a 3G or 4G
namely the controller and the switch. The controller and the (LTE) network and access service provided a WiFi network.
switch communicate using the OpenFlow protocol [12]. When The LTE network consists of several LTE evolved NodeB
a switch receives a packet it has never seen before, it forwards (eNodeB or basestation) nodes that serve the network’s cells.
it to the controller. The controller takes the routing decision, The LTE network architecture consists of two major sub-
and instructs the switch on how to forward similar packets by systems: the Evolved UMTS Terrestrial Radio Access Network
adding entries in the switch’s flow table. (E-UTRAN) system and the Evolved Packet Core (EPC).
The proposed SIFM architecture exploits the advances in the The E-UTRAN forms the wireless part of the LTE network
field of SDNs to handle mobility related control signalling. and handles the radio communications between the User
We define a Flow Controller (FC) similar to an OpenFlow Equipment (UE) and the EPC. The Evolved Packet Core (EPC)
controller [12]. The FC only carries out the mobility related communicates with packet data networks in the outside world
functionality. The Packet Data Network Gateway (PGW) in such as the internet, private corporate networks or the IP
the LTE network and the Wireless Access Gateway (WAG) multimedia subsystem.
in the WiFi network act as Mobility Agents (MA). They The EPC consists of three components: (i) Mobility Man-
are OpenFlow-hybrid switches that carry out mobility related agement Entity (MME); (ii) Serving Gateway (SGW) and
signalling on behalf of the User Equipment (UE) [12]. They (iii) Packet Data Network Gateway (PGW). The MME is
follow the instructions of the FC when a mobile node moves mainly responsible for controlling the LTE access network.
from an LTE network to a WiFi network in order to provide It is responsible for the activation and de-activation of bearers
seamless transition. on behalf of a UE. It also performs tracking and paging
In the current work, the SIFM architecture and the basic procedures for UEs in idle mode and selects the UE’s Serving
PMIPv6 architecture have been implemented specifically for Gateway during the initial attach and handover. The Serving
studying data offloading between the LTE and the WiFi Gateway (S-GW) is responsible for forwarding the end-user’s
networks. These architectures can be used for traffic offloading data packets from the eNodeB to the Packet Data Network
between any two access technologies such as 2G and 3G gateway (P-GW). It serves as the local anchor point during
by implementing the functionalities required for seamless the inter-eNodeB handover.
mobility at the corresponding entities defined in the respective The Packet Data Network gateway (P-GW) provides con-
standards. For the SIFM architecture, the entities that perform nectivity to external PDNs for the UEs. It assigns IP addresses
the functionality of the MA must be OpenFlow compliant in to UEs and may also perform firewall functions such as deep
order to communicate with the FC. Performance studies show packet inspection and packet filtering on per-user basis. It also
that with the best possible (scenario dependent) offload value, performs service level gating control and rate enforcement
both SIFM and PMIPv6 architectures improve performance through rate policing and shaping. One UE can be connected
when offloading the data compared to the no offload scenario. more than one P-GW if it needs to access more than one PDN.
We also show that selective offloading helps in achieving better The WiFi network consists of IEEE 802.11 protocol based
performance gain by considering a simple scenario and using access points (APs). The APs operate using unlicensed spec-
static flow table rules. trum in the 2.4 Ghz and 5 Ghz bands. The WiFi network is
The proposed architecture has been implemented in an based on collision-based medium access and hence can suffer
experimental testbed consisting of two off-the-shelf LG mobile from collisions when the number of network users is large.
phones, a software defined radio based LTE base station, and a The advantage of the LTE network is its better coverage
WiFi access point. The testbed is used to test basic networking due to cell ranges that are of the order of a 1-3 Km. In
functionality between the mobile nodes and other nodes in the comparison, the WiFi network ranges are typically around
network. 200-300 m. On the other hand, the LTE network capacity per
The remainder of the paper is organized as follows. Sec- cell sector is of the order of 70 Mbps, with higher capacities
 3

supported by the LTE-Advanced standard. The WiFi network’s

aggregate capacity varies from few hundred Mbps to as high
as 1 Gbps based on standards including IEEE802.11ac and
IEEE 802.11n.
The current generation user equipment (UE) mobile phones
(mostly smartphones) have both 3G/4G cellular and WiFi
interfaces. When a UE that is connected to the cellular network
comes within the range of a WiFi network, then the UE’s
data sessions are transferred to WiFi, for two reasons: higher
bandwidth and lower (often, no) cost. Thus, there is a need for
seamless mobility protocol standards that can transfer a UE’s
ongoing and new connections from LTE to WiFi and back, as
necessary. This aspect is the focus of this paper.
The discussion above presents 3G/4G and WiFi networks.
However, this is applicable for any other combination of access
protocols that might be developed in the future.

B. Existing Mobility Support Protocols

The existing standards that define mobility support protocols Fig. 1: PMIPv6 architecture.
are presented next.
DSIMPv6: The 3GPP Release 8 [7] standard has proposed
an architecture for seamless mobility between 3G and WiFi Mobility Anchor (LMA) and the Mobile Access Gateway
networks based on the Dual-Stack Mobile IPv6 (DSMIPv6) (MAG). The MAG performs the mobility related signalling
standard [4]. The solution does not require any support from on behalf of the mobile nodes. The LMA keeps track of
WLAN accesses. The changes are required only at the UE and the users and issues the same IP address to the users when
the PGW. The Home Agent functionality as defined in [3] can they move across different networks. The LMA and the MAG
be implemented in the PGW or as a stand alone box. The communicate over the tunnel that is established between the
S2c interface is defined between the UE and the PGW for all two. Fig. 1 shows the PMIPv6 architecture.
the DSMIPv6 related communications. Cisco and Qualcomm The 3GPP Release 8 standard defines the S2a interface
have proposed architectures based on DSMIPv6 for mobility based on the PMIPv6 architecture between the PGW and the
between the 3GPP and the non-3GPP (WiFi) networks [1], Wireless Access Gateway (WAG) for mobility between the
[2]. This approach requires significant changes at the UE since 3GPP networks (e.g., LTE) and the non-3GPP networks (e.g.,
UE initiates the binding related communications, which is the WiFi) [9]. Cisco has proposed an architecture for mobility
major drawback of the approach. between the 3GPP and the non-3GPP networks based on
In UE-initiated procedures, the mobile nodes must signal PMIPv6 [1].
themselves to the network when their location changes and PMIPv6 solves the problem of user session mobility but
must update routing states in the Foreign Agent, in the local does not provide the flexibility to move selected flows of
Home Agent, or in both. This requires changes to the UE stack, a user. Various architectures adding flow mobility support
and also raises the problem of complex security configurations to PMIPv6 have been proposed in [13] and [14]. Recently,
to authenticate the signalling exchanges and modifications of IETF has proposed extensions to PMIPv6 to support flow
routing states. The signalling messages also increase the load mobility. In all these architectures, the decision about which
on the wireless radio interface. flow to move has to be done at the LMA which is generally
PMIPv6: The Internet Engineering Task Force (IETF) has implemented at PGW. The algorithms that determine optimal
defined a network-based local mobility management protocol, movement of flows are quite complex and running them at
where local IP mobility is handled without any involvement PGW significantly increases its complexity. The proposed
from the mobile node. As a part of the first phase of efforts in SIFM architecture, exploits the features of SDN by separating
this working group, Proxy Mobile IPv6 (PMIPv6), a network- the control plane and moving it to a centralized flow controller
based local mobility management protocol was developed [5]. for mobility related signalling. All the decisions regarding the
In network-based mobility, only the entities in the backbone movement of a flow is done at the Flow Controller instead
network participate in the mobility related signalling thus of PGW, there by reducing the complexity of the PGW. Flow
reducing the overhead on the wireless radio interface. The Controller has an overall global view of both the networks,
changes required at the UE are minimal and the network which is an added advantage to make flow mobility decisions
architectural changes at the backbone are independent of the at the Flow Controller.
UE changes unlike UE-initiated procedures in which network Mechanisms that can be implemented on mobile phones to
changes are tightly coupled with the UE and require changes seamlessly move flows between networks have also been stud-
at the UE side. ied extensively. Two such techniques named ‘wait-n-migrate’
PMIPv6 mainly defines two components to achieve and ‘resumption agent’ have been proposed in [15]. In ‘wait-
network-based local mobility management namely the Local n-migrate’, new flows are established on the new network, but
 4

preexisting flows remain on the old network until a specific

time-out value set by the policy. ‘Resumption agent’ resumes
a flow from the place it was disrupted, which is transparent
to applications. A client based solution that makes switching
decisions based on the policies set by the user on his device
is proposed in [16]. Qualcomm has proposed a connectivity
engine that dynamically determines the characteristics of an
unplanned WiFi network on the mobile device [17]. This
works together with Access Network Discovery and Selection
Function (ANDSF) and IFOM on the network side to provide
seamless flow mobility [18], [7]. All these are UE initiated
procedures and have drawbacks similar to DSMIPv6 based
protocols as discussed before.
A solution for IP flow mobility that can be integrated with
either DSMIPv6 or PMIPv6 is proposed in [19]. It introduces
a policy routing architecture that is used to signal routing Fig. 2: Proposed SIFM architecture for LTE and WiFi
rules between the UE and the network infrastructure. A unified networks.
protocol stack that includes all the original functions of both
LTE and WLAN systems is proposed in [20]. The solution
proposed in [20] consists of a Converged Base Station (CBS) concepts of Software Defined Networks (SDN). Since the
that integrates different Radio Access Technologies (RAT) at Flow Controller is centralized, it has the complete view of
the MAC layer. This solution is very complex and requires both LTE and WiFi networks. Hence, better algorithms can be
complete change to the existing infrastructure. The tight cou- developed to dynamically move the flows between LTE and
pling between the two RATs poses problems of scalability and WiFi networks based on the current network conditions, user’s
restricts independent development of different components in charging profile, priorities etc. The communication protocol
future. An SDN based RAN architecture that provides higher used for mobility control messages is also based on the
programmability and an easier vertical handover process is OpenFlow standard [12].
proposed in [21]. However, this poses scalability issues. To The problems related to scalability observed in SDN due
overcome these problems, we propose a new architecture to centralized controller could be solved by using redundant
called SIFM that takes the best of both PMIPv6 and SDN controllers or having a distributed controller environment [22].
based architectures. The SIFM architecture is easy to integrate since it does not
require major changes to the existing architecture, unlike
III. S EAMLESS I NTERNETWORK F LOW M OBILITY (SIFM) PMIPv6. This can serve as an intermediate step to move
cellular networks towards SDN based architectures.
This section presents the design, the components and the
1) Flow Controller: The FC is a new component defined in
working of the proposed Seamless Internetwork Flow Mobility
the SIFM architecture and has to be added to the current LTE
(SIFM) architecture.
EPC in order to facilitate flow mobility. The FC works similar
In this paper, we define a network flow as having five
to an OpenFlow controller but only performs the flow mobility
attributes: the source and the destination IP address, the source
related actions in this architecture [12]. The Flow Controller
and the destination port and the transport protocol used. A set
(FC) is responsible for assigning flows to the Mobile Agents
of packets with common attribute values within a given time
(MAs), defined in the next section. It is aware of all the MAs
period is considered as one flow. The definition of flows can
to which the UE is connected to and is active on. Based on the
be extended as needed.
information obtained from the MAs, the FC sets up the flow
rules and communicates the same to the MAs. When a UE
A. Architectural Design moves from one network to another, the FC instructs the MAs
Fig. 2 represents the SIFM architecture for LTE and WiFi involved to create a tunnel through which active connections
networks. The main components of SIFM are: (i) a Flow are transmitted to the UE without any disruption.
Controller (FC); (ii) one or more Mobility Agents (MA); and 2) Mobility Agents: The Mobility Agent (MA) is a router
(iii) multiple User Equipment (UE) nodes. In the example that provides Internet services to the UE and is responsible
shown, the EPC Packet Gateway (PGW) and the Wireless for detecting the movement of the UE between the access
Access Gateway (WAG) act as the MAs. They connect the technologies (e.g., LTE and WiFi). The MA’s functionality is
UE to the Internet and also communicate with the FC. Based similar to that of the MAG in PMIPv6 [5]. In the OpenFlow
on the flow instructions given by the FC, the mobile data flow context, it behaves similar to an OpenFlow-hybrid switch [12].
either takes the path along the LTE network or is offloaded Whenever a UE comes within a MA’s access network, the MA
through the tunnel between the PGW and the WAG to reach assigns an IP address to the UE and informs the FC about its
the UE through the WiFi network. binding. The MA gets the flow information from the FC and
In the SIFM architecture, we choose to implement the new forwards the data packets based on the obtained information.
functionality of mobility using a the centralized controller The MA can provide more information about the UE’s binding
 5

such as access technology, link bandwidth information, packet C. Message Formats

and port statistics to the FC. Based on these information,
the FC can run several algorithms to assign flows between Communication between the FC and the MAs uses mes-
the MAs. Only control messages are exchanged between the sages that comply with the OpenFlow Protocol. Two new
MAs and the FC. There is no actual data transfer between message types that follow the experimenter message type
the two. A messaging protocol, similar to OpenFlow, is used as specified in [12] are introduced. The Flow Modification
to communicate between the FC and the MAs. In the current Message and the Port Status update Message defined in
infrastructure, functionality of the MA is added at the PGW OpenFlow are used to meet the system requirements.
for the LTE and at the WAG for the WiFi network. 1) Binding Update: A Binding Update is sent from an MA
3) User Equipment: The UE is a user or a mobile node to the FC when the MA receives a connection request from the
(MN) that requests for the service. User, UE and MN mean UE. The Binding Update message contains MN-ID, MA-ID,
the same and are used interchangeably in this paper. Since MN-IP, MA-IP, PORT-ID and STATUS. MA-IP is the tunnel IP
the SIFM architecture supports flow mobility, the UE should of the MA which is used to communicate with the other MAs.
be able to receive packets destined to multiple IP addresses On receiving the Binding Update message, the FC updates its
at the same time. Also, the IP address cannot be bound to BC and sends a Binding Acknowledgement.
a network interface, in case of the flows which are being 2) Binding Acknowledgement: On receiving the Binding
moved from LTE to WiFi or vice-versa. To support this, Update, the FC sends a Binding Acknowledgement to the
either the UE should support a weak host model or have a MA to acknowledge the reception of the Binding Update. In
logical interface [23], [24]. The logical interface abstracts the addition to this, if the FC already has a BC entry for the UE,
underlying physical interfaces called the sub-interfaces and it sends the information about the IP of the UE corresponding
may be attached to multiple access technologies (e.g., LTE to the old MA, to the new MA. This is required by the new
and WiFi). Only the logical interface is exposed to the higher MA to map the flows corresponding to the old IP, to the new
layers at the UE and the physical interfaces are hidden. The IP.
Transmit/Receive functions of the logical interface are mapped
to the Transmit/Receive services exposed by the sub-interfaces. 3) Flow Modification Message: A Flow Modification Mes-
This mapping is dynamic and any change is not visible to the sage is sent from the FC to an MA to inform the MA about
upper layers of the IP stack. all the flow mobility related decisions taken by the FC. The
Flow Modification Message mainly contains information about
B. Data Structures the match fields which is used to match the incoming flow at
Two main data structures are defined to support SIFM, as the MA and the instructions which define the actions to be
described below: Binding Cache (BC) at the FC and Flow performed on the matched flows. In addition to this, it also
Table (FT) at the MA. contains auxiliary fields such as priority and time-out values.
1) Binding Cache (BC): The binding cache (BC) is main- On receiving the Flow Modification Message, the MA updates
tained at the FC and contains the information about all the its Flow Table.
UEs and the MAs to which they are attached to. Every BC 4) Port Status Update: The Port Status Update is sent from
entry contains: an MA to the FC to inform the FC about any change in the
• MN-ID: Identifies the Mobile Node uniquely. UE’s port status with respect to the MA. It contains MN-
• MA-ID: Identifies the Mobility Agent uniquely. ID, MA-ID, PORT-ID and STATUS. On receiving the Port
• MN-IP: IP Address of the Mobile Node within MA’s Status Update, the FC updates the status of the port as per the
network. received message in the appropriate BC entry.
• MA-IP: IP Address of the Mobility Agent. This is the
tunnel address which is used to communicate with other
MAs.
• PORT-ID: Physical/Logical port on which the packets
destined to the MN are forwarded at the MA.
• STATUS: Status of the UE in a MA’s network.
2) Flow Table (FT): The Flow Table (FT) is maintained
at the MAs and reflects the flow decisions taken by the FC.
Entries of the FT determine the path taken by the flow received
at the MA. Each FT entry contains:
• Match-fields: Fields of the packet header to match against
the incoming packets. It might be an ingress port,
source/destination IP etc.
• Priority: Matching precedence of the flow entry.
• Counters: Updated when the packets are matched.
• Instructions: Actions to be performed by the MA on the
Fig. 3: SIFM architecture operation details.
packets matched.
• Timeout: Idle time before a flow is expired by the switch.
 6

D. Protocol Operation IV. P ERFORMANCE S TUDY: S IMULATION M ODELING

Fig. 3 explains the working of the SIFM architecture with This section explains the simulation modeling, topology and
the LTE and the WiFi networks. The steps are detailed below. the network parameters used to evaluate the PMIPv6 and the
1) The UE connects to the LTE network. The PGW receives SIFM architectures for LTE and WiFi networks. Comparative
the connection request, assigns an IP to the UE, sets up analysis of the metrics for both the architectures are presented.
default bearers and sends the Binding Update to the FC. The PMIPv6 based architecture and the SIFM based ar-
The FC responds with a Binding Ack. chitecture for LTE-WiFi network mobility have been imple-
2) When the UE comes in the range of a WiFi network, mented in the ns-3 network simulator [26] (version 3.20).
the WAG receives a connection request from the UE. The ns-3 network simulator does not support IPv6 with LTE.
The WAG assigns a new IP to the UE and sends a To implement PMIPv6, we have extended the LTE module
binding update to the FC. Both the IP addresses are of the simulator (LENA) to support IPv6. PMIPv6 messages
now configured on the UE’s logical interface. i.e, proxy binding updates and acknowledgements are imple-
3) Since the FC already has an entry corresponding to the mented as per RFC 5213 [5]. LMA is implemented as a
UE, it makes a new entry for the WAG and sends a different node which is connected to PGW/SGW node and
Binding Ack to the WAG. The FC also sends Flow WAG by point-to-point links. Communication between the
Modification Messages to the PGW and the WAG based LMA and the access gateways happen via PMIPv6 tunnel that
on its decision. is established at the start of the simulation.
4) In case of dual network connectivity ( i.e., UE is in To implement the SIFM architecture for LTE and WiFi net-
the range of both LTE and WiFi networks), the FC works, we have added a new module to ns-3 simulator called
can run several algorithms based on the link bandwidth “openflow-hybrid”. This implements the functionalities of the
information, packet and port statistics, etc. and assign FC, OpenFlow-hybrid switch and the messaging between the
flows between the PGW and the WAG based on the FC and the MA. The PGW/SGW and the WAG are modified to
algorithm’s output. Algorithms should be aimed at bal- support the MA functionalities. To support the logical interface
ancing the load on both the networks and provide better at the UE, a new UeLogicalNetDevice class, that abstracts the
quality of experience to the user. LTE and the WiFi interfaces at the UE, is implemented.
5) In case of complete handover (i.e., UE moves out of
the LTE network range and connects to WiFi network),
the PGW informs the FC about the UE’s movement by
sending a Port Status Update message. The FC instructs
the PGW to move all the existing flows corresponding
to the UE over the tunnel. It also instructs the WAG
to decapsulate the packets received on the tunnel from
the PGW and forward it to the UE on the appropriate
port. The new connections from the UE are established
over the new network (i.e, WiFi in this case), there by
reducing the tunnelling overhead.

E. Discussion
In the PMIPv6-based Distributed Mobility Management Fig. 4: Network topology for PMIPv6 architecture.
(DMM) approach [25], the functions of LMA (both control
and data plane) are split across multiple MAGs and hence
distributed. The proposed solution combines the best of both
centralized and distributed approaches. The control and the A. Network Topology and Simulation Parameters
data plane are separated, and the LMA which hosts the The network topology for PMIPv6 architecture is as shown
control plane is still a centralized entity. However, the data in Fig. 4. Both the PGW and the WAG (MAGs) are connected
plane is distributed across the MAGs. At a higher level, even to LMA via a point-to-point link and communicate over the
though the concept is similar to the partial DMM approach, PMIPv6 tunnel. The LMA is connected to the Remote Host.
the proposed work defines and evaluates a more fine-grained The network topology for the SIFM architecture is as shown
architecture. in Fig. 5. In the SIFM architecture, both the PGW and the
This paper has considered a domain to be within that of a WAG are directly connected to the Internet. The PGW and
region served by a given PGW. when a mobile node moves the WAG (MAs) are connected to the FC via a point-to-point
from one PGW to another, it is considered to be moved to a link and a TCP connection is established between the FC and
different domain: this case is NOT handled in this paper. And the MAs for all mobility related communications. A simple IP-
even though PGW covers wide-areas, the controller can be in-IP tunnel is established between the PGW and the WAG to
made scalable by using replicated controllers with consistency offload the traffic. In all the simulation experiments, we create
mechanisms. Any solution to SDN controller scalability can the tunnel pro-actively at the start of the simulation. This can
be used in our framework. also be dynamically created (re-active approach) when there
 7

is a need to offload. But this approach is not considered since TABLE I: Simulation Parameters
it might increase the overhead of the handover process. Parameter Value
Bandwidth of Link 1 Gbps
Connecting to Internet
LTE Downlink Capacity 100 Mbps
LTE Uplink Capacity 50 Mbps
Scheduler Used at LTE Proportional Fair
WiFi Network Capacity 54 Mbps (802.11 a)
No. of users varied from 10 to 50
Offload value varied from 0% to 75%
of WiFi Bandwidth
Traffic at each UE One UDP app, 1 Mbps (CBR & VBR);
One TCP app, 1 Mbps (CBR & VBR)

B. Performance Evaluation Results

This section presents a comparative analysis of delay and
throughput for the SIFM architecture and the PMIPv6 archi-
tecture considering different offload values. The packet loss
Fig. 5: Network topology for SIFM architecture.
values are not reported due to space constraints. The offload
value indicates the percentage of maximum feasible WiFi
The network parameters used for the simulation are sum- bandwidth. For a 54 Mbps link, this is taken to be ≈ 22
marized in Table I. The effective capacity of LTE downlink is Mbps, to account for various inter-frame spacing overhead.
≈ 71 Mbps, uplink is ≈ 40 Mbps and that of WiFi network This has been obtained using simulations with a single user
is ≈ 22 Mbps due to signalling overhead. The effective in the WiFi network, and is taken as an upper limit of the
WiFi Bandwidth is actually the total available bandwidth feasible WiFi bandwidth. The experiments are repeated for
with 802.11a. Even though the theoretical maximum bitrate both Constant Bit-Rate (CBR) and Variable Bit-Rate (VBR)
is 54Mbps, in reality only 22Mbps is achieved, due to effects traffic. The packet arrival for VBR traffic follow a Poisson
of inter-frame spacing gaps in the MAC protocol. This has distribution with a mean rate of 1 Mbps and the results are
been verified using the simulations. This does not change presented with 95% Confidence Interval. The graphs presented
with the number of users. As the number of users increase, shows the results for VBR traffic only. The CBR traffic also
the bandwidth per user decreases; however, the available shows similar behaviour.
bandwidth (capacity) is still the same. Delay: Fig. 6(a) presents the average delay experienced by
Multiple UEs are connected to either the LTE or the WiFi a UE for different offload values for both the architectures.
Network. We consider a single eNB to which all the UEs are This includes the average delay of both TCP and UDP flows.
connected. Both TCP and UDP traffic are running between It can be seen that up to 30 users, LTE successfully handles
every UE and the remote host. The details of the traffic are the load and the average delay is less than 300ms since the
as given in Table I. Some of the UEs are static and others total capacity of the LTE eNB is approx. 71 Mbps and the total
are mobile as determined by the offload value specified in the downlink traffic is 60 Mbps for 30 users. When the number of
simulation. The offload value indicates the percentage usage UEs is further increased, the LTE network experiences conges-
of the available WiFi bandwidth (≈ 22 Mbps). The arrow in tion and hence the delay increases for the no-offload scenario.
Fig. 4 and Fig. 5 indicates the direction of movement of the For 40 and 50 users, offloading the data to WiFi network
UEs. Initially, all the UEs are in the range of the LTE Network. decreases the average delay. The degree of improvement is
The UEs that are mobile will move towards the WiFi network less for 50 users since the traffic on the network (approx. 100
and their flows are offloaded when they get connected to the Mbps) is more than the combined bandwidth available from
WiFi network. The speed of the UE is 1 metre/s (1.8 Kmph). both LTE and WiFi networks (approx. 93 Mbps). However,
A lower speed is considered since WiFi offloading helps only when the load on the LTE network is less, higher offload
when users are less mobile. In other words, UEs are expected value increases the delay. For example., in 10 users and 75%
to be connected to WiFi for a sufficient period of time such offload scenario, the delay is higher compared to the no-
as at home, at coffee shops, or in the office. When a user is offload scenario. This increase is because of higher load (75%
constantly moving at a high speed, offloading induces a ping- of the available bandwidth) in the WiFi network despite the
pong effect since the user will have to shift between LTE bandwidth being available on the LTE network.
and WiFi networks frequently. The algorithms at the flow-
controller are responsible to detect this and not offload sessions TABLE II: Impact of RLC Buffer Size on Delay
for such users. Since, this work does not concern algorithms RLC buffer size Avg. delay (ms)
at the flow-controller, we study only low-mobility (or almost 10 KB 13,063.30
100 KB 9,917.26
stationery) scenarios. The delay, the throughput and the packet 2 MB 8,880.96
loss values are calculated for different offload percentages by 10 MB 7,639.10
varying the number of UEs. However, for low to moderate
speeds, offloading can be applicable. Table II presents the variation of average delay for different
 8

Average Delay Average Handover Delay

600

Average Handover Delay (ms)

500
1000
Average Delay (ms)

400

100 300

200
10
100

1 0
10 20 30 40 50 5 10 15 20 25
Number of UEs Number of flows offloaded
SIFM PMIPv6
No offload - SIFM 50% offload - SIFM
No offload - PMIPv6 50% offload - PMIPv6
25% offload - SIFM 75% offload - SIFM
25% offload - PMIPv6 75% offload - PMIPv6 Fig. 7: Handover delay comparison for SIFM and PMIPv6.
(a) Delay

Average throughput per application network. PMIPv6 has a slightly higher handover delay. This
1
is due to the fact that when a UE moves to a different MAG,
Average Throughput (Mbps)

0.9 the IP address configuration takes time since the MAG has to
consult the LMA before sending the Router Advertisement.
0.8
UE-level performance: Fig. 8 present the average delay and
0.7 throughput at any time instant for an arbitrarily selected user
0.6
plotted against the simulation time. These graphs are plotted
for an arbitrarily selected UE in the 40-user, 50%-offload
0.5
10 20 30 40 50 scenario and show how offloading benefits this user.
Number of UEs
Fig. 8(a) presents the average per packet delay at any instant
No offload - SIFM 50% offload - SIFM
No offload - PMIPv6
25% offload - SIFM
50% offload - PMIPv6
75% offload - SIFM
‘t’ of TCP and UDP applications for an arbitrarily selected
25% offload - PMIPv6 75% offload - PMIPv6
LTE user and a user whose flows are offloaded to WiFi. We
(b) Throughput can see that the delay values go down for both the users when
Fig. 6: Comparison of SIFM and PMIPv6 architectures. the offloading is done around 1s. Around 14.8s, the offloaded
users come back to LTE network from WiFi network. Hence
the delay increases again.
Radio Link Control layer (RLC) buffer sizes for 50 users in the
LTE network. When the buffer size is small and the network LTE User-TCP
Offloaded User-TCP
LTE to WiFi LTE User-UDP
is loaded, the packets are dropped at the RLC layer, which Offloaded User-UDP
WiFi to LTE
1000
triggers re-transmissions of TCP packets and thus increases
the delay. However, when the buffer size is large, TCP does
Delay (ms)

not see any loss of packets, thus re-transmissions are reduced

and hence the delay is reduced. However, in order to reduce 100

fragmentation at the lower layers, RLC buffer is kept small.

This adversely affects the performance of TCP applications
when the network is highly loaded. One other thing to note 10
0 5 10 15 20 25
in this experiment is that, for each of the RLC buffer size, Time (s)

TCP buffer size is kept constant and the change in the delay (a) Instantaneous delay
is only due to RLC retransmissions and hence the delay keeps 1.2
decreasing with increase in buffer size. LTE to WiFi
LTE User-TCP
Offloaded User-TCP
LTE User-UDP
Offloaded User-UDP
Throughput: Fig. 6(b) presents the average per applica- 1
Throughput/application (Mbps)

tion throughput experienced by a UE for different offload 0.8

values for both the architectures. It can be seen that the

0.6 WiFi to LTE
throughput is almost equal to the requested bandwidth (i.e,
1 Mbps/application) up to 30 users. Further increase in the 0.4

number of users decreases the throughput drastically for the 0.2

no-offload scenario. Offloading the traffic for higher number
of users (40 and 50 users), i.e. when the LTE network is 0
0 5 10 15 20 25
Time (s)
congested, increases the average throughput. In addition, for
(b) Throughput
a high load scenario, increase in the offload value increases
the throughput since more of the available WiFi bandwidth is Fig. 8: Performance of an arbitrarily selected UE.
being used.
Handover delay: Fig. 7 presents the average handover delay Fig. 8(b) presents the average throughput of TCP and UDP
for a flow that is moved between the LTE and the WiFi applications at any time instant ‘t’ for an arbitrarily selected
 9

LTE user and a user whose flows are offloaded to WiFi. We can offload scenario for the SIFM architecture. The results are
see that the throughput for both the applications are higher for shown in Fig. 9 and Fig. 10.
the user who is offloaded to WiFi compared to the throughput Fig. 9(a) shows that the reduction in the average delay for
of the user who stays in LTE network. This is because the TCP applications is higher in the selective offload scenario
offloaded user gets more bandwidth in the WiFi network compared to full mobility in PMIPv6. This is demonstrated
when compared to the loaded LTE network. The throughput clearly in the graph for 40 and 50 users. Fig. 9(b) presents a
decreases again when the offloaded user moves back to LTE similar result for UDP applications. Fig. 10(a) and Fig. 10(b)
network around 14.8 seconds. show that the applications experience a better throughput in
Flow Mobility: The main advantage of the SIFM architec- selective offload scenario compared to full mobility scenario.
ture over the PMIPv6 architecture is flow mobility support.
Flow mobility is useful when the user is connected to both Average Throughput for TCP applications
1
the networks at the same time. To demonstrate the advantages

Average TCP Throughput (Mbps)

0.9
of flow mobility, we consider the same topology as in Fig. 4
0.8
and Fig. 5 but static UEs. All the UEs are connected to both
LTE and WiFi networks at the same time. We consider 3 kinds 0.7

of offloads: 0.6

0.5
• Full Mobility: All the flows of a user is moved.
0.4
• TCP offload: Only TCP flows of a user is moved.
• UDP offload: Only UDP flows of a user is moved. 0.3
10 20 30 40 50
Number of UEs
No offload - SIFM 50% TCP offload - SIFM
No offload - PMIPv6 50% UDP offload - SIFM
Average Delay for TCP applications 50% offload - PMIPv6

10000 (a) TCP Throughput

Average TCP Delay (ms)

1000 Average Throughput for UDP applications

1
Average UDP Throughput (Mbps)

100
0.9

10 0.8

1 0.7
10 20 30 40 50
Number of UEs
0.6
No offload - SIFM 50% TCP offload - SIFM
No offload - PMIPv6 50% UDP offload - SIFM
50% offload - PMIPv6 0.5
10 20 30 40 50
(a) TCP delay Number of UEs
No offload - SIFM 50% TCP offload - SIFM
No offload - PMIPv6 50% UDP offload - SIFM
Average Delay for UDP applications 50% offload - PMIPv6
50
(b) UDP Throughput
45
Average UDP Delay (ms)

40
Fig. 10: Throughput comparison: with and without flow
35
30
mobility
25
20
15 Complete Offload Selective Offload
10 TCP delay 7.02% 22.72%
5 UDP delay 16.32% 21.39%
10 20 30 40 50
TCP packet loss 15.79% 19.17%
Number of UEs UDP packet loss 11.76% 20.56%
No offload - SIFM 50% TCP offload - SIFM TCP throughput 2.64% 3.16%
No offload - PMIPv6 50% UDP offload - SIFM UDP throughput 0.24% 0.28%
50% offload - PMIPv6

(b) UDP delay TABLE III: Average performance improvement of SIFM

Fig. 9: Delay comparison: with and without flow mobility. over PMIPv6 architecture

The results are presented only for 50% offload scenario due Table III presents the average performance improvement of
to space constraints. In case of PMIPv6, there is no selective the SIFM architecture compared to PMIPv6 architecture (aver-
offload. Hence equal number of TCP and UDP flows which age over all the scenarios mentioned before is considered). The
together amounts to 50% of the WiFi bandwidth are offloaded. experimental results show that flow mobility provides more
For TCP offload, only TCP flows equivalent to 50% of the flexibility in offloading the traffic and in turn achieves better
WiFi bandwidth are offloaded and for UDP offload, only UDP performance gain. For example, flows can be given priorities
flows equivalent to 50% of WiFi bandwidth are offloaded. and offloaded based on the priorities. In the experiments
Full mobility scenario for PMIPv6 is compared with selective conducted, if UDP flows are assigned high priority, then the
 10

results show that retaining the TCP flows and offloading only [27]. OpenLTE includes the implementation of LTE eNB with
UDP flows to WiFi will improve the overall performance a built-in LTE EPC. It also includes tools for scanning and
of the UDP traffic compared to the full mobility scenario. recording LTE signals based on GNU radio [28]. GNU radio
Similarly, if TCP traffic is given high priority, then offloading is a software framework that can be used with external RF
only the TCP traffic will improve the performance of the TCP hardware to create software-defined radios (SDR). OpenLTE
applications. Using algorithms for dynamic flow modification currently supports ETTUS radios (USRP B200x and USRP
based on user and flow priorities and the current network state, B210x) for the external RF hardware [29]. USRP Hardware
additional performance gain can be achieved. Driver (UHD) along with GNU radio acts as an interface
Only control packets flow between the FC and the MA in between the OpenLTE eNB and the USRP hardware and
the SIFM architecture. The FC is no more a single point of communicates the RF signals between the two. OpenLTE
failure because it is only logically centralized and only the requires huge amount of processing power and a very low
mobility related functionality is affected when the FC fails. latency since it transmits and receives a radio frame every 1
Since the data and the control plane is separated, failure of ms. Any delay in processing results in loss of radio signals.
the FC does not have any impact on the functionalities of LTE Hence, it is recommended to run OpenLTE on a machine that
and WiFi as stand alone networks. Only the existing flows pass has high processing capabilities and also to turn off any system
through the tunnel between the MAs, and the new connections processes that can cause delay due to context switching time.
are established over the network to which the UE is currently We have extended the existing OpenLTE PGW functionality
attached to. Thus, the load on the tunnel is reduced. to support seamless data offloading. A new TCP socket was
created to send and receive messages to and from the FC.
V. T ESTBED I MPLEMENTATION The Flow Table was implemented at the PGW that defines
This section explains the set-up and implementation of the the routing for the packets received. The Flow Table rules are
proof-of-concept prototype of the SIFM architecture. updated by the Flow Modification messages that are sent by
the FC. The uplink path is unaffected by the changes. For the
downlink packets, the PGW first checks its Flow Table for a
A. Testbed Set-up
match. If there is no match, then the packets are forwarded
Fig. 11 shows the topology of the experimental testbed to the UE via OpenLTE eNB and the USRP radio. If there
being implemented. The PGW, the WAG and the FC are is a match, appropriate action is taken, which in the case of
implemented on Linux systems that are connected to each offload is to send the packet to UE via the WAG. The offloaded
other over the LAN (at DON Lab, IITM). USRP b210x board packets are sent to the WAG over a pre-established IP-in-IP
is connected to the system running as PGW, which provides tunnel between the PGW node and the WAG node.
the radio interface for the LTE network. WAG is implemented
on a Linux system with WLAN interface support. Remote
C. WiFi Network
Host is also a Linux system connected to the LAN (at DON
Lab, IITM). The WiFi network is emulated by creating a WiFi hotspot on
a laptop running Ubuntu 12.04. A Linux box with at least one
WiFi interface and one Ethernet interface can be turned into a
Controller Remote Host
Wireless Access Gateway (WAG) with the help of hostapd and
dnsmasq. Hostapd is a user-space program that implements
access point functions and authentication servers [30]. The
LAN
dnsmasq software implements the DNS forwarder and DHCP
server [31].
OpenLTE based To support seamless data offloading, a new “wificlient”
PGW
interface is implemented that communicates with hostapd and
WAG on Linux
USB 3.0
(hostapd; dnsmasq) the FC. The wificlient connects to the control interface of
USRP
B210x hostapd and listens to the events that are sent by the hostapd. It
also implements a TCP socket that is used to send and receive
messages from the FC. The wificlient interface captures the
events such as the connection and the disconnection of the
LG G2 Mobile connects UE to the WiFi network via hostapd control interface and
to OpenLTE eNB via USRP informs the FC about the events by sending Binding Update
or WAG
and Port Status Update messages. It also takes care of routing
the incoming packets based on the Flow Table rules that is
Fig. 11: Testbed Topology. updated by the FC via Flow Modification Messages.

D. Flow Controller
B. LTE Network The Flow Controller (FC) was implemented as an user-
The LTE network is emulated using an open-source imple- space application that can run on any Linux system. The FC
mentation of the 3GPP LTE specifications known as OpenLTE communicates with the OpenLTE PGW and the WAG over
 11

a TCP server socket that can handle multiple clients. On eNodeB and the successful attach of the user to the created
receiving Binding Updates and Port Status Updates from the OpenLTE network. Fig. 13 presents the screen shots of the
OpenLTE PGW and the WAG, the FC updates its Binding connected mobile device. At the right top corner of the UE
Cache entry and replies with a Binding Ack and a Flow screen we can see the icon 4g, denoting the LTE connection.
Modification message whenever necessary. In the present The figure also shows successful ping to a remote machine on
implementation, to show the seamless transition, we move the LAN over the established LTE connection.
the flow over WiFi network whenever a UE comes in contact We demonstrate the seamless mobility feature of the SIFM
with the WiFi network. The FC software can be extended to architecture with the help of a TCP chat application. TCP
implement algorithms to determine when and what flows could server runs on a remote machine in the LAN. Fig. 14(a) shows
be moved. that the UE is connected as a TCP client to the remote TCP
server over the established LTE connection. Fig. 14(b) presents
E. User Equipment the messages that are exchanged between the TCP server and
the client over the LTE connection. The red circle at the right
An off-the-shelf commercial LG G2 mobile phone run- top corner of the UE screen shows that only LTE is active at
ning Android 4.2.2 is used as the User Equipment (UE). this time.
The OpenLTE’s Home Subscriber Station (HSS) database
After a while, the WiFi AP is turned on, and the UE
is updated with the mobile’s dummy International Mobile
connects to this network too. The red circle at the right top
Subscriber Identity (IMSI) so that authentication is success-
corner of the UE screen in Fig. 14(c) shows that both LTE and
ful and the UE successfully connects to the LTE network.
WiFi are active at this time. As discussed in Section V-E, we
In order to support seamless mobility, both LTE and WiFi
can currently show only the movement of downlink traffic due
interfaces should be active and capable of receiving packets
to the limitations of Android. We require the uplink packets
simultaneously. Android by default allows only one active
to still go via LTE network in order to keep both the LTE
interface at a time. To support multiple active interfaces,
and WiFi interfaces active. The figure presents the messages
routing functionalities of Android should be modified or a
exchanged between the TCP client and the TCP server over
logical interface should be implemented both of which requires
the WiFi network.
a lot of changes in the Android source code. As a work around,
Fig. 15 presents the packet traces captured at the PGW
we have developed an application that exploits the weak host
and the WAG nodes. This helps establish that the downlink
model supported by Android and use the High Priority (HIPRI)
traffic to the UE is sent over the WiFi network. We can
feature. This allows only certain connections to go over the
see both uplink and downlink packets in the packet trace
cellular network even when WiFi is on, thereby keeping both
at the PGW (Fig. 15(a)), where as the packet trace at the
the cellular interface and the WiFi interface active at the same
WAG (Fig. 15(b)) shows only the downlink packets. Downlink
time. HIPRI basically lets the programmer have data as high-
packets are exchanged between the PGW and the WAG over
priority even when WiFi is available.
the IP-in-IP tunnel created between the two. The UE receives
the downlink packets over the WiFi interface.
VI. T ESTBED E VALUATION
This section presents the results of the experiments con-
ducted on the proof-of-concept testbed. We demonstrate that B. Two UEs communicating with each other
a TCP connection can be moved seamlessly from the imple-
mented LTE network to the WiFi network. The aim of the This section presents the results of the experiment in which
prototype was to demonstrate basic functionality and feasibil- two UEs communicate with each other, after successfully
ity. Getting the system integration done was quite technically attaching to the created OpenLTE network. Fig. 16(a) shows
challenging and time-consuming, when compared to running the 4G connection on both the UEs and the successful ping
simulation based experiments. Since the OpenLTE package between the connected UEs over the OpenLTE network. One
is not very robust enough, we could not conduct detailed of the UE runs a TCP client and the other runs a TCP server.
performance runs on the testbed at this point and is left for The TCP server IP address is 192.168.1.4 and the client
future work. IP address is 192.168.1.3. Fig. 16(b) shows the connection
between the TCP client and the TCP server. It also presents
the messages exchanged between them. The 4G connection
A. Single UE communicating with a server on the network at the right top corner of the screen shot validates that the
This section presents the results of the experiment in which connection is over the LTE network.
a UE communicates with the remote TCP server connected to After a while, only the client is moved to WiFi network. In
the LAN. Fig. 12(a) shows the OpenLTE eNB running on the the Fig. 16(c), it should be noted that only the client UE is
Linux machine. OpenLTE loads the required firmware on the connected to WiFi and the server remains in the LTE network.
USRP B210x board and tunes it to the required frequency to It can also be observed that the established TCP connection
listen to LTE signals. Before starting the OpenLTE eNB, the is intact even after the client is moved to WiFi network. The
parameters should be set for the radio. The user information messages from the TCP server are offloaded successfully from
is added to the Home Subscriber Station (HSS) of OpenLTE LTE network to the WiFi network over the IP-in-IP tunnel
for authentication. Fig. 12(b) shows the configuration of the created between the PGW and the WAG.
 12

(a) OpenLTE eNB running

(b) UE connected to LTE network

Fig. 12: Screen shots of eNodeB and UE, showing connection establishment messages.

Level Agreement (SLA) between the two operators in order

to move the flows between the LTE and the WiFi networks.
With the increase in the use of mobile users, we believe that
the LTE service providers like AT&T who also have their own
WiFi infrastructure can deploy more and more WiFi access
points for data offloading. There can also be an agreement
between the existing LTE service providers and the WiFi
service providers in which the WiFi providers allow the LTE
traffic to be offloaded with the appropriate charging policies.
Since all the offloaded traffic go via the PGW, Policy and
Charging Functionality (PCRF) at the LTE core network can
handle the charging policies. Authentication between the two
networks is an important aspect in data offloading which is
a problem on its own and is not discussed in this paper. The
3GPP standard TS 24.234 v12.2.0 proposes EAP SIM and
EAP AKA based authentication mechanisms that can be used
for authentication [32]. The scalability and reliability problem
Fig. 13: Mobile connected to the created test network. of the Flow Controller has not been dealt in this paper. There
have been several research that is going on to build a scalable
and reliable SDN controller. Any such solution can be used to
C. Discussion have a reliable and scalable Flow Controller (FC).
In this paper, the solution to data offloading is looked from
a network perspective rather than user perspective. However, VII. C ONCLUSIONS
the decisions about which flows to move, can still consider
user preferences. It is assumed that both LTE and the WiFi In this paper, we present a new architecture called Seamless
services are provided by a single operator or there is a Service Internetwork Flow Mobility (SIFM) for the network based
 13

(a) TCP connection between UE and Remote host

(b) Messages sent over LTE network

(c) Messages sent over WiFi network after offload

Fig. 14: Flow Mobility between LTE and WiFi.

 14

(a) Packet trace at PGW

(b) Packet trace at WAG

Fig. 15: Traces captured during WiFi traffic flow.

flow mobility and seamless data offload. The SIFM archi- [3] D. Johnson, C. Perkins, and J. Arkko, “RFC 3775: Mobility Support in
tecture and the PMIPv6 architecture have been implemented IPv6,” Jun. 2004.
[4] H. Soliman, “RFC 5555: Mobile IPv6 Support for Dual Stack Hosts and
in the ns-3 simulator and evaluated for data offloading be- Routers,” Jun. 2009.
tween the LTE and the WiFi networks. The evaluation results [5] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B. Patil,
show that the delay, the throughput and the packet loss “RFC 5213: Proxy Mobile IPv6,” Aug. 2008.
[6] J. Kempf, “RFC 4830: Problem Statement for Network-Based Localized
values are improved (on an average) by 16.86%, 1.58% and Mobility Management (NETLMM),” Apr. 2011.
16.82% respectively for the SIFM architecture compared to the [7] “3GPP TS 23.261 : IP flow mobility and seamless Wireless Local Area
PMIPv6 architecture. It is shown that the flow mobility support Network (WLAN) offload, (Rel. 10),” http://www.3gpp.org/DynaReport/
23261.htm, Dec. 2015.
provides the flexibility to move selective flows which helps [8] “3GPP TS 24.327 : Mobility between 3GPP Wireless Local Area
in achieving better performance gain compared to moving Network (WLAN) interworking (I-WLAN) and 3GPP systems; General
all the flows of the user. A proof-of-concept prototype of Packet Radio System (GPRS) and 3GPP I-WLAN aspects, (Rel. 10),”
http://www.3gpp.org/DynaReport/24327.htm, Dec. 2015.
the SIFM architecture is implemented on an experimental
[9] “3GPP TS 23.402 : Architecture enhancements for non-3GPP accesses,
testbed. We demonstrate the seamless movement of a TCP (Rel. 10),” http://www.3gpp.org/DynaReport/23402.htm, Dec. 2015.
flow between the implemented LTE and WiFi networks to [10] C. Bernardos, “RFC 7864: Proxy Mobile IPv6 Extensions to Support
support the working of the SIFM architecture. In future work, Flow Mobility,” May 2016.
[11] W. Stallings, Foundations of Modern Networking: SDN, NFV, QoE, IoT,
mechanisms for determining when to switch from LTE to WiFi and Cloud. Addison Wesley, 2015.
and dynamically modifying the flow table rules based on the [12] “OpenFlow Specification,” https://www.opennetworking.org/
flow priority and current network state can be studied. images/stories/downloads/sdn-resources/onf-specifications/openflow/
openflow-spec-v1.4.0.pdf, Dec. 2015.
[13] H.-Y. Choi, S.-G. Min, and Y.-H. Han, “PMIPv6-based Flow Mobility
R EFERENCES Simulation in NS-3,” in 5th International Conference on Innovative
Mobile and Internet Services in Ubiquitous Computing (IMIS), Jun.
[1] “Architecture for Mobile Data Offload over Wi-Fi Access Networks,” 2011, pp. 475–480.
http://www.cisco.com/c/en/us/solutions/collateral/service-provider/ [14] T. M. Trung, Y.-H. Han, H.-Y. Choi, and H. Y. Geun, “A design of
service-provider-wi-fi/white_paper_c11-701018.html, Dec. 2015. network-based flow mobility based on Proxy Mobile IPv6,” in 3rd IEEE
[2] “3G LTE Wifi Offload Framework,” http://www.qualcomm.com/media/ International Workshop on Mobility Management in the Networks of the
documents/3g-lte-wifi-offload-framework, Dec. 2015. Future World, Apr. 2011, pp. 373–378.
 15

[15] A. Rahmati, C. Shepard, C. Tossell, L. Zhong, P. Kortum, A. Nicoara,

and J. Singh, “Seamless TCP Migration on Smartphones without Net-
work Support,” IEEE Transactions on Mobile Computing, vol. 13, no. 3,
pp. 678–692, Mar. 2014.
[16] S. Nirjon, A. Nicoara, C.-H. Hsu, J. Singh, and J. Stankovic, “MultiNets:
Policy Oriented Real-Time Switching of Wireless Interfaces on Mobile
Devices,” in 18th IEEE Symposium on Real-Time and Embedded Tech-
nology and Applications (RTAS), Apr. 2012, pp. 251–260.
[17] “A 3G/LTE Wi-Fi Offload Framework: Connectivity Engine (CnE)
to Manage Inter-System Radio Connections and Applications,” https:
//www.qualcomm.com/documents/3g-lte-wifi-offload-framework, Dec.
2015.
[18] “3GPP TS 24.312 : Access Network Discovery and Selection Function
(ANDSF) Management Object (MO), (Rel. 10),” http://www.3gpp.org/
DynaReport/24312.htm, Dec. 2015.
[19] P. Loureiro, M. Liebsch, and S. Schmid, “Policy routing architecture for
IP flow mobility in 3GPP’s Evolved Packet Core,” in IEEE GLOBECOM
Workshops, Dec. 2010, pp. 2000–2005.
[20] Q. Cui, Y. Shi, X. Tao, P. Zhang, R. Liu, N. Chen, J. Hamalainen, and
A. Dowhuszko, “A unified protocol stack solution for LTE and WLAN
in future mobile converged networks,” IEEE Wireless Communications,
vol. 21, no. 6, pp. 24–33, Dec. 2014.
[21] M. Yang, Y. Li, D. Jin, L. Su, S. Ma, and L. Zeng, “OpenRAN: a
software-defined ran architecture via virtualization,” in Proceedings of
the ACM SIGCOMM, Aug. 2013, pp. 549–550.
[22] S. H. Yeganeh, A. Tootoonchian, and Y. Ganjali, “On scalability of
(a) Ping between 2 UEs
software-defined networking,” IEEE Communications Magazine, vol. 51,
no. 2, pp. 136–141, February 2013.
[23] “Host Model,” http://en.wikipedia.org/wiki/Host_model, Dec. 2015.
[24] T. Melia and S. Gundavelli, “Logical Interface Sup-
port for multi-mode IP Hosts,” http://tools.ietf.org/html/
draft-ietf-netext-logical-interface-support-09, Dec. 2015.
[25] J. Lee, “Dmm wg draft: Pmipv6-based distributed mobility manage-
ment,” https://tools.ietf.org/html/draft-jaehwoon-dmm-pmipv6-01, Jun.
2013.
[26] “NS-3,” http://www.nsnam.org/documentation/, Dec. 2015.
[27] “OpenLTE,” http://openlte.sourceforge.net, Dec. 2015.
[28] “GNU radio,” https://en.wikipedia.org/wiki/GNU_Radio, Dec. 2015.
[29] “ETTUS SDR,” http://www.ettus.com/product/category/
USRP-Bus-Series, Dec. 2015.
[30] “hostapd,” https://wireless.wiki.kernel.org/en/users/documentation/
hostapd, Dec. 2015.
[31] “dnsmasq,” http://www.thekelleys.org.uk/dnsmasq/doc.html, Dec. 2015.
[32] “3GPP TS 24.234 : 3GPP system to Wireless Local Area Network
(WLAN) interworking; WLAN User Equipment (WLAN UE) to net-
work protocols, (Rel. 10),” http://www.3gpp.org/DynaReport/24234.htm,
(b) TCP session between 2 UEs Dec. 2015.

(c) Seamless offload of TCP client to WiFi network

Fig. 16: Experiments with two UE mobiles.