Abstract
Due to the advancement of mobile technology, a large number of computationally intensive applications are created for smart phones. But the limitations of battery and processing power of smart phones are making it inferior to laptops and desktop computers. Mobile Cloud Offloading (MCO) allows the smart phones to offload computationally intensive tasks to the cloud, making it more effective in terms of energy, speed or both. Increased networking capacity due to the availability of high speed Wi-Fi and cellular connections like 3G/4G makes offloading more efficient. Even then, the choice of offloading is not always advisable, because of the highly dynamic context information of mobile devices and clouds. In this paper, we propose a dynamic decision making system, which will decide whether to offload or do the tasks locally, depending on the current context information and the optimization choice of the user. Metrics are developed for time, energy and combination of time and energy to assess the proposed system. A test bed is implemented and the results are showing improvements from the currently existing methods.
Keywords
Introduction
Smart devices like mobile phones and tablets are getting increasingly popular nowadays because of the rapid advancements in mobile and wireless communication technologies. These devices are equipped with lots sensors that assist the smart life of today’s younger generation. Along with this, the applications which can be used are also progressing in a dramatic way. Now the mobile applications are coming in abundance in various categories [6]. Gaming, virtual reality and social media applications are also being increasingly added and used in these devices. The data storage and processing power of these devices are also increasing.
These sophisticated and resource hungry applications are making our smart devices perform much weaker than what we expect. Even though the technology is advancing, the battery life and processing capacity is still a headache for the users. For example, if a person who is using the Smart phone is travelling constantly the charging of battery becomes a major concern for him. For some of the users, Quality of Experience (QoE) of the application is important, which they may not get with a resource poor device. In order to find a solution for these problems, the mobile devices can be augmented with cloud technology using Mobile Cloud Computing (MCC) [10]. In MCC, the smart phones are allowed to access the cloud resources to augment with the mobile capacity and make the application less energy consuming or less time consuming or both. Mobile Cloud Offloading is a technique, where the energy and time consuming tasks of the smart devices can be offloaded to the cloud for execution. Since the network access now is abundant everywhere, due to the Smart City Project of the Government, it can be used for connectivity between the cloud and the device. Technologies like Wi-Fi or cellular connectivity like 3G/4G/5G which offer fast connectivity can be used for the connectivity [5]. Due to the high bandwidth a low latency connection can be obtained with these connections.
Although a good number of offloading methods are available in literature, they do not consider the energy consumption in smart devices which happens while offloading. They also do not consider the dynamic choice from the user and what optimization they want. In our proposed work, the user decides whether he want time efficiency, energy efficiency or both depending on the current context. A decision for offloading is taken based on this choice. Regression method is used in this work and this result in reduced energy consumption and increased accuracy of the decision making. If a wrong decision of offloading is taken, it will eventually affect the QoE of the user and in turn the time and the energy.
In this paper we propose the following. We introduce an architecture where a light weight decision algorithm based on regression is selected to reduce the burden on the mobile devices. We propose context aware algorithms so that the decision is based on the current context. A dynamic decision process is selected, where based on the user’s choice; a metric is selected for decision making.
This paper is organized in six sections. Section 2 describes related works, Section 3 is dealing with the proposed architecture, Section 4 deals with the regression technique used, Section 5 describes a real time application, Section 6 deals with the results and Section 7 gives the conclusion and finally Section 8 lists down the references.
Related works
The technique of offloading from a resource limited smart device to the unlimited resource cloud has been studied extensively in literature. Several frameworks [7] have been proposed and several techniques have been introduced [9]. Generally these can be classified as what, when, where and how to offload.
In what to offload scenario, a decision is made on which part of the application is offloaded to the cloud. Is it the whole application or parts of the application after partitioning is offloaded? In the decision of when to offload, the offloading decision is taken on the basis of at what time an offloading decision can be taken. The context information is considered and an offloading decision is taken based on this information [11]. If the situation is not favorable a local execution decision is taken. In the offloading decision of where to offload, the consideration is on whether to offload to the nearby cloudlets or distant cloud or if multiple clouds are available, which one should be selected [8]. Finally in how to offload decision, a decision on how are we going to offload, which network to select, which cloud to select and on what context to offload is considered.
The cloudlet [3] is a nearby computational resource which can be used for offloading. It is a miniature representation of a distant cloud, with the advantage of fast connection speed and low latency. Because of these advantages, we will get energy efficient and time efficient processing if a local cloudlet is available.
Clone Cloud [2] is a framework, where the code is partitioned before execution and a linear programming is used for solving. A set of input is generated and the partitioning is based on this input. When an input scenario comes, the most appropriate partition is taken from the already generated set. Since the application can take any inputs, this method lacks the flexibility and is not dynamic. Think Air [1] uses method level offloading. It predicts the next execution time from the previous observations. The main disadvantage of this is that it is not flexible with dynamic changes in the context. If the context varies largely, the averaging doesn’t take that context changes into consideration. CADA [4] is dealing with a context aware offloading algorithm. The movement of the mobile device is also taken into consideration in CADA. It considers the regular pattern of the user and takes an offloading decision based on that. If the user violates the regular pattern, CADA may take a wrong decision. The dynamic network changes and other dynamic behavior are not taken into consideration.
MAUI [13] works on the principle of code annotations. Offloading decision is taken based on these annotations which are added with the method. An annotation can be clubbed with the source code, which is similar to the metadata information. These annotations allow easy identification of the resource intensive tasks that can be offloaded to the cloud. This can be added with the help of the program developer. Once the annotations are made, it converts in the form of offloadable format. Techniques similar to RMI can be used to invoke methods from the cloud. Device dependent dynamic adaptations cannot be executed with this method. The issue of scalability is also a disadvantage of this approach since it requires a specific server to be attached to the mobile device which acts as the cloud server.
Our proposed work is dealing with offloading decision making using regression. A dynamic metric selection is also included in this work. The user selects the mode in which he wants to do the operation and based on this a metric is selected. A metric called ERWS [15] is introduced to evaluate the energy and time together. The selection of the weightage parameter is based on the remaining battery charge of the device.
System architecture and problem formulation
In offloading architecture, the computationally intensive parts of the mobile application are run at the cloud server. We assume that the smart devices are always connected to the internet via cellular connection like 3G/4G/5G or a high speed Wi-Fi connection. The intensive parts are executed at the cloud server and the results are sent back to the mobile devices for integration. The main goals of the architecture are as follows.
a) Adaptation to dynamic network changes:
The connected network is heterogeneous and the properties may change dynamically. The network bandwidth is a dynamic factor, based on which the offloading decision may change. If the bandwidth is too low, the decision of offloading is local execution and depending on the bandwidth value, parts which can be offloaded may change. Instead of two classes, four classes can be offloaded, if enough bandwidth is available.
b) Adaptation to dynamic properties of the device:
The next feature which will affect the offloading decision is the properties of the mobile device. Depending on the context information the offloading decision may change.
Real time application (OCR application) is explained in Section 5. c) Quality of Experience of the user:
The QoE of the user is the measure of how well his criterion is getting satisfied by the application. Based on the above three scenarios, the user will get the optimization of his choice and hence the QoE will be improved.
Architecture
The architecture of dynamic offloading is shown in Fig. 1. The main components of the architecture are profiler, decision maker and partitioning execution.
Profiler
Profiler is a module which collects all the context information about the mobile, network and the cloud. For the mobile device it collects the information about the current battery level and CPU utilization. The network information that the profiler collects is the current bandwidth between the mobile and the cloud server. Periodically this information is collected by sending a dummy packet from mobile to the device. When this packet returns from the cloud, the server attaches the information of cloud CPU load along with that.
Profiler collects this information and inserts into the profiler database. The latency is calculated by sending an ICMP packet to the cloud server. CPU and memory availability is calculated by examining proc/stat and proc/meminfo files of the android and the cloud server. Execution time of the cloud server is highly dependent on the load on the server [16]. The load changes from time to time depending on how many applications are running at the cloud server. Hence accurate calculation of the cloud load is necessary to predict the execution time and energy of the application at the cloud. Following data are used for decision making. Signal strength [B]: Profiler periodically collects the bandwidth (signal strength) of Wi-Fi or 3G connection CPU load on the mobile in % [CPUmobile] Battery Charge of the mobile [Batt] Load at the cloud % [CPUcloud]
A sample dataset is shown below in Fig. 2.
Regression and decision
This module helps us to decide upon the location of execution. Is it local or remote execution? The decision maker first calculates the estimated execution time on the local deice and the cloud. If the estimated time on the device is higher compared to the execution time for the remote execution, then an offloading decision is taken, else a decision of local execution is taken by the decision maker.
A regression technique is used to predict the time and energy for execution. Based on the context dataset which is collected in the profiler, the regression analysis is used to predict the execution time and energy. The regression analysis is explained in detail in Section 4.
Device clone
We assume that a clone of the device we are using is present in the cloud for execution. We also assume that the clone is loaded with necessary packages, application code and data and it is eligible to execute the same application on the cloud. The device is synchronized with the cloud clone so that when a new application is installed on the device, the same is reflected in the clone too.
Client handler interface at cloud and mobile side
A client handler at cloud side will handle all the offloading requests from the devices. The handler continuously monitors the client requests and when a request comes it is forwarded to the correct clone for execution. The handler listens to two types of messages. First one is the periodical message from the mobile device for the context information. The handler attaches the current load on the cloud and the network bandwidth along with the reply to this message. This information is stored in the profiler for decision making.
The next message is the actual message for application execution. Whenever there is a request for application execution, request along with the data is transferred to the handler. Handler in turn redirects this to the device clone. The application is executed there and the results are handed over to the handler and in turn it will reach the mobile device and is displayed there. The important point to be noted in the application is that, some of the application parts are considered as non-offloadable because of the access to local sensors like camera. These parts are considered to be non-offloadable and are not considered for offloading. In our method we have made some classes annotated with a flag variable 0, indicating that classes should be executed locally.
Metrics for evaluation
The following are the metrics for evaluating the criteria for user execution. Execution Time/Response Time:
If the user selects the option to save execution time, local and remote execution times are calculated using regression analysis and a decision is taken.
Time for local execution is calculated as Equation (1).
Time for offloading is calculated as Equation (2).
Where,
Time for cloud execution,
Hence, Total time of offloading can be calculated as Equation (3).
Where S mobile is speed of the mobile device, S cloud is speed of the cloud (processing capacity) and N is the number of instructions to be executed, b is the Current Bandwidth and D is the size of data to be exchanged.
If the objective is to minimize execution time and T
mobile
> T
offload
, the task is executed remotely else the task is executed locally. Similar calculations can be done for energy utilization also. Execution Energy:
If the user’s option is to save execution energy, the local and remote execution energy are calculated for the current context and if the local execution energy is more than remote execution energy, a decision of offloading is taken. Else local execution decision is taken by the offloading system. The local and offloaded execution energy can be calculated as Equations (4–6).
Where P
i
is the idle time of the mobile when the server is executing the task, P
send
is the sending power, P
receive
is the receiving power, D
s
is the amount of data to be sent and D
r
is the amount of data to be received. Execution Energy and Time:
If the objective is a trade-off [12] between execution time and energy the decision should be taken considering both execution time and energy. We can use the metric called Energy Response time Weighted Sum (ERWS) for trade-off analysis. In this, ERWS for local execution and remote execution is calculated and if ERWS for local execution is higher than the ERWS of remote execution, application is executed on the server, since remote execution will save both energy and time. If ERW
m
< ERWS
offload
, the execution is done in the local machine. The ERWS can be calculated as Equations (7, 8).
The value of ω depends on the remaining battery power of the device, which is available in the dataset. Hence more weight is given to the execution time when battery of the device is greater than a high threshold or full. At this situation value of ω can be set high. The value of ω reduces as the remaining battery power of the mobile decreases [14]. The current battery power, which is there in the context database stored by the profiler, is taken for calculation. This will give context aware value to ω, which will lead to exact decision for offloading. The value of ω, can be calculated using the following equation. The value of ω will increase linearly till the current battery charge reaches the Battt, the threshold level. Here we have considered 25% as the threshold level. If the value decreases more than 25% it gives more weightage to the energy factor and ω > 0.5. The value of β is set as 1 in our experiments. For example if the battery level is 75% the value of ω becomes 0.25 and if battery level is 15% the value of becomes 0.85. The calculation of ω can be done using Equation (9).
Offloading is not always beneficial. The metrics associated with mobile execution and for cloud execution is compared and a decision is taken for offloading. The following are the criteria to be considered. Offloading is beneficial only if it takes less time or energy or both, depending on the metrics under consideration and it should consider all dynamic factors which affect offloading. The decision of offloading will deteriorate the system if the context is not favorable. Parameters affecting the offloading decision are highly dynamic and hence decision making should consider all parameters at current context.
Considering all these limitations offloading decision can be considered as a decision making problem, which is highly dynamic, low biased and tolerant to the noise. As this works on a mobile device, the classifier should be light weight, adaptive and should be self learning. It should also consume less energy and time.
The decision algorithm assesses a processing task and determines the location for execution that would maximize energy conservation and minimize execution time on the mobile device. The trade-offs between local and remote execution influence the decision made. In other words, if local computation cost is larger than communication cost, offloading is advised and vice versa.
The decision engine selects the most energy saving task execution option. For this, the context data is parsed and processed for fine tuning the decision of local or remote execution. Following parameters are considered for decision making which is obtained from the context database. < Bandwidth, Battery Charge, CPU load at mobile side, CPU load at cloud side>
A comparison of different classification algorithm is given in Table 1. The time, energy and accuracy vary slightly. Even though SVM and MLP has higher accuracy ratio, the time and energy consumed for regression is less. In this paper the classification technique used is Multiple Logistic Regression. SVM is having high computational burden which is not desirable for this system because time and energy are constraints for our mobile device. This disadvantage can be overcome by LS-SVM, which solves linear equations rather than quadratic programming. The independent variables are the above tuple from data set and the dependent variable is the decision of local/remote execution. Since logistic regression takes categorical data, it is suitable for offloading decision. The two categories of decision are local or remote execution.
Advantage of regression analysis is that it is simple and less time and energy consuming. From the previous data which is available in the data set, the classifier will predict the fate of current execution. Table 1 shows the energy, time and accuracy for regression analysis compared to other classification and prediction techniques. Compared to Threshold, SVM (Support Vector Machine), MLP (Multilayer Perceptron) and decision tree, regression takes less time and less energy. But classification accuracy is slightly lower than some of the other methods. As the offloading decision should be executed in the resource limited smart phones, time and energy are the major factors and hence regression analysis is selected for classification.
Based on the collected information in the dataset, the classifier makes the decision on either to offload the method or to execute it locally. The classifier has a feedback channel so that it can learn by itself through the entire decision process.
To make an offloading decision, it is important to calculate estimated time and energy for local and remote execution for computationally intensive tasks. We use statistical regression technique to find the time of execution and energy utilization. Following are the variables that we are calculating. Energy and time can be calculated from the following Equation (10).
Where, m (X) is a function of all the context information such as bandwidth, battery charge, CPU utilization of mobile and cloud and data to be transferred. ɛ is the residual factor, which is caused due to any un-modeled parameters. To predict the value of m(X)for local execution time, we use a weighted model. The equation used for weighted model is given below Equation (11).
Where n is the number of previous observation to be considered, W i (x) is the weight of each observation and t i is the ith local execution time. In our experiments, i value is taken as 10. 10 closest observations are considered for the calculation of a new value. For W i (x) a weight is given as 1 to the latest value, 0.9 to the previous value and so on.
Similarly the residual factor ‘ɛ’ can be calculated as Equation (12).
Prediction Accuracy:
For the statistical regression model the predicted execution time and energy can be compared with the actual execution time and energy. This will give a better view of the prediction accuracy. The prediction accuracy for time and energy can be calculated using the following equations Equations (13, 14).
Where, T p is the predicted execution time, T a is the actual execution time, E p is the predicted energy and E a is the actual energy.
Consider a real world scenario of a traveller. He is going to a foreign country, where he does not know the language. For translating the local shop boards he can use a translator application which will convert the local language into English. For this application the translation engine takes majority of the computations and if it is done at the local device the battery will be drained quickly and the response time will be larger. So the translator engine can be offloaded to the cloud.
Depending on the context of the user mobile, he can have three choices of operation. In the first choice, if he is nearer to the hotel and battery charging is possible in a short period of time, the application choice can be taken as offloading with faster response time. In this case energy consumption is not considered. The next choice is, he doesn’t have a choice of battery recharging, and he can select an offloading technique which saves energy. In this case response time is not taken into consideration. A dynamic choice can be taken from the user based on the mode he wants the operation to be offloaded. ‘Is it energy efficient or time efficient or both’? The last choice is saving both energy and time. That is a trade-off between the execution energy and response time can be done and a decision of offloading can be taken if both saving energy and time is possible. The following Fig. 3 shows the decision making algorithm.
Figure 4 shows the OCR application architecture. The image is taken using the phone camera and it is forwarded to the cloud for character recognition and translation. The translated text is sent back to the device for display. Figure 5 shows a sample OCR picture.
Numeric results and discussions
The implementation of the decision making and partitioning algorithms uses a Gionee V4S Smart phone (Low End) and Samsung Galaxy S4 (high End). The server is installed on apache tomcat and Open-Shift cloud server. The applications are randomly executed and time and energy are calculated. Power Tutor is used for measuring the power consumption of the applications. A real world scenario described in the Section 5 is used for evaluation. The OCR application will convert the images of the sign boards to English text.
Figures 6 and 7 shows the comparison of our regression technique with some existing technologies. The time and energy increases as the file size increases. But compared to other methods, the regression technique decreases the execution time and energy in all cases. Figures 9 and 10 shows the energy and time saving depending on the bandwidth changes. If the bandwidth is too low, there is no energy and time savings. In such cases, local execution will give much better results. But as the bandwidth increases the advantages also increases. In high bandwidth cases the energy and time saving due to offloading is much higher. So the decision of offloading can be selected for high bandwidth cases and local execution in low bandwidth cases.
Figure 8 shows the prediction accuracy compared to the previously existing technologies. In all cases, regression shows better prediction accuracy. This is because regression considers all the important parameters related to offloading and takes the previous 10 values and gives weightage to them properly. The major factors are bandwidth, CPU load at the mobile and the cloud. All these factors make the prediction accuracy of our system much better than other technologies. Similarly for CPU load and saving energy and time, as the CPU load of the cloud increases the energy and time saving decreases. If the cloud is heavily loaded, instead of offloaded execution, the application can be run locally to obtain good performance.
Conclusion
The proposed method makes offloading decision based on regression analysis. Since regression analysis is simple and will take only less time and energy it can be easily adopted for mobile environment. It takes into consideration all the important parameters which affect the decision. More accurate prediction accuracy and energy and time saving can be obtained by this method. In future, more applications can be taken into consideration. More real time applications can be used to verify the results.
