# An Adaptive Back-Off Mechanism for Wireless Sensor Networks
## 3 Proposed Back-Off Scheme  
In order to improve the delivery performance under heavy load in WSNs, we propose a new back-off scheme to decrease the probability of data collision. In our designed protocol, the number of historical collisions is chosen as the parameter to reflect the channel status and nodes' usage of the wireless channel. This parameter is easy to acquire and can reduce the complexity of the algorithm when compared with research mentioned above. A larger collision number reflects a higher competitive level in the wireless channel, and a larger contention window is needed under this condition to prolong the access time in order to relieve the competition. In BEB, its contention window adjustment mechanism is too rough that it only depends on the data transmission status to double or halve the contention window size. On the one hand, when data collision occurs, the contention window is doubled in BEB. However, this exponential increase is too rapid when traffic load is not heavy, which leads to unnecessary delay. It is better to retard this increase process under this circumstance. If traffic load is heavy, this exponential increase in BEB can effectively avoid data collision. On the other hand, when data transmission is successful, the contention window is halved directly in BEB. It is better to refer to the last transmission, which can partially reflect channel status. Based on these core ideas, the detailed back-off algorithm is described in Figure 3.  
Figure 2: Binary exponential back-off (BEB) algorithm.  
In the algorithm mentioned above, \([]\) represents a function of getting an integral value (\([x]\) denotes the largest integer that is no more than a positive real number \(x\)). From the beginning, the contention window is set to \(CW_{\text{min}}\) as a default. Once data collision occurs during transmission, the contention window will be adjusted. In detail, if the collision number (denoted as \(i\)) is less than the first threshold (denoted as TH\({}_{1}\)), the contention window size will be calculated by Equation (2):  
\[CW=\left[CW_{\text{min}}\times\prod_{n=0}^{i-1}\left(1+\frac{\text{TH}_{1}-n}{ \text{TH}_{1}}\right)\right] \tag{2}\]  
where \(n\) is a variable ranging from \(0\) to \(i-1\). Obviously, after the multiplication, a larger collision number brings with a larger contention window size. It is worth noting that TH\({}_{1}\) is a relatively smaller constant. By adopting this formula, the window size will increase smoothly as the collision number increases. When the collision number surpasses the first threshold and is less than the second threshold (denoted as TH\({}_{2}\)), which represents a more serious competition, this formula will be abandoned and the current contention window size will be doubled in order to obtain a fast adjustment. Especially, if the transmission is still failed even when collision number has reached TH\({}_{2}\), the contention window will be set to \(CW_{\text{min}}\) directly. There are two main reasons for setting the contention window to \(CW_{\text{min}}\). The first reason is that, if a node's contention window is persistently large, it has to wait for a long time to transmit its packets. As a result, its data buffer is likely to be full. Under this circumstance, the node has to drop its upcoming packets, which is adverse for network throughput. The second reason is that this operation can balance the contention window size between different nodes, which can improve the fairness between different nodes as well as the average transmission delay. In the BEB mechanism, after a successful data delivery, the contention window size will be reset to \(CW_{\text{min}}\) regardless of the channel status. In our mechanism, the window size, after a successful transmission, will be halved if the node's last transmission is successful or will remain if its last transmission fails, considering that a sharp decrease in the contention window size will lead to a higher collision probability under a heavy network load.