Choice of Effective Messaging Protocols for IoT

Systems: MQTT, CoAP, AMQP and HTTP

Nitin Naik
Defence School of Communications and Information Systems
Ministry of Defence, United Kingdom
Email: nitin.naik100@mod.gov.uk

Abstract—The standard and real-time communication tech- Unlike the Web, which uses a single standard messaging
nology is an unalloyed inevitability for the development of protocol HTTP, IoT cannot rely on a single protocol for all
Internet of Things (IoT) applications. However, the selection of its need [5]. Consequently, hundreds of messaging protocols
a standard and effective messaging protocol is a challenging and are available to choose for various types of requirements of
daunting task for any organisation because it depends on the the IoT system. Some of them have been designed to address
nature of the IoT system and its messaging requirements. Copious
messaging protocols have been developed and employed by
applications requiring fast and reliable business transactions
various organisations based on their requirements in the last two such as AMQP and JMS [3], [6]. A numerous have been
decades. Though, none of them is able to support all messaging designed to address applications requiring data collection (e.g.
requirements of all types of IoT systems. Messaging protocol sensor updates) in constrained network such as MQTT and
is an ongoing dilemma for the IoT industry; consequently, it CoAP [7], [8], [9]. Many of them have been designed to
is important to understand the pros and cons of the widely address applications requiring instant messaging (IM) and
accepted and emerging messaging protocols for IoT systems to online presence detection such as XMPP and SIP [3]. A few of
determine their best-fit scenarios. Therefore, this paper presents them have been designed to address web applications requiring
an evaluation of the four established messaging protocols MQTT, communicating over the Internet such as RESTful client/server
CoAP, AMQP and HTTP for IoT systems. Firstly, it presents the protocols HTTP and CoAP [7], [10]. This clearly shows that
broad comparison among these messaging protocols to introduce
their characteristics comparatively. Afterwards, it performs a
the future of the IoT lies on several messaging protocols and
further in-depth and relative analysis based on some interrelated any one protocol cannot deal with all possible IoT use cases.
criteria to gain insight into their strengths and limitations. Thus, Consequently, it is necessary to investigate the pros and cons of
based on this detailed evaluation, the user can decide their the widely accepted and emerging messaging protocols for IoT
appropriate usage in various IoT systems according to their systems to determine their best-fit scenarios. Therefore, this
requirements and suitability. paper presents an evaluation of the four messaging protocols
MQTT, CoAP, AMQP and HTTP. Firstly, it presents the
Keywords—IoT Systems; M2M Communication; Messaging
Protocol; MQTT; CoAP; AMQP; HTTP; Quality of Services;
general comparison among these protocols to introduce their
Interoperability characteristics comparatively. Subsequently, it performs a fur-
ther in-depth and relative analysis based on some interrelated
criteria to gain insight into their strengths and limitations.
I. I NTRODUCTION For making this relative analysis easy, it is illustrated using
simple graphs to render a nimble and broader view of each
In the Internet of Things (IoT), everyday things and protocol with respect to other protocols for an ordinary user.
machines are in the lead role and communicate with each Accordingly, the user can decide their relevant usage in IoT
other. These IoT networks employ various radio technologies systems based on their requirements and suitability.
such as Radio-Frequency Identification (RFID), WLAN (IEEE
802.11), WPAN (IEEE 802.15) and WMAN (IEEE 802.16) The remainder of this paper is organised as follows: Section
for communications at the lower level [1]. Irrespective of II elucidates the theoretical background of the four widely
the specific radio technology used to deploy the Machine-to- accepted and emerging messaging protocols for IoT systems:
Machine (M2M) network, all end-devices should make their MQTT, CoAP, AMQP and HTTP; Section III demonstrates
data available to the industrial Internet [2]. Industrial Internet a comparative analysis of these four messaging protocols for
can be considered as the connection of industrial machine providing their general information; Section IV presents an
sensors and actuators to the Internet that can independently in-depth and relative analysis of these messaging protocols for
generate value [3]. One of the major factors that determine revealing their relative strengths and limitations; Section V
the performance of this M2M communication is the messaging concludes the paper and suggests some future work.
protocol specially designed for M2M communications within
the IoT applications. The selection of a standard and effective II. M ESSAGING P ROTOCOLS FOR I OT S YSTEMS
messaging protocol is a challenging and daunting task for
any organisation [4]. While selecting an appropriate messaging This section presents the four widely accepted and emerg-
protocol for IoT systems, the pre-requisite is the better under- ing messaging protocols for IoT systems: MQTT, CoAP,
standing of a target IoT system and its message/data sharing AMQP and HTTP, which are shown at the top of the protocol
requirements. stack for IoT systems in Fig. 1.
 a preferred representation of a resource; this allows client and
server to evolve independently, adding new representations
without affecting each other.

C. AMQP (Advanced Message Queuing Protocol)

AMQP is a lightweight M2M protocol, which was de-
veloped by John O’Hara at JPMorgan Chase in London,
UK in 2003. It is a corporate messaging protocol designed
for reliability, security, provisioning and interoperability [3].
Fig. 1: Protocol Stack for IoT Systems AMQP supports both request/response and publish/subscribe
architecture [13]. It offers a wide range of features related
to messaging such as a reliable queuing, topic-based publish-
and-subscribe messaging, flexible routing and transactions [3].
A. MQTT (Message Queuing Telemetry Transport Protocol) AMQP communication system requires that either the pub-
MQTT is one of the oldest M2M communication protocols, lisher or consumer creates an “exchange” with a given name
which was introduced in 1999. It was developed by Andy and then broadcasts that name. Publishers and consumers use
Stanford-Clark of IBM and Arlen Nipper of Arcom Control the name of this exchange to discover each other. Subsequently,
Systems Ltd (Eurotech). It is a publish/subscribe messaging a consumer creates a “queue” and attaches it to the exchange at
protocol designed for lightweight M2M communications in the same time. Messages received by the exchange have to be
constrained networks [7]. MQTT client publishes messages to matched to the queue via a process called “binding”. AMQP
an MQTT broker, which are subscribed by other clients or exchanges messages in various ways: directly, in fanout form,
may be retained for the future subscription. Every message by topic, or based on headers. AMQP is a binary protocol and
is published to an address, known as a topic [11]. Clients normally requires fixed header of 8-bytes with small message
can subscribe to multiple topics and receives every message payloads up to maximum size dependent on the broker/server
published to the each topic. MQTT is a binary protocol or the programming technology [14], [15]. AMQP uses TCP
and normally requires fixed header of 2-bytes with small as a default transport protocol and TLS/SSL and SASL for
message payloads up to maximum size of 256 MB [9]. It uses security [13]. Thus, the communication between client and
TCP as a transport protocol and TLS/SSL for security. Thus, broker is a connection-oriented. Reliability is one of the core
communication between client and broker is a connection- features of AMQP, and it offers two preliminary levels of
oriented. Another great feature of MQTT is its three levels of Quality of Service (QoS) for delivery of messages: Unsettle
Quality of Service (QoS) for reliable delivery of messages [7]. Format (not reliable) and Settle Format (reliable) [3].
MQTT is most suitable for large networks of small devices that
need to be monitored or controlled from a back-end server on D. HTTP (Hyper Text Transport Protocol)
the Internet. It is neither designed for device-to-device transfer
nor for multicast data to many receivers [11]. It is a very basic HTTP is predominantly a web messaging protocol, which
messaging protocol offering only a few control options. was originally developed by Tim Berners-Lee. Later, it was de-
veloped by IETF and W3C jointly and first published as a stan-
dard protocol in 1997 [13]. HTTP supports request/response
B. CoAP (Constrained Application Protocol)
RESTful Web architecture. Analogous to CoAP, HTTP uses
CoAP is a lightweight M2M protocol from the IETF Universal Resource Identifier (URI) instead of topics. Server
CoRE (Constrained RESTful Environments) Working Group. sends data through the URI and client receives data through
CoAP supports both request/response and resource/observe (a particular URI. HTTP is a text-based protocol and it does
variant of publish/subscribe) architecture [7]. CoAP is mainly not define the size of header and message payloads rather it
developed to interoperate with HTTP and the RESTful Web depend on the web server or the programming technology.
through simple proxies. Unlike MQTT, CoAP uses Universal HTTP uses TCP as a default transport protocol and TLS/SSL
Resource Identifier (URI) instead of topics [9]. Publisher for security [10]. Thus, communication between client and
publishes data to the URI and subscriber subscribes to a server is a connection-oriented. It does not explicitly define
particular resource indicated by the URI. When a publisher QoS and requires additional support for it. HTTP is a globally
publishes new data to the URI, then all the subscribers are accepted web messaging standard offers several features such
notified about the new value as indicated by the URI. CoAP as persistent connections, request pipelining, and chunked
is a binary protocol and normally requires fixed header of transfer encoding [4], [5], [10].
4-bytes with small message payloads up to maximum size
dependent on the web server or the programming technology III. C OMPARATIVE A NALYSIS OF M ESSAGING
[9]. CoAP uses UDP as a transport protocol and DTLS for P ROTOCOLS FOR I OT S YSTEMS : HTTP, C OAP, AMQP AND
security [12]. Thus, clients and servers communicate through MQTT
connectionless datagrams with less reliability. However, it uses
“confirmable” or “non-confirmable” messages to provide two This section presents a comparative analysis of the four
different levels of QoS. Where, confirmable messages must be widely accepted and emerging messaging protocols for IoT
acknowledged by the receiver with an ACK packet and non- systems MQTT, CoAP, AMQP and HTTP based on several
confirmable messages are not. CoAP offers more functionality criteria to introduce their characteristics comparatively. This
than MQTT such as it supports content negotiation to express complete comparative study is shown in Table I.
 TABLE I: Comparative Analysis of Messaging Protocols for IoT Systems: MQTT, CoAP, AMQP and HTTP

Criteria MQTT CoAP AMQP HTTP

1. Year 1999 2010 2003 1997
2. Architecture Client/Broker Client/Server or Client/Broker or Client/Server
Client/Broker Client/Server
3. Abstraction Publish/Subscribe Request/Response or Publish/Subscribe or Request/Response
Publish/Subscribe Request/Response
4. Header Size 2 Byte 4 Byte 8 Byte Undefined
5. Message Size Small and Undefined (up Small and Undefined Negotiable and Undefined Large and Undefined
to 256 MB maximum (normally small to fit in (depends on the
size) single IP datagram) web server or the
programming technology)
6. Semantics/ Connect, Disconnect, Get, Post, Put, Delete Consume, Deliver, Pub- Get, Post, Head, Put,
Methods Publish, Subscribe, lish, Get, Select, Ack, Patch, Options, Connect,
Unsubscribe, Close Delete, Nack, Recover, Delete
Reject, Open, Close
7. Cache and Proxy Partial Yes Yes Yes
Support
8. Quality of QoS 0 - At most once Confirmable Message Settle Format (similar to Limited (via Transport
Service (QoS)/ (Fire-and-Forget), (similar to At most once) At most once) or Protocol - TCP)
Reliability QoS 1 - At least once, or Non-confirmable Unsettle Format (similar
QoS 2 - Exactly once Message (similar to At to At least once)
least once)
9. Standards OASIS, Eclipse Founda- IETF, Eclipse Foundation OASIS, ISO/IEC IETF and W3C
tions
10. Transport TCP (MQTT-SN can use UDP, SCTP TCP, SCTP TCP
Protocol UDP)
11. Security TLS/SSL DTLS, IPSec TLS/SSL, IPSec, SASL TLS/SSL
12. Default Port 1883/ 8883 (TLS/SSL) 5683 (UDP Port)/ 5684 5671 (TLS/SSL), 5672 80/ 443 (TLS/SSL)
(DLTS)
13. Encoding Binary Binary Binary Text
Format
14. Licensing Open Source Open Source Open Source Free
Model
15. Organisational IBM, Facebook, Large Web Community Microsoft , JP Morgan, Global Web Protocol
Support Eurotech, Cisco, Red Support, Cisco, Contiki, Bank of America, Bar- Standard
Hat, Software AG, Tibco, Erika, IoTivity clays, Goldman Sachs,
ITSO, M2Mi, Amazon Credit Suisse
Web Services (AWS),
InduSoft, Fiorano

IV. R ELATIVE A NALYSIS OF M ESSAGING P ROTOCOLS with respect to other protocols. There is one caveat here that
FOR I OT S YSTEMS : MQTT, C OAP, AMQP AND HTTP this relative comparison may vary in some circumstances due
to the above IoT components and may reflect different compar-
This section presents a further in-depth and relative analysis ative results than shown here. Additionally, this evaluation is
of these four messaging protocols for IoT systems: MQTT, based on static components and some empirical evidence from
CoAP, AMQP and HTTP. It critically analyses the two closely the literature. Nonetheless, it does not consider the dynamic
associated criteria to provide corresponding strengths and limi- network conditions and overheads incur in the retransmission
tations of each messaging protocol. These messaging protocols of packets, which may also change comparison results.
are very extensive and different from each other because they
have been evolved through different processes and needs. Also, A. Message Size vs. Message Overhead
their precise and relative comparisons depend on the types
of IoT systems, devices, resources, applications, and specific Fig. 2 shows the relative comparison of these messaging
conditions and requirements of the system. However, this protocols based on their common message size and message
relative comparison is based on a linguistic range “Lower” and overhead. The graph illustrates that HTTP incurs the highest
“Higher” to render a nimble and broader view of each protocol message size and overhead, and then it decreases for the other
 Fig. 2: Message Size vs. Message Overhead Fig. 3: Power Consumption vs. Resource Requirement

protocols with CoAP incurring the lowest message size and and resources for the same operation [17], [20]. Again, this
overhead [7], [8], [9], [16], [17]. MQTT, AMQP and HTTP run comparison does not consider dynamic network conditions and
on TCP; therefore, they incur all TCP connection overheads overheads incur in the retransmission of packets.
for connection establishment and closing. However, MQTT
is lightweight and has the least header size of 2-byte per C. Bandwidth vs. Latency
message but its requirement of TCP connection increases the
overall overhead, and thus the whole message size. CoAP Fig. 4 elicits the relative comparison of these messaging
runs on UDP; consequently, it does not incur connection protocols based on their average bandwidth and latency. The
overheads as UDP works in fire and forget basis [7], [9], graph reveals the very similar patterns as the first two, where
[17], [18]. This reduces the overall overhead considerably, and HTTP involves largest bandwidth and latency than any other
thus the whole message size. AMQP is also a lightweight protocols, and then it decreases for the other protocols with
binary protocol; however, its support for security, reliability, CoAP involves lowest bandwidth and latency [7], [8], [9],
provisioning and interoperability increases the overhead and [16], [17], [21], [22]. The use of TCP in MQTT, AMQP
message size [14], [19]. Finally, HTTP among all four is the and HTTP is a major factor in determining the latency and
most verbose and heavyweight protocol [17]. It was originally bandwidth requirement. Unfortunately, TCP does not help
designed for the Web and not for the IoT; therefore, it requires in improving latency. It does not fully utilize the available
maximum overhead and message size among all. As previously network bandwidth for the first few roundtrips of a connection
mentioned, this comparison does not consider retransmission because of its slow start approach to avoid network congestion
scenario that can completely change overall overheads and [23]. Where, TCP sender gradually opens the congestion
amount of transmitted data and, thus, comparison results. window and doubling the number of packets in each round-
trip time (RTT). In CoAP, a UDP transaction requires only
B. Power Consumption vs. Resource Requirement two UDP datagrams, one in each direction; this reduces the
network load response times. Various experimental studies
Fig. 3 exhibits the relative comparison of these messaging found that MQTT consumes higher bandwidth than CoAP
protocols based on their normal power consumption and re- for transferring same payload under same network condition
source requirement. The graph highlights the similar patterns (MQTT QoS 1 or 2 vs. CoAP CON) [7], [8], [9], [17], [18].
as the first one, where HTTP requires highest power and Moreover, when comparing MQTT QoS 2 with CoAP CON,
resource than any other protocols, and then it decreases for the bandwidth usage of MQTT was approximately double than
the other protocols with CoAP requires lowest power and CoAP. This is because of the four-way handshake mechanism
resource [7], [8], [9], [16], [17], [20], [21], [22]. Both CoAP of QoS 2. AMQP’s extra services demand moderately higher
and MQTT are designed for low bandwidth and resource- bandwidth and latency [14], [19]. HTTP takes significantly
constrained devices and can be used on an 8-bit controller larger bandwidth and latency time [4], [5], [17], [20].
and 100s bytes of memory. Various experimental studies found
that CoAP consumes slightly less power and resources in D. Reliability/QoS vs. Interoperability
similar circumstances: unreliable scenario (MQTT QoS 0 vs.
CoAP NON), and reliable scenario (MQTT QoS 1 or 2 Fig. 5 displays the relative comparison of these messaging
vs. CoAP CON), while assuming that no packet losses are protocols based on their Quality of Services (QoSs) and inter-
happened [7], [8], [9], [17], [18]. AMQP requires slightly operability. The graph divulges that MQTT offers the highest
higher power and resources due to performing other necessary level of quality of services with least interoperability among
operations for provisioning and reliability [14], [19]. Finally, four, whereas HTTP was designed for greatest interoperability
HTTP is a bigger than all and needs greater processing power on the Web and did not include reliability as a core feature
 Fig. 4: Bandwidth vs. Latency Fig. 5: Reliability/QoS vs. Interoperability

[3], [13], [14], [15], [19]. One of the biggest benefits of using [3], [6], [11], [13], [14], [15], [19]. Except TLS/SSL, MQTT
TCP as a transport protocol by MQTT, AMQP and HTTP is has minimal authentication features and only rely on simple
the guaranteed delivery of a packet. MQTT, AMQP and CoAP username and password [6], [11]. The CoAP uses two methods
protocols have different levels of QoS support. MQTT defines DTLS and IPsec for authentication, integrity and encryption.
three QoS levels: 0- at most once (only TCP guarantee), 1- at HTTP facilitates two authentication approaches: HTTP Basic
least once (MQTT guarantee with confirmation), 2- exactly and HTTP Digest [10]. HTTP basic authentication uses unen-
once (MQTT guarantee with handshake) [7]. Additionally, crypted Base64-encoding username and password to authenti-
it also provides “last will and testament” message facilities cate a service client over TLS/SSL. HTTP digest authentication
(guarantee after disconnect). AMQP defines two QoS lev- uses an encrypted username and password to authenticate over
els: Settle Format (similar to MQTT QoS 0) and Unsettle on non-TLS/SSL connection. AMQP provides the strongest
Format (similar to MQTT QoS 1). CoAP, which deprived security with different approaches to TLS negotiation: Single-
of the reliability of TCP, compensates for the unreliability port TLS Model, Pure TLS and WebSockets Tunnel TLS
of UDP protocol by defining a retransmission mechanism Model. It has explicitly facilitated the integration of TLS (e.g.
and providing resource discovery mechanism with resource TLS virtual server extensions, known as SNI) and SASL [3],
description [18]. Though CoAP does not provide explicit [6]. MQTT does not offer any extra services even message
QoS, it facilitates the use of non-confirmable messages (NON) labelling; consequently, messages can be used for any purpose;
and confirmable messages (CON), which is very similar to therefore, all clients must know the message formats up-front
MQTT QoS 0 and QoS 1 [21]. The QoS is not a default to allow communication [11]. In CoAP, there are several ex-
service of HTTP; therefore, its default reliability is the TCP tensions for enhanced services depending on the requirements
guarantee [13]. Interoperability is the biggest issue among of the IoT system such as support for observers, multicast
all IoT protocols. MQTT only supports the publish/subscribe group communications, resource discovery and block-wise
pattern of communication, which barely covers all use cases transfers [9]. HTTP is a full web standard and offers several
within the IoT. In AMQP, it is common to use serialization services such as multiplexing and concurrency, stream depen-
formats such as Protocol Buffers, MessagePack, Thrift, and dencies/prioritization, header compression and server push [4],
JSON to serialize structured data in order to publish it as the [5], [10]. AMQP is the preferred choice for businesses because
message payload [3]. CoAP is a part of the Web architecture of its wide range of services related to messaging such as
and best suited for devices that support UDP or a UDP reliable queuing, topic-based publish-and-subscribe messaging,
analogue, however, making it limited to a few special kinds flexible routing and transactions [15]. It provides various ways
of IoT devices [12]. HTTP-based RESTful clients and servers to exchange route messages: directly, in fanout form, by topic,
are the most interoperable because all that is needed to support and based on headers [3]. For enhancing the security of IoT
message exchanges, is an HTTP stack (either on the client or systems across multiple clouds, these messaging protocols can
the server) [4], [5], [10]. be combined with identity and access management protocols
[24], [25], [26], [27], [28], [29]. Similarly, for the better
E. Security vs. Provisioning provisioning of IoT systems, the Docker-based design may be
an alternative option for users [30], [31], [32].
Fig. 6 demonstrates the relative comparison of these
messaging protocols based on the security and provisioning
F. M2M/IoT Usage vs. Standardisation
support provided by them. The graph discloses that AMQP
has the highest level of support for security and additional Fig. 7 expresses the relative comparison of these messaging
services, while MQTT is barely a messaging protocol and protocols based on their usage in M2M/IoT and accreditation
supports the lowest level of security and additional services from standard organisations. The graph indicates that MQTT
 Fig. 6: Security vs. Provisioning Fig. 7: M2M/IoT Usage vs. Standardisation

has been employed by the large number of organisations but Nonetheless, it did not consider dynamic network conditions
it is still not a global standard, while, HTTP is a global web and overheads incur in the retransmission of packets, which
standard but mostly not suitable and used in the IoT industry may produce the different results from the comparison shown
[3], [6], [7], [8], [9], [10], [11]. MQTT is an established M2M here. Additionally, this is the rapidly growing and changing
protocol and has been used and supported by the large number area that might change the presented scenario in the future. In
of organisations such as IBM, Facebook, Eurotech, Cisco, the future, it may be interesting to practically evaluate these
Red Hat, M2Mi, Amazon Web Services (AWS), InduSoft and protocols in the same IoT system.
Fiorano [7], [8], [9]. Besides, AMQP is the most successful IoT
protocol that has been employed in the worlds biggest projects R EFERENCES
such as Oceanography’s monitoring of the Mid-Atlantic Ridge,
[1] V. Gazis, M. Gortz, M. Huber, A. Leonardi, K. Mathioudakis, A. Wies-
NASA’s Nebula Cloud Computing and Indias Aadhar Project maier, F. Zeiger, and E. Vasilomanolakis, “A survey of technologies for
[3], [6], [11]. CoAP has been swiftly gaining momentum and the internet of things,” in 2015 IEEE International Wireless Communi-
supported by many large companies such as Cisco (Field Area cations and Mobile Computing Conference, 2015, pp. 1090–1095.
Network), Contiki, Erika and IoTivity [7], [8], [9]. Finally, the [2] V. Karagiannis, P. Chatzimisios, F. Vazquez-Gallego, and J. Alonso-
usage of HTTP in the IoT is limited due to its heavyweight Zarate, “A survey on application layer protocols for the internet of
size and slow performance. MQTT is an emerging as a de facto things,” Transaction on IoT and Cloud Computing, vol. 3, no. 1, pp.
11–17, 2015.
protocol for the IoT and hosted by OASIS open standards
[3] A. Foster, “Messaging technologies for the industrial internet and the
consortium and Eclipse Foundation [11], [33]. AMQP is an internet of things whitepaper,” PrismTech, 2015.
OASIS adopted international standard ISO/IEC 19464:2014
[4] N. Naik, P. Jenkins, P. Davies, and D. Newell, “Native web communi-
[3]. CoAP is an IETF standard specially designed to integrate cation protocols and their effects on the performance of web services
the IoT and Web and supported by Eclipse Foundation [11]. and systems,” in 16th IEEE International Conference on Computer and
Finally, HTTP is an IETF and W3C standard and already Information Technology (CIT). IEEE, 2016, pp. 219–225.
established as a global standard for the Web [4], [5], [10]. [5] N. Naik and P. Jenkins, “Web protocols and challenges of web latency
in the web of things,” in 2016 Eighth International Conference on
Ubiquitous and Future Networks (ICUFN). IEEE, 2016, pp. 845–850.
V. C ONCLUSION
[6] R. S. Cohn, “A comparison of AMQP and MQTT,” 2011.
This paper has presented an evaluation of the four widely [7] S. Bandyopadhyay and A. Bhattacharyya, “Lightweight internet proto-
accepted and emerging messaging protocols for IoT systems: cols for web enablement of sensors using constrained gateway devices,”
MQTT, CoAP, AMQP and HTTP. Firstly, it has presented the in Computing, Networking and Communications (ICNC), 2013 Interna-
tional Conference on. IEEE, 2013, pp. 334–340.
overall comparison among these protocols to introduce their
[8] N. De Caro, W. Colitti, K. Steenhaut, G. Mangino, and G. Reali, “Com-
characteristics comparatively. Subsequently, it has performed parison of two lightweight protocols for smartphone-based sensing,”
a further in-depth and relative analysis based on some interre- in Communications and Vehicular Technology in the Benelux (SCVT),
lated criteria to gain insight into their strengths and limitations. 2013 IEEE 20th Symposium on. IEEE, 2013, pp. 1–6.
For making this relative analysis easy, it was illustrated using [9] D. Thangavel, X. Ma, A. Valera, H.-X. Tan, and C. K.-Y. Tan, “Perfor-
simple graphs to render a nimble and broader view of each mance evaluation of MQTT and CoAP via a common middleware,” in
protocol with respect to other protocols for an ordinary user. Intelligent Sensors, Sensor Networks and Information Processing, 2014
IEEE Ninth International Conference on. IEEE, 2014, pp. 1–6.
Accordingly, the user can decide their relevant usage in IoT
[10] I. Grigorik, “Making the web faster with HTTP 2.0,” Communications
systems based on their requirements and suitability. This of the ACM, vol. 56, no. 12, pp. 42–49, 2013.
critical evaluation has demonstrated a bigger and comparative [11] T. Jaffey. (2014, February) MQTT and CoAP, IoT protocols.
picture of messaging protocols; which was based on the static [Online]. Available: https://eclipse.org/community/eclipse newsletter/
components and some empirical evidence from the literature. 2014/february/article2.php
[12] A. Ludovici, P. Moreno, and A. Calveras, “TinyCoAP: a novel con- [32] ——, “Applying computational intelligence for enhancing the de-
strained application protocol (CoAP) implementation for embedding pendability of multi-cloud systems using Docker Swarm,” in IEEE
RESTful web services in wireless sensor networks based on tinyos,” Symposium Series on Computational Intelligence (SSCI), 2016.
Journal of Sensor and Actuator Networks, vol. 2, no. 2, pp. 288–315, [33] OASIS.org. (2015, December 10) MQTT 3.1. 1. edited by Andrew
2013. Banks and Rahul Gupta. 29 october 2014. OASIS Standard. [Online].
[13] N. S. Han, “Semantic service provisioning for 6LoWPAN: powering Available: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html
internet of things applications on web,” Ph.D. dissertation, Institut
National des Télécommunications, 2015.
[14] J. E. Luzuriaga, M. Perez, P. Boronat, J. C. Cano, C. Calafate, and
P. Manzoni, “A comparative evaluation of AMQP and MQTT protocols
over unstable and mobile networks,” in 12th Annual IEEE Consumer
Communications and Networking Conference, 2015, pp. 931–936.
[15] G. Marsh, A. P. Sampat, S. Potluri, and D. K. Panda, “Scaling advanced
message queuing protocol (AMQP) architecture with broker federation
and infiniband,” Ohio State University, Tech. Rep. OSU-CISRC-5/09-
TR17, 2008.
[16] K. Kuladinithi, O. Bergmann, T. Pötsch, M. Becker, and C. Görg,
“Implementation of coap and its application in transport logistics,” Proc.
IP+ SN, Chicago, IL, USA, 2011.
[17] S. S. Ngo Manh Khoi, K. Mitra, and C. Ahlund, “Irehmo: An efficient
IoT-based remote health monitoring system for smart regions,” 2015.
[18] J. Stansberry. (2015, October 7) MQTT and CoAP: Underlying
protocols for the IoT. [Online]. Available: http://electronicdesign.com/
iot/mqtt-and-coap-underlying-protocols-iot
[19] J. E. Luzuriaga, M. Perez, P. Boronat, J. C. Cano, C. Calafate,
and P. Manzoni, “Testing AMQP protocol on unstable and mobile
networks,” in Internet and Distributed Computing Systems. Springer,
2014, pp. 250–260.
[20] S. Nicholas. (2012, May 31) Power profiling: HTTPS long
polling vs. MQTT with SSL, on android. [Online]. Available:
http://stephendnicholas.com/posts/power-profiling-mqtt-vs-https
[21] W. Colitti, “Communication stacks: Constrained Application Protocol,”
ISN Interoperable Sensor Networks Deliverable, 2011.
[22] W. Colitti, K. Steenhaut, and N. De Caro, “Integrating wireless sensor
networks with the web,” Extending the Internet to Low power and Lossy
Networks (IP+ SN 2011), 2011.
[23] M. Mellia, M. Meo, and C. Casetti, “TCP smart framing: a segmentation
algorithm to reduce TCP latency,” Networking, IEEE/ACM Transactions
on, vol. 13, no. 2, pp. 316–329, 2005.
[24] N. Naik and P. Jenkins, “Securing digital identities in the cloud
by selecting an apposite federated identity management from saml,
oauth and openid connect,” in 2017 11th International Conference on
Research Challenges in Information Science (RCIS). IEEE, 2017, pp.
163–174.
[25] N. Naik, P. Jenkins, and D. Newell, “Choice of suitable identity and ac-
cess management standards for mobile computing and communication,”
in 2017 24th International Conference on Telecommunications (ICT).
IEEE, 2017, pp. 1–6.
[26] N. Naik, “Connecting Google cloud system with organizational systems
for effortless data analysis by anyone, anytime, anywhere,” in IEEE
International Symposium on Systems Engineering (ISSE). IEEE, 2016.
[27] N. Naik and P. Jenkins, “An analysis of open standard identity protocols
in cloud computing security paradigm,” in 14th IEEE International
Conference on Dependable, Autonomic and Secure Computing (DASC
2016). IEEE, 2016.
[28] ——, “A secure mobile cloud identity: Criteria for effective identity
and access management standards,” in 2016 4th IEEE International
Conference on Mobile Cloud Computing, Services, and Engineering
(MobileCloud). IEEE, 2016, pp. 89–90.
[29] N. Naik, P. Jenkins, N. Savage, and V. Katos, “Big data security analysis
approach using computational intelligence techniques in R for desk-
top users,” in IEEE Symposium Series on Computational Intelligence
(SSCI). IEEE, 2016.
[30] N. Naik, “Migrating from Virtualization to Dockerization in the cloud:
Simulation and evaluation of distributed systems,” in IEEE 10th In-
ternational Symposium on the Maintenance and Evolution of Service-
Oriented and Cloud-Based Environments, MESOCA 2016. IEEE, 2016.
[31] ——, “Building a virtual system of systems using Docker Swarm
in multiple clouds,” in IEEE International Symposium on Systems
Engineering (ISSE). IEEE, 2016.