Dhrystone million instructions per second–based task offloading from smartwatch to smartphone

Abstract

Wearable devices such as smartwatches are critical to energy consumption due to their small battery size. To reduce possible energy consumption for high computational tasks, task offloading is a solution, but smartwatches are usually connected to smartphones that are also exposed to energy-saving issues. To resolve this problem, we propose a task offloading model that compares the energy efficiency of two cases: offloading or no offloading. When a task is offloaded, energy of a smartphone is sacrificed instead of a smartwatch, and additional energy is used for the communication. To derive the condition of an offloading, the size of a task could be considered, but it is impossible to estimate accurate energy due to various computational specifications of smartphones as well as smartwatches. To generalize the task size for different CPU conditions, we propose to use Dhrystone million instructions per second. The proposed model was evaluated through our testbed and confirmed that it shows a reasonable offloading condition for both the smartphone and the smartwatch.

Keywords

Wearable device power management offloading Dhrystone million instructions per second dual offloading decisions

Introduction

With the popularity of smart devices such as smartphones, wearable appliances have gained more attention, and their number is estimated to reach 274.6 million units in 2016. Recently, wearable devices for augmented reality or virtual reality such as Google’s Glass and Microsoft’s Hololens attract customers’ attention. Despite the popularity of wearable devices, they are facing technical challenges for computational issues as well as wireless communications. Since various sensors, for example, a camera and a heart rate sensor, are attached to a wearable device, more computations need to be executed in the wearable device; that is, the amount of work for processing data is gradually increasing as the amount of measured information from the sensors is increased.

Wearable devices, however, have limitations in battery and computational power. In particular, smartwatches have a disadvantage that it is difficult to handle many computational tasks because of the lack of computing resources than smartphones due to its inherent nature in size and weight. In order to overcome this problem, research has been conducted to offload the tasks to external resources such as smartphones or cloud systems using network connection, which is called task offloading. In this article, we investigate task offloading from wearable to smartphones (more generally mobile systems) for energy saving because wearable devices are usually connected to a smartphone. This is different to existing work that usually focuses on task offloading from wearable to server/cloud systems.

However, both the wearable and mobile systems are exposed to battery issues; therefore, it is of great importance to find the optimal size of a task for offloading. Wearable and mobile devices are connected through wireless communication such as Bluetooth. Since smartphones also have limited battery resources, if offloading is performed irrespective of the status of smartphones, the remaining battery power of smartphones will become insufficient, and the usability of the user will be lowered. Furthermore, since smartphones compute instead of smartwatches, the battery condition of smartphones must be taken into consideration in the offloading request. Therefore, in order to overcome the limitations mentioned above, smartphones should also have a module of offload decision. In this article, we propose a task offloading algorithm for both a smartwatch and a smartphone, where DMIPS (Dhrystone million instructions per second) is adopted to consider the size of a task generally, irrespective of the kind of hardware. We implemented a testbed for evaluation and confirmed that the energy consumption of a smartwatch is reduced when the proposed offloading algorithm is used to offload the smartphone.

The remainder of this article is organized as follows. Section “Background” presents previous work related to task offloading and existing methods of measuring processor performance. In section “The proposed offloading architecture,” we illustrate the difference between existing and proposed offloading architecture. In section “Offloading decision model,” we propose our offloading decision model that considers the energy of both a smartphone and a smartwatch as well as the communication energy. In section “Evaluation results,” we describe the testbed implementation and exhibit our experimental results. Finally, in section “Conclusion,” we conclude.

Background

Related work

Chun et al.¹ proposed CloneCloud, which consists of static analyzer, dynamic profiler, and optimization solver. This article proposes a method to divide a mobile device and a cloud server into a module of execution of an application and sends a task of a mobile application divided into a server environment in which a virtual machine is installed. Cuervo et al.² proposed a MAUI architecture that consists of proxy, profiler, and solver. The profiler uses device profile, program profile, and network profile to determine whether to invoke the method call locally or remotely. In addition, the solver establishes an optimized partitioning strategy based on energy consumption and latency, and the proxy located on the server side extracts the remote method and executes it. They aim to minimize modifications to the target application and offload it to resource-rich server nodes to increase the energy efficiency of mobile devices.

Kosta et al.³ proposed ThinkAir framework that supports on-demand resource allocation for different requests of mobile device users. The ThinkAir framework on the cloud server consists of program profile, client handler, and dynamic object input stream. Profiler is divided into hardware profiler, software profiler, and network profiler to estimate the amount of energy consumed by each part so that efficient offloading can take place. Shi et al.⁴ proposed COSMOS (computation offloading as a service for mobile devices) system that manages the resources of a cloud and efficiently allocates and schedules tasks. In particular, COSMOS used the average and standard deviation values based on the distribution to determine offloading of the task by controlling the risk of mobile network connection, program execution, and resource contention.

Altamimi et al.⁵ measured the energy consumed in offloading based on four scenarios depending on where the task data existed and where it was executed. In particular, energy cost model for downloading and uploading task data is presented, and the energy consumed when using third generation (3G) and fourth generation (4G) networks is analyzed. Cheng et al.⁶ showed an architecture consisting of three layers: wearable, mobile, and cloud server to reduce the difference between resource demand and supply on wearable devices. In particular, they proposed a fast heuristic algorithm based on genetic algorithms to maximize the number of tasks that must be executed immediately due to the nature of wearable devices. Here, for all crossover and mutation operations in each offspring chromosome, all the offspring chromosome operations are checked to prevent any problems that may occur.

Kumar and Lu⁷ pointed out the problems of hardware resource limitation such as battery and computing resources caused by the small size of mobile devices and defined by battery usage–related metrics. This study shows the performance and power efficiency improvements when applying offloading vertically. In addition to the above-mentioned research, it is found that offloading is performed for improving performance or reducing power consumption,^8–10 or offloading execution environment; and the operation of applications is considered.^11–13

Previous studies, including the ones described above, have presented offloading cost models using factors such as the size of the job to be offloaded, the environment of the network, and how to divide the work efficiently to request offloading. Although our work is similar to the offloading cost model using various factors, the differences between our work and previous studies are summarized as follows. First, the study of Chun et al.¹ and Cuervo et al.² considers the division of offloaded jobs, which does not work for various hardware systems. To resolve such an issue, we replace it with DMIPS. In addition, Kosta et al.³ and Shi et al.⁴ have a limit in that they are not suitable for servers with limited resource because they present a cost model for offloading to a cloud server with unlimited resources. While the study of Altamimi et al.⁵ considers 3G and 4G networks, our work considers offloading cost in Bluetooth environment. In the study of Kumar and Lu,⁷ improvement in performance and power efficiency is shown for offloading to a relatively resource-rich place.

Classification of offloading techniques

When offloading is performed to process a job, overhead due to offloading execution generally occurs. In this case, there are two criteria, that is, the amount of work to be offloaded and the amount of workload, considering factors that affect overhead. First, it affects runtime overhead in case the amount of work to be offloaded is transferred in advance or dynamically transferred whenever necessary. The case of offloading beforehand is referred to as static offloading, and the case of offloading as necessary is classified as dynamic offloading. Also, in case of the amount of workload to be offloaded, since the workload is transmitted through the network, the smaller the size, the more the network overhead is reduced. Considering this, it is possible to offload the entire workload or only a part of the workload. The total offloading of the entire workload is classified as full offloading. In contrast, in partial offloading, a part of workload is offloaded. Figure 1 shows the result of the classification divided by the two criteria.

Figure 1.

Four types of offloading scheme.

Measuring processor performance

MIPS (million instructions per second) is a unit that represents the performance of a computer processor. Normal MIPS shows the highest execution speed in ideal jobs with few branches, but MIPS values in realistic workloads where branches occur can be relatively low. Another disadvantage is that other factors, such as the memory layer, which are not directly considered in MIPS calculations, can have a significant impact on processor performance. In addition, MIPS depends on the architecture of the processor, so it is not suitable for comparing processors with different architectures. Due to these problems, a comprehensive application benchmark program such as Dhrystone is used for performance evaluation of the processor, and simply MIPS is not used. Hence, in this article, we use DMIPS instead of MIPS.

DMIPS is a unit that evaluates performance based on the time it takes to execute a Dhrystone instruction program on a processor and process it. Compared to MIPS, benchmark applications do not depend on the architecture of the processor by making measurements, so they can compare and evaluate processors with different architectures. DMIPS for a given machine represents the relative speed at which a VAX 11/780 (1 MIPS machine) should be run to complete benchmark application performance within the same time as the machine being measured. For example, a 100-MHz CPU running a benchmark application 200 times faster than a VAX 11/780 would be considered a 200-DMIPS machine. For CPUs that can be run at various frequencies, DMIPS divided by MHz, such as 200 DMIPS/MHz, may be used.

The proposed offloading architecture

The goal of our work is to reduce the energy consumption of wearable devices. In our work, we consider a system model where the task of a smartwatch is offloaded to a smartphone using DMIPS in the process. A smartwatch and a smartphone are connected through Bluetooth, 3G/long-term evolution (LTE), or WiFi where communication is used to transmit the information required for offloading and the result of offloading. In practice, Bluetooth is more energy efficient; so it is considered for our testbed. Instead of using a cloud server, a smartphone with a rich resource status is used instead of a smartwatch. However, the resource status of a smartphone as a mobile device is also limited. If the smartphone becomes disabled due to a battery shortage, the usability of the smartphone is lowered for a user. In order to prevent this, we propose a mechanism that accepts offloading requests and processes work only when the resource status of a smartphone is sufficient.

Unlike the conventional method in which there is an offloading decision only in the place where the offloading is requested, in the proposed method, both the offloading requesting side and the receiving side have an offloading decision module. Using such a double offloading decision technique, a smartphone can decide whether or not the offloading request should be accepted in consideration of its own resource state. The procedures of existing and proposed task offloading methods are seen in Figures 2 and 3, respectively.

Figure 2.

Procedure of general task offloading.

Figure 3.

Procedure of the proposed task offloading.

In Figure 3, given a task with a smartwatch, the work is analyzed through modeling, and its size is shown in the form of DMIPS. In the offloading decision module of a smartwatch, the offloading request is made in consideration of the energy consumed in the Bluetooth communication and the standby energy, and the energy consumed in the self operation. When the offloading request is made to the smartphone, the smartphone compares the current battery state with the offloading request and determines whether to accept the offloading request. The smartwatch analyzes the response message from the smartphone in the offloading manager and decides whether to send the result of the operation or to calculate it by itself. According to the offloading classification mentioned above, the proposed scheme can be classified as a static full offloading scheme.

Offloading decision model

In the smartwatch, the energy consumed when the work is processed without offloading according to the size of the work may be less than the energy consumed when offloading. In a smartphone acting as a server, the remaining battery should be compared with the expected energy consumption in accepting the offloading request, and then the acceptance of the offloading request should be determined. This section presents a DMIPS model that can be used to determine the size of a program without relying on hardware. We also propose a model for the offloading decision on both a smartwatch and a smartphone using DMIPS.

DMIPS measurement model

The size of a given task can be expressed in DMIPS form using the following formula

D M I P S = \frac{D M I P S_{a v g}}{C P U_{u s a g e_d m i p s}} \times C P U_{u s a g e_t a s k} \times t_{t a s k}

(1)

where $D M I P S_{a v g}$ and $C P U_{u s a g e_d m i p s}$ mean the DMIPS result and the CPU utilization at the time when executing the application to obtain DMIPS, respectively. Here, $C P U_{u s a g e_t a s k}$ is the CPU usage rate for performing the task, and $t_{t a s k}$ is the time for performing the task. DMIPS can be calculated for a given task by dividing the average DMIPS by the CPU utilization to obtain DMIPS per CPU utilization (%) and then multiplying the CPU utilization and time when the operation is performed.

Offloading decision model in smartwatch

The offloading decision model in the smartwatch is made by comparing the energy consumption when the operation is processed by itself and the energy consumption when the offloading is requested without offloading. First, the energy consumption when the local operation is performed without requesting the offloading is calculated as follows

E_{l o c a l} = E_{d m i p s_l} \times D M I P S

(2)

where $E_{local}$ and $E_{dmip_l}$ mean the energy consumption when the task is executed locally and energy consumption per DMIPS, respectively. Here, DMIPS indicates the size of the task.

When the offloading is requested to the smartphone (server), the energy consumption of the smartwatch can be expressed as follows

t_{t a s k_s} = \frac{D M I P S \times C P U_{u s a g e_d m i p s_s}}{D M I P S_{a v g_s} \times C P U_{u s a g e_m e t h o d_s}}

(3)

E_{o f f l o a d i n g} = E_{w a i t_l} \times t_{t a s k_s} + E_{b l u e t o o t h}

(4)

First, the time, $t_{task_s}$ , required to process the job that is offloaded from the server is measured through equation (3). In equation (3), $DMIPS$ is the DMIPS value of the task to be processed obtained from equation (1). Here, $CP U_{usage_dimps_s}$ and $CP U_{usage_method_s}$ mean the CPU usage rate in processing the work on the server. $DMI P_{avg_s}$ represents the average DMIPS value in the server. After substituting the result obtained by equation (3) into equation (4), the energy consumption $E_{offloading}$ in the smartwatch is calculated by multiplying the standby energy per second of the smartwatch, $E_{wait_l}$ , by the standby time, $t_{task_s}$ , plus the energy consumption $E_{bluetooth}$ for Bluetooth communication.

Finally, offloading can be determined by comparing $E_{local}$ and $E_{of floading}$ values obtained from equations (2) and (4) as follows

\begin{array}{l} If E_{l o c a l} \geq E_{o f f l o a d i n g}, request of floading \\ If E_{l o c a l} < E_{o f f l o a d i n g}, local computation \end{array}

(5)

If the energy consumption $E_{local}$ when the work is processed locally without offloading is higher than the consumed energy $E_{offloading}$ when offloading, offloading is requested. Otherwise, the work is processed by itself without offloading.

Offloading decision model in smartphone

The model that determines whether an offloading request from a smartphone is accepted by a smartphone is made by comparing the amount of battery remaining on the current smartphone with the amount of energy consumed when the offloading request is accepted. The expected energy consumption, $E_{of floading_s}$ , when accepting the offloading request is given as follows

E_{o f f l o a d i n g_s} = E_{d m i p s_s} \times D M I P S + E_{b l u e t o o t h}

(6)

where $E_{dmips_s}$ represents the energy consumption per DMIPS, and $DMIPS$ represents the size of the task calculated as the DMIPS value. $E_{of floading_s}$ obtained from the model of equation (6) is compared with a threshold value set for usability, and it can be determined whether offloading is accepted as follows

\begin{array}{l} If E_{o f f l o a d i n g_s} \geq T, disable of floading \\ If E_{o f f l o a d i n g_s} < T, enable of floading \end{array}

(7)

The offloading request is accepted if the energy consumption $E_{of floading_s}$ when accepting the offloading request is lower than the specific threshold value $T$ , and the offloading request is rejected if the power consumption $E_{of floading_s}$ is higher than $T$ .

Evaluation results

Test environment

To evaluate the proposed method, we set up an experiment testbed. We used smartwatches, smartphones, and tablets with Android operating system (OS) installed. Table 1 summarizes the specifications of the devices used in the experiment, focusing on the CPU, which is the most influential hardware component to process the work. To verify the characteristics of DMIPS that are not architecture-dependent, experiments were conducted using devices equipped with different CPUs. LG Urbane and LG Nexus 5 were connected to each other by Bluetooth pairing to confirm the reduction of energy consumption of a smartwatch when offloading. We measured the energy consumption of the smartwatch using the Monsoon Power Monitor. Figure 4 shows the connection between the Monsoon Power Monitor and LG Urbane.

Table 1.

Test devices’ specification.

Device Name	Type	CPU	Architecture	Performance (DMIPS/MHz)
LG Urbane	Smartwatch	Qualcomm Snapdragon 400 MSM8926	ARM Cortex-A7	1.9
LG Nexus 5	Smartphone	Qualcomm Snapdragon 800 MSM8974	Qualcomm Krait 400	3.39
ASUS Nexus 7	Tablet	Qualcomm Snapdragon S4 Pro APQ8064	Qualcomm Krait	3.3
Galaxy Note 5	Smartphone	Samsung Exynos 7420	ARM Cortex-A57	4.1–4.76

Figure 4.

Connection between Monsoon Power Monitor and LG Urbane.

In the experiment, two kinds of applications are used: a benchmark application¹⁴ for obtaining the DMIPS of an experimental instrument and an application that performs actual work. Because there is a difference between the estimated and actual performance in the specifications shown in Table 1, DMIPS is obtained using a benchmark application to obtain actual DMIPS. We chose the Tower of Hanoi as the application for offloading. The reason for this is that it requires an application that requires high computation processing without depending on the graphics processing capability of the device. In addition, since it is performed in the Bluetooth network environment, it is necessary to minimize the overhead of exchanging packets and to generate a high-level operation.

In this article, we propose a method to represent the amount of workload without hardware dependency and to decide the offloading request according to the resources of the server and the energy consumption when offloading. Therefore, the amount of workload is expressed in the form of DMIPS, and then we show the comparison of energy consumption between offloading and no offloading, and whether the offloading request is accepted according to the battery remaining amount of the smartphone.

DMIPS measurement result

Figures 5 –7 show the DMIPS value and the CPU usage when the benchmark application for DMIPS measurement is executed for LG Nexus5, ASUS Nexus 7, and Galaxy Note5 in the form of Boxplot. Each device was tested 40 times, and the CPU utilization and DMIPS measurement data were collected. The median value in each data set was used to reduce the influence of extreme values. As a result of the experiment, the median value of CPU usage and DMIP of each device were 40.225% and 2171 DMIPS/MHz for the LG Nexus 5, 45.727%, and 3427 DMIPS/MHz for the ASUS Nexus 7, 11.135% for the Galaxy Note 5 and 4913 DMIPS/MHz. It is analyzed that the hardware specification has lower CPU utilization and higher DMIPS for the devices with better CPUs.

Figure 5.

CPU usage and DMIPS measurement in Nexus 5 for DMIPS benchmark application: (a) CPU usage in Nexus 5 and (b) DMIPS in Nexus 5.

Figure 6.

CPU usage and DMIPS measurement in Nexus 7 for DMIPS benchmark application: (a) CPU usage in Nexus 7 and (b) DMIPS in Nexus 7.

Figure 7.

CPU usage and DMIPS measurement in Note 5 for DMIPS benchmark application: (a) CPU usage in Note 5 and (b) DMIPS in Note 5.

Figure 8 shows DMIPS as a function of the number of Hanoi disks for each mobile device. The DMIPS measurement values according to the number of cases are collected in equation (1) by substituting the DMIPS measurement value and the CPU utilization rate of each device with the execution time and the CPU usage rate when the Hanoi application is executed are collected. For the collected data, nonlinear regression analysis was performed using the least squares method, and the model for the number of Hanoi disks and DMIPS relation for each device was obtained.

Figure 8.

DMIPS as a function of the number of Hanoi tower disks for each mobile device.

Table 2 summarizes the results of the regression analysis using the least squares method. To obtain the model to be used in the experiment, the average of the three instruments was obtained. It can be seen that the DMIPS according to the number of disks increases proportionally with the exponential function, which is consistent with $O (2^{n})$ , the time complexity of Hanoi’s top algorithm. As the number of samples tested in this study, there was an error rate of about 8% between the model and the actual measured values. As the number of disks increases, higher computation is required.

Table 2.

DMIPS as a function of the number of disks with regression analysis.

Formula	Hanoi_DMIPS ~ aexp(bDisk) + c
		Estimate	Standard error	t value	Pr (>\|t\|)
LG Nexus 5	a	3.036e – 04	8.297e – 05	3.659	0.000433
	b	6.677e – 01	1.012e – 02	65.981	<2e – 16
	c	−1.669e + 02	6.920e + 01	−2.411	0.017997
ASUS Nexus 7	a	1.334e – 04	4.069e – 05	3.277	0.00151
	b	6.986e – 01	1.130e – 02	61.803	<2e – 16
	c	−7.243e + 01	7.260e + 01	−0.998	0.32120
Galaxy Note 5	a	2.844e – 05	1.462e – 05	1.946	0.0549
	b	7.557e – 01	1.904e – 02	39.682	<2e – 16
	c	−5.163e + 01	1.076e + 02	−0.483	0.6306

DMIPS: Dhrystone million instructions per second.

Offloading power consumption measurement result

Before measuring the energy consumption during offloading, the relationship between the DMIPS and the energy consumption of the device should be grasped in order to utilize the amount of the work obtained in the DMIPS form.

The relationship between DMIPS and energy consumption in the smartwatch (LG Urbane) and the smartphone (LG Nexus5) is shown in equations (4) and (6), and the model can be obtained by linear regression analysis between DMIPS and energy consumption. The correlation coefficients between DMIPS and energy consumption of LG Urbane and LG Nexus 5 are positively correlated with 0.9925161 and 0.95211298, respectively. Figure 9 is a graphical representation of the model from the linear regression analysis. For the same DMIPS, the Nexus 5 consumes more power than the Urbane because it is affected by the amount of power consumed on each device’s screen (4.95 and 1.3 in). And the difference in the amount of power consumed to process one DMIPS in the CPU mounted on the device may also be a reason.

Figure 9.

Power consumption as a function of DMIPS.

Figure 10 is a graphical representation of the power consumption of the LG Urbane with and without offloading workloads with DMIPS sizes. As in equation (5), DMIPS $(α)$ at the intersection of the two graphs is used as a reference value. If the DMIPS is smaller than the reference value, the power efficiency is better when offloading is not performed. This is because the overhead involved in sending offloading requests to the smartphone using Bluetooth communication and receiving the result of the operation will affect the offloading decision.

Figure 10.

Comparison of power consumption with and without offloading.

As shown in equation (7), the smartphone determines whether to accept the offloading request according to the magnitude of the estimated power consumption when the offloaded job is processed. In Figure 11, if the expected power consumption based on the threshold value $(τ)$ is bigger than the reference, it rejects the offloading request and accepts it otherwise.

Figure 11.

Accepting offloading requests on a smartphone based on the threshold value.

Conclusion

In order to solve the limited battery problem caused by the small size of the mobile device, this study proposed a method of reducing the energy consumption of the smartwatch using an offloading technique. Unlike the existing offloading method, a smartphone is used as a server instead of the cloud server having unlimited resources. Because of the difference, we considered the resource state of the smartphone that occurred, and we considered a common method that could be used to represent workload on two different hardware devices.

In this article, we propose a mechanism to reveal the condition of accepting offloading considering the status of a smartphone. This was done by putting offloading modules to both a smartwatch and a smartphone. In addition, the size of the work to be processed for the offloading decision is represented by DMIPS, which is not dependent on the architecture, so that the analysis of the work is done using a unified model in mobile devices with various CPUs.

For future work, when setting a threshold value for determining whether to accept an offloading request from a smartphone, it is necessary to conduct further research to consider the amount of future use based on the remaining battery of the smartphone and the number of running applications. In addition, another step of offloading to the cloud server is made possible by utilizing abundant opportunities of connections of the smartphone using 3G/LTE and WiFi. So it is possible to extend the proposed method using external resources. Also, if offloading does not allocate the total workload to the server, the operation is divided, and the operation is performed in both the smartwatch and the smartphone, which is expected to be more usable and more power efficient.

Footnotes

Handling Editor: An Liu

Declaration of conflicting interests

The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This research was supported by the Ministry of Science, ICT & Future Planning (MISP), Korea, under the National Program for Excellence in SW supervised by the Institute for Information & communications Technology Promotion (IITP) (2015-0-00908) and Basic Science Research Program through the National Research Foundation of Korea (NRF) funded by the Ministry of Education (2015R1D1A1A01058025).

References

Chun

Ihm

Maniatis

et al . Clonecloud: elastic execution between mobile device and cloud. In: Proceedings of the sixth conference on computer systems, Salzburg, 10–13 April 2011. New York: ACM.

Cuervo

Balasubramanian

Cho

et al . MAUI: making smartphones last longer with code offload. In: Proceedings of the 8th international conference on mobile systems, applications, and services, San Francisco, CA, 15–18 June 2010. New York: ACM.

Kosta

Aucinas

Hui

et al . ThinkAir: dynamic resource allocation and parallel execution in the cloud for mobile code offloading. In: 2012 proceedings IEEE INFOCOM, Orlando, FL, 25–30 March 2012. New York: IEEE.

Shi

Habak

Pandurangan

et al . Cosmos: computation offloading as a service for mobile devices. In: Proceedings of the 15th ACM international symposium on mobile ad hoc networking and computing, Philadelphia, PA, 11–14 August 2014. New York: ACM.

Altamimi

Abdrabou

Naik

et al . Energy cost models of smartphones for task offloading to the cloud. IEEE Trans Emerg Top Comput 2015; 3: 384–398.

Cheng

Wang

et al . Just-in-time code offloading for wearable computing. IEEE Trans Emerg Top Comput 2015; 3: 74–83.

Kumar

YH.

Cloud computing for mobile users: can offloading computation save energy?

Comput 2010; 43(4): 51–56.

Chen

Kang

Kandemir

et al . Studying energy trade offs in offloading computation/compilation in Java-enabled mobile devices. IEEE T Parall Distr 2004; 15(9): 795–809.

Hong

Kumar

. Energy efficient content-based image retrieval for mobile systems. In: Proceedings of the 2009 IEEE international symposium on circuits and systems, Taipei, Taiwan, 24–27 May 2009. New York: IEEE.

10.

O’Hara

Nathuji

Raj

et al . Autopower: toward energy-aware software systems for distributed mobile robots. In: Proceedings of the 2006 IEEE international conference on robotics and automation, Orlando, FL, 15–19 May 2006. New York: IEEE.

11.

Nahrstedt

Messer

et al . Adaptive offloading inference for delivering applications in pervasive computing environments. In: Proceedings of the first IEEE international conference on pervasive computing and communications, Fort Worth, TX, 26 March 2003. New York: IEEE.

12.

Gurun

Chandra

Rich

. NWSLite: a light-weight prediction utility for mobile devices. In: Proceedings of the 2nd international conference on mobile systems, applications, and services, Boston, MA, 6–9 June 2004. New York: ACM.

13.

Huerta-Canepa

Lee

. An adaptable application offloading scheme based on application behavior. In: Proceedings of the 22nd international conference on advanced information networking and applications-workshops, Okinawa, Japan, 25–28 March 2008. New York: IEEE.

14.

http://www.roylongbottom.org.uk/