In this series of three blog articles, adapted from the IoT M2M Times, we take a closer look at the energy consumption of NB-IoT and LTE-M. On their own, these physical layer standards do not deliver energy savings. The IoT developer has to choose the right AT commands and the right protocol with the right strategy for their chosen application. Sometimes we have to do without NB-IoT and LTE-M and take a different path. We hope that you have fun reading and learning.

This second article compares LWM2M and MQTT. In a simple summary: MQTT can do practically nothing and LwM2M can do everything.

So what can MQTT do?

Message Queuing Telemetry Transport (MQTT) can, as the name suggests, only transport data with 14 control commands. Unfortunately, MQTT does not transport the data in an energy-optimised way for battery-operated devices. MQTT is a compromise between energy-saving and safety when transporting data having been developed by IBM for oil pipelines. Compared to the energy-hungry HTTP, MQTT requires less energy. HTTP was developed to transfer web pages based on TCP and therefore does not need to save energy. TCP is inherently very hungry because it repeats packets if there is no acknowledgement. Unfortunately, with MQTT, only the complex page description language HTML has been trimmed and the main problem caused by TCP has not been eliminated. MQTT makes it possible to work on the protocol layer with and without acknowledgements, however the layer below is TCP and continues to acknowledge. In addition, TCP servers have a time-out window that can often not be met via radio protocols leading to further energy-sapping retransmissions. #NBIoT and #LTEM with a latency of up to 20 seconds are difficult to use with high energy consumption. The Power Saving modes of (PSM) with up to 310 hours and Extended Discontinuous Reception (eDRX) of up to 40 minutes cannot be operated at all with MQTT. The developers had a good idea in 1999 and unfortunately missed the chance to develop the MQTT protocol on User Datagram Protocol (UDP) instead of TCP.

What can CoAP do?

CoAP was published 10 years later in December 2009 as “CoAP Feature Analysis draft-shelby-6lowapp-coap-00“. Like MQTT, it can transport data. It was specified as a transmission protocol for use in restricted networks and nodes for M2M applications. These constrained nodes often use 8-bit microcontrollers with little memory. Wireless networks such as 6LoWPAN often have a high packet error rate. The special conditions and packet loss were taken into account in the specification of CoAP from experience in the 6LoWPAN world. CoAP used UDP instead of TCP. It has only four control commands (Get, Put, Delete and Post). UDP does not acknowledge at its protocol layer. An acknowledgement is only made one level higher with CoAP. Within CoAP, commands can be sent with or without an acknowledgement. Because the fill level of a tank or a water meter is sent cyclically, an acknowledgement is usually unnecessary. Packet loss is not critical. Since CoAP on UDP or SMS has no time-out, a few minutes delay with SMS or hours and days with NB-IoT PSM and NB-IoT eDRX are no problem. NB-IoT Release Assistance Indication (RAI) immediately switches off the receiver after sending and thus fits perfectly with CoAP without acknowledgement. CoAP is in perfect symbiosis with NB-IoT and LTE-M. The first version of the specification had 14 pages, but had grown to 110 pages over several adaptations by 2013.

What can LwM2M do?

LwM2M, unlike MQTT and CoAP, is much more than just a transmission protocol for data. In order for LwM2M to perfectly serve the new low-energy radio protocols NB-IoT and LTE-M, CoAP/UDP and SMS were chosen in version 1.0. This ensures that NB-IoT can be used taking advantage of energy saving modes PSM, eDRX, and RAI. In the newer versions of LwM2M, LoRaWAN, CoAP/TCP and even MQTT have been added. Devices with MQTT can thus be easily integrated into LwM2M. One of the key features of LwM2M is device management. Since LwM2M was influenced by mobile network operators at the OMA, their experience in managing wireless phones has been taken into account. Registration with the LwM2M server is possible very securely in various ways. The commissioning of a device with bootstrap is also standardised under LwM2M. Necessary FOTA (Firmware Over The Air) updates are also managed by the server. The communication of a device is standardised with profiles and resources. Through the mandatory profiles Security, Server, Device and Location, any LwM2M device from any manufacturer can communicate with any LwM2M server on our beautiful blue planet. After successful registration, the LwM2M server enquires and then knows whether it is talking to, for example: a water meter, presence detector, level meter or tracking device. A single device can also support several profiles in parallel providing even greater flexibility.

Summary LwM2M versus MQTT

LwM2M v MQTT Feature table

LwM2M supports many protocols for transmission and was first specified on CoAP/UDP. Unlike MQTT, it was planned from the beginning to support devices with batteries and low energy consumption. LwM2M handles device management, bootstrapping, firmware update over the air and communication via profiles. MQTT does not offer all this. MQTT has never been optimised for lowest energy consumption and nothing is regulated and standardised except transport. Any company aiming for extensive digitalisation has a good starting point with LwM2M.

Perhaps we will soon see the launch of a rocket to Mars, with firmware updates via LwM2M. The transit time of about 3 to 22.3 minutes from Mars to Earth is no hurdle for LwM2M. Even signals from Neptune with a 4-hour delay can be solved with this genius protocol.

Firmware update to a rocket