A battery-powered sensor on a cellular network holds an MQTT session. After quiet periods the server's messages stop arriving, though the device's socket is still open and sending works. Which change fixes it at the lowest energy cost?

What is actually happening

The device is behind carrier-grade NAT. The carrier holds a mapping from its internal address to a public one, and that mapping expires after an idle period — commonly a few minutes for TCP on mobile networks, and shorter still for UDP. When it expires, the path from server to device is gone.

The device does not find out. TCP has no heartbeat of its own, so the socket stays in ESTABLISHED and outbound writes appear to succeed, because the NAT creates a fresh mapping in the outbound direction. Only the downstream direction is dead. That asymmetry — sending works, receiving silently does not — is the signature of an expired NAT mapping, and it is why this is diagnosed late.

Why the chosen answer is right

Two halves. The keepalive interval must be shorter than the shortest mapping timeout on the path, which keeps the mapping alive and, as a bonus, lets both ends detect a dead peer within one interval. The persistent session (MQTT clean start disabled) means the broker retains the subscription and queues QoS 1 messages while the device is away, so a reconnect does not lose commands.

Measure, do not guess, the timeout: watch how long silence can last before delivery fails, on each network the fleet uses, and set the keepalive under the smallest observed value with margin.

Why the other options fail

• A 30-second keepalive. It works and it is expensive. On a cellular radio the cost of a transmission is dominated not by the bytes but by waking the radio and the tail time it stays in a connected state afterwards, typically seconds of elevated power per wake. At 30 seconds that is roughly 2900 wakes a day against about 160 at a nine-minute interval — an order of magnitude of battery for no functional gain.
• HTTPS polling every 15 minutes. It removes the NAT problem by removing the connection, and it pays a fresh handshake per poll and a delivery latency of up to a full interval. For a device that must receive a command promptly, that is a different product. For one that only reports, it may be the right answer — see below.
• A longer TCP retransmission timeout. It changes how long the stack waits before giving up on an unacknowledged segment. It has nothing to do with a mapping that no longer exists.

When not to hold a connection at all

If the device never needs to be reached, do not keep a socket open. A sensor that reports every fifteen minutes and accepts configuration on its next report should wake, send, receive its response and sleep: no keepalive, no mapping to maintain, and battery life measured in years rather than months. Persistent connections are for devices that must be commanded within seconds, and that requirement should be written down and challenged before it is designed for.