MQTT
There are a number of technical limitations and challenges associated with the creation and operation of a wireless sensor network. In many scenarios, however, a fully-connected network is not actually required. An alternative approach is to create a loosely coupled system in which individual nodes communicate by sending messages via a broker. The broker simply acts as a clearing house for messages, receiving them from individual nodes and forwarding them to any other nodes in the system which have registered an interest. Figure 7 illustrates this architecture.
Figure 1: Message broker architecture. A message received from on node is relayed to all other interested nodes
A message broker system can be thought of as a star topology, but the difference is that there is no direct connection between the nodes as there is in, say, a WiFi network. All of the connectivity is handled by the passing of lightweight messages, and nodes do not need to have any information about the source or final destination of those messages. Figure 1 uses the terms node and broker; some MQTT implementations use the terms client and server.
MQTT
One of the most popular message broker protocols at the moment is Message Queuing Telemetry Transport (MQTT). It runs over TCP and replaces http for simple messages. Its big advantage is its small packet size which is achieved by reducing the amount of information in the packet headers to a minimum. It c an do this because of the restricted range of operations that it allows. There are essentially three things that a node can do:
- Publish: a node sends a message to the broker
- Subscribe: a node registers an interest in a particular topic with the broker
- Unsubscribe: a node cancels its earlier interest in a topic
Topics
The job of the broker is to maintain a list of subscriptions, and when a message arrives, to forward that message to examine its topic and to forward it to any nodes that have subscribed to that topic. Topics are character strings used to label a message. They can be arranged hierarchically into a topic tree as shown in Figure 2 by concatenating them with forward slashes.
Figure 2: Example MQTT topic tree for a home automation
Each composite entry in the topic tree is known as a topic string, and
can be used in an MQTT message. In a home automation
scenario for example, the heating system in bedroom1 might publish regular
status messages about the temperature in the room using the topic string
myHouse/heating/bedroom1.
When subscribing to a topic, a node can use wildcards in order to cover
several branches of the topic tree. the plus sign (+) can be used to
represent any single level in the topic tree, and the hash sign (#) can be
used to represent any number of levels. Referring to the topic tree in
Figure 8, to subscribe to all messages about my house, a node might use
the topic string myHouse/# while to
subscribe to any messages about the kitchen the topic string myHouse/+/kitchen/#
could be used.
Quality of service
There is a limited number of options available for publishing messages. One of them though is that a node can specify that a message should be retained. This means that it will be kept on the server so that it can be passed to any new subscriber node. Non-retained messages are only forwarded to subscribers that are connected at the moment that the message is received by the broker.
Messages are allocated one of three quality of service (QoS) levels by the
publisher:
| Level | Name | Description |
|---|---|---|
| QoS=0 | at most once | 'Fire-and-forget' - messages are not retained, and neither are they acknowledged by the broker |
| QoS=1 | at least once | The message is retained by the sender until an acknowledgement (PUBACK) is received from the receiver. Messages may be sent several times if the PUBACK is not received within some timeout period. |
| QoS=2 | exactly once | In this highest quality of service level, there are two exchanges between the sender and receiver for each message to guarantee that the message has been processed correctly |
For more information about QoS levels, please refer to the IBM Knowledge Center link in the resources box at the bottom of the page.
Message contents
MQTT is agnostic regarding the datatype of the message payload. In other words, you can send anything you like as a message including text, numerical, binary or structured data such as XML or JSON. This makes it possible to pass images from a door entry camera, for example, to a smartphone app very easily.
The second link in the resources box provides a more in-depth description of how MQTT works. It also includes a worked example of using MQTT as the communications core of a taxi-ordering service.
Last will and testament
When first connecting to a broker, an MQTT client can specify a last will and testament (LWT) message that the broker will send if the client is disconnected unexpectedly. This can be useful, for example, to let subscribing clients know that that a publishing client is no longer available.
IBM Knowledge Center
MQTT Essentials
MQTT Essentials