## 4 Results and Discussion  
The results from the Distributed Forwarding Algorithm (DFA) were obtained using the ONE Simulator [24]. Mobility traces used for the simulation were generated by the ONE Simulator and OpenJump [25] over a map depicting the area where the GOLDFISH Colombian tests took place, as can be seen in Figures 7 and 8. The implementation of our algorithm in the ONE Simulator and the files used to run the simulations to compare it with other protocols in this scenario are available at the GitHub repository of this project [26]. Figures 9-40 show simulation results. Our Distributed Forwarding Algorithm was tested against three of the most popular and used routing algorithms in DTNs, namely, Epidemic Routing [11], Spray and Wait [12], and PROPHETv2 [9]. Simulation parameters are showed in Table 3. We tested the scenario shown in Figures 7 and 8 with different configurations, as shown in Table 4. In our first scenario, five sensor nodes (in the river) generate information messages that should be sent to the gateway (at the river bank), so it can pass them to the MAPs, and they can eventually reach the ICS. The number of nodes come from the GOLDFISH project, where there are a few nodes on the river communicating with the Gateway at the river shore, and the number of MAPs (10 mobile APs) was chosen based on the idea that there were enough transmission opportunities to take the sensor messages to the ICS and to cover a rural area of approximately 20 km \(\times\) 16 km where public transportation is scarce. In this scenario, all sensor nodes' messages should go through the Gateway; there is no direct communication from sensor nodes to MAPs. All nodes have wireless communication capabilities resembling IEEE 802.11b with 8 Mbps and a transmission range of 10 m. We also varied the movement model of the MAPs, from random networks to the network. The network is a network with 100 nodes, and the network is a network with 100 nodes. around the path to MapReduce, which means that all MAPs followed the path at different speeds in only one direction. We tested the scenario with the four protocols, with 11 different buffer sizes (from 5 MB to 1 GB), with the two movement models for the MAPs, and with five different random seeds. Each scenario ran 440 times (once per every protocol, every buffer size, every movement model, and every random seed) for one simulated week (60,4800 s) to create the results (Figures 9-24). Results are plotted for delivery rate, average delay, average hop count, and average overhead. After this, we ran another scenario setup (Scenario 2) where sensor nodes (message sources) could move randomly around all paths, creating contacts with MAPs and the ICS. In this second setup there is no need for a Gateway, since sensor nodes can communicate directly with the MAPs and the ICS. We also ran the same parameter combinations for this scenario (Figures 25-40). The 95% confidence intervals were calculated for every result and they are plotted on the figures. Results shown in Figure 9 indicate that, in this particular scenario, with low connectivity and a bottleneck node (the Gateway), DTN-based protocols can experience difficulties to deliver messages when information sources generate large messages (2 MB) at high frequency (less than 2 min between each message). The Gateway, then, becomes a mandatory path for all messages generating at the sensor nodes and seeking to reach the ICS through the MAPs. In the first scenario (Scenario 1.1, Figure 9), sensor nodes are sending 2 MB messages every 1 to 2 min, saturating the buffers and forcing nodes (probably the Gateway) to discard most messages, even with buffers over 500 MB per node. Results in Figure 13 show that when nodes generate light-sized messages (2 kB), DTN nodes can store more messages than in the previous scenario and deliver most of them.