enhancing content-centric networking for vehicular environments

Computer Networks xxx (2013) xxx–xxx

Contents lists available at SciVerse ScienceDirect

Computer Networks

journal homepage: www.elsevier .com/ locate/comnet

Enhancing content-centric networking for vehicularenvironments

1389-1286/$ - see front matter � 2013 Elsevier B.V. All rights reserved.http://dx.doi.org/10.1016/j.comnet.2013.07.005

⇑ Corresponding author. Tel.: +39 3491775654.E-mail addresses: [email protected] (M. Amadeo), claudia.cam-

[email protected] (C. Campolo), [email protected] (A. Molinaro).

Please cite this article in press as: M. Amadeo et al., Enhancing content-centric networking for vehicular environments, Comput(2013), http://dx.doi.org/10.1016/j.comnet.2013.07.005

Marica Amadeo, Claudia Campolo ⇑, Antonella MolinaroUniversity ‘‘Mediterranea’’ of Reggio Calabria, Italy

a r t i c l e i n f o

Article history:Available online xxxx

Keywords:Content-centric networkingIEEE 802.11p/WAVEVehicular networks

a b s t r a c t

Content-Centric Networking (CCN) is a new popular communication paradigm thatachieves information retrieval and distribution by using named data instead of end-to-end host-centric communications. This innovative model particularly fits mobile wirelessenvironments characterized by dynamic topologies, unreliable broadcast channels, short-lived and intermittent connectivity, as proven by preliminary works in the literature.

In this paper we extend the CCN framework to efficiently and reliably support contentdelivery on top of IEEE 802.11p vehicular technology. Achieved results show that the pro-posed solution, by leveraging distributed broadcast storm mitigation techniques, simpletransport routines, and lightweight soft-state forwarding procedures, brings significantimprovements w.r.t. a plain CCN model, confirming the effectiveness and efficiency ofour design choices.

� 2013 Elsevier B.V. All rights reserved.

1. Introduction

Vehicular ad hoc networks (VANETs) are getting closerand closer to reality in everyday life by providing vehiclesand roadside units (RSUs) with communication capabili-ties. Although initially designed to improve road safety,VANETs can additionally offer commercial, informative,and entertainment services to drivers and passengers [1],thus also providing revenues to the car manufacturersand service providers.

For a deep market penetration of VANETs, efforts arestill required to deal with some issues typical of vehicularenvironments like the fast changing topology, the short-lived intermittent connectivity, the unique set of conceivedapplications, and the harsh propagation conditions. Suchdistinguishing features ask for the design of innovativenetworking solutions to replace the traditional end-to-endhost-centric Internet paradigm with its TCP/IP protocol

stack, which is notoriously ineffective in mobile wirelessenvironments and further challenged in VANETs. The typi-cal location- and time-dependent vehicular applicationswould rather benefit of in-network and decentralized datacaching and replication mechanisms, as also acknowledgedin [2]. As a matter of fact, the Wireless Access in VehicularEnvironments (WAVE) protocol stack [3], which has beenad hoc conceived for VANETs, supports data exchangewithout the TCP/IP overhead, by means of the WAVE ShortMessage Protocol (WSMP) designed for safety–critical andcontrol messages.

In this paper, we advocate the need for a paradigm shifttowards a groundbreaking clean-slate vehicular network-ing solution and recognize the Content-Centric Networking(CCN) architecture [4] as the key enabler for content retrie-val and delivery in VANETs.

CCN has gained momentum in research on Information-Centric architectures for the future Internet [5,6]. It pro-poses a simple and effective communication model basedon content names, instead of IP addresses and host-to-hostconversations. Nodes broadcast Interest packets to ask for‘‘named’’ and ‘‘secured’’ contents. Any authorized network

. Netw.

http://dx.doi.org/10.1016/j.comnet.2013.07.005

mailto:[email protected]





http://www.sciencedirect.com/science/journal/13891286

http://www.elsevier.com/locate/comnet


2 M. Amadeo et al. / Computer Networks xxx (2013) xxx–xxx

node can cache the contents and is allowed to reply withthe required Data. The salient CCN features, i.e., nameddata, caching and lightweight forwarding, make CCN a par-ticularly attractive solution for VANETs. Names can be di-rectly used by the applications for content retrieval,hence permitting a node to communicate without anyneed of IP layer configuration, which is difficult to achievein highly dynamic environments. Caching, transparentlyperformed at every CCN node, is particularly beneficial un-der the intermittent connectivity on the road, and canspeed up data retrieval by replicating contents in severalnodes. CCN packet processing routines well face typicalVANETs situations in which end-to-end path set-up andmaintenance is difficult, if not impossible, to achieve.

The potential advantages that CCN can bring to VANETshave been preliminarily discussed in [7], and further inves-tigated in the recent literature [8–13]. However, most ofthe existing works either focus on simplified scenarios(for example, single-hop communications) or they focuson a specific vehicular application (e.g., traffic informationdissemination).

To advance the state-of-the-art, we design the Content-Centric Vehicular Networking (CCVN) architecture, whichborrows the main CCN ideas in [4] and extends it to copewith impairments in vehicular networks. Specifically,CCVN targets the following objectives:

(i) providing a general-purpose content retrieval anddistribution framework for vehicular applicationsthat is compliant with the WAVE architecture andleverages its strengths and capabilities;

(ii) keeping scalability under control through a distrib-uted counter-based broadcast scheme coupled withtransmission defer timers that counteract the broad-cast storm phenomena by reducing packet collisionevents on the wireless medium;

(iii) providing reliable content delivery through thespecification of a simple routine for Interest retrans-mission in case of packet losses;

(iv) improving content retrieval through the design of asoft-state forwarding strategy leveraging barebonepath-state information carried out in Interest andData packets, in order to face varying vehiculartopologies.

A preliminary evaluation of the CCVN architecture is re-ported in our early work in [14] that shows advantages ofCCVN over the traditional TCP/IP networking. In this paper,we enhance the previous work by adding an incrementaldesign and evaluation approach to understand to whichextent each proposed extension to the CCN model canbring benefits in VANETs.

The paper is organized as follows. In Section 2 we dis-cuss the main CCN features, its potential benefits and lim-itations in VANETs, while surveying the closest relatedliterature. The CCVN architecture is shortly presented inSection 3. The motivations and expected effects of eachincremental extension to the CCN design are debated inSections 4 and 5. In Section 6 the CCVN performance is as-sessed through simulations. Section 7 concludes the paper.

Please cite this article in press as: M. Amadeo et al., Enhancing conten(2013), http://dx.doi.org/10.1016/j.comnet.2013.07.005

2. Background and motivations

2.1. VANET applications and enabling communicationparadigms

A large variety of applications are foreseen for VA-NETs. In addition to road safety applications (like acci-dent warnings), also information dissemination (e.g.,parking lots, traffic/weather conditions, fuel prices, pointsof interest, bus times) and entertainment applications(e.g., file sharing, web browsing, gaming, etc.) will bedelivered.

Most of the applications specifically conceived forvehicular environments target vehicles in a given area,regardless of their identity or IP address.

Push-based dissemination and pull-based queryingtechniques, with focus on the content and the temporaland spatial scope of information, are both advocated in[2] to tackle the demands of information-rich vehicularapplications. They can be considered as forms of content-based communications that differ from the traditionalhost-centric paradigm since messages are routed basedon their content name rather than on their destinationaddress.

Publish-subscribe (pub/sub) event notification is aform of push-based communication, where senders pub-lish messages and receivers subscribe for their content.Examples of pub/sub approaches for VANETs can be foundin the literature, e.g., in [15,16]. The pub/sub paradigm iswell-suited for some VANET applications where drivers/vehicles indicate their interests about certain types ofnotifications (e.g., warnings concerning traffic jams onlywithin 1 km from the vehicle’s route) announced by thepublishers.

Other vehicular applications could instead benefit frompull-based approaches that deliver named content upondemand (e.g., map download, file sharing). The CCN frame-work well suits pull-based applications where a given con-tent, which might be available from multiple providers, istransmitted on demand in reply to an Interest. Thanks todata caching in on-board units available in every vehicle,contents can spread into the network as vehicles movearound, without being tied to a specific node. Moreover,vehicles (and co-located sensors) themselves could gener-ate data on the fly in response to a particular query, withoutpublishing procedures.

Both pub/sub event notification and on-demand con-tent delivery rely on asynchronous communication andallow spatial and temporal decoupling of transmittersand receivers. However, they have some conceptualdifferences, mainly in terms of initiator of the contentflow and content validity over time, as discussed in[17].

The idea of applying CCN for on-demand content deliv-ery in VANETs is quite novel but promising and deserves adeep investigation. In this paper we focus on CCN and pro-pose some extension to this paradigm in order to performmore effectively in vehicular environments.

The CCN main features and potential benefits for VA-NETs are discussed in the following subsections.

t-centric networking for vehicular environments, Comput. Netw.


M. Amadeo et al. / Computer Networks xxx (2013) xxx–xxx 3

2.2. CCN: an overview

The CCN architecture in [4] was one of the pioneeringresearch works on the future Internet. Its innovative ideasare currently the focus of many worldwide research initia-tives. CCN shares some basic common principles withother Information-Centric architectures that have been re-cently proposed [5,18] and differs in the way these basicfunctionalities are implemented.

The main CCN building blocks can be summarized asfollows:

Naming. Each content packet is associated with a persis-tent, unique, hierarchically structured name that isdirectly used by the applications for search and retrie-val. The name is independent of any transportconnections.Security. Security services (authentication and data-integrity) are embedded in each content packet, whichcarries a signature and data publisher information.Caching. Since each packet is a self-consistent (i.e., self-identifying and self-authenticating) data unit, cachingis facilitated. A subset (or all) of the network nodescan cache content in order to speed up data retrievaland delivery while reducing the network overhead.Packets and roles. Communication is a receiver-drivenprocess based on two packet types: the Interest, whichcarries the request for a content unit identified by itsname, and the Data, which carries the content payload.Each node requesting a content is referred to as ‘‘con-sumer’’ and each node providing the content as ‘‘pro-vider’’. A consumer requests Data by broadcasting anInterest packet over all available network interfaces1;any receiving node storing the content can provide theData.Data structures. Each CCN node maintains three datastructures: (i) a Content Store (CS) caching incomingData; (ii) a routing table named Forwarding Informa-tion Base (FIB), which stores the outgoing interface(s)to forward the Interests; (iii) a Pending InterestTable (PIT), which keeps track of the forwarded Inter-est(s), so that received Data can be sent back to therequester(s).Data retrieval. Each node receiving an Interest looks up aprefix-based longest-match on the content name in itsCS. If a matching is found, the Data is sent back on thesame interface the Interest arrived. Otherwise, if thereis a matching PIT entry, the Interest is discarded sincea pending request is already outstanding. If not, a newPIT entry is created and a FIB lookup returns the inter-face where to forward the Interest. The retrieved Datafollow the chain of PIT entries in each node back tothe requester(s). Flow control is achieved by an Interestconsuming a single Data packet.Transport. The plain CCN architecture does not specify areliable underlying transport of messages and Interest

1 In the general case, nodes like routers or multi-mode devices can beequipped with several interfaces.


retransmission mechanisms are not detailed albeitforeseen.Deployment. CCN is considered as a ‘‘clean-slate’’ solu-tion to be developed on top of layer 2 access technolo-gies and to replace IP. However, it can also be deployedas an overlay on top of an IP network.

2.3. Is CCN a solution for VANETs?

Differently from the current host-centric Internet model,which poorly fits the dynamicity of the vehicular environ-ment, the described content-centric paradigm naturallymatches various VANETs requirements and features:

2.3.1. Lightweight configuration networkingBy leveraging location-independent content names,

CCN would allow a network node to communicate withoutany a priori need for network parameters configuration(i.e., IP address, network mask, default router, name ser-ver). This is especially useful in dynamic environmentswhere static configuration is not possible due to nodemobility and where solutions like Mobile IP would beunsatisfactory [7].

2.3.2. Easy and straightforward in-network cachingIn-network caching techniques can be applied at low

cost in VANETs, thanks to the capabilities of vehicularnodes not limited by battery, memory, or computationconstraints. Although the benefits of caching in mobileand vehicular networks have been largely investigated,e.g., in [19] and references therein, the novelty of CCN isthe coupling of caching and named-data. In fact, the useof named-data makes the content accessible in an applica-tion-independent manner, so a content request can be sat-isfied by any matching data regardless of its location.

2.3.3. Service over sporadically connected linksCCN natively supports asynchronous data exchange be-

tween end-nodes. By using its cached data, a mobile nodecan serve as a link between disconnected areas and enablecommunications even under intermittent connectivity,typical of vehicular environments with sparse roadsideinfrastructure.

2.4. Preliminary examples of CCN over VANETs

The advantages of applying the CCN principles to on-de-mand content dissemination in a VANET have been re-cently discussed in the scientific community.

In [7] a data collection system via named data is de-signed for manufacturers to collect information from vehi-cles for monitoring and alert purposes. The CCNarchitecture in [4] is applied: RSUs play the role of consum-ers by broadcasting Interests and collecting informationfrom vehicles acting as providers in a given scope. The workin [8] discusses the potentialities of data naming in single-hop vehicle-to-vehicle (V2V) and vehicle-to-infrastructure(V2I) scenarios, when focusing on a traffic information dis-semination application. As pointed out by the authorsthemselves, both works in [7,8] can be considered aspreliminary explorations of the CCN model in vehicular



Fig. 1. CCVN reference scenario with the protocol stack, the data structures, and a snapshot of content retrieval when the NMRP provider selection schemeis enabled.


environments. In [9] the same authors propose and evalu-ate an application for V2V traffic information dissemina-tion that leverages CCN for efficient Interest and Databroadcasting. Similarly to our proposal, the solution in[9] employs a set of timers to coordinate transmissionsand minimize packets collisions on the shared wirelessmedium. The CCN framework is applied in [10] to dissem-inate safety information when vehicles are equipped withseveral radio interfaces. A node monitors the latency oneach interface, so that safety packets are transmitted overthe fastest path. In [11] a prototype for vehicles has beendesigned and developed that utilizes all available commu-nication technologies to search and route named data. In[12] the redundant paths of CCN are beneficially exploited,by applying network coding techniques to improve contentdissemination in VANETs.

3. The CCVN design in a nutshell

Similarly to the aforementioned works, we propose aCCN-based solution for VANETs, CCVN, in replacement ofTCP/IP networking and conventional routing protocols.However, our contribution differs from previous relatedwork because it proposes a general content-centric frame-work that addresses the following objectives:

3.1. Compliance with the IEEE 802.11p/WAVE standard

Each CCVN node runs the IEEE 802.11p standard [20]for vehicular communications. Specifically, the solution re-lies on the legacy OCB (Outside the Context of a BSS)mode.2 CCVN provides an alternative solution to the IP-based delivery of non-safety applications by leveragingCCN-based naming, caching, transport, and forwarding facil-ities, while legacy WSMP supports safety–critical data ex-change. CCVN does not require modifications of theunderlying consumer-driven CCN philosophy, as instead in

2 Explicit signaling for Basic Service Set (BSS) association and synchro-nization is not required before data exchange if the OCB mode is enabled.


previous works, e.g., [10]. The resulting protocol stack is de-picted in Fig. 1.

3.2. Pull-based applications support

CCVN can be applied in scenarios where vehicles act asconsumers and retrieve contents from the infrastructureand from nearby vehicles, e.g., they ask for location-basedinformation (e.g., digital maps, flyer and/or video clip ofnearby gasoline/charging stations, supermarkets, virtualtour of points-of-interest in a proximity, etc.) or for enter-taining contents (e.g., movie or music trailers). CCVN canbe as well applied when remote entities, e.g., road trans-port authorities, act as consumers to collect data from vehi-cles that behave as producers. For instance, vehicles deliveron demand their position information with pollution mea-surements retrieved by environmental sensors [21], andvideo/pictures recorded by on board cameras, to a remoteserver for traffic monitoring and surveillance purposes[11]. In both cases, content retrieval is started by consum-ers that broadcast Interest packets with the name of thedesired content (it could be /maps/LA/downtown in the caseof digital map of a place required by a vehicle passing by,or /traffic/pics/highway/Route51 in the case of traffic moni-toring images requested by a remote center).

3.3. Scalability

In CCVN, all transmissions are broadcast to leverage theshared nature of the wireless channel, so that nodes cantake advantage of overheard packets, similarly to [9,22].On the wireless medium broadcast packets can be lostdue to channel errors or collisions; there are no collisionavoidance/detection nor acknowledgment/retransmissionmechanisms. CCVN exploits packet overhearing and imple-ments appropriate countermeasures for controllingscalability and packet redundancy due to multiple trans-missions on the shared channel. Moreover, it specificallyaddresses the impact of vehicles forwarding Interests andrelaying Data for other vehicles, which are not investigated



Table 1Summary of the main differences between Basic CCN and CCVN.

Feature Basic CCN CCVN

Communication model Receiver-driven Interest/data exchange Like in Basic CCNPacket types Interest, data B-Int, A-Int, dataData structures CS, PIT, FIB CS, PIT, FIB, CPTBroadcast mitigation Counter-based broadcasting coupled with defer

timersLike in Basic CCN

Provider selection Not supported MRP: the most responsive providerNMRP: the nearest and most responsive provider

Interest retransmission After RTO expiration Like in Basic CCNRTT update Whenever a non-duplicated Data packet is

received at the first relevant Interesttransmission attempt

Whenever a non-duplicated Data packet from the currentpreferred provider is received at the first relevant Interesttransmission attempt

Interest forwarding If a PIT matching is not found MRP: only if there is a match for the current preferred provider inthe CPTNMRP: only if the node is closer to the preferred provider than theprevious sender

Data forwarding If there is a match in the CS MRP: like in Basic CCNNMRP: only if the node is closer to the consumer than thepreferred provider


in other works such as in [7–10], where only single-hopcommunications are considered.

3.4. Forwarding efficiency

CCVN introduces smart routines that handle forwardingdecisions in a distributed way, based on barebone path-state information carried in Interest and Data packetsand stored in a new data structure kept by vehicular nodesthat enables a soft-state forwarding.

3.5. Transport reliability

To provide reliable delivery, a consumer maintains atimer on each unsatisfied Interest, and retransmits it whenthe timer expires. The CCN model [4] and its implementa-tion in [23] do not include a specific timer value, whilepreliminary works, such as [24], address Interest retrans-missions in wired networks. In [25] transport routinesaddressing both Interest retransmissions and flow controlare designed for mobile ad hoc networks. CCVN includesa simple routine that manages Interests retransmissionsin case of missing Data.

3.6. Delivery effectiveness

Robust and adaptive mechanisms are enforced by CCVNin the soft-state Interest and Data forwarding proceduresto counteract the mobility-induced link breakages andthe unreliability of the wireless channel so reducing thecontent download time.

The CCVN architecture design follows an incrementalapproach by starting from the plain CCN architecture in[4,23], and extending it step-by-step to cope with theunreliable broadcast 802.11p wireless channel. The result-ing scheme has been further augmented with smarter rou-tines overall making CCVN. The main features of theincremental schemes are summarized in Table 1 and dis-cussed in the next sections.


4. First step: the basic CCN scheme

The first step has been implemented as a benchmarkingsolution for performance comparison. It is referred as BasicCCN since it inherits the main characteristics from the ori-ginal CCN protocol in [4,23]: (i) the Interest and Data pack-et exchange; (ii) the format of packets, reported in Fig. 2and 3; (iii) the node’s data structures (CS and PIT); (iv)the hierarchical naming scheme.

Regarding naming, we assume that each content isidentified by a Content Identifier (CID) and it is fragmentedinto packets, each one identified by a Packet Identifier (PID).The Data packet name is therefore represented as a ‘‘CID/PID’’ concatenation. Like naming, security and caching arealso applied on a per-packet base.

The Basic CCN scheme implements some features overthe original CCN architecture: (i) a mechanism allowingpackets to be re-broadcasted over the same network inter-face over which they arrived; (ii) two timers for delayingInterest and Data transmissions, respectively; (iii) a coun-ter-based scheme that controls packet redundancy in thebroadcast forwarding process; (iv) a rudimental flow con-trol mechanism that rules the Interest retransmissions.

The legacy CCN forwarding fabric assumes that anInterest can be forwarded over some available networkinterfaces, except from the interface the Interest arrivedfrom. Then, a new PIT entry is created from the Interestand its arrival face to manage data forwarding. In our mod-el, each node is provided with a single IEEE 802.11p inter-face and, therefore, a first required modification weintroduced in the forwarding strategy is to allow that pack-ets can be re-broadcasted over the same network interfacethey arrived and we do not consider the FIB role in theinterface selection.

The retrieval process for a consumer C starts with thebroadcasting of an Interest that includes the unique identi-fier of the desired data. Each intermediate node R receivingthe Interest first considers the NONCE and the HCNT fields tocheck the validity of the packet. If the packet is a replica orHCNT has reached the maximum value, it is dropped.



Fig. 2. Interest packets in Basic CCN and CCVN.

Fig. 3. Data packets in Basic CCN and CCVN.


Otherwise, R looks at its CS. If a matching is found, then thenode can act as a provider and schedules the Data trans-mission after a random defer time Tdata. Hidden terminalscan bring redundant requests on the same provider, butit only replies to the first Interest and discards the others.

If the CS check fails, R looks for a matching entry in thePIT. If a matching is found, R does not forward the Interestsince an equal request has already been sent. If not, a newPIT entry is created and, then, R schedules the packet for-warding after a random defer time Tinterest .

Defer times Tdata and Tinterest are used according to acounter-based scheme with a counter threshold, Ct. Specif-ically, during the Tdata waiting time, a provider listens toon-going transmissions: if it overhears the same Datatransmitted by other nodes for a number of times Ct, thenit aborts its data broadcasting. Similarly, during the Tinterest

waiting time, a potential Interest forwarder listens to thechannel: if it overhears the same Interest or the requestedData, then it cancels its own transmission and deletes therelated PIT entry. Tdata and Tinterest are multiple values ofthe 802.11p slot time and are randomly chosen in disjointintervals, with Tinterest > Tdata, in order to give higher accesspriority to Data over Interest packets.

Data forwarding is based on PIT matching: each nodereceiving a Data packet checks if it maintains a relatedPIT entry and, if so, decides if forwarding the Data packet


or not by following the counter-based scheme. If the re-lated PIT entry does not exist, the Data packet is discarded.

By following the chain of PIT entries, the Data packet isforwarded to consumer C. Subsequent content packets arerequested by following the same procedure: a new Interestis emitted at the reception of the Data packet until the con-tent download is completed.

Consumer C retransmits the Interest if the related Datais not received within a retransmission timeout (RTO)interval, which depends on the estimated Round Trip Time(RTT), i.e., the time interval passing from the transmissionof the Interest and reception of the requested Data. If noData is received after a number of retries (NR), C eventuallygives up and declares the content unreachable. At thereception of each non-duplicated Data packet, the con-sumer updates the estimate of the average RTT, accordingto the Exponential Weighted Moving Average (EWMA)formulation:

RTTk ¼ bRTTk�1 þ ð1� bÞRTTk ð1Þ

where RTTk�1 is the estimated mean RTT at the previousstep, RTTk is the round trip time measurement from themost recently received Data packet, and b is a filter gainconstant. In our current implementation, b equal to 0.85proved to be the best value to filter out transient effects.




In analogy to the Jacobson’s RTO estimation formula[26], the RTO for the kth Interest packet is related to theestimated mean and variance of the RTT:

RTOk ¼ RTTk þ f � r ð2Þ

where f is a constant factor set to 4 to accommodate theRTT variations without causing frequent premature time-out expiration, and r is the mean prediction error or theRTT mean deviation.

To avoid ambiguity, the RTT estimate is not updatedwhen a Data packet is received after an Interest retrans-mission, because the consumer cannot distinguish whetherit is a delayed Data related to the original Interest or theData related to the retransmitted Interest. The initial RTTsettings and the NR value depend on the application sce-nario and content type. The initial RTT is set to accommo-date Interest and Data transmissions over the longestconsumer–provider path in our settings, while NR is setequal to 7, in analogy with the suggested number ofretransmissions in the 802.11p standard.

3 Each CCVN node has a unique identifier (nodeID) that does not changeas the vehicle moves. One possible assumption is that the nodeID coincideswith the node’s MAC address, but it is not a mandatory choice.

4 The number of additional subfields depend on the implementedprovider selection scheme, i.e., one 6 bytes-long subfield for MRP and twosubfields for NMRP, accounting for 7 extra bytes.

5. CCVN: the enhanced scheme

CCVN is designed upon the Basic CCN scheme with theaim of providing faster and more efficient (multi-hop) con-tent dissemination, while further reducing packet forward-ing load at the expenses of little-to-none additionaloverhead. Each CCVN node maintains a new table calledContent Provider Table (CPT); it keeps track of the reachableproviders of a given content. The provider information isretrieved from an additional PROVIDER INFO field carried inthe Data packet, as illustrated in Fig. 3. This informationis used by consumer C to select its preferred provider onthe basis of the criterion specified in subSection 5.1. Theinformation stored in CPT also serves the additional pur-pose of supporting packet forwarding decisions at interme-diate nodes.

In CCVN the content retrieval is split in two mainphases: (i) the retrieval of the first content packet, whenno information about reachable providers is available yetat the consumer, and (ii) the retrieval of the subsequentpackets for which consumers indicate in Interest packetsthe preferred provider, which is selected among the onesthat replied with Data packets. To implement the twophases, CCVN distinguishes two Interest packet subtypesillustrated in Fig. 2: the Basic Interest (B-Int), sent forretrieving the first content packet, and the Advanced-Inter-est (A-Int), to request subsequent Data packets and adver-tise information about the preferred provider in thePROVIDER INFO field.

5.1. Preferred provider selection

Thanks to packet caching, more providers capturing anInterest can deliver Data to consumer C and, therefore,more copies of the same Data might arrive to C. Hence, Ccollects information about the reachable providers andstores the related parameters in its CPT.

In our current study, we consider two simple providerselection schemes: the Most Responsive Provider (MRP)


and the Nearest and Most Responsive Provider (NMRP)schemes.

The simplest one, MRP, only needs the provider identi-fier3 subfield, PROVID, to be carried in the PROVIDER INFO field ofData packets. This information is associated by the con-sumer to a response counter and stored in its CPT. The coun-ter keeps track of the responsiveness of each contentprovider, since it records the number of times the providerreplies with Data packets of a given content. The counteris increased by 1 at each new Data packet reception. Cchooses the node with the highest counter value (i.e., themost responsive) as its preferred provider and includes theprovider identifier in the sProvID subfield of the A-Int subse-quently issued.

The NMRP scheme needs two pieces of information tobe carried in the PROVIDER INFO field in Data packets: PROVID

and the DC subfield that reports the hop distance betweenthe replying provider and the consumer. It is initially set tozero and incremented along the reverse provider–con-sumer path. NMRP considers both the provider responsive-ness and the provider’s hop distance to the consumer asselection criteria. The consumer selects the nearest pro-vider and, in case of equally distant providers, the mostresponsive one among them. The relevant information isthen copied in the sProvID and DP subfields in subsequentlytransmitted A-Ints.

Both MRP and NMRP schemes consider the minimumRTT as an additional selection criterion. It is measured bythe consumer at each Data reception and included in theCPT. In case of equivalent providers (e.g., with the same re-sponse counter in MRP, or the same distance and responsecounter in NMRP), the consumer chooses the one with theminimum RTT.

5.2. Retrieval process

5.2.1. First packet retrieval and provider discoveryThe content retrieval process for a consumer C starts

with the broadcasting of a B-Int that includes the name(CID/PID) of the first Data packet.

B-Int packets are processed as Interests in CCN. Then,upon the B-Int reception at the provider, CCN and CCVNexhibit different behaviors. While in CCN, a provider P sim-ply replies with the requested Data, in CCVN, P appends itsPROVIDER INFO field in the Data packet before replying with it.4

Since MRP can be considered as a special case of NMRP,in the following we focus on the retrieval process when thelatter one is applied and we highlight differences amongthe schemes when necessary.

Each intermediate node R receiving a Data packet,checks if it maintains a related PIT.

If so, R adds a new entry (or it updates the entry if it ex-ists) in the CPT with information about the provider iden-tifier, its hop distance to it, as read from the ProvID and DC




subfields, respectively, and the owned CID. Finally, R for-wards the Data by following the counter-based schemelike in the Basic CCN scheme.

If the related PIT entry does not exist, the Data packet isdiscarded. This limits the number of nodes taking part inthe forwarding process and, consequently, it controls sca-lability and congestion in the system.

5.2.2. Successive packets retrievalOn receiving Data, C asks for the subsequent Data pack-

et by broadcasting an A-Int packet. It fills in the sProvIDand DP subfields with, respectively, the identifier of thepreferred provider and its expected hop distance to it.

At the A-Int reception, if the packet is valid, each inter-mediate node R looks for a matching in the CS.

In case of cache hit, if the node is also the preferred pro-vider, then it immediately sends the Data. Otherwise, twodifferent behaviors are foreseen for MRP and NMRP. If theMRP policy is enforced, R always replies with the Data pack-et as in the Basic CCN. Contrarily, if NMRP is enabled, R re-plies with Data only if it realizes itself to be closer to C thanthe preferred provider advertised in the A-Int (by comparingthe distance value DP , stored in A-Int, with its own distanceto the consumer C). We refer to this CCVN feature as in-net-work provider switching. If R replies to A-Ints on behalf ofthe current preferred provider for CsProv times, finally Celects R as the new preferred provider and includes its no-deID in the successive A-Int packets.

If the CS matching fails, a PIT lookup follows. Unlike inCCN, where each node forwards the Interest packet if a PITmatching is not found, in CCVN R looks for a CPT entrymatching both sProvID and the content name. If R is clo-ser to the preferred provider than the previous sender(i.e., its distance to P is lower than DP � 1), then it up-dates the DP subfield in the A-Int packet with its own dis-tance value and broadcasts the packet by following thecounter-based scheme, as described for Interest packetsin Basic CCN.

In MRP no hop distance information is carried in A-Intand Data packets. Hence, each forwarding node stores inthe CPT only the provider identifier and the related CID.At the A-Int reception, the node forwards the packet onlyif there is a match with the preferred provider identifierin its CPT and without any distance check.

If the selected preferred provider does not reply to A-Ints for a given number of attempts, CsProv ,5 the consumerlooks in the CPT for a new provider with the available con-tent and includes the relevant information in the subsequentA-Int packet; if no other provider is available in the CPT,then the consumer issues a new B-Int to discover a new pro-vider. We refer to this procedure as consumer-driven providerswitching.

The provider switching mechanisms conceived in CCVN,which permit to update the preferred provider role, wellcope with the highly dynamic VANET topology, where,due to the node mobility, the preferred provider may easilybecome unreachable or a consumer may enter the trans-

5 We assume CsProv ¼ 7, similarly to the 802.11p MAC Long Retry Limitvalue.


mission range of a new, more suitable, provider. Moreover,it is worth noticing that the indication of a preferred pro-vider does not imply that only a given node can providethe requested Data, rather the Interests continue to be sentin broadcast. The provider switching mechanism counter-acts the probability of content fetching from a single node,thus preserving the advantages of multiple providers andin-network caching typical of CCN. For example, in caseof packet losses in the path between the consumer andthe selected provider, an intermediate node caching themissing Data can provide it.

5.2.3. Managing retransmissionsIn analogy to CCN, each time a Data packet is not re-

ceived within an RTO interval, consumer C retransmitsthe related Interest (B-Int or A-Int). However, in CCVNthe RTT estimate is updated only if the received Data isoriginated by the preferred provider. This choice is madeto avoid fluctuations caused by nodes, different from theselected provider, that could reply with Data stored in theirCS.6

5.3. A snapshot of the CCVN behavior

For the sake of clarity, we summarize here how con-tent retrieval is performed in CCVN through the simpleexample illustrated in Fig. 1. Two consumers, C1 and C2,are interested in downloading content X and Z, respec-tively. Consumer C1 starts the provider discovery phaseby broadcasting a B-Int with the CONTENT PKT NAME set to(CID X/PID 1). Both neighboring nodes R and C2 receive theB-Int. R keeps a cached copy of content X in its CS and re-plies with the Data packet after a random delay Tdata.Node C2, which does not have a cached copy of X, sched-ules the B-Int re-broadcasting after a random delayTinterest , but in the meanwhile it overhears the Data trans-mitted by R, so it aborts the B-Int forwarding and deletesthe related PIT entry. After the Data reception, C1 tempo-rarily selects R as the preferred provider for subsequentcontent requests and updates its CPT with the providerinformation.

Consumer C2, on the other hand, broadcasts A-Int pack-ets carrying information about P, previously discoveredand selected as preferred provider, and node R, storing aCPT entry for P, relays A-Int (and related Data) packetsfrom C2 to P (and vice versa).

6. Performance evaluation

6.1. Simulation settings

To evaluate the performance of the proposed frame-work, the Basic CCN and the CCVN architectures have beendeployed in ns-2 [27] on top of 802.11p physical and med-ium access control layers [28].

6 The consumer also updates the RTT estimate from each reachableprovider to enable the selection of the preferred provider based on theminimum RTT, as explained in Section 5.1.



Fig. 4. Simulation scenario.

Table 2Main simulation parameters.

Category Parameter Value

PHY Frequency/channelbandwidth

5.9 GHz/10 MHz

Propagation Nakagami (m = 3)Transmission range 200 m

MAC Slot time 13 lsSIFS time 32 lsHeader length 40 lsaCWmin 15

APPL Content size 500 kbytesData payload 1000 bytes

CCN Interest size 20 bytesCCVN Interest size 26 bytes (MRP), 27 bytes

(NMRP)


The reference simulation scenario is depicted in Fig. 4:100 vehicles move according to the VanetMobiSim vehicu-lar traffic simulator [29], with speeds ranging between 20and 40 km/h. An RSU is positioned in the middle of thetopology storing a set of distinct contents (100) whichare requested by some vehicles (from 5 to 20 over 100)randomly selected in the grid to act as consumers. Contentdownload requests start asynchronously: the time be-tween two consecutive Interest transmissions for the firstData packet by different consumers is exponentially dis-tributed with rate k ¼ 1request=s.

We assume that content popularity follows a Zipf-likedistribution [30], characterized by an a exponent set equalto 0.8, unless differently specified in the text. A summaryof the main simulation parameters is given in Table 2.

Simulation results are averaged over 20 independent400s-long runs and reported with the 95% confidenceintervals.


6.2. Basic CCN: tuning the counter threshold

We start our analysis of results by evaluating the per-formance of the Basic CCN scheme, when varying the coun-ter threshold, Ct, from 1 to 4. The effectiveness of Basic CCNis evaluated by means of the following performance met-rics: (i) the Content Completion, computed as the fractionof consumers able to receive at most a given amount ofkbytes of the requested content; (ii) the Download TimeCDF representing the cumulative distribution function(CDF) of the time required to download the overall content.

Fig. 5a shows the content completion in the case of 5and 20 consumers in the grid. Under the 5 consumers sce-nario, CCN allows all requesting vehicles to receive the en-tire 500 kbytes-large content, whatever the counterthreshold value. This is not the case under heavier trafficload conditions (20 consumers), where a lower percentageof consumers complete the download, in the best case 93%when setting Ct equal to 1.

Fig. 5b shows the CDF of the download time under thesame load settings. As expected, the delay values are high-er under heavier traffic load due to the increased conges-tion and contention. For instance, the probability that thecontent download is completed in 200s is 0.8 when 5 con-sumers are considered and gets close to 0.5 with 20 con-sumers. The impact of the counter threshold on thedownload time is negligible.

The efficiency of Basic CCN is measured through the sig-naling overhead metric that represents the fraction of sig-naling bytes (Interest packets and header of Datapackets) over the total number of bytes (signaling and Datapayload) transmitted in the network. Results are shown inFig. 6a. The signaling overhead reasonably increases withthe number of consumers and with the counter threshold,



K bytes Time [s]

Fig. 5. Metrics for Basic CCN when varying the counter threshold, Ct, and the number of consumers, Nc.

Ct=1

Ct=2

Ct=3

Ct=4

Ct=1

Ct=2

Ct=3

Ct=4

Fig. 6. Metric vs. number of consumers when varying the counter threshold.

7 Although not reported in the text, simulation results show that theimpact of Ct on CCVN performance is qualitatively the same as in CCN.


given the higher number of forwarded packets. However, itrepresents a very low fraction of the overall generated loadin the network; it achieves 0.12 as the highest value.

In order to get further insights into the efficiency of theBasic CCN protocol and the tuning of the counter threshold,two additional metrics are considered: (i) Interest bytes,computed as the number of bytes transmitted in all Inter-est packets; (ii) Data bytes computed as the number of by-tes transmitted in all Data packets. Results in Fig. 6b showthat the higher the counter threshold, the higher the num-ber of nodes taking part in the Interest forwarding, thusleading to a higher number of transmitted Interest packets.When passing from Ct = 1 to Ct = 4, the number of Interestbytes is almost doubled. In contrast, the effect of Ct is lessnoticeable when focusing on the number of transmittedData bytes, although results are not shown due to lengthconstraints. In fact, during the Interest dissemination, for-warding nodes create PIT entries, according to which theydecide whether forwarding subsequently received Data.Henceforth, they do not struggle with the counter-basedscheme as instead they do for Interest forwarding.

All in all, achieved results would suggest that the BasicCCN scheme achieves the best trade-off between


effectiveness and efficiency when setting the counterthreshold Ct to 1. This is because a lower number ofrebroadcasting events leads to lower congestion and con-tention. This value is considered for further results in thenext subsection.7

6.3. CCVN vs. Basic CCN

We now compare the Basic CCN solution and the en-hanced CCVN scheme. Both provider selection criteria,MRP and NMRP, are considered in the CCVN evaluationcampaign. Fig. 7 shows the content completion when con-sidering 20 downloading vehicles. It can be noticed thatCCVN outperforms Basic CCN, with a higher fraction ofcompleted content downloads. Such improvements aremore noticeable when the NMRP scheme is applied.

The higher effectiveness of CCVN compared to BasicCCN is also witnessed by the shorter content downloadtimes in Fig. 8. Differences are more remarkable underlow traffic load in Fig. 8a: CCVN with NMRP allows all



K bytes

CCN

CCVN-MRP

CCVN-NMRP

Fig. 7. Fraction of consumers that complete the download of x kbytes for20 consumers.


the nodes to complete their content download in 100 s,while, under the other scheme, vehicles take a longer time.

Such improvements are achieved at the expenses of anadditional overhead per packet. Notwithstanding, the in-curred packet overhead is negligible (up to 7 bytes for eachA-Int and Data packet) and the overall network load in CCVNis lower than the one in Basic CCN. In fact, both the number

Time [s]

CCNCCVN-MRPCCVN-NMRP

Fig. 8. CDF of content download time for 5

CCN

CCVN-MRP

CCVN-NMRP

Fig. 9. Metric vs. numb


of Interest bytes, Fig. 9a, and the Data bytes, Fig. 9b, are sig-nificantly reduced w.r.t. Basic CCN. The MRP and NMRPschemes reduce the number of transmitted Interest (bytes)because they are not always forwarded as, instead, in BasicCCN, where the plain counter-based scheme is only ap-plied. Indeed, the relaying nodes are only those maintain-ing a CPT entry for the preferred provider (MRP) and thatare also closer to it (NMRP); this implies reduced channelcongestion and improved delivery performance. In particu-lar, NMRP generates a significantly lower number of Databytes compared to the MRP policy since, thanks to the Dpsubfield in A-Int packets, only providers that are closer tothe consumer than the preferred provider are eligible to re-ply with Data packets.

6.4. CCVN: MRP vs. NMRP

The last simulation campaign focuses on CCVN tounderstand, more in detail, the motivations behind theoutperforming behavior of NMRP compared to MRP. Tothis aim we compute the provider selection effectivenessmetric, as the fraction of Data packets received by the con-sumer with the ProvID subfield that coincides with the pre-ferred provider. As suggested by the name, it evaluates therobustness of the provider selection criterion; the higher

Time [s]

CCNCCVN-MRPCCVN-NMRP

consumers (a) and 20 consumers (b).

CCN

CCVN-MRP

CCVN-NMRP

er of consumers.



MRP, α=0.8

MRP, α=2

NMRP, α=0.8

NMRP, α=2

Fig. 10. Provider selection effectiveness vs. the number of consumers fordifferent a values for MRP and NMRP.


its value (bounded to 1) the more effective the preferredprovider selection performed at the consumer side.

In this analysis we consider two different Zipf a values,0.8 (low content popularity) and 2 (high contentpopularity).

Fig. 10 shows that, for both schemes, the metric getslower as the number of consumers and the content popu-larity increase.

This is because: (i) with more consumers, more contentrequests are sent from many places in the grid and, conse-quently, cached contents are better spread in the network;(ii) when a content is popular, a larger fraction of nodesmaintains a copy of it and can reply to A-Int with Datapackets.

With the NMRP scheme, leveraging distance-based cri-teria in both provider selection and provider switchingprocedures, the selected provider more likely coincideswith the serving provider, i.e., the one from which the Datapacket is received, compared to the simpler MRP approach.Such a result confirms the benefits of a more sophisticated,although still barebone, provider selection policy andpaves the way for the investigation of further solutions,encompassing soft-state forwarding procedures, whichwill be a subject matter of future work.

7. Conclusions

In this paper we investigated the content-centric net-working paradigm in vehicular environments. A carefuljoint analysis of the CCN features and the peculiarities ofVANETs has shown the feasibility of the content-centricparadigm for non-safety applications provisioning to IEEE802.11p/WAVE vehicular devices. This is however possibleprovided that properly enhancements and adjustments areenforced compared to the originally conceived CCNarchitecture.

We design the CCVN framework in a two step approach.The basic protocol deployment relies on the main CCN pil-lars and it enforces a simple counter-based approach cou-pled with defer transmission timers and Interestretransmission routines, to allow efficient and reliablebroadcast transmissions in the wireless environment.


Results show that by properly tuning the counter thresh-old, a satisfactory trade-off between efficiency and effec-tiveness can be achieved.

As a following step we deployed an enhanced solution,CCVN, encompassing procedures, like soft-state forwardingand provider selection/switching, which further reducecongestion in disseminating Interest and content packets,while ensuring efficient content delivery in shorter times.

As a future work we plan to improve CCVN by address-ing more in detail transport-related issues, e.g., through asmarter Interest flow control that considers feedback infor-mation about available network resources.

References

[1] M. Amadeo, C. Campolo, A. Molinaro, Enhancing IEEE 802.11 p/WAVE to provide infotainment applications in VANETs, Ad HocNetworks 10 (2) (2012).

[2] F. Bai, B. Krishnamachari, Exploiting the wisdom of the crowd:localized, distributed, information-centric VANETs, IEEECommunications Magazine 48 (5) (2010).

[3] C. Campolo, A. Molinaro, Multichannel communications in vehicularad hoc networks: a survey, IEEE Communications Magazine 51 (5)(2013) 158–169.

[4] V. Jacobson et al., Networking named content, in: ACM CoNEXT,2009.

[5] B. Ahlgren et al., A Survey of information-centric networking, IEEECommunications Magazine 50 (7) (2012) 26–36.

[6] A. Detti et al., Supporting the Web with an information centricnetwork that routes by name, Computer Networks 56 (17) (2012).

[7] J. Wang et al., DMND: collecting data from mobiles using nameddata, in: IEEE Vehicular Networking Conference, 2010.

[8] J. Wang et al., Data naming in vehicle-to-vehicle communications,in: IEEE INFOCOM NOMEN Workshop, 2012.

[9] L. Wang et al., Rapid traffic information dissemination using nameddata, in: ACM MobiHoc NoM Workshop, 2012.

[10] G. Arnould et al., A self-organizing content centric network modelfor hybrid vehicular ad-hoc networks, in: ACM DIVANet, 2011.

[11] G. Grassi et al., Vehicular inter-networking via named data, in: ACMHotMobile 2013 Poster.

[12] P. Talebi Fard, V.C.M. Leung, A content centric approach todissemination of information in vehicular networks, in: ACMDIVANet, 2012.

[13] M. Amadeo, C. Campolo, A. Molinaro, CRoWN: content-centricnetworking in vehicular ad hoc networks, IEEE CommunicationsLetters 16 (9) (2012) 1380–1383.

[14] M. Amadeo et al., Content-centric networking: is that a solution forupcoming vehicular networks? in: ACM VANET, 2012.

[15] I. Leontiadis, P. Costa, C. Mascolo, A hybrid approach for content-based publish/subscribe in vehicular networks, Pervasive andMobile Computing 5 (6) (2009) 697–713.

[16] F. Malandrino, C. Casetti, C.F. Chiasserini, Discovery and provision ofcontent in vehicular networks, Wireless Communications andMobile Computing (2012).

[17] A. Carzaniga et al., Content-based publish/subscribe networking andinformation-centric networking, in: ACM SIGCOMM ICN, 2011.

[18] A. Detti et al., Conet: a content centric inter-networking architecture,in: ACM SIGCOMM ICN Workshop, 2011.

[19] M. Fiore et al., Caching strategies based on information densityestimation in wireless ad hoc networks, IEEE Transactions onVehicular Technology 60 (5) (2011).

[20] IEEE 802.11p. Amendment 6: Wireless Access in VehicularEnvironments, 2010.

[21] C. Campolo et al., SMaRTCaR: an integrated smartphone-basedplatform to support traffic management applications, in: FirstInternational Workshop on Vehicular Traffic Management forSmart Cities (VTM), 2012.

[22] M. Meisel, V. Pappas, L. Zhang, Listen first, broadcast later: topology-agnostic forwarding under high dynamics. In: Annual Conference ofInternational Technology Alliance in Network and InformationScience, 2010.

[23] CCNx Protocol. <http://www.ccnx.org/documentation/>.[24] S. Salsano et al., Transport-layer issues in information centric

networks, in: ACM SIGCOMM ICN Workshop, 2012.


http://refhub.elsevier.com/S1389-1286(13)00221-1/h0005

























http://www.ccnx.org/documentation/



[25] M. Amadeo, A. Molinaro, G. Ruggeri, E-CHANET: routing, forwardingand transport in information-centric multihop wireless networks,Computer Communications 36 (7) (2013) (Elsevier).

[26] V. Jacobson, Congestion avoidance and control, in: ACMSIGCOMM’88.

[27] ns-2, Network Simulator Tool. <http://www.isi.edu/nsnam/ns>.[28] Q. Chen et al., Overhaul of IEEE 802.11 Modeling and Simulation in

ns-2, in: ACM MSWiM, 2007.[29] J. Harri et al., VanetMobiSim: generating realistic mobility patterns

for VANETs, in: ACM VANET, 2006.[30] L. Breslau et al., Web caching and zipf-like distributions: evidence

and implications, in: IEEE INFOCOM, 2009.

Marica Amadeo is a PhD Student at Univer-sity Mediterranea of Reggio Calabria, Italy. InNovember 2005, she received a Bs Degree inTelecommunications Engineering from theUniversity ‘‘Mediterranea’’ of Reggio Calabriaand in October 2008, she received a MsDegree in Telecommunications Engineeringfrom the same University. In January 2010,she started her PhD program and her majorresearch interests are in the field of Informa-tion-Centric Networking, Mobile Ad-HocNetworks (MANETs) and Vehicular Ad-Hoc

Networks (VANETs).

Claudia Campolo is an Assistant Professor ofTelecommunications at University Mediter-ranea of Reggio Calabria, Italy. Before hercurrent appointment, she received a Laureadegree in Telecommunications Engineering(October 2007) and a PhD degree (February2011) from the University Mediterranea ofReggio Calabria, Italy. Since March 2011 shehas been with the same university as a Post-Doc researcher. She was a visiting PhD stu-dent at the Department of Electronics Engi-neering of Politecnico di Torino (from May to

October 2008). Her main research interests are in the field of vehicularand cooperative networking. She served as a TPC member of internationalconferences and as a technical reviewer of several journals.


Antonella Molinaro is an Associate Professorof Telecommunications at University Medi-terranea of Reggio Calabria, Italy. Before hercurrent appointment, she worked at the Uni-versity of Messina (1998–2001) and the Uni-versity of Calabria (2001–2004) as anAssistant Professor, and at Polytechnic ofMilano (1997) as a research assistant. Sheworked with Telesoft S.p.A. in Rome as anetwork designer (1992–1993), and withSiemens AG, Munich, Germany (1994–1995)as an EU Fellow within the RACE II ATDMA

(Advanced-TDMA Mobile Access) project. She received the Laurea Degreein Computer Engineering from University of Calabria in 1991, a post-laurea master diploma in Information Technology from CEFRIEL/Politec-
nico di Milano in 1992, and a PhD degree in Multimedia Technology andCommunication Systems in 1996. She has served in the Technical Pro-gramme Committee, Steering Committee, and Advisory Board of severalIEEE conferences. Her recent research activity mainly focuses on archi-tectures and protocols design and optimization for wireless networking,multihop communications, wireless ad hoc networks, vehicular networks,Information-Centric Networking for the future Internet.




http://www.isi.edu/nsnam/ns


enhancing content-centric networking for vehicular environments

Documents