Basic Function of DRX
DRX (Discontinuous Reception) allows the terminal to periodically turn off the receiving circuit while in RRC idle state, waking up only during paging subframes to listen, thereby reducing standby current. The network sends pages according to the paging group assigned to the terminal. If the terminal misses the window, it must wait until the next cycle. The DRX cycle is determined by both the network and the terminal capabilities. Consumer-grade phones typically use shorter cycles to ensure call experience, while IoT devices, such as for meter reading, can tolerate longer cycles.
Trade-offs
Shorter cycle: faster paging response, higher standby current; longer cycle: significant power saving, but increased latency for downlink signaling and call-like services. For Cat.1/4G gateway products, if using long TCP connections instead of relying on paging, DRX impact is relatively minor; for SMS wake-up or network-triggered services, DRX directly affects wake-up delay. The choice should be based on the business model rather than blindly copying phone parameters.
DRX in Connected Mode
In addition to the idle state, RRC connected state also has DRX configuration, which is used to reduce the listening frequency when there is no data transmission. Improper connected-state DRX may lead to increased scheduling delays, affecting applications with high real-time requirements. Module documentation usually distinguishes between idle DRX and C-DRX, so it is necessary to clarify which type of timer is being modified during debugging.
Measurement Recommendations
Use a power analyzer to record long-term current curves to identify whether periodic wake-ups align with the expected DRX. If irregular spikes occur, check whether they are caused by application heartbeats, sensor sampling, or erroneous watchdog resets to avoid misjudging them as RF issues.
Differences Between IoT and Mobile Parameters
Mobile phones, to accommodate incoming calls and instant messages, usually use shorter DRX cycles; copying the default mobile parameters to IoT terminals like smart meters or environmental monitors can significantly shorten battery life. The correct approach is: first clarify the business requirements for the "latest downstream arrival time," then infer the maximum acceptable DRX/eDRX cycle, and confirm with the module manufacturer the configurable parameter range under the target RAT (LTE/NB-IoT, etc.). For gateway-type always-on devices, DRX has relatively minor impact on battery life, so more focus should be on connected-state scheduling and TCP keep-alive intervals; for battery-powered nodes, the firmware should differentiate strategies for "registered-state DRX" and "whether to quickly enter PSM after task completion" to avoid wasting energy in idle listening. During field testing, it is recommended to record both wireless quality and current curves to distinguish between "frequent reselection due to weak signals" and "intrinsically unreasonable parameters."
Size SMS wake-up for the worst paging cycle
DRX means that, while idle, the terminal does not keep the receiver open. It listens only at its own paging occasion to see whether anyone is looking for it. The cycle is set jointly by the network and the terminal’s capability. Miss this occasion and the terminal waits for the next one. The condition is that the latest downlink the service can accept is no shorter than this cycle plus the time to establish the connection. A short cycle delivers a command sooner and raises standby current. A long cycle lowers current and makes network-triggered work slower. Meter reading and environmental monitoring can accept a long idle cycle. A device that depends on SMS or a network command to wake immediately cannot.
A gateway that stays connected and keeps the link with an application heartbeat is barely affected by the idle cycle, because it spends most of its time out of idle. Copying a handset’s short cycle there only uses more power. It does not make the service faster. A battery device should leave unnecessary listening as soon as the work is done, rather than staying in “registered and still listening.”
Connected-mode parameters written down as idle parameters
Connected mode has its own discontinuous reception, used to listen less often when there is no data. Treating that and the idle cycle as one switch is a common debugging error. Changing the wrong timer either makes real-time work sluggish or leaves standby current completely unchanged. The manual and the log should say which one was changed. The application’s own heartbeat, sensor sampling, and a watchdog reset also put spikes on the current curve. Do not count all of those spikes as paging.
Repeated reselection in a weak network uses more energy than the cycle itself. Record radio quality and current together, so “the parameter is too eager” can be separated from “the device cannot camp.” When a longer sleep is needed and limited reachability must remain, look at eDRX. The window for a meter’s downlink command has to be counted together with the valve time limit in AMI. Do not demonstrate success once in the lab on a short cycle and stop there. Match spikes on the current curve to the application log, rule out heartbeat and sampling first, and only then decide whether the paging cycle is too short.