IoT Gets Its Own Messaging Protocol Standard, MQTT

By: Jonah McLeod, Dir. of Corp. Mkt. Comm. at Kilopass Technology Inc.

Anyone creating applications for the Internet of Things (IoT) will soon have a standard messaging protocol, the Message Queue Telemetry Transport (MQTT). Created in 1999 by Dr. Andy Stanford-Clark of IBM, and Arlen Nipper of Arcom (now Eurotech), MQTT began life as a means of hobbyists automating their homes. (See Dr. Stanford-Clark’s YouTube TED Talk for more.) MQTT 3.1.1 entered a 60-day public review period, beginning July 7, 2014, in preparation for a member ballot to consider its approval as an OASIS Standard. The review will complete September 4, 2014.

MQTT enables the equivalent of a social network for things in that it provides a publisher-subscriber model of communications. Consider the sensors in an earthquake early warning system. Each time any sensor (client) detects earth movement it publishes its location and reading, a “topic,” to a server or message broker. Anyone who subscribes to this topic will be notified.  This example illustrates features of MQTT that make it well suited as an IoT communications protocol.  First, the protocol was designed as a lightweight protocol to work over lossy or constrained cellular or satellite network, where connections can be problematic.

In its simplest form, the protocol requires two bytes and allows for 15 different message types (one reserved for a total of 16). Five deal with connection to the message broker (server). Two establish connect and acknowledge connection to the broker.  One disconnects from the broker. The remaining two provide for a keep-alive function for the connection (ping request to broker and ping respond to client).

Five message types deal with clients that publish topics to the message broker using three levels of QoS (quality of service) 0, 1, and 2. With the first, the client publishes a topic without acknowledgement (assuming that as long as there is a network connection, the message broker received the topic). The second (level 1), the client publishes a topic and receives an acknowledgement from the broker.

The third (level 2) has extra handshakes to avoid the client having to republish the topic until acknowledgement. In this level of QoS, the client publishes a topic to the message broker, which generates a publish-receive response to the client. The client then issues a publish-release confirmation to the message broker. The broker then issues a publish-complete response to the client.  In this manner the broker acts as an intermediary between publishing clients and subscriber clients—the equivalent of a social network provider for things.

The remaining four message types deal with the subscriber. Two from the client to broker subscribe or unsubscribe to a topic. Two from the broker to the client acknowledge subscribe and unsubscribe to a topic.

MQTT was designed to accommodate the special needs of mobile applications as contrasted with HTTP, which was designed for the wired Internet.  For example, in Stanford-Clark’s TED Talk, he describes an application to provide commuters updates on ferry service in the English Channel. The application publishes the arrivals and departures of ferries at all the ports in the service area, an example of small amounts of data published continuously throughout the day from many clients published (ferries) to large numbers of client subscribers (commuters).

Pipelines are another example, which illustrates another feature of MQTT –– its ability to scale. In his presentation “MQTT and Java,” at the International Software Development Conference Q Com New York in June 2013, Peter Niblett, IBM Senior Technical Staff Member, cited the pipeline as giving rise to MQTT. Niblett explained that the pipeline had 4000 sensor nodes and had to be expanded two-fold. The existing network was built on polling where every sensor was queried for its status and a response was issued. It took on the order of 20 minutes to interrogate the entire pipeline. Doubling the number of sensors would mean over an hour to perform the task.

The solution Niblett described was based on changing the polling network into an exception reporting system, since many of the sensors’ status—temperature, pressure, control valve setting, etc.—changed only when oil was present. Oil like cargo doesn’t flow continuously but rather in response to orders. And like cargo, the progress of the shipment along its path of travel is important to monitor continuously. Using the exception system built around an early version of MQTT, the pipeline network could easily accommodate growth over time. It also reduced network traffic on the satellite link connecting the pipeline network to the back office servers.

Niblett cited a number of emerging applications that will be built around MQTT, including automobile companies to manage fleets of leased vehicles and ultimately to enable the connected car. Other applications included home monitoring for health and safety, financial notifications, asset tracking for common carriers and supply chain management. With a robust networking protocol like MQTT becoming a standard this year, the Internet of Things is set to enjoy the explosive growth that market analysts are predicting.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>