Wireless Pers Commun (2013) 73:1455–1476

DOI 10.1007/s11277-013-1260-3

ODSA: Chord-Based Object Discovery Service

Architecture for the Internet of Things

De-Gang Xu · Lei-Hua Qin · Jong-Hyuk Park ·

Jing-Li Zhou

Published online: 15 June 2013

© Springer Science+Business Media New York 2013

Abstract In the emerging Internet of Things (IOT), as a means to fulfill item-level lookup,
lookup service or discovery service plays a critical role. However, existing lookup service and
discovery service of IOT mainly rely on a centralized or a chain-style framework, thus have
some drawbacks or bottlenecks to prevent them from being widely adopted, while the issue of
locating hot-point resource has received much less attention, as well as the item-level lookup
service is still missing. Therefore, we present object discovery service architecture (ODSA),
a distributed serial number level object discovery service architecture using Chord for the
IOT, give its two kinds of framework and some relevant mechanisms, and mainly focus on the
Double-Ring architecture for enhancing the lookup efficiency and relieving the congestion
of network by balancing the flows of query. Additionally, we analyze theoretically the node
number constraint relationship between inside ring and outside ring. We conduct a simulation
study based on P2PSim of MIT and our prototype to validate and evaluate the analysis and
our solution. Results from the simulation validate the correctness of the theoretical analysis
and the availability, scalability of our solution. The related comparisons and analysis show
that our solution is available and outperforms substantially other approaches of current IOT
lookup service.

D.-G. Xu · L.-H. Qin (B) · J.-L. Zhou

School of Computer Science and Technology,
Huazhong University of Science and Technology, Wuhan, China
e-mail: dgx.hust@gmail.com
L.-H. Qin
e-mail: lhqin@hust.edu.cn
J.-L. Zhou
e-mail: jlzhou@hust.edu.cn

J.-H. Park
Department of Computer Science and Engineering, Seoul National University of Science and Technology,
Seoul, Korea
e-mail: jhpark1@seoultech.ac.kr

123
1456 D.-G. Xu et al.

Keywords Internet of Things · Chord · Discovery service · Object naming service · Object
discovery service

1 Introduction

In recent years, there is growing interest in Internet of Things (IOT) in the world. Within
supply chain communities, the term of IOT, in which each item has its unique ID—Electronic
Product Code [EPC, is stored on its Radio Frequency Identification (RFID) tag], is founded to
depict an emerging global, Internet-based information service architecture for RFID-tagged
items (RFID, is a core technology for Ubiquitous Computing and Ambient Intelligence). IOT,
served as the backbone of Ubiquitous Computing, whose core idea is to collect any useful
information about RFID-tagged (i.e. EPC-tagged) objects in global supply chain networks,
use the information in various applications during the objects’ lifecycle, and help companies
to improve existing business processes and decision-making.
To guarantee major transparency in products flow along the whole supply chain, the
item-level lookup requirements are quickly becoming a key issue in many application sce-
narios of IOT. In the future IOT, rich data of real-world objects and events will be avail-
able globally and in vast amounts, and will be stored widely in distributed, heterogeneous
information systems [e.g., EPC Information Service (EPCIS)]. To implement item-level
product tracking & tracing, it is critical to find such data in a timely fashion from these
systems. Thus, a high efficient lookup service (LS) is essential that allows accessing such
data, even if its exact location and form of storage are unknown to the requester. LS will
respond to such requests by returning a list of corresponding data providers [1] or a single
server.
The key components of IOT LS are the Object Name Service (ONS) and the Discovery
Service (DS). In the EPCglobal Architecture [1], the most influential architecture and poten-
tial future nucleus for the IOT, ONS lookup bases only on product type [2,3], DS is not yet
specified [1], a lookup service to locate item-level information stored at potentially unknown
supply chain partners is still missing.
In IOT, current LS and DS mainly rely on a centralized or a chain-style framework,
e.g., EPCglobal Architecture, Affilias DS [4,5], BRIDGE Project [3,6] and the Distributed
ePedigree Architecture proposed by Huang et al. [7]. These systems have some restrictions,
such as poor scalability, load imbalance, poor reliability owing to the presence of single
points of failure, or bottlenecks, which prevent them from being widely adopted. More-
over, the approach of locating hot-point resource has received much less attention in IOT.
Therefore, we present object discovery service architecture (ODSA), a distributed item-
level (EPC-tagged) Object Discovery Service (ODS) architecture based on Chord [8] for
the IOT, which makes the system more load balanced, scalable and efficient. In addition,
we mainly focus on the goal of enhancing the lookup efficiency and relieving the con-
gestion of network by balancing the flows of query. The main contributions of this paper
include:

• Object discovery service architecture proposes a new ODS architecture for IOT by com-
bining from functionality ONS and DS into ODS, which makes it easier to implement
EPC query at the granularity of serial number level. Additionally, it introduces Chord
lookup algorithm into ODS to inherit the many advantages of the underlying DHT (Dis-
tributed Hash Table) architecture, gives its two kinds of framework and some relevant
mechanisms.

123
ODSA: Chord-Based Object Discovery Service Architecture 1457

• Object discovery service architecture adopts Double-Chord-Ring overlay networks as the

substrate of the LS for IOT to further improve the efficiency of EPC query, and balance
the flows of EPC query, which reduces the probability of congestion in outer ring.
• Our theoretical analysis gives the corresponding node number constraint relationship
between outer ring and inner ring that makes the advantage of Double-Ring architecture
can be exhibited in the aspect of lookup efficiency.
• Our experimental evaluation of ODSA, base on the simulation of the real application
environment of IOT, shows that our solution is available and scalable, and validates the
correctness of our theoretical analysis.

The rest of this paper is organized as follows. In Sect. 2, we present background and motivation
for this research. Then, we present a basic architecture called ODSA in Sect. 3. Section
4 describes ODSA in detail and gives some mechanisms involved in ODSA. In Sect. 5,
theoretical analysis that gives the corresponding node number constraint relationship, a set
of experiments using this prototype are described and the results of these experiments are
analyzed, and the comparison evaluation of ODSA is provided. Section 6 gives an overview
of related work. Finally, we draw conclusions and outline future work in Sect. 7.

2 Background and Motivation

In this section, we firstly provide the necessary background for our research by summarizing
and analyzing the LS of EPCglobal network and some existing DS approaches and research
in related disciplines, then introduce Chord and motivate our research.

2.1 Key Components of Lookup Service

Two of the key components of IOT LS architecture required to implement track and trace
capabilities are the DS and the ONS. ONS provides a pointer to the information service
provided by the manufacturer of the object. DS provides pointers to multiple information
providers across a supply chain—not only the manufacturer.
The role of DS is not to aggregate the information from the various information providers,
but to provide relevant link information to clients and enable the gathering of this complete
information from multiple information providers that hold information for a given EPC.
Furthermore, DS will need to be designed to accept updates in close to real time from
multiple information providers across the supply chain or lifecycle of an object [3]. ONS is
imaged for the static nature, but DS is designed for the dynamic nature, of supply chains and
networks. Thus, from the functional point of view, the role of ONS and DS in relation to
multiple EPCISs is complementary (Fig. 1, extracted from [3]).

ONS lookup DS DS lookup based on unique

based only ID of each individual
on product object (serial-level records)
type EPCIS provides a
ONS EPCIS EPCIS EPCIS standard query interface
Company Company Company for exchange of servial-
A B C level event information
(Manaufacturer) among organization
Flow of an object across its supply chain or lifecycle

Fig. 1 Complementary roles of ONS and discovery services

123
1458 D.-G. Xu et al.

Fig. 2 Multi-step lookup procedure inside ONS resolver

So far, the up-to-date version of ONS 2.0.1 [2] does not specify queries for SGTIN
(Serialized Global Trade Identification Number) [1]. It specifically stops at the “Object Class”
level, namely the granularity of ONS resolution is limited to product type rather than serial
number level lookup (see Fig.1). In real world, only depends on ONS, it is difficult to realize
the fine-grain query. Therefore, it is indispensable for DS to fulfill the tracking & tracing of
item, though DS is still under development.

2.2 EPCglobal Network Architecture

Note that Afilias DS is compliant to the EPCglobal architecture framework, and the BRIDGE
project prototype is very similar to the EPCglobal approach, all three of them share the same
advantages and disadvantages [9]. Therefore, we only describe and analyze the EPCglobal
network architecture in detail here.
Inside the ONS resolver of the EPCglobal Architecture [1], a multi-step lookup is per-
formed as illustrated in Fig. 2 (extracted from [1]). First, it consults the Local ONS pertaining
to the EPC Manager Number for that EPC from the Root ONS controlled by EPCglobal. Then,
according to the GTIN part of this EPC, the End User consults the Local ONS, which pro-
vides the pointer to the EPCIS of interest. Finally, the End User obtains the data of interest
by consulting this EPCIS according to the whole EPC (mainly determined by the part of
serial number of the EPC). Obviously, Root ONS plays an indispensable central role during
the whole query, each query must start from it, which make the centralized architecture of
hierarchical ONS is vulnerable to single point failure, workload-imbalance due to excessive
lookup load of Root ONS and not scalable to handle a large number of query requests. On
the other hand, the ONS specified in the EPCglobal architecture is architected as an appli-
cation of the Internet domain name service (DNS). The use of DNS for ONS will inherit all
the well-documented DNS weaknesses [10,11] in robustness, configuration complexity and

123
ODSA: Chord-Based Object Discovery Service Architecture 1459

security. All these drawbacks have prevented the EPCglobal Architecture Framework from
being widely adopted.
Additionally, in this framework, ONS only provides a link to the manufacturer EPCIS,
which makes it is not enough for implementing traceability applications. Despite DS is envis-
aged to provide a list of links to all EPCISs that contain events information related to a particu-
lar EPC, enable the collecting of complete lifecycle information from multiple EPCISs across
an object’s supply chain or lifecycle and implement item-level product tracking & tracing,
however, so far, a technical standard (or specification) for DS has not been specified yet.
Although the method depicted in [12] to implement traceability applications through ONS
is plausible, it has serious drawbacks: if an EPCIS is failure, it is impossible to get information
from the next company, nor to get the most recent information without traversing the whole
supply chain. Thus, the method is unfeasible in practice.

2.3 A Distributed ePedigree Architecture

As centralized architecture suffers from drawbacks in single point failure, complicated regis-
tration and processing procedures, Huang et al. [7] propose a distributed ONS architecture by
combining ONS and DHT to find out drug counterfeit points in the pharmacy supply chains,
and the distributed ONS be constructed involving the EPCIS servers of all the participants.
This approach of locating drug counterfeit points through forward tracing or reverse tracing
is called “Daisy Chain” approach. Although the approach is implemented in a distributed
manner, all the processes rely on rewritable tags and must be supervised by an entity to be
able to identify the offender [7,13]. In addition, to collect information about an item, tra-
versing all relevant EPCISs along the supply chain for a given EPC cannot be parallelized
and therefore raises high lookup latency because each EPCIS must be queried sequentially
[7,13].

2.4 DHT-Based Chord Lookup Algorithm

In the last years, Peer-to-Peer (P2P) network has become one of the most popular applica-
tions in the Internet, and the P2P paradigm has emerged as an alternative to centralized and
hierarchical architectures. The scalability and the other advantages of P2P systems have been
proven in real-world applications.
Based on the deferent ways nodes are linked to each other and content is paced on the nodes
[14], P2P networks are classified into unstructured, such as Gnutella [15], and structured or
DHTs, such as Pastry [16], Kademlia [17] or Chord [8]. The advantages of DHTs include,
among other aspects, scalability, self-organizing, load-balance, less traffic that data placement
and search procedures generate. Three features that distinguish Chord from many other
P2P lookup protocols are its simplicity, provable correctness, and provable performance [8].
Among the DHT-based approaches, Chord is one of the most popular systems (for instance,
it has been adopted as mandatory by the IETF P2PSIP Working Group [18] and also be used
to obtain the scalability of ALE (Application Level Events) engine in RFID Middleware by
Schmidt et al. [19]) and it is the focus of the present paper [19–21].
As depicted in [21–23], similarly, novel approaches for the construction of scalable and
efficient IOT lookup systems need to have the following properties: self-organization, decen-
tralization, and adaptivity. The large-scale and dynamic nature of IOT make human admin-
istrative intervention difficult or even unfeasible, and centralized LSs are proving unsuitable
to scale to hundreds or thousands of nodes. In addition, it is worth noting that the frequently
accessing of hot-point resource may lead to the congestion of network in IOT. Therefore, in

123
1460 D.-G. Xu et al.

view of the advantages aforementioned of Chord and P2P network and the current develop-
ment state and limitations of LS for the IOT, in particular for the urgent need of serial number
level query nowadays, we have proposed a distributed Chord-based DS architecture according
to the P2P paradigm for obtaining better features of scalability, efficiency and adaptivity.

3 The Distributed ODSA

In this section, we present a distributed IOT ODS architecture based on Chord—ODSA. It

includes two kinds of framework: DR-ODSA (based on Double-Chord-Ring) and SR-ODSA
(based on Single-Chord-Ring). In this paper, we principally study DR-ODSA, and its basic
framework is shown in Fig. 3 below.

3.1 DR-ODSA

DR-ODSA consists of three major parts—Savant Server, ODS System and EPCIS Cloud.

3.1.1 Savant Server

Savant [24], designed to process the streams of tag or sensor data (event data) coming from of
one or more reader devices, is a “middleware” software system that sits between tag readers
and enterprise applications. Its intent is to address the unique computational requirements
presented by EPC applications. Savant performs filtering, aggregation, and counting of tag
data, reducing the volume of data prior to sending to Enterprise Applications. The Savant
itself is a container for Processing Modules defined by Auto-ID standards or users and other
third parties. More details about Savant can be found in [24].The Savant server is a server
installed with savant software.

3.1.2 ODS System

In ODSA, from functionality, we combine ONS and DS into ODS, and introduce Chord
into ODS, the structured Chord overlay networks are the network substrate of the applica-
tions about ODS and information interaction. And every participant, such as manufacture,

ODS-Ring ODS
ODS
ODS
Savant Server HODS
EPC
URI HODS-Ring
MapInfo HODS HODS
EPC Internet ODS
HODS
ODS
ODS ODS

Reader MapInfo

Electrom
-agnetic EPC EPC
PML EPCIS Cloud
EPCIS
Tag

Fig. 3 The framework of DR-ODSA

123
ODSA: Chord-Based Object Discovery Service Architecture 1461

distributor, or retailer, deploys a dedicated ODS node, and all the ODS nodes are organized
in a Chord ring and ordered following the hash values of their IPs.
Within a continuous period of time T , when the accessed times of an EPC exceeds the
accessed times threshold of EPC (A T ), the EPC is called hot-point resource (HPR). Only
depends on ODS-Ring, as the HPR objects are frequently accessed by the client application of
some organizations, it generates vast network traffic flows that may lead to the network con-
gestion of ODS-Ring. To relieve this problem and balance the flows of query, we add a HPR
ODS-Chord-Ring (HODS-Ring) into DR-ODSA. On the other hand, HODS brings appro-
priate hot-point data redundancy and backup, helps to enhance the reliability of the system.
ODS-Ring and HODS-Ring together form an ODS System. The ODS-Ring is responsible
for the queries of all objects (include HPR), and the HODS-Ring is only responsible for the
queries of HPR objects. In real world, HODS nodes, may be derived from the participants’
ODS servers which have better hardware configuration, also may are responsible by the third
party or be constructed and maintained by the government, according to network region.
Whichever method to be selected, it is depended on the concrete situation or the relevant
regulation of real world.

3.1.3 EPCIS Cloud

The EPCIS is a role defined in EPCglobal Network Architecture Framework [1], which
provide for storage and retrieval of filtered and processed information (static or dynamic)
related to EPC-tagged objects about different events within the supply-chain. In ODSA, each
participant (company or organization) maintains at least one EPCIS server. All the EPCIS
servers constitute an EPCIS Cloud.

3.2 SR-ODSA

SR-ODSA, a distributed IOT ODS Architecture Based on Single-Chord-Ring, is very similar

to DR-ODSA in every aspect. The main difference between it and DR-ODSA is that its ODS
System only includes ODS-Ring.

3.3 Deployment Scenario

The base composition of a company deployment is shown in Fig. 4.

Each company deploys only one Savant Server logically, although in practice, every one
may deploy more than one Savant Server. In one company, the ODS/HODS node may each
be implemented by multiple physically separate servers that act as backups for each other to
increase the scalability and reliability of the entire system. However, it must take appropriate
measures to ensure that it is still only one ODS/HODS node logically. It is important to note
that the number of HODS nodes must be far smaller than the number of ODS nodes. The
node number relationship of ODS and HODS is analyzed in detail in Sect. 5.1.
Fig. 4 Base composition of
EPC
company deployment
Reader Local Local
Electrom Savant ODS
-agnetic EPC Server

Tag
Application EPCIS

123
1462 D.-G. Xu et al.

Normally, a company needs only one EPCIS Server in theory. As a kind of service,
each company may deploy more than one EPCIS Server (multiple redundant servers, one
for backup of another one) as needed, but logically, the external feature of multiple EPCIS
Servers within a company is still one server through the relevant mechanism of main-backup.
For the sake of cost saving, for every stakeholder, its ODS may be combined together with
its EPCIS server.

4 Relevant Mechanisms of ODSA

To achieve the anticipative designing objective, it is very necessary for our ODSA framework
to have some relevant mechanisms, include storage and caching mechanisms, information
interaction mechanism and lookup mechanism. We will explain them in detail in this section.

4.1 Storage and Caching Mechanisms

In our ODSA framework, the DS is designed not to duplicate or aggregate information stored
within each individual EPCIS repository, but to store only sufficient relevant information to
be able to create the list of links.
Each of the ODS node has and maintains a finger table, a mapping table (map-table), a
hot-point table (hot-table), a cache table. And every ODS node holds the network addresses of
three closest HODS nodes to facilitate the information interaction between it and HODS node.
With finger table, which is similar to the one of Chord [8], we do not intend to describe it
in detail here. Hot-table includes two fields: key represents the hash value of hot-point EPC,
and upload time represents the time when the EPC become as HPR. Map-table mainly stores
the list of mappings between EPC and the network addresses (IP address or URL) of its
corresponding EPCIS servers, the lookup count (represents the accessed times of the EPC).
Cache table stores the EPC accessed recently and the network address of its corresponding
EPCIS, the access flag (Fa ) of the EPC and the time (Tfa ) at which the EPC was visited the
first time by ODS node. The information storage in ODS System are shown in Fig. 5, where
Key(EPC) represent the hash value of EPC.
In order to obtain a high cache hit rate, the content of Cache Table must be updated
dynamically, here we adopt NUR-like (Not Recently Used) algorithm to clean up or update
cache data periodically. The concrete operations are depicted as follows: To allow the system
to judge whether the EPC is visited recently, there have two variables (Fa , T f a ) associated
with each EPC in Cache Table. The value of Fa is set to 1 whenever the EPC is accessed by
someone ODS node, otherwise is set to 0. The NRU-like algorithm removes periodically the
EPC record, whose Fa is 0, or is 1 and the interval between its T f a and current time is bigger
than the cycle of cache update. To do its best to ensure the real-time of cache information, we
do not replace T f a with the last time when the EPC was accessed by the ODS node, which
may have somewhat negative impact on the lookup efficiency.
Only one finger table and one map-table are in HODS node, where the roles and content
of these tables are similar to the ones in ODS node. So, we don’t describe them in detail here.

4.2 Information Interaction Mechanism

In our ODSA, the information interactions principally include three aspects: publishing of
resource information, interaction of hot-point information and switch of lookup between
ODS-Ring and HODS-Ring.

123
ODSA: Chord-Based Object Discovery Service Architecture 1463

Fig. 5 ODS storage and data flow chart

Fig. 6 Information publishing principle chart

4.2.1 Information Publishing

The current EPCIS standard [13,25] does not involve a specific communication mechanism
between an EPCIS and a lookup service. Thus, here, we give an information publishing
mechanism to send the association between an EPC and the URL of the relevant EPCISs to
corresponding ODS node. It is possible that the EPCIS registers several events associated to
the same EPC because it has more than one RFID reader at the same company. Therefore, in
this situation, our mechanism determines that the lookup service stores only one association
between that EPC and the public URL of the EPCIS.
When an EPC-tagged object flows along the supply chain, the relevant EPCIS servers
must publish in time the relevant event information related to the EPC to the corresponding
ODS node that determined by hashing the object’s EPC. The event information registered or
published to ODS by EPCIS (see Fig. 6) is mainly the mapping information associated to the
current EPC that is passing the company that possesses this EPCIS. The mapping information

123
1464 D.-G. Xu et al.

is a 3-tuple (KEY, URL, FLAG), includes three fields: the SHA1 (or MD5) hash value of the
EPC, the URL where the information related to the EPC is available and the flag indicating
the information type (0 as static and 1 as dynamic).

4.2.2 Interaction of Hot-Point Information

As shown in Fig. 5, for one ODS node, once someone EPC of its map-table becomes as
HPR, it simultaneously do three things. They are: (1) uploading the relevant information
of this EPC to corresponding HODS node’s map-table, (2) writing current time into the
field of Hot Upload Time of its map-table, (3) and informing the relevant ODS nodes which
are consulting the EPC to add this Key and current time into their hot-table. On the other
hand, with the moving through the supply chain, for a HPR, once new mapping informa-
tion about it is published to the corresponding ODS node by relevant EPCIS Server, this
ODS node upload the newest information to relevant HODS node to assure the perfor-
mance of real-time of mapping information. In this paper, we only discuss the case: HPR is
always HPR, so it does not need to delete dynamically the HPR record in the hot-table of
ODS node.

4.2.3 Switch of Lookup

When an ODS node receives an EPC query of subscriber or end user, if it finds that the EPC
is in its hot-table, it will forward the query to its available closest HODS node (one of the
three closest HODS nodes). Then, the HODS node performs the query in inside ring, and
returns query result to this ODS node.

4.3 Lookup Mechanism

As the complete information about an individual object may be fragmented across multi-
ple organizations, the role of lookup service is to locate all the providers of the fragments
of information that constitute the complete supply-chain or lifecycle history for an object,
to implement tracking and tracing of EPC-tagged object. Thus, we give relevant lookup
mechanism here.

4.3.1 Routing in Chord-Based ODS System

As shown in Fig. 7, routing in Chord-based ODS System is based on the following EPC
lookup algorithm.
Firstly, the ODS node which is the first receiver of a query from a requester (savant
server) on a given EPC, looks into its map-table and cache table in turn (we call this ODS
node FRODS). If this EPC is found in one of the two tables, it returns directly relevant address
information to requester. Otherwise, it judges whether the key (the hash value of the EPC) is
located between itself and its immediate successor. If is, it forwards the query to the immediate
successor that is responsible for the requested EPC-tagged object, and then, the immediate
successor returns directly desired result to FRODS. If not, it looks into hot-table, if this EPC is
found, it forwards the query to ACHODS (one of the three closest HODS node and is available)
which is responsible for this query within HODS-Ring and return net result (relevant address
information) to it. If FRODS does not find EPC in hot-table, it looks into its finger table for the

123
ODSA: Chord-Based Object Discovery Service Architecture 1465

Fig. 7 Flow chart of routing in Chord-based ODS system

closest ODS node to the key (the hash value of the EPC) that has a lower or equal identifier, and
forwards the query message to this ODS node which is called the closest predecessor refer to
this key.
The closest predecessor does the work similar to what done by the FRODS. The main
difference between them is that the closest predecessor doesn’t look into its hot-table. In this
way, the query message is routed through the ODS-Ring until it reaches a node containing
mapping information related to the requested EPC-tagged object, this node then returns
directly desired result to FRODS. Finally, FRODS returns the result to the requester.
Likewise, when HODS node receives the query forwarded by other node (FRODS or
other HODS node), it takes the handling similar to what done by the closest predecessor in
ODS-Ring. The main difference is that HODS node lookups EPC only in its map-table.

4.3.2 Lookup Protocol of Application Level

In our architecture framework, in terms of manufacturer, as the static information (product

data from a manufacturer) of items which are made locally (local items) are all stored in local
EPCIS server, it only need to consult local EPCIS server when the application lookups static
information for local items. The local items’ static mapping information between EPC and the
address of its manufacturer’s EPCIS are stored into static map-table of its manufacturer’s ODS
server. In query process, the EPC of an object is used as an index to locate the corresponding
EPCIS server’s address, while the FLAG is used as a secondary index to confirm whether
the query aims at only static information.
As shown in Fig. 8, the query procedure of application level is described as follows:

123
1466 D.-G. Xu et al.

Fig. 8 Lookup flow chart of application level

Fig. 9 The 4-level hierarchical

structure of lookup

1. The application issues EPC query to local Savant server through whose application soft-
ware interface.
2. The local Savant server calls the query module to deal with the query: first looks into
its EPC cache information, if finds relevant record(s), it returns the result to application,
otherwise it forwards the query to the local ODS server.
3. The local ODS server first judge whether the query aims at the static information of
local item, if does, it looks into its static map-table and sends the result to the local
Savant server. If does not, it calls lookup module to consult in ODS system (as depicted
in Sect. 4.3.1 ). If it finds successfully the desired result—a list of network addresses
of relevant EPCIS servers related to the EPC, it stores the result into its cache table in
the form of 2-tuple—(EPC, URL-list) and returns the result to the local Savant server.
Otherwise, it analyzes the causes of failure and sends this analysis result to the local Savant
server.
4. The local Savant server analyzes the result from the local ODS Server. If the result
is failure causes, it switches to exception handling, and informs application. If is the
list of EPCIS addresses, it accesses in parallel the corresponding EPCISs of EPCIS
Cloud according to the list of addresses, to collect the detail information related to
the EPC.
5. Every corresponding EPCIS sends its lookup result using PML (Physical Markup Lan-
guage) file format to the local Savant server.
6. The local Savant server resolves these lookup results from previous step, stores the col-
lated results into its EPC cache and sends them to the application through the application
software interface.
7. Finally, the application integrates the collated results and displays them through the
user-friendly interface, and thereby implements the tracking and tracing of EPC-tagged
object.

In summary, in our solution, the query on a given EPC-Tagged object, using 4-level hier-
archical structure (Fig. 9), followed by local Savant server cache, the local ODS server,
HODS-Ring, ODS-Ring.

123
ODSA: Chord-Based Object Discovery Service Architecture 1467

5 Evaluation

For evaluating ODSA, we first give the number constraint relationship of nodes of two rings
through theoretical analysis, and then conduct a simulation study based on P2PSim of MIT
and our prototype to validate and evaluate the correctness of the theoretical analysis and the
availability, scalability, lookup efficiency of our solution. Finally, we give the comparisons
with related work to show the improvements of ODSA in performance of lookup, load-
balance, reliability, scalability, adaptivity, tracking & tracing, especially the locating of hot-
point resource.

5.1 Theoretical Analysis

To exhibit the advantages of lookup efficiency of DR-ODSA, the node number of two rings,
namely the proportion of the node number of HODS-Ring to the one of ODS-Ring PH O must
meet the corresponding constraint relationship. So, let us start with the analysis of the impact
of PH O on lookup performance. Let Pc be the probability of cache hit, Ph the probability
of hot-point hit, No the node number of ODS-Ring, Ni the node number of HODS-Ring, L i
the average lookup length of HODS-Ring, L S the average lookup length of SR-ODSA and
L D the average lookup length of DR-ODSA. Pc and Ph are defined as the following:
total count of cache hit
Pc = (1)
total count of queries
total count of hot-point hit
Ph = (2)
total count of queries
As the lookup length is 0 when cache is hit, and from [8], we know that the average lookup
length is 21 log2 N in an N -node Chord overlay network, so we have:
1
L s = (1 − Pc ) log2 No (3)
2
L i = Pi (log2 Ni + 1) = Ph (log2 Ni + 1) (4)
where Pi is the probability of the queries have been fulfilled by HODS-Ring, and it is equal
to Ph . The next step is to compute the average lookup length in DR-ODSA, L D :
 
1  1
L D = Ph log2 Ni + 1 + 1 − Ph − Pc log2 No (5)
2 2
Now assuming that L S is smaller than L D , combining (3), (4) and (5), we obtain the following
inequality:
 
 1 1  1
1 − Pc log2 No ≤ Ph log2 Ni + 1 + 1 − Ph − Pc log2 No (6)
2 2 2
From which we finally obtain the following expression of node number relationship between
ODS-Ring and HODS-Ring:
1
Ni ≥ No (7)
4
Thus, it can be obviously concluded that for the same value of Pc , the lookup performance
of SR-ODSA is better than the one of DR-ODSA when Ni is bigger than quarter of No . To
achieve more small lookup length, it is crucial that Ni is smaller than quarter of No . And

123
1468 D.-G. Xu et al.

(a) (b) (c) (d)

7 7 7 7

Average Length/Query
Average Length/Query

Average Length/Query

Average Length/Query
S-CM S-CM
6 S-SM 6 S-SM 6 6
5 5 5 5

4 4 4 S-CM 4 S-CM
S-SM S-SM
3 3 3 3
00

00

00

00
0

0
0

0
00

00

00

00

00

00

00

00

00

00
00

00

00

00

00

00

00

00

00

00
50

50

50

50
10

15

20

25

30

10

15

20

25

30
10

15

20

25

30

10

15

20

25

30
Time units Time units Time units Time units

Fig. 10 Average lookup length of SR-ODSA in both SM and CM with different number of ODS node. a
No = 256. b No = 512. c No = 1, 024. d No = 2, 048

only in this situation, the lookup efficiency advantage of DR-ODSA can be exhibited. And,
the smaller the PH O , the greater the efficiency advantage of DR-ODSA.

5.2 Experimental Evaluation of ODSA

For convenience of description, we present three kinds of lookup mode: SM (simple-mode,

the base manner), CM (cache mode, only enable cache) and HM (hot-point mode, only enable
hot-table). And let TS represent the time cost of simulation, R H represent the desired hot
resource hit rate,RC represent the desired cache hit rate, in IOT.
To evaluate ODSA, both SR-ODSA and DR-ODSA are compared through simulation in
this subsection. Furthermore, we prove the correctness of the results of theoretical analysis in
Sect. 5.1 by comparing it against the results of simulations. Simulations have been performed
using the simulator developed in C++ based on P2Psim of MIT and our prototype. Though
the simulator uses the Chord lookup algorithm of paper [8], in order to better simulate the
real application environment of IOT, the EPC queries are performed concurrently as time
goes by. In the simulator, we generate randomly K EPCs (i.e., K items) and allocate them to
No ODS nodes evenly. It can control the real hit rate to a certain extent by setting the value
of R H or RC , the actual hot hit rate or cache hit rate varies directly with the value of R H or
RC . During all the tests, we assign the same number of items K = 105 . For each value, we
repeat the experiment 20 times, and then take the average value as our result.

5.2.1 CM for the Improvement of Efficiency

We first test respectively the lookup performance in SM and CM for SR-ODSA (i.e., S-SM
and S-CM) with different TS to validate the impact of caching mechanism on the improvement
of lookup performance. In this test, we set No (i.e., the node number of ODS-Ring) from 256
to 2,048, TS from 5,000 to 30,000 in increments of 5,000, RC to 0.2 and the lookup mode is
set respectively to SM and CM.
Figure 10 shows the comparison of lookup performance of SR-ODSA for different TS in
both SM and CM, with No ranging from 256 to 2,048. It can be observed from the figure
that the introduction of caching mechanism improves obviously the lookup efficiency of
SR-ODSA. Without doubt, as the same principle, similarity to SR-ODSA, in DR-ODSA, the
introduction of caching mechanism can effectively improve the lookup performance too.

5.2.2 Node Number Constraint Relation in DR-ODSA

To validate the node number constraint relationship between ODS-Ring and HODS-Ring in
DR-ODSA, we divide this test into the following three parts:

123
ODSA: Chord-Based Object Discovery Service Architecture 1469

(a) (b) (c) (d)

7 7 7 7

50 Average Length/Query
Average Length/Query

Average Length/Query
Average Length/Query

D-HM D-HM
6 6 S-SM 6 6
S-SM
5 5 5 5
D-HM D-HM
4 4 4 S-SM 4 S-SM
3 3 3 3
00

00

00
0

0
0

00

0
00

00

00

00

00

00

00

00

00

00
00

00

00

00

00

00

00

00

00

00
50

50

50
10

15

20

25

30

10

15

20

25

30
10

15

20

25

30

10

15

20

25

30
Time units Time units Time units Time units

Fig. 11 The comparison of average lookup length of S-SM and D-HM with Ni is bigger than quarter of
No (Ni = (1/2)No in D-HM). a No = 256, Ni = 128.bNo = 512, Ni = 256. c No = 1024, Nin = 512. d
No = 2, 048, Ni = 1, 024

1. Ni is bigger than quarter of No . In this part, we test and compare the lookup performance
of SR-ODSA in SM and DR-ODSA in HM (D-HM) with Ni is the half of No.
2. Ni is equal quarter of No . In this part, we test and compare the lookup performance of
SR-ODSA in SM and DR-ODSA in HM with Ni equals quarter of No.
3. Ni is smaller than quarter of No . In this part, we test and compare the lookup performance
of SR-ODSA in SM and DR-ODSA in HM with Ni is equal to one-eighth of No.

In the three parts of this test, all corresponding parameters exclude Ni are set the same value
respectively. For example, in terms of the case when No equals 2,048, Ni equals 1,024 in
the fist part, Ni equals 512 in the second part, Ni equals 256 in the third part. And T is
assigned the value equals TS respectively. In this test, we set No from 256 to 2,048, TS from
5,000 to 30,000 in increments of 5,000,A T to 3, R H to 0.2, and the lookup mode is set to SM
in SR-ODSA and HM in DR-ODSA.
Figures 11, 12 and 13 show the impacts of different values of PH O on lookup performance
of DR-ODSA. Figure 11 shows the results of the first part of this test. From this figure, it is
obvious that DR-ODSA in HM has no advantages over SR-ODSA in SM in terms of lookup
efficiency as a whole, although there are some slight deviations in Fig. 11 b when No equals
512.
Figure 12 illustrates the results of the second part of this test. From this Figure, it can be
observed that the average lookup length of both DR-ODSA in HM and SR-ODSA in SM is
almost equal and DR-ODSA in HM has a slight advantage. Figure 13 shows the results of
the third part of this test. We first observe from the figure that DR-ODSA in HM with Ni
is smaller than quarter of No has visible advantages over SR-ODSA in SM in the aspect of
lookup efficiency. We further observe from Fig. 14 that the lookup performance of DR-ODSA
in HM outperforms clearly the one of SR-ODSA in SM in larger scale IOT with No = 2048,
and, the smaller the PH O , the greater the efficiency advantage of DR-ODSA.
In general, the results of this test show that 1/4 is the critical point of PH O , and the advan-
tage of DR-ODSA can be exhibited clearly in lookup efficiency only in the situation when
PH O is smaller than 1/4. The analytical results in Sect. 5.1 follow these results reasonably
closely, which validate the part of the analysis and show that DR-ODSA is available and
scalable.

5.2.3 HM for the Improvement of Efficiency

In Sect. 5.2.3, we consider the impacts of different values (1/2, 1/4, 1/8) of PH O on lookup
performance of DR-ODSA, and R H is set to 0.2 in the experiments of the section. In this

123
1470 D.-G. Xu et al.

(a) (b) (c) (d)

7 7 7 7

Average Length/Query

Average Length/Query
Average Length/Query

Average Length/Query
D-HM D-HM
6 6 S-SM 6 6
S-SM
5 5 5 5
D-HM
4 4 4 S-SM 4 D-HM
S-SM
3 3 3 3
00

00

00
0

00

0
00

00

00

00

00

00

00

00

00

00

00

00

00

00

00

00

00

00

00

00
50

50

50

50
10

15

20

25

30

10

15

20

25

30

10

15

20

25

30

10

15

20

25

30
Time units Time units Time units Timeunits

Fig. 12 The comparison of average lookup length of S-SM and D-HM with Ni equals quarter of No. a
No = 256, Ni = 64. b No = 512, Ni = 128. c No = 1024, Ni = 256. d No = 2, 048, Ni = 512

(a) (b) (c) (d)

7 7 7 7
Average Length/Query

Average Length/Query
Average Length/Query
Average Length/Query

D-HM D-HM
6 S-SM 6 S-SM 6 6
5 5 5 5
D-HM D-HM
4 4 4 S-SM 4 S-SM
3 3 3 3
00

00

00
0

0
00

0
00

00

00

00

00

00

00

00

00

00

00

00

00

00

00
00

00

00

00

00
50

50

50
50
10

15

20

25

30

10

15

20

25

30

10

15

20

25

30
10

15

20

25

30
Time units Time units Time units Time units

Fig. 13 The comparison of average lookup length of S-SM and D-HM with Ni is smaller than quarter of
No (Ni = (1/8)No in D-HM). a No = 256, Ni = 32 b No = 512, Ni = 64. c No = 1, 024, Ni = 128.
d No = 2, 048, Ni = 256

7
1024-HM
512-HM
Average Length/Query

256-HM
128-HM
S-SM

6
5000 10000 15000 20000 25000 30000
Time units
Fig. 14 The comparison of average lookup length of S-SM and D-HM with No equals 2,048 and Ni ranging
from 128 to 1,024

section, we consider the impacts of different values of R H on the lookup efficiency of

DR-ODSA.
This subsection presents simulation results obtained with a variable number of Ni ranging
from 128 to 1,024, R H ranging from 0.05 to 0.35 in increments of 0.05, the same No equals
2,048 and the same TS equals 104 . Figure 15 shows the trend of the average length of
DR-ODSA in HM decreases with the increasing of R H . From Fig. 15, we observe that the
average lookup length of DR-ODSA in HM decreases as R H increases and Ni decreases,

123
ODSA: Chord-Based Object Discovery Service Architecture 1471

Average Length/query
6

1024-HM
512-HM
256-HM
128-HM
5
0.05 0.1 0.15 0.2 0.25 0.3 0.35
Hot Hit Rate
Fig. 15 The comparison of average lookup length of D-HM with No equals 2,048, Ni from 128 to 1,024 and
R H ranging from 0.05 to 0.35

which further validate the correctness of the theoretical analysis in Sect. 5.1 and the scalability
of DR-ODSA.

5.3 Comparative Evaluation of ODSA

Next, the comparisons of ODSA to related work in the area of IOT lookup service and relevant
analysis are provided from the following aspects.

5.3.1 Scalability and Reliability

In IOT, all nodes will not join concurrently or leave voluntarily, which make the overall IOT is
relative stable, that is, ODS nodes do not suffer from frequent failures (nodes join the system
concurrently and leave voluntarily). On the other hand, even if IOT is not relative stable, as
ODSA is constructed on the basis of Chord lookup algorithm, all ODS nodes and HODS
nodes are organized according to Chord protocol and do not rely on any external supervisor
(unlike the Distributed ePedigree Architecture [7]), it enables ODSA is scalable and adaptive
by performing the stabilization operation.

5.3.2 Load Balance

Object discovery service architecture implements the load balance of EPC resource over
ODS and HODS nodes through consistent hashing, though it maybe not absolute balanced
[26], but is still far better than the centralized framework (e.g., EPCglobal Architecture,
Affilias DS, BRIDGE Project) in terms of EPC distribution balance. Of course, in ODSA,
the distribution balance of EPC resource can be further improved by using the approach of
[26]. More importantly, through the introduction of HODS-Ring in DR-ODSA, it balances
the query flows and relieves the congestion of ODS-Ring, and implements the workload
balance of query processing in ODS system, which further enhances the lookup efficiency,
reliability and scalability of ODSA. In the centralized framework, it is not workload-balanced
due to excessive lookup load of Root ONS.

123
1472 D.-G. Xu et al.

5.3.3 Tracking & Tracing

As the combination of function of both ONS and DS, and the introduction of Chord lookup
algorithm, it is easier to fulfill item-level track-and-trace requirements in supply chain net-
works for ODSA. Moreover, in ODSA, it is not essential that the tags must be or not be
rewritable.

5.3.4 Efficiency

Object discovery service architecture inherits the ability of efficient lookup of Chord,
and takes relevant measures to further enhance the efficiency of EPC query. Addition-
ally, in contrast to the Distributed ePedigree Architecture proposed by Huang et al., in
ODSA, the information collection from all relevant EPCISs along the supply chain for a
given EPC can be parallelized and therefore achieves low lookup latency because EPCIS
queries can be performed concurrently, which further improves the lookup efficiency
in practice.

5.3.5 Locating of Hot-Point Resource

Although the issue of discovery service or ONS of IOT has been extensively stud-
ied in the literature [3–7,9–13,27], most of the efforts so far have been devoted to
traceability applications, while the issue of locating of hot-point resource has received
much less attention. To the best of our knowledge, our paper is the first paper that
gives solution on this issue. ODSA adopts Double-Chord-Ring overlay networks as the
substrate of the lookup service, and introduces HODS-Ring and gives relevant mech-
anisms to deal with the location of hot-point resource. The results from testing (in
Sect. 5.2.2, 5.2.3) show that our solution about the location of hot-point resource is
feasible and available when meet the corresponding node number constraint relations.
Introducing HODS-Ring and related mechanisms, it can further improve the efficiency of
EPC query, balance the flows of EPC query and reduce the probability of congestion in
outer ring.

5.3.6 Privacy or Security

In our solution, information publishing, query and storage are all done using the hash
value of EPC. As the unipolarity of hash function (MD5, SHA), non-requester (non-
subscriber) of query or eavesdroppers cannot know the real value of EPC, which make
them not be able to know which EPC-tagged object corresponds to the data (the detail
object information from EPCIS or the mapping information from ODS or HODS).
Thus, information is not understandable or meaningful to them. Therefore, the pri-
vacy of object information can get protection to certain extent, though there are not
additional measures. Of course, some traditional security measures and the methods of
[28–31] may be flexibly adopted to our architecture to further enhance the security
of system.
In general, compared with other lookup service architecture of IOT, ODSA obtain a better
overall performance though there are possibly some rooms to improve.

123
ODSA: Chord-Based Object Discovery Service Architecture 1473

6 Related Work

Lookup service is an essential and critical component for a variety of application scenarios of
the IOT, especially in supply chain network. We briefly review the work that is most relevant
to our ODSA system to put it in the appropriate perspective, as follows.
Apart from EPCglobal Architecture, Affilias DS, BRIDGE Project and the Distributed
ePedigree Architecture [7], there are some related work in the area of IOT. Barchetti et al. [32]
focus on the implementation of DS developed as an extension of FossTrak open framework
[33] based on centralized framework. Paper [27] presents a centralized aggregating DS for the
EPCglobal Network and shows how to overcome scalability challenges through notification
in a real-world environment.
Object discovery service architecture is in part inspired by the DHT-based Chord algorithm
and Paper [13]. The paper has proposed a distributed discovery service for EPCglobal network
in nested package scenarios, which is based on the implementation of a DHT based ONS
and a totally distributed DS.
Most recently, there have been studies that explore the emerging applications of DHT and
the lookup service of IOT, such as the DHT-based ALE engine [19], the discovery service
[10,13,27], the Self-Chord [21], suggesting an increasing popularity and importance of DHT
application and the lookup service of IOT.

7 Conclusion and Future Work

For the current development status and existing problems of lookup service in IOT, in this
paper, we propose ODSA, a distributed serial number level ODSA based on Chord for the IOT,
give its two kinds of framework and some relevant mechanisms to make the EPCglobal net-
work and lookup more reliable, scalable, efficient and load balanced. We combine ONS and
DS into ODS from functionality to make it is easier to implement item-level tracking & trac-
ing. Additionally, we introduce HODS-Ring into DR-ODSA to further improve the efficiency
of lookup, balance the flows of query, and reduce the probability of congestion of ODS-Ring.
Both SR-ODSA and DR-ODSA are compared by performing the tests based on our pro-
totype and P2PSim of MIT. Results from the tests validate the correctness of the theoretical
analysis about the node number constraint relationship between two rings and the availabil-
ity, scalability of our solution, the related comparisons and analysis show that our solution
is available and outperforms substantially other approaches of current IOT lookup service.
So far, many research problems and implementation issues are still unsolved, and require
more efforts from both academia researchers and industrial practitioners, though lookup
service is a vital research direction in IOT. Our research points out one of viable directions to
foster the development and acceptance of IOT. Future work should focus on the security of IOT
and the relevant mechanism that the content of hot-table updates dynamically. Additionally,
in this paper, we propose the preliminary conception of EPCIS Cloud. To introduce Cloud
Storage and Cloud Computation into ODSA will also be our next work.

References

1. GS1. (2013). The GS1 EPCglobal Architecture Framework-Version 1.5. March 23, 2013.
2. GS1. (2013). GS1 Object Name Service (ONS) 2.0.1. Ratified Standard, January 31, 2013.

123
1474 D.-G. Xu et al.

3. AT4 Wireless, BT Research, SAP Research. (2007). High level design for discovery services. BRIDGE
project. University of Cambridge.
4. Afilias. (2008). Afilias discovery services: Enabling secure, selective visibility in global supply chains.
White paper. http://www.afilias.info/webfm send/37.
5. Rezafard, A. (2008). Extensible supply-chain discovery service problem statement. IETF Internet-draft.
http://tools.ietf.org/html/draft-rezafard-esds-problem-statement-03.
6. AT4 Wireless, BT Research, SAP Research. (2008). BRIDGE WP02-working prototype of serial-level
lookup service. BRIDGE project. University of Cambridge.
7. Huang, D., Verma, M., Ramachandran, A., & Zhou, Z. (2007). A distributed ePedigree architecture. In
Proceeding of the 11th IEEE international workshop on future trends of distributed computing systems,
(pp. 220–230).
8. Stoica, I., Morris, R., Karger, D., Kaashoek, M. F., & Balakrishnan, H. (2001). Chord: A scalable
peer-to-peer lookup service for internet applications. In Proceeding of the 2001 SIGCOMM confer-
ence on applications, technologies, architectures, and protocols for computer communications, ACM
(pp. 149–160).
9. Evdokimov, S., Fabian, B., Kunz, S., & Schoenemann, N. (2010). Comparison of discovery service
architectures for the internet of things. In Proceeding of IEEE international conference on sensor networks,
ubiquitous, and trustworthy computing (pp. 237–244).
10. Ramasubramanian, V., & Sirer, E. G. (2004). The design and implementation of a next generation name
service for the internet. In Proceedings of the 2004 conference on applications, technologies, architectures,
and protocols for computer communications (SIGCOMM’04) (pp. 331–342).
11. Fabian, B., & Gunther, O. (2007). Distributed ONS and its impact on privacy. In Proceeding of IEEE
international conference on communications (pp. 1223–1228).
12. Cantero, J.J., Guijarro, M.A., Arrebola, G., Garcia, E., Banos, J., Harrison, M., & Kelepouris, T. (2008).
Traceability applications based on discovery services. In Proceeding of the 2008 IEEE international
conference on emerging technologies and factory automation (pp. 1332–1337).
13. Manzanares-Lopez, P., Munoz-Gea, J. P., Malgosa-Sanahuja, J., & Sanchez-Aarnoutse, J. C. (2011). An
efficient distributed discovery service for EPCglobal network in nested package scenarios. Journal of
Network and Computer Applications, 34(3), 925–937.
14. Androutsellis-Theotokis, S., & Spinellis, D. (2004). A survey of peer-to-peer content distribution tech-
nologies. ACM, Computing Surveys(CSUR), 36(4), 335–371.
15. Klinberg, T., & Manfredi, R. (2002). Gnutella 0.6. http://rfc-gnutella.sourceforge.net/src/rfc-0_6-draft.
txt.
16. Rowstron, A., & Druschel, P. (2001). Pastry: Scalable, distributed object location and routing for large-
scale Peer-to-peer systems. Lecture Notes in Computer Science, 2218, 329–350.
17. Maymounkov, P., & Mazieres, D. (2002). Kademlia: A peer-to-peer information system based on the
XOR metric. Lecture Notes in Computer Science, 2429, 53–65.
18. Jennings, C., Lowekamp, B., Rescorla, E., Baset, S. A., & Schulzrinne, H. (2009). Resource location and
discovery (RELOAD). http://draft-ietf-p2psip-reload-00.txt.
19. Schmidt, L., Mitton, N., Simplot-Ryl, D., Dagher, R.,& Quilez, R. (2011). DHT-based distributed ALE
engine in RFID Middleware. In Proceedings of the 2011 IEEE International Conference on RFID-
Technologies and Applications (RFID-TA) (pp. 319–329).
20. Cuevas, R., Uruena, M., & Banchs, A. (2009). Routing fairness in Chord: Analysis and enhancement. In
Proceedings of the IEEE INFOCOM 2009 (pp. 1449–1457).
21. Forestiero, A., Leonardi, E., Mastroianni, C., & Meo, M. (2010). Self-Chord: A bio-inspired P2P frame-
work for self-organizing distributed systems. IEEE/ACM Transactions on Networking, 18(5), 1651–1664.
22. Taylor, I. J. (2004). From P2P to web services and grids: Peers in a client/server world. New York:
Springer.
23. Iamnitchi, A., Foster, I., Weglarz, J., Nabrzyski, J., Schopf, J., & Stroinski, M. (2003). A peer-to-peer
approach to resource location in grid environments. In Grid resource management. Norwell, MA: Kluwer.
24. Auto-ID Center. Auto-ID Savant Specification 1.0[EB/OL].
25. EPCglobal. (2007). EPC Information Service (EPCIS) version 1.0.1. September.
26. Karger, D. R., & Ruhl, M. (2006). Simple efficient load-balancing algorithms for peer-to-peer systems.
Theory of Computing Systems, 39(6), 787–804.
27. Muller, J., Oberst, J., Wehrmeyer, S., Witt, J., Zeier, A., & Plattner, H. (2010). An aggregating discovery
service for the EPCglobal network. In Proceeding of the 2010 43rd Hawaii international conference on
system sciences (pp. 1–9).
28. Ech-Cherif El Kettani, M. D., & En-Nasry, B. (2011). MIDM: an open architecture for mobile identity
management. Journal of Convergence, 2(2), 25–32.

123
ODSA: Chord-Based Object Discovery Service Architecture 1475

29. Elmisery, A. M., & Botvich, D. (2011). Enhanced middleware for collaborative privacy in IPTV recom-
mender services. Journal of Convergence, 2(2), 33–42.
30. Aikebaier, A., Enokido, T., & Takizawa, M. (2011). Trustworthy group making algorithm in distributed
systems. Human-Centric Computing and Information Sciences, 1(1), 1–15.
31. Bringer, J., & Chabanne, H. (2012). Embedding edit distance to enable private keyword search. Human-
Centric Computing and Information Sciences, 2(1) 1–12.
32. Barchetti, U., Bucciero, A., DE Blasi, M., Mainetti, L, & Patrono, L. (2009). Implementation and testing
of an EPCglobal-aware discovery service for item-level traceability. In Proceedings of the 2009 ICUMT
conference on modern ultra telecommunication (pp. 1–8).
33. Floerkemeier, C., Roduner, c, & Lampe, M. (2007). RFID application development with the accada
middleware platform. IEEE Systems Journal, 1(2), 82–94.

Author Biographies

De-Gang Xu received the M.S. degree from Huazhong University

of Science and Technology in 2007, where he is now pursuing his
Ph.D. degree in computer science. His main interests are computer net-
work and trust management, network storage system, network security,
Internet of things.

Lei-Hua Qin received the Ph.D. degree in computer system archi-

tecture in 2007 from Huazhong University of Science and Technol-
ogy (HUST). He is now an associate professor at School of Computer
Science and Technology of HUST. His main research interests include
computer network and cloud computing, network storage system and
Internet of things.

123
1476 D.-G. Xu et al.

Jong-Hyuk Park received his Ph.D. degree in Graduate School of

Information Security from Korea University, Korea. He is now a pro-
fessor at the Department of Computer Science and Engineering, Seoul
National University of Science and Technology (SeoulTech), Korea. He
is a member of the IEEE, IEEE Computer Society, KIPS, KICS, KIISC,
KMMS, KDFS and KIIT◦ Dr. Park’ s research interests include Digi-
tal Forensics, Security, Ubiquitous and Pervasive Computing, Context
Awareness, Multimedia Service, etc.

Jing-Li Zhou received the B.E. degree in 1969. She is a Professor

and doctor advisor at Huazhong University of Science and Technology.
She had been a visiting scholar in USA from 1995 to 1996 and has
been honor of the State Department Special Allowance since 1999. Her
main field of research: computer network, network storage system, and
multimedia signal processing.

123