germa

Evaluation of Discovery Services for the Internet

of
Sreehari Buddappagari Jayapal Gowdu and Gaurav Gubbi Suresha
Communication Networks Group
Ilmenau University of Technology
P. O. Box 100565, D-98684 Ilmenau, Germany
Email: { sreehari.jayapal, gaurav.gubbi-suresha }@tu-ilmenau.de

Abstract In our paper we consider the problem

of Discovery Services in the Internet of Things(IoT).
We divide the problem into two abstraction levels from
our architecture of the IoT - higher level and lower
level Discovery Services. At the higher level we make a
comparitive study of the state-of-the-art architectures and
at the lower level we study efficient node and service
discovery mechanisms. We also perform a comparitive
study of the simulation tools for IoT. Then we perform
simulations for a typical scenario in order to evaluate the
delay performance in the lower level Discovery Service.
Index TermsInternet of Things, Directory Services, Simulation Tools, Discovery Services

I. I NTRODUCTION
Over the past decade there has been significant research
interest in the Future Internet as society is moving towards the
so-called paradigm The Internet of Things(IoT).The concept
of IoT has grown into multiple dimensions, encompassing
intelligent sensor networks and distributed smart devices that
are globally connected via the Internet. It is a development
that combines information service and intelligence to control
and co-ordinate very large number of different objects, where
the objects become part of the Internet. The IoT proposes
connectivity for anyone from any time, any place for
anything. It is estimated that 50 billion of devices will
be connected to the Internet by 2020, this demands a high
scalability requirement to manage resources and services. In
addition, such a network should be dynamically adapted with
the inclusion of new devices and changes of the existing ones.
Finding devices and providing the required services is
an essential aspect for a comprehensive Internet of Things.
This calls for the necessity of a suitable and convenient
infrastructure that allows resolution, look-up and discovery
of IoT devices and Services and also a proper abstraction
level needs to be provided to the application programmers.
Therefore,we came up with an architecture of IoT as shown
in fig 1. According to the figure we have two main services
-Directory Services(DrS) and Discovery Services (DS).
1) DrS - Each IoT device has its own characteristics and in
order to search for available capabilities of individual devices,

a directory service might be useful. All devices should be registered in this directory which then allows to include new devices on their arrival. The DrS is defined as a service that stores
collections of bindings between names and attributes and that
looks up entries that match attribute-based specifications [6].
Directory Services are sometimes called yellow pages in an
analogy with the traditional types of telephone directory.A
directory service returns the sets of attributes of any objects
found to match some specified attributes. For example, the
request TelephoneNumber = 05166737374 might return Name
= Alex, TelephoneNumber = 05166737374, emailAddress =
alex@ilmenau.de, .... The client may specify that only a subset
of the attributes is of interest for example, just the name of
matching objects. A drS thus maintains lists . It could be an
exhaustive list of data, that is either centralized or distributed
over several nodes.In the fig, we have the Event Repository
(ER) which could be the DrS or could be backed up by a DrS
that could have more features, like adding intelligence to the
network, etc.

Fig. 1.

Architecture of IoT

2) DS - A DS on the other hand is used to specify how

we find the lists (DrS) or parts of lists and services that is of
interest to us. DS is an aid to build a Drs, but not a DrS itself.
In our paper, we focus on the DS in specific as we consider
it to be the crucial aspect of our architecture. With our research
interest firmly estabished, we continue to delve deeper into this

area of IoT. In our architecture in fig.1, we provide Discovery

Services on two abstraction levels, the higher level (client
level) which includes the DS that enables the client application
to discover a particular device or service of its interest using
the DrS and , the lower level, the level of the Wireless Sensor
Networks(WSN)and includes the problem of node and service
discovery mechanisms and its subsequent registration in the
DrS .
Apropos, we identified problems with respect to each level
of DS. At the higher level, there is a lack of a comprehensive
study of the state-of the art architectures for implemeting an
efficient DS and at the lower level we consider the problem
of discovery in a dynamic wireless sensor network in which
devices are liable to connect and disconnect unpredictably
. Therefore, in order to formulate solutions to these, we
make a comparitive study of the present Discovery service
architectures in IoT. At the lower level, we analyze and
evaluate mechanisms for node and service discovery. Both are
described in Section 2. Subsequently, in order to simulate the
whole system, we need to build the client discovery problem,
set up the central DS network and also the WSN at lower level
as established in fig., This calls for the necessity of a detailed
study of Network Simulators for IoT, which is provided in
section 3. In section 4, we discuss our simulations and results.
In the last section, we give our conclusions and an outline for
future work.
II. H IGHER L EVEL D ISCOVERY S ERVICES
A. Comparison of the state-of the-art DS Architectures
We studied the existing state-o-the-art DS in the IoT architectures thoroughly. A detailed description of the existing
architectures is beyond the scope and interest of our paper,
and can be found in [8]. However, we have gathered the key
points of our findings into Table.I.

Fig. 2.

A centralized Discovery Service Architecture [8]

The EPCGlobal(Electronic Product code), Affilias,

ID@URI(Uniform Resource Identifier) follow this model.[8]
Another contrasting architecture is distributed P2P DS
that is shown in the fig.3. Peer-to-Peer Systems (P2P) are
highly distributed alternatives to classical network service
architectures and can be considered to be a paradigm shift
from the classical clientserver architecture to a new paradigm
with a roughly equal distribution of responsibility and load
among peers. An implementation of P2P DS architecture uses
Distributed Hash Tables (DHT). These offer high robustness to
faults, avoid single points of failures (e.g., they have no special
root nodes like Domain Name System servers), and distribute
responsibility and load among participants in a systematic way
by means of a prearranged topological overlay structure. Since
DHTs offer fundamental lookup functionality of arbitrary
device identifiers to nearly arbitrary answer documents (e.g.,
one or multiple node addresses), they can also constitute a
foundation for highly scalable and robust global DS.

B. Overview of two main architectures

For convenience, we organised these architectures into two
main approaches,a centralized one and a decentralised Peer to
Peer (P2P) service. These are described in this subsection.
A centralized DS architecture is depicted in Fig.2. It follows
the traditional Client-Server paradigm. The following steps
describe the process of data exchange between the client, the
DS, and corresponding Event Repository(ER): In step (0ab), the device owners notify the DS about events that were
recently added to their ER. (1) The client wants to get data
about all events that are related to a given device and issues a
corresponding query to the DS, receiving the references to ER
that hold any events related to the query. Then, (2) the client
sends these references to the to the Domain Name Systems
(DNS), which resolves the references into IP addresses. Using
these IP addresses, (3a-b) the client queries the ER that can
provide data about the corresponding device. Core Services are
responsible for interconnection and interoperability between
different DSs and clients, as shown in step(5). They provide
the central support for the global discovery system.

Fig. 3.

P2P Discovery Service Architecture [8]

Once a device Discovery Mechanism has updated an event

involving a node, corresponding data can be published using
an Event Repository (0a-c). To enable clients to discover
the nodes and services, a Local Publish Application (here
Event Repository) uses a Local Peer Client to insert a pair
(key=h(EPC), value=node address document) into the DHT

Name of Architecture

Features

Demerits

EPC Global (Electronic

Product Code)

Core services provided by EPCglobal

Lack of detailed architecture limited to a supply

chain and for which client applications are preconfigured with entry points of the corresponding instance
of a DS

Affilias

Afilias DS utilize an open, Web services protocol

called the Extensible Supply-chain Discovery Service (ESDS) A clear and mature implementation of
EPCGlobal

Same as above

ID@URI(Identity@Uniform
Resource Identifier)

Object Agent, the only one source of data has to be

discovered

Standardization Issues

P2P-DHT (Peer to Peer

using Distributed Hash
Tables)

Self-organisation, flexible, load-balancing,no bottlenecks while carrying multiple data update and search
operations, secure

Localizing failures Difficult

TABLE I
C OMPARISON O F DS A RCHITECTURES

system, where h denounces a (cryptographic) hash function.

A Client Query Application, which wants to discover data on
a given node, can use the DHT Lookup Interface via its own
Local Peer Client to get the IP addresses of the corresponding
Event Repositories (1) and retrieve all data stored for an EPC
(2).
The three centralized architectures share the same advantages and disadvantages. Data manangement is easy because
the files are in one location. Query requests can be served
faster. Failures can be localized and errors can be managed
efficiently. But these are very expensive and require a lot
of maintainance. A failure , though can be localized, can
break down or cause heavy delay as the server constitutes a
single point of failure. Server downtime could accumulate to
high costs. On the other hand , a P2P model offers a more
flexible and scalable solution. There is no single point of
failure, which means, if one peer breaks down, the rest of
the peers are still able to communicate. Peer-to-Peer provides
the opportunity to take advantage of unused resources such
as processing power for computations and storage capacity.
In Client-Server architectures, the centralized system bears
the majority of the cost of the system. Peer-to-Peer allows
to prevent bottleneck such as traffic overload using a central
server architecture, because P2P network can distribute data
and balance request across the system without using a central
server. There is better scalability due to a lack of centralized
control and because most peers interact with each other.
Security is a major concern, which can be solved using DHT
approach. Meanwhile, one of the disadvantages is the difficulty
in localizing failures. Since our main concern is to build a
highly scalable and flexible DS, we prefer a P2P architecture
as the advantages far outweight the disadvantages. However,
we keep open the possibility of building a hybrid architecture

using the above two approaches in our future work.

C. Lower Level Discovery Service Mechanisms
At this level, we have wireless sensor networks(WSN) that
are composed of one or more source nodes and a sink node.
The sink nodes constitute the event repositories / directory
services that are connected through an overlay distributed peer
to peer network.
Initially the source nodes need to be detected. After detection/discovery of a new sensor node, the sink node inititates
the registration procedure, communicating directly with this
node. Three approaches for discovery have been proposed
in [11] YouCatchMe, ICatchYou and Some1CatchMe. In the
YouCatchMe paradigm the sink node periodically broadcasts
announcements, which are received by a new source node
on arrival. In the ICatchYou node/service discovery paradigm
when a sensor node is deployed or arrives at a new network,
starts sending requests for registration. Some1CatchMe uses
RFID to discover the new nodes within the network range.
Upon arrival at a new network, nodes equipped with a passive
RFID tag are discovered by a local RFID reader when placed
within a range of few meters, which is connected to the local
sink node.
Another way of classifying the node discovery are [12]Direct-Discovery Algorithms in which nodes discovers their
neighbors only when they hear transmission from that neighbor and Gossip-Based Discovery Algorithms in which nodes
gossip about each others location information to speed up
discovery.
The three paradigms of YouCatchMe, ICatchYou and
Some1CatchMe seem to provide a scalable and efficient discovery mechanism and hence we choose to evaluate these in
the simulations. In the next section, we provide a comprehensive study of the simulation tools for IoT.

Simulator

Platform

Features

NS-3

C++

1. Alignment with realworld interfaces, supports a realtime scheduler

and emphasizes on the reuse of real application and kernel code 2.
Backward incompatible and do not have all models as its preceeder.

OmNet++

C++

1.can support MAC protocols and some localized protocols in WSN 2.simulate power
consumptions and channel controls 3. limited available protocols

TOSSIM(TinyOS
Simulator)

NesC

1.can support thousands of nodes simulation 2.can emulate radio models and code
executions 3.only emulate homogeneous applications 4.have to use PowerTOSSIM to
simulate power consumption

COOJA

Java

1.Concerning both simulated hardware and software 2.Largerscale behavior protocols

and algorithms can be observed 3.Supports a limited number of simultaneous node types
4. Not extremely efficient.

Castalia

C++

1. Highly tunable MAC protocol and a flexible parametric physical process model 2.
Not useful if one would like to test code compiled for a specific sensor node platform.
TABLE II
C OMPARISON O F S IMULATION T OOLS

III. E VALUATION OF S IMULATION T OOLS

Wireless sensor networks(WSN) are one of the most
actively developing areas in network research field, to reduce
the cost and time of deployment process, simulation of the
network is a preferred task before testing it with the real
hardware. In this section we review simulation tools to find
its suitability for modeling and simulating and compare it in
Table.II.
1) NS-3 [2]- The NS-3 is an open sourced discreteevent network simulator for Internet systems, focused
primarily for research and educational purpose. It is
written in C++ with Python scripting interface. It allows
researchers to study Internet protocols and large scale
systems in a controlled environment. NS-3 provides
Peer To-Peer link and shared link with CSMA also
provides routing ARP and can run real implementation
of application. NS-3 has capabilities such as handling
multiple interfaces on nodes correctly and efficiently
handles large scale networks but as the number of nodes
increase the computational time also increases.
2) OMNeT++ [3]- OMNeT++ is an open source component
based discrete event network simulator. This mainly
supports standard wired and wireless IP communication
networks. OMNeT++ uses building blocks known as
modules to their simulator. An OMNeT++ model consists of Modules which are connected in a hierarchical
nested fashion, where each module can contain their
own modules and communicate by passing messages.
Modules can be classified as simple and compound, simple modules are used to define algorithms which make
up the bottom of the hierarchy and compound modules

are a collection of simple modules. It has a powerful

GUI which makes tracing and debugging much easier
than compared to other simulator for WSN. OMNeT++
can support MAC protocols along with other localized
WSN protocols, simulation of channel control in WSN is
also possible. But the number of protocols supported is
limited. As the researching individual develop separate
models, compatibility issues rise as it is difficult to
combine models. OMNeT++ has better computational
time, CPU utilization and memory usages than compared
to NS-3, when the number of nodes increases [5].
3) TOSSIM [4]-TinyOS Simulator Tiny OS[5] is an open
source operating system specially developed for the
wireless embedded sensor networks. TinyOS release
includes a simulator called TOSSIM. TOSSIM is an
emulator rather than a simulator, Emulators are different
from simulator in that they run actual application code.
TOSSIM is a simple but a powerful emulator for WSN.
Each node can be evaluated under perfect transmission
conditions, and using this emulator can capture the hidden terminal problems. As a specific network emulator,
TOSSIM can support thousands of nodes simulation. Besides network, TOSSIM can emulate radio models and
code executions. This emulator may be provided more
precise simulation result at component levels because
of compiling directly to native codes. TOSSIM allows
the TinyOS to be flexible, power efficient, accurate and
handle large number of nodes, but does not work well
with long uninterrupted codes and requires additional
extension called PowerTOSSIM for issues related to the
power consumtion in WSN.
4) COOJA- Contiki Os Java- COOJA [10] is a simulator

for Contiki [1] sensor node operating system. It combines low level simulation of sensor node hardware and
simulation of high level behavior in a single simulation.
COOJA is flexible and extensible in that all levels
of the system can be altered or replaced. COOJA is
scripted in Java. It is primarily a code level simulator
for networks consisting of nodes running Contiki OS. It
can simulate sensor networks simultaneously at different
levels, including the operating system level and the
application level. But the simulator has relatively low
efficiency, simulating many nodes with several interfaces
each require a lot of calculations and the simulator has
to be restarted frequently if the number of nodes exceeds
the allowable [9].
5) Castalia [?]- Castalia is a application level simulator
for WSN based on OMNeT++. It is highly parametric
and can be used to simulate wide range of platforms.
In this, sensor nodes are implemented as compounds
of modules, consisting of sub-modules that represent
network stack layers, application and sensor. Castalia
is developed in C++. It has a high tunable Medium Access Control protocol and a flexible parametric physical
process model, which help Castalia represent different
sensing devices and consider device noise and bias.
But Castalia is not sensor platform specific because
it is meant to provide a generic reliable and realistic
framework for the first order validation of an algorithm
before moving to implementation on a specific sensor
platform. Castalia is not useful if one would like to test
code compiled for a specific sensor node platform [7].
Due to short time frame of our project, we choose to
perform simulations in NS-3 among the above five reviewed
simulation tools as it had clearer documentation and more
online support. However, we keep other options open for the
future.
IV. S IMULATIONS AND R ESULTS
We evaluated the performance of the Discovery Services
by considering a scenario that is based on the lower level DS
Mechanisms. The scenario can be cosiderd in a big factory
that monitors the product status by smart sensors (source
nodes) attached to them. Each sector of the factory could have
a sink node that acts as the ER or the DrS. When a new
product comes in the area of coverage of a sink node, the new
source is discovered. After this, a direct comunication link
is established to this node to initiate the registration process.
In our simulations, we considered a network of 25 registered
source nodes randomly spread within the range of the sink. We
evaluated the performance of YouCatchMe discovery mechanism by computing the delay for initial discovery whenever
a new source node is added into the WSN. The delay is the
total time taken for the first broadcast packet to reach the
new source node and its acknowledgement reaching the sink
node. The delay was also computed for varying distances of
the new source node from the sink node. As Shown in fig.4,
The simulation results returned a constant delay for all the

distances throughout the range of the sink node. This is evident

from the graph that we plotted from our results. We thus
conclude that the discovery mechanism has a uniform delay
performance over the range of the sink node. Therefore, we
learnt that in the YouCatchMe discovery mechanism delay is
not a critical metric to compute the performance as it remains
constant over all the distances from the sink node. To

Fig. 4.

A graph of Total Delay vs Distance from Sink node

V. C ONCLUSIONS AND F UTURE W ORK

In our paper, we compared the existing DS Architectures
for IoT and concluded to prefer P2P model over others. We
studied the various DS mechanisms at the lower level and
simulated the YouCatchMe discovery paradigm. The Simulations were carried out in NS3 , which we decided upon after
a detailed study of simulation tools. The delay performance
of the simulated DS mechanism did not show any variations
over the range of the sink node and hence we conclude that
delay is not a critical metric. However, in future we intend to
simulate more scenarios and evaluate the performance of the
DS mechanisms at both lower abstraction level taking various
parameters into account. We also hope to extend it to test
the P2P architecture at the higher level and even hopefully
investigate the possibility of a hybrid P2P architecture for
Discovery Services in the IoT.
VI. ACKNOWLEDGEMENTS
We would like to thank our supervisors, Prof.Jochen Seitz
and Silvia Krug, for their unwavering guidance in this academic endeavour.
R EFERENCES
[1] Contiki, URL::http://www.contiki-os.org/index.html.
[2] The ns3 development team and the ns3 network simulator., URL:http:
//www.nsnam.org.
[3] Omnet++ discrete event simulation system,
URL::http://www.
omnetpp.org.
[4] Tinyos simulator, URL::http://docs.tinyos.net/index.php/TOSSIM.
[5] Sardar M Bilalb, Mazliza Othmana, et al., A performance comparison of network simulators for wireless networks, arXiv preprint
arXiv:1307.4129, 2013.
[6] George F. Coulouris and Jean Dollimore, Distributed Systems: Concepts
and Design, Addison-Wesley Longman Publishing Co., Inc., Boston,
MA, USA, 1988.

[7] E Egea-Lopez, J Vales-Alonso, AS Martinez-Sala, P Pavon-Marino, and

J Garca-Haro, Simulation tools for wireless sensor networks, in
Summer Simulation Multiconference-SPECTS, vol. 2005, 2005.
[8] S. Evdokimov, B. Fabian, S. Kunz, and N. Schoenemann, Comparison
of discovery service architectures for the internet of things, in Sensor
Networks, Ubiquitous, and Trustworthy Computing (SUTC), 2010 IEEE
International Conference on, pp. 237244, June 2010.
[9] M.N. Jambli, H. Lenando, K. Zen, S.M. Suhaili, and A Tully, Simulation tools for mobile ad-hoc sensor networks: A state-of-the-art survey,
in Advanced Computer Science Applications and Technologies (ACSAT),
2012 International Conference on, pp. 16, Nov 2012.
[10] Fredrik Osterlind, Adam Dunkels, Joakim Eriksson, Niclas Finne, and
Thiemo Voigt, Cross-level sensor network simulation with cooja, in
Local Computer Networks, Proceedings 2006 31st IEEE Conference on,
pp. 641648. IEEE, 2006.
[11] Ricardo Silva, Valderi R.Q. Leithardt, Jorge Sa Silva, Claudio Geyer,
Joel Rodrigues, and Fernando Boavida, A comparison of approaches
to node and service discovery in 6lowpan wireless sensor networks,
in Proceedings of the 5th ACM Symposium on QoS and Security for
Wireless and Mobile Networks, Q2SWinet 09, pp. 4449, New York,
NY, USA, 2009. ACM.
[12] S. Vasudevan, J. Kurose, and D. Towsley, On neighbor discovery in
wireless networks with directional antennas, in INFOCOM 2005. 24th
Annual Joint Conference of the IEEE Computer and Communications
Societies. Proceedings IEEE, vol. 4, pp. 25022512 vol. 4, March 2005.