MQTT, CoAP oder LwM2M: Protokoll fur NB-IoT

June 3, 2026 · 8 min read · Technical Whitepapers

CoAP UDP ~208 mJ. MQTT TCP ~348 mJ. TLS: grosse Unterschiede.

TL;DR: On an NB-IoT network, sending a 1,000-byte sensor reading via CoAP over UDP costs ~208 mJ. The same payload via MQTT over TCP costs ~348 mJ —67% more. Add TLS encryption and MQTT burns over 1,600 mJ per exchange; CoAP+DTLS stays around 600 mJ. The difference is not academic: for a battery-powered sensor transmitting once per hour, MQTT+TLS drains a 2,400 mAh Li-SOCl2 cell in approximately 8 months. CoAP+DTLS on the same hardware runs for over 2 years. The question is not which protocol has the cleaner architecture diagram. It is which one keeps your devices alive long enough to justify the deployment cost. On NB-IoT, the answer is CoAP —by about 14 months of additional battery life.

The Numbers: Real NB-IoT/LTE-M Benchmarks

A 2025 quantified test (Tartabit) on a representative NB-IoT/LTE-M node sending a 1,000-byte sensor record once per day, cold-start, no session reuse:

The gap widens with encryption: CoAP+DTLS ~600 mJ. MQTT+TLS >1,600 mJ —the TCP+TLS handshake alone costs more energy than the entire CoAP+DTLS exchange including payload delivery.

Why TCP hurts on NB-IoT: NB-IoT is half-duplex. A TCP connection requires a 3-way handshake (SYN, SYN-ACK, ACK) before any data flows. If the device enters PSM (Power Saving Mode) between transmissions —which it should, to save battery —the TCP session is torn down. The next transmission pays the full handshake cost again. CoAP over UDP is stateless: the device wakes, sends a UDP datagram, receives a response, goes back to sleep. No session state. No handshake.

Source: Tartabit, "LPWAN protocols for battery-powered devices", 2025. Available at https://www.tartabit.com/blog/lpwan-protocols-for-battery-powered-devices

MQTT: When Ecosystem Inertia Is the Right Call

MQTT dominates cloud IoT because it is the default protocol for AWS IoT Core, Azure IoT Hub, and every major MQTT broker (Mosquitto, HiveMQ, VerneMQ). If your architecture is already built around a pub/sub broker —devices publish to topics, cloud services subscribe —switching to CoAP means rebuilding the message routing layer.

MQTT is the right choice when: the device is mains-powered or has a rechargeable battery with regular charging cycles; the deployment uses LTE-M (full-duplex, TCP-friendly) rather than NB-IoT; the cloud backend is an existing MQTT-based platform and the cost of rewriting the ingestion pipeline exceeds the battery-life savings; or the use case requires multi-subscriber message distribution (one device publishes, three cloud services consume) —CoAP's request/response model does not natively support this.

MQTT tuning for constrained devices: use QoS 0 (fire-and-forget —no acknowledgment overhead), keep topic names under 16 bytes (every byte in the topic is transmitted in every PUBLISH packet), set keep-alive intervals long enough to span PSM sleep cycles, use session persistence to avoid re-subscription on reconnect, and use binary payloads (CBOR, Protobuf) instead of JSON to minimize bytes over the air.

Source: Motive, "Why MQTT Persists in NB-IoT —And When to Choose Alternatives", 2025. Available at https://motive.com/news-and-resources/why-mqtt-persists-in-nb-iot

LwM2M: The Protocol That Solves Device Management —Not Just Data Transport

LwM2M is not a data transport protocol. It is a device management standard that uses CoAP as its transport layer. This is a critical distinction: MQTT and CoAP solve "how do I move bytes from A to B?" LwM2M solves "how do I update firmware on 10,000 devices without sending a technician to each one?"

LwM2M defines standardized objects for: firmware update (Object 5 —FOTA), device configuration (Object 1), connectivity monitoring (Object 4 —signal strength, IP address, cell ID), sensor readings (Object 3303 for temperature, 3304 for humidity), and security bootstrap (Bootstrap Server for zero-touch provisioning).

The energy cost: LwM2M adds approximately 18% overhead over raw CoAP (246 mJ vs 208 mJ in the benchmark above). This buys full remote device lifecycle management. For deployments over 1,000 devices —especially in inaccessible locations —the 18% energy premium is recovered the first time you push a firmware update over-the-air instead of rolling trucks.

LwM2M 1.2 (current version) adds SenML+CBOR encoding (smaller payloads), multi-transport support (can run over MQTT or HTTP when UDP is blocked), OSCORE for end-to-end security beyond hop-by-hop DTLS, and conditional notification triggers to reduce redundant reporting.

Source: Yang & Jain, Washington University, "CoAP and LwM2M: Lightweight Protocols for Constrained IoT Devices", November 2025. Available at https://www.cs.wustl.edu/~jain/cse5700-25/ftp/coap/index.html

Protocol Selection Matrix: What to Use, When

The protocol decision is not permanent: a device can support both CoAP (for telemetry) and LwM2M (for management) on the same eUICC. The radio, the SIM, and the data plan are the same regardless of which protocol rides on top. The protocol choice determines energy budget and operational capability —not connectivity cost.

What the SIM Needs to Support —Regardless of Protocol

MQTT, CoAP, and LwM2M all run over IP. The SIM must provide: transparent IP access (no proxy interference with TLS/DTLS), always-on or on-demand PDP context activation, and support for the APN that routes to the correct cloud endpoint. For NB-IoT specifically, the SIM must be provisioned for the correct NB-IoT band and the network must support the IP data delivery mode (Control Plane CIoT optimization is not sufficient for UDP or TCP —User Plane is required). These are SIM procurement questions, not protocol questions. Get them wrong and no protocol will save the deployment.

References

• Tartabit —LPWAN protocols for battery-powered devices (2025)
• Motive —Why MQTT Persists in NB-IoT —And When to Choose Alternatives (2025)
• Yang & Jain, Washington University —CoAP and LwM2M: Lightweight Protocols for Constrained IoT Devices (November 2025)