
MQTT Communication Protocol
The MQTT protocol was developed in 1999 for the oil and gas industry. Engineers needed a protocol that consumed minimal bandwidth and energy for monitoring pipelines via satellite.
01.07.2024
6 mins
The MQTT protocol was developed in 1999 for the oil and gas sector. Engineers needed a protocol that consumed minimal bandwidth and energy for satellite monitoring of oil pipelines. Initially, it was known as "Message Queuing and Telemetry Transport" because IBM’s MQ series supported its early phase. In 2010, IBM released MQTT 3.1 as an open protocol. Later in 2013, the protocol was submitted to OASIS (Organization for the Advancement of Structured Information Standards) for further development. OASIS published version 5 in 2019. MQTT has seen multiple versions, such as 3.0, 3.1.1 (version 4), and 5.0. It is widely used in industries like automotive, logistics, manufacturing, smart systems, consumer goods, and transportation.
MQTT stands for "Message Queuing Telemetry Transport" and is a standard for IoT communications. It is a publish/subscribe messaging protocol designed for machine-to-machine communication. It includes two main components: broker and client.
The MQTT broker is essentially a server, while clients are devices connected to this server. Publishing is when a client sends data to the broker, and subscribing is when it receives data.
Why MQTT?
- Lightweight and efficient
- Supports bidirectional communication
- Scalable for millions of IoT devices
- Reliable messaging (QoS 0, 1, 2)
- Supports insecure networks
- Offers robust security: TLS encryption, OAuth
MQTT Components
MQTT operates with a publish/subscribe model. A client can be any device (server, microcontroller, mobile, PC) with an MQTT library. A publishing client sends messages, while a subscribing client receives them. The broker handles message reception, filtering, and delivery to relevant subscribers. Clients and broker communicate over an MQTT connection.How MQTT Works
A client connects to a broker, then can publish or subscribe to messages. The broker routes incoming messages to appropriate subscribers based on the topic. Key elements include Publish/Subscribe, Messages, Topics, and Broker.- Publish/Subscribe: Devices publish or subscribe to specific topics. A smart home app, for instance, may subscribe to the "Lights" topic to count active lights.
- Messages: These carry data (commands, sensor readings) between devices. Clients publish these in byte format and can use formats like text, binary, XML, or JSON. For example, a light-on message may be published under "livingroom/light".
- Topics: Hierarchical strings (e.g., "home/groundfloor/kitchen/temp") define where messages are published or subscribed.
- Broker: Receives all messages, filters them, identifies subscribers, and delivers messages accordingly.