PSM power saving mode

Power Save Mode and IoT Reachability

Mechanism Description

PSM (Power Save Mode) is a power-saving mechanism defined by 3GPP for low-power wide area networks. After completing a data transmission or periodic update, the terminal can request to enter deep sleep, shutting down the RF transceiver and most baseband activities, retaining only timers and necessary context. During sleep, the current can drop to the microampere level, which is critical for battery-powered water meters, smoke detectors, and asset tracking devices. The network will remember that the terminal is in PSM state, and downlink paging is unreachable during the sleep window.

Timers T3324 and T3412

PSM behavior is controlled by NAS timers, commonly including activity timers (such as T3324) and periodic TAU/RAU timers (such as T3412). The activity timer determines how long the terminal stays in idle mode before entering PSM; the periodic timer determines how often the device must wake up for a location update to maintain registration. Setting it too long can save power but increases downlink latency and the risk of disconnection; setting it too short limits power-saving benefits. The available range should be discussed with the operator, as different networks and SIM card policies provide varying levels of support.

Service Matching

Meter reading and sensor scenarios that are primarily uplink and occasionally downlink are most suitable for PSM; services requiring real-time downlink control or voice are not suitable. The platform side should adopt a "device first connect" or cached delivery strategy in conjunction with periodic wake-ups. For urgent downlink, SMS wake-up or short-cycle eDRX can be used rather than simply extending PSM.

Module and MCU Coordination

Before entering PSM, the module peripherals should be turned off, unused GPIOs set high, and the main controller confirmed to be in standby. After waking up, RF resynchronization takes time, so the application layer should tolerate the initial packet delay. During debugging, measure the entire system's sleep current and check for leaky components and incorrect pull-up configurations.

Engineering Practice Supplement

Cross-team coordination for the "PSM power-saving mode": the hardware team provides impedance and power budgets, RF provides spurious and sensitivity margins, embedded development defines the thread model and storage life, and the cloud side defines SLA and rate limiting. For NB-IoT and similar scenarios, the business model must match wake-up cycles, packet lengths, and downlink capacity; for automotive and mobile scenarios, session continuity during handover and roaming must be considered. At project closure, conduct a "red team" style review: ensure behavior is defined for weak networks, power loss, expired certificates, clock jumps, and full storage.

Context the Network Still Holds During Deep Sleep

PSM means that after the agreed active time the terminal turns the radio off. Most of the baseband stops, and only enough remains to keep time. The network does not delete the device. The registration remains. Downlink data is buffered or dropped, depending on the core network and the service platform, but nothing on the air interface can wake the device. It wakes mainly when the periodic location update comes due, or when the terminal itself has uplink data. What you buy with the power saving is a defined interval of unreachability, not "poor signal." How low the module current can go also depends on whether the host has really stopped feeding and pulling up the module pins. Turning off the protocol stack alone is not enough.

The condition of use is a service that is mostly uplink, with downlink that can wait for the next wake. Meter reading and environmental monitoring fit. A remote close that must happen now, voice, and continuous control do not. The active timer and the periodic-update timer have to be chosen together with the values the operator allows. The network may shorten what the terminal requested. The platform must send queued commands in the short window after the device wakes, not retry continuously while it is asleep.

When the Network Rewrites the Active Timer

The most common error is a firmware power budget built on the requested value, while the live network shortens the periodic update. Battery life falls short of the lab, and the investigation goes looking for leakage. The second is to believe SMS or downlink IP is still delivered immediately during deep sleep. The field symptom is "the command was sent, the device did not react," until the next wake, by which time conditions on site have changed. The third is to send service traffic the moment the device wakes, before the radio has finished resynchronizing. The first packet fails and is logged as poor coverage. If the host holds the serial lines high while the module is in deep sleep, whole-device current never falls. The protocol is in a power-saving mode. The circuit is not.

If urgent downlink cannot wait for the periodic wake, use a mechanism that still listens for paging on a cycle. Do not set the active timer to zero and still claim power saving is on. Radio idle and deep sleep are not the same layer; see RRC states. Whether the packet context is still there during deep sleep decides whether a new address is required after wake; see PDP context.

Accept power on the whole device, not by reading the deep-sleep current in the module manual. Host pull-ups, indicator lamps, external sensors, and a serial level shifter left on all keep drawing current after the protocol has entered power saving. Measure at the battery, with a series ammeter or a small enough sense resistor, and include the synchronization time after wake in the average current of one cycle. Otherwise the budget contains sleep and not the search for the network on waking. If the network rewrites the periodic update, the log should keep both the requested value and the accepted value. When they differ, recompute life from the accepted value. Do not keep promising the requester the requested one. A downlink command that misses the wake window should be marked on the platform as waiting for the next delivery, not retried until the core-network buffer is full. If an urgent service does not meet the premise that it can wait, do not use this deep sleep as the only way to reach the device. Average current has to include the time spent finding the network after wake. Measuring only deep-sleep current overstates life.

Related Terms

Return communication modules terminology