# A Literature Review on Caching Transient Contents in Vehicular Named Data Networking
## 2 Vehicular NDN  
Vehicular networks were originally conceived to support two broad classes of applications, namely: (i) safety applications, devoted to improving the safety of drivers and passengers, and (ii) non-safety applications, with infotainment purposes. Today, however, the advent of intelligent and autonomous driving applications has turned connected vehicles into one of the major contributors of IoT traffic and has promoted the new Internet of Vehicle (IoV) paradigm. Provided with multiple on-board sensors, cameras and GPS devices, vehicles will generate and process terabytes of contents per driving hour, while offering advanced driving experiences to drivers and passengers. A proper network architecture is, therefore, required that effectively and reliably delivers vehicular information in presence of mobility, harsh propagation conditions, and typically stringent latency constraints. In this challenging context, NDN, and particularly its customization in the vehicular environment, namely VNDN [4], represents an extremely promising solution. In principle, VNDN can operate in presence of multiple wireless access standards, including the most prominent alternatives for vehicular networks, namely IEEE 802.11p and Cellular Vehicle to Everything (C-V2X) [16]. In the following, however, we mainly refer to vehicular ad hoc networks (VANETs) based on IEEE 802.11p, which is the reference technology in almost all the VNDN-based solutions available in the literature [14]. As shown in Figure 2, in the considered VNDN network, vehicular on-board units (OBUs) interact among each other through vehicle-to-vehicle (V2V) communications, and with nearby road-side units (RSUs) and other infrastructure elements, e.g., smart semaphores, through vehicle-to-infrastructure (V2I) communications. In the majority of VNDN deployments, V2V and V2I interactions are based on the broadcast exchange of Interest and Data packets to maximize the data sharing over the wireless channel. The basic forwarding strategy in VNDN consists of controlled-flooding [4]. A consumer node (either a vehicle or a RSU) broadcasts the Interest packet. Each node \(R\) receiving the request checks if it maintains the Data packet in the CS. If so, it schedules the broadcasting of the Data after a certain time, to avoid collisions with other neighbors. Otherwise, \(R\) schedules the re-transmission of the Interest packet. If \(R\) overhears the Data or the Interest transmitted by other nodes, then it cancels its own transmission. In case of an Interest (re)-transmission, the request is maintained in a data structure called Pending Interest Table (PIT) until the correspondent Data packet is received or the Interest lifetime expires. NDN nodes are usually provided with multiple access network interfaces; therefore, to forward the content requests, they record the outgoing interface(s) per each named prefix in the so-called Forwarding Information Base (FIB). In the considered scenario, however, we assume that node \(R\) is provided with a single wireless access interface, i.e., IEEE 802.11p; therefore, it simply re-broadcasts the packet over the same interface the Interest arrived from. The request travels hop by hop in the network until the Data is discovered or an hop count, carried in the header and decremented at each hop, is set to zero. Multiple approaches have been proposed over the years to limit the adverse effects of packet broadcasting, e.g., high traffic congestion and limited reliability, and improve the forwarding decision. For instance, in References [7, 17], the effects of the hop count added in the Interest header to limit the multi-hop forwarding of the requests are studied. In Reference [18], controlled-flooding is used only to discover the content provider (either the original producer or a cache). Then, subsequent Interests are marked with the MAC address of the discovered provider and only the nodes in the path towards it are allowed to forward the requests.