## 5 Performance Evaluation
### Simulation Settings  
We use various network topologies that are generated based on the real map obtained from the Google Earth as follows. First, we extract from the maps around the Amazon ten regions which contain obstacles, and embed each them into a 1000 m \(\times\) 1000 m network area. Then, for each network area, we randomly scatter about 4000 nodes by dividing the network into \(63\times 63\) square grid and in each square, we put one sensor in a random position. Finally, we remove all sensor nodes that stay inside the obstacles. Please note that we have also performed the simulation with various settings concerning the network size, the number of sensors, etc., We observed that the results obtained in all the scenarios have similar trends. Thus, in this paper, we present the results of a particular case.  
Figure 7 shows the real images obtained from the Google Earth. From these images, we create six network topologies for 1-n communication (multiple sources vs one destination) (Figure 8) and other sixes topologies for n-n communication (multiple sources vs multiple destinations) (Figure 9). There are total 120 source-destination pairs which are randomly chosen to intersect with the holes.  
Figure 8: Network topologies for 1-n communication. (**a**) Topology 1. (**b**) Topology 2. (**c**) Topology 3. (**d**) Topology 4. (**e**) Topology 5. (**f**) Topology 6.  
Figure 7: Real maps obtained from the Google Earth. The black regions represent the lakes [38]. (**a**) Region 1. (**b**) Region 2. (**c**) Region 3. (**d**) Region 4. (**e**) Region 5. (**f**) Region 6.  
The simulated time is 2000 s. The first 400 s is for network setup and the remaining 1600 s is for data forwarding. In the network setup phase, the nodes broadcast HELLO packets which contain their own location information. In LVGR and BSMH, the network setup phase is also for locating and disseminating information of the holes and the forbidden areas. The plotted values are the average of 10 simulation runs along with 95% confidence interval. The experiments are conducted using the NS-2 simulator and on a computer with an Intel Core i5-4570 3.2 GHz \(\times\) 4 CPU and 8 GB of RAM, and running Ubuntu 14.04 64-bit. The MAC protocol, interface queue model, radio model, antenna type, queue length, transmission range are set to the default values of NS2. To study the energy consumption of the protocols, we used the energy model suggested by [PERSON] et al. [55]. Specifically, the power supply is set to 3 V, the currents regrading idle state, receiving state and transmitting state are set to 3.2 mA, 15 mA and 21.5 mA, respectively. Accordingly, the per second energy consumption with respect to idle state, receiving state and transmitting state are 9.6 mW, 45 mW and 88.5 mW, respectively. The initial energy of all node is set to 30 J to ensure that the network lifetimes achieved by all protocols are smaller than the simulated time. As the maximum size of a packet following 802.15.4 standard is 127 bytes, if the packet size exceeds 127 bytes, there will be multiple packets sent. Therefore, the data packet size should be set to less than 127 bytes. We have conducted the experiments with the data packets size of 50 bytes and 100 bytes and found that the trend of the results does not depend on the data packet size. Therefore, in the following, we set the size of all data packets to 50 bytes. The fragmentation threshold of the control packets is set to the default value in NS2, i.e., 1000 bytes. When the size of a control packet exceeds the fragmentation threshold, it will be fragmented into multiple packets. Table 1 summarizes the parameters used for the sensor nodes.  
Figure 9: Network topologies for n-n communication [38]. The blue circles represent the sensors. The red diamonds represent the sources and the blue triangle represents the destination. (**a**) Topology 1. (**b**) Topology 2. (**c**) Topology 3. (**d**) Topology 4. (**e**) Topology 5. (**f**) Topology 6.