Skip to content

Build1 publisher3 min readPublished

Ten-year LTE-M battery numbers rest on PSM timers the network overwrites at attach

PSM sleep is negotiated, not configured, so the interval that sets battery life is the one in the Attach Accept. AT+CPSMS returns OK either way. AT+CEREG in mode 4 or 5 reports what was actually granted.

The Engineer · Build desk

Illustration accompanying Ten-year LTE-M battery numbers rest on PSM timers the network overwrites at attach

What happened

  • PSM sleep rests on two timers negotiated during LTE attach: T3412 extended, the periodic Tracking Area Update timer that dominates battery life, and T3324, the active time before the device drops into PSM.
  • The modem forwards AT+CPSMS parameters in the Attach Request and the network answers in the Attach Accept, so the OK returned by the command means the request was accepted for forwarding, not granted.
  • AT+CEREG? in mode 4 or 5 appends the granted T3324 and T3412 extended as quoted eight-character binary strings, and 11100000 in the T3324 field means PSM was refused outright.
  • An nRF9160 developer on Nordic's DevZone asked China Mobile for a specific TAU interval and was granted 54 minutes, which a Nordic engineer confirmed the network sets in the Attach Accept message.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • cost The gap between the interval you requested and the one the network enforces is paid in radio wakeups by every unit already shipped, and no modem return code bills you for it at design time.
  • constraint Because a shortened, downgraded or deactivated PSM grant raises no error, firmware logs and AT command responses cannot be the evidence base for a power budget.
  • decision A ten-year figure has to be recomputed per carrier from granted values, which turns the battery spec into a per-network test result rather than a firmware constant you quote in a datasheet.
  • exposure Nordic's engineer puts the interval in the carrier's hands, and obtaining the one you designed for may require a dedicated APN, which moves a battery-life requirement into a commercial negotiation.

The byte is where the first mistake happens. T3412 extended and T3324 are each a single octet encoded per 3GPP TS 24.008, with the three most significant bits selecting a unit and the five least significant bits carrying a multiplier [5]. In the T3412 table, 01000011 is 10 hours times 3, so 30 hours [6]. In the T3324 table, 00001000 is 2 seconds times 8, so 16 seconds [7]. The unit codes do not line up between the two tables: 000 is 10 minutes in T3412 and 2 seconds in T3324, so decoding one with the other's table moves the answer by a factor of 300 [8]. Mixing the tables is the one bug here that a code review can actually catch.

A request of AT+CPSMS=1,,,"00100100","00001010" asks for 4 hours of T3412 and 20 seconds of T3324 [9]. That nets 3 hours, 59 minutes and 40 seconds of sleep per cycle, because active time comes off the TAU period [4]. What comes back can be shorter, or it can be the non-extended T3412 format with its lower ceiling, or PSM can be deactivated outright, and none of those paths raises an error [13].

Take the DevZone case at its granted value. A 4-hour TAU forces 2,190 TAU cycles a year: 365 x 24 / 4 [21]. Fifty-four minutes forces 9,733: 365 x 1440 / 54 [22]. That is 7,543 extra wakeups per device per year, roughly 4.4 times the design figure [23]. I am not converting that into months of battery, because energy per TAU depends on the modem, the RF conditions and the supply. The multiplier on its own is enough to void a ten-year figure produced from requested timers [20].

eDRX repeats the pattern with a different command. AT+CEDRXS=2,4,"1001" requests the 163.84-second Cat-M1 cycle on LTE-M [17], and the available cycle lengths are fixed by the standard, so there is no partial credit [24]. AT+CEDRXRDP returns the access technology, the requested value, the network-provided value and the Paging Time Window; when the middle two differ, your cycle was replaced with the network's [18]. Qoitech, measuring with an Otii Arc Pro, found that a device requesting one cycle and receiving another draws a profile matching neither the requested configuration nor the datasheet's nominal figure, and concluded that "these differences are impossible to detect in firmware logs or modem responses" [19]. Lose eDRX and the device is back to waking every 1.28 or 2.56 seconds to check for pages [16].

So the condition for a profiler's ten-year number to transfer to your fleet is narrow and testable. The granted T3412 read out of AT+CEREG has to equal the one you requested [11], and the network-provided eDRX value out of AT+CEDRXRDP has to equal what you asked for [18], on every network the fleet attaches to. Both comparisons run at attach and cost one AT command each. That is the whole audit.

What to watch

  • Whether granted-value read-back becomes part of production acceptance testing rather than a debug step, so a battery spec fails at attach instead of in the field.
  • Whether target networks hand back the non-extended T3412 format, which caps sleep at a lower ceiling without reporting an error.
  • Whether firmware reports the granted T3324 and T3412 extended in telemetry, so a fleet-wide downgrade is visible from the server side.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories