ditional delays. Therefore, to reduce the delays, the device remains in the active state for a configurable period of time after being scheduled. This is realized by an inactivity timer started by the UE every time that it is scheduled where the UE remains awake until the time expires (Fig. 2.25). Since NR supports multiple numerologies the time unit of the DRX timers is specified in milliseconds in order to avoid associating the DRX periodicity to a certain numerology (Fig. 2.26). The NR HARQ retransmissions are asynchronous in both downlink and uplink. If the device has been scheduled a transmission in the downlink that it cannot decode, a typical gNB behavior is to retransmit the data at a later time. In practice, the DRX scheme has a config- urable timer which is started after an erroneously received transport block and is used to wake up the UE receiver when it is likely for the gNB to schedule a retransmission. The value of the timer is preferably set to match the (implementation-specific) roundtrip time in the HARQ protocol. The above mechanism is a (long) DRX cycle in conjunction with the device remaining awake for a period of time after being scheduled. However, in some ser- vices such voice over IP, which is characterized by periods of regular transmission, fol- lowed by periods of no activity, a second (short) DRX cycle can be optionally configured in addition to the long DRX cycle. The RRC entity controls the DRX operation by configuring the following parameters [14]: drx-onDurationTimer: The duration at the beginning of a DRX cycle. drx-SlotOffset: The delay before starting the drx-onDurationTimer. drx-InactivityTimer: The duration after the PDCCH occasion in which a PDCCH indi- cates a new uplink/downlink transmission for the MAC entity. drx-RetransmissionTimerDL (per-DL HARQ process except for the broadcast process): The maximum duration until a downlink retransmission is received. Last successful PDCCH decoding Short DRX cycle timer Inactivity On duration On duration On duration On duration On dur