Why MQTT Persists in NB-IoT — And When to Choose Alternatives

NB-IoT is designed for Massive IoT deployments: millions of cheap, long-life devices operating under severe constraints of bandwidth, latency, and power. A range of optimised protocols—CoAP, LwM2M, MQTT-SN, and non-IP delivery, address these limitations with lightweight headers, UDP transport, and efficient sleep-friendly messaging. Yet, despite its inefficiencies, MQTT remains widely used on NB-IoT. The reason is rarely technical. MQTT enjoys a huge ecosystem: mature open-source stacks, cloud platform integration, developer familiarity, and persistent device designs inherited from earlier cellular generations. For mains-powered or low-volume devices, MQTT can be made to work with careful tuning—short topics, binary payloads, long keep-alive timers, session persistence, and SIM/APN-based security. For battery-powered devices, however, MQTT’s TCP, TLS, and keep-alive overheads are hard to overcome, making LwM2M or CoAP far more suitable. Understanding these trade-offs is key: MQTT’s ecosystem benefits must be balanced against the technical realities of NB-IoT.

Introduction

NB-IoT is a 3GPP network technology oriented towards Massive IoT devices. The Massive IoT device category means very large numbers of cheap endpoints with very limited computational resources, such as processor capability and volatile and non-volatile memory, usually meaning quite limited bandwidth. On top of this, Massive IoT devices often have long lifetimes—anything up to 15 years—regardless of whether they are connected to mains electricity or not. Massive IoT devices are also expected to be deployed in a much less constrained way compared to other cellular types, meaning that they may be much further from radio towers. To achieve all this, NB-IoT has introduced a set of new ways of operating. Examples include half-duplex transmission, meaning that a device can only send and receive data in one direction at a time. Also, to save on using the radio—which is a way of optimising power and computing resources—the device can switch off its radio and only use it sparingly. These features enable a new range of IoT applications but do introduce technical challenges for bandwidth and latency.

Because of these limitations, a range of protocols has been introduced and extended. Examples include the Constrained Application Protocol (CoAP), MQTT for sensor networks (MQTT-SN), and the Lightweight Machine-to-Machine Protocol (LwM2M). These protocols include many optimisations for the constrained nature of the network and the devices that they use. The features vary from protocol to protocol, but they include things such as tokenising variable names, procedures for going offline while retaining device state, and the ability to exclude confirmative messages. One big feature that is common to all these protocols is that the binding to the lower layers can use the User Datagram Protocol, which is much "lighter" than the alternatives in terms of payload and latency.

What we are addressing here is related to the Message Queuing Telemetry Transport protocol (MQTT). The question is: given the limitations of NB-IoT and the availability of protocols, why is the MQTT protocol often used for devices when there are quite obviously much better alternatives?

Message Queuing Telemetry Transport protocol (MQTT)

The MQTT protocol was developed with IoT in mind and, as such, has a very simple operation focused around a simple message broker concept.

Clients, which can be either an IoT device or an IoT application, use the concept of "subscribe" to ask to be notified when a client does a "publish" of data towards the broker. In this way, data can be easily sent and received between IoT devices and IoT applications that are able to communicate with the broker as a client, and clients can expect to receive only the data they are interested in.

Data is organised in the form of "topics," which are essentially the name in a name/value variable. The structure of the name can be used to filter what data the client is interested in. The name is arguably not a name in the traditional sense, but more like an address with a structure to signify hierarchy. For example, "/Device/Sensor1/Temperature" would be an example of a sensor for a thermometer. The hierarchy can be used to filter data of interest by using wildcards. For example, "/Device/Sensor1/#" would allow for the collection of all data for any sensor, not just temperature, and "/Device/+/Temperature" would signify that all sensors are of interest, not just "Sensor1." The value associated with a topic is called the payload, and this can vary in structure depending on the implementation. The payload can be a simple variable, a composite JSON or XML-style string, or a binary value.

The MQTT protocol uses TCP for the lower layer and, as such, when security is needed this can be combined with TLS security with usernames and passwords for authentication, which is similar to HTTPS used on the web.

MQTT also has a number of features to optimise the IoT experience, such as session persistence and quality-of-service options.

The simplified nature of the MQTT protocol has made it very popular for IoT applications, as reflected in surveys. This popularity is having a snowball effect, with more devices, services, cloud providers, chipsets, and other elements of the ecosystem adopting it, making it an easy choice and reinforcing the ecosystem to invest in itself.

MQTT and NB-IOT

Using MQTT with NB-IoT presents some challenges, which are not always obvious to service developers. Although MQTT is comparatively lightweight compared to other protocols, and is marketed as such, it does have characteristics that mean it is not well suited to NB-IoT networks.

MQTT relies on an always-on session state, meaning that any client can directly communicate with any other. In NB-IoT, this is acceptable for IoT Device-to-IoT Application communication, as the device can decide to come online to initiate communication, but for IoT Application-to-IoT Device communication this is not as straightforward, as the IoT device will most likely not be online and the broker may have to wait a significant amount of time.

MQTT also has packet header overhead as well as small transport blocks. This may be too much for NB-IoT, which has low bandwidth and can get congested. Additionally, the underlying TCP protocol may need re-establishing when the device comes in and out of power-saving mode and connection continuity is lost, all of which adds to bandwidth overhead.

The high latency and half-duplex transmission of NB-IoT require careful management to ensure that MQTT sessions are established and acknowledged before a broker times out. The technical characteristics of NB-IoT radio, such as its high latency and half-duplex operation, necessitate strategic session management to prevent MQTT timeouts. To successfully use MQTT on NB-IoT, developers must account for the network's high latency and half-duplex behavior to ensure that session establishment and acknowledgments are completed in a timely manner.

MQTT can also drain the battery with multiple keep-alive messages. Quality-of-Service (QoS) acknowledgments and the need to keep sessions open for communication mean many messages, which in turn consume a lot of power. Using the radio is one of the most power-intensive aspects of a device.

Security is another major overhead for MQTT devices. This is because TLS is used with X.509 public key infrastructure. This involves exchanging kilobytes of data, which is expensive in resource terms—especially when reconnecting after coming out of power-saving mode, as the TLS connection may need to be re-established.

How MQTT Compares to other protocol

There are many alternatives to MQTT for use on NB-IOT. The table below summarises how MQTT compares to the COAP, Lightweight M2M, MQTT-SN and using Non-IP connections.
Although originally designed as a lightweight protocol, it is obvious that MQTT has been significantly improved upon. In some cases this is with easy wins such as employing UDP and DTLS rather than TCP and TLS. Further improvements involve changing how payloads are formatted and how keep alive sequences work.  

One particular benefit of improving these protocols is the movement towards standardisation where complete sequences and data models are standardised, this has the further benefit of increasing interoperability and allowing difference servers and devices to work with each other in an easy way.

Why is MQTT used with NB-IOT

The key question is that if MQTT is so unsuitable for NB-IOT, why is it used so frequently. A quick scan of the internet will locate multiple device types that support MQTT with NB-IOT.
The main reason why MQTT is used is very rarely a technical decision based on comparison to other available technologies. The main reason is that the design of a particular module is often an evolution from a previous design where the constrained nature of a device was not seen as a problem. Given that MQTT is designed and promoted as a lightweight protocol there is a level of justification for this. So a design for a previous sensor was using MQTT, it worked fine when connected to mains power using standard cellular, then the modem was enhanced to support Low Power Cellular such as NB-IOT. This is the point where issues can occur.

The ecosystem for MQTT is very large. There are lots of devices out there that support and have been supporting it for years. There are people who understand it and there are open source software components that can be used in devices as well as brokers and other supporting capabilities. Additionally there are public cloud MQTT capabilities which can be used very cheaply, at least to get started allowing developers to build and test complete systems from scratch.

For powered devices MQTT can be made to work with NB-IOT, it can be a somewhat long complex messaging sequences, but it can be done. The benefit is the good coverage of NB-IOT which can be up to 10 times better than standard cellular which is good for IoT deployments where the cellular network is used to cover a wide area. A simple example is metering.

For unpowered devices, the challenge of making MQTT work on NB-IOT becomes harder and in terms of comparative battery life, it is probably impossible to make an MQTT device work as well as the alternatives.

How can you use MQTT with NB-IOT

When connecting an MQTT device with NB-IOT there are aspects that should be considered to ensure that the device performs as well as possible.

Obviously smaller payloads make sense. Using topic names that are short or, even better, tokenised topic names. e.g. Device/Sensor/Temperature -> 11/01/23, this case each string is represented as a number. Payloads in binary tend also to be smaller compared to say XML or JSON, but the decoding and encoding of values need to be considered, as when using unpowered devices, encoding and decoding does increase battery usage. Combining payloads to reduce the number of messages is also a way of reducing the total size of payloads.

Although reducing the payload is significant, there are diminishing returns as to how effective this is, as the number of messages and sequencing of messaging is probably more significant, especially if it means turning the half-duplex connection around. To reduce the signalling overhead the keep alive sequences in MQTT should be aligned with the telco signalling procedures and if possible reduced substantially. If it is possible for the application to receive device cellular status from other sources, the keep alive sequences could be kept so long as to be insignificant.

The Quality of Service (QoS) sequences should be optimised to what is appropriate for the applications. There are a range of options, from fire and forget, to acknowledgement by the main IoT Application to acknowledgement by all applications. For simple telemetry where data is periodically collected a simple QoS value zero is probably enough and best most optimal on signalling efficiency.

Session persistence is an important aspect to be considered, especially working with downlink messages. This is because a device may be offline and unable to receive messages or the device is part way through a sequence and has gone offline. A key use case is for Device Management sequencing where a downlink activity such as configuration or firmware upgrade is applicable. Careful use of session persistence can avoid the need for excessive device signalling at reconnect as the device subscriptions are retained.

Timers need to  be carefully managed. In general they need to aligned with cellular timers that are used to control when the device comes in and out of power saving mode and the Extended Discontinuous Reception (eDRX) mechanisms are aligned. Timers apply to several levels. At the cellular level, the TCP level and optionally TLS level as well as the MQTT layer all interact with each other and the very high latency of NB-IOT can affect the whole stack very significantly.

Security is a significant overhead when used with MQTT, at best the approach would be to avoid the use of security entirely and the underlying Cellular connectivity that already provides enough security. This can be done easily with a private APN with VPN security. This not only improves power and bandwidth efficiency but also has the plus of reducing the complexity of rollout as certificate and other credentials do not need to be distributed. If TLS security is unavoidable TLS session resumption should be used to reduce the handshaking sequencing at reconnect.

Some vendors are investing in solutions that optimise MQTT such that these issues are mitigated and the power characteristics are extended. It could be argued that this is not the best approach as there are lots of other well proven alternatives which are readily available.

Conclusion

In conclusion, it is clear that MQTT can be made to work with NB-IoT, but when battery performance is critical it is not the best choice. Better options exist, such as Lightweight M2M (LwM2M), which also provides benefits for device management and interoperability.

The Motive IMPACT IoT platform supports a wide range of protocols and connectivity options, including MQTT in the NB-IoT space. This is the culmination of many years of experience working with mobile operators and enterprises to optimise high-value IoT services at scale across multiple regions. Additionally, the Motive IoT platform supports a range of other protocols that are better suited for NB-IoT—particularly for battery-powered devices, where extreme care is required to ensure the expected device lifespan.