An ONS-based Architecture for Resolving RFID-enabled Objects in Collaborative Environments

Abstract

Collaborative B2B and B2C environments provide enterprises with the necessary level of flexibility and efficiency in order to retain competitiveness under the increasingly turbulent e-business area. Web-Services are utilized by enterprises in order to integrate high and low level enterprise applications, thus providing a collaborative e-business environment without affecting inter-and intra-enterprise processes. Nevertheless, the above paradigm should be enhanced in order to comply with the Web-of-Things concept. This paper describes a sustainable approach towards the above requirement by employing ONS-based services able to provide targeted information regarding RFID-enabled physical objects (i.e. products) that are handled in a B2B/B2C collaborative environment.

Full text

An ONS-based Architecture for Resolving RFID-
enabled Objects in Collaborative Environments
J Gialelis, D Karadimas, P Chondros, E Polytarchos
Industrial Systems Institute/RC Athena, PlataniPatras, Greece
Athens University of Economics and Business, Athens, Greece
1gialelis@isi.gr, 2karadimas@ieee.org, 3chondros@isi.gr, 4e.polytarchos@gmail.com
Abstract: Collaborative B2B and B2C environments provide enterprises with the necessary
level of flexibility and efficiency in order to retain competitiveness under the increasingly
turbulent e-business area. Web-Services are utilized by enterprises in order to integrate
high and low level enterprise applications, thus providing a collaborative e-business
environment without affecting inter- and intra-enterprise processes. Nevertheless, the above
paradigm should be enhanced in order to comply with the Web-of-Things concept. This
paper describes a sustainable approach towards the above requirement by employing ONS-
based services able to provide targeted information regarding RFID-enabled physical
objects (i.e. products) that are handled in a B2B/B2C collaborative environment.
Keywords: collaborative b2b, supply chain collaboration, web services, RFID, ONS
I. INTRODUCTION
Business-to-Business and Business-to-Customer electronic transactions (B2B/B2C e-commerce) outfit the
enterprises with the necessary tools for real-time interaction with their suppliers, dealers and customers. As a
result, competition among businesses turns gradually from an enterprise-to-enterprise matter to a value chain-
to-value chain one.
E-Business frameworks represent the state of the art in e-commerce; since framework-based B2B e-
commerce effectively addresses the seamless linking of inter-enterprise (public) processes involving
Enterprise layer’s applications to those of business partners. These frameworks provide the necessary layers
to achieve interoperability in e-commerce, since their interactions involve various business processes and
business components, such as executable applications, systems, and their associated information [1].
In order to support the interchange of information among “public” modules, several standards and languages
have been developed. EDI (Electronic Data Interchange), EDIINT (EDI over the Internet), ebXML (e-
business eXtended Markup Language) and BizTalk are some generic standards addressing vertical as well as
horizontal integration issues. Furthermore, standards such as RosettaNet, IOTP (Internet Open Trading
Protocol), ICE (Information and Content Exchange) and OBI (Open Buying on the Internet) deal more with
vertical market-oriented integration issues [2].
However, current framework-based developments consider inter- as well as intra-enterprise processes,
involving information at the level of enterprise layer applications, without taking into consideration the
tracking information of a physical object (i.e. a product) through its lifecycle.The work presented in this
paper focuses in the challenging concept of an RFID-enabled value chain from the manufacturing industry up
to the point of sales, by introducing an architecture that utilizes components of the EPC global network, such
DOI: 02.WCMCS.2013.1.17
© Association of Computer Electronics and Electrical Engineers, 2013
Proc. of
W
orld
Cong
. on
Multimedia and Computer Science

114
as the. Object Naming Services (ONS) and the EPC Information Services (EPCIS), in order to support the
Internet of Things concept. Our current add on enhances the architecture of e-business frameworks in order
to involve all enterprise layers into e-commerce interactions, thus introducing an innovative collaborative
business model which seamlessly integrates the inter-enterprise (public) with the intra-enterprise (private)
processes.
II. COLLABORATIVE E-BUSINESS ENVIRONMENTS
Continuous Replenishment Planning (CRP) model is an example of a collaborative B2B model which can
constitute the base for the development of an efficient inventory management function. Even though, CRP
model has the potential to alter significantly production-scheduling methods and inventory management
practices, so that enterprises enjoy the above-mentioned benefits, survey results do not keep up with these
expectations [3]. This drawback is caused, mainly, due to CRP deployment methodologies. Such
methodologies are based on point-to-point architectures and on the utilization of proprietary
solutions/technologies which present very limited tolerance to system/applications alterations and minimum
scalability to value network expansion.
In order to fully overcome these drawbacks and achieve both integration of heterogeneous systems and
applications, at any layer in the enterprises they may reside and unlimited expansion of the value-network,
this paper proposes an enhancement of an approach described in [4] and [5]. Fig. 1 depicts the corresponding
architecture. Our approach was based on Internet ubiquity and the XML standard. In a nutshell, a hierarchical
model was utilized based on [6], which comprises three layers: the Communication, the Content and the
Business Process layer.
The technologies per layer are as follows. For the communication needs the SOA paradigm (WSDL. SOAP,
etc.)was utilized by employing the use of Web-Services technology in order to open up enterprise systems,
plant systems and production systems; thus making available their functionalities. For the Content layer
which provides the means to describe and organize exchanged information in such a way that it can be
understood and used by all the collaborating partners, product ontologies in order to achieve a uniform
product terminology were utilized. For the Business Process layer which is concerned with the conversational
interactions among services, RosettaNet Partner Interface Processes (PIPs) was the paradigm that was
adopted.
Therefore, our proposed enhancement comprises the introduction of an additional layer called Object Naming
Services (ONS) layer which resides above the business process layer and it is responsible for resolving the
Electronic Product Code (EPC) of RFID tags to Internet addresses which correspond to specific services thus,
fully supporting the expansion of the value-network.
III. RESOLVING EPC OF RFID-ENABLED PHYSICAL OBJECTS
In order to support an RFID-enabled value chain from the manufacturing industry [7]to the point of sales and
beyond in a global scale, the proposed architecture utilizes the standards and specifications concerning the
Electronic Product Code (EPC) published by the GS1 [8].
A. The EPC global
The GS1 EPC global is a suite of standards and specifications that leverage the RFID technology in order
to enable visibility and collaboration in the value-chain on an item level. An organizational entity that
supports these standards will be able to manage, keep track, provide value added services and collaborate in a
global scale with other entities that support the EPC global stack, for every EPC tagged item that has been
detected within its premises.
 Tag data & tag data translation. These standards define EPC tag data, the different schemes of
encoding and their translation to various forms of presentation.
 Tag protocol. These standards define the physical and logical requirements for the EPC RFID
systems (tags and interrogators).
 Low level reader protocol. The low level reader protocol defines the interface between the RFID
interrogators and their clients.
 Discovery configuration and initialization & reader management. These standards define the
management interface between the RFID interrogators and Access controllers that includes the

115
discovery of other components within the network, the configuration of the interrogators and the
monitoring of their status.
 Application level events. The application level events standard specifies the filtering and data
collection interface that provides tag data acquired from a interrogators.
 EPC information services. This standard provides a standard interface to provide services related
with the EPC tag data.
 Object naming service. The Object Naming Service (ONS) is a crucial component of the EPC global
framework, essential for the discovery of services related with an EPC tagged object. [9]. Concisely,
it describes a mechanism, which utilizes the DNS infrastructure to translate the EPC encoded on the
RFID tag of a product to a collection of services (EPC information services) and their corresponding
addresses. The EPCs are structured using any one of the various numbering schemes available in the
Tag Data Standard (TDS) [10]. Most of the schemes have the general structure depicted in Fig. 2.
The ONS uses the EPC Manager Number (company prefix) and the Object Class components of an
EPC to search through the DNS for appropriate services and it returns the list of services along their
corresponding addresses. These services are in essence links to their formalized description
(ServiceType XML) that can enable a machine to automatically determine how to interact with the
service located at that address [9].
 Discovery services. These standards are still in development, but they will enable trading partners
in the value chain and other entities to share resources, knowledge and data related to EPC tagged
objects. Concisely, they will provide a standardized interface for an interested party to learn which
EPCIS servers provide information for an EPC tagged object.
 Certificate profile. This standard specifies the digital certificates used to securely identify RFID
interrogators.
Figure 1. e-Business holistic framework.
III. ENHANCED ARCHITECTURE FRAMEWORK
The proposed enhancement of the existing e-Business Framework aims to support as many of the EPC global
standards as possible; in order to provide the ability to resolve single physical objects to URIs and to track
related information regarding the entire lifecycle of the representation for all involved enterprises in the value
chain, i.e. manufacturer, logistics, retailand end-user (customer), together with the realization of an ONS-
based web service available in the cloud.
Figure 2. Common structure of TDS schemes.
Manufacturing Enterprise
SOA
SCADA
MES
Enterprise Layer Shop Floor
Layer
Plant
Layer
Business
Process Layer
Content Layer
ERP
OPC

Retail Enterprise
Communication
Layer
Business
Process Layer
Content Layer
Communication
Layer
SOA
e-Business
Dialog
ERP
Enterprise LayerShop Floor Layer
Header EPC
Manager
Number
Object
Class Serial
Number

116
Fig. 3illustrates the incorporation of such an ONS service layer at the top of each existing CRP model. The
proposed ONS service layer consists of a collection of ONS-based web services that are able to serve
information from the internal of the CRP model breakdown, using the global EPC notation, without affecting
the existing e-Business dialogs among the enterprises of the value chain. Each enterprise’s ONS service layer
is responsible for providing per object, both public and private information, using the global EPC notation.
The private web services satisfy per sector- needs for real-time, synchronous physical objects tracking. These
needs have various orientations, depending on the corresponding node of the chain. The public web services
address needs of purchasers, regarding single product’s lifecycle information
Figure 3. Proposed architecture framework
The integration of an RFID subsystem, into an existing architecture framework raised two main issues. The
first regards the capturing of tags’ information as well as the identification of the tags themselves. The RFID
reader scaling, range and reading angle are of major importance since it is incorporated in an industrial
environment. The second issue regards the employment and integration of the protocol stack into the CRP
model. In the following section, the ONS service layer is described.
A. The ONS service layer
Since the main focus of the architecture presented in this paper is the collaboration within B2B/B2C
environments, one of the key motivators for integrating an EPC RFID system in the architecture would be
collaboration itself, which, within the EPC global framework, is mainly represented by the Object Naming
Service, that provides interested parties with the ability to resolve EPC tagged objects to addresses of
arbitraryservices, but with a standardized interface.
Adhering to the well-defined and widely supported SOA paradigm of SOAP Web-Services, we have defined
services that provide the ONS functionality to EPC-agnostic web service clients. Thus, if a client wants to
discover the available services related to an EPC tagged item, both the required by the ONS standard NAPTR
DNS query and a SOAP web service call will be available.
The architecture also embraces another key component of the EPC global, the EPCIS [11], in order to
provide value added services that include traceability (i.e. a history of the item that includes the locations

117
where it has been detected and the corresponding business events) and a mapping service that acts as a
translator of legacy bar-code based application dependent codes to EPCs.
Additionally, in order to simplify the development of the various components of the architecture, the ONS
service layer has been designed so as to provide web services that provide a uniform interface to the
traceability service.Thereby, whenever the system gets input from an RFID reader and uses the ONS service
layer to detect the network address of an EPCIS server, a corresponding entry is added in the traceability
service that contains:
 the EPC oftheitem,
 thelocationofthedetection (whichalsoindicatesthebusinessevent),
 theservicerequested,
 thedateoftherequest.
The next section presents a small subset of possible services that have been employed as private or public
services, illustrating the usage and large scale capabilities of the proposed architecture.
B. Use case scenario
The main use case scenario illustrated in this paragraph utilizes the enhanced architecture framework as
described previously, premises that discrete product manufacturing enterprises are involved in the chain.
Additionally, the enterprise of primal production within the chain should own a company prefix (Global
Trade Item Number - GTIN) so as their products are not only RFID-capable but also the corresponding EPC
tags have global visibility and uniqueness. The above requirements among with the proposed architecture
framework constitute the integrated, collaborative environment that is able to deliver significant benefits to
all involved parts in the chain, i.e. the enterprises and the consumers.
An integral substitution of the existing e-Business dialog in a stable chain is not an option in large scale
enterprises, since huge investments and efforts have been achieved for such an accomplishment. The
accomplished benefits from such an integrated environment for a contemporary B2B and B2C trading
scheme, aim to complement the existing e-Business dialog of collaborative B2B environments so as to
include ONS-obtained functionality, thus the single object resolving capability. However, many critical or
just informational services could be deployed on such an architectural framework for a B2B/B2C
environment.
The critical under-tracking information within a manufacturing enterprise is the processing log and tracking
of a single product. This is more meaningful if the manufacturing enterprise fabricates large objects,
following a build-to-order approach.
Logistics and retail enterprises could benefit the most from such an e-Business framework since the ability of
a single object tracking is of great importance for them. Assuming that all cooperating partners of a logistic
and a retail enterprise follow the proposed architecture, then all involving parts are capable to track a single
product not only within their facilities but worldwide.
Finally, consumers are able to track provided information from a single product’s lifecycle, assuming that the
points of sales are equipped with RFID readers. The real-time and synchronous tracking of all relevant
information regarding a product will provide next generation informational services regarding the
consumable products. These services may include product energy characterization, product designation of
origin, the obvious information about manufacturing and packaging dates, even information regarding the
intermediate steps of manufacturing or supply chain.
V. ARCHITECTURE’S HOLISTIC SERVICE LAYER
The implementation of the proposed service layer as an enhanced architecture scheme for collaborative
environments is based on two major aspects: the XML structures that are handled by the ONS service layer
of each CRP Model and also the operations that this layer is capable of, which are both described in this
section.
A. Structures used by the ONS service layer
The developed ONS service layer uses the XML structure described below in order to represent the pairs of
information services and their respective internet addresses (Pairs):
 Pair

118
o Service (The definition of the service, according to [9])
o Servers (The URI of the server that provides the service that is contained in the Pair e.g.
“https://location.randomserver.org/locate”)
The following structure represents the Pairs that are related with an EPC:
 EUSSN (the name is an acronym derived from EPC, URI, (Service-Server)*N) contains the fields:
o EPC (an EPC writtenas a string according to [10])
o URI (The URI that results from the conversion of the EPC according to[10])
o Location (A string that describes the location where the detection took place)
o Time Stamp (The time the item was detected, in UTC)
o A number of Pairs
The structure below is used in the operations that require authentication and authorization in order to
function. It is comprised by a user, an encrypted password and a number (0 or more) of Pairs that are related
with an EPC (EUSSN).
 UEUSSN (User + EUSSN)
o User (a username)
o Pass (an encrypted password)
o EUSSN (zero or more)
The Location Time structure is used to specify the location and the date that an item was detected
 Location Time:
o Description (A string that describes the location of the detection e.g. “storehouse A”)
o Timestamp (The detection time - UTC)
Finally, the structure below represents a list of the locations where the item has been detected:
 Locations:
o A number of LocationTime entries
B. Service Operations
Based on the previously described structure, the implemented ONS service layer supports the operations
described in this section: EPC query, EPC service Query, EPC2URI, EPC addition, EPC deletion, User
Addition, User Deletion and Location Query.
Below, the detailed description of the operations can be found.
EPC query:
The EPC query returns the Pairs located for the specified EPC or URI (hereby mentioned collectively as
EPC), included in an EUSSN structure.
This, EPC2URI and EPC service Query services do not require authentication. The EPC query operation
accepts a single argument:
 EUSSN (A EUSSN node that does not contain any Pairs. In it, either the EPC or the URI or both
should be mentioned (if both are mentioned; only the URI will be considered). If a location is not
mentioned, the location is not stored into the tracking service. If the Time Stamp field exists, it is
used for the detection time in the tracking service. If that is omitted, the query arrival time is used.)
The operation returns a EUSSN node that contains:
 The EPC for which the query was for. If the request did not contain an EPC, but only a URI, the EPC
field will contain the corresponding translated value of the URI, according to[10]
 The URI representation of the EPC. Conversely with the EPC, if a URI hasn’t been contained in the
request, the URI field of the response will contain the result of the EPC to URI conversion.
 The previous location where the item was detected, along with the date of that detection

119
 A number of service-server pairs that will contain the pairs of service tags and server addresses for
the EPC-URI contained in the EUSSN
EPC Service Query
The EPC service query returns the Pairs located for the specified EPC or URI (hereby mentioned collectively
as EPC) and service, included in a EUSSN structure.
This operation does not require authentication. The operation accepts a single argument:
 EUSSN (An EUSSN node. In it, either the EPC or the URI or both should be mentioned (if both are
mentioned, only the URI is considered) and a Pair that should contain only the desired service name.
Optionally, the query can also include a Location and a TimeStamp.)
The operation returns a EUSSN node that contains:
 The EPC for which the query was for. If the request did not contain an EPC, but only a URI, the EPC
field will contain the correspondingtranslatedvalueofthe URI, accordingto[10]
 The URI representation of the EPC. Conversely with the EPC, if a URI hasn’t been contained in the
request, the URI field of the response will contain the result of the EPC to URI conversion.
 The previous location where the item was detected, along with the date of that detection.
 A number of service-server pairs that will contain the pairs of service tags and server addresses for
the EPC-URI contained in the EUSSN that matched the service in the request.
EPC 2URI
The EPC to URI returnsthe URI ofthetranslationaccordingto[10]ofthe EPC provided. This operation does not
require authentication. The operation accepts a single argument:
 EPC (The EPC that should be translated.)
The operation returns a string that contains the resulting URI. If the EPC could not be translated, a zero string
is returned.
EPC addition
This action adds a Pair for the specified EPC (the pair and the EPC are provided by an EUSSN structure).
If the EPC isn’t already contained in the system, a new entry for that EPC will be created. A valid user with
sufficient permissions is required. Along with this operation the user must pass his encrypted password, in
order for the server to verify whether the user is authorized to add a service-server pair for an EPC. The
required arguments are:
 EPC additionRequest (A UEUSSN node that contains the credentials of the user and an EUSSN node
that must contain the EPC and the Pair that should be added in the ONS. The EUSSN must contain
only one pair.)
This operation returns an integer. If the new service was successfully added to the ONS, the operation returns
0, else if the Pair already exists 1 is returned. If the Pair could not be added -1 is returned. If the user doesn’t
have sufficient permissions to add an EPC, 2 is returned.
EPC deletion
The provided Pair is removed for the specified EPC (the data are provided using an EUSSN structure).
If no Service-server pair has been provided, all the records for the in the local ONS server will be deleted.
A valid user with sufficient permissions is required. Along with this operation the user must pass his
encrypted password, in order for the server to verify whether the user is authorized to delete a service-server
pair for an EPC. The required arguments are:
 EPC deletion Request (A UEUSSN node that contains the credentials of the user and an EUSSN
node that must contain the EPC and the service-server pair that should be removed from the ONS.
The EUSSN must contain only one pair.)
This operation returns an integer. If the service has been successfully removed from the ONS, the operation
returns 0, else if the service-server pair doesn’t exist 1 is returned. If the service-server pair could not be
deleted -1 is returned. If the user isn’t permitted to delete an EPC, code 2 is returned.
User Addition
This operation creates a user with certain permissions. It must be executed by an authorized user. The
required arguments are:

120
 User (A UEUSSN node that must contain the credentials of a user with the appropriate user
management rights. No EPCs or Pairs should be contained.)
 Added User (A UEUSSN node with the credentials of the user that will be created. No EPCs or Pairs
should be contained.)
 Permissions
o 3bits: add EPC (If the first bit is set - i.e. Permissions Value | 1 -, the user will be able to add
EPCs), delete EPC (If the second bit is set - i.e. Permissions Value | 2 -, the user will be able to
delete EPCs) and user management (If the third bit is set - i.e. Permissions Value | 4 -, the user
will be able to add or delete users.)
The operation returns an integer: 0 for success, 1 if the user already exists, 2 for insufficient permissions, -1
for general failure.
User Deletion
This operation removes a user. It must be executed by an authorized user. The required arguments are:
 User (A UEUSSN node that must contain the credentials of a user with the appropriate user
management rights. No EPCs or Pairs should be contained.)
 Deleted User (The username of the user that will be deleted. This must be different than the user that
requested the deletion.)
The operation returns an integer: 0 for success, 1 if the user doesn’t exist, 2 for insufficient permissions, -1
for general failure.
Location Query
The Location Query service returns the locations where the EPC provided as an argument has been detected.
This service does not require a valid user and requires a single argument, the EUSSN structure that will
provide the EPC of the item:
EUSSN (An EUSSN node that does not contain any service-server pairs. In it, either the EPC or the URI or
both should be mentioned - if both are mentioned; only the URI is considered.)
The Location Query call returns a list of the locations where the item has been detected, using a Locations
structure.
VI. EXPERIMENTAL IMPLEMENTATION
The experimental implementation of the ONS service layer employs the bind 9.8.4 DNS server for the ONS
instance, as specified in [9] and the Tomcat Java 6.0.35 applet container to deploy the web services,
supported by the PostgreSQL 9.1 database and the OpenJDK Java platform. The whole ONS service layer
has been included in a virtual machine running the debian 7.1 linux distribution, in order to streamline
installation and ease deployment.
The validation and verification of the functionality of the system included the creation two such ONS service
nodes in different physical servers. Each instance contained a user that could add and delete EPCs, as
described in section V. Then, their web services were used to add a set of services (location tracking and
legacy code mapping) for a number of dummy EPCs. Finally, the system was queried for these services both
through the web service interface and via DNS queries.
VII. CONCLUSION
This paper presents an innovative approach towards collaborative e-business environments by utilizing
Rosetta Net standard, Service Oriented Architecture and semantically enriched information combined with
Object Name Services in order to seamlessly integrate the inter-enterprise (public) and intra-enterprise
(private) processes in an ONS-based perspective.
The main focus of the architecture presented in this paper is the interoperable integration of B2B/B2C
environments, which constitutes one of the key motivators for involving an EPC RFID system in the
architecture. The integration itself, which, within the EPC global framework, is mainly achieved by
utilizingthe Object Naming Service, provides collaborating parties with the ability to resolve EPC tagged
objects to addresses of arbitrary services, but with a standardized manner.

121
ACKNOWLEDGMENT
The work presented in this paper has been partially supported by the General Secretariat for Research and
Technology (GSRT) [12] of the Hellenic Ministry of Development in the framework of project SELIDA -
contract # 09SYN-72-646 which runs under the “Cooperation”, 2009 Call.
REFERENCES
[1] Simon S.Y. Shim, Vishnu S. Pendyala, Meera Sundaram, Jerry Z. Gao: Business-to-Business E-Commerce
Frameworks. IEEE Computer, vol. 33, no.10, pp. 40--47, (October 2000)
[2] Kim Tae-Young Kim, Sunjae Lee, Kwangsoo Kim, Cheol-Han Kim: A modeling framework for agile and
interoperable virtual enterprises. Computers in Industry, vol. 57, issue 3, pp. 204--217. Elsevier Science Publishers
(April 2006)
[3] S. Lee et al.: Business Value of B2B Electronic Commerce. Electronic Commerce Research and Applications 2, pp.
350--361 (2003)
[4] J. Gialelis, A. Kalogeras, A. Kaklis, S. Koubias: RosettaNet-based implementation for a collaborative continuous
replenishment planning model utilizing Web services and Ontologies. IEEE Emerging Technologies and Factory
Automation, ETFA 2005.
[5] J. Gialelis, A. Kalogeras, A. Kaklis, S. Koubias: Collaborative Continuous Replenishment Planning Process
Implementation Utilizing Web Services, Product Ontologies and Workflow Management Systems. IEEE Emerging
Technologies and Factory Automation ETFA 2006.
[6] B. Medjahed et al.: Business-to-Business Interactions: issues and enabling technologies. The VLDB Journal 12, pp.
59--85 (2003)
[7] Dongmyung Lee and Jinwoo Park (2010). RFID-enabled Supply Chain Traceability: Existing Methods,
Applications and Challenges, Sustainable Radio Frequency Identification Solutions, Cristina Turcu (Ed.), ISBN:
978-953-7619-74-9
[8] GS1, EPC global network specifications, http://www.gs1.org/gsmp/kc/epcglobal/
[9] GS1, Object Name Service (ONS) Version 2.0, Ratified Standard, Issue 1, 2012/12/20
[10] GS1, EPC Tag Data Standard 1.6, Ratified Standard, September, 2011
[11] GS1, EPC Information Services (EPCIS) Version 1.0.1 Specification, 2007/09/21
[12] General Secretariat for Research and Technology, http://www.gsrt.gr