This document introduces MQTT, a lightweight messaging protocol for IoT applications. It describes key MQTT concepts like publish/subscribe messaging, topics, quality of service levels, and client/broker communication. It also outlines MQTT control packets, connection handling, message delivery guarantees, and new features in MQTT 5.0 like enhanced scalability and session management.

1. Introduction to MQTT
The PubSub Messaging for IoT Applications
EMQ TECHNOLOGIES CO., LTD.
contact@emqx.io
Twitter @emqtt

2. Agenda
► Introducing MQTT
► MQTT Publish / Subscribe
► MQTT Client / Server
► MQTT Control Packets
► MQTT Connection and Session
► MQTT Message and QoS
► MQTT Client Libraries
► MQTT-SN Gateway
► MQTT5.0 Roadmap

3. What is MQTT?
► MQTT is a lightweight Client Server Pub/Sub messaging transport protocol for
IoT/M2M.
► MQTT is a Client Server publish/subscribe messaging transport protocol. It is light
weight, open, simple, and designed to be easy to implement. These characteristics
make it ideal for use in many situations, including constrained environments such as for
communication in Machine to Machine (M2M) and Internet of Things (IoT) contexts
where a small code footprint is required and/or network bandwidth is at a premium.
► Invented in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper. And now MQTT v5.0
is an approved OASIS Committee Specification.

4. Key features of MQTT
► The protocol runs over TCP/IP, or over other network protocols that provide ordered, lossless, bi-
directional connections.
► Use of the publish/subscribe message pattern which provides one-to-many message distribution
and decoupling of applications.
► Three qualities of service for message delivery
► QoS0: At most once
► QoS1: At least once
► QoS2: Exactly once
► A small transport overhead and protocol exchanges minimized to reduce network traffic.
► A mechanism to notify interested parties when an abnormal disconnection occurs.

5. MQTT Publish / Subscribe
Topic based Publish / Subscribe and Message Routing

6. MQTT Topic Name and Topic Filters
► Publish via Topic Name
► sensor/10/temperature
► chat/room/1
► channel/sports
► Subscribe via Topic Name or Filter
► sensor/+/temperature
► sensor/#
► A topic is a hierarchical structured string like Unix file path.

7. MQTT Topic Name and Topic Filters (Cont.)
► The forward slash (‘/’) is used as separator of levels within topic name or filter.
► sensor/10/temperature
► The number sign (‘#’) is a wildcard character that matches any number of levels
within a topic.
► sensor/#
► The plus sign (‘+’) is a wildcard character that matches only one topic level.
► sensor/+/temperature

8. MQTT Client / Server
► The topic based PubSub decouples the publisher from the subscriber.
► Both publishers and subscribers are “clients”.
► Clients are always connected with a broker via TCP, TLS or WebSocket
► The client (publisher) sends a message to a broker.
► One or more clients (subscribers) receive the message from a broker.

9. MQTT Connection over TCP, TLS or WebSocket
► MQTT over TCP
► The default port is 1883
► MQTT over TLS
► The default port is 8883
► MQTT over WebSocket
► The default port is 8083
► The URL path is ‘/mqtt’

10. MQTT Control Packets
► CONNECT/CONNACK
► PUBLISH
► PUBACK/PUBREC/PUBRE
► SUBSCRIBE/UNSUBSCRIBE
► PINGREQ/PINGRESP

11. MQTT CONNECT Packet
► ClientId: Unique ID per broker.
► MQTT Protocol Name and Version.
► Clean Session: Flag to indicate if the session must be persistent or not.
► Will Message: Its purpose is to notify other clients when a client disconnects
ungracefully. The broker sends this message on behalf of the client.
► KeepAlive: Period in secs the client is committed to send a PING to the
broker, so each other know if the other end is alive and reachable.

12. CleanSession Flag and Session Management
► A persistent session (CleanSession = false) means, that the broker will store
all subscriptions for the client and all missed messages (with Quality of
Service (QoS) 1 or 2).
► If a CONNECT packet is received with CleanSession is set to 1, the Client
and Server MUST discard any existing Session and start a new Session.

13. Persistent Session and Message Queue
► A persistent session (CleanSession = false) is identified by the clientId.
► The following is stored in the session:
► Existence of a session, even when there are no subscriptions.
► All subscriptions.
► All messages with a Quality of Service (QoS) 1 or 2, which are not
confirmed by the client.
► All new QoS 1 or 2 messages, which the client missed while offline.
► All received QoS 2 messages, which are not yet confirmed to the client.

14. Last Will and Testament
► Sent to subscribers when a client disconnects ungracefully (network error,
no PINGS within specified “Keep Alive” period).
► The LWT can be specified on the CONNECT message.
► It will not be sent if the client sends the DISCONNECT message (graceful
disconnect).

15. MQTT Client KeepAlive
► Keep Alive at the MQTT protocol layer because TCP/IP stacks “not always”
notify when a socket breaks.
► The Keep Alive in CONNECT Packet is a time interval measured in
seconds.
► It is the maximum time interval that is permitted to elapse between the point
at which the Client finishes transmitting one Control Packet and the point it
starts sending the next.

16. MQTT PUBLISH Packet
► Topic Name: A string, hierarchically structured with forward slashes as delimiters, i.e “building/1/room/10/humidity”
► QoS: Quality of Service Level. Possible values are (0,1,2).
► Retain Flag: Specifies if the broker saves the latest message for the specified topic as last known good value.
New clients that subscribe to that topic will receive the last retained message on that topic instantly after
subscribing.
► DUP flag: Indicates that this message is a duplicate and is resent because no ACK was received. Only relevant
for QoS greater than 0. Retries must be handled as an implementation detail by the client or the broker.
► Packet Identifier: Unique identifier between client and broker to identify a message in a message, but only
relevant for QoS 1 and 2. The client or the broker must set by the client or the broker.
► Payload: In binary form.

17. MQTT Retained Message
► If the RETAIN flag is set to 1 in a PUBLISH packet sent by a Client to a Server,
the Server MUST replace any existing retained message for this topic and store
the Application Message, so that it can be delivered to future subscribers whose
subscriptions match its Topic Name.
► If the Payload contains zero bytes it is processed normally by the Server but any
retained message with the same topic name MUST be removed and any future
subscribers for the topic will not receive a retained message.
► A retained message with a Payload containing zero bytes MUST NOT be stored
as a retained message on the Server

18. MQTT SUBSCRIBE Packet
► Packet Identifier: Only needed for QoS > 0.
► List of Subscriptions: A SUBSCRIBE message can contain an arbitrary
number of subscriptions for a client An arbitrary number of subscriptions are
valid for a SUBSCRIBE message. Each subscription consists of a topic and
QoS level.

19. MQTT QoS0 message - At most once delivery

20. MQTT QoS1 message - At least once delivery

21. MQTT QoS2 message - Exactly once delivery

22. MQTT Client Libraries
► GitHub: https://github.com/emqtt
► emqttc - Erlang MQTT Client
► CocoaMQTT - Swift MQTT Client
► QMQTT - QT MQTT Client
► Eclipse Paho: https://www.eclipse.org/paho/
► Python, Java, C, C++, Android, Go
► MQTT.org: https://github.com/mqtt/mqtt.github.io/wiki/libraries

23. MQTT-SN Gateway
► MQTT-SN stands for ‘MQTT for Sensor Networks’ which is aimed at
embedded devices on non-TCP/IP networks, such as Zigbee.
► MQTT-SN is a publish/subscribe messaging protocol for wireless sensor
networks (WSN), with the aim of extending the MQTT protocol beyond the
reach of TCP/IP infrastructure for Sensor and Actuator solutions.
► MQTT-SN specification can be downloaded from http://mqtt.org/new/wp-
content/uploads/2009/06/MQTT-SN_spec_v1.2.pdf.

24. MQTT-SN vs MQTT
► MQTT-SN runs on UDP, and MQTT runs on TCP.
► MQTT-SN use the TopicId to replace topic name in MQTT. TopicId is a 16 bits
integer which stands for a topic name.
► MQTT-SN introduce gateways in its network. Gateway translate between MQTT-SN
and MQTT, exchange messages between device and MQTT broker.
► MQTT-SN support sleeping client feature which allows device to shutdown itself to
save power for a while.
► Gateway need to queue downlink publish message for sleeping devices, and push
these message to devices once they are awake.

25. MQTT 5.0 Improvements
► Enhancements for scalability and large scale systems.
► Session management: Session Expiry & Message Expiry
► Reason Code & Reason String
► User properties, Payload Format Indicator & Content Type
► Shared Subscriptions
► Publish Reason Codes
► Publication Expiry interval
► Disconnect notification

26. MQTT 5.0 Roadmap
► EMQ R3.0 will release with fully MQTT 5.0 support
► The R3.0-beta.1 will be released before the end of February, 2018

27. Useful links
► EMQ & Github
- https://github.com/emqx/emqx
- https://emqx.io
► MQTT.org information
- http://mqtt.org
► MQTT 3.1.1 Specification
- http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html
► MQTT 5.0 Specification
- http://docs.oasis-open.org/mqtt/mqtt/v5.0/csprd01/mqtt-v5.0-csprd01.html
► Eclipse Paho Project
- http://www.eclipse.org/paho/

28. Thank you.
Site: https://www.emqx.io
Twitter: @emqtt
Phone: 400-696-5502
Contact: contact@emqx.io