# EmuCD: An Emulator for Content Dissemination Protocols in Vehicular Networks
## 5 EmuCD in Action
### EmuCD Validation  
This section presents the validation of EmuCD against a real vehicular network, when running a content distribution protocol. This validation is performed with the content distribution protocol InterPlanetary File System (IPFS) [24]. IPFS is a decentralized, peer-to-peer distributed file system [24]; it can be seen as a single BitTorrent swarm exchanging objects within one Git repository, providing a content-addressed block storage model. As far as we know, IPFS has never been tested in a VANET before, so it was tested not only in our emulator, but also in a small subset of a real VANET. Despite the OBUs running a custom version of OpenWRT and EmuCD's Docker containers Ubuntu, it is exactly the same code/software running on both: what runs in the real boards is what runs in the emulator. This VANET is located in Oporto city [25] from which data traces were collected to build the dataset used in the emulator. This dataset considers both mobility traces and connectivity traces between VANET nodes. A small 5-node subset of this VANET was made available for testing in real conditions with Veniam's (Veniam, The Internet of Moving Things-[[https://veniam.com/](https://veniam.com/)]([https://veniam.com/](https://veniam.com/))) support. In this section we consider the validation metric the progress rate (average of the content's download progress across all OBUs) over time, when running IPFS in a real VANET and in the EmuCD. We consider three different use cases for the validation with one seeder and four OBUs: Scenario (1) a fast content dissemination, where the nodes are close neighbours (not only spatially but also temporally) with contact times long enough for data transfers to occur; Scenario (2) a medium-speed content dissemination, where the nodes are occasionally in each other's neighbourhood but, contact times are not enough for the file to be fully transferred between two OBUs, requiring multiple contacts and taking potentially hours until the data are distributed across every node; Scenario (3) long content dissemination, where some OBUs are very far away from nodes with useful data (e.g., non-overlapping bus routes), and it can take a full day or longer for the content to reach every node. Figure 9 compares the progress rate of a IPFS file of 50 MB in Scenario 1. Figure 8: RAM usage of BitTorrent during a stress test, 100 nodes, 50 MB file. The graph shows that the results are similar, with only a few seconds of difference in some parts and fully distributing the content to every node within 175 s, but there are some important observations to be made:  
* the emulator graph only shows straight lines during data transfers, whereas the real VANET's graph has more granularity and variance-in the real VANET there is more than connectivity information, such as interference, leading to an inconsistent throughput, which ranged from under 0.5 MB/s up to 2.8 MB/s; EmuCD sets a 2 MB/s upload and download fixed limit on the wireless interfaces, which was observed to be the average in initial lab tests with the hardware;
* the emulator graph reached 50% progress 10 s earlier than the real VANET, it accompanied the VANET in the second dissemination period and fell 8 s behind the real VANET in the final dissemination period--this can happen because of several factors, but the most probable one is the connection establishment time, which is not negligible in ad-hoc networks. The emulated scenario did not replicate this, it only added/removed IP addresses from the OS's routing table. Figure 10 shows the comparison between IPFS distributing a 50 MB file in a five node real VANET and in an emulated five node VANET in Scenario 2. The emulator had very close results when compared with the VANET, albeit with lower accuracy, namely in the first 300 s where in the real test the transfer slowed down but in the emulator it kept going, arriving at 50% content dissemination earlier than it should.