skip to main content
Close Icon

In order to deliver a personalized, responsive service and to improve the site, we remember and store information about how you use it. This is done using simple text files called cookies which sit on your computer. By continuing to use this site and access its features, you are consenting to our use of cookies. To find out more about the way Informa uses cookies please go to our Cookie Policy page.

Global Search Configuration

Ovum view

Summary

Ovum is a firm believer in the premise that there should be no "religion" around specific IoT messaging standards. Message queue telemetry transport (MQTT) is not a new messaging standard and existed well before the rise of IoT. However, with support from major software (including middleware) vendors and the wider IoT ecosystem, it is well placed to continue to enjoy an increasing footprint in enterprise IoT.

While not a silver bullet to IoT interoperability, MQTT has a significant lead over competing standards

Discussions regarding IoT interoperability frequently revolve around how to achieve this without relying on wishful thinking that one day in the very near future all major stakeholders will agree on and promote a specific set of messaging standards. While for several years MQTT was considered to be an IBM-promoted standard, the development of Mosquitto, an open source MQTT broker, helped in removing the misleading “proprietary” tag. However, the most noteworthy acceptance came from OASIS (Organization for the Advancement of Structured Information Standards), which approved MQTT v3.1.1 as an OASIS Standard in October 2015.

MQTT can be used by clients and subscribers that are running a MQTT library and are capable of connecting to a MQTT broker. A range of programming languages and development frameworks, including Android, Arduino, .NET, Python, C & C++, iOS, and JavaScript offer MQTT client libraries, and its open source implementations, such as Apache ActiveMQ and RabitMQ, are also available. Enterprises have used MQ-based messaging middleware in the past, and with several major middleware vendorsincluding IBM, Tibco, Red Hat, Oracle, and Software AG offering support for MQTT, there is definitely a push for its adoption to meet IoT messaging and integration requirements.

MQTT is data format-agnostic and its low bandwidth and minimal packet overhead aligns with the requirements of constrained devices and unreliable networks. MQTT Its used across at gnostic and ould like to exploit existing middleware stacks for IoT messaging and is used across several vertical-specific IoT use cases, and endorsements from Facebook, which exploits MQTT for its messenger, and Amazon (MQTT is a primary transport protocol for AWS IoT platform), have added to its credentials. It is possible to assign a quality-of-service (QoS) level to MQTT messages and this can be used to achieve an optimal balance between performance and reliability.

However, there are some limitations that need to be addressed to mitigate data security-related concerns. MQTT was developed at a time when security was hardly an important aspect. While several enterprises have used security mechanisms, such as the use of transport layer security and network security capabilities as add-ons over MQTT, more mission-critical and sensitive use cases will require baked-in security features. Then there is a need to implement message expiry policies so that old messages do not choke the functioning of a MQTT broker. Moreover, MQTT broker availability could be a make or break factor for the success of MQTT-based IoT messaging.

A few other protocols, such as advanced message queuing protocol (AMQP), constrained application protocol (CoAP), and data distribution service (DDS), are also gaining ground, but their use and endorsement across different segments of the wider IoT ecosystem is significantly lower than that of MQTT. These protocols also have their inherent limitations.

Appendix

Author

Saurabh Sharma, Senior Analyst, Middleware

saurabh.sharma@ovum.com

Have any questions? Speak to a Specialist

Europe, Middle East & Africa team - +44 (0) 207 017 7700


Asia-Pacific team - +61 (0)3 960 16700

US team - +1 646 957 8878

+44 (0) 207 551 9047 - Operational from 09.00 - 17.00 UK time

You can also contact your named/allocated Client Services Executive using their direct dial.
PR enquiries - +44 (0) 207 017 7760 or email us at pr@ovum.com

Contact marketing - marketingdepartment@ovum.com

Already an Ovum client? Login to the Knowledge Center now