MQTT-RD: A MQTT based Resource Discovery for Machine to Machine
Communication
Eliseu Pereira, Rui Pinto, Jo
˜
ao Reis and Gil Gonc¸alves
SYSTEC - Research Center for Systems and Technologies, Faculty of Engineering, University of Porto, Porto, Portugal
Keywords:
M2M Communication, IoT, Resource Discovery, Resource Directory, Zero Configuration, MQTT.
Abstract:
The Internet of Things (IoT) is one of the key enablers for digital businesses and economic growth. By in-
terconnecting objects and people through diverse heterogeneous networks, using Machine to Machine (M2M)
communication, IoT enables the continuous monitoring of devices its surrounding environment, proving to
have a huge potential in terms of new business opportunities. One of the biggest challenges nowadays in
M2M communication, is the way devices are capable to look up for other devices and their services in local
networks and internet. This paper proposes a distributed resource discovery architecture (MQTT-RD) based
on the MQTT protocol. The proposed architecture enables decentralized discovery and management of de-
vices in multiple networks, by introducing plug and play capabilities to devices, contributing for a mechanism
for zero-configuration networking in IoT environments. This architecture was tested in an experimental envi-
ronment, composed of multiple devices, in order to test resource discovery capabilities using an MQTT based
protocol. The evaluated metrics were the overall message drop in the network, the delays in the delivery of
messages and the processing time of each message.
1 INTRODUCTION
Information and Communication Technology (ICT) is
considered to be one of the most important areas dur-
ing the last decades and upcoming years. The con-
stant miniaturization of technology enabled informa-
tion processing devices to shift from large comput-
ers towards small portable computers integrated into
larger products. ICT devices embedded into larger
systems led to the term ‘embedded systems’. These
systems are defined as information processing sys-
tems embedded into enclosing products, character-
ized specially for their real-time constrains, depend-
ability, concurrency and efficiency requirements.
These embedded systems have been equipped
with sophisticated sensors and actuators, interfaces,
processors, complex control loops, software agents
and communication means. Since the embedded com-
putation on these products uses closed models and
algorithms to control the electronics, the link to the
physical world is frequently ignored. More recently
this close link between computation and real world
has recently been stressed by the introduction of the
term Cyber-Physical Systems (CPS). [Lee, 2008] de-
fined CPS as the integration of computation and phys-
ical processes. Later, [Hellinger and Seeger, 2011]
extended the definition of CPS by mentioning the im-
portance of networking, control-loops and distribu-
tion. In fact, CPS differ of embedded systems in the
sense that CPS operate in a much larger scale, while
an embedded system is a self-contained system con-
fined to a single device. CPS usually include many
embedded systems and other devices.
The electronics of a CPS are controlled based on
an open control feedback loop, where the resulting
sensor information of the physical process monitoring
is used to control and optimize the CPS functionality.
In a CPS, sensors and actuators have been recently
enabled by Wireless Sensor and Actuator Networks
(WSAN). Sensors perceive the environment condi-
tions of the physical world and these data is used as
input in decision making processes. These processes
are usually represented as holonic representations of
the physical object in the virtual world, mostly known
as Digital Twins (DT). Usually, in a CPS, several
components of the system are represented by several
DTs. Because centralized control is unsuitable for
large-scale system integration, cooperation between
networked DTs enables distributed control.
Advances in wireless technology enabled the ex-
tension of devices with network connectivity for re-
mote monitoring and control. These solutions based
Pereira, E., Pinto, R., Reis, J. and Gonçalves, G.
MQTT-RD: A MQTT based Resource Discovery for Machine to Machine Communication.
DOI: 10.5220/0007716201150124
In Proceedings of the 4th International Conference on Internet of Things, Big Data and Security (IoTBDS 2019), pages 115-124
ISBN: 978-989-758-369-8
Copyright
c
2019 by SCITEPRESS Science and Technology Publications, Lda. All rights reser ved
115
on communication between devices, also know as
Machine to Machine (M2M) communication [Galeti
´
c
et al., 2011], were based on closed networks, built
specifically for this purpose. Later, this network con-
nection was based on the Internet Protocol (IP), al-
lowing for IP enabled devices to be monitored and
controlled over the Internet. Connecting objects to
each other over the Internet is the main idea of the
Internet of Things (IoT).
The term IoT refers to uniquely identifiable phys-
ical objects (‘Things’), also known as Smart Objects,
and their virtual representations in an internet-like
structure, namely the DT. The internet represents the
global networking of connected Smart Objects, en-
abling them to communicate with each other by ex-
changing and transforming information. [Gubbi et al.,
2013] define IoT as the interconnection of sensing and
actuation devices, providing the ability to share in-
formation across platforms through a unified frame-
work, developing a common operating picture for en-
abling innovative applications. It represents informa-
tion, networking and knowledge being integrated into
CPS.
IoT networks have several applications, at the
level of factories, hospitals, cities or agriculture.
Within Industrial IoT applications, M2M communica-
tion enables full automation of sensors and actuators,
allowing machines to be interconnected and to com-
municate over a network with minimal human inter-
vention. Human operators and stakeholders are able
to access production systems and monitoring man-
ufacturing processes, using several Human-Machine
Interfaces (HMI) and remotely connected devices.
This enables the collection of machine condition and
diagnosis data, and control process parameters for op-
timizing costs and product quality. Also, M2M com-
munication enables machines to connect with the IT
infrastructure of their own manufactures, in order to
request repairs and order new parts and components.
Regarding Intelligent Transportation Systems,
M2M will play an important role in connecting cars,
buses, traffic lights, trams, roads and emergency
crews, enabling the interconnection of all objects and
roads for road traffic efficiency and safety. In e-
Healthcare applications, patients staying at home with
medical bio-sensors can be monitored remotely by
doctors in the hospital, collecting data and analyzing
the patient’s health condition in real time. Networked
smart meters and advanced metering infrastructures
are enabled by M2M communications in Smart Power
Grid applications, for efficiency improvement, ser-
vice quality enhancement, save cost in power genera-
tion, distribution and consumption.
However, M2M communication presents some
challenges, namely [Song et al., 2014,Datta and Bon-
net, 2015]: 1) Communication interoperability, due
to the heterogeneity of the communication technolo-
gies used by different devices, e.g., Bluetooth, Zig-
bee, Modbus, etc; 2) Semantic interoperability, due to
different data models used to exchange sensor mea-
surements and actuator commands; 3) Resource dis-
covery, i.e., lack of capabilities to detect devices and
services offered by these devices in a CPS or IoT envi-
ronment, e.g., sensor measurements and/or actuation
commands; 4) Self-management, i.e., lack of system
capabilities to configure network topology and man-
age a large number of smart devices across multiple
networks.
Several M2M architectures were developed by
different standard organizations to tackle some of
these challenges, such as the European Telecommuni-
cations Standards Institute (ETSI) [Boswarthick and
Mulligan, 2009], 3rd Generation Partnership Project
(3GPP) [Kunz et al., 2012] and one Machine to Ma-
chine (oneM2M) [Chang et al., 2011]. In this pa-
per, the authors tackle the resource discovery chal-
lenge, by proposing a distributed resource discov-
ery approach, which enables zero-configuration net-
working in an IoT environment. This approach in-
troduces to M2M networked devices capabilities to
discover other devices and services in the same lo-
cal network and in remote networks, without relying
in a centralized entity to manage devices and com-
munications. The proposed solution, named MQTT-
RD, explores the MQTT protocol by using the Con-
strained RESTful Environments Resource Directory
(CoRE RD) principles. To validate the proposed so-
lution, scalability tests were carried out in an exper-
imental environment. The experimental environment
contains 2 machines, one runs the main component of
the MQTT-RD (Sniffer) while the other machine sim-
ulates multiple devices, which are successively added
to the network. Through the scalability tests it is pos-
sible to infer about the overall message drop in the
network, the delays in communication between com-
ponents and the processing time of new messages by
the Sniffer. From these metrics is estimated the limit
number of devices per Sniffer, and when this limit is
reached, Sniffer overloads message management, i.e,
at this point Sniffer can only receive messages, not
being able to forward them to the subscribers devices.
The rest of the paper is organized as follows. Sec-
tion 2 presents the background and surveys the state-
of-the-art regarding M2M protocols and methodolo-
gies that enable zero-configuration for resource dis-
covery. Section 3 presents and describes the pro-
posed architecture, highlighting the novel aspects of
the work. Section 4 characterizes a testbed for test-
IoTBDS 2019 - 4th International Conference on Internet of Things, Big Data and Security
116
ing the overall functionalities of the proposed solu-
tion and presents a discussion of the obtained results.
Finally, in Section 5, the conclusions are presented,
while future directions of the work are identified.
2 BACKGROUND & RELATED
WORK
Regarding M2M communication and according to
[Fysarakis et al., 2016], there are three main ap-
proaches for communication protocols used in IoT
environments, namely service-oriented approaches,
message-oriented approaches and resource-oriented
approaches.
Protocols used in service-oriented architectures
(SOA) are oriented for Web services, where a service
is a discrete unit of functionality that can be accessed
and updated remotely. The Devices Profile for Web
Services (DPWS) [Driscoll et al., 2009] and the Uni-
versal Plug and Play (UPnP) [Jeronimo and Weast,
2003] are examples of such protocols, where the
DPWS was introduced by Microsoft as a successor to
UPnP. Nowadays, the DPWS is an open standard of
the Organization for the Advancement of Structured
Information Standards (OASIS), being widely used
for large-scale enterprise deployment, such as indus-
trial automation systems, for exchange soft real-time
data [Cucinotta et al., 2009]. Despite being suited
for residential networks without enterprise-class de-
vices, for sharing digital media among multimedia
devices, UPnP was also used in industrial applica-
tions [Gonc¸alves et al., 2014]. Recently, since DPWS
is characterized by large memory requirements and
message overhead, the OPC Foundation developed
the Open Platform Communications - Unified Archi-
tecture (OPC-UA) [Mahnke et al., 2009], oriented for
industrial usage [C
ˆ
andido et al., 2010].
Message-oriented protocols typically focus on
providing asynchronous messaging between dis-
tributed devices, focusing on reliable messaging, in-
cluding Quality of Service (QoS) mechanisms. The
Message Queue Telemetry Transport (MQTT) [Banks
and Gupta, 2014], the Advanced Message Queu-
ing Protocol (AMQP) [Kramer, 2009] and Extensi-
ble Messaging and Presence Protocol (XMPP) are ex-
amples of such protocols. While XMPP is an IETF
standard, MQTT e AMQP are currently standard-
ized by OASIS. AMQP is also a standard of the In-
ternational Standards Organization (ISO) and the In-
ternational Electrotechnical Commission (IEC). Both
MQTT and AMQP were designed as a lightweight
publish-subscribe communication model, where a
broker is responsible for handling and organizing all
communications between the various devices. Mes-
sages are published with specific topics, which can be
subscribed by different devices. AMQP provides a
richer set of messaging scenarios and supports differ-
ent acknowledgment use cases and transactions across
message queues. On the other side, despite Google
stopped supporting XMPP, due the lack of worldwide
support, lately the protocol has re-gained a lot of at-
tention as a communication protocol suitable for IoT
environments.
Resource-oriented protocols refer to protocols fol-
lowing the Representational State Transfer (REST)
architecture, which is widely known within Internet
application, since typically uses the Hypertext Trans-
fer Protocol (HTTP). Because HTTP is not suitable
for IoT environments, considering the resource, band-
width and energy restrictions of devices, the Con-
strained Application Protocol (CoAP) [Shelby et al.,
2014] was introduced by the Internet Engineering
Task Force (IETF), suitable for constrained nodes and
networks. Table 1 provides a comparison between
the different M2M communication protocols identi-
fied, where it is considered that a constrained envi-
ronment is a device with few computational resources
(e.g. embedded device).
Regarding resource discovery, [Datta et al., 2015]
defend that mechanisms for automatic discovery of
resources, their properties and capabilities, as well as
the means to access them, are fundamental to realize
the M2M communication between devices and, con-
sequently, the vision of IoT. Traditional Web resource
discovery models use Web crawlers to discover re-
sources across the Internet. However, according to
[Vandana and Chikkamannur, 2016], these traditional
models are not suited for IoT applications. First, since
most of IoT devices are energy constrained, they re-
main most of the time inactive, until and event trig-
gers them to perform a specific function. In tradi-
tional Web resource discovery models, Web crawlers
can only discover Web servers that are always active.
Second, most of IoT devices are deployed in semi-
closed networks, which have firewalled gateways. On
the other hand, Web crawlers are suitable to discover
resources in a typical Web infrastructure.
Since traditional Web discovery techniques do not
produce accurate resource discovery results for IoT
applications, current trends are based in network as-
sociation, directory domain, peer-to-peer configura-
tion and based on resource semantics. The most
promising approaches refer to protocols specifically
for resource discovery, currently proposed by IETF
working group for Constrained RESTful Environ-
ments (CoRE), which are based on CoAP and Do-
main Name System (DNS), such as CoAP resource
MQTT-RD: A MQTT based Resource Discovery for Machine to Machine Communication
117
Table 1: Comparison Between M2M Communication Protocols.
Protocol Standards
Constrained
Environment
Communication
Model
QoS
Resource
Discovery
Transport
Layer
MQTT
OASIS &
Eclipse Foundation
3 Publish-Subscribe 3 levels 7 TCP
COAP
IETF &
Eclipse Foundation
3
Request-Reply
Resource-Observe
2 levels 3 UDP
AMQP
OASIS &
ISO/IEC
7
Request-Reply
Publish-Subscribe
2 levels 7 TCP
XMPP IETF 7
Request-Reply
Publish-Subscribe
3 levels 3 TCP
OPC-UA ISO/IEC 7
Request-Reply
Publish-Subscribe
7 3
TCP &
UDP
DPWS OASIS 7 Request-Reply 7 3
TCP &
UDP
UPnP ISO/IEC 7 Request-Reply 3 levels 3
TCP &
UDP
discovery, CoAP Resource Directory (RD) [Koster
et al., 2017] and DNS-Service Discovery (DNS-
SD) [Cheshire and Krochmal, 2013].
Regarding CoAP based approaches, CoAP re-
source discovery is a distributed approach, where a
direct query is performed between devices, in order
to discover resources offered by each other. A de-
vice can request the resources hosted by another de-
vice using the CoRE Link Format [Shelby, 2012]. Re-
quests are mostly unicast, but there are the possibility
to issue a multicast request, in the case that the IP ad-
dress or host name of the device to be required are not
known. On the other hand, CoAP RD performs re-
source discovery queries in a centralized manner, us-
ing a directory entity (RD). The RD is defined within
a given domain, i.e., logical groups of IoT devices, in-
stead of the entire Web. RD can be found by IoT de-
vices using IP multicast. Then, each IoT device must
register its resources to the found RD. After registra-
tion, IoT devices can discover other devices and be
discovered, requesting the RD database. Discovery
can occur between IoT devices located in the RD do-
main or may be outside of it.
[Liu et al., 2013] proposed a distributed resource
directory architecture for M2M applications, referred
to as DRD4M, which uses HTTP and CoAP proto-
cols for resource registration and lookup in a peer-to-
peer (P2P) scenario. This work focuses on design-
ing a distributed RD and providing a real prototype.
[Datta et al., 2015] proposed a resource discovery
framework, based on the CoRE Link Format, which
comprises a proxy layer that includes drivers for vari-
ous communication technologies and protocols. [Ko-
vatsch et al., 2014] presents a CoAP framework for
IoT deployments named Californium, which imple-
ments RD functionality in general purpose servers.
[Cirani et al., 2015] propose a Fog node named IoT
Hub, which integrates RD functionality in order to en-
able a truly seamless interaction between IoT devices.
Based on the previous description of the protocols,
MQTT and CoAP are supported by constrained envi-
ronment devices, which allows these protocols to run
almost on any device, regardless of the type of hard-
ware. Among these two protocols, there are some
differences, e.g., CoAP uses UDP while MQTT uses
TCP regarding the transport layer. This difference
in the transport layer gives MQTT the advantage of
being more reliable in package delivery. Also, be-
cause of the higher levels of quality of service, MQTT
guarantees better the delivery of messages in compar-
ison with CoAP. Finally, regarding implementation,
MQTT is easier to integrate new components when
compared to more complex protocols (e.g. OPC-UA).
Although IoT networks rely greatly in the
publisher-subscriber model, as supported by MQTT,
request-reply models are also widely suported,
namelly by protocols such as CoAP. Despite both
are targeted to IoT networks, on contrary to MQTT,
CoAP already supports zero configuration and re-
source discovery mechanisms. This capability al-
lows the automatic configuration / discovery of new
devices (hardcoded IP address not required) and the
search of resources inside the Resource Collection.
For this reason, the proposed protocol (MQTT-RD)
aims to solve the limitations of the MQTT protocol,
referring to resource discovery and zero configura-
tion.
IoTBDS 2019 - 4th International Conference on Internet of Things, Big Data and Security
118
3 PROPOSED APPROACH
This section presents the MQTT-RD approach for re-
source discovery in M2M communication within IoT
applications. The MQTT-RD uses the CoRE RD prin-
ciples, but its functionalities are based on the MQTT
protocol instead of CoAP. Also, the CoRE Link For-
mat is replaced by a new defined JSON file format,
named Resource Collection, which contains a list of
all components in the network. Communication be-
tween devices is based in different message types de-
fined in MQTT.
A typical MQTT communication scenario uses
a topic-based publish-subscribe architecture. There
are: 1) publishers, which are IoT devices that share
data; 2) subscribers, which are IoT devices that re-
ceive shared data by the publishers; 3) brokers, which
are entities that manage topics and message exchange,
and can be implemented within any device in the net-
work, including the publishers and subscribers. When
new data is generated, publishers send messages to
the broker, in order to update a given topic. Every
time a topic is updated, the broker broadcasts the new
data to every subscriber of that topic. Figure 1 repre-
sents a sequence diagram regarding the message ex-
change in the MQTT protocol.
Figure 1: Message exchange in the MQTT protocol.
The CONNECT message is used when a device
requests a connection to the broker, identifying in the
payload the device ID, name and password. The bro-
ker returns a CONNACK message to indicate to the
device success or failure in the connection. The PUB-
LISH message is associated with a topic and is used
by a device to update data within a topic. The mes-
sage payload contains the data to be published. After
receiving a PUBLISH message, the broker returns a
PUBACK message, which means that the message re-
ceived can be brodcasted by all the subscribers. Fac-
ing other levels of QoS, the broker may also return a
PUBREC message, which means that the message re-
ceived can not be yet broadcasted to the subscribers.
In order to subscribe to one or more topics, a SUB-
SCRIBE message can be sent to the broker, identify-
ing the topic to be subscribed and the level of QoS.
After receiving a SUBSCRIBE message, the broker
returns a SUBACK message.
MQTT-RD is based on a distributed architecture
where some devices are responsible for the resource
discovery, i.e., identification of the IoT devices and
MQTT brokers present in the network, these devices
are called Sniffers. There is, at least, one Sniffer rep-
resenting a LAN (i.e. Local Sniffer), the same way
as a RD is defined within a given domain. While Lo-
cal Sniffers are only capable of discovering resources
in a specific LAN, Internet Sniffers can connect with
other Internet Sniffers in other networks using the
Internet, these components are present in Figure 2,
which contains 2 different LANs, where each LAN
contains one Local Sniffer and one Internet Sniffer.
This way, the Sniffer is responsible off managing all
the devices in the network and publications performed
between them, by taking advantage of the MQTT bro-
ker functionalities. For this reason a MQTT bro-
ker is required for communication between compo-
nents, so each Sniffer has an associated MQTT bro-
ker, while Internet Sniffer additionally uses another
MQTT broker for communication over the internet
and that’s why this MQTT broker is hosted at a public
address (a CloudMQTT broker was used). While the
other MQTT devices may choose to have an associ-
ated MQTT broker depending on the traffic they gen-
erate or if they want an M2M communication. The
interaction between Sniffers and devices is also pre-
sented in Figure 2, where the data flow goes from the
devices to the Sniffers, from there the Sniffer forwards
the data to the stakeholders, either locally or remotely.
3.1 MQTT Topics
As mention before, Sniffers take advantage of MQTT
functionalities in order to connect with MQTT de-
vices and other Sniffers present in the network. In this
case, the Sniffer uses several specific topics, accord-
ing to the type of message, namely:
/getlist: This topic is present in every MQTT bro-
ker and is used by Sniffers to update the list of ev-
ery existing Sniffer and MQTT device in the net-
work, i.e., the Resource Collection. In this case, a
MQTT-RD: A MQTT based Resource Discovery for Machine to Machine Communication
119
Figure 2: MQTT-RD Architecture.
new Sniffer or MQTT device that connects to the
network should subscribe to this topic, in order to
get and updated version of the Resource Collec-
tion.
/registdevice: This topic is used to register new
MQTT devices. In this case, the new MQTT de-
vice publish to this topic a self-description docu-
ment. The Sniffer associated to the corresponding
MQTT broker, which have already subscribed to
this topic, uses the self-description document to
add the new MQTT device to the Resource Col-
lection.
/device id/attrs/object id: This topic is used by
MQTT devices to publish data regarding their at-
tributes, such as sensor readings or actuator state.
Each device attribute is associated with one of
these topics, where device id represents the ID
used by the MQTT device in the registration in
the Sniffer and the object id represents the ID of
the considered attribute.
/sniffercommunication: This topic is used for
message exchange between Sniffers, in order to
update the Resource Collection between Sniffers
in the registration and removal of Sniffers and
MQTT devices. Also, this topic can be used by
Sniffers to detect if there are anomalies regarding
other Sniffers.
3.2 Resource Collection
The Resource Collection is a JSON file format that
contains information regarding every Sniffer and
MQTT device in the network. Every Sniffer contains
a copy of the Resource Collection, which is updated
regularly in order to keep track of existing MQTT de-
vices and other Sniffers in the network, considering
the registration and removal of Sniffers and MQTT
devices in the network. Figure 3 represents the struc-
ture of the Resource Collection file.
The file is structured by the characterization of
Sniffers. In this case, each Sniffer is represented by
an unique ID, a type (in order to differentiate between
local or Internet), the network location of the MQTT
broker associated (local IP address and port) and the
MQTT broker that enables remote connections with
other Sniffers (public IP address, port, username and
password), LAN identification and multicast IP, and
a list of all MQTT devices registered in that Sniffer,
each one containing a device ID, attributes (associ-
ated with topics, such as sensor measurements and
actuator state) and device type, i.e., with or without
MQTT broker associated. If a MQTT broker is asso-
ciated, their parameters should be included (local IP
address and port). Otherwise, parameters regarding
the MQTT broker of the Sniffer should be considered.
3.3 Resource Registration
Before registering resources MQTT devices and Snif-
fers should know the IP address of the Sniffer to which
they will join and for this are used multicast IP ad-
dresses. In this case, when joining the network, every
MQTT device or Sniffer connects to the same multi-
cast IP address. In case of one MQTT device or Snif-
fer sends a ping message to that IP, every other MQTT
device or Sniffer connected to it are able to receive and
respond to the ping message. Through this process, it
is possible to add to the network new devices with or
without MQTT broker and new Sniffers, in the case
of devices with MQTT broker it is also necessary for
Sniffer to subscribe to all MQTT broker topics.
IoTBDS 2019 - 4th International Conference on Internet of Things, Big Data and Security
120
Figure 3: Resource Collection Information Model.
From this point forward, the MQTT device is able
to register in a Sniffer, using the /registdevice topic, as
shown in Figure 4. On the other hand, Sniffers should
subscribe to this topic, in order to add MQTT devices
in the Resource Collection. In this case, a Sniffer
can subscribe to the /registdevice topic provided by
their own MQTT brokers or the ones associated with
MQTT devices, as previously mentioned. To update
the Resource Collection on the remaining Sniffers, a
message is sent to every Sniffers present on the net-
work, this message is associated with the /sniffercom-
munication topic, as reported in Figure 4. To update
the Resource Collection on all LANs, Internet Sniffer
must forward the register message to the remaining
Internet Sniffers in order to update the data on their
LANs.
After registration, every Sniffer gets the Resource
Collection with updated data regarding existing Snif-
fers and MQTT devices in the network. The Resource
Collection allows Sniffers and MQTT devices to learn
the location of every component in the network and
the attributes of each MQTT device. With this ap-
proach, the Resource Collection simplifies the opera-
tions of MQTT devices regarding topic subscription.
Thus, as shown in Figure 4, after searching at the
Resource Collection for the resource, the MQTT de-
vice can subscribe to this resource through the /de-
vice id/attrs/object id topic.
3.4 Device Anomaly Detection
The MQTT-RD provides a mechanism to detect
anomalies in Sniffers, in order to reconfigure the net-
work accordingly. In this case, in order to evaluate
the malfunction of a Sniffer, two methods were im-
plemented, namely 1) the exchange of alive messages
and 2) detection of connectivity lost with the MQTT
broker.
Exchange of alive messages consists in a mecha-
nism implemented in the Sniffers, where a ping mes-
sage is broadcasted regularly. Within a give time pe-
riod, if a ping message is not received by a given
Sniffer that was present in the network, a request to
remove that Sniffer from the Resource Collection is
issued to all Sniffers in the network, as illustrated in
Figure 4.
Figure 4: Message exchange in the MQTT-RD protocol.
On the other end, evaluate malfunction Sniffers
is possible by identifying the lost of connection of a
given Sniffer to the respective MQTT broker. If the
Sniffer cannot reconnect to the MQTT broker after a
couple of trials, then a request to remove that Sniffer
MQTT-RD: A MQTT based Resource Discovery for Machine to Machine Communication
121
from the Resource Collection is issued to all Sniffers
in the network.
4 TESTS AND RESULTS
This section details the implemented testbed to assess
the concept and evaluate the technological constraints
od the proposed protocol. In this case, the MQTT-RD
was tested in a laboratory environment, where it was
evaluated the Sniffer component and overall network
functionality regarding scalability, i.e., number of de-
vices available and message exchange.
4.1 Testbed
For proof of concept and evaluation, a simple version
of the system architecture represented in Figure 2 was
implemented. In this case, it was considered one net-
work, containing a Sniffer associated with a respective
MQTT broker. Simulated MQTT devices are intro-
duced to the network, where each of these devices is
associated with the MQTT broker in the Sniffer. Fig-
ure 5 represents the implemented testbed.
Figure 5: Testbed Architecture.
The local network was setup using a network
switch, where both Sniffer and MQTT device com-
ponents were connected via Ethernet cable. In this
case, a machine (Intel i7 processor with 16GB RAM)
was used to execute the Sniffer component and cor-
responding MQTT broker, while another machine
(ARM Cortex-A7 processor with 1GB RAM) was
used to execute a routine that simulates MQTT de-
vices in intervals of 10 seconds. Each simulated de-
vice has only one attribute and it publish updates in
the respective topic with a frequency of 1Hz. Every
time a new MQTT device is created, it connects to the
MQTT broker and registers in the Sniffer, in order to
start publishing in the respective topic and subscribe
to every topic of the existing MQTT devices in the
network. For this, the recently registered MQTT de-
vice requests the Sniffer for the list of existing devices
and topics, in order to subscribe to all of them.
4.2 Solution Evaluation
Evaluating the proposed solution consisted in moni-
toring the overall network traffic and Sniffer response
while the implemented proof of concept executes as
described earlier. In this case, every existing topic
in the network was monitored, by using the corre-
sponding Publish and Subscribe messages sent be-
tween MQTT devices and MQTT broker. Three dif-
ferent metrics were used to evaluate the robustness of
the solution, namely: 1) the overall message drop in
the network; 2) time of travel of Publish messages
from MQTT device to broker; and 3) delay between
receiving Publish messages and issuing correspond-
ing Subscribe messages to topic subscribers. Wire-
shark was used to monitor network traffic, by analyz-
ing MQTT messages exchanged in the network. This
way, 8 packet captures were obtained with an increas-
ing number of devices between 5 and 40. For each of
the packet captures, an average value was calculated
in any of the metrics analyzed.
For overall message drop in the network, Wire-
shark was used to monitor several MQTT messages
exchanged between publisher MQTT devices, MQTT
broker and subscribers MQTT devices, as represented
in Figure 1. Figure 6 represents the results of MQTT
message drop in the network, by identifying the deliv-
ery rate of publication messages sent by the devices to
the MQTT broker (Publish messages) and the deliv-
ery rate of messages forwarded by the MQTT broker
to the devices (Subscribe messages).
Figure 6: Yield on Package Delivery.
After the inspection of Figure 6, it is concluded
that for a low number of devices, the message deliv-
ery rate is around 80-90%, which is acceptable in this
case because there is a bidirectional communication
with high packet traffic between the devices and the
MQTT broker. The packet loss value also includes
the packets that have a significant delay, i.e. packets
IoTBDS 2019 - 4th International Conference on Internet of Things, Big Data and Security
122
that are not within the time interval, consequently the
value of the losses increases a little. When the number
of devices exceeds 20, there is a drop in the message
delivery rate, more specifically in the Subscribe mes-
sages. This break occurs because the MQTT broker
becomes saturated and is no longer able to forward
messages.
Figure 7 represents the time of travel of Publish
messages and the delay between the MQTT broker
receiving Publish messages and issuing correspond-
ing Subscribe messages to topic subscribers (MQTT
broker processing delay). The time of travel of Pub-
lish messages from MQTT device to broker was de-
termined by calculating the difference between the in-
stance when MQTT devices send Publish messages
and the instance when the MQTT broker receives
them (network delay).
In this case, the number of Subscribe messages of
a given topic increases proportionally with the num-
ber of MQTT devices in the network, because every
new MQTT device in the network subscribes every
topic already existing. This constant subscription of
topics generates a high traffic in the network, with the
increasing number of devices.
Figure 7: Delays in Delivering Messages.
For both network delay and MQTT broker pro-
cessing time, their time delays tend to increase signif-
icantly when the number of devices exceeds 20. For
a low number of devices the network delays range is
between 10 and 60 milliseconds, which for a network
with high exchange of messages is normal. Another
important point is the comparison of the processing
time with the network delay, in this case the process-
ing time is lower than the network delay, which is a
good indicator of the correct operation of the Sniffer.
5 CONCLUSION AND FUTURE
WORK
As mentioned earlier, the zero configuration and re-
source directory mechanisms allow an easy integra-
tion of new devices into large networks. Some of the
existing protocols already have these features, such as
CoAP, OPC-UA or XMPP. By integrating these func-
tionalities into a MQTT based protocol allows MQTT
main advantages to be used in networks with a large
number of devices, where the devices are constantly
replaced. Therefore the networks become more sta-
ble, meaning less time lost in maintenance and con-
figuration of new components.
MQTT-RD has some of the characteristics of
MQTT, which distinguish it from other protocols,
such as its easy integration into devices and the ability
to run on components with low computational power.
As improvements to MQTT, MQTT-RD allows the
automatic configuration of new devices (zero config-
uration), the updated registration of the topics of each
device (resource directory) and the search of topics by
each device (resource discovery). These features en-
able MQTT-RD to be versatile, complete and an easy-
to-use protocol.
On the other hand, as disadvantages, MQTT-RD,
such as MQTT, is not as robust as OPC-UA (regard-
ing industrial applications), since it is a less com-
plex protocol and only supports the publish-subscribe
communication model. MQTT-RD has other handi-
caps that make it difficult to use, such as not being
available in a programming framework and increasing
MQTT overheads. By means of the experimental re-
sults, it is demonstrated that for an increasing number
of devices the Sniffer has a high network traffic and a
high processing load of the MQTT broker. To reduce
the load on the Sniffer processing, it would be ideal to
distribute the devices uniformly across all the Sniffers
present in the network, in order to have a minimum
number of devices per Sniffer.
Based on the disadvantages presented, future work
focuses on the development of a framework, in such a
way MQTT-RD can be used in other application sce-
narios and later compared in a more detailed way with
other protocols, such as the OPC-UA. After the devel-
opment and testing of the framework, another goal is
to apply this solution in a real environment, in order
to validate the application. In general, the MQTT-RD
protocol can be used in home or industrial networks,
as it provides bidirectional channels, which allows the
subscription and publication of topics / messages and
the discovery of resources (resource directory) and
endpoints (zero configuration) in a typical IoT envi-
ronment.
MQTT-RD: A MQTT based Resource Discovery for Machine to Machine Communication
123
REFERENCES
Banks, A. and Gupta, R. (2014). Mqtt version 3.1. 1. OASIS
standard, 29.
Boswarthick, D. and Mulligan, U. (2009). M2m activities
in etsi. Presentation Report.
C
ˆ
andido, G., Jammes, F., de Oliveira, J. B., and Colombo,
A. W. (2010). Soa at device level in the industrial do-
main: Assessment of opc ua and dpws specifications.
In Industrial Informatics (INDIN), 2010 8th IEEE In-
ternational Conference on, pages 598–603. IEEE.
Chang, K., Soong, A., Tseng, M., and Xiang, Z. (2011).
Global wireless machine-to-machine standardization.
IEEE Internet Computing, 15(2):64–69.
Cheshire, S. and Krochmal, M. (2013). Dns-based service
discovery. Technical report.
Cirani, S., Ferrari, G., Iotti, N., and Picone, M. (2015).
The iot hub: a fog node for seamless manage-
ment of heterogeneous connected smart objects. In
Sensing, Communication, and Networking-Workshops
(SECON Workshops), 2015 12th Annual IEEE Inter-
national Conference on, pages 1–6. IEEE.
Cucinotta, T., Mancina, A., Anastasi, G. F., Lipari, G.,
Mangeruca, L., Checcozzo, R., and Rusin
`
a, F. (2009).
A real-time service-oriented architecture for industrial
automation. IEEE Transactions on industrial infor-
matics, 5(3):267–277.
Datta, S. K. and Bonnet, C. (2015). A lightweight
framework for efficient m2m device management in
onem2m architecture. In Recent Advances in Internet
of Things (RIoT), 2015 International Conference on,
pages 1–6. IEEE.
Datta, S. K., Da Costa, R. P. F., and Bonnet, C. (2015). Re-
source discovery in internet of things: Current trends
and future standardization aspects. In Internet of
Things (WF-IoT), 2015 IEEE 2nd World Forum on,
pages 542–547. IEEE.
Driscoll, D., Mensch, A., Nixon, T., and Regnier, A. (2009).
Devices profile for web services version 1.1. OASIS
standard, 1(4).
Fysarakis, K., Askoxylakis, I., Soultatos, O., Papaefs-
tathiou, I., Manifavas, C., and Katos, V. (2016).
Which iot protocol? comparing standardized ap-
proaches over a common m2m application. In Global
Communications Conference (GLOBECOM), 2016
IEEE, pages 1–7. IEEE.
Galeti
´
c, V., Boji
´
c, I., Ku
ˇ
sek, M., Je
ˇ
zi
´
c, G., De
ˇ
si
´
c, S., and
Huljeni
´
c, D. (2011). Basic principles of machine-to-
machine communication and its impact on telecom-
munications industry. In MIPRO, 2011 Proceedings
of the 34th International Convention, pages 380–385.
IEEE.
Gonc¸alves, G., Reis, J., Pinto, R., Alves, M., and Correia,
J. (2014). A step forward on intelligent factories: A
smart sensor-oriented approach. In Proceedings of
the 2014 IEEE Emerging Technology and Factory Au-
tomation (ETFA), pages 1–8.
Gubbi, J., Buyya, R., Marusic, S., and Palaniswami, M.
(2013). Internet of things (iot): A vision, architectural
elements, and future directions. Future Generation
Computer Systems, 29(7):1645–1660.
Hellinger, A. and Seeger, H. (2011). Cyber-physical sys-
tems. driving force for innovation in mobility, health,
energy and production. Acatech Position Paper, Na-
tional Academy of Science and Engineering.
Jeronimo, M. and Weast, J. (2003). Upnp design by exam-
ple.
Koster, M., Shelby, Z., Bormann, C., and Stok, P. V. d.
(2017). Core resource directory.
Kovatsch, M., Lanter, M., and Shelby, Z. (2014). Cali-
fornium: Scalable cloud services for the internet of
things with coap. In Internet of Things (IOT), 2014
International Conference on the, pages 1–6. IEEE.
Kramer, J. (2009). Advanced message queuing protocol
(amqp). Linux Journal, 2009(187):3.
Kunz, A., Kim, H., Kim, L., and Husain, S. S. (2012). Ma-
chine type communications in 3gpp: from release 10
to release 12. In Globecom Workshops (GC Wkshps),
2012 IEEE, pages 1747–1752. IEEE.
Lee, E. A. (2008). Cyber physical systems: Design chal-
lenges. In Object Oriented Real-Time Distributed
Computing (ISORC), 2008 11th IEEE International
Symposium on, pages 363–369. IEEE.
Liu, M., Leppanen, T., Harjula, E., Ou, Z., Ramalingam, A.,
Ylianttila, M., and Ojala, T. (2013). Distributed re-
source directory architecture in machine-to-machine
communications. In Wireless and Mobile Comput-
ing, Networking and Communications (WiMob), 2013
IEEE 9th International Conference on, pages 319–
324. IEEE.
Mahnke, W., Leitner, S.-H., and Damm, M. (2009). OPC
unified architecture. Springer Science & Business
Media.
Shelby, Z. (2012). Core link format, draft-ietf-core-link-
format-11. Technical report, Internet draft, IETF 2012
(in progress).
Shelby, Z., Hartke, K., and Bormann, C. (2014). The con-
strained application protocol (coap). Technical report.
Song, J., Kunz, A., Schmidt, M., and Szczytowski, P.
(2014). Connecting and managing m2m devices in the
future internet. Mobile Networks and Applications,
19(1):4–17.
Vandana, C. and Chikkamannur, A. A. (2016). Study of re-
source discovery trends in internet of things (iot). In-
ternational Journal of Advanced Networking and Ap-
plications, 8(3):3084.
IoTBDS 2019 - 4th International Conference on Internet of Things, Big Data and Security
124