LPWAN Protocols for Battery Powered Devices

As IoT proliferates, we continue to see a trend to optimize and improve basic "first" and "second" generation designs into highly optimized "next" generation implementations that improve the business value delivered by LPWA IoT solutions. One of the areas that we see being explored is how to improve the network communications between battery powered devices and the cloud. We will be exploring the topic of LPWAN protocol selection for battery powered devices below.

The Scenario

We are going to look at a scenario of a battery powered device, sending a once-per-day transmission to the cloud. This scenario is common in asset tracking, smart metering, and many other long life IoT deployments. This use case exposes pure protocol overhead: there is no session amortization, no keep-alive, no connection reuse.

Protocol background

In this article we are going to explore four protocols: CoAP, LwM2M, MQTT and HTTP on a representative NB-IoT / LTE-M node and explains why transport choice influences the service life of the device.

• CoAP is a compact UDP request/response protocol intended for constrained devices. While CoAP is a compact binary protocol, it maps cleanly onto HTTP semantics but runs over UDP instead of TCP. A CoAP message begins with a fixed 4-byte header, and has concepts such as retries and acknowledgements to give it the same durability as TCP without the connection sequence. CoAP is the transport, but the content and format of the data is 100% up to the user. This gives flexibility, as you can select the best encoding for your data, but it also makes interoperability tricky.
  

• LwM2M layers a resource-oriented device-management framework on top of CoAP, trading a little wire efficiency for lifecycle control and firmware distribution. The main advantage is that there is more structure around common device management operations like firmware update over-the-air (FOTA) and configuration management. There is a rich library of standard sensor objects to represent common sensors like temperature, humidity, speed, pressure, etc., or you can define your own custom objects to meet your needs.
  

• MQTT relies on a persistent TCP connection to a broker; its publish/subscribe model is friendly to firewalls and back-end fan-out but pays the TCP handshake tax when the socket is not held open. MQTT has the advantage of significant industry support, from the hyper-scale service providers like Amazon and Azure, to the small specialized IoT platforms, but it trades significant performance for the easy of integration. Also, as MQTT uses TCP as its underlying transport, it pays a penalty to create new connections, especially when devices have been sleeping for long periods of time. For a device reporting in once per day, it would be almost impossible to keep the connection alive between reporting intervals.

  
  

• HTTP/1.1 remains the lingua franca of the web: universally tooled, universally verbose. Sometimes keeping to the basics ends up being the best approach, HTTP offers the best integration and flexible data models, but it is, by far, the least efficient communication protocol for LPWA. Further, without using HTTP/2.0 it is difficult to create models for devices to connect to the server and receive streaming data, and the methods that exist become more bespoke and not well supported by platforms in the industry.

  
  

Methodology

The radio model assumes 20 kbps uplink, 15 kbps downlink and draws 120 mA while transmitting, 60 mA while receiving at 3.7 V. Each protocol exchange begins from a powered-down modem, performs the minimum legal transaction to deliver one 1 000-byte sensor record, then releases the RF stack. IP and MAC framing bytes are counted; higher-layer security is measured separately using a full TLS 1.2 or DTLS 1.2 handshake. Energy equals airtime multiplied by current and supply voltage. Results are deterministic: there is no probabilistic RRC negotiation or retransmission penalty baked in.

Results and insight

Protocol Comparison Results

CoAP finishes with the leanest footprint—roughly a megabyte per thousand uplinks across a three-year deployment—and the lowest energy draw. Even after adding the DTLS handshake, its total energy is half that of MQTT or HTTP with TLS because UDP needs fewer round-trips.

LwM2M pays for its register/ack cycle, but the surcharge is only eighteen percent over raw CoAP. The upside is rich device management: queued mode lets a sleeping endpoint accept downlink commands within the same wake-window, and full firmware updates ride the same channel.

MQTT looks costly in a cold-start test because it must climb the TCP three-way handshake, then perform CONNECT/CONNACK before the first PUBLISH can leave the modem buffer. If the device can keep its PDP context and TCP socket alive for multiple publishes, that cost amortises quickly; if it cannot, MQTT drains the battery 70 percent faster than CoAP.

HTTP inherits MQTT’s TCP expense and overlays a second layer of verbosity in the form of headers and a full response body. That makes it the heaviest choice when the connection is ephemeral. Its advantage—ubiquitous tool support and immediate compatibility with web back-ends—rarely outweighs the power penalty in coin-cell systems.

Security handshakes dominate short exchanges. DTLS roughly triples CoAP’s energy bill but still lands below half the TLS/TCP options. TLS adds about 750 mJ to every cold wake, enough to shave months off a two-year duty-cycle budget.

Data & Energy usage per protocol

Summarizing LPWAN protocols for battery powered devices

For single-shot telemetry, UDP protocols win: they terminate air-time sooner and let the modem re-enter deep sleep before TCP’s FIN exchange even finishes. CoAP is sufficient when the device only needs to push data. LwM2M earns its incremental cost when remote configuration, queued commands or firmware updates are scheduled. MQTT belongs in architectures where broker semantics and firewall traversal trump joule economy and long-lived TCP sessions are technically feasible. HTTP should be reserved for gateways or mains-powered equipment that can afford the luxury of REST.

CoAP with DTLS maximises battery life in cold-wake LPWA devices. LwM2M adds device-management features at modest overhead. MQTT and HTTP become defensible only when their session semantics are exploited through connection persistence or unavoidable integration constraints.