# Underwater Electromagnetic Sensor Networks, Part II: Localization and Network Simulations
## 4 Simulation of a Complete U-WSN
### Scenarios under Test
#### 4.3.4 Network Routing Using Unicast Transmissions with ACK for Monitoring  
In this scenario, we consider the same network topology displayed in Figure 10. Nevertheless, instead of diffusing information within their neighborhoods, the nodes forward packets multiple hops until reaching a sink node; see Figure 13. In this particular experiment, every node sends 50 packets to the sink. Hence, the nodes closer to the sink have to forward multiple packets, apart from transmitting their own packets. The main application for this scenario is to collect data from the network for external monitoring.  
Figure 12: Successfully-received packets vs. asynchronous term \(\delta\) for different waiting times between consecutive packets.  
We chose the collection tree protocol (CTP) for routing packets to the sink [28; 29; 30]. CTP uses three techniques to provide efficient and reliable routing: (i) an accurate link estimator that uses feedback from both the data and control planes; (ii) the trickle algorithm [32] to time the control traffic, sending a few beacons in stable topologies, yet quickly adapting to changes; and (iii) actively probing the topology with data traffic, quickly discovering and fixing routing failures. As already mentioned in Section 4.3.2, CTP relies on acknowledged unicast transmissions for estimating the quality of the links.  
When a node is chosen as the parent from several neighbors or it must perform many retransmissions attempts, its transmission queue can be filled up with unsent packets, and further, incoming packets are dropped. Since the dropped incoming packets are never acknowledged, the link seems down for its neighbors. This kind of congestion becomes worse when nodes operate at low data rates. Although CTP is able to detect and surmount congested nodes, there is some performance limit. We have studied the average number of successfully routed packets from any node to the sink as a function of the packet periodicity. The idea is that the packet period should be long enough for every other node in the network to route its packet to the sink successfully. Figure 14 shows that the application layer should wait 60 s between consecutive transmissions in order to successfully route 93.7% of the packets to the sink, and it must wait 100 s for routing 99.8% of the packets.  
Another important metric is the time that it takes a packet from any node to be routed to the sink. This latency depends on several issues, like the number of hops in the route, whether there are congested nodes that behave like bottlenecks, packet loss and retries, etc. Figure 15 shows a latency histogram. We have observed that, for this particular scenario and packet period equal to 100 s, 46% of the received packets have latency lower than 1.8 s, 80% lower than 3.6 s, 90.8% lower than 14.4 s and 98.6% lower than 72 s.  
Figure 14: Average successfully routed packets from every node to the sink vs. packet period.  
Figure 13: Routing scenario. Example of the path followed by some packet transmitted from the node with identity 20 to the sink. Contiguous nodes are separated 15 m.  
In order to perform these simulations, we extended the default CtpTest application such that the sink could store the packet number and source ID for each received packet. This way, we were able to discharge duplicated packets (due to retransmission) and count only the packets that were successfully routed. In addition, we increased the ACK wait delay constant to 0.469 s (by setting the constant CC2420_ACK_WAIT_DELAY = 15360 jiffies) in the CC2420 Mac header file to work better with our low bit rate.  
Moreover, we set the transmit power to 40 dBm and used coherent receiver and channel coding, so that we achieved good connectivity and every node could find a route to the sink.