Understanding MQTT Protocol Packet Format

MQTT protocol communicates by exchanging a series of predefined MQTT control packets. The MQTT packets consist of up to three parts in the following order as a 2-byte fixed header that appears in all MQTT packets, Variable Headers, and Payload that appear in some MQTT packets. This document describes how to format an MQTT Message or Packet.

MQTT Protocol Packet Types

Types of MQTT Protocol Control Packets are:

• CONNECT – Fixed Header / Variable Header / Payload – MQTT Client requests a connection to a Broker.
• CONNACK – Fixed Header – Acknowledge connection request.
• PUBLISH – Fixed Header / Variable Header – Publish message.
• SUBACK – Fixed Header / Variable Header / Payload – Subscribe acknowledgement.
• UNSUBSCRIBE – Fixed Header / Variable Header / Payload – Unsubscribe from a topic.
• UNSUBACK – Fixed Header / Variable Header / Payload – Unsubscribe acknowledgement.
• DISCONNECT – Fixed Header – Disconnect notification.
• PUBREL – Fixed Header / Variable Header – Publish release(QoS 2 publish received).
• PUBACK – Fixed Header / Variable Header – Publish acknowledgement.
• PUBREC – Fixed Header / Variable Header – Publish received(QoS 2 publish received).
• PUBCOMP – Fixed Header / Variable Header – Publish complete.
• SUBSCRIBE – Fixed Header / Variable Header / Payload – Subscribes to a topic.
• PINGREQ – Fixed Header – PING request.

MQTT Packet Sizes

The fixed header field consists of the control field, and the variable header contains the packet length field. The minimum size of a packet length field is 1 byte, which is for messages less than 127 bytes.

The maximum packet size is 256 MB. The minimum packet size is only 2 bytes with a single control field and a single packet length field. Smaller packets less than 127 bytes have a 1-byte packet length field. The Packets greater than 127 and less than 16383 use 2 bytes, and so on. 7-bits that are used with the 8th bit is the continuation bit.

Control Field

The 8-bit control field is the principal byte of the 2-byte fixed header. It is divided into two 4 bit fields and contains all protocol commands and responses. The first four most important bits are the command or message type field, while the remaining 4 bits are used as control flags.

Control Flags

While there are 16 possible flags, a limited is used. The Publish message makes the most use of these flags. The duplicate flag is used when a message is republished with QoS 0 or 1 or 2. QoS flags are used when publishing to indicate a QoS level of -0,1,2. The Retain Message flag is also used when publishing a message.

Remaining Length

The Remaining Length is the number of bytes left in the current packet, including variable header and payload data. The Remaining length does exclude the bytes used to encode the Remaining Length.

The Remaining Length is encoded using a variable-length encoding scheme that uses one byte for values up to 127. The least seven important bits of each byte encodes the data, and the most important bit is used to indicate there are following bytes in the representation. Thus, each byte encodes 128 values and one “continuation bit”. The greatest number of bytes in the remaining length field is four.

Variable Header

Some types of MQTT control packets have a variable header component. Variable-length header fields are not always present in MQTT messages. Some MQTT message types or commands require this field to carry additional control information. It remains between the Fixed Header and the Payload. The Variable Header will vary depending on the packet type.

Example: MQTT Connect Message Structure

As an example, let’s take a look at the details of the CONNECT message packet in the Bevywise MQTTRoute / MQTTBroker.

After establishing a connection between the MQTT client and the broker, the first packet must be a CONNECT packet. The CONNECT packet only needs to be sent once over the network connection. The second CONNECT packet sent by the MQTT client is ignored and disconnected.

Fixed Header

Variable Header

The variable header must have four parts. They are the protocol name bytes, protocol level, connect flags, and keepalive.

Protocol name bytes

MQTTRoute will disable false protocol name.

Protocol level

The protocol level for MQTTRoute is 4, other values lead to disconnection.

Connect flags

This field indicates the presence or absence of data in the payload.

Keep Alive

The MQTT client should send control packets that do not exceed the value of the defined Keep Alive. The Keep Alive value depends on the duration of the control packet of one transmission by the client.

MQTT Protocol Payload

The payload contains the MQTT client credentials (username, password, etc.). The client ID must be unique for each client. The broker responds with a unique client ID for each client. If you send a client ID in an empty field, the client will be rejected. The fields must be filled in the following order: Client ID, Will Topic, Will message, username, password.

The above fields must be in string format. Any packet that does not send a CONNECT packet after a reasonable amount of time will be rejected by the broker. After successful validation, the broker will respond in 2 format

• Check if the client already exists. If so, the broker will respond with the disconnection.
• The MQTT Broker will send a CONNACK packet with zero value.

After successful CONNACK, the broker will do a keepalive monitoring regularly.

To know more about the MQTT messages or packets structure, do visit the MQTT Developers page.

To know about the format of the MQTT-SN packets, visit the MQTT-SN Developers page.

Try our MQTT Broker for FREE and experience seamless connectivity.