# ndInIoT-FC: IoT Devices as First-Class Traffic in Name Data Networks
## 5 Performance Evaluation  
To evaluate the proposed publisher-subscribe mechanism, we will focus on the burden caused by network overhead according to the different use cases previously described, in which both Data providers and content subscribers are non-mobile and are connected through various intermediate nodes. The simulations, carried out using the NDNsim framework, were performed throughout a five minutes period, during which subscribers would notify the network of their interest in a certain content via an Interest packet, which remains in PIT tables for 15 seconds, time after which the entry will expire (subscriber methodology). In case a subscriber still requires the content after this period, a new Interest is issued to update the existing PIT entries. On the other hand, publishers will react to incoming Interest events, by sending content every two s. These parameters are illustrated in Table 1, as well as the network topology considered, depicted in Figures 8-10. The number of packets counted in each use case is retrieved by registering every occurrence of a received/sent Interest/Data packet during simulation for each of the 15 nodes considered and performing a sum of the values of all nodes registered according to their type (e.g., Sent Data packets). This allows us to understand metrics such as the network overhead and how much unnecessary traffic is being propagated throughout the network. Furthermore, as no acknowledgements exist, we can calculate how many Interests are generated by each subscriber node, by knowing the total simulation time, which was 5 min, and the rate of Interest retransmissions. For the native case, every Interest transmission was set at 2 s, which means that every consumer node will generate 150 Interests to the network for each subscribed service; in the pub-sub case, retransmission of persistent interests was set at 14 s, meaning that every subscriber node will renew each content 21 times, thus, generating 22 packets towards the network for a given service. A comparison will be made between the native NDN forwarding, in which one Data packet refers to an Interest, and the publisher-subscriber mechanism described in Section 3, given that caching will need to be disabled, as we aim to evaluate scenarios in which data is volatile, and therefore should not be stored locally. Lastly, we study the impact aggregation can have in PIT table sizes, and how they can improve performance. Table 2 describes the number of nodes and their types across all the Use Cases, from a global count of 15 nodes comprising the network topology. In both variants of Use Case 1, the evaluation of each strategy was done separately, so it makes sense that same nodes were selected across both simulations, in order to guarantee that results obtained are valid and able to be compared, the difference being that in the first variant only a single node is considered as publisher, whereas the second scenario was scaled to have three different publishers. The remaining Use Cases, 2 and 3, refer to a scenario in which both the native NDN and proposed pub-sub were coexisting. In the former, each of the two available applications were installed in a pair of nodes, meaning that four different entities will be servicing either pub-sub or native requests at any given time, with the remaining ten nodes acting as intermediate and forwarding packets between each end-point. As for the latter, each of the four previously selected content delivery nodes will act in behalf of both strategies, which means they will satisfy both native NDN and pub-sub services \begin{table}
\begin{tabular}{c c c c} \hline \hline \multicolumn{1}{c}{**Subscribers**} & \multicolumn{2}{c}{**Publishers**} \\ \hline Entry Lifetime (LifeT) & 15 s & Data Generation & On Wake Up \\ Interest Retransmission & LifeT-1.0 sec & Transmission Interval & 2 s \\ Cache Size & 0 & Cache Size & 0 \\ Installed Technology & Ethernet & Installed Technology & Ethernet \\ Mobility & Fixed & Mobility & Fixed \\ \hline \hline \end{tabular}
\end{table}