## 3 Proposed C-HARQ Protocol Design
### Scheme Description  
We now proceed to describe the C-HARQ protocol of error-control for data transmission from a particular source to a destination. The scheme works in the following subsequent phases:  
1. Transmission of _Pac_-0 by Source. 2. Discovery of available Cooperative nodes. 3. Cooperation process. 4. Transmission of _ACK/NACK_ by Destination. Phases 2 and 3 come into play only when an error is detected at the destination. As mentioned earlier, the source is not involved in any convolution encoding process. The source is only concerned with sending/resending the current or the next data packet, from its packet buffer, depending on the type of acknowledgement received from the destination. Encoding process is required only at the _CNodes_ to generate the FEC packets using the overheard _Pac_-0. The source starts Phase1 by transmitting the _Pac_-0 that is present at the top of its packet buffer, to the destination. This transmission, which is a broadcast in nature, is also overheard by the _CNodes_. The _CNodes_ individually compute CRC to check for errors in the overheard _Pac_-0. Those _CNodes_ which correctly receive _Pac_-0, encode it into _Pac_-1, _Pac_-2_..._Pac_-_N_\({}_{\textit{mr}}\), and saves them at the top of their  
Figure 3: Final Link Layer Packet Format. Figure 2: Packet Generation. individual packet buffer, to become \"_available\"_ for cooperation. Other _CN Nodes_ discard the erroneous overhearing and remain silent. Meanwhile, at the destination end, error detection is applied to the received _Pac_-0 and steps are taken accordingly:  
_No Error_ in received Pac-0:  
Phase 2 and 3 are skipped and an _ACK_ is immediately sent to the source by destination. Upon overhearing _ACK_, the _CN Nodes_ drops the current FEC packets from the top of their packet buffer:  
_Error detected in received Pac-0:_  
Destination saves the erroneous _Pac_-0 in its packet buffer as _saved_Pac_-0 and enters Phase 2 by broadcasting a \"_Request for Cooperation_\" (_C\({}_{Req}\)_) signal. Prior to the broadcast, the destination initializes enough memory space in its packet buffer for the upcoming FEC packets meant for error correction. On overhearing the _C\({}_{Req}\)_ signal, the source continues to remain in \"_idle_\" mode waiting for an _ACK or NACK_ signal to respond to. By doing so it temporarily leaves the responsibility of recovering _Pac_-0 to the cooperation process. In our system model, we have assumed that a node operates in _idle_-mode when it is involved in none of the following activities: transmitting, receiving or convolution decoding. Meanwhile, the available-_CN Nodes_ respond to _C\({}_{Req}\)_ by individually transmitting the \"_Availability for Cooperation_\" (_C\({}_{Avl}\)_) signals to the destination. To make the collisions of _C\({}_{Avl}\)_ less likely, a proper media access protocol (like a Random Back-Off algorithm) can be used here. However, for our performance analysis, this probability of collision is neglected due to the very small size of _C\({}_{Avl}\)_ and location of _CN Nodes_ at a random distance from the destination. The destination, after transmitting _C\({}_{Req}\)_, waits for a maximum of \"_Tc_\" amount of time to allow all the availability signals to reach the destination before the commencement of the cooperation process. The value of \"_Tc_\" is set to twice the source-to-destination propagation delay so that the _C\({}_{Avl}\)_ signals, even from the farthest _CN Nodes_ (located at a distance of source-to-destination distance from both the source and the destination), have enough time to reach the destination. Upon expiration of this waiting time, the destination saves all the received _C\({}_{Avl}\)_ signals in a list, called the \"_Look-Up_\" list. This list is mainly used to select or look for the current or the next available-_CN Node_ during the cooperation process. Prior to the cooperation process, the destination applies a predefined selection criterion to sort the list in a particular order.