# Enhancing the 3 GPP V2X Architecture with Information-Centric Networking
## 3 NDN for V2X Communications
### NDN Basics  
In NDN, the original content is segmented into chunks, which are individually named and secured. The resulting unit may be transmitted in a single Data packet or further fragmented and transferred over the channel in more than one packet of smaller size. NDN follows a _receiver-driven_ approach: an Interest is used to request a given named Data packet. NDN names are application-specific and hierarchically structured. For instance, a video produced in a classroom during the maths lecture at the university of Reggio Calabria (UNIRC) may have the name _/unirc/videos/classrooms/maths.mpg_, where \"/\" delineates name components in text representations, similar to Uniform Resource Locators (URLs). An NDN consumer, i.e., an end device interested in a given content, includes the content name in an Interest packet and sends it to the network without specifying a destination address. The network nodes apply a forwarding-by-name mechanism to move the request toward the source(s) generating or owning that content. The node(s) will return a Data packet that contains the content with the addressed name. Data packets are signed by the content source with its key so that the consumer and any network node can check the packets authentication and integrity. As a result, NDN natively overcomes many conventional security attacks [11] and represents a valid alternative to other security frameworks (e.g., [12]). The Interest processing at each NDN node involves three tables: (i) the _Content Store_ (CS) that is used to cache incoming Data packets; (ii) the _Pending Interest Table_ (PIT) that keeps track of all incoming unsatisfied Interests with the related incoming node's interfaces (named _faces_ in NDN terminology); and (iii) the _Forwarding Information Base_ (FIB) that records, per each name prefix, one or more outgoing faces for the Interest packets forwarding. The FIB can be dynamically populated by a routing protocol [13]. Specifically, at the Interest reception, a node \(N\) first looks up in its CS for a matching content. If it is found, then the cached Data packet is returned to the consumer. Conversely, \(N\) looks up in the PIT for the same pending request. If a PIT entry for the same content already exists, then it is updated with the new incoming face and the Interest is discarded; otherwise, a FIB look-up is performed. If a matching is found in the FIB, then the Interest is forwarded towards the next hop(s) through the face(s) stored in the FIB, otherwise it is discarded. As soon as a node owning the content is reached, the Data packets follow the chain of PIT entries back to the consumer(s). Data packets can be cached by en-route nodes and made available for future requests. Two main decision engines are implemented at the NDN forwarding plane that may affect the data retrieval performance:  
* _The forwarding strategy_ permits each NDN node to take actions related to the Interest forwarding, specifically to decide if, when and where forwarding the packet. Depending on the application requirements, the strategy may prioritize the delivery of certain packets or even transmit them in parallel over multiple interfaces. In the case of transmission over a wireless medium with access procedures managed in a distributed manner, the node may defer the packets in order to limit the collision probability with other potentially transmitting nodes. In the case that no route is available in the FIB, it may issue a negative acknowledgement (NACK) message indicating the error type toward the previous node. * _The content caching/replacement strategy_ permits each NDN node to decide whether to cache the incoming Data packet(s) and which buffered packets to replace in the case the CS is full. The simplest and most intuitive cache-and-replacement strategy implemented in NDN is cache-everything-everywhere with Least Frequently Used (LFU) replacement. This means that _all_ nodes cache _all_ Data packets and replace the least requested ones.