Analysts forecast that up to 50 billion devices could be part of the Internet of Things (IoT) by 2020. This presents a challenge for engineers developing the underlying technology to integrate these devices seamlessly into the IoT. The majority of devices are likely to be relatively small and simple, i.e. sensors and/or actuators built into larger systems such as machines or factories. However the IoT is configured, there will be lots of microcontroller-enabled devices spread over large areas connected to cloud-based data hubs. To achieve this, engineers need a connection protocol that’s small, simple, robust, and secure.

A prime candidate to meet this challenge is MQTT, or Message Queue Telemetry Transport. MQTT is a simple protocol that lets an embedded device publish/receive messages in the cloud. It has minimal packet overhead compared to protocols like HTTP and is therefore very efficient, lending itself to low-power environments.

The MQTT publish/subscribe system consists of many clients, which are connected to a server acting as a broker. A client is both the producer and consumer of MQTT data. Figure 1 illustrates a simple MQTT publish/subscribe transaction. The MQTT messaging protocol is architected around several fundamental principles:

• A message broker acts as an intermediary between multiple subscribers. It’s a server and the centralized system through which client data is communicated.
• The publishing and subscribing elements never need to be connected.
• A subscriber subscribes to one or more topics.
• One published message can be sent to many subscribers interested in receiving information on a topic.
• A subscriber can receive messages from multiple publishers.
• A subscriber can unsubscribe from a topic at any time.

[Figure 1 | A simple publish and subscribe operation]

A client publishes free-format data to a broker using an application-defined “topic.” The broker transmits the data to all client(s) that have subscribed to that topic. Using wildcards, a single subscription can result in data from many clients being received. Similarly, data from a single publish action may be forwarded to many clients. Figure 2 illustrates how a mobile phone could communicate with a remote automobile to lock a car door.

1. The app on the user’s phone requests car to lock doors to topic “Message_Car001.”
2. Broker receives request.
3. Car001 receives message through subscription.
4. Car locks door and sends confirmation.
5. App receives confirmation.

• The message payload contains the instruction to lock the door. A range of other instructions could be sent through the same publish/subscribe system.

[Figure 2 | This is how to use MQTT to monitor and control a car locking system.]

MQTT provides three quality-of-service (QoS) levels that represent a trade-off between communication overhead and the assurance that a message will arrive. Level 0 is “fire and forget” with no guarantee the message will be received. Level 1 will guarantee the message will arrive at least once but maybe more than once. Level 2 will assure the message is received exactly once. Selecting an MQTT implementation that supports all three levels will give the developer the flexibility to optimize for their data requirements.

MQTT doesn’t guarantee secure connections, but can form a secure communication mechanism when used with the Transport Layer Security (TLS). TLS handles secure connections: the server and client authenticate each other using key exchange and negotiate a mutually acceptable encryption suite for the data exchange. MQTT version 3.1 allows use of a user name and password within a packet to allow a client to authenticate itself with the broker.

One often-overlooked weakness in security strategies is the quality of the MQTT messaging software itself. A recent spate of high profile security breaches occurred not because of hacked algorithms but because of poor quality source code. Episodes such as Heartbleed demonstrate that poor quality code can provide openings that a hacker can exploit to gain access. For these reasons, it’s advantageous to select a vendor who employs and can demonstrate evidence of quality software development processes. HCC Embedded has implemented an MQTT protocol that runs on its trusted MISRA-compliant TCP/IP stack and provides life-cycle evidence to validate its quality claims.

MQTT represents a small, versatile communication protocol that, when used with a security mechanism like TLS, can provide efficient, reliable, and secure connectivity for myriad small devices. However, not all MQTT implementations are the same. An application must be built on a platform of high quality, reliable software to ensure security and reliability.

David Brook is a Director at HCC Embedded.