Sensor Cloud Computing for Vehicular Applications: from Analysis to Practical Implementation

Advances in sensor cloud computing to support vehicular appli-cations are becoming more important as the need to better utilize computation and communication resources and make them energy efficient. In this paper, we propose a novel approach to minimize energy consumption of processing a vehicular application within mobile wireless sensor networks (MWSN) while satisfying a cer-tain completion time requirement. Specifically, the application can be optimally partitioned, offloaded and executed with helps of peer sensor devices, e.g., a smart phone, thus the proposed solution can be treated as a joint optimization of computing and networking re-sources. Our theoretical analysis is supplemented by simulation results to show the significance of energy saving by 63% compared to the traditional cloud computing methods. Moreover, a prototype cloud system has been developing to validate the efficiency of sen-sor cloud strategies in dealing with diverse vehicular applications.

Categories and Subject Descriptors

G.1 [Mathematics of Computing]: NUMERICAL ANALYSIS; C.2 [COMPUTER-COMMUNICATION NETWORKS]: Network Architecture and Design

Keywords

Mobile wireless sensor networks, cloud computing, vehicular applications

1.

INTRODUCTION

Cloud computing [1, 2] has been proposed as an efficient and cost effective way of providing highly scalable and reliable infras-∗_{This work was supported in part by the Canadian Natural Sciences} and Engineering Research (NSERC), the NSERC DIVA Strategic Research Network, and various industry partners.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full cita-tion on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re-publish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected].

tructures and services for running mobile applications. The key idea of cloud computing is to create a pool of visualized, dynami-cally configurable and manageable resources across computing net-works, which can deliver on demand services to users over the In-ternet. In a simple, topological sense, a cloud computing solution is made up of several components, such as clients, data center and dis-tributed servers. Clients can subscribe services via the cloud com-puting platform which can offer diverse storage and computation capabilities from both data center and distributed servers, respec-tively. Today, with the development of wireless technologies and powerful computing hardware, the cloud computing capability has been largely extended to a broad range of MWSN, such as wireless sensor networks [3, 4] and Internet-of-Things (IoT) [5], to support flexible mobile applications.

In MWSN, sensor devices are commonly with a radio transceiver and a microcontroller powered by a battery, as well as diverse sen-sors for detecting light, heat, humidity, temperature, etc. Examples of mobile sensor devices include most current mobile phones (such as iPhone, Samsung’s Android phones, etc.) which are equipped with a rich set of embedded sensors such as camera, GPS, WiFi/3G/ 4G radios, accelerometer, digital compass, gyroscope, microphone and so on. Moreover, the recent developed sensor platforms, such as WRTnode1and Arduino2, are also capable of connecting exter-nal sensors (such camera sensor, thermal sensor, heartbeat sensor, air pollution sensor, etc.) to enable attractive mobile sensing ser-vices in various domains such as environmental monitoring, social networking, healthcare and transportation, etc.

Different to the static sensor networks, MWSN are much more versatile as they can be deployed in any scenario and cope with rapid topology changes. The advantage of allowing the sensor de-vices to be mobile increases the number of applications beyond those for which static WSNs are used. This particularly promotes the development of intelligent transportation systems (ITS) for re-ducing the traffic congestions, the high number of traffic road ac-cidents, etc. Indeed ITS can support a large number of applica-tions including safety traffic applicaapplica-tions (e.g., collision avoidance, road obstacle warning, safety message disseminations, etc.), traf-fic information and infotainment services (e.g., games, multime-dia streaming, etc.). For example, a car attached with a mobile sensing device can actively collect on-board diagnostics (OBD) in-formation and nearby messages via vehicle-to-roadside (V2R) and vehicle-to-vehicle (V2V) communications, and inform drivers and

1

http://wrtnode.com/.

2

(2)

Gateway Mobile wireless sensor networks Ethernet Wi-Fi Request offloading Response o

Figure 1: An illustration of sensor cloud computing

nearby vehicles of the emerging situation. A comprehensive survey of the vehicular applications is presented in [6]. In essence, with these sensor devices which basically consist of powerful sensing, processing and communicating capabilities, the emerging dissem-ination of MWSN and cloud computing can bring new opportuni-ties of sensor and cloud integration, which will facilitate clients not only to monitor and collect data from the environment but also to execute and output sensor services using its own processing capa-bilities.

Although various sensor cloud schemes have been developed to increase bandwidth efficiency [7, 8], the sensor device is usually assumed as data collecting point and there is lack of understanding of its processing capability and the potential benefits of being as a computing cloud. Thanks to the recent developments in micro-electromechanical systems (MEMS) and software platforms, the sensor devices are shown to be promising to host lightweight appli-cations as a web server. Moreover, the latest radio frequency (RF) technologies and lightweight web services, e.g., (REST) Repre-sentational State Transfer (REST)3, for accessing applications and services on MWSN has enabled the newly emerging Sensor-as-a-Service (SaaS) paradigm.

In this paper, we investigate fundamental characteristics of cloud computing in MWSN in terms of energy efficiency and propose a novel approach to optimize total energy consumption of process-ing a mobile application requested by a client, while satisfyprocess-ing a certain delay requirement. Specifically, by introducing the concept of cooperation which encourages single devices to share their re-sources cooperatively, the proposed solution can jointly consider computation and communication costs as a whole, and optimally partition, offload and execute tasks between mobile sensor devices to boost energy efficiency. Moreover, a prototype cloud system has been developing to validate the efficiency of sensor cloud strategies in dealing with diverse vehicular applications. Fig. 1 gives an ex-ample of the sensor cloud computing where mobile wireless sensor networks form a cooperative cloud and can serve clients’ service requests via IP networks. To the best of our knowledge, this is the first work that considers mobile sensor device as a service and realizes cooperative sensor cloud computing.

This paper is organized as follows. The motivation is highlighted in Section 2. The system model and problem formulation are intro-duced and derived in Section 3. The optimal sensor cloud com-puting scheme is presented and analyzed in Section 4. Analytical results are provided in Section 5. Prototype system is demonstrated in Section 6. Finally, concluding remarks are given in Section 7.

3_{REST, a lightweight web service implementation, is a design}

con-cept that all the objects in the Internet are abstracted as resources. REST style can make applications as sharable, reusable and loose coupling services.

2.

MOTIVATION

Cooperative allocation of resources and offloading is a promi-nent feature in cloud computing that can be leveraged by means of chaining virtualized service instances. When a mobile applica-tion is running, auxiliary services may be instantiated either locally at the device level or at the edge of cloud or near a data center based on the nature of the service. Services can be composed to run a new service or application and these services can be instan-tiated at different locations. In this model, service instances and applications are agnostic to the underlying infrastructure and de-mand that a certain Service Level Agreement (SLA) is met while the virtual compute, networking and storage resources are allocated optimally. Intelligent applications and context-aware services can leverage contextual interactions among the objects of IoT through a content-aware networking approach. On the other hand, interaction of elements and devices within the ITS and vehicular clouds raise the new challenge of interconnecting massive amount of heteroge-neous applications, services, sensors and devices. On the approach towards an edge cloud platform that supports services pertaining to the advancement of applications in IoT, a generic platform is demonstrated in [9] and a top down service chaining approach from abstraction to composition and virtual infrastructure embedding is proposed. Authors in [10, 11] tackle the challenge of IoT by pro-moting the information centric networking paradigm to leverage higher order connectivity among the objects.

3.

SYSTEM MODEL AND PROBLEM

FOR-MULATION

3.1

Mobile Application Model

We consider MWSN where sensor devices can execute lightweight mobile applications with helps of peer sensor devices. In order to characterize the mobile application, we consider a canonical model [12] that captures the essentials of a typical mobile appli-cation. Specifically, a mobile application can be abstracted into the following two parameters:

• Processing data sizeL: the total number of data bits for ex-ecuting a mobile application. We also assume that such pro-cessing data can be partitioned from the main code and of-floaded to a peer sensor for remote execution [13].

• Application completion deadlineT: the maximum number of time slots that a mobile application must be completed.t

is discrete time index ranging fromt= 1...T.

In the following, we denote an application asA(L, T)and use it to characterize energy behaviors.

3.2

Computation Energy Consumption

The energy consumption of computation is directly determined by the CPU workload of a sensor node. According to [14], the workload can be measured by the number of CPU cycles required by an application, which is related to the data size and computation complexity, and can be defined as

W =LX , (1)

whereWis the number of CPU cycles,Lis the processing data size andXis the computation algorithm which can be characterized as a random variable with Gamma distribution.

Although a number of factors consume CPU power, such as short circuit power and dynamic power, etc., the energy consumption is dominated by dynamic power which can be minimized by configur-ing the clock frequency of the chip via the dynamic voltage scalconfigur-ing

(3)

technology [15]. In CMOS circuits [16], the computation energy per operation cyclecis proportional toV2, whereV is the

sup-ply voltage to the chip. When operation is at low voltage, likes in wireless sensor networks, the clock frequency,f, can be treated as a linear function of the voltage supply. As a result, the total energy consumption of computation can be expressed as

Ec= W X w=1 c(w) = W X w=1 κfw2, (2)

whereκis the effective switched capacity determined by the chip architecture andfwis the clock-frequency which is scheduled in

the next CPU cycle given the number ofwCPU cycles have been completed.

Intuitively, the CPU can reduce its energy consumption by schedul-ing low clock frequency. However, as a practical implementation, the application has to meet a delay deadline. We adopt the sta-tistical CPU scheduling model [17] which assumes the application should satisfy the soft real-time requirement, in which the applica-tion compleapplica-tion needs to meet its deadline with the probabilityp

by allocatingWpCPU cycles. The parameterpis the application

completing probability (ACP). In other words, the probability of an application requires no more than the allocatedWpshould

sat-isfyFW(Wp) = P r[W ≤ Wp] ≥ p. According to (1), since

W is a linear function of X, we can obtain Wp = LFX−1(p),

whereF_X−1(p)is the inverse cumulative distribution function of

X. Hence, the total energy consumption can be derived as

Ec=κ Wp X w=1 FWc (w)f 2 w, (3)

whereFWc(w)is the complementary cumulative distribution

func-tion (CCDF) that the applicafunc-tion has not completed afterwCPU cycles. Since the Gamma distribution is exponentially tailed, the CCDF can be assumed asFWc (w) ∼ µe

−νw

for some constants

µ > 0andν >0. It is noted that withw → ∞, the probability

goes to 0, which means it is unlikely that an application cannot be completed with a large CPU cycles.

According to [12], by optimizing the clock-frequency scheduling for each CPU cyclefwand ensure the application completion time

is less than the deadline (PWp

w=11/fw ≤ T), we can derive the

minimum value of (3) as

Ec=

KL3

T2 . (4)

whereKis a constant factor determined byκandp.

3.3

Communication Energy Consumption

The power consumption of communication is determined by the number of bits being transmitted and the current draw of the electri-cal circuits that implement the physielectri-cal communication layer which includes idle, transmit and receive modes. According to the data sheet of a typical low energy radio transceiver, e.g., IEEE 802.11n [18] or 802.15.4 [19], the power consumption is dominated by the transmit or receive modes and their costs are approximately the same. So in this paper, we assume the communication energy in-cludes both transmission and reception of processing data, and do not consider the small output results4from the cloud.

We use an empirical transmission energy model [20] to charac-terize communication cost. The required energyEtto transmitL 4

This is a reasonable assumption for sensor cloud computing where most of sensor based applications come with simple results of warning or image detection indication, etc.

bits within a time slot is governed by a convex monomial function5

Et=ρ

Ln

g . (5)

whereρdenotes the energy coefficient,gdenotes channel state and

n denotes the order of monomial with value1 ≤ n ≤ 5. The choice ofndepends on the bit scheduler policy, with a large value ofn, the scheduler will transmit equal number of bits at every time slot regardless of the channel state [20]. In this paper, we con-sider the optimal case forn = 1which is called one-shot policy, in which the transmission only depends on the channel state and is completed in one time slot. There are several reasons for ap-plying this scenario: First, for energy constrained sensor device, it may not be desirable to split a single data across multiple time slots because of extra energy consumed by large overhead associ-ated with each slot. Second, since we impose a delay deadline for completing a mobile application, the transmission time should be relatively small compared toT, such that the time offset between local and remote executions can be negligible. Third, as a mobile application, the transmission air time should be minimized to avoid channel fluctuation. In order to ensure the optimal performance of such policy, the scheduler should be opportunistic, in the sense of offloading tasks to a peer node with good channel quality.

4.

ENERGY OPTIMIZATION FOR SENSOR

CLOUD COMPUTING

Our interest in this section is to find an optimal mobile appli-cation partition solution to minimize the total energy consumption of processing a mobile application given that a target completing deadlineTis satisfied with the help of a peer sensor device and can be formulated as

min

ll,lr

Elc(ll, t) +Et(lr, gl,r)

| {z }

local energy cost

+Er(lr, gr,l) +Ecr(lr, t)

| {z }

remote energy cost

s.t. ll+lr=L , t≤T . (6)

•Ecl and Erc denote the local and remote nodes computation

energy consumption, andEtandEr denote transmission and

re-ception energy consumption, respectively.

•llandlrare partitioned data size for local and remote

process-ing. A symmetric channel is assumed between local and remote sensor nodes and has channel gaingl,r =gr,l. A delay deadlineT

is considered to ensure Quality-as-Service.

Theorem 1: The optimal data partition to minimize the total en-ergy consumption of processing a mobile applicationA(L, T), is given by l∗l = L 2 + β 6αL, l ∗ r = L 2 − β 6αL. (7) whereα= _TK2,β= 2ρ

g_l,r,Kdenotes the computation coefficient,

ρdenotes communication coefficient of wireless channel andgl,r

is the channel gain.

Proof: See Appendix A. 2

In general, we find that the minimum total energy consumption can be achieved by optimally partitioning, offloading and executing the data via the sensor cloud computing, which can be determined by the application profile, hardware configurations of sensor de-vices and wireless channel conditions.

5

Although the monomial cost does not hold for operation at capac-ity in AWGN channel, there is a practical modulation scheme to well approximate by a monomial [20].

(4)

Property 2: The size difference of the optimal processing data between local and remote executions is

diff(L, T, K, ρ, gl,r) =

2ρT2

3gl,rKL

. (8)

In essence, we can observe that the optimal partition is highly depending on system parameters. Specifically,the local execution is preferablewhen (8) tends to increase (i.e., small data sizeL, long delay deadlineT, large transmission costρ, small computation cost

Kor high channel lossgl,r). Otherwise,the remote execution is preferable.

Property 3: By defining the application processing speed asυ=

L

T, we have the equivalent offload decision rules

   Never offload, if υ≤q₃_Kg2ρ l,r Offload, if υ >q₃_Kg2ρ l,r (9)

Proof: According to (7), sinceL 2 ≤l ∗ l ≤L, we should have0≤ β 6αL < L

2 for data offload. Thus, the lower bound of application

processing speed can be achieved as

L T > s 2ρ 3Kgl,r . (10) when₆_αLβ ≥L

2, only the local execution is applied. 2

In other words, when the application prefers to offload for remote execution, it can always achieve better processing speed than the non-offload case.

Property 4: For the offloading case, the bound performance of computation to communication energy ratio of local and remote execution nodes are

Ecl Et >1 6, Ecr Er <Kgl,r 4ρ υ 2 . (11)

Proof: See Appendix B. 2

The result tells that the proposed optimal solution can best achieve the local computation energy as close as1/6of transmission en-ergy, which is promising to show the advantage of using cooper-ative sensor cloud computing in wireless sensor networks. More-over, the cooperative sensor cloud computing can also help reduce the remote computation energy. The upper bounded is govern by the system parameters and maximum number of bits can be of-floaded. The result is useful when selfish nature is imposed to indi-viduals, because reducing the energy consumption for helper nodes can largely improve their willingness of cooperation.

5.

ANALYTICAL RESULTS

In this section, we provide simulation results to validate the per-formance of the proposed method. To be consistent with the real energy measurements [14], we set the computation coefficient in the order of10−11, the communication coefficient in the order of

10−2

, a time slott= 2ms and channel gain0< g <1.

Fig. 2 shows the local processing data size partitioned by the proposed optimal solution. The processing data size is assumed

asL = 1024bits and channel gain isgl,r = 0.5. It is clear that

the optimal partition is significantly affected by the system coeffi-cients. With better computation efficiency (smallerK) and higher communication cost (largerρ), the optimal partition tends to allo-cate more processing task locally. Moreover, with a relaxed delay deadline (largeT), the local execution is more preferable to save energy by reducing processing speed. Fig. 3 gives an illustration

0 0.02 0.04 0.06 2 4 6 8 10 x 10−11 500 600 700 800 900 1000 1100

Optimal data size of local execution (bits)

Computation coefficient K Communication coefficient ρ T=15ms T=10ms T=20ms

Figure 2: The relations between the optimal data size of local execution and system coefficientsKandρ

0.01 0.02 0.03 0.04 0.05 0.06 0.5 1 1.5 2 2.5 3 3.5x 10 −11 Computation coefficient K Communication coefficient ρ

Never offload

Offload

Figure 3: An illustration of energy optimal offloading decision rules

of the offloading decision rules. With the information of applica-tion profile and system coefficients, we can quickly decide the best strategy for processing a mobile application.

Fig. 4 shows the total energy consumption of the optimal so-lution and compare it with that of non-cooperative case where the cloud computing is purely executed locally. By settingK= 10−10,

ρ= 0.006andT = 20ms, we observe that under the same com-munication coefficient, the energy performance improves with bet-ter channel quality. Even with severe channel quality and high communication cost (gl,r = 0.1,ρ = 0.01), the performance of

the proposed solution is closed to the non-cooperative case when the application processing requirement is not stringent (smallL, largeT). As the data size increases, the cooperative sensor cloud computing can ensure optimal with better energy efficiency than the non-cooperative case. Given the worst channel scenario with

gl,r= 0.1, an average of 63% of energy can be saved by using the

proposed cooperative cloud computing.

6.

PROTOTYPE CLOUD SYSTEM FOR

VE-HICULAR APPLICATIONS

As shown in Fig. 5, our cloud platform adopts a hierarchical architecture which consists of the following four layers.

(5)

500 1000 1500 101

102 103

Data size L (bits)

Total energy comsuption (

µ J) Non−cooperative cloud Cooperative cloud g=0.1,ρ=0.006 Cooperative cloud g=0.3,ρ=0.006 Cooperative cloud g=0.9,ρ=0.006 Cooperative cloud g=0.1,ρ=0.01

Figure 4: Total energy consumption vs. processing data size

ManagedInterface

APIs|Dev.Environment

Partners Customers Developers Employees MoreThings API API API API API Applications Runtime|Services

Datastorageservices

Historian|Cache|Search Failurehandling

Real-timeBigDataAnalysis

Dataanalytics|Eventanalytics|Servicecomposition

Visualization ProcessMgmt

DeviceRegistration&Connectivity

Naming|Addressing|Protocoladaptation|Security&Privacy|Eventmgmt

Figure 5: Architecture of the sensor cloud platform According to Section 4, this is the layer where sensor devices, e.g., smartphone, form a sensor cloud and can process lightweight vehicular applications using their own processing and communica-tion capabilities. The output results can be uploaded via wireless, wired or hybrid networks to the upper management and services layers.

6.2

Cloud gateway layer

This layer works as a bridge between the sensor device and the cloud platform, so as to form a seamless management platform. Although most of the current service interactions on the cloud are based on Simple Object Access Protocol (SOAP) which is a proto-col specification for exchanging structured information in the im-plementation of web services in computer networks, the SOAP-REST transformation can be achieved using additional adapters. This adapter can receive the REST service invocation request and transform it into the SOAP service invocation request [21].

6.3

Cloud management layer

Beyond the basic management services like data storage, visu-alization and failure handling, we propose the real-time big data analysis as a key service in this layer.

Consider the limited resource of sensor devices, diverse contex-tual data need to be uploaded to the cloud platform for further pro-cessing. Such data collected from independent sensor sources often have implicit but disparate assumptions of interpretation. For

ex-ample, data standard about distance collected from a sensor device in the US (mile) and the same concept of data comes from Europe (kilometer) are different. Such implicit assumptions of data inter-pretation have to be addressed before the services can be dynami-cally composed and delivered. Thus, to make the raw sensing data from different sources be context-aware, one possible way is to re-quire service providers to pre-specify the context definition for their sensor devices and register them to the cloud [22]. Further, as in-troduced in our earlier works, we use a lightweight ontology which contains a modifier using to capture additional information that af-fects the interpretations of generic concepts [22–24]. Specifically, the generic concept in the ontology can have multiple modifiers, each of which indicates an orthogonal dimension of the variations in data interpretation. The data analysis engine can understand the context of data sources and therefore know how to interpret the data based on the values of the modifiers associated with the cor-responding context, which is more flexible and adaptable to the dynamic service environment.

6.4

Customized application and service layer

This layer is built upon the specifications and methodologies of RESTful web services and provides the managed interfaces which consists of development environment and application programming interfaces (APIs) to support customized vehicular applications and services. Similar to our prior work [21], the managed interface can be implemented by integrating the Apache ODE6management in-terface, the JBoss jBPM7_{management interface and series of open}

source packages.

During a sensor device’s run-time, once this layer receives a web service request from a user, it can automatically analyze the re-quested Uniform Resource Identifier (URI) and the related param-eters encapsulated by HTTP, so as to determine the specific class (e.g., JAVA class) to invoke the corresponding web services based on the configuration files. After the operation of the related web services, the sensor cloud will return the results to the user through HTTP.

Thus, compared to traditional service-oriented architecture (SOA) based solutions, the advantage of the proposed architecture is that developers can focus on developing the functions of vehicular ap-plications without concerns of transforming raw sensing data to contextual information, and the mapping between specific service request and the corresponding context information in run-time. Fig. 6 shows the user-cloud-sensor interactions in the proposed system.

6.5

System evaluation

We develop a prototype cloud system to connect senor devices via the cloud platform using the proposed sensor cloud method. The snapshot of the web portal is shown in Fig. 6 (a). Through the pre-defined APIs, interactions with application data can be easily managed and retrieved in a unified manner.

We evaluate the system performance of the sensor cloud in terms of time efficiency by setting up a test environment in which a user request environmental data from his car and 5 sensor devices are used to upload computing tasks to the cloud platform with a to-tal average rate of E = 5/min. Theε£-GALEN ontology [25] is adopted as benchmark, and the computing tasks are to index and calculate the similarities of concepts on this ontology under the condition of four different size assertions (1000, 1500, 2000, 36000). We take 5 tests and each lasts for 30 minutes. The average results are shown in Fig. 6 (b). The time delay when performing the task via cloud consists of: 1) response and communication time

6_{http://ode.apache.org/} 7

(6)

(a)An illustration of management web portal Big data uploading & analysis Response Request Offloading

(b) Overall system performance of the sensor cloud

Average time delay (ms) Data set 1 (1000) Data set 2 (1500) Data set 3 (2000) Data set 4 (36000) Cloud platform Response time 4683 4475 4626 4395

Process time 40 461 702 2483 Smart phone

platform Total time 2234 4736 7445 136073

Hardware

Software

•Amazon EC2 M1 Medium Instance, 2 EC2 Compute Unit •3.75 GB memory, 410 GB

storage

•32-bit or 64-bit platform •I/O Performance: Moderate

•OS: Ubuntu 14.04 •Servers: ApacheTomcat 8.08 •BPEL engine: Apache

ODE1.3.4 H

Cloud

Platform

Nexus 4 smart phone

Figure 6: User-cloud-sensor interactions and its performance between the remote cloud platform and the sensor device; and 2)

processing time of the task. The results show closed performance of response time with an average of 4.5s, while the process time mostly depends on the size of the data set. As a comparison, we run the application directly on Nexus 4 smartphones, which is a reason-able example to illustrate sensor cloud processing capability, and it shows that sensor cloud can better achieve communication and computation efficiency when running lightweight vehicular appli-cation services, whereas the remote cloud platform is more efficient in processing high complexity and big data applications. This result is consistent with analytical result in Section 5. It is worth noting that since the current cloud server is designated to support different types of vehicular applications simultaneously, its response time is inevitable a bit longer comparing to that of servers deployed for specific applications.

7.

CONCLUSIONS

We have shown in this paper that it is advantageous to employ cooperative sensor cloud computing to process vehicular applica-tions. For the future work, we plan to propose additional robust peer-selection mechanisms, which can account for other parame-ters of importance as the fairness measures, such as the remaining energy of each nodes.

APPENDIX

A.

PROOF OF THEOREM 1

We use the Lagrange multiplier method to solve the optimization problem. According to (4) and (5), the optimization problem in (6) can be written as min ll,lr Kl3l t2 +ρ lnr gl,r +ρl n r gr,l +Kl 3 r t2 , s.t. ll+lr=L, t≤T . (12)

In order to simplify the notation, we usegl,r to denotegr,l

be-cause of the symmetric channel assumption, andn= 1. According to the Kuhn-Tucker condition (p.244: KKT conditions for convex problems [26]), the inequality constraint in (12) can be converted to the equality constraint and have the convex function

`(ll, lr, λ) = K T2l 3 l+ρ lr gl,r +ρ lr gl,r +K T2l 3 r+λ(ll+lr−L), (13) Letα = _TK2 andβ = 2ρ

gl,r, we can derive the optimal partition

which must satisfy the following conditions

∂`(ll, lr, λ) ∂ll = 3αl2l+λ (14) ∂`(ll, lr, λ) ∂lr = 3αl2r+β+λ , (15) Then we obtain l2l = −λ 3α, l 2 r = −λ−β 3α , (16) Sincell+lr=L, we have λ=−3αL 2 4 − β2 12αL2 − β 2. (17)

Substituting (17) into (16), we obtain the unique optimal solution.

B.

PROOF OF PROPERTY 4

1) For local execution: According to (4) and (5), we obtainElc

Et = Kl3_l T2 · gl,r ρlr. Sincelr≤ll, we have El c Et ≥ Kl 3 l T2 · gl,r ρll ⇒E l c Et ≥Kgl,r ρ · ll T 2 , (18)

(7)

BecauseL₂ ≤ll∗≤L, we can obtain the lower bound performance of local execution as Elc Et ≥ Kgl,r ρ · L 2T 2 . Replacing (10) into equation leads to the result.

2) For remote execution: similarly we haveEcr

Er = Kgl,r ρ · lr T 2

. Since0≤lr∗≤ L2, we can obtain the upper bound performance

of remote executionEcr Er ≤ Kgl,r ρ · L 2T 2 .

C.

REFERENCES

[1] M. Dikaiakos, D. Katsaros, P. Mehra, G. Pallis, and A. Vakali, “Cloud Computing: Distributed Internet Computing for IT and Scientific Research,”IEEE Internet Comput., vol. 13, pp. 10–13, Sept 2009.

[2] K. Kumar and Y.-H. Lu, “Cloud computing for mobile users: Can offloading computation save energy?,”Computer, vol. 43, pp. 51–56, April 2010.

[3] Z. Sheng, K. Leung, and Z. Ding, “Cooperative wireless networks: from radio to network protocol designs,”IEEE Commun. Mag., vol. 49, pp. 64–69, May 2011.

[4] Z. Sheng, J. Fan, C. Liu, V. Leung, X. Liu, and K. Leung, “Energy efficient relay selection for cooperative relaying in wireless multimedia networks,”IEEE Trans. Veh. Technol., vol. PP, no. 99, pp. 1–1, 2014.

[5] Z. Sheng, S. Yang, Y. Yu, A. Vasilakos, J. Mccann, and K. Leung, “A survey on the IETF protocol suite for the Internet of Things: standards, challenges, and opportunities,”IEEE Wireless Commun. Mag., vol. 20, pp. 91–98, December 2013.

[6] E. Hossain, G. Chow, V. C. Leung, R. D. McLeod, J. Misi˘´c, V. W. Wong, and O. Yang, “Vehicular telematics over heterogeneous wireless networks: A survey,”Computer Communications, vol. 33, no. 7, pp. 775 – 793, 2010.

[7] A. Alamri, W. S. Ansari, M. M. Hassan, M. S. Hossain, A. Alelaiwi, and M. A. Hossain, “A Survey on Sensor-Cloud: Architecture, Applications, and Approaches,” inInt’l J. of Distributed Sensor Networks, p. 18, 2013.

[8] N. Zingirian and C. Valenti, “Sensor clouds for Intelligent Truck Monitoring,” inProc. IEEE Intelligent Vehicles Symposium (IV), pp. 999–1004, June 2012.

[9] P. Talebifard, R. Ravindran, A. Chakraborti, G. Wang, and V. Leung, “Towards a Context Adaptive ICN based Service Centric

Framework,” in2014 to appear in Proceedings of QShine Workshop on Quality, Reliability, and Security in Information-Centric Networking (Q-ICN), IEEE, 2014.

[10] P. TalebiFard and V. Leung, “A content centric approach to dissemination of information in vehicular networks,” inProceedings of the second ACM international symposium on Design and analysis of intelligent vehicular networks and applications, pp. 17–24, ACM, 2012.

[11] P. TalebiFard, H. Nicanfar, X. Hu, and V. Leung, “Semantic based networking of information in vehicular clouds based on dimensionality reduction,” inProceedings of the third ACM

international symposium on Design and analysis of intelligent vehicular networks and applications, pp. 69–76, ACM, 2013. [12] W. Zhang, Y. Wen, K. Guan, D. Kilper, H. Luo, and D. Wu,

“Energy-optimal mobile cloud computing under stochastic wireless channel,”IEEE Trans. on Wireless Commu., vol. 12, pp. 4569–4581, September 2013.

[13] C. Mei, D. Taylor, C. Wang, A. Chandra, and J. Weissman, “Sharing-aware cloud-based mobile outsourcing,” inProc. IEEE CLOUD, pp. 408–415, June 2012.

[14] A. P. Miettinen and J. K. Nurminen, “Energy efficiency of mobile clients in cloud computing,” inProc. of the 2nd USENIX Conf. on Hot Topics in Cloud Computing, HotCloud’10, (Berkeley, CA, USA), pp. 4–4, USENIX Association, 2010.

[15] J. M. Rabaey, A. Chandrakasan, and B. Nikolic,Digital Integrated Circuits (2nd Edition). Prentice Hall, 2002.

[16] T. Burd and R. W. Brodersen, “Processor design for portable systems,”J. of VLSI Signal Processing, vol. 13, pp. 203–222, 1996. [17] W. Yuan and K. Nahrstedt, “Energy-efficient CPU scheduling for

multimedia applications,”ACM Trans. Comput. Syst., vol. 24, no. 3, pp. 292–331, 2006.

[18] D. Halperin, B. Greenstein, A. Sheth, and D. Wetherall, “Demystifying 802.11n power consumption,” inProc. of

International Conference on Power Aware Computing and Systems, HotPower’10, 2010.

[19] M. Palattella, N. Accettura, X. Vilajosana, T. Watteyne, L. Grieco, G. Boggia, and M. Dohler, “Standardized protocol stack for the Internet of (Important) Things,”IEEE Commun. Surveys Tuts., vol. 15, pp. 1389–1406, Third 2013.

[20] J. Lee and N. Jindal, “Delay constrained scheduling over fading channels: Optimal policies for monomial energy-cost functions,” in Proc. IEEE Int’l Conf. on Commu. (ICC)., pp. 1–5, June 2009. [21] X. Hu, T. Chu, H. Chan, and V. Leung, “Vita: A

crowdsensing-oriented mobile cyber-physical system,”IEEE Trans. Emerging Topics in Computing, vol. 1, pp. 148–165, June 2013. [22] X. Hu, X. Li, E.-H. Ngai, V. Leung, and P. Kruchten,

“Multidimensional context-aware social network architecture for mobile crowdsensing,”IEEE Commun. Mag., vol. 52, pp. 78–87, June 2014.

[23] X. Li, S. E. Madnick, and H. Zhu, “A context-based approach to reconciling data interpretation conflicts in web services

composition,”ACM Trans. Internet Technol., vol. 13, pp. 1:1–1:27, Nov. 2013.

[24] X. Hu, Q. Liu, C. Zhu, V. C. M. Leung, T. H. S. Chu, and H. C. B. Chan, “A mobile crowdsensing system enhanced by cloud-based social networking services,” inProceedings of the First International Workshop on Middleware for Cloud-enabled Sensing, MCS ’13, pp. 3:1–3:6, 2013.

[25] A. Rector, J. Roger, P. Zanstor, and E. Haring, “OpenGALEN: open source medical terminology and tools,”American Medical Informatics Association, 2003.

[26] S. Boyd and L. Vandenberghe,Convex optimization. Cambridge University Press, 2003.