# Dynamic Cooperative MAC Protocol for Navigation Carrier Ad Hoc Networks: A DiffServ-Based Approach
## 4 DiffServ-Based Dynamic Cooperative MAC Protocol
### MAC Sub-Protocol for on-Demand Communication
#### 4.2.1 Negotiation Phase  
The negotiation phase aims to handle the pairs of three scenarios. **Scenario 1** is intra-cluster transmission, where both the sender and receiver are members of the same cluster; additionally, the pair pre-stores their prior knowledge of each other by PE packet (e.g., CSI, ID, and azimuth). **Scenario 2** is inter-cluster single-hop transmission, where the receiver and sender are not located at the same cluster, but are located in direct range of each other. **Scenario 3** is inter-cluster two-hop transmission, the receiver is located between one-hop and two-hop range of the sender. These scenarios will be our basis for the negotiation policy.  
First, a rule for channel switch sequence, namely, adaptive channel back-off sequence (ACBS), will be encoded in RTS and CTS. The proposed ACBS is to detect and eliminate the threats in congested network. The ACBS is generated by the negotiation of the sender and the intended receiver based on prior knowledge, e.g., channels' idle probability, ID, and azimuth. When encountering collision among pairs, ACBS can act as a reference for the lower prior pair to switch among data channels directly without additional negotiation packets, thus effectively curtailing the process and improving the utilization rate of the medium. The negotiation phase of Scenarios 1 and 2 is depicted in Figure 4, with the details as follows:  
Suppose that the sender \(s_{i}\) has an OC request to the intended receiver \(r_{i}\), sender \(s_{i}\) will first sense the medium. If the medium is busy, sender \(s_{i}\) will postpone the negotiation and keep sensing. If some channel is idle, sender \(s_{i}\) will arrange the idle probability of the channels according to prior knowledge during the carrier sense, denoted by \(h_{s_{i}}\), encode it into RTS, and then initiate the negotiation phase.  
In Scenario 1, sender \(s_{i}\) has prior knowledge of receiver \(r_{i}\) before sending RTS, and thus can select an idle channel, and sends a RTS to receiver \(r_{i}\) through the _idle frame_ of both \(s_{i}\) and \(r_{i}\). If the PF of \(r_{i}\) is \"00\" and without other OC requests, \(r_{i}\) will receive the RTS, and decode the information of \(s_{i}\), i.e., the service's type, data packet size, ID, and \(h_{s_{i}}\). Thereafter, this information and the prior knowledge of receiver \(r_{i}\) (denoted by \(h_{d,i}\)) will be used to generate an ACBS for the pair (\(s_{i}\), \(r_{i}\)), encoded in CTS, and then reply to \(s_{i}\). Both RTS and CTS are sent in DT-OR mode. If the PF of \(r_{i}\) is \"00\" but with other OC requests, receiver \(r_{i}\) will sense the collision, and broadcast a warning packet, namely WARN, in order to prevent the sender from transmitting the above packet and notifying sender to switch channel immediately. Then, the senders will postpone randomly according to service priorities, and compete for the right of channel access again.  
In Scenario 2, sender \(s_{i}\) has no prior knowledge of the intended receiver \(r_{i}\) except for its ID. Then \(s_{i}\) sends a RTS in OT-OR mode. If PF of \(r_{i}\) is \"00\" when RTS reaches it, the pair (\(s_{i}\), \(r_{i}\)) then performs the same procedure as in Scenario 1. If PF of \(r_{i}\) is \"01/11\", \(r_{i}\) will send a WARN packet, sender \(s_{i}\) will postpone for a duration according to WARN, and will compete for the channel access rights again.  
Figure 4: State diagram of Scenarios 1 and 2 in the negotiation phase.  
If sender \(s_{i}\) does not receive CTS after a time threshold, then it switches to the next data channel according to \(h_{s,i}\), and sends RTS again.