MQTT Communication Patterns - Designing MQTT Topics for AWS IoT Core

MQTT Communication Patterns

IoT applications support multiple communication scenarios, such as device to device, device to cloud, cloud to device, and device to or from users. Although the range of patterns can significantly vary, a majority of MQTT communication models derive from three MQTT patterns: point-to-point, broadcast, and fan-in.


A point-to-point communication pattern is one of the basic building blocks of how devices commonly send and receive messages in MQTT. Two things use a single MQTT topic as the communication channel. The thing that receives the event subscribes to an MQTT topic. The thing that sends the message publishes to the same known MQTT topic. This approach is common in smart home scenarios where an end user receives updates about the thing in the home. In the following example, the robotic arm publishes a message on a topic that the mobile application subscribes to.

One to One Messaging in Point-to-point Communication

Figure 1: One to One Messaging in Point-to-point Communication

Point-to-point communication is not limited to one to one communication between devices. Point-to-point is also used in one-to-many communication where a single publisher can publish to individual devices using a different MQTT topic per device. This approach is common in notification scenarios where an administrator sends distinct updates to specific devices. In the following example, the repair service uses a set of point-to-point communications to programmatically loop through a list of appliances and publish a message.

Figure 2: One-to-many messaging in point-to-point communication


Broadcast patterns are used for one-to-many messaging. The broadcast pattern sends the same message to a large fleet of devices. In a broadcast, multiple devices subscribe to the same MQTT topic, and the sender publishes a message to that shared topic. A typical use of a broadcast pattern is to send a notification to devices based on the category or group of the device. For example, a weather station transmits a broadcast message based on a device's current geolocation, where devices are grouped by location.

The following illustration depicts an example where a broadcast pattern sends a message on a weather topic that all buses in the state subscribe to. Based on the current location of the bus, it can ignore or respond to the message.

Figure 3: One-to-many messaging in broadcast communication


The fan-in pattern is a many-to-one communication pattern and can be thought of as the reverse of the broadcast pattern. Multiple devices publish on a shared topic with a single subscriber to that topic. With the fan-in pattern, the subscriber has the added ability to leverage wildcards as the publishers all use a similar but unique MQTT topic. The fan-in pattern is commonly used to facilitate aggregation of telemetry to an IoT application.

In the following example, each end device publishes to an MQTT topic containing a known group identifier. The AWS IoT Rules Engine uses a wildcard subscription to receive the messages and route them to an Amazon Kinesis stream. Specifically, the robotic arms publish on a fan-in topic associated with a specific building (building1234). The administrative system receives all updates for the building using an MQTT wildcard (+).

Figure 4: Many to one communication in fan-in pattern

When devices communicate via the cloud using MQTT, avoid using the fan-in pattern to a single subscribing end device, because this routing may hit a non-adjustable limit on a single device MQTT connection. Instead, use the fan-in pattern to route a large fleet of messages to your IoT application via the AWS IoT Rules Engine. For large scale fan-in scenarios, combine the Rules Engine with a wildcard subscription pattern and a Rules Engine action to route to Amazon Kinesis Data Streams, Amazon Kinesis Data Firehose, or Amazon Simple Queue Service (Amazon SQS).