# Logically-Centralized SDN-Based NDN Strategies for Wireless Mesh Smart-City Networks +
## 4 Experimental Evaluation
### Experimentation Setup  
Here, we present the most important experimentation details of both scenarios. The NDN implementation is based on the containerized Named data Forwarding Daemon (NFD) [34], developed in Docker containers [35] since it is lightweight, easily reconfigurable, and facilitates the NDN deployment on any hardware. Moreover, we use the better approach to mobile ad-hoc networking (BATMAN) [28] wireless mesh routing protocol.  
The multi-hop network topologies consist of wireless network nodes (Intel NUC devices) of the w-iLab.1 testbed. The nodes are equipped with an AR9462 wireless network adapter that we used to construct our wifi mesh network. We used the ath9k driver and configured these devices to run at 2.4 GHz with 20 MHz channel width in mesh mode. Moreover, we use a separate 802.11 wireless channel for the control messages (i.e., for the communication of the controller with the NDN nodes,) which is in mesh mode and uses the ath10 driver.  
Regarding the performance measurements of the wireless links (i.e., RSSI and delay) utilized in the clustering process, we use wireless connectivity (among all nodes of the network) based on a Peer Link Management protocol, which is used to discover neighboring nodes and keep track of them. Here, the neighbor discovery is only limited to the signal range of each node. The evaluation is based on _Ping_ tool by sending a batch of 100 ICMP packets every 3 s. As illustrated in Figure 4, the results present: _total_ completion time--the total time to communicate of the 100 packets (we use a 2-s threshold waiting for each batch to complete. If the time is exceeded the particular batch is considered undelivered); _PLR_--the percentage of ICMP packets loss (i.e., out of 100); _avg_--the average Round Trip Time (RTT) of the ICMP packets; _sd_--and the Standard deviation RTT of the ICMP packets. The _RSSI_ measurements are recorded from a second interface on each wireless node (the first interface was in mesh mode and was used for sending the ICMP packets), which is in monitor mode and uses the same driver. The performance measurements were collected from the w-iLab.1 testbed [18], utilizing the above method, are provided in [19].  
Finally, the use case under consideration is an IoT scenario, where an IoT NDN Consumer requests sensor measurements from an IoT NDN Producer, that generates emulated sensor measurements. Here, focus on two IoT applications with different requirements: (i) short flows with delay demands, assuming a typical sensor measurement application, i.e., the produced data packets have a limited size (350 Bytes) and represent raw sensor measurements (e.g., temperature, humidity, etc); and (ii) long flows with throughput demands, assuming photo file transfers with a limited size (1 Mb). In the short flows, the emulation of Consumer and Producer applications are based on the _ndupeek_ and _ndupoke_ tools, respectively, and for the long flows emulation, we use the _nducatchunks and nduputchunks_ tools to transfer files as data segments. Moreover, to measure NDN connectivity failure attempts, we have disabled NDN retransmissions for the short-flow application.