# Low-Power Wake-Up Receivers for Resilient Cellular Internet of Things
## 1 Introduction  
The Internet of Things enables novel applications such as Smart Cities, industrial automation, smart infrastructure, and environmental monitoring [1, 2, 3]. These connected nodes use various wireless standards to communicate with each other, such as ZigBee, Bluetooth, NB-IoT, and LoRa. For Smart City applications, cellular IoT such as LTE-M and NB-IoT is preferred because it leverages existing network infrastructure and is capable of providing reliable, scalable, and secure connectivity. In general, IoT devices deployed for monitoring, measuring, etc., are expected to have a battery life of at least a few years [4]. However, current 5G user equipment (UE) is extremely power hungry: according to a recent 3 GPP report [5], 5G devices consume tens of milliwatts in the idle/inactive state and hundreds of milliwatts in the active state. As a result, the battery must be recharged or replaced weekly or daily, which is high-cost and not scalable for energy-constrained IoT nodes. Among device operations, wireless communication dominates system power consumption, far exceeding that of sensing, processing, and actuation in most cases [1]. An energy-efficient wireless system design is needed to prolong battery life, improve user experience, and enable mass deployment. Figure 1 shows the evolution of power-saving mechanisms of cellular devices [6]. Traditionally, power saving can be achieved via Medium Access Control (MAC) duty-cycling protocols. The device is periodically put to sleep and woken up only to transmitor receive, for example, through extended discontinuous reception (eDRX) and paging protocols in 4G [7; 8] and 5G [9] UEs. During the DRX mode, the UE turns off most of its circuitry to save power and pauses monitoring of the physical downlink control channel (PDCCH), as shown in Figure 2a. To meet the battery life requirements, long eDRX cycles must be used: the eDRX sleep time can be as long as 43 min for devices using LTE-M networks, and three hours for devices using NB-IoT or 5G networks in an idle mode [10]. However, this results in high latency in device response time which is unacceptable in many use cases. For example, in the fire detection and extinguishment use case, fire shutters shall be closed and fire sprinklers shall be turned on by the actuators within 1 to 2 s from the time the fire is detected by sensors [11]. In addition, many cellular radios are complex systems that require \(\sim\)second(s) to boot up from sleep [5]. The ramp-up/-down time and energy from the duty-cycling operation are therefore nontrivial and will be wasted if the device wakes up and receives no actual data packets. Alternatively, wake-up radios have recently gained attention as a novel hardware solution to significantly reduce the power and bandwidth while maintaining a low latency. While the high-power main radio (MR) is in sleep mode, a separate lightweight wake-up receiver (WUR) is monitoring the RF spectrum for a wake-up signal (WUS). Upon receiving the WUS from the base station (eNB for NB-IoT and gNB for 5G), the WUS wakes up the MR for subsequent operation including network synchronization and packet transmission. Figure 2b shows a generic architecture of a cellular IoT node with an MR and a WUR, and the corresponding power model assuming a duty-cycled WUR with negligible OFF power consumption. In general, the WUR may reuse some of the MR's hardware components such as the RF matching network, RF front-end filter, and real-time clock (RTC). The WUR can either be always ON or duty-cycled to further save power. In either case, the WUR is expected to periodically synchronize with the base station via synchronization signals (SSs), as shown in Figure 2b. Simulations show that WUR can achieve significant power-saving gain and paging latency reduction compared to the DRX baseline [5]. The power-saving gain can be greater than 90% and 70% for a UE paging probability of 0.1% and 1%, respectively [12]. Figure 1: Evolution of cellular device power-saving mechanisms (adapted from [6]).