# Priority-Based Content Delivery in the Internet of Vehicles through Named Data Networking +
## 4 The Priority-Based Forwarding Framework
### 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.  
Figure 2: Protocol stack with prioritized Named Data Networking (pNDN) and supporting tables.  
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/streetSy/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).