A Solution with Security Concern for
RFID-Based Track & Trace Services in EPCglobal-Enabled Supply Chains 13
shown that our solution can achieve secure information flow control for product track & trace
services. We have also implemented a prototype of our solution for OM processes.
The working prototype of our solution has demonstrated high feasibility and efficiency in
industrial scenarios under rigorous testing. It has attracted significant interests from industrial
participants. While we are patenting the solution at this stage, we plan to commercialize the
solution and make it a product of application package in the future.
6. Acknowledgment
This work is partly supported by A*Star SERC Grant No. 082 101 0022 in Singapore.
7. References
Accada EPCIS (n.d.).
URL: http://www.accada.org/epcis/
Accada EPCIS User Guide (n.d.).
URL: http://www.accada.org/epcis/docs/userguide.html
Angeles, R. (2005). RFID technologies: supply-chain applications and implementation issues,
Information Systems Management 22(1): 51–65.
Auto-ID Centre at St. Gallen (2006). Anti-counterfeiting and secure supply chain.
Avoine, G. (n.d.). Security and Privacy in RFID Systems.
URL: http://lasecwww.epfl.ch/˜gavoine/rfid
Chuang, M L. & Shaw, W H. (2007). RFID: integration stages in supply chain management,
IEEE Engineering Management Review 35(2): 80–87.
Derakhshan, R., Orlowska, M. E. & Li, X. (2007). RFID data management: challenges
and opportunities, Proceedings of the 2007 IEEE International Conference on RFID,
Gravevine, TX, USA, pp. 175–182.
Diekmann, T., Melski, A. & Schumann, M. (2007). Data-on-network vs. data-on-tag: managing
data in complex RFID environments, Proceedings of the 40th Hawaii International
Conference on System Sciences 2007, Hawaii, USA.
E-Pedigree (n.d.).
URL: http://www.axway.com/solutions/healthcare/epedigree.php
EPCglobal network (n.d.).

Engineering Workshop (ICDEW’08), Cancun, Mexico, pp. 102–103.
Michael, K. & McCathie, L. (2000). The pros and cons of RFID in supply chain management,
Proceedings of the 4th International Conference on Mobile Business (ICMB’05), Sydney,
Australia, pp. 623–629.
Mintchell, G. (2002). It’s automatic: automation shifts transmission assembly into high gear,
Control Engineering 49(6): 12.
Neuman, B. C. & Ts’o, T. (1994). Kerberos: an authentication service for computer networks,
IEEE Communications Magazine 32(9): 33–38.
RFID Journal (1983). A Guide to Understanding RFID.
URL: http://www.rfidjournal.com/article/gettingstarted/
Sheu, C., Lee, L. & Niehoff, B. (2006). A voluntary logistics security program and
international supply chain partnership, Supply Chain Management: An International
Journal 11(4): 363–374.
Song, S., Shim, T K. & Park, J H. (2006). Proxy based EPC track & trace service, Proceedings of
the 2006 IEEE International Conference on e-Business Engineering (ICEBE’06), Shanghai,
China, pp. 528–531.
Straube, F., Vogeler, S. & Bensel, P. (2007). RFID-based supply chain event management,
Proceedings of the 1st Annual RFID Eurasia 2007, Istanbul, Turkey, pp. 1–55.
Tan, J. S. (2005). ISO focus, The Magazine of the International Organization for Standardization
2(2): 19–25.
Tan, P. S., Goh, A. E. S., Lee, S. S. G. & Lee, E. W. (2006). Issues and approaches to dynamic,
service-oriented multi-enterprise collaboration, Proceedings of 2006 IEEE International
Conference on Industrial Informatics (INDIN ’06), Singapore, pp. 399–404.
Thornton, F. (2006). RFID security, Syngress pp. 46–48.
Xiong, L. & Liu, L. (2004). PeerTrust: supporting reputation-based trust in peer-to-peer
communities, IEEE Transactions on Knowledge and Data Engineering (TKDE), Special
Issue on Peer-to-Peer Based Data Management 16(7): 843–857.
Yu, T., Ma, X. S. & Winslett, M. (2000). PRUNES: an efficient and complete strategy for
automated trust negotiation over the internet, Proceedings of the 7th ACM Conference
on Computer and Communications Security (CCS 2000), Athens, Greece, pp. 210–219.

stock in times of higher demand. Real-time information can help to detect critical stock levels
early. Sharing that information instantly with suppliers allows them to take immediate action
such as rescheduling of shipments or increasing production rates to cope with temporary
increased demand. Section 2 of this chapter will go into the details of two selected industry
use cases that outline the benefits of company-overlapping collaboration.
The existence of practical scenarios for supply chain collaboration based on Auto-ID data
demands for an infrastructure of information systems to support these use cases. EPCglobal,
a joint venture between GS1 (formerly known as EAN International) and GS1 US (formerly
the Uniform Code Council, Inc.), introduced the EPCglobal Architecture Framework, which
is suppose to increase visibility and efficiency throughout the supply chain as well as to
8
2 RFID / Book 2
guarantee higher quality information flow between companies and their trading partners
[EPCglobal (2007a)]. The EPCglobal Architecture Framework, for the rest of this chapter
named EPC Network, is derived from the concept of the “Internet of Things” (IoT). The IoT
Fig. 1. EPCglobal Architecture Framework
is a concept that describes a self-configuring wireless network of sensors whose purpose is to
provide objects with a means to interconnect and to interact [Polytarchos et al. (2010)]. Based
on this idea, the EPC Network defines information systems, communication protocols, and
data types that support capturing, storage, and exchange of EPC data among participants of a
supply chain network. Figure 1 depicts the different standards defined for the EPC Network.
The architecture includes specification for low level communication protocols such as the air
interface between tag and reader as well as high level aggregated business information such
as the EPC Information Services (EPCIS) and the EPC Discovery Service (EPCDS). Especially
the latter play key roles for the company-overlapping exchange of information.
The diagram depicted in Figure 1 shows the discovery service component in a pale green
color, indicating that it is still question to research how such a discovery service has to be
designed. The purpose of this chapter is to elaborate on the complexity of this issue and
introduce scientific work related to the definition of a discovery service component for the
EPC Network. There are numerous functional and non-functional requirements that make

conducted by custom authorities in all EU members states. More than 34 million fake drug
tablets were detected at customs control at the borders of the European Union in a two
month period [Group (2009)]. This can put lives in danger as pharmaceuticals might not
contain active pharmaceutical ingredients, wrong ingredients, a wrong dosis or other harmful
substances.
To increase process efficiency and fight smuggling as well as counterfeiting, companies more
and more inspect the concept of “unique identification”, meaning that not only the product
manufacturer and the product type is encoded but that each and every single item receives
a unique serial number. That is the point where EPC an RFID comes into play. With the
ability of unique identification using EPC and ubiquitous data capturing using RFID, it is
possible to track items along their way from the point of production to the consumption. A
major component in such a scenario is the company’s read event repository, which stores
the events captured by the RFID readers. Each company in the supply chain that captures
Auto-ID data from their processes, needs to operate such a read event repository, to persist its
data. Combining the information distributed over all repositories of the companies that are
part of the manufacturing and/or distribution process, allows to reconstruct a complete trace
of each individual item. Such a trace can be used to verify the origin and the distribution path
of an item, providing customers only with pharmaceuticals from licit supply chains.
The problem is that a retailer needs to determine all resources of information, i.e., the
addresses of the read event repositories that contain information regarding the particular EPC.
Globalized trade, dynamic business relations, re-importing, and multiple levels of wholesalers
and distributors, require a dynamic aggregation of information from a number of potentially
unknown resources. To gather all this information, a component is needed that, given an EPC,
111
Discovery Services in the EPC Network
4 RFID / Book 2
provides pointers to the resources that contain the read events created during the travel of the
item through the supply chain. Such a component is the EPC Discovery Service.
2.2 Use case 2: Product recall
The second use case that we want to present is product recalls. Product recalls usually occur

Network. In this section, we go into the details of the EPC Network to understand the
interconnection between the individual components and their relation to the use cases. We
need to do this because most of the requirements for a discovery service are based on the
existing components, the data that is available in the network, and the interfaces used to access
the data. We will not go into the details of low-level physical data access and tag encodings,
instead we restrict our discussion to the components above Application Level Events (ALEs),
see Figure 1.
112
Designing and Deploying RFID Applications
Discovery Services in the EPC Network 5
3.1 Read events
The primary type of data exchanged in the EPC Network are read events. read events are
business-level events, which represent a scan of an RFID tag or 2D barcode associated with
business context. There are five types of events: EPCISEvent, ObjectEvent, AggregationEvent,
TransactionEvent and QuantityEvent. Figure 2 depicts an UML class diagram, showing the
relation between the different types of events.
EPCISEvent
-eventTime
-recordTime
-eventTimeZoneOffset
-action
-epcList
-bizstep
-disposition
-readPoint
-bizLocation
-bizTransactionList
ObjectEvent
-parentID
-childEPCs

business context of items during their travel through the supply chain.
3.2 EPC information services
Once these events are created, they need to be stored persistently at some point, to provide
other applications with the ability to use these events. For this purpose, the EPC Network
defines the EPC Information Services. The EPCIS provides a repository to store the
information about read events that is why it is also called read event repository. Furthermore,
it provides a capture interface to provide a way to store the events, as well as a query interface
to query for stored events. Each company, which captures Auto-ID data is supposed to operate
an EPCIS to be able to store and to exchange the information with internal and external
applications. Figure 3 illustrates the process of information storage and exchange with the
EPCIS. However, the EPCIS is nothing more than a repository for read event data. It solely
serves as a resource of information and does not implement any business logic. In order to be
able to leverage the full potential of the information distributed among the EPCIS servers of
different trading parties, it is necessary to derive the exact addresses of the EPCIS servers
that posses information about a particular item, i.e., EPC. The EPC Network defines two
113
Discovery Services in the EPC Network
6 RFID / Book 2
Distributor Wholesaler RetailerLogistics ProviderManufacturer
Physical Flow
EPCIS Layer
Information Flow
Fig. 3. EPC Information Services Data Flow
information systems that provide such kind of functionality, namely the Object Name Service
(ONS) and the EPC Discovery Service.
3.3 Object name service
The ONS is a DNS-based service, whose purpose is to resolve information resources to an
EPC. Information resources in the context of ONS can be websites, web services, or an EPCIS
repository. However it is important to note that the ONS does not process the serial version
of the EPC. Figure 4 depicts the EPC numbering scheme. It consists of a header, defining

Client
EPCIS
manufacturer
EPCIS
distributor
EPCIS
wholesaler
EPCIS
retailer
Scan Events Scan Events Scan Events Scan Events
EPC
R
ONS Query
R
DS Query
R
D
S
Q
u
e
r
y
Authentication & Authorisation
Fig. 5. Object Name Service vs. EPC Discovery Service
In this section, we looked at the individual EPC Network components and defined their
particular roles, regarding information storage and exchange. We introduced the concept
of the EPC Discovery Service, which is the central component to support the use cases
from Section 2. The following section takes the prerequisites from this section and the use
case definitions and derives a list of basic requirements for a discovery service for the EPC

RQ1: A discovery service needs to provide a way for resources to publish their information,
i.e., EPC and corresponding EPCIS server address.
RQ2: It needs to store the EPC/URL mappings and the according timestamps persistently.
RQ3: It needs to provide a way for clients to execute ad hoc queries for EPC-related
information.
RQ4: It needs to provide a way for clients to register/unregister standing queries to provide
instant information on incoming notifications.
RQ5: It needs to provide authentication and authorization mechanisms to protect the stored
data.
4.2 Data ownership
According to Kürschner et al., data control aspects have to be considered by any discovery
service approach. Their investigations showed that there exist companies that are not
willing to share their EPCs or EPCIS addresses with other companies. The reason for this
is self-interest, i.e., system owners have greater interest in system success than non-owners.
The issue of data ownership is considered to be a major reason for managers to decline the
participation in supply chain overlapping business collaboration. Neglecting this fact will
lead to a reduced adoption rate of the particular discovery service approach among supply
chain partners. Based on their findings, Kürschner et al. defined two requirements for the
discovery service design, regarding data ownership.
RQ6: Companies shall be in complete control over their data including EPCIS addresses, read
events, business data as well as setting of detailed, fine-grained access rights.
RQ7: Companies shall be able to track the usage or the requests upon their data. Particularly,
publications of data at the discovery service level should be avoided.
4.3 Security
Security is a vital factor in any enterprise application. In case of the discovery service this
issue becomes even more relevant due to the fact that it operates on public networks, keeping
sensitive information potentially necessary for business success. Kürschner et al. derive
a set of characteristics from the overall topic of security. These are availability, reliability,
safety, confidentiality, integrity, and maintainability. Although all of the above mentioned
116

(13.5%), early majority (34%), late majority (34%), and laggards (16%). As a result of this
development there will be only few companies initially joining the network in the beginning.
However, the actual value of the EPC Network depends on the number of participating
companies. Consequently, it is of high importance to lower the threshold for joining the
network for less innovative companies, fostering the adoption of the EPC Network.
RQ12: The discovery service architecture shall encourage participation in the EPC Network.
Although this requirement is somewhat straightforward for any new technology, it is worth
special consideration, because the value of the network and therefore the acceptance of the
EPCglobal idea, to support supply chain innovation for all industries, depends on the fast
adoption of discovery services.
Low threshold in this context can be related to technical, financial and political obstacles.
In order to push the desire to participate in an innovative idea such as the EPC Network,
it is important to keep a positive relation between opportunity and risk. An economically
117
Discovery Services in the EPC Network
10 RFID / Book 2
expensive solution, creating large administrative overhead, leads to a low adoption rate,
resulting in an EPC Network with low attraction to potentially interested parties.
4.6 Scalability
Another very important requirement is scalability. Müller et al. have already been aware
of the problem of handling large amounts of requests and data. The issue of information
production in RFID-enabled supply chains has been topic to a number of research works
all aiming to understand the nature and behavior of these RFID enabled supply chains [Ilic,
A. Groessbauer and & Fleisch (2009)]. Depending on the industry and application scenario,
a discovery service can become a bottleneck or, even worse, a single point of failure when
scalability becomes an issue.
RQ13: The discovery service architecture shall be highly scalable to be able to handle both,
data volume and number of participants.
4.7 Quality of service
From a client’s perspective, quality of service means the discovery service needs to provide

distributed discovery services, to share the work load [Ilic, Groessbauer, Michahelles & Fleisch
(2009); Müller, Pöpke, Urbat, Zeier & Plattner (2009)]. Secondly, there are political problems
that prevent the successful operation of a single global discovery service. Companies from
many different countries and industries would have to agree on publishing their data to a
discovery service, operated by some authority organization. It is most likely that there are
countries and individual organizations that are not willing to publish their data to such a
discovery service for a number of political reasons. Thirdly, the operation of a global discovery
service would require processing power and storage space similar to the data processing
centers of the major search engine providers. However, search engine providers are able to
be financed via advertisements and additional services. An organization running a global
discovery service would have to be financed by its users, who might not be willing or able to
pay for the service. This issue directly influences requirement seven.
In the above paragraph, we identified technical, political and economical problems that
lead to a distributed network of independent, collaborating discovery services. These
discovery services will be operated by different providers such as legal authorities, companies
themselves, or third-party profit organizations. In [A. Rezafard (2008)] Rezafard assumes
that there will be globally operating communities (supply chains) that commit to a discovery
service of choice.
It has been suggested that the ONS could be used for the bootstrapping process. However,
the ONS is authoritative in that the entity that has change control over the information about
the EPC is the same entity that assigned the EPC to the item to begin with. This means that
the entity that assigned the EPC has to determine the discovery service that each company,
which gets in contact with the object, has to publish its information to. This procedure may
be feasible for supply chains, completely owned by a single company, but it is not possible to
force all supply chain participant in global dynamic supply chains to publish their information
to a particular discovery service. We already mentioned the issue of information ownership.
Each company, producing RFID data is in full control of the data and decides autonomously
about the publication of this information. That way it might be possible that the information
about an EPC is distributed over a number of different discovery services.
Until now there is no accepted network architecture for discovery services. The reason for

company’s EPCIS. For each EPC that is stored in an EPCIS for the first time, the discovery
service is notified and stores the EPC, the URL of the submitting EPCIS, a timestamp, the
certificate of the submitter, and a visibility flag in its repository. The discovery service can
then be queried with an EPC of interest. It replies with a list of relevant EPCIS URLs. Finally,
the requester can query all relevant EPCIS servers by himself and aggregate the respective
information. The underlying assumptions are that all participants of the EPC network are
authorized by EPCglobal and equipped with a certificate by a trusted third party.
According to Beier et al. [Beier et al. (2006)], access to a company’s EPCIS should be
implemented role-based and policy-based with cell-level data disclosure control. At the
discovery service level, row-level data access control should be enforced and, using the
visibility flag, the owner of the data decides whether the record is shared among all authorized
participants of the EPC network or access is restricted to companies, which have information
about the same EPC. To retrieve EPCIS addresses confidentially, Beier et al. propose the usage
of EPCIS proxy servers by storing not the real but the proxies URL at discovery service level.
5.1.2 BRIDGE project: High-level design for discovery services
BRIDGE is an acronym for Building Radio frequency IDentification for the Global
Environment. The objective of this EU-funded project is to “research, develop and implement
tools to enable the deployment of EPCglobal applications in Europe” [of Cambridge & UK
(2007)].
In the report [of Cambridge & Research (2007)] the authors propose eight discovery service
approaches, evaluate them, and finally judge four as promising candidates for large scale
discovery services. It is important to understand that EPCIS servers can serve two different
types of queries: ad hoc queries and standing queries. One-off queries are performed by a
client once and no further communication between client and EPCIS is planned. Standing
queries are subscriptions, which can be time-controlled using a query schedule (e.g., a client
120
Designing and Deploying RFID Applications
Discovery Services in the EPC Network 13
wants to be informed every hour) or trigger-controlled (e.g., a client wants to be informed if
new information about an EPC of interest is available) [EPCglobal (2007b)].0

5.2 Our new design - an aggregating discovery service
The idea of the Aggregating Discovery Service (ADS) is to forward client queries to relevant
EPCIS servers, aggregate their responses and synchronously respond to the client request.
This reduces client complexity, brings low response latency, delivers complete and correct
information for the requester, ensures data ownership for the information holder, avoids
the need for fine-grained access control replicated at discovery service level, and guarantees
confidentiality of clients and information holders. The ADS is a centralized service, which
offers two interfaces (see Figure 6).
The query interface is used to gather information about an EPC of interest from the EPC
Network. The ADS links EPCs to supply chain partners, which can provide detailed
information about those EPCs. Certificates are used to provide authentication as proposed
in [Beier et al. (2006); Kürschner, Condea, Kasten & Thiesse (2008)].
121
Discovery Services in the EPC Network
14 RFID / Book 2
Aggregating Discovery Service
EPCIS Pointer Database
Notify
Interface
Query
Interface
Interested Party
R
Producers, Distributors, Retailers
EPC
Middleware
EPC
Middleware
Reader
EPCIS Repository

Designing and Deploying RFID Applications
Discovery Services in the EPC Network 15
which are relevant for this query (3.) and forwards the original query to those EPCIS
servers (4.). After subresponses returned from the EPCIS servers (5.), they are parsed and
the read events are extracted and combined (6.). The aggregated result is then returned to the
client (7.). Effectively, this means the ADS acts as a proxy.
When querying EPCIS servers, problems might occur. Subqueries might time out, EPCIS
servers may be temporarily unreachable or may refuse to answer the query. To prevent
timeout of its client connection, the ADS will return a possibly incomplete result set marked as
such, distinguishing between temporary problems (indicating that the client should try again
later) and permanent reasons that prevent returning a complete response.
The ADS query interface should also support standing queries. The ADS needs to store all
standing queries it received in order to forward them to an EPCIS when the EPCIS sends an
event notification containing an EPC that matches a standing query of a client. This approach
has the advantage that other EPCIS servers are not burdened with irrelevant standing queries,
as they would be if the ADS was to distribute all standing queries to all EPCIS servers in order
to achieve complete coverage.
5.3 Comparison of the different approaches
The fulfillment of the requirements stated in Section 4 and referenced literature in that section
is substantial for a well-designed discovery service architecture that can easily be integrated in
the EPC Network. In this section, we compare the existing approaches, introduced in Section
5.1, categorizing into the concepts Directory Service (DS) and Query Relay (QR), with our
new Aggregating Discovery Service (ADS) approach. To do so, we elaborate on the different
concepts, regarding the requirements, defined in Section 4. A summary of the comparison is
depicted in Tables 1 and 2.
5.3.1 Directory Service (DS) approach
The Directory Service approach represents the most basic way to provide discovery service
functionality. Given an EPC, a query to the discovery services would return a simple list
of EPCIS server addresses that are in possession of read events for this particular EPC. Even
though the design is simple, it has all means to provide functionality for the core requirements

volumes of many TB. The bigger problem is the potential request load, which increases with
the number of clients and resources. These large data volumes produced by RFID enabled
supply chains need to be searched very fast. This problem even aggravates when the number
of parallel requests increases. We are currently conducting further research to analyze the
impact of increased request load and data volume on the scalability of the different discovery
service concepts. However, we expect the DS approach to be able to scale well by applying
conventional scalability mechanisms such as load balancing and clustering. This assumption
is based on the observation that most processing steps for the notification and the query of a
discovery service can be parallelized very well.
RQ14 focuses on the quality of information. Assuming a suitable role-based access layer
and a correct working query algorithm, the information returned by the discovery service
is complete and correct.
We rate the client complexity (RQ15) for the DS concept high in comparison to the other two
concepts. The DS approach only returns the URLs of the EPCIS servers’ query interface. The
client is responsible for invoking the individual EPCIS servers, to parallelize the different
requests, to aggregate the information and to invoke successive request, related to different
packaging hierarchies.
5.3.2 Query Relay (QR) approach
The Query Relay approach implements an asynchronous request/response paradigm, where
the client submits a query for an EPC to the discovery service. The discovery service
determines all potential resources for that EPC and propagates the query to these resources,
which in turn answer directly to the client. The client needs to implement a callback interface,
which is used to aggregate incoming EPCIS responses.
Just like the DS approach, the QR concept provides functionality for requirements RQ1
through RQ4. An authorization and authentication layer needs to be implemented to restrict
the number of authorized clients (RQ5).
Security (RQ5, RQ8 and RQ9) can also be covered by introducing a PKI. By the same token,
information integrity can be ensured using digital signatures based on certificates of PKI
(RQ9).
In contrast to the DS approach, data ownership (RQ6, RQ7) is a strong feature of the QR

client has to wait until a timeout is reached. This stands in contrast to a low response time.
The result of a client query is complete and correct (RQ14) if and only if the client waits long
enough to assure that no more replies are still underway. The client has no indication if EPCIS
servers are temporarily unavailable.
The asynchronous communication inherent in the QR concept directly leads to an increased
client complexity (RQ15). In the QR approach the client must be able to receive data from
multiple previously unknown sources without knowing the exact number of responses. This
results in the need for a complex software design that has to handle multiple incoming
connections for a single request. Furthermore, the client has to aggregate the EPCIS responses
by itself. Given the fact that client queries are forwarded to respective EPCIS servers
immediately, the client is not in full control of its query. It cannot cancel the request or deny
that his query is forwarded to a specific EPCIS, which might be a competitor’s EPCIS.
5.3.3 Aggregating Discovery Service (ADS) approach
The ADS approach combines the advantages of the DR and the QR. The ADS shifts the
complexity (RQ15) of query parallelization and the aggregation of EPCIS responses from the
client to the discovery service and creates a view of the relevant information for the client.
Hence, a query is immediately forwarded to all relevant EPCIS servers. The client is no longer
in control of the query once it submitted it. If EPCIS severs enforce role-based access control
this is not an issue because only the client role is revealed to the information holder, not the
client identity.
125
Discovery Services in the EPC Network
18 RFID / Book 2
Similar to the previous two approaches the ADS supports the four core functionalities
(RQ1-RQ4). Security measures (RQ5, RQ9) and RQ10) can also be taken from the DS and
the QR approaches.
The first major improvement compared to DS and QR is data ownership (RQ6 and RQ7). The
discovery services relays the client query to the respective EPCIS servers, providing complete
privacy for the resources (RQ8), but in contrast to the QR approach, the ADS can control the
query process, enabling it to take remedial action upon non-responding resources. The ADS

5.4.1 Scalability
The ADS provides additional functionality, which requires more computing power than the
Directory Service or Query Relay approach. Like stated before the ADS has to wait for all
responses of the subqueries, thus maintaining a connection’s state for the request-response
126
Designing and Deploying RFID Applications
Discovery Services in the EPC Network 19
cycle with the client. In this section we show that it is possible to implement a scalable
discovery service following the ADS approach.
We exemplify the potential load for a discovery service in the U.S. pharmaceutical supply
chain by a back-of-the-envelope calculation. Following the supply chain network model of
Williams et al. [Williams et al. (2008)] a discovery service has to deal with 1,000 notifications
per second at peak times and 200 queries per second in average. We assume the worst case
scenario that supply chain partners conduct a query for each item they notify as indicated by
[of Cambridge & UK (2007)]. The ADS therefore has to deal with the same amount of queries
to the discovery service. As the authors additionally state a supply chain does not exceed 15
partners.
5.4.2 Load balancing and data partitioning
Distributing incoming notification messages and client queries to many self-contained
application servers allows the ADS to scale very well. HTTP load balancing can be performed
in both, hardware and software for very high connection speeds. Additional servers can be
added at any time allowing the system to grow in size.
HTTP reverse proxy servers balance incoming HTTP queries. They accept incoming HTTP
connections and are able to act based on the queried URL or even arguments in the HTTP
request. Implementations like the event-driven nginx
1
can help to lower the CPU load on
application server machines by mapping requests to a specific EPC to one specific server. Each
server is then responsible for a range of EPCs, implementing partitioning at the application
server and database tier. Client queries always refer to one or more EPCs. No single database

In comparison, the ADS is the single response endpoint for all subqueries. Like described
before, during peak hours the ADS has to be able to cope with 1,000 incoming client requests
per second. For 6 relevant EPCIS servers on average, it has to send 6,000 subrequests and
receive 6,000 subreponses per second. We expect each (sub)query to be 1 KB, each subresponse
to be 2 KB in size, and each aggregated response to be 12 KB in size.
Receiving 1,000 queries/s at 1 KB per query and 6,000 subresponses/s at 2 KB per subresponse
comes out to an inbound bandwidth of
(1,000·1)+(6,000·2)· 8
1000
= 104 Mbit/s. On the other hand,
sending 6,000 subqueries/s at 1 KB per subquery and 1,000 aggregated responses/s at 12 KB
per response equals an outbound bandwidth of
(6,000·1)+(1,000·12)· 8
1000
= 144 Mbit/s. Both
throughputs are perfectly feasible using available internet connections.
5.4.5 XML handling
All replies sent back from EPCIS servers to the ADS use the XML format standardized by
EPCglobal. It wraps all ObjectEvents in a single EventList [EPCglobal (2007b)]. XML
parsers optimized for high throughput provide efficient functionality for aggregating these
XML responses. SAX or Pull parsers have proven their efficiency in SOAP environments
where a large number of small XML queries have to be processed [Chiu et al. (2002)].
While receiving the XML data stream from a responding EPCIS every parsed tag inside the
EventList can instantly be created on the output stream that, after all EPCIS servers replied,
will be sent back to the client. This eliminates the need to add further buffers for XML objects
and reduces XML rendering time.
6. Summary and future work
We started out by motivating the necessity of a discovery service for the EPC Network by
introducing real world use cases that require the presence of such a component. In Section 3,
we looked at the components of the EPC Network, discussed their particular roles within

Ilic, A., A. Groessbauer and, F. M. & Fleisch, E. (2009). Understanding Data Volume Problems
of RFID-enabled Supply Chains, Business Process Management Journal, Vol. 16.
Ilic, A., Groessbauer, A., Michahelles, F. & Fleisch, E. (2009). Estimating Data Volumes
of RFID-enabled Supply Chains, 15th Americas Conference on Information Systems
(AMCIS).
Kürschner, C., Condea, C. & Kasten ,O.(2008). Discovery Service Design in the EPCglobal
Network, The Internet of Things .
Kürschner, C., Condea, C., Kasten, O. & Thiesse, F. (2008). Discovery service design in the
EPCglobal network: towards full supply chain visibility, IOT’08: Proceedings of the 1st
international conference on The internet of things, Springer-Verlag, Berlin, Heidelberg,
pp. 19–34.
Melski, A., Müller, J., Zeier, A. & Schumann, M. (2008). Assessing the effects of enhanced
supply chain visibility through rfid, 14th Americas Conference on Information Systems
(AMCIS’08), Toronto, Canada.
Müller, J., Oberst, J., Wehrmeyer, S., Witt, J. & Zeier , A.(2009). An Aggregating Discovery
Service for the EPCglobal Network, hicss .
Müller, J., Pöpke, C., Urbat, M., Zeier, A. & Plattner, H. (2009). A Simulation of the
Pharmaceutical Supply Chain to Provide Realistic Test Data, Advances in System
Simulation, International Conference on 0: 44–49.
OECD (2008). The Economic Impact of Counterfeiting and Piracy.
OECD (2009). Magnitude of counterfeiting and piracy of tangible products.
of Cambridge, A. U. & Research, S. (2007). High Level Design for Discovery Services. BRIDGE
project.
of Cambridge, A. U. & UK, G. (2007). Requirements document of serial level lookup service
for various industries. BRIDGE project.
of Cambridge, U., wireless, A., Research, B., Research, S., Zurich, E. & UK, G. (2007).
Ohnsman, A. & Kitamura, M. (2010). Toyota Recalls Increase on Brake Flaw Shared by Honda.
Polytarchos, E., Eliakis, S. & Bochtis, D. (2010). Evaluating Discovery Services Architectures
in the Context of the Internet of Things, Unique Radio Innovation .
Rogers, E. M. (1995). Diffusion of innovations, Free Press, New York.

it was authorized as a Global Standards I (GS1). The GS1 system of standards is the most
widely-used supply-network standards system in the world, the traditional barcode being its
most widely used standard.
1.1 Product identifier proposals
The DIALOG system was developed at the Helsinki University of Technology. In this
approach an ID@URI notation is used to create a GUPI, where the ID part identifies the
product item located at the URI. If the URI is an URL, it is a straightforward task to link it
to an information service. For an ID@URI to be a GUPI, the ID part should be unique for the
corresponding URI. In the DIALOG system every product is implemented as a software agent
(Nwana, 1996), and the information of each of them is accessed and updated through methods
in the product agent interface (Främling et al., 2006). These interface methods are as follows:
update() and getProductInformation(), which are used to append and retrieve information,
respectively, and getCompositeInformation(), which relates to managing component hierarchies.
The World Wide Article Information (WWAI) protocol developed by Trackway (formerly
known as Stockway) is based on P2P principles. The manufacturers form a network of
nodes which are identified by company numbers. When a node has joined the network,
it can autonomously issue identifiers for individual products, the product GUPI consisting
of a concatenation of the company prefix and item-specific suffix. The service provided by
1
http://www.trackway.eu
9