The Great Expectations of Smartphone Traffic Scheduling

The Great Expectations of Smartphone Traffic Scheduling Vilen Looga, Zhonghong Ou, Yu Xiao, Antti Ylä-Jääski Department of Computer Science and Engineering Aalto University School of Science Espoo, Finland Email: firstname.lastname@aalto.fi Abstract Utilizing network traffic scheduling to improve the energy efficiency of smartphones has been studied extensively in the past few years. These studies usually take certain approaches and make some assumptions concerning traffic predictability, regardless of whether these assumptions hold or whether the approaches have been studied before. In this paper, we conduct an analysis of existing work to find common approaches and assumptions among the proposed solutions. We find out the following: 1. A large part of the solutions target a specific (single) application or category of applications, and do not schedule the whole traffic transmitted on the smartphone. 2. A common assumption is that network traffic for smart phones is predictable. The focus of our work is to test these assumptions against real-world data and analyze whether the approaches presented in the literature are feasible. By leveraging two data sets from NetSense, we make several major contributions: 1. We demonstrate clearly, based on a large dataset, that background apps are the largest energy consumers for smart phones. 2. although some traffic traces exhibit long-term trends, in general traffic from a single app or a user is not predictable in the short-term. 3. achieving energy savings is difficult by scheduling traffic only from a specific app, since multi-app scenarios are so prevalent on today s smartphones. We also pinpoint future directions for traffic scheduling schemes. I. INTRODUCTION The battery life of smartphones has been a primary concern in the past several years. In a breakdown of energy consumption for smartphones, wireless communication components account for a prominent part of the overall energy [1]. Thus, improving the energy efficiency of data transmission for smartphones has attracted significant interest, both from industry and academia. One proposed approach is to use prediction coupled with scheduling to collect traffic into more coherent bursts [2] [5]. This reduces intra-burst intervals and allows the wireless network interface (WNI) to spend less time idling, thus decreasing energy waste [6]. Nevertheless, the underlying assumption is that smartphone traffic is predictable, which has not been verified with analysis of large-scale reallife smartphone traffic traces. Hence, to create effective traffic prediction/scheduling schemes it is necessary to understand the characteristics of network traffic in modern smartphones. In this work, we conduct a systematic analysis on smartphone traffic based on traces from the NetSense Project [7], [8]. Our analysis focuses on three aspects: which apps consume the most energy on wireless transmissions, predictability of the traffic, and feasibility of single-app traffic scheduling. For the analysis, we got access to two datasets from NetSense. The data consists of transmitted and received perapp traffic over Wi-Fi, with 60-second sampling interval. The first set (November 2012) consists of one week of data from 145 users, while the second set (November 2013) encompasses one month of data from 65 users. We extract traffic traces for single apps and single users from the dataset and use an Augmented Dickey-Fuller (ADF) test [9] to determine whether they exhibit long-term trends. Furthermore, we apply Autoregressive Integrated Moving Average (ARIMA) models to promising traffic traces to determine whether they are predictable on a short time-scale. Through extensive analysis, we make three major contributions as follows: 1. We demonstrate clearly, based on a large dataset, that background services, media apps and the Facebook app contribute the most to the volume of network traffic and the energy consumed by the WNI. 2. Some traffic traces have long-term trends, however on a short-term scale, traffic from a single app or a single user is not predictable. 3. focusing on single-app scheduling is not beneficial since the WNI is almost always used by multiple apps. The rest of the paper is organized in the following way. We study the representative traffic scheduling solutions in Section II. In Section III we briefly describe the NetSense datasets. In Section IV we investigate how the network traffic profile of the application affects its energy consumption. In Section V we analyze predictability of single app and single user traffic. We finish the paper with discussion in Section VI and conclusions in Section VII. II. TRAFFIC SCHEDULING APPROACHES Traffic scheduling on smartphones is an ongoing research topic. We analyze the existing solutions to try to find out common assumptions and approaches among them. A representative sample of existing solutions found during our literature survey is shown in Table I. In our survey, we found that more than half of the traffic scheduling schemes have the underlying assumption that app or device traffic is predictable. The motivation here is that if network traffic is predictable, then it can be scheduled into more coherent bursts, thus improving the energy efficiency of the radio interface. However, among the surveyed works we did not find a strong argument for the assumption of predictability, neither for single-app nor multi-app scenarios. Among the solutions that did not rely on traffic predictability, the prevalent

approach was either to use some kind of traffic management protocol between endpoints or cues from the environment. Some works test their traffic scheduling schemes with simulated pseudo-random traffic, while others test on real hardware with real traffic [4], [10]. However, in the case of the latter, the traffic over the radio interface during the experiment is often limited only to the experimental apps, thus taking background apps out of the equation. Unfortunately, this means that such scheduling schemes are not tested in a scenario that is close to the real world. Among the surveyed solutions, the prevalent approach was single-app traffic scheduling, while solutions that addressed traffic scheduling for the whole device were fewer. For the single app we found solutions focusing on improving the energy efficiency of bulk streaming (multimedia, Youtube), while others addressed frequent, but short transmissions (email, background). We will not describe in detail the exact methods used by these solutions to do traffic scheduling, it should suffice to say that most of them try to delay packet transmissions and collect them into coherent bursts. On the other hand, multi-app (whole device) traffic scheduling solutions are usually more varied in their approaches, for example by taking cues from the environment, such as signal strength or user activity, to figure out the best time to transmit packets. Thus, based on our literature survey, we want to analyze the following: the assumption of smartphone traffic predictability; feasibility of single-app traffic scheduling; best targets for energy savings among smartphone apps. III. DATASET As mentioned above, we get access to two data sets provided by the NetSense Project, which consists of Wi-Fi network traffic (both transmitted and received) logs from Android smartphone users. For each user, the specific app that is using the WNI and the amount of data that is exchanged during a 60-second interval is logged. The data is provided in the format of (timestamp, user, app name, transmitting/receiving, bytes) and is collected in 60-second intervals. There are two separate datasets, one 5-day long from November 2012 and another 30-day long from November 2013. The first dataset has a total of 145 users, who used a total of 699 different apps, while the second one has 56 users and 293 unique apps. Although background services are few (<10) compared to the total amount of unique apps, they are top contributors to the overall traffic volume and transmission count (see Table II). This allows us to extract 6726 and 13024 single app traffic traces from the first and second dataset respectively. In total, these two datasets logged over 61 GB of transmitted traffic and over 235 GB of received traffic. IV. ENERGY CONSUMPTION OF SMARTPHONE APPS First we find applications that are the largest WNI consumers by volume. As expected, most of the traffic volume is either from Facebook, media applications (Pandora etc.) or background services (e.g., Location, Play Services, and Google Apps). The same holds true for frequency of bursts 1, where 1 A burst can be defined as a train of packets with a packet interval less than a threshold. Due to traffic data resolution, we set the threshold to 60 seconds. background services dominate (see Table II). We analyze whether frequent bursts have a stronger impact (compared to traffic volume) on energy consumption of apps. To estimate the energy consumption of the app network traffic we use energy models developed earlier [6] [16]. The energy model is configured to simulate the energy expenditure of the WNI according to the parameters of a modern Android smartphone. The amount of data transmitted every 60-seconds (the granularity of the traffic trace) is given as a single coherent burst to the energy model (e.g. no intra-burst intervals). The energy model then estimates how much energy it consumes to send a traffic burst over the WiFi interface. The estimation is based on the size of the burst and includes the tail energy, i.e when the WiFi interface stays in IDLE mode after sending traffic (this is a simplification of the model and for a more precise description see the referenced papers). It should be noted that due to the resolution of the traffic provided by the NetSense study, our energy estimation results are relatively conservative. The available data does not contain the exact traffic shape, but rather the aggregation of traffic in 60-second intervals. It means that we have to make an assumption that the traffic was sent in the most efficient way (a single burst) during those 60 seconds. Obviously, in realistic scenarios the traffic, although bursty, might still have large enough intra-burst intervals to cause the WiFi interface to stay in IDLE mode, thus wasting more energy than our estimate. Thus, the actual energy consumption of the applications transmitting frequently will not be lower than our estimate. A. Single app traffic First, we analyze the correlation between energy expenditure and volume or frequency of the app network traffic. For that, we separate the data into single app traffic traces and run each of them through the energy model. We then calculate the volume and frequency for each app trace and create correlation graphs with energy (see Fig. 1, where each point in the figure represents the result of an app trace, with a total 293 app traces). Transmitted and received bursts for the same app are counted as separate traffic traces. The reason for strong correlation between app frequency and energy expenditure is due to the way the latter is counted. The presumed bandwidth of the link is rather high in the case of WiFi and each burst from the app is relatively small. This means that each burst adds an equal amount of energy to the overall expenditure, thus creating a strong correlation between the number of bursts and energy spent. It should be noted that these calculations presume that each app bears the full cost of tail energy of the WNI. A slightly different picture emerges when we look at the correlation between traffic volume and spent energy. As can be seen from the graph, apps can have large variations in total traffic volume, while having similar energy expenditure. This points to the fact that traffic optimization into bursts can result in improvements in energy efficiency. However, since realistic scenarios of smartphones rarely presume only a single app using the WNI, we must look at traffic profile of all the apps that run on the same smartphone, e.g. the multi-app scenario. B. Single user traffic To look at aggregated traffic profile of every smartphone, we separate the data into traffic traces from each user. If

TABLE I. REPRESENTATIVE SAMPLE OF TRAFFIC SCHEDULING APPROACHES FOR SMARTPHONES. FOR EACH APPROACH, THE TABLE SHOWS WHETHER IT TARGETS A SINGLE OR MULTIPLE APP SCENARIOS, WHAT IS THE TARGET OF SCHEDULING AND WHETHER TRAFFIC PREDICTABILITY IS ASSUMED OR NOT. Name Single/Multi-app scenario Target Traffic predictability Testing environment Network traffic traces Xu 2013 [11] Single Email client YES Smartphone Fixed size packets Pyles 2011 [12] Single Voice data YES Smartphone Real Liu 2011 [13] Single P2P apps NO Desktop PC Real Li 2012 [14] Single Video streaming YES Smartphone Real Huang 2012 [15] Multi Background apps NO Simulated Real Dogar 2010 [4] Single Web, FTP NO Smartphone, laptop Pseudo-random Looga 2012 [2] Multi All traffic YES Simulated Real Ou 2014 [10] Multi All traffic YES Smartphone Real Wei 2006 [5] Single Media streaming YES Simulated Pseudo-random TABLE II. TOP 10 APPLICATIONS (OMITTED COM. AND ABBREVIATED GOOGLE. TO G. IN PROCESS NAMES FOR CLARITY). ANDROID SYSTEM PROCESS NAMES ARE IN ITALICS FONT. FREQUENCY OF BURSTS (inter-burst interval 60s) VOLUME (BYTES) Transmitted Received Transmitted Received Total transmitted 1727259 Total received 1728528 Total transmitted 61944854001 Total received 235544413495 g.process.gapps 135071 g.process.gapps 132018 facebook.katana 8031821733 facebook.katana 62496810058 g.process.location 134183 g.process.location 131277 pandora.android 6278551509 android.settings 25141050646 g.android.gms 119762 g.android.gms 117260 android.systemui 3983931454 android.systemui 24367753677 facebook.katana 99973 facebook.katana 97994 system 3562742870 system 22221917034 g.android.gsf.login 97009 g.android.gsf.login 95933 android.settings 3292265411 g.android.pr...media 21586638817 system 75824 system 78996 g.android.apps.plus 3230087988 android.browser 17696809230 sec.spp.push 64198 sec.spp.push 63724 g.process.gapps 1596997663 pandora.android 7267586737 android.settings 55303 android.settings 58127 g.android.gms 1576637303 co.vine.android 6347565160 android.systemui 49580 android.systemui 52783 g.process.location 1484364277 android.chrome 2920427500 facebook.orca 47679 facebook.orca 48373 facebook.orca 1274926295 g.process.gapps 2479647185 Fig. 1. Correlation between spent energy and volume or frequency of bursts for single app traffic traces. Transmitted and received bursts for the same app are counted in separate traffic traces.

Fig. 2. Correlation between spent energy and volume or frequency of bursts for single user aggregated traffic. Transmitted and received bursts for the same app are counted in separate traffic traces. multiple apps are using the WNI at the same time interval, we aggregate their traffic. Again, we run the traffic traces through the energy model and try to look at the correlation with frequency and volume. The results are demonstrated in Fig. 2, where each point represents the result of an user trace, with a total of 145 user traces. From the figure, we can see that there exists a strong correlation between energy spent and volume, especially as the traffic volume increases. There is also a correlation between frequency and energy spent, but with a larger variation than the former. C. Targets for energy saving Based on our analysis of the traffic data, where we found a strong correlation between volume and energy spent, we can conclude that a significant part of the WNI energy is spent using large volume/high frequency Android system services, media apps and the Facebook app. This finding correlates with earlier work, such as [15]. However, the previous work was based on a smaller dataset, with fewer users and total apps. Although our energy estimate is limited in precision due to the resolution of the data, it is still apparent, even by conservative estimates, that the services and apps mentioned previously are good targets to improve energy efficiency of smartphone network transmissions. Taking a look at the traffic scheduling schemes mentioned earlier (see Table I), it is apparent that multi-app scenario solutions are better suited for addressing the biggest energy consumers. On the other hand, single-app scheduling schemes tend to focus on apps that do not contribute significantly to the overall energy budget (e.g. email). Our analysis also shows that compared with how much background system services contribute to the overall energy consumption, there is an under-representation of scheduling schemes that address this issue. V. TRAFFIC PREDICTABILITY Having identified background services as a good target for improving the energy efficiency of the smartphone WNI, we now analyze whether it is possible to predict their traffic. We are interested in finding out whether it is possible to predict the time (when the traffic arrives) and the size of the packet bursts. We investigate traffic predictability both from the perspective of single apps and single users (multi-app) scenarios. We evaluate the predictability of traffic traces using the Augmented Dickey-Fuller (ADF) test. It tests the existence of a unit root in time series by comparing an ARIMA(p,1,0) process against a stationary ARIMA(p+1,0,0) alternative. A presence of a unit root indicates that there is no trend in the time series. When testing, we use the strictest recommended p-value of less than 0.001 [17] to rule out the presence of a unit root. If the ADF test returns a p-value for a traffic trace higher than 0.001, we consider the trace unpredictable.

TABLE III. ADF TEST RESULTS FOR SINGLE APP TRAFFIC TRACES. WE TEST FOR PREDICTABILITY OF BURST INTERVALS (TIMING) AND THEIR SIZE. COLUMNS DENOTED BY * INDICATE DATA WITH REMOVED DATAPOINTS, WHERE THE BURST INTERVAL IS EXACTLY 60 SECONDS. Set Nov 12 Nov 13 Nov 12 (*) Nov 13 (*) Single app traffic samples 6726 13024 3529 4789 Avg. nr. of bursts per sample 193.4 876.8 101.3 157.8 Without unit root 2172 3765 546 776 TABLE IV. ADF TEST RESULTS FOR SINGLE USER TRAFFIC TRACES. WE TEST FOR PREDICTABILITY OF BURST INTERVALS (TIMING) AND THEIR SIZE. COLUMNS DENOTED BY * INDICATE RESULTS WITH REMOVED DATAPOINTS, WHERE THE BURST INTERVAL IS EXACTLY 60 SECONDS. Set Nov 12 Nov 13 Nov 12 (*) Nov 13 (*) Single user traffic samples 290 130 273 128 Avg. nr. of bursts per sample 805.6 5242.8 276.6 1173.8 Without unit root, both 217 121 206 108 % w/o unit root, both 74.8 93.0 75.4 84.3 Avg. nr. of bursts per sample w/o unit root 1072.6 5631.3 364.5 1387.2 A. Data resolution effects on results When trying to analyze network traffic, the ideal is to have data with exact timestamps and sizes of packets. However, the best available dataset that we can use comes with its own limitations. The reason why NetSense traffic data was collected at only 60-second intervals, is that collecting data at higher resolution quickly drains the batteries of smartphones. Thus, before we start analyzing the results of our ADF tests, we discuss the potential effect of 60-second data resolution on our results. As it stands, if the test finds a unit root at 60-second resolution, then it means that even at the most precise resolution the unit root will still be present. However, if the test rules out the existence of a unit root at 60-second resolution, the unit root might still appear at higher resolutions. This means the following for our test results: If the test shows that a traffic trace is not predictable (e.g. ADF test p-value larger than 0.001) at 60-second resolution, then it cannot be predictable, even if we knew the exact packet arrival times and sizes. If the test shows that a traffic trace might be predictable at 60-second resolution (e.g. ADF test p- value smaller than 0.001), then it might become unpredictable at higher resolution. Thus, the test might show that the 60-second resolution traffic trace is predictable, whereas the actual traffic was unpredictable. Another important issue to consider is whether 60-second resolution introduces prediction bias to our results. Consider the case where most packet transmissions would occur with an interval of less than 60 seconds. This means that the traffic samples would contain a large number of datapoints with intervals of exactly 60 seconds. If there is more than half of such intervals per sample, it creates a bias in predictability test as there is a larger than random chance of exactly 60 second intervals between datapoints. Thus, we must account for resolution bias in our predictability tests. To do that, we exclude datapoints with exactly 60 second intervals from the traffic traces and analyze whether the predictability of traffic traces changes significantly in separate tests. B. Single app network traffic predictability Our first attempt to test the predictability of single app traffic, both Tx and Rx, reveals that 28% to 32% of samples exhibit a long-term trend in both timing and burst size (see Table III, samples without a unit root vs. total number of samples). However, after we take into account the potential resolution bias mentioned earlier, the number of traffic samples decreases significantly for both datasets to approximately half of the initial number, while the number of traffic traces without a unit root decreases to only approximately 16% of the modified sample set. The number of traffic traces that exhibit a long-term trend decreases even more significantly to only a fraction of the initial unmodified sample set. Out of the traffic samples that do show a long-term trend, our analysis found that they tend to be longer than the average sample length. Our attempts to predict traffic for a single app using the ARIMA model did not give any positive results. The ARIMA prediction always lags in its estimate for the next packet transmission. This is likely due to traffic traces having longterm trends, as discovered by the ADF test, but not being predictable on a short time scale. C. Single user network traffic predictability Testing single user traffic traces, both Tx and Rx, shows a high percentage of samples with long-term trends (see Table IV). Interestingly, when we take into account resolution bias, the number of samples exhibiting long-term trends does not decrease, except for significant decreases in average sample sizes. The cause is the much longer average size of user traffic traces compared with application traffic traces. As we noted before, samples without a unit root tend to be longer than average. Single user traffic traces are more likely to exhibit longterm trends, as verified by the ADF test. Nevertheless, the ARIMA model fitting does not produce any positive results regarding short-term traffic predictability. Our results show that short-term (1-5 future bursts) predictions based on 50-100 burst samples had large forecast errors. For example, predicting the packet size of the next 5 bursts in a sample with a mean of 465409.8 bytes had a forecast error mean of 72979.76 bytes (see Fig. 3). Thus, we conclude, based on our analysis of NetSense data, that network traffic transmissions from a single user (single device) are not predictable in the short-term. D. Multi-app scenarios Existing traffic scheduling schemes often work with a single application, even though there might be multiple applications transmitting traffic at the same time. This means that the benefits of one scheduled application might be lost if other

Fig. 3. ARIMA model burst size forecast error distribution for a single user traffic trace (sample size 50, mean 465409.8 bytes, forecast for next 5). Forecast error mean 72979 bytes. applications transmit at the same time, thus waking up the WNI. We also analyze the traffic traces for single users and find that on average 5.07 applications use the WNI in one direction during a 60-second interval. Also, on average, only 33.37% of bursts contain traffic from a single application. Thus, we can conclude that most of the time multiple applications use a single WNI concurrently. VI. DISCUSSION Our analysis demonstrates that most of the energy on the WNI is used by Android background services, media apps and Facebook in particular. These apps and their traffic shape are an interesting target for improvements in energy efficiency. The traffic scheduling schemes that we surveyed tend to focus on bulk transfer apps, such as video streaming, while some addressed the frequent WNI wake-ups caused by background updates of apps. Although it might be tempting to try to predict and optimize the traffic shape of a single app, such an approach cannot yield good results in unpredictable multi-app scenarios. Among the traffic scheduling schemes, there are few that target all of the traffic transmitted on a device. On the other hand, most of the schemes target specific apps, which begs the question of how effectively they can perform in multi-app scenarios. One could suggest that several single-app scheduling schemes might be combined into a system-level solution to achieve energy savings in multi-app scenarios. However, we have not found examples of such work in the literature and we do not consider such a solution practical. Using several scheduling schemes on the same device would likely cause computational overhead that would negate potential savings. Our attempts at per app traffic prediction did not yield positive results. Our analysis mostly focused on shorter predictability intervals, thus leaving out seasonality in longer dayto-day intervals. Nevertheless, the ADF test functions well for finding potential long-term trends among app and user traffic. Although there exists a large body of work on network traffic prediction, there is still lack of work on real smartphone traffic data with the focus on analyzing its predictability in the short- and long-term. Therefore, future work on traffic scheduling schemes that relies on traffic being predictable, should carefully consider this assumption. It should be noted that even if traffic from a single app might be predictable, multi-app traffic from a single device is most likely not. In our opinion, this is the most important implication to consider when designing traffic scheduling schemes. We also noted that performance evaluations of traffic scheduling schemes are lacking at the moment. Networkingrelated research requires extensive performance evaluation from the perspective of the network stack, CPU, memory etc., while protocols should be additionally evaluated from the theoretical (algorithmic) point of view [18], [19]. From the surveyed literature, the proposed solutions were evaluated mostly from a few aspects, such as total energy savings, while at the same time comparison to existing solutions was lacking. One problematic aspect is that evaluation of each scheduling scheme is done with different network traffic datasets, which makes comparison between different solutions difficult. Future traffic scheduling work should include performance evaluation of various proposed solutions with the same experimentational data to ensure thorough comparison. VII. CONCLUSIONS Our goal was to analyze traffic scheduling schemes and find out what kind of common assumptions and approaches they share. We found that a number of scheduling schemes focus on improving the energy efficiency of a single specific app or app category. Also, significant number of scheduling schemes assumed that traffic can be predictable, making it more suitable for scheduling. To test these assumptions, we conducted an analysis of traffic data collected from a largescale real-world smartphone usage study. We analyzed the dataset provided by the NetSense study and found that background processes, media streaming apps and Facebook were frequently performing network transmissions and contributed most of the volume and energy spent on the WNI. Since these apps are a good target to improve energy efficiency through traffic scheduling and prediction, we analyzed whether their traffic profiles were predictable or not. We found that although 20-30% of traffic traces did not contain a unit root (thus having a long-time trend), they did not either show significant shortterm predictability upon further ARIMA tests. Furthermore, we found that compounded network traffic from a single user is unpredictable since applications with unpredictable traffic profiles dominate the overall traffic. We believe that our findings carry important implications for future work on traffic scheduling schemes. Namely, traffic scheduling schemes should focus on multi-app (whole device traffic) scenarios. Furthermore, if a traffic scheduling scheme assumes traffic predictability in short or long time-intervals, a strong argument should be presented why this assumption holds. ACKNOWLEDGMENTS We would like to thank the NetScale Lab from University of Notre Dame and personally Dr. Aaron Striegel for giving us early access to the NetSense Project data. This work was supported by the Academy of Finland, grants number 268096 and 278207.

REFERENCES [1] A. Carroll and G. Heiser, An analysis of power consumption in a smartphone, in Proceedings of the 2010 USENIX Conference on USENIX Annual Technical Conference, ser. USENIXATC 10. Berkeley, CA, USA: USENIX Association, 2010, pp. 21 21. [Online]. Available: http://dl.acm.org/citation.cfm?id=1855840.1855861 [2] V. Looga, Y. Xiao, Z. Ou, and A. Ylä-Jääski, Exploiting traffic scheduling mechanisms to reduce transmission cost on mobile devices, in Wireless Communications and Networking Conference (WCNC), 2012 IEEE, April 2012, pp. 1766 1770. [3] S. V. Rajaraman, M. Siekkinen, V. Virkki, and J. Torsner, Bundling frames to save energy while streaming video from lte mobile device, in Proceedings of the Eighth ACM International Workshop on Mobility in the Evolving Internet Architecture, ser. MobiArch 13. New York, NY, USA: ACM, 2013, pp. 35 40. [Online]. Available: http://doi.acm.org/10.1145/2505906.2505913 [4] F. R. Dogar, P. Steenkiste, and K. Papagiannaki, Catnap: Exploiting high bandwidth wireless interfaces to save energy for mobile devices, in Proceedings of the 8th International Conference on Mobile Systems, Applications, and Services, ser. MobiSys 10. New York, NY, USA: ACM, 2010, pp. 107 122. [Online]. Available: http://doi.acm.org/10.1145/1814433.1814446 [5] Y. Wei, S. Bhandarkar, and S. Chandra, A client-side statistical prediction scheme for energy aware multimedia data streaming, Multimedia, IEEE Transactions on, vol. 8, no. 4, pp. 866 874, Aug 2006. [6] Y. Xiao, Y. Cui, P. Savolainen, M. Siekkinen, A. Wang, L. Yang, A. Ylä-Jääski, and S. Tarkoma, Modeling energy consumption of data transmission over wi-fi, IEEE Transactions on Mobile Computing, vol. 99, no. PrePrints, p. 1, 2013. [7] S. Liu and A. Striegel, Casting doubts on the viability of wifi offloading, in Proceedings of the 2012 ACM SIGCOMM Workshop on Cellular Networks: Operations, Challenges, and Future Design, ser. CellNet 12. New York, NY, USA: ACM, 2012, pp. 25 30. [Online]. Available: http://doi.acm.org/10.1145/2342468.2342475 [8] University of Notre Dame. (2013, Jul.) NetSense Project. [Online]. Available: http://netsense.nd.edu [9] Y.-W. Cheung and K. S. Lai, Lag Order and Critical Values of the Augmented Dickey-Fuller Test, Journal of Business and Economic Statistics, vol. 13, no. 3, pp. 277 280, 1995. [Online]. Available: http://amstat.tandfonline.com/doi/abs/10.1080/07350015.1995.10524601 [10] Z. Ou, J. Dong, S. Dong, J. Wu, A. Yla-Ylä-Jääski, H. Pan, R. Wang, and A. Min, Utilize signal traces from others? a crowdsourcing perspective of energy saving in cellular data communication, Mobile Computing, IEEE Transactions on, vol. PP, no. 99, pp. 1 1, 2014. [11] F. Xu, Y. Liu, T. Moscibroda, R. Chandra, L. Jin, Y. Zhang, and Q. Li, Optimizing background email sync on smartphones, Proceeding of the 11th annual international conference on Mobile systems, applications, and services - MobiSys 13, p. 55, 2013. [Online]. Available: http://dl.acm.org/citation.cfm?doid=2462456.2464444 [12] A. J. Pyles, Z. Ren, G. Zhou, and X. Liu, Sifi: Exploiting voip silence for wifi energy savings insmart phones, in Proceedings of the 13th International Conference on Ubiquitous Computing, ser. UbiComp 11. New York, NY, USA: ACM, 2011, pp. 325 334. [Online]. Available: http://doi.acm.org/10.1145/2030112.2030157 [13] Y. Liu, F. Li, L. Guo, Y. Guo, and S. Chen, Bluestreaming: Towards power-efficient internet p2p streaming to mobile devices, in Proceedings of the 19th ACM International Conference on Multimedia, ser. MM 11. New York, NY, USA: ACM, 2011, pp. 193 202. [Online]. Available: http://doi.acm.org/10.1145/2072298.2072325 [14] X. Li, M. Dong, Z. Ma, and F. C. Fernandes, Greentube: Power optimization for mobile videostreaming via dynamic cache management, in Proceedings of the 20th ACM International Conference on Multimedia, ser. MM 12. New York, NY, USA: ACM, 2012, pp. 279 288. [Online]. Available: http://doi.acm.org/10.1145/2393347.2393390 [15] J. Huang, F. Qian, Z. M. Mao, S. Sen, and O. Spatscheck, Screen-off traffic characterization and optimization in 3G/4G networks, Proceedings of the 2012 ACM conference on Internet measurement conference - IMC 12, p. 357, 2012. [Online]. Available: http://dl.acm.org/citation.cfm?doid=2398776.2398813 [16] Y. Xiao, P. Savolainen, A. Karppanen, M. Siekkinen, and A. Ylä- Jääski, Practical power modeling of data transmission over 802.11g for wireless applications, in Proceedings of the 1st International Conference on Energy-Efficient Computing and Networking, ser. e-energy 10. New York, NY, USA: ACM, 2010, pp. 75 84. [Online]. Available: http://doi.acm.org/10.1145/1791314.1791326 [17] V. E. Johnson, Revised standards for statistical evidence, Proceedings of the National Academy of Sciences, vol. 110, no. 48, pp. 19 313 19 317, 2013. [Online]. Available: http://www.pnas.org/content/110/48/19313.abstract [18] Z. Ou, H. Zhuang, A. Lukyanenko, J. Nurminen, P. Hui, V. Mazalov, and A. Ylä-Jääski, Is the Same Instance Type Created Equal? Exploiting Heterogeneity of Public Clouds, Cloud Computing, IEEE Transactions on, vol. 1, no. 2, pp. 201 214, July 2013. [19] Z. Ou, E. Harjula, T. Koskela, and M. Ylianttila, GTPP: General Truncated Pyramid Peer-to-Peer Architecture over Structured DHT Networks, Mobile Networks and Applications, vol. 15, no. 5, pp. 729 749, 2010. [Online]. Available: http://dx.doi.org/10.1007/s11036-009-0193-2