Messaging Protocols
Section - 1
Messaging Protocols in IoT
Messaging protocols are very important for the transfer of data in terms of messages.
They are useful for send/receive of a message to/from the cloud in IoT applications.
In the section, two messaging protocols are discussed.
1. Message Queuing Telemetry Transport (MQTT)
2. Constrained Application Protocol (CoAP)
Prof. Tushar J Mehta #3160716 (IoT and Applications) Unit 3 – Protocols for IoT 3
Message Queuing Telemetry Transport (MQTT)
As we know, IoT has one of the biggest challenges of resource constraints, the lightweight protocol is more preferred.
MQTT is widely used in IoT applications as it is a lightweight protocol.
Here, lightweight means, it can work with minimal resources and does not require any specific hardware architecture
or additional resources.
Prof. Tushar J Mehta #3160716 (IoT and Applications) Unit 3 – Protocols for IoT 4
MQTT
MQTT works with "publish – subscribe" pattern.
The MQTT working can be explained as follows.
1. The publisher (node) sends a message to the MQTT broker.
2. The MQTT broker transmits the message to the subscribed destinations.
Subscriber
Publisher MQTT Broker
Subscriber
Prof. Tushar J Mehta #3160716 (IoT and Applications) Unit 3 – Protocols for IoT 5
MQTT - Example
Suppose a temperature sensor is connected to any system and we want to monitor that temperature.
The controller connected to the temperature sensor publishes the temperature value to the MQTT broker with a topic
name: Hence, it is considered a publisher.
The MQTT broker transmits the temperature value to the subscribers.
Note that the only nodes which have subscribed to the topic will capture the
data and not the other nodes. Subscriber 1
Subscribed to:
Subscriber 2
Publisher MQTT Broker
Subscribed to:
Subscriber 3
Prof. Tushar J Mehta #3160716 (IoT and Applications) Unit 3 – Protocols for IoT 6
MQTT - Working
In MQTT, clients do not have any address like a typical networking scheme.
The broker filters the messages based on the subscribed topics.
The messages will then be circulated to respective subscribers.
The topic name can be anything in string format.
The MQTT working can be explained with an example of the television broadcast.
Client_Address
Prof. Tushar J Mehta #3160716 (IoT and Applications) Unit 3 – Protocols for IoT 9
QoS in MQTT
MQTT supports different QoS (Quality of Service) levels.
There are 3 layers of QoS supported by MQTT.
1. Level 0 = At most once (Best effort, No Acknowledgement)
2. Level 1 = At least once (Acknowledged, retransmitted if not received)
3. Level 2 = Exactly once (Requested to send, clear to send)
Prof. Tushar J Mehta #3160716 (IoT and Applications) Unit 3 – Protocols for IoT 12
Constrained Application Protocol (CoAP)
CoAP is designed by IETF (Internet Engineer Task Force) to work in constrained environment.
It is a one to one communication protocol.
CoAP is also light weight like MQTT protocol and it uses less resources than HTTP.
HTTP runs over TCP and is connection oriented while CoAP runs over UDP and it is connection less.
Prof. Tushar J Mehta #3160716 (IoT and Applications) Unit 3 – Protocols for IoT 21
CoAP Architecture
CoAP is based on the RESTful architecture (Representational State Transfer).
REST approach ensures the secure, fault tolerant and scalable system.
The CoAP optimizes the length of the datagram.
CoAP is connectionless protocol and it requires retransmission support.
Prof. Tushar J Mehta #3160716 (IoT and Applications) Unit 3 – Protocols for IoT 22
CoAP Layers
CoAP has four layers:
1. UDP
2. Messages Application
3. Request-Response
4. Application Request/Response
The message layer is designed to deal with UDP and asynchronous
switching. Messages
The request/response layer concerns communication method and deal
with request/response messages. UDP
In the request/response layer, clients may use GET/PUT/DELET
methods to transmit the message.
Prof. Tushar J Mehta #3160716 (IoT and Applications) Unit 3 – Protocols for IoT 23
Message Layer in CoAP
CoAP message layer supports four types of messages:
1. Confirmable – Reliable Messaging (CON):
This is reliable approach because the retransmission of message occurs until the acknowledgement of the same message ID is received.
If there is a timeout or fail of acknowledgement, the RST message will be sent from the server as a response.
Hence, the client will retransmit the message, this resolves the retransmission and it is considered a reliable approach.
Client Server
CON (ADDR)
Prof. Tushar J Mehta #3160716 (IoT and Applications) Unit 3 – Protocols for IoT 24
Message Layer in CoAP (Contd.)
2. Non-confirmable – Non-reliable Messaging (NON):
In this message transmission style, there is no reliability is ensured.
The acknowledgement is not issued by the server.
The message has ID for supervision purpose, if the message is not processed by the server it transmits the RST message.
Client Server
NON [Message ID]
Prof. Tushar J Mehta #3160716 (IoT and Applications) Unit 3 – Protocols for IoT 25
Message Layer in CoAP (Contd.)
3. Acknowledgement (ACK):
In this messaging, the traditional acknowledgement message sent as usual protocol.
We can compare this with regular handshaking scheme.
The handshake is automated process that establishes a link for communication before actual data transfer begins.
Client Server
CON (ADDR)
ACK (ADDR)
Prof. Tushar J Mehta #3160716 (IoT and Applications) Unit 3 – Protocols for IoT 26
Message Layer in CoAP (Contd.)
4. Reset (RST):
The receiver is expecting the message from sender of a particular message ID.
If no message is processed or received before specific amount of time (called timeout), the message called RESET is transmitted from
receiver.
This message informs the sender that there is a trouble in transmission of messages.
Client Server
CON (ADDR)
Timeout
RST
Prof. Tushar J Mehta #3160716 (IoT and Applications) Unit 3 – Protocols for IoT 27
Request-Response Layer in CoAP
There are three modes in CoAP request-response layer.
1. Piggy-Backed:
In this mode, the client sends the data with particular method (GET, PUT etc.) with token number and CON messaging method.
The ACK is transmitted by server immediately with corresponding token number and message.
If the message is not received by server or data is not available then the failure code is embedded in ACK.
Client Server Client Server
CON (ADDR) CON (ADDR)
GET/Humidity GET/Humidity
(Token Number) (Token Number)
ACK (ADDR) ACK (ADDR)
(Token Number) (Token Number)
72% NOT FOUND
Prof. Tushar J Mehta #3160716 (IoT and Applications) Unit 3 – Protocols for IoT 28
Request-Response Layer in CoAP (Contd.)
2. Separate Response:
Client Server
In this mode, the client sends the data with particular method (GET,
PUT etc.) with token number and CON messaging method.
CON (ADDR)
If the server is unable to respond immediately, an empty ACK will be GET/Humidity
reverted. (Token Number)
After some time, when the server is able to send the response, it sends
a CON message with data.
In response to that, ACK is sent back from client to server. ACK
.
.
.
.
CON (ADDR)
(Token Number)
60%
ACK
Prof. Tushar J Mehta #3160716 (IoT and Applications) Unit 3 – Protocols for IoT 29
Request-Response Layer in CoAP (Contd.)
3. Non-Confirmable Request and Response:
In this mode, the client sends the data with particular method (GET, PUT etc.) with token number and NON messaging method.
The server does not give ACK in NON messaging method, so it will send a NON type response in return with token number and its data.
Client Server
NON (Message ID)
GET/Humidity
(Token Number)
NON (Message ID)
(Token Number)
72%
Prof. Tushar J Mehta #3160716 (IoT and Applications) Unit 3 – Protocols for IoT 30
Li-Fi Working
The LED lamp is turned on and off at very high speed that human eyes can not capture it.
The light is received by the photo detector and it is passed for demodulation process and amplification to generate the
data stream sent by transmitter.
The received data stream is further given to receiver (e.g. mobile, PC etc.) via receiver app. All components working for
receiving the data combined known as receiver dongle.
Streaming Lamp
Server Driver
Content
LED LED
Internet Lamp Lamp
Power
Receiver dongle Photo Receiver dongle Photo
Detector Detector
Received App Amplification & Received App Amplification &
Data Processing Data Processing
Prof. Tushar J Mehta #3160716 (IoT and Applications) Unit 3 – Protocols for IoT 58
