Priority-Based Content Delivery in the Internet of Vehicles through Named Data Networking ^†

Abstract

Named Data Networking (NDN) has been recently proposed as a prominent solution for content delivery in the Internet of Vehicles (IoV), where cars equipped with a variety of wireless communication technologies exchange information aimed to support safety, traffic efficiency, monitoring and infotainment applications. The main NDN tenets, i.e., name-based communication and in-network caching, perfectly fit the demands of time- and spatially-relevant content requested by vehicles regardless of their provenance. However, existing vehicular NDN solutions have not been targeted to wisely ensure prioritized traffic treatment based on the specific needs of heterogeneous IoV content types. In this work, we propose a holistic NDN solution that, according to the demands of data traffic codified in NDN content names, dynamically shapes the NDN forwarding decisions to ensure the appropriate prioritization. Specifically, our proposal first selects the outgoing interface(s) (i.e., 802.11, LTE) for NDN packets and then properly tunes the timing of the actual transmissions. Simulation results show that the proposed enhancements succeed in achieving differentiated traffic treatment, while keeping traffic load under control.

1. Introduction

The technological advancements in the field of sensing, automation, computing, communication and networking technologies for vehicles are driving the shift from conventional Vehicular Ad hoc Networks (VANETs) to the so-called “Internet of Vehicles” (IoV) [1,2].

IoV can be defined as a large-scale distributed and dynamic system for “Vehicle-to-everything” (V2X) wireless communications (with X being another vehicle, the road, a sensor, a pedestrian and Internet facilities); see Figure 1. It represents a prominent instantiation of the Internet of Things (IoT) technology in an Intelligent Transportation System (ITS) aimed at supporting a wide range of safety and non-safety applications for smart, efficient and green traffic management, environmental monitoring, intelligent vehicle control, safe, comfortable and pleasant driving and traveling experience of users on wheels.

IoV must face many issues to become a reality. Its successful rollout relies on several factors, ranging from the proper collaboration and interconnection between different sectors (such as energy, environment, automotive manufacturing, transportation, etc.) to sustained technology evolutions at the lower and upper layer of the communication protocol stack.

The main concerns come from the fact that ideally, according to the IoV vision, a car should be able to utilize any and all of the available communication interfaces, such as 3G/Long Term Evolution (LTE), Wi-Fi and 802.11 Outside the Context of a Basic Service Set (OCB) to interact with either remote/edge servers or other vehicles, as needed by the wide range of supported applications, while meeting their heterogeneous delivery demands (e.g., in terms of reliability, timeliness), under poor connectivity due to mobility and harsh propagation conditions. In particular, OCB is the operational mode of IEEE 802.11, specifically conceived for vehicular communications, that allows nodes that are not members of a Basic Service Set (BSS) to transmit data without preliminary authentication and association [3]. It clearly emerges that networking plays a crucial role to fulfil such huge expectations.

Today, there is a large consensus on developing “information-centric” approaches for vehicular environments [4] to satisfy the unmet challenges of current IP-dependent host-centric networking solutions. Information Centric Networking (ICN) and, in particular, its prominent example, Named Data Networking (NDN) [5], have attracted a significant interest in the research community as a promising solution for content search and delivery in the future Internet [6].

NDN shifts from the IP’s communication model, focused on “where” the content is stored, to a content dissemination model caring about “what” content to retrieve. To this aim, in NDN, application-level content names are directly used for content retrieval, hence permitting a node to communicate without any need of name-to-IP address resolution. Names are hierarchically structured (possibly user-friendly) and consist of a variable number of components, similarly to Uniform Resource Locators (URLs), that can define the scope of the data. Nodes send Interest packets to ask for named Data packets, replied by any node owning or caching the requested content.

The mentioned features make NDN particularly suitable for content retrieval in IoV, where: (i) vehicles are interested in retrieving content regardless of the identity of the node producing it (e.g., road congestion information, weather conditions, electric vehicle charging fees); and (ii) most of the content has a spatial and/or temporal scope. Caching, transparently performed at every NDN node, is particularly beneficial under the intermittent vehicular connectivity and can facilitate data retrieval by replicating contents in several nodes. Moreover, it can be applied at no additional cost thanks to the virtually unlimited storage capabilities of vehicular devices.

A fundamental component of the NDN architecture is the “strategy layer”, which is in charge of deciding where and when to forward incoming Interest packets, i.e., over which interface(s) and after which delay. Therefore, the definition of the NDN forwarding techniques to retrieve content [7,8,9,10,11,12], by overhauling the functionalities of the strategy layer, is among the crucial design choices to tackle in vehicular NDN.

To benefit from in-network caching and maximize the probability of content sharing, NDN typically assumes that packets are transmitted in broadcast over the wireless medium (usually the 802.11 OCB access technology is considered).

Existing literature works mainly focused on the definition of solutions aimed to counteract broadcast storm effects and limit useless transmissions while speeding up data delivery [8,9,10,11]. Overhearing is used to limit packet collisions and suppress redundancy. Typically, a defer time is calculated before each packet forwarding so that, if the same packet is overheard, then forwarding is canceled for the delayed packet.

Two main open issues still exist in the design of vehicular NDN forwarding.

First, IoV applications may exhibit very different (and stringent) demands, especially in terms of freshness and latency. For instance, traffic congestion information is “transient” and needs to be promptly retrieved, while file sharing applications are characterized by static contents and tolerate longer delays. So far, however, the content type of vehicular applications has not been considered as an input to the NDN forwarding strategy: all vehicles apply the same forwarding rules to all NDN packets.

Second, less attention has been devoted to the selection of the best interface(s) where to forward packets, nonetheless the multihome nature of recently manufactured vehicular devices [7,12]. For instance, in [12], a naïve approach is followed of forwarding each Interest to all of the interfaces that are available at the time, i.e., IEEE 802.11 in ad hoc mode for short-range vehicle-to-vehicle interactions, 3G and Wi-Fi mesh networks for long-range communications.

In this paper, we aim to take a step forward by designing a comprehensive NDN framework for prioritized content delivery in IoV, we refer to it as “prioritized NDN” (pNDN). Our proposal targets the support of data traffic originated by non-safety applications. Indeed, many efforts, both from standardization bodies and academia, have been already devoted to prioritizing the delivery of safety applications through solutions enforced at different layers of the protocol stack, whereas non-safety applications have received a lower interest.

The main contributions of pNDN can be summarized as follows:

• It identifies the content priority with well-known name prefixes and uses the “freshness” parameter carried out in NDN packets to further characterize the content delivery demands.
• It dynamically molds the NDN forwarding decisions according to the name prefix of contents, by selecting the outgoing interface(s) and properly tuning the defer timers of broadcast transmissions over the 802.11 OCB interface.

The performance of pNDN has been evaluated in a realistic fashion by leveraging the official NDN simulation framework and compared with reference NDN implementations without traffic prioritization. Results show that pNDN outperforms benchmarking schemes in that it speeds up the delivery of high-priority packets, while also reducing the latency of low-priority traffic, at the expenses of a slightly higher overhead.

The remainder of the paper is organized as follows. Section 2 debates the motivations for our work; background material about NDN and its usage in vehicular environments is provided in Section 3. The description of the proposed NDN solution is reported in Section 4. Simulation settings and tools are described in Section 5. A performance evaluation against legacy NDN implementations is presented in Section 6. Conclusions and hints for future works are provided in Section 7.

2. Traffic Prioritization in IoV: What and Why?

2.1. Towards IoV Applications

So far, the majority of research efforts worldwide considered a rough taxonomy of vehicular applications, by distinguishing safety data from non-safety data, where the first category accounts for high-priority messages crucial for the safety of drivers and passengers on wheels, whereas the second one may tolerate graceful performance degradation being mainly targeted to improve the traveling experience.

Starting from this, designed solutions have been mainly devoted to ensuring the reliable and timely delivery of safety messages, prioritized over non-safety messages. Such a kind of prioritization has been tackled as follows.

First, at the physical layer, dual-radio on-board transceivers are deployed to have one radio constantly tuned on a dedicated channel for the exchange of periodical and event-driven safety messages among vehicles without interference from other message types [13]. In the spectrum at 5.9 GHz allocated for VANETs, the dedicated safety channel is Channel 180 (named the Control Channel (CCH)) in Europe or Channel 172 in the US. Other (non-safety) data are, instead, expected to be transmitted on the second transceiver tuned into a different channel, i.e., a service channel (SCH). Multiple SCHs (up to five) are available for non-safety data, but there is not a clear indication about what type of traffic to transmit on which SCH [13].

Then, the Medium Access Control (MAC) layer of IEEE 802.11 OCB [3] relies on differentiated channel access (i.e., the Enhanced Distributed Channel Access (EDCA)) in order to further prioritize safety transmissions. Through EDCA, different channel contention parameters, e.g., the contention window, the Arbitration Inter-Frame Space (AIFS), are assigned in order to ensure high-priority safety packets seize the channel before less crucial ones. Parameters are set for transmissions over the CCH to provide aggressively differentiated priorities.

Moreover, at the upper layers, to further speed-up the exchange of safety messages, they are allowed to be exchanged by leveraging the lightweight Wireless Access for Vehicular Environment (WAVE) Short Message Protocol (WSMP) protocol, not to incur the overhead foreseen by heavy TCP/IP-based networking/transport protocols [14].

The aforementioned taxonomy of applications is too ossified for the IoV, which is expected to encompass novel applications specifically emerging with vehicles becoming multi-faceted elements (equipped with cameras, sensors [15], radars, storage, processing [4] and positioning capabilities [16,17]) of smart and connected cities able to interact also with nearby/remote people and objects [18,19].

The rich variety of IoV applications exhibits heterogeneous requirements in terms of delivery performance (i.e., latency, reliability, etc.) and space and time relevance. For instance, road traffic information (e.g., average speed in a given area) is locally-relevant data, the time validity of which lasts a few seconds or minutes; whereas the time validity of fee information about charging stations for electric vehicles and flyers of points-of-interest in a road area may span several hours.

Moreover, traffic of the same type, e.g., video, may require different delivery priorities. For instance, the delivery of a video requested by an autonomous car to improve its perception of the surrounding area under foggy weather conditions should be prioritized over the retrieval of the trailer of a recent cartoon, for a baby in the backseat. Indeed, the former video should be promptly retrieved for safe driving, whereas the latter is less crucial, but still asking for Quality of Experience (QoE) demands to be satisfied.

Despite such heterogeneous requirements, the MAC layer of 802.11 would treat video packets of both applications with the same Access Category (AC) parameters. Hence, we argue in favor of solutions able to complement the traffic differentiation capability at the MAC layer of the 802.11 technology to fulfil IoV requirements.

2.2. Heterogeneous Networking for IoV

The growing complexity and pervasiveness of envisioned IoV applications seriously challenge the capacity of 802.11 and pave the way for resorting to the usage of different wireless communication technologies. Indeed, recently manufactured vehicles can be provided with multihomed communication devices that enable different technologies to play alternative roles or be combined to boost vehicular connectivity depending on application requirements, content availability and network performance [20].

Basically, three different types of connectivity can be established by vehicles: (i) Vehicle-to-Infrastructure (V2I), i.e., communications over 3G/LTE to reach remote nodes; (ii) Vehicle-to-Roadside (V2R), i.e., interactions with the local roadside infrastructure (Road-Side Units, RSUs) set-up over 802.11 OCB links; (iii) Vehicle-to-Vehicle (V2V), e.g., interactions with other vehicles. V2V communications can be established both over 802.11 OCB links and, as more recently debated in the research community, through LTE Device-to-Device (D2D) communications, also known as Proximity Services (ProSe) in Third Generation Partnership Project (3GPP) Release 12 [21].

The aforementioned kinds of communications typically exhibit different performance features. For instance, V2I communications over LTE may have poor quality under high speeds, but are able to provide ubiquitous coverage. 802.11 OCB, instead, provides high-throughput for localized V2V and V2R interactions, with performance getting worsened in the case of multi-hop communications. However, it may suffer from intermittent connectivity, either due to sparsely-deployed RSUs in the case of V2R communications, or fragmented topologies, in the case of V2V interactions. Unlike 802.11 OCB, for which standardization, testing and experimentation are at a mature stage worldwide [20], with the consensus of many stakeholders, the design of the D2D technology for V2V interactions is still at its infancy and specifically under study in Release 14 [22].

Heterogeneous networking can be particularly helpful to accommodate the different delivery requirements of IoV traffic. In particular, prioritization of traffic can highly benefit from the availability of multiple interfaces. Low-priority traffic tolerating delays can be delivered over V2V/V2R links when available, by offloading the cellular interface, strained by the explosive growth of mobile data traffic [23]. On the other hand, bulky high-priority data transfers, especially if they have a tight deadline, may benefit from the usage of multiple interfaces in parallel.

3. Background and Motivations

3.1. Vehicular NDN

Several ICN architectures for the future Internet have been designed so far [6]; they all support name-based communication and in-network caching, but differ in the implementation details. Among them, Content-Centric Networking (CCN), originally proposed by Van Jacobson, is under continuous development by research initiatives worldwide, including the CCNx project (http://blogs.parc.com/ccnx/) and the Named Data Networking (NDN) project (https://named-data.net/).

The applicability of NDN in vehicular networks has been investigated in recent years [4,24,25]. Indeed, NDN receiver-driven connectionless communications, based on the exchange of two packet types—called Interest and Data—and pervasive in-network caching particularly suit the vehicular ecosystem.

Content retrieval in NDN starts when the consumer node requests a Data packet by broadcasting an Interest, which carries a hierarchical content name. There are no restrictions in the name components and their composition. For instance, in [25], the following scheme has been proposed: /traffic/geolocation/timestamp/data-type/nonce, where the component traffic is the application identifier, the geolocation component identifies road, section and direction, the timestamp component represents a time period, the data type component indicates the meaning of the data itself, e.g., vehicle speed, and finally, the nonce is a random number generated by the publisher.

Interest and Data processing at each node is performed with the help of three data structures: the Content Store (CS) that caches incoming Data; the Pending Interest Table (PIT) that keeps track of the forwarded Interests and their incoming interface; and the Forwarding Information Base (FIB), used as a routing table to select the outgoing face(s) for incoming Interests. In NDN, the term face is used to indicate the interface over which packets are received or delivered (i.e., network interfaces or application interfaces).

On the Interest reception, an NDN node N first looks in its CS for a name matching. If the content is found, it replies with the cached Data. Otherwise, if there is a matching entry in the PIT, N discards the Interest since a pending request is already outstanding. If not, a new PIT entry is created, and then, an FIB lookup returns the outgoing face(s), if any, where the Interest will be forwarded towards the provider. Data packets are not routed; they simply follow the chain of PIT entries in each crossed node back to the consumer.

Each intermediate node may cache incoming Data packets, so to serve future requests.

Although the NDN forwarding fabric coupled with in-network caching can enable simple and effective interactions in IoV, a major open issue is related to the deployment of the strategy layer, which implements the forwarding strategy and decides if, when and where to forward an incoming Interest. In the following, we survey the related literature, by distinguishing the case when only V2V and V2R interactions are enabled over the IEEE 802.11 OCB face (i.e., single-face communication), and the case when also V2I interactions are enabled (i.e., multi-face communication). It is worth noticing, however, that priority-based named data dissemination in IoV is still almost unexplored.

3.2. NDN Forwarding in VANETs

3.2.1. Single-Face Communications

NDN communication over IEEE 802.11 is generally based on controlled flooding [10,11,26]: the Interest is broadcast by the consumer and re-broadcast by some available intermediate nodes until a content provider is found or the Interest Time-To-Live (TTL) expires.

Broadcasting is generally useful because: (i) it allows one to reach multiple nodes, potentially storing the content; and (ii) it may facilitate content sharing, since broadcast packets can be overheard over the wireless channel. However, broadcast may unavoidably result in high channel access contention, collisions and redundancy, especially in dense multi-hop environments like IoV.

To limit such adverse effects, solutions in the literature typically assume that the transmission instant of both Interest and Data packets is delayed in each node of a given defer time, and packet suppression techniques based on overhearing are applied. According to them, during the waiting time, each transmitting node listens to the channel: if it overhears the same packet, then the imminent transmission is canceled. The additional delay can be randomly selected in a pre-defined temporal window [11,27] or it can be related to the distance from the previous sender [8,9]. Such schemes are totally distributed and performed autonomously by vehicles and RSUs; therefore, we refer to such mechanisms as “Blind Flooding” (BF).

To restrict the use of broadcasting, in some works, Interests are flooded only initially, when the content location is unknown; then, once a provider is discovered, an eligible forwarder/provider is addressed hop-by-hop. For instance, the Listen First Broadcast Later (LFBL) protocol [28], frequently used as the reference NDN forwarding strategy in wireless networks, piggybacks additional information (e.g., the hop distance from the content source and its unique identifier) in Interest and Data packets, which are tracked by traversed nodes. In particular, each intermediate node receiving the Interest checks if it is closer to the provider than the previous sender. If this is the case, it computes the defer time to rebroadcast the Interest. In so doing, Interests are more quickly and efficiently driven towards the content source.

Other approaches use regular beacon exchange to carry information helpful to select the best forwarder, at the expense of additional signaling, e.g., [9,29].

Finally, in [24], the concept of “geo-faces” is introduced: content names are bound to the providers’ geographic area(s), and Interests are forwarded towards such area(s) by using a shortest path algorithm over the road topology. When a geo-face is not present for content, flooding is performed. If a provider is found, it attaches its geo-area name to the returned Data packet, which follows the breadcrumb trace of the Interest and allows nodes to learn the binding between the data name prefix and the corresponding geo-area.

3.2.2. Multi-Face Communications

The previously-scanned literature considers NDN to exchange Interest/Data packets over a single wireless interface, i.e., 802.11. However, in the near future, vehicles will be equipped with a variety of wireless communication interfaces.

Thanks to name-based communication, the NDN forwarding strategy is natively able to deal with multiple network interfaces. Indeed, there is no need to set up a connection for data retrieval; IP addressing and port numbers are not used since forwarding depends only on a label, i.e., the content name. Therefore, Interest can be sent unmodified on any available interface.

NDN can decide, for each incoming Interest, which outgoing face(s) to use, e.g., the best-performing face, a subset of possible faces or all available faces. The decision depends on the implemented forwarding strategy, which may take as inputs the face cost, determined by the routing protocol, and the face rank, maintained by the forwarding strategy [30]. Indeed, unlike traditional IP-based networks where forwarding is a “dumb” operation driven by routing, in NDN, each node maintains a soft-state for every pending Interest in the PIT, and when the Data packets are received from the face(s), the node can know how the downstream faces actually work. The performance of each face, e.g., its Smoothed Round Trip Time (SRTT), can be therefore recorded to improve future forwarding decisions, without waiting for the routing protocol’s updates.

Standard NDN forwarding mechanisms include: (i) the broadcast (also known as parallel) strategy, where the Interest is forwarded over each available interface; (ii) the best route strategy, where the Interest is forwarded upstream with the lowest routing cost; (iii) the CCNx 0.7.2 strategy, where the Interest is first forwarded on the best route and, if a matching Data does not come in the predicted time, the Interest is forwarded to the other possible faces. How to properly estimate the Data arrival time and decide if/when transmitting redundant Interests over the other faces in the CCNx 0.7.2 strategy is however an open issue, which deserves proper investigation under different network environments.

In [12], the broadcast strategy is used on vehicles equipped with 3G/LTE/Wi-Fi connectivity, regardless of the content requirements. Results show that the solution is robust and resilient to connectivity disruption, but it causes high packet redundancy that should be eliminated.

In [7], heterogeneous technologies are used for different purposes: the cellular network is used to carry the NDN Interests over long distances and counteract possible connectivity gaps over the V2V links, while short-range V2V communications are exploited for content delivery.

In this paper, we consider vehicles equipped with two wireless access technologies: a cellular 3G/LTE face and an IEEE 802.11 OCB face. Although the cellular network offers global V2I coverage, V2V and V2R communications via IEEE 802.11 OCB are a good alternative connectivity solution that offloads the cellular infrastructure and takes advantage of high-speed opportunistic connectivity and data muling. Our designed forwarding strategy will take the best of the two faces in order to satisfy the priority requirements of the consumer application.

4. The Priority-Based Forwarding Framework

In this section, we present our proposed NDN forwarding framework, called pNDN, conceived to meet the priority requirements of IoV traffic.

As graphically sketched in Figure 2, our solution is intended to be deployed in a “clean-slate” manner, i.e., directly on top of the access technology (802.11 OCB, 3G/LTE). It leverages the legacy NDN supporting tables and consists of the following novel features:

• an advanced naming scheme that tags NDN packets with a name prefix identifying the application latency requirements and the consumer preferences;
• a freshness attribute in the Interest that captures the consumer expectation for the data retrieval;
• a smart strategy layer that decides where and when NDN packets should be transmitted, forwarded and (if necessary) retransmitted. To this aim, it encompasses the following modules: (i) the face selection, which decides which network face(s) is (are) forwarding an Interest; (ii) a freshness-based forwarding protocol, which accounts for the freshness specified by the consumer to decide if the Data can be served by the content store; (iii) a timing algorithm, implemented only on top of the 802.11 OCB face, which ensures the efficient and prioritized multi-hop delivery of Interest and Data packets in the V2V/V2R domain; and (iv) an Interest retransmission scheme, which allows a consumer to retransmit Interests whenever the Data packets are not received within a predefined time interval.

4.1. Naming and Freshness Settings

We assume that vehicular devices and other entities exchanging data with them (e.g., road side units, pedestrians, remote servers) agree upon a hierarchical namespace with a globally understood set of prioritization values. Here, for the sake of simplicity, we divide vehicular contents into two main priority categories, labeled as “high” and “low”. Of course, the scheme can be easily generalized to include more service classes.

Similarly to [31], where a name-based packet replication mechanism is proposed in a post-disaster scenario, the packet priority is codified within the hierarchical NDN name carried by Interest and Data packets. We use two prefixes, /high and /low, to identify the class membership of a given Data and the related Interest packet.

The class membership is set according to two different specifications:

• Application latency requirements: Vehicular applications usually have specific time constraints. For instance, the reception of road traffic information may be urgent for a vehicle planning its route. The Interest asking for such information should be forwarded with some privileges w.r.t. the Interest requesting the retrieval of software updates of the in-vehicle infotainment platform.
• User-defined preferences: Different network faces have usually different high-level characteristics, such as the monetary costs and the bandwidth limits. For instance, 802.11 OCB operates on the unlicensed spectrum enabling V2V and V2R connectivity free of charge; whereas the cellular network provides V2I connectivity over licensed frequencies and, typically, with a data plan requiring a monthly fee.

Such considerations result in different preferences of the users for different content types. For low-importance contents, the willingness of the user to leverage high-cost interfaces is quite low, and she/he prefers (inexpensive) interfaces, regardless of the provided quality; whereas for high-importance traffic, users require to experience the best performance, tolerating even some costs.

The pNDN naming module of the consumer node takes as inputs both the application latency requirements and the user-defined preferences for a desired content to select the name prefix (/low or /high) and includes it as the main name component in the Interest packet. For instance, the urgent road traffic information for a vehicle planning its route will be requested by an Interest with the name /high/trafficInfo/streetXy/km20/.

A fundamental parameter is also included by the consumer in the Interest packet so to influence the priority-based forwarding decision from the receiving node(s), i.e., the freshness. Unlike Internet contents (e.g., a YouTube video) characterized by typically time-invariant files, some IoV data are usually transient, e.g., vehicular traffic information may vary from instant to instant, and applications are interested in the freshest data packets.

NDN Data include by default a freshness parameter that establishes how long the content can be considered as valid in the CS [32]. Recently, to improve the accuracy of data retrieval, some works [33,34] encouraged a consumer-driven freshness approach: i.e., the freshness requirement is specified by the consumer and included also in the Interest. We follow the same approach in our proposal, since it particularly matches the requirements of IoV data that may be requested by different consumers with different freshness values (e.g., traffic information requested by vehicles for real-time route planning and by road authorities for long-term analytics).

4.2. Face Selection and Forwarding

The face selection module in pNDN decides the outgoing network face(s) for every Interest. In the considered IoV scenario, where two network faces are available for a vehicle, i.e., 3G/LTE and IEEE 802.11 OCB, pNDN implements the following selection strategy:

• Interests for Low Priority (LP) contents (i.e., with prefix name /low) are forwarded only over the 802.11 OCB interface.
• High Priority (HP) contents (i.e., with prefix name set to /high) are forwarded by consumers according to a parallel forwarding strategy, i.e., the Interest is simultaneously forwarded on both faces. This is to ensure the low latency and reliable delivery of such sensitive data. Vice versa, vehicles acting as forwarders may decide, according to their own user-defined preferences (e.g., monetary costs), whether to use only the IEEE 802.11 OCB face or also apply the parallel strategy. In case the LTE face is not available for a forwarding vehicle, it can only forward the Interest over the IEEE 802.11 OCB face.

Whatever the priority of content, the processing of an Interest packet at an intermediate node N can be summarized as follows. N first looks for a CS matching. In the presence of a CS hit, the receiving node checks if the freshness parameter specified in the Interest is satisfied by the stored Data. If this is the case, the Data is sent back. Otherwise, the Data packet is deemed outdated for the consumer, and the Interest is forwarded until the actual provider or a node caching a fresher copy is located. Multi-hop packet delivery over the 802.11 OCB interface is performed according to legacy protocols, like BF or LFBL, extended with additional priority-based forwarding rules, as specified in the following.

Figure 3 and Figure 4, respectively, depict the processing of an Interest packet at the consumer and at an intermediate vehicle node.

4.3. IEEE 802.11 OCB Timing Algorithm

If the face selection module decides to forward packets over the 802.11 OCB face, a proper mechanism is required to enable efficient and effective forwarding over multiple hops, by ensuring prioritization of HP contents over LP ones.

We preliminarily introduced such a forwarding algorithm in [35], and we briefly recall it in the following for the sake of completeness. Basically, it consists of a timer-based rebroadcast mechanism for Interest and Data packets, where the defer time is set locally by each forwarder according to the priority embedded in the content name of the incoming packet. Timers are computed in a totally distributed way by each vehicle without incurring any additional signaling overhead.

Any potential forwarder N defers its Interest retransmission of an additional delay, during which it listens to the channel: if it overhears the requested Data or the same Interest, then it cancels the Interest forwarding and deletes the related PIT entry. Similarly, any node N defers its Data transmission: if it overhears the same Data during the waiting time, then it drops the delayed packet.

In order to give Data packets priority over Interest packets, we let defer timers for Data and Interest forwarding be initialized from two distinct and adjacent time windows. They are, respectively, the Data Defer Window (DDW), in the range $[0;DD{W}_m)$, and the Interest Defer Window (IDW), in the range $[DD{W}_m,ID{W}_m]$. DDW and IDW sizes are set according to the 802.11 slot time and the short inter-frame spacing (SIFS) [3] to better and quickly adapt to MAC dynamics; a detailed study about their tuning can be found e.g., in [27].

To let HP (Interest and Data) packets be prioritized over LP ones, both IDW and DDW are then split into two disjoint sub-windows. In the first DDW sub-window, only HP Data packets are transmitted according to a high priority timer, $HP{T}_D$, extracted in the range $[0;HP{D}_m)$. In the second DDW sub-window, LP Data packets are transmitted by selecting a low priority timer $LP{T}_D$ in the range $[HP{D}_m;DD{W}_m$]. A similar division between high and low-priority parts is used for IDW; see Figure 5.

The $HP{D}_m$ and $HP{I}_m$ bounds are dynamically computed by each node according to the overheard traffic load for each traffic priority. To this aim, each node tracks the number of (HP and LP) received Data bytes. The number of received high and low priority bytes ($N_{HP}$ and $N_{LP}$, respectively) can be easily inferred by a node from the packet-size field in the header of each NDN packet [32]. Notice that the number of bytes, instead of the number of packets, permits a more precise channel load estimation at the NDN layer, since in a general case, the size of HP and LP IoV Data packets can be different, and differences can be appreciable also within the same priority class (e.g., a few bytes for environmental sensing data, a large chunk of a digital map). The bound between HP and LP Data packets in the $DDW$ is dynamically computed as follows:

$$HP{D}_m=\frac{N_{HP}}{N_{LP}+N_{HP}}·DD{W}_m.$$

(1)

The higher the number of overheard HP packets, the higher $HP{D}_m$. The bound in IDW for the Interest timer is computed analogously.

Once the window bounds have been computed, the defer times ($HP{T}_D$, $LP{T}_D$, $HP{T}_I$, $LP{T}_I$ for high priority and low priority Data and Interest, respectively) are calculated every time a node has to forward a packet. The timer is randomly chosen in its dedicated window, e.g., the $HP{T}_D$ value is uniformly distributed in the range $[0;HP{D}_m)$. However, more sophisticated calculations can be conceived for future work, e.g., by leveraging the spatial/temporal attributes of content. Once the defer time is computed, each packet is included in the proper priority queue and then either forwarded when the timer expires or dropped. In the rare case that two defer times from different priority queues expire at the same time, then the HP packet is consumed first.

4.4. Interest Retransmissions

After the Interest transmission, a consumer could not receive the Data due to losses over the error-prone wireless channel or to the temporary unavailability of producers or neighbor nodes storing the desired content.

Therefore, an Interest is retransmitted if the requested Data is not received within the relevant Retransmission Timeout (RTO) from neither of the two network faces. The RTO depends on the measured RTT at each received Data packet, and it is set according to Jacobson’s estimation. In particular, in the implementation, we refer to the built-in ndnSIM routines for the RTO computation.

Retransmission of Interests is enforced only at the consumer side; intermediate nodes simply forward Interest/Data. Such a choice is meant to control packet redundancy over the shared wireless medium, and it is even more reasonable when the parallel strategy is applied.

5. Simulation Settings

A comprehensive simulation campaign has been performed under a wide range of settings as reported in

Table 1. Simulation parameters.

	Parameter	Value
Application	Content size	1 MB
	Data payload	1000 bytes
	Content popularity	Zipf distribution
Topology	Area size	3.2 × 1.7 km2
	Number of vehicles	200
	Number of RSUs	55
	Mobility model	SUMO [36]
Load	Number of consumers	8–24
802.11 OCB	Propagation model	Nakagami [37]
	Data rate	6 Mbps [38]
3G/LTE	RTT	150 ms
NDN	Defer Window [27]	511
	DeferSlotTime [27]	58 μs

and detailed as follows.

Topology: To create a realistic road layout, we used maps publicly available from the OpenStreetMap (OSM) project [39] and combined them with realistic vehicular mobility traces derived from SUMO [36]. In particular, similarly to [15], a map of the city of Rome has been chosen; the map has a size of nearly 3.2 × 1.7 km²; see Figure 6. The positions of public Wi-Fi APs deployed in an urban area are available from [40], and have been used to resemble the position of 802.11 OCB RSUs. The mobility traces of vehicles are given as an input to ndnSIM [41], the official NS-3 based NDN simulator, together with the RSUs’ coordinates, available in latitude and longitude, converted in 2D positions.

Content features and request patterns: A subset of vehicles (from eight to 24) request 1 MB-large content from a population of $M=30$ content files (e.g., road pics, traffic maps, flyers, etc.). Such content is initially hosted at RSUs placed in the topology and acting as fog servers locally storing content [42] and also in remote servers accessible through the LTE connectivity. Although some preliminary works about the feasibility for LTE nodes to run ICN capabilities are available in the literature, e.g., [43], the topic is still at its infancy; thus, we assume that the eNodeB is not equipped with caching capabilities.

Each content is fragmented into Data packets of 1000 bytes. Content popularity follows a Zipf-like distribution with parameter $\alpha =0.8$ [44]. Without loss of generality, we assume that more popular content (i.e., with popularity index $<5$) is treated as HP content and named with the main prefix /high.This would be the case of road traffic-related data that are of interest for many vehicles. Other content is named with the main prefix /low. Each consumer vehicle chooses to download a single content file during the simulation. Interarrival times of content requests by different consumers are exponentially distributed with mean $\lambda =0.5$. Each consumer issues a new Interest at the reception of the (previously requested) Data packet to request the subsequent one and retransmits an Interest when the RTO of the current Interest expires, until the retrieval is completed.

Access technologies: The NDN instance in each vehicle runs over a multi-face device equipped with a dual-radio IEEE 802.11 OCB transceiver [3] and a cellular LTE interface. The first one is used for V2V and V2R communications, whereas the second one provides V2I connectivity towards the remote content server.

For what concerns 802.11 OCB, we focus on a service channel, where NDN packets are only transmitted in broadcast. All RSUs and on-board units (OBUs) can listen to the packets within their vicinity of 802.11 signal reachability. By leveraging the OCB mode, there is no need for them to be in the same Service Set Identifier (SSID) domain. Radio signal propagation follows a Nakagami distribution with fading factor m equal to three to model medium fading conditions in vehicular environments [37].

With LTE, an OBU with an Interest to send must first obtain a resource in the uplink through a random access mechanism, then transmits the message in the uplink towards the eNodeB, in its turn connected to the remote content server through the Packet Data Gateway (PDG) in the core network. We assume that the access delay and the transmission delay over the uplink are almost negligible compared to the RTT towards the server set. RTT values typically considered in the literature are in the order of 100 to 200 ms [45,46], thus we set the overall RTT equal to 150 ms.

Benchmarking solutions: The performances of the following NDN schemes are evaluated and compared:

• Single-Face NDN without prioritization (SF-NDN): All content is requested only over the 802.11 OCB face. The forwarding strategy is based on the BF protocol; Interest/Data packets of different contents are transmitted without differentiation.
• Single-Face NDN with prioritization (SF-pNDN): Similarly to the previous case, all content is requested only over the 802.11 OCB face, and the forwarding strategy is based on the BF protocol. In addition, the timing algorithm for traffic prioritization mechanism is applied; two transmission windows, IDW and DDW, are identified for high/low priority data delivery, as described in Section 4.3.
• Multi-Face NDN without prioritization (MF-NDN): Similarly to [12], content requests are transmitted over both faces, regardless of their performance and the priority of content.
• Multi-Face NDN with prioritization (MF-pNDN): According to the pNDN face selection module, LP and HP contents are differently transmitted over the network faces. LP content is only requested over the 802.11 OCB interface by both consumers and forwarding vehicles; HP content is requested with the parallel strategy by consumers, while forwarding vehicles use the 802.11 OCB face only. Packets transmitted over the 802.11 OCB face follow the timing algorithm described in Section 4.3 for prioritization.

For each implemented scheme, the timing algorithm applies the following settings. The window sizes for the defer timers are set by considering the IEEE 802.11 OCB parameters with $DDW=IDW=(slotTime+2·SIFS)·CW$, where $SIFS=36$ $\mathsf{\mu }$s, $slotTime=13$ $\mathsf{\mu }$s and $CW$ is the maximum contention window size for 802.11 OCB, set equal to 511 [3].

Metrics: The following performance metrics are computed to measure the effectiveness of data delivery and the efficiency in the usage of network resources, respectively:

• Content retrieval time: the average time required for a consumer to retrieve all of the Data packets of the desired content.
• Interest overhead: the total number of Interest packets transmitted and retransmitted (over both faces when MF-schemes are considered) during the simulation by all of the nodes involved in the content retrieval (i.e., consumers and intermediate nodes) over the total number of useful (non-duplicated) Data packets received by the consumers.
• Interest retransmissions: the percentage of Interests retransmitted by the consumers (at the RTO expiration) over the number of Interest packets required to retrieve the desired content (excluding retransmissions).
• Data retrieved over the 802.11 OCB face (defined for the MF-* schemes only): the percentage of useful Data packets received by the consumers via the 802.11 OCB face over the number of Interest packets required to retrieve the desired content (excluding retransmissions). The percentage of Data packets received from the LTE face can be inferred through the complementary value.

Results are averaged over 15 independent runs and reported with 95% confidence intervals.

6. Evaluation Results

Single-face NDN vs. multi-face NDN schemes: The first set of results, reported in Figure 7, is aimed at shedding light onto the performance of the multi-face forwarding strategy against the single-face solution, when no prioritization is enabled.

The content retrieval time is reported in Figure 7a. Regardless of the considered scheme, it can be observed that as the number of consumers increases, the content retrieval time gets significantly shorter. Values get nearly halved when passing from 8 to 24 consumers. This is because consumers can benefit from cache hits for the requested content in neighbor vehicles, which previously requested or forwarded the content, with no need to reach the original content source. Such a trend is more evident for the SF-NDN scheme where Interest and Data packets are exchanged over the IEEE 802.11 OCB face only. As expected, the MF-NDN scheme exhibits lower content retrieval times w.r.t. the SF-NDN. This is especially visible in the case of a few consumers, when the benefits of the content sharing over the broadcast medium are less noticeable. Whenever consumers are multiple hops far from a content source (i.e., either the RSU or a caching vehicle), with MF-pNDN, they can benefit from the Data packets received over the LTE face, without straining in retransmitting Interest packets in broadcast over the error-prone 802.11 OCB face, which may delay the content retrieval.

Such a trend is confirmed by the results reported in Figure 7b, which shows that the percentage of retransmitted Interests for MF-NDN is very low compared to SF-NDN. Indeed, the number of Interest retransmissions is always lower than 10% with MF-NDN, while it is always higher than 30% with SF-NDN, with a peak of nearly 53% for 12 consumers. As mentioned before, SF-NDN benefits from the presence of a higher number of vehicles requesting and, consequently, sharing contents. This is why the number of retransmitted Interests shrinks as the number of consumers increases.

The best performance of MF-NDN compared to SF-NDN is achieved at the expenses of a higher Interest overhead due to the simultaneous transmission of Interests over the two faces; see Figure 7c.

To gain more insight into the Data delivery performance over the two faces, let us refer to

Table 2. Percentage of Data packets retrieved via the 802.11 OCB face over the total number of requests.

Number of Consumers	8	12	16	20	24
MF-NDN	43.4	49.87	54.97	60.68	64.56
MF-pNDN	72.74	76.53	79.67	82.09	87.57

, which reports the percentage of Data received over the 802.11 OCB face for the MF-NDN solution (first row). The metrics increases with the number of consumers due to the higher content sharing over the short-range interface. Indeed, starting from 12 consumers, a slightly larger part of Data packets is received over the 802.11 OCB face rather than over the LTE connection. It is worth noticing that many vehicles/RSUs with a cached copy of the Data may answer to the same Interest. Indeed, there is no guarantee that the BF protocol can completely mitigate the Data redundancy. However, duplicated packets are simply discarded by the consumer, and they are not considered in the metrics computation, where only each first received Data packet is considered as valid.

Single-face NDN vs. multi-face prioritized NDN schemes: The second set of results targets the assessment of the prioritization routines enabled in the SF and MF schemes (Figure 8). In the figures, we distinguish the performance of HP and LP contents.

Similarly to the results achieved without prioritization in Figure 7a, the content retrieval time gets significantly shorter as the number of consumers increases (Figure 8a), thanks to the higher content sharing opportunities over the 802.11 OCB interface.

Moreover, it can be clearly observed that both solutions are successful in prioritizing HP contents over LP ones: (i) HP contents are retrieved in a shorter time w.r.t. LP ones; (ii) content retrieval times for HP contents are significantly lower compared to the ones experienced without prioritization and reported in Figure 7a. For instance, for 24 consumers, the retrieval time of HP contents is nearly 20 s and 35 s with MF-pNDN and SF-pNDN, respectively, while the counterparts MF-NDN and SF-NDN, without prioritization, exhibit an average retrieval delay of nearly 55 s and 70 s, respectively.

Thanks to the parallel transmission of Interests over multiple faces, the content retrieval time for MF-pNDN is significantly reduced compared to the SF-pNDN scheme. Such a trend applies for both HP and LP contents; however, it is more noticeable for the former ones.

With MF-pNDN, Interests are satisfied by the LTE face, whenever the 802.11 OCB face is too slow either because of harsh propagation conditions/interference or when consumers are multiple hops far from a content source (i.e., either the RSU or a caching vehicle).

Such a behavior translates into a lower number of Interest retransmissions for MF-pNDN compared to SF-pNDN, as depicted in Figure 8b. In particular, Interest retransmissions of HP contents are very low for MF-pNDN because, for them, thanks to the usage of the parallel strategy, they are likely to receive a Data packet, with no need to issue a retransmission.

Interestingly, the reduced load over the 802.11 OCB face (a lower number of Interest packets is exchanged over such a face since some of them may be served by the cellular network before the expiration of the corresponding RTO) has also the additional benefit of shortening the retrieval time for LP content.

Thus, *-pNDN schemes are effective in dealing with HP contents and also reduce the retrieval time for LP ones.

The significantly improved performance achieved by MF-pNDN in terms of retrieval time for both HP and LP contents is achieved at the expense of a higher overhead incurred w.r.t. SF-pNDN; see Figure 8c. However, unlike the previous results for the non-prioritized schemes, smaller differences are noticeable between the SF and the MF schemes, because only Interests for HP contents are transmitted simultaneously over the two faces. Interestingly, the incurred overhead is lower than the one achieved when prioritization is not enabled; see Figure 7c.

Table 2 reports the percentage of Data received over the 802.11 OCB face for the MF-pNDN solution (second row). Similarly to the previous case, values increase as the number of consumers increases due to the higher content sharing over the 802.11 OCB interface. In absolute terms, we can observe that a large percentage of Data packets is received over the 802.11 OCB face. Instead, only a few HP Data packets are received through the LTE face, whenever retrieval over the 802.11 OCB face fails either because of lossy links or when consumers are multiple hops far from the providers of the desired content.

7. Conclusions and Future Works

In this paper, we proposed a novel mechanism for the retrieval of named IoV content that uses information codified in the name and the freshness attribute for the prioritized delivery of content over multi-interface vehicular devices.

Prioritization is enforced in a two-fold manner: (i) in the face selection scheme by letting HP content be requested over multiple faces in parallel so as to speed up their retrieval; (ii) in the dissemination of Interest and Data packets over the 802.11 OCB interface by accelerating the forwarding of HP Interest/Data packets over LP ones.

Performance evaluation has been conducted under realistic settings through the official NDN simulator. The results achieved show that the proposed solution succeeds in reducing the latency of high priority packets, which is crucial for IoV content, while also improving the performance of low priority ones. This is achieved at the expense of a slightly higher signaling overhead due to the usage of multiple interfaces in parallel.

Enhancements left for future work are related to the design of more sophisticated multi-face forwarding algorithms with the main intent of improving content delivery performance while reducing the current overhead and further encouraging research in this promising area. Solutions will be specified to be able to dynamically weight the number of requests sent over the available interfaces according to operational metrics (e.g., SRTT), as preliminarily proposed in [47] for static users, and content requirements specified in names and attributes. Further efforts will be devoted to the definition of retransmission routines, which promptly switch from an interface to another one in the case of poor performance.

Moreover, as soon as the D2D technology for V2V communications becomes mature, improved multi-face forwarding solutions will be conceived of, also accounting for such a promising face option.