MQTT

Getting to know about MQTT
• The MQ Telemetry Transport (MQTT) protocol was invented by Dr Andy Stanford-
MQTT was invented by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom, now
Cirrus Link) back in 1999, when their use case was to create a protocol for minimal
battery loss and minimal bandwidth connecting oil pipelines over satellite connection.
They specified the following goals, which the future protocol should have:
• Simple to implement
• Provide a Quality of Service Data Delivery
• Lightweight and Bandwidth Efficient
• Data Agnostic
• Continuous Session Awareness

Why MQTT ?
✤ The motivation for designing MQTT was to create a lightweight and bandwidth-efficient
protocol that was data challenger with support for multiple levels of Quality of Service
(QoS). Interestingly, even today, those are the same reasons for which MQTT is
chosen for implementing IoT solutions.
✤ Enables minimized sizes, pub/sub messaging across mobile networks.
✤ Network Usage/Power consumption/CPU Usage

To understand why MQTT is such a good fit for IoT developers, let's first
examine why other popular network protocols failed in IoT.
Why not HTTP???
The device could send in its data as an HTTP request and receive updates from the system as the HTTP
response. This request and response pattern does have some severe limitations:
• HTTP is a synchronous protocol. The client waits for the server to respond.-High latency
• HTTP is one way.
• HTTP is a 1-1 protocol. The client makes a request, and the server responds.No broadcast

MQTT & HTTP
MQTT HTTP
Design orientation Data centric-byte Document centric-It supports the
Multipurpose Internet Mail Extensions (MIME)
Pattern Publish/subscribe Request and response
Complexity Simple More complex
Message size Small, with a compact binary header
that is just two bytes in size
Larger, partly because status
detail is text-based
Service levels Three QoS settings All messages get the same
level of service
Data distribution Supports 1 to zero, 1 to 1, and 1 to
n
1 to 1 only

MEMORY COMPARISONS
3G Wifi
HTTPS MQTT HTTPS MQTT
receive msgs / hour 1,708 160,278 3,628 263,314
% battery / msg 0.01709 0.00010 0.00095 0.00002
msgs
(note losses)
240 / 1024 1024 / 1024 524 / 1024 1024 / 1024
send msgs / hour 1,926 21,685 5,229 23,184
% battery / msg 0.00975 0.00082 0.00104 0.00016

MQTT Terminology
• Client : Any publisher or subscriber that connects to the centralized broker over
a network is considered to be the client.
• Broker : The broker is the software that receives all the messages from the
publishing clients and sends them to the subscribing clients.Some of the
commercial implementations of MQTT brokers include HiveMQ, Xively, AWS IoT,
and Loop.
• Topic : A topic in MQTT is an endpoint to that the clients connect. It acts as the
central distribution hub for publishing and subscribing messages.
Example - building1/room1/temperature and building1/room1/humidity are valid topic
names.
wildcards - building1/+/temperature , building1/#/.
• Connection :MQTT can be utilized by clients based on TCP/IP. You can pass a
user name and password with an MQTT packet in V3.1 of the protocol. Encryption
across the network can be handled with SSL, independently of the MQTT protocol
itself.

Basic concepts of the MQTT protocol
Publish/subscribe : The MQTT protocol is based on the principle of publishing messages and
subscribing to topics, which is typically referred to as a publish/subscribe model.
Topics and subscriptions : Messages in MQTT are published to topics, which can be thought of
as subject areas. Clients, in turn, sign up to receive particular messages by subscribing to a topic.
Quality of service (QoS) levels :QoS is a major feature of MQTT, it makes communication in
unreliable networks a lot easier because the protocol handles retransmission and guarantees the
delivery of the message.
Also it empowers a client to choose the QoS level depending on its network reliability and
application logic.
QoS 0 (At most once)
QoS 1 (At least once)
QoS 2 (Exactly once)

QOS 0 – AT MOST
ONCE
QOS 1 – AT LEAST
ONCE
QOS 2- ONLY ONCE

Basic concepts of the MQTT protocol
Retained messages :
With MQTT, the server keeps the message even after sending it to all current subscribers. If a new
subscription is submitted for the same topic, any retained messages are then sent to the new subscribing
client.
Clean sessions and durable connections :
When an MQTT client connects to the server, it sets the clean session flag.Using the clean
session flag is optional.
If the flag is true ?
If the flag is false ?
The client will (or message):
When a client connects to a server, it can inform the server that it has a will, or a message,
that will be published to a specific topic or topics in the event of an unexpected
disconnection. A will is particularly useful in alarm or security settings where system
managers must know immediately when a remote sensor has lost contact with the network.

Benefits of using MQTT
MQTT was designed to overcome these limitations and issues and includes the following underlying principles:
•Simplicity: The protocol was made open so that it can be integrated easily into other solutions.
•Use of the publish/subscribe model: The sender and the receiver are decoupled. Therefore, publishers do not
need to know who or what is subscribing to messages, and vice versa.
•Minimal maintenance: Features, such as automated message storage and retransmission, minimize the need for
administration tasks.
•Limited on-the-wire footprint: The protocol keeps data that is overhead to a minimum on every message.
• Continuous session awareness: By being aware of when sessions have terminated, the protocol can take action
accordingly, thanks in part to a will feature.
•Local message processing: The protocol assumes that remote devices have limited processing capabilities.
•Message persistence: Through the designation of a specific QoS, the publisher can ensure delivery of the most
important messages.
•Agnostic regarding data type: The protocol does not require that the content of messages is in any particular
format.

MQTT Message format
The message header for each MQTT command message contains a fixed header, some messages
also require a variable header and a payload. The format for each part of the message header is
described in the following:
1.Fixed header:
The message header for each MQTT command message contains a fixed header header format.
2.Payload
This is the actual content of the message. MQTT is totally data-agnostic, it’s possible to send images, texts in any encoding, encrypted
data and virtually every data in binary.
https://www.facebook.com/notes/facebook-engineering/building-facebook-messenger/10150259350998920

CONNECTED CITY - EXAMPLE