Android-based application. Due to growing demand for a high- speed mobile data connection around the clock, 3G networks begin to face high congestion ...
3G to Wi-Fi Offloading on Android Khaled Bakhit
Chantal Chalouhi
Sabine Francis
Sara Mourad
Imad H. Elhajj
Ayman Kayssi
Ali Chehab
Department of Electrical and Computer Engineering American University of Beirut Beirut 1107 2020, Lebanon {kab11, ccc03, sjf04, sjm07, ie05, ayman, chehab}@aub.edu.lb
Abstract—In this paper, we propose a 3G to Wi-Fi offloading Android-based application. Due to growing demand for a highspeed mobile data connection around the clock, 3G networks begin to face high congestion levels rendering the mobile service providers unable to meet customer expectations. Despite the existence of various solutions, offloading to Wi-Fi proves to be an optimal one as it takes advantage of the resources that Wi-Fi offers in terms of availability and bandwidth. The proposed application measures the download speed of an online page on both Wi-Fi and 3G networks simultaneously. After comparing the results, the device gets switched to the best network. This enables operators to manage their networks more adequately and to improve users experience. Keywords—3G, Android, offloading, telecommunication, Wi-Fi
I. INTRODUCTION The evolution of mobile networks towards 3G supporting multimedia services allowed users to surf the Internet at higher speeds. According to recent statistics, mobile data traffic is experiencing in excess of 100 percent growth on a yearly basis due mostly to the usage of tablets and smart phones. This trend is expected to continue even more aggressively in the coming years. The authors of [1] stated that the number of mobile devices exceeded the number of people on earth. By the year 2016, the total mobile data traffic will reach 10.8 EB/Month, of which 2.6 GB/Month will be associated with the average smart phone device [1]. However, the ubiquity of accessing the Internet through mobile devices backfired, as the 3G networks are no longer able to handle the explosive growth in the traffic. When accessing the Internet in major city agglomerations or even in malls and in football stadiums, users experience a low quality of service. The network, which was originally designed to handle voice and some data, is now experiencing high congestion. In fact, and unlike voice which can be to some extent predictable in its usage and resources, data has unlimited and difficult to predict characteristics [2]. In order to address the high pressure arising in 3G networks, operators are trying to increase their limited spectrum and are moving to LTE. However, this approach will either be insufficient or ineffective [3]. In fact, increasing the speed will only increase the cost of deployment; and increasing the bandwidth will not be able to accommodate the exponentially
increasing number of subscribers [3].As an alternative, several research works propose offloading data traffic to Wi-Fi networks. Wi-Fi offloading consists of switching the mobile data from the 3G network to the Wi-Fi network and vice versa. Other than the fact that Wi-Fi offers a larger bandwidth, it also reduces costs for operators since sending data through Wi-Fi is around ten times cheaper than sending it through 3G [4]. The authors in [5] deployed an iPhone application that monitors Wi-Fi connectivity on 100 devices and carried their experiment for two and a half weeks. They found out that users are in a Wi-Fi covered zone 70% of the time, they stay in a coverage area for an average of 2 hours, and after leaving, they return to a Wi-Fi covered area within 40 minutes. They also added that on-the-spot offloading alone can offload 65 % of the total traffic. Balasubramanian et al. proposed a scheme called Wiffler to augment mobile 3G using Wi-Fi for delay-tolerant applications such as email and file transfer, by transmitting delay tolerant traffic over Wi-Fi when available, thus performing a trade-off between high application latency and lower 3G usage [6]. In [7], the authors proposed two Wi-Fi based offloading solutions; the MixZones algorithm which makes use of opportunistic exchanges between smartphones in what the authors label as MixZones areas, and the HotZones algorithm which covers a fraction of cells with Wi-Fi access points. The two algorithms were designed for delay-tolerant offloading of content from 3G networks. The authors in [8] explore an approach for operators to dynamically offload traffic to Wi-Fi networks by using tightly coupled cellular/Wi-Fi systems, such as deploying three Wi-Fi Access Points within the coverage of a single 3G cell. Their simulation results showed power saving up to 65 % for cellular networks. In this paper, we propose performing the offloading operations on the mobile end rather than the operator end. We introduce an Android-based mobile application that offloads users from 3G to Wi-Fi and vice versa. The application compares the quality of both networks simultaneously and switches the user data traffic accordingly. This method 1) requires no changes to the network and no additional costs, 2) benefits from the advantages that Wi-Fi offers, and 3) is adequate for any Android-based device.
978-1-4799-7100-8/14/$31.00 ©2014 IEEE 247
The rest of this paper is organized as follows: in Section II, we discuss the network tests to measure performance. In Section III, we present techniques used on Android for simultaneous connectivity. Section IV presents the offloading algorithm, and Section V shows the obtained results. Finally, we discuss future work and conclude in Section VI.
networks. The average RTT of these three pings were recorded. Tables 1 and 2 summarize the correlation between the RTTs of these pings over the Wi-Fi and 3G networks, respectively. Table 1: Correlation between RTT of the ping tests over Wi-Fi Ping With
II. NETWORK MEASURES In order for the offloading decision to be done properly, the application needs to choose the better network. For this reason, we first identify the network parameters to monitor and then choose the tests to conduct.
1 Packet
3 Packets
5 Packets
1 Packet
-
0.63
0.62
3 Packets
0.63
-
0.83
Table 2: Correlation between RTT of the ping tests over 3G
A. Network Parameters In order to test the quality of the networks, different parameters need to be evaluated. Of these, we consider the signal strength, the throughput, and the loss rate [6]. First, the signal strength is a necessary but not a sufficient condition to have a good end-to-end network quality [9]. For example, the signal can be very strong while the network core itself can be congested. Second, the throughput of the network, i.e. the network effective bitrate, is calculated using the time it takes the TCP packets to be entirely downloaded. Measuring these rates is hence a good indicator of the quality of the network since having congestion or bad signal result in poor speeds. Finally, an indirect way of measuring the loss rate is through the download speed. The download rate is actually affected when there is high packet loss. In fact, the TCP protocol itself ensures no loss of information through the retransmission of the lost packets. A slower download speed is hence obtained when high loss rate is available.
Ping With
1 Packet
3 Packets
5 Packets
1 Packet
-
0.59
-0.59
3 Packets
0.59
-
0.91
As shown in these two tables, pinging the networks with three packets is highly correlated to pinging them with five packets. So, three packets are sufficient to estimate the RTTs of the networks. 2) Download Test The implemented download test consists of downloading a web page from a reliable server. The download speeds of the Facebook and Google pages were compared to the download speeds obtained from Speedtest.net. In fact, Speedtest.net is considered as a reliable measure of the network bitrate. If the download speeds of Speedtest.net increase/decrease, we expect the download speeds of the Google and Facebook pages to follow the same trend if they are a good indicator of the network changes. An experiment was set in two regions (R1 and R2) within Lebanon at two different days and times to record the download speeds of the Google and Facebook pages and those of the Speedtest.net. The correlations between the Facebook page and Speedtest.net and between the Google page and Speedtest.net were calculated. Plots 1, 2, 3 and 4 in Figure 1 show the variations of the measured speeds. As noticed, speeds obtained for the Facebook page and the Google page follow the same trend as those of Speedtest.net. This is also shown in the correlation values recorded in Table 3.
B. Network Test In order to measure the different parameters listed above, two types of tests can be conducted, the download test and the ping test. The first gives the download speed, whereas the second gives both the round trip time (RTT) and the loss rate. As the offloading application aims at minimizing its own overhead, only one type of these two network tests is adopted. To choose between these two tests, the download speed of the Google page and the average RTT of three Google server pings (the first pings the server with one packet, the second with three packets and the third with five packets) were recorded three times a day over a period of one week.
Table 3: Correlation between speeds of Google/Facebook pages and those of Speedtest.net Location
1) Ping Test In the ping test, the number of packets used to ping the server can be monitored. The IP address of a Google server was pinged with one, three and five packets over the Wi-Fi and the 3G
248
R1
R2
Pages
Google
Facebook
Google
Facebook
Speed Test
0.98
0.91
0.85
0.81
Figure 1. Download test results for Google and Facebook
As Table 3 shows, both pages are correlated to Speedtest.net regardless of the servers’ locations or downloaded page sizes (Google page was around 70 KB while Facebook page was around 10 KB in size).
Based on these tests, we concluded that indeed the download speed decreases as the average RTT increases. So, the testing done by the offloading application will only be based on the download speeds of the available networks.
3) Comparison
4) Download Page Size
The three-packet ping test conducted for the Google server was then compared to the download speed of the Google page. Comparing the timings of the different download speeds listed in Table 3, we noticed that for speeds less than 1.0 Mbps, the average RTT is in the order of the hundreds of milliseconds; and for speeds around 1.1 Mbps, the average RTT is in the order of the tens of milliseconds.
It is a well-known that mobile network connections are more expensive per bit that Wi-Fi connections. As such, it is vital to determine the smallest possible size for a test page to download, that would reduce the total amount of mobile data consumed while still allowing the offloading algorithm to deduce similar decisions that would result from Speedtest.net measurements. For this purpose, several test pages of various sizes were uploaded to an online server. The sizes were: 8 KB, 16 KB, 32 KB, 64 KB, 128 KB, 256 KB, 512 KB, 1024 KB, 2048 KB, and 3072 KB. Afterwards, we downloaded each page over the Wi-Fi and over 3G separately and recorded the download speeds. Simultaneously, we obtained measurements from Speedtest.net. We repeated the measurements 10 times at different times. Finally, for each pair (Wi-Fi, 3G) of measurements, we projected the algorithm’s decision and compared it to the decision using Speedtest.net values. Our results are summarized in Table 5. According to the obtained results, it is determined that 64 KB is the smallest possible size for a test page that would follow the
Table 4: Google page download speed and corresponding average RTT
Google Page Download Speed (Mbps) 1.17 1.12 1.11 0.93 0.91 0.99 0.91 0.92
Average Round Trip Time (milliseconds) 95 80.5 82 114.2 99.9 130.2 100.2 119
249
Speedtest.net based decisions while minimizing mobile data consumption. In our simulation results, we selected a download test page of size 69 KB that was available on a reliable remote server. We performed the same experiment mentioned in Table 5 to verify its suitability and achieved a similar 80 % decision matching.
download the test page, while keeping the phone connected to the Wi-Fi network. Hence, the application is able to measure on one hand the download speed of the Wi-Fi network, and on the other hand, the download speed of the 3G network – without the need for switching the user to 3G. The collected results are then compared and the user is switched to the better network.
Table 5: Matching decisions compared to speed test based decisions
B. Wi-Fi Connection in a 3G Environment Page Size (KB) 8 16 32 64 128 256 512 1024 2048 3072
Percentage of Matching Decisions 50 % 50 % 60 % 80 % 80 % 90 % 80 % 80 % 80 % 90 %
In this case, we aim at opening a Wi-Fi connection while the phone is connected to 3G. However, this case is more challenging as any attempt to connect to Wi-Fi automatically gives priority to Wi-Fi. Hence the phone switches all connections to Wi-Fi, and hinders the goal of testing both networks simultaneously prior to switching. Therefore, the application changes the priority of the networks by giving higher priority to 3G. However doing so will not enable automatically the simultaneous connectivity. In fact, and even though the routing table of the phone contains both 3G and Wi-Fi interfaces, the phone disregards the Wi-Fi interface. So, the next step is to add a routing table entry to a specified destination server, with the gateway router set to the Wi-Fi interface (see Figure 2.)
5) Frequency of Testing The offloading application needs to test the network quality whenever the users are accessing the Internet (over 3G and/or Wi-Fi). Hence, the application is programmed to run whenever the users unlock their phones. When the application has run once, and in case the first conditions are still valid, it waits for a pre-defined time interval before launching the algorithm again. In this fashion, the application would not run if the phone is sleeping, thus saving battery energy, unnecessary switching, and user data quota. III. SIMULTANEOUS CONNECTIVITY The offloading application requires measuring the download speeds of both the Wi-Fi and the 3G networks in order to know which one of these two provides better user experience. Two scenarios need to be addressed: 1) when the user is connected to Wi-Fi, a simultaneous 3G connection is needed to download the test page over 3G, and 2) when the user is connected to 3G, a simultaneous Wi-Fi connection is needed to download the test page over Wi-Fi.
Figure 2: Routing Table Before Adding the Entry (Top). Routing Table After Adding the Entry (Bottom)
A. 3G Connection in a Wi-Fi Environment
Thus, the application is now able to open a single Wi-Fi connection to the pre-specified IP address of the test server while keeping the phone connected to 3G.
In this scenario, we aim at opening a 3G connection while the phone is connected to Wi-Fi. As Wi-Fi has priority over 3G in Android, any 3G connection made while connected to Wi-Fi will fail. The solution is to set up a mobile connection of type HIPRI. This network type has a priority over Wi-Fi and can be established only on a pre-defined IP address. Accordingly, the offloading application is able to open a 3G connection to
IV. ALGORITHMS The offloading application switches between 3G and Wi-Fi networks based on the download speeds obtained by
250
simultaneously downloading the test page via Wi-Fi and 3G. The testing is triggered by unlocking the Android phone home screen, connecting to the Internet and satisfying the time interval condition.
12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. }
Algorithm 1: Pseudo Code of the Algorithm when the User is Connected to Wi-Fi 1. if (screen is unlocked AND 2. Wi-Fi connectivity available AND 3. time interval satisfied ) 4. { 5. Download test page and retrieve the download speed denoted by WIFI_Speed 6. 7. Open the 3G connection of type HIPRI 8. 9. Download test page and retrieve the download speed denoted by 3G_Speed 10. 11. Close the 3G connection 12. 13. if ( WIFI_Speed >= 3G_Speed ) 14. Keep the user connected to Wi-Fi 15. else 16. Switch the user to 3G 17. }
to connect to the test page Download test page and retrieve the download speed denoted by WIFI_Speed Close the WIFI connection Delete the added route table entry Restore default network preference if ( 3G_Speed >= WIFI_Speed ) Keep the user connected to 3G else Switch the user to Wi-Fi
V. RESULTS To evaluate the performance of the offloading application, we deployed the application on multiple Android phones that were then used by users during their normal daily activities. The application was setup to use the test page for download speed measurements and to execute in the background upon screen unlock every 15 minutes (testing time interval). The end users were most of the time on the move, which provided real world testing condition leading to measurements being performed at various locations. The testing took place over several days to evaluate the added value of the application. We collected a total of 158 samples from all the participating users. Table 6 represents the distribution of the switching/offloading decisions that were made by the application. We have four cases: switching from Wi-Fi to 3G, offloading from 3G to Wi-Fi, keeping the Wi-Fi connection, and keeping the 3G connection. We can see that 51.26% of the total decisions were in favor of Wi-Fi, while the remaining 48.73% were in favor of mobile data.
The steps followed by the algorithm depend on the initial connectivity of the user. If the user is connected to Wi-Fi, the pseudo-code in Algorithm 1 is executed. Otherwise, if the user is connected to 3G, the algorithm performs the steps described in Algorithm 2. In case the user is disconnected, no operation will be performed. Algorithm 2: Pseudo Code of the Algorithm when the User is Connected to 3G 1. if (screen is unlocked AND 2. 3G connectivity available AND 3. time interval satisfied ) 4. { 5. Download test page and retrieve the download speed denoted by 3G_Speed 6. 7. Give priority to 3G connection 8. 9. Open the Wi-Fi connection 10. 11. Add a route table entry to use the Wi-Fi interface
Table 6: Distribution of offloading decisions
Wi-Fi to 3G 30.38 %
3G to Wi-Fi 22.78 %
Keep Wi-Fi 28.48 %
Keep 3G 18.35 %
To evaluate the end user’s overall experience, we recorded the download speeds measured in every test performed by the application. Table 7 displays the average download speed experienced on the 3G network, Wi-Fi network, and the combined approach which represents the effective download speed experienced after the offloading operations.
251
3G 157.34
Table 7: Average speed experienced (KBps)
ACKNOWLEDGMENT
Wi-Fi 775.82
The research work was sponsored by Aruba Networks and Triple C. The authors would like to thank Mr. Rabih Itani for his support.
Combined 832.33
The recorded data shows that the application always favored the faster Wi-Fi connection over the slower 3G connection leading to a reduced congestion on the mobile operator’s network. However, the application still respected the user experience by switching to the mobile data network when it was determined to be faster than the available Wi-Fi connection, leading to a better overall user experience. In addition, according to Table 7, the end user will only notice the increased download speed observed which improves the overall user experience.
REFERENCES [1]
[2]
[3]
VI. CONCLUSIONS AND FUTURE WORK
[4]
We proposed an Android-based application, which through novel algorithms switches efficiently and seamlessly the users between 3G and Wi-Fi networks. The ability to connect to both networks simultaneously avoids unnecessary switching and service interruptions. By downloading a test page with an optimized size, the download speeds of both networks are compared. This unique criterion upon which the application is based is an indirect measure of the networks signal strength, loss rate and delay. In addition, the application requires no changes to the infrastructure of the service provider networks; this implies no additional costs on their behalf. It also allows the users to benefit from the best performing network. It would be interesting to observe the application effect on the overall mobile network performance. We will proceed into deploying the mobile application at a larger scale within a single cell tower area and observe the variations in the 3G network behavior at that area. Such testing will help outline the benefits of the application for the mobile operators at a bigger scale.
[5] [6]
[7]
[8]
[9]
252
Cisco (2012, February 14). Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update, 2011–2016 [Online]. Available: http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns70 5/ns827/white_paper_c11-520862.html 4G Americas, “Optimizing the mobile application ecosystem,” April 2011. [Online]. Available: http://www.4gamericas.org/UserFiles/file/Presentations/AppsWorld2011_ GautamTalagery.pdf S.Dimatteo, P. Hui, B. Han, and V.O.K Li, “Cellular traffic offloading through WiFi networks,” in IEEE 8th International Conference on Mobile Ad-Hoc and Sensor Systems, pp. 192-201, 2011. Mobile Data Offloading [Online]. Available: http://www.aptilo.com/solutions_mobile-data-offloading.htm K. Lee, J. Lee, Y. Yi, I. Rhee, and S. Chong, "Mobile data offloading: how much can WiFi deliver?," in Proceedings of the 6th International Conference. ACM, 2010. A. Balasubramanian, R. Mahajan, and A. Venkataramani, “Augmenting mobile 3G using Wi-Fi,” in MobiSys, San Francisco, CA, June 15–18, 2010. N. Ristanovic, J.Y. Le Boudec, A. Chaintreau, and V. Erramilli, "Energy efficient offloading of 3G networks," in Mobile Adhoc and Sensor Systems (MASS), 2011 IEEE 8th International Conference on. IEEE, 2011. A. Aijaz, O. Holland, P. Pangalos, and H. Aghvami, "Energy savings for cellular access network through Wi-Fi offloading," in Communications (ICC), 2012 IEEE International Conference on, pp. 4369-4373. IEEE, 2012. Martin Boutler (2012, May). Measuring Wireless Network Performance: Data Rates vs. Signal Strength [Online]. Available: http://digitaleditions.napco.com/publication/?i=111443&p=31
