Phone2Cloud: Exploiting Computation Offloading for Energy Saving on Smartphones in Mobile Cloud Computing

1 Introduction

• Resource-demanding applications place heavy workloads on processors, wireless interfaces, and displays, causing significant energy costs.Source: §1 · p. 1
• Battery technology and energy-saving solutions have not kept pace with rising energy demand, while thinner smartphones imply smaller batteries and lower capacity.Source: §1 · pp. 1–2
• Phone2Cloud offloads all or part of smartphone application computation to the cloud to conserve energy, reduce execution time, and improve user experience.Source: §1 · p. 2
• The system uses a modified offloading-decision algorithm that incorporates the user’s delay-tolerance threshold, and the authors report two experiment types demonstrating its superiority.Source: §1 · p. 2

2 Related work

• Prior work spans battery and energy-cost models, techniques that avoid energy waste through sleep states, and methods for reducing communication energy.The communication approaches include interface shutdown, switching between Wi-Fi and Bluetooth, and predicting Wi-Fi availability.Source: §2 · p. 2
• Computation offloading migrates computation-intensive tasks from mobile devices to servers or clouds to save energy on the device.Source: §2 · p. 2
• The cited cloud-offloading literature includes quantitative analyses, but the authors identify extensive quantitative analysis and consideration of users’ delay-tolerance thresholds as remaining gaps.Source: §2 · p. 3
• Phone2Cloud develops an offloading system, quantitatively analyzes its energy savings, and considers users’ delay-tolerance thresholds.Source: §2 · p. 3

3 System architecture

• The architecture has seven components, with an extensible offloading decision engine at its core.Fig. 1 presents the Phone2Cloud architecture.Source: §3 · p. 3, Figure 1 · p. 3

3.1 Bandwidth monitor and resource monitor

• The bandwidth monitor predicts average network bandwidth, while the resource monitor tracks smartphone status and predicts average CPU workload.Source: §3.1 · p. 3

3.2 Execution time predictor

• The execution-time predictor estimates application runtime by finding the two nearest history-log entries using input size and predicted average CPU workload, then averaging their execution times.The log records application, input size, average CPU workload, and execution time.Source: §3.2 · p. 3

3.3 Offloading decision engine

• The decision engine uses current average bandwidth, predicted application runtime, and the Section 4.3 algorithm to choose local execution or cloud offloading.Source: §3.3 · p. 4

3.4 Offloading proxy

• The offloading proxy sends required input data to the remote manager, receives results, and delivers them to the application; the application must be manually modified for cloud execution.Phone2Cloud is therefore a semi-automatic offloading system.Source: §3.4 · p. 4
• The local execution manager runs applications through the smartphone operating system and logs execution information, while the remote manager executes offloaded computation and returns results.Source: §3.5 · p. 4

4 Algorithms

• Phone2Cloud’s algorithms include CPU workload prediction, bandwidth prediction, and an offloading-decision algorithm.The decision algorithm is the core method described in this section.Source: §4 · p. 4, §4.3 · p. 5

4.1 CPU workload prediction

• The execution-time predictor uses average CPU workload, application input size, and a history log to predict smartphone execution time.The resource monitor estimates average CPU workload with an exponential moving average (EMA) of periodically recorded CPU workload.Source: §4.1 · p. 4

4.2 Bandwidth prediction

• The bandwidth monitor uses EMA recursively to predict average bandwidth from periodic bandwidth readings.The bandwidth coefficient β has the same meaning as α, and N is the number of time periods.Source: §4.2 · p. 4

4.3 Offloading-decision making algorithm

• The decision algorithm first compares predicted execution time with the user’s delay-tolerance threshold, then compares local and cloud energy estimates.If predicted runtime exceeds the user threshold, it offloads immediately; otherwise, it offloads only when estimated cloud energy is no greater than local energy.Source: §4.3 · p. 5

4.3.1 Energy consumption on smartphone

• Local smartphone energy is estimated as processor active power multiplied by predicted application execution time.The equation defines Elocal as Pexec · Texec.Source: §4.3.1 · p. 5

4.3.2 Energy consumption on cloud

• Cloud energy includes smartphone energy for sending input, waiting for execution, and receiving results, under an assumption that the offloaded part is already on the cloud.The model bounds idle time by Texec/n, uses that maximum in experiments, and derives a trade-off energy from local and cloud estimates.Source: §4.3.2 · pp. 5–6

5.1 Experiment setup

• Experiments used three applications and a face-finder scenario, varying four factors; the Android phone connected over Wi-Fi to a Hadoop desktop cloud.The phone ran Android 2.2 on a 600MHz CPU, while the cloud ran Hadoop 0.20.2; applications required manual modification for offloading.Source: §5 · p. 6, §5.1 · p. 7, §5.2.1 · p. 7

5.2.1 Energy consumption

• With increasing input size, sort stayed local, path finder favored cloud offloading, and word count shifted toward cloud above 256KB.Phone2Cloud's own overhead made sort use slightly more power than local execution; for word count, transmitting inputs below 256KB cost more energy than local counting.Source: §5.2.1 · p. 8, Figure 4 · p. 9
• As bandwidth rose, sort remained local and path finder favored cloud; word count favored local execution below 600KB/s and cloud above it.For word count, the energy benefit of cloud offloading increased as bandwidth rose above 600KB/s.Source: §5.2.1 · p. 8, Figure 5 · p. 9
• Under CPU workload changes, sort favored local execution and path finder cloud offloading; word count favored cloud above 25%, while delay tolerance changed no application's energy use.For sort, the delay-tolerance threshold should exceed 90 milliseconds; path finder and word count were recommended for cloud offloading across thresholds.Source: Figure 6 · p. 9, §5.2.1 · p. 10

5.2.2 Execution time

• For execution time, sort favored local execution and path finder cloud offloading across input sizes; with bandwidth changes, Phone2Cloud offloaded word count only above 600KB/s.The cloud took longer than local execution for sort, but less time for path finder; the word-count decision also accounted for energy, although cloud execution could be faster above 230KB/s.Source: §5.2.2 · pp. 10, 12, Figure 8 · p. 11, Figure 9 · p. 11
• Cloud execution time stayed stable as CPU workload and delay tolerance changed; path finder was offloaded, while word count was local below 25% CPU workload and offloaded above it.Sort's local execution time was about 80 milliseconds, leading the authors to recommend a threshold greater than 90 milliseconds.Source: §5.2.2 · p. 12, Figure 10 · p. 13, Figure 11 · p. 13

5.3.1 Energy consumption

• In the face-finder scenario, cloud use favored energy as input size and CPU workload rose; energy favored offloading only above 50KB/s bandwidth, with delay tolerance recommended above 30 seconds.At bandwidth below 50KB/s, face finder used less energy locally than in the cloud.Source: Figure 12 · p. 13, §5.3.1 · pp. 13–14

5.3.2 Execution time

• Face finder took longer and grew faster locally than in the cloud; Phone2Cloud offloaded it, with bandwidth above 50KB/s and delay tolerance above 23 seconds identified as useful thresholds.The reported local execution time was about 23 seconds; cloud execution time decreased with increasing bandwidth, while local time had no relationship to bandwidth.Source: Figure 13 · p. 14, §5.3.2 · p. 14

• The experiments demonstrate that Phone2Cloud is effective at saving smartphone energy and improving application performance and user experience.Source: §6 · p. 14
• Phone2Cloud uses computation offloading to improve energy efficiency and application performance on smartphones.Source: §6 · p. 14
• Its execution-time predictor uses a naive approach that considers only CPU workload and input size.The authors say they plan to compare other prediction methods and factors in future work.Source: §6 · p. 14
• Phone2Cloud is semi-automatic, and further work is needed to make it fully automatic.Source: §6 · p. 14