The document presents a comparison of MQTT (Message Queuing Telemetry Transport) and CoAP (Constrained Application Protocol), two lightweight messaging protocols for the Internet of Things (IoT). It outlines their working principles, communication models, message types, and suitability for various IoT applications, highlighting key differences such as MQTT's publish/subscribe model versus CoAP's request/response model. The conclusion emphasizes both protocols' unique benefits and challenges in the context of IoT implementations.

1. MTECH(I.T) ADVANCED SEMINAR TOPIC PRESENTATION
Comparison of MQTT and CoAP Protocols
PRESENTED BY:
YUSUF HUMAYUN(20MTECHIT09)
DEPARTMENT OF INFORMATION TECHNOLOGY
NORTH EASTERN HILL UNIVERSITY
SHILLONG

2. Contents:
 Introduction
 What is MQTT
 Working principle
 What is CoAP
 working principle
 Message types
 Comparison of MQQT and COAP
 Conclusion
 References

3. Introduction:
IoT developers face a wide range of protocol choices like
MQTT and CoAP in creating applications for the Internet
of Things (IoT). These applications need to be able to
consume information from numerous devices. The choice
of protocol depends on the use case and where the
application will be staged in the software environment.

4. MQTT
o Expanded as “MQ Telementry Transport(MQTT)”.
o Also referred as Message Queuing Telemetry Transport.
o MQTT is referred as a light weight protocol.
o It is based on Publish/Subscribe model.
o Most suitable for machine to machine telemetry(m2m).
o Who designed it?
o Andy Standford clark- for IBM + Arten Nipper
o 1999
o Was a proprietary then, Made open and free in 2014.
Telemetry:the process of recording and
transmitting the reading of an instrument.

5. Contd., How it works?
• MQTT uses Publish/Subscribe. Central broker
plays a major role in the entire schema.
• Who play a major role here?
• It is MQTT broker.
• What is the Role of broker?
• It is to dispatch the messages to the ones
who subscribed
• The publishers sends the message to the
broker while it is being dispatched to the
subscribers.
• Will all the messages be received by all?
• Messages are published to topics.
• Clients can subscribe to a topic or a set of
related topics.
• The topic is a simple string. –Let us go
deeper into this!
Subscri
ber1
Subscri
ber2
Subscri
ber3
Publisher-Publishes
the humidity value
Public on the topic
“humidity”
Humidity
MQTT
broker
Subscribe to the
topic “Humidity”
Subscribe to the topic
“Humidity”

6. Contd.,
• This is similar to the TV/Radio Broadcast,
• The Tv or Radio stations do the broadcast and “viewers/Listeners” tune
it to the favourite ones.(Just like the Subscription done to the favourite
topics)
• This is a minor change in from the Tv scenario .Here, the clients who are
subscribed, the message gets removed from the broker.
• If there are no takers/ no subscribers for a particular topic, it
automatically get wiped off

7. Why topic?
• Here, clients does not have any address.(No address as you client can
relate it to E-mail address).Hence, the message can’t directly be sent
to the clients.
• So, what is the option?
• Topic comes to rescue.
• Messages shall be sent (Published) to the broker on a / with a
topic.
• Now, the broker does the work.
• It will filter the messages all based on “topic”.Then, the same shall
be distributed to the subscriber.(FilterSend)
• To make it better Topics connect Publisher and subscriber
• Topics are really kind of informal stuff!

8. Lets draw couple diagrams…
• So understand this!
• MQTT CLIENT:
• Well ,it collects information from the
sensors(Telemetry devices)
• Connects it to the messaging server-
broker.
• A topic shall be topic used to the
publish this message lo let other
clients understand what the message
is.
• An MQTT client in addition to
publishing can also be a subscriber.
• MQTT Broker:
• Here is where the protocols is
implemented
• It mediates/facilitates
Mqqt
Broker
Publisher
client
client
client
subscriber
subscriber

9. MQTT – Qos Levels
• MQTT is concerned about quality of service too!
• Three levels are supported:
• 0= At most once (Best effort, No Ack)
• 1=At least once(Acked, retransmitted if ack not received)
• 2=Exactly once (Request to send (Publish), clear-to-send)

10. CoAP- An in depth analysis
• Constrained Application Protocol-CoAP
• Iot- Definition:
• All about collecting data from various modules and to record it in cloud,
analyze and act ,whenever needed.
• Mere comes with necessity.
• Many devices/ equipment(things) needs to be connected to the internet.
• This cannot be done light!.
• Need protocols to come into the picture.
• CoAP in one such protocol,
• Developed by IETF(Internet Engineering Task Force)
• Developed to enable smart devices to connect the internet.
• Light weight protocol( today, multiple constraints are there in IoT
environment, because multiple things persist)
• It certainly uses lesser resources than HTTP and it is not a replacement of
HTTP.

11. Contd.,
• Remember this:
• Http is very popular and has no constraints/ restrictions.
• CoAP is designed for the device with Constraints.
• One should remember that HTTP runs over TCP.
• CoAP runs over UDP, not TCP.
• Since ,it is UDP, it is obviously connection less.
• CoAP is based on “Client Server Model”.
• As usual, clients shall send the request to the server.
• Servers shall respond.
• Clients are free to do “Get, Put,….”

12. Contd.,
• CoAP is based on REST.(Someone
can call it “RESTFUL”, other option
is “SOAPFUL”)
• What is REST?
• Representational State Transfer.
• This is s style or a method one
should say.
• To ensure a secure, Fault-tolerant
and scalable system.
• CoAP- Provides support to optimize
the datagram length.
• Provides GET/PUT/DELETE
methods support.
• Support Multicast.
• Retransmission supported (To
address the UDP weakness)

13. Contd.,
• Two layered.
• Lower layer  message
layer(Happens with UDP)
• Upper layer 
Request/Response everything
happens here!.

14. CoAP – Message layer – Messages Types
• Supports 4 types of messages.
1. Confirmable(CON)
2. Non Confirmable(NON)
3. Acknowledgement (ACK)
4. Reset(RST)
o Confirmable(CON)- Reliable
messaging
o Retransmit –Untill acknowledgement
arrives with the some message ID.
o Time out/ Recipient fails to process
message – will send RST with
response
c
Client Server
ACK [ADDR]
CON[ADDR]

15. Contd.,
NON (This is unreliable)
• No ack here
• Message ID port of the transaction .This
enables supervising.
• If not processing done by receiver. RST will
be sent
c
Client Server
NON (message ID)

16. CoAP –Request/ Response layer-messages
Piggy-backed: Client shall send request with a CON/ NON.
Ack shall be received immediately the corresponding token number and message
(Here, humidity).If not available, the failure code shall be embedded as a part of the
ACK
c
Client Server
CON/NON [MESSAGE_ID]
GET/Humidity
(Token number)
c
Client Server
ACK [MESSAGE-ID]
(Token Number)
60%
CON/NON [MESSAGE_ID]
GET/Humidity
(Token number)
ACK [MESSAGE-ID]
(Token Number)
NOT FOUND

17. Contd.,
• Separate response: when a
CON type message is sent to
the server from the client
and in case, the server is
unable to respond
immediately, An Empty ACK
shall be reverted.
• After some time(not sure
how much),when the server
can send the response ,it shall
send a CON message with
data, ACK shall be back from
the client
c
Client Server
CON/NON [MESSAGE_ID]
GET/Humidity
(Token number)
CON/NON [MESSAGE_ID]
GET/Humidity
60%
ACK
ACK

18. Contd.,
o Non confirmable request and response:
o Here, NON type message shall be sent from the
client to server .Server need not give ACK. Server
can send a NON type response in turn
c
Client Server
CON/NON [MESSAGE_ID]
GET/Humidity
(Token number)
CON/NON
[MESSAGE_ID]
GET/Humidity
60%

19. Message Format and Contents

20. Lets have quick view of comparison!
Criteria MQTT CoAP
Communication model Publish/Subscribe Request/Response
Base protocol TCP UDP
Communication mode M:N 1:1
POWER
CONSUMPTION
Higher than CoAP Lower than MQTT
Header size
It has 2 bytes sized
header
It has 4 bytes sized
header
Message types
16 different types
messeges
Only 4 types
Methods Connect, Disconnect,
Publish, Subscribe,
Unsubscribe, Close
Get, Post, Put, Delete
Application Reliability 3 level 2 level
Encryption TLS/SSL DTLS, IPSec
Default Port 1883/ 8883 (TLS/SSL) 5683 (UDP Port)/ 5684
(DLTS)

21. Conclusion
This paper has presented an evaluation of the two widely accepted and
emerging messaging protocols for IoT systems: MQTT, and CoAP.
MQTT and CoAP are rapidly emerging as leading lightweight
messaging protocols for the booming IoT market. Each protocol offers
unique benefits, and each poses challenges and tradeoffs. Both protocols
are being implemented for mesh-networking applications, in which
lightweight end nodes are a necessary aspect of almost every network,
and for gateway bridging logic to allow inter-standard communication.

22. References:
[1] Gazis, Vangelis, et al. A survey of technologies for the internet of things.,2015
International Wireless Communications and Mobile Computing Conference
(IWCMC). IEEE, 2015.
[2] Karagiannis, Vasileios, et al. A survey on application layer protocols for the
internet of things,Transaction on IoT and Cloud computing 3.1 (2015): 11-17.
[3] Grigorik, Ilya. Native web communication protocols and their effects on the
performance of web services and systems.,Transaction on IoT and Cloud
computing 3.1 (2015): 11-17.
[4] Karagiannis, Vasileios, et al. Making the web faster with HTTP
2.0.,Communications of the ACM 56.12 (2013): 42-49.
[5] Stansberry, J. ”MQTT and CoAP: Underlying protocols for the IoT.”,Electronic
Design (2015).
[6] Colitti, Walter, Kris Steenhaut, and Niccolo De Caro. ` ”Integrating wireless
sensor networks with the web.”,Extending the Internet to Low power and Lossy
Networks (IP+ SN 2011) (2011).