ArticlePDF Available

A survey on application layer protocols for the Internet of Things

Authors:
Transaction on IoT and Cloud Computing 2015
A Survey on Application Layer Protocols for the
Internet of Things
Vasileios Karagiannis1, Periklis Chatzimisios1, Francisco Vazquez-Gallego2, Jesus Alonso-Zarate2
1CSSN Research Lab, Department of Informatics, Alexander TEI of Thessaloniki, Greece
basilkaragiannis@ gmail.com, peris@it.teithe.gr
2Centre Tecnologic de Telecomunicacions de Catalunya (CTTC), Spain
[francisco.vazquez, jesus.alonso]@cttc.es
Abstract
It has been more than fifteen years since the term Internet of Things (IoT) was in-
troduced to the public. However, despite the efforts of research groups and innovative
corporations, still today it is not possible to say that IoT is upon us. This is mainly due
to the fact that a unified IoT architecture has not been yet clearly defined and there is
no common agreement in defining protocols and standards for all IoT parts. The frame-
work that current IoT platforms use consists mostly in technologies that partially fulfill
some of the IoT requirements. While developers employ existing technologies to build the
IoT, research groups are working on adapting protocols to the IoT in order to optimize
communications. In this paper, we present and compare existing IoT application layer
protocols as well as protocols that are utilized to connect the things but also end-user
applications to the Internet. We highlight IETFs CoAP, IBMs MQTT, HTML 5s Web
socket among others, and we argue their suitability for the IoT by considering reliability,
security, and energy consumption aspects. Finally, we provide our conclusions for the IoT
application layer communications based on the study that we have conducted.
Keywords:Internet of Things (IoT), Application Layer Protocols, Request/Response,
Publish/Subscribe.
1 Introduction
The IoT envisions hundreds or thousands of end-devices with sensing, actuating, pro-
cessing, and communication capabilities able to be connected to the Internet [1]. These
devices can be directly connected using cellular technologies such as 2G/3G/Long Ter-
m Evolution and beyond (5G) or they can be connected through a gateway, forming
a local area network, to get connection to the Internet. The latter is the case where
the end-devices usually form Machine to Machine (M2M) networks using various radio
technologies, such as Zigbee (based on the IEEE 802.15.4 Standard), Wi-Fi (based on
the IEEE 802.11 Standard), 6LowPAN over Zigbee (IPv6 over Low Power Personal Area
1
ISSN: 2331-4753 (Print)
ISSN: 2331-4761 (Online)
3(1) 9-18
Networks), or Bluetooth (based on the IEEE 802.15.1).
Regardless the specific wireless technology used to deploy the M2M network, all the
end-devices should make their data available to the Internet [2]. This can be achieved
either by sending the information to a proprietary web server accessible from the Internet
or by employing the cloud. Onlineplatforms such as ThingSpeak.com or Open.Sen.se,
among any other alternatives, are virtual clouds able to receive, store, and process data.
Besides acting as remote data bases, M2M clouds also offer the following key services:
1. They offer Application Programming Interfaces (API) with built-in functions for
end-users, thus providing the option to monitor and control end-devices remotely
fromaclient device.
2. They act as asynchronous intermediate nodes between the end-devices and final
applications running on devices such as smart phones, tablets or desktops.
Our paper focuses on the protocols that handle the communication between the gateways,
the public Internet, and the final applications (Figure 1). They are application layer
protocols that are used to update online servers with the latest end-device values but also
to carry commands from applications to the end-device actuators.
The rest of the paper is organized as follows. Section 2 describes our research motiva-
tion whereas each of the other sections is dedicated to a specific application layer protocol.
At the first part of each section we introduce each application layer protocol, we present
its usage, we discuss the reliability and security features it offers and we then compare
its suitability for the IoT with other application layer protocols. Finally, in Section 9, we
present overall conclusions based on the previous sections and we provide further research
areas.
2 Research motivation
The IoT is a term used for a huge wave of innovation originated in industries, but
currently heading to urban centers, in-home environments, and individuals.
2
Figure 1. IoT architecture
Our main motivation was to create an IoT test-bed where to test communications
protocols and also innovative applications that could be applied to a gamut of scenarios.
While searching for the appropriate application layer protocols to use, we found out that
while comparisons can be found between two protocols, there is no paper overviewing all
the possible alternatives with pros and cons.
The main motivation of this paper is to fill this gap and provide a brief yet accurate
description of the key protocols that are being used today to implement the IoT. More
specifically, we will discuss on the following list of protocols being used alternatively or
jointly to solve different needs of the communication between machines:
1) CoAP: Constrained Application Protocol.
2) MQTT: Message Queue Telemetry Transport.
3) XMPP: Extensible Messaging and Presence Protocol.
4) RESTFUL Services: Representational State Transfer.
5) AMQP: Advanced Message Queuing Protocol
6) Websockets.
3 CoAP
The Constrained Application Protocol (CoAP) is a synchronous request/response application-
layer protocol that was designed by the Internet Engineering Task Force (IETF) to target
constrained-recourse devices. It was designed by using a subset of the HTTP methods
making it interoperable with HTTP [3].
CoAP runs over UDP to keep the overall implementation lightweight. It uses the
HTTP commands GET, POST, PUT, and DELETE to provide resource-oriented inter-
actions in a client-server architecture. CoAP is a request/response protocol that utilizes
both synchronous and asynchronous responses. The reason for designing a UDP-based
application layer protocol to manage the resources is to remove the TCP overhead and
reduce bandwidth requirements [4]. Additionally, CoAP supports unicast as well as mul-
ticast, as opposed to TCP, which is by its nature not multicast-oriented.
Running on the unreliable UDP, CoAP integrated its own mechanisms for achieving
reliability. Two bits in the header of each packet state the type of message and the
required Quality of Service (QoS) level. There are 4 message types:
1. Confirmable: A request message that requires an acknowledgement (ACK). The
response can be sent either synchronously (within the ACK) or if it needs more
computational time, it can be sent asynchronously with a separate message.
2. Non-Confirmable: A message that does not need to be acknowledged.
3. Acknowledgment: It confirms the reception of a confirmable message.
4. Reset: It confirms the reception of a message that could not be processed.
3
There is also a simple Stop-and-Wait retransmission mechanism for confirmable mes-
sages and a 16-bit header field in each CoAP packet called Message ID which is unique
and used for detecting duplicates.
CoAPCHTTP Mapping enables CoAP clients to access resources on HTTP servers
through a reverse proxy that translates the HTTP Status codes to the Response codes of
CoAP [5].
Even though CoAP was created for the IoT and for M2M communications, it does
not include any built-in security features. The protocol that is proposed to secure CoAP
transactions is the Datagram Transport Layer Security (DTLS). DTLS runs on top of
UDP and is the analogous of TLS for the TCP. It provides authentication, data integri-
ty, confidentiality, automatic key management, and cryptographic algorithms [6]. Even
though DTLS secures UDP transfers, it was not designed for the IoT, thus its suitability
can be argued. To begin with, DTLS does not support multicast [6], which is a prime
advantage of CoAP compared to other application layer protocols. DTLS handshakes
[7] require additional packets that increase the network traffic, occupy additional compu-
tational resources, and shorten the lifespan of mobile devices that run on batteries, an
essential part of the IoT. Being designed for the IoT, CoAP is HTTP-compatible, but
CoAP over DTLS might create additional confusion to the HTTP servers due to its di-
verse packet structure. Other protocols for securing CoAP can be found in the literature
including approaches that are still being under research [6]-[7].
4 MQTT
Message Queue Telemetry Transport (MQTT) was released by IBM and targets lightweight
M2M communications. It is an asynchronous publish/subscribe protocol that runs on top
of the TCP stack. Publish/subscribe protocols meet better the IoT requirements than re-
quest/response since clients do not have to request updates thus, the network bandwidth
is decreasing and the need for using computational resources is dropping.
In MQTT there is a broker (server) [8] that contains topics. Each client can be a
publisher that sends information to the broker at a specific topic or/and a subscriber that
receives automatic messages every time there is a new update in a topic he is subscribed.
The MQTT protocol is designed to use bandwidth and battery usage sparingly, which is
why, for example, it is currently used by Facebook Messenger [9].
MQTT ensures reliability by providing the option of three QoS levels:
1. Fire and forget: A message is sent once and no acknowledgement is required.
2. Delivered at least once: A message is sent at least once and an acknowledgement is
required.
3. Delivered exactly once: A four-way handshake mechanism is used to ensure the
message is delivered exactly one time.
Even though MQTT runs on TCP, it is designed to have low overhead compared
to other TCP-based application layer protocols [10]. Moreover, the publish/subscribe
architecture that it used, is more suitable for the IoT than request/response of CoAP,
for example, because messages do need to be responded. This means lower network
4
bandwidth and less message processing that actually extends the lifetime of battery-run
devices.
To ensure security, MQTT brokers may require username/password authentication
which is handled by TLS/SSL (Secure Sockets Layer), i.e., the same security protocols
that ensure privacy for HTTP transactions all over the Internet.
By comparing MQTT with the aforementioned CoAP, it is possible to see that the
UDP-based CoAP has lower overhead than the TCP-based MQTT. However, due to the
lack of TCPs retransmission mechanisms, packet loss is more likely to happen when using
CoAP. According to a recent research study [10], MQTT experiences lower delays that
CoAP for low packet losses, but CoAP generates less extra traffic for ensuring reliability.
However, results can vary depending on the network conditions. Additionally packet loss
and delays depend on the QoS of the messages. In both protocols, packet loss degrades
and delays increase when the QoS level is higher.
5 XMPP
The Extensible Messaging and Presence Protocol (XMPP) was designed for chatting
and message exchanging. It was standardized by the IETF over a decade ago, thus being
a well-proven protocol that has been used widely all over the Internet. However, being an
old protocol, it falls short to provide the required services for some of the new arising data
applications. For this reason, last year, Google stopped supporting the XMPP standard
due to the lack of worldwide support [11]. However, lately XMPP has re-gained a lot of
attention as a communication protocol suitable for the IoT.
XMPP runs over TCP and provides publish/subscribe (asynchronous) and also re-
quest/response (synchronous) messaging systems. It is designed for near real-time com-
munications and thus, it supports small message footprint and low latency message ex-
change [12]. As the name explicitly states, XMPP is extensible and allows the specification
of XMPP Extension Protocols (XEP) that increase its functionality.
XMPP has TLS/SSL security built in the core of the specification. However, it does
not provide QoS options that make it impractical for M2M communications. Only the
inherited mechanisms of TCP ensure reliability.
XMPP supports the publish/subscribe architecture that is more suitable for the IoT in
contrast to CoAPs request/response approach. Furthermore, it is an already established
protocol that is supported all over the Internet as a plus with regard to the relatively new
MQTT [13]. However, XMPP uses XML messages (eXtensible Markup Language) that
create additional overhead due to unnecessary tags and require XML parsing that needs
additional computational ability which increases power consumption.
6 RESTFUL SERVICES
The Representational State Transfer (REST) is not really a protocol but an architec-
tural style. It was first introduced by Roy Fielding in 2000 [14], and it is being widely
used ever since.
REST uses the HTTP methods GET, POST, PUT, and DELETE to provide a resource-
5
oriented messaging system where all actions can be performed simply by using the syn-
chronous request/response HTTP commands. It uses the built-in accept header of HTTP
to indicate the format of the data that it contains. The content type can be XML or
JSON (JavaScript Object Notation) and depends on the HTTP server and its configura-
tion. REST is already an important part of the IoT because it is supported by all the
commercial M2M cloud platforms. Moreover it can be implemented in smartphone and
tablet applications easily because it only requires an HTTP library which is available for
all the Operative Systems (OS) distributions. The features of HTTP can be completely
utilized in the REST architecture including cashing, authentication, and content type
negotiation [15].
RESTful services use the secure and reliable HTTP which is the proven worldwide
Internet language. It can make use of TLS/SSL for security. However, today most
commercial M2M platforms do not support HTTPS requests. Instead, they provide unique
authentication keys that need to be in the header of each request to achieve some level of
security.
Even though REST is already used widely in commercial M2M platforms, it is unlikely
that it will become a dominant protocol due to not being easily implementable. It us-
es HTTP which means no compatibility with constrained-communication devices. This
leaves its use for final applications.
Given the current tendency for applications running on smartphones, tablets and pads,
the additional overhead associated to request/response protocols affect battery usage, as
it also does the continuous polling or long polling for values especially when there are
no new updates and the overhead becomes useless. Issues that can be avoided if a pub-
lish/subscribe protocol is used such as MQTT or XMPP. CoAP on the other hand, which
is the lightweight version of REST, bears the same disadvantages of the request/response
architecture. However it is designed to run over UDP making it capable of being used by
constrained resource devices, counter to REST.
7 AMQP
The Advanced Message Queuing Protocol (AMQP) is a protocol that arose from the
financial industry. It can utilize different transport protocols but it assumes an underlying
reliable transport protocol such as TCP [16].
AMQP provides asynchronous publish/subscribe communication with messaging. Its
main advantage is its store-and-forward feature that ensures reliability even after network
disruptions [17]. It ensures reliability with the following message-delivery guarantees [16]:
1. At most once: means that a message is sent once either if it is delivered or not.
2. At least once : means that a message will be definitely delivered one time, possibly
more.
3. Exactly once : means that a message will be delivered only one time.
Security is handled with the use of the TLS/SSL protocols over TCP.
Recent research has shown that AMQP has low success rate at low bandwidths, but
it increases as bandwidth increases [17]. Another study shows that comparing AMQP
6
with the aforementioned REST, AMQP can send a larger amount of messages per second
[18]. Additionally, it has been reported that an AMQP environment with 2,000 users
spread across five continents can process 300 million messages per day [18]. Furthermore,
JPMorgan which is an American banking and financial services company uses AMQP to
send 1 billion messages per day [19].
8 WEBSOCKET
The Websocket protocol was developed as part of the HTML 5 initiative to facili-
tate communications channels over TCP. Websocket is neither a request/response nor a
publish/subscribe protocol. In Websocket a client initializes a handshake with a server to
establish a Websocket session. The handshake itself is similar to HTTP so that web servers
can handle Websocket sessions as well as HTTP connections through the same port [20].
However, what comes after the handshake does not conform to the HTTP rules. In fact,
during a session, the HTTP headers are removed and clients and servers can exchange
messages in an asynchronous full-duplex connection. The session can be terminated when
it is no longer needed from either the server or the client side. Websocket was creat-
ed to reduce the Internet communication overhead while providing real-time full-duplex
communications. There is also a Websocket sub-protocol called Websocket Application
Messaging Protocol (WAMP) that provides publish/subscribe messaging systems.
Websocket runs over the reliable TCP and implements no reliability mechanisms by
its own. If needed, the sessions can be secured using the Websocket over TLS/SSL.
During the session, Websocket messages have only 2 bytes of overhead. As reported
by relevant studies [21], the HTTP polling (in REST) repeats header information when
the data transmission rate increases, thus increasing latency. Websocket is estimated
to provide a three-to-one reduction in latency against the half-duplex HTTP polling.
Websocket is not designed for resource constrained devices as the previous protocols and
its client/server based architecture does not suit IoT applications. However it is designed
for real-time communication, it is secure, it minimizes overhead and with the use of WAMP
it can provide efficient messaging systems. Thus, it can compete any other protocol
running over TCP.
9 Conclusions & future work
In this paper, we have presented a common IoT architecture by describing the parts
where application layer protocols are needed to handle communication. We have present-
ed the most representative application layer protocols that have gained attention for IoT
while providing a comparison among each other and argue about their suitability for the
future of the IoT. Among them, we have identified IETFs CoAP as the only one that runs
over UDP, thus making it the most lightweight, followed by HTML 5s Websocket that
significantly reduces the communications overhead. The computational and communica-
tion ability of the devices involved must also be taken into consideration when choosing
the most appropriate protocol. If constrained communication and battery consumption
is not an issue, RESTful services can be easily implemented and interact with the In-
ternet using the worldwide HTTP. This can be proved very useful in testbeds as it can
7
Protocol Transport QoS options Architecture Security
CoAP UDP YES Request/Response DTLS
MQTT TCP YES Publish/Subscribe TLS/SSL
XMPP TCP NO Request/Response
Publish/Subscribe TLS/SSL
REST HTTP NO Request/Response HTTPS
AMQP TCP YES Publish/Subscribe TLS/SSL
Web socket TCP NO Client/Server
Publish/Subscribe TLS/SSL
Table 1: Major differences among protocols
work as proof of concept for final applications. On the contrary, MQTT which is used by
Facebook Messenger is not as widely used as HTTP but has proved to be more efficient
for battery-run devices. Additionally if the targeted final applications require massive
updates of the same value, publish/subscribe protocols are more suitable. To sum up,
there are several factors that influence the selection of an application layer protocol the
most important of which are the computational and communication ability of the devices,
battery consumption and final application in mind. For this reason opinions differ. An
overview of major differences among the aforementioned protocols can be found below
(Table 1).
Having seen this paper purely qualitatively, future work will be aimed at implementing
all these protocols and obtain an experimental and quantifiable comparison among them.
Moreover, we plan to explore the possibility of creating a server that supports multiple
application layer protocols and dynamically chooses the most appropriate according to
the networks conditions. Such an innovative approach not designed so far, would optimize
the overall performance of the IoT in various application scenarios.
References
[1] Tasos Kaukalias and Periklis Chatzimisios, Internet of Things (IoT) C Enabling tech-
nologies, applications and open issues, Encyclopedia of Information Science and Tech-
nology (3rd Ed.), IGI Global Press, 2014.
[2] Periklis Chatzimisios, Industry Forum & Exhibition Panel on Internet of Humans
and Machines, IEEE Global Communications Conference (Globecom 2013), Atlanta,
USA, December 2013.
[3] Angelo P. Castellani, Mattia Gheda, Nicola Bui, Michele Rossi, Michele Zorzi, We-
b Services for the Internet of Things through CoAP and EXI, IEEE International
Conference on Communications Workshops (ICC), 5-9 June 2011, pp. 1-6.
[4] Sye Loong Keoh, Sandeep S. Kumar, Hannes Tschofenig, Securing the Internet of
Things: A Standardization Perspective, Internet of Things Journal IEEE (Volume:
1, Issue: 3), June 2014, pp. 265-275.
[5] Maria Rita Palattella, Nicola Accettura, Xavier Vilajosana, Thomas Watteyne, Luigi
Alfredo Grieco, Gennaro Boggia, Mischa Dohler, Standardized Protocol Stack for the
8
Internet of (Important) Things, Communications Surveys & Tutorials IEEE 15(3),
2013, pp. 1389-1406.
[6] Thamer A. Alghamdi, Aboubaker Lasebae, Mahdi Aiash, Security Analysis of the
Constrained Application Protocol in the Internet of Things, Second International
Conference on Future Generation Communication Technology (FGCT), 12-14 Nov.
2013, pp. 163-168.
[7] Shahid Raza, Hossein Shafagh, Kasun Hewage, Ren Hummen, Thiemo Voigt, Lithe:
Lightweight Secure CoAP for the Internet of Things, Sensors Journal, IEEE 13(10),
Oct. 2013, pp. 3711-3720.
[8] Shinho Lee, Hyeonwoo Kim, Dong-kweon Hong, Hongtaek Ju, Correlation Analy-
sis of MQTT Loss and Delay According to QoS Level, International Conference on
Information Networking (ICOIN), 28-30 Jan. 2013, pp. 714-717.
[9] http://mqtt.org/2011/08/mqtt-used-by-facebook-messenger, cited 28 Jul 2014.
[10] Dinesh Thangavel, Xiaoping Ma, Alvin Valera, Hwee-Xian Tan, Colin Keng-Yan
Tan, Performance Evaluation of MQTT and CoAP via a Common Middleware, IEEE
Ninth International Conference on Intelligent Sensors, Sensor Networks and Informa-
tion Processing (ISSNIP), 21-24 April 2014, pp. 1-6.
[11] http://www.zdnet.com/google-moves-away-from-the-xmpp-open-messaging-
standard-7000015918/, cited 28 Jul 2014.
[12] Sven Bendel, Thomas pringer, Daniel Schuster, Alexander Schill, Ralf Ackermann,
Michael Ameling, A Service Infrastructure for the Internet of Things based on XMPP,
IEEE International Conference on Pervasive Computing and Communications Work-
shops (PERCOM Workshops), 18-22 March 2013, pp. 385-388.
[13] Michael Kirsche, Ronny Klauck, Unify to Bridge Gaps: Bringing XMPP into the In-
ternet of Things, IEEE International Conference on Pervasive Computing and Com-
munications Workshops (PERCOM Workshops), 19-23 March 2012, pp. 455-458.
[14] Roy Thomas Fielding, Architectural Styles and the Design of Network-based Software
Architectures, PhD thesis, University of California, Irvine, USA, 2000.
[15] Bipin Upadhyaya, Ying Zou, Hua Xiao, Joanna Ng, Alex Lau, Migration of SOAP-
based Services to RESTful Services, 13th IEEE International Symposium on Web
Systems Evolution (WSE), 30 Sept. 2011, pp. 105-114.
[16] http://en.wikipedia.org/wiki/Advanced Message Queuing Protocol, cited 28 Jul
2014.
[17] Frank T. Johnsen, Trude H. Bloebaum, Morten Avlesen, Skage Spjelkavik, Bjørn
Vik, Evaluation of Transport Protocols for Web Services, Military Communications
and Information Systems Conference (MCC), 7-9 Oct. 2013, pp. 1-6.
[18] Joel L. Fernandes, Ivo C. Lopes, Joel J. P. C.Rodrigues, Sana Ullah, Performance
Evaluation of RESTful Web Services and AMQP Protocol, Fifth International Con-
ference on Ubiquitous and Future Networks (ICUFN), 2-5 July 2013, pp. 810-815.
9
[19] http://www.amqp.org/about/examples, cited 28 Jul 2014.
[20] http://en.wikipedia.org/wiki/WebSocket, cited 28 Jul 2014.
[21] Victoria Pimentel, Bradford G. Nickerson, Communicating and Displaying Real-Time
Data with WebSocket, Internet Computing IEEE 16(4), July-Aug. 2012, pp. 45-53.
10
... The main advantage of using AMQP is the store-and-forward feature, which assures dependability and trustworthiness. However, it may create network interruptions [116]. It requires a reliable transport protocol that specifies how it uses the Transmission Control Protocol (TCP) to deliver and receive messages [117]. ...
... Intercepting the packet when an end-user has been authenticated allows an attacker to undertake account hijacking. As documented in several situations [126], the [105] RST should be expanded to include LoWPANsg [106] Reliability is achieved by the use of re-transmission mechanism [107] Application layer [108] Formatting handshaking connection [118] MQTT WSN,M2M, and IoT [110] Lightweight M2M communication [111] Telemetry-style data transmission [112] XMPP Security [113] Exchange of messages [114] Reliable and trustworthy network [115] Multi-party chatting, telepresence,and voice & video calling [116] Financial industry [117] TCP for exchanging messages [119] LoRa Collecting human body data, "MySignals" developed a healthcare management solution based on the LoRa wireless network option to guess inputs, such as passwords. IoMT apps are vulnerable to brute-force attacks, because there is inadequate security to prevent such attacks on IoT devices. ...
Article
Full-text available
Extensive research has been conducted on healthcare technology and service advancements during the last decade. The Internet of Medical Things (IoMT) has demonstrated the ability to connect various medical apparatus, sensors, and healthcare specialists to ensure the best medical treatment in a distant location. Patient safety has improved, healthcare prices have decreased dramatically, healthcare services have become more approachable, and the operational efficiency of the healthcare industry has increased. This research paper offers a recent review of current and future healthcare applications, security, market trends, and IoMT-based technology implementation. This research paper analyses the advancement of IoMT implementation in addressing various healthcare concerns from the perspectives of enabling technologies, healthcare applications, and services. The potential obstacles and issues of the IoMT system are also discussed. Finally, the survey includes a comprehensive overview of different disciplines of IoMT to empower future researchers who are eager to work on and make advances in the field to obtain a better understanding of the domain.
... Likewise [5] grantsan agent application layer conventions which can be acquired consideration for IoT.By giving an examination from one another and squabble over their appropriateness for the eventual fate. ...
... These details can be found in [2]. This means anything can connect to the internet, and the IoT provides integration among all these elements, which serve a common goal of providing solutions and services anytime and anywhere to make our environment smart which is asserted by [3]. The development of connection protocols (higher speed or lower cost) has played a vital role like Bluetooth, ZigBee, Wi-Fi, 4G, 5G, and 6G, whose details can be found in [4]. ...
Article
Full-text available
The Internet of Things, computing models, artificial intelligence algorithms, and communication protocols have all contributed to a smarter world. These technologies are achieving tremendous results in advancement in areas such as health, education, transportation, economy, services, and environment, to name a few. However, there are still serious challenges that need to be addressed in regard to security and the privacy of users’ data. Unfortunately, so far, the current methods for protection have only met the requirements of specific applications. Most of these methods suffer from problems related to the level of protection, level of resistance to attacks, performance, and accuracy of results of the main services. Moreover, the methods lack the mechanism to trust other parties, which are often the source of threat. This paper presents a comprehensive privacy protection framework that seeks to create an effective, dynamic, and adaptive approach, which we call the Comprehensive Privacy and Security Framework (CPSF). The proposed approach is not based on any particular technology, but on the integration of most of the main protection techniques. In this research, we will provide a framework of the first stage of the CPSF and discuss its components that would be able to choose the appropriate method from a list of the available protection methods. For future research, we will provide an extended framework and its implementation, which would be tested on real cases on different components of the Internet of Things.
... In particular, short-range standard network protocols, such as ZigBee, Bluetooth Low Energy (BLE), Z-Wave, and Near Field Communication (NFC), are considered, as well as SigFox and Cellular, which, instead, are LPWAN standard protocols. Furthermore, the paper presented in [7] focuses on IoT application layer protocols, without considering the security-related requirements. ...
Article
Full-text available
The Internet of Things (IoT) paradigm is characterized by the adoption of different protocols and standards to enable communications among heterogeneous and, often, resource-constrained devices. The risk of violation is high due to the wireless nature of the communication protocols usually involved in the IoT environments (e.g., e-health, smart agriculture, industry 4.0, military scenarios). For such a reason, proper security countermeasures must be undertaken, in order to prevent and react to malicious attacks, which could hinder the data reliability. In particular, the following requirements should be addressed: authentication, confidentiality, integrity, and authorization. This paper aims at investigating such security features, which are often combined with native functionalities, in the most known IoT-related protocols: MQTT, CoAP, LoRaWAN, AMQP, RFID, ZigBee, and Sigfox. The advantages and weaknesses of each one will be revealed, in order to point out open issues and best practices in the design of efficient and robust IoT network infrastructure.
... The Things layer are the group of physical devices that directly collect data or perform an action based on a control command from the user. The device is usually limited in power, processing and bandwidth [3]. So, the most important requirement of the Things layer is balanced between processing capabilities and power consumption of devices (1). ...
Article
Full-text available
The Internet of Things (IoT), currently, is one of the most interesting technology trends. IoT is the foundation and driving force for the development of other scientific fields based on its ability to connect things and the huge amount of data it collects. The IoT Platform is considered the backbone of every IoT architecture that not only allows the transfer of data between user and device but also the feed of high-level applications such as big data or deep learning. As a result, the optimal design of the IoT Platform is a very important issue, which should be carefully considered in many aspects. Although the IoT is applied in multiple domains, there are three indispensable features including (a) data collections, (b) devices and users management, and (c) remote device control. These functions usually come with some requirements, for example, security, high-speed transmission, low energy consumption, reliable data exchange, and scalable systems. In this paper, we propose the IoT Platform,called BMP (Broker-less and Microservice Platform) designed according to microservice and broker-less architecture combined with gRPC protocol to meet the requirements of the three features mentioned above. Our IoT Platform addresses five issues: (1) address the limited processing capacity of devices, (2) reduce energy consumption, (3) speed up transmission rate and enhance the accuracy of the data exchange, (4) improve security mechanisms, and (5) improve the scalability of the system. Moreover, we describe the evaluation to prove the effectiveness of the BMP (i.e., proof-of-concept) in three scenarios. Finally, a source code of the BMP is publicized on the GitHub repository to engage further reproducibility and improvement.
Conference Paper
Full-text available
La generación de tráfico realista en una red es un problema complejo, que habitualmente se aborda mediante el establecimiento previo de un modelo de tráfico. Un modelo de tráfico es una representación, lo más cercana a la realidad, del comportamiento de los paquetes y mensajes que recorren una red en un escenario concreto. Por ello, en este artículo se parte del análisis del estado del arte de todas las tecnologías que permiten la generación de tráfico, para posteriormente introducir el diseño de un sistema cuyo objetivo es la generación de tráfico realista basado en comportamiento de usuario, haciendo uso de usuarios simulados (NPC – Non-Playable Characters), totalmente automatizado y auto adaptable a escenarios virtualizados para su uso en plataformas de tipo Cyber Range utilizadas en el ámbito del entrenamiento en ciberseguridad.
Conference Paper
Full-text available
Wireless sensor networks (WSNs) typically consist of sensor nodes and gateways that operate on devices with limited resources. As a result, WSNs require bandwidth-efficient and energy-efficient application protocols for data transmission. Message Queue Telemetry Transport (MQTT) and Constrained Application Protocol (CoAP) are two such protocols proposed for resource-constrained devices. In this paper, we design and implement a common middleware that supports MQTT and CoAP and provides a common programming interface. We design the middleware to be extensible to support future protocols. Using the common middleware, we conducted experiments to study the performance of MQTT and CoAP in terms of end-to-end delay and bandwidth consumption. Experimental results reveal that MQTT messages have lower delay than CoAP messages at lower packet loss rates and higher delay than CoAP messages at higher loss rates. Moreover, when the message size is small and the loss rate is equal to or less than 25%, CoAP generates lower additional traffic than MQTT to ensure message reliability.
Article
Full-text available
The Internet of Things (IoT) is the next wave of innovation that promises to improve and optimize our daily life based on intelligent sensors and smart objects working together. Through Internet Protocol (IP) connectivity, devices can now be connected to the Internet, thus allowing them to be read, controlled, and managed at any time and at any place. Security is an important aspect for IoT deployments. However, proprietary security solutions do not help in formulating a coherent security vision to enable IoT devices to securely communicate with each other in an interoperable manner. This paper gives an overview of the efforts in the Internet Engineering Task Force (IETF) to standardize security solutions for the IoT ecosystem. We first provide an in-depth review of the communication security solutions for IoT, specifically the standard security protocols to be used in conjunction with the Constrained Application Protocol (CoAP), an application protocol specifically tailored to the needs of adapting to the constraints of IoT devices. Since Datagram Transport Layer Security (DTLS) has been chosen as the channel security underneath CoAP, this paper also discusses the latest standardization efforts to adapt and enhance the DTLS for IoT applications. This includes the use of 1) raw public key in DTLS; 2) extending DTLS record Layer to protect group (multicast) communication; and 3) profiling DTLS for reducing the size and complexity of implementations on embedded devices. We also provide an extensive review of compression schemes that are being proposed in IETF to mitigate message fragmentation issues in DTLS.
Conference Paper
Full-text available
MQTT is an open protocol developed and released by IBM. To ensure the reliability of message transmission, MQTT supports three levels of QoS. In this paper, we analyze MQTT message transmission process which consists of real wired/wireless publish client, broker server and Subscribe client. By transmitting messages through 3 levels of QoS with various sizes of payloads, we have captured packets to analyze end-to-end delays and message loss.
Conference Paper
Full-text available
The concept of Internet of Things involves huge number of constrained devices such as wireless sensors to communicate in a machine-to-machine pattern. Based on the implementation scenario, such communication might take place over a public network such as the Internet, which is based on the TCP/IP stack. However, different research working groups argue that some of these stack protocols such as the Hyper Text Transfer Protocol (HTTP) might not be suitable for constrained devices. Therefore, the IETF Constrained RESTful Environments (CoRE) WG has proposed the Constrained Application Protocol (CoAP); an application layer protocol for constrained devices in the IoTs. The CoRE WG proposed using IPSec or DTLS to secure the CoAP communication at different levels of the protocol stack. However, to investigate the feasibility of such a proposal, we use the X.805 security standard to analyze the security aspects of such implementation. The analysis highlights the main security drawbacks and hence argues of the need for a new integrated security solution.
Conference Paper
Full-text available
Following the vision of an Internet of Things (IoT) real world objects are integrated into the Internet to provide data as sensors and to manipulate the real world as actors. While current IoT approaches focus on the integration of things based on service technologies, scenarios in domains like smart cities, automotive or crisis management require service platforms involving real world objects, backend-systems and mobile devices. In this paper we introduce a service platform based on the Extensible Messaging and Presence Protocol (XMPP) for the development and provision of services for such pervasive infrastructures. We argue for XMPP as protocol for unified, real-time communication and introduce the major concepts of our platform. Based on two case studies we demonstrate real-time capabilities of XMPP for remote robot control and service development in the e-mobility domain.
Article
Full-text available
The Internet of Things (IoT) enables a wide range of application scenarios with potentially critical actuating and sensing tasks, e.g., in the e-health domain. For communication at the application layer, resource-constrained devices are expected to employ the constrained application protocol (CoAP) that is currently being standardized at the Internet Engineering Task Force. To protect the transmission of sensitive information, secure CoAP mandates the use of datagram transport layer security (DTLS) as the underlying security protocol for authenticated and confidential communication. DTLS, however, was originally designed for comparably powerful devices that are interconnected via reliable, high-bandwidth links. In this paper, we present Lithe-an integration of DTLS and CoAP for the IoT. With Lithe, we additionally propose a novel DTLS header compression scheme that aims to significantly reduce the energy consumption by leveraging the 6LoWPAN standard. Most importantly, our proposed DTLS header compression scheme does not compromise the end-to-end security properties provided by DTLS. Simultaneously, it considerably reduces the number of transmitted bytes while maintaining DTLS standard compliance. We evaluate our approach based on a DTLS implementation for the Contiki operating system. Our evaluation results show significant gains in terms of packet size, energy consumption, processing time, and network-wide response times when compressed DTLS is enabled.
Article
Full-text available
The Internet of Things vision states that sensors and actuators shall be integrated into the global Internet to facilitate an interaction with and integration of the physical environment. The development of enabling technologies like uIPv6 and 6LoWPAN provide the basic requirements for this interconnection. However, a seamless Internet-connection and interconnection between sensors and actuators can still only be provided with the help of protocols that use gateways, intermediate proxies, and protocol translators. We propose a solution to unify the world of sensors and actuators with the Internet through the use of the Extensible Messaging and Presence Protocol (XMPP) while omitting application protocol gateways and protocol translators at the same time. This article describes our ideas to boost the Internet of Things vision by using XMPP. We present our current work in progress and an outlook into our future working directions in this field.
Conference Paper
Web services appeared as a promising technology for Web environments independent of technologies, services, and applications. Currently, there are some issues related with this approach that should be studied. For instance, if massive quantities of data are sent to databases it can influence significantly the performance of the whole system. The Advanced Message Queuing Protocol (AMPQ) appears as a promising solution to address this problem. Then, in order to evaluate the performance of this approach, this paper presents a performance comparison study of RESTful Web services and the AMQP Protocol considering exchanging messages between client and server. The study is based on the averaged exchanged messages for a period of time. It was observed and concluded that, for large quantities of messages exchange, the best results comes from the Advanced Message Queuing Protocol.
Conference Paper
Web services can be used as a middleware for standardized, interoperable machine-to-machine communication. However, the technology has communication overhead, leading to a need to investigate ways to optimize its resource use when applying the technology in limited capacity networks. There exist several approaches to optimization, and in this paper we investigate potential gains from replacing the commonly used HTTP/TCP transport for Web services with alternative transport protocols. We study four different protocols (TCP, UDP, SCTP, and AMQP) for conveying Web services traffic, evaluating them in an emulator under typical civil and military networking conditions.
Article
Internet communication provides a convenient, hyperlinked, stateless exchange of information, but can be problematic when real-time data exchange is needed. The WebSocket protocol reduces Internet communication overhead and provides efficient, stateful communication between Web servers and clients. To determine whether WebSocket communication is faster than HTTP polling, the authors built a Web application to measure the one-way transmission latency of sending real-time wind sensor data at a rate of 4 Hz. They implemented a Jetty servlet to upgrade an HTTP connection to a WebSocket connection. Here, they compare the WebSocket protocol latency to HTTP polling and long polling.