Why you should use MQTT in IoT projects and why SAP should support it

While designing an IoT device, there are multiple options to connect them. Once of the considerations should be the protocol being used to chat to other devices or to a server.

Previously, I would have easily chosen to make the interface REST based and have done so with Jeenode project a few years ago. But REST is not ideal as it is designed around a simple request/response model. So you ask “did my account balance change” and the response is returned “no it did not”. So you check again a few minutes later, and get the same response. Sound like a silly example? Actually we’ve learned that it is a very real issue that many customers obsessively check throughout the day, as many as 60 times inflicting a load on back-ends that they weren’t designed for.

REST via HTTP also wasn’t really designed to work on mobile networks. HTTP on mobiles is a bit heavy, fragile and slow and drains batteries quickly.

Andy Stanford-Clark and Arlen Nipper invented MQTT to solve a problem they had: how to do reliable messaging over unreliable networks? In an industrial environment with computationally ”challenged” devices, with restricted power due to solar or battery power, on extremely low bandwidth and often brittle RF communications including satellite. It had to work reliably, it had to use very few computational cycles, consume trivial power and could not hog what little bandwidth there was. And it had to be pub/sub so to break the cycle of violence being inflicted by heavy unnecessary workloads and bandwidth consumption due to all the request/response polling-based monitoring & control systems that were in place at that time.

So Arlen & Andy developed a very simple, extremely efficient publish/subscribe reliable messaging protocol and named it MQ Telemetry Transport (MQTT). A protocol that enabled devices to open a connection, keep it open using very little power and receive events or commands with as little as 2 bytes of overhead. A protocol that has the things built in that you need for reliable behavior in an unreliable or intermittently connected wireless environments. Things such as “last will & testament” so all apps know immediately if a client disconnects ungracefully, “retained message” so any user re-connecting immediately gets the very latest business information, etc.

Stephen Nicholas did a fascinating apples to apples comparison of MQTT vs HTTPS on Android, 3G and WiFi which you can read here. The 3G results are quite interesting:

• 93x faster throughput
• 11.89x less battery to send
• 170.9x less battery to receive
• 1/2 as much power to keep connection open
• 8x less network overhead

At this moment, MQTT is getting quite some tracktion and MQTT 3.1.1 has become an OASIS Standard with a royalty-free license for many years (read the OASIS press release here). On top of that, IBM has open sourced all of its MQTT source code via Eclipse.org including the new HTML5 MQTT over WebSocket JavaScript which enables MQTT in any HTML5 container including mobile browsers, desktop browsers, vehicle infotainment, consumer electronics. At the same time, open source brokers such as Mosquitto, client libraries for Java, Node.js, Python are getting increasingly mature. Also the firmware clients such as for Arduino and the ESP8266 are already very useful.

Initial versions of MQTT have been sending plain information over networks. In V3.1 you can also pass a user name and password with an MQTT packet of the protocol. Encryption across the network can be handled with SSL, independently of the MQTT protocol itself (it is worth noting that SSL is not the lightest of protocols, and does add significant network overhead). Additional security can be added by an application encrypting data that it sends and receives, but this is not something built-in to the protocol, in order to keep it simple and lightweight. These security features are especially meaningful when the IoT thing is running in e.g. a cloud scenario, in which the thing sends and receives data through the public internet.

SAP, eager to also claim its part in the IoT domain, unfortunately has not really shown any signs of offering MQTT on any of its services yet. It is currently being investigated, but nothing concrete has trickled down yet:

@wolf_gregor @jpenninkhof @schneidertho @h_neumann @qmacro MQTT is under evaluation, but not available as roadmap item, yet

— ruinogueira (@ruinogueira) January 26, 2015

It is really a pitty that SAP is not supporting MQTT yet, as this would require a MQTT to HTTP bridge to collect messages from things into the SAP HANA Cloud. As the MQTT protocol is mature and secure enough to be used over the public internet, I think SAP should also support this IoT standard, especially given the fact that SAP wants claim a good chunk of the IoT domain. I could think of hooking up MQTT to e.g. SAP’s HCI, but perhaps this would also be a good business case to get ESP (Event Stream Processing) to run on the HANA Cloud Platform