PSM eDRX Power Saving on LTE-M and NB-IoT: Timers, RAI and Real Battery Life

A cellular IoT module can sleep at a few microamps, yet plenty of “ten-year” trackers die in eighteen months. The radio is rarely the culprit on paper. The loss hides in the seconds after each message, when the modem sits in connected mode waiting for a network timer, and in the minutes after that, when it listens for pages nobody sends. PSM eDRX power saving is the set of 3GPP features that removes those seconds and minutes, but only if the device asks for the right values and the network actually grants them.

This matters in 2026 because 2G and 3G sunsets have pushed battery-powered fleets onto LTE-M and NB-IoT, and operators now differ widely in which timers they honour. Lab numbers no longer predict field life.

You will leave with the state machine, the exact timer encodings, the AT commands, a worked battery model and a test plan.

What this covers: RRC and NAS states, PSM timers T3324 and T3412, eDRX cycles and paging time windows, release assistance indication, CoAP and LwM2M queue mode, battery maths, measurement and failure modes.

Context and Background

Cellular IoT inherited its power problem from smartphones. A phone keeps a signalling relationship with the network at all times so it can receive a call within a second or two. That means waking every idle-mode DRX (discontinuous reception) cycle, typically 1.28 or 2.56 seconds, to check the paging channel. For a phone recharged nightly that is fine. For a water meter on two AA-size cells it is fatal, because the paging wake-ups alone dominate the energy budget.

3GPP responded in stages. Power Saving Mode (PSM) arrived in Release 12 and lets a device stay registered while switching its receiver off for hours or days. Extended DRX (eDRX) arrived in Release 13, stretching the paging interval from seconds to minutes or hours. Release 13 also introduced the two narrowband radio technologies the industry now calls LTE-M (Cat-M1) and NB-IoT (Cat-NB1), plus a non-access-stratum release assistance indication for NB-IoT control-plane data. Release 14 added an access-stratum release assistance indication (AS-RAI) that works on both LTE-M and NB-IoT. Later releases added wake-up signals and early data transmission, which refine the same ideas.

If you are still choosing a radio, our comparison of LoRaWAN vs NB-IoT vs LTE-M for industrial IoT covers coverage, mobility and cost; this post assumes you have picked cellular and now need it to last. The timers themselves are defined across a handful of specifications: 3GPP TS 23.682 describes UE power saving functions and high-latency communication at the architecture level, TS 24.301 defines the EPS NAS procedures that carry the timers, and TS 24.008 defines the GPRS Timer information elements that encode them.

The existing literature is good at defining PSM and eDRX one at a time. Where it is weak is the interaction: how the RRC inactivity timer, T3324, T3412, eDRX and RAI chain together, which of those the device controls, and which the network silently overrides. My thesis is simple. Multi-year cellular IoT battery life is decided less by the sleep floor than by the “tail” energy between the last useful byte and the moment the radio switches off. RAI and a near-zero T3324 attack that tail; eDRX trades it for reachability. Everything else is measurement discipline.

How PSM eDRX Power Saving Works: The State Machine

Direct answer: PSM eDRX power saving combines three mechanisms. After data, the device leaves RRC connected mode, early if it sends a release assistance indication. In RRC idle it listens for pages on a DRX or eDRX cycle until the T3324 active timer expires. It then enters PSM, radio off but still registered, until uplink data or the T3412 periodic update timer wakes it.

Figure 1: The LTE-M and NB-IoT power state machine. RAI shortens the connected tail, T3324 bounds idle listening, and T3412 schedules the periodic tracking area update.

The diagram shows four places where energy goes. Connected mode is where data moves and current is highest. Idle mode is a listening state whose cost depends on how often the device checks for pages. PSM is the near-off state. Exits from PSM happen only on the device’s own initiative: either the application has uplink data, or the periodic tracking area update (TAU) timer expires and the modem must tell the network it is still alive.

Connected mode and the inactivity tail

When a device sends data it holds an RRC (radio resource control) connection. The eNodeB keeps it there until an inactivity timer expires, and that timer is set by the operator, not the device. Values in the region of ten to twenty seconds are commonly reported on commercial networks, but they are operator configuration and not standardised, so treat any specific number as something to measure.

During that tail the modem is not transmitting much, but it is far from asleep. It is monitoring the downlink control channel, possibly with connected-mode DRX, at milliamp-level average current. For a sensor that sends 50 bytes once an hour, the tail can easily cost more charge than the transmission itself. That is the single most important fact in this article and the reason release assistance indication exists.

Idle mode, paging and T3324

Once released to RRC idle, the device is reachable by paging. The network pages it in a known paging occasion, and the device must wake to check. With ordinary idle DRX that happens every 1.28 or 2.56 seconds on typical configurations, so the average current settles in the tens to hundreds of microamps depending on the module and radio conditions.

The T3324 “active timer” controls how long the device stays in this reachable idle state before entering PSM. It is a NAS timer: the device requests it in Attach or TAU Request, and the MME (mobility management entity) returns the value it is willing to use. If the device requests no T3324 at all, PSM is not used. T3324 is encoded as a GPRS Timer 2 information element, with units of 2 seconds, 1 minute or 1 decihour (6 minutes) and a 5-bit multiplier, so its maximum is 31 decihours, or 186 minutes.

PSM and T3412

In PSM the device keeps its registration, security context and IP address, but its receiver is off. The network marks it unreachable, and mobile-terminated data either waits in a buffer or is dropped, depending on network configuration and the high-latency communication features described in TS 23.682. The device does not need to re-attach when it wakes, which is the core energy win over simply powering the modem down.

The extended periodic TAU timer, T3412, bounds how long the device can stay silent. It is encoded as a GPRS Timer 3 element whose 3-bit unit field supports 2 seconds, 30 seconds, 1 minute, 10 minutes, 1 hour, 10 hours and 320 hours, again with a 5-bit multiplier. The theoretical maximum is 31 multiplied by 320 hours, which is 9,920 hours or roughly 413 days. In practice operators cap it far lower; the Twilio and KORE knowledge bases, for example, cite a 12-hour maximum PSM duration on T-Mobile US.

Two subtleties matter for battery life. First, T3412 restarts each time the device returns to idle, so a device that reports every hour with a 24-hour T3412 never performs a periodic TAU at all. Second, the MME runs a “mobile reachable” timer a little longer than T3412, and if it expires without contact it eventually implicitly detaches the device. A device that misses its TAU because it is out of coverage pays for a full re-attach later.

eDRX: paging every few minutes instead of every few seconds

Extended DRX keeps the device reachable but stretches the gap between paging checks. The network defines an eDRX cycle and, within each cycle, a paging time window (PTW) during which the device monitors ordinary paging occasions. Outside the window it sleeps.

The allowed values differ by radio. On LTE-M, eDRX cycles run from 5.12 seconds to 2,621.44 seconds, about 43.7 minutes, and the PTW from 1.28 to 20.48 seconds in 1.28-second steps. On NB-IoT, cycles run from 20.48 seconds to 10,485.76 seconds, about 2.9 hours, and the PTW from 2.56 to 40.96 seconds in 2.56-second steps. A requested value that is not on the list is replaced by the network’s nearest permitted value.

eDRX and PSM can be combined. A device can listen on a long eDRX cycle during T3324 and then drop into PSM. That pattern makes sense when you want a reachable window of, say, twenty minutes after each report without paying ordinary DRX costs for all twenty minutes.

Release assistance indication: cutting the tail

RAI is the device telling the network, “I have nothing more to send, and I expect at most one reply,” so the network can release the RRC connection immediately instead of waiting for the inactivity timer. It exists in two forms. Control-plane RAI, from Release 13, rides in NAS signalling (the ESM DATA TRANSPORT message) and applies to NB-IoT data sent over the control plane. Access-stratum RAI, from Release 14, is signalled at the radio layer and works on both LTE-M and NB-IoT, for control-plane and user-plane data.

The network still decides. An eNodeB that does not support AS-RAI ignores it and the inactivity timer runs as usual. That is why RAI shows up in field data as either a dramatic win or nothing at all, depending on the operator and sometimes the specific cell.

Walk-through: Requesting, Verifying and Using the Timers

The most common mistake in cellular IoT firmware is treating the AT command that requests a timer as if it set the timer. It does not. Every value in this section is a request that the network may accept, shorten, lengthen or refuse. The firmware must read back what was granted and adapt.

Figure 2: Requested versus granted timers. The host asks, the MME decides in the Attach or TAU Accept, and only the reported values should drive firmware behaviour.

The sequence is straightforward. The host microcontroller writes PSM and eDRX preferences to the modem. The modem includes them in the next Attach Request or TAU Request. The MME answers with the values it will apply, and the modem reports them through unsolicited result codes. When the application later sends its final uplink with an RAI flag, the eNodeB can release the connection immediately, and the modem moves through idle into PSM.

Encoding PSM timers with AT+CPSMS

The 3GPP TS 27.007 command AT+CPSMS takes the requested periodic TAU and active time as 8-character bit strings. The top three bits select the unit and the bottom five bits are the multiplier.

GPRS Timer 3 (requested periodic TAU, T3412 extended), bits 8-6:
  000 = 10 min   001 = 1 h     010 = 10 h    011 = 2 s
  100 = 30 s     101 = 1 min   110 = 320 h   111 = deactivated

GPRS Timer 2 (requested active time, T3324), bits 8-6:
  000 = 2 s      001 = 1 min   010 = 6 min (decihour)   111 = deactivated

AT+CPSMS=1,,,"00100110","00000000"   // request TAU 6 h, active time 0 s
AT+CPSMS=1,,,"01000011","00000101"   // request TAU 30 h, active time 10 s
AT+CPSMS=0                           // disable PSM

The first example, 001 for hours and 00110 for six, requests a six-hour periodic TAU. The active-time string 00000000 requests zero seconds, meaning the device should drop into PSM immediately after release. Not every network accepts zero; some impose a minimum active time, and you will see a larger value in the granted parameters.

Encoding eDRX with AT+CEDRXS

eDRX uses AT+CEDRXS=<mode>,<AcT-type>,<eDRX value>, where the access technology type is 4 for E-UTRAN WB-S1 (LTE-M) and 5 for E-UTRAN NB-S1 (NB-IoT). The value is a 4-bit code from the table in TS 24.008.

AT+CEDRXS=2,4,"1001"    // LTE-M: request 163.84 s eDRX, enable +CEDRXP URC
AT+CEDRXS=2,5,"0101"    // NB-IoT: request 81.92 s eDRX
+CEDRXP: 4,"1001","1001","0111"   // URC: requested, granted cycle, granted PTW
AT+CEDRXRDP             // read the dynamic eDRX parameters in use now
AT+CEDRXS=0             // disable eDRX

The +CEDRXP report shows the requested value, the network-provided eDRX value and the paging time window. In the example, PTW code 0111 on LTE-M corresponds to 8 x 1.28 = 10.24 seconds. Modem vendors add their own commands for setting the PTW request; on Nordic’s nRF91 series it is AT%XPTW. Check your module’s AT manual rather than assuming portability.

Reading back what the network granted

The standard registration status command exposes the granted PSM timers. With AT+CEREG=5 enabled, the modem’s +CEREG notification includes the active time and periodic TAU strings the network accepted, in the same bit encoding used for the request.

AT+CEREG=5
+CEREG: 1,"0A1B","01C2D3E4",7,,,"00000101","00100110"
//      stat tac   cell id   AcT    active  periodic TAU
AT+CSCON=1               // report RRC connected/idle transitions
+CSCON: 0                // signalling connection released

Here AcT 7 is LTE-M and the granted strings show 10 seconds of active time and a six-hour TAU. AT+CSCON is just as useful. Logging the timestamp of +CSCON: 1 and +CSCON: 0 tells you the real connected duration on a given cell, which is the first number to check when RAI appears not to work.

Firmware should parse these reports and store them alongside telemetry. A fleet dashboard that plots granted T3324 and connected duration per operator will explain more battery variance than any lab measurement.

Using RAI from application code

On Nordic’s nRF91 modems, RAI is enabled with AT%RAI=1 and then controlled per socket. The nRF Connect SDK exposes it as a socket option, so the application decides which send is the last.

/* Uplink a reading, then tell the network nothing else is coming. */
int rai = NRF_RAI_LAST;               /* no more uplink after this send */
nrf_setsockopt(fd, NRF_SOL_SOCKET, NRF_SO_RAI, &rai, sizeof(rai));
nrf_sendto(fd, buf, len, 0, (struct nrf_sockaddr *)&srv, sizeof(srv));

/* Request/response pattern, e.g. a confirmable CoAP POST: */
rai = NRF_RAI_ONE_RESP;               /* expect exactly one reply */
nrf_setsockopt(fd, NRF_SOL_SOCKET, NRF_SO_RAI, &rai, sizeof(rai));
nrf_sendto(fd, req, req_len, 0, (struct nrf_sockaddr *)&srv, sizeof(srv));
nrf_recvfrom(fd, rsp, sizeof(rsp), 0, NULL, NULL);
rai = NRF_RAI_NO_DATA;                /* after the reply: release now */
nrf_setsockopt(fd, NRF_SOL_SOCKET, NRF_SO_RAI, &rai, sizeof(rai));

Two details from Nordic’s documentation and DevZone answers deserve emphasis. First, the modem aggregates RAI state across all open sockets, so one socket marked as ongoing keeps the connection alive for everyone. Second, the “one response” hint maps cleanly onto NB-IoT control-plane RAI but is not effective with AS-RAI, so Nordic engineers recommend following the received reply with an explicit no-data indication to cover LTE-M. Other vendors expose the same 3GPP feature through different AT commands or socket flags, but the logic is identical.

How eDRX paging actually behaves

Figure 3: Inside one eDRX cycle. The device wakes at its paging hyperframe, monitors normal paging occasions during the PTW, then sleeps until the next cycle.

eDRX timing is anchored to the hyperframe counter (H-SFN), in which one hyperframe spans 1,024 radio frames, or 10.24 seconds. The device computes its paging hyperframe from its identity and the eDRX cycle, opens its PTW there, and inside the window checks ordinary paging occasions at the normal DRX interval. If the network pages it, the device performs random access, sets up an RRC connection and receives the buffered data. If not, it closes the window and sleeps for the remainder of the cycle.

The practical consequence is a predictable worst-case downlink latency roughly equal to the eDRX cycle plus connection setup. On NB-IoT with a 10,485.76-second cycle, a command could wait nearly three hours. The core network has to hold that data. TS 23.682 describes extended buffering for high-latency devices, but how much an operator actually buffers, and for how long, is network policy. Several operator guides suggest planning on buffering of only small payloads, so design downlinks to be tiny and idempotent.

A less obvious point is that a longer PTW is not free. Each paging occasion within the window costs a wake-up and a short receive period. On NB-IoT, where coverage enhancement may require many repetitions of the control channel in poor signal, each check costs more than on LTE-M. Request the shortest PTW your network allows unless you have evidence that pages are being missed.

CoAP and LwM2M queue mode: matching the application to the radio

Radio timers do nothing if the application protocol assumes an always-reachable device. CoAP (RFC 7252) over UDP is the natural fit because a single datagram and its acknowledgement fit inside one short connection. Its default transmission parameters assume a device that can wait for retransmissions; the derived MAX_TRANSMIT_WAIT is 93 seconds, which is far longer than you want a sleepy device to stay awake. Tune ACK_TIMEOUT and MAX_RETRANSMIT for your link, or rely on non-confirmable messages with application-level acknowledgement.

LwM2M, the OMA device-management protocol built on CoAP, formalises the pattern as queue mode. In LwM2M 1.0, queue mode is signalled through the Binding resource of the Server object (for example “UQ”). In 1.1 it moved to a registration parameter. Either way the server stops sending requests directly and instead holds them until the client next contacts it with a Register Update, Send or Notify. The client stays awake for a configurable period after each uplink to receive those queued operations. AVSystem’s Anjay documentation notes that this awake time defaults to MAX_TRANSMIT_WAIT in their implementation, again 93 seconds with default CoAP parameters, and warns against making it so short that the server’s retransmissions never arrive.

Queue mode is the application-layer twin of PSM. Pair them deliberately: set the LwM2M awake period and T3324 to the same order of magnitude, and send the RAI no-data indication only after the queued operations have been processed. Our deep dive on LwM2M device management architecture covers object models and server design; here the point is that queue mode, PSM and RAI must agree on when the device is listening.

NAT is the hidden fourth party. After hours in PSM, the carrier-grade NAT binding for your UDP flow has almost certainly expired, so the server cannot address the device by its old IP and port. DTLS 1.2 Connection ID (RFC 9146) or OSCORE avoid having to redo a handshake on every wake-up because the security context no longer depends on the address 5-tuple. Our comparison of securing CoAP with DTLS 1.3, OSCORE and EDHOC quantifies the handshake costs you avoid.

A Worked Cellular IoT Battery Life Model

Battery maths for cellular IoT is simple arithmetic on charge, and the arithmetic is worth doing because it shows where the energy goes. The numbers below are illustrative. The PSM floor is anchored to a published figure: Nordic lists a 2.7 microamp PSM floor current for the nRF9160 SiP. Every other current and duration is a round, plausible assumption chosen to make the mechanism visible, not a measurement of any specific module or network. Replace them with your own power-profiler data.

Assumptions (illustrative)

Parameter	Value	Basis
PSM floor current	3 µA	Nordic’s 2.7 µA nRF9160 figure plus board leakage
Uplink burst (RRC setup, send, ack)	1.5 s at 40 mA average	illustrative, good coverage
Connected tail without RAI	10 s at 6 mA average	illustrative operator inactivity timer
Connected tail with working RAI	0.5 s at 6 mA average	illustrative
Idle DRX listening during T3324	0.25 mA average	illustrative, 2.56 s DRX
Usable battery capacity	2,400 mAh	illustrative after temperature and pulse derating

Charge per event is current multiplied by time. Converting to microamp-hours keeps the numbers readable: one milliamp for one second is 1,000 / 3,600, or about 0.278 µAh.

Scenario A: hourly report, no RAI, 60-second active time

The uplink burst costs 40 mA x 1.5 s = 60 mAs, or 16.7 µAh. The connected tail costs 6 mA x 10 s = 60 mAs, another 16.7 µAh. Sixty seconds of idle listening at 0.25 mA costs 15 mAs, or 4.2 µAh. PSM for the rest of the hour adds 3 µA x 1 h = 3 µAh. The total is about 40.5 µAh per hour, an average current of 40.5 µA.

At 2,400 mAh that is 2,400 / 0.0405 = about 59,000 hours, or 6.8 years, before self-discharge.

Scenario B: hourly report, working RAI, 2-second active time

The burst is unchanged at 16.7 µAh. The tail falls to 6 mA x 0.5 s = 3 mAs, or 0.8 µAh. Two seconds of idle listening is about 0.14 µAh. PSM still adds 3 µAh. The total is about 20.7 µAh per hour, roughly half of scenario A, and the projected life rises to around 13 years.

At that point the radio is no longer the limit. Lithium thionyl chloride bobbin cells, the usual choice for multi-year meters, lose capacity to self-discharge and passivation, and a 13-year paper figure becomes a design that the battery chemistry has to justify. Halving the energy per report bought you margin for bad coverage, not a longer warranty.

Scenario C: report every 15 minutes

Quadrupling the report rate multiplies only the per-event terms. Scenario A becomes 4 x 37.5 + 3 = 153 µA average, about 1.8 years. Scenario B becomes 4 x 17.7 + 3 = 73.7 µA, about 3.7 years. The ratio between them widens as reporting gets more frequent, because the tail grows with every event while the sleep floor stays fixed.

Scenario D: paying for reachability with eDRX

Suppose the device must accept commands within about 82 seconds. Pure PSM cannot do that. NB-IoT eDRX with an 81.92-second cycle can. Module makers quoted in the Twilio and KORE guides put eDRX sleep current in the range of roughly 10 to 30 µA, against roughly 1 to 5 µA for PSM. Take 20 µA as an illustrative blended eDRX average including paging wake-ups. The cost of reachability is then about 17 µA over the PSM floor, or 17 µA x 8,760 h = about 149 mAh per year.

That is the real trade-off in one number. On a 2,400 mAh budget, 82-second downlink latency costs roughly 6 percent of the battery per year. If the business can tolerate commands arriving at the next hourly report, LwM2M queue mode plus PSM is almost free.

# Illustrative cellular IoT battery model. Replace every constant with measured data.
MAS_TO_UAH = 1000 / 3600          # 1 mA*s = 0.2778 uAh

def avg_current_ua(reports_per_h, burst_ma=40, burst_s=1.5,
                   tail_ma=6, tail_s=10, idle_ma=0.25, t3324_s=60,
                   floor_ua=3.0):
    per_event = (burst_ma*burst_s + tail_ma*tail_s + idle_ma*t3324_s) * MAS_TO_UAH
    return reports_per_h * per_event + floor_ua    # uAh per hour == average uA

def life_years(avg_ua, capacity_mah=2400):
    return capacity_mah / (avg_ua / 1000) / 8760

for name, kw in {"A no RAI": {}, "B RAI": {"tail_s": 0.5, "t3324_s": 2}}.items():
    for rate in (1, 4):
        ua = avg_current_ua(rate, **kw)
        print(f"{name:9s} {rate}/h  {ua:6.1f} uA  {life_years(ua):5.1f} y")

Run the script with your own measured burst and tail figures and the conclusions above either survive or they do not. The structure of the model is what transfers between projects: energy per event multiplied by event rate, plus a floor, plus whatever reachability costs.

What the model leaves out

Coverage is the largest omission. LTE-M and NB-IoT reach deep indoor locations by repeating transmissions, and coverage enhancement can multiply airtime, and therefore burst charge, by one to two orders of magnitude at the cell edge. A meter in a basement can spend more energy per report than a meter on a wall at street level spends in a week. Model your fleet as a distribution of coverage classes, not a single average.

The second omission is network-initiated behaviour you do not control: cell reselection after waking, failed RRC setups that retry, and TAUs triggered by moving into a new tracking area. Asset trackers, which cross tracking areas, pay a mobility tax that static meters never see. Our post on IoT electric vehicle architecture and battery telematics shows how moving assets reshape the data path; for power, the takeaway is that mobile devices perform extra TAUs regardless of T3412.

Measuring It: Power Profiling on a Real Network

No battery estimate is credible until it has been compared to a current trace taken on the target operator’s network. A power analyser that can capture from sub-microamp sleep currents up to several hundred milliamps of transmit peak, with fine time resolution, is the minimum tool. Nordic’s Power Profiler Kit II and Qoitech’s Otii instruments are common choices for nRF91 work; a source-measure unit or a well-designed shunt and data acquisition system also works.

What a good trace looks like

A healthy PSM trace has a recognisable shape. There is a cluster of high peaks during RRC setup and transmission, a short plateau of connected-mode activity, a release, a brief period of idle paging spikes if T3324 is non-zero, and then a flat floor at a few microamps until the next event. Each part maps onto Figure 1. If you see the plateau run for ten or twenty seconds after your last packet, RAI is not taking effect. If paging spikes continue for minutes, the network granted a longer active time than you requested.

A cautionary measurement

Qoitech published measurements of an nRF9151 development kit on a live Telia network in Sweden. Their averages over an hour were about 630 µA in PSM on LTE-M and about 640 µA on NB-IoT, against about 1.15 mA and 1.36 mA with no power saving. Those PSM figures are two orders of magnitude above the datasheet floor, and the authors explain why: the setup left the UART block enabled to drive the AT command interface, which by their estimate consumed roughly 600 µA on its own.

That is the most common real-world failure, and it has nothing to do with 3GPP. A host MCU that keeps the modem’s serial interface, a debug console, an LED or a pull-up active will mask every gain from PSM. The same Qoitech run also noted that the network’s minimum supported PSM interval was one hour, a reminder that operator policy shapes what you can even test.

A test protocol that survives contact with the field

Measure each configuration for long enough to include several report cycles and at least one periodic TAU; a single event tells you little. Record +CSCON and +CEREG logs alongside the current trace so that every plateau has a cause. Test on each operator and roaming partner you will deploy on, at representative signal levels, ideally with an attenuator to emulate basement coverage. Finally, put a coulomb counter or a periodic battery-voltage report in the product itself. Field telemetry about energy per report, grouped by operator and cell, is the only feedback loop that catches regressions after a network software upgrade.

Trade-offs, Gotchas, and What Goes Wrong

Every power-saving feature trades something away, usually reachability or robustness. The failure modes below are the ones that most often turn a design that looks right on paper into a field problem.

Figure 4: Choosing a power-saving profile from the downlink requirement. Every branch ends in the same two steps: add RAI and verify granted timers on the target network.

Granted is not requested. Networks routinely return a longer T3324, a shorter T3412, a different eDRX cycle or no PSM at all. Some operators reject PSM when roaming. Firmware that assumes its requested values will keep a device awake far longer than designed. Always parse +CEREG and +CEDRXP, log them and alarm on drift.

Unreachable means unreachable. A device in PSM cannot be paged. Firmware updates, configuration changes and remote unlock commands wait until the next uplink. For fleets that need urgent commands, that is a product decision, not a firmware detail. Size eDRX to the true latency budget rather than defaulting to the longest cycle.

Buffers are small and finite. Downlink data held for a sleeping device depends on operator policy. Large firmware images are never pushed into a PSM device; the device must pull them in a scheduled session. Keep server-initiated messages small, idempotent and safe to receive late or twice.

RAI that never takes effect. If the eNodeB does not support AS-RAI, or the modem aggregates an “ongoing” state from another socket, the inactivity tail returns silently. An MQTT client with a keep-alive or a background DNS lookup is enough to defeat it. Prefer one socket, one exchange, then release.

NAT and session expiry. After long PSM sleeps, NAT bindings and sometimes DTLS sessions are gone. Without Connection ID or OSCORE, every wake-up may pay for a full handshake, which can cost more energy than the payload.

Missed TAUs and implicit detach. A device that wakes in no coverage cannot complete its TAU. If the network’s reachability and implicit-detach timers expire, the next contact becomes a full attach, which is markedly more expensive. Backoff logic that searches aggressively for a network in no coverage is one of the fastest ways to flatten a battery.

Clock drift and stuck states. Long PSM intervals rely on the modem’s low-power timer. Combined with application timers on the host, drift can cause the host to wake before the modem is ready, or to miss a scheduled window. Let the modem’s timers drive wake-ups where possible.

Battery chemistry limits. High-energy lithium cells handle the microamp floor well but may sag under transmit peaks, especially when cold. A pulse-capable cell or a hybrid layer capacitor buffers the burst. Without it, a brown-out mid-transmission can trigger a reset loop that does more damage than any timer misconfiguration.

Practical Recommendations

Start from the downlink requirement, because it decides everything else. If the device never needs server-initiated commands faster than its own report interval, use PSM with a T3412 longer than the report interval, request an active time near zero, and run LwM2M or CoAP in a queue-mode style. If commands must arrive within minutes, use eDRX sized to that budget and accept the floor-current cost, which you can now estimate in milliamp-hours per year. Reserve plain idle DRX for mains-powered or frequently recharged devices.

Treat RAI as mandatory on every final uplink, and verify that it works on each operator with +CSCON timing. Design the application exchange so there is a clear “last packet”: one request, at most one response, then release. Keep sockets few and short-lived.

Build observability into the firmware from the first prototype. Report granted timers, connected duration, coverage enhancement level and battery voltage with each upload. Then use a power profiler on the actual operator network, with the host MCU in its production low-power configuration, before you commit to any battery-life number in a datasheet or contract.

A short checklist:

Request PSM with AT+CPSMS and eDRX with AT+CEDRXS; parse and log granted values.
Set T3412 longer than the report interval so periodic TAUs never fire.
Request T3324 near zero unless queue mode needs a listening window.
Enable RAI and mark the last send on every exchange.
Use DTLS Connection ID or OSCORE so wake-ups skip handshakes.
Power-profile on the target network, at cell-edge signal, with the host in production sleep.
Add field telemetry for energy per report, grouped by operator and cell.

Frequently Asked Questions

What is the difference between PSM and eDRX?

PSM switches the receiver off entirely for hours or days while keeping the device registered, so it is unreachable until it next sends data or performs a periodic tracking area update. eDRX keeps the device reachable but stretches the interval between paging checks to seconds, minutes or, on NB-IoT, nearly three hours. PSM gives the lowest average current; eDRX trades some battery for bounded downlink latency. Many designs use both, listening on eDRX briefly after each report and then entering PSM.

What are T3324 and T3412 in LTE-M and NB-IoT?

T3324 is the active timer: how long a device stays reachable in idle mode after releasing its connection, before entering PSM. Its maximum is 186 minutes. T3412 extended is the periodic tracking area update timer: how long the device may stay silent before it must check in with the network, theoretically up to about 413 days. The device requests both in Attach or TAU Request messages, and the network returns the values it will actually apply, which may differ substantially.

What is release assistance indication in NB-IoT and LTE-M?

Release assistance indication (RAI) lets a device tell the network it has no more data to send, or expects only one reply, so the network can release the radio connection immediately instead of waiting for its inactivity timer. Control-plane RAI from 3GPP Release 13 applies to NB-IoT control-plane data. Access-stratum RAI from Release 14 works on both LTE-M and NB-IoT. Network support varies, so verify it on each operator by timing connection releases.

How long can an NB-IoT battery last?

It depends on report frequency, coverage and network timers far more than on the module datasheet. A device sending a small report once an hour, with working RAI and PSM, can average a few tens of microamps, which supports multi-year life on a lithium primary cell. Poor coverage can multiply energy per report many times, and missing RAI can double it. Claims of ten or more years are credible only with infrequent reporting and measured field data.

Do all carriers support PSM and eDRX?

No. Support, permitted timer values and minimums differ by operator, and features may be unavailable while roaming. For example, operator documentation from Twilio and KORE cites a 12-hour maximum PSM duration on T-Mobile US, and Qoitech observed a one-hour minimum PSM interval during tests on Telia in Sweden. Always read the granted values the network returns and test on each network and roaming partner before quoting battery life to customers.

Can a device in PSM receive firmware updates or commands?

Not while it is in PSM, because its receiver is off and it cannot be paged. Commands and update notifications must wait until the device next connects, either for its own report or a periodic TAU. The standard pattern is LwM2M queue mode or a CoAP poll: the server queues operations, the device checks in, processes them, and then sends its release indication. Large firmware images are pulled by the device in a scheduled session rather than pushed.