# Context-Aware Pending Interest Table Management Scheme for NDN-Based VANETs
## 3 PIT Management in NDN-Based VANETs  
The PIT data structure contains information about Interests currently pending, its outgoing interfaces from where the data are yet to be received and the incoming interface that has not yet been served. In other words, PIT is held accountable to store the content name and other important information components of the Interest, for which no Data message has been received yet. It also contains information about recently satisfied Interests. PIT Entry (PITE) is a set of InRecords and a collection of \(OutRecords\). \(InRecord\) and \(OutRecord\) comprised a set of attributes such as Nonce, reference to the face, and the timestamp at which the Interest arrives [12]. \(PITE\) is identified by the Interest name. Interest is uniquely identified by combining two fields: name and Nonce. Nonce is a random number generated by the consumer vehicle and inserted in the Interest header. The \(InterestLifetime\) field in the Interest packet controls the expiration of the Inrecord. If \(InterestLifetime\) is not specified, the value 4 s is used as the default. If an Interest is not satisfied within the \(InterestLifetime\) period, the relevant \(PITE\) is deleted [12; 13]. When \(InterestLifetime\) elapses after the last Interest packet arrives, an in-record expires. When all the InRecords expire, the \(PITE\) expires. If a \(PITE\) contains at least one unexpired InRecord, it is said to be pending. When \(InterestLifetime\) elapses after the last Interest packet is sent, an OutRecord expires. \(PITE\) is associated with an expiry timer. The \(expiry\) timer is fired when the \(PITE\) expires. When \(PITE\) lifetime is short, it becomes difficult to detect the Interest loop problem, caused by congestion or multi-path propagation. Therefore, another data structure called \(DeadNonceList\) is considered for loop detection that complements PIT. The entry deleted from PIT is stored in the DeadNoncelist for some time to address the loopback problem. The entry in the \(DeadNonceList\) comprises Interest name and Nonce. Each entry in the \(DeadNonceList\) is associated with the static 6 s time value. When an Interest is received, its Nonce and the name is checked in the \(DeadNonceList\). If the matching entry is found, the loop is suspected and the Interest is considered invalid. If a matching Nonce is not found in the \(DeadNonceList\), it searches PIT for the existing entry. If the \(PITE\) already exists, the incoming Interest Nonce is checked in the existing \(PITE\) before it is processed further. Initially, for each new PITE, the PEL is set by considering the InterestLifeTime field in the Interest. \(InterestLifetime\) is specified in the Interest packet header by the consumer before forwarding the packet. The \(PITE\) is removed when the PEL expires or the vehicle with \(PITE\) receives the required Data packet. In Vanilla NDN, the PEL default value is 4 s.  
When a new interest is received and its name matches the PITE, then its Nonce is compared to the Nonce in \(PITE\) InRecords. If the Nonce in the new Interest matches the Nonce in an InRecord with similar face, the Interest is considered a legitimate retransmission because there is no risk of a persistent loop. The Interest message is considered asa duplicate in case the Nonce matches the Nonce in an in-record of a different face. If a similar Nonce is not found, the Interest is considered as a new valid Interest. When a new valid Interest for the same name arrives, the expiry timer on the existing \(PITE\) is extended. Upon receiving Interest, if no matching \(PITE\) is found, then the cache (content store) is checked for the required content. If the required content is not in its cache, an \(InRecord\) is added with the incoming face to the PIT. Afterwards, the Interest message is forwarded and \(OutRecord\) (which represents the upstream face for the Interest) is added to the PITE.