Deliverable D6.1 Unique identifier analysis report and ... - D6.1_0.pdf · IoT6 D6.1 First report...

Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture enabling heterogeneous components

interoperability

Grant agreement for: Collaborative project Grant agreement no.: 288445

Start date of project: October 1st, 2011 (36 months duration)

Deliverable D6.1 Unique identifier analysis report and STIS, ONS, IoT6 integration Contract Due Date 30/09/2012

Submission Date 30/09/2012

Version 1.0

Responsible Partner KAIST

Author List Daeyoung Kim, Seong Hoon Kim, Janggwan Im,

Jaewook Byun, Giang Nam, Kwangkook Lee

Dissemination level PU

Keywords Internet of Things, IPv6, Dissemination

Project Coordinator: Mandat International (MI) Sébastien Ziegler <[email protected]>

IoT6 D6.1 First report on Unique identifier analysis report and STIS, ONS, IoT6 integration

2

Abstract

This deliverable reports on the unique identifier analysis and integration of STIS, ONS, and

IoT6. As a result, this document explores and analyzes various unique identifiers such as

Uniform Resource Identifier (URI), Handle System Micro ID (uID), Object Identifier (OID),

Universally Unique Identifier (UUID), and Electronic Product Code (EPC), etc. Thus, we

have reported that URI could be desirable for the identifier to enable interoperation among

heterogeneous identifiers.


3

Table of Contents

[1] Introduction ....................................................................................................................... 4 1.1 Domain overview ........................................................................................................ 4 1.2 About this document .................................................................................................... 5

[2] Unique Identifier Analysis ................................................................................................ 6 2.1 Overview ..................................................................................................................... 6

2.2 Unique universal identifiers......................................................................................... 6 2.2.1 Uniform Resource Identifier (URI) ...................................................................... 6 2.2.2 Handle System ...................................................................................................... 6

2.2.3 Micro ID (uID) ..................................................................................................... 7 2.2.4 Object Identifier (OID) ......................................................................................... 7 2.2.5 Universally Unique Identifier (UUID) ................................................................. 7 2.2.6 Digital Object Identifier (DOI) ............................................................................ 8

2.2.7 Global Trade Item Number (GTIN) ..................................................................... 8 2.2.8 Global Location Number (GLN) .......................................................................... 9 2.2.9 Serial Shipping Container Code (SSCC) ............................................................. 9 2.2.10 Global Individual Asset Identifier (GIAI) ............................................................ 9

2.2.11 Global Service Relation Number (GSRN) ........................................................... 9 2.2.12 Electronic Product Code (EPC) ............................................................................ 9

2.3 The use of URI for interoperability of heterogeneous identification systems ........... 13

[3] STIS, ONS, and IoT6 integration .................................................................................. 14 3.1 Object Naming Service (ONS) .................................................................................. 14 3.2 Smart Things Information Service (STIS) ................................................................. 14 3.3 Overview of Interaction between STIS, ONS, and IoT6 ........................................... 14

3.4 Integration Aspects .................................................................................................... 15 3.4.1 Description of ONS interface ............................................................................. 15

3.4.2 Description of STIS interface ............................................................................. 18 3.4.3 Example applications ......................................................................................... 21

3.5 Communication complexity and cost analysis .......................................................... 24

3.5.1 Communication cost of CoAP implementation .................................................. 24 3.5.2 Communication cost between heterogeneous things and other components such

as STIS and ONS.............................................................................................................. 26

[4] Conclusion ...................................................................................................................... 30

[5] Reference.......................................................................................................................... 31

[6] Appendix .......................................................................................................................... 32


4

[1] Introduction

1.1 Domain overview

To enable the vision of Internet of Things (IoT), one of the pivotal technologies is a global

identification system like radio frequency identification (RFID)[14]. Since IoT scales up to

trillions of networked objects, the global identification system should allow everyday objects

to be distinguished from each other. In addition, IoT needs to be aware of physical changes of

objects or their surroundings in order to monitor their concise physical context or to react to a

certain condition. In this regard, sensor technology is an essential integral part of IoT. It

bridges the gap between physical world and virtual one.

As an approach to solve the issues stated above, Smart Thing Information Service

(STIS)[17] has been developed from KAIST (Rep. of Korea) for integrating RFID networks

with heterogeneous sensor networks (e.g., ZigBee, 6LoWPAN, etc.) in a transparent network

distribution and homogeneous manner. To provide applications with global accessibility,

interoperability, and information sharing about things, STIS exploits well-standardized

protocols and interfaces of electronic product code (EPC) Network where EPC[7] is a

standardized global identification system by EPCglobal. As for the information sharing about

things, distributed databases in STIS archive refined data from RFID/sensor networks via a

complex event processing (CEP) engine[15]. The CEP engine filters and groups a large

volume of data generated from the physical world and extract useful information. The right-

hand side of the Fig. 1 presents the STIS.

STIS can interoperate with IoT6 through IPv6 networks as both clients and/or servers. When

the STIS works as a server, it provides STIS clients with a unique identifier and the

spatiotemporal information about their physical things. On the other hand, when the STIS

plays a role of a client, it requests sensory data to IoT6 devices like 6LoWPAN sensor nodes.

Figure 1. STIS architecture and Interaction with IoT6


5

1.2 About this document

This document reports two subjects: unique identification analysis and STIS[17], ONS[16],

and IoT6 integration. The first subject explores numerous identification systems which might

be used for RFID tags, logical location, sensors or actuators, followed by the exploration

about the usage of URI [1] as a consistent approach using heterogeneous identification

systems. The second part presents the interface specification for the interoperability between

IoT6, STIS, and ONS. Moreover, this document includes analysis reports about complexity

and communication costs between heterogeneous smart things through these unique

identifiers as well as with other components such as STIS and ONS, while focusing on STIS

as a server role.


6

[2] Unique Identifier Analysis

2.1 Overview

Enabling the IoT requires a unique identification system in order to distinguish from trillions

of things and to make them globally accessible from the Internet. This system must provide

global unique identifiers to enable all things worldwide being identifiable and retrievable

without ambiguity. In the following we first illustrate representative identification systems

and afterwards suggest a unified solution for making those heterogeneous identification

systems interoperable.

2.2 Unique universal identifiers

2.2.1 Uniform Resource Identifier (URI)

URI [1] provides a simple and scalable way to identify web resources such as pages of text,

video/sound clips, programs, etc. An identification system using the URI enables

communications with the resources through their representations (e.g., name, identifier, etc.).

Each URI can be defined by specific protocols and schemes indicating syntax. URI can

categorize as a locator, a name, or both. The Uniform Resource Locator (URL) is the subset of

URI that identifies resources by using attributes such as their addresses representing their

network location. On the other hand, the Uniform Resource Name (URN) is the subset of URI

that must be globally unique and not be changed even if resources are not available in the

previous locations. Several examples of the URL and URN are shown below:

URL: ftp://ftp.is.co.za/rfc/rfc1808.txt

- ftp scheme for File Transfer Protocol services

URL: gopher://spinaltap.micro.umn.edu/00/Weather/California/Los%20Angeles

- gopher scheme for Gopher and Gopher+ Protocol services

URL: http://www.math.uio.no/faq/compression-faq/part1.html

- http scheme for Hypertext Transfer Protocol services

URL: telnet://melvyl.ucop.edu/

- interactive services via the TELNET Protocol

URN: mailto:[email protected]

- mailto scheme for electronic mail addresses

URN: news:comp.infosystems.www.servers.unix

- news scheme for USENET news groups and articles

2.2.2 Handle System

Handle System [2] provides a basic identifier resolution system in which any heterogeneous

local namespaces is able to join a global namespace. This namespace is administered by the

system using a unique naming authority. The unique Handle System naming authority can

help any local name to be definitely unique under the global handle namespace. The Handle

system is designed to overcome limitations and to add important functionalities. The Handle

System can especially guarantee the following objectives: uniqueness, persistence, multiple

instances, multiple attributes, extensible namespace, and international support, distributed

service model, etc.

The handle is generated by the following format:

<Handle> ::= <Handle Naming Authority> “/” <Handle Local Name>

The naming authority and local name are divided by a forward slash (/). Any local name must

be unique within its local namespace, and the set of local names under a naming authority

defines the local handle namespace for that naming authority. The uniqueness of a naming


7

authority and a local name under that authority guarantees that any handle is globally unique

within the Handle System.

An example of handle is shown as follows:

Handle = 10.1045/january99-bearman

This handle means that it is under the handle naming authority “10.1045” and its handle local

name is “january99-bearman”.

2.2.3 Micro ID (uID)

MicroID (uID) [3] is a lightweight identity protocol, which enables the creation of a

convenient identity token based on any two URIs. uID consists of a hashed

communication/identity URI and claimed URL. By concatenating these two elements, a hash

is generated which can be claimed by third party services.

An example of uID can be computed like the following:

uID = sha1( sha1("mailto:[email protected]") + sha1("http://example.net/") );

Computed uID is then put in web resource to identify the resource. At the first glance it is

seen that uID depends on the resource location and email address of the resource’s authority.

2.2.4 Object Identifier (OID)

Object identifier (OID) [4] is officially defined using the ITU-T's ASN.1 standard and enables

an object, anything from a piece of paper to a country, to be named. OID is represented as a

dotted decimal string like the example below. Enterprises and individuals can obtain a root

OID from an issuing authority and employ it to assign internally new OIDs to its child node

applying tree scheme. Since each OID can be translated as all nodes from the root to the leaf

in the tree, successive numbers of the nodes can identify each node in the tree. In addition,

new nodes are only registered under their registration authority so that only the authority of

“a.b.c” can tell what “a.b.c.d” means.

An example of OID and its interpretation is shown below:

OID = 1.2.840.113556.1.5.4

Number “1” refers to the root authority which is the ISO. The number “2” denotes ANSI

encoding scheme. “840” is the code for USA (the country). “113556” tells the object is under

the authority of Microsoft Company. “1”, “5” and “4” are active directory, classes, and built-

in-domain, respectively.

2.2.5 Universally Unique Identifier (UUID)

Universally unique identifier (UUID) [5] is a standard of Global Unique Identifier (GUID)

used in software construction, standardized by the Open Software Foundation (OSF). UUID is

used originally in Apollo Network computing System and later in OSF Distributed Computing

Environment (DCE), and then in Microsoft Windows platforms. UUID is a 128bits (16bytes)

long and it is represented by 32 hexadecimal digits. UUID consists of five hexadecimal digit

groups separated by hyphens as follows: 8-4-4-4-12. As a result, the total number of

characters in UUID is 36, because the number of hexadecimal digits and hyphens is 32 and 4,

respectively.

An example of UUID and its interpretation is shown below:

UUID = 550e8400-e29b-41d4-a716-446655440000


8

At the beginning of that UUID, the hexadecimal digits “550e8400”, “e29b” and “41d4”

denote the low field of the time stamp, the middle field of the timestamp and the high field of

the time stamp multiplexed with the version number respectively. An, “a7” and “16”, among

the following hexadecimal digits “a716”, represent the high field of the clock sequence

multiplexed with variant and the low field of the clock sequence respectively. Finally, the last

hexadecimal digits “446655440000” depict the spatially unique node identifier.

2.2.6 Digital Object Identifier (DOI)

Digital object identifier (DOI) [6] is an identifier assigned permanently to a digital object such

as web file or internet document. Although a digital object’s address is changed, DOI enables

users to find it as before. Metadata about an object and DIO name are stored in the DOI

system and this metadata includes the location information of the object, such as URL, which

can find where the object is. The DOI system is generally used by the publishers who want to

track and manage thousands of documents used on the web. In case of using only the URL, if

the location of documents is changed, publishers must change many links related to thousands

of the documents in their sites. However, by using DOI, the publishers need only to change

the metadata for DOI to link to the new URL, even if the URL of an object changes. DOI is a

character string divided into two parts, a prefix and a suffix, separated by a forward slash (/).

The prefix identifies the registrant of the name, while the suffix is chosen by the registrant and

identifies the specific object associated with that DOI.

An example of DOI and its interpretation is shown below:

DOI = 10.1000/182

The prefix is “10.1000” and the suffix is “182”. The first part of the prefix, “10”, identifies the

DOI registry, and the second part in the prefix, “1000”, identifies the registrant; in this case

the registrant is the International DOI Foundation. The suffix, “182”, represents item ID

identifying a single object.

2.2.7 Global Trade Item Number (GTIN)

Global Trade Item Number (GTIN) [9] is an identifier for trade items developed by General

Specification-1 (GS1). It is used exclusively with bar codes and sometime in RFID for the

purpose of automating trading process, basically buying and selling, and also to retrieve the

predefined product’s information. The family of data structures comprising GTIN includes

GTIN-12, GTIN-8, GTIN-13, and GTIN-14. The number following “GTIN” indicates the

digit in the identification string, usually GTIN-x will be padded with zero to the left to

achieve the full 14-ditgit GTIN. GTIN-8 is used for EAN-8 bar codes whose seven digits

contain a GS1-8 Prefix and item reference, and additional one digit represents the check digit.

GTIN-12 is used for UPC-A and UPC-E bar codes whose eleven digits contain a U.P.C

Company Prefix and item reference and additional one digit represent the check digit. GTIN-

13 is used for EAN-13 bar codes whose twelve digits contain a GS1 company prefix and the

item reference and additional one digit represent the check digit. GTIN-14 is used for ITF-14,

UCC/EAN-128, reduced space symbols, and data matrix barcodes whose one digit represent

the indicator digit to indicate packaging level and twelve digits contain the GS1 company

prefix and the item reference and additional one digit represent the check digit to verify the

integrity.

GS1 provides mapping between GTIN and EPC. A portion of the EPC address space is

allocated for GTIN. That is, GTIN can be referred using EPC scheme.


9

2.2.8 Global Location Number (GLN)

GLN [10] is the GS1 Identification Key for Locations. GLN is used to identify physical

location of entities in the product supply chain. By using GLN as a key, a product

administration can determine where the product has been through and what the status is. GLN

structure comprises 13 digits, whose 12 digits contain GS1 company prefix and location

reference. GS1 company prefix is assigned by the GS1 member organization and location

reference is allocated by the company. The additional one digit is the check digit to verify the

integrity.

GS1 provides mapping between GLN and EPC. A portion of the EPC address space is

allocated for GLN. That is, GLN can be referred using EPC scheme.

2.2.9 Serial Shipping Container Code (SSCC)

SSCC [11] is the GS1 Identification Keys used to identify a shipping container. A container

can be a case, pallet, specific load of truck or any combination of containers. This container

can be tracked individually using SSCC, which enables delivery tracking and autonomous

receiving. SSCC is used when specific unit load from one place to another needs to be

identified, while traded item is used to tag an item itself. So, a single item can be identified

with both an SSCC and a GTIN. The key is comprised of an Extension digit, GS1 Company

Prefix, Serial Reference, and Check Digit.

GS1 provides mapping between SSCC and EPC. A portion of the RPC address space is

allocated for SSCC. That is, SSCC can be referred using EPC scheme.

2.2.10 Global Individual Asset Identifier (GIAI)

Global Individual Asset Identifier (GIAI) [12] is the GS1 keys for identification of fixed asset.

Any individual asset within a company of any value needs to be identified uniquely. GIAI

enables company’s assets to be individually recorded as part of its fixed asset inventory

control system. Detailed information regarding the asset will be recorded in a database and the

GIAI provides the link to that information or identification point which can be used to retrieve

information held in a database.

GS1 provides mapping between GIAI and EPC. A portion of address space of EPC is

allocated for GIAI. That is, GIAI can be referred using EPC scheme.

2.2.11 Global Service Relation Number (GSRN)

Global Service Relation Number [13] is the GS1 identifier for a relationship between a

service provider and a client. Example of this relationship is a club membership, a patient

attending hospital and so on. It does not include information of a business or individual, and

therefore, does not raise privacy concerns. The GSRN plays a role of the key that links to a

database for retrieving the information of the service offered based on the contract with the

individual. The GSRN may be held in a database record and encoded in a barcode so that the

customer may identify themselves to the service provider.

GS1 provides mapping between GSRN and EPC. A portion of the EPC address space is used

for GSRN. That is, GSRN can be referred using EPC scheme.

2.2.12 Electronic Product Code (EPC)

EPC is a unique identifier defined by GS1 and used to identify a specific item in the supply

chain. The EPC is said to be the next generation of the bar code; radio waves are used to read


10

product information faster, more efficiently, and even without recognition. EPC is usually

stored on RFID tags and retrieved by RFID reader via the RFID technology. Although RFID

and EPC are used together, their roles are not the same; EPC is an identifier, whereas RFID is

a data carrier. In addition to the general identifier (GID) of EPC, EPC also provides the

encodings of seven GS1 keys such as SGTIN (GTIN with serial number), SSCC, SGLN

(GLN with serial number), GRAI (Global Returnable Asset Identifier), GIAI, GDTI (Global

Document Type Identifier), and GSRN. It means that it is possible to encode the GS1 keys in

EPC scheme. GS1 Tag Data Standard document [7] defines EPC scheme.

Once EPC is retrieved from RFID tags, it can be associated with the data such as the

manufactured place of an item or the date of its production. This association can be provided

by EPCglobal architecture framework [8] which defines components and interfaces for

sharing EPC-related data. It defines RFID reader interface, middleware for processing EPC

and EPC-related data, distributed database, object naming service, and discovery service. In

the near future, clients will look up EPC-related data with given EPC employing this

architecture.

The general structure of EPC tag is a string of bits consisting of an 8-bit header followed by a

series of numeric whose length, structure and function are determined by the header.

Figure 2. EPC format [7]

The header has a length of 8 bits and defines the overall length, identity type, and structure of

EPC tag. This header also determines the encoding schemes. Some of these coding schemes

are shown in the next table and the rest are reserved for future use.

Figure 3. EPC tag header defines coding scheme [7]

Pure Identity EPC URI:

[General Syntax] urn:epc:id:scheme:component1.component2.component3. …


11

[Example] urn:epc:id:sgtin:0614141.112345.400

EPC Tag URI:

[General Syntax] urn:epc:tag:EncodingName:EncodingSpecificFields

[Example] urn:epc:tag:sgtin-96:3.0614141.112345.400

EPC can be written as a human-readable form called EPC URI as described above. There are

two URI forms in EPC; one is Pure Identity EPC URI, and the other is EPC Tag URI. Pure

Identity EPC URI contains only identity information, but EPC Tag URI contains not only

identity information, but also necessary information for encoding on actual RFID tags such as

number of encoding bits, control information, etc.

Pure identity EPC URI form has a prefix ‘urn:epc:id’ which means that it is one of the

uniform resource name (URN) whose name is ‘epc’, and ‘id’ refers to the identifier. ‘scheme’

is one of coding scheme in the Figure 3, except for the information bit. Subsequent

component1, components2, components3 are different according to the EPC scheme. If this

scheme is ‘sgtin’ these components are company prefix, item reference and serial number,

respectively. The example EPC has company prefix ‘0614141’, item reference ‘112345’,

serial number ‘400’.

EPC Tag URI form has additional information for encoding on actual RFID tags. Unlike Pure

identity, EPC tag begins with ‘urn:epc:tag’ where ‘tag’ means that it contains information for

encoding on RFID tags. ‘EncodingName’ is one of coding scheme in the Figure 3 such as

SGTIN-96 and GID-96. ‘EncodingSpecificFields’ is determined by ‘EncodingName’, and it

can have information for encoding on RFID tags such as control information. In the string

‘3.0614141.112345.400’, the first digit ‘3’ refers to control information which is used for

actual reading or writing EPC on RFID tags and the remaining part ‘0614141.112345.400’ is

the same as in Pure identity EPC URI.

As discussed previously, EPC is versatile and can interoperate many other identifier code

schemes into its format in a hierarchical fashion. This interoperation is shown in the next

subsections.

2.2.12.1 EPC supports GTIN code scheme

Figure 4. EPC to GTIN code scheme [7]

Figure 4 shows the interpretation of an EPC URI into GS1 SGTIN (Serialized Global Trade

Item Number) identification system. EPC URI begins with “urn:epc:id” and follows by an

identification scheme which are “sgtin” and three digits: company prefix, item reference and

serial number. The company prefix is assigned by GS1 to a managing entity. The item

reference is assigned by the managing entity to a particular object class. On the other hand,

the serial number is assigned by the managing entity to an individual object. The serial

number is not part of the GTIN, but is formally a part of the SGTIN.


12

[General syntax] urn:epc:id:sgtin:CompanyPrefix.ItemReference.SerialNumber

[Example] urn:epc:id:sgtin:0614141.112345.400

2.2.12.2 EPC supports SSCC code scheme

Figure 5. EPC to SSCC code scheme [7]

Figure 5 shows the EPCglobal standard in SSCC code scheme. The GS1 Company Prefix is

assigned by GS1 to a managing entity and the Serial Reference is assigned by the managing

entity to a particular logistics handling unit. The Serial Reference as it appears in the EPC

URI is derived from the SSCC by concatenating the Extension Digit of the SSCC and the

Serial Reference digits, and treating the result as a single numeric string.

[General syntax] urn:epc:id:sscc:CompanyPrefix.SerialReference

[Example] urn:epc:id:sscc:0614141.1234567890

2.2.12.3 EPC supports SGLN code scheme

Figure 6. EPC to SGLN code scheme [7]

Figure 6 shows EPCglobal SGLN code scheme. The GS1 Company Prefix is assigned by GS1

to a managing entity. This is the same as the GS1 Company Prefix digits within a GS1 GLN

key. The Location Reference is assigned uniquely by the managing entity to a specific

physical location. The GLN Extension is assigned by the managing entity to an individual

unique location. If the entire GLN Extension is just a single zero digit, it indicates that the

SGLN stands for a GLN, without an extension.


13

[General syntax] urn:epc:id:sgln:CompanyPrefix.LocationReference.Extension

[Example]urn:epc:id:sgln:0614141.12345.400

2.3 The use of URI for interoperability of heterogeneous identification systems

The above sections have shown that there are many identification systems available in

consumer market. Part of these IDs which are developed by GS1 can be represented under

EPC and some others are not. Under the IoT vision, the interoperation between these

identification systems is critical, since physical objects come from very different

manufactures and categories so that they carry different identifiers. Thus, IoT architecture

should be mature and intelligent enough to cope with thing’s diversity. To achieve this, URI

would be a good solution due to its flexibility and hierarchical nature. A URI can be presented

as a URN or URL. URN tells the unique name of the resource and URL points to its real

location. In the context of identification scheme, URN is used to name the physical objects. A

standard URN can be seen as:

urn:<identification scheme>:<identifier number>

The “urn” is used to indicate that this is an URL representing thing’s ID opposed to a location.

Identification scheme indicates the identification system where the queries should be routed

to. Lastly the identification number is the entity’s identifier according to each identification

scheme which is interpreted normally in each identification system. By doing this way, the

IoT infrastructure can name everything that comes from every source available just by

forming a suitable URN. For the above example, in order to point to a digital object with DOI

name 10.1000/182 the following URN can be used:

urn:doi:10.1000/182.

Or an object with OID 1.2.840.113556.1.5.4 can be represented as:

urn:oid:1.2.840.113556.1.5.4

Or for an EPC:

urn:epc:id:sgtin:30.744B5A1.C00001.00000000A

Figure 7. Relationship between URI, URL, and URN


14

[3] STIS, ONS, and IoT6 integration

This section describes how to retrieve EPC-related data from STIS, i.e., EPC information

service (EPCIS), in cooperation with an object naming service (ONS). Before exploring these,

ONS and STIS are introduced below.

3.1 Object Naming Service (ONS)

The primary responsibility of ONS is to provide pointers to authoritative information about an

object. Examples of authoritative information are multiple types of services which can be

included in ONS records, EPC information services (EPCIS) as a STIS, product specific web

pages, web services and other data such as XML data about products. Thus, the ONS client

can obtain the product information from ONS.

3.2 Smart Things Information Service (STIS)

STIS is rooted from EPCIS which enables enterprises to share the EPC-related data.

Ultimately, this sharing is aimed at enabling participants in the EPCglobal Network to achieve

a shared view of the disposition of EPC-bearing objects within a relevant business context.

Unlike pure EPCIS which is tailored to RFID networks, STIS is in charge of providing not

only RFID data, but also sensor data from physical world based on EPC. It allows a global

sharing of information about physical things with both real-time and historical status.

3.3 Overview of Interaction between STIS, ONS, and IoT6

The following Figure 8 describes a configuration of the IoT6 test-bed in KAIST. A

client searches for an address of EPCIS for a given EPC via ONS. After retrieving the EPCIS

address, the client queries to the EPCIS for EPC-related data via EPCIS query interface.

Figure 8. Interaction with ONS and EPCIS

Application level events (ALE) administrator as one of the clients can manipulate actions of


15

the filtering and the collection (F&C) middleware to control the way of storing EPC-related

data to EPCIS via ALE interface. For this purpose, ALE administrators need to understand the

way that RFID or sensor data is stored into EPCIS. Meanwhile, RFID readers periodically

read RFID tags where they are operating in IPv4 address. They transmit tag data to the F&C

middleware which filters and groups the tag data in order to remove duplicate data and

accommodate a large volume of data to store into EPCIS in an efficient manner. After filtering

and grouping, the F&C middleware notifies the result in ALE format to EPCIS.

3.4 Integration Aspects

3.4.1 Description of ONS interface

Regarding the ONS interaction, there are the set of terminologies here to explain the

interface.

Domain Name Service (DNS): a hierarchical distributed naming system for

computers, services, or any resource connected to the Internet or a private network. It

associates various information with domain names assigned to each of the

participating entities.

Object Name Service (ONS): a hierarchical distributed naming system for things.

The ONS is used when querying the DNS for an EPC.

ONS Client: ONS Client gets the service-endpoint from ONS by querying EPC to

ONS. There are several EPC formats; Binary encoding, Tag-encoding URI, Pure

Identity URI, and ONS Hostname.

ONS Publisher (KAIST): ONS Publisher provides pointers to authoritative

information for EPCs to the ONS Client. Each pointer takes the form of a DNS Type

Code 35 (NAPTR) record.

Until ONS client obtains the EPC-related data from ONS, several components are

interacted. In this subsection, the general flow of ONS is described, then we group

the several steps into three steps and present how ONS clients process the

transformation of EPC and returned data from ONS. Finally, we conclude this

subsection with summarized ONS sequence diagram.

1) Flow of ONS

A flow of typical ONS query from the beginning to the end is described here. First, an

ONS client just sends ONS Hostname to DNS/ONS Cloud, then the DNS/ONS Cloud

sends the available service-endpoint to the ONS client for obtaining service related to

EPC. In the ONS specification, current available services are Web-Service, EPCIS,

HTML, and XML-RPC. Given an EPC, the detailed steps of these operations are

shown below:


16

Figure 9. Typical ONS Query from start to finish from the viewpoint of a client application

Step 1: A sequence of bits denoting an EPC is read from a 64-bit RFID tag.

Example: (10 000 00000000000000 00000000000000011000 0000000000000000110010000)

Step 2: The tag Reader sends this bits sequence to a local server.

Example: (10 000 00000000000000 00000000000000011000 0000000000000000110010000)

Step 3: The local server converts the bits sequence into the pure identity URI Form

defined in Section 4.3.3 of the EPCGlobal Tag Data Standard.

Example: urn:epc:id:sgtin:0614141.000024.400

Step 4: The local server presents the URI to the local ONS Resolver.

Example: urn:epc:id:sgtin:0614141.000024.400

Step 5: The resolver converts the URI form into an ONS Hostname and issues a DNS

query for NAPTR records for that domain.

Example: 000024.0614141.sgtin.id.onsepc.com

Step 6: The DNS infrastructure returns a series of answers that contain URLs pointing

to one or more services (for example, an EPCIS Server, WSDL, html, XML-RPC,

etc.)

Step 7: The local resolver extracts the URL from the DNS record and presents it back

to the local server.

Example:

http://epc-is.example.com/epc-wsdl.xml

Step 8: The local server contacts the correct EPCIS server found in the URL for the

EPC in question.

2) Explanation of Steps Step 1-6

These steps just said that there are many formats that represent EPC. Consequently, ONS

Client just sends the ONS Hostname format of EPC to the ONS.

Tip: Tag Data Translation (TDT) Engine

TDT engine translates any EPC format to other EPC format(Binary encoding, Tag-encoding

















17

URI, Pure Identity URI, or ONS Hostname)

Specification: http://www.gs1.org/gsmp/kc/epcglobal/tdt/tdt_1_6_RatifiedStd-20111012-

i2.pdf

Fosstrak TDT engine: http://code.google.com/p/fosstrak/wiki/TdtDownload

Step 7 : Publisher’s role ( KAIST )

Step 8 Returned NAPTR Records are logically represented like this

Figure 10. Returned NAPTR Records from ONS

c.f.

Order : FIXED, it’s for Future Spec.

Pref : non-negative integer which specifies the service in one record is preferred to the

service in another record having the same Service field.

Flags : FIXED to “u”, it indicates the Regexp field contains a URI.

Service : Indicates the type of service and must be named by EPC+<service-name>. Current

Specification provides 4 services; Web-service (ws), EPCIS (epcis), HTML (html), XML-

RPC (xmlrpc)

Replacement : FIXED to ‘.’, and not used by EPC Network

Regexp: indicates service URL such as “!^.*$!<service-URL>!” Processing ONS Query Responses :

ONS Clients SHALL use the following procedures to interpret the results returned by

an ONS query

Procedures:

1. The result from the ONS query is a set of NAPTR records

2. From among the results from Step 1, select those records whose Service field names

the desired service. If there is no such record, stop: a pointer to the desired service is

not available from ONS for the specified EPC.

3. From among the results from Step 2, select those records having the lowest value in

the Pref field.

4. From among the results from Step 3, select a record at random.

5. Extract the service URL from the record from Step 4, by extracting the substring

between the initial !^.*$! and the final ! character.

6. Attempt to use the service URL from Step 5.

7. If Step 6 is not successful, go back to Step 4, using a different record from among the

records from Step 3.

If all records from Step 3 have been tried, go back to Step 3 using records from Step 2

having the next lowest value in the Pref field.

If all records from Step 2 have been tried, stop: no service is available.

http://www.gs1.org/gsmp/kc/epcglobal/tdt/tdt_1_6_RatifiedStd-20111012-i2.pdf























http://code.google.com/p/fosstrak/wiki/TdtDownload
















18

3) Summarized ONS Sequence Diagram

Figure 11. ONS Sequence Diagram

3.4.2 Description of STIS interface

Regarding STIS interaction, a set of terminologies to explain the interface is presented.

EPCIS Accessing Application (AA): A client of EPCIS to which EPCIS data is

delivered. AA is responsible for carrying out overall enterprise business processes

such as warehouse management, shipping and receiving, historical throughput

analysis, and so forth, aided by EPC-related data.

EPCIS Capturing Application (CA): A client to capture the ALE events and to route

them to EPCIS Repository.

EPCIS Repository: It records ALE events generated by one or more CAs and makes

them available for later queries by AA.

EPCIS Interfaces: The interfaces through which EPCIS data is delivered to

enterprise-level roles including EPCIS Repositories and AAs. There are three EPCIS

interfaces: EPCIS Capture Interface, EPCIS Query Control Interface, and EPCIS

Query Callback Interface.

EPCIS Capture Interface: Interface to define the delivery of ALE events from

CAs to other roles that consume the data in real time including EPCIS

Repositories and real-time “push” to AA.

EPCIS Query Interface: Interface to define the means for AA to obtain EPCIS

data. In “on-demand” or “synchronous” mode, a client makes a request through

the EPCIS Query Control Interface and receives a response immediately. In

“standing request” or “asynchronous” mode, a client establishes a subscription

for a periodic query. Each time the periodic query is executed, the results are

delivered asynchronously (or “pushed”) to a recipient via the EPCIS Query

Callback Interface.

EPCIS Callback Interface: Interface to define the means for AA to obtain

EPCIS data asynchronously. The EPCIS Query Interface registers the AA‘s


19

subscription. When the event is occurred, event is sent to the AA via the EPCIS

Callback Interface.

Figure 12. EPCIS Structure

In order to retrieve EPCIS data from EPCIS repository, AA sends a query through EPCIS

Query Interface. The EPCIS specification defines the EPCIS Query Interface using UML, and

the interface consists of EPCIS Query Control Interface and EPCIS Query Callback Interface.

The specification also defines bindings which are related to concrete realizations of the

interface. SOAP over HTTP binding via WSDL is one of such implementations.

From GS1 website, a client can get a WSDL file to describe EPCIS Query Interface with

related XML schema files (i.e.,http://www.gs1.org/gsmp/kc/epcglobal/epcis/epcis_1_0-

schema-20070412/). Then, the client can generate an EPCIS query client source code from the

WSDL using a code-conversion tool like wsdl2java. The client implements AA with the

generated EPCIS query client source code. Finally, the AA gets the EPCIS address which is

retrieved from ONS to access EPCIS.

The usages of the EPCIS interface methods are summarized in the following tables.

1) EPCIS Query Control Interface:

Method Description

subscribe (queryName:String, params:QueryParams, dest:URI, controls:SubscriptionContr

ols, subscriptionID:String)

Registers a subscriber for a previously defined query having

the specified name. The “params” argument provides the values

to be used for any named parameters defined by the query. The

“dest” parameter specifies a destination where results from the

query are to be delivered, via the Query Callback Interface. The

“dest” parameter is an URI that both identifies a specific binding

of the Query Callback Interface to use and specifies addressing

information. The “controls” parameter controls how the

subscription is to be processed; in particular, it specifies the

conditions under which the query is to be invoked (e.g.,

specifying a periodic schedule). The “subscriptionID” is an

arbitrary string that is copied into every response delivered to the

specified destination, and otherwise not interpreted by the EPCIS

service. The client may use the “subscriptionID” to identify from

http://www.gs1.org/gsmp/kc/epcglobal/epcis/epcis_1_0-schema-20070412/

http://www.gs1.org/gsmp/kc/epcglobal/epcis/epcis_1_0-schema-20070412/


20

which subscription a given result was generated, especially when

several subscriptions are made to the same destination. The “dest” parameter MAY be “null” or empty, in which case

results are delivered to a pre-arranged destination based on the

authenticated identity of the caller. If the EPCIS implementation

does not have a destination pre-arranged for the caller, or does

not permit this usage, it SHALL raise an “InvalidURIException”.

unsubscribe

(subscriptionID:String)

Removes a previously registered subscription having the

specified “subscriptionID”.

poll

(queryName:String,

params:QueryParams)

: QueryResults

Invokes a previously defined query having the specified name

that returns the results. The “params” parameter provides the

values to be used for any named parameters defined by the query.

getQueryNames () : List Returns a list of all query names available for using with the

“subscribe” and “poll” methods. This includes all pre-defined

queries provided by the implementation, including those

specified in Section 8.2.7.

getSubscriptionIDs

(queryName:String)

Returns a list of all “subscriptionIDs” currently subscribed to

the specified named query.

getStandardVersion() Returns a string that identifies what version of the

specification this implementation complies with. The possible

values for this string are defined by EPCglobal. An

implementation SHALL returns a string corresponding to a

version of this specification to which the implementation fully

complies, and SHOULD return the string corresponding to the

latest version to which it complies. To indicate compliance with

this Version 1.0 of the EPCIS specification, the implementation

SHALL return the string 1.0.

getVendorVersion() Returns a string that identifies what vendor extensions this

implementation provides. The possible values of this string and

their meanings are vendor-defined, except that the empty string

SHALL indicates that the implementation implements only

standard functionality with no vendor extensions. When an

implementation chooses to return a non-empty string, the value

returned SHALL be an URI where the vendor is the owning

authority. For example, this may be an HTTP URL whose

authority portion is a domain name owned by the vendor, an

URN having a URN namespace identifier issued to the vendor by

IANA, an OID URN whose initial path is a Private Enterprise

Number assigned to the vendor, etc.

2) EPCIS Query Callback Interface:

callbackResults(resultData : QueryResults) : void

callbackQueryTooLargeException(e : QueryTooLargeException) : void

callbackImplementationException(e : ImplementationException) : void

Each time EPCIS generates the event for the standing query, EPCIS delivers the result to the

subscriber by invoking one of the three method of the EPCIS Query Callback Interface. The


21

results from the EPCIS can be the event or error. If the result is event, EPCIS invokes the

callbackResults method with result data. If the result is error, EPCIS invokes the

callbackQueryTooLargeException or callbackImplementationException with error.

cf. ImplementationException is implementation-specific exception and

QueryTooLargeException is occurred, when the subscription generates more events than the

EPCIS was willing to provide.

There are predefined queries having different purpose.

3) Predefined Queries:

(1) SimpleEventQuery

The SimpleEventQuery is defined to return a set of events that match the criteria

specified in the query parameters (as specified below). When returning events were

captured via the EPCIS Capture Interface, each event SHALL be identical to the

originally captured event.

This query is invoked by specifying the string SimpleEventQuery as the queryName

parameter to poll or subscribe. The result is a QueryResults instance whose body

contains a (possibly empty) list of EPCISEvent instances. Unless constrained by the

eventType parameter, each element of the result list could be of any event type; i.e.,

ObjectEvent, AggregationEvent, QuantityEvent, TransactionEvent, or any extension

event type that is a subclass of EPCISEvent.

(2) SimpleMasterDataQuery The result of this query is a QueryResults instance whose body contains a (possibly empty)

list of vocabulary elements together with selected attributes. This query is invoked by

specifying the string SimpleMasterDataQuery as the queryName argument to poll (not to

subscribe).

3.4.3 Example applications

1) Prerequisite

It is assumed a client already has STIS and ONS. Since a real-world implementation

of STIS is based on EPCglobal architecture, instead of STIS this document shows a

use-case of an EPCIS, which provides information about things using EPC as a

unique ID.

Assumption

At the server site, the following information is assumed to be given.

- Epc : urn:epc:id:sgtin:369783.6810725.52500494167 ( pure-entity URI )

- Host Name of EPC : 6810725.369783.sgtin.id.onsepc.com

- ONS address : dns://[2002:8ff8:6a87::8ff8:6a87]

- EPCIS Query Interface URL : http:// [2002:8ff8:6a89::8ff8:6a89]/epcis-

repository-0.4.2/query

The client’s address scheme already enables IPv6 Stack (e.g. 6to4 tunneling )

Ex: windows xp


22

> netsh interface ipv6 install

We use named for DNS.

2) ONS

For supporting IPv6 target address, a client should follow this.

In a <DNS>/etc/named.conf file, adding this information

options {

version "unknown";

directory "C:\work\dns\var\named";

dump-file "..\tmp\named_dump.db";

statistics-file "..\tmp\named.stats";

pid-file "..\run\named.pid";

listen-on-v6 {any; };

};

Adding Zone to <DNS>/etc/named.conf

zone "369783.sgtin.id.onsepc.com" {

type master;

file "369783.sgtin.id.onsepc.com-zone";

allow-update {none;};

};

Creating Zone to <DNS>/var/named/369783.sgtin.id.onsepc.com $TTL 86400 ; 1 day

@ IN SOA ns.369783.sgtin.id.onsepc.com. hostmaster.company.co.kr. (

2008010801 ; serial

21600 ; refresh (6 hours)

1800 ; retry (30 minutes)

1209600 ; expire (2 weeks)

86400 ; minimum (1 day)

)

IN NS ns.369783.sgtin.id.onsepc.com.

ns.369783.sgtin.id.onsepc.com. IN A 127.0.0.1

$ORIGIN 369783.sgtin.id.onsepc.com.

52 IN NAPTR 0 1 "u" "C2U+mois:web" "!^.*$!http://epc.onlinesensors.net/product/sn1.html!" .

800031 IN NAPTR 0 0 "u" "EPC+x-metadata"

"!^.*$!http://epc.onlinesensors.net/metadata_exchanges.asmx?WSDL!" .

800031 IN NAPTR 0 1 "u" "EPC+x-metadata"

"!^.*$!http://epc.onlinesensors.net/metadata_exchanges.asmx/things!" .

800031 IN NAPTR 0 2 "u" "EPC+x-metadata" "!^.*$!http://epc.onlinesensors.net/product/000024/index.html!" .

6810725 IN NAPTR 0 0 "u" "EPC+epcis" "!^.*$!http://[fe80::217:a4ff:fe78:6033]/epcis-repository-

0.4.2/query!" .

Ex : this zone represents 369783.sgtin.id.onsepc.com, so if someone wants to resolve

“6810725.369783.sgtin.id.onsepc.com” as a NAPTR Type, DNS will return 0 0 "u" "EPC+epcis"

"!^.*$!http://[fe80::217:a4ff:fe78:6033]/epcis-repository-0.4.2/query!"

3) EPCIS

There is no additional task for using EPCIS with IPv6.

4) Simple Application Example

This section describes an example of accessing ONS and EPCIS, detail of which is described

in Figure. 11. The sample application operates as follows.


23

Phase 1 : Using TDTEngine

An EPC will be translated to ONS HostName by TDTEngine

Phase 2 : DNS Resolving via ONS

Translated ONS Hostname of the EPC will go to the ONS, then a client can get

EPCIS URL. Finally, the client can get manufacturer information from

<returned EPCIS address>/WS/<queried EPC>.ws 이

Phase 3 : Using EPCIS(Poll) – one time query

Clients can query with EPC ( our case is urn:epc:id:sgtin:1234567.000001.7 )

by using simple event query, this example contains 3 query types ( eventType,

MATCH_epc, GE_eventTime ), further information can be get from

http://www.gs1.org/gsmp/kc/epcglobal/epcis/epcis_1_0_1-standard-20070921.pdf

Phase 4 : Using EPCIS(subscribe) – scheduled query, triggered query

Clients can use scheduled query with EPC

once clients subscribe with simple event query, they can get the response from

selected port such as localhost:8899. ( current Fosstrak implementation is not able to

modify port )

Implementation specific question can be solved from

“http://code.google.com/p/fosstrak/wiki/EpcisUserGuide”

ONSTest java project

There are many libraries in lib folder, because EPCIS Query Interface API has hard

dependency with many libraries. Clients just add all libraries in lib folder.

If a client debugs this code step by step, the following codes are easily interpreted.

This is the console output. Put your EPC :

host name of EPC : 6810725.369783.sgtin.id.onsepc.com

Returned Service related to EPC : 0 0 u EPC+epcis !^.*$!http://[2002:8ff8:6a89::8ff8:6a89]/epcis-repository-

0.4.2/query! .

We need 3th and 4th information of parsed string

If you want to know more detail, you can use [ONS] specification

0th : 0

1th : 0

2th : u

3th : EPC+epcis

4th : !^.*$!http://[2002:8ff8:6a89::8ff8:6a89]/epcis-repository-0.4.2/query!

5th : .

Service End Point will be !^.*$!<service end point>!

So, Service End Point : http://[2002:8ff8:6a89::8ff8:6a89]/epcis-repository-0.4.2/query

We will use the convention for giving you Manufacturer information like this :

<returned EPCIS address>/WS/<queried EPC>.wsdl

So, You can get MANUFACTURER Information from :

http://[2002:8ff8:6a89::8ff8:6a89]/epcis-repository-0.4.2/query/WS/6810725.369783.sgtin.id.onsepc.com.wsdl

log4j:WARN No appenders could be found for logger (org.apache.cxf.common.logging.LogUtils).

log4j:WARN Please initialize the log4j system properly.

2012-01-18T20:30:59.548+09:00

<ns3:QueryResults xmlns:ns2="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader"

xmlns:ns4="urn:epcglobal:epcis:xsd:1" xmlns:ns3="urn:epcglobal:epcis-query:xsd:1"

xmlns:ns5="urn:epcglobal:epcis-masterdata:xsd:1">

<queryName>SimpleEventQuery</queryName>

<resultsBody>

<EventList>

<ObjectEvent>

<eventTime>2012-01-18T11:30:59.000Z</eventTime>

http://www.gs1.org/gsmp/kc/epcglobal/epcis/epcis_1_0_1-standard-20070921.pdf

http://code.google.com/p/fosstrak/wiki/EpcisUserGuide


24

<recordTime>2012-01-18T11:31:00.000Z</recordTime>

<eventTimeZoneOffset>+09:00</eventTimeZoneOffset>

<epcList>

<epc>urn:epc:id:sgtin:369783.6810725.52500494167</epc>

</epcList>

<action>ADD</action>

<bizStep>urn:fosstrak:demo:bizstep:warehouse</bizStep>

<disposition>urn:fosstrak:demo:disp:testing</disposition>

<bizLocation>

<id>urn:fosstrak:demo:loc:1.1</id>

</bizLocation>

</ObjectEvent>

<ObjectEvent>




<epcList>


</epcList>




<bizLocation>


</bizLocation>

</ObjectEvent>

……

<ObjectEvent>




<epcList>


</epcList>




<bizLocation>


</bizLocation>

</ObjectEvent>

</EventList>

</resultsBody>

</ns3:QueryResults>

Subscription Done, you can get the callback event in http://localhost:8899

3.5 Communication complexity and cost analysis

3.5.1 Communication cost of CoAP implementation

This section shows evaluations of CoAP implementation according to the varying number of

concurrent connections and the number of hop counts. The first evaluation is reported in

Figure 13. The completion time in this figure is the time to take from initiating all CoAP

requests to a thing to fully retrieving thing’s information for all requests. As seen in the figure,

it takes 3506ms for thing’s live information (e.g., 30degreeC) to be retrieved by CoAP

protocol for 12 concurrent connections, which is suitable for the IoT context.


25

Figure 13. CoAP completion time by number of concurrent connection

Figure 14. Round trip time by number of hop counts

In the evaluation reported in Figure 14, for one request to a thing round trip time is measured

according to the number of hops counts on IEEE 802.15.4 network level. The time is

measured in millisecond between PAN Coordinator and thing nodes. As the hop counts grow,

more time is needed for the request to be fulfilled. As seen in the figure, the CoAP protocol

performs very well when only 190ms is required to retrieve the sensing data through 5 hops.

The table below further reports these evaluations in a time decomposition fashion. From this

table the CoAP protocol is shown to be really lightweight since it does not require any

connection setup procedure which is opposite to HTTP/TCP protocol.

Table 1. CoAP evaluation in time decomposition

Hops count 1 2 3 4 5

coap coap coap Coap coap

1 Conn setup 0.00 0.00 0.00 0.00 0.00

Request 2.62 2.62 2.62 2.62 2.62

Receive 113.02 7.25 6.04 6.30 6.93


26

2 Conn setup 0.00 0.00 0.00 0.00

Request 5.63 5.77 7.81 5.69

Receive 115.79 7.93 6.65 6.02

3 Conn setup 0.00 0.00 0.00

Request 5.70 5.16 6.85

Receive 121.23 6.02 17.56

4 Conn setup 0.00 0.00

Request 6.63 7.40

Receive 116.42 6.30

5 Conn setup 0.00

Request 8.31

Receive 123.08

Total time 115.64 131.29 149.28 157.62 190.75

3.5.2 Communication cost between heterogeneous things and other components such as STIS and ONS

1) Lookup Cost of ONS query

Complexity of processing ONS queries in the network is mainly affected by the structure of

ONS cloud. In order to process ONS-hostname of ONS query, the ONS namespace such as

root, manufacturer, and product information should be hierarchically structured, and the

processing cost of the ONS queries depend on the number of comparisons in the namespace

hierarchy. For example, as described in Figure 15, eight-level comparisons are needed to

process an ONS-hostname, “000024.0614141.sgtin.id.onsepc.com”. Specifically, the

comparison operations are invoked in Local DNS, DNS root, organization-type DNS (com),

organization-DNS (onspec), epc-name-type DNS (id), GS1-key-type DNS (sgtin), company-

prefix DNS (0614141), and product DNS (000024). Each DNS does not need to be a real

DNS server; the several namespace can be implemented in one server and vice versa.

Nevertheless, the number of comparison is not changed.

Figure 15. ONS comparison hierarchy


27

Different from DNS hostname of variable size, the depth of ONS hostname is fixed because it

is generated from an EPC code which can have only information of manufacturer, product,

and serial number. So, it can expect that the number of comparisons does not increase

vertically. Other things being equal such as ordinary DNS components, the number of

comparisons in ONS depends only on the number of manufacturers and products.

It is said that most ONS query processing burden can be concentrated first on the GS1-key-

type DNS which does comparisons of manufacturer code. This is because there are a great

number of manufacturers in the world, and they are hierarchically at the same level. If GS1-

key-type DNS uses binary search to compare manufacturer code, then the complexity will be

O(log nm) where nm is the number of manufacturers. Likewise, product codes in a

manufacturer DNS can be compared in O(log np) where np is the maximum number of

products of each manufacturer. Comparison cost of GS1 keys is constant because there are

only 9 GS1 keys. There is no actual comparison in EPC name type because the entire ONS

hostnames end with id.onsepc.com, and EPC name type is fixed as “id”. Therefore, the worst

case complexity of comparisons for each ONS query is:

O( log nm + log np ) + dns_comparison_cost (“onsepc.com”)

Once each ONS query is successfully returned with EPCIS address, it is cached in the local

DNS server so that subsequent ONS queries can be processed using only the local DNS

server.

2) Empirical evaluations on query response time

Description of experiments

For reporting communication costs between heterogeneous smart things through

unique identifier, extensive experiments are conducted. The first experiment is for

measuring the communication cost between an IPv6 client and ONS (on the top of

Figure 16). The second experiment is for measuring the communication cost between

an IPv6 client and EPCIS (to the bottom of Figure 16). This experiment contains three

query types. First one gets the exact one object event by given EPC. Second one gets

the five object events by given EPC. Third one gets the ten object events by given

EPC.

Figure 16. Experimental setup on KAIST

Performance Results

The environment of first experiment is as follow:

ONS Client is operated on Intel i7-870 2.93Ghz quad-core CPU and 8 GB RAM and

ONS Server is operated on Intel® Xeon™ 2.80Ghz dual-core CPU and 1GB RAM.


28

Example of EPC is - urn:epc:id:sgtin:369783.6810725.52500494167, the pure-identity

URI. It is translated to the - 6810725.369783.sgtin.id.onsepc.com, the ONS-hostname by

TDT-Engine. Then, ONS Client queries to the - [2002:8ff8:6a87::8ff8:6a87] (ONS IP-

address) with 6810725.369783.sgtin.id.onsepc.com. Finally, ONS Server gives 0 0 “u“ “EPC+epcis" ”!^.*$!http://[2002:8ff8:6a89::8ff8:6a89]/epcis-repository-0.4.2/query!“

to the ONS Client.

We measured the query response delay between query and response with 8,000 times

repetitions. Fig. 17 shows empirical cumulative distribution function (ECDF) of ONS

response time in log scale where its average response time is about 800 us.

Figure 17. CDF of ONS Response Time

The environmental setup of the second experiment is as follow. EPCIS Client is

operated on Intel i7-870 2.93Ghz quad-core CPU and 8 GB RAM and EPCIS Server

is operated on Intel® Xeon™ 2.80Ghz dual-core CPU and 1GB RAM. The second

experiment is measured 8,000 times with each query types. Fig. 8 shows that ECDF

of EPCIS Query response time in log scale while varying the number of event

parameters included in query response. The average response times of ‘Query 1#

event’, ‘Query 5# event’ and ‘Query 10# event’ are 0.0339 s, 0.0520 s, and 0.0737 s,

respectively.

Figure 18. CDF of EPCIS Query Response Time


29

The average response times of each experiment appear in the following table, and this result

shows that the communication cost of STIS is acceptable.

Table 2. Average response times for different experiments

Experiment type Average response time (second)

ONS Response Time 8.382432794019198e-04

EPCIS Query Response Time ( 1# ) 0.0339




30

[4] Conclusion

The objective of this deliverable is to report unique identifier analysis and integration of STIS,

ONS, and IoT6. As a result, this report has explored and analyzed various unique identifiers

such as Uniform Resource Identifier (URI), Handle System Micro ID (uID), Object Identifier

(OID), Universally Unique Identifier (UUID), and Electronic Product Code (EPC), etc. Thus,

we have reported that URI could be desirable for the identifier to enable interoperation among

heterogeneous identifiers.

Together with this analysis, this deliverable has presented the interface specification and

interaction flows for interoperability between IoT6, STIS, and ONS and has described the

STIS test-bed in KAIST, which allows the IoT6 or other clients to access STIS over a public

IPv6 network. Based on this test-bed, this report has also analyzed complexity and

communication costs between heterogeneous smart things through the IPv6 network as well

as between IoT6, STIS and ONS. In particular, IP-WSN nodes are used as a smart thing and

the communication cost of CoAP protocol has been analyzed.

Overall, this report has presented interoperability issues like the potential use of URI for an

integrated identifier system and interaction between STIS, ONS, and IoT6. The

communication cost analysis based on real-world test-bed has provided a more practical

performance analysis and feasibility regarding real-world interaction.


31

[5] Reference

1. T. Berners-Lee, R. Fielding, L. Masinter, “Uniform Resource Identifiers (URI): Generic

Syntax,” IETF RFC 2396, Aug. 2007.

2. S. Sun, L. Lannom, B. Boesch, “Handle System Overview,” IETF RFC 3650, Nov. 2003.

3. J. Miller, F. Stutzman, “MicroID,” IETF Internet-Draft, Dec. 2007.

4. Microsoft/TechNet Objective Identifier, website: http://technet.microsoft.com/en-

us/library/cc961749.aspx

5. P. Leach, M. Mealling, R.Salz, “A Universally Unique Identifier (UUID) URN

Namespace,” IETF RFC4122, Jul. 2005.

6. Reference: The International DOI Foundation (IDF), website: http://www.doi.org

7. GS1, “EPCglobal Tag Data Standard v1.6”,

http://www.gs1.org/gsmp/kc/epcglobal/tds/tds_1_6-RatifiedStd-20110922.pdf

8. GS1, “EPCglobal Architecture Framework v1.4” ,

http://www.gs1.org/gsmp/kc/epcglobal/architecture/architecture_1_4-framework-

20101215.pdf

9. BarCodes and eComTM

“An Introduction to the Global Trade Item Number (GTIN)”,

website: http://www.gs1us.org/resources/standards/gtin

10. BarCodes and eComTM

“An Introduction to the Global Location Number (GLN)”,

website: http://www.gs1us.org/resources/standards/gln

11. GS1, “SSCC Executive Summary”, website:

http://www.gs1.org/sites/default/files/docs/idkeys/GS1_SSCC_Executive_Summary.pdf

12. GS1, “GIAI Executive Summary”, website:

http://www.gs1.org/sites/default/files/docs/idkeys/GS1_GIAI_Executive_Summary.pdf

13. GS1, “GSRN Executive Summary”, website:

http://www.gs1.org/sites/default/files/docs/idkeys/GS1_GSRN_Executive_Summary.pdf

14. R. Want, “An Introduction to RFID Technology,” IEEE Pervasive Computing, 5, 1,

January-March 2006, pp. 25-33

15. Reference: Esper Complex Event Processing Engine, website :

http://esper.codehaus.org/esper/documentation/documentation.html

16. GS1, “Object Naming Service (ONS) Standard”, website:

http://www.gs1.org/gsmp/kc/epcglobal/ons/ons_1_0_1-standard-20080529.pdf

17. Seong Hoon Kim, Janggwan Im, Jaewook Byun, Kwangkook Lee, Daeyoung Kim,

Cedric Crettaz, Sebastien Ziegler," Enabling A Global Infrastructure for

Physical Information Sharing over the Internet," to appear as Demo paper in The 3rd

International Conference on the Internet of Things (IoT 2012) Wuxi, China, October 24-

26, 2012.

http://www.gs1.org/gsmp/kc/epcglobal/tds/tds_1_6-RatifiedStd-20110922.pdf

http://www.gs1.org/gsmp/kc/epcglobal/architecture/architecture_1_4-framework-20101215.pdf

http://www.gs1.org/gsmp/kc/epcglobal/architecture/architecture_1_4-framework-20101215.pdf

http://www.gs1us.org/resources/standards/gtin

http://www.gs1us.org/resources/standards/gln

http://www.gs1.org/sites/default/files/docs/idkeys/GS1_SSCC_Executive_Summary.pdf

http://www.gs1.org/sites/default/files/docs/idkeys/GS1_GIAI_Executive_Summary.pdf

http://www.gs1.org/sites/default/files/docs/idkeys/GS1_GSRN_Executive_Summary.pdf

http://esper.codehaus.org/esper/documentation/documentation.html

http://www.gs1.org/gsmp/kc/epcglobal/ons/ons_1_0_1-standard-20080529.pdf


32

[6] Appendix

Source – ONSTest.java /*

* 2012 RESL KAIST in KOREA

* Realtime Embedded System Laboratory

* Author :

* Name : Jaewook Byun. Master Student in RESL KAIST

* Mail : [email protected]

*

* This file is simple program making you to easily use ONS and EPCIS

*

*/

import java.io.IOException;

import java.util.ArrayList;

import java.util.GregorianCalendar; import java.util.HashMap;

import java.util.Hashtable;

import java.util.Map;

import org.apache.axis.types.Time;

import org.epcglobalinc.tdt.LevelTypeList; import org.fosstrak.epcis.model.ArrayOfString;

import org.fosstrak.epcis.model.Poll;

import org.fosstrak.epcis.model.QueryParam; import org.fosstrak.epcis.model.QueryParams;

import org.fosstrak.epcis.model.QueryResults;

import org.fosstrak.epcis.model.QuerySchedule; import org.fosstrak.epcis.model.Subscribe;

import org.fosstrak.epcis.model.SubscriptionControls;

import org.fosstrak.epcis.queryclient.QueryControlClient;

import org.fosstrak.epcis.soap.DuplicateSubscriptionExceptionResponse;

import org.fosstrak.epcis.soap.ImplementationExceptionResponse;

import org.fosstrak.epcis.soap.InvalidURIExceptionResponse; import org.fosstrak.epcis.soap.NoSuchNameExceptionResponse;

import org.fosstrak.epcis.soap.NoSuchSubscriptionExceptionResponse; import org.fosstrak.epcis.soap.QueryParameterExceptionResponse;

import org.fosstrak.epcis.soap.QueryTooComplexExceptionResponse;

import org.fosstrak.epcis.soap.QueryTooLargeExceptionResponse; import org.fosstrak.epcis.soap.SecurityExceptionResponse;

import org.fosstrak.epcis.soap.SubscribeNotPermittedExceptionResponse;

import org.fosstrak.epcis.soap.SubscriptionControlsExceptionResponse; import org.fosstrak.epcis.soap.ValidationExceptionResponse;

import org.fosstrak.epcis.utils.QueryResultsParser;

import org.fosstrak.tdt.TDTEngine;

import java.util.Scanner;

import javax.naming.NamingEnumeration;

import javax.naming.NamingException;

import javax.naming.directory.Attributes; import javax.naming.directory.DirContext;

import javax.naming.directory.InitialDirContext;

import javax.xml.datatype.DatatypeConfigurationException; import javax.xml.datatype.DatatypeFactory;

import javax.xml.datatype.XMLGregorianCalendar;

public class ONSTest {

/**

* @param args

* @throws DatatypeConfigurationException

* @throws QueryParameterExceptionResponse

* @throws SubscriptionControlsExceptionResponse

* @throws NoSuchNameExceptionResponse

* @throws SubscribeNotPermittedExceptionResponse

* @throws ValidationExceptionResponse

* @throws InvalidURIExceptionResponse

* @throws SecurityExceptionResponse

* @throws QueryTooComplexExceptionResponse

* @throws ImplementationExceptionResponse

* @throws DuplicateSubscriptionExceptionResponse

* @throws NoSuchSubscriptionExceptionResponse

*/

public static void main(String[] args) throws DatatypeConfigurationException, DuplicateSubscriptionExceptionResponse,

ImplementationExceptionResponse, QueryTooComplexExceptionResponse, SecurityExceptionResponse, InvalidURIExceptionResponse, ValidationExceptionResponse, SubscribeNotPermittedExceptionResponse, NoSuchNameExceptionResponse,


33

SubscriptionControlsExceptionResponse, QueryParameterExceptionResponse, NoSuchSubscriptionExceptionResponse { // TODO Auto-generated method stub

// Phase 1 : Using TDTEngine // TDTEngine for translating any epc format to ONS hostname

// Initialize

TDTEngine engine = null; Map<String, String> params;

params = new HashMap<String, String>();

if( engine == null ) {

try

{ engine = new TDTEngine();

}

catch ( Exception e ) {

e.printStackTrace(System.err);

}

}

System.out.println("Put your EPC : "); Scanner scan = new Scanner(System.in);

//String epc = scan.next();

String epc = "urn:epc:id:sgtin:369783.6810725.52500494167"; //pure-entity URL has no length information, so you should have parameter

params.put("taglength", "96");

//Run the TDT Engine // convert( source epc, parameters, target type )

String hostName = engine.convert(epc, params, LevelTypeList.ONS_HOSTNAME);

//You get Host Name Of EPC System.out.println("host name of EPC : "+ hostName);

//Phase 2 : DNS Resolving via ONS //We use JNDI for using DNS

String serviceEndPoint = "";

try {

Hashtable<String, String> env = new Hashtable<String,String>(); // JNDI Properties

env.put("java.naming.factory.initial", "com.sun.jndi.dns.DnsContextFactory");

// IPv6 address of ONS env.put("java.naming.provider.url", "dns://[2002:8ff8:6a87::8ff8:6a87]");

// Variable Initialize

Attributes returnAttributes = null; NamingEnumeration attributeEnum = null;

ArrayList results = new ArrayList();

DirContext ictx = new InitialDirContext(env);

//ONS use NAPTR Type

returnAttributes = ictx.getAttributes(hostName, new String[]{"NAPTR"}); if(returnAttributes.size() > 0) {

attributeEnum = returnAttributes.get("NAPTR").getAll();

while(attributeEnum.hasMore()) results.add((String)attributeEnum.next()); }

String result;

String[] subResults = null; //ONS can returns several records ( Service )

//This scenario only returns 1 record ( EPCIS Service )

for( int i = 0 ; i < results.size() ; i ++ ) {

result = (String)results.get(i);

System.out.println("Returned Service related to EPC : " + result); //Split by delimiter " " <-- whitespace

subResults = result.split(" ");

System.out.println("We need 3th and 4th information of parsed string"); System.out.println("If you want to know more detail, you can use [ONS] specification");

for( int j = 0 ; j < subResults.length ; j++)

{ String subResult = subResults[j];

System.out.println("\t" + j +"th : " +subResult);

} }

//Service End Point will be !^.*$!<service end point>!

System.out.println("Service End Point will be !^.*$!<service end point>!"); serviceEndPoint = subResults[4].substring(6, subResults[4].length()-1);

System.out.println("So, Service End Point : " + serviceEndPoint);

//We will use the convention for giving you Manufacturer information like this : //<returned EPCIS address>/WS/<queried EPC>.wsdl

System.out.println("We will use the convention for giving you Manufacturer information like this :");


34

System.out.println("<returned EPCIS address>/WS/<queried EPC>.wsdl"); System.out.println("So, You can get MANUFACTURER Information from : ");

System.out.println(serviceEndPoint+"/WS/"+hostName+".wsdl");

} catch( NamingException ne)

{

ne.printStackTrace(); }

//Phase 3 : Using EPCIS ( Poll ) //We already have epcis url from ONS

String epcisURL = serviceEndPoint;

//String epcisURL = "http://[fe80::217:a4ff:fe78:6033]/epcis-repository-0.4.2/query"; //Initialize Query ControlClient

QueryControlClient client = new QueryControlClient(epcisURL);

//Create Poll //We have one Tag ( urn:epc:id:sgtin:1234567.000001.7 )

Poll poll = createPoll("urn:epc:id:sgtin:1234567.000001.7");

QueryResults qresults;

try {

qresults = client.poll(poll);

//you can use queryResultsToDocument for traslating result to DOM model String dresult = QueryResultsParser.queryResultsToXml(qresults);

System.out.println(dresult);

} catch (ImplementationExceptionResponse e) { // TODO Auto-generated catch block

e.printStackTrace();

} catch (QueryTooComplexExceptionResponse e) { // TODO Auto-generated catch block


} catch (QueryTooLargeExceptionResponse e) { // TODO Auto-generated catch block


} catch (SecurityExceptionResponse e) { // TODO Auto-generated catch block


} catch (ValidationExceptionResponse e) { // TODO Auto-generated catch block

e.printStackTrace(); } catch (NoSuchNameExceptionResponse e) {

// TODO Auto-generated catch block

e.printStackTrace(); } catch (QueryParameterExceptionResponse e) {


e.printStackTrace(); } catch (IOException e) {


e.printStackTrace(); }

//Phase 4 : EPCIS Query Callback Interface for ( Scheduled , Triggered Query )

//EPCIS URL and Query Control Client is already set

//subscription ids cannot be same //unscribe method is client.unsubscribe("<subscriptionID>"); it may be useful for you

Subscribe subscribe = createSubscribe("urn:epc:id:sgtin:1234567.000001.7", "resl14"); //For subscribe you can use Scheduled Query or Triggered Query

//this Example is Scheduled Query. EPCIS will return the queried event every 5 seconds

client.subscribe(subscribe); System.out.println("Subscription Done, you can get the callback event in http://localhost:8899");

} public static Poll createPoll(String epc) throws DatatypeConfigurationException {

//Make Query using SimpleEventQuery

// construct the query parameters

//You can modify event type

QueryParam queryParam1 = new QueryParam(); queryParam1.setName("eventType");

ArrayOfString queryParamValue1 = new ArrayOfString();

queryParamValue1.getString().add("ObjectEvent"); queryParam1.setValue(queryParamValue1);

//You can modify it to MATCH_parentID , MATCH_anyEPC , ...

QueryParam queryParam2 = new QueryParam();


35

queryParam2.setName("MATCH_epc"); ArrayOfString queryParamValue2 = new ArrayOfString();

queryParamValue2.getString().add(epc);

queryParam2.setValue(queryParamValue2);

//You can modify it to LT(Less Than)_eventTime, recordTime ...

QueryParam queryParam3 = new QueryParam(); //Retrieving events by Greater Than Query Parameter

queryParam3.setName("GE_eventTime");

DatatypeFactory dataFactory = DatatypeFactory.newInstance(); XMLGregorianCalendar now = dataFactory.newXMLGregorianCalendar(new GregorianCalendar());

now.setMonth(5);

now.setDay(13); now.setHour(20);

now.setMinute(30);

now.setSecond(59); System.out.println(now.toString());

queryParam3.setValue(now);

QueryParams queryParams = new QueryParams();

queryParams.getParam().add(queryParam1);



//Other query types are avaiable

//bizStep, disposition, readpoint, bizLocation, ... //For more detail, you should refer to http://www.gs1.org/gsmp/kc/epcglobal/epcis/epcis_1_0_1-standard-20070921.pdf

// create the Poll object Poll poll = new Poll();

poll.setQueryName("SimpleEventQuery");

poll.setParams(queryParams); return poll;

}

public static Subscribe createSubscribe(String epc, String subID) throws DatatypeConfigurationException { //Make Query using SimpleEventQuery

// construct the query parameters //You can modify event type

QueryParam queryParam1 = new QueryParam(); queryParam1.setName("eventType");

ArrayOfString queryParamValue1 = new ArrayOfString();

queryParamValue1.getString().add("ObjectEvent"); queryParam1.setValue(queryParamValue1);

//You can modify it to MATCH_parentID , MATCH_anyEPC , ...

QueryParam queryParam2 = new QueryParam();

queryParam2.setName("MATCH_epc"); ArrayOfString queryParamValue2 = new ArrayOfString();

queryParamValue2.getString().add(epc);

queryParam2.setValue(queryParamValue2);

QueryParams queryParams = new QueryParams(); queryParams.getParam().add(queryParam1);


SubscriptionControls controls = new SubscriptionControls();

QuerySchedule querySchedule = new QuerySchedule();

querySchedule.setSecond("3"); DatatypeFactory dataFactory = DatatypeFactory.newInstance();

XMLGregorianCalendar now = dataFactory.newXMLGregorianCalendar(new GregorianCalendar());

now.setYear(2000); now.setMonth(1);

now.setDay(18);

now.setHour(20); now.setMinute(30);

now.setSecond(59);

controls.setInitialRecordTime(now); controls.setReportIfEmpty(true);

controls.setSchedule(querySchedule);

// create the Subscribe object

Subscribe subscribe = new Subscribe();

subscribe.setQueryName("SimpleEventQuery");

// Destination should be your ipv6 localhost full url : 8899

// below is our case subscribe.setDest("http://[2002:8ff8:6a1a::8ff8:6a1a]:8899");

subscribe.setParams(queryParams);


36

subscribe.setSubscriptionID(subID); subscribe.setControls(controls);

return subscribe;

} }

Source – CallbackClass.java /*

* 2012 RESL KAIST in KOREA

* Realtime Embedded System Laboratory * Author :

* Name : Jaewook Byun. Master Student in RESL KAIST

* Mail : [email protected] *

* This file is simple program for getting callback event.

* * FossTrak implementation is now providing socket "localhost:8899"

* So, you should set the destination url as localhost:8899 when you subscribe the event

* */

import java.io.IOException;

import org.fosstrak.epcis.utils.QueryCallbackListener;

public class CallbackClass extends Thread {

/**

* @param args

*/ public static void main(String[] args) {

// TODO Auto-generated method stub

//Simple Thread

Thread t = new CallbackClass();

t.start();

}

public void run() {

try {

//QueryCallbackListener QueryCallbackListener listener;

listener = QueryCallbackListener.getInstance();

while(true) {

//Getting instance

if (!listener.isRunning()) {

//listener start

listener.start();

}

synchronized (listener) { try {

//if getting time is over 20000, you can not get response.

listener.wait(20000); }

catch (InterruptedException e)

{ e.printStackTrace(); }

}

//you can get the result in response variable String response = listener.fetchResponse();

System.out.println(response);

} } catch (IOException e1) {


e1.printStackTrace(); }

}

}

Deliverable D6.1 Unique identifier analysis report and ... - D6.1_0.pdf · IoT6 D6.1 First report...

Documents

Transcript of Deliverable D6.1 Unique identifier analysis report and ... - D6.1_0.pdf · IoT6 D6.1 First report...