MQTT (Message Queuing Telemetry Transport) is a popular protocol built on TCP for lightweight M2M (Machine-to-Machine) communication. It has become a standard choice in IoT applications due to its simplicity, efficiency, and ease of implementation. We've had a great deal of experience working with both UDP and MQTT and wanted to share our experiences with MQTT.
Section 1: Core Advantages of MQTT
1.1 Lightweight Protocol
MQTT is designed to use low bandwidth and provide reliable message delivery even in high latency or unreliable networks. The protocol’s small header size and the keep-alive mechanism make it a great fit for IoT applications where bandwidth and battery power are often constrained.
1.2 Quality of Service Levels
QOS or Quality of Service levels is a feature of MQTT where you can decide how reliable you want the communication to be.
MQTT offers three Quality of Service (QoS) levels for message delivery:
0: The message is delivered at most once, delivery is not confirmed.
1: The message is delivered at least once, delivery is confirmed.
2: The message is delivered exactly once by using a four-step handshake.
These QoS levels allow for tailored message delivery guarantees based on the use-case requirements.
1.3 Last Will and Testament (LWT) Feature
The Last Will and Testament (LWT) feature allows a client to specify a “last will” message sent by the broker on its behalf in case it gets disconnected unexpectedly. This feature is vital in ensuring that other clients are informed about the disconnection, which can be crucial in monitoring and alert systems.
Now lets look at some of the major limitations of MQTT when it comes to low power IoT applications.
Section 2: Limitations of MQTT for low-power IoT applications
2.1 Too many configurable options
MQTT gives us a lot of options when it comes to authentication via username, password or x.509 certificates but along with the authentication, there are a lot of different types of configurations that are minute but can cause errors in transmission that are extremely hard to understand why it happens.
Especially when dealing with BG96, where everything has to be a configuration, as a manufacturer it gets extremely complicated to support different MQTT servers with various settings. We tried to simplify these and have default configurations for major vendors but every now and then we encounter issues due to some edge case like one firmware version of BG96 couldn't parse the certificate chain for TLS from certain MQTT servers.
2.2 Battery life and data consumption
When dealing with low-power battery operated devices, they are usually asleep for most of the time and wake up to transmit at regular intervals. Modems are usually the biggest cause of battery drain so they are completely turned off while the device is asleep. This means, we have to initiate the MQTT connection everytime the device wakes up which causes a lot of battery and network overhead. While MQTT provides a lot of flexibility, in scenarios like these it may not be the ideal choice.
2.3 Security Concerns
MQTT’s standard specification doesn’t include a defined security mechanism, thus relying on the underlying network’s security. This may necessitate additional security layers such as SSL/TLS for encrypted communication. If the vendor does not have a private SIM network and does not implement SSL, all communication will be in plain text.
2.4 Lack of Built-in Error Handling
As mentioned in the first point, there is no error handling mechanism when you have an issue. A lot of steps must be performed with trial and error to diagnose the issue.
2.5 Scalability Challenges
As the number of connected devices grows, there may be scalability challenges due to increased message traffic and the need for more robust broker solutions to handle a high number of concurrent connections. Services like EMQX and AWS IoT Core offer fully managed serverless solutions to solve part of the challenge but it comes at the cost of vendor lock-in.
Section 3: Comparing MQTT with Other Protocols
Protocols like customised UDP, CoAP (Constrained Application Protocol), HTTP (Hypertext Transfer Protocol), and WebSockets also serve the IoT ecosystem. CoAP, for instance, is designed for use in constrained environments and offers features like multicast support which MQTT lacks. HTTP and WebSockets, on the other hand, are more common in web services but might not be as efficient as MQTT in terms of bandwidth usage and latency in certain IoT scenarios.
There are other protocols entering the market like HTTP/3 with QUIC that are promising to make the web better which in turn also makes IoT communications better.
Section 4: Future of MQTT in IoT
The MQTT standards are evolving with the advent of MQTT 5.0, which brings in new features like enhanced authentication, shared subscriptions, and better error reporting, making it even more suitable for a broader range of IoT applications.
Wirepas an industrial mesh network uses MQTT as the protocol of choice for all the communications between the gateway and application server.
Conclusion
Like with any technology, MQTT has its advantages and disadvantages. If you are looking for a stateful connection that transmits data in milliseconds, it is the best choice but for battery operated devices that have to reinitate a connection everytime they wake up, you may find UDP or simple HTTP with TLS to be more efficient.
Hopefully, with this article, we've shed some light on the protocol so you may be better informed to choose the correct option for your IoT application. Our experts are available and happy to discuss and suggest a better choice for your application. Use the Contact Us page to get in touch or write to us on info@ellenex.com