How MQTT on Narrowband-IoT Can Ruin Your Project

September 02, 2022

Blog

MQTT is a popular protocol for connecting Internet of Things (IoT). But it’s incompatible with Narrowband-IoT (NB-IoT) – an increasingly popular communications standard for most IoT projects. It works fine during prototyping, giving companies the false impression that MQTT is the right choice of protocol.

But chances are high that products using MQTT will suffer performance issues or completely malfunction when they’re in the field. This problem is exacerbated by the fact that many manufacturers and system integrators aren’t aware of the consequent risks: high-expense support efforts, the need to reengage development teams, problems in distributing firmware updates to the device fleet, and product recalls.

NB-IoT is a cellular technology for constrained, (often) battery-powered devices that falls into the Low-Power Wide-Area (LPWA) networking category. It promises low cost, long battery life, and superior coverage compared to more traditional standards such as LTE. It's ideal for asset tracking, smart metering, smart city, and other connected devices that require little data (such as geographical positioning, sensor data, or error codes) and is already being used in real-world applications with deployments increasing daily.

NB-IoT networks are currently operating in 64 countries (including the U.S., China, Australia, and the majority of Europe), and 166 operators worldwide are investing in expanding this reach. But despite its benefits, there remains an unadvertised potential snag that, if it not caught early in product development, could prevent a stable product lifecycle of 10 years or more.

NB-IoT Works Differently Than the Rest of the Internet

NB-IoT is optimized for the User Datagram Protocol (UDP), but most of the Internet uses the Transmission Control Protocol (TCP) for basic communication. TCP is a good choice for certain projects such as websites, file downloads, and emails because it guarantees that data arrives, that it's in the right order, and allows for error detection and retransmission in case of corruption.

But TCP requires more processing power on the device itself, leading to more energy consumption, and it consumes more traffic. If your device wants to send a single byte (for example, that a light is on or off, sent in the form of a 1 or 0), the overhead TCP metadata is another 40 bytes. In practice, data is rarely sent in single bytes, but it’s worth noting because cellular data transmissions are a heavy energy consumer that must be minimized on battery-powered devices.

Worse yet, if there's radio interference from other devices, if the device is in an area with poor reception like a basement, or data gets lost or corrupted, the retransmission mechanisms of TCP kick in and much more data is consumed. These scenarios are quite common in cellular networks, which means that devices send entire packets again which amounts to twice the traffic and twice the energy.

These characteristics make TCP a bad choice for battery-powered devices or constrained hardware. As NB-IoT is optimized for constrained devices, the 3GPP standardized it around global UDP instead.

Traps When Using MQTT on NB-IoT

Many product manufacturers pick MQTT as the data exchange protocol between device and cloud because it is widely supported by cloud providers and IoT application enablement platforms. They also often pick MQTT simply because they’ve used it when developing previous connected products using Wi-Fi or LTE.

But MQTT relies on TCP’s error correction and retransmission schemes and works well with Wi-Fi, LTE, and Ethernet. It’s not that TCP is incompatible with NB-IoT, but when companies are experimenting with the technology (for example, when building a prototype) they’re working in conditions that don’t reflect what the device will encounter later in its deployment lifecycle.

So, MQTT and TCP work great if you have “good enough” network coverage. And because most offices are not underground and/or are in big cities with a lot of radio coverage where issues are minimal, many companies assume that MQTT will work automatically for their specific use. After all, the prototype was successful, so they unknowingly release a subpar product to the market.

Then, once deployed, they start receiving complaints from customers who are having issues because they were unaware of the consequences of placing an NB-IoT-enabled device in a basement with bad reception, for example.

Like any bit of tech, TCP connections can and will fail, resulting in repeated data retransmissions. This leads to wasted traffic on overhead other than actual business data, less battery life, and poor user experience.

And there’s another ticking time bomb for projects using TCP: The more crowded NB-IoT networks become, the more often TCP connections will fail. So even if companies optimize their devices for bad local reception, performance will degrade over time. 

Addressing the Business Impact

What seemed like a good product launch at first is now potentially bound for disaster. High latency leads to a bad user experience and, depending on the use case, could completely derail a project. Then end users rightfully complain that their device isn’t working as expected.

Consequently, the development team must be reassembled or a new team without prior knowledge of the system must be formed to make improvements. Then the new solution has to be rolled out, which is tricky for a device that's offline because it means either the customer has to return the product or a technician must be dispatched to the device location to perform upgrades. However it's addressed, this process incurs significant time and monetary expense.

Another small factor in this complex equation is probably the cost associated with data overages, but the used traffic might exceed contractually agreed upon limits and trigger additional charges from carriers. The amount depends on the contract, carrier, and size of device fleet, but this can't be ignored, either.

But the biggest cost of all is a dissatisfied customer base. It's hard to measure the impact this sort of scenario has on their loyalty or impression of a brand, but it could have long-lasting consequences.

Protocols Actually Optimized for NB-IoT

To be fair, most of the points outline above are true for all connected devices and not limited to MQTT on NB-IoT. Nevertheless, it’s a bigger problem here because businesses just aren't aware of the risks – they’re simply too comfortable with MQTT to know what they’re missing

Product manufacturers and system integrators should choose UDP-friendly protocols such as CoAP or Lightweight M2M (LwM2M) instead. These protocols are optimized for cellular IoT and bring most of the advantages of TCP to UDP. These protocols all support data retransmission, error detection, and order guarantees. Additionally, LwM2M offers far more extensive features than MQTT in building connected products, and especially constrained devices.

With these NB-IoT-friendly protocols designed in, companies and engineering teams can embark on extensive testing that examines how devices operate under various in the field. This testing must cover many environments and every country rollouts are planned in, but that's time and resource that might have been spent debugging the MQTT over NB-IoT problem, anyway.