sporadic cloud-based mobile augmentation on the top of a virtualization layer: a case...

Research ArticleSporadic Cloud-Based Mobile Augmentation on the Top ofa Virtualization Layer A Case Study of Collaborative Downloadsin VANETs

Esteban Fernando Ordoacutentildeez-Morales 1 Mart-n Loacutepez-Nores 2

Yolanda Blanco-Fernaacutendez 2 Efren Patricio Reinoso-Mendoza1

Jack Fernando Bravo-Torres 1 Joseacute V-ctor Saiaacutens-Vaacutezquez2

Joseacute Juan Pazos-Arias 2 Manuel Ramos-Cabrer 2 and Alberto Gil-Solla 2

1Universidad Politecnica Salesiana Calle Vieja 12-30 y Elia Liut Cuenca Ecuador2Atlantic Research Center for Information and Communication Technologies (AtlantTIC) University of Vigo Spain

Correspondence should be addressed to Esteban Fernando Ordonez-Morales eordonezupseduec

Received 28 November 2018 Revised 28 January 2019 Accepted 27 February 2019 Published 21 March 2019

Academic Editor Yair Wiseman

Copyright copy 2019 Esteban FernandoOrdonez-Morales et alThis is an open access article distributed under the Creative CommonsAttribution License which permits unrestricted use distribution and reproduction in any medium provided the original work isproperly cited

Current approaches to Cloud-based Mobile Augmentation (CMA) leverage (cloud-based) resources to meet the requirements ofrichmobile applications so that a terminal (the so-called application nodeorAppN) can borrow resources lent by a set of collaboratornodes (CNs) In themost sophisticated approaches proposed for vehicular scenarios the collaborators are nearby vehicles that mustremain together near the application node because the augmentation service is interrupted when they move apart This leads todisruption in the execution of the applications and consequently impoverishes the mobile usersrsquo experience This paper describesa CMA approach that is able to restore the augmentation service transparently when AppNs and CNs separate The functioning isillustrated by a NaaS model where the AppNs access web contents that are collaboratively downloaded by a set of CNs exploitingboth roadside units and opportunistic networking The performance of the resulting approach has been evaluated via simulationsachieving promising results in terms of number of downloads average download times and network overhead

1 Introduction

The incorporation of on-board units (OBUs) into vehiclesallows envisaging advanced information services groundedon vehicle-to-vehicle communications and the possibilityof accessing the Internet via roadside infrastructure Theseservices allow (i) delivering information of interest betweenthe occupants of the vehicles (eg chats among driversproactive organization of ride-sharing opportunities selec-tive distribution of personalized advertising or collabora-tive downloading of web contents [1 2]) and (ii) enablingintelligent transportation systems offering increased trafficsafety smart parking or traffic flow optimization just toname a few [3 4] Sharing and managing this kind ofdata requires the running of resource-intensive applications

and to this aim both the vehiclesrsquo OBUs and the occu-pantsrsquo mobile devices need to be augmented to have extraprocessingstoragedownloadingsensing capabilities Inliteraturemost of approaches resort toMobile CloudComput-ing (MCC) to bring rich computational resources to mobileusers and more specifically to Vehicular Cloud Computing(VCC) when the augmentation resources are lent by othervehicles within a vehicular ad hoc network (VANET) [5]Both paradigms are under the umbrella of the so-calledCloud-based Mobile Augmentation (CMA) where a set ofnodes (hereafter called collaborator nodes or CNs) lendtheir own resources to augment the capabilities of the so-called application node (AppN) For that purpose currentCMA approaches leverage cloud-based resources to meet therequirements of rich mobile applications by offloading (part

HindawiJournal of Advanced TransportationVolume 2019 Article ID 3548213 21 pageshttpsdoiorg10115520193548213

2 Journal of Advanced Transportation

of) their codes and the data required for their executionto a remote server According to the taxonomy of [6]existing CMA solutions can be categorized into four maintypes as per the location and mobility of the augmentationclouds distant immobile clouds proximate immobile cloudsproximate mobile clouds and hybrid approaches that combinethe previous models [7 8]

(i) The distant immobile clouds (MCC) are supportedby public and private clouds that comprise a largenumber of stationary remote servers that are typicallylocated far from vehicles The distance to the basestation along with the interference caused by thepresence of buildings or a high number of simulta-neously connected users leads to problems of highlatency and low bandwidth that greatly degrade theexperience of mobile users and hamper the deploy-ment of non-delay tolerant information services [910]

(ii) In order to tackle problems related to bandwidth andlatency some CMA solutions adopt proximate immo-bile clouds (typically named cloudlets) that involvestationary computers located in public places near thevehicles (eg parking lotsmalls and airports) whoseresources are typically underutilized The problemis that these approaches significantly limit the usersrsquomobility because resource-intensive mobile applica-tions can be just executed in the area around thecloudlet [11]

(iii) The most recent CMA approaches rely on proximatemobile clouds (VCC) where nearby vehicles lend theirresources to other vehicles to perform intensive com-putations in a distributed manner [12] Despite theirname the first approaches proposed in this regard dis-regarded the mobility of the augmentation nodes (byhandling instead clusters of fixed handheld devices)due to the open challenges related to this trait (suchas communication disruption as the users move andthe consequent frequent interruptions of applicationexecution [13]) More sophisticated approaches aroselater in literature [14 15] However in these solutionsthe management of the mobility continues beingan open problem due to the fact that they restrictthe movements of the AppN and its collaborators(requiring for instance that all these nodes remaintogether during the augmentation process whichis interrupted when AppN and CNs move away)[16ndash18]

Bearing in mind the above limitations in [19] we pro-posed an approach where the augmentation resources weresharedlent by a sporadic cloud of near vehicles that remaintogether during a certain period of time For that reasonwe coined our approach as Sporadic Cloud-based MobileAugmentation (hereafter S-CMA) which is based on a newparadigm we have called Sporadic Cloud Computing (SCC)

In other words S-CMA is based on the SCC principles inthe same way that traditional CMA relies on MCCVCCfoundations In particular in [19] we envisaged the commonfoundations for the deployment of diverse ldquoXrdquoaaS servicemodels over a VANET (such as Networking as a Service(NaaS) STorage as a Service (STaaS) Computing as a Service(CaaS) and SEnsing as a Service (SEaaS) just to name a few)Later in [20] we focused on the particular refinements thatworking on the top of the common basis were required in aNaaS service In this paper we have extended that previouswork developing a hybrid S-CMA approach that exploitsboth the augmentation capabilities of a sporadic cloud of on-move vehicles and the resources available at roadside-fixedinfrastructure (through WiFi access points) Unlike existingCMA approaches our sporadic cloud comprises an ad hoccluster of mobile devices that do move freely where (i) their(high) mobility is managed by a virtualization layer (namedVaNetLayer) that engages the mobile nodes in collaborationto emulate a reliable infrastructure of stationary virtualnodes [21] and (ii) a seamless handover allows restoring theaugmentation service transparently for the applications whenAppN and CNs separate

In our approach the web contents will be splitted intochunks that the CNs must download (from a remote server)and finally deliver to the AppN To this aim we exploit aNaaS model that supports both individualized access to webcontents of interest for just one vehicle within the VANET(hereafter individual content) and access to popular contentsthat are appealing to allmost of the vehicles within the adhoc network thus leading to two download models whichwe will be referred to as individual content download (ICD)and popular content download (PCD) respectively As amain difference in PCD some collaborator nodes could havedownloaded previously (for other interested AppNs) andlocally stored some chunks of the requested popular contentswhereas in ICD (all the pieces of) the individual contentsmust be always retrieved from the Internet In conclusionwe contribute with a new hybrid S-CMA approach for thedeployment of a NaaS model for collaborative download ofweb contents inVANETs working on the top of virtualizationmechanisms that hide the complexity derived from themobility of the augmentation cloud which is an issue thatto the best of our knowledge remains unresolved in theliterature

This paper is organized as follows In Section 2 we presenta review of existing approaches to collaborative download ofweb contents in VANETs along with the mechanisms thatare typically adopted to incentivize the involvement of nodesin augmentation tasks Next Section 3 summarizes the mainfoundations of the virtualization layer (VaNetLayer) and therouting protocol (VNIBR) on which our hybrid S-CMAapproach works The S-CMA mechanisms envisaged for thedeployment of ourNaaSmodel will be presented in Section 4The experiments carried out to assess the performance ofour proposal in terms of number of downloads downloadtime networking overhead and some augmentation-specificmetrics will be described in Section 5 Lastly Section 6concludes the paper and points out some lines of furtherwork

Journal of Advanced Transportation 3

2 Related Works

In literature we can found many approaches to collaborativedownload of popular content from the web that are based onV2I communications As we will detail in Section 21 someof them take advantage of the formation of groups vehiclesthat travel together on the road in order to download contentand then share it [22ndash25] whereas other works are supportedby vehicles parked on the streets [12 26ndash29] or even vehiclesthat form clusters according to their geographical positions[16 30] Beyond the technical challenges these approachesrequire incentive mechanisms to promote the collaborationof the nodes during the download processes (Section 22)

21 Collaborative Download SPAWN was one of the firstprotocols for collaborative download of Internet contents inVANETs [31] SPAWN manages groups (swarms) of mobilenodes that get different chunks ofweb contents (seeds) duringperiods of connectedness A gossip mechanism propagatescontent availability information within the swarms so thatthe nodes can get chunks they are missing from one anotherChunks are transmitted by TCP at the transport layerwhereasUDP is adopted for gossipmessages CarTorrent [23]was proposed as an evolution of SPAWN with a differentstrategy to select chunks to download a refined gossipmechanism and additional controls to use only UDP atthe transport layer (due to the bad behavior of TCP incase of frequent packet losses) Later CodeTorrent proposesnew mechanisms to speed up the content dissemination andbe more resilient against fast mobility relying on single-hop unicast with overhearing [24] With a slightly differentperspective MobTorrent uses Wireless Wide-Area Networks2G3G4G (WWANs) to provide a communication channelso that (i) the vehicles can upload information to the accesspoints in order for the remaining vehicles to be able todownload it when they are within their coverage area and (ii)the vehicles can offer themselves as collaborators to carry thecontent they have previously downloaded for other vehicles[25]

In [32] Huang et al proposed a k-hop bandwidth aggre-gation scheme for cooperative video streaming in a vehic-ular environment by using 3G35G and Dedicate Short-Range Communications (DSRC) ad hoc networks alongwith nearby vehicles as collaborators nodes In [16] Firoozand Roy present a more restrictive cooperative downloadscheme which requires that the vehicles remain close fromeach other and keep the same route on the way The sameconstraints are valid for the approach described in [33] whereWang et al describe a mechanism for downloading popularcontent by deploying a P2P network where the content to bedownloaded is divided into chunks that are distributed overthe VANET and finally delivered to all the vehicles

In [26] Liu et al presented ParkCast an approach thatexploits the networking capabilities of parked vehicles atroadsideThese nodes are grouped in a cluster with one of thevehicles being selected as coordinator for data transmissionThe vehicles can both upload information to the cluster ofparked nodes and download data from it as long as they staywithin its coverage area Similarly in [30] Huang and Wang

presented a cell-based clustering scheme named EfficientCollaborative Downloading Scheme (ECDS) that works ondistributing popular content in urban vehicular networksIn ECDS the vehicles join in different cells according totheir geographical positions Treating the cells as nodes theirpositions are fixed which greatly simplifies the modeling oftheVANETWhen the vehicles are outside the coverage of theroadside units they form a P2P network and collaborativelyexchange chunks to complete the popular content dissemina-tion

22 Incentive Schemes for Collaboration Usually the aboveapproaches work in tandem with different mechanisms forpromoting the collaboration among the vehicles with thegoal of improving the performance in face of topologicalchanges in the ad hoc network Even though some existingcollaboration mechanisms are categorized as per the kind ofad hoc networkwhere they are deployed (MANETsVANETs)and the type of transmitted information (non-delaydelaytolerant) there exist two main trends (i) monetary rewardsystems and (ii) reputation-based systems The first oneshandle virtual money that can be finally exchanged forreal money and resort to a central entity that manages the(economic) transactions made by the collaborator nodes Inthe reputation-based collaboration system the collaboratorsgain reputation scores as they collaborate in the network

As examples of monetary reward systems we can cite theapproach by Chen et al presented in [34] where the authorspropose a collaborative mechanism based on coalitionalgame theory that rewards the cooperation among the nodesinvolved in a routing protocol This approach includes avirtual credit center [35] that keeps updated the amount ofvirtual money of each node whose value is increased as thenodes collaborate in the forwarding of messages In the sameline in [36] Ananthanarayanan et al propose an approachto collaborative download called COMBINE which adoptsa cooperation solution with monetary incentives for nodesthat sell their (unused) bandwidth to augment the capabilitiesof other nodes within the network so that the collaboratorsoffering the best prices can be chosen In COMBINE thetransactions and payments among nodes are protected bysecurity mechanisms based on public and private keys In[37] Caballero et al propose a mechanism where the rewardfor each collaborator node is computed once the contentthey have downloaded is finally delivered to the applicationnode by considering their percentage of participation in thisprocess

Regarding reputation-based collaboration systemsDotzer et al proposed in [38] a distributed approach (namedVARS) where a number of vehicles move at high speedsVARS works with several areas (i) an event area that isthe physical region where an event occurs (ii) the decisionarea that defines the integrity of the involved messagesand (iii) the range which specifies how far these messagescan be distributed The reputation score of each nodeis computed by checking the integrity of the messagessent by the collaborators and considering also parametersrelated to trust and opinions given by the rest of nodesinvolved in the forwarding process As another sample


Link layer

(IEEE 80211p)

Virtualization layer

(VaNetLayer)

Network layer

(VNIBR)

Augmentation layer

(S-CMA)

Application layer

(NaaSSTaaSSEaaS)

Figure 1 Protocol stack of our approach

note the approach proposed by Li in [39] that handles acomprehensive announcement mechanism that enablesassessing the reliability of the messages by deciding toforward (or not) a message as per the reputation of thesender node These scores are computed staring from thenumber of reliable messages transmitted in the past and arekept in a centralized server that is connected to each nodevia WiFi access points located in strategic locations (eg gasstations)

3 Background on VaNetLayer and VNIBR

Most of the approaches mentioned in the previous sectionhave problems when it comes to handling the mobility of thevehicles due to the constant changes in the VANET topol-ogy This causes disruption in the communications packetlosses low throughput overhead of the routing protocolsetc In our case the problems stemmed from the mobilityare managed by a virtualization layer named VaNetLayerwhich is a cluster-based approach where the mobile nodescollaboratively create an infrastructure of static virtual nodes(VNs) to ease the routing problem and the maintenanceof Persistent State Information (PSI) in the area covered byVANET notwithstanding the mobility of the real physicalnodes (PNs) The protocol stack of our approach is depictedin Figure 1 where the link layer supports the protocol IEEE80211p that has been specifically developed for vehicularnetworks S-CMAmust provide transport-layer mechanismsto coordinate the devices that are willing to share theircapabilities for augmenting other terminals of the VANETby dealing with virtual nodes of the VaNetLayer (Section 31)This way S-CMA enables the execution of resource-intensiveapplications to improve the experience of the users withoutcaring about the mobility of the nodes included in theaugmentation sporadic cloud In fact themobility-awarenessis provisioned from the virtualization layer which ensures areliable data exchange thanks to the collaboration with therouting protocol VNIBR (Section 32)

31 VaNetLayer As depicted in Figure 2 the VaNetLayerdivides the geographical area of the VANET into regionsfollowing an intersection-based layout placing one VN ateach crossroad and covering the road segments in betweenwith equispaced VNs We denote these regions as crossroadregions and road segment regions respectively In each regionone or several PNs are chosen as leaders to take charge ofpacket reception buffering and forwarding in the communi-cation with other VNs In turn a subset of nonleaders workas backups to maintain replicas of PSI so that the VNs canbe fault-tolerant even when individual PNs fail or leave theregion as long as there remains at least one PN

Apart from backups that maintain PSI replicas VaNet-Layer has snapshot mechanisms to preserve the PSI whenthe regions are left without physical nodes (fallen VNs) Thesnapshot mechanismswork supporting the information of theVNs located in the intersections through the neighboringVNs of the intersection This mechanisms allow upper layersto continue to work even though the VNs of the intersectionsare down

The VNs are addressed by class E IP addresses (ldquoExper-imentalrdquo between 240000 and 255255255255) and theirsize is determined by the communications range of theunderlying link layer protocol to guarantee that a PN in anyposition in one region can communicate directly with anyother PN in a neighboring region

In [40] we have tested the refinements envisaged in ourVaNetLayer through an application for accessing web con-tents where the nodes download contents directly throughWiFi access points (APs) In our experiments we adopted therouting protocol Virtual Node Ad hoc On-demand DistanceVector (VNAODV) [21] which is a virtualization-drivenversion of the classical protocol AODV [41] that routes trafficthrough virtual nodes (instead of physical nodes like inAODV) The tandem VaNetLayer-VNAODV was comparedwith existing approaches to collaborative download of webcontents such as CarTorrent [23] and CodeTorrent [24]Briefly speaking the simulations results showed the followingbenefits of the VaNetLayer (see details in [40])

(i) Virtualization overhead is similar to the amount ofcontrol information handled in CarTorrent

(ii) The packet delivery ratios are high (comparable toCodeTorrent)

(iii) The approach scales well with the number of nodeswithin the VaNetLayer

There results confirm that the efforts establishing andmaintaining the virtual node infrastructure enable reliablecommunications where the VNs can be seen as stationarysources of computation and resources thus leading to greaterlevels of reliability for the upper layers (routing and sporadicCloud-based Mobile Augmentation)

32 VNIBR The interface between the VaNetLayer and thenetwork layer exposes the notion of regions the role (leaderor backup) played by a PN at each moment and functions tosendreceive messages and to getsetcheck the PSIThis wayit is possible to adapt existing routing algorithms to lean on


CN2 CN1

REGION 51

Sporadic Cloud 3

Sporadic Cloud 4

Sporadic Cloud 1

Sporadic Cloud 2

Road Segment Region

L1VNL2VN

L2VN

L2VN

L2VNL3VN

L3VN

L3VN

L3VNL3VN L3VN

L1VN

REGION 52REGION 53

INTERSECTION

REGION 50

INTERSECTION

REGION 54

Base Station3G4G

ServerInternet

CN3

AppN

AP

dic Cloud 4L3VN

L3VN

L1VN

Figure 2 Distribution of static virtual nodes and definition of L1VN L2VN and L3VN in our VaNetLayer

the VNs as stable routing entities or even as destinations forgeocasting In particular we have developed a protocol thatenables an efficient combination of topological and geograph-ical routing [42] which is called VNIBR (Intersection-BasedRouting on Virtual Nodes) In this protocol we identify threetypes of routing entities (named L1VNs L2VNs and L3VNs)that are depicted in Figure 2 (in colors blue brown and greenrespectively)

(i) Level 1 entities (L1VNs) are the VNs placed at theintersections This is where the routing decisions aremade using the procedure we will describe later inthis section Routing tables are transparently kept bythe VaNetLayer as PSI with entries indicating whichis the next road segment (identified by the L1VN atthe other end) that the packets must traverse in orderto reach the corresponding destination Note that theL1VNs that are located at a crossroad where there is afixedAP are permanently available virtual nodes withno downtimes thanks to the WiFi connectivity

(ii) Level 2 entities (L2VNs) are the VNs neighboringan intersection where an AP is not available TheseVNs start forwarding packets along a road segmentas mandated by the neighboring L1VN irrespectiveof whichever PN actually does the transmissionBesides L2VNs act also as backing entities tryingto relay packets onto other road segments duringdowntimes of the neighboring L1VNs

(iii) Finally as depicted in Figure 2 level 3 entities(L3VNs) are the VNs that are either (i) in interme-diate position of road segments or (ii) in a regionneighboring an intersection with an AP These nodessimply relay packets from one side to the other againirrespective of specific PNs

The L2VNs and L3VNs forward the packets from oneend of the road segments to the other without any otherprocessing than setting a delivery bit in the header to 1 ifthe destination PN is within the current region Due to thereactive nature communication routes in VNIBR are createdonly when a source PN needs to send a packet but it does notknow a route to the intended destination PN VNIBR handlesthe following messages

(i) M Hello This message is steadily exchanged betweenL1VNs which are one road segment away from oneanother to keep track of (i) the connectivity condi-tions they provide and (ii) the average number ofphysical nodes in its virtual region calculated usingan exponentially weighted moving average (EWMA)This way when an L1VN receives aM Hellomessageit assigns a QoS value to that link pondering theL1VN-to-L1VN transmission delay (again filtered byEWMA) the average number of PNs in the inter-mediate VNs and the amount of data traffic goingthrough that road segment (recall Figure 2) Thisinformation is kept and updated in the two L1VNs


that delimit the road segment by the periodic trans-mission of this type of messages If a road segmentdoes not provide connectivity to the other end asdetermined by the exchange ofM Hellomessages it isskippedTheprocess of exchange ofM Hellomessagesstarts when a timer called T Hello ends This timer isinitialized when the L1VN gets up for first time or itis restored after a fall

(ii) M RouteRequest This message is used by a PN thatneeds to send a data packet to the other node withinVANETThis PN sends thismessage to the L1VNs thatdelimit its road segment Each one of those L1VNsputs its ID as the first element of a L1VN list in theM RouteRequest message header and sends a copyto other L1VNs which are one road segment awayA broadcast ID is included in the periodically trans-mittedM RouteRequestmessage to prevent any L1VNfrom transmitting the same packet more than onceAnyway the flooding implies very little overheadbecause it involves only the leaders of the traversedVNs (unless some backup PNs have to assist as aresult of packet losses) A route is established (i) whenthe M RouteRequest message reaches an L1VN thatknows a valid route to the destination PN (ii) whenan L1VN receives the M RouteRequest message withthe delivery bit set to 1 meaning that the destinationPN is in the road segment just traversed or (iii) whenan L1VN receives the M RouteRequest message withthe delivery bit set to 0 but the destination PN is inthe current intersection

(iii) M RouteReply This message is used when a createdroute travels along the backpath allowing the L1VNson the way to set up the path to the destination PN intheir routing tablesOnce a route between source and destination PNshas been established the data packets are sent VN byVN via unicast transmissions between leader nodesWhen the VaNetLayer detects a failure (eg when itis not possible to resolve the MAC address of the nexthop node when the RTSCTS mechanism of IEEE80211 cannot reserve the shared channel or when noacknowledgment for a data packet can be receivedand retransmission attempts also failed) differentmechanisms to report the error or even to endeavora local repair can be exploited Further details (out ofthe scope of this paper) can be found in [43]

The performance of VNIBR protocol has been evaluatedby the simulation presented in [44] In particular in thiswork we compared our VNIBR protocol against AODV andVNAODV Briefly speaking the simulation results showedthe following

(i) Both versions of VNIBR provide better performancethan AODV and VNAODV in terms of overhead

(ii) Regarding packet delivery ratios reactiveVNIBRout-performs proactive VNIBR in scenarios with sparsevehicular traffic density where the low mobility of

vehicles leads to more stable and reliable communi-cations between L1VNs

(iii) Lastly the results for end-to-end delays suffered bythe packets that do reach the intended destinationsshow that the both the proactive and reactive versionsof VNIBR are faster than traditional routing proto-cols

4 S-CMA Sporadic Cloud-BasedMobile Augmentation

By virtue of its hybrid nature the S-CMA approach thatsupports our NaaS model exploits both the bandwidth lentby an ad hoc cluster of close on-move vehicles (proximatemobile sporadic cloud) and the availability of roadside unitsIn our proposal several AppNs can be augmented (to accessindividualpopular web contents) by a set of CNs that arein charge of downloading (from a remote server) and finallydelivering all the chunks of the requested content Specificallythe server computes the number of chunks per content thusacting as an additional augmentation source The chunks areprocessed as binary data and a hash code is used for integritychecking at the receiver side Besides the server may chooseto apply compression techniques (eg based on Lempel-Zivor Burrows-Wheeler algorithms) to reduce the size of thechunks to be downloadedmdashas in [45 46] the selection ofone technique or another can consider parameters such asspeed and compression efficiency quality of the communi-cation links (latency available bandwidth ) and type ofdata Anyhow the availability of the downloaded contentis confirmed from the server via PUSH notifications [47]which report on the URL the number of chunks and theirrespective identifiers (If the server cannot find the requestedcontent a PUSH notification ldquofile not foundrdquo is sent to theapplication layer of the AppN)

Our S-CMA mechanisms need to collect informationabout the amount of resources that eachCN iswilling to shareto augment the AppN To this aim we have envisaged twomain processes to meet the requirements stemmed from thehighly changing topology of VANETs which are periodicallyexecuted to maintain fresh information

(i) Resource report This process allows the CNs to sendinformation about the augmentation resources lentThese resources include both the available bandwidthand the possible chunks of popular contents thateach CN has previously downloaded (after beingrequested by other AppNs) and locally stored to beshared with other interested vehicles in the ad hocnetwork This way of advertising the availability ofpopular chunks in someCNs prevents redownloadingof these contents which brings significant benefitsin our NaaS model as evidenced in the simulationspresented in Section 5The information about the augmentation resourcesis reported by each CN through a M ResourceIn-foFromCN message which is sent to the leader of itscurrent region when (i) the CN enters a new region(except at the intersections) and (ii) the CN reports


3140

43

46

4142

43

91

92 93

32

33

31 61

71

12191

41

6 1

6 26 3

7 27 1

121122

Internet

APL3VN

L3VN

L3VN

L3VN

L3VN

L3VN

L3VN

L3VN

L3VN

51

52

53

71

72

73

75

76

77

55

56

57

31

32

33

74

70

54

34

30

38

50

58

35

36

37

L3VN

60

63

66

62

65

68

42

45

48

78

Base Station3G4G

Base Station3G4G

R-S 9

R-S 8

R-S 6

R-S 1

R-S 2

R-S 7

R-S 3

R-S 4

R-S 5

R-S 10

R-S 11

R-S 12

AppN

Lider

CNVehicle

R-S Road Segment

S-C Sporadic CloudS-C 1

S-C 3

S-C 4

S-C 2

S-C 5

L1VN

L1VN

L1VN

L1VN

L1VN

L1VN

L1VN

L1VN

Figure 3 Possible connectivity options of AppNs in the NaaS model supported by our S-CMAmechanisms

on the availability of new augmentation resourcesafter finishing a previous download for an AppN

(ii) Resource discovery This process consists ofexchanging M ResourceDiscovery messages betweenthe L1VNs that are one road segment away fromone another in order to collect the PSI about theavailable bandwidth in each VN deployed over theroad segment The process resource discovery startsonce the T Discovery timer has expired which isinitialized when the L1VN starts to work for first timeor is restored after a fall

Since the augmentation process is triggered when theAppN requests a particular (individualpopular) content thisnode needs to get information about the amount (and IDs) ofthe chunks to be downloaded by its CNs As this informationis available at the remote server we can identify two possibleconnectivity scenarios as per the location of the AppN

(i) TheAppN is located in a road segment that is delimitedby an intersection where an AP is located Since theAP covers the four road segment regions neighboringthe intersections in this scenario it is possible thatthe AppN cannot connect to the remote serverFor instance the AppN61 AppN71 and AppN41(located in road segments 6 7 and 4 in Figure 3respectively) need to form a sporadic cloud (by theprocedure we will describe later in this section) tofind CNs that retrieve information about the numberof chunks to be downloaded To this aim the AppN

communicates with the L1VN at the intersectionwhere the AP is located which maintains informa-tion about the availability of possible CNs and theirrespective augmentation resources After receivingthe requests from the CNs the server allocates amongthem the corresponding download tasks However itis also possible that the AppN is located in a road seg-ment region neighboring the intersection connectedvia the AP (eg AppN91 in Figure 3) In this case theAppN can retrieve from the server information aboutthe amount of chunks to download Next the AppNtriggers an augmentation request in order to form thesporadic cloud and ask each CN to download a givennumber of chunks (computed by the procedure wewill describe in Section 45)

(ii) The AppN is in a road segment whose (two) delimitingintersections do not have an AP As shown in Figure 3in absence of a nearby AP the AppN31 and AppN121require that an augmentation request is triggered (tothe closest L1VNs) to find CNs that get informationfrom the server which allocates again the downloadtasks among the collaborators without the participa-tion of the AppN

The augmentation procedure described next in thissection will be common to the above two connectivityscenarios In particular the deployment of the augmentationsporadicmobile cloud ismanaged by different types of eventsmessages exchanged between AppN and CNs (see Table 1)timers to control the download tasks performed by each


Table1Listof

messagesu

sedin

ourS

-CMAapproach

Usedby

Messages

Descriptio

nCN

MResourceInfoFrom

CNUsedto

send

ther

esou

rceinformationfro

maC

Nto

aVN

AppN

MSearchRequest

Allo

wsrequestingaC

Nto

perfo

rmcontentsearchwhenan

AppN

isno

tcon

nected

totheInternet

AppN

MResourceRequest

Usedto

requ

estaug

mentatio

nresources(band

width

inNaaS)

AppN

MCloudR

esourceInfo

Con

tainsinformationabou

tthe

availableb

andw

idth

forthe

augm

entatio

nprocess

AppN

MWith

outCollaborators

Indicatesthatthere

aren

oavailablea

ugmentatio

nresources

AppN

MInsufficie

ntResources

Indicatesthatthere

aren

oenou

ghaugm

entatio

nresources

AppN

MUn

availableA

ugmentatio

nService

Indicatestothea

pplicationlay

erthatthea

ugmentatio

nserviceisn

otavailable

AppN

MCloudR

elease

Indicatesthe

releaseo

fasporadicclo

ud

AppN

MSend

TaskToCN

Allo

wstosend

downloadtaskstoCN

sCN

MAc

ceptedTaskFrom

CNAllo

wsthe

CNstoconfi

rmthatthey

accept

todo

wnloadcontentsforthe

AppN

CN

MCo

mpleteTask

Allo

wsthe

CNstosend

chun

ksof

theA

ppN-requeste

dcontent

AppN

MCo

mpleteTaskA

CKAc

know

ledgem

entthatthe

chun

kshave

arriv

edcorrectly

from

theC

Nto

theA

ppN

CNM

IncompleteTask

Usedto

repo

rtthatad

ownloadtask

cann

otcontinue

AppN

MIncompleteTaskA

CKAc

know

ledgem

entthata

downloadtask

cann

otcontinue

inaC

N

AppN

MTaskInfo

Allowstosend

theinformationof

completedin

completed

ownloadtaskstothea

pplicationlayero

fthe

AppN


RESOURCEREQUEST

INITIAL

in IntersectionFlag==1out send(M_CloudRelease)

in recv[M_AugmentationRequest OR M_SearchRequest] AND (IntersectionFlag==0)

out send(M_ResourceRequest)start(T_ResourceRequest)expires=0

in [expire(T_ResourceRequest) AND (expires==2)] OR recv(M_WithoutCollaborators)

out send(M_UnavailableAugmentationService)

in [expire(T_ResourceRequest) AND (expireslt2)]out start(T_ResourceRequest)

expires++

Figure 4 Transition from INITIAL to RESOURCE REQUEST state

CN (Table 2) flags that provide information to the nodes(Table 3) and a set of possible states for each node

We start by describing the possible states and the condi-tions that cause their respective transitions

(i) INITIALThis is the state that all the nodes start from(ii) RESOURCE REQUEST This state indicates that the

AppN requests augmentation resources in order toincrease its downloading capabilities

(iii) TASK DISTRIBUTION The goal here is to allocatethe download tasks among the CNs by deciding howmany chunks of the web content will be downloadedby each one of them

(iv) COLLABORATION Once the augmentation taskshave been accepted by the CNs these nodes start tocollaboratively download chunks from the server

(v) TASK RECEPTION In this state the AppN waits forreceiving the downloaded chunks in order to deliverthem to the application layer

41 INITIAL 997888rarr RESOURCE REQUEST When an AppNis located in a road segment region (which is denoted inFigure 4 as IntersectionFlag=0) it must get information aboutthe amount of possible CNs available throughout that roadsegment To this aim the application layer of the AppNsends aM AugmentationRequestmessage to the S-CMA layer

(recall Figure 1) which causes our augmentationmechanismsto send a M ResourceRequest message to the L1VN of theclosest intersection Next the AppN changes from INITIALto RESOURCE REQUEST state and waits for responses fromthe L1VN during the time set in the T ResourceRequest timeras shown in Figure 4

After the reception of this request the node L1VN checksthe possibility of augmenting the AppN by exploiting thebandwidth borrowed from the CNs located in the sameregion segment as the AppN

(i) If there are no CNs L1VN reports the AppN via aMWithoutCollaborators message Next the AppNswitches again to INITIAL state and its applicationlayer is notified by a M UnavailableAugmentation-Servicemessage

(ii) Otherwise L1VN reports on the amount of avail-able CNs by a M CloudResourceInfo message If itdoes not arrive before the T ResourceRequest expiresthree times the AppN changes from RESOURCEREQUEST to INITIAL state Otherwise the AppNchanges to TASK DISTRIBUTION state starts aT TaskDistribution timer and begins to allocateamong the CNs the chunks to download

42 RESOURCE REQUEST 997888rarr TASK DISTRIBUTION 997888rarrTASK RECEPTION In this point of our augmentation pro-cess we can identify four different scenarios


Table2Listof

timersu

sedin

ourS

-CMAapproach

Usedby

Timers

Tune

timeto

AppN

TResourceRequest

Waitfor

inform

ationabou

tavailablea

ugmentatio

nresources

AppN

TTaskDistrib

ution

Allo

wallocatin

gdo

wnloadtasksa

mon

gtheC

Ns

AppN

TIntersectio

nReceptio

nWaitfor

thetasks

perfo

rmed

bytheC

Nsw

henan

AppN

entersan

intersectio

nAp

pNTReception

Waitfor

thec

hunk

sofcon

tent

downloadedby

theC

Ns

CNTCo

mpleteTaskA

CKWaitfor

ACKof

oneo

rmorec

ompleted

chun

ksthathave

been

sent

from

theC

NstotheA

ppN

CNTIncompleteTaskA

CKWaitfor

ACKof

adow

nloadtask

thatcann

otcontinue

AppN

TGu

ardT

ime

Waita

GuardTimefor

chun

kssent

bytheC

Nsa

fterreceiving

MCloudR

eleasefrom

theA

ppN


Table 3 List of flags used in our S-CMA approach

Used by Flags Flag=1 indicates thatAppNCN IntersectionFlag A node is at an intersectionAppN DistributionFlag The distribution process of the download tasks were successfully completedCN FinishFlag The download task performed by a CN ended successfullyCN AvailableResourcesFlag A CN has available augmentation resourcesCN AugmentationAgreeFlag A CN is willing to collaborate by lending its resources

RESOURCEREQUEST

TASK DISTRIBU-

TION

in recv(M_CloudResourceInfo)out start(T_TaskDistribution)

Distribution=0DistributionFlag=0InsufficientResources=0

in [expire(T_TaskDistribution) AND(Distribution==2)]


in [expire(T_TaskDistribution)AND (Distributionlt2)]

out start(T_TaskDistribution)Distribution++

Figure 5 Transition from RESOURCE REQUEST to TASK DISTRIBUTION

TASK DISTRIBU-

TION


in InsufficientResource==1out send(M_CloudRelease)

send(M_InsufficientResources)

INITIAL

Figure 6 Transition from RESOURCE REQUEST to DISTRIBUTION state

(i) First if the T TaskDistribution timer expires threetimes before concluding the chunk allocation theAppN returns to RESOURCE REQUEST state andsends again the M ResourceRequest message to theclosest L1VN as depicted in Figure 5 This actionis required due to the fact that the availability ofaugmentation resources changes as CNs move (egwhen the collaborators become inactive or leave asporadic cloud after entering a crossroad)

(ii) The second possibility happens when the AppN findsthat the CNsrsquo bandwidth (reported by L1VN) is not

enough for downloading the content Then as shownin Figure 6 a M CloudRelease message is broadcast(in order to remove the resource request in theL1VN) and the application layer is also notified viaa M InsufficientResources message Otherwise theprocess continues in the AppN

(iii) In this point it is also possible that theAppN enters anintersection region (recall Figure 2) before concludingthe chunk allocation among its CNs In this casethe augmentation request must be deleted from thesporadic cloud that the AppN has just left and


triggered again in the cloud corresponding to the newroad segment that this node will traverse after leavingthe intersection To this aim the AppN broadcastsa M CloudRelease message before returning to theINITIAL state as depicted in Figure 6 After receiv-ing this message the CNs can release their currentaugmentation resources which can be used to servenew augmentation requests from other AppNs in acompletely transparent way for the application layer

(iv) The last possibility is that the chunk allocation fin-ishes in time while the AppN is located in a roadsegment (which is denoted in Figure 7 as Distribu-tionFlag=1) In this situation the AppN sends thedownload tasks to the CNs of the sporadic cloud viaM SendTaskToCN messages including the URL thenumber of chunks and their respective identifiersNext the AppN changes to TASK RECEPTION stateand waits for CNs to confirm if they agree to down-load the corresponding pieces of the content

43 TASK RECEPTION 997888rarr INITIAL The download taskscan be completed not completed or even rejected by the CNsof the sporadic cloud We consider that a CN has completedits task when all the requested chunks have been successfullydownloaded and delivered to the AppN As depicted inFigure 8 as theAppN receives the notifications of the pendingtasks (including completed incomplete and not accepted)from the CNs it sends the corresponding information to theapplication layer (via a M TaskInfo message for each task)The application layer receives the chunks decompresses themif necessary and according to their chunk identifier restoresthe original information

(a) On the one hand if the application layer requiresmore CNs to finish the incomplete and rejecteddownloads a new augmentation process can betriggered following the guidelines described alongthis section Note that this seamless handover iscompletely transparent for the application layer sothat the mobile applications of the users can continueworking without noticing the transition betweendifferent augmentation clouds and without sufferingany disruption (as long as there exist CNs willing tolend augmentation resources)

(b) On the other hand if the CNs have completedall their download tasks the AppN changes fromTASK RECEPTION to INITIAL state However ifsome chunks still have not been delivered by theCNs before the (i) T Reception timer expires twotimes or (ii) the AppN enters in an intersectionthe AppN broadcasts aM CloudReleasemessage overthe sporadic cloud in order that the CNs cancelimmediately their in-progress download tasks Inboth cases a T GuardTime is set to wait for themissing chunks before sending the M CloudReleasemessage As shown in Figure 8 when this timerexpires the AppN returns to INITIAL state and theaugmentation process ends

44 INITIAL 997888rarr COLLABORATION The last state of ourapproach is associated with the CNs involved in the collab-orative downloading process In particular as presented inFigure 9 aCNchanges from INITIAL toCOLLABORATIONstate after the reception of the M SendTaskToCN messagefrom the AppN through leader of its current region Thenthe CN confirms the acceptance of the download task bysending to the AppN a M AcceptedTaskFromCN messageAs the CNs get the requested chunks they send them to theAppN through aM CompleteTaskmessage

According to what we explained in previous sections theCNs must submit the intermediate results of the downloadtasks that had not been completed yet when they (i) hearthe M CloudRelease message (ii) enter an intersection or(iii) decide to stop being collaborators To this aim theCNs send theM IncompleteTaskmessage to the AppN Sincethis message carries very relevant information (identifyingmissing pieces of the contents) the CN waits until theAppN acknowledges the reception We have defined theM CompleteTaskACK and M IncompleteTaskACK messagesand the T CompleteTaskACK and T IncompleteTaskACKtimers for this purpose

Having delivered the pending tasks the CNs releasethe involved resources and report to their VN on thenew availability of their augmentation capabilities (via aM ResourceInfoFromCN message) This information is alsoupdated in the L1VNs located in the intersections thanks tothe periodic sending of the M ResourceDiscovery messages(recall the processes of resource report and resource discoverydescribed in Section 4) Lastly as shown in Figure 9 theCN returns to INITIAL state and waits to lend again itsbandwidth when requested by an AppN

The overall statemachine that supports our augmentationmechanisms is shown in Figure 10 compiling all the transi-tion among states described throughout this section

45 How to Allocate Chunks to Collaborator Nodes Accord-ing to the two connectivity scenarios detailed at the beginningof Section 4 allocating the chunks that each CN mustdownload is a task that can be performed by either the AppNor the remote server itself In our augmentationmechanismsthis procedure considers two parameters that are reportedfrom the CNs

(i) The first parameter is the average time a CN willstay within the same sporadic cloud as the AppNwhich is relevant because that collaborator cannotcontinue lending its bandwidth after leaving the roadsegment (triggering then a seamless handover forthe applications) This parameter will be denoted as119877119878119860119879119862119873119894 (Road Segment Average Time) for the i-thcollaborator

(ii) The second parameter is the bandwidth lent by eachCN to the collaborative download process (denotedas 119861119882

119862119873119894)

Obviously the 119877119878119860119879119862119873119894

value depends on the aver-age speed of 119862119873

119894within the corresponding segment road

(denoted as 119860V119878119901119890119890119889119862119873119894

in (1)) and on its location with


TASK DISTRIBU-

TION

in DistributionFlag==1 out send(M_SendTaskToCN)

start(T_Reception)CompleteTasksCounter=0IncompleteTasksCounter=0ExpireReception=0

TASKRECEPTION

Figure 7 Transition from TASK DISTRIBUTION to TASK RECEPTION state

INITIALin [expire(T_Reception) AND (CompleteTasksCounter==Ntasks)]

OR [expire(T_Reception) AND (CompleteTasksCounter+IncompleteTasksCounter+NoAcceptedTasksCounter==Ntasks)]

OR[expire(T_Reception) AND (ExpireReception==2)]


start(T_IntersectionReception)

in recv(M_AcceptedTaskFromCN) out update(TasksAck)

in [expire(T_Reception) AND (ExpireReception==0)]

out start(T_Reception)ExpireReception++


out start(T_Reception)send(M_CloudRelease)ExpireReception++

in recv(M_CompleteTask)out send(M_CompleteTaskACK)

send(M_TaskInfo)CompleteTasksCounter++

in recv(M_IncompleteTask)out send(M_IncompleteTaskACK)

send(M_TaskInfo)IncompleteTasksCounter++

TASKRECEPTION

in expire (T_IntersectionReception)

Figure 8 Transition from TASK RECEPTION to INITIAL state

respect to the intersection (119875119900119904119894119905119894119900119899119862119873119894

) The position iscomputed resorting to a Haversine formula to computethe distance between 119862119873

119894rsquos geographical location (ie GPS

coordinates) and the reference points delimitating the nextintersection region (see Figure 2)

119877119878119860119879119862119873119894=119875119900119904119894119905119894119900119899

119862119873119894

119860119881119878119901119890119890119889119862119873119894

(1)

Each CN periodically obtains new samples of the valuesneeded by (1) and sends them to the corresponding VNthrough a M ResourceInfoFromCN message According towhat we mentioned in the process resource discovery thisinformation is finally included in the M ResourceDiscoverymessage used for (i) gathering information about the band-width (and the amount of chunks of popular contents)available in the CNs that are located along the segmentroad and (ii) keeping this information updated in the L1VNsof each intersection Starting from the 119877119878119860119879 and 119861119882

119862119873119894

values of each collaborator and the chunk size (defined bythe server through the compression process established) the

AppN computes via (2) the number of chunks that 119862119873119894will

download (denoted as 119888ℎ119906119899119896119904119862119873119894

)

119888ℎ119906119899119896119904119862119873119894=119861119882119862119873119894sdot 119877119878119860119879

119862119873119894

119888ℎ119906119899119896 119904119894119911119890(2)

As per (2) the longest download tasks are carried outby the CNs (i) with a high bandwidth and (ii) that arelocated at the beginning of a road segment since thesecollaborators (according to their direction) take longer toreach an intersection On the contrary the CNs that are nearthe intersections take charge of shorter downloads becausethey remain for less time within the augmentation sporadiccloud formed in that road segment (recall Figure 3)

The outputs from (1) and (2) are used only locally and notaggregated in any way Since the periodical samples may betaken at any point of a road segment or intersection withvehicle speeds conditioned by a number of circumstances theaggregates would be essentially random

46 How to Incentivize the Collaboration among Nodes Inour proposal the collaboration among the nodes involved in


INITIAL

in [recv(M_CompleteTaskACK)ORrecv(M_IncompleteTaskACK)]

COLLA-BORATION

in FinishFlag==1out send(M_CompleteTask)

start(T_CompleteTaskACK)

in expire(T_CompleteTaskACK)out send(M_CompleteTask)

in expire(T_IncompleteTaskACK)out send(M_IncompleteTask)

out send(M_ResourceInfoFromCN)FinishFlag=0

in [(IntersectionFlag==1) OR recv(M_CloudRelease)OR (AugmentationAgree==NO)]

out send(M_IncompleteTask)start(T_IncompleteTaskACK)

in [recv(M_SendTaskToCN) AND (AugmentationAgreeFlag==1) AND (IntersectionFlag==0) AND (AvailableResourceFlag==1)]

out send(M_AcceptedTaskFromCN)FinishFlag=0

Figure 9 Transition from INITIAL to COLLABORATION state

RESOURCEREQUEST

TASKDISTRIBU-

TION

INITIAL



in [expire(T_TaskDistribution)AND (Distribution==2)]






out start(T_Reception)CompleteTasksCounter=0IncompleteTasksCounter=0ExpireReception=0

in recv(M_SendTaskFromServer)

in DistributionFlag==1out send(M_SendTaskToCN)

in [expire(T_ResourceRequest) AND(expires==2)] OR

recv(M_WithoutCollaborators)out send(M_UnavailableAugmentationService)

in [expire(T_ResourceRequest)AND (expireslt2)]

out start(T_ResourceRequest)expires++

in [expire(T_Reception) AND(CompleteTasksCounter==Ntasks)]

OR[expire(T_Reception) AND

(CompleteTasksCounter+IncompleteTasksCounter+NoAcceptedTasksCounter==Ntasks)]

OR[expire(T_GuardTime) AND(ExpireReception==2)]


start(T_GuarTime)

in recv(M_AcceptedTaskFromCN)out update(TasksAck)

in [expire(T_Reception)AND(ExpireReception==0)]



out start(T_GuardTime)send(M_CloudRelease)ExpireReception++





TASKRECEPTION

in recv(M_CompleteTaskACK)ORrecv(M_IncompleteTaskACK)

COLLA-BORATION






in [IntersectionFlag==1OR recv(M_CloudRelease)OR (AugmentationAgree==NO)]


in [recv(M_AugmentationRequest) ORrecv(M_SearchRequest)] AND

(IntersectionFlag==0)out send(M_ResourceRequest)

start(T_ResourceRequest)expires=0




in [recv(M_SendTaskToCN) AND (AugmentationAgreeFlag==1)AND (IntersectionFlag==0)AND (AvailableResourceFlag==1)]


Figure 10 State machine of our S-CMA approach that supports the proposed NaaS modelThis figure is reproduced fromOrdonez-MoralesE F et al [20] (under the Creative Commons Attribution Licensepublic domain)


the VANET is crucial to support the virtualization mecha-nisms on which both the routing protocol and our S-CMAapproach work Specifically the nodes need to communicateto each other forward packets receive messages downloadinformation etc For that reason in this section we describethe mechanism we have envisaged to encourage the nodesto collaborate with each other at the different levels involvedin the proposal virtualization routing and sporadic Cloud-based Mobile Augmentation (recall Figure 1)

According to the review presented in Section 22 wehave discarded a credit-based solution and opted for areputation-based collaboration approach The credit-basedmechanisms are hard to implement because it is not easy todecide when the credit must be paid to the CNs for theiraugmentation services If the CN receives the credit beforethe augmentation it would be possible that this node rejectsfinally to lend its resources if the payment ismade after somemalicious CNs could forward any number of packets notnecessary referring to the AppN-requested content [37]

Specifically in our collaboration mechanism all the(physical) nodes involved in the communications have repu-tation values which are increased as the nodes collaborate atthe different levels of the protocol stack depicted in Figure 1(Note that our approach starts to work with reputation valuesthat are estimated by averaging historical values becauseinitially the nodes still have not collaborated (or these valueshave not reached the server yet)) In particular

(i) the AppNs and CNs have a reputation value as per theamount of data sent which are properly received bythe destination nodes at virtualization routing andaugmentation levels

(ii) besides the CNs have a second reputation valueas per the amount of individualpopular contentsthat are downloaded from the remote server whenaugmenting the AppNs this second value dependson the size of data downloaded from the server andnot on the data that the AppNs do receive (because itwould not be fair to limit the reputation of the CNs tothe network conditions)

Following the guidelines of the existing approaches weadopt as manager entity the remote server where the contentsare available The nodes must register in this server whichprovides a security layer to ensure that (i) all the nodeshave worked properly in the forwarding and downloadingof contents and (ii) their reputation values respectivelyhave been correspondingly updated Specifically each nodeinvolved in our communications maintains a table including(i) theMAC addresses of the destination nodes to which datahas been forwarded and (ii) their respective reputation valuesThis information is sent to the server when a connection tothe Internet (either via AP or via own 3G4G connection)is available After receiving all the contributions the serverproceeds as follows

(i) First the server verifies the forwarding and down-loading tasks performed by each type of node (AppNor CN) by matching both the amount of data thathave been sent by the origin nodes and received by the

destination nodes and the amount of data that havebeen downloaded (as appropriate)

(ii) Second the server updates the corresponding reputa-tion scores for AppNs and CNs and sends them to thenodes via PUSH notifications

The reputation values of theCNs andAppNs take a crucialrole Specifically we use them to prioritize the augmentationrequests performed by several AppNs so that if many ofthese nodes need to be augmented and there are enoughaugmentation resources the CNsrsquo bandwidth is lent first tothe AppNs with the highest reputation values To this aimthe information related to the reputation of each node is alsocommunicated to the L1VNs (located at the intersections)and maintained as PSI after the resource discovery processdescribed in Section 4

The reputation scores of the CNs are used for dimension-ing rightly the augmentation (sporadic) cloud because anexcessive ratio of CNs can affect negatively the performanceof the ad hoc network (due to overhead collisions and packetlosses as we will detail in Section 5) This way in case of asurplus of collaborators our S-CMA approach can select CNsby considering not only the average time they will stay in aroad segment and their available bandwidth (as shown in (2))but also their respective reputation scores Besides each nodecan work as CN or as AppN or even take both roles For thatreason the reputation values of a CN can be exploited whenthis node needs to be augmented (turning into a AppN)According to what commented above in this scenario thehigher the reputation score this node has reached asCN is themost preferential its augmentation request will be as AppN

Lastly the CNs can be also incentivized by consid-ering our S-CMA approach as the only opportunity toenjoy context-aware tailor-made applications that will not beavailable outside of our opportunistically deployed sporadicnetwork (wheremembership is conditioned to the acceptanceof sharing some own resources in exchange for using otherexternal ones if necessary)

5 Experimental Evaluation

In order to validate our S-CMA approach we propose ascenario of simulation that considers the center of the city ofCuenca in Ecuador (previously captured in OpenStreetMap)covering an area of 1375x1375meters with 7x7 two-way streetsof the city center Five APs are located within the area ofsimulation as depicted in Figure 11 which have a coveragearea of 50 meters that guarantees connectivity to the remoteserver where the AppNs-requested contents are available

The vehicles are equipped with on-board units includingGPS 80211p Wi-Fi and 3G4G connections To simulatethe communications we use (i) ns-3 simulator with IEEE80211p PHYMAC (adopting the shadowing radio propaga-tion model [48]) and all the protocols on top and (ii) SUMOto get realisticmobility traces for 300 vehicles on the streets ofthe simulation area Besides the following settings have beenconsidered in our experiments


AP AP

AP

AP AP

Figure 11 Distribution of the 5 APs within our simulation scenario

(1) The CNs can handle several augmentation requests(by lending resources to multiple AppNs simultane-ously) by resorting first to near APs and in case ofunavailability of them to their own 3G4G connec-tions

(2) The AppNs can just download contents from theInternet through either near APs or collaboratornodes willing to lend their 3G4G connections

(3) The AppNs request 5 MB of individual content and 5MB of popular contents

(4) The servers do not use compression(5) 10 of total nodes are AppNs that request aug-

mentation processes to download popularindividualcontents

(6) We consider diverse proportions of collaboratornodes within the VANET (specifically 255075of CNs) with the aim of representing pessimistmiddleoptimistic collaboration environments

(7) The timers used in our augmentation approach (seeTable 2) have been settled to 1ms

(8) Lastly we measure the performance of our S-CMAapproach in terms of average number of downloadsaverage download time and S-CMA overhead againstthe percentage of CNs within the VANET (25 50and 75 of CNs) comparing the two collaborativedownload models described in the paper (ICD orindividual content download vs PCD or popularcontent download)

We start analyzing the average amount of downloadscarried out by the CNs in the two experimented downloadmodels

As shown in Figure 12 the average number of contentsdownloaded by the CNs is greater in PCD than in ICDThe reason behind these figures is related to the nature of

ICD

PCD

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

Figure 12 Average number of downloads performed in ICD andPCD against different ratios of CNs within the VANET

the AppN-requested contents while the individual contentshandled in ICD must be always retrieved from the remoteserver in PCD some chunks of popular contents are alreadystored in the CNs and therefore these collaborators candeliver very fast these pieces to the AppN thus being readyagain for performing new downloads This behavior leads toan increase of average number of downloads as the numberof available CNs gets higher However this trend is reversedfor proportions greater than 50 of CNs since having moreCNs in the road segment makes it easier to form sporadicclouds during the augmentation process A high numberof augmentation requests cause greater occupation of thetransmission medium resulting in collisions and packetlosses that degrade the performance of the VANET andreduce the average total number of downloads made by theCNs for their respective AppNs

The evolution of the average number of augmentationrequests and the amount of formed sporadic clouds inboth download models are depicted in Figures 13 and 14respectively

As explained in Section 4 after forming the sporadiccloud in the road segment where the AppN is located thisnode waits until the CNs deliver the requested contentDuring this period of time the AppN cannot trigger newaugmentation requests unless its CNs deliver the requestedcontent before the corresponding timer expires or the AppNenters an intersection In this case theCNs deliver the chunks


ICD

PCD

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

Figure 13 Average number of augmentation requests performed byAppNs in ICD and PCD against different ratios of CNs within theVANET

of the content available until that moment Next a newprocess of augmentation is triggered in the road segmentfollowed by the AppN after leaving the intersection (in atotally seamless handover for the applications) with the goalof getting the missing pieces of the content

As shown in Figure 13 the number of augmentationrequests dispatched on average is lower in ICD than in PCDAs mentioned before in ICD the CNs must download allthe chunks (for being content of interest just for a particularuser in the VANET) and therefore dispatching each requesttakes longer Instead in PCD as many popular chunks mayalready be available in the CNs the collaborators can deliverdirectly their contents to the AppN thus remaining free toattend new augmentation requests In addition since thereare fewer augmentation requests fewer sporadic clouds ineach road segment (see Figure 14) are also formed in ICD thanin PCD where both parameters increase proportionally withthe number of CNs available As shown in Figures 13 and 14both values decrease for greater ratios of CNs due to a higheroccupation of the transmission medium and the consequentfrequent collisions and packet loss aforementioned

The explanations given above justify also the resultsachieved for average download times and S-CMA overhead

(i) As depicted in Figure 15 in bothmodels the downloadtime of each 5MB content gets lower as the number

ICD

PCD

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med

Figure 14 Average number of augmentation sporadic cloudsformed in ICD and PCD against different ratios of CNs within theVANET

of CNs willing to lend their bandwidths increasesreaching the minimum value with a ratio of 50 ofCNs (when this parameters remain almost stable)The benefits of PCD due to the availability of manypopular chunks in the CNs are noticeable in oursimulations as well as the degradation suffered inthe download time due to a transmission mediumcongested for a higher number of augmentationrequests and sporadic clouds formed

(ii) As shown in Figure 16 the measured S-CMA over-head is greater in PCD than in ICD due to the factthat the amount of control information that must beexchanged among CNs and AppNs (to orchestratethe augmentation process) is also higher The figuresdepicted in both charts also confirm the congestionof the VANET for a proportion of CNs greater thanabout 60 In particular when the VANET perfor-mance is degraded the controlmessages coming fromthe S-CMA layer are lostmore frequently andmust besent again which increases the networking overhead

To conclude our experimental design we depict in Fig-ure 17 the average download speeds achieved in PCD andICD for the AppNs involved in our simulations whose valueshave been compared considering the typicalreal downloadrates for 35G (4 Mbps) 4G (15 Mbps) and 80211p (6 Mbps)


ICD

PCD

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]

Figure 15 Average download time in ICDandPCDagainst differentratios of CNs within the VANET

which are the connections that our CNs can use duringthe collaborative download of web contents These valueshave been taken from httpkenstechtipscomindexphpdownload-speeds-2g-3g-and-4g-actual-meaning In particu-lar the typical download rate for 80211p networks is about 11Mbps We are considering a real value of 6 Mbps as referencefor the WiFi APs located at the intersections assuming thatthe presence of buildings degrades network performanceAs expected PCD outperforms ICD for the reasons giventhroughout this section achieving download speeds that are(i) much better than the rates of 35G and WiFi connectionsvia 80211p (1333 Mbps vs 4 Mbps and 6 Mbps respectively)and (ii) slightly lower than the rates of 4G connections (1333Mbps vs 15 Mbps) This last point is due to the fact that thecongestions interferences and the movement of CNs duringthe augmentation process reduce the real download speedthus shaping a nonideal scenariowhere the rate of 15Mbps of a4G connection is not feasiblerealistic Anyway the achievedresults are certainly promising for a CMA approach likeours where unlike existing related works the execution ofmobile applications does not suffer disruption as AppN andCNs move away thus switching seamlessly between differentaugmentation clouds

6 Conclusions and Further Work

In this paper we have presented an approach to CMA thatenables execution of intensive-resource applications in a

ICD

PCD

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs

Figure 16Average networking overheadmeasured in ICDandPCDagainst different ratios of CNs within the VANET

vehicle (application node) within a VANET by deployinga NaaS model that borrows augmentation resources Theaugmentation resources gain advantages from two sourcesThe first is constituted by the sporadic clouds of close(collaborator nodes) vehicles that move along a road segmentduring a period of time while the second source is theroadside-fixed unit Both sources of augmentation maintainconnections to a central server that manages the contentdesired by the application node The service model enablesindividualized download of web contents (ICD) and access topopular contents that are discovered within the VANET anddelivered to the interested vehicles (PCD) Unlike existingCMA solutions our S-CMA approach mitigates to a largeextent the problems related to latency excessive bandwidthconsumption and constraints related to relative locationsbetween the vehicles that require augmentation and the onesthat lend resources Asmajor novelty our approach is the firstproposal that explores synergies between CMA solutions andvirtualization mechanisms by handling stationary virtualnodes instead of on-move vehicles The notion of virtualnode has been also exploited when routing traffic by arobust and efficient protocol working in tandem with thevirtualization layer Our virtualization mechanisms managethe mobility of the cluster of collaborator nodes an issuethat has not been yet completely resolved in the literature


ICD vs PCD

ICDPCD

0

2

4

6

8

10

12

14

16

Aver

age d

ownl

oad

spee

d [M

bps]

30 40 50 6 0 70 80 20 CNs

Figure 17 Average download speeds achieved for the augmentedAppNs (in ICD and PCD) against different ratios of CNs within theVANET

where the most sophisticated solutions interrupt the aug-mentation service once AppN and CNs have moved awayInstead our virtualization layer enables stable and reliablecommunication environments even in scenarios of highmobility where the (application and collaborator) vehiclesmove freely and where disruptions in the augmentationservice are automatically restored (from the S-CMA layer)when AppN andor CNs leave the current sporadic cloud asthey separate

We have evaluated the performance of our approachachieving very promising results in terms of number ofdownloads and average download speed (forAppNs) averagedownload time (of CNs) and networking overhead Theseresults showed that PCD outperformed ICD where theAppNs have accessed a greater amount of web contents inless time at the cost of slightly increasing the overhead inthe VANET This reveals the benefits of the gossip mech-anisms adopted in our approach in order to discover theavailability of popular chunks in some CNs and deliver themsoon to the corresponding AppNs Besides our simulationshave also allowed us to detect that the number of CNswithin the augmentation sporadic clouds must be properlydimensioned in order to prevent excessively occupied trans-mission mediums high overhead frequent collisions andconsequent packet losses In this dimensioning procedureour approach exploits a reputation-based mechanism thatenables not only identifying the best CNs (in case of surplus ofcollaborators) but also prioritizing the augmentation requestsmade by theAppNs (when there are no enough augmentationresources)

As further work we plan to compare our approach withexisting CMA solutions in order to quantify the improve-ments of our refinements at virtualizationroutingmobileaugmentation-level with regard to solutions that sufferrestrictions related to the mobility of the augmentationcluster Besides we are working on the deployment of newldquoXrdquoaaSmodels (specifically SEnsing and SToring as a Service

models) on the foundations of our S-CMA paradigm withthe goal of enriching themobile usersrsquo experience in vehicularenvironments

Data Availability

The simulation data used to support the findings of this studyare available from the corresponding author upon request

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

This work has been supported by the European RegionalDevelopment Fund (ERDF) and the Galician Regional Gov-ernment under agreement for funding the Atlantic ResearchCenter for Information and Communication Technologies(AtlantTIC) by the Program for theConsolidation and Struc-turing of Competitive Research Groups within the GalicianRampDampI System by the Ministerio de Educacion y Ciencia(Gobierno de Espana) research project TIN2017-87604-RThe authors are also thankful to FREEPIK for providing uswith some of the graphics used in this document

References

[1] M Gerla C Wu G Pau and X Zhu ldquoContent distributionin VANETsrdquo Vehicular Communications vol 1 no 1 pp 3ndash122014

[2] S Jia Z Liu K Zhu L Zhang Z M Fadlullah and NKato ldquoBus-Ads Bus-based priced advertising in VANETs usingcoalition formation gamerdquo in Proceedings of the IEEE Interna-tional Conference on Communications ICC 2015 pp 3628ndash3633London UK June 2015

[3] G S Khekare ldquoDesign of emergency system for intelligenttraffic system using VANETrdquo in Proceedings of the 2014 Interna-tional Conference on Information Communication and Embed-ded Systems ICICES 2014 Chennai India February 2014

[4] B Liu D Jia J Wang K Lu and L Wu ldquoCloud-assisted safetymessage dissemination in VANET-cellular heterogeneous wire-less networkrdquo IEEE Systems Journal vol 11 no 1 pp 128ndash1392017

[5] H S Hassanein S Abdelhamid and K Elgazzar ldquoA frameworkfor vehicular cloud computingrdquo in Proceedings of the Interna-tional Conference on Connected Vehicles and Expo ICCVE 2015pp 238-239 Shenzhen China October 2015

[6] S Abolfazli Z Sanaei E Ahmed A Gani and R BuyyaldquoCloud-based augmentation for mobile devices motivationtaxonomies and open challengesrdquo IEEE Communications Sur-veys amp Tutorials vol 16 no 1 pp 337ndash368 2014

[7] M Gerla ldquoVehicular cloud computingrdquo in Proceedings of the11th AnnualMediterranean AdHocNetworkingWorkshop (Med-Hoc-Net 2012) pp 152ndash155 Ayia Napa Cyprus June 2012

[8] R Yu Y Zhang S Gjessing W Xia and K Yang ldquoTowardCloud-based vehicular networks with efficient resource man-agementrdquo IEEE Network vol 27 no 5 pp 48ndash55 2013


[9] R Karim ldquoVANET superior system for content distribution invehicular network applicationsrdquo Tech Rep Rutgers UniversityDepartment of Computer Science 2008

[10] S Hussain Z Hamid and N S Khattak ldquoMobility manage-ment challenges and issues in 4G heterogeneous networksrdquo inProceedings of the First International Conference on IntegratedInternet Ad-hoc and Sensor Networks (InterSense) p 14 NiceFrance May 2006

[11] C Wang Y Li D Jin and S Chen ldquoOn the serviceability ofmobile vehicular cloudlets in a large-scale urban environmentrdquoIEEE Transactions on Intelligent Transportation Systems vol 17no 10 pp 2960ndash2970 2016

[12] S Olariu I Khalil and M Abuelela ldquoTaking VANET tothe cloudsrdquo International Journal of Pervasive Computing andCommunications vol 7 no 1 pp 7ndash21 2011

[13] E Lee E-K Lee M Gerla and S Y Oh ldquoVehicular cloudnetworking architecture and design principlesrdquo IEEE Commu-nications Magazine vol 52 no 2 pp 148ndash155 2014

[14] S Abolfazli Z Sanaei M Shiraz and A Gani ldquoMOMCCmarket-oriented architecture formobile cloud computing basedon service oriented architecturerdquo in Proceedings of the 2012 1stIEEE International Conference on Communications in ChinaWorkshops ICCC 2012 pp 8ndash13 Beijing China August 2012

[15] K Xu K-C Wang R Amin J Martin and R Izard ldquoAfast cloud-based network selection scheme using coalitionformation games in vehicular networksrdquo IEEE Transactions onVehicular Technology vol 64 no 11 pp 5327ndash5339 2015

[16] M H Firooz and S Roy ldquoCollaborative downloading inVANET using network codingrdquo in Proceedings of the IEEEInternational Conference on Communications (ICC rsquo12) pp4584ndash4588 Ottawa ON Canada June 2012

[17] N Kumar J J Rodrigues and N Chilamkurti ldquoBayesiancoalition game as-A-service for content distribution in internetof vehiclesrdquo IEEE Internet ofThings Journal vol 1 no 6 pp 544ndash555 2014

[18] H R Arkian R E Atani A Diyanat and A Pourkhalili ldquoAcluster-based vehicular cloud architecture with learning-basedresource managementrdquo The Journal of Supercomputing vol 71no 4 pp 1401ndash1426 2015

[19] E F Ordonez-Morales Y Blanco-Fernandez J F Bravo-torresM Lopez-Nores V Saians-Vazquez and J J Pazos-arias ldquoS-CMA sporadic cloud-based mobile augmentation supportedby an ad-hoc cluster of moving handheld devices and avirtualization layerrdquo inProceedings of the 2015 Fifth InternationalConference on Innovative Computing Technology (INTECH) pp152ndash157 Vigo Spain May 2015

[20] E F Ordonez-Morales J F Bravo-Torres Y Blanco-FernandezM Lopez-Nores V Saians-Vazquez and J J Arias ldquoExploitingvirtualization and sporadic clouds for collaborative down-loading in vanets a new networking as a service modelrdquoin Proceedings of the 2016 IEEE 4th International Conferenceon Future Internet of Things and Cloud (FiCloud) pp 50ndash57Vienna Austria August 2016

[21] J F Bravo-Torres M Lopez-Nores Y Blanco-Fernandez J JPazos-Arias M Ramos-Cabrer and A Gil-Solla ldquoOptimizingreactive routing over virtual nodes in VANETsrdquo IEEE Trans-actions on Vehicular Technology vol 65 no 4 pp 2274ndash22942016

[22] S Ahmed and S S Kanhere ldquoVANETCODE network cod-ing to enhance cooperative downloading in vehicular ad-hoc networksrdquo in Proceedings of the International Wireless

Communications and Mobile Computing Conference (IWCMCrsquo06) pp 527ndash532 ACM Vancouver BC Canada July 2006

[23] K C Lee S-H Lee R Cheung U Lee and M Gerla ldquoFirstexperience with CarTorrent in a real vehicular ad hoc networktestbedrdquo in Proceedings of the Mobile Networking for VehicularEnvironments (MOVE rsquo07) pp 109ndash114 Anchorage AK USAMay 2007

[24] U Lee J-S Park J Yeh G Pau and M Gerla ldquoCode torrentcontent distribution using network coding in VANETrdquo inProceedings of the 1st International Workshop on Decentral-ized Resource Sharing in Mobile Computing and Networking(MobiShare rsquo06) pp 1ndash5 ACM Los Angeles CA USA Septem-ber 2006

[25] B B Chen and M C Chan ldquoMobTorrent a framework formobile internet access from vehiclesrdquo in Proceedings of the28th Conference on Computer Communications (INFOCOM)pp 1404ndash1412 Rio De Janeiro Brazil April 2009

[26] N Liu M Liu G Chen and J Cao ldquoThe sharing at road-side vehicular content distribution using parked vehiclesrdquo inProceedings of the 31st Annual IEEE International Conferenceon Computer Communications (INFOCOM) pp 2641ndash2645Orlando FL USA March 2012

[27] S Arif S Olariu J Wang G Yan W Yang and I KhalilldquoDatacenter at the airport Reasoning about time-dependentparking lot occupancyrdquo IEEE Transactions on Parallel andDistributed Systems vol 23 no 11 pp 2067ndash2080 2012

[28] M Eltoweissy S Olariu and M Younis ldquoTowards autonomousvehicular cloudsrdquo in Proceedings of the AdHocNetworks vol 49pp 1ndash16 Springer 2010

[29] S Olariu T Hristov and G Yan ldquoThe next paradigm shiftfrom vehicular networks to vehicular cloudsrdquo inMobile Ad HocNetworking The Cutting Edge Directions pp 645ndash700 Wileyand Sons 2012

[30] W Huang and L Wang ldquoECDS Efficient collaborative down-loading scheme for popular content distribution in urbanvehicular networksrdquo Computer Networks vol 101 pp 90ndash1032016

[31] A Nandan S Das G Pau M Gerla and M Y Sanadidi ldquoCo-operative downloading in vehicular ad-hoc wireless networksrdquoin Proceedings of the 2nd Annual International Conference onWireless On-Demand Network Systems and Services (WONSrsquo05) pp 32ndash41 January 2005

[32] C Huang C Yang and H Lin ldquoA bandwidth aggregationscheme for member-based cooperative networking over thehybrid VANETrdquo in Proceedings of the 2011 IEEE 17th Interna-tional Conference on Parallel and Distributed Systems (ICPADS)pp 436ndash443 Tainan Taiwan December 2011

[33] T Wang L Song and Z Han ldquoCollaborative data dissemina-tion in cognitive VANETs with sensing-throughput tradeoffrdquoin Proceedings of the 2012 1st IEEE International Conferenceon Communications in China ICCC 2012 pp 41ndash45 BeijingChina August 2012

[34] T Chen L Zhu F Wu and S Zhong ldquoStimulating cooperationin vehicular ad hoc networks a coalitional game theoreticapproachrdquo IEEE Transactions on Vehicular Technology vol 60no 2 pp 566ndash579 2011

[35] S-B Lee J-S Park M Gerla and S Lu ldquoSecure incentivesfor commercial ad dissemination in vehicular networksrdquo IEEETransactions on Vehicular Technology vol 61 no 6 pp 2715ndash2728 2012


[36] G Ananthanarayanan V N Padmanabhan C A Thekkathand L Ravindranath ldquoCollaborative downloading for multi-homed wireless devicesrdquo in Proceedings of the 8th IEEE Work-shop on Mobile Computing Systems and Applications HOTMO-BILE 2007 pp 79ndash84 Tucson AZ USA February 2007

[37] P Caballero-Gil J Molina-Gil C Hernandez-Goya andC Caballero-Gil ldquoStimulating cooperation in self-organizedvehicular networksrdquo in Proceedings of the 2009 15th Asia-Pacific Conference on Communications APCC 2009 pp 346ndash349 Shanghai China October 2009

[38] F Dotzer L Fischer and P Magiera ldquoVARS a vehicle ad-hoc network reputation systemrdquo in Proceedings of the 6th IEEEInternational Symposium on a World of Wireless Mobile andMultimedia Networks WoWMoM rsquo05 pp 454ndash456 Taormina-Giardini Naxos Italy June 2005

[39] Q Li A Malip K M Martin S-L Ng and J Zhang ldquoAreputation-based announcement scheme for VANETsrdquo IEEETransactions on Vehicular Technology vol 61 no 9 pp 4095ndash4108 2012

[40] J F Bravo-Torres M Lopez-Nores Y Blanco-Fernandez JJ Pazos-Arias and E F Ordonez-Morales ldquoVaNetLayer Avirtualization layer supporting access to web contents fromwithin vehicular networksrdquo Journal of Computational Sciencevol 11 pp 185ndash195 2015

[41] C E Perkins and EM Royer ldquoAd hoc on-demand distance vec-tor (AODV) routingrdquo in Proceedings of the 2nd IEEE Workshopon Mobile Computing Systems and Applications (WMCSA rsquo99)pp 90ndash100 New Orleans La USA February 1999

[42] M Jerbi S-M Senouci T Rasheed and Y Ghamri-DoudaneldquoTowards efficient geographic routing in urban vehicular net-worksrdquo IEEE Transactions on Vehicular Technology vol 58 no9 pp 5048ndash5059 2009

[43] J F Bravo-Torres M Lopez-Nores J V Saians-Vazquez YBlanco-Fernandez and J J Pazos-Arias ldquoAn efficient combi-nation of topological and geographical routing for VANETs ontop of a virtualization layerrdquo in Proceedings of the 2015 IEEE81st Vehicular Technology Conference (VTC Spring) pp 1ndash5Glasgow United Kingdom May 2015

[44] E F Ordonez-Morales V Saians-Vazquez J F Bravo-Torres YBlanco-Fenandez and M Lopez-Noresi ldquoLeveraging proactiveand reactive intersection-based routing protocols for collabo-rative downloading in VANETsrdquo in Proceedings of the 2016 8thIEEE Latin-American Conference on Communications (LATIN-COM) pp 1ndash6 Medellin Colombia November 2016

[45] YWiseman ldquoCan flight data recorder memory be stored on thecloudrdquo Journal of Aviation Technology and Engineering vol 6no 1 p 3 2016

[46] Y Wiseman ldquoUnlimited and protected memory for flight datarecordersrdquo Aircraft Engineering and Aerospace Technology vol88 no 6 pp 866ndash872 2016

[47] A Baiocchi and F Cuomo ldquoInfotainment services based onpush-mode dissemination in an integrated VANET and 3Garchitecturerdquo Journal of Communications and Networks vol 15no 2 pp 179ndash190 2013

[48] P K Singh and K Lego ldquoComparative study of radio prop-agation and mobility models in vehicular adhoc networkrdquoInternational Journal of Computer Applications vol 16 no 8 pp37ndash42 2011

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018


Active and Passive Electronic Components

VLSI Design



Shock and Vibration


Civil EngineeringAdvances in

Acoustics and VibrationAdvances in



Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of



Journal ofEngineeringVolume 2018

SensorsJournal of



RotatingMachinery


Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018


Chemical EngineeringInternational Journal of Antennas and

Propagation




Navigation and Observation


Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom


of) their codes and the data required for their executionto a remote server According to the taxonomy of [6]existing CMA solutions can be categorized into four maintypes as per the location and mobility of the augmentationclouds distant immobile clouds proximate immobile cloudsproximate mobile clouds and hybrid approaches that combinethe previous models [7 8]

(i) The distant immobile clouds (MCC) are supportedby public and private clouds that comprise a largenumber of stationary remote servers that are typicallylocated far from vehicles The distance to the basestation along with the interference caused by thepresence of buildings or a high number of simulta-neously connected users leads to problems of highlatency and low bandwidth that greatly degrade theexperience of mobile users and hamper the deploy-ment of non-delay tolerant information services [910]

(ii) In order to tackle problems related to bandwidth andlatency some CMA solutions adopt proximate immo-bile clouds (typically named cloudlets) that involvestationary computers located in public places near thevehicles (eg parking lotsmalls and airports) whoseresources are typically underutilized The problemis that these approaches significantly limit the usersrsquomobility because resource-intensive mobile applica-tions can be just executed in the area around thecloudlet [11]

(iii) The most recent CMA approaches rely on proximatemobile clouds (VCC) where nearby vehicles lend theirresources to other vehicles to perform intensive com-putations in a distributed manner [12] Despite theirname the first approaches proposed in this regard dis-regarded the mobility of the augmentation nodes (byhandling instead clusters of fixed handheld devices)due to the open challenges related to this trait (suchas communication disruption as the users move andthe consequent frequent interruptions of applicationexecution [13]) More sophisticated approaches aroselater in literature [14 15] However in these solutionsthe management of the mobility continues beingan open problem due to the fact that they restrictthe movements of the AppN and its collaborators(requiring for instance that all these nodes remaintogether during the augmentation process whichis interrupted when AppN and CNs move away)[16ndash18]

Bearing in mind the above limitations in [19] we pro-posed an approach where the augmentation resources weresharedlent by a sporadic cloud of near vehicles that remaintogether during a certain period of time For that reasonwe coined our approach as Sporadic Cloud-based MobileAugmentation (hereafter S-CMA) which is based on a newparadigm we have called Sporadic Cloud Computing (SCC)

In other words S-CMA is based on the SCC principles inthe same way that traditional CMA relies on MCCVCCfoundations In particular in [19] we envisaged the commonfoundations for the deployment of diverse ldquoXrdquoaaS servicemodels over a VANET (such as Networking as a Service(NaaS) STorage as a Service (STaaS) Computing as a Service(CaaS) and SEnsing as a Service (SEaaS) just to name a few)Later in [20] we focused on the particular refinements thatworking on the top of the common basis were required in aNaaS service In this paper we have extended that previouswork developing a hybrid S-CMA approach that exploitsboth the augmentation capabilities of a sporadic cloud of on-move vehicles and the resources available at roadside-fixedinfrastructure (through WiFi access points) Unlike existingCMA approaches our sporadic cloud comprises an ad hoccluster of mobile devices that do move freely where (i) their(high) mobility is managed by a virtualization layer (namedVaNetLayer) that engages the mobile nodes in collaborationto emulate a reliable infrastructure of stationary virtualnodes [21] and (ii) a seamless handover allows restoring theaugmentation service transparently for the applications whenAppN and CNs separate

In our approach the web contents will be splitted intochunks that the CNs must download (from a remote server)and finally deliver to the AppN To this aim we exploit aNaaS model that supports both individualized access to webcontents of interest for just one vehicle within the VANET(hereafter individual content) and access to popular contentsthat are appealing to allmost of the vehicles within the adhoc network thus leading to two download models whichwe will be referred to as individual content download (ICD)and popular content download (PCD) respectively As amain difference in PCD some collaborator nodes could havedownloaded previously (for other interested AppNs) andlocally stored some chunks of the requested popular contentswhereas in ICD (all the pieces of) the individual contentsmust be always retrieved from the Internet In conclusionwe contribute with a new hybrid S-CMA approach for thedeployment of a NaaS model for collaborative download ofweb contents inVANETs working on the top of virtualizationmechanisms that hide the complexity derived from themobility of the augmentation cloud which is an issue thatto the best of our knowledge remains unresolved in theliterature

This paper is organized as follows In Section 2 we presenta review of existing approaches to collaborative download ofweb contents in VANETs along with the mechanisms thatare typically adopted to incentivize the involvement of nodesin augmentation tasks Next Section 3 summarizes the mainfoundations of the virtualization layer (VaNetLayer) and therouting protocol (VNIBR) on which our hybrid S-CMAapproach works The S-CMA mechanisms envisaged for thedeployment of ourNaaSmodel will be presented in Section 4The experiments carried out to assess the performance ofour proposal in terms of number of downloads downloadtime networking overhead and some augmentation-specificmetrics will be described in Section 5 Lastly Section 6concludes the paper and points out some lines of furtherwork


2 Related Works










Link layer

(IEEE 80211p)


(VaNetLayer)

Network layer

(VNIBR)

Augmentation layer

(S-CMA)

Application layer

(NaaSSTaaSSEaaS)















CN2 CN1

REGION 51

Sporadic Cloud 3

Sporadic Cloud 4

Sporadic Cloud 1

Sporadic Cloud 2

Road Segment Region

L1VNL2VN

L2VN

L2VN

L2VNL3VN

L3VN

L3VN

L3VNL3VN L3VN

L1VN

REGION 52REGION 53

INTERSECTION

REGION 50

INTERSECTION

REGION 54

Base Station3G4G

ServerInternet

CN3

AppN

AP

dic Cloud 4L3VN

L3VN

L1VN






















3140

43

46

4142

43

91

92 93

32

33

31 61

71

12191

41

6 1

6 26 3

7 27 1

121122

Internet

APL3VN

L3VN

L3VN

L3VN

L3VN

L3VN

L3VN

L3VN

L3VN

51

52

53

71

72

73

75

76

77

55

56

57

31

32

33

74

70

54

34

30

38

50

58

35

36

37

L3VN

60

63

66

62

65

68

42

45

48

78

Base Station3G4G

Base Station3G4G

R-S 9

R-S 8

R-S 6

R-S 1

R-S 2

R-S 7

R-S 3

R-S 4

R-S 5

R-S 10

R-S 11

R-S 12

AppN

Lider

CNVehicle

R-S Road Segment


S-C 3

S-C 4

S-C 2

S-C 5

L1VN

L1VN

L1VN

L1VN

L1VN

L1VN

L1VN

L1VN










Table1Listof

messagesu

sedin

ourS

-CMAapproach

Usedby

Messages

Descriptio

nCN

MResourceInfoFrom

CNUsedto

send

ther

esou

rceinformationfro

maC

Nto

aVN

AppN

MSearchRequest

Allo

wsrequestingaC

Nto

perfo


AppN

isno

tcon

nected

totheInternet

AppN

MResourceRequest

Usedto

requ

estaug

mentatio

nresources(band

width

inNaaS)

AppN

MCloudR

esourceInfo

Con


tthe

availableb

andw

idth

forthe

augm

entatio

nprocess

AppN

MWith

outCollaborators

Indicatesthatthere

aren

oavailablea

ugmentatio

nresources

AppN

MInsufficie

ntResources

Indicatesthatthere

aren

oenou

ghaugm

entatio

nresources

AppN

MUn

availableA

ugmentatio

nService

Indicatestothea

pplicationlay

erthatthea

ugmentatio

nserviceisn

otavailable

AppN

MCloudR

elease

Indicatesthe

releaseo

fasporadicclo

ud

AppN

MSend

TaskToCN

Allo

wstosend

downloadtaskstoCN

sCN

MAc

ceptedTaskFrom

CNAllo

wsthe

CNstoconfi

rmthatthey

accept

todo


AppN

CN

MCo

mpleteTask

Allo

wsthe

CNstosend

chun

ksof

theA

ppN-requeste

dcontent

AppN

MCo

mpleteTaskA

CKAc

know

ledgem

entthatthe

chun

kshave

arriv

edcorrectly

from

theC

Nto

theA

ppN

CNM

IncompleteTask

Usedto

repo

rtthatad

ownloadtask

cann

otcontinue

AppN

MIncompleteTaskA

CKAc

know

ledgem

entthata

downloadtask

cann

otcontinue

inaC

N

AppN

MTaskInfo

Allowstosend

theinformationof

completedin

completed

ownloadtaskstothea

pplicationlayero

fthe

AppN


RESOURCEREQUEST

INITIAL







expires++
















Table2Listof

timersu

sedin

ourS

-CMAapproach

Usedby

Timers

Tune

timeto

AppN

TResourceRequest

Waitfor

inform

ationabou

tavailablea

ugmentatio

nresources

AppN

TTaskDistrib

ution

Allo

wallocatin

gdo

wnloadtasksa

mon

gtheC

Ns

AppN

TIntersectio

nReceptio

nWaitfor

thetasks

perfo

rmed

bytheC

Nsw

henan

AppN

entersan

intersectio

nAp

pNTReception

Waitfor

thec

hunk

sofcon

tent

downloadedby

theC

Ns

CNTCo

mpleteTaskA

CKWaitfor

ACKof

oneo

rmorec

ompleted

chun

ksthathave

been

sent

from

theC

NstotheA

ppN

CNTIncompleteTaskA

CKWaitfor

ACKof

adow

nloadtask

thatcann

otcontinue

AppN

TGu

ardT

ime

Waita

GuardTimefor

chun

kssent

bytheC

Nsa

fterreceiving

MCloudR

eleasefrom

theA

ppN




RESOURCEREQUEST

TASK DISTRIBU-

TION








TASK DISTRIBU-

TION




INITIAL



















119862119873119894)

Obviously the 119877119878119860119879119862119873119894



(denoted as 119860V119878119901119890119890119889119862119873119894



TASK DISTRIBU-

TION



TASKRECEPTION
















TASKRECEPTION







119877119878119860119879119862119873119894=119875119900119904119894119905119894119900119899

119862119873119894

119860119881119878119901119890119890119889119862119873119894

(1)


119862119873119894




)

119888ℎ119906119899119896119904119862119873119894=119861119882119862119873119894sdot 119877119878119860119879

119862119873119894

119888ℎ119906119899119896 119904119894119911119890(2)





INITIAL


COLLA-BORATION











RESOURCEREQUEST

TASKDISTRIBU-

TION

INITIAL





















start(T_GuarTime)










TASKRECEPTION


COLLA-BORATION


































AP AP

AP

AP AP












ICD

PCD

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med






ICD

PCD

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]





ICD

PCD

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs




ICD vs PCD

ICDPCD

0

2

4

6

8

10

12

14

16

Aver

age d

ownl

oad

spee

d [M

bps]

30 40 50 6 0 70 80 20 CNs






Data Availability




Acknowledgments


References






















































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



2 Related Works










Link layer

(IEEE 80211p)


(VaNetLayer)

Network layer

(VNIBR)

Augmentation layer

(S-CMA)

Application layer

(NaaSSTaaSSEaaS)















CN2 CN1

REGION 51

Sporadic Cloud 3

Sporadic Cloud 4

Sporadic Cloud 1

Sporadic Cloud 2

Road Segment Region

L1VNL2VN

L2VN

L2VN

L2VNL3VN

L3VN

L3VN

L3VNL3VN L3VN

L1VN

REGION 52REGION 53

INTERSECTION

REGION 50

INTERSECTION

REGION 54

Base Station3G4G

ServerInternet

CN3

AppN

AP

dic Cloud 4L3VN

L3VN

L1VN






















3140

43

46

4142

43

91

92 93

32

33

31 61

71

12191

41

6 1

6 26 3

7 27 1

121122

Internet

APL3VN

L3VN

L3VN

L3VN

L3VN

L3VN

L3VN

L3VN

L3VN

51

52

53

71

72

73

75

76

77

55

56

57

31

32

33

74

70

54

34

30

38

50

58

35

36

37

L3VN

60

63

66

62

65

68

42

45

48

78

Base Station3G4G

Base Station3G4G

R-S 9

R-S 8

R-S 6

R-S 1

R-S 2

R-S 7

R-S 3

R-S 4

R-S 5

R-S 10

R-S 11

R-S 12

AppN

Lider

CNVehicle

R-S Road Segment


S-C 3

S-C 4

S-C 2

S-C 5

L1VN

L1VN

L1VN

L1VN

L1VN

L1VN

L1VN

L1VN










Table1Listof

messagesu

sedin

ourS

-CMAapproach

Usedby

Messages

Descriptio

nCN

MResourceInfoFrom

CNUsedto

send

ther

esou

rceinformationfro

maC

Nto

aVN

AppN

MSearchRequest

Allo

wsrequestingaC

Nto

perfo


AppN

isno

tcon

nected

totheInternet

AppN

MResourceRequest

Usedto

requ

estaug

mentatio

nresources(band

width

inNaaS)

AppN

MCloudR

esourceInfo

Con


tthe

availableb

andw

idth

forthe

augm

entatio

nprocess

AppN

MWith

outCollaborators

Indicatesthatthere

aren

oavailablea

ugmentatio

nresources

AppN

MInsufficie

ntResources

Indicatesthatthere

aren

oenou

ghaugm

entatio

nresources

AppN

MUn

availableA

ugmentatio

nService

Indicatestothea

pplicationlay

erthatthea

ugmentatio

nserviceisn

otavailable

AppN

MCloudR

elease

Indicatesthe

releaseo

fasporadicclo

ud

AppN

MSend

TaskToCN

Allo

wstosend

downloadtaskstoCN

sCN

MAc

ceptedTaskFrom

CNAllo

wsthe

CNstoconfi

rmthatthey

accept

todo


AppN

CN

MCo

mpleteTask

Allo

wsthe

CNstosend

chun

ksof

theA

ppN-requeste

dcontent

AppN

MCo

mpleteTaskA

CKAc

know

ledgem

entthatthe

chun

kshave

arriv

edcorrectly

from

theC

Nto

theA

ppN

CNM

IncompleteTask

Usedto

repo

rtthatad

ownloadtask

cann

otcontinue

AppN

MIncompleteTaskA

CKAc

know

ledgem

entthata

downloadtask

cann

otcontinue

inaC

N

AppN

MTaskInfo

Allowstosend

theinformationof

completedin

completed

ownloadtaskstothea

pplicationlayero

fthe

AppN


RESOURCEREQUEST

INITIAL







expires++
















Table2Listof

timersu

sedin

ourS

-CMAapproach

Usedby

Timers

Tune

timeto

AppN

TResourceRequest

Waitfor

inform

ationabou

tavailablea

ugmentatio

nresources

AppN

TTaskDistrib

ution

Allo

wallocatin

gdo

wnloadtasksa

mon

gtheC

Ns

AppN

TIntersectio

nReceptio

nWaitfor

thetasks

perfo

rmed

bytheC

Nsw

henan

AppN

entersan

intersectio

nAp

pNTReception

Waitfor

thec

hunk

sofcon

tent

downloadedby

theC

Ns

CNTCo

mpleteTaskA

CKWaitfor

ACKof

oneo

rmorec

ompleted

chun

ksthathave

been

sent

from

theC

NstotheA

ppN

CNTIncompleteTaskA

CKWaitfor

ACKof

adow

nloadtask

thatcann

otcontinue

AppN

TGu

ardT

ime

Waita

GuardTimefor

chun

kssent

bytheC

Nsa

fterreceiving

MCloudR

eleasefrom

theA

ppN




RESOURCEREQUEST

TASK DISTRIBU-

TION








TASK DISTRIBU-

TION




INITIAL



















119862119873119894)

Obviously the 119877119878119860119879119862119873119894



(denoted as 119860V119878119901119890119890119889119862119873119894



TASK DISTRIBU-

TION



TASKRECEPTION
















TASKRECEPTION







119877119878119860119879119862119873119894=119875119900119904119894119905119894119900119899

119862119873119894

119860119881119878119901119890119890119889119862119873119894

(1)


119862119873119894




)

119888ℎ119906119899119896119904119862119873119894=119861119882119862119873119894sdot 119877119878119860119879

119862119873119894

119888ℎ119906119899119896 119904119894119911119890(2)





INITIAL


COLLA-BORATION











RESOURCEREQUEST

TASKDISTRIBU-

TION

INITIAL





















start(T_GuarTime)










TASKRECEPTION


COLLA-BORATION


































AP AP

AP

AP AP












ICD

PCD

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med






ICD

PCD

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]





ICD

PCD

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs




ICD vs PCD

ICDPCD

0

2

4

6

8

10

12

14

16

Aver

age d

ownl

oad

spee

d [M

bps]

30 40 50 6 0 70 80 20 CNs






Data Availability




Acknowledgments


References






















































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



Link layer

(IEEE 80211p)


(VaNetLayer)

Network layer

(VNIBR)

Augmentation layer

(S-CMA)

Application layer

(NaaSSTaaSSEaaS)















CN2 CN1

REGION 51

Sporadic Cloud 3

Sporadic Cloud 4

Sporadic Cloud 1

Sporadic Cloud 2

Road Segment Region

L1VNL2VN

L2VN

L2VN

L2VNL3VN

L3VN

L3VN

L3VNL3VN L3VN

L1VN

REGION 52REGION 53

INTERSECTION

REGION 50

INTERSECTION

REGION 54

Base Station3G4G

ServerInternet

CN3

AppN

AP

dic Cloud 4L3VN

L3VN

L1VN






















3140

43

46

4142

43

91

92 93

32

33

31 61

71

12191

41

6 1

6 26 3

7 27 1

121122

Internet

APL3VN

L3VN

L3VN

L3VN

L3VN

L3VN

L3VN

L3VN

L3VN

51

52

53

71

72

73

75

76

77

55

56

57

31

32

33

74

70

54

34

30

38

50

58

35

36

37

L3VN

60

63

66

62

65

68

42

45

48

78

Base Station3G4G

Base Station3G4G

R-S 9

R-S 8

R-S 6

R-S 1

R-S 2

R-S 7

R-S 3

R-S 4

R-S 5

R-S 10

R-S 11

R-S 12

AppN

Lider

CNVehicle

R-S Road Segment


S-C 3

S-C 4

S-C 2

S-C 5

L1VN

L1VN

L1VN

L1VN

L1VN

L1VN

L1VN

L1VN










Table1Listof

messagesu

sedin

ourS

-CMAapproach

Usedby

Messages

Descriptio

nCN

MResourceInfoFrom

CNUsedto

send

ther

esou

rceinformationfro

maC

Nto

aVN

AppN

MSearchRequest

Allo

wsrequestingaC

Nto

perfo


AppN

isno

tcon

nected

totheInternet

AppN

MResourceRequest

Usedto

requ

estaug

mentatio

nresources(band

width

inNaaS)

AppN

MCloudR

esourceInfo

Con


tthe

availableb

andw

idth

forthe

augm

entatio

nprocess

AppN

MWith

outCollaborators

Indicatesthatthere

aren

oavailablea

ugmentatio

nresources

AppN

MInsufficie

ntResources

Indicatesthatthere

aren

oenou

ghaugm

entatio

nresources

AppN

MUn

availableA

ugmentatio

nService

Indicatestothea

pplicationlay

erthatthea

ugmentatio

nserviceisn

otavailable

AppN

MCloudR

elease

Indicatesthe

releaseo

fasporadicclo

ud

AppN

MSend

TaskToCN

Allo

wstosend

downloadtaskstoCN

sCN

MAc

ceptedTaskFrom

CNAllo

wsthe

CNstoconfi

rmthatthey

accept

todo


AppN

CN

MCo

mpleteTask

Allo

wsthe

CNstosend

chun

ksof

theA

ppN-requeste

dcontent

AppN

MCo

mpleteTaskA

CKAc

know

ledgem

entthatthe

chun

kshave

arriv

edcorrectly

from

theC

Nto

theA

ppN

CNM

IncompleteTask

Usedto

repo

rtthatad

ownloadtask

cann

otcontinue

AppN

MIncompleteTaskA

CKAc

know

ledgem

entthata

downloadtask

cann

otcontinue

inaC

N

AppN

MTaskInfo

Allowstosend

theinformationof

completedin

completed

ownloadtaskstothea

pplicationlayero

fthe

AppN


RESOURCEREQUEST

INITIAL







expires++
















Table2Listof

timersu

sedin

ourS

-CMAapproach

Usedby

Timers

Tune

timeto

AppN

TResourceRequest

Waitfor

inform

ationabou

tavailablea

ugmentatio

nresources

AppN

TTaskDistrib

ution

Allo

wallocatin

gdo

wnloadtasksa

mon

gtheC

Ns

AppN

TIntersectio

nReceptio

nWaitfor

thetasks

perfo

rmed

bytheC

Nsw

henan

AppN

entersan

intersectio

nAp

pNTReception

Waitfor

thec

hunk

sofcon

tent

downloadedby

theC

Ns

CNTCo

mpleteTaskA

CKWaitfor

ACKof

oneo

rmorec

ompleted

chun

ksthathave

been

sent

from

theC

NstotheA

ppN

CNTIncompleteTaskA

CKWaitfor

ACKof

adow

nloadtask

thatcann

otcontinue

AppN

TGu

ardT

ime

Waita

GuardTimefor

chun

kssent

bytheC

Nsa

fterreceiving

MCloudR

eleasefrom

theA

ppN




RESOURCEREQUEST

TASK DISTRIBU-

TION








TASK DISTRIBU-

TION




INITIAL



















119862119873119894)

Obviously the 119877119878119860119879119862119873119894



(denoted as 119860V119878119901119890119890119889119862119873119894



TASK DISTRIBU-

TION



TASKRECEPTION
















TASKRECEPTION







119877119878119860119879119862119873119894=119875119900119904119894119905119894119900119899

119862119873119894

119860119881119878119901119890119890119889119862119873119894

(1)


119862119873119894




)

119888ℎ119906119899119896119904119862119873119894=119861119882119862119873119894sdot 119877119878119860119879

119862119873119894

119888ℎ119906119899119896 119904119894119911119890(2)





INITIAL


COLLA-BORATION











RESOURCEREQUEST

TASKDISTRIBU-

TION

INITIAL





















start(T_GuarTime)










TASKRECEPTION


COLLA-BORATION


































AP AP

AP

AP AP












ICD

PCD

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med






ICD

PCD

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]





ICD

PCD

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs




ICD vs PCD

ICDPCD

0

2

4

6

8

10

12

14

16

Aver

age d

ownl

oad

spee

d [M

bps]

30 40 50 6 0 70 80 20 CNs






Data Availability




Acknowledgments


References






















































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



CN2 CN1

REGION 51

Sporadic Cloud 3

Sporadic Cloud 4

Sporadic Cloud 1

Sporadic Cloud 2

Road Segment Region

L1VNL2VN

L2VN

L2VN

L2VNL3VN

L3VN

L3VN

L3VNL3VN L3VN

L1VN

REGION 52REGION 53

INTERSECTION

REGION 50

INTERSECTION

REGION 54

Base Station3G4G

ServerInternet

CN3

AppN

AP

dic Cloud 4L3VN

L3VN

L1VN






















3140

43

46

4142

43

91

92 93

32

33

31 61

71

12191

41

6 1

6 26 3

7 27 1

121122

Internet

APL3VN

L3VN

L3VN

L3VN

L3VN

L3VN

L3VN

L3VN

L3VN

51

52

53

71

72

73

75

76

77

55

56

57

31

32

33

74

70

54

34

30

38

50

58

35

36

37

L3VN

60

63

66

62

65

68

42

45

48

78

Base Station3G4G

Base Station3G4G

R-S 9

R-S 8

R-S 6

R-S 1

R-S 2

R-S 7

R-S 3

R-S 4

R-S 5

R-S 10

R-S 11

R-S 12

AppN

Lider

CNVehicle

R-S Road Segment


S-C 3

S-C 4

S-C 2

S-C 5

L1VN

L1VN

L1VN

L1VN

L1VN

L1VN

L1VN

L1VN










Table1Listof

messagesu

sedin

ourS

-CMAapproach

Usedby

Messages

Descriptio

nCN

MResourceInfoFrom

CNUsedto

send

ther

esou

rceinformationfro

maC

Nto

aVN

AppN

MSearchRequest

Allo

wsrequestingaC

Nto

perfo


AppN

isno

tcon

nected

totheInternet

AppN

MResourceRequest

Usedto

requ

estaug

mentatio

nresources(band

width

inNaaS)

AppN

MCloudR

esourceInfo

Con


tthe

availableb

andw

idth

forthe

augm

entatio

nprocess

AppN

MWith

outCollaborators

Indicatesthatthere

aren

oavailablea

ugmentatio

nresources

AppN

MInsufficie

ntResources

Indicatesthatthere

aren

oenou

ghaugm

entatio

nresources

AppN

MUn

availableA

ugmentatio

nService

Indicatestothea

pplicationlay

erthatthea

ugmentatio

nserviceisn

otavailable

AppN

MCloudR

elease

Indicatesthe

releaseo

fasporadicclo

ud

AppN

MSend

TaskToCN

Allo

wstosend

downloadtaskstoCN

sCN

MAc

ceptedTaskFrom

CNAllo

wsthe

CNstoconfi

rmthatthey

accept

todo


AppN

CN

MCo

mpleteTask

Allo

wsthe

CNstosend

chun

ksof

theA

ppN-requeste

dcontent

AppN

MCo

mpleteTaskA

CKAc

know

ledgem

entthatthe

chun

kshave

arriv

edcorrectly

from

theC

Nto

theA

ppN

CNM

IncompleteTask

Usedto

repo

rtthatad

ownloadtask

cann

otcontinue

AppN

MIncompleteTaskA

CKAc

know

ledgem

entthata

downloadtask

cann

otcontinue

inaC

N

AppN

MTaskInfo

Allowstosend

theinformationof

completedin

completed

ownloadtaskstothea

pplicationlayero

fthe

AppN


RESOURCEREQUEST

INITIAL







expires++
















Table2Listof

timersu

sedin

ourS

-CMAapproach

Usedby

Timers

Tune

timeto

AppN

TResourceRequest

Waitfor

inform

ationabou

tavailablea

ugmentatio

nresources

AppN

TTaskDistrib

ution

Allo

wallocatin

gdo

wnloadtasksa

mon

gtheC

Ns

AppN

TIntersectio

nReceptio

nWaitfor

thetasks

perfo

rmed

bytheC

Nsw

henan

AppN

entersan

intersectio

nAp

pNTReception

Waitfor

thec

hunk

sofcon

tent

downloadedby

theC

Ns

CNTCo

mpleteTaskA

CKWaitfor

ACKof

oneo

rmorec

ompleted

chun

ksthathave

been

sent

from

theC

NstotheA

ppN

CNTIncompleteTaskA

CKWaitfor

ACKof

adow

nloadtask

thatcann

otcontinue

AppN

TGu

ardT

ime

Waita

GuardTimefor

chun

kssent

bytheC

Nsa

fterreceiving

MCloudR

eleasefrom

theA

ppN




RESOURCEREQUEST

TASK DISTRIBU-

TION








TASK DISTRIBU-

TION




INITIAL



















119862119873119894)

Obviously the 119877119878119860119879119862119873119894



(denoted as 119860V119878119901119890119890119889119862119873119894



TASK DISTRIBU-

TION



TASKRECEPTION
















TASKRECEPTION







119877119878119860119879119862119873119894=119875119900119904119894119905119894119900119899

119862119873119894

119860119881119878119901119890119890119889119862119873119894

(1)


119862119873119894




)

119888ℎ119906119899119896119904119862119873119894=119861119882119862119873119894sdot 119877119878119860119879

119862119873119894

119888ℎ119906119899119896 119904119894119911119890(2)





INITIAL


COLLA-BORATION











RESOURCEREQUEST

TASKDISTRIBU-

TION

INITIAL





















start(T_GuarTime)










TASKRECEPTION


COLLA-BORATION


































AP AP

AP

AP AP












ICD

PCD

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med






ICD

PCD

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]





ICD

PCD

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs




ICD vs PCD

ICDPCD

0

2

4

6

8

10

12

14

16

Aver

age d

ownl

oad

spee

d [M

bps]

30 40 50 6 0 70 80 20 CNs






Data Availability




Acknowledgments


References






















































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia
















3140

43

46

4142

43

91

92 93

32

33

31 61

71

12191

41

6 1

6 26 3

7 27 1

121122

Internet

APL3VN

L3VN

L3VN

L3VN

L3VN

L3VN

L3VN

L3VN

L3VN

51

52

53

71

72

73

75

76

77

55

56

57

31

32

33

74

70

54

34

30

38

50

58

35

36

37

L3VN

60

63

66

62

65

68

42

45

48

78

Base Station3G4G

Base Station3G4G

R-S 9

R-S 8

R-S 6

R-S 1

R-S 2

R-S 7

R-S 3

R-S 4

R-S 5

R-S 10

R-S 11

R-S 12

AppN

Lider

CNVehicle

R-S Road Segment


S-C 3

S-C 4

S-C 2

S-C 5

L1VN

L1VN

L1VN

L1VN

L1VN

L1VN

L1VN

L1VN










Table1Listof

messagesu

sedin

ourS

-CMAapproach

Usedby

Messages

Descriptio

nCN

MResourceInfoFrom

CNUsedto

send

ther

esou

rceinformationfro

maC

Nto

aVN

AppN

MSearchRequest

Allo

wsrequestingaC

Nto

perfo


AppN

isno

tcon

nected

totheInternet

AppN

MResourceRequest

Usedto

requ

estaug

mentatio

nresources(band

width

inNaaS)

AppN

MCloudR

esourceInfo

Con


tthe

availableb

andw

idth

forthe

augm

entatio

nprocess

AppN

MWith

outCollaborators

Indicatesthatthere

aren

oavailablea

ugmentatio

nresources

AppN

MInsufficie

ntResources

Indicatesthatthere

aren

oenou

ghaugm

entatio

nresources

AppN

MUn

availableA

ugmentatio

nService

Indicatestothea

pplicationlay

erthatthea

ugmentatio

nserviceisn

otavailable

AppN

MCloudR

elease

Indicatesthe

releaseo

fasporadicclo

ud

AppN

MSend

TaskToCN

Allo

wstosend

downloadtaskstoCN

sCN

MAc

ceptedTaskFrom

CNAllo

wsthe

CNstoconfi

rmthatthey

accept

todo


AppN

CN

MCo

mpleteTask

Allo

wsthe

CNstosend

chun

ksof

theA

ppN-requeste

dcontent

AppN

MCo

mpleteTaskA

CKAc

know

ledgem

entthatthe

chun

kshave

arriv

edcorrectly

from

theC

Nto

theA

ppN

CNM

IncompleteTask

Usedto

repo

rtthatad

ownloadtask

cann

otcontinue

AppN

MIncompleteTaskA

CKAc

know

ledgem

entthata

downloadtask

cann

otcontinue

inaC

N

AppN

MTaskInfo

Allowstosend

theinformationof

completedin

completed

ownloadtaskstothea

pplicationlayero

fthe

AppN


RESOURCEREQUEST

INITIAL







expires++
















Table2Listof

timersu

sedin

ourS

-CMAapproach

Usedby

Timers

Tune

timeto

AppN

TResourceRequest

Waitfor

inform

ationabou

tavailablea

ugmentatio

nresources

AppN

TTaskDistrib

ution

Allo

wallocatin

gdo

wnloadtasksa

mon

gtheC

Ns

AppN

TIntersectio

nReceptio

nWaitfor

thetasks

perfo

rmed

bytheC

Nsw

henan

AppN

entersan

intersectio

nAp

pNTReception

Waitfor

thec

hunk

sofcon

tent

downloadedby

theC

Ns

CNTCo

mpleteTaskA

CKWaitfor

ACKof

oneo

rmorec

ompleted

chun

ksthathave

been

sent

from

theC

NstotheA

ppN

CNTIncompleteTaskA

CKWaitfor

ACKof

adow

nloadtask

thatcann

otcontinue

AppN

TGu

ardT

ime

Waita

GuardTimefor

chun

kssent

bytheC

Nsa

fterreceiving

MCloudR

eleasefrom

theA

ppN




RESOURCEREQUEST

TASK DISTRIBU-

TION








TASK DISTRIBU-

TION




INITIAL



















119862119873119894)

Obviously the 119877119878119860119879119862119873119894



(denoted as 119860V119878119901119890119890119889119862119873119894



TASK DISTRIBU-

TION



TASKRECEPTION
















TASKRECEPTION







119877119878119860119879119862119873119894=119875119900119904119894119905119894119900119899

119862119873119894

119860119881119878119901119890119890119889119862119873119894

(1)


119862119873119894




)

119888ℎ119906119899119896119904119862119873119894=119861119882119862119873119894sdot 119877119878119860119879

119862119873119894

119888ℎ119906119899119896 119904119894119911119890(2)





INITIAL


COLLA-BORATION











RESOURCEREQUEST

TASKDISTRIBU-

TION

INITIAL





















start(T_GuarTime)










TASKRECEPTION


COLLA-BORATION


































AP AP

AP

AP AP












ICD

PCD

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med






ICD

PCD

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]





ICD

PCD

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs




ICD vs PCD

ICDPCD

0

2

4

6

8

10

12

14

16

Aver

age d

ownl

oad

spee

d [M

bps]

30 40 50 6 0 70 80 20 CNs






Data Availability




Acknowledgments


References






















































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



Table1Listof

messagesu

sedin

ourS

-CMAapproach

Usedby

Messages

Descriptio

nCN

MResourceInfoFrom

CNUsedto

send

ther

esou

rceinformationfro

maC

Nto

aVN

AppN

MSearchRequest

Allo

wsrequestingaC

Nto

perfo


AppN

isno

tcon

nected

totheInternet

AppN

MResourceRequest

Usedto

requ

estaug

mentatio

nresources(band

width

inNaaS)

AppN

MCloudR

esourceInfo

Con


tthe

availableb

andw

idth

forthe

augm

entatio

nprocess

AppN

MWith

outCollaborators

Indicatesthatthere

aren

oavailablea

ugmentatio

nresources

AppN

MInsufficie

ntResources

Indicatesthatthere

aren

oenou

ghaugm

entatio

nresources

AppN

MUn

availableA

ugmentatio

nService

Indicatestothea

pplicationlay

erthatthea

ugmentatio

nserviceisn

otavailable

AppN

MCloudR

elease

Indicatesthe

releaseo

fasporadicclo

ud

AppN

MSend

TaskToCN

Allo

wstosend

downloadtaskstoCN

sCN

MAc

ceptedTaskFrom

CNAllo

wsthe

CNstoconfi

rmthatthey

accept

todo


AppN

CN

MCo

mpleteTask

Allo

wsthe

CNstosend

chun

ksof

theA

ppN-requeste

dcontent

AppN

MCo

mpleteTaskA

CKAc

know

ledgem

entthatthe

chun

kshave

arriv

edcorrectly

from

theC

Nto

theA

ppN

CNM

IncompleteTask

Usedto

repo

rtthatad

ownloadtask

cann

otcontinue

AppN

MIncompleteTaskA

CKAc

know

ledgem

entthata

downloadtask

cann

otcontinue

inaC

N

AppN

MTaskInfo

Allowstosend

theinformationof

completedin

completed

ownloadtaskstothea

pplicationlayero

fthe

AppN


RESOURCEREQUEST

INITIAL







expires++
















Table2Listof

timersu

sedin

ourS

-CMAapproach

Usedby

Timers

Tune

timeto

AppN

TResourceRequest

Waitfor

inform

ationabou

tavailablea

ugmentatio

nresources

AppN

TTaskDistrib

ution

Allo

wallocatin

gdo

wnloadtasksa

mon

gtheC

Ns

AppN

TIntersectio

nReceptio

nWaitfor

thetasks

perfo

rmed

bytheC

Nsw

henan

AppN

entersan

intersectio

nAp

pNTReception

Waitfor

thec

hunk

sofcon

tent

downloadedby

theC

Ns

CNTCo

mpleteTaskA

CKWaitfor

ACKof

oneo

rmorec

ompleted

chun

ksthathave

been

sent

from

theC

NstotheA

ppN

CNTIncompleteTaskA

CKWaitfor

ACKof

adow

nloadtask

thatcann

otcontinue

AppN

TGu

ardT

ime

Waita

GuardTimefor

chun

kssent

bytheC

Nsa

fterreceiving

MCloudR

eleasefrom

theA

ppN




RESOURCEREQUEST

TASK DISTRIBU-

TION








TASK DISTRIBU-

TION




INITIAL



















119862119873119894)

Obviously the 119877119878119860119879119862119873119894



(denoted as 119860V119878119901119890119890119889119862119873119894



TASK DISTRIBU-

TION



TASKRECEPTION
















TASKRECEPTION







119877119878119860119879119862119873119894=119875119900119904119894119905119894119900119899

119862119873119894

119860119881119878119901119890119890119889119862119873119894

(1)


119862119873119894




)

119888ℎ119906119899119896119904119862119873119894=119861119882119862119873119894sdot 119877119878119860119879

119862119873119894

119888ℎ119906119899119896 119904119894119911119890(2)





INITIAL


COLLA-BORATION











RESOURCEREQUEST

TASKDISTRIBU-

TION

INITIAL





















start(T_GuarTime)










TASKRECEPTION


COLLA-BORATION


































AP AP

AP

AP AP












ICD

PCD

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med






ICD

PCD

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]





ICD

PCD

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs




ICD vs PCD

ICDPCD

0

2

4

6

8

10

12

14

16

Aver

age d

ownl

oad

spee

d [M

bps]

30 40 50 6 0 70 80 20 CNs






Data Availability




Acknowledgments


References






















































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



RESOURCEREQUEST

INITIAL







expires++
















Table2Listof

timersu

sedin

ourS

-CMAapproach

Usedby

Timers

Tune

timeto

AppN

TResourceRequest

Waitfor

inform

ationabou

tavailablea

ugmentatio

nresources

AppN

TTaskDistrib

ution

Allo

wallocatin

gdo

wnloadtasksa

mon

gtheC

Ns

AppN

TIntersectio

nReceptio

nWaitfor

thetasks

perfo

rmed

bytheC

Nsw

henan

AppN

entersan

intersectio

nAp

pNTReception

Waitfor

thec

hunk

sofcon

tent

downloadedby

theC

Ns

CNTCo

mpleteTaskA

CKWaitfor

ACKof

oneo

rmorec

ompleted

chun

ksthathave

been

sent

from

theC

NstotheA

ppN

CNTIncompleteTaskA

CKWaitfor

ACKof

adow

nloadtask

thatcann

otcontinue

AppN

TGu

ardT

ime

Waita

GuardTimefor

chun

kssent

bytheC

Nsa

fterreceiving

MCloudR

eleasefrom

theA

ppN




RESOURCEREQUEST

TASK DISTRIBU-

TION








TASK DISTRIBU-

TION




INITIAL



















119862119873119894)

Obviously the 119877119878119860119879119862119873119894



(denoted as 119860V119878119901119890119890119889119862119873119894



TASK DISTRIBU-

TION



TASKRECEPTION
















TASKRECEPTION







119877119878119860119879119862119873119894=119875119900119904119894119905119894119900119899

119862119873119894

119860119881119878119901119890119890119889119862119873119894

(1)


119862119873119894




)

119888ℎ119906119899119896119904119862119873119894=119861119882119862119873119894sdot 119877119878119860119879

119862119873119894

119888ℎ119906119899119896 119904119894119911119890(2)





INITIAL


COLLA-BORATION











RESOURCEREQUEST

TASKDISTRIBU-

TION

INITIAL





















start(T_GuarTime)










TASKRECEPTION


COLLA-BORATION


































AP AP

AP

AP AP












ICD

PCD

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med






ICD

PCD

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]





ICD

PCD

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs




ICD vs PCD

ICDPCD

0

2

4

6

8

10

12

14

16

Aver

age d

ownl

oad

spee

d [M

bps]

30 40 50 6 0 70 80 20 CNs






Data Availability




Acknowledgments


References






















































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



Table2Listof

timersu

sedin

ourS

-CMAapproach

Usedby

Timers

Tune

timeto

AppN

TResourceRequest

Waitfor

inform

ationabou

tavailablea

ugmentatio

nresources

AppN

TTaskDistrib

ution

Allo

wallocatin

gdo

wnloadtasksa

mon

gtheC

Ns

AppN

TIntersectio

nReceptio

nWaitfor

thetasks

perfo

rmed

bytheC

Nsw

henan

AppN

entersan

intersectio

nAp

pNTReception

Waitfor

thec

hunk

sofcon

tent

downloadedby

theC

Ns

CNTCo

mpleteTaskA

CKWaitfor

ACKof

oneo

rmorec

ompleted

chun

ksthathave

been

sent

from

theC

NstotheA

ppN

CNTIncompleteTaskA

CKWaitfor

ACKof

adow

nloadtask

thatcann

otcontinue

AppN

TGu

ardT

ime

Waita

GuardTimefor

chun

kssent

bytheC

Nsa

fterreceiving

MCloudR

eleasefrom

theA

ppN




RESOURCEREQUEST

TASK DISTRIBU-

TION








TASK DISTRIBU-

TION




INITIAL



















119862119873119894)

Obviously the 119877119878119860119879119862119873119894



(denoted as 119860V119878119901119890119890119889119862119873119894



TASK DISTRIBU-

TION



TASKRECEPTION
















TASKRECEPTION







119877119878119860119879119862119873119894=119875119900119904119894119905119894119900119899

119862119873119894

119860119881119878119901119890119890119889119862119873119894

(1)


119862119873119894




)

119888ℎ119906119899119896119904119862119873119894=119861119882119862119873119894sdot 119877119878119860119879

119862119873119894

119888ℎ119906119899119896 119904119894119911119890(2)





INITIAL


COLLA-BORATION











RESOURCEREQUEST

TASKDISTRIBU-

TION

INITIAL





















start(T_GuarTime)










TASKRECEPTION


COLLA-BORATION


































AP AP

AP

AP AP












ICD

PCD

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med






ICD

PCD

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]





ICD

PCD

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs




ICD vs PCD

ICDPCD

0

2

4

6

8

10

12

14

16

Aver

age d

ownl

oad

spee

d [M

bps]

30 40 50 6 0 70 80 20 CNs






Data Availability




Acknowledgments


References






















































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia





RESOURCEREQUEST

TASK DISTRIBU-

TION








TASK DISTRIBU-

TION




INITIAL



















119862119873119894)

Obviously the 119877119878119860119879119862119873119894



(denoted as 119860V119878119901119890119890119889119862119873119894



TASK DISTRIBU-

TION



TASKRECEPTION
















TASKRECEPTION







119877119878119860119879119862119873119894=119875119900119904119894119905119894119900119899

119862119873119894

119860119881119878119901119890119890119889119862119873119894

(1)


119862119873119894




)

119888ℎ119906119899119896119904119862119873119894=119861119882119862119873119894sdot 119877119878119860119879

119862119873119894

119888ℎ119906119899119896 119904119894119911119890(2)





INITIAL


COLLA-BORATION











RESOURCEREQUEST

TASKDISTRIBU-

TION

INITIAL





















start(T_GuarTime)










TASKRECEPTION


COLLA-BORATION


































AP AP

AP

AP AP












ICD

PCD

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med






ICD

PCD

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]





ICD

PCD

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs




ICD vs PCD

ICDPCD

0

2

4

6

8

10

12

14

16

Aver

age d

ownl

oad

spee

d [M

bps]

30 40 50 6 0 70 80 20 CNs






Data Availability




Acknowledgments


References






















































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia















119862119873119894)

Obviously the 119877119878119860119879119862119873119894



(denoted as 119860V119878119901119890119890119889119862119873119894



TASK DISTRIBU-

TION



TASKRECEPTION
















TASKRECEPTION







119877119878119860119879119862119873119894=119875119900119904119894119905119894119900119899

119862119873119894

119860119881119878119901119890119890119889119862119873119894

(1)


119862119873119894




)

119888ℎ119906119899119896119904119862119873119894=119861119882119862119873119894sdot 119877119878119860119879

119862119873119894

119888ℎ119906119899119896 119904119894119911119890(2)





INITIAL


COLLA-BORATION











RESOURCEREQUEST

TASKDISTRIBU-

TION

INITIAL





















start(T_GuarTime)










TASKRECEPTION


COLLA-BORATION


































AP AP

AP

AP AP












ICD

PCD

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med






ICD

PCD

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]





ICD

PCD

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs




ICD vs PCD

ICDPCD

0

2

4

6

8

10

12

14

16

Aver

age d

ownl

oad

spee

d [M

bps]

30 40 50 6 0 70 80 20 CNs






Data Availability




Acknowledgments


References






















































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



TASK DISTRIBU-

TION



TASKRECEPTION
















TASKRECEPTION







119877119878119860119879119862119873119894=119875119900119904119894119905119894119900119899

119862119873119894

119860119881119878119901119890119890119889119862119873119894

(1)


119862119873119894




)

119888ℎ119906119899119896119904119862119873119894=119861119882119862119873119894sdot 119877119878119860119879

119862119873119894

119888ℎ119906119899119896 119904119894119911119890(2)





INITIAL


COLLA-BORATION











RESOURCEREQUEST

TASKDISTRIBU-

TION

INITIAL





















start(T_GuarTime)










TASKRECEPTION


COLLA-BORATION


































AP AP

AP

AP AP












ICD

PCD

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med






ICD

PCD

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]





ICD

PCD

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs




ICD vs PCD

ICDPCD

0

2

4

6

8

10

12

14

16

Aver

age d

ownl

oad

spee

d [M

bps]

30 40 50 6 0 70 80 20 CNs






Data Availability




Acknowledgments


References






















































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



INITIAL


COLLA-BORATION











RESOURCEREQUEST

TASKDISTRIBU-

TION

INITIAL





















start(T_GuarTime)










TASKRECEPTION


COLLA-BORATION


































AP AP

AP

AP AP












ICD

PCD

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med






ICD

PCD

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]





ICD

PCD

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs




ICD vs PCD

ICDPCD

0

2

4

6

8

10

12

14

16

Aver

age d

ownl

oad

spee

d [M

bps]

30 40 50 6 0 70 80 20 CNs






Data Availability




Acknowledgments


References






















































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



















AP AP

AP

AP AP












ICD

PCD

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

0

5

10

15

20

Num

ber o

f ave

rage

dow

nloa

ds m

ade

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med






ICD

PCD

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]





ICD

PCD

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs




ICD vs PCD

ICDPCD

0

2

4

6

8

10

12

14

16

Aver

age d

ownl

oad

spee

d [M

bps]

30 40 50 6 0 70 80 20 CNs






Data Availability




Acknowledgments


References






















































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



ICD

PCD

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

0

5

10

15

20

25

30

Aver

age n

umbe

r of a

ugm

enta

tion

requ

ests

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs






ICD

PCD

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

0

5

10

15

20

25

Aver

age n

umbe

r of s

pora

dic c

loud

s for

med






ICD

PCD

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]





ICD

PCD

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs




ICD vs PCD

ICDPCD

0

2

4

6

8

10

12

14

16

Aver

age d

ownl

oad

spee

d [M

bps]

30 40 50 6 0 70 80 20 CNs






Data Availability




Acknowledgments


References






















































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



ICD

PCD

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]

30 40 50 60 70 80 20 CNs

30 40 50 60 70 80 20 CNs

3 4 5 6 7 8 9

10 11 12

Aver

age d

ownl

oad

time [

s]





ICD

PCD

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs

0

125

25

375

5

625

Net

wor

king

ove

rhea

d [K

B]

30 40 50 60 70 80 20 CNs




ICD vs PCD

ICDPCD

0

2

4

6

8

10

12

14

16

Aver

age d

ownl

oad

spee

d [M

bps]

30 40 50 6 0 70 80 20 CNs






Data Availability




Acknowledgments


References






















































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia



ICD vs PCD

ICDPCD

0

2

4

6

8

10

12

14

16

Aver

age d

ownl

oad

spee

d [M

bps]

30 40 50 6 0 70 80 20 CNs






Data Availability




Acknowledgments


References






















































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia















































RoboticsJournal of




VLSI Design



Shock and Vibration







Journal of



Volume 2018



Volume 2018


Journal of




SensorsJournal of



RotatingMachinery





Propagation






Hindawi


Advances in

Multimedia


sporadic cloud-based mobile augmentation on the top of a virtualization layer: a case...

Documents