# Underwater Electromagnetic Sensor Networks, Part II: Localization and Network Simulations
## 4 Simulation of a Complete U-WSN
### Scenarios under Test
#### 4.3.2 Diffusion Unicast Transmission with ACK  
In this scenario, we simulate a complete network of 21 nodes, which are deployed over a field of \(105\,\mathrm{m}\times 30\,\mathrm{m}=3.150\,\mathrm{m}^{2}\) in a three-row by seven-column grid, so that contiguous and diagonal nodes in the same row or column are separated \(15\,\mathrm{m}\) and \(21.2\,\mathrm{m}\), respectively; see Figure 10. The nodes only communicate with their neighbors (see Figure 10), as if they were performing an iterative distributed algorithm (like those presented in Section 3.1).  
We use acknowledged unicast transmissions. This means that every node has to discover its neighbor nodes. We use the collection-tree-protocol (CTP) [28; 29; 30], since it offers an MAC with an ACK layer and an efficient mechanism for neighborhood discovery. CTP has been implemented in several operating systems (e.g., TinyOS, Mantis OS, Contiki OS, Sun SPOTs). It is also offered by Castalia [31] as a set of routing and MAC modules. We remark that for the Castalia implementation of CTP, the neighborhood discovery mechanism is only available for routing tasks. Therefore, we have extended the current CTP implementation so that this neighborhood discovery mechanism can be used for diffusion, as well. We followed the following steps to extend CTP:  
1. Create an extra field in the routing packet that accounts for the address of the destination neighbor.
2. Extend CtpForwardingEngine::encapsulatePacket to account for the new field.
3. Include in CtpForwardingEngine::event_SubReceive_receive the case where the node that receives the packet is the destination neighbor, so that it passes the packet to the application layer instead of forwarding it to its parent.  
This extension should be also useful for simulating more complex scenarios, where nodes perform a distributed algorithm and also transmit data to the sink, combining autonomous and external monitoring.  
When using unicast transmissions, the nodes have to transmit and receive as many packets as neighbors per iteration. In order to minimize congestion, we have modeled an asynchronous algorithm in which, at every iteration, every node transmits its packet to all of its neighbors, waiting some time (named unicast period) between each unicast transmission (i.e., the waiting time before transmitting the same information to the following node in its neighbors' table). Then, once the current packet has been transmitted to all of its neighbors, each node waits some extra time (named contention period) before starting another iteration. This contention period allows enough retri  
Figure 10: Diffusion scenario.  
Figure 9: Successfully received packets vs. distance (m).  
the latest iteration can be acknowledged. Thus, the time between consecutive packets for node \(i\) is given by:  
\[T_{i}^{\text{uni}}=t_{\text{u}}N_{i}+t_{\text{c}} \tag{12}\]  
where \(t_{\text{u}}\) is the unicast period, \(t_{\text{c}}\) denotes the contention period and \(N_{i}\) is the number of neighbors of node \(i\).  
Figure 11 shows the percentage of successfully received packet vs. unicast period for different contention periods. We have observed that for unicast period 50 s and contention period 30 s, the received packet rate is greater than 91.6%, achieving 98% for 90 s of the unicast period. These long periods are required for low data rates and dense deployments.  
We conclude that, although reliable communications are possible using unicast transmissions, it takes a long time to transmit packets safely. The reason is that, since the data rate is low and each node has to transmit the same information to each of its neighbor, the collision probability is high. In addition, multiple collisions imply multiple retransmissions, which also implies high energy consumption, especially when the transmit power is high.