# Current Trends on Green Wireless Sensor Networks
## 2 Energy Conservation
### Sleep/Wake-Up Schemes
#### 2.3.3 Wake-Up Radios  
Recently, low-power wake-up radio technology (WuR) appeared as a promising alternative, perhaps making duty-cycling unnecessary [108]. In general, duty-cycling saves energy at the cost of an increase in the end-to-end packet delivery delay. Moreover, such savings will not be optimal because of collateral effects as, for instance, protocol overhead in synchronized approaches and higher contention--so collisions and retransmissions--in collective awakenings. Finally, idle listening is not completely removed. To achieve higher energy efficiency without increasing latency, wake-up radios--a second radio onboard--have been proposed as a promising alternative for asynchronous protocols. A wake-up radio is a low-power hardware device--consuming three orders of magnitude less power than a main RF chip [108]--capable of immediately reacting to an external event, waking up the node--and so its main radio--that is in sleep mode. Moreover with recent advancement in micro-electronics it is even possible to perform destination address decoding without waking the microcontroller, which would avoid false wakeups and overhearing [109]. It is not vain to say the only disadvantage of WuR systems appears to be the extra hardware expenditure. Though, well, limited range is another one. Wake-up MAC protocols can be seen as on demand MAC protocols where sending nodes ask receivers to wake-up for attending an imminent packet arrival. The wake-up signal can be sent on an exclusive control channel or on the same used by the main radio; and, in the basic implementation, not even CCA is performed. In [110], state-of-the-art wake-up MAC protocols have been split into three categories that use different hardware technology: (i) duty-cycled wake-up MAC protocols, (ii) non-cycled wake-up MAC protocols, (iii) path reservation wake-up MAC protocols. The first group is a special case where duty cycling is applied to the wake-up radio, which has similar characteristics in terms of coverage range and power consumption as the main transceiver (actually something less but not enough). So neither it is attractive from the point of view of energy efficiency nor eliminates the extra delay associated with duty cycling technique. In the second group (non-cycled) we find two interesting alternatives: those based on an always-on low-power wake-up radio (active wake-up radio) that is able of transmitting and receiving wake-up messages, and those where the wake-up radio is passive (powered by the wake-up signal, reminding RFID technology) or low-power active (using just a few micro watts from the battery), being able to receive the wake-up signal but delegating on main radio its transmission. Both share high responsiveness; active wake-up radio has greater coverage--20 m vs. \(\ll\)10 mm--though leaving it active all the time conducts to a non-negligible power consumption; and passive devices achieve the highest energy conservation. Finally, in path reservation wake-up MAC protocols nodes take advantage of the additional (wake-up) radio to perform at the same time the early warning reception and a wake-up message transmission to prepare a forwarding event in a multihop context, so eliminating path establishment waiting time. Other interesting taxonomies, a hardware review, and WuR-based MAC protocol survey can be found in [111]. The clear advantage of RI schemes in duty-cycling asynchronous protocols disappears (RI vs. TI) in WuR, and, once more, the application and the scenario will determine the most suitable operation mode. In general, RI suits better for data collection whereas TI is more appropriate for event-triggered data reporting in WSNs. In the next lines we present the very last contributions in the field of EE/EH-MAC protocols:  
1. In [112], FAWR (Fully Asynchronous Wake-up Radio-based MAC), a RI sink commanded scheme, is presented as a multihop WuR MAC able to overcome the short-range limitation (20 m) of this low power transceivers.