Comparison of IoT protocols: CoAP and MQTT
EECS 780 Term Paper – Prof. James P.G. Sterbenz
1 December 2017
MQTT and CoAP
are the leading lightweight messaging protocols for the IoT market providing
machine-to-machine (M2M) communication. Each protocol has some advantages over
the other but some disadvantages as well. They are implemented for
mesh-networking applications, where end nodes are lightweight. MQTT uses a
“publish/subscribe” model. It uses a centralized MQTT broker to manage and
route messages between nodes. The publish/subscribe models provide several
advantages like scalability, space and time decoupling, and security. CoAP is a
client/server protocol defined by IETF. Its main purpose is to use in
constrained environment such as lossy networks.
compares the strengths and weaknesses of MQTT and CoAP in performance and
security standpoints utilizing the existing research done to compare
performance between these two protocols in narrow bandwidth, high latency, and
high packet loss conditions. CoAP uses UDP, and its performance is better even
with less server utilization. MQTT performs better at higher server
utilizations. This paper compares these protocols through different scenarios to
help choose the appropriate protocol.
IoT or “Internet of Things” is one of the hot topics in communication
networks, as well as in information technology due to amount of data it
generates. From the networking standpoint, it is important to understand the
underlying mechanisms which makes IoT possible. IoT is wireless networking of
smart objects, which provides machine to machine communication. It consists of
several thousands of machines connected to the Internet and exchanging enormous
amount of data. This data is transmitted via the networks, and the introduction
of IoT brought along with itself the huge amount of traffic flowing through the
network. In this paper, we will focus our discussion
mainly on two protocols, Message Queue Telemetry Transport (MQTT) protocol and
Constrained Application Protocol (CoAP). These protocols are highly
popular application layer protocols in IoT implementations.
of Things (IoT)
Any physical device, whether personal objects such as smart phones or
laptops, or electronic equipment which can connect to the Internet can serve as
the sender for IoT data. With the increase in the processing power and storage
among devices, and decrease in the actual size, these devices can be equipped
with sensors, which are used to transmit real time information, providing an
always-connected model Kraijak 2015. Kraijak 2015 provides a generic architecture for IoT which consists of
five layers. Perception layer, which consists of the sensor devices such as
RFID, Zigbee, Infrared etc. This layer gathers information from across these
sensors and passes to upper layer which is Network layer. Network layer is
responsible for secure transfer of this information and maintain
confidentiality for the sensitive information. Middleware layer stores and
process the information received from lower layers. Application layer is
responsible for application management and Business layer is responsible for
service management, which provides the results used in decision making.
Kraijak 2015 discusses several different applications of IoT such as
Assisted driving, Sensing, Identification and Authentication, Comfortable homes
and offices, Social Networking.
Implementation of IoT requires a hardware platform, network protocol and
data protocol. Hardware components can be power sources, memory storage and
processing, and gather data in IoT devices. While choosing a protocol, one must
consider the amount of data that needs to be send, network resource
availability, frequency of data transfer and hardware platform resource
There are many application protocols proposed for IoT such as CoAP,
REST, XMPP, AMQP, MQTT, DDS etc. Each protocol provides specific set of features.
But with this variety of protocols, there is also an interoperability issue. As
an example, devices without enough resources to support TCP/IP communication
usually use UDP based communications. But due to this, they are unable to
interoperate with devices which have plenty of resources and support TCP/IP Guizani
2015. Also, the current range of IoT protocols are unable to offer QoS
There are security and privacy concerns around IoT. Attackers can access
the devices with front end sensors and manipulate the information. These unsecure
devices lead to loss of sensitive information. The communication needs to be
secured. Storage and processing of data must involve authentication mechanisms Kraijak
Messaging Protocols Overview
Queuing Telemetry Transport) Uses TCP/IP. Publish subscribe model requires a
message broker (switch). Due to use of TCP, MQTT provides reliability and
Message Queuing Protocol) Uses TCP/IP. This also supports a publish subscribe
protocol but it differs from MQTT since this is a point-to-point protocol
whereas MQTT is many-to-many. Due to use of TCP, AMQP also provides reliability
(Extensible Messaging and Presence Protocol) “used by wide range of
applications including instant messaging, presence, multi-party chat, voice and
video calls, collaboration, lightweight middleware, content syndication, and generalized
routing of XML data.” XMPP
Application Protocol) Uses UDP designed specifically for IoT uses request
response model like HTTP.
Distribution Service) publish-subscribe communications for real-time and
MQTT protocol runs over TCP/IP and is based on publish/subscribe model.
It was developed by IBM.
“MQTT is a
lightweight broker-based publish/subscribe messaging protocol for small code
footprints (e.g., 8-bit, 256KB ram controllers), low bandwidth and power,
high-cost connections and latency, variable availability, and negotiated
delivery guarantee” Hedi 2017. MQTT is a broker based protocol. It helps in
offloading the IoT devices so that they can handle large number of server
requests. There is another variant of MQTT protocol called MQTT-SN, for sensor
networks. It follows the same publish and subscribe model as MQTT and
translates messages between clients and servers.
With the use of
MQTT broker, publishers and subscribers do not need to know each other which is
one of the major advantages of this protocol. The publishers and subscribers can
communicate at different times and do not need to be familiar with each other Shriramoju
three types of services. “At most once”, is a best effort service but there is
no guaranteed delivery. “At least once” provides assured delivery but can
result into duplicate messages. “Exactly once” sends a message only once and
there is no duplication.
Any IoT object
can be MQTT client that sends or receives telemetry data. MQTT client should first
connect to a messaging server and must declare himself whether he is a
subscriber or publisher. Figure 1 shows the basic model for MQTT where MQTT
clients can act as either a subscriber or a publisher and they send messages to
Figure 1: Message queuing
telemetry transport protocol modelHedi 2017
One of the
MQTT implementations include the Intel IoT Platform. Intel IoT platform
consists of middle ware, connectivity and security components. “It supports
ZigBee, Cellular 2G/3G/4G, BlueTooth, Serial, USB, VPN, Wi-Fi and MQTT” Guizani
CoAP is an application layer protocol which provides reliability and
congestion control over unreliable UDP. It is designed for use in lossy and low
powered networks. Since a lot of IoT devices function under a constrained
environment, CoAP was specifically designed by IETF to be used in such
environment, particularly for IoT devices. It is a stateless, web transfer
protocol which provides a request and response interaction model between application
CoAP provides several features as are also highlighted in Bhalerao
2016. It consumes low power and provides less overhead in terms of memory
which makes it attractive for use in lossy and low powered networks. It is a RESTful
protocol and has HTTP like semantics for interactions between clients and
servers. To provide reliability, it provides the use of optional end-to-end
acknowledgements. But in case of congested networks, use of ACKs can also lead
to spurious retransmissions and thus reduction is throughput. There are basic
methods like exponential backoff which can be used to solve this problem. There
is also a variation of CoAP called “CoAP Congestion Control Advanced(CoCoA)”
which uses Round trip times (RTTs) along with confirmable message and ACK. It
calculates parameterized retransmission time out using two estimator algorithms.
CoCoA has been able to reduce the quantity of MAC layer buffer overflows.
Hedi 2017 provides few more features of CoAP-
URI and Content-type support, Simple proxy and
caching capabilities, A stateless HTTP mapping, allowing proxies to be built
providing access to CoAP resources via HTTP in a uniform way or for HTTP simple
interfaces to be realized alternatively over CoAP) Hedi 2017.
With the use of UDP, CoAP experiences a low overhead as compared to MQTT.
CoAP supports asynchronous communication between endpoints. A message that does
not require reliable transmission can be sent as a non-confirmable message
(NON). Since it consumes less energy, it is generally implemented for low power
devices Hedi 2017. Figure 2 shows the two models of CoAP, with reliable and
Figure 2: Reliable and non-reliable
transmission with CoAP Hedi 2017
CoAP provides three commands for exchanging messages-
GET, PUT and DELETE. In case of GET CoAP caches the reponse so that for similar
requests, reponse time in decreased, which also decreases the overall bandwidth
consumption of the network. Thus with more and more GET request messages, the
average response time decreasesKayal 2017.
5. Comparison of MQTT and CoAP
One of the main differences between MQTT and CoAP can be found in the
transport layer. MQTT runs on top of the Transmission Control Protocol while
CoAP runs on top of the User Datagram Protocol.
MQTT is a many-to-many communication protocol. Multiple MQTT clients can
exchanges messages through a centralized broker. The publishers can send
messages to the brokers which in turn decides which subscriber will receive the
message. CoAP is a one-to-one protocol for transferring state information
between client and server Hedi 2017.
Thangavel 2014 compares the performance of CoAP and MQTT using a
common middleware. Their results show that in high packet loss networks, MQTT
experiences higher latency than CoAP which is understandable due to high
reliability requirement of MQTT. In
Chen 2016, the authors have performed various quantitative comparisons among
TCP-based protocols and UDP-based protocols including MQTT and CoAP
respectively. In order to find results for the change in bandwidth consumption
by these protocols in different environments, experiments were performed with
increased network latency and increase in packet loss rate. It was determined
that since UDP does not do any retransmissions even with packet loss, protocols
based on UDP (CoAP) do not experience any change in bandwidth consumption.
Where in TCP based protocols (MQTT), this consumption increases with packet loss
and high latency.
When the network conditions are poor (due to high latency), MQTT does
not suffer from packet loss. But CoAP is well suited for applications that
require low latency and less bandwidth consumption.
Based on the research done to compare the response time of these
protocols for a smart parking application, since CoAP uses UDP for
communication, it performs better at lower utilization as shown in Figure 3.
MQTT performs better at higher server utilizations due to high overhead with
the use of TCP Kayal 2017.
Figure 3: Mean response time for
CoAP & MQTT vs server utilization Kayal 2017
5.1.1. Lossy network conditions
2016 compares the CoAP and CoCoA Congestion control protocols. CoCoA requires
maintenance of state for the estimators and has higher overhead. But it also
performs conservatively in a lossy environment.
When there is less congestion in the
network, there are a lower number of congestion-related packet losses, and thus
CoAP and CoCoA perform similarly. However, as the data rate increases creating
congestion in the network, the congestion-related losses increase and CoCoA
performs better than CoAP, delivering around 20% more packets Bhalerao 2016.
With the increasing number of devices that have becomes a part of the
IoT world, security becomes one of the major concerns, since now the attack
surface is not only limited to information systems that need to be secured
against such attacks, but instead any device which can act as a IoT device and
connects to the Internet to vulnerable to such attacks and need appropriate
CoAP comes with different security modes and one of the main benefits of
CoAP is that it enforces the need to implement ciphers when using this protocol
for communication between endpoints Shelby 2014. MQTT also provides several
recommendations for achieving security but it is not a mandatory enforcement Oasis
MQTT packet can contain authentication information in the form of
username and password. Messages exchanged can be encrypted using SSL or TLS, since
the MQTT protocol runs over TCP. “Since CoAP is built on top of UDP, it cannot
rely on SSL/TLS to provide security capabilities. To achieve security, CoAP
uses Datagram Transport Layer Security (DTLS) which provides the same assurances
as TCP” Hedi 2017. CoAP and MQTT both support the use of certificates for
authorization Zamfir 2016.
6. Summary and Conclusions
Hou 2016 Lu Hou, Shaohang
Zhao and Xiong Xiong, “Internet of Things Cloud: Architecture and
Implementation,” IEEE Communications
Magazine, vol. 54, no. 12, December 2016, pp. 32–39
2016 Rahul Bhalerao, Sridhar
Srinivasa Subramanian and Joseph Pasquale, “An analysis and improvement of
congestion control in the CoAP Internet-of-Things protocol,” 2016 13th IEEE Annual Consumer
Communications & Networking Conference (CCNC), Las Vegas, NV, January 2016,
Thangavel 2014 D.
Thangavel, X. Ma, A. Valera, H. X. Tan and C. K. Y. Tan, “Performance
evaluation of MQTT and CoAP via a common middleware,” 2014 IEEE Ninth International Conference on Intelligent Sensors, Sensor
Networks and Information Processing (ISSNIP), Singapore, April 2014, pp. 1–6.
Soma Bandyopadhyay, Abhijan Bhattacharyya, “Lightweight Internet Protocols
for Web Enablement of Sensors using Constrained Gateway Devices”, 2013 International Conference on Computing
Networking and Communications (ICNC), IEEE, San Diego, CA, January 2013, pp. 334–340.
Caro 2013 N. De
Caro, W. Colitti, K. Steenhaut, G. Mangino and G. Reali, “Comparison of
two lightweight protocols for smartphone-based sensing,” 2013 IEEE 20th Symposium on Communications
and Vehicular Technology in the Benelux (SCVT), Namur, Belgium, November 2013,
Chen 2016 Yuang Chen
and Thomas Kunz, “Performance evaluation of IoT protocols under a
constrained wireless access network,” 2016
International Conference on Selected Topics in Mobile & Wireless Networking
(MoWNeT), IEEE, Cairo, Egypt, April 2016, pp. 1–7.
Kraijak 2015 Surapon
Kraijak and Panwit Tuwanut, “A survey on IoT architectures, protocols,
applications, security, privacy, real-world implementation and future
trends,” 11th International
Conference on Wireless Communications, Networking and Mobile Computing (WiCOM
2015), IET, Shanghai, China, September 2015, pp. 1–6.
Kayal 2017 Paridhika
Kayal and Harry Perros, “A comparison of IoT application layer protocols
through a smart parking implementation,” 2017 20th Conference on Innovations in Clouds, Internet and Networks
(ICIN), IEEE, Paris, France, March 2017, pp. 331–336.
Hedi 2017 I. He?i,
I. Špeh and A. Šarabok, “IoT network protocols comparison for the purpose
of IoT constrained networks,” 2017
40th International Convention on Information and Communication Technology,
Electronics and Microelectronics (MIPRO), IEEE, Opatija, Croatia, May 2017,
Shriramoju 2013 S.
K. Shriramoju, J. Madiraju and A. R. Babu, “An approach towards
publish/subscribe system for wireless networks”, International Journal of Computer and Electronics Research, vol.2,
August 2013, pp. 505–508.
Guizani 2015 A.
Al-Fuqaha, A. Khreishah, M. Guizani, A. Rayes and M. Mohammadi, “Toward
better horizontal integration among IoT services,” IEEE Communications Magazine, vol. 53, no. 9, September 2015, pp.
Zamfir 2016 S.
Zamfir, T. Balan, I. Iliescu and F. Sandu, “A security analysis on
standard IoT protocols,” 2016
International Conference on Applied and Theoretical Electricity (ICATE), IEEE,
Craiova, October 2016, pp. 1–6.
Shelby 2014 Z.
Shelby, K. Hartke, C. Bormann The
Constrained Application Protocol,
RFC 7252, 2014.
Oasis 2014 Oasis Message Queue Telemetry Transport, OASIS
MQTT version 3.1.1,
An Overview of XMPP