Adaptive Heterogeneous Network Handoff of Smartphone Based on the Closed Control Loop

Abstract

Owing to complementary characteristics of wireless networks, it is deserved to achieve automatic handoff on the modern smartphone for taking full exploitation of these accessible technologies. In this paper, we have proposed the closed loop model on smartphone switching heterogeneous wireless networks, which is full-client based without requiring additional support from the access points or gateways and modification of the network protocols. It only intuitively takes advantage of user scheme as the feedback adjustment approach to handoff policy. Furthermore, we have analyzed the closed loop handoff model to illustrate and evaluate how the user feedback of the policy acts on adapting to change context. In the experiment, we have evaluated four metrics on the closed loop handoff policy in real smartphone device: performance, energy saving, data offloading, and user experience.

1. Introduction

Contemporary smartphones with multiple air interfaces leave the choice of wireless networks selection to users. The characteristics and qualities of heterogeneous wireless networks vary greatly. Take for instance, cellular networks, for example, GPRS/WCDMA, provide nationwide coverage but with scarce cellular bandwidth and expensive spectrum cost, and WiFi offers limit coverage but with high bandwidth and low cost (often no cost). These unique characteristics make complementary action on the mobile device with multiple wireless interfaces. However, the state-of-art manual selection interfaces operation in the modern smartphone cannot take full exploitation of such complementary network characteristics. Furthermore, this manipulation not only brings about the inefficient and inconvenient usability of mobile devices but also leads to the interruption of ongoing network flows. In this paper, we focus on adaptive handoff policy to enable switching and aggregate heterogeneous wireless networks on smartphones.

The key issue of the modern smartphone that leaves the choice of air interface switch to users is about twofold aspect factors. On the one hand, the choice of the most suitable connectivity technology depends on a large variety of elements, from user preferences to application requirements and from network layer conditions to the physical layer status. However, dynamical information collection and sophisticated evaluation process are not suitable for smartphones with limit capacity and energy. Furthermore, along with the increment of the number and popularity of mobile apps, it is a challenge to handle various QoS of numerous apps. Take for instance, Android has mostly 400 K daily activations [1] and AppStore with 450 K apps has more than 10 billion [2]. On the other hand, switching air interfaces between different networks brings about existing network flow interrupting, data loss, and undesirable user experience, which involves turning off the current interface and activating another one. Existing works that attempt to eliminate the negative effect of switching network interface requiring either additional infrastructure or network support. For instance, mobility gateways [3, 4] were acted as a proxy between mobile devices and the Internet, and extending the TCP/IP protocol supported networks switching, such as the Mobile IP [5, 6]. However, these approaches cannot be immediately deployable and engineering projects cost extremely large and modify largely existing infrastructure and network protocol.

Note that previous research works lack a feedback from users as well as the ambient environment. Intuitively, such a feedback scheme can make applications adaptive to the changing contexts, which can reduce the distinct gap between network switching and network interruptions. In this paper, our general idea is to put this intuition into the interface switching policy and we have done some preliminary research in [7, 8]. We have proposed a novel feedback scheme that takes ambient information and user experiences into consideration. We demonstrate that, by using such a scheme, the gap between the handoff and user satisfaction can be significantly reduced.

The contribution of this paper is given as follows. We have proposed the adaptive heterogeneous wireless network handoff based on the closed control loop. The goal is to achieve the suitable time to select accessible points or the air interface, which eliminate the bad effect of interrupting ongoing network flows for improving user experience as far as possible. Furthermore, we have presented the closed loop handoff model to illustrate and evaluate how the user feedback of the policy acts on adapting to change context. To illustrate this intuition and closed loop model on the handoff policy, we have designed and implemented the prototype system, which does not require any changes to the existing network architecture or extending additional infrastructure. In addition, apps running transparently take automatic exploration of heterogeneous wireless networks in Android platform without considering compatible problems. In the experiment, we have evaluated four metrics on the closed loop handoff policy—performance, energy saving, data offloading, and user experience. And our analysis based on the third-party apps running in real smartphone (HTC G7) via collecting user experience data show that the closed loop handoff adapts various contexts.

The rest of this paper is organized as follows. In Section 2, we describe the background of selection heterogeneous wireless networks and show the motivation of our research on the handoff policy of smartphone. In Section 3, we present the closed loop handoff paradigm and analyze the user feedback model effect on the adaptive policy. In Section 4, we have designed and implemented the programmatic third-party application on Android platform. In Section 5, we have presented evaluation performance of this adaptive closed loop handoff in real smartphone. Finally, we discuss methods to further work enhance the closed loop handoff policy for increased performance and conclusion in Section 6.

2. Background

2.1. Smartphone Usage Characteristics

Modern smartphones are powerful enough to run modern operating systems and sophisticated network applications such as web browsing, email, and streaming media, for example, Android and iOS platform. Unlike traditional Internet-based applications in Personal Computer, the usage of smartphones [9–11] trends to include low UDP usage, high TCP usage, high volumes of HTTP traffic, and a great proportion of video traffic. The popular apps in Google play [1] and Apple store [2] are developed by specific Platform APIs. Understanding the apps usage custom and network requirements [12, 13] is important for our work to implement the adaptive handoff. Therefore, we have conducted real-life smartphone usage traces with five participants for lasting one week. The experiment has been executed on the machine HTC G7 (based on Android platform 2.3.3).

Our study on some broad characteristics of smartphone usage is shown in Figure 1. In our research, we have used the third-party software [14] that is capable of logging important information of the running applications within the smartphone and periodically sending it to a remote server. Five volunteers who already used Internet-ready smartphones were from our research lab. They used their phones as usual for one week while the service is running in background without disturbing users. The information that we collect from these logs include the names and types of the applications, the frequency, and the duration of their usage. For our analysis, we have chosen a number of different natural metrics that profile smartphone usage. As shown in Figure 1, we use the following three metrics through most of our analysis: (a) apps usage percentage defined as frequency and during time consumed by end-users; (b) traffic volume of apps, defined as the form cumulative function of the number of traffic data throughout our week-long data set; (c) access time off, defined as the total duration summed across all network flows generated by the apps over our week-long data set.

Figure 1

Smartphone apps usage statistics. (a) shows various apps usage percentage, (b) shows traffic volume of smartphone apps, and (c) shows accessible network time of smartphone apps.

In summary, we confirmed that the apps usage and network have distinct character differ from tradition PCs. And we also found that typical users have extensive experience when network disruptions happened, and they have even figured out the conditions in which they often occur. The successful solution for handoff should keep the balance between user experience and selection air interfaces, and we have done some preliminary research in [7]. These findings motivate the design of our handoff policy based on closed loop.

2.2. Related Work

The state-of-art handoff in smartphone was focused on networking layer factors and physical layer factors without considering application layer factor and user feedback factors. Switching among multiple network interfaces of a mobile device exploited a static priority order among available interfaces and considered dynamic data, often based on beacon frames [15–17]. Some work [15, 16] is primarily based on physical context information, that is, current RSSI of APs and the threshold for handover triggering. Differently, work [17] focus on a small set of physical-level parameters primarily considers power consumption and, secondarily, network conditions. Other solutions [18, 19] considered more expressive and complex dynamic context data. The measurements of throughput, channel utilization and frame loss rate are derived to determine the suitable network. However, these approaches that just make use of physical and network level information are unsuitable for the complicated context along with the increase of apps in the smartphone [1, 2]. Therefore, the networks selection choice approaches [16, 17] depending on low-level network information (e.g., signal strength) leaded to a distinct gap between the approaches behavior and user satisfaction. Furthermore, the more complex context gathering is, the more energy and compute overhead are needed, which conflict to the limitation of modern smartphones. We propose that the user feedback scheme has two advantages. First, the dynamic data collection would be calibrated by user feedback data. Second, the lack of complicated apps context also can be supplemented by user feedback data.

Switching among multiple network interfaces in the smartphone bring about the interruption of ongoing network flow. Therefore, there exists a body of research on providing continuity management between different networks. Mobile IP [20, 21] uses foreign/home agents to forward network traffic from/to the mobile device that move among access networks. This way not only may take years to be done but also incurs tremendous costs and burden via deploying mobile IP agents. Gateways [22, 23] between smartphones and the Internet can be another approach to eliminate the network interrupting. However, similar to the mobile IP, gateway solutions also require deploying cost and take a long time to be fulfilled. Different from this work, we proposed the closed loop approach, which is just based on the pragmatic client-end application in the Android platform without adding the support infrastructure or modifying network protocol. In addition, modern apps can run transparently on the smartphone without considering compatible problems.

3. The Closed Loop Handoff Model

Without infrastructure support or modifying existing network protocol, the client based solution on the smartphone that deals with the handoff problem has twofold aspects issues. On the one hand, along with sophisticated and changing apps emerging rapidly, the static statistic approaches are not suitable and the dynamically collection approaches conflict with the limitation of smartphones. On the other hand, finishing the old interface and activating the new interface would bring about the network flows interruption, which brings about bad user experience. In this section, we have proposed the closed loop handoff model, which take advantage of user feedback scheme as an important way in complementing various context gathering and selection evaluation process. Since WiFi and cellular accessible technologies are commonly available to modern mobile devices and complementary, we focus on these technologies in the closed loop model, but our approach is widely applicable across any set of access technologies and applications.

3.1. The Closed Loop Handoff Paradigm

Our proposed closed loop handoff paradigm is shown in Figure 2, which can be immediately deployed in the most mobile device without any revision. The paradigm is divided into two parts: the positive direction flow drawing the blue line and the feedback direction flow drawing the red line.

Figure 2

The heterogeneous wireless networks handoff paradigm.

As shown in Figure 2, the positive direction flow includes three parts; (1) low-level context acts as the input of interfaces handoff policy; (2) handoff evaluation process determines when to select the accessible wireless network; (3) handoff consequence component acts as the output of selection process to benefits of current accessible network.

Context input may include physical-layer, network-layer, and application-layer information. Physical context data usually provided by the smartphone platform relates to dynamic information such as RSSI or SNR. Network layer data comprise current bandwidth, delay, and jitter, which typically require much compute overhead and energy consumption. Application layer data include network requirements of apps, which are challenging to acquire due to the increasing of apps market [1, 2]. With the limitation of energy and capacity of modern mobile devices, the context gathering and evaluation process should be simple and not impact smartphone usage. Our closed loop handoff model adopted user feedback to simplify the overhead of this procedure. Handoff evaluation process combined the low-level context and user feedback to determine the suitable time to handoff interfaces. The detail of handoff policy is described in next subsection. The handoff consequence component shows the benefits of current execution handoff policy. We have defined three metrics that profile the handoff policy: (a) performance, (b) energy conservation, and (c) cost conservation.

As shown in Figure 2, the feedback direction flow includes two parts: (1) user feedback offered by end-users acts as the input of upper-level context; (2) upper-level context acts as the revised input of handoff evaluation process.

For user feedback presentation, we have defined the feedback vector, which has four values, including performance variable, energy variable, offloading variable, and continuity variable. In addition, various apps running on the smartphone have different Qos requirements. Take for instance, streaming video requires high bandwidth and continuous services. With the number and popularity of mobile apps rising dramatically, it is very challenging to classify the network demands of existing apps. We have proposed a heuristic classification approach along with the usage of handoff policy.

3.2. User Feedback

In this subsection, we present details of the feedback used in closed loop handoff model. The user feedback acts as the input of handoff policy for adjusting the interfaces selecting evaluation. We used the two forms to represent the current handoff usage, in which smartphone owners can give the user experience back.

The first way is end-users' subjective experience on the handoff policy. Let vector $\overrightarrow{V}$ represent the user feedback value of current interfaces selection policy. Consider

$$\begin{array}{cc}& \overrightarrow{V}=\left(\alpha ,\beta ,\lambda ,\eta \right),\end{array}$$

(1)

where α is performance requirement parameter of user on the handoff policy, β means the energy saving requirement, λ represents the data offloading requirement, and η is network service continuity requirement parameter. When the policy is first used in the mobile devices, the parameters are initialized via default values ${\alpha }_d$ , ${\beta }_d$ , ${\lambda }_d$ , and ${\eta }_d$ .

The second way is modification on the list of apps Qos requirements. Due to the exploration of the mobile apps, it is challenging to predefine the Qos requirements. We proposed the heuristic approach via user feedback. In the closed loop handoff model, each application has three attributes: time critical, bandwidth, and continuity parameters. When the policy is first used in the mobile devices, the list of apps is set up to the blank list. Along with the usage of handoff policy, end-users can add or delete items of the list to seek out a suitable satisfactory value.

3.3. Adaptive Handoff Policy

In this subsection, we described the details of adaptive handoff policy deployed in closed loop model. As shown in Figure 1, the handoff evaluation process has two kinds of input data: the low-level context collection and upper-level context from user feedback. The process combined these two types input data to determine the suitable time to execute handoff operation.

Let $U=\{u_1,u_{2,},\dots ,u_N,u_{N+1}\}$ be the set of WiFi APs and the cellular BS accessible points. Note that, modern smartphones do not permit users to choose the BS accessible point. Therefore, we take into account only $u_i\in \text{APs}\hspace{0.17em}\hspace{0.17em}(1\le i\le N)$ and $u_i\in \text{BS}\hspace{0.17em}\hspace{0.17em}(i=N+1)$ as candidate attachment points.

To formulate the network selection problem, we have defined an association vector $X={(x_i)}_{N+1}$ to represent condition of network on the smartphone:

$$\begin{array}{cc}& {\displaystyle \sum }_{1\le i\le N+\mathrm{1}}{x}_i=\{\begin{array}{cc}0,\hfill & \text{if}\hspace{0.17em}\hspace{0.17em}\text{none}\hspace{0.17em}\hspace{0.17em}\text{connectivity}\hfill \\ 1,\hfill & \text{if}\hspace{0.17em}\hspace{0.17em}\text{only}\hspace{0.17em}\hspace{0.17em}\text{one,}\hspace{0.17em}\hspace{0.17em}\text{AP}\hspace{0.17em}\hspace{0.17em}\text{or}\hspace{0.17em}\hspace{0.17em}\text{BS}\hfill \\ 2,\hfill & \text{if}\hspace{0.17em}\hspace{0.17em}\text{both}\hspace{0.17em}\hspace{0.17em}\text{AP}\hspace{0.17em}\hspace{0.17em}\text{and}\hspace{0.17em}\hspace{0.17em}\text{BS}\hfill \end{array}\\ x_i=\left\{\mathrm{1,0}\right\},\end{array}$$

(2)

where $x_i\mathrm{\hspace{0.17em}\hspace{0.17em}}(\mathrm{1}\le i\le N+\mathrm{1})$ is binary indicators, each of which has a value of 1 if and only if the mobile device connected the correspondence network attachment point. If a binary variable $x_i$ is equal one $(x_i=\mathrm{1})$ , network interface is associated with AP $u_i\mathrm{\hspace{0.17em}\hspace{0.17em}}(\mathrm{1}\le i\le N)$ or BS $u_{N+\mathrm{1}}$ . Otherwise, the variable $x_i$ is equal zero when none of network associating.

To illustrate the closed loop handoff policy to adapt various contexts, we used the user feedback vector $\overrightarrow{V}=(\alpha ,\beta ,\gamma ,\eta )$ mentioned in the previous section to describe how the handoff evaluation process adopts these variables.

Firstly, we present the parameter α in the user feedback vector $\overrightarrow{V}$ , which is on behalf of network performance requirement. The larger the parameter α value is, the more bandwidth and higher performance the end-user demands. For the given user feedback on the parameter α, we formulate the handoff policy to maximize the network performance as follows:

$$\begin{array}{cc}& \underset{u_i\in U}{\mathrm{Min}}\left|f\left(\alpha \right)-g\left(u_i\right)\right|,\\ \mathcal{F}\left(\alpha \right)={\mathcal{F}}_{\text{bit}}·{\alpha }_{\mathrm{1}}+{\mathcal{F}}_{\mathrm{err}}·{\alpha }_{\mathrm{2}},\end{array}$$

(3)

where effective data rate $g(u_i)$ of each point usually is unknown for the handoff client. In particular, when the mobile devices are not connected to the point ( $u_i$ ), the client is not able to evaluate valid data of these candidate attachment points due to the absence of active signaling between smartphone and the point ( $u_i$ ). Therefore, we are equipped with handoff client application that periodically collects the bit rate information for every AP/BS in its neighborhood by using beacon messages/pilot bursts. And formulation $\mathcal{F}(\alpha )$ is determined by parameters ${(\alpha }_1,{\alpha }_2)$ , where ${\mathcal{F}}_{\text{bit}}$ the weight of effective data rate users' demands, and ${\mathcal{F}}_{\mathrm{err}}$ is the error packets error rate.

Secondly, the parameter β in the user feedback vector $\overrightarrow{V}$ represents energy saving requirement. We define the element E that denotes the available amount of power of the smartphone. The value $p_i$ denotes the power consumption of transmission per unit data with the attachment point. When the mobile device is associated with AP $u_i\in \text{APs}\hspace{0.17em}\hspace{0.17em}(1\le i\le N)$ and $u_i\in \text{BS}\hspace{0.17em}\hspace{0.17em}(i=N+1)$ , the battery lifetime element is given as follows:

$$\begin{array}{cc}& \underset{u_i\in U}{\mathrm{Max}}\left\{l_i=\frac{E}{p_i}\right\}.\end{array}$$

(4)

Note that the value $p_i$ depends on the real condition of attachment point, which is related to the factors such as the number of connecting mobiles device and distance between them. The larger the transmit bit rate, the less power consumed of the device. It is because lower rates need to more time to finish data transmission. We define the value $p_a$ that denotes the power consumption time needed in connecting the AP and $p_c$ to the cellular BS, when the interfaces keep idle. We formulate the handoff policy to maximize the battery lifetime in idle duty as follows:

$$\begin{array}{cc}& \mathrm{Max}\left\{\frac{p_{\mathrm{1}}}{p_a},\frac{p_{\mathrm{2}}}{p_a},\dots ,\frac{p_N}{p_a},\frac{p_{N+\mathrm{1}}}{p_c}\right\}.\end{array}$$

(5)

Note that energy saving functions formulation used in the optimization methods leads to handoff decisions. In our handoff model, we adopt the parameter β in the formulation (1) to acts as the saving energy threshold in the formulation (4) and (5). According to the specific parameter β of user feedback, the closed loop model selects the energy saving function formulation.

Thirdly, we present the parameter γ in the user feedback vector, which represents network data offloading requirement. Let $\mathcal{W}=\{w_1,w_2,\dots ,w_N\}$ be the set of the amount network traffic, corresponding to the attachment point set $U=\{u_1,u_{2,},\dots ,u_N\}$ . The variable C is the total amount of mobile interface traffic, which is related to the cellular BS. We defined ${\rho }_a$ as the radio of the total amount WiFi traffic to the amount of cellular network traffic, shown as follows:

$$\begin{array}{cc}& \underset{w_i\in W}{\mathrm{Min}}\left|{\rho }_a-\frac{{\sum }_{i=\mathrm{1}}^N{w}_i}{C}\right|.\end{array}$$

(6)

Note that the value ${\rho }_a$ denotes the degree of data offloading between the cellular interface and the WiFi interface. In the closed loop handoff model, we proposed to compare the total ${\rho }_a$ with the dynamic variable ( ${\rho }_{\gamma }$ ), which is related to user feedback parameter (γ).

Fourthly, the feedback parameter η and the list of apps network requirements collaboratively revised the handoff policy. The feedback parameter η determined the degree of continuity service that the handoff policy concerned. When the handoff policy decides to select another network accessible point introducing flows interruption, the parameter η fixed the threshold waiting time ( $T_{\eta }$ ), which possibly reduces bad effect of interruption inference.

We define the set $\text{Apps}=\{a_1,a_2,\dots ,a_K\}$ as the running application in the mobile device, where each application has its network requirements in the form of the set $R=\{r_1,r_2,\dots ,r_K\}$ . And the value K is the number of running apps at present. The application has necessary accessing Internet, whose $r_i$ has twofold time critical and continuity demand; otherwise it is setup to zero. Note that, usually, the value K is dependent on smartphone usage habits, and the specific application network requirement $r_i$ cannot be predefined by developers. When the handoff policy is first used in the mobile devices, the list of apps is set up to the blank list. End-users can add or delete the application network requirements as the item of the list. For the given user feedback on the parameter η and the apps list, we formulate the handoff policy to reduce the interruption of ongoing network flows as follows:

$$\begin{array}{cc}& T_{\text{wait}}=\{\begin{array}{cc}\underset{r_i\in R}{\mathrm{Max}}\left\{f\left(r_i\right)\right\}\hfill & \text{if}\hspace{0.17em}\hspace{0.17em}{T}_{\eta }\le \underset{r_i\in R}{\mathrm{Max}}\left\{f\left(r_i\right)\right\}\hfill \\ T_{\eta }\hfill & \text{if}\hspace{0.17em}\hspace{0.17em}{T}_{\eta }>\underset{r_i\in R}{\mathrm{Max}}\left\{f\left(r_i\right)\right\},\hfill \end{array}\end{array}$$

(7)

where the formulation $f(r_i)$ is determined by mobile devices users input data.

Our closed loop handoff model is the complement part of the previous handoff approaches [15, 17], which is dependent on simple factor. These simple approaches cannot accurately choose a time to select suitable wireless network accessible points. And complicated handoff process brings about high overhead and large energy cost. In addition, with considering the different network Qos requirements of huge number apps in current smartphone markets [1, 2], designing an apt-handoff process is the challenge issue. We present that the user feedback scheme $\overrightarrow{V}=(\alpha ,\beta ,\gamma ,\eta )$ plays adaptive function on the handoff policy of smartphone. This feedback scheme avoid sophisticated context gathering and apps Qos requirements handle via applying end-users input. Our closed model can be implemented as the programmatic client form in the modern smartphone without infrastructure support or modifying existing network protocol.

4. Design and Implementation

The design of the closed loop handoff in the current smartphone is modular, consisting of three principal components: feedback mechanism, handoff policy, and switch execution. As shown in Figure 3, these components isolate the mechanism, policy, and monitoring tasks of the system and allow extending their capabilities without requiring any changes to the architecture. We designed and implemented the closed loop handoff in the real smartphone HTC G7 (based on the Android platform 2.3). The Android provides general users SDK (Software Development Kits) to develop custom application. Furthermore, it is possible to develop low-level system software and implement these mechanisms, as Android is open source operation system. We implemented the feedback mechanism and handoff policy via public APIs (supported by SDK) and activate/deactivate network interfaces via private APIs without kernel modification. Some implementation details are described below.

Figure 3

The closed loop handoff model architecture.

4.1. Feedback Mechanism

The feedback mechanism implements the function of bidirectional interaction with end-users, including two components: consequence monitor and user feedback as shown in Figure 3.

The submodule “consequence monitor” achieves the positive direction interaction, where mobile devices users are directly aware of the consequence of switching network accessible points. Different wireless networks provide different QoS level, which influence the apps performance in the smartphone, for example, as the web browsing behavior diversity between the WiFi AP and the cellular BS. Therefore, we have introduced three symbols to exhibit the effect of switching different networks, which are app performance, energy saving, and cost saving. We implemented the submodule “consequence monitor” as the foreground app showing in smartphone screen, which act as the activity in Android platform.

The submodule “user feedback” achieves the feedback direction interaction, where end-users give themselves experience back to handoff policy. Through the above mentioned exhibition of consequence switching, mobile owners directly know the effect of handoff policy. We implemented two ways of giving user feedback: personal evaluation on the handoff policy and apps Qos requirements list. The personal evaluation represents handoff policy requirement including four parts, as the performance, energy saving, data offloading, and apps continuity. They are stored in the form of vector $\overrightarrow{V}=(\alpha ,\beta ,\gamma ,\eta )$ . The Apps list comprise the network Qos requirements, and users can add or delete items of the list for seek out a suitable satisfactory value. The data of list is stored in a database which is made available to the switching policy.

4.2. Handoff Policy

The handoff policy determines the network points switch according to the four aspects requirements: apps continuity, performance, data offloading, and energy saving, where the above mentioned user feedback affords the specific values, as shown in Figure 2. Along with changing context, end-users can give feedback value $\overrightarrow{V}=(\alpha ,\beta ,\gamma ,\eta )$ to the closed loop handoff. According the specific value, the adaptive handoff policy can be generated to meet current requirements. The adaptive handoff policy generation is shown in Algorithm 1.

Algorithm 1: Adaptive handoff policy pseudocode.

Check whether apps or network context has changed

    if not changed then

    execute current handoff policy;

    else {

    if user give feedback then;

       $\mathrm{\rho }=(\mathrm{\alpha },\mathrm{\beta },\mathrm{\gamma },\mathrm{\eta })$ ;

    else

      adopting default value $\mathrm{\rho }=(\mathrm{\alpha },\mathrm{\beta },\mathrm{\gamma },\mathrm{\eta })$ ;

    Check $\mathrm{\alpha }$ , $\mathrm{\beta }$ , $\mathrm{\gamma }$ , $\mathrm{\eta }$ condition compared with previous

    values;

    if $\mathrm{\eta }$ happened to change then

      re-setup waiting time threshold;

    else

      maintain waiting time threshold;

    If $\mathrm{\alpha }$ happened to change then

      re-modify handoff requirement of network

    performance;

    else {

      if $\mathrm{\beta }$ happened to change then

        re-modify handoff requirement of energy

      saving;

      else

        if $\mathrm{\gamma }$ happened to change then

         re-modify cost offloading

        requirement;

    }

    }

As shown in Algorithm 1, algorithm firstly checked whether the apps context or network status changed. For example, when the smartphone is carried to another place, the wireless network environment changed. The adaptive algorithm will check whether end-user give feedback value back. If the feedback returns, the adaptive algorithm will adopt this value to adjust current policy, otherwise using the default value. Then the adaptive algorithm firstly checks the value η in the vector $\overrightarrow{V}$ . According the formulation (7), the parameter η is used to set the value of waiting time threshold $T_{\text{wait}}$ . As shown in Algorithm 1, the algorithm sets three metrics as the following order: performance α, energy conservation β, and data offload $(\gamma )$ . And the algorithm remodified performance requirement via formulation (3), energy requirement via formulation (4), and data offload via formulation (6).

4.3. Switching Execution

The switching execution implements the function of selection interfaces, including two components: status monitor component and switching entity component as shown in Figure 3.

In Figure 4, it shows flowchart of switching execution, including network state diagram and selection utility. Once the adaptive algorithm adjusted the handoff policy according to user feedback, the switching execution component will carry out specific policy to select suitable air interface or accessible points.

Figure 4

Adaptive handoff policy pseudocode.

Handoff policy firstly checks the current network state. We have used the state diagram together with all the states and transitions of air interfaces. If the current network connectivity is the WiFi AP, the module checks the candidate set accessible points to find another WiFi AP or activate the cellular interface to access the BS. If the current network connectivity is the cellular BS, the module checks the candidate set accessible points to activate the WiFi interface and to find the AP to connect. Once the policy makes handoff decision, the policy will send the handoff command to the switching entity. We have implemented the switching entity via the Android Platform SDK. The entity has two kinds of operation. First one is selection suitable accessible point via WiFi, which less network interruption compared with handoff operation between cellular and WiFi networks. If this selection operation occurred in the same domain, the handoff command will be executed, or otherwise the entity will wait the default time threshold to lower the influence of interfere. Other one is switching operation between cellular and WiFi networks. The execution will activate the new interface and inactivate the ole interface. And the component switching entity will follow the formulation (7) to wait $T_{\text{wait}}$ to reduce the bad effect of interruption of ongoing network flows.

5. Evaluation

The proposed switching solution in the closed loop handoff model is fully client based; it does not require additional support from the access points or gateways. Furthermore, it does not require any modification to the network protocols. It only used user feedback to adjust the handoff policy to adapt various contexts and only achieved the function via public or private APIs, which is compatible with other apps.

All experiments are performed in the real smartphone HTC G7 (based on the Android platform 2.3). The device has the WCDMA with frequency 2100 MHz, WiFi (802.11 b/g) and Bluetooth 2.1 with EDR. And the device is equipped with CPU Qualcomm MSM7225 528 MHz, 512 MB ROM, 384 MB RAM, and 1300 mAh battery limitation.

Apps performance is the significant boost to switch air interfaces or accessible points with better network status. As shown in Figure 5, for network bandwidth, the closed loop handoff is compared with other two approaches. The heuristic handoff approach periodically records the signal strengths of both cellular and WiFi networks and makes selection decision. The manual handoff approach makes selection decision via end-user setting up in person. As shown in Figure 5, along with increment of the handoff number, the performance with manual handoff approach drops dynamically compared with other methods. Intuitively, it is common that end-users do not update the network connectivity frequently. Relative to the heuristic handoff, our closed loop handoff gets the convergence of the batter performance value.

Figure 5

Performance along with the number of handoff.

The data offloading ratio is that data traffic migrates from cellular to WiFi network with selection different air interface. As shown in Figure 6, we analyze eight types of smartphone apps data traces that we have collected. For each application running, we compute the average WiFi usage and compare it to the amount of all data traffic. Since apps have various Qos requirements and traffic volume, the closed loop handoff approach shows different values of data offloading ratio. For example, we have measured streaming video data offloading by a 30 minute video on the phones using a Youku application. From the collected packet trace, we calculate the size of the video from WiFi compared with the size downloading from cellular network. In Figure 6, the closed loop handoff approach performance is much better than other two methods in data offloading ratio. The heuristic handoff depends on history data traffic volume via calling platform APIs. Due to the lack of knowledge of future data usage, the heuristic handoff method only deployed traffic volume estimation approach.

Figure 6

Data traffic volume between cellular network and WiFi network.

Energy conservation for each user is the important factor to employ the network the accessible point or other interfaces with less energy consumption. We used the third-party software [24] to estimate the average energy consumption for each user when the handoff closed running. We collected energy consumption in 30 min time. Since the handoff operation would consume much energy compared to the idle period; we also record the handoff times in Table 1. From Table 1, the closed loop handoff saves the distinct energy amount compared with other two approaches.

Table 1

Energy consumption.

	The closed loop handoff	Heuristic handoff	Manual handoff
Energy (J)	114 J	183 J	146 J
Handoff count	4 times	7 times	0 times

6. Conclusion and Future Work

In this paper, we consider the user feedback scheme as the same as the ambient environment to complement the handoff policy from the intuition. We have proposed the adaptive heterogeneous wireless network handoff based on the closed control loop. We have illustrated that the closed loop model can achieve reducing the distant gap between handoff policy and user satisfaction. Furthermore, we have designed and implemented prototype system in the real smartphone, which is fully client based; it does not require additional support from the access points or gateways. For our experiment, we have chosen three different metrics to profile the usefulness of the closed loop model: energy conservation, data offloading, and performance. Our experiment evaluation results show that the closed loop handoff outperforms the state-of-the-art manual handoff operation and simple heuristic approaches, from the following three metrics: throughput, energy conservation, and data offloading.

In the future work, we would improve the handoff policy from brute force switch network to seamless handoff. We would add the middleware deployed in the modern smartphone to achieve this seamless switch operation, where other apps are transparently running.