finding your way in the internet of things

www.afilias.info

Finding your Way in the

Internet of Things

An Afilias Whitepaper September 2008

Finding Your Way in the Internet of Things © 2008 Afilias Limited www.afilias.info/ads

EXECUTIVE SUMMARY

The Internet of Things (IoT) has been evolving based on the model used for the Internet we are all familiar with: a single authoritative root, with complete interoperability based on common standards. This model has resulted in an IoT architecture that currently consists of ONS (root service), EPCIS (standardized interface for data exchange) and Discovery Service (secure and selective visibility of event data). As adoption progresses, however, the complexities of implementing a single, authoritative ONS root system have stimulated debate focused around 5 main issues:

1. Unique identification of items in a world of diverse identifier authorities (identifier collisions)

2. Backward compatibility with existing identification schemes

3. Concerns regarding control of a “single point of authority” that is outside local boundaries

4. Assurance of practicality, scalability and openness to competition in the provision of services

5. Trust/security and how to ensure that both are at the core of the system

This paper puts forward an architectural approach to ONS that addresses all 5 issues and could serve as a model for a decentralized and interoperable IoT root system. It provides a model for localized ONS that could support a multiplicity of IoT networks and explains the pivotal role of Discovery Services in ensuring both local control and global interoperability.

TOPIC This paper outlines a technical architecture that addresses point of

control issues for tracking items across supply chains and the Internet of Things. This paper presents a simple, distributed, referral model of tracking and tracing items to enable multiple identifier authorities, support the interests of local, regional and national policymakers, and addresses concerns over a fractured Internet of Things architecture. Supply chains are the main focus of this paper and Afilias recognizes that the Internet of Things will be broader than just supply chain elements thereof. However, these architectural concepts apply with equal force beyond supply chain implementations. This paper is offered to facilitate discussion among all Internet of Things stakeholders.

http://www.afilias.info/ads


AUDIENCE The audiences of this paper are stakeholders in the business and

user communities, government and non-government organizations that have an interest in the development of public and private network based tracking and tracing of products, down to the item level, in supply chains.

BACKGROUND For many years, there has been a focused discussion on

how to leverage the Internet to share product information across robust and, in certain instances, global supply chains. The technical community has struggled to articulate the feasibility of different technical solutions and approaches while businesses, governments and consumers have struggled to understand the implications for competitiveness, governance, liability and privacy.

This effort became intensified in 2002 with the formation of EPCglobal1, a standards group primarily focused on the public network enablement of unique identifiers managed by their supporting organization GS1. Born of the former UCC (Uniform Code Council), EPCglobal made great progress, birthing several related standards at the Tag/Reader level, the back-office service to back-office server level (EPCIS2), the public network level, (ONS3) Object Naming Service and the public to private network level, (in-process) “Discovery Services”. Additional, key supportive and parallel efforts were initiated in 2003 by the PROMISE4 group and in 2005 by the BRIDGE5 group, respectively. Another more recently related (and complimentary) standards effort was formed by Afilias at the Internet Engineering Task Force (IETF6) as a protocol effort for Discovery Services7 called ESDS8 (Extensible Supply Chain Discovery Service).

In the simplest terms, these technical efforts have been focused on numerous areas of concern:

1. Standardizing communications between tags and readers. 2. Standardizing direct communications between supply chain

partners’ electronic systems. 3. Enabling network level data exchange through standardizing

the manner in which a given identifier refers to a particular source of further information (i.e. an electronic information service).



THE PROBLEM Many concerns have emerged concerning the tracking of identified

products across the Internet of Things and both public and private networks. Among the biggest concerns are: privacy, control, and the ability for businesses to not just remain competitive in the face of these new technologies, but to actually realize operational and economic advantages. Governments have been concerned, in part, about the ability to exercise oversight over the tracking and tracing of potentially dangerous goods (e.g. foods, pharmaceuticals, etc.). Identifier authorities have been concerned about representing the needs of their respective constituencies. All parties ideally would like to enable tracking products across the supply chain lifecycle but all share concerns that add up to following challenges:

1. Unique identification of items is a key issue. Most parties think

about solving this issue by labeling products with globally unique identifiers. However, maintaining any particular identifier as globally unique, when there are multiple identifier authorities, implies a significant effort of global cooperation. The successful management of fraudulent identities further implies global cooperation between all stakeholders.

2. Identifier Authorities want to continue to manage their unique

identifier schemes and yet leverage the next generation of information exchange. These authorities are in some cases older and well-established and represent a strong constituency. They need a path to move forward and participate while continuing to support existing identifier sets without a next generation third-party identity authority being required to enable them.

3. National and Regional authorities want to ensure that entire

control of this next generation information sharing does not lie exclusively within the power of a specific public or private authority. They want to ensure accountability with respect to local law and policy in any solution for information exchange.

4. All parties want to be assured that any approach is practical,

scalable and allows for open competition in providing these information services.

5. Trust. All parties want to take lessons learned from their collective

experience with the Internet, and DNS in particular, to build architecture and an ecosystem that has a “trust model” at its center.

The proposal in this paper assists with these issues.



ARCHITECTURAL VISION

Afilias believes that DNS provides a publicly available platform that can be leveraged for homing multiple, decentralized ONS services. Identifier Authorities can set up referral systems under any of the existing top level domains (i.e. dotORG) or country top level domains (i.e. dotFR) and establish ONS operations without a next generation third-party identity authority being required to enable them. As long as an Identifier Authority adopts a translation mechanism (such as ONS has done) to translate their identifiers for DNS compatibility, they can ensure uniqueness of their identifiers on public networks. In order to be interoperable, where necessary, Identifier Authorities would have to coordinate amongst themselves to facilitate the look up of their respective identifiers in global supply chains.

The following architectural discussion walks the reader through a basic DNS look up scheme. The purpose is to provide an understanding of the DNS name space from a functional perspective that in turn provides the basis for the proposed ONS solution which simply leverages the DNS namespace to achieve the stated objectives. (For the definition and description of DNS, see the Definitions section at the end of the document.)

It is much easier to describe the solution using examples, however, there are many valid identifier strings and identity authorities so the examples used herein will be very generalized and conceptual. Rest assured, the principles in the examples still apply to all participants. Using the basic problem of track and trace again, suppose a company received a product (a yoyo) and it had not received any advance notice of the yoyo’s identity. This is discovered when the yoyo is received and a look up is executed in the inventory management system. This inventory management system could be a full electronic management system with receiving, shipping and various other components, or it could be just an individual, a spreadsheet and a web-browser. Either way, the company or its employee needs to know what or to whom they should talk to in order to get more information about this product. The identifier printed on the side of the yoyo is expressed as both a barcode and a written identifier string and can be scanned or just read by a human:



For example, assume the identifier string looks like this: “CA.SAMSuniqueidentifiers.Scarborough.BOBSYOYOS.Yoyo.Yoyo64” Let’s break it down and look at what each part of this string means. We’ll start with the part of the string specific to the product: “BOBSYOYOS.Yoyo.Yoyo64” The label sections correspond to the following pieces of information:

BOBSYOYOS = the company that manages the product and attached the label in the first place. Yoyo= the kind of product; it’s a yoyo Yoyo64= a unique serial number that says this is yoyo number “64”

In this example, there’s even more information on this label. It actually says: “CA.SAMSuniqueidentifiers.Scarborough”

in front of that identifier string.

The other labels contain the following information:

CA= Canada SAMSuniqueidentifiers = the international association and manager of YOYO globally unique identifiers. Scarborough = the local branch office of SAMSuniqueidentifiers, who issued this unique identifier to BOBYOYOS.

Again, the entire label now on the Yoyo looks like this:

“CA.SAMSuniqueidentifiers.Scarborough.BOBSYOYOS.Yoyo.Yoyo64”



The next step is to look this up in DNS and find out who should be contacted for more information. The electronic backend system will prepare this string for reading by DNS by turning it around (remember ONS’ role is to prep identifier strings to be read by DNS). Now the identifier is going to look like this:

“Yoyo64.Yoyo.BOBYOYOS.Scarborough.SAMSuniqueidentifiers.CA”

The following illustrative pictures should assist in this deeper analysis of the DNS. When a DNS query for “Yoyo64.Yoyo.BOBYOYOS.Scarborough.SAMSuniqueidentifiers.CA” is made, this is what happens:

The following steps break down what the ISP’s DNS server does with “Yoyo64.Yoyo.BOBYOYOS.Scarborough.SAMSuniqueidentifiers.CA” string in order to tell the person querying with whom they should talk.

1. The ISP’s DNS server looks up the DNS service at the ICANN

root servers for “.CA”, and gets a referral to that DNS service. Assume there are billions of Yoyos in the world. Won’t that cause a problem for ICANN? No, it won’t and the explanation follows later.



2. The look up for “SAMSuniqueidentifiers.CA” gets referred to

the DNS service of SAMS, the identity authority.

3. SAMS refers the querying entity to a DNS service running “Scarborough.SAMSuniqueidentifier.CA”. Why wouldn’t the Identity Authority just tell the querying entity about “Yoyo64.Yoyo.BOBYOYOS.Scarborough.SAMSuniqueidentifiers.CA”? DNS is about delegating. Since SAMS is international, they have a branch office in Scarborough, Canada that handles all the identifiers issued in that locale.

4. Next the ISP’s DNS service asks the DNS service handling

“Scarborough.SAMSuniqueidentifiers.CA” if they have an answer to the whole question “Yoyo64.Yoyo.BOBYOYOS.Scarborough.SAMSuniqueidentifiers.CA” and if the answer is yes, they can now direct the querying entity to an electronic service at that address. However, there’s one more delegation there. It seems that BOBYOYOS is the biggest yoyo producer in the world and while the Scarborough office of SAMSuniqueidentifiers does answer some DNS queries for the smaller Yoyo companies, BOBYOYOS wants to handle its own DNS. So the querying entity is directed to one more DNS service at “BOBYOYOS.Scarborough.SAMSuniqueidentifiers.CA”

5. Finally, after about 70 milliseconds, an answer is provided

from the DNS handling “BOBYOYOS.Scarborough.SAMSuniqueidentifiers.CA” that it has a numerical number for a computer that can answer questions about “Yoyo64.Yoyo.BOBYOYOS.Scarborough.SAMSuniqueidentifiers.CA”. Or, through a special type of DNS record called a Naptr record, more specific referrals can be provided about different types of electronic services willing to talk about “Yoyo64.Yoyo.BOBYOYOS.Scarborough.SAMSuniqueidentifiers.CA” at that computer. These could be websites, backend system API’s, even someone’s phone number.



Here’s a picture of another more familiar identifier string being used with this approach (note the ONS specification has been modified in this example):

This example takes the exact same approach as BOBYOYOS does. To walk through the steps one more time:

1. The querying entity’s ISP DNS server looks up the DNS service at the ICANN root servers for “.FR”, and gets a referral to the .FR DNS service.

2. Next look up is for “GS1.FR” and the DNS service

provides a referral to GS1 Global.

3. GS1 Global refers to a DNS service running “france.gs1.fr”. Why did they do that? If the Identity Authority is querying, why not just respond with “412.000026.0413131.sgtin.france.gs1.fr”? Again, DNS is about delegating, so since GS1 Global is international, they have a country member office in France that handles all the identifiers issued in that locale.

4. Now the ISPs DNS service asks the DNS service

handling “france.gs1.fr” if they have an answer to the



whole question “412.000026.0413131.sgtin.france.gs1.fr” and if the answer is yes, the querying entity can now be directed to an electronic service. However there’s one more delegation there. GS1 France has delegated the next level of DNS to the Product Manager’s DNS service at “0413131.sgtin.france.gs1.fr” that finally provides the full answer to “412.000026.0413131.sgtin.france.gs1.fr”.

5. That answer is a referral to an electronic system such

as a business API (i.e. EPCIS) or a privacy service such as a Discovery Service.

AN OBVIOUS QUESTION

At this point, one might ask how the receiving party who is looking up “412.000026.0413131.sgtin.france.gs1.fr” knows about the “france.gs1.fr” part of the label. There are a few choices for an answer: One approach:

The business application reading the initial identifier can make some decisions about this by conditional rules for example: “FR” The TLD part of the label “FR” in this case is a root/bootstrapping choice for GS1 Global (N.B.This is only an example.). This would be communicated to user of the GS1 identifiers as a common TLD for that identifier authority. The business application would have this as static information. “GS1”

The business application can recognize it has a GS1 identifier and inserts the “GS1” part of the label. “FRANCE” The receiving party is in France. Therefore the business application adds “FRANCE” to the label assuming it wants to refer to GS1 France’s DNS during the lookup process. If the



product was created and labeled in Germany, this model assumes that the shipping product manager would inject relevant entries in GS1 Germany and GS1 France’s DNS. If the product was reshipped to another country, such as Canada, the product manager would place an entry at GS1 Canada’s DNS service. In the case of the global Identifier Authority that does not have any country members or branches, the regional section of this example would be omitted, making things simpler.

A second approach:

Modify existing identifier schemes to support the entire string “412.000026.0413131.sgtin.france.gs1.fr” on the actual identifier. This could be done potentially by using existing allocated but flexible space on current labels and tags.

It’s important to note that everything discussed so far is about finding referrals to sources of information on a public network (e.g. the Internet). However it’s recognized that privacy and selective visibility is a key and desired benefit. In this case, referrals would not lead directly to product manager’s electronic services. Most supply chain partners will want selective visibility and privacy. Most will post their public referrals to lead to secure and selectively visible services like a Discovery Service.



A generic overview of the overall architecture, including privacy services like a Discovery Service, using a generic identifier string “Identifierstring.REGION.IDENTITYAUTHORITY.TLD: is provided below:

Step 1: A look up of the identifier string going from right to left beginning with IDENTITYAUTHORITY.TLD. The TLD choice is a matter of preference in this approach not necessity. The ISP’s DNS service queries the Root server’s DNS service (not shown) then the Identity Authority’s DNS service and is referred to the Identity Authority’s regional branch.

Step 2: The ISP’s DNS service now queries the regional Identity Authority’s DNS service against the “Identifierstring.REGION.IDENTITYAUTHORITY.TLD” can now refer directly to an electronic service such as a Business API (i.e. EPCIS) or a privacy service such as a Discovery Service. Alternatively it can refer to the DNS service of the Product Manager.



Step 3: If the optional referral to the DNS Service of the Product Manager occurs, then the ISP’s DNS service will query the Product Manager’s DNS against “Identifierstring.REGION.IDENTITYAUTHORITY.TLD” and now refers directly to an electronic service such as a Business API (i.e. EPCIS) or a privacy service such as a Discovery Service. Access to the Discovery Service is controlled, and subsequent referrals within the Discovery Service are selectively visible, meaning participants can choose which supply chain partners can see their referrals at all.

SUMMARY A review of the problem points and why this architectural solution

assists or addresses them:

1. Unique identification of items is a key issue and many parties think about solving this issue by labeling products with globally unique identifiers. However, maintaining any particular identifier as globally unique, when there are multiple identifier authorities, implies a significant effort of global cooperation. The successful management of fraudulent identities further infers global cooperation between all stakeholders.

DNS, or ONS if you prefer, by its design is a publically available unique naming and delegation mechanism. As long as an Identifier Authority adopts a translation mechanism (such as ONS has done) to translate their identifiers for DNS compatibility, they can ensure uniqueness of their identifiers on public networks without coordination between Identifier Authorities just by leveraging the existing uniqueness of the Internet hierarchy.

2. Identifier Authorities want to continue to manage their unique

identifier schemes and yet leverage the next generation of information exchange. These authorities are in some cases older and well established and represent a strong constituency. They need a path to move forward and participate while continuing to support existing identifier sets without a next generation third-party identity authority being required to enable them.

Again by leveraging existing DNS systems, and a simple translation mechanism (such as ONS has done), Identity Authorities can leverage public networks by setting up referral systems under any of the existing top level domains (i.e. dotORG) or country top level domains (i.e. dotFR). It’s also important to note that ICANN has now



announced intentions to open the TLD space extensively to new TLDs, therefore another option is to found a new Top Level Domain.

3. National and Regional authorities want to ensure that entire control

of this next generation information sharing does not lie exclusively within the power of a specific public or private authority. They want to ensure accountability of law and policy in any solution for information exchange.

This paper infers the natural point of referral for unique identifiers are the Identifier Authorities that issued them. These Identifier Authorities are already beholden to the laws and policies of the jurisdictions in which they reside. They are the issuers of these identifiers, and hold the direct relationships with the origin product managers for the identifiers.

4. All parties want to be assured that any approach is practical, scalable

and allows for open competition in providing these information services.

This proposal allows for an unlimited number of identifier authorities, different DNS operators can be employed not only at each Identifier Authority, but at each level of DNS resolution, as described in the examples above. It enables referrals to countless electronic business systems, including additional private and selective access referral services such as Discovery Services. DNSSEC (DNS Security) is a recently deployed solution that, if fully propagated, ensures that DNS referrals are from legitimate sources. This type of delegation model allows for traffic volume to be disbursed at the lower, and most distributed levels of DNS delegation. DNS caching, a practice where common top level sections of an identifier name are retained by the requesting (ISP) DNS service, ensures that the top level DNS services are not overtaxed.

5. Trust. All parties want to take lessons learned from their collective

experience with the Internet, and DNS in particular, to build architecture and an ecosystem that has a “trust model” at its center.

By centering the system on diverse identifier authorities who are subject to their respective jurisdictions, the proposal facilitates a decentralized architecture that permits local control but also interoperability and scalability should the participants desire to extend their supply chain or trust network.



Q&A Question #1: Does this propose an alternate root system?

Answer: No. Operationally, a multitude of root servers already exist in the DNS. The DNS root servers operate in a hierarchical structure that takes an “authoritative” addressing list and distributes it across the Internet. “Alternate” implies conflicting addressing in different roots that frustrates universal resolvability. This system proposes a decentralized (not single, unique authoritative) root system that provides flexibility of addressing and interoperability (resolvability) if desired. Question #2: Is this ONS system interoperable with EPCglobal ONS root? Answer: Yes, should the Identifier Authority and the participants in a given chain so choose. If, for some reason, they prefer to operate from a network perspective as a closed user group, or for national security considerations, they can choose to not interoperate across public networks. They can also choose to use a privacy service such as Discovery Services.

Question #3: Will governments control local identifier authorities and create, in some instances, closed islands that are not interoperable? Answer: It depends on the needs of the user group in question. For items that are part of regional, international or global supply chains, the use of unique identifiers and/or interoperable systems is a foundational principle. Commercially, supply chains will likely expand over time and the ability to interoperate with other supply chains will be a compelling impetus for the business community.



DEFINITIONS

Identity Authority This is a body or organization responsible for the issuing and managing the allocation of unique identifiers and their supporting schema. Identifier string This is a unique identifier string issued by the Identifier Authority. It is typically numerical, however, it can also contain alphanumeric values and even characters through binary representation schemes. Internet of Things The Internet of Things is a term coined to describe a future ubiquitous sensor enabled network that collects commercial and personal data associated with objects in public and private settings. The Internet of Things has evolved, in part, through the rollout of RFID technology. The topography of the Internet of Things is one of private networks, public (open) networks and mixed-use networks. In supply chain settings, the need for secure and selective visibility for data sharing is significant for commercial entities. The Internet of Things will not be, in all respects, globally and publicly accessible like the Internet. DNS or Domain Name Service This is a hierarchal lookup system that matches numerical addresses to human readable names (think of a postal code). It is a delegated electronic system that reads names from right to left. Each section of a human readable name (i.e. www.ietf.org) or also known as “hostname” can be delegated to a different DNS provider. This is what powers hostname lookups on the Internet. For example: A human readable address www.ietf.org would be read the following way:

1. Your local computer would ask your (ISP) Internet Service Provider’s DNS service to match www.ietf.org to the numerical address of the computer running this website. Once your computer has the numerical address it can connect to the website.


http://www.ietf.org/




2. The ISP’s DNS service would first ask the ICANN administrated root servers what DNS service is responsible for the first part of the address, in this case “org.” These are called the root servers because every DNS server in the world that’s operating already has the numerical addresses for this starting set of DNS servers. Remember we read from right to left, so the root servers would provide a referral to the next level of DNS service answering questions about “.org” .

3. The ISP DNS service would then ask the DNS service operating “.org”

which DNS service is responsible for the next part of the address “ietf.org”. The DNS service operating “.org” would respond with a referral to that DNS service.

4. The DNS service answering the final part of the address

“www.ietf.org” would respond with a numerical address and your computer can now use that to connect to the computer running the website.

Confusing? Think about it like a treasure hunt for a map, where each clue leads to another clue until at the end you get the final directions to the actual treasure.

So in this example, to convert one human readable name “www.ietf.org” to a numerical address, no less than four DNS




services were involved: one DNS service asking for information, (the ISP’s or our treasure hunter), two DNS services providing clues to the next stop, and the last DNS service providing answers for different sections of the human readable name (or the treasure’s location).

DNS Caching A mechanism by which DNS servers retain repeatedly-requested portions of names in memory to prevent over-taxing DNS services at the top levels. For Example: www.ietf.org is requested by ABC ISP DNS service 1500 times a day. However the “.org” portion of the domain name is requested at ABC ISP DNS servers by their clients 200,000 times a day. The first time ABC ISP DNS servers are asked about any name that included “.org”, the ICANN root servers answered about which DNS service runs “.org” and then told ABC ISP’s DNS server to cache that information for 86400 seconds, or 24 hours. Now if I try if ABC ISP’s DNS server receives a request to look up www.ietf.org from my computer, it won’t ask the root servers again but just reuse the last answer it received for another 24 hours. DNS caching occurs independently at every level of any given name answered by DNS. The time specified for DNS caching, also known as time-to-live (TTL) can be prescribed by the DNS server or the ISP itself. ONS or Object Naming Service A standard for converting an identifier string to a label format that is readable by DNS servers. For all effective purposes, DNS and ONS on the service side are functionally equivalent. So we can easily refer to the DNS services as ONS services, whatever is most convenient. Using an EPCglobal electronic product code in its URI form as an example:

“urn:epc:id:sgtin:0413131.000026.412” This code includes a section that identifies product manager (“0413131”), product class (“000026”) and a serial number for the actual item (“412”). Note a “urn:” is also included in the address. Note: ONS usually, as currently specified, only translates these codes down to the product class level (“000026”), however it’s a simple matter to keep on going and include the actual item (“412”).





Since DNS servers read right to left, after conversion for interaction with a DNS server we end up with:

“412.000026.0413131.sgtin.gs1.fr” Note, we changed the typical ONS translation method and substituted different labels in this DNS usable string. These changes support an organizational approach that includes multiple identity authorities. The examples later on will clarify this. ISP Internet Service Provider ICANN The Internet Corporation for Assigned Names and Numbers (www.icann.org) is California –based non-profit body that oversees the naming system for the Internet under a Joint Project Agreement with the United States Department of Commerce.

ABOUT AFILIAS Afilias is the largest provider of outsourced global domain name

registry services supporting over 14 million domains across 15 top level domains. Afilias leverages proven technology to deliver fast, reliable and secure service. Afilias’ technology supports a wide range of applications, including Internet domain registries such as .INFO, .ORG, .aero, .mobi, .asia, .me, and many country code domains. Afilias also provides services in the RFID market with its Afilias Discovery Service, which enables real-time lookup of event histories across RFID networks.


http://www.icann.org/


REFERENCES 1 EPCglobal, ( http://www.epcglobalinc.org ), standards body responsible EPCIS and ONS specifications (see subsequent footnotes/references).

2 EPC Information Services Version 1.01 Copyright @ 2004-2007, EPCglobal (http://www.epcglobalinc.org/standards/epcis/epcis_1_0_1-standard-20070921.pdf)

3 EPCglobal Object Name Service (ONS) 1.0.1 Copyright © 2004–2008 EPCglobal,(http://www.epcglobalinc.org/standards/ons/ons_1_0_1-standard-20080529.pdf).

4 PROMISE, an European funded research project on end to end electronic supply chain architecture, now completed and noted as successful, and been succeeded by a commercial Endeavour, more information at ( http://www.promise-plm.com )

5 BRIDGE (Building Radio Frequency Identification for the Global Environment) is a European Union funded 3-year Integrated Project addressing ways to resolve the barriers to the implementation of RFID in Europe, based upon GS1 EPCglobal standards (www.bridge-project.eu ).

6 IETF: The Internet Engineering Task Force, an Internet standards making body, ( www.ietf.org )

7 Discovery Service: a selectively visible and secured referral system, generally more specific to individual supply chains that supports the track and tracing of entire “lifecycles” of products through the supply chain. Cooperative work is currently being done at the BRIDGE project, EPCGLobal and IETF working groups.

8 ESDS, Extensible Supply Chain Discovery Service: Current protocol effort at the IETF with contributions from BRIDGE and EPCglobal to create a selectively visible and secure referral lookup system.

POINTS OF CONTACT Brian Cute Vice President, Discovery Services [email protected] Michael Young Vice President, Product Development [email protected]


http://www.epcglobalinc.org/

http://www.epcglobalinc.org/standards/epcis/epcis_1_0_1-standard-20070921.pdf

http://www.epcglobalinc.org/standards/ons/ons_1_0_1-standard-20080529.pdf

http://www.promise-plm.com/

http://www.epcglobalinc.org/home

http://www.bridge-project.eu/


mailto:[email protected]

mailto:[email protected]

finding your way in the internet of things

Documents