International Journal of Emerging Technology and Advanced Engineering
Website: www.ijetae.com (ISSN 2250-2459, ISO 9001:2008 Certified Journal, Volume 7, Issue 11, November 2017)
207
Internet of Things Application Layer Protocol: Comparison of
CoAP and MQTT
Madhavi Dave
1, Dr. Jyotika Doshi
2,
Dr. Harshal Arolkar
31Assistant Professor, Indus University
2,3
Associate Professor, GLS University
Abstract—Internet of Things paradigm means connecting any device to any other device with the use of Internet. The device can range from home appliance to medical devices which can have unique IP address for identification on Internet. For providing communication platform, variety of IoT protocols are used working as middle-wear among different connected embedded systems [3].
The main objective of any IoT device is connectivity with the network; even in case of mobility the device must be in connection with system and its performance should not be compromised. IoT layered architecture describes widely accepted protocols like CoAP, MQTT and 6LoWAN for communication which is dependent on TCP/IP protocol suit. TCP/IP is favored worldwide for wired connection but in case of constrained devices of IoT, it is not best option for intermittent networks.
In this phase of research two standard but distinctly used application layer protocols are compared which plays major role in communication of ubiquitous and constrained devices of IoT network. By having apprehensive knowledge of CoAP and MQTT protocols, the communication of embedded appliances with varied protocols may rest to a common mechanism which could be the solution provider at application layer of IoT framework.
Keywords— CoAP, Internet of Things, IoT Application layer protpcol, MQTT, Protocol comparison.
I. INTRODUCTION
In today’s emerging world of Internet, each and every thing is supposed to be in connected mode with the help of billions of smart devices. By connecting all the devices used in our day to day life, make our life trouble less. We are incorporated in a world where we are used to have smart phones, smart cars, smart gadgets, smart homes and smart cities.
As the future internet will grow, it collaborates a huge number of objects which use standard protocols and architecture to provide services to end user. It is envisioned to provide new interactions between physical world and Information and Communication Technology domain. This resulting network paradigm is called Internet of Things [8].
IoT provides unprecedented opportunities to users, manufacturers and service providers in a wide variety of sectors.
Seamless connection between all devices is the essential requirement for any IoT system, thus the protocols are needed for easy and robust communication. As we mostly use IP protocol for connecting through internet, but it requires high degree of features which is a great overhead for small devices [13]. The Internet protocol for lower-power radio IPv6 is used for the same as different existing systems having to work together. Machine-to-machine interfaces and protocols of electronic communication set the rules of engagement for two or more nodes of a network. An individual sensor can drop out for a number of reasons, so the network must be self-adapting. Energy is the main consideration for the existing protocols in the case of IoT[12].
Technical interoperability is usually associated with software/ hardware used along with its platform used by the components to have communication. Such interoperability generally depends on the communication protocol used for the specified infrastructure, thus it needs to have a proper validation methodology used before implementation of interoperable protocol [12]. Interoperable protocols tend to provide seamless interconnection with format perseverance of any communicated message. Message representation issues mostly dealt by application layer of communication model and thus two widely used application layer protocols CoAP and MQTT are discussed for achieving interoperability among IoT devices communication.
II. COAP
International Journal of Emerging Technology and Advanced Engineering
Website: www.ijetae.com (ISSN 2250-2459, ISO 9001:2008 Certified Journal, Volume 7, Issue 11, November 2017)
208 It provides request/ response interaction model which supports built-in discovery of services and resources. It also includes key concepts of web (URI) and internet media types. CoAP is designed for easy interface with HTTP so can integrated with web which helps to meet specialized requirements like (a) multi-cast support, (b) low overhead, and (c) simplicity for constrained environment. [1]
CoAP is logically 2 layered protocol; layer 1 (message layer) is dealing with UDP and asynchronous nature of interactions and layer 2 (request/ response) is dealing interactions with methods and response codes.
Table 1: CoAP layered protocol
Application
Message
Request/ Response
UDP
A. Communication Method
CoAP makes use of GET, PUT, POST, and DELETE methods in a similar manner to HTTP and methods beyond the basic four can be added to CoAP in separate specifications. 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. It provides security by binding to Datagram Transport Layer Security (DTLS). It also helps for URI and Content-type support with simple proxy and caching capabilities. With CoAPasynchronous communication occurs which provides low header overhead and parsing complexity. [1]
B. Message Format
There are 4 types of messages in CoAP; (a) Conformable, (b) Non-conformable, (c) Acknowledgment and (d) Reset. Requests can be carried in Confirmable and Non-confirmable messages, and responses can be carried in these as well as piggybacked in Acknowledgement messages.
[image:2.612.123.212.285.439.2]CoAP messages are encoded in a simple binary format. The message format starts with a fixed-size 4-byte header which is followed by a variable-length Token value, which can be between 0 and 8 bytes long.
Table 2: CoAP message format
12345678123456781234567812345678
V er
T TKL Code Message ID
Token (if any, TKL bytes) ...
Options (if any) ...
1 1 1 1 1 1 1 1 Payload (if any)...
Version (Ver):
o 2-bit unsigned integer which indicates the CoAP version number.
o Implementations of this specification MUST set this field to 1 (01 binary).
o Other values are reserved for future versions.
o Messages with unknown version numbers MUST be silently ignored.
Type (T):
o 2-bit unsigned integer.
o Indicates if this message is of type Confirmable (0), Non-confirmable (1), Acknowledgement (2), or Reset (3).
Token Length(TKL):
o 4-bit unsigned integer. Indicates the length of the variable-length Token field (0-8 bytes).
o Lengths 9-15 are reserved, MUST NOT be sent, and MUST be processed as a message format error.
Code:
o 8-bit unsigned integer, split into a 3-bit class (most significant bits) and a 5-bit detail (least significant bits).
o The class can indicate a request (0), a success response (2), a client error response (4), or a server error response (5). (All other class values are reserved.)
o As a special case, Code 0.00 indicates an Empty message.
International Journal of Emerging Technology and Advanced Engineering
Website: www.ijetae.com (ISSN 2250-2459, ISO 9001:2008 Certified Journal, Volume 7, Issue 11, November 2017)
209 o Possible values are maintained in the CoAP Code
Registries
Message ID:
o 16-bit unsigned integer in network byte order. o Used to detect message duplication and to match
messages of type Acknowledgement/Reset to messages of type Confirmable/Non-confirmable. o The header is followed by the Token value, which
may be 0 to 8 bytes, as given by the Token Length field.
o The Token value is used to correlate requests and responses.
o Header and Token are followed by zero or more Options.
o An Option can be followed by the end of the message, by another Option, or by the Payload Marker and the payload.
III. MQTT
MQ Telemetry Transport is a lightweight broker-based publish/subscribe messaging protocol designed to be open, simple, lightweight and easy to implement which is designed by IBM Corporation, Eurotech. MQTT is used for expensive networks having low bandwidth and unreliable connectivity. It runs on embedded device with limited processing capacity and memory resources. [2]
MQ Telemetry Transport is a lightweight broker-based publish/subscribe messaging protocol designed to be open, simple, lightweight and easy to implement which is designed by IBM Corporation, Eurotech. MQTT is used for expensive networks having low bandwidth and unreliable connectivity. It runs on embedded device with limited processing capacity and memory resources. [2]
A. Communication Method
MQTT provides Publish/ Subscribe communication pattern which helps for one to many message distributions. It uses TCP/IP for basic network connectivity and decoupling of application is also possible. The message format includes 3 different types of Quality of Service,
―At most one‖: The message is delivered as per the best practice of underlying TCP/IP network. Message lost or duplication may occur.
―At least one‖: Message is assured to arrive (may be duplicated).
―Exactly one‖: Messages are assured to arrive exactly ones.
B. sage Format
[image:3.612.324.557.155.752.2]Fixed header format of 2 bytes. Table 3: MQTT message format
Bit 7 6 5 4 3 2 1 0
Byte 1
Message Type DUP Flag
QoS Level RETAI N
Byte 2
Remaining Length
o Message Type
[image:3.612.333.555.300.705.2] Represented as 4 bit unsigned value
Table 4: MQTT message type
Mnemonic Enumeration Description
Reserved 0 Reserved
CONNECT 1 Client request to connect server
CONNACK 2 Connect
Acknowledgment
PUBLISH 3 Publish Message
PUBACK 4 Publish
Acknowledgment
PUBREC 5 Publish Received
(assured delivery part 1)
PUCREL 6 Publish Release
(assured delivery part 2)
PUBCOMP 7 Publish Complete
(assured delivery part 3)
SUBSCRIBE 8 Client Subscribe Request
SUBACK 9 Subscribe
Acknowledgment
UNSUBSCRIBE 10 Client Unsubscribe Request
UNSUBACK 11 Unsubscribe
Acknowledgment
PINGREQ 12 PING Request
PINGRESP 13 PING Response
DISCONNECT 14 Disconnecting Client
International Journal of Emerging Technology and Advanced Engineering
Website: www.ijetae.com (ISSN 2250-2459, ISO 9001:2008 Certified Journal, Volume 7, Issue 11, November 2017)
[image:4.612.65.272.151.250.2]210 o Flags
Table 5: MQTT flag type
Bit Position Name Description
3 DUP Duplicate Delivery
2 – 1 QoS Quality of Service
0 RETAIN RETAIN Flag
IV. COMPARATIVE ANALYSIS:COAPAND MQTT
According to comparative analysis shown in table 6, performance of MQTT is better in low throughput and single device situation. Thus the use of MQTT is preferable in high delay scenario compare to CoAP. While CoAP is advantageous in situation of increased traffic as CoAP's operational parameters can be tuned. For the devices which require hourly or daily basis (sleepy) communication, CoAP is preferable as it does not require TCP handshake like MQTT.
REFERENCES
[1] RFC: ―The Constrained Application Protocol‖ by Internet Engineering Task Force (IETF); Updated by Z. Shelby, K. Hartke, C. Bormann;ISSN: 2070-1721; June 2014.
[2] RFC: ―MQ Telementry Transport Protocol‖ by International BusinessMachine (IBM), Eurotech; MQTT Protocol Version V3.1; May 2013.
[3] Takeshi Yashiro, Shinsuke Kobayashi, Noboru Koshizuka, and Ken Sakamura, ―An Internet of Things (IoT) architecture for embedded appliances‖, Humanitarian Technology Conference (R10-HTC) 2013,Sendai, Japan, IEEE Region 10,INSPEC Accession Number: 13916362, 26-29 Aug 2013.
[4] M. Collina, M. Bartolucci, A. Vanelli-Coralli, and G.E. Corazza, "Internet of Things application layer protocol analysis over error and delay prone links," Advanced Satellite Multimedia Systems Conference and the 13th Signal Processing for Space Communications Workshop (ASMS/SPSC), pp.398,404, 8-10 Sept. 2014.
[5] Ponte Eclipse Project, "Connecting Things to Developers," Available: http://eclipse.orglponte, 2015 (accessed on Feb 21,2 015). [6] E. Garcia Davis, A. Calveras, and I. Demirkol, "Improving packet delivery performance of publish/subscribe protocols in wireless sensor networks," Sensors 2013,13,648-680; doi:I O.3390/sI30100648.
[7] Xi Chen, Prof. Raj Jain, ―Constrained Application Protocol‖, http://www.cse.wustl.edu/~jain/cse 574-14/index.html; April, 2014. [8] Willian Stallings, ―Fundamentals of Modern Networking: SDN,
NFV, QoE, IoT and Cloud‖, Pearson Publication, 2016. [9] K. Ashton, Internet of Things, RFID Journal. (2009).
[10] Tara Salman, Prof. Raj jain, ―Networking Protocols and Standards for Internet of Things‖, November 2015, CSE 570-15
[11] O. Vermesan, P. Friess, P.Guillemin, S. Gusmeroli, ―Internet of Things, Strategic Research Agenda‖, River Publication, 2011, ISBN- 978-87-92329-67-7.
[12] IoT-From Research and Innovation to Market Deployment_IERC . River Publisher, Denmark. ISBN: 978-87-93102-4-1, 2014. [13] A. Passemard, ―The Internet of Things protocol Stack‖ – from
sensors to business value, Jan 2014.
[14] Galerie Jean-Malbuisson, ―Internet Society‖, 15 CH-1204 Geneva, Switzerland, Carolyn Marsan, October 2015.
[15] JaveriaAmbareen, PritamGajkumar Shah and M. Prabhakar, A Survey of Security in Internet of Things – Importance and Solutions, Indian Journal of Science and Technology, Vol 9(45),December, 2016.
[16] D. Miorandi, S. Sicari, F. De Pellegrini, and I. Chlamtac, ―Internet of things: vision, applications and research challenges,‖ Ad Hoc Networks, vol.10, no.7, pp.1497-1516, 2012.
[17] NomusaDlodlo, ThatoFoko, Promise Mvelase, and SizakeleMathaba―,The State of Affairs in Internet of Things Research‖ ,www.ejise.com 255 ISSN 1566-6379.
[18] [18] Gont, F., "Security Assessment of the Internet Protocol version 6 (IPv6)", UK Centre for the Protection of National Infrastructure, October 2012.
[19] Pratap Kumar, Rakesh Singh Kunwar, AlokSachan ,‖A Survey Report on: Security & Challenges in Internet of Things‖, IJSRD, National Conference on ICT &IoT, January 2016.
[20] Securing the Internet of Things: Seven Steps to Minimize IoT Risk, ptc.com,J5637–Securing–IoT–EN–1015
[21] Angelo P. Castellani, Nicola Bui, Paolo Casari, Michele Rossi, Zach Shelby, Michele Zorzi, ―Architecture and Protocols for the Internet of Things: A Case Study‖, Department of Information Engineering, University of Padova, Via Gradenigo 6/B, I-35131 Padova, Italy, 978-1-4244-5328-3/10, IEEE, 2010.
[22] I.F. Akyildiz, W. Su, Y. Sankarasubramaniam, E. Cayirci, Wireless Sensor Networks: A Survey, Computer Networks 38 (2002) 393– 422.
[23] A. Ghosh, S.K. Das, Coverage and connectivity issues in wireless sensor networks: A survey, Pervasive and Mobile Computing. 4 (2008) 303–334.
[24] I. Demirkol, C. Ersoy, F. Alagoz, MAC protocols for wireless sensor networks: A survey, IEEE Communication Magazine 44 (2006) 115–121.
[25] J. Al-Karaki, A. Kamal, Routing techniques in wireless sensor networks: A survey, IEEE Wireless Communication 11 (2004) 6– 28.A. Aijaz and A. Aghvami, "Cognitive machine-to-machine communications for internet-of-things: A protocol stack perspective," IEEE Internet of Things Journal, vol. 2, no. 2, pp.
103-112, April
2015,http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber =7006643
[26] A. Al-Fuqaha, M. Guizani, M. Mohammadi, M. Aledhari, and M. Ayyash, "Internet of things: A survey on enabling technologies, protocols and applications," IEEE Communications Surveys
Tutorials, vol. PP, no. 99,
International Journal of Emerging Technology and Advanced Engineering
Website: www.ijetae.com (ISSN 2250-2459, ISO 9001:2008 Certified Journal, Volume 7, Issue 11, November 2017)
211 [27] J. Granjal, E. Monteiro, and J. Sa Silva, "Security for the internet of
things: A survey of existing protocols and open research issues," IEEE Communications Surveys Tutorials, vol. 17, no. 3, pp.
1294-1312, 2015,
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7005393 [28] T. He, J. Stankoviv, C. Lu and T. Abdelzaher, A Spatiotemporal
Communication Protocols for Wireless Sensor Networks, IEEE Transaction on Parallel and Distribute Systems, Oct 2005.
[29] B. Brummit, B. Meyers, J. Krumm, A. Kem and S. A. Shafer, Easyliving: Technologies for Intelligent Environments, HUC, 2000. [30] J. Stankovic, ―A Vision of Smart City in Future‖, Smart Cities, Oct
2013.
[31] S. Ravi, A. Raghunathan, S. Chakradhar. Temper Resistance Mechanism for Secure, Embedded System, 17th International Conference on VLSI Design, 2004.
[32] John A. Stankovic, ―Research Directions for the Internet of Things‖, University of Virginia, IEEE 2014.
[33] JayavardhanaGubbia, RajkumarBuyyab, SlavenMarusic, MarimuthuPalaniswami, ―Internet of Things (IoT): A vision, architectural elements, and future directions‖, Department of Computing and Information Systems, The University of Melbourne, IEEE Wireless Communication 116–28.Australia, 2013.