IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL ......Content may change prior to final publication....

0018-9545 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. Seehttp://www.ieee.org/publications_standards/publications/rights/index.html for more information.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI10.1109/TVT.2015.2480711, IEEE Transactions on Vehicular Technology

IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. X, NO. X, XXXXXXX 2015 1

On-Road Caching Assistance for UbiquitousVehicle-Based Information Services

Sherin Abdelhamid, Member, IEEE, Hossam S. Hassanein, Member, IEEE, and Glen Takahara, Member, IEEE

Abstract—Smart vehicles are considered major providers ofubiquitous information services. In this paper, we proposea solution for expedited and cost-effective access to vehicularpublic sensing services. The proposed caching-assisted datadelivery (CADD) scheme applies caching on the delivery pathof the collected data. Cached information can be used for laterinterests without having to request similar data from vehicles. Forthe operation of CADD, we introduce a light-weight road cachingspot (RCS) to work as an on-road caching and forwardingassistant. CADD utilizes these caching spots along with vehicleson roads for handling the data collection and delivery processes.The proposed scheme involves a novel caching mechanism thatutilizes real-time information for selecting the caching RCSswhile considering popularity in cache replacement. A data chunkto be replaced may be forwarded to another less-loaded RCS.CADD considers vehicles’ headings to direct communicationtowards the destination. Mathematical analysis and simulation-based evaluation of the scheme are conducted. The evaluationresults show significant improvements achieved by CADD in theaccess cost, delivery delay, and packet delivery ratio comparedto other schemes that do not involve caching-assistance and donot take vehicles’ headings into consideration.

Index Terms—Vehicular resources, Data delivery, Caching,Content popularity.

I. INTRODUCTION

SMART vehicles with their abundant on-board resourcessuch as the sensing, computing, data storage, and relaying

resources are promising solutions for providing ubiquitousinformation services [1]. These services are not only confinedto other vehicles on the road but also to remote third parties.Vehicle-based services have broad potential for enhancingthe public sensing domain [2]. A vehicle on the road canbe considered a mobile sensor collecting data on the go,processing such data, and sharing it with others for supportinga wide range of information services [3]. Examples of suchservices include reporting road and weather conditions tointerested authorities, reporting how crowded it is near pointsof interest, monitoring medium/long-lasting events on the road(e.g., fires), and reporting pollution and noise levels. Thesesupported services can benefit a wide scope of consumersthat include municipalities, governmental authorities, news andweather centers, end users, and other vehicles.

Copyright (c) 2015 IEEE. Personal use of this material is permitted.However, permission to use this material for any other purposes must beobtained from the IEEE by sending a request to [email protected].

S. Abdelhamid is with the School of Computing, Queen’s University,Kingston, ON, K7L2N8 CANADA e-mail: ([email protected]).

H. S. Hassanein is with the School of Computing, Queen’s University,Kingston, ON, K7L2N8 CANADA e-mail: ([email protected]).

G. Takahara is with the Department of Mathematics and Statistics,Queen’s University, Kingston, ON, K7L2N8 CANADA e-mail: ([email protected]).

Utilizing vehicular resources for providing sensing-basedservices faces two major concerns. The resource owners needto get rewarded each time their resources are accessed whichbrings forward an access cost challenge. Also, when data isneeded from a specific area of interest, a sensing requestneeds to be forwarded towards that area which imposes anaccess delay challenge. In this paper, we present a solution thathandles the aforementioned access concerns through applyingcaching on the delivery path of the service data (i.e., cachingthe collected sensing data needed for providing the service).

We propose a caching-assisted data delivery (CADD)scheme that depends on utilizing caching spots deployedon the road for assisting in collecting vehicular data andproviding vehicle-based information services. Our argumentis that caching of collected data somewhere on the road helpsin resolving later interests in similar data without having toaccess vehicular resources again. In addition, bringing the dataof interest closer to the requesters through caching aids inreducing the access delay.

For achieving the targeted functionality of the pro-posed scheme, three design elements need to be addressed:1) where caching can be applied on roads, 2) which cachingmechanism to be used to cope with the dynamic nature of thevehicular network generating the data, and 3) how to achieveoptimized forwarding of the interest and reply packets.

Some data delivery schemes that utilize assistance fromroadside entities are available in the literature. These schemesdepend on utilizing powerful RSUs for forwarding assistancewithout caching consideration. These RSUs can be adjustedand utilized for supporting the proposed caching concept;however, the cost of ubiquitous deployment will be high sincethe off-the-shelf RSU models available are not inexpensive.As a solution, we propose the use of a simple, light-weightdevice that can complement RSUs when ubiquitous RSUdeployments are not feasible. Our proposed road cachingspot (RCS) consists of an 802.11p radio for communicationwhich comes with an embedded processor, a memory chipfor caching, and a power port. Having only the componentsneeded for forwarding and caching assistance, our proposedRCS is lower-priced than an RSU.

As a default caching mechanism in caching-assistedschemes, ubiquitous caching is used for caching every contenteverywhere. Apparently, this mechanism is not efficient andother caching mechanisms are proposed to solve its ineffi-ciency [4]. One approach gaining popularity is the centrality-based caching approach [5] which aims at finding a subset ofcaching nodes that are the most central nodes in the networkand directing caching to these nodes as these are the spotsthat are more likely to get many interests passing by, and




hence more cache hits. The most central nodes in a networkare usually determined based on the locations of the nodes inthe network graph such that those that can be encounteredthe most on the set of shortest paths between all pairs ofnodes in the network are claimed to be the most central.Unfortunately, most of the caching mechanisms utilizing thecentrality-based approach use such static computations for thecentrality values as they target networks with static topologiessuch as the Internet backbone. As a vehicular network isdynamic in nature, we propose a dynamic centrality-basedcaching mechanism as part of the proposed CADD scheme.The proposed mechanism considers data popularity in cachereplacement, favoring data types with more interests from endusers. A popular data type with more generated interests thanother types is preferred to stay longer in the caching entitiesfor the sake of increasing the chance of cache hits. As well, incache replacement, the proposed mechanism works on givingthe to-be-replaced data chunk another caching opportunityinstead of dropping it as commonly followed by other cachingmechanisms.

For optimized forwarding of the interest and reply packets,the proposed data delivery scheme is heading-aware in thesense that vehicles carrying packets to be forwarded checkat intersections whether they are heading towards the packetdestination or not. If a vehicle finds that it is heading awayfrom the destination and it has no potential neighboringvehicle to forward the carried packet to, it seeks forwardingassistance from the neighboring RCS by offloading the packetto that RCS giving it a better delivery chance. The proposedCADD scheme inherits this heading-awareness feature fromour previously-proposed infrastructure-assisted data delivery(IADD) scheme [6]. Taking vehicles’ headings into consider-ation improves the data delivery ratio and lowers the deliverydelay through saving the carried packets from going away fromtheir destinations.

Our contributions are summarized as follows:

• Proposing the caching-assisted data delivery (CADD)scheme aiming at reducing the access cost of vehicularresources and expediting the access time. To the best ofour knowledge, CADD is the first data delivery schemethat considers caching-assistance from roadside entitiesto support location-based vehicular information services.

• Introducing the road caching spot (RCS) as a cost-effective assistant to the highly-priced RSUs.

• Proposing a decentralized, dynamic, centrality-basedcaching mechanism with data popularity in cache replace-ment for favoring highly-interested data.

• Improving the commonly used cache replacement con-cept through considering re-caching a replaced datachunk at another caching spot instead of dropping it.

We mathematically analyze the performance of the pro-posed CADD scheme in terms of its delay and access costthrough introduced assessment models and a comparison toanother scheme. First, we introduce a mathematical model toanalyze and compare CADD to a scheme with inter-connectedRSUs. The assessment results show that the access delay ofthe connected RSU scheme falls between those of the best

and worst cases of CADD, while its access cost is the sameas CADD in its worst case. Second, we present another math-ematical model to compute the estimated delay to reach anarea of interest (AoI) from a considered gateway providing ameans for analyzing and assessing the scheme performance ina considered region. In addition to the mathematical analysis,we evaluate the performance of the proposed CADD schemeusing the NS-3 simulator and compare it to the popular store-carry-forward (SCF) mechanism with no roadside assistance.Simulation results show that CADD achieves significant im-provements in the access cost, delay, and delivery ratio.1

The remainder of this paper is organized as follows. InSection II, we discuss some related work on roadside-assisteddata delivery for vehicular ad-hoc networks (VANETs), vehic-ular data gathering schemes, and data caching. We present theproposed CADD scheme in Section III including the cachingmechanism. In Section IV, we mathematically analyze theperformance of the scheme through introduced assessmentmodels. In Section V, we present simulation-based perfor-mance evaluation of the CADD scheme comparing it tothe SCF scheme. We highlight some practical considerationsrelated to the operation of the proposed scheme in Section VI.Finally, we conclude the paper and present our future work inSection VII.

II. RELATED WORK

A. Roadside-assisted Data Delivery for VANETs

Among the various VANET data delivery schemes avail-able in the literature [8] [9] [10], some are proposed withroadside-assistance to enhance the forwarding performance.All these schemes utilize assistance from RSUs deployed atintersections. Some of these schemes depend mainly on multi-hop communication through vehicles for forwarding [6] [11],and others assume that RSUs are inter-connected through theInternet and utilize that for delay-critical forwarding [12] [13].An example of the former category is our IADD scheme[6] that seeks RSU forwarding assistance in handling caseswhen the data carrying vehicles are going away from theintended destination for the sake of improving both the datadelivery ratio and delivery delay. Another example is theStatic-Node Assisted Adaptive routing protocol (SADV) [11]that utilizes RSUs at intersections for reducing the deliverydelay. In SADV, a data packet can be stored at an RSU tilla forwarding vehicle is encountered on the best delivery pathfor expedited forwarding. An example of the latter categoryis the Infrastructure-Assisted Geo-Routing scheme [12] thatutilizes inter-connectivity of RSUs for improved end-to-endperformance through reducing the number of hops and, hence,the delivery delay. Another example is the Infrastructure-Assisted Routing scheme proposed in [13] that follows thesame concept proposed in [12] with the focus being on theRSUs buffer allocation and management challenges.

Although the aforementioned schemes succeed in achievingperformance improvements, they build on an assumption of

1A simplified version of the work presented in this paper was introduced inour previous work in [7]. The work in [7] does not include the mathematicalanalysis section and has preliminary simulation results.




having an RSU deployed at each intersection. As mentionedearlier, the RSU models available on the market are quitepricey and, therefore, do not readily support such ubiquitousdeployments. In addition, the assistance sought from RSUsin these schemes is only for forwarding purposes withoutcaching considerations. Our proposed CADD scheme tacklesthese limitations through the introduction of the lower-pricedRCS and using it for both forwarding and caching assistance.

B. Vehicle-based Data Gathering

Some platforms and schemes are proposed in the literatureto utilize the resources of vehicles for gathering on-road dataon-demand and handling interest and reply dissemination.The Vehicular Information Transport Protocol (VITP) [14]is proposed for the retrieval of vehicular information overVANETs through directing queries to areas of interest andretrieving resolved replies with both query and reply dissem-ination being handled by intermediate vehicles via multi-hopcommunication. VITP is only responsible for specifying thesyntax and semantics of messages carrying location-dependentqueries and replies between the nodes of a VANET. It worksindependently of the underlying VANET transmission androuting protocols.

Unlike VITP, the Delay-Bounded Vehicular Data Gathering(DB-VDG) solution [15] supports geographical vehicle-baseddata gathering services with taking into consideration therouting of query and reply messages. DB-VDG depends onvehicles as mobile sensors and data relays, and on a fixedbase station to create queries and collect replies back. Basedon a delay-bound, vehicles in DB-VDG decide on eitherforwarding the packets immediately or carrying them whilemoving aiming at reducing the communication overhead andaggregating data from multiple sources.

Although the aforementioned solutions share with the pro-posed CADD scheme its basic target of accessing the vehicularsensing resources, they include very simplistic data gatheringmechanisms that do not take the access cost into consideration.

C. Data Caching

Different data caching mechanisms have been proposedin the literature to handle, for instance, the web caching[16] and information-centric network (ICN) caching [4] com-ponents. Examples of such mechanisms include the ubiq-uitous, probabilistic, and centrality-based caching. Amongthe aforementioned mechanisms, centrality-based cachinghas proven to be highly efficient in terms of cachehits with reasonable storage requirements [5]. Unfortu-nately, the centrality-based caching mechanisms proposedin the literature are designed for use in networks withstatic topologies, mainly the Internet. For example, the be-tweenness centrality-based caching mechanism [5] computesa node’s centrality value as the the number of times thatnode lies in the set of shortest paths between all pairs ofnodes in the network, with the argument that if a nodelies in many delivery paths, it is more likely to experiencea cache hit. Apparently, this approach cannot be applieddirectly to a dynamic network such as a VANET. Therefore,

there is a need for a mechanism that utilizes this centrality-based concept with support for highly dynamic networks.

In the area of caching in VANETs, a few schemes areproposed in the literature that utilize the caching conceptconsidering the mobile vehicles themselves to be the cachingentities. In [17], the authors extend the location-aware VITPprotocol [14] to enable in-vehicle caching. The caching-enabled VITP allows the intermediate nodes to cache thereplies on their way to the requesting nodes. While propagatingthe queries to the areas of interest, the VITP-enabled nodescheck their local cache for the possibility of cache hits. If amatching replica is not found locally, the query is forwarded toa neighboring vehicle. The authors use the Time-to-Live (TTL)value of the messages as the metric for cache replacementand management. A message is removed from the cacheonce its TTL reaches a pre-defined value. Another exampleis the CRoWN framework [18] that brings the content-centricnetworking (CCN) concept [19] to the vehicular environ-ment implemented on top of the IEEE 802.11p standard. InCRoWN, communications are driven by the contents insteadof host addresses while exploiting in-network caching andreplication to achieve fast content retrieval. Although theseschemes have achieved performance improvements comparedto their counterparts that do not consider caching, with the verydynamic nature of VANETs, caching replicas on mobile nodesthat can be reached fortuitously limits the opportunities ofcache hits. In addition, with the large-scale nature of VANETs,finding a vehicle with a replica of interest requires queryinga huge number of vehicles. Thus, a solution that utilizesstatic nodes for on-road caching is much more desirable toincrease the opportunities of cache hits and minimize theinterest dissemination overhead.

III. CACHING-ASSISTED DATA DELIVERY (CADD)

One of the main goals of the proposed CADD scheme is tominimize the cost of accessing the vehicular resources throughdeploying road caching spots, one at each intersection, that cancache previously asked-for data for satisfying later interests.The second goal is to reduce the roundtrip delay of the interest-reply cycle through utilizing the caching concept for bringingdata closer to requesters and introducing cache hits on theinterest dissemination path. In order to achieve these goals,the CADD scheme depends on the caching and forwardingcapabilities of the deployed RCSs and vehicles on the roadthat work as carriers of both interests and replies.

As the caching concept is a main part of our proposedscheme, we introduce the RCS that works as our caching anddelivery-assistant to be deployed at each intersection. An RCShas only the components necessary for forwarding and cachingtherefore it is less expensive than the regular RSU models onthe market. Details about the RCS structure and deploymentare presented in Section VI-A.

Since our CADD scheme aims at providing vehicle-assistedinformation services to remote end users, a connection needsto be established between those end users and the vehicularnetwork in order to be able to inject the service requests andget the data replies. As part of our system, we deploy gateway




entities to work as the points of attachment (PoA) of end usersto the vehicular network. A single gateway will be deployed ateach area of a city/deployment region which will be dividedinto main non-overlapping areas. An end user interested ina service communicates with a gateway through the Internet.End users, in the subscription stage, select which gateway willbe their PoA based on the users’ preference and the area theywill be interested in getting services from more often.

In addition to the caching-assisted feature of the proposedCADD scheme, another main feature is being heading-aware.CADD builds on the heading-awareness concept of our previ-ously proposed IADD scheme [6] which considers vehicles’headings for the goals of improving the data delivery ratio andend-to-end delay.

In the next subsections, we discuss the general operation ofCADD through an illustrating scenario, then we describe thedetailed operations of the three main entities involved in thescheme; a vehicle on the road, an RCS at an intersection, anda gateway.

Table I summarizes the list of notations to be used through-out the paper.

A. CADD General OperationThe service acquisition process starts with an end user

sending a request to the designated gateway which formulatesa corresponding interest, then injects it into the vehicularnetwork. The interest is disseminated in the network throughvehicles and RCSs towards the AoI defined in the interestpacket. While passing by RCSs in its path, the interest ischecked at each passed-by RCS for a cached match (a cachehit). Unless a cache hit happens, the interest is forwardedtowards the AoI using heading-aware geographical forwardingas detailed later in this section.

Once the interest reaches a vehicle in the AoI, this vehiclegenerates a data reply packet resolving the interest parameters.On the way back to the requesting gateway, the reply iscached at the RCS with the maximum centrality among allthe RCSs in the interest-followed path. Details about theproposed centrality-based caching mechanism are discussedin subsection III-C5. With caching the collected data on thereply delivery path, the scheme brings chances for cache hitsto be encountered by subsequent interests in the same data.

While propagating the interest and reply packets, thedata carrying vehicles keep checking their headings at anyapproached intersection. If it happens that a vehicle does notfind a neighboring vehicle as a potential forwarder, it keepscarrying the packet if it finds that it is going towards thepacket’s destination, otherwise, it leaves the packet at theneighboring RCS to give it a chance for a better forwardingopportunity towards its destination which means a higherdelivery probability for that packet.

All vehicles and RCSs exchange periodic beacon packetscarrying their IDs, positions, and velocities (for vehicles) toannounce their presence. Such beacons are used for neighbordiscovery needed by the geographical forwarding procedure.

The scenario illustrated in Figure 1 shows the benefitsof caching-assistance in reducing access to the vehicularresources, implying reducing the service access cost, and

TABLE ILIST OF NOTATIONS

List of NotationsGeneral Notations

r Interest packetp Reply packetp′ Packet with the lowest popularity in cachev Forwarding vehicles Road segmentGy Gateway with ID yRCSl Road caching spot with ID l

RCSmaxRoad caching spot with maximum centrality on an interestforwarding path

RCS2maxRoad caching spot with second maximum centrality on aninterest forwarding path

Ak Area of interest with ID kN Neighborhood list of a node (either a vehicle or an RCS)ρa Density assessment periodρc Centrality periodρp Popularity periodρr Interest generation period

For Mathematical ModelingNI Total number of generated interestsNS Number of segments

cCost of getting a single reply through accessing vehicularresources

τ Propagation delay over a road segmentADensl Average density of RCSl’s incoming road segmentsADGl Average distance between RCSl and the gatewaysSy→k

Set of RCSs on the full path from gateway Gy to area Ak

Pl Set of interest paths going through RCSlRS Cache size of an RCSPcacher Probability of cache hit for interest rPcmaxr Probability of cache hit at RCSmax of interest rPc2maxr Probability of cache hit at RCS2max of interest rDP lr p Degree of popularity of interest path r p ∈ PlDmax Distance from gateway Gy to RCSmax

y→kD2max Distance from gateway Gy to RCS2max

y→kDAk

Distance from gateway Gy to area AkDCl Degree of centrality of RCSlCTh Caching threshold for cache probability

minimizing the data retrieval delay. In Figure 1(a), requesterK needs information about an event in the area of interest A.Since he has registered to gateway G2, his request goes to itthrough the Internet. G2 generates a corresponding interest, rk,and sends it to the closest neighboring vehicle. The carryingvehicles follow the CADD heading-aware forwarding proce-dure detailed later to get the interest towards A resulting in theforwarding path shown in Figure 1(a). During the forwardingprocess, the RCSs that are passed by the interest packetcheck the availability of a matching reply in their caches. Inaddition, they store information in the interest header aboutthe maximum central and second maximum central RCSs tobe used for the caching purposes. In the case shown, no matchhas been encountered so the interest went to A.

In Figure 1(b), rk is received by a vehicle S in A. Sgenerates a reply packet, pk, with corresponding data matchingthe parameters of rk, and caching-related fields matching thosecarried in rk. S follows the CADD forwarding procedure tosend pk back to G2 resulting in the path shown in Figure1(b). At each intersection, the carrying vehicle of pk checks ifthe neighboring RCS is the one with the maximum centralitystored in the packet header. In the illustrated scenario, it




G4G3

G1 G2

R3R2

R6

R10

R5

R9

R1 R4

R7 R8

R11 R12

Interest Forwarding Path

AS

Requester K

(a)

G4G3

G1 G2

Reply Forwarding Path

S

Reply is cached at RCS11

Requester K

A

R3R2

R6

R10

R5

R9

R1 R4

R7 R8

R11 R12

(b)

G4G3

G1 G2

Reply Forwarding PathInterest Forwarding Path

Replica is found at RCS11

A

Requester J

R3R2

R6

R10

R5

R9

R1 R4

R7 R8

R11 R12

(c)

Fig. 1. An illustrating scenario showing the benefit of caching on the service data delivery path. Requester K needs information aboutan event in area A. He sends a request to G2 that generates an interest following the path shown in part (a). A reply is generated by vehicle S in Aand sent back to G2 following the path shown in part (b) with a replica cached at RCS11. A moment later, requester J asks for similar data from A. Hisinterest meets the cached replica at RCS11 resulting in the shortened interest and reply paths shown in part (c).

happened that RCS11 was the maximum central node on theinterest path and, therefore, it is where a replica of pk is cachedon the way back. Note that an RCS at an intersection x isabbreviated as Rx in the figure for simplicity.

A moment later, a requester J , registered with gateway G1,gets interested in information similar to that requested by re-quester K. G1 generates a corresponding interest rj and sendsit towards A through the vehicular network. As rj is checkedat the passed-by RCSs for a matching reply, it happens that ithits the replica of pk cached in RCS11. Since pk matches theparameters of rj , a replica of it is forwarded to G1. In thiscase, rj is kept from going all the way towards A minimizingthe roundtrip access delay. Since the reply sent to J wasa replica of a previously-generated data packet, no access forvehicular sensing resources was required saving the cost thatwould have been incurred if caching was not considered. Theinterest and reply paths of this case are shown in Figure 1(c).

B. CADD at a Vehicle on the Road

In CADD, vehicles work as the main carriers for bothinterest and reply packets. We detail the forwarding logicfollowed by a vehicle in Algorithm 1 for both forwarding aninterest (lines 9-24) and forwarding a reply (lines 27-51). On aroad, a vehicle can be in one of two modes: a segment modeor an intersection mode. In the segment mode, a vehicle ismoving on a road segment and not close to any intersectionswhile in the intersection mode, a vehicle is approaching anintersection and hence, has the opportunity of getting RCSassistance. We discuss the detailed forwarding logic below.

1) Interest Forwarding:When a vehicle gets an interest packet which is not expired yet,it checks if it is in the defined AoI. If so, it generates a replypacket, sets the corresponding caching values in the headerwhich it retrieves from the interest header, and triggers the re-ply forwarding procedure (lines 11-13). Otherwise, the vehiclechecks its current mode of operation to start forwarding theinterest. If it is in the segment mode (lines 17-21), it anchorsthe packet towards the next RCS (RCSnext) through the use of

greedy forwarding. It checks its neighboring vehicles to findthe one closest to RCSnext and if this potential forwarderis closer to RCSnext than the vehicle itself, it forwards thepacket to it, otherwise, it keeps holding the packet until a betterforwarder is encountered or it approaches RCSnext.

When a vehicle gets a beacon from an approached RCS,it activates the intersection mode of forwarding (lines 15 &16). The carrying vehicle sends the interest to RCScur whichchecks the possibility for a cache hit, if it has a matching replyin its cache, or continues the forwarding process towards theAoI, otherwise.

2) Reply Forwarding:The reply forwarding procedure gets called when a vehiclegenerates a reply packet itself (if it gets an interest while it isin the corresponding AoI), or receives a generated one to beforwarded. If the vehicle is in the segment mode, it forwardsthe packet towards RCSnext the same way defined above inthe interest forwarding (lines 46-50). If it is in the intersectionmode, it goes through many check points as follows.(a) The vehicle checks if it has a candidate neighbor for

forwarding the packet. The beacon packet sent fromRCScur carries the RCS’s real-time assessment of thedensities of its linked road segments. The density of a roadsegment s assessed by an RCS is defined as the numberof beacons heard by that RCS from vehicles on s duringan assessment period (ρa):

density(s) = no. of received beaconss |t+ρat (1)

where t is the start time of the current period. The vehicleuses the received densities for prioritizing the neigh-boring segments through computing a weighted priority(wpriority) for each segment as follows

wpriority(s) = α× density(s) + β × dpriority(s) (2)

where dpriority(s) is the priority of road segment s interms of its direction towards the packet destination. Theparameters α and β are tunable weights with α+ β = 1.The vehicle uses the prioritized segment list for finding itsnext-hop forwarder. It checks the availability of neighbor-ing vehicles on the segments in a prioritized order and if




Algorithm 1 : CADD at a Vehicle1: Input:2: Forwarding vehicle v3: Interest packet r4: Reply packet p5: Gateway G6: Neighborhood list N7:8: forward interest(r)9: Begin

10: if r is not expired then11: if v is in the area of interest defined in r then12: generate a reply packet p and set its RCSmax and RCS2max fields as

carried in r13: forward reply(p)14: else15: if Intersection Mode = true then16: send r to RCScur

17: else //In the segment mode18: if N is empty then19: keep holding r20: else21: send r to the neighbor closest to RCSnext if it is closer than v

22: else23: drop r // r is expired24: End25:26: forward reply(p)27: Begin28: if v is a neighbor to G then29: send p to G30: else31: if Intersection Mode = true then32: prioritize neighboring segments according to the density and direction

priority33: for all segment s ∈ the prioritized segment set do34: if list of neighboring vehicles on s is not empty then35: send p to the farthest vehicle on s36: break37: if p is not relayed then38: if v is heading towards G then39: keep holding p40: else41: send p to RCScur with the forwarding flag ON

42: if RCScur = RCSmax then43: send a replica of p to RCScur with the caching flag ON44: else if v is heading away from RCSmax then45: send a replica of p to RCSmax using the same procedure of the

forward reply(p) function46: else //In the segment mode47: if N is empty then48: keep holding p49: else50: send p to the neighbor closest to RCSnext if it is closer than v

51: End

it finds any, it stops looping on the segments and selectsthe next forwarder on the segment with availability in agreedy fashion (lines 32-36).

(b) If not (a), the vehicle checks if it is going towards thepacket destination. If it is, it keeps carrying the packetuntil it finds a better forwarder (37-39). Otherwise, it sets adesignated forwarding flag in the packet to ON then sendsit to RCScur to give it a better forwarding opportunity(lines 40 & 41).

(c) The vehicle checks if RCScur is the RCS with max-imum centrality (RCSmax) stored in the header forcaching. If so, the vehicle generates a replica of the replypacket, marks its caching flag as ON , and sends it toRCScur to be cached (lines 42 & 43).

(d) If not (c), the vehicle checks if it is going far fromRCSmax so that the packet may not pass by thecaching RCS on its way. If this is the case, the carryingvehicle generates a replica of the packet, sets its destina-

tion to RCSmax, and forwards it towards RCSmax usingthe same forwarding procedure used for forwarding a reply(lines 44 & 45). The idea behind this is to maintain thecaching opportunity for that packet regardless of the pathfollowed by the original packet itself.

C. CADD at an Intersection RCS

RCSs are used mainly for caching replicas of the replypackets with the aim of resolving later relevant interests so thatthere will not be a need to access vehicular resources everytime an interest is injected into the vehicular network. They arealso used for forwarding assistance in cases when the packet-carrying vehicles are heading away from the destination. Thelogic followed by an RCS for both caching and forwarding isdetailed in Algorithm 2 and discussed in the following.

1) Receiving an Interest:When an RCS receives an interest packet from a vehicle,if this interest is not expired yet, it checks its cache fora matching replica. If it finds a match, it sends a reply back tothe requesting gateway (lines 10 & 11), otherwise, it forwardsthe interest towards the AoI using the forwarding procedurediscussed later in this section (line 17).

Before forwarding a received interest, an RCS checks itscentrality value relevant to the interest type and area, as dis-cussed later in this section, to determine if it is a candidate forthe maximum central RCS (RCSmax) or the second maximumcentral RCS (RCS2max) among the RCSs encountered onthe interest-traversed path so far (lines 13-16). In the interestheader, the ID and location of RCSmax and RCS2max isrecorded along the path and is updated by a passed-by RCSif it is a better candidate than any of the recorded ones.

2) Receiving a Reply:After receiving a reply packet by an RCS, it starts checking theforwarding and caching flags carried in the reply header. If thecaching flag is ON , the RCS calls the caching procedure forhandling both the storage and cache replacement (lines 26 &27). If the forwarding flag is ON , the RCS inserts the packetinto the forwarding queue to be forwarded as discussed below(lines 24 & 25).

3) Forwarding a Packet:The packet forwarding procedure is called by an RCS whenit has to forward either an interest or a reply packet.An RCS’s forwarding logic has similarities with the one usedby a vehicle for forwarding a reply. When a packet needs tobe forwarded, the carrying RCS uses Eq. 2 for computing aweighted priority for all of its linked segments based on thedensity and direction criteria as discussed earlier. Afterwards,the RCS searches for a neighboring vehicle on these roadsegments in the order of their weighted priorities (lines 32& 33). If neighbors are found on a segment while searching,the RCS sends the packet to the farthest vehicle on thatsegment (lines 34-36). If no potential forwarder is encountered,the RCS keeps carrying the packet and marks it to be re-transmitted (lines 37 & 38).

4) Caching a Reply:When an RCS receives a reply packet to be cached, it checksthe availability of a vacant spot in its cache; if there is any,it caches the packet right away (lines 43 & 44). If the RCS’s




cache is full, it considers replacing a previously cached packet,(lines 45-51), as discussed below.

One of the main contributions of this paper is the pro-posed cache replacement mechanism which, compared to othercaching mechanisms that drop the replaced packet, gives thispacket another caching chance to stay longer in the networkand increase the chances for a cache hit. In contrast to manycaching mechanisms that consider picking the to-be-replacedpacket using the Least Recently Used (LRU) policy whileignoring the popularity of the different packets, our replace-ment mechanism considers this popularity criterion in pickingthe replacement candidate. Considering popularity favors thepackets with more interests from end users which enhances thequality of service (QoS) and increases the chance of cache hits.

When a replacement needs to be considered, the RCS withthe full cache picks the least popular packet among thosestored in its cache (line 46). Details about popularity com-putation are discussed later in this part. When it happens thatan RCS finds many packets with the same lowest popularityvalue, it picks the LRU one among those of equal popularity.Then, the RCS compares the popularity of the candidate packet(p′) to the to-be-cached packet (p). The one with the higherpopularity will be the caching winner and the other one willbe given another caching chance. Each reply packet carriesin its header information about the second maximum RCS(RCS2max) encountered on the interest path and this is wherethe other caching chance will be targeted. The packet with thelower popularity between p′ and p will be offloaded to theRCS2max recorded in its header using the same forwardingprocedure (lines 47-51). A packet is kept in an RCS’s cacheuntil the packet expires or gets replaced.

5) Centrality Computation:Another main contribution in this paper is our dynamic,decentralized mechanism for computing the centrality of theRCSs. These centrality values are used for caching purposesthrough directing a reply replica to the maximum central nodeencountered on the interest forwarding path. A replaced replicais directed to the second maximum central node encounteredon its interest path, as discussed earlier.

Among the different caching mechanisms proposed in theliterature, we build on the centrality-based caching mechanismdue to its demonstrated ability to achieve high levels of cachehits with less overhead compared to many other mechanisms[5]. The concept of centrality-based caching aims at directingcaching to the nodes that are most central in the networkas they are more likely to get many interests passing byand hence, more cache hits. Unlike the static centrality-basedcaching mechanisms that compute the centrality value of anode based on its position in the static network topology, ourproposed mechanism handles the computation in a dynamicway based on the number of interests received by a node suchthat the more interests a node receives, the more central it is inthe network and the more likely it will get upcoming interests.

In CADD, all the potential interests are classified into maintypes (e.g., traffic conditions, road conditions, and crowd).Each RCS maintains an Interest Type Area table that liststhese pre-defined interest types each associated with the differ-ent pre-defined main areas of the whole region in (type, area)

Algorithm 2 : CADD at an RCS1: Input:2: Interest packet r3: Reply packet p4: Gateway G5: Neighborhood list N6:7: interest received(r)8: Begin9: if r is not expired then

10: if there is p matching r in Cache then11: forward p to G by calling forward packet(p)12: else13: if centrr (tp,a) of the RCS > centr of RCSmax then14: update RCSmax, RCS2max, and their stored locations15: else if centrr (tp,a) of the RCS > centr of RCS2max then16: update RCS2max and its stored location17: forward packet(r)18: else19: drop r // r is expired20: End21:22: reply received(p)23: Begin24: if the packet’s forwarding flag is set to ON then25: forward packet(p)26: if the packet’s caching flag is set to ON then27: cache reply(p)28: End29:30: forward packet(k) // k can be a reply packet or an interest packet31: Begin32: prioritize neighboring segments according to the density and direction priority33: for all segment s ∈ the prioritized segment set do34: if list of neighboring vehicles on s is not empty then35: send k to the farthest vehicle on s36: break37: if a forwarder is not found then38: keep holding k to be re-transmitted39: End40:41: cache reply(p)42: Begin43: if Cache is not full then44: store p in Cache45: else //Cache is full, consider replacement46: p′ ← the packet with the lowest popularity in Cache47: if p.pop < p′.pop then48: forward p to p.RCS2max

49: else50: forward p′ to p′.RCS2max

51: store p in Cache52: End53:54: //The following two functions will be called periodically upon the firing

of corresponding timers.55: calculate centrality() //as in Eq. 356: calculate popularity() //as in Eq. 4

2-tuples. The RCS computes its centrality for each tuple anduses it when it receives an interest of that tuple for checkingits candidacy to be the RCSmax or the RCS2max on thatinterest forwarding path.

As shown in Eq. 3, an RCS’s centrality of a specific tupleis computed as the number of interests of that type towardsthat area received during a pre-defined centrality period (ρc).

centralityr (type,area) = no. of interestr (type,area) |t+ρct (3)

6) Popularity Computation:Using a similar dynamic mechanism to the one used forcomputing the centrality, an RCS computes a popularity valuefor all of the different packets it carries in its cache asthe popularity of its corresponding interest tuple. A tuplepopularity is computed as the number of interests of that type




towards that area received during a popularity period ρp, asshown below

popularityr (type,area) = no. of interestr (type,area) |t+ρpt (4)

The RCS uses the computed popularity for picking thecaching replacement candidate as discussed before.

D. CADD at a Gateway

In CADD, a gateway is used as the PoA of the requestersto the vehicular network. Its main job in the scheme isinjecting the service requests into the network and waitingfor the replies, which is presented in Algorithm 3 through therequest data procedure. When a gateway receives a servicerequest through the Internet, it generates an interest packetwith the corresponding parameters defined in the requestincluding the interest type, AoI, and the expiry times of theinterest and its requested reply. Before injecting the interestinto the network, the gateway initializes the caching-relatedfields of the interest header: the centrality, IDs and locations ofRCSmax and RCS2max. Then, it sends the generated interestto its closest neighbor of the vehicular network. A gatewaykeeps track of all the interests it sent until it gets matchingreplies or the interests expire. Once a gateway receives a replymatching with a stored interest, it sends this reply back to therequester through the Internet.

IV. MATHEMATICAL ANALYSIS OF THE PROPOSED CADDSCHEME

In this section, we analyze the delay and access cost of theproposed CADD scheme through mathematical modeling andassessment.

A. CADD and Connected RSUs

In this part, we present a mathematical model to analyzeand compare CADD to a scheme utilizing RSUs with inter-connection (CRSU). We consider an m×n grid topology withan RSU deployed at each corner working as a gateway forboth schemes. In CRSU, the four RSUs can communicate withone another through the Internet such that they can move theinterests and replies closer to their destinations through theirbackhaul connection. For CADD, an RCS is deployed at eachintersection point of the grid.

In assessing the performance of CADD, we consider itsbest case (CADDB) when a cache hit is encountered at thenext intersection RCS, and its worst case (CADDW ) when nocache hits happen on the interest path so the interest has to be

Algorithm 3 : CADD at a Gateway1: Input:2: Neighborhood list N3:4: request data()5: Begin6: generate interest r with the corresponding parameters7: initialize the centrality-related caching fields of the header8: send r to the nearest neighbor in N9: keep track of r till either getting a reply or it expires

10: End

resolved by a vehicle at the AoI.In our assessment scenario, we consider each segment on

the grid as a possible AoI with one interest generated to it byan RSU/gateway. In an m × n grid, the number of segments(NS), which equals to the total number of generated interests(NI), is computed as: NS = NI = 2mn−m− n.

As a first assessment metric, we consider the total cost(TCost) incurred by each scheme for getting a reply to eachof the NI interests. Assume the cost of getting a single replythrough accessing vehicular resources is c. In both CADDW

and CRSU each interest is resolved by a vehicle in the AoI, sotheir TCost is equal to NI × c. For CADDB , as all interestsare resolved through cache hits, its TCost is equal to 0.

As a second metric, we compute the average delay(ADelay) of reaching all the segments from the requestingRSU. We assume that the propagation delay over a roadsegment is τ and is the same for all segments. Since inCADDB a cache hit is encountered at the next intersection(one segment away), the delay of getting a reply targetingany segment is equal to τ , except for the two segmentsdirectly linked to the requesting gateway where the delay is0. Consequently, the ADelay of CADDB is computed as

ADelay(CADDB) = (NI − 2)× τ/NI (5)

For CADDW , the delay of reaching an AoI/segment startingat point (i, j) on the grid and the average delay can becomputed as in Eqs. 6 and 7, respectively.

Delay(CADDW )(i,j) = (i+ j) τ (6)

ADelay(CADDW ) =

[2m−2∑i=0

n−2∑j=0

(i+ j) +m−2∑i=0

(i+ n− 1) +n−2∑j=0

(j +m− 1)]τ

NI(7)

To reach an AoI starting at point (i, j) in CRSU, sincethe RSUs are connected, the delay is the minimum delay ofreaching this segment from the four RSUs, as computed inEq. 8. Eqs. 9 and 10 show the computation of the CRSUaverage delay for all different cases of the m and n values.

Delay(CRSU)(i,j) =

min[(n−1−j+i),(i+j),(m−i+n−j−2),(m−1−i+j)]× τ (8)

ADelay(CRSU) = Total Delay(CRSU) / NI (9)

Total Delay(CRSU) =W × τ, if both m&n are odd[W+X+Z]× τ, if m is even and n is odd[W+Y+Z]× τ, if m is odd and n is even[W+X+Y+(Z × 4)]× τ, if both m&n are even

(10)

where:

W =((

8×U−1∑i=0

V−1∑j=0

(i+j))+(2×( U−1∑i=0

(i+V )+V−1∑j=0

(j+U))))

,

X = 4×U−1∑i=0

(i+ V ), Y = 4×V−1∑j=0

(j + U),

Z = U + V , U = b(m− 1

2)c, V = b(n− 1

2)c




Figure 2 shows the assessment results of the CADDW ,CADDB , and CRSU in terms of the average delay computedbased on Eqs. 5, 7, and 9 with varying grid sizes and τ equal to10. The results show that in small areas (small grid sizes), theaverage delay of CADDB is almost equal to that of CRSU.In larger areas, the average delay of CRSU is significantlyhigher than the delay of CADDB and getting closer to that ofCADDW as many of the segments get farther from the cornerRSUs.

B. CADD to a specific AoI

In this part, we consider analyzing the delay to reach aspecific AoI by an interest packet initiated from a specificgateway. First, we consider this analysis under the assumptionsof having a fixed traffic density for each road with non-uniformdensity distribution for the whole set of segments (i.e., eachsegment has a fixed density which may differ from othersegments’ densities), and having a uniform popularity for allthe interest tuples. Second, we consider the analysis under thefixed non-uniform density distribution assumption with non-uniform popularity distribution for the interest tuples.

1) Analysis Considerations:We consider an m×n grid topology with a gateway deployedat each corner and an RCS deployed at each intersection pointof the grid. The delay is estimated for an interest packet goingfrom a gateway to the starting point of an AoI (road segment)on the grid. Note that the location points of the gateway, AoIreaching point, and the RCSs are mapped to points on the gridin terms of m and n.

The density of road segments, popularity of interest tuples,and locations of RCSs on the grid are known and usedas inputs to the assessment model. Based on this informa-tion, the full paths from the considered gateway (Gy s.t.y = 1, ...., no. of Gateways) to each candidate AoI (Ak s.t.k = 1, ...., no. of AoIs) are computed a priori based on theCADD forwarding procedure as a list of junction/intersectionpoints. Therefore, the set of RCSs on the full path from Gy

to Ak is known and referred to as Sy→k

.

2) Analysis Model:Case I: Non-uniform Density and Uniform Popularity:

First, based on the inputs mentioned above and the computedfull path between the considered Gy and Ak, we compute

Fig. 2. Average delay of CADD and CRSU with varying grid sizes.

the locations of RCSmax and RCS2max on that path. Foreach RCSl ∈ S

y→k, we compute a corresponding degree of

centrality DCl that indicates the candidacy of that RCS to bethe most central node. RCSmax on a path represents the nodewith the highest number of interests passing by. In case thereis more than one RCS encountering the same highest numberof interests, RCSmax is chosen to be the one closest to thegateways among those nodes with the maximum centrality.Based on this centrality notion, the DCl of RCSl is computedas below

DCl = ADensl ×1

ADGl(11)

where ADensl is the average density of RCSl’s incomingroad segments and ADGl is the average distance betweenRCSl and the gateways considering only those having RCSl

between the gateway and AoI (i.e., the gateways that mighthave RCSl on the path to the considered AoI).

According to the computed degrees of centrality, we deter-mine RCSmax

y→k∈ S

y→kand RCS2max

y→k∈ S

y→kof the path from

Gy to Ak as follows

RCSmaxy→k

←− RCSl with max(DCl)

Sy→k←− S

y→k\RCSmax

y→k

RCS2maxy→k

←− RCSl with max(DCl)

Consider the probability of having a cached replica on thepath to be Pcache = Pcmax + Pc2max, where Pcmax is theprobability of having a cached replica at RCSmax and Pc2max

is the probability of having a cached replica at RCS2max.Note that according to the scheme, a cached replica can onlybe found at either RCSmax or RCS2max, but not in both.Accordingly, the estimated distance to be traversed by aninterest r initiated through Gy and directed towards Ak canbe computed as in Eq. 12.

EDistry→k

=

[Pcmaxr×Dmax]+[Pc2maxr×D2max]+[(1−Pcacher )×DAk )](12)

where Dmax, D2max, and DAkare the distances from Gy to

the determined RCSmaxy→k

and RCS2maxy→k

, and Ak, respectively.

Note that the distances in the model are expressed in thenumber of road segments between a pair of points on anm × n grid. For example, the distance between a specificGy at point (0,n−1) and an Ak reachable through point(m−1,2) = [|m−1−0|+ |2−(n−1)|] = m−n+2 segments.

The last term in Eq. 12 represents where the requestedinterest r has not been previously requested, or was requestedand reached its expiry time before initiating the current interestpacket, as the worst case of CADD where the interest packethas to go all the way towards the AoI. The probability of acache hit, Pcacher = Pcmaxr

+ Pc2maxr, can be computed as

detailed below.We consider the popularity of the interest tuples and the

cache sizes of the RCSs for computing Pcache. Based onthe full path set computed a priori from the gateways to the




AoIs, for each RCSl, we compute the set of interest pathsgoing through it, referring to it as Pl. Accordingly, with theassumption that all interest tuples have the same popularity,Pcmaxr

and Pc2maxrof an interest r from Gy to Ak are

computed as in Eqs. 13 and 14, respectively.

Pcmaxr =1

|PRCSmaxy→k

| ×RS (13)

Pc2maxr =1

|PRCS2maxy→k

| ×RS × (1− Pcmaxr ) (14)

where RS is the cache size of an RCS. In cases where thevalues of Pcmaxr

and Pc2maxrare greater than 1 due to having

|PRCSmaxy→k

| much smaller than RS, Pcmaxrand Pc2maxr

are

assigned the probability upper bound 1.The probabilities of caching obtained through Eqs. 13 and

14 are plugged into Eq. 12 to compute EDistry→k

. Finally,

following the general assumption considered in Section IV-Aof having the propagation delay over a road segment to be τ ,we can compute the estimated delay for an interest r initiatedthrough Gy and targeting data about Ak as shown in Eq. 15.

EDelayry→k

= EDistry→k

× τ (15)

Case II: Non-uniform Density & Non-uniform Popularity:

The same model and formulation discussed under CaseI applies to this case as well except for the computationof Pcmaxr and Pc2maxr . Since non-uniform popularity isconsidered (i.e., each interest tuple may have a differentpopularity), we rank the different interest paths in Pl ofeach RCSl in ascending order according to the popularityof its corresponding interest tuple, s.t. the interest tuplewith the highest popularity gets a rank of 1. Each interestpath r p ∈ Pl is assigned a degree of popularity, DP l

r p,equivalent to its rank in Pl. Pcmaxr and Pc2maxr ofan interest r from Gy to Ak following a path r p arecomputed as in Eqs. 16 and 17, respectively.

Pcmaxr =

{1, if DP

RCSmaxy→k

r p ≤ RS0 otherwise

(16)

Pc2maxr =

0, if DPRCS2max

y→kr p > RS

or Pcmaxr is equal to 1

1 otherwise

(17)

It is worth noting that in the two cases of the analysis above,we consider the popularity values at the time of computing theestimated delay. Such values may vary at different times dueto the dynamic nature of popularity, but this does not affectthe computation at a specific time.

3) Numerical Results:Below are the results of computing the average estimateddelay for reaching data about all the segments in the m × ngrid topology, considering each segment on the grid as apossible AoI and one of the corner gateways to be the initiatorof all the interests targeting the segments. To generalize and

assess the model for different grid sizes, we adopt uniformtraffic density with uniform interest popularity for all thesegments in the grid.

Since having uniform density over the segments leads tohaving multiple potential paths between the gateway Gy andan area of interest Ak, we adopt the following strategy toform a path from Gy to Ak. Among the set of shortest pathsfrom Gy to Ak, we select the one giving priority in segmentselection in a counterclockwise fashion (e.g., considering thegateway in the top right, the selection strategy picks all thesegments to the left until reaching the same grid column ofAk, then moves down selecting all the segments on the wayuntil reaching Ak). Due to the use of uniform density aswell, the use of the ADensl parameter in Eq. 11 is relaxedleading to considering only the average distance to gateways(ADGl) in computing DCl of RCSl.

For each AoI/road segment, we generate a random valueto indicate if an interest to that AoI was requested beforeor not (i.e., there is a probability of a cache hit or not). Ifthis generated value is greater than a pre-defined threshold(CTh), it will be assumed that an interest r to that AoI willnot meet a cached replica anywhere on the grid leading tohaving Pcacher = Pcmaxr

= Pc2maxr= 0; hence, having

the estimated delay converges to that of CADDW for thatAoI. If this value is less than or equal to CTh, the values ofPcmaxr , Pc2maxr , and Pcacher are computed according to theproposed model.

We compare this model, referring to it as CADDE , toCADDW and CADDB defined in the previous part in termsof the average delay to reach all the segments in the gridfor different grid sizes. Figure 3 shows the results of thecomparison considering a cache size equals to 20, CTh

equals to 0.5, and τ equals to 10. As expected, the delayof CADDE lies between these of CADDW and CADDB .For larger grid sizes, the difference between CADDW

and CADDE is more apparent as the distances betweenthe gateway and some of the segments get longer, witha probability of not being traversed in CADDE due to thepotential cache hits.

We also assess the average delay computedby CADDE with considering different cache sizes(RS) over different grid sizes. The results in Figure 4show that with increasing the cache size, the average delay

Fig. 3. Average delay of CADDE , CADDW , and CADDB with varying gridsizes.




decreases due to increasing the values of Pcmaxrand Pc2maxr

per an interest r which decreases the corresponding EDistr,according to Eq. 12.

Finally, we assess CADDE with considering differentvalues for CTh over different grid sizes. The results in Figure5 show that with increasing CTh the delay decreases, as fewersegments would be assumed not having a cached replicaleading to lower estimated distances to more segments.

V. SIMULATION-BASED EVALUATION OF THE PROPOSEDCADD SCHEME

In this section, we evaluate the performance of theCADD scheme using simulation assessment. The perfor-mance of CADD is analyzed and compared to the non-assisted SCF scheme in which a vehicle continues to carrythe data if it does not find a potential next-hop forwardereven if the vehicle is heading away from the destination’sdirection. The two schemes are compared in terms of:1) the average round-trip access delay since an interest is sentby a gateway until its reply is received, 2) the packet deliveryratio, highlighting the benefit of the heading-awareness feature,and 3) the cache hit ratio, which is an indicator of the savedaccess cost.

A. Simulation Setup

Both CADD and SCF are implemented using theNS-3 network simulator [20]. Simulations were performedover different vehicle densities for a period of 2000 seconds

Fig. 4. Average delay of CADDE with different cache sizes over varyinggrid sizes.

Fig. 5. Average delay of CADDE with different caching probability thresh-olds over varying grid sizes.

each. We considered a grid simulation topography similarto the part of Kingston city shown in Figure 6 with onegateway deployed at each corner and a scale mapped to1km × 1km area. The interest generation is uniformly dis-tributed among the four gateways with the default injectionrate equals to 1 every 20 seconds. In generating interests, 4interest types and 4 targeted areas of interest are consideredleading to 16 different interest tuples. The SUMO (Simulationof Urban MObility) vehicular simulator [21] in conjunctionwith MOVE (MObility model generator for VEhicular net-works) [22] are used to generate realistic mobility traces. TheIEEE 802.11p WAVE standard is used for communication inthe vehicular network with the beaconing interval set to 0.5second and the transmission range set to 150 meters.

In CADD, an RCS is added at each intersection. Theparameters ρc and ρp are set to 250 seconds and the wholesimulation time (2000 seconds), respectively. The α and βweights for calculating segments’ priorities are set to 0.2and 0.8, respectively, giving a higher weight at each RCSto the segment whose direction brings a packet closer to thedestination.

We consider two different cache sizes (the maximum num-ber of cached packets at each RCS) to show the effect of thepopularity-based cache replacement. Cache sizes of 5 (CADD-5) and 20 (CADD-20) are considered. In CADD-5, only thefive most popular tuples are kept at an RCSmax while lesspopular ones are offloaded to their corresponding RCS2max,while in CADD-20, an RCS can accommodate a replica ofeach possible interest.

Table II summarizes the simulation parameters and thecorresponding values.

B. Simulation Results and Analysis

First, we compare CADD-5, CADD-20, and SCF interms of the average round-trip delay over varying vehiculardensities. As shown in Figure 7(a), CADD decreases thedelay compared to SCF. This decrease is due to: a) thecaching-assistance feature that brought the replies closerto the requesters saving the interests from having to go totheir designated AoIs, and b) the heading-awareness feature

Fig. 6. The part of Kingston city representing the simulation topography.




TABLE IISIMULATION PARAMETERS AND CONFIGURATIONS

Simulation Parameter ValueNumber of vehicles 200, 400, 600, 800, 1000Max. vehicle speed (Km/h) 40Average road segment length (m) 300Topography size 1km × 1kmBeaconing interval (sec) 0.5Transmission range (m) 150Communication technology IEEE 802.11pNumber of interest types 4Number of targeted areas of interest 4ρc (sec) 250ρp (sec) 2000ρr (sec) 20, 60α 0.2β 0.8RS 5, 20

that saved the interests and replies from going farther fromtheir destinations. Comparing CADD-5 and CADD-20, wecan notice a slight increase in the delay with reducing thecache size. Since our cache replacement mechanism gives areplaced packet another caching chance instead of droppingit, reducing the cache size has not greatly affected the delayas still there have been chances for cache hits for the replacedreplicas.

We also consider a similar comparison in terms of thepacket delivery ratio metric. As shown in Figure 7(b), CADDsignificantly improves the delivery ratio in its two versions,CADD-20 and CADD-5, compared to SCF. The main reasonfor such improvement is the heading-awareness feature of

(a) Average delay of CADD and SCF with varying densities.

(b) Packet delivery ratio of CADD and SCF with varying densities.

Fig. 7. Comparison of CADD and SCF with varying densities.

CADD that saves packets from eventual dropping due togoing away from their destinations.

Another main metric we use to evaluate the performanceof CADD is the cache hit ratio of the resolved interests.With caching assistance, CADD achieves significantsavings of the access cost through succeeding in achievinga high cache hit ratio, as shown in Figure 8. For the samereason discussed earlier, CADD-5 has a slight decrease in thehit ratio compared to CADD-20. Since SCF does not involveany caching assistance, the cache hit ratio does not apply.

Second, we compare CADD with its underlyingcentrality-based caching mechanism (referring to it asCADD-Centrality) to another version with random caching(referring to it as CADD-Random) to show the effect ofthe proposed caching mechanism. In terms of the averageround-trip delay, Figure 9(a) shows that CADD-Centralityachieves lower delay than CADD-Random due to ensuringto have the cached replicas at the maximum central RCSs,which have higher probabilities for cache hits than randomly-chosen RCSs. This is demonstrated in Figure 9(b) comparingCADD-Centrality and CADD-Random in terms of the cachehit ratio. We considered CADD-20 in the above comparison,as well as in the following.

Third, we compare CADD in its complete form (referringto it in this comparison as CADD-Caching) and SCF toanother version of CADD with relaxing the caching feature(referring to it as CADD-NoCaching) to show the effect ofthe heading-awareness feature independently. In terms of theaverage round-trip delay, as expected, Figure 10(a) shows thatCADD-NoCaching achieves a value between those achievedby CADD-Caching and SCF, highlighting the delay reductionachieved through taking vehicles’ headings into consideration.Figure 10(b) shows a similar comparison in terms of thepacket delivery ratio emphasizing significant improvementsthrough CADD with and without caching compared to SCFdue to the heading-awareness feature.

Finally, we study the effect of changing the interestgeneration period (ρr) in CADD-20 and CADD-5, showingthe results in Figures 11 and 12, respectively, for varyingvehicular densities. We considered values 20 and 60 for ρr(generating an interest every 20 and 60 seconds, respectively).In terms of the average delay, Figures 11(a) and 12(a) showthat with increasing ρr, the delay increases. The reason being

Fig. 8. Cache hit ratio of CADD with varying densities.




(a) Average delay of CADD-Centrality and CADD-Random withvarying densities.

(b) Cache hit ratio of CADD-Centrality and CADD-Randomwith varying densities.

Fig. 9. Comparison of CADD with centrality-based caching vs. randomcaching with varying densities.

(a) Average delay of CADD with and without caching, and SCFover varying densities.

(b) Packet delivery ratio of CADD with and without caching,and SCF over varying densities.

Fig. 10. Comparison of CADD with and without caching, and SCF overvarying densities.

(a) Average delay of CADD-20 with different interest generationperiods over varying densities.

(b) Cache hit ratio of CADD-20 with different interest generationperiods over varying densities.

Fig. 11. Comparison of CADD-20 with different interest generation periodsover varying densities.

(a) Average delay of CADD-5 with different interest generationperiods over varying densities.

(b) Cache hit ratio of CADD-5 with different interest generationperiods over varying densities.

Fig. 12. Comparison of CADD-5 with different interest generation periodsover varying densities.




is that with such an increase in ρr, some cached replicasexpire before being asked for by later interests leading toreduced cache hits hence, longer delay. Figures 11(b) and12(b) show such a decrease in the cache hit ratio withincreasing ρr. We can also see from Figures 11 and 12that the results when ρr is equal to 60 is quite the samein CADD-5 and CADD-20 for the same reason mentionedabove: the reduced cache hits, diminishing the effect of thecache size.

VI. PRACTICAL CONSIDERATIONS

In this section, we highlight the practical considerationsrelated to the operation and implementation of the CADDscheme and the deployment of the required components.

A. The Road Caching Spot (RCS)

Compared to the different RSU models that are on themarket (e.g., the LOCOMATE devices that are used in theUS pilot and test-field programs [23]), the proposed RCS isa more cost-effective solution for data delivery assistance asit only holds the components needed for the caching andmulti-hop data delivery processes. The other RSU modelsinclude a variety of components that are not required forthose processes such as the Ethernet, M2M, and GPS modules.Our proposed RCS is a simple, light-weight device that canbe deployed on traffic lights or electric poles to complementRSUs for providing ubiquitous roadside assistance. It consistsof an 802.11p radio for communication which comes with anembedded processor, a memory chip for caching, and a powerport. Figure 13 shows the basic architecture of an RCS. It isworth noting that the RCS is not proposed to replace the RSU;it will be used to complement and assist the RSUs when/wheretheir ubiquitous deployment is not feasible.

B. The Communication Technologies

The IEEE 802.11p communication standard is suggestedas the main communication technology between the RCSsand vehicles since each smart vehicle will be equipped bydefault with an 802.11p radio to support the ITS services. Ourproposed RCS is equipped with an 802.11p radio as well tosupport such a communication. However, the scheme operationis not confined only to the 802.11p use; other inter-vehiclecommunication technologies can be utilized without affectingthe scheme. For example, some Zigbee modules [24] [25] are

IEEE 802.11p Radio

Processor

Memory Chip

5.9 GHz Antenna

Power Port

Fig. 13. The basic architecture of an RCS.

introduced to the market to support communication amongvehicles, and between vehicles and infrastructure. These mod-ules can be easily attached to vehicles and road units. TheVLC technology is currently gaining interest as a candidatefor vehicular communication [26] [27]. A vehicle’s regularlights can be replaced with light emitting diodes (LEDs) asVLC transmitters and each vehicle can be equipped as wellwith a VLC receiver which can be either an image sensor ora photo diode. To support such type of communication, ourbasic RCS can be modified to include a VLC transmitter anda receiver instead of the 802.11p radio.

It is worth mentioning that with the flexibility and easeof altering the communication interface of the RCSs, thepenetration rate of the roadside assistance can be boostedthrough adjusting such interfaces to cope with whichevervehicular communication technology is available.

The gateways needed as the PoA to the vehicular net-work are equipped with two communication interfaces:1) a broadband interface to be connected to the Internet for re-ceiving and sending service requests and replies, respectively,and 2) a communication interface to communicate with thevehicular network supporting the same technology used bythat vehicular network. A gateway can either have the samearchitecture as an RCS with an added capability for Internet-connectivity, or can be an RSU.

C. Backward CompatibilityOur scheme depends mainly on smart vehicles as carriers

of interest and reply packets between RCSs and as the mainresources of the sensing-based data; however, the entitiesinvolved in the scheme can be adjusted to support backwardcompatibility with regular/legacy vehicles having no on-boardconnectivity. Owners of legacy vehicles who are willing toparticipate in public sensing services supported by the pro-posed scheme can equip their vehicles with an 802.11p radioto be engaged in the forwarding loop. The owner of thesevehicles can depend on the sensing resources of smartphonesfor potential tasks (e.g., depending on a smartphone camerafor monitoring an event on the road). For the communicationbetween the smartphone and the outside vehicular network(for getting sensing interests and replying with sensed data),a Bluetooth interface can be integrated with a standalone802.11p radio for establishing an in-vehicle communicationbetween the smartphone and the added communication modulethat is responsible for the out-of-vehicle communication.

We also highlight that the operation of the scheme does notrequire that all vehicles should be CADD-enabled. Regularcommunication-enabled vehicles can also be involved in thesystem for basic data relaying through their default dataforwarding capabilities and vehicular communication. TheCADD-enabled vehicles support interoperability with suchregular vehicles, as well as communication with on-road RSUsand RCSs, see Figure 14. Regular vehicles (referred to asRVs) can be involved in regular vehicle-to-vehicle (V2V),vehicle-to-infrastructure (V2I), and infrastructure-to-vehicle(I2V) communications. CADD-enabled vehicles (referred asCVs) can support all the aforementioned types of communi-cation in addition to communication with RCSs; denoted as




RCS RSU

RV

CV RV

V2I

V2I V2R R2V I2V

I2V

V2V

Fig. 14. Interoperability of CADD-enabled vehicles with regular vehicularnetworks.

V2R and R2V communications.For the backward compatibility of roadside assistance, as

mentioned earlier, the RCS is proposed to complement theRSU operation not to replace it. For an intersection with adeployed RSU, the scheme does not require an RCS to bedeployed; only the storage capacity of the deployed RSU canbe upgraded to support caching.

D. Distributed Storage and Processing

Currently, there is a great push towards the adoption offog/edge computing [28] [29] and cloudlets [30] [31] aimingat providing local distributed computing as opposed to cloudcentral computing to handle the torrent of data being gener-ated by the Internet of Things (IoT) [32] [33]. Such trendsmove computing to a virtualized layer between the users andtraditional cloud computing platforms bringing content closerto consumers of local interest. Following these hot trends, ourscheme builds on distributed storage and processing throughRCSs deployed in a distributed fashion. In our scheme, data ofinterest is cached and processed locally relaxing the need forcentral/cloud computing for the sake of an efficient use of thebroadband bandwidth, and a fault-tolerant and load-balancedcaching of the generated data avoiding directing the cachingload to one central node.

E. Advantageous Delivery Features

The proposed scheme works on utilizing the current stateof vehicular density efficiently for data delivery. In cases ofcongested areas, the scheme utilizes the dense availabilityof vehicles for faster multi-hopping even if the carryingvehicles are quasi-stationary, while in sparse environments,the scheme depends on moving vehicles and their heading forbringing packets closer to/from areas of interest. Therefore,the proposed scheme can successfully operate in both casesconsidering its adaptive delivery features.

F. Performance Overhead

The CADD scheme works on achieving its functionalitieswithout imposing a communication overhead on the networkand its involved entities. Vehicles and RCSs use the IEEE802.11p WAVE standard in which, by default, the nodesperiodically broadcast beacon packets to exchange ID, po-sition, and velocity information. Our scheme mainly utilizessuch exchanged beacon packets for performing geographical

TABLE IIICOMMUNICATION OVERHEAD FOR RESOLVING AN INTEREST PACKET

Packet Type Number of Generated Packets by CADD

Control Packets 0

Data Packets 1 in case of a cache hit2 otherwise

data forwarding without the need to exchange special controlpackets. In terms of the data packets, for every interest packetsent, the scheme generates a maximum of two reply packets,see Table III. If the interest packet does not meet a cachedreplica on its way towards the corresponding AoI, it wouldbe resolved by a vehicle at the AoI sending a data replypacket to the requesting gateway. In addition, a replica ofthis reply would be generated and directed towards RCSmax

encountered on the interest path. On the other hand, when aninterest encounters a cache hit at one of the traversed RCSs,only one packet would be generated which is a copy of thecached data.

VII. CONCLUSIONS AND FUTURE WORK

we proposed the caching-assisted data delivery (CADD)scheme that enhances access to vehicular resources for vehicle-based public sensing services. Through applying caching onthe data delivery path, CADD aims at reducing the cost anddelay of accessing vehicular resources. CADD relies on thedeployment of a light-weight road caching spot (RCS) at eachintersection, and vehicles work as carriers of both interestsand replies between the RCSs. As part of CADD, a novelcentrality-based caching mechanism was proposed that han-dles the dynamic nature of vehicular networks and considerspopularity in cache replacement. CADD considers vehicles’headings to direct interests and replies towards their desti-nations. We presented mathematical analysis of the schemethrough assessment models comparing it to another schemewith connected RSUs in addition to analyzing its estimateddelay to reach an AoI from a considered gateway. Simulation-based performance evaluation was conducted as well showingthat CADD achieves significant improvements in the accesscost, delivery delay, and packet delivery ratio compared toanother scheme that does not involve caching-assistance anddoes not take vehicles’ headings into consideration. In ourfuture work, we will consider having a targeted cache hit ratioand study the placement and distribution of RCSs to achievethis ratio.

ACKNOWLEDGMENT

This research is supported by a grant from the NaturalSciences and Engineering Research Council (NSERC) ofCanada.

We thank Hesham Farahat for his help in the NS-3 simula-tion.

REFERENCES

[1] S. Abdelhamid, H. S. Hassanein, and G. Takahara, “Vehicle as a resource(VaaR),” IEEE Network Magazine, vol. 29, no. 1, pp. 12–17, 2015.




[2] A. T. Campbell, N. D. Lane, E. Miluzzo, R. A. Peterson, H. Lu,X. Zheng, M. Musolesi, K. Fodor, S. B. Eisenman, and G.-S. Ahn,“The rise of people-centric sensing,” IEEE Internet Computing, vol. 12,no. 4, pp. 12–21, 2008.

[3] S. Abdelhamid, H. S. Hassanein, and G. Takahara, “Vehicle as amobile sensor,” in International Conference on Future Networks andCommunications (FNC ’14), Elsevier Procedia Computer Science, vol.34, 2014, pp. 286–295.

[4] G. Zhang, Y. Li, and T. Lin, “Caching in information centric networking:a survey,” Computer Networks, vol. 57, no. 16, pp. 3128–3141, 2013.

[5] W. K. Chai, D. He, I. Psaras, and G. Pavlou, Cache ”less for more” ininformation-centric networks, ser. NETWORKING 2012, Lecture Notesin Computer Science. Springer, 2012, pp. 27–40.

[6] S. Abdel Hamid, M. Abu-Elkheir, H. S. Hassanein, and G. Takahara,“Towards provisioning vehicle-based rural information services,” inIEEE 37th Conference on Local Computer Networks Workshops, 2012,pp. 835–842.

[7] S. Abdelhamid, H. S. Hassanein, G. Takahara, and H. Farahat, “Caching-assisted access for vehicular resources,” in the IEEE Conference onLocal Computer Networks (LCN ’14), Sept. 2014, pp. 28–36.

[8] S. Abdel Hamid, H. S. Hassanein, and G. Takahara, Routing for WirelessMulti-Hop Networks. SpringerBriefs in Computer Science, 2013.

[9] F. Li and Y. Wang, “Routing in vehicular ad hoc networks: A survey,”IEEE Vehicular Technology Magazine, vol. 2, no. 2, pp. 12–22, 2007.

[10] K. C. Lee, U. Lee, and M. Gerla, “Survey of routing protocols invehicular ad hoc networks,” Advances in vehicular ad-hoc networks:Developments and challenges, pp. 149–170, 2010.

[11] Y. Ding and L. Xiao, “SADV: Static-node-assisted adaptive data dis-semination in vehicular networks,” IEEE Transactions on VehicularTechnology, vol. 59, no. 5, pp. 2445–2455, 2010.

[12] D. Borsetti and J. Gozalvez, “Infrastructure-assisted geo-routing forcooperative vehicular networks,” in IEEE Vehicular Networking Con-ference (VNC), 2010, pp. 255–262.

[13] Y. Wu, Y. Zhu, and B. Li, “Infrastructure-assisted routing in vehicularnetworks,” in the 31st IEEE International Conference on ComputerCommunications (INFOCOM ’12), 2012, pp. 1485–1493.

[14] M. D. Dikaiakos, S. Iqbal, T. Nadeem, and L. Iftode, “VITP: aninformation transfer protocol for vehicular computing,” in the 2nd ACMinternational workshop on Vehicular ad hoc networks, Germany, 2005,pp. 30–39.

[15] C. E. Palazzi, F. Pezzoni, and P. M. Ruiz, “Delay-bounded data gatheringin urban vehicular sensor networks,” Pervasive and Mobile Computing,vol. 8, no. 2, pp. 180–193, 2012.

[16] W. Ali, S. M. Shamsuddin, and A. S. Ismail, “A survey of web cachingand prefetching,” Int. J. Advance. Soft Comput. Appl., vol. 3, no. 1, pp.18–44, 2011.

[17] N. Loulloudes, G. Pallis, and M. D. Dikaiakos, Caching dynamicinformation in vehicular ad hoc networks, ser. Euro-Par 2010-ParallelProcessing. Springer, 2010, pp. 516–527.

[18] M. Amadeo, C. Campolo, and A. Molinaro, “CRoWN: Content-centricnetworking in vehicular ad hoc networks,” IEEE Communications Let-ters, vol. 16, no. 9, pp. 1380–1383, 2012.

[19] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs,and R. L. Braynard, “Networking named content,” in Proceedings of the5th international conference on Emerging networking experiments andtechnologies, 2009, pp. 1–12.

[20] “The NS-3 network simulator,” https://www.nsnam.org/, accessed: 16-09-2015.

[21] “SUMO (simulation of urban mobility),” http://sumo-sim.org/, accessed:16-09-2015.

[22] “Rapid generation of realistic simulation for VANET,” http://lens1.csie.ncku.edu.tw/Joomla Version/index.php/research-projects/past/18-rapid-vanet/, accessed: 16-09-2015.

[23] “Arada systems,” http://www.aradasystems.com/, accessed: 16-09-2015.[24] “ZigVi – Zigbee vehicle interface,” http://ph-elec.com/archives/

zigvi-zigbee-vehicle-interface, 2011, accessed: 13-02-2015.[25] “OBD2 fleet management system vehicle telematics monitor,”

http://www.fleet-genius.com/obd2-fleet-vehicle-telematics-monitors, ac-cessed: 16-09-2015.

[26] C. B. Liu, B. Sadeghi, and E. W. Knightly, “Enabling vehicular visiblelight communication (V2LC) networks,” in the 8th ACM internationalworkshop on Vehicular inter-networking (VANET ’11), Sept. 2011, pp.41–50.

[27] “LEDs bring new light to car-to-car communica-tion,” http://spectrum.ieee.org/transportation/advanced-cars/leds-bring-new-light-to-car-to-car-communication, 2014, accessed:16-09-2015.

[28] F. Bonomi, R. Milito, J. Zhu, and S. Addepalli, “Fog computing andits role in the internet of things,” in the 1st edition of the ACM MCCworkshop on Mobile cloud computing (MCC ’12), 2012, pp. 13–16.

[29] “Fog computing - Cisco systems,” https://techradar.cisco.com/trends/Fog-Computing, accessed: 16-09-2015.

[30] T. Verbelen, P. Simoens, F. De Turck, and B. Dhoedt, “Cloudlets:Bringing the cloud to the mobile user,” in the 3rd ACM workshop onMobile cloud computing and services (MCS ’12), 2012, pp. 29–36.

[31] M. Satyanarayanan, P. Bahl, R. Caceres, and N. Davies, “The case forvm-based cloudlets in mobile computing,” IEEE Pervasive Computing,vol. 8, no. 4, pp. 14–23, 2009.

[32] L. Atzori, A. Iera, and G. Morabito, “The internet of things: A survey,”Computer networks, vol. 54, no. 15, pp. 2787–2805, 2010.

[33] D. Miorandi, S. Sicari, F. De Pellegrini, and I. Chlamtac, “Internet ofthings: Vision, applications and research challenges,” Ad Hoc Networks,vol. 10, no. 7, pp. 1497–1516, 2012.

Sherin Abdelhamid is a Postdoctoral Fellow andResearch Associate at the Telecommunications Re-search Lab of the School of Computing - QueensUniversity in Canada, where she received her Ph.D.in 2014. She received her B.Sc. and M.Sc. degreesin computer sciences in 2005 and 2009, respectively,from Ain Shams University, Egypt. Her researchinterests include intelligent transportation systems,vehicular and wireless multi-hop networks, vehicu-lar cloud computing, information-centric networks,crowdsourcing, and Internet of things. Dr. Abdel-

hamid has several publications in top venues and is the winner of the bestpaper award of the AHSN symposium of IEEE GLOBECOM 2013.

Hossam S. Hassanein is a leading authority in theareas of broadband, wireless and mobile networksarchitecture, protocols and performance evaluation.His record spans more than 500 publications, inaddition to numerous keynotes and plenary talks inflagship venues. Dr. Hassanein has received severalrecognitions and best paper awards at top inter-national conferences. He is also the founder anddirector of the Telecommunications Research Lab atQueen’s University School of Computing. He is asenior member of the IEEE, and is a former chair of

the IEEE Communication Society Technical Committee on Ad hoc and SensorNetworks. Dr. Hassanein is an IEEE Communications Society DistinguishedSpeaker.

Glen Takahara received the B.A. degree in math-ematics from the University of British Columbia,Vancouver, B.C., in 1988, and the M.S. and Ph.D.degrees in Statistics from Carnegie Mellon Univer-sity in 1990, and 1994, respectively. Currently, he isan associate professor in Mathematics and Engineer-ing in the Department of Mathematics and Statisticsat Queen’s University in Kingston, Ontario, Canada.His research interests are in communications theory,networking, applied probability, and statistics.

IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL ......Content may change prior to final publication....

Documents

Transcript of IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL ......Content may change prior to final publication....