MQTT not IoT “god protocol”, but getting closer

One protocol, and its descendants, drove the success of the World Wide Web. IP, or Internet Protocol, is the basis of every browser connection and the backbone of IT data centers. Some assumed that the Internet of Things would follow suit, with the thought that having an IP address would be a sufficient condition to connect.

The problem on the IoT isn’t IP – the problem is all the stuff layered on top of it. Running protocols such as HTTP, SSL, and XML requires significant compute power and memory space. The average PC, smartphone, or tablet has enough horsepower today to do that, but the average sensor running on a smaller microcontroller does not. (ARM Cortex-M7 notwithstanding.)

To combat that, the industry has spawned a huge list of alternative, mostly non-interoperable IoT protocols. A partial list: 6LoWPAN, AllJoyn, AMQP, ANT+, Bluetooth, CoAP, DASH7, DDS, INSTEON, KNX, MQTT, NFC, RFID, STOMP, Thread, Weightless, XMPP, ZigBee, and Z-Wave. New consortia are popping up weekly with more ideas.

Searching for an IoT “god protocol”, one unifying end-to-end protocol serving all things, is silly. At one end, sensors have different requirements such as range, RF spectrum, security, topology, and power consumption. At the other, any successful IoT strategy will ultimately need to integrate with an IP-based cloud in some form. Greenfields of any scale rarely exist. IoT applications need to connect and exchange data.

The answer is building a multi-protocol bridge between sensors and actuators, mobile devices, and the cloud. Ideally, code would be open source, and would provide scalability to span a wide range of devices in large numbers. Additionally, transport would be reliable, surviving brief intermittency in wireless connections.

More and more organizations are embracing MQTT as part of the bridge. MQTT offers a full-up version running over TCP/IP, and a slimmed down version MQTT-SN for non-IP devices. Its publish/subscribe model allows topologies to scale while retaining real-time characteristics and configurable quality of service.

IBM started the whole MQTT movement as a message broker for mainframes and servers, with integration into WebSphere for web services. They then opened it up for embedded use in a release to OASIS and the Eclipse Foundation.

A big piece of IBM Bluemix is the IoT Foundation, a cloud-based instance of MQTT with predefined topic structures and message formats. Mobile apps are already using MQTT, with applications such as Facebook Messenger and Salesforce.com. IBM also has an e-book on MQTT in mobile.

Other recent developments to consider:

• ARM’s mbed device server seeks to replace a generic web server with one tailored for the IoT. Built from technology in the Sensinode acquisition, ARM has brought HTTP, CoAP, and MQTT together in one platform.
• 2lemetry has taken that a step further with ThingFabric, integrating protocol actors including MQTT, CoAP, and STOMP, along with extensibility.
• PubNub has taken a websocket connections approach running over MQTT, focusing on low latency, reliable delivery from a cloud implementation. There is a good PubNub guest post on Atmel Bits and Pieces describing the approach.
• Speaking of Atmel and Arduino, IBM has several recipes for leveraging Arduino with the IoT Foundation, such as an Arduino Uno connection example, and a series on implementing a cloud-ready temperature sensor.
• Open source motivates many folks, and one of the more interesting individual projects out there is a bridge for AllJoyn to MQTT. If successful, the implications could be significant, such as controlling home entertainment devices directly from Facebook on a mobile device.

Again, I don’t think there is a “god protocol” that will take over the IoT once and for all, satisfying each and every use case. The winners are going to integrate multi-protocol bridges to serve as wide a range of use cases as possible. The ability of MQTT to connect sensors and mobile devices to big data systems in real time is drawing more participants in.