Comparison of IoT protocols: CoAP and MQTTTermPaper DraftApoorva [email protected] 780 Term Paper – Prof. James P.G. Sterbenz1 December 2017 AbstractMQTT and CoAPare the leading lightweight messaging protocols for the IoT market providingmachine-to-machine (M2M) communication. Each protocol has some advantages overthe other but some disadvantages as well.
They are implemented formesh-networking applications, where end nodes are lightweight. MQTT uses a”publish/subscribe” model. It uses a centralized MQTT broker to manage androute messages between nodes. The publish/subscribe models provide severaladvantages like scalability, space and time decoupling, and security. CoAP is aclient/server protocol defined by IETF. Its main purpose is to use inconstrained environment such as lossy networks.This papercompares the strengths and weaknesses of MQTT and CoAP in performance andsecurity standpoints utilizing the existing research done to compareperformance between these two protocols in narrow bandwidth, high latency, andhigh packet loss conditions.
CoAP uses UDP, and its performance is better evenwith less server utilization. MQTT performs better at higher serverutilizations. This paper compares these protocols through different scenarios tohelp choose the appropriate protocol. 1. Introductionand MotivationIoT or “Internet of Things” is one of the hot topics in communicationnetworks, as well as in information technology due to amount of data itgenerates.
From the networking standpoint, it is important to understand theunderlying mechanisms which makes IoT possible. IoT is wireless networking ofsmart objects, which provides machine to machine communication. It consists ofseveral thousands of machines connected to the Internet and exchanging enormousamount of data. This data is transmitted via the networks, and the introductionof IoT brought along with itself the huge amount of traffic flowing through thenetwork. In this paper, we will focus our discussionmainly on two protocols, Message Queue Telemetry Transport (MQTT) protocol andConstrained Application Protocol (CoAP). These protocols are highlypopular application layer protocols in IoT implementations. 2. Background2.
1. Internetof Things (IoT)Any physical device, whether personal objects such as smart phones orlaptops, or electronic equipment which can connect to the Internet can serve asthe sender for IoT data. With the increase in the processing power and storageamong devices, and decrease in the actual size, these devices can be equippedwith sensors, which are used to transmit real time information, providing analways-connected model Kraijak 2015. Kraijak 2015 provides a generic architecture for IoT which consists offive layers. Perception layer, which consists of the sensor devices such asRFID, Zigbee, Infrared etc. This layer gathers information from across thesesensors and passes to upper layer which is Network layer. Network layer isresponsible for secure transfer of this information and maintainconfidentiality for the sensitive information. Middleware layer stores andprocess the information received from lower layers.
Application layer isresponsible for application management and Business layer is responsible forservice management, which provides the results used in decision making. Kraijak 2015 discusses several different applications of IoT such asAssisted driving, Sensing, Identification and Authentication, Comfortable homesand offices, Social Networking. Implementation of IoT requires a hardware platform, network protocol anddata protocol. Hardware components can be power sources, memory storage andprocessing, and gather data in IoT devices. While choosing a protocol, one mustconsider the amount of data that needs to be send, network resourceavailability, frequency of data transfer and hardware platform resourceavailability. 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.
Asan example, devices without enough resources to support TCP/IP communicationusually use UDP based communications. But due to this, they are unable tointeroperate with devices which have plenty of resources and support TCP/IP Guizani2015. Also, the current range of IoT protocols are unable to offer QoSguarantees. There are security and privacy concerns around IoT. Attackers can accessthe devices with front end sensors and manipulate the information. These unsecuredevices lead to loss of sensitive information.
The communication needs to besecured. Storage and processing of data must involve authentication mechanisms Kraijak2015.2.
2. IoTMessaging Protocols Overview· MQTT (MessageQueuing Telemetry Transport) Uses TCP/IP. Publish subscribe model requires amessage broker (switch). Due to use of TCP, MQTT provides reliability andsecurity. · AMQP (AdvancedMessage Queuing Protocol) Uses TCP/IP. This also supports a publish subscribeprotocol but it differs from MQTT since this is a point-to-point protocolwhereas MQTT is many-to-many. Due to use of TCP, AMQP also provides reliabilityand security. · XMPP(Extensible Messaging and Presence Protocol) “used by wide range ofapplications including instant messaging, presence, multi-party chat, voice andvideo calls, collaboration, lightweight middleware, content syndication, and generalizedrouting of XML data.
” XMPP· COAP (ConstrainedApplication Protocol) Uses UDP designed specifically for IoT uses requestresponse model like HTTP. · DDS (DataDistribution Service) publish-subscribe communications for real-time andembedded systems.3. MQTTProtocolMQTT protocol runs over TCP/IP and is based on publish/subscribe model.
It was developed by IBM.3.1 Strengths”MQTT is alightweight broker-based publish/subscribe messaging protocol for small codefootprints (e.
g., 8-bit, 256KB ram controllers), low bandwidth and power,high-cost connections and latency, variable availability, and negotiateddelivery guarantee” Hedi 2017. MQTT is a broker based protocol. It helps inoffloading the IoT devices so that they can handle large number of serverrequests. There is another variant of MQTT protocol called MQTT-SN, for sensornetworks. It follows the same publish and subscribe model as MQTT andtranslates messages between clients and servers. With the use ofMQTT broker, publishers and subscribers do not need to know each other which isone of the major advantages of this protocol.
The publishers and subscribers cancommunicate at different times and do not need to be familiar with each other Shriramoju2013.3.1.1.
ImplementationMQTT providesthree types of services. “At most once”, is a best effort service but there isno guaranteed delivery. “At least once” provides assured delivery but canresult into duplicate messages. “Exactly once” sends a message only once andthere is no duplication. Any IoT objectcan be MQTT client that sends or receives telemetry data. MQTT client should firstconnect to a messaging server and must declare himself whether he is asubscriber or publisher.
Figure 1 shows the basic model for MQTT where MQTTclients can act as either a subscriber or a publisher and they send messages toMQTT broker. Figure 1: Message queuingtelemetry transport protocol modelHedi 2017 One of theMQTT implementations include the Intel IoT Platform. Intel IoT platformconsists of middle ware, connectivity and security components. “It supportsZigBee, Cellular 2G/3G/4G, BlueTooth, Serial, USB, VPN, Wi-Fi and MQTT” Guizani20154. CoAPCoAP is an application layer protocol which provides reliability andcongestion control over unreliable UDP. It is designed for use in lossy and lowpowered networks. Since a lot of IoT devices function under a constrainedenvironment, CoAP was specifically designed by IETF to be used in suchenvironment, particularly for IoT devices. It is a stateless, web transferprotocol which provides a request and response interaction model between applicationend points.
4.1. StrengthsCoAP provides several features as are also highlighted in Bhalerao2016. It consumes low power and provides less overhead in terms of memorywhich makes it attractive for use in lossy and low powered networks. It is a RESTfulprotocol and has HTTP like semantics for interactions between clients andservers. To provide reliability, it provides the use of optional end-to-endacknowledgements. But in case of congested networks, use of ACKs can also leadto spurious retransmissions and thus reduction is throughput.
There are basicmethods like exponential backoff which can be used to solve this problem. Thereis also a variation of CoAP called “CoAP Congestion Control Advanced(CoCoA)”which uses Round trip times (RTTs) along with confirmable message and ACK. Itcalculates 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 andcaching capabilities, A stateless HTTP mapping, allowing proxies to be builtproviding access to CoAP resources via HTTP in a uniform way or for HTTP simpleinterfaces to be realized alternatively over CoAP) Hedi 2017. 4.
1.1. ImplementationWith the use of UDP, CoAP experiences a low overhead as compared to MQTT.
CoAP supports asynchronous communication between endpoints. A message that doesnot require reliable transmission can be sent as a non-confirmable message(NON). Since it consumes less energy, it is generally implemented for low powerdevices Hedi 2017. Figure 2 shows the two models of CoAP, with reliable andnon-reliable transmissions. Figure 2: Reliable and non-reliabletransmission 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 similarrequests, reponse time in decreased, which also decreases the overall bandwidthconsumption of the network.
Thus with more and more GET request messages, theaverage response time decreasesKayal 2017.5. Comparison of MQTT and CoAPOne of the main differences between MQTT and CoAP can be found in thetransport layer. MQTT runs on top of the Transmission Control Protocol whileCoAP runs on top of the User Datagram Protocol.5.1.
PerformanceMQTT is a many-to-many communication protocol. Multiple MQTT clients canexchanges messages through a centralized broker. The publishers can sendmessages to the brokers which in turn decides which subscriber will receive themessage.
CoAP is a one-to-one protocol for transferring state informationbetween client and server Hedi 2017. Thangavel 2014 compares the performance of CoAP and MQTT using acommon middleware. Their results show that in high packet loss networks, MQTTexperiences higher latency than CoAP which is understandable due to highreliability requirement of MQTT. InChen 2016, the authors have performed various quantitative comparisons amongTCP-based protocols and UDP-based protocols including MQTT and CoAPrespectively. In order to find results for the change in bandwidth consumptionby these protocols in different environments, experiments were performed withincreased network latency and increase in packet loss rate. It was determinedthat since UDP does not do any retransmissions even with packet loss, protocolsbased on UDP (CoAP) do not experience any change in bandwidth consumption.
Where in TCP based protocols (MQTT), this consumption increases with packet lossand high latency. When the network conditions are poor (due to high latency), MQTT doesnot suffer from packet loss. But CoAP is well suited for applications thatrequire low latency and less bandwidth consumption. Based on the research done to compare the response time of theseprotocols for a smart parking application, since CoAP uses UDP forcommunication, it performs better at lower utilization as shown in Figure 3.MQTT performs better at higher server utilizations due to high overhead withthe use of TCP Kayal 2017. Figure 3: Mean response time forCoAP & MQTT vs server utilization Kayal 2017 5.1.1.
Lossy network conditionsBhalerao2016 compares the CoAP and CoCoA Congestion control protocols. CoCoA requiresmaintenance of state for the estimators and has higher overhead. But it alsoperforms conservatively in a lossy environment. When there is less congestion in thenetwork, there are a lower number of congestion-related packet losses, and thusCoAP and CoCoA perform similarly. However, as the data rate increases creatingcongestion in the network, the congestion-related losses increase and CoCoAperforms better than CoAP, delivering around 20% more packets Bhalerao 2016.5.2.
SecurityWith the increasing number of devices that have becomes a part of theIoT world, security becomes one of the major concerns, since now the attacksurface is not only limited to information systems that need to be securedagainst such attacks, but instead any device which can act as a IoT device andconnects to the Internet to vulnerable to such attacks and need appropriatesecurity measures. CoAP comes with different security modes and one of the main benefits ofCoAP is that it enforces the need to implement ciphers when using this protocolfor communication between endpoints Shelby 2014. MQTT also provides severalrecommendations for achieving security but it is not a mandatory enforcement Oasis2014. MQTT packet can contain authentication information in the form ofusername and password. Messages exchanged can be encrypted using SSL or TLS, sincethe MQTT protocol runs over TCP. “Since CoAP is built on top of UDP, it cannotrely on SSL/TLS to provide security capabilities. To achieve security, CoAPuses Datagram Transport Layer Security (DTLS) which provides the same assurancesas TCP” Hedi 2017.
CoAP and MQTT both support the use of certificates forauthorization Zamfir 2016.6. Summary and Conclusions ReferencesHou 2016 Lu Hou, ShaohangZhao and Xiong Xiong, “Internet of Things Cloud: Architecture andImplementation,” IEEE CommunicationsMagazine, vol. 54, no. 12, December 2016, pp. 32–39 Bhalerao2016 Rahul Bhalerao, SridharSrinivasa Subramanian and Joseph Pasquale, “An analysis and improvement ofcongestion control in the CoAP Internet-of-Things protocol,” 2016 13th IEEE Annual ConsumerCommunications & Networking Conference (CCNC), Las Vegas, NV, January 2016,pp. 889–894. Thangavel 2014 D.
Thangavel, X. Ma, A. Valera, H. X. Tan and C. K. Y. Tan, “Performanceevaluation of MQTT and CoAP via a common middleware,” 2014 IEEE Ninth International Conference on Intelligent Sensors, SensorNetworks and Information Processing (ISSNIP), Singapore, April 2014, pp.
1–6. Bandyopadhyay 2013Soma Bandyopadhyay, Abhijan Bhattacharyya, “Lightweight Internet Protocolsfor Web Enablement of Sensors using Constrained Gateway Devices”, 2013 International Conference on ComputingNetworking and Communications (ICNC), IEEE, San Diego, CA, January 2013, pp. 334–340.
Caro 2013 N. DeCaro, W. Colitti, K. Steenhaut, G. Mangino and G. Reali, “Comparison oftwo lightweight protocols for smartphone-based sensing,” 2013 IEEE 20th Symposium on Communicationsand Vehicular Technology in the Benelux (SCVT), Namur, Belgium, November 2013,pp. 1–6. Chen 2016 Yuang Chenand Thomas Kunz, “Performance evaluation of IoT protocols under aconstrained wireless access network,” 2016International Conference on Selected Topics in Mobile & Wireless Networking(MoWNeT), IEEE, Cairo, Egypt, April 2016, pp.
1–7. Kraijak 2015 SuraponKraijak and Panwit Tuwanut, “A survey on IoT architectures, protocols,applications, security, privacy, real-world implementation and futuretrends,” 11th InternationalConference on Wireless Communications, Networking and Mobile Computing (WiCOM2015), IET, Shanghai, China, September 2015, pp. 1–6. Kayal 2017 ParidhikaKayal and Harry Perros, “A comparison of IoT application layer protocolsthrough 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 purposeof IoT constrained networks,” 201740th International Convention on Information and Communication Technology,Electronics and Microelectronics (MIPRO), IEEE, Opatija, Croatia, May 2017,pp. 501–505.
Shriramoju 2013 S.K. Shriramoju, J. Madiraju and A. R. Babu, “An approach towardspublish/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, “Towardbetter horizontal integration among IoT services,” IEEE Communications Magazine, vol. 53, no. 9, September 2015, pp.72–79. Zamfir 2016 S.
Zamfir, T. Balan, I. Iliescu and F. Sandu, “A security analysis onstandard IoT protocols,” 2016International Conference on Applied and Theoretical Electricity (ICATE), IEEE,Craiova, October 2016, pp.
1–6. Shelby 2014 Z.Shelby, K.
Hartke, C. Bormann TheConstrained Application Protocol, RFC 7252, 2014. Oasis 2014 Oasis Message Queue Telemetry Transport, OASISMQTT version 3.1.1,2014.
XMPP https://xmpp.org/about/technology-overview.html,An Overview of XMPP