Internet of Things (IoT) architecture requires a different kind of message queue based communication than other types of software systems or big data solutions. Most of these solutions will implement some type of one-way messaging to integrate the different components of the application stack. With IoT, the messaging needs are more complex since IoT requires 2-way message communication between the server-side / cloud components and the IoT hardware devices.

IoT Messaging Architecture

Traditional distributed systems and asynchronous processing architectures utilize message queues or brokers to handle passing messages between the different components of the software system. This enables software systems to handle massive amounts of events and data at scale. However, the Internet of Things requires a different kind of messaging.

The messaging used by traditional distributed systems and asynchronous processing architectures uses a message communication process that only works in one direction. Messages and event telemetry are able to be sent to the Cloud in massive amounts and processed at high scale.

This 1-way messaging (also referred to as Device-to-Cloud) doesn’t account for the “Command and Control” style messaging required by Internet of Things (IoT) architectures. IoT architectures also require the use of “Cloud-to-Device” messaging to implement the ability to send “Command and Control” messages back down to the devices.

The above diagram visualizes a simple IoT architecture including the following components:

• Smart Thermostat or other IoT device hardware
• Cloud message queue / broker and other system components
• Smartphone or other device enabling local or remote user interaction

With this 2-way IoT messaging architecture, the system is able to (1) receive event telemetry from the IoT Device, (2) enable user interaction with the software system, and (3) sent “Command and Control” style messages back down to the IoT device based on user interaction or other events generated by the system.

2-way IoT Messaging

The 2-way messaging needs of Internet of Things solutions include sending device telemetry (or event data) from the device to the cloud, as well as the ability to send messages / events back down from the cloud to the device.

Device-to-Cloud Messaging

This is sending messages from the IoT Device(s) in the solution to the Cloud-based components of the application. This is the primary way that the sensor readings and other event telemetry are gathered from the devices and sent to the cloud.

Device-to-Cloud messaging is the same type of message / event communication that’s used in any other type of Asynchronous Programming model used in distributed systems and Big Data architectures that need to handle massive amounts of events and messages at scale.

Here are some example use cases of Device-to-Cloud messaging:

• Send sensor readings from the IoT Device to the Cloud
• Send event telemetry from the IoT Device to the Cloud

These event / messages sent up to the Cloud to a message queue or message broker. After the events / messages are receive by the message broker, they are then gathered into a message stream that is consumed by Real-time or Batch processing components.

Cloud-to-Device Messaging

This is sending messages from the Cloud-based components of the application down to the IoT Devices. This type of messaging is a bit different than the messaging used by other Big Data or Distributed systems that use asynchronous communication through message queues.

Cloud-to-Device messaging enables the software solution to be able to integrate the Cloud-based components to send Command-and-Control or other types of messages to the IoT Devices.

Here are some example use cases of Cloud-to-Device messaging:

• Send control messages from the Cloud to the IoT Device(s) to modify device configurations.
• Send control messages from the Cloud to the IoT Device(s) to instruct them to change their behavior.
• Send command messages from the Cloud to the IoT Device(s) giving the ability to push down firmware updates to the device(s).
• Send messages from the Cloud to the IoT Device(s) giving the ability to provide user feedback based on events received.

Most message queues or message brokers do not support this second path of message communication to send messaged down to the IoT devices.

IoT Message Broker / Queue

The 2-way messaging architectures of Internet of Things (IoT) solutions require more than just the usual Message Queue or Message Broker user by other disconnected systems. Traditional messaging services only implement 1-way messaging as a means of providing asynchronous communication between application components. IoT solutions have a different requirement that utilizes 2-way message to provide a more integrated communications architecture between the Message Broker or Queue, and the IoT devices.

Traditional message brokers or queues support anywhere from one-to-many connected clients sending messages to the broker. Different message brokers supports varying levels of scalability; including support for massive amounts of messages in Big Data type scenarios. Even though there can be many connected clients, there is limited ability to manage a large amount of connected clients in the realm of thousands or even millions of connected devices. In these cases many traditional messaging services will have a limit on the number of access keys that can be managed with the service, so large amounts of devices would need to share access keys; which can cause some security issues.

Message Brokers / Queues that are built for the Internet of Things (IoT) support some additional features so they can implement 2-way messaging reliably. The primary feature for this is some kind of IoT Device Management. By enabling the ability to manage the list of individual IoT Devices that are connected, the Broker is able to unique identify, authenticate, and address each IoT Device to enable the “Cloud-to-Device” communication piece of an IoT Messaging Architecture.

IoT Message Brokers / Queues offer the following additional benefits for IoT solutions that traditional message brokers do not:

• Device Management to enable per-device authentication / authorization, as well as revocation.
• Device Identities to be able to track what messages / events come from each of the connected IoT Devices.
• Device Identities also enable the ability to uniquely address specific IoT Devices to be able to support “Cloud-to-Device” messaging and send messages down to specific IoT Devices.

While you can use most traditional Message Brokers / Queues for IoT Solutions, the use of IoT Message Brokers / Queues will enable easier development, deployment, and management of IoT solutions. Manually building out 2-way messaging, device management, and device identities for an IoT solution can be time consuming, expensive, and pose potential security risks. By utilizing a Message Broker / Queue specifically built for IoT enables the device management, device identity, and 2-way messaging capabilities to be taken advantage of in an easier, more secure, and cheaper manner.

IoT Brokers / Queues are among the many different PaaS (Platform-as-a-Service) offerings provided by cloud providers. In the Microsoft Azure cloud, the Azure IoT Hub service provides an IoT Message Broker service that supports massive amount of events / telemetry from billions of connected IoT devices. As a PaaS service, it’s offered as a fully managed offering that eliminates the need to setup and maintain any Virtual Machines in the cloud, and instead focus on building and managing the IoT solution. Other than the IoT Message Broker features listed throughout this article, the Azure IoT Hub service also supports a number of additional features that enable more robust IoT solutions to be built in the Microsoft Azure cloud.

About the Author