# UCMAC: A Cooperative MAC Protocol for Underwater Wireless Sensor Networks
## 4 Operation of Proposed Protocol
### Channel Reservation Phase  
The source begins with the channel reservation by sending a _request-to-send_ (RTS) to the destination, which contains the propagation delay between source and destination, \(\tau_{\text{S,D}}\). Overhearing the RTS, a neighbor \(n\) determines whether it is an eligible cooperator based on the following criteria:  
\[\tau_{\text{S,$n$}}<\tau_{\text{S,D}}\text{ and }\tau_{\text{n,D}}<\tau_{\text{S,D}} \tag{1}\]  
\begin{table}
\begin{tabular}{c c} \hline \hline
**Symbol** & **Description** \\ \hline \(T_{x}\) & Transmission time of a packet \(x\)1  \\ \(\tau_{i,j}\) & Propagation delay between nodes \(i\) and \(j\) \\ \(\tau_{\text{max}}\) & Maximum propagation delay \\ \(\tau_{\text{C}^{i}}\) & Backoff time of a cooperator \(j\) \\ \(N_{\text{noop}}^{\text{max}}\) & Maximum number of cooperators allowed in one session \\ \(d_{\text{delay}}^{\text{S}}\) & Delay of DATA transmission at a source \\ \(d_{\text{w\_x}}^{i}\) & Duration that a node \(i\) waits for reception of a packet \(x\)1  \\ \(\text{N}_{\text{coop}}\) & List of cooperators recognized by a source \\ \(\text{N}_{\text{neg}}\) & List of potential RTC-CTS collision-causing neighbors \\ \hline \hline \end{tabular}
\end{table}
Table 1: Notations used to explain UCMAC.  
Figure 2: Basic procedure of UCMAC.  
This means that the cooperator should be closer to both the source and the destination than the source-to-destination distance. Accordingly, the _cooperative region_ is defined as the area where eligible cooperators may exist, as shown in Figure 3. Every neighbor \(n\) that resides in the cooperative region sends a _request-to-cooperate_ (RTC) containing \(\tau_{n,\text{D}}\), while the destination sends a _clear-to-send_ (CTS) back to the source in response to the RTS. Then, referring to the RTC, the source builds a list of cooperators, \(\mathbb{N}_{\text{coop}}\), which is sequenced based on their closeness to the destination. To prevent excessively long operation time resulting from the participation of the cooperators, the number of cooperators included in \(\mathbb{N}_{\text{coop}}\) is limited by \(N_{\text{coop}}^{\text{max}}\). Supposing \(\tau_{\text{C}_{2},\text{D}}\) is smaller than \(\tau_{\text{C}_{1},\text{D}}\) in Figure 3, the destination gives selection preference to C\({}_{2}\). If the retransmssion of C\({}_{2}\) also fails, the retransmission continues through the next most preferred cooperator, C\({}_{1}\), in this example. If no available cooperator exists, then the conventional MACA-U protocol works.  
RTC and CTS, the responses to the RTS from cooperators and the destination, respectively, may collide at the source. Figure 4a shows examples of RTC-RTC and RTC-CTS collisions. RTC-CTS collisions are significantly more severe than RTC-RTC collisions; they trigger the whole procedure to restart from the beginning. To avoid RTC-CTS collisions, we prohibit the neighbors that may cause collisions from transmitting RTC. Based on the pre-acquired knowledge regarding propagation delay information, the source builds a list of potential RTC-CTS collision-causing neighbors, \(\mathbb{N}_{\text{neg}}\), and includes it into RTS. Then the neighbors included in \(\mathbb{N}_{\text{neg}}\) are banned from sending RTC. In Figure 4b, C\({}_{3}\) represents a case of RTC transmission prohibition so that CTS can escape a collision at the source. Meanwhile, RTC-RTC collisions can be alleviated by implementing random backoff times.  
Figure 4: _Cont._  
Figure 3: Cooperative region.