# Data Gathering Techniques in WSN: A Cross-Layer View
## 4 Medium Access Control (MAC)
### Duty-Cycle MAC Protocols  
Traditionally, duty-cycle MAC protocols can be classified as either synchronous or asynchronous. In synchronous protocols the awake time interval is synchronized such that all devices are awake (or asleep) at the same time intervals (e.g., S-MAC [78], T-MAC [79]). Since the awake time intervals are quite limited, they can be highly congested and prone to collisions. Several synchronous protocols have devised mechanisms to attenuate this congestion and to allow more devices to transmit in each cycle, for example, DW-MAC [80], which allocates the awake time for transmission reservations that will be executed during the sleep interval. In asynchronous protocols, each device has its own wake-up schedule. Accordingly, the main challenge is setting a rendezvous time when both the sender and the receiver are awake and devising a signaling mechanism that informs both that they are awake and can communicate. Asynchronous MAC protocols can further be divided into two categories, transmitter- or receiver-initiated. In transmitter-initiated protocols, the transmitter initiates the transmission by capturing the channel waiting for its designated receiver to wake up. For instance, in B-MAC [81], the transmitter transmits a long preamble capturing the channel prior to the data transmission, waiting for its intended receiver to wake up and reply. In X-MAC [82], the transmitter transmits a sequence of short preambles allowing the intended receiver to interrupt, notifying the receiver that it is awake. In WiseMAC [83], the transmitter learns the wake-up time of its intended receiver and starts the preamble transmission just prior to this wake-up time. The second approach, the receiver-initiated paradigm, relies on the receiver, whenever awake and ready to receive data, to initiate the data exchange. The basic receiver-initiated MAC concept was introduced in RI-MAC [84], in which whenever the receiver wakes up, it transmits a predefined preamble, signaling to its potential transmitters that it is awake and ready to receive data. Several protocols took up the RI-MAC paradigm and suggested modifications and enhancements. Some protocols strived to reduce the energy consumed while a sender stays awake, waiting for its intended receiver to wake up. For instance, PW-MAC [85] and AP-MAC [86] suggested that each transmitter will learn its receiver's expected wake-up time, and instead of staying awake waiting for its designated receiver to wake up, will wake up just before its intended receiver's wake-up instance. Another receiver-initiated enhancement is suggested by A-MAC [87], which aims to reduce the time in which a receiver and, consequently, its potential transmitters stay awake, by trying to determine whether there are pending packets for transmission and if it needs to stay awake or if it can go back to sleep after probing the channel. The enhancement relies on an additional frame, termed \"_auto-ack_\", sent by pending transmitters, which follows the receiver's probe packet and proceeds with the data transmission. The \"_auto-ack_\" frame is such that the receiver can decode a superposition of several such frames and determine whether there is traffic being sent. Even though the energy saved per cycle is negligible, the cumulative savings per day can be significant due to the numerous times a device wakes up probing the channel. RIVER-MAC [88] suggests two enhancements, one aiming at reducing the awake time a sender is waiting for its intended receiver to wake up, and one that aims at improving the RI-MAC collision resolution mechanism by letting an active receiver keep controlling the channel after invoking the collision resolution mechanism, and specifically during the silent backoff interval. MAR-RiMAC [89] suggested an amendment to the receiver-initiated approach, and in particular RI-MAC, to cope with the perpetual collisions, common in dense networks and heavy traffic loads, in which many devices are trying to transmit to the same entity (sink or relay).