# Receiver-Initiated Handshaking MAC Based on Traffic Estimation for Underwater Sensor Networks +
## 6 Adaptive Data Polling for Teri-Mac
### When to Poll Data  
In most of the receiver-initiated methods, due to the lack of knowledge of the current status of the intended senders, e.g., having packets to send or not, on the receiver side, receivers usually blindly decide when to poll data from the surrounding senders. Frequent data polling results in high energy consumption if the sender has few packets to transmit. The parallel reservation and packet train lose effectiveness when the data is polled too frequently. Conversely, if receivers do not request data in time, long delays will be introduced into the data transmission, which is also not acceptable in most applications. Therefore, a receiver needs to adjust the frequency of data polling in order to get an appropriate tradeoff between energy efficiency and communication latency.  
In UWSNs with a constrained power supply, high energy efficiency is preferred to extend the network's lifetime. In order to achieve a controllable performance, we set up a threshold of the control packet overhead \(E_{th}\), which is defined as the total power consumption of the control packets during the data transmission during one round handshake, and the average hop-by-hop communication delay \(D_{th}\), which is defined as the average delay for data packets waiting for transmission. For each node \(Q_{i},i\in\{1,\ldots,N\}\), where \(N\) is the total number of nodes in the network, \(Q_{i}\) will start the data request in three cases, as follows.  
* **Case 1:** If \(Q_{i}\) is the next-hop destination of the current active receiver, \(Q_{i}\) will start the data polling as soon as it can so that the packets can be forwarded to the final destination smoothly in the multi-hop communications. As shown in Figure 5, the \(RTR\) message including the \(A_{next}\) information notifies the successive node of the coming data reception. It is worth noting that the \(A_{next}\) does not indicate the dependency of Teri-MAC on specific routing protocols. When a new packet is generated or a forwarding packet is received, it is temporally stored in a queue before being sent out. The node also records the generation or reception time and the next-hop receiver's ID, \(A_{next}\) for each packet. The \(A_{next}\) information can be obtained from the routing header. When a node receives an \(RTR\) request from \(A_{next}\), all the packets with a matched next-hop ID have the chance to be transmitted in a group. Although Teri-MAC can work with most of the existing routing protocols, clustering-based routing enables better data aggregation, allowing Teri-MAC to achieve higher throughputs and better energy efficiency.
* **Case 2:**\(Q_{i}\) starts the handshake if the estimated energy efficiency \(E_{est(i)}\), which is the power consumption of control packets over the estimation of data transmission, is below the defined threshold of performance \(E_{th}\). Here, \(E_{est(i)}\) is estimated by the receiver based on the traffic estimation which is introduced in the next section. In this way, a baseline energy efficiency \(E_{th}\) can be achieved in TERI-MAC.
* **Case 3:**\(Q_{i}\) requests data from its neighbors when the time interval \(D_{i}\) since the last communication exceeds the delay threshold \(D_{th}\). In networks with a low traffic load, the waiting time to cumulate packets and achieve the desired energy efficiency becomes too long to be acceptable, since the out-of-date sensing information may become useless even if the destination is received successfully. The hop-by-hop communication delay threshold \(D_{th}\) can guarantee the maximum delay performance. In most cases, we can achieve preferable energy efficiency with a tolerable amount of delay.