arX

iv:1

308.

6208

v1 [

cs.D

C]

28 A

ug 2

013

1

Toward Cloud-based Vehicular Networks withEfficient Resource Management

Rong Yu,Member, IEEE, Yan Zhang,Senior Member, IEEE, Stein Gjessing,Senior Member, IEEE,Wenlong Xia,Student Member, IEEE, Kun Yang, Senior Member, IEEE

Abstract—In the era of Internet of Things, all components inintelligent transportation systems will be connected to improvetransport safety, relieve traffic congestion, reduce air pollutionand enhance the comfort of driving. The vision ofall vehiclesconnected poses a significant challenge to the collection andstorage of large amounts of traffic-related data. In this article,we propose to integrate cloud computing into vehicular networkssuch that the vehicles can share computation resources, storageresources and bandwidth resources. The proposed architectureincludes a vehicular cloud, a roadside cloud, and a central cloud.Then, we study cloud resource allocation and virtual machinemigration for effective resource management in this cloud-basedvehicular network. A game-theoretical approach is presented tooptimally allocate cloud resources. Virtual machine migrationdue to vehicle mobility is solved based on a resource reservationscheme.

Index Terms—cloud computing, mobile cloud, vehicular net-works, Internet of vehicles, resource management, cloudlet,virtual machine migration.

I. I NTRODUCTION

Vehicular networks are in the progress of merging withthe Internet to constitute a fundamental information platformwhich is an indispensable part of Intelligent Transport Sys-tem (ITS) [1]. This will eventually evolve into all vehiclesconnected in the era of Internet of Things (IoT) [2]. Bysupporting traffic-related data gathering and processing,ve-hicular networks is able to notably improve transport safety,relieve traffic congestion, reduce air pollution, and enhancedriving comfortability [3]. It has been reported that, in WesternEurope, 25% of the deaths due to car accidents could bereduced by deploying safety warning systems at the highwayintersections [4]. Another example is that real-time trafficinformation could be collected and transmitted to data centerfor processing, and in return, information could be broadcastedto the drivers for route planning. City traffic congestion isalleviated and traveling time is reduced, leading to greenercities.

A variety of information technologies have been developedfor intelligent vehicles, roads, and traffic infrastructures suchthat all vehicles are connected. Smart sensors and actuators aredeployed in vehicles and roadside infrastructures for dataac-quisition and decision. Advanced communication technologies

Rong Yu and Wenlong Xia are with Guangdong University of Technology,China. Email: yurong@ieee.org, wlxia@ieee.org

Yan Zhang and Stein Gjessing are with Simula Research Laboratory,Norway; and University of Oslo, Norway. Email: yanzhang@ieee.org, ste-ing@ifi.uio.no

Kun Yang is with University of Essex, UK. Email: kunyang@essex.ac.uk

are used to interconnect vehicles and roadside infrastructures,and eventually access to Internet. For instance, DedicatedShort Range Communications (DSRC) is specifically designedfor Vehicle-to-Vehicle (V2V) and Vehicle-to-Roadside (V2R)communications. The IEEE 802.11p, called Wireless Accessin Vehicular Environments (WAVE) [5], is currently a popularstandard for DSRC. Besides, the Long-Term Evolution (LTE),LTE-Advanced and Cognitive Radio (CR) [6][7] are all fairlycompetitive technologies for vehicular networking [8][9].

Despite of the well-developed information technologies,there is a significant challenge that hinders the rapid devel-opment of vehicular networks. Vehicles are normally con-strained by resources, including computation, storage, andradio spectrum bandwidth. Due to the requirements of small-size and low-cost hardware systems, a single vehicle haslimited computation and storage resources, which may resultin low data processing capability. On the other hand, manyemerging applications demands complex computation andlarge storage, including in-vehicle multimedia entertainment,vehicular social networking, and location-based services. Itbecomes increasingly difficult for an individual vehicle toef-ficiently support these applications. A very promising solutionis to share the computation and storage resources among allvehicles or physically nearby vehicles. This motivates us tostudy the new paradigm of cloud-based vehicular networks.

Recently, a few research works are reported to study thecombination of cloud computing and vehicular networks. In[10], the concept of Autonomous Vehicular Clouds (AVC) isproposed to exploit the under-utilized resources in vehicularad hoc networks (VANETs). A Platform as a Service (PaaS)model is designed in [11] to support cloud services for mobilevehicles. The work in [12] proposes architectures of VehicularClouds (VC), Vehicles using Clouds (VuC) and Hybrid Clouds(HC). Vehicles play as cloud service providers and clientsrespectively in VC and VuC, and as hybrids in HC.

In this article, we propose a hierarchical cloud architecturefor vehicular networks. Our work is different from previousresearches in three main aspects. First, we aim to create apervasive cloud environment for mobile vehicles by integratingredundant physical resources in ITS infrastructures, includingdata center, roadside units and vehicles. The aggregation ofthese sporadic physical resources potentially compose massiveand powerful cloud resources for vehicles. Second, we proposea three-layered architecture to organize the cloud resources.The layered structure allows vehicles to select their cloudservices resiliently. Central clouds have sufficient cloudre-sources but large end-to-end communications delay. On the

2

Central Cloud Vehicular CloudRoadside Cloud

Public Cloud Servers

Private Cloud Servers

I nternet

RSU

RSU

RSU

Local

Servers

Local

Servers

Base

Stat ion

Vehicles

Fig. 1. Proposed cloud-based vehicular networks architecture

contrary, roadside cloud and vehicular cloud have limitedcloud resources but satisfying communications quality. Third,we emphasize the efficiency, continuity and reliability of cloudservices for mobile vehicles. As a consequence, efficient cloudresources management strategies are elaborately proposed.Countermeasures to deal with vehicle mobility are devised.

The remainder of the article is organized as follows. SectionII illustrates the proposed architecture that includes vehicularcloud, roadside cloud, and central cloud. Cloud deploymentstrategies are discussed for these three layers. Section IIIenvisions several promising applications for different resourcessharing in cloud-based vehicular networks. In Section IV, wefocus on cloud resource allocation problems and a game-theoretical approach is presented to optimally allocate cloudresources. In Section V, we study virtual machine migrationdue to vehicle mobility. Illustrative results indicate resourceallocation optimization and virtual machine migration perfor-mance. The conclusion is presented in Section VI.

II. PROPOSEDCLOUD-BASED VEHICULAR NETWORKS

ARCHITECTURE

Fig.1 shows the proposed cloud architecture for vehicularnetworks. It is a hierarchical architecture that consists of threeinteracting layers: vehicular cloud, roadside cloud, and centralcloud. Vehicles are mobile nodes that exploit cloud resourcesand services.

• Vehicular Cloud: a local cloud established among a groupof cooperative vehicles. An inter-vehicle network, i.e., avehicular ad hoc network (VANET), is formed by V2Vcommunications. The vehicles in a group are viewedas mobile cloud sites and they cooperatively create avehicular cloud.

• Roadside Cloud: a local cloud established among a setof adjacent roadside units. In a roadside cloud, there arededicated local cloud servers attached to Roadside Units(RSUs). A vehicle will access a roadside cloud by V2Rcommunications.

• Central Cloud: a cloud established among a group ofdedicated servers in the Internet. A vehicle will access acentral cloud by V2R or cellular communications.

This architecture has several essential advantages. First, thearchitecture fully utilizes the physical resources in an entirenetwork. From vehicles to roadside infrastructures and datacenter, the computation and storage resources are all mergedinto the cloud. All clouds are accessible to all vehicles. Second,the hierarchical nature of the architecture allows vehicles usingdifferent communication technologies to access to differentlayers of clouds accordingly. Hence, the architecture is flexibleand compatible with heterogeneous wireless communicationtechnologies, e.g., DSRC, LTE/LTE-Advanced and CR tech-nologies. Third, the vehicular clouds and the roadside cloudsare small-scale localized clouds. Such distributed cloudscanbe rapidly deployed and provide services quickly.

A. Vehicular Cloud

In a vehicular cloud, a group of vehicles share their com-putation resources, storage resources, and spectrum resources.Each vehicle can access the cloud and utilize services forits own purpose. Through the cooperation in the group, thephysical resources of vehicles are dynamically scheduled ondemand. The overall resource utilization is significantly en-hanced. Compared to an individual vehicle, a vehicular cloudhas much more resources.

Due to vehicle mobility, vehicular cloud implementationis very different from a cloud in a traditional computer net-work. We propose two customization strategies for vehicularclouds: Generalized Vehicular Cloud Customization (GVCC)and Specified Vehicular Cloud Customization (SVCC).

In GVCC, a cloud controller is introduced in a vehicularcloud. A cloud controller is responsible for the creation,maintenance, and deletion of a vehicular cloud. All vehicleswill virtualize their physical resources and register the virtualresources in the cloud controller. All virtual resources ofthevehicular cloud are scheduled by the cloud controller. If a

3

vehicle needs some resources of the vehicular cloud, it shouldapply to the cloud controller. In contrast to GVCC, SVCC hasno cloud controller. A vehicle will specify some vehicles ascandidate cloud sites, and directly apply for resources fromthese vehicles. If the application is approved, the correspond-ing vehicles become cloud sites, which will customize virtualmachines (VMs) according to the vehicle demand.

These two strategies, GVCC and SVCC, are quite different.With respect to resource management, GVCC is similar toa conventional cloud deployment strategy in which cloudresources are scheduled by a controller. A vehicle is not awareof the cloud sites where the VMs are built up. The cloudcontroller should maintain the cloud resources. During a cloudservice, if a cloud site is not available due to vehicle mobility,the controller should schedule a new site to replace it. InSVCC, since there is no cloud controller, a vehicle has toselect other vehicles as cloud sites and maintain the cloudresources itself. In terms of resource utilization, GVCC isableto globally schedule and allocate all resources of a vehicularcloud. GVCC has higher resource utilization than SVCC.However, the operation of the cloud controller will need extracomputation. Therefore, SVCC may be more efficient thanGVCC in terms of lower system overhead.

B. Roadside Cloud

A roadside cloud is composed of two main parts: dedicatedlocal servers and roadside units. The dedicated local serversvirtualize physical resources and act as a potential cloud site.RSUs provide radio interfaces for vehicles to access the cloud.A roadside cloud is accessible only by the nearby vehicles,i.e., those locate within the radio coverage area of the cloudsite’s RSU. This fact helps us recall the concept of acloudlet.A cloudlet is a trusted, resource-rich computer or cluster ofcomputers that is connected to the Internet and is availableforuse by nearby mobile devices [13]. In this article, we proposethe concept of a roadside cloudlet. A roadside cloudlet refersto a small-scale roadside cloud site that offers cloud servicesto bypassing vehicles. A vehicle can select a nearby roadsidecloudlet and customize a transient cloud for use. Here, we callthe customized cloud atransient cloud because the cloud canonly serve the vehicle for a while. After the vehicle moves outof the radio range of the current serving RSU, the cloud willbe deleted and the vehicle will customize a new cloud fromthe next roadside cloudlet in its moving direction.

When a vehicle customizes a transient cloud from a road-side cloudlet, it is offered by virtual resources in terms ofvirtual machine (VM). This VM consists of two interactingcomponents: the VM-base in the roadside cloudlet and theVM-overlay in the vehicle. A VM-base is a resource templaterecording the basic structure of a VM, while a VM-overlaymainly contains the specific resource requirements of thecustomized VM. Before a cloud service starts, the vehicle willsend the VM-overlay to the roadside cloudlet. After combiningthe VM-overlay with the VM-base, the roadside cloudletcompletes the customization of a dedicated VM. During acloud service, as the vehicle moves along the roadside, it willswitch between different RSUs. For the continuity of cloud

service, the customized VM should be synchronously trans-ferred between the respective roadside cloudlets. This processis referred to as VM migration. VM migration scenarios willbe further elaborated in Section V.

C. Central Cloud

Compared to a vehicular cloud and a roadside cloud, acentral cloud has much more resources. The central cloud canbe driven by either dedicated servers in vehicular networksdata center or servers in the Internet. A central cloud is mainlyused for complicated computation, massive data storage, andglobal decision. There already exist mature open source orcommercial software platforms that could be employed forthe deployment of a central cloud. Openstack is an opensource cloud platform using Infrastructure as a Service (IaaS)model. Other potential commercial platforms are Amazon WebServices, Microsoft Azure and Google App Engine.

III. PROMISING APPLICATIONS OFCLOUD-BASED

VEHICULAR NETWORKS

With powerful cloud computing, cloud-based vehicular net-works can support many unprecedented applications. In thissection, we illustrate potential applications and explaintheexploitation of a vehicular cloud, a roadside cloud, and acentral cloud to facilitate new applications.

A. Realtime Navigation with Computation Resources Sharing

In a realtime navigation application, the computation re-sources in the central cloud is utilized for traffic data mining.Vehicles may offer services that use resources that are outsidetheir own computing ability. Different from traditional navi-gation that can only provide static geographic maps, realtimenavigation is able to offer dynamic three-dimensional mapsand adaptively optimize routes based on traffic data mining.

In Fig. 2(a), vehicleA is using realtime navigation duringits traveling. It will first request cloud service from the centralcloud and the roadside cloud. Then, a VM cluster and a VMare established in the central cloud and the roadside cloud,respectively. The VM cluster-A in the central cloud is in chargeof traffic data mining and will suggest several routes basedon the current traffic conditions. Once a route is selected byA, realtime navigation starts. VM-A in the roadside cloudacts as an agent to push messages to vehicleA, updatingthe driver with traffic conditions on the road. As vehicleAmoves on, VM-A will migrate to different roadside cloud sites.During the entire travel, VM cluster-A in the central cloudwill keep updating the route information based on realtimetraffic condition. Once there is an unexpected event, e.g., trafficcongestion, VM cluster-A will report the situation timely andcompute a new route.

B. Video Surveillance With Storage Resource Sharing

Video surveillance is an important application that utilizesshared storage resources. Currently, many buses in a city haveinstalled High-Definition (HD) camera systems to monitor in-bus conditions. A very large-volume hard-drive is needed to

4

Guest VM- A

A

C

Large- Volum e File

File Dow nload App.

Cooperat ive dow nload

Cooperat ive dow nload

Filesegm ent - 3

Fil

eS

eg

me

nt-

2

Roadside Cloudlet - 1

Roadside Cloudlet - 2

Centra l Cloud

I nternet

A

Guest VMCluster- A

Route

Guest VM- A

Local m ap & Route

Traffic data m ining

Navigat ion App.

Navigat ion agent

Roadside Cloudlet - 1

Guest VM- A

Guest VM- A

Videosegm ent- 1

Video segm ent- 2

Video storage

A

( a) Traffic data m ining for realt im e navigat ion ( b) Dist r ibuted storage in video surveillance

Video Surveillance App. Guest VM- A

Roadside Cloudlet - 2

( c) Cooperat ive dow nload of large file

Video storage

Roadside Cloudlet - 2

Roadside Cloudlet - 1

File Segm ent- 1

B

Fig. 2. Applications of cloud-based vehicular networks

TABLE IAPPLICATIONS OFCLOUD-BASED VEHICULAR NETWORKS

Potential ApplicationsRelevant Cloud Assistance Resource Sharing

Central Cloud Roadside Cloud Vehicular Cloud Computation Storage Bandwidth

Realtime Traffic Condition Analysis and Broadcast√ √ √ √

Realtime Car Navigation√ √ √

Video Surveillance√ √

LBS Commercial Advertisement√ √ √ √

Vehicular Mobile Social Networking√ √ √ √

In-Vehicle Multimedia Entertainment√ √ √ √ √

Inter-Vehicle Video and Audio Communications√ √

Remote Vehicle Diagnosis√ √ √

store video content for a couple of days. This video storagescheme has several disadvantages. First, to save HD videocontent for days, the hard-drive should have very large storage,which leads to high cost and big size. Second, video contentcan only be checked in an off-line manner, the departmentof transportation is not able to make timely and proper deci-sions immediately after an accident. In cloud-based vehicularnetworks, a new distributed storage paradigm can addressthis problem. The storage capability of in-bus video camerasystems is significantly extended.

In Fig. 2(b), busA exploits the roadside cloud to facilitatestorage of in-bus video surveillance content. Specifically, thebus applies for cloud services and receives a VM in the road-side cloud. The video content is uploaded to the guest VM-Ain the roadside cloudlet-1 in a realtime manner. When the busmoves along the road and is located in the coverage area ofthe roadside cloudlet-2, VM-A will be migrated accordingly.As a result, the video content is divided into several segmentsand separately stored in different roadside cloudlets along theroad. The video segments in the roadside cloudlets will betransmitted to a data center on demand. When an accidentis reported, department of transportation can request roadsidecloudlets to send back video to the data center.

C. Cooperative Download/Upload with Bandwidth Sharing

Cooperative downloading and uploading services are in-teresting applications that share bandwidth resources. Many

new applications involves large-volume data uploading ordownloading. Typical examples include in-vehicle multimediaentertainment, location-based rich-media advertisements, andbig-size e-mail services. Due to limited wireless bandwidthand vehicle movement, it is very difficult to download an entirelarge file from a specific RSU. While the vehicle drives by,there is not enough time to complete the download of largeamount of data. Here, we illustrate that the usage of a vehicularcloud will make such applications feasible.

In Fig. 2(c), vehicleA is going to download a large file fromthe roadside infrastructure. The cooperative downloadinghastwo phases. In the first phase, vehicleA observes neighboringvehiclesB andC and then setups a vehicular cloud for coop-erative downloading. Then, a guest VM will be constructed inbothB andC. The file downloading will be carried out by thevehicular cloud that consists of vehicleA and the two VMsonB andC. Since the file is downloaded by three vehicles ina parallel manner, the total transmission rate becomes muchfaster. In this way, vehicleA has high possibility to finishdownloading before vehicleA moves out of the range ofthe roadside infrastructure. In the second phase, the VMs inB and C will further cooperatively transmit two separatedsegments of the file toA. Since only V2V communicationsis involved, the second phase can be performed without theroadside infrastructure. After that,A will reassemble the filesegments into an entire file.

Table I summarizes potential applications in cloud-based

5

vehicular networks. We also show the relevant cloud resourcesharing in each application.

IV. GAME-THEORETICAL APPROACH FORRESOURCE

ALLOCATION

Vehicle and roadside clouds are both resource-intensivecomponents. Resource management is very crucial for thesetwo types of clouds. Resources in vehicle and roadside cloudsare represented in form of VMs. In the literature, VM researchhas been mainly studied in computer networks. In the recentstudy [14], VM migration is considered for dynamic resourcemanagement in cloud environments. In [15], VM replicationand scheduling are intelligently combined for VM migrationacross wide area network environments. However, there arefew studies on VM resource management in mobile cloudenvironments. In [13], cloudlet is discussed and customizedin the mobile computing environments.

In this section, we mainly focus on VM resource alloca-tion in vehicular clouds and roadside clouds. In a roadsidecloud, there are multiple VMs since a cloud site providesservices to several vehicles simultaneously. In this case,theresources in a cloud site should be appropriately allocated.VM resource allocation should consider several aspects. i)Efficiency: VM resource allocation strategy should be efficientsuch that the limited resources are fully utilized. ii) Quality-of-Service (QoS): the allocated resources to a specific VMshould be sufficient for the accomplishment of the VM’s tasksto achieve its QoS requirements. iii) Fairness: VMs with thesame workload should be offered statistically equal resources.Here, we formulate the competition among the VMs for cloudresources as a non-cooperative game.

A. Game-theoretical Model

Consider a roadside cloudlet withN VMs, i.e., players ofthe game. The VMs will apply to the cloud site and competefor resources. These VMs are selfish in the sense that theyaim to obtain as much resources as possible for their ownusage. The cloud will allocate the total available resources tothe VMs in proportion to the number of requested resources.

Let C and M represent the total available computationand storage resources of the cloud site, respectively. Letci(0 < ci ≤ C) and mi (0 < mi ≤ M ) denote the numberof requested resources from thei-th VM in computation andstorage, respectively. Definec−i =

∑N

n=1,n6=i cn andm−i =∑N

n=1,n6=imn. The i-th VM will be allocated computationand storage resourcesciC

ci+c−i

and miMmi+m

−i

, respectively. Forthe sake of fairness, the cloud site sets up two Virtual ResourceCounters (VRCs) for each VM. These two VRCs are used torecord the accumulative number of applied resources, one forcomputation and the other for storage. When a VRC reaches itsmaximal value, the VM is not allowed to apply for that typeof resource. By using VRCs, the total amount of allocatedresources are equal for all VMs from a long-term perspective.Let αi and βi (αi > 0, βi > 0), respectively, denote thepredefined resource weights that indicate the importance ofcomputation and storage resources in the workloads of thei-th VM, and let λi and γi (λi > 0, γi > 0) denote

the pricing factors associated with applied computation andstorage resources, respectively, of thei-th VM. The utilityfunction, orpayoff, for the i-th VM is given by

U(ci,mi) =αiciC

ci + c−i

+βimiM

mi +m−i

− (λici + γimi) . (1)

The proposed game-theoretical model is specially devisedfor mobile cloud applications in vehicular networks. In particu-lar, the resource weightsαi andβi in the utility function makethe game model adaptable to resources preference in differentapplications. The pricing factorsλi andγi are set to preventfrom resource waste imposed by excessive competition, andthus, potentially enhance resource utilization. These keypa-rametersαi, βi, λi andγi are elaborately selected regardingthe mobile environment of the cloud-assisted vehicles. Forexample, vehicles may have different quality of radio linkstothe cloud site. Their VMs should be provided with differentαi, βi, λi and γi according to the link quality. Typicaly,in a mobile multimedia application where scalable videocoding (SVC) technique is involved, the VM is responsiblefor adaptive video decoding in the cloud site. The requiredVM resource mostly depends on the link quality. Becausethe link rate restricts the affordable quality of video stream,and consequently, determines the amount of VM resources forvideo processing.

B. Nash Equilibrium

In a non-cooperative game, a Nash equilibrium is a balancedstate with a strategy profile, from which no game playerhas any incentive to deviate. In the proposed VM resourceallocation game, by computing the second order derivativeof U(ci,mi) with respect toci andmi respectively, we get∂2U∂ci

2 = − 2αic−iC

(ci+c−i)3

< 0 and ∂2U∂mi

2 = − 2βim−iM

(mi+m−i)3

< 0. Thismeans that,U(ci,mi) is a concave function with respect toci or mi. Therefore, the existence of a Nash equilibrium isproven in the VM resource allocation game model [16]. Giventhe other VMs’ applications, say,c−i and m−i, we define(c∗i ,m

∗i ) ∈ argmaxU(ci,mi) as thebest response,t or called

optimal strategy, of the i-th VM in each iteration. We have

c∗i = min

(

C,

√

αic−iC

λi

− c−i

)

,

m∗i = min

(

M,

√

βim−iM

γi−m−i

)

.

(2)

To prove the uniqueness of Nash equilibrium in the VM re-source allocation game, we can validate that the best responsefunction is a standard function, which has three features: posi-tivity, monotonicity and scalability [16]. Follwing (2), it is easyto prove that the sufficient conditions for the uniqueness ofNash equilibrium are∀i, αi ≥ 4(N−1)λi andβi ≥ 4(N−1)γi.

Fig.3 shows a numerical example of resource allocationin our game-theoretical model. In the example, there arethree VMs in a roadside cloud. The total available resourcesin computation and storage are set to50 and 100 units,respectively. The VMs have different resource demands. VM-1 has the highest demand on computation while VM-2 has

6

Computation Storage Utility0

5

10

15

20

25

30

35

40

VM−1VM−2VM−3

Fig. 3. Resource allocation result in roadside cloud

the highest demand on storage. We randomly select initialvalues of the resource applications for the three VMs, say,c{1,2,3} = {10, 5, 5} and m{1,2,3} = {5, 15, 10}. In thesimulation, it is observed that the game iteration convergesfast. The game reaches its Nash equilibrium after nearly10 rounds of iterations. Results indicate that the resourcesare appropriately allocated based on demand. In particular,VM-1, VM-2 and VM-3 are allocated21.4, 14.3, 14.3 unitsin computation, respectively. VM-1, VM-2 and VM-3 areallocated31.1, 37.8, 31.1 units in storage, respectively.

V. RESOURCERESERVATION SCHEME FORV IRTUAL

MACHINE M IGRATION

A. Virtual Machine Migration Scenarios

VM migration refers to the process that an operating VM istransferred along with its applications across different phys-ical machines. In a VM migration, a VM image has to becopied from the source to the destination roadside cloudlets.Different from traditional VM migration, VM migration incloud-based vehicular networks has several different scenariosdue to different deployments of roadside clouds and vehiclesmovements.

• Inter-Cloudlet Case: In Fig. 4(a), when vehicleA movesfrom the coverage area of RSU-1 to that of RSU-2, a VMmigration is needed. Since RSU-1 and RSU-2 connectto different cloudlets, guest VM-A should be transferredfrom roadside cloudlet-1 to roadside cloudlet-2. Afterthat, A will access cloudlet-2 via RSU-2 to resume itsservice.

• Intra-Cloudlet Case: In Fig. 4(b), vehicleA moves fromthe coverage area of RSU-1 to that of RSU-2. Since thesetwo RSUs connect to the same roadside cloudlet, there isno need for VM migration. However, radio handoff fromRSU-1 to RSU-2 may still take a short period. Duringhandoff, the interaction between vehicleA and guest VM-A may be temporally suspended.

• Across Roadside-vehicular cloud Case: In Fig. 4(c), ve-hicle A moves from the coverage area of RSU-2 to that

of RSU-1. BeforeA’s movement, nodesA, C and D

have connection in an ad hoc manner. VehicleC accessthe roadside cloud through vehicleA. The movement ofA will cause the disconnection ofC from the roadsidecloud. In this case, guest VM-C will be transferred fromthe roadside cloud to the vehicle cloud inD. Then,vehicleC can continue its service throughD.

• Across Roadside-Central Cloud Case: The scenario inFig. 4(d) is similar to that in Fig. 4(c), except that thereis no direct link between vehiclesC andD in Fig. 4(d).In this case, guest VM-C has to be migrated from theroadside cloud to the central cloud. After that,C willaccess the central cloud to resume its service by long-distance communications, e.g., 3G/4G cellular.

B. Resource Reservation Scheme

The discussion about VM migration indicates that the VMmigration process involves resource re-allocation in roadsidecloud. If the resources of the destination cloud have beenintensively occupied, after a VM migration and resource re-allocation, some of the VMs may not have sufficient resourcesand may not even resume their services. In order to avoidresource over-commitment, the target cloud site has to denythe VM migration so as to maintain the services of the existingVMs. In this case, the cloud service of a vehicle with VMmigration is said to be dropped. To reduce service dropping,we propose a resource reservation scheme. In this scheme, asmall portion of the cloud site resources are reserved merelyfor migrated VMs, but not for local VMs. When there arededicated resources for VM migration, the dropping rate ofcloud services will be significantly decreased.

In the proposed resource reservation scheme, resources aredivided into two categories: reserved resources and commonresources. LetCr andMr denote the reserved resources, andCc = C − Cr and Mc = M − Mr the common resourcesin computation and storage, respectively. In VM migration,aVM arrival refers to the event that a VM is created either fora new local VM or a migrated VM. AVM departure refersto the request of a VM deletion, either for an ending of VMservice or VM migration to another cloud site. The resourcereservation scheme operates as follows:

• Local VM arrival: When there is a request for creatinga new local VM, resource allocation will be carriedout, e.g., using the proposed game-theoretic allocationscheme. Since a part of the resources are reserved, thelocal VMs can only share the common resources. If theresource allocation result satisfies all existing VMs, thenew local VM is admitted; otherwise, it is blocked.

• Local VM departure: Resource allocation is also per-formed when the service of a local VM ends or migratesto another cloud site.

• Migrated VM arrival: Upon a request for a VM mi-gration, the target cloud site will re-allocate resources.In this case, the reserved resources will be also takeninto account. Specifically, the existing local VMs and themigrated VM will share all available resources. After re-allocation, if all the VMs (including the migrated VM)

7

RSU-1A

B

Roadside

Cloudlet

Guest VM-A

Guest VM-B

Guest VM-CRSU-1

RSU-2

A

B

A

C

D

Roadside Cloudlet-1

Guest VM-A

Guest VM-B

Guest VM-A

Guest VM-C

Guest VM-D

VM migration

RSU-1

RSU-2

A

B

AC

No need for migration

Guest VM-A

Guest VM-B

Guest VM-C

RSU-2

A

C

D

Guest VM-C

VM migration

newnew

new

Roadside Cloudlet-2

Roadside

Cloudlet

(a) Inter-Cloudlet (b) Intra-Cloudlet

(c) Across Roadside-Vehicular Cloud

RSU-1

RSU-2

A

B

AC

Guest VM-A

Guest VM-B

Guest VM-C

VM migration

new

Roadside

Cloudlet

(d) Across Roadside-Central Cloud

D

CentralCloud

BS

Guest VM-C

D

Fig. 4. Virtual machine migration scenarios

resource requests are satisfied, VM migration is approved;otherwise, the VM migration request is rejected.

• Migrated VM departure: Resource allocation is also per-formed when the service of a migrated VM ends or itmigrates to another cloud site. It is noticeable that, if thereis no migrated VMs in a cloud site, the resource allocationcan only use common resources. The reserved resourceswill be conserved for further usage upon another VMmigration.

C. Optimal Resource Reservation

We considerK classes of VMs. Letck andmk representthe amount of required resources by thek-th class of VMsin computation and storage, respectively. Letnl

k and ngk

denote the number of local and migrated VMs of classk,respectively. Suppose that the arrivals and departures of bothlocal and migrated VMs follow a Poisson process model.The system state transition may be formulated as continuous-time Markov process. Letnl = (nl

1, · · · , nlk, · · · , n

lK) and

ng = (ng1, · · · , n

gk, · · · , n

gK). We represent the system state

by s = (nl,ng) and the state space byS. Let πs denotethe steady state probability of states. Given the arrival anddeparture rates of new and migrated VMs, the steady stateprobability matrixΠ = {πs|s ∈ S} will be derived by a2K-dimension Markov chain model.

Let Rb andRd denote the blocking rate and the droppingrate, respectively. Then, a new local VM is blocked if thetotal amount of required resources of the local VMs (includingthe new one) exceeds that of the common resources, i.e.,∑K

k=1 nlkck > Cc or

∑K

k=1 nlkmk > Mc. A migrated VM is

dropped if the total amount of required resources of all VMs(including the migrated one) is more than that of all resources,i.e.,

∑K

k=1(nlk +n

gk)ck > C or

∑K

k=1(nlk +n

gk)mk > M . Let

λlk, µl

k, λgk andµ

gk denote the arrival and departure rates of

local and migrated VMs, thenSb and Sd the sets of statesthat encounter blocking and dropping, respectively. We canderive Rb(Cr ,Mr) =

∑

s∈Sb

∑

k πsλlk, and Rb(Cr ,Mr) =

∑

s∈Sd

∑

k πsλgk. LetRc

b denote the constraint of the blockingrate. The optimal number of reserved resources is derived bysolving the following optimization problem.

min Rd(Cr,Mr),

s.t. Rb(Cr,Mr) ≤ Rcb.

(3)

Fig.5 shows a performance comparison with and withoutresource reservation. The total resources of the roadside cloudsare50 and100 units in computation and storage, respectively.Two classes of VMs are considered. VMs of class-1 are mainlyfor computation-type applications, which needs20 units incomputational resources and15 units in storage resources.VMs of class-2 are mainly for storage-type applications, whichneed 10 units in computational resources and40 units in

8

0.1 0.15 0.2 0.25 0.30

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1x 10

−3

Arrival Rate of Local VMs

Rd

Reservation (Rbc=0.01)

Reservation (Rbc=0.02)

No reservation

Fig. 5. Dropping rate in terms of local VM arrival rate

storage resources. The two classes of VMs are assumed to haveidentical in arrival and departure rates. We set the range oflocal VM arrival rate from0.1 to 0.3, the local VM departurerate by2.0, the arrival and departure rates of migrated VM by0.05 and 0.1, respectively. The simulation results show thatthe dropping rate of migrated VMs is significantly reducedwith resource reservation, which demonstrates the efficiencyof our proposed mechanism.

VI. CONCLUSIONS

In this article, we first discussed the opportunities and chal-lenges in exploiting cloud computing in vehicular networks.Then, we presented a hierarchical architecture for cloud-basedvehicular networks that facilitates sharing of computationalresources, storage resources and bandwidth resources amongvehicles. Furthermore, we focused on efficient resource man-agement in the proposed architecture. The resource compe-tition among virtual machines is formulated and solved in agame-theoretical framework. Virtual resource migration due tovehicle mobility is addressed based on a resource reservationscheme. Finally, illustrative results indicated a significantreduction of the service dropping rate during virtual machinemigration.

ACKNOWLEDAGEMENT

This research is partially supported by program of NSFC(grant no. U1035001, U1201253, 61203117), the OpeningProject of Key Lab. of Cognitive Radio and Information Pro-cessing (GUET), Ministry of Education (grant no. 2011KF06),the project 217006 funded by the Research Council of Norway,the European Commission FP7 Project EVANS (grant no.2010-269323), and the European Commission COST ActionIC0902, IC0905 and IC1004.

REFERENCES

[1] M. Miche, and T. M. Bohnert, “The Internet of Vehicles or the SecondGeneration of Telematic Services”,ERCIM News, vol. 77, pp. 43-45,2009.

[2] ITU Strategy and Policy Unit (SPU),ITU Internet Reports 2005: TheInternet of Things, Geneva, International Tele-communication Union(ITU), 2005.

[3] J. Chen, X. Cao, Y. Zhang, W. Xu, Y. Sun, “Measuring the performanceof movement - assisted certificate revocation list distribution in VANET”,Wireless Communications and Mobile Computing, 11 (7), 888-898,2011.

[4] WHO, World health report 2002: reducing risks, promoting healthy life,Geneva, World Health Organization, 2002.

[5] R. A. Uzcategui, and G. Acosta-Marum, “WAVE: A Tutorial”, IEEECommunications Magazine, vol. 47, no. 5, pp. 126-133, May 2009.

[6] R. Yu, Y. Zhang, Y. Liu, S. Xie, L. Song and M. Guizani, “SecondaryUsers Cooperation in Cognitive Radio Networks: Balancing SensingAccuracy and Efficiency”,IEEE Wireless Communications Magazine,vol. 19, no. 2, April 2012, pp.2-9.

[7] S. Xie, Y. Liu, Y. Zhang, and . Yu, “A Parallel CooperativeSpectrumSensing in Cognitive Radio Networks”,IEEE Transactions on VehicularTechnology, vol. 59, no. 8, pp.4079 C 4092, 2010.

[8] T. Wang, L. Song, and Z. Han, “Coalitional Graph Games forPopularContent Distribution in Cognitive Radio VANETs,” to appear, IEEETransactions on Vehicular Technologies.

[9] T. Wang, L. Song, Z. Han, and B. Jiao “Popular Content Distributionin CR-VANETs with Joint Spectrum Sensing and Channel Access,” toappear,IEEE Journal on Selected Areas in Communications.

[10] S. Olariu, M. Eltoweissy and M. Younis, “Towards Autonomous Ve-hicular Clouds,” ICST Transactions on Mobile Communications andApplications, vol. 11, no. 7-9, pp. 1-11, 2011.

[11] D. Bernstein, N. Vidovic and S. Modi, “A Cloud PAAS for High Scale,Function, and Velocity Mobile Applications - With Reference Applica-tion as the Fully Connected Car, inProc. Fifth International Conferenceon Systems and Networks Communications (ICSNC), pp. 117-123, 2010.

[12] R. Hussain, J. Son, H. Eun, S. Kim and H. Oh, “Rethinking VehicularCommunications: Merging VANET with cloud computing”, inProc.IEEE 4th International Conference on Cloud Computing Technologyand Science, pp. 606-609, 2012.

[13] M. Satyanarayanan, P. Bahl, R. Caceres, and N. Davies. “The Case forVM-based Cloudlets in Mobile Computing”,IEEE Pervasive Comput-ing, vol. 8, no. 4, 2009.

[14] M. Mishra, A. Das, P. Kulkarni, A. Sahoo, ”Dynamic resource man-agement using virtual machine migrations”,IEEE CommunicationsMagazine, vol. 50, no. 9, pp. 34-40, 2012.

[15] S. K. Bose, S. Brock, R. Skeoch and S. Rao, “Cloudspider:Combiningreplication with scheduling for optimizing live migrationof virtualmachines across wide area networks”, inProc. International Symp. onCluster, Cloud and Grid Computing, pp.13-22, 2011.

[16] D. Fudenberg, J. Tirole.Game Theory, MIT Press, Cambridge, MA,1991.

Rong Yu [S05, M08] (yurong@ieee.org) received his Ph.D. from TsinghuaUniversity, China, in 2007. After that, he worked in the School of Elec-tronic and Information Engineering of South China University of Technol-ogy (SCUT). In 2010, he joined the Institute of Intelligent InformationProcessing at Guangdong University of Technology (GDUT), where he isnow an associate professor. His research interest mainly focuses on wirelesscommunications and networking, including cognitive radio, wireless sensornetworks, and home networking. He is the co-inventor of over10 patents andauthor or co-author of over 50 international journal and conference papers.Dr. Yu is currently serving as the deputy secretary general of the Internet ofThings (IoT) Industry Alliance, Guangdong, China, and the deputy head ofthe IoT Engineering Center, Guangdong, China. He is the member of homenetworking standard committee in China, where he leads the standardizationwork of three standards.

9

Yan Zhang [SM10] (yanzhang@ieee.org) received a Ph.D. degree fromNanyang Technological University, Singapore. He is working with SimulaResearch Laboratory, Norway; and he is an adjunct AssociateProfessor atthe University of Oslo, Norway. He is an associate editor or guest editor ofa number of international journals. He serves as organizingcommittee chairsfor many international conferences. His research interests include resource,mobility, spectrum, energy, and data management in wireless communicationsand networking.

Stein Gjessing (steing@ifi.uio.no) is a professor of computer science inDepartment of Informatics, University of Oslo and an adjunct researcher atSimula Research Laboratory. He received his Dr. Philos. degree from theUniversity of Oslo in 1985. Gjessing acted as head of the Department ofInformatics for 4 years from 1987. From February 1996 to October 2001 hewas the chairman of the national research program Distributed IT-System,founded by the Research Council of Norway. Gjessing participated in threeEuropean funded projects: Macrame, Arches and Ascissa. Hiscurrent researchinterests are routing, transport protocols and wireless networks, includingcognitive radio and smart grid applications.

Wenlong Xia (wenlong.xia@ieee.org) received his M.S. degree in electronicsengineering from the PLA Information Engineering University, China in 2011.Now he is pursuing his M.S. degree in signal and information processingfrom Guangdong University of Technology (GDUT), China. Hisresearchinterests include vehicular wireless networks, opportunistic networks andcloud computing.

Kun Yang (kunyang@essex.ac.uk) received his PhD from the Departmentof Electronic & Electrical Engineering of University College London (UCL),UK. He is currently a full Professor in the School of ComputerScience &Electronic Engineering, University of Essex, UK, and the Head of the NetworkConvergence Laboratory (NCL) in Essex. His main research interests includewireless networks/communications, fixed mobile convergence, future Internettechnology and network virtualization. He has published over 150 papers inthe above research areas. He serves on the editorial boards of both IEEE andnon-IEEE journals. He is a Senior Member of IEEE and a Fellow of IET.