# A Novel Cooperative Opportunistic Routing Scheme for Underwater Sensor Networks
## 3 Opportunistic Void-Avoidance Routing Protocol
### Beaconing Model  
We consider \(S\) as a single sink on the surface for collecting the information. Other nodes, including relay nodes and anchored nodes, can be shown by \(V=\{R_{1},R_{2},...,R_{m}\}\). Let \(m=|V|\) denote the number of nodes in \(V\). We define \(N(R_{i})\) as the set of \(R_{i}\) neighbouring nodes. Based on \(R_{i}\) members' hop count values, \(N(R_{i})\) can be partitioned as follows:  
\[N(R_{i})=L(R_{i})\bigcup E(R_{i})\bigcup H(R_{i}) \tag{4}\]  
where \(L(R_{i})\), \(E(R_{i})\) and \(H(R_{i})\) indicate disjoint neighbouring sets of \(R_{i}\) with lower, equal and higher hop count values, respectively. Each node in \(V\) locally holds a table about its neighbouring nodes and classifies them based on the partitioning criteria expressed in Equation (4). At the beginning of the beaconing process, all of the nodes in \(V\) are isolated from each other, and their hop count value is set to a maximum value, to show no connectivity with \(S\). Node \(S\) is the final destination on the surface, and accordingly, its hop count number is set to zero. In our beaconing model, node \(S\) along with all of the nodes in \(V\) periodically propagate a beacon, including their ID, depth, hop count value and all neighbouring nodes in subset \(E(R_{i})\) (neighbouring nodes with the same hop count value as the sender). Nodes with the maximum hop count value are exempted from the beaconing until they find a path to the sink. The sink node initiates the beaconing process and gradually is cascaded down to the network. The beacon interval for each node is considered as \(T_{update}\). In order to facilitate a quick convergence in the network, a node resets its beacon timer and propagates a new beacon, or triggered beacon, as soon as its hop count value is changed. A triggered beacon can subsequently initiate some new triggered beacons, gradually leading to the synchronisation of beacons. This is an issue due to periodic beacon propagation. Synchronised beacons can collide, due to long propagation delay and also the existence of hidden nodes, and cause delays and wasting of bandwidth. The beacons are not initially synchronised, but the timers across the network become globally synchronised over time. To prevent this issue, a random amount of time is added to the beacon interval at each node. This random time ranges from 0% to 20% of the determined beacon interval, \(T_{update}\). In this way, the beacon interval varies randomly in a range from \(T_{update}\) to \((T_{update}+T_{update}\times 20\%)\). Depending on the hop count value of the beacon, the receiving node decides how to deal with it. Upon receiving a beacon with a lower hop count, the receiving node updates its hop count value, holds the sender's ID in its subset \(L\) and attaches its depth, as well as all other existing IDs within the beacon to the sender entry in the table. If a node receives other beacons with the same lower value, it will also add them to the table in the same manner. Since all nodes periodically broadcast a beacon, the receiver knows all of its neighbours with a lower hop count (all next available nodes to relay the packets during the packet forwarding stage). On the other hand, when a node receives a beacon with the same hop count value as its own value, it only holds the sender's ID in its subset \(E\) and broadcasts it with the next beacon. Furthermore, the receiving node drops all of the beacons with the higher hop count value. According to the information extracted from the table, each node can form its own adjacency graph. Only nodes in the subset \(L\) are considered to be included in the graph, and other nodes, which are inaccessible by the sender, can be removed from the table. It can simply be realized by checking the beacons from which neighbours directly received by the node. Upon changing the hop count value in each node (e.g., finding a shorter path), the table is updated based on the current available path, and it sends out a beacon with a new hop count value and also resets the beacon timer.