# SDN-Based Mobile Data Offloading Scheme Using a Femtocell and WiFi Networks

Authors: Chang-Woo Ahn; Sang-Hwa Chung
Journal: Mobile Information Systems
 (2017)

---

## Abstract

Because of the many applications running on smartphones, the load of mobile data traffic on cellular networks is increasing rapidly. A femtocell is a solution to increase the cellular network capacity and coverage. However, because it uses the same frequency bands as a macrocell, interference problems have prevented its widespread adoption. In this paper, we propose a scheme for traffic offloading between femtocells and WiFi networks utilizing software-defined networking (SDN) technology. In the proposed offloading scheme, the SDN technology allows a terminal to maintain existing sessions after offloading through a centralized control of the SDN-based equipment. We also propose an offloading target selection scheme based on available bandwidth estimation and an association control mechanism to reduce the femtocell load while ensuring quality of service (QoS) in terms of throughput. Experimental results on an actual testbed showed that the proposed offloading scheme provides seamless connectivity and reduces the femtocell load by up to 46% with the aid of the proposed target selection scheme, while ensuring QoS after offloading. We also observed that the proposed target selection scheme offloads 28% more traffic to WiFi networks compared to received signal strength indicator-based target selection in a low background traffic environment.


---

## Body

## 1. Introduction

Recently, mobile data explosion caused by the emergence of a variety of applications and the penetration rate upsurge of smartphones has been increasing the traffic load on cellular networks. These mobile data growth trends are expected to exceed the capacity of cellular networks despite the evolution of the technology from 3G to LTE. To offload data traffic from overloaded cellular networks, cellular operators have deployed a large number of WiFi hotspots and provide WiFi access to their subscribers. Femtocells are also being implemented as a solution to offload the cellular network traffic [1].Mobile data offloading schemes through heterogeneous networks (HetNets) such as WiFi and WiMax can increase the capacity of a cellular network. However, with these offloading schemes, it is difficult to provide seamless connectivity between the macrocell and the HetNets. Despite this disadvantage, many studies have been conducted on offloading cellular network traffic using WiFi, which uses ISM bands, to increase the capacity of the cellular network [2–10]. The majority of these studies proposed offloading schemes based on delay transmission. Rather than transmitting data immediately using a cellular network, these schemes wait for a WiFi connection to become available to reduce the cellular traffic. However, these studies are difficult to apply in delay-sensitive services such as VoIP and do not consider a disconnection due to offloading.A femtocell is a small, low-power base station, which is typically used in a home or small business. Because it connects to an operator’s core network via a user broadband network instead of an operator’s private network, it is easy to install with no additional private network infrastructure and it reduces the traffic load of the operator’s private network. Because a femtocell uses the same frequency bands as the macrocell, it can provide seamless data connectivity through cooperation with the macrocell. However, interference from a femtocell can have a critical influence on the performance of a macrocell. This factor is a reason that prevents femtocells from widespread adoption.In this paper, we propose a novel femtocell-to-WiFi offloading scheme that provides seamless connectivity. The proposed scheme utilizes the property of the femtocell wherein data traffic to the operator’s core network is transmitted via the user’s broadband network. Using this property, the proposed offloading scheme can reduce the interference level of the femtocell by offloading traffic to the WiFi network from the femtocell without performance degradation and connection losses. The proposed scheme has the following key features:(i)
It provides seamless connectivity between a femtocell and a WiFi network.(ii)
It does not require modification of the operator’s core network except for the femtocell. This feature allows for the immediate implementation of seamless offloading using the femtocell in a small area such as the home or office.(iii)
It provides quality-of-service (QoS) guarantees in terms of throughput after offloading traffic to a WiFi network from a femtocell using available bandwidth estimation of a WiFi access point (WiFi AP) and an association control mechanism.To implement an offloading scheme with the above features, we designed an SDN-based [11, 12] femtocell-to-WiFi offloading system. Software-defined networking (SDN) is a new paradigm for programmable networking and is adopted extensively in enterprise networks and data centers. It divides the control plane and the data plane of the network. Thus, a data plane process such as packet forwarding is performed by a switch, and the network control is conducted by an SDN controller with a total view of the network. The most popular protocol is OpenFlow, which defines the rules for communication between a controller and the switches. With SDN, the network operator can apply routing protocols and network applications to the network easily and flexibly. Utilizing the above advantages of SDN technology, we implemented a femtocell-to-WiFi offloading system. Furthermore, we propose offloading target selection schemes to reduce femtocell traffic without QoS degradation. Then, we performed experiments to validate the feasibility of the proposed system. Through the experiments on an actual testbed, we confirmed that the proposed offloading system and offloading target selection scheme provide seamless connectivity between a femtocell and a WiFi network and reduce the load of the femtocell without QoS degradation due to offloading.The remainder of this paper is organized as follows. In Section2, we review the related works. In Section 3, we describe the proposed system architecture and operation details. In Section 4, we describe the proposed schemes for offloading the target selection. In Section 5, we discuss the experiment results. Finally, in Section 6, we conclude this paper.


## 2. Related Works

Recently, many studies on offloading cellular traffic to a WiFi network have been conducted. In this section, we review the related works.


### 2.1. Delayed Offloading Schemes

Many research studies have reported that offloading cellular traffic via WiFi provides an improved user experience such as higher throughput and lower delay. In this category, the majority of the studies proposed offloading schemes based on delay-tolerant networking (DTN) [13]. If the WiFi connection is expected to be established before a predefined deadline of data traffic, these schemes delay the transmission of the data traffic via the cellular network. Then, they transmit the data traffic after the WiFi connection is established. The goal of these schemes is to reduce the load on the cellular network and the user’s cost by minimizing the transmission of data traffic via the cellular network [3].Wiffler [4] and MADNet [5] proposed DTN-based WiFi offloading schemes. Wiffler reduces the cellular network usage by up to 40% with a 60 s delay tolerance. MADNet also demonstrates that its offloading scheme can reduce cellular network usage by up to 50% in its experiment scenarios. Lee et al. [6] studied the economic aspect of DTN-based WiFi offloading schemes by modeling a game theoretic framework. Siris and Kalyvas [7] proposed a WiFi offloading scheme that exploits mobility prediction and prefetching to enhance its efficiency. However, because there is a trade-off between delay and offloading efficiency in DTN-based offloading schemes, they are difficult to apply to real-time application such as video streaming and VoIP. Moreover, considering that most applications (e.g., web surfing) used in smartphones require real-time responses or short delays, DTN-based offloading schemes have difficulty maintaining maximum efficiency in the real world.


### 2.2. Seamless Offloading Mechanism

Research studies that proposed solutions for seamless WiFi offloading can be divided into two categories: network layer-based and transport layer-based solutions. In the network layer-based solutions, mobile IPv6 is used in place of IPv4. Mobile IP (MIP) allows the use of a single IP address in terminals regardless of the wireless network type. IP flow mobility (IFOM) [8], which was standardized in 3GPP Release 10 for seamless WiFi offloading, is based on an extension of MIPv6 that uses dual stacks (DSMIPv6). The IFOM solution commonly requires a home agent (HA) as an anchoring node, and it also requires modification of the terminal to support DSMIPv6. In addition, the network equipment in the EPC has to be modified because the HA needs to interwork with the PDN gateway (P-GW) in the EPC. These aspects make its immediate implementation and deployment difficult. However, the proposed solution in this paper does not require modification of the network equipment in the EPC because it works without cooperation with EPC.The transport layer-based solutions use new transport protocols rather than legacy TCP and UDP. The mobile Stream Control Transmission Protocol (mSCTP) [9] and Multipath Transport Control Protocol (MPTCP) [10] are examples of new transport protocols. The mSCTP is an extension of the Stream Control Transmission Protocol for mobile applications; it shows superior performance compared to the legacy transport protocols, such as TCP and UDP, by supporting multihoming and multistreaming. MPTCP is similar to mSCTP in that it supports multihoming; however, it is different in terms of backward compatibility with legacy TCP. Thus, no adaptation is required of applications that run on MPTCP, and its packets can pass through a network address translation equipment and firewalls without problems. However, these new schemes on the transport layer require new wireless terminals and servers that support these new transport protocols. The wide dissemination of these devices will require substantial time. Conversely, the offloading scheme proposed in this paper allows for the immediate implementation of seamless offloading in a small area such as the home or office.


### 2.3. Access Network Selection

In this subsection, we review the research studies on access network selection in heterogeneous wireless network environments. Gazis et al. [14] modeled the Always-Best-Connected problem as a knapsack problem and argued that it is an NP-hard problem. Song and Jamalipour [15] proposed an access network selection scheme in an integrated WLAN and UMTS environment by using mathematical modeling and computational techniques that apply an analytic hierarchy process (AHP) to determine the relative weights of the various evaluation criteria and a grey relational analysis (GRA) to rank the network alternatives. Xing and Venkatasubramanian [16] modeled the problem of access network selection as a variant of the bin-packing problem. Then, they proposed approximation algorithms for determining near-optimal solutions. Jung et al. [17] proposed a network-assisted WiFi offloading model and an offloading decision scheme to maximize per-user throughput. The majority of the studies in this category focused primarily on maximizing performance in terms of throughput in saturated traffic scenarios and performed performance evaluations through model-based simulation only. In this paper, we design and implement a femtocell-to-WiFi offloading system. We also propose an offloading target selection scheme to reduce the load of the femtocell, which uses the same air interface as that of the macrocell, without QoS degradation in terms of throughput due to offloading. We evaluated the proposed system and offloading target selection scheme in an actual testbed implemented using SDN technology.


## 2.1. Delayed Offloading Schemes

Many research studies have reported that offloading cellular traffic via WiFi provides an improved user experience such as higher throughput and lower delay. In this category, the majority of the studies proposed offloading schemes based on delay-tolerant networking (DTN) [13]. If the WiFi connection is expected to be established before a predefined deadline of data traffic, these schemes delay the transmission of the data traffic via the cellular network. Then, they transmit the data traffic after the WiFi connection is established. The goal of these schemes is to reduce the load on the cellular network and the user’s cost by minimizing the transmission of data traffic via the cellular network [3].Wiffler [4] and MADNet [5] proposed DTN-based WiFi offloading schemes. Wiffler reduces the cellular network usage by up to 40% with a 60 s delay tolerance. MADNet also demonstrates that its offloading scheme can reduce cellular network usage by up to 50% in its experiment scenarios. Lee et al. [6] studied the economic aspect of DTN-based WiFi offloading schemes by modeling a game theoretic framework. Siris and Kalyvas [7] proposed a WiFi offloading scheme that exploits mobility prediction and prefetching to enhance its efficiency. However, because there is a trade-off between delay and offloading efficiency in DTN-based offloading schemes, they are difficult to apply to real-time application such as video streaming and VoIP. Moreover, considering that most applications (e.g., web surfing) used in smartphones require real-time responses or short delays, DTN-based offloading schemes have difficulty maintaining maximum efficiency in the real world.


## 2.2. Seamless Offloading Mechanism

Research studies that proposed solutions for seamless WiFi offloading can be divided into two categories: network layer-based and transport layer-based solutions. In the network layer-based solutions, mobile IPv6 is used in place of IPv4. Mobile IP (MIP) allows the use of a single IP address in terminals regardless of the wireless network type. IP flow mobility (IFOM) [8], which was standardized in 3GPP Release 10 for seamless WiFi offloading, is based on an extension of MIPv6 that uses dual stacks (DSMIPv6). The IFOM solution commonly requires a home agent (HA) as an anchoring node, and it also requires modification of the terminal to support DSMIPv6. In addition, the network equipment in the EPC has to be modified because the HA needs to interwork with the PDN gateway (P-GW) in the EPC. These aspects make its immediate implementation and deployment difficult. However, the proposed solution in this paper does not require modification of the network equipment in the EPC because it works without cooperation with EPC.The transport layer-based solutions use new transport protocols rather than legacy TCP and UDP. The mobile Stream Control Transmission Protocol (mSCTP) [9] and Multipath Transport Control Protocol (MPTCP) [10] are examples of new transport protocols. The mSCTP is an extension of the Stream Control Transmission Protocol for mobile applications; it shows superior performance compared to the legacy transport protocols, such as TCP and UDP, by supporting multihoming and multistreaming. MPTCP is similar to mSCTP in that it supports multihoming; however, it is different in terms of backward compatibility with legacy TCP. Thus, no adaptation is required of applications that run on MPTCP, and its packets can pass through a network address translation equipment and firewalls without problems. However, these new schemes on the transport layer require new wireless terminals and servers that support these new transport protocols. The wide dissemination of these devices will require substantial time. Conversely, the offloading scheme proposed in this paper allows for the immediate implementation of seamless offloading in a small area such as the home or office.


## 2.3. Access Network Selection

In this subsection, we review the research studies on access network selection in heterogeneous wireless network environments. Gazis et al. [14] modeled the Always-Best-Connected problem as a knapsack problem and argued that it is an NP-hard problem. Song and Jamalipour [15] proposed an access network selection scheme in an integrated WLAN and UMTS environment by using mathematical modeling and computational techniques that apply an analytic hierarchy process (AHP) to determine the relative weights of the various evaluation criteria and a grey relational analysis (GRA) to rank the network alternatives. Xing and Venkatasubramanian [16] modeled the problem of access network selection as a variant of the bin-packing problem. Then, they proposed approximation algorithms for determining near-optimal solutions. Jung et al. [17] proposed a network-assisted WiFi offloading model and an offloading decision scheme to maximize per-user throughput. The majority of the studies in this category focused primarily on maximizing performance in terms of throughput in saturated traffic scenarios and performed performance evaluations through model-based simulation only. In this paper, we design and implement a femtocell-to-WiFi offloading system. We also propose an offloading target selection scheme to reduce the load of the femtocell, which uses the same air interface as that of the macrocell, without QoS degradation in terms of throughput due to offloading. We evaluated the proposed system and offloading target selection scheme in an actual testbed implemented using SDN technology.


## 3. Proposed Offloading System

### 3.1. Outline of the Proposed System

Figure1 presents the overall structure of the proposed femtocell-to-WiFi offloading system. In this figure, the components within the shaded area, namely, the LTE user equipment (UE), LTE femtocell, WiFi AP, SDN switch, and SDN controller, comprise a radio access network that is modified for the offloading operation. However, the components outside the shaded area, namely, the Evolved Packet Core (EPC) and public data server, are not modified for the offloading operation. That is, from the viewpoint of the EPC and public server, the modified access network for the offloading operation is identical to legacy versions. This figure also indicates the data transmission path between the UE and the public data server. When a UE is handed over from the macrocell to the femtocell, data traffic passes through the LTE femtocell (solid line). If a UE is offloaded to a WiFi AP, the data transmission path is changed in the SDN switch such that the data traffic passes through the WiFi AP (dotted line).Figure 1
The system architecture.In the proposed system, the femtocell is connected to the EPC via the SDN switch. Furthermore, the SDN controller gathers the status information such as traffic statistics and wireless channel condition from the SDN equipment. Then, it determines the WiFi offloading on the basis of the collected information. If the controller decides to initiate the WiFi offloading, it starts an exchange of control messages with the SDN switch, WiFi AP, and UE. For the communication between the SDN controller and the other equipment under its control, we ported the SDN agent software to the WiFi AP and femtocell. The SDN agent sends the internal status information to the SDN controller in the form of an OpenFlow message. It receives OpenFlow messages from the controller and performs an action according to the controller command by parsing the OpenFlow messages. In addition, the proposed system controls the actions of the smartphone such as activating its WiFi interface and associating it with a specific WiFi AP. We have implemented a mobile app for the smartphone to enable its control by the SDN controller. The mobile app has an OpenFlow message handling module for communicating with the SDN controller and performs the actions according to the command of the SDN controller. Some actions of each equipment for the proposed offloading scheme are beyond the scope of a state-of-the-art OpenFlow specification. However, the OpenFlow specification provides vendor extension messages for one’s own extension. Using this feature, we implemented the SDN controller to control these actions by defining vendor extension messages for the proposed offloading scheme.


### 3.2. Detailed Operation Process

Figure2 presents the detailed operation process for the femtocell-to-WiFi offloading. As indicated on the left side of Figure 2, the operation states of the UE consist of the idle, onload, and offload states. In the idle state, the SDN controller awaits the entrance of a new UE to use the packet data service. In the onload state, all user packets of the UE pass through the femtocell; however, in the offload state, they pass through the WiFi AP. In both the onload and offload state, the SDN controller gathers the status information to verify the necessity of transitioning to the other state. In all states, the SDN switch forwards the LTE signaling messages between the femtocell and the EPC to the SDN controller so that the SDN controller can detect the state transition conditions. Of all the operations executed in the SDN controller, the following three major operations will be discussed in the followed subsection: (i) terminal presence detection, (ii) traffic/wireless channel status gathering, (iii) traffic offloading to a WiFi AP, and (iv) traffic onloading to a femtocell.Figure 2
Operation procedure and message exchange for offloading.


#### 3.2.1. Terminal Presence Detection

The proposed system performs the WiFi offloading operation only when the smartphone actively exchanges packet data with the EPC in the service area of the femtocell. Therefore, in the SDN controller, the management operation regarding the presence of a terminal is initiated when the first packet bearer is established or a packet call is handed over from the macrocell. This management operation is ended when a packet call is terminated or handed over to the macrocell. For terminal presence detection, the SDN switch forwards all LTE signaling messages to the SDN controller. If the presence of a new terminal is detected, then the UEs transition to the onload state, as indicated in Figure2.


#### 3.2.2. Traffic/Wireless Channel Status Gathering

The SDN equipment reports its internal state information periodically to the controller to allow the controller to make decisions regarding the WiFi offloading according to the traffic and wireless channel status. The offloading condition can be changed easily according to the operator’s policy by modifying only the control application in the controller to utilize the advantages of the SDN technology.


#### 3.2.3. Traffic Offloading (from Femtocell to WiFi AP)

If the collected status information satisfies the predefined offloading condition, the SDN controller controls the SDN switch and the WiFi AP so that user traffic data are routed to the WiFi AP instead of to the femtocell. Prior to the actual offloading, the SDN controller sends a control message to the UE to activate its WiFi module and scan available WiFi APs. Simultaneously, the SDN controller sends a control message to register the UE’s MAC address of its WiFi interfaces to the WiFi AP. If the WiFi AP receives a probe frame of the UE during the UE’s scanning process, it reports the information to the controller with the received signal strength indicator (RSSI) of the probe frame. Through this step, the controller can find WiFi APs that are available for offloading the UE.After this step, the controller sends control messages to the UE and WiFi AP requesting the UE to perform an association process with the corresponding WiFi AP. In this request message to the WiFi AP, the UE’s IP address information that was assigned by the EPC is included so that the WiFi AP can assign the same IP address to the UE for exchanging the DHCP frame. The reason for assigning the same IP address is to avoid the reestablishment of a data session after offloading to the WiFi. In a conventional transport layer, the change in IP address causes the disconnection of the data session, and then, the application program is temporarily suspended until the data session is recovered. Although the IP address hierarchy of a UE, assigned by EPC, is different from the IP address hierarchy of the user networks, SDN technology allows packet routing regardless of an IP address hierarchy [12].When the controller receives a report that connection between the UE and the WiFi AP is established normally (offloading request confirmed), the SDN switch is configured by the SDN controller so that the packets can be routed between the EPC and the UE via the WiFi AP. With this configuration, the user packets, which were previously routed to the femtocell, are forwarded to the switch port where the WiFi AP is connected. Meanwhile, the packets from the WiFi AP, the destination of which is the EPC, are routed to the switch port where the EPC is connected. While processing these packets from the smartphones, the SDN switch performs an additional General Packet Radio Service (GPRS) Tunneling Protocol (GTP) processing operation. A detailed explanation of this operation is provided in the following subsection.During the WiFi offloading procedure, no changes occur in the femtocell. This is because the offload state is recognized by the femtocell as a type of no-traffic state. At the same time, the UE activates both the LTE module and the WiFi module simultaneously. This is performed to provide continuous mobility support for the smartphone. The maintenance of the bearer information between the femtocell and the UE in the offload state is required to allow a fast onloading procedure that recovers the packet routing path from the WiFi AP link to the femtocell link when the WiFi connection is broken unexpectedly.


#### 3.2.4. Traffic Onloading (from WiFi to Femtocell)

The gathering and analysis of channel status information are continued in the offload state. If the analysis results satisfy a predefined onloading condition, then the SDN controller starts an onloading procedure that changes the user traffic routing path from via the WiFi AP to via the femtocell. In addition, when a UE is handed over from the femtocell to the macrocell, the SDN controller switches the UE to the onload state for seamless connectivity because the offloading path for the UE is not valid after the handover. The handover from the femtocell to macrocell can be detected through the femtocell because the handover decision in the cellular network is performed at the serving cell [18]. When the handover from the femtocell to the macrocell is decided by the femtocell, the OpenFlow agent in the femtocell notifies it to the SDN controller. Thus, the SDN controller initiates the procedure for the onloading immediately before the handover situation.The onloading procedure is started by sending a control message to the smartphone to deactivate its WiFi module. As mentioned above, there are no changes in the femtocell after the offloading; the reconfiguration of the smartphone alone is sufficient for resuming the communication via the femtocell. This short procedure for onloading allows a UE to transit quickly to the onload state. Then, the SDN controller sends the other control messages to the SDN switch and the WiFi AP to release the assigned network resources for the offloading.


### 3.3. Implementation and Integration Issues

#### 3.3.1. Traffic Offloading in the Smartphone

For the proposed offloading scheme, we need to activate both the LTE module and the WiFi module of the Android smartphones. Because the default APIs provided by Android do not allow the activation of both modules at the same time, we need to install an application program for achieving root permission; this is called rooting. After activating both modules, we require a technique for dynamically controlling the routing path of the user traffic between the LTE module and the WiFi module that does not have an impact on the user application or require modification of the kernel. This requirement is satisfied using the routing policy database (RPDB). We register two routing policies on the database, with information fields that are identical except for the priority and device name. Then, the routing path control is achieved by changing the priority of these two routing policies.


#### 3.3.2. IPsec Protocol Processing

For the interconnection of the EPC and femtocell, it is common to use a public data network. Therefore, a security protocol, IPsec, is applied on this link to provide user data protection [19]. However, if the user traffic on this link is encrypted using the IPsec protocol, the SDN switch cannot analyze the header fields of the messages between the EPC and the femtocell, which is required for data offloading according to the operation states. To avoid this problem, the SDN controller obtains the decryption key from the SDN agent of the femtocell. Then, SDN controller informs the SDN switch of the IPsec decryption key. We also defined OpenFlow vendor messages for this purpose. Through this, the decryption of the IPsec packet can be performed at the SDN switch in the offload state.One possible security concern related to the proposed scheme is that the link between the femtocell and the SDN switch is not protected by a security protocol in the offload state. However, we assume that this link is not a part of the public data network because the subnetwork under the SDN switch is located within a private facility, such as the building of a company, and the SDN switch may behave as a gateway between the public and the private network.


#### 3.3.3. GTP Processing

In mobile communication systems, a tunneling scheme called GTP is applied on the transport links between the base stations and the EPC for transferring the user IP packet on the IP-based EPC without a change in the user IP address. It is almost identical to the tunneling scheme used by a mobile IP protocol.In a conventional LTE system, the GTP protocol is terminated in the femtocell. Therefore, in the onload state, a problem does not arise because all the user packets pass through the femtocell. However, in the offload state, the user packets bypass the femtocell. In the proposed offloading system, the SDN switch terminates the GTP protocol in the offload state. Thus, in the offload state, the SDN switch detaches the GTP header of the IP packets transmitted from the EPC to the smartphones and forwards the packets to the WiFi AP. The GTP header is attached at the SDN switch when the IP packets transmitted from the smartphones to the EPC are delivered via the WiFi AP. The change in the GTP termination point in the proposed offloading systems does not cause a complex state information transfer between the femtocell and the SDN switch. The message fields of the GTP header consist of static information such as a bearer identifier. Thus, one control message exchanged in the early terminal presence detection phase is sufficient for building the GTP header in the SDN switch.


#### 3.3.4. Modification of the OpenFlow Protocol for Offloading Support

Originally, the OpenFlow specification was defined for wired network devices, and, therefore, its control messages cannot control the operation of wireless network devices such as entrance/leave management, wireless channel status information gathering, and onload/offload control operations. In the proposed offloading system, we additionally define proprietary messages on the payload portion of the vendor-specific messages of the OpenFlow specification. Moreover, the GTP termination and IPsec termination operations explained above, which are beyond the scope of the OpenFlow specification, are implemented on the SDN switch in the form of add-on modules.


#### 3.3.5. Avoiding Radio Resource Control (RRC) Connection Release in the Offload State

In the LTE network, the operation state of a terminal is maintained in two places: the EPC and the base station. Furthermore, all data traffic must pass through a base station, which is the femtocell in the proposed approach. Thus, the operation states maintained in both the EPC and the femtocell are synchronized. However, in the offload state, user traffic does not pass through the femtocell, and, therefore, the femtocell interprets this state as a long idle period. After a predefined period, the femtocell releases an RRC connection, which is a logical control connection established between the cellular terminal and the base station for signaling [20]. The release of the RRC connection also triggers the release of the entire packet session, although data traffic is actively exchanged between the EPC and the terminal via the WiFi AP. To avoid this problem without changing the existing protocol stack of the EPC, we periodically generate a ping message via the LTE module of the smartphone. Because these ping messages are generated only in the offload state, they do not place any meaningful burden on the EPC.This approach does not require modification of the current protocol stack, but it can cause unnecessary energy consumption because radio resources of the LTE interface of the UE is awake in the offload state. However, the energy consumption of the UE in offload state can be rather reduced than the UE in onload state considering that the power consumption of data transmission using the LTE interface is larger than using the WiFi interface [21].


#### 3.3.6. System Integration and Deployment Issues

The proposed system works based on the cooperative operations of various equipment in the area where the femtocell is installed. As mentioned in the previous subsections, some information for the IPsec and GTP termination should be obtained from the femtocell to perform certain tasks for offloading. This raises a security concern for the integration of the proposed solution. If the proposed solution is deployed on a network owned by a mobile network operator (MNO), the security concern does not arise because the SDN controller and other equipment are under their control. However, in case that the proposed solution is deployed on the user’s network, the authentication and authorization mechanism should be implemented additionally to establish trusted relationship between each entity. In addition, in this deployment scenario, the MNO should be allowed to manage the flows related to the offloading in a user’s network although the SDN network controller is owned by the user. Fortunately, the SDN controllers from various vendors provide APIs to control the traffic flow through a network application running on top of the controller. So, in our implementation, the module that controls the traffic flows related to the offloading was implemented as a network application running on top of the SDN controller and it only controls the flow related to the offloading. Using this feature, the MNO can manage the flows related to the offloading in the user’s network by installing the network application running on the user’s SDN controller while the other flows are controlled by the user’s policy.The scalability issue can arise in the large-scale deployment scenario because various tasks for the offloading are performed in the SDN controller and SDN switch. However, some of these tasks can be migrated to the femtocell. For example, the task analyzing the signaling messages between the femtocell and EPC can be handled at the femtocell by implementing the femtocell to report the events that the SDN controller has to be aware for the offloading. In case of the processing overhead for the GTP and IPsec termination on the SDN switch, the femtocell can be implemented to redirect the UE’s flow that is decided to offload by the SDN controller to a WiFi AP after the IPsec and GTP termination through a tunnel between the femtocell and WiFi AP. In case of this implementation, the femtocell should report each UE’s traffic statistics to the SDN controller. The WiFi AP also have to forward the traffic from the UE to the femtocell for the GTP and IPsec encapsulation. Although this implementation method can avoid scalability issues due to the processing overhead, it induces additional traffic overhead for redirecting traffic flows of the offloaded UE.One possible way to integrate the proposed solution avoiding the issues in this subsection is to implement the proposed offloading scheme using the femtocell with multiple WiFi interfaces as an all-in-one solution. The role of the SDN controller in the proposed scheme can be implemented as a control module in the kernel of the femtocell. It controls the data forwarding between the radio interfaces in the femtocell and controls the operation of the UE by establishing a control channel between the control module and the mobile app in the UE. This way for the integration requires the design of a new femtocell with multiple WiFi interfaces but does not cause security and scalability issues because the GTP and IPsec termination are performed on the femtocell. We believe this is one of the ways that the proposed solution is implemented and deployed.


## 3.1. Outline of the Proposed System

Figure1 presents the overall structure of the proposed femtocell-to-WiFi offloading system. In this figure, the components within the shaded area, namely, the LTE user equipment (UE), LTE femtocell, WiFi AP, SDN switch, and SDN controller, comprise a radio access network that is modified for the offloading operation. However, the components outside the shaded area, namely, the Evolved Packet Core (EPC) and public data server, are not modified for the offloading operation. That is, from the viewpoint of the EPC and public server, the modified access network for the offloading operation is identical to legacy versions. This figure also indicates the data transmission path between the UE and the public data server. When a UE is handed over from the macrocell to the femtocell, data traffic passes through the LTE femtocell (solid line). If a UE is offloaded to a WiFi AP, the data transmission path is changed in the SDN switch such that the data traffic passes through the WiFi AP (dotted line).Figure 1
The system architecture.In the proposed system, the femtocell is connected to the EPC via the SDN switch. Furthermore, the SDN controller gathers the status information such as traffic statistics and wireless channel condition from the SDN equipment. Then, it determines the WiFi offloading on the basis of the collected information. If the controller decides to initiate the WiFi offloading, it starts an exchange of control messages with the SDN switch, WiFi AP, and UE. For the communication between the SDN controller and the other equipment under its control, we ported the SDN agent software to the WiFi AP and femtocell. The SDN agent sends the internal status information to the SDN controller in the form of an OpenFlow message. It receives OpenFlow messages from the controller and performs an action according to the controller command by parsing the OpenFlow messages. In addition, the proposed system controls the actions of the smartphone such as activating its WiFi interface and associating it with a specific WiFi AP. We have implemented a mobile app for the smartphone to enable its control by the SDN controller. The mobile app has an OpenFlow message handling module for communicating with the SDN controller and performs the actions according to the command of the SDN controller. Some actions of each equipment for the proposed offloading scheme are beyond the scope of a state-of-the-art OpenFlow specification. However, the OpenFlow specification provides vendor extension messages for one’s own extension. Using this feature, we implemented the SDN controller to control these actions by defining vendor extension messages for the proposed offloading scheme.


## 3.2. Detailed Operation Process

Figure2 presents the detailed operation process for the femtocell-to-WiFi offloading. As indicated on the left side of Figure 2, the operation states of the UE consist of the idle, onload, and offload states. In the idle state, the SDN controller awaits the entrance of a new UE to use the packet data service. In the onload state, all user packets of the UE pass through the femtocell; however, in the offload state, they pass through the WiFi AP. In both the onload and offload state, the SDN controller gathers the status information to verify the necessity of transitioning to the other state. In all states, the SDN switch forwards the LTE signaling messages between the femtocell and the EPC to the SDN controller so that the SDN controller can detect the state transition conditions. Of all the operations executed in the SDN controller, the following three major operations will be discussed in the followed subsection: (i) terminal presence detection, (ii) traffic/wireless channel status gathering, (iii) traffic offloading to a WiFi AP, and (iv) traffic onloading to a femtocell.Figure 2
Operation procedure and message exchange for offloading.


### 3.2.1. Terminal Presence Detection

The proposed system performs the WiFi offloading operation only when the smartphone actively exchanges packet data with the EPC in the service area of the femtocell. Therefore, in the SDN controller, the management operation regarding the presence of a terminal is initiated when the first packet bearer is established or a packet call is handed over from the macrocell. This management operation is ended when a packet call is terminated or handed over to the macrocell. For terminal presence detection, the SDN switch forwards all LTE signaling messages to the SDN controller. If the presence of a new terminal is detected, then the UEs transition to the onload state, as indicated in Figure2.


### 3.2.2. Traffic/Wireless Channel Status Gathering

The SDN equipment reports its internal state information periodically to the controller to allow the controller to make decisions regarding the WiFi offloading according to the traffic and wireless channel status. The offloading condition can be changed easily according to the operator’s policy by modifying only the control application in the controller to utilize the advantages of the SDN technology.


### 3.2.3. Traffic Offloading (from Femtocell to WiFi AP)

If the collected status information satisfies the predefined offloading condition, the SDN controller controls the SDN switch and the WiFi AP so that user traffic data are routed to the WiFi AP instead of to the femtocell. Prior to the actual offloading, the SDN controller sends a control message to the UE to activate its WiFi module and scan available WiFi APs. Simultaneously, the SDN controller sends a control message to register the UE’s MAC address of its WiFi interfaces to the WiFi AP. If the WiFi AP receives a probe frame of the UE during the UE’s scanning process, it reports the information to the controller with the received signal strength indicator (RSSI) of the probe frame. Through this step, the controller can find WiFi APs that are available for offloading the UE.After this step, the controller sends control messages to the UE and WiFi AP requesting the UE to perform an association process with the corresponding WiFi AP. In this request message to the WiFi AP, the UE’s IP address information that was assigned by the EPC is included so that the WiFi AP can assign the same IP address to the UE for exchanging the DHCP frame. The reason for assigning the same IP address is to avoid the reestablishment of a data session after offloading to the WiFi. In a conventional transport layer, the change in IP address causes the disconnection of the data session, and then, the application program is temporarily suspended until the data session is recovered. Although the IP address hierarchy of a UE, assigned by EPC, is different from the IP address hierarchy of the user networks, SDN technology allows packet routing regardless of an IP address hierarchy [12].When the controller receives a report that connection between the UE and the WiFi AP is established normally (offloading request confirmed), the SDN switch is configured by the SDN controller so that the packets can be routed between the EPC and the UE via the WiFi AP. With this configuration, the user packets, which were previously routed to the femtocell, are forwarded to the switch port where the WiFi AP is connected. Meanwhile, the packets from the WiFi AP, the destination of which is the EPC, are routed to the switch port where the EPC is connected. While processing these packets from the smartphones, the SDN switch performs an additional General Packet Radio Service (GPRS) Tunneling Protocol (GTP) processing operation. A detailed explanation of this operation is provided in the following subsection.During the WiFi offloading procedure, no changes occur in the femtocell. This is because the offload state is recognized by the femtocell as a type of no-traffic state. At the same time, the UE activates both the LTE module and the WiFi module simultaneously. This is performed to provide continuous mobility support for the smartphone. The maintenance of the bearer information between the femtocell and the UE in the offload state is required to allow a fast onloading procedure that recovers the packet routing path from the WiFi AP link to the femtocell link when the WiFi connection is broken unexpectedly.


### 3.2.4. Traffic Onloading (from WiFi to Femtocell)

The gathering and analysis of channel status information are continued in the offload state. If the analysis results satisfy a predefined onloading condition, then the SDN controller starts an onloading procedure that changes the user traffic routing path from via the WiFi AP to via the femtocell. In addition, when a UE is handed over from the femtocell to the macrocell, the SDN controller switches the UE to the onload state for seamless connectivity because the offloading path for the UE is not valid after the handover. The handover from the femtocell to macrocell can be detected through the femtocell because the handover decision in the cellular network is performed at the serving cell [18]. When the handover from the femtocell to the macrocell is decided by the femtocell, the OpenFlow agent in the femtocell notifies it to the SDN controller. Thus, the SDN controller initiates the procedure for the onloading immediately before the handover situation.The onloading procedure is started by sending a control message to the smartphone to deactivate its WiFi module. As mentioned above, there are no changes in the femtocell after the offloading; the reconfiguration of the smartphone alone is sufficient for resuming the communication via the femtocell. This short procedure for onloading allows a UE to transit quickly to the onload state. Then, the SDN controller sends the other control messages to the SDN switch and the WiFi AP to release the assigned network resources for the offloading.


## 3.2.1. Terminal Presence Detection

The proposed system performs the WiFi offloading operation only when the smartphone actively exchanges packet data with the EPC in the service area of the femtocell. Therefore, in the SDN controller, the management operation regarding the presence of a terminal is initiated when the first packet bearer is established or a packet call is handed over from the macrocell. This management operation is ended when a packet call is terminated or handed over to the macrocell. For terminal presence detection, the SDN switch forwards all LTE signaling messages to the SDN controller. If the presence of a new terminal is detected, then the UEs transition to the onload state, as indicated in Figure2.


## 3.2.2. Traffic/Wireless Channel Status Gathering

The SDN equipment reports its internal state information periodically to the controller to allow the controller to make decisions regarding the WiFi offloading according to the traffic and wireless channel status. The offloading condition can be changed easily according to the operator’s policy by modifying only the control application in the controller to utilize the advantages of the SDN technology.


## 3.2.3. Traffic Offloading (from Femtocell to WiFi AP)

If the collected status information satisfies the predefined offloading condition, the SDN controller controls the SDN switch and the WiFi AP so that user traffic data are routed to the WiFi AP instead of to the femtocell. Prior to the actual offloading, the SDN controller sends a control message to the UE to activate its WiFi module and scan available WiFi APs. Simultaneously, the SDN controller sends a control message to register the UE’s MAC address of its WiFi interfaces to the WiFi AP. If the WiFi AP receives a probe frame of the UE during the UE’s scanning process, it reports the information to the controller with the received signal strength indicator (RSSI) of the probe frame. Through this step, the controller can find WiFi APs that are available for offloading the UE.After this step, the controller sends control messages to the UE and WiFi AP requesting the UE to perform an association process with the corresponding WiFi AP. In this request message to the WiFi AP, the UE’s IP address information that was assigned by the EPC is included so that the WiFi AP can assign the same IP address to the UE for exchanging the DHCP frame. The reason for assigning the same IP address is to avoid the reestablishment of a data session after offloading to the WiFi. In a conventional transport layer, the change in IP address causes the disconnection of the data session, and then, the application program is temporarily suspended until the data session is recovered. Although the IP address hierarchy of a UE, assigned by EPC, is different from the IP address hierarchy of the user networks, SDN technology allows packet routing regardless of an IP address hierarchy [12].When the controller receives a report that connection between the UE and the WiFi AP is established normally (offloading request confirmed), the SDN switch is configured by the SDN controller so that the packets can be routed between the EPC and the UE via the WiFi AP. With this configuration, the user packets, which were previously routed to the femtocell, are forwarded to the switch port where the WiFi AP is connected. Meanwhile, the packets from the WiFi AP, the destination of which is the EPC, are routed to the switch port where the EPC is connected. While processing these packets from the smartphones, the SDN switch performs an additional General Packet Radio Service (GPRS) Tunneling Protocol (GTP) processing operation. A detailed explanation of this operation is provided in the following subsection.During the WiFi offloading procedure, no changes occur in the femtocell. This is because the offload state is recognized by the femtocell as a type of no-traffic state. At the same time, the UE activates both the LTE module and the WiFi module simultaneously. This is performed to provide continuous mobility support for the smartphone. The maintenance of the bearer information between the femtocell and the UE in the offload state is required to allow a fast onloading procedure that recovers the packet routing path from the WiFi AP link to the femtocell link when the WiFi connection is broken unexpectedly.


## 3.2.4. Traffic Onloading (from WiFi to Femtocell)

The gathering and analysis of channel status information are continued in the offload state. If the analysis results satisfy a predefined onloading condition, then the SDN controller starts an onloading procedure that changes the user traffic routing path from via the WiFi AP to via the femtocell. In addition, when a UE is handed over from the femtocell to the macrocell, the SDN controller switches the UE to the onload state for seamless connectivity because the offloading path for the UE is not valid after the handover. The handover from the femtocell to macrocell can be detected through the femtocell because the handover decision in the cellular network is performed at the serving cell [18]. When the handover from the femtocell to the macrocell is decided by the femtocell, the OpenFlow agent in the femtocell notifies it to the SDN controller. Thus, the SDN controller initiates the procedure for the onloading immediately before the handover situation.The onloading procedure is started by sending a control message to the smartphone to deactivate its WiFi module. As mentioned above, there are no changes in the femtocell after the offloading; the reconfiguration of the smartphone alone is sufficient for resuming the communication via the femtocell. This short procedure for onloading allows a UE to transit quickly to the onload state. Then, the SDN controller sends the other control messages to the SDN switch and the WiFi AP to release the assigned network resources for the offloading.


## 3.3. Implementation and Integration Issues

### 3.3.1. Traffic Offloading in the Smartphone

For the proposed offloading scheme, we need to activate both the LTE module and the WiFi module of the Android smartphones. Because the default APIs provided by Android do not allow the activation of both modules at the same time, we need to install an application program for achieving root permission; this is called rooting. After activating both modules, we require a technique for dynamically controlling the routing path of the user traffic between the LTE module and the WiFi module that does not have an impact on the user application or require modification of the kernel. This requirement is satisfied using the routing policy database (RPDB). We register two routing policies on the database, with information fields that are identical except for the priority and device name. Then, the routing path control is achieved by changing the priority of these two routing policies.


### 3.3.2. IPsec Protocol Processing

For the interconnection of the EPC and femtocell, it is common to use a public data network. Therefore, a security protocol, IPsec, is applied on this link to provide user data protection [19]. However, if the user traffic on this link is encrypted using the IPsec protocol, the SDN switch cannot analyze the header fields of the messages between the EPC and the femtocell, which is required for data offloading according to the operation states. To avoid this problem, the SDN controller obtains the decryption key from the SDN agent of the femtocell. Then, SDN controller informs the SDN switch of the IPsec decryption key. We also defined OpenFlow vendor messages for this purpose. Through this, the decryption of the IPsec packet can be performed at the SDN switch in the offload state.One possible security concern related to the proposed scheme is that the link between the femtocell and the SDN switch is not protected by a security protocol in the offload state. However, we assume that this link is not a part of the public data network because the subnetwork under the SDN switch is located within a private facility, such as the building of a company, and the SDN switch may behave as a gateway between the public and the private network.


### 3.3.3. GTP Processing

In mobile communication systems, a tunneling scheme called GTP is applied on the transport links between the base stations and the EPC for transferring the user IP packet on the IP-based EPC without a change in the user IP address. It is almost identical to the tunneling scheme used by a mobile IP protocol.In a conventional LTE system, the GTP protocol is terminated in the femtocell. Therefore, in the onload state, a problem does not arise because all the user packets pass through the femtocell. However, in the offload state, the user packets bypass the femtocell. In the proposed offloading system, the SDN switch terminates the GTP protocol in the offload state. Thus, in the offload state, the SDN switch detaches the GTP header of the IP packets transmitted from the EPC to the smartphones and forwards the packets to the WiFi AP. The GTP header is attached at the SDN switch when the IP packets transmitted from the smartphones to the EPC are delivered via the WiFi AP. The change in the GTP termination point in the proposed offloading systems does not cause a complex state information transfer between the femtocell and the SDN switch. The message fields of the GTP header consist of static information such as a bearer identifier. Thus, one control message exchanged in the early terminal presence detection phase is sufficient for building the GTP header in the SDN switch.


### 3.3.4. Modification of the OpenFlow Protocol for Offloading Support

Originally, the OpenFlow specification was defined for wired network devices, and, therefore, its control messages cannot control the operation of wireless network devices such as entrance/leave management, wireless channel status information gathering, and onload/offload control operations. In the proposed offloading system, we additionally define proprietary messages on the payload portion of the vendor-specific messages of the OpenFlow specification. Moreover, the GTP termination and IPsec termination operations explained above, which are beyond the scope of the OpenFlow specification, are implemented on the SDN switch in the form of add-on modules.


### 3.3.5. Avoiding Radio Resource Control (RRC) Connection Release in the Offload State

In the LTE network, the operation state of a terminal is maintained in two places: the EPC and the base station. Furthermore, all data traffic must pass through a base station, which is the femtocell in the proposed approach. Thus, the operation states maintained in both the EPC and the femtocell are synchronized. However, in the offload state, user traffic does not pass through the femtocell, and, therefore, the femtocell interprets this state as a long idle period. After a predefined period, the femtocell releases an RRC connection, which is a logical control connection established between the cellular terminal and the base station for signaling [20]. The release of the RRC connection also triggers the release of the entire packet session, although data traffic is actively exchanged between the EPC and the terminal via the WiFi AP. To avoid this problem without changing the existing protocol stack of the EPC, we periodically generate a ping message via the LTE module of the smartphone. Because these ping messages are generated only in the offload state, they do not place any meaningful burden on the EPC.This approach does not require modification of the current protocol stack, but it can cause unnecessary energy consumption because radio resources of the LTE interface of the UE is awake in the offload state. However, the energy consumption of the UE in offload state can be rather reduced than the UE in onload state considering that the power consumption of data transmission using the LTE interface is larger than using the WiFi interface [21].


### 3.3.6. System Integration and Deployment Issues

The proposed system works based on the cooperative operations of various equipment in the area where the femtocell is installed. As mentioned in the previous subsections, some information for the IPsec and GTP termination should be obtained from the femtocell to perform certain tasks for offloading. This raises a security concern for the integration of the proposed solution. If the proposed solution is deployed on a network owned by a mobile network operator (MNO), the security concern does not arise because the SDN controller and other equipment are under their control. However, in case that the proposed solution is deployed on the user’s network, the authentication and authorization mechanism should be implemented additionally to establish trusted relationship between each entity. In addition, in this deployment scenario, the MNO should be allowed to manage the flows related to the offloading in a user’s network although the SDN network controller is owned by the user. Fortunately, the SDN controllers from various vendors provide APIs to control the traffic flow through a network application running on top of the controller. So, in our implementation, the module that controls the traffic flows related to the offloading was implemented as a network application running on top of the SDN controller and it only controls the flow related to the offloading. Using this feature, the MNO can manage the flows related to the offloading in the user’s network by installing the network application running on the user’s SDN controller while the other flows are controlled by the user’s policy.The scalability issue can arise in the large-scale deployment scenario because various tasks for the offloading are performed in the SDN controller and SDN switch. However, some of these tasks can be migrated to the femtocell. For example, the task analyzing the signaling messages between the femtocell and EPC can be handled at the femtocell by implementing the femtocell to report the events that the SDN controller has to be aware for the offloading. In case of the processing overhead for the GTP and IPsec termination on the SDN switch, the femtocell can be implemented to redirect the UE’s flow that is decided to offload by the SDN controller to a WiFi AP after the IPsec and GTP termination through a tunnel between the femtocell and WiFi AP. In case of this implementation, the femtocell should report each UE’s traffic statistics to the SDN controller. The WiFi AP also have to forward the traffic from the UE to the femtocell for the GTP and IPsec encapsulation. Although this implementation method can avoid scalability issues due to the processing overhead, it induces additional traffic overhead for redirecting traffic flows of the offloaded UE.One possible way to integrate the proposed solution avoiding the issues in this subsection is to implement the proposed offloading scheme using the femtocell with multiple WiFi interfaces as an all-in-one solution. The role of the SDN controller in the proposed scheme can be implemented as a control module in the kernel of the femtocell. It controls the data forwarding between the radio interfaces in the femtocell and controls the operation of the UE by establishing a control channel between the control module and the mobile app in the UE. This way for the integration requires the design of a new femtocell with multiple WiFi interfaces but does not cause security and scalability issues because the GTP and IPsec termination are performed on the femtocell. We believe this is one of the ways that the proposed solution is implemented and deployed.


## 3.3.1. Traffic Offloading in the Smartphone

For the proposed offloading scheme, we need to activate both the LTE module and the WiFi module of the Android smartphones. Because the default APIs provided by Android do not allow the activation of both modules at the same time, we need to install an application program for achieving root permission; this is called rooting. After activating both modules, we require a technique for dynamically controlling the routing path of the user traffic between the LTE module and the WiFi module that does not have an impact on the user application or require modification of the kernel. This requirement is satisfied using the routing policy database (RPDB). We register two routing policies on the database, with information fields that are identical except for the priority and device name. Then, the routing path control is achieved by changing the priority of these two routing policies.


## 3.3.2. IPsec Protocol Processing

For the interconnection of the EPC and femtocell, it is common to use a public data network. Therefore, a security protocol, IPsec, is applied on this link to provide user data protection [19]. However, if the user traffic on this link is encrypted using the IPsec protocol, the SDN switch cannot analyze the header fields of the messages between the EPC and the femtocell, which is required for data offloading according to the operation states. To avoid this problem, the SDN controller obtains the decryption key from the SDN agent of the femtocell. Then, SDN controller informs the SDN switch of the IPsec decryption key. We also defined OpenFlow vendor messages for this purpose. Through this, the decryption of the IPsec packet can be performed at the SDN switch in the offload state.One possible security concern related to the proposed scheme is that the link between the femtocell and the SDN switch is not protected by a security protocol in the offload state. However, we assume that this link is not a part of the public data network because the subnetwork under the SDN switch is located within a private facility, such as the building of a company, and the SDN switch may behave as a gateway between the public and the private network.


## 3.3.3. GTP Processing

In mobile communication systems, a tunneling scheme called GTP is applied on the transport links between the base stations and the EPC for transferring the user IP packet on the IP-based EPC without a change in the user IP address. It is almost identical to the tunneling scheme used by a mobile IP protocol.In a conventional LTE system, the GTP protocol is terminated in the femtocell. Therefore, in the onload state, a problem does not arise because all the user packets pass through the femtocell. However, in the offload state, the user packets bypass the femtocell. In the proposed offloading system, the SDN switch terminates the GTP protocol in the offload state. Thus, in the offload state, the SDN switch detaches the GTP header of the IP packets transmitted from the EPC to the smartphones and forwards the packets to the WiFi AP. The GTP header is attached at the SDN switch when the IP packets transmitted from the smartphones to the EPC are delivered via the WiFi AP. The change in the GTP termination point in the proposed offloading systems does not cause a complex state information transfer between the femtocell and the SDN switch. The message fields of the GTP header consist of static information such as a bearer identifier. Thus, one control message exchanged in the early terminal presence detection phase is sufficient for building the GTP header in the SDN switch.


## 3.3.4. Modification of the OpenFlow Protocol for Offloading Support

Originally, the OpenFlow specification was defined for wired network devices, and, therefore, its control messages cannot control the operation of wireless network devices such as entrance/leave management, wireless channel status information gathering, and onload/offload control operations. In the proposed offloading system, we additionally define proprietary messages on the payload portion of the vendor-specific messages of the OpenFlow specification. Moreover, the GTP termination and IPsec termination operations explained above, which are beyond the scope of the OpenFlow specification, are implemented on the SDN switch in the form of add-on modules.


## 3.3.5. Avoiding Radio Resource Control (RRC) Connection Release in the Offload State

In the LTE network, the operation state of a terminal is maintained in two places: the EPC and the base station. Furthermore, all data traffic must pass through a base station, which is the femtocell in the proposed approach. Thus, the operation states maintained in both the EPC and the femtocell are synchronized. However, in the offload state, user traffic does not pass through the femtocell, and, therefore, the femtocell interprets this state as a long idle period. After a predefined period, the femtocell releases an RRC connection, which is a logical control connection established between the cellular terminal and the base station for signaling [20]. The release of the RRC connection also triggers the release of the entire packet session, although data traffic is actively exchanged between the EPC and the terminal via the WiFi AP. To avoid this problem without changing the existing protocol stack of the EPC, we periodically generate a ping message via the LTE module of the smartphone. Because these ping messages are generated only in the offload state, they do not place any meaningful burden on the EPC.This approach does not require modification of the current protocol stack, but it can cause unnecessary energy consumption because radio resources of the LTE interface of the UE is awake in the offload state. However, the energy consumption of the UE in offload state can be rather reduced than the UE in onload state considering that the power consumption of data transmission using the LTE interface is larger than using the WiFi interface [21].


## 3.3.6. System Integration and Deployment Issues

The proposed system works based on the cooperative operations of various equipment in the area where the femtocell is installed. As mentioned in the previous subsections, some information for the IPsec and GTP termination should be obtained from the femtocell to perform certain tasks for offloading. This raises a security concern for the integration of the proposed solution. If the proposed solution is deployed on a network owned by a mobile network operator (MNO), the security concern does not arise because the SDN controller and other equipment are under their control. However, in case that the proposed solution is deployed on the user’s network, the authentication and authorization mechanism should be implemented additionally to establish trusted relationship between each entity. In addition, in this deployment scenario, the MNO should be allowed to manage the flows related to the offloading in a user’s network although the SDN network controller is owned by the user. Fortunately, the SDN controllers from various vendors provide APIs to control the traffic flow through a network application running on top of the controller. So, in our implementation, the module that controls the traffic flows related to the offloading was implemented as a network application running on top of the SDN controller and it only controls the flow related to the offloading. Using this feature, the MNO can manage the flows related to the offloading in the user’s network by installing the network application running on the user’s SDN controller while the other flows are controlled by the user’s policy.The scalability issue can arise in the large-scale deployment scenario because various tasks for the offloading are performed in the SDN controller and SDN switch. However, some of these tasks can be migrated to the femtocell. For example, the task analyzing the signaling messages between the femtocell and EPC can be handled at the femtocell by implementing the femtocell to report the events that the SDN controller has to be aware for the offloading. In case of the processing overhead for the GTP and IPsec termination on the SDN switch, the femtocell can be implemented to redirect the UE’s flow that is decided to offload by the SDN controller to a WiFi AP after the IPsec and GTP termination through a tunnel between the femtocell and WiFi AP. In case of this implementation, the femtocell should report each UE’s traffic statistics to the SDN controller. The WiFi AP also have to forward the traffic from the UE to the femtocell for the GTP and IPsec encapsulation. Although this implementation method can avoid scalability issues due to the processing overhead, it induces additional traffic overhead for redirecting traffic flows of the offloaded UE.One possible way to integrate the proposed solution avoiding the issues in this subsection is to implement the proposed offloading scheme using the femtocell with multiple WiFi interfaces as an all-in-one solution. The role of the SDN controller in the proposed scheme can be implemented as a control module in the kernel of the femtocell. It controls the data forwarding between the radio interfaces in the femtocell and controls the operation of the UE by establishing a control channel between the control module and the mobile app in the UE. This way for the integration requires the design of a new femtocell with multiple WiFi interfaces but does not cause security and scalability issues because the GTP and IPsec termination are performed on the femtocell. We believe this is one of the ways that the proposed solution is implemented and deployed.


## 4. Proposed Scheme for Offloading Target Decision

In this section, we describe the offloading target decision scheme for selecting an offloading target. When the SDN controller decides to offload UE traffic to the WiFi from the femtocell, it is important to select the target UE and WiFi AP appropriately. Because WiFi AP works on ISM bands, it is influenced by congestion and interference caused by WiFi devices in its surroundings. Therefore, if an offloading target decision is performed on the basis of signal strength (e.g., RSSI) only, the offloading target UE may experience reduced service quality after offloading. In particular, if the UE is offloaded to a WiFi AP that is using a congested channel owing to the WiFi devices around it, the user experience can be degraded dramatically.In this paper, we propose an offloading target selection scheme for reducing the channel load of a femtocell while ensuring QoS in terms of throughput. The proposed scheme makes the offloading decision only when the ongoing traffic of the offloading target UE in a femtocell can be carried via the WiFi AP without throughput degradation of the current traffic. For this, the proposed scheme estimates the available bandwidth of a WiFi AP using the channel busy/idle information collected from the WiFi AP. The available bandwidth depends on the link quality between the UE and the WiFi AP because the transmission rate at the PHY layer (PHY rate) of IEEE 802.11, which is the standard for WiFi devices, varies according to the link quality. To address this, we adopted a mechanism that verifies the link quality before offloading the data traffic to a WiFi AP from a femtocell. This mechanism prevents QoS degradation due to offloading. The following subsections describe the proposed target selection scheme in detail.


### 4.1. Available Bandwidth Estimation of a WiFi AP

In this subsection, we describe a model for the available bandwidth estimation of a WiFi AP. To begin, we define the available bandwidth as the maximum data rate that can be transmitted via a link between a newly associated station and a WiFi AP without hindering ongoing traffic. With the available bandwidth defined in this manner, we can predict whether the ongoing traffic of UEs via a femtocell can be accommodated via a WiFi connection without throughput degradation. Furthermore, if a UE, which has a lower traffic bandwidth than the available bandwidth, is offloaded to a WiFi AP, we ensure that current ongoing connections in the WiFi AP are not hindered owing to the offloaded traffic. In this paper, we select the offloading target UE and WiFi AP on the basis of an estimation of the available bandwidth of the WiFi AP to ensure QoS after offloading.Some existing works use probe packets to estimate the available bandwidth [22]. However, these schemes induce a probe packet overhead. In this paper, we utilize achannel loadmeasurement method, which is defined in the IEEE 802.11 standard [23], to estimate the available bandwidth of the WiFi AP without a probe packet overhead. In the standard, channel load is defined as the percentage of time the station sensed that the medium was busy, as indicated by the carrier sense mechanism. To calculate the channel load, we need the channel busy time and measurement duration; these two values can be obtained from the register of the WLAN card. From these two values, we can obtain the idle fraction (fIDLE) of the wireless channel that the WiFi AP uses currently as follows:(1)fIDLE=1-Channel Busy TimeMeasurement Druration.UsingfIDLE, we can compute an available bandwidth on the basis of the data frame transmission time. In the IEEE 802.11 standard, the transmission time Ttx of a unicast data frame is expressed as follows:(2)Ttx=Tdifs+Tbackoff+Tdata+Tsifs+Tack,where Tdifs is the waiting time before the data frame transmission, Tbackoff is the random backoff time, Tdata is the data frame transmission time, Tsifs is the waiting time before the ACK frame transmission, and Tack is the ACK frame transmission time.In (2), Tdifs and Tsifs are constant and depend on the physical layer (PHY) specifications. The number of backoff slots at the initial data transmission attempt is randomly selected within the range of [0, CWmin], and the range is increased exponentially when the transmission fails, as defined in the IEEE 802.11 standard. We compute the average backoff time Tbackoff by multiplying the slot time (Tslot) by CWmin/2 because we cannot know the probability of a transmission failure, which is needed for considering the exponential backoff mechanism, before the actual transmission. The data and ACK frame, as the MAC sublayer protocol data unit (MPDU), are converted to the physical layer convergence procedure protocol data unit (PPDU) for transmission. The PPDU is composed of a PLCP preamble, a PHY header, and the MPDU. Equation (3) is the simplified equation for the PPDU transmission time TPPDU, defined in the IEEE 802.11a standard. As indicated in (3), TPPDU is the sum of the preamble of a transmission time Tpre, the signal transmission time Tsig, the OFDM symbol time Tsym, and the data (a part of the PHY header, MPDU, and checksum) transmission time. From (3), Tdata and Tack can be expressed as (4) and (5), respectively. (3)TPPDU=Tpre+Tsig+Tsym2+16+8∗LMPDU+6RPHY rate,(4)Tdata=Tpre+Tsig+Tsym2+16+8∗Ldata+6R,(5)Tack=Tpre+Tsig+Tsym2+16+8∗Lack+6R.In (4), the data transmission time varies depending on the PHY rate used and packet length. In the IEEE 802.11 PHY layer, multiple PHY rates that use different modulation and coding schemes (MCS) are defined to utilize wireless resources efficiently. The maximum PHY rate that is available for data transmission varies according to the wireless channel condition. Because the ACK packet length is fixed, Tack depends on the PHY rate only. Therefore, the unicast frame transmission time Ttx can be expressed as a function of PHY rate R and data packet length Ldata, as shown in (6). From (6), we can compute the transmission time of a single frame. If the wireless channel is completely idle, 1/Ttx frames can be transmitted per second. Thus, using the channel’s idle fraction fIDLE, we can estimate an available bandwidth, as illustrated in (7). Table 1 shows the default values for IEEE 802.11a used in our experiments.(6)TtxR,Ldata=Tdifs+Tbackoff+TdataR,Ldata+Tsifs+TackR,(7)AvailBWAPR,Ldata=8Ldata1TtxR,LdatafIDLE.Table 1 Symbol Default value Description T p r e 16μs PLCP preamble duration T s i g 4μs PHY signal symbol duration T s y m 4μs OFDM symbol duration T s l o t 9μs MAC layer slot duration T d i f s 34μs DIFS duration T s i f s 16μs SIFS duration C W m i n 15 Minimum contention window


### 4.2. Association Control Mechanism

In the proposed femtocell-to-WiFi offloading system, we estimate an available bandwidth between a candidate UE and a WiFi AP before deciding the offloading. As mentioned in the previous subsection, to estimate an available bandwidth between a new client and the WiFi AP, we need the average packet length and PHY rate. We can obtain the average packet length of a candidate UE’s traffic via the femtocell from traffic statistics on the SDN switch. However, we cannot know the PHY rate, which varies according to channel condition, before the WiFi AP transmits data packets to the candidate UE after the association.However, given the average packet length and current traffic bandwidth of a candidate UE for offloading, we can compute a minimum PHY rateRmin, which is required to transmit the current traffic of a candidate UE via the WiFi AP without throughput degradation, using (7). In other words, we know that the current traffic of the UE via the femtocell can be transmitted through the WiFi AP without throughput degradation if PHY rate Rmin is available for transmission via a link between the WiFi AP and the candidate UE.In this paper, we adopt an association control mechanism to test a link between a candidate UE and a WiFi AP before changing the data path for offloading. The WiFi client and AP have to exchange a series of 802.11 management frames to obtain an authenticated and associated state before the data transmission. The proposed association control mechanism allows the WiFi AP to send the management frames with theRmin PHY rate to associate with the candidate UE. During this process, the WiFi AP verifies that the connection is established without any management frame loss and retry. If the association process is not performed normally, we consider that this link between the candidate UE and the WiFi AP is not able to transmit/receive data with the Rmin PHY rate. In this case, we select another UE or WiFi AP as a candidate and then restart the offloading process. Through this association control mechanism, we can prevent an offloaded UE from throughput degradation due to a lower link quality than expected.


### 4.3. Offloading Procedure and Target Selection

On the basis of the available bandwidth estimation and association control mechanism described in the previous subsection, Figure3 illustrates the flowchart for the offloading procedure.Figure 3
Flowchart for offloading decision.To begin, from the traffic statistics from the SDN switch, the SDN controller initiates the offloading preparation process when there are UEs with average traffic bandwidth above the predefined threshold. The threshold is used for preventing a UE with very low traffic bandwidth from offloading to the WiFi because the benefits from its offloading may be relatively low when considering the costs caused by offloading (e.g., control packet overhead and UE’s energy consumption caused by turning on the WLAN interface). The threshold is set to 2 Mbps, considering the overhead due to offloading in the proposed system. It is easily modified using the controller’s API according to the operator’s policy.As mentioned in Section3, for the offloading preparation process, a controller must send the MAC addresses of the candidate UEs to the WiFi APs and then instruct the UEs to activate the WiFi interface and scan the WiFi APs. During this process, the controller can obtain lists of pairs of UEs and connectable WiFi APs. The controller selects the optimal pair in the lists as a target for offloading and calculates Rmin for the target UE and WiFi AP. Then, the controller initiates the offloading procedure. During this step, the UE attempts to associate with the WiFi AP and the WiFi AP transmits the management frames with the Rmin PHY rate for association, according to the SDN controller’s command via an OpenFlow message. If the controller receives reports that the association is established successfully without management frame losses and retries, the controller modifies the flow table and packet processing rule in the SDN switch for seamless offloading. If the association fails, the controller selects the next optimal pairs as offloading targets for the offloading and restarts the association process for the corresponding pairs. Through these offloading procedures, we can prevent throughput degradation due to offloading.The algorithm used to select the optimal offloading target UE (UET) and WiFi AP (APT) in this paper is presented in Algorithm 1. First, we find a set of available offloading target pairs, denoted as Spair. As indicated in lines (2)–(5), we remove an offloading target pair {UEi,APj}, where the traffic bandwidth of UEi is greater than the available bandwidth of APj, assuming the wireless link quality between them is acceptable for transmission with the maximum PHY rate. Then, we identify the UE with the greatest traffic bandwidth in Spair and select the UE as the target UE (UET). After selecting UET, we identify a target AP (APT) in Spair. If there are multiple target APs available for offloading in Spair, we choose the AP that reported the greatest RSSI value during the UE scanning process as the target AP (APT). If UET failed to associate with APT, the candidates that are predicted to fail to associate with APT are removed. Then, the controller reselects the offloading target (lines (8)–(13)). With this target selection algorithm, we can offload the UE that has the maximum traffic bandwidth and should not experience throughput degradation after offloading.Algorithm 1:Offloading target selection algorithm.
Input: BW(UEi) = Traffic Bandwidth of UEi, L(UEi) = Average packet length of UEi R S S I U E i (APj) = reported RSSI value of UEi from APj R m a x = maximum transmission rate supported in PHY layer Output:{UET,APT} = Offloading Target Pair Offloading Target Selection (1)  Find offloading set of target pairs Spair {UEi,APj}∈Spair, where  UEi is able to associate with APj, (2)  for each pair {UEi,APj}∈Spair (3)   if(BW(UEi) > AvailBWAPj(Rmax,L(UEi))) (4)    Remove {UEi,APj} in Spair  end if (5)  end for (6)  UET← argmax(BW(UEi)) in Spair (7)  APT← argmax(RSSIUEj(APj)), where  UEi = UET in Spair (8)  if  UET failed to associate with APT (9)   for each pair {UEi,APj}∈SpairwhereUEi=UET (10)   if (AvailBWAPj(Rmax,L(UEi)) ≤ AvailBWAPT(Rmax,L(UEi))) (11)    Remove {UEi,APj} in Spair  end if (12) end for (13) Goto (6) (14) end if


## 4.1. Available Bandwidth Estimation of a WiFi AP

In this subsection, we describe a model for the available bandwidth estimation of a WiFi AP. To begin, we define the available bandwidth as the maximum data rate that can be transmitted via a link between a newly associated station and a WiFi AP without hindering ongoing traffic. With the available bandwidth defined in this manner, we can predict whether the ongoing traffic of UEs via a femtocell can be accommodated via a WiFi connection without throughput degradation. Furthermore, if a UE, which has a lower traffic bandwidth than the available bandwidth, is offloaded to a WiFi AP, we ensure that current ongoing connections in the WiFi AP are not hindered owing to the offloaded traffic. In this paper, we select the offloading target UE and WiFi AP on the basis of an estimation of the available bandwidth of the WiFi AP to ensure QoS after offloading.Some existing works use probe packets to estimate the available bandwidth [22]. However, these schemes induce a probe packet overhead. In this paper, we utilize achannel loadmeasurement method, which is defined in the IEEE 802.11 standard [23], to estimate the available bandwidth of the WiFi AP without a probe packet overhead. In the standard, channel load is defined as the percentage of time the station sensed that the medium was busy, as indicated by the carrier sense mechanism. To calculate the channel load, we need the channel busy time and measurement duration; these two values can be obtained from the register of the WLAN card. From these two values, we can obtain the idle fraction (fIDLE) of the wireless channel that the WiFi AP uses currently as follows:(1)fIDLE=1-Channel Busy TimeMeasurement Druration.UsingfIDLE, we can compute an available bandwidth on the basis of the data frame transmission time. In the IEEE 802.11 standard, the transmission time Ttx of a unicast data frame is expressed as follows:(2)Ttx=Tdifs+Tbackoff+Tdata+Tsifs+Tack,where Tdifs is the waiting time before the data frame transmission, Tbackoff is the random backoff time, Tdata is the data frame transmission time, Tsifs is the waiting time before the ACK frame transmission, and Tack is the ACK frame transmission time.In (2), Tdifs and Tsifs are constant and depend on the physical layer (PHY) specifications. The number of backoff slots at the initial data transmission attempt is randomly selected within the range of [0, CWmin], and the range is increased exponentially when the transmission fails, as defined in the IEEE 802.11 standard. We compute the average backoff time Tbackoff by multiplying the slot time (Tslot) by CWmin/2 because we cannot know the probability of a transmission failure, which is needed for considering the exponential backoff mechanism, before the actual transmission. The data and ACK frame, as the MAC sublayer protocol data unit (MPDU), are converted to the physical layer convergence procedure protocol data unit (PPDU) for transmission. The PPDU is composed of a PLCP preamble, a PHY header, and the MPDU. Equation (3) is the simplified equation for the PPDU transmission time TPPDU, defined in the IEEE 802.11a standard. As indicated in (3), TPPDU is the sum of the preamble of a transmission time Tpre, the signal transmission time Tsig, the OFDM symbol time Tsym, and the data (a part of the PHY header, MPDU, and checksum) transmission time. From (3), Tdata and Tack can be expressed as (4) and (5), respectively. (3)TPPDU=Tpre+Tsig+Tsym2+16+8∗LMPDU+6RPHY rate,(4)Tdata=Tpre+Tsig+Tsym2+16+8∗Ldata+6R,(5)Tack=Tpre+Tsig+Tsym2+16+8∗Lack+6R.In (4), the data transmission time varies depending on the PHY rate used and packet length. In the IEEE 802.11 PHY layer, multiple PHY rates that use different modulation and coding schemes (MCS) are defined to utilize wireless resources efficiently. The maximum PHY rate that is available for data transmission varies according to the wireless channel condition. Because the ACK packet length is fixed, Tack depends on the PHY rate only. Therefore, the unicast frame transmission time Ttx can be expressed as a function of PHY rate R and data packet length Ldata, as shown in (6). From (6), we can compute the transmission time of a single frame. If the wireless channel is completely idle, 1/Ttx frames can be transmitted per second. Thus, using the channel’s idle fraction fIDLE, we can estimate an available bandwidth, as illustrated in (7). Table 1 shows the default values for IEEE 802.11a used in our experiments.(6)TtxR,Ldata=Tdifs+Tbackoff+TdataR,Ldata+Tsifs+TackR,(7)AvailBWAPR,Ldata=8Ldata1TtxR,LdatafIDLE.Table 1 Symbol Default value Description T p r e 16μs PLCP preamble duration T s i g 4μs PHY signal symbol duration T s y m 4μs OFDM symbol duration T s l o t 9μs MAC layer slot duration T d i f s 34μs DIFS duration T s i f s 16μs SIFS duration C W m i n 15 Minimum contention window


## 4.2. Association Control Mechanism

In the proposed femtocell-to-WiFi offloading system, we estimate an available bandwidth between a candidate UE and a WiFi AP before deciding the offloading. As mentioned in the previous subsection, to estimate an available bandwidth between a new client and the WiFi AP, we need the average packet length and PHY rate. We can obtain the average packet length of a candidate UE’s traffic via the femtocell from traffic statistics on the SDN switch. However, we cannot know the PHY rate, which varies according to channel condition, before the WiFi AP transmits data packets to the candidate UE after the association.However, given the average packet length and current traffic bandwidth of a candidate UE for offloading, we can compute a minimum PHY rateRmin, which is required to transmit the current traffic of a candidate UE via the WiFi AP without throughput degradation, using (7). In other words, we know that the current traffic of the UE via the femtocell can be transmitted through the WiFi AP without throughput degradation if PHY rate Rmin is available for transmission via a link between the WiFi AP and the candidate UE.In this paper, we adopt an association control mechanism to test a link between a candidate UE and a WiFi AP before changing the data path for offloading. The WiFi client and AP have to exchange a series of 802.11 management frames to obtain an authenticated and associated state before the data transmission. The proposed association control mechanism allows the WiFi AP to send the management frames with theRmin PHY rate to associate with the candidate UE. During this process, the WiFi AP verifies that the connection is established without any management frame loss and retry. If the association process is not performed normally, we consider that this link between the candidate UE and the WiFi AP is not able to transmit/receive data with the Rmin PHY rate. In this case, we select another UE or WiFi AP as a candidate and then restart the offloading process. Through this association control mechanism, we can prevent an offloaded UE from throughput degradation due to a lower link quality than expected.


## 4.3. Offloading Procedure and Target Selection

On the basis of the available bandwidth estimation and association control mechanism described in the previous subsection, Figure3 illustrates the flowchart for the offloading procedure.Figure 3
Flowchart for offloading decision.To begin, from the traffic statistics from the SDN switch, the SDN controller initiates the offloading preparation process when there are UEs with average traffic bandwidth above the predefined threshold. The threshold is used for preventing a UE with very low traffic bandwidth from offloading to the WiFi because the benefits from its offloading may be relatively low when considering the costs caused by offloading (e.g., control packet overhead and UE’s energy consumption caused by turning on the WLAN interface). The threshold is set to 2 Mbps, considering the overhead due to offloading in the proposed system. It is easily modified using the controller’s API according to the operator’s policy.As mentioned in Section3, for the offloading preparation process, a controller must send the MAC addresses of the candidate UEs to the WiFi APs and then instruct the UEs to activate the WiFi interface and scan the WiFi APs. During this process, the controller can obtain lists of pairs of UEs and connectable WiFi APs. The controller selects the optimal pair in the lists as a target for offloading and calculates Rmin for the target UE and WiFi AP. Then, the controller initiates the offloading procedure. During this step, the UE attempts to associate with the WiFi AP and the WiFi AP transmits the management frames with the Rmin PHY rate for association, according to the SDN controller’s command via an OpenFlow message. If the controller receives reports that the association is established successfully without management frame losses and retries, the controller modifies the flow table and packet processing rule in the SDN switch for seamless offloading. If the association fails, the controller selects the next optimal pairs as offloading targets for the offloading and restarts the association process for the corresponding pairs. Through these offloading procedures, we can prevent throughput degradation due to offloading.The algorithm used to select the optimal offloading target UE (UET) and WiFi AP (APT) in this paper is presented in Algorithm 1. First, we find a set of available offloading target pairs, denoted as Spair. As indicated in lines (2)–(5), we remove an offloading target pair {UEi,APj}, where the traffic bandwidth of UEi is greater than the available bandwidth of APj, assuming the wireless link quality between them is acceptable for transmission with the maximum PHY rate. Then, we identify the UE with the greatest traffic bandwidth in Spair and select the UE as the target UE (UET). After selecting UET, we identify a target AP (APT) in Spair. If there are multiple target APs available for offloading in Spair, we choose the AP that reported the greatest RSSI value during the UE scanning process as the target AP (APT). If UET failed to associate with APT, the candidates that are predicted to fail to associate with APT are removed. Then, the controller reselects the offloading target (lines (8)–(13)). With this target selection algorithm, we can offload the UE that has the maximum traffic bandwidth and should not experience throughput degradation after offloading.Algorithm 1:Offloading target selection algorithm.
Input: BW(UEi) = Traffic Bandwidth of UEi, L(UEi) = Average packet length of UEi R S S I U E i (APj) = reported RSSI value of UEi from APj R m a x = maximum transmission rate supported in PHY layer Output:{UET,APT} = Offloading Target Pair Offloading Target Selection (1)  Find offloading set of target pairs Spair {UEi,APj}∈Spair, where  UEi is able to associate with APj, (2)  for each pair {UEi,APj}∈Spair (3)   if(BW(UEi) > AvailBWAPj(Rmax,L(UEi))) (4)    Remove {UEi,APj} in Spair  end if (5)  end for (6)  UET← argmax(BW(UEi)) in Spair (7)  APT← argmax(RSSIUEj(APj)), where  UEi = UET in Spair (8)  if  UET failed to associate with APT (9)   for each pair {UEi,APj}∈SpairwhereUEi=UET (10)   if (AvailBWAPj(Rmax,L(UEi)) ≤ AvailBWAPT(Rmax,L(UEi))) (11)    Remove {UEi,APj} in Spair  end if (12) end for (13) Goto (6) (14) end if


## 5. Performance Evaluation and Result Analysis

### 5.1. Experimental System

Figure4 shows the structure of the experimental system for the femtocell-to-WiFi offloading. The experimental system consisted of an Android smartphone, LTE femtocell, EPC emulator for 4G wireless network access, WiFi AP for providing wireless local network access, SDN switch, and SDN controller for adaptive packet routing.Figure 4
The experimental system.The SDN controller, which conformed to the OpenFlow 1.3 specifications, was implemented by porting an open source MUL [24] controller on a Linux machine. The SDN switch was a commercial SDN switch with a number of 10 G ports. The Android smartphone was a Samsung Galaxy S3 equipped with the Android Jelly Bean 4.1.2 operating system. The OpenFlow agent software, which was required for interworking with the SDN controller, was installed on the Android smartphone in the form of application software. The WiFi AP, which equips the IEEE 802.11a WLAN card, ran on OpenWRT. On the WiFi AP, the OpenFlow agent software was additionally ported. The femtocell was an LTE femtocell conforming to the 3GPP Release 8 specifications. The EPC emulator, instead of a commercial EPC, provided signaling and data switching services to the femtocell. This system was also implemented on a Linux server.In the experimental system, we emulated the entrance and departure of terminals by switching the power button of the smartphones. In this system, a standalone femtocell ran without any interaction with the other LTE femtocells and macrocells, and, therefore, a handover situation could not be generated. However, we believe that this was sufficient for validating the proposed offloading scheme.


### 5.2. Seamless Connectivity Test

First, we performed experiments to demonstrate that the proposed system could provide seamless connectivity during the offloading. For this experiment, one UE was connected to a femtocell and received a video streaming service using TCP. Then, we manually offloaded the UE to the WiFi AP using the controller’s API. We again moved the UE to the femtocell from the WiFi AP after 20 s. Figure5 shows the result of the experiment. As shown in this figure, no idle period appears even in the onloading and offloading timings because the UE can maintain existing flows without a TCP session reestablishment during the offloading in the proposed system.Figure 5
Result of the WiFi offloading and onloading of a video streaming service.


### 5.3. Accuracy of the Available Bandwidth Estimation

We performed an experiment to evaluate the accuracy of the available bandwidth estimation scheme used in the offloading target decision. For this experiment, two UEs were connected to one WiFi AP, which was operating on the 5 GHz band. Moreover, the two UEs and the WiFi AP were close to each other to allow transmission traffic without channel loss. One UE generated UDP traffic at a constant rate to the AP as the background traffic using the Iperf tool [25]. To estimate the real available bandwidth in the experiment, the AP generated UDP traffic to the other UE. We increased the traffic of the AP gradually until the background UDP traffic and AP’s traffic began to lose owing to channel saturation. In this manner, we measured the maximum rate of the AP’s UDP traffic that did not hinder the ongoing background traffic. For the evaluation of the estimation scheme, when there was a background traffic only, the WiFi AP computed the available bandwidth using the idle fraction of the wireless channel, fIDLE, which was obtained from its WLAN card register.In Figure6, we compared the real available bandwidth, denoted asReal, with the estimation computed at the AP using the WLAN card register values only, denoted asResister only. As indicated in the figure, we observed that there was a gap betweenReal andRegister only. In particular, we observed that the gap increased as the background traffic increased. The reason for this is that the idle fraction fIDLE, which is computed using the values from the register, does not reflect the periods required essentially for unicast frame transmission, such as Tdifs, Tsifs, and Tbackoff, as indicated in (2). To account for this, we added Tdifs, Tsifs, and Tbackoff to fIDLE as a busy period for each unicast frame overheard by the WLAN card. In Figure 6, we plotted the experimental result of the available bandwidth estimation, which was computed on the basis of the adjusted fIDLE, asAdjustment. The available bandwidth estimation scheme tended to overestimate the available bandwidth compared to the actual one. This was because the model-based estimation scheme is a theoretical maximum bandwidth; therefore, it does not reflect the wireless error and hardware-dependent times such as the transition time between the RX and the TX states. However, the overestimation tendency was removed easily by adding the redundancy value when comparing the ongoing traffic bandwidth of the UE with the estimated available bandwidth. From the results in Figure 6, we can see that the available bandwidth estimation based on adjusted fIDLE shows an acceptable accuracy within 2 Mbps. Considering the overestimation tendency, we added a redundancy value when comparing the available bandwidth with the UE’s ongoing traffic at the controller.Figure 6
Accuracy of the available bandwidth estimation.


### 5.4. Effects of the Association Control Mechanism of the Proposed Offloading Scheme

Next, we performed an experiment to evaluate the effects of the association control mechanism of the proposed offloading scheme. For this experiment, one UE was connected to a femtocell and the traffic server generated the downlink UDP traffic to the UE at a constant data rate. Additionally, we generated a background traffic to the WiFi AP using a laptop. In the repeated experiments, the data rate of the UDP traffic to the UE was selected randomly between 5 and 20 Mbps, and the location of the UE was changed to vary the link quality of the UE and WiFi AP. The laptop also generated a background traffic with a constant data rate between 1 and 10 Mbps. For comparison, we disabled the association control mechanism and performed the same experiments.Figure7 shows the average throughput and loss rate measured at the UE. As we mentioned in Section 4.2, the association control mechanism checks the link quality using management frames during the WLAN association procedures; thus, it can prevent a UE, which is expected to experience throughput degradation due to low link quality, from offloading to a WiFi AP. We observed that the proposed scheme with the association control mechanism did not incur throughput degradation due to the offloading in most cases; thus, it showed very low loss rate, as shown in Figure 7. On the other hand, we observed that the proposed scheme without the association control mechanism incurred considerable throughput degradation and data frame losses due to the offloading in some cases, although it decided to offload the UE traffic to the WiFi by considering the available bandwidth.Figure 7
Result of the WiFi offloading with/without the association control mechanism.


### 5.5. Performance Comparison of the Offloading Target Selection Scheme

We performed the following experiments to evaluate the proposed offloading target selection scheme, which is based on the available bandwidth estimation and association control mechanism (AVAC), in the cases where there existed multiple target UEs available for offloading. For these experiments, four UEs connected to the femtocell and the traffic server generated a downlink UDP traffic to each UE at a constant data rate. The data rate of each UDP traffic was selected randomly between 5 and 20 Mbps. We adjusted the distance between each UE and the WiFi AP to ensure that each link between them had a different quality. The other experiment environments were the same as in the previous experiments. We performed experiments in 20 scenarios with different data rates for each UDP traffic.We compared the proposed scheme with the following target selection schemes: (1) offloading target selection based on the highest RSSI value, which was collected during the scanning process (RSSI). This scheme offloads a UE with the best link quality to a WiFi AP. We let this scheme offload only one UE to a WiFi AP in these experiments; otherwise, this scheme offloads all UEs to a WiFi AP because it does not consider the load of the AP; (2) offloading target selection based on available bandwidth estimation (available). This scheme is the same as the proposed scheme without the association control mechanism; thus, it assumes that the link between a UE and a WiFi AP is good enough to transmit/receive at the maximum PHY rate.In Figure8, we plotted the average traffic bandwidth offloaded via the WiFi AP according to the offloading target selection. The RSSI-based offloading target selection scheme demonstrated the lowest performance in the scenarios with low background traffic (1–5 Mbps) because it did not account for the UE’s traffic bandwidth; thus, it selected UEs with low traffic bandwidth as the offloading target in some scenarios. The available bandwidth-based offloading target selection indicated improved performance compared to the RSSI-based target selection in the low background traffic scenarios. The proposed scheme indicted superior performance in terms of the amount of traffic offloaded to a WiFi AP in the low background traffic scenarios. On average, the proposed offloading target selection scheme offloaded 28% more traffic to the WiFi AP than the RSSI-based offloading target selection scheme in the low background traffic scenarios.Figure 8
Average traffic bandwidth offloaded to WiFi.All schemes demonstrated similar results in the scenarios with high background traffic (6–10 Mbps). This is because the RSSI-based and the available bandwidth-based offloading target selection schemes offloaded a UE that can receive more traffic via WiFi AP than the proposed scheme in some scenarios, although it incurred performance degradation due to offloading. To explain this, in Figure9, we plotted the throughput maintenance ratio, which is the received traffic throughput of the offloaded UE after offloading to the WiFi AP divided by the received traffic throughput before the offloading. Thus, if all the traffic of the offloaded UE is accommodated via the WiFi after offloading, the value of the throughput maintenance ratio is 1. As shown in Figure 9, the average throughput maintenance ratio of the proposed scheme in the experiment scenarios is 0.97. Thus, the majority of the UEs selected as the offloading target in the proposed target selection scheme in each scenario did not experience throughput degradation due to offloading. However, the RSSI-based and the available bandwidth-based offloading target selection schemes demonstrated a lower throughput maintenance ratio on average than the proposed scheme. In particular, we observed that the available bandwidth-based target selection schemes decreased the UE’s traffic bandwidth by 60% in a specific scenario. The RSSI-based offloading target selection scheme indicated better throughput maintenance ratio compared to the available bandwidth-based offloading target selection schemes; however, it also decreased the UE’s traffic bandwidth by 50% in a specific scenario. From the results indicated in Figures 8 and 9, we observed that the proposed target selection scheme reduced the femtocell load, which causes interference to the macrocell, without QoS reduction in terms of throughput in various scenarios.Figure 9
Throughput maintenance ratio.In Figure10, we plotted the average delay, which is one of the important QoS parameters, for an offloaded UE. The proposed scheme indicated a lower delay on average compared to the other schemes because it did not experience the condition where the wireless channel was saturated owing to the offloaded traffic. However, the RSSI-based and the available bandwidth-based offloading target selection schemes increased the delay of the offloaded UE significantly in the specific scenarios owing to wireless channel saturation caused by the offloaded traffic. Thus, the average delay of all experiments using the RSSI-based and the available bandwidth-based target selection schemes was relatively high compared to that using the proposed scheme.Figure 10
Average delay after offloading.Furthermore, we performed experiments where there existed two WiFi APs available for offloading. For these experiments, we installed two WiFi APs, which operated on a different channel. We installed two laptops for generating the background traffic to each WiFi AP. The other experimental configuration factors were the same as in the previous experiments. For the comparison, we let the RSSI-based offloading target selection scheme offload two UEs to the WiFi AP in these experiments.In Figure11, we plotted the average traffic bandwidth offloaded to the WiFi and the throughput maintenance ratio in this experimental scenario. Intuitively, if there exist more APs available for offloading, more traffic on femtocell can be offloaded to the WiFi APs. As shown in Figure 11, the average traffic bandwidth offloaded to the WiFi APs was significantly increased compared to that in the previous experiment. Through these experiments, we observed that the proposed scheme also showed better performance than the other schemes in the situation where there were multiple WiFi APs and UEs available for offloading. In particular, we observed that the proposed schemes reduced the femtocell load by up to 46% without QoS reduction in terms of throughput.Figure 11
Average traffic bandwidth offloaded to the WiFi AP and throughput maintenance ratio where there are two APs available for offloading.


### 5.6. Control Overhead

Finally, we measured the control overhead of the proposed system. As mentioned previously, the SDN controller gathers information from the SDN equipment and sends commands to them using an OpenFlow message so that it puts the SDN equipment under its control and maintains a centralized view of the network. To demonstrate the control overhead for the proposed system, we measured the OpenFlow message overhead during the experiment performed in Section5.2. As shown in Figure 12, the SDN switch incurred the highest overhead for the centralized control because the SDN controller gathered the most status information from it including flow statistics for the UE and routing table status. The WiFi AP had the next highest overhead because it sent its wireless channel status and its client information to the controller every second. The femtocell had a lower overhead compared to the WiFi AP because it reported only events such as UE entrance and leave to the controller except keep-alive messages (e.g., echo request/reply). Considering that these messages were transmitted via a wired line using the Ethernet port, the overhead for the centralized control was small (e.g., the sum was approximately 560 bytes per second). However, because the control messages of the UE were sent over a wireless link, we minimized this message overhead by defining a longer period for the keep-alive messages of the UE. Thus, we observed that the UE had the lowest control overhead and incurred an overhead of only 14 bytes per seconds.Figure 12
OpenFlow message overhead for SDN-based control.


## 5.1. Experimental System

Figure4 shows the structure of the experimental system for the femtocell-to-WiFi offloading. The experimental system consisted of an Android smartphone, LTE femtocell, EPC emulator for 4G wireless network access, WiFi AP for providing wireless local network access, SDN switch, and SDN controller for adaptive packet routing.Figure 4
The experimental system.The SDN controller, which conformed to the OpenFlow 1.3 specifications, was implemented by porting an open source MUL [24] controller on a Linux machine. The SDN switch was a commercial SDN switch with a number of 10 G ports. The Android smartphone was a Samsung Galaxy S3 equipped with the Android Jelly Bean 4.1.2 operating system. The OpenFlow agent software, which was required for interworking with the SDN controller, was installed on the Android smartphone in the form of application software. The WiFi AP, which equips the IEEE 802.11a WLAN card, ran on OpenWRT. On the WiFi AP, the OpenFlow agent software was additionally ported. The femtocell was an LTE femtocell conforming to the 3GPP Release 8 specifications. The EPC emulator, instead of a commercial EPC, provided signaling and data switching services to the femtocell. This system was also implemented on a Linux server.In the experimental system, we emulated the entrance and departure of terminals by switching the power button of the smartphones. In this system, a standalone femtocell ran without any interaction with the other LTE femtocells and macrocells, and, therefore, a handover situation could not be generated. However, we believe that this was sufficient for validating the proposed offloading scheme.


## 5.2. Seamless Connectivity Test

First, we performed experiments to demonstrate that the proposed system could provide seamless connectivity during the offloading. For this experiment, one UE was connected to a femtocell and received a video streaming service using TCP. Then, we manually offloaded the UE to the WiFi AP using the controller’s API. We again moved the UE to the femtocell from the WiFi AP after 20 s. Figure5 shows the result of the experiment. As shown in this figure, no idle period appears even in the onloading and offloading timings because the UE can maintain existing flows without a TCP session reestablishment during the offloading in the proposed system.Figure 5
Result of the WiFi offloading and onloading of a video streaming service.


## 5.3. Accuracy of the Available Bandwidth Estimation

We performed an experiment to evaluate the accuracy of the available bandwidth estimation scheme used in the offloading target decision. For this experiment, two UEs were connected to one WiFi AP, which was operating on the 5 GHz band. Moreover, the two UEs and the WiFi AP were close to each other to allow transmission traffic without channel loss. One UE generated UDP traffic at a constant rate to the AP as the background traffic using the Iperf tool [25]. To estimate the real available bandwidth in the experiment, the AP generated UDP traffic to the other UE. We increased the traffic of the AP gradually until the background UDP traffic and AP’s traffic began to lose owing to channel saturation. In this manner, we measured the maximum rate of the AP’s UDP traffic that did not hinder the ongoing background traffic. For the evaluation of the estimation scheme, when there was a background traffic only, the WiFi AP computed the available bandwidth using the idle fraction of the wireless channel, fIDLE, which was obtained from its WLAN card register.In Figure6, we compared the real available bandwidth, denoted asReal, with the estimation computed at the AP using the WLAN card register values only, denoted asResister only. As indicated in the figure, we observed that there was a gap betweenReal andRegister only. In particular, we observed that the gap increased as the background traffic increased. The reason for this is that the idle fraction fIDLE, which is computed using the values from the register, does not reflect the periods required essentially for unicast frame transmission, such as Tdifs, Tsifs, and Tbackoff, as indicated in (2). To account for this, we added Tdifs, Tsifs, and Tbackoff to fIDLE as a busy period for each unicast frame overheard by the WLAN card. In Figure 6, we plotted the experimental result of the available bandwidth estimation, which was computed on the basis of the adjusted fIDLE, asAdjustment. The available bandwidth estimation scheme tended to overestimate the available bandwidth compared to the actual one. This was because the model-based estimation scheme is a theoretical maximum bandwidth; therefore, it does not reflect the wireless error and hardware-dependent times such as the transition time between the RX and the TX states. However, the overestimation tendency was removed easily by adding the redundancy value when comparing the ongoing traffic bandwidth of the UE with the estimated available bandwidth. From the results in Figure 6, we can see that the available bandwidth estimation based on adjusted fIDLE shows an acceptable accuracy within 2 Mbps. Considering the overestimation tendency, we added a redundancy value when comparing the available bandwidth with the UE’s ongoing traffic at the controller.Figure 6
Accuracy of the available bandwidth estimation.


## 5.4. Effects of the Association Control Mechanism of the Proposed Offloading Scheme

Next, we performed an experiment to evaluate the effects of the association control mechanism of the proposed offloading scheme. For this experiment, one UE was connected to a femtocell and the traffic server generated the downlink UDP traffic to the UE at a constant data rate. Additionally, we generated a background traffic to the WiFi AP using a laptop. In the repeated experiments, the data rate of the UDP traffic to the UE was selected randomly between 5 and 20 Mbps, and the location of the UE was changed to vary the link quality of the UE and WiFi AP. The laptop also generated a background traffic with a constant data rate between 1 and 10 Mbps. For comparison, we disabled the association control mechanism and performed the same experiments.Figure7 shows the average throughput and loss rate measured at the UE. As we mentioned in Section 4.2, the association control mechanism checks the link quality using management frames during the WLAN association procedures; thus, it can prevent a UE, which is expected to experience throughput degradation due to low link quality, from offloading to a WiFi AP. We observed that the proposed scheme with the association control mechanism did not incur throughput degradation due to the offloading in most cases; thus, it showed very low loss rate, as shown in Figure 7. On the other hand, we observed that the proposed scheme without the association control mechanism incurred considerable throughput degradation and data frame losses due to the offloading in some cases, although it decided to offload the UE traffic to the WiFi by considering the available bandwidth.Figure 7
Result of the WiFi offloading with/without the association control mechanism.


## 5.5. Performance Comparison of the Offloading Target Selection Scheme

We performed the following experiments to evaluate the proposed offloading target selection scheme, which is based on the available bandwidth estimation and association control mechanism (AVAC), in the cases where there existed multiple target UEs available for offloading. For these experiments, four UEs connected to the femtocell and the traffic server generated a downlink UDP traffic to each UE at a constant data rate. The data rate of each UDP traffic was selected randomly between 5 and 20 Mbps. We adjusted the distance between each UE and the WiFi AP to ensure that each link between them had a different quality. The other experiment environments were the same as in the previous experiments. We performed experiments in 20 scenarios with different data rates for each UDP traffic.We compared the proposed scheme with the following target selection schemes: (1) offloading target selection based on the highest RSSI value, which was collected during the scanning process (RSSI). This scheme offloads a UE with the best link quality to a WiFi AP. We let this scheme offload only one UE to a WiFi AP in these experiments; otherwise, this scheme offloads all UEs to a WiFi AP because it does not consider the load of the AP; (2) offloading target selection based on available bandwidth estimation (available). This scheme is the same as the proposed scheme without the association control mechanism; thus, it assumes that the link between a UE and a WiFi AP is good enough to transmit/receive at the maximum PHY rate.In Figure8, we plotted the average traffic bandwidth offloaded via the WiFi AP according to the offloading target selection. The RSSI-based offloading target selection scheme demonstrated the lowest performance in the scenarios with low background traffic (1–5 Mbps) because it did not account for the UE’s traffic bandwidth; thus, it selected UEs with low traffic bandwidth as the offloading target in some scenarios. The available bandwidth-based offloading target selection indicated improved performance compared to the RSSI-based target selection in the low background traffic scenarios. The proposed scheme indicted superior performance in terms of the amount of traffic offloaded to a WiFi AP in the low background traffic scenarios. On average, the proposed offloading target selection scheme offloaded 28% more traffic to the WiFi AP than the RSSI-based offloading target selection scheme in the low background traffic scenarios.Figure 8
Average traffic bandwidth offloaded to WiFi.All schemes demonstrated similar results in the scenarios with high background traffic (6–10 Mbps). This is because the RSSI-based and the available bandwidth-based offloading target selection schemes offloaded a UE that can receive more traffic via WiFi AP than the proposed scheme in some scenarios, although it incurred performance degradation due to offloading. To explain this, in Figure9, we plotted the throughput maintenance ratio, which is the received traffic throughput of the offloaded UE after offloading to the WiFi AP divided by the received traffic throughput before the offloading. Thus, if all the traffic of the offloaded UE is accommodated via the WiFi after offloading, the value of the throughput maintenance ratio is 1. As shown in Figure 9, the average throughput maintenance ratio of the proposed scheme in the experiment scenarios is 0.97. Thus, the majority of the UEs selected as the offloading target in the proposed target selection scheme in each scenario did not experience throughput degradation due to offloading. However, the RSSI-based and the available bandwidth-based offloading target selection schemes demonstrated a lower throughput maintenance ratio on average than the proposed scheme. In particular, we observed that the available bandwidth-based target selection schemes decreased the UE’s traffic bandwidth by 60% in a specific scenario. The RSSI-based offloading target selection scheme indicated better throughput maintenance ratio compared to the available bandwidth-based offloading target selection schemes; however, it also decreased the UE’s traffic bandwidth by 50% in a specific scenario. From the results indicated in Figures 8 and 9, we observed that the proposed target selection scheme reduced the femtocell load, which causes interference to the macrocell, without QoS reduction in terms of throughput in various scenarios.Figure 9
Throughput maintenance ratio.In Figure10, we plotted the average delay, which is one of the important QoS parameters, for an offloaded UE. The proposed scheme indicated a lower delay on average compared to the other schemes because it did not experience the condition where the wireless channel was saturated owing to the offloaded traffic. However, the RSSI-based and the available bandwidth-based offloading target selection schemes increased the delay of the offloaded UE significantly in the specific scenarios owing to wireless channel saturation caused by the offloaded traffic. Thus, the average delay of all experiments using the RSSI-based and the available bandwidth-based target selection schemes was relatively high compared to that using the proposed scheme.Figure 10
Average delay after offloading.Furthermore, we performed experiments where there existed two WiFi APs available for offloading. For these experiments, we installed two WiFi APs, which operated on a different channel. We installed two laptops for generating the background traffic to each WiFi AP. The other experimental configuration factors were the same as in the previous experiments. For the comparison, we let the RSSI-based offloading target selection scheme offload two UEs to the WiFi AP in these experiments.In Figure11, we plotted the average traffic bandwidth offloaded to the WiFi and the throughput maintenance ratio in this experimental scenario. Intuitively, if there exist more APs available for offloading, more traffic on femtocell can be offloaded to the WiFi APs. As shown in Figure 11, the average traffic bandwidth offloaded to the WiFi APs was significantly increased compared to that in the previous experiment. Through these experiments, we observed that the proposed scheme also showed better performance than the other schemes in the situation where there were multiple WiFi APs and UEs available for offloading. In particular, we observed that the proposed schemes reduced the femtocell load by up to 46% without QoS reduction in terms of throughput.Figure 11
Average traffic bandwidth offloaded to the WiFi AP and throughput maintenance ratio where there are two APs available for offloading.


## 5.6. Control Overhead

Finally, we measured the control overhead of the proposed system. As mentioned previously, the SDN controller gathers information from the SDN equipment and sends commands to them using an OpenFlow message so that it puts the SDN equipment under its control and maintains a centralized view of the network. To demonstrate the control overhead for the proposed system, we measured the OpenFlow message overhead during the experiment performed in Section5.2. As shown in Figure 12, the SDN switch incurred the highest overhead for the centralized control because the SDN controller gathered the most status information from it including flow statistics for the UE and routing table status. The WiFi AP had the next highest overhead because it sent its wireless channel status and its client information to the controller every second. The femtocell had a lower overhead compared to the WiFi AP because it reported only events such as UE entrance and leave to the controller except keep-alive messages (e.g., echo request/reply). Considering that these messages were transmitted via a wired line using the Ethernet port, the overhead for the centralized control was small (e.g., the sum was approximately 560 bytes per second). However, because the control messages of the UE were sent over a wireless link, we minimized this message overhead by defining a longer period for the keep-alive messages of the UE. Thus, we observed that the UE had the lowest control overhead and incurred an overhead of only 14 bytes per seconds.Figure 12
OpenFlow message overhead for SDN-based control.


## 6. Conclusion and Future Work

In this paper, we designed a novel femtocell-to-WiFi offloading system to reduce the femtocell load, which incurs interference to a macrocell. The proposed system utilizes the property of the femtocell, wherein data traffic to the operator’s core network is transmitted via the user’s broadband network, and the advantage of the femtocell, which provides seamless connectivity. Furthermore, we proposed an offloading target selection scheme based on available bandwidth estimation and an association control mechanism. We built a femtocell-to-WiFi offloading system to validate the feasibility of the proposed system and offloading target selection schemes utilizing SDN technology. Experimental results on an actual testbed showed that the proposed offloading scheme provided seamless connectivity and reduced the femtocell load by up to 46% with the aid of the proposed target selection scheme while ensuring QoS after offloading. We also observed that the proposed target selection scheme offloaded 28% more traffic to WiFi networks compared to the RSSI-based target selection in the low background traffic environment.In the future, we plan to study the power consumption issues to enhance the efficiency of the offloading system and the scalability issues for the large-scale deployment.



---

*Source: 5308949-2017-02-19.xml*