## 4 Performance Evaluation and Comparative Analysis
### Simulation Scenario  
Most of the works on caching in NDN used simplistic topologies of a few nodes, which cannot represent an IoT environment. For our simulations, we rather opted for the Transit Stub (TS) network structure, whose properties closely mimic those of a wide-area IoT. The used TS is a 3-level hierarchical topology of interconnected stubs and transit domains. The stubs transport either originating or terminating traffic. The transit domains, however, are intended to efficiently interconnect the stub domains. The TS topology has been used to represent named data networking of things in works such as [10,24,29]. We used the BRITE library for ndnSIM to generate a TS topology integrated within the ndnSIM simulator [40,41].  
Figure 4 illustrates a graphical example of a 3-level TS topology. The internal green-colored nodes are level 0 backbone routers to which are connected 2 transit domains comprising level 1 nodes colored in yellow, and finally the stubs containing blue- and red-colored nodes. The actual network topology used in our conducted simulations is composed of around 632 nodes in total: a core domain containing 2 level 0 backbone routers, 2 transit domains each containing (on the average) 15 level 1 backbone routers, and 30 stubs per transit domain each containing (on average) 10 routers. Each stub is either connected to 1 or 2 transit nodes. Consumers are connected to nodes of the stubs in one transit domain, while producers are connected to nodes in the stubs or the other transit domain. Twenty producers are spread randomly across the 30 stubs of a transit domain, and 30 consumers each attached to a node in only 3 out of the 30 stubs on the other transit domain.  
We used a large catalogue of half a million data. This content is assigned uniformly to the 20 producers so that each producer is the home of twenty five thousand pieces of data content. At each producer, the data content is divided into one unpopular group and zero or more popular groups. This serves to create a mix of popular and unpopular flows within the network and investigate the influence of the unpopular group traffic on the performance of the studied caching strategies. Requests for data content (i.e., Interests) are generated for each group and each consumer according to a Poisson distribution. However, the requested data content is either selected randomly if it belongs to the unpopular group or selected according to a Zipf probability distribution if it belongs to a popular group. The cumulative submitted traffic rate to the network depends on the number of data content groups used in the simulation. The traffic rate submitted per consumer is defined as the number of requests submitted per second per consumer and denoted by \(\lambda_{c}\). The traffic rate per consumer per group of data content is denoted by \(\lambda_{g}\).  
We shall investigate the effect of the cache size on the performance of our selected caching strategies. However, nodes within the network are assumed to have the same constant cache size. The popularity table adjustment and smoothing process is performed periodically each freshness period using EWMA. The simulation parameters that have been used are summarized in Table 1. The question remains as to the value at which to fix the popularity threshold of PF-ClusterCache. Recall that we are using a large catalogue size of half a million content. As such, the chance to request the same content more than once within its freshness period is considerably low, unless the content is popular. As a result, we fix the PF-ClusterCache popularity threshold to 2. Interestingly, the used LPF replacement technique is forced to retain the most popular data content in the caches. Recall that LPF evicts content from the CS if it only has a lower popularity count than the new arriving candidate.  
Figure 4: Transit Stub topology used in the simulation.