# Popularity-Aware Closeness Based Caching in NDN Edge Networks
## 3 PaC-Based Caching
### Tracking Content Popularity  
Similarly to other schemes [6; 10; 11; 13], the edge nodes track in the Popularity Table the received requests in order to identify the most popular contents.  
Basically, the ingress nodes (green devices in Figure 2) counts the Interests received from consumers they are connected to, in order to determine the average request rate of each content. At the ingress node \(v_{j}\in I\), the average request rate for content \(x_{n}\) is denoted as \(R_{v_{j}}(x_{n})\).  
The node periodically updates the average request rate, with a time interval \(T\) set to one minute, similarly to [13], to properly infer potential changes in the request patterns. Therefore, we assume each entry in the Popularity Table includes three fields: content name, average request rate, and current counter of requests.  
In our design, the ingress nodes are also in charge of identifying the most popular contents that should be cached along a delivery path. More specifically, a content is considered popular by the ingress node \(v_{j}\) if it is requested a higher number of times than a popularity threshold \(\Theta_{P}\). This latter is computed as the EWMA of the average request rate per each requested content:  
\[\Theta_{P}=(1-\alpha)\Theta_{POld}+\alpha\overline{R_{v_{j}}}, \tag{2}\]  
with  
\[\overline{R_{v_{j}}}=\frac{\sum_{n=1}^{M_{v_{j}}}R_{v_{j}}(x_{n})}{M_{v_{j}}}, \tag{3}\]  
with \(M_{v_{j}}\) being the number of distinct contents requested during the last time interval \(T\), as perceived by node \(v_{j}\), and \(\alpha\in(0,1)\) set to 0.125 to avoid large fluctuations in the computation and give relevance to the historical values.  
Because the Interest aggregation in the PIT hides the actual number of consumers requesting the same contents, a specific signalling mechanism is deployed to let intermediate nodes effectively track the request rate. More specifically, each time an ingress node \(v_{j}\) forwards an Interest for content \(x_{n}\) to the next on-path node \(v_{i}\), it includes the average request rate information in the rate field. Of course, the same edge node \(v_{i}\) can be in multiple shortest delivery paths towards the same content. For instance, node \(v_{4}\) in Figure 2 is traversed by two shortest paths from the ingress nodes \(v_{8}\) and \(v_{9}\). Instead, node \(v_{2}\) is traversed by three shortest delivery paths from the ingress nodes \(v_{8}\), \(v_{9}\), and \(v_{10}\).  
We denote as \(\hat{I}_{i}(x_{n})\subset I\) the set of ingress nodes forwarding Interests for content \(x_{n}\) to \(v_{i}\). In other words, \(v_{i}\) belongs to the shortest paths connecting the ingress nodes belonging to \(\hat{I}_{i}(x_{n})\), which receive the requests from the consumers, and the egress node towards the origin source. Since NDN implements only on-path caching, \(v_{i}\) is a candidate cache for a content \(x_{n}\) for which requests are received by ingress nodes in \(\hat{I}_{i}(x_{n})\). For instance,  
Figure 3: Overhauled NDN packets (fields with text in orange are those added by the PaC-based caching).  
a content cached at \(v_{2}\), in Figure 2, may serve the requests coming from the three ingress nodes, \(v_{8}\), \(v_{9}\), \(v_{10}\).  
The intermediate node \(v_{i}\) (e.g., \(v_{4}\) in Figure 2) collects the \(R_{v_{j}}(x_{n})\) values from the Interests received through the incoming interfaces and calculates the local average request rate as:  
\[R_{v_{i}}(x_{n})=\sum_{j\in\hat{I}_{i}(x_{n})}R_{v_{j}}(x_{n}). \tag{4}\]  
When re-transmitting the Interest packet, \(v_{i}\), in its turn, overwrites the rate field with the new cumulative value, thus the next-hop node will be aware of the average number of requests that can be satisfied with a Data packet over that incoming interface. The next-hop node (e.g., \(v_{2}\) in Figure 2) also calculates the cumulative request rate, and so on.