Radio Wake Budget

A team halves its telemetry payload with a binary encoding and measures no improvement in battery life. The payload was never the cost.

On a cellular or low-power radio, the energy of a message is dominated by waking the radio and by the tail of elevated power it holds afterwards, typically seconds of connected state after the bytes have gone. Two hundred bytes and two thousand bytes cost nearly the same. Two transmissions cost twice one.

Why it matters

It inverts the intuition engineers bring from server work, where bytes and CPU are the currency. On a device, the correct unit of account is transactions per day, and every design decision — keepalive interval, telemetry rate, retry policy, update checks — is a claim on that budget.

Stating the budget turns arguments into arithmetic. A device with a target of three years on a primary cell has a wake allowance that a 30-second keepalive exhausts by itself, and that fact ends the discussion faster than any principle.

Implementation patterns

• Compute the allowance first, from battery capacity, the measured energy per transaction on the actual radio, and the target lifetime. Then allocate it: so many wakes for keepalive, so many for telemetry, a reserve for retries and updates.
• Batch aggressively. Twelve samples posted once a minute carry the same payload bytes as twelve posts and cost one wake instead of twelve. The price is staleness, which is a product decision.
• Align wakes. Piggyback the keepalive, the telemetry flush and the configuration check onto one wake rather than three independent timers that drift into three separate ones.
• Avoid a handshake per message. A persistent session, or DTLS session resumption for CoAP, turns several round trips into one and removes most of the connected time.
• Cap retries in the budget, not only in the code. A retry storm after an outage is a wake storm, and it is drawn from the same account.

Industry example

The design of the low-power cellular standards is this budget made into a protocol. Power-saving mode and extended discontinuous reception exist precisely so a device can tell the network it will be unreachable for a long interval and then keep its radio off, which is only useful if the application above agrees to wake on the same schedule. Fleets that adopt those radios and keep an application-level keepalive of a few minutes get the cost of both designs and the benefit of neither, which is the most common battery failure in production IoT.

Failure scenarios

• The keepalive that ate the budget, set to 30 seconds to work around an unexplained connectivity problem and never revisited: roughly 2900 wakes a day against about 160 at nine minutes.
• Three timers, three wakes, because telemetry, heartbeat and configuration were built by different teams.
• Retry storms after an outage, which drain a fleet's batteries during the recovery.
• A field-measured lifetime that is a third of the laboratory number, because the laboratory test had perfect signal and real devices spend far longer transmitting at the edge of coverage.
• Firmware update checks on a short interval, invisible in review and significant in the budget.

Trade-offs

When not to use it

For mains-powered devices this budget is not a constraint and optimising for it costs freshness for nothing. It also does not apply to devices on WiFi where the radio is already awake for other reasons. The metric earns its place where the battery is a service visit: meters, trackers, agricultural sensors, anything installed once and expected to run for years.

Interview question

Q: A tracker must last two years on a primary cell and report position every fifteen minutes, and product now wants a command channel with sub-minute delivery. Tell me what that costs and what you would propose instead.

What a strong answer covers: energy per transaction rather than per byte · the wake arithmetic for a keepalive short enough to survive carrier NAT · that sub-minute command delivery and multi-year battery are close to mutually exclusive on that radio · alternatives such as scheduled command windows or a downlink-capable low-power mode · and asking what latency the business actually needs, since "immediate" usually means "within the hour" once someone is asked.

Quick check

Quiz: Why did halving the payload not improve battery life? Because energy is spent per wake and its tail, not per byte, so the number of transmissions is the thing to reduce.

Flashcard: What is the right unit for a device energy budget? — Transactions per day, allocated across keepalive, telemetry, retries and updates.