Internet of Things is a computing concept in which various physical devices, vehicles, buildings, systems and services are connected over internet to achieve a wide range of use cases. Technology world is taking strong efforts to connect intelligent things and develop smart solutions. Few popular examples are the efforts made by technology leaders in the field of connected home, connected vehicles, smart cities, industrial or building automation etc.
Figure 1 : Internet of Things
Please refer “Credits” section to know credits for image used
Communication between the connected things is a key factor in IoT solutions. Battery operated devices running in a constrained network are mostly common in IoT solutions. So, the communication protocol used should be lightweight, consume less energy and suit such constrained environments. Various messaging protocols are defined and published to serve this purpose. This series of blogs will discuss in detail about the popular IoT messaging protocols such as MQTT, MQTT-SN and CoAP
Message Queuing Telemetry Transport (MQTT) is a lightweight publish-subscribe messaging protocol. It is a broker-controlled and topic based messaging protocol. MQTT runs over TCP/IP or any other network protocol that provides ordered, lossless and bi-directional connections.
Message flow in a MQTT based solutions is as follows,
- MQTT clients connects with a pre-known broker.
- MQTT clients can act as a publisher, subscriber or both.
- Publishers sends the messages with a topic name to MQTT broker.
- Subscribers sends the topic subscription messages to MQTT broker.
- MQTT broker controls the message flow, receives the messages from publishers and routes the message to interested subscribers.
- A MQTT broker can connect as a client to another broker to form a MQTT bridge (This concept is not discussed in specification). MQTT bridges will be helpful in scaling up the MQTT nodes connected to a broker.
Figure 2 : MQTT entities
Please refer “Credits” section to know credits for image resources used.
In the above example,
- A smart thermostat in a connected home acts as a MQTT client, publishes temperature topic (Ex: /HomeX/Thermostat/CurrentTemp) to MQTT broker and subscribes to thermostat control message topics (Ex: /HomeX/Thermostat/SetTemp).
- An application running in a smart phone acts as a MQTT client, subscribes to temperature topic and publishes thermostat control message topics to MQTT broker.
- Server running in cloud acts as a MQTT broker and controls the message transaction between the components in this home automation solution.
MQTT is invented by IBM and Eurotech. MQTT v3.1.1 is an OASIS standard. TCP/IP port 1883 is reserved with IANA for MQTT. TCP/IP port 8883 is registered for using MQTT over SSL.
MQTT defines fourteen type of control messages for the communication between clients and brokers such as CONNECT, PUBLISH, SUBSCRIBE, UNSUBSCRIBE, DISCONNECT etc.
Every MQTT message contains a fixed header, some messages contain a variable header and payload associated with it. Smallest MQTT message will be 2 bytes. Maximum size of a MQTT message can be upto 256 MB.
MQTT offers three type of QoS (Quality of Service) for message delivery as described below,
- QoS 0 – At most once delivery
Subscriber receives the message once or not at all. No retry is performed from the publisher.
- QoS 1 – At least once delivery
Subscriber receives the message at-least once. Subscriber may receive duplicate messages.
- QoS 2 – Exactly once delivery
Subscriber receives the message exactly once.
Clients can communicate the required QoS to MQTT broker in publish and subscribe messages. These QoS levels are achieved with the help of acknowledge messages from the receiver end.
Real world implementations
Microsoft’s Azure IoT, Amazon’s AWS IoT and IBM’s Watson IoT platforms supports communication over MQTT protocol. Facebook messenger for mobile uses MQTT. Other popular real world implementations are listed here.
MQTT defines simple text based authentication of MQTT clients with username and password when connecting to MQTT broker. Additionally, data sent over network can be encrypted using TLS/SSL. Security mechanisms can be added at application layer independent of MQTT. It is also recommended to use industry specific security models. OASIS have defined NIST cybersecurity framework for MQTT here.
Where MQTT fits in IoT ecosystem ?
As MQTT is defined to work on top of ordered and lossless network protocols, it can be used as a messaging protocol over the internet as stated in the examples below,
- Device to Cloud server and vice versa – In a use case where a smart device should directly communicate with a cloud server, MQTT can be used as a messaging protocol.
- Gateway to Cloud server and vice versa – In an ecosystem, where multiple battery operated devices are connected to a IoT gateway in a local network, MQTT can be used for messaging between IoT gateway and Cloud server. Some other protocol that works on lighter network protocol like UDP can be used for communication between devices and IoT gateway in a local network.
- MQTT is widely adopted. IoT platforms of technology leaders supports communication over MQTT.
- MQTT is used in scalable IoT platforms like AWS IoT, Azure IoT hub and IBM Watson IoT.
- Publish-subscribe message pattern provides one-to-many message distribution and decoupling of applications.
- Community participation is high and many open source implementations in different programming languages are available for MQTT and it is listed here.
- Supports MQTT sessions to be continued over multiple network sessions (network disconnect and reconnect).
- Supports wild-card topic subscription.
- Allows subscribers to know the disconnection of publishers using WILL topic and message features.
- Public MQTT brokers are available for quick demos.
- Provides three level of QoS for message delivery.
- Allows new subscribers to receive the recent message in the interested topic using RETAIN message feature.
- Requires ordered and lossless network protocol like TCP. Long living TCP connections may be an over-ask for some battery operated devices. In an IoT solution where a power constrained device communicates directly to cloud server over MQTT, long living TCP connections should be avoided with a proper design and message contracts.
- Does not support dynamic discovery of MQTT broker or topic. MQTT expects clients to know MQTT broker and topics priorly.
Entire content of this series of blogs is available here.
- MQTT v3.1.1 specification from OASIS, 29 Oct 2014.
- MQTT community website, github repo and real world MQTT implementations.
- MQTT and the NIST Cyber Framework v1.0 specification from OASIS, 28 May 2014.
- MQTT bridge concept, IBM, 17 Mar 2017.
Image used in “Figure 1” is used as it is from the link “http://www.rklesolutions.com/blog/internet-of-things-business-impact/”.
Resources used in “Figure 2” are downloaded from web as follows,
- Smart thermostat image is downloaded from “https://dominickcomfort.com/heating-cooling/equipment/accessories/thermostats/”
- WiFi access point or router image is downloaded from “https://www.netgear.com/home/products/networking/wifi-range-extenders/EX6200.aspx?cid=wmt_netgear_organic”
- Cloud image is downloaded from “http://www.iconarchive.com/show/long-shadow-media-icons-by-pelfusion/Cloud-icon.html”
- Cloud server image is downloaded from “http://www.pngall.com/cloud-server-png”
- Smartphone in hand image is downloaded from “http://www.freepngimg.com/png/298-smartphone-in-hand-png-image”
- WiFi logo and waves are downloaded from the links,