Design, Implementation and In-Field Testing of an Original Discovery Service for EPC Network Infrastructure

The EPC Network is an ubiquitous infrastructure designed to link physical objects through the Internet. The EPC Network is organized as a service-oriented architecture (SOA) made up of loosely coupled and interoperable modules. An essential component to fully exploit the EPC Network capability is the Discovery Service, although today its functional definition and interface standardization is still at a very early stage. This paper presents a possible implementation of Discovery Service inside a fully functional RFID infrastructure, tested within the first italian RFID Supply Chain Pilot in the Fast Moving Consumer Goods industry. The main advantages of the chosen design have been proven to be the high level of integration, its scalability and reliability. The proposed system is one of the first implementations of the Discovery Service tested in field and could be considered as a feasible solution for the EPCIS framework.

I. Introduction

The EPCglobal Network is a software architecture for exploiting RFID technology and for exchanging information among trading partners. The EPC Network enables true visibility of the flow of goods in the supply chain, streamlining business processes. EPCglobal [1], the organization in charge for standard developments related to the so called ``Internet of Things'' defines it as ``a way of leveraging the internet to access a large amount of logistics information that can be shared among authorized trading partners'' [2]. The EPC Network uses data stored into the tag chip in the form of an electronic product code (EPC) as the key to gather all the information related to an item, such as lot number, shelf life or expiration date, as well as the information related to the flow of goods all the way down the supply chain, up to the store shelves. The framework is composed by a suite of selected services, namely EPC Information Services (EPCIS), Object Naming Service (ONS) and Discovery Service (DS) [3].
EPCIS is the primary vehicle for data exchange between partners in the EPCglobal Architecture Framework, encompassing both interfaces for data exchange and specifications of the data itself. The ONS provides a logically centralized registry through which an EPC may be statically associated to its producer [4]. Through ONS a trade partner can discover the address of the goods manufacturer EPCIS, and have access to product static data, like lot number, expiration date, weight, etc. If the trade partner is interested into dynamic data, such as business transactions, data can be provided through Discovery Services. DS are able to search EPCIS for dynamic data providing the querying party with up to date information about the flow of goods such as Track & Trace, inventories at different supply chain levels, shipments, etc. The DS is not yet a defined part of the EPCglobal Architecture Framework, as claimed by EPCglobal Inc, but rather a placeholder for functionality that is envisioned for the EPCglobal Network but not yet architected [5]. Although many research have been carried out in order to tackle appropriate architectures and implementations of Discovery Services, none of them has established itself as a standard and only a few have been field tested in a real supply chain environment.
This paper strives at designing, implementing and optimizing a fully compatible Discovery Services within a real EPCglobal network. The proposed model fulfills the requirements of scalability, reliability and security, and makes it possible to gather additional information from EPCIS repositories. Traditionally, DS store data related to EPC and timestamps. In our approach, the DS deals also with event action, business steps (biz_step) and business location (biz_location) fields.
The entire research was conducted within the first Italian RFID Supply Chain Pilot in the Fast Moving Consumer Goods industry, in which 12,067 cases and 1,059 pallet have been tagged at the manufacturing lines and followed all the way down to the retail shop floor (for more details consult [6]). The DS architecture has been regularly queried by the receiving party to gather information about the receiving goods.
The remainder of the paper is organized as follows. In the next section, a literature review related to EPCglobal network and DS implementations is examined in detail. In Section 3, after a brief introduction to the RFID Supply Chain Pilot, the DS framework design, methodology and steps for its implementation are described. The main results of the research are presented and discussed in Section 4. Finally, concluding remarks, found limitations and future research directions are pointed out.

II. Literature Review

The functional definition and standardization of the Discovery Service is still at a very early stage, therefore only a few works have studied and proposed new solutions for Discovery Services. Literature review outlines papers focused on the one hand to develop new architectural frameworks for DS implementation and, on the other one, to address security issues of EPC transactions. In the next paragraphs these two points are tackled.
As far as the architectural solutions are concerned, several works propose approaches based on proxy modules. A Proxy is an application module that services the requests of its clients by forwarding requests to other servers. According to Sunghak Song et al. [7], a proxy can be used to reduce query's response time. Reusing existing EPC Track&Trace data, EPCIS servers can get EPC information locally rather than from remotely distributed EPCISs. In the work done by Kuerchner et al. [8], a proxy layer is proposed to reduce the overall complexity.
Another architectural research issue is related to how event notifications may be submitted to the DS: according to Verisign [9], new data records should be added by EPCIS repositories every time a business process ends. A different approach is proposed by Cantero et al. [10], which have implemented a new DS within the BRIDGE EU project (fore more details see [11]). Nome brings in a DS that actively updates itself, obeying to a predefined policy.
Moreover, due to the lack of standardization on how DS data should be set up, different data structures have been proposed. Sunghak Song et al. [7] add two additional fields besides the EPC code and related EPCIS address: Event Time and Record Time fields. The former records when the EPC information is registered for the first time; the latter is overwritten whenever a new event with the same EPC code is added to the EPCIS.
In [12], the data structure contains a security certificate of the company whose EPCIS submitted this record, as well as a visibility flag. The visibility flag indicates whether the record can be shared with everybody or only with parties who submitted records about the same EPC (i.e., supply chain partners). Furthermore, the timestamp about record input is added. Although the previous solutions demonstrate a reduced level of complexity, and thus faster response times, the possibility to retrieve more information such as business step, business location and event action [4] could be rather straightforward, making it possible for clients to avoid expensive EPCIS queries.
Security of DS transactions is another important issue which has been tackled in recent literature. According to EPCglobal [5], DS are strongly recommended when it is ``impractical to follow the flow of goods within the supply chain'' because participants are not known in advance. This point raises up a discussion on how to balance the need for security with the openness of the EPCIS system. In other words, while dedicated mechanisms should be implemented for the sake of security, these tools could prevent access to the EPCIS from unknown clients. Authentication of unknown clients is critical for almost every organization that publishes strategic information on the web, although an heavily secure network leans towards a closed loop system, in contrast with the openness of the EPCglobal Network philosophy.
In [8], a research was conducted to study the impact of different security strategies on the network, suggesting new approaches. In this scenario a client sends an EPCIS query to an external, third party proxy module, named Query Relay, which encapsulates the DS and forwards the query to the appropriate EPCIS repository. In this framework, all the queries made by clients are visible to the proxy, even if the proxy can deny access to the EPCIS resource. In this way only the server privacy is guaranteed.
The demo developed by the IBM Research Center team [12] adopts security certificates for managing EPCIS security. In this system, row-level data access control is granted. Only a querying party owning a valid certificate is allowed to access related records in the EPCIS.
The DS proposed in this work contemplates a proxy module, like other architectures cited in this literature review. Clients do not connect directly to the DS server but they send requests to the proxy, which then contacts the ONS and Discovery services. Any client can get information from the DS, while only authorized clients can write records in it. The authorization control in querying data from a given EPCIS repository is assured by the use of security certificates.
In our work, we propose a new DS data structure with more fields than solutions already implemented. We believe that these fields are paramount to let the clients get dynamic information about a product such as business step, business location and event action together with the EPCIS repository's address. Therefore, clients avoid querying for these data to the remote EPCIS server.
The final relevant point worth remarking is that most of the works reviewed [10], [7] and [8] propose DS approaches that either have not been yet validated in-field or have not been included in a software commercial product. Only [12] claims to have developed a demo software that can be made available on request. Our DS has been thoroughly tested in-field for robustness, availability and reliability. The results of this campaign is presented in Section 4 ``Findings''.

III. Design

A. The RFID Logistics Pilot

The project was officially launched in June 2007 inside the RFID Lab of the University of Parma, in collaboration with thirteen national and multinational companies, operating as manufacturers, distributors, logistic providers and retail companies in the FMCG supply chain, and actively participating in the RFID Lab research activities. Among others, the company panel includes Auchan, Carapelli, Chiesi, Corriere Cecchi, Conad, Danone, Grandi Salumifici Italiani, Goglio, Nestlé, Number 1, Lavazza, Parmacotto, and Parmalat.
The project is the first Italian example of a pilot implementation of RFID and EPC Network (the so-called ``Internet of Things''), enabling to track and trace the flow of products from manufacturers to the final customer.
The main objective of the project was to test and check, by in-field experiments, the technical feasibility and benefits of RFID technology, coupled with the EPCGlobal Network, when applied to the supply chain processes.
An innovative, and probably unique, aspect of the RFID Logistics Pilot project is the methodology followed during its development. In fact, companies involved in the project shared not only the cost of the project itself, but also the design choices, experimentations and the resulting know-how. Hence, only some companies provided manufacturing sites, warehouses and retail outlets for the in-field experiments, while the know-how developed will be shared between all participants to the working group.
The supply chain examined during the pilot involved a manufacturer of food products, its distribution center (DC), a distributor's DC and two retail stores. More than 12,000 cases of product were equipped with RFID tags, which were coded with a unique SGTIN serial number. The flow of cases and pallets, this latter identified through RFID tags and SSCC codes, was traced through the DCs and retail stores, and the data obtained were shared through the EPC Network.
The field experiments involved a DC of Parmacotto, an Italian company leader in the production of sausages and sliced whole, a DC and two department stores of Auchan, one of the main reality of large retailers operating in Italy.
The technology partners of the laboratory RFID Lab also contributed to the project, by providing the RFID hardware and software equipment required for field testing. As regards to the software infrastructure to manage the flow of data generated from RFID reads, this has been designed and developed by Id-Solutions, spinoff company of the University of Parma and Alliance Partners of RFID Lab, under Oracle technology. A group of companies, including (in alphabetical order) Avery Dennison, Caen RFID, Impinj, Intermec, Jamison Doors, Motorola, Psion Teklogix, Siemens, Toshiba TEC, UPM, provided most of the required RFID hardware.
The project also had the support of universities adhering to the Global RF Lab Alliance Network [13].
The experimental campaign took about 5 months, from May to September 2008. In that period, approx 12,000 cases and 800 pallets were equipped with RFID tags and followed in the supply chain involved in the Pilot project.

Fig. 1. RFID Logistics Pilot -- Software Architecture

B. Infrastructure

The software architecture deployed for the project is shown in fig. 1. It is modeled after the standard EPC Network infrastructure [5], and is based on a SOA (Service-Oriented Architecture) approach. The project structure can be separated in three areas, each composed of several loosely coupled and interoperable modules:

The Business Process, encompassing the capturing applications, middleware and RFID devices;
The EPCIS, with standard query and capture interfaces;
The Business Intelligence Modules, which represent the front-end for the operators.

1) Business Process
The Business Process layer provides real-time data collecting from RFID hardware. The raw data is processed according to EPCglobal specifications and the resulting EPC event stored in the EPCIS repository.
The lowest software layer consists of adapters, which allow communication with hardware devices such as RFID readers and printers. The adapter modules hide the details of different vendor specifications and offer a unified interface to the middleware. The middleware provides a framework through which the capturing applications can receive data read from RFID tags and other sensors.
The re-engineered logistic processes are embodied in the capturing applications. Capturing applications have been developed as web services, running on the application server. Some of them are completely automated and run continuously. Other applications support interaction with the operators and expose web interfaces, which can be accessed from either desktop computers and mobile terminals.
The Capturing Applications feed the EPCIS Repository with event data. The project leverage an additional Proxy module that acts as an interface between the capturing applications and the EPCIS. The proxy translates the event data to comply with the standard EPCIS specifications. The following capturing applications have been implemented, identified in EPCIS as biz_step:

- Slap and Ship creates EPC tags for case and pallets, aggregation of cases into shipping pallets.
- Shipping shipment of goods from the manufacturer and distributor DC; checks for order accuracy.
- Receiving receiving goods at the distributor and retail stores; retrieves data via EPC Network, checks for order accuracy (mix and quantity).
- Packing and Marking at the retailer DC, this capturing application tags pallets to be shipped to project stores, and aggregates EPC cases to pallets.
- Replenishment tracks movements of tags from the backroom to the shop floor at the retail store.
- Trash checks the cases that are put into the trash compactor at the retail store, before being destroyed.

2) EPCIS
The EPCIS module implements the standard EPCglobal specifications. It is based on the Fosstrak (previously Accada) EPCIS project [14], an open source software certified by EPCglobal. This module consists of three components:

- EPCIS Repository, whose purpose is to store the EPC events data; the underlying database is MySQL.
- Capture Interface, through which capturing applications can fill the repository with data. The Fosstrak project provides only the HTTP POST protocol binding, so a wrapper was developed to provide access as a web Service.
- Query Interface, which provides data available on the repository to other applications. It is implemented as a web service operation.

3) Business Intelligence
The purpose of the Business Intelligence (BI) module is to analyze the data stored in EPCIS Repositories from trusted Supply Chain partners and to present the relevant results in a Logistics Dashboard. The Dashboard is a web application developed with Oracle technology which provides value added information to assess the efficiency of the supply chain. TheBI modules are based on data stored in a centralized data warehouse, synchronized every 15 minutes by leveraging implemented Discovery Services. Both the Capturing and Accessing applications rely on the ONS and DS components of the EPC Network to locate the appropriate EPCIS servers in the supply chain.
Both the Capturing and Accessing applications rely on the ONS and DS components of the EPC Network to locate the EPCIS servers in the supply chain.
The ONS (Object Naming Service) could be considered a specialized Discovery Service based on the existing DNS infrastructure. When a client queries the ONS with an EPC urn, the ONS provides static supply chain information about the goods manufacturer, such as the EPCIS Query Interface URL and the Discovery Services URLs.
The Discovery Service provides dynamic Track & Trace information: for example, links to remote EPCIS Repositories containing data about a given EPC code. While the ONS has been developed according to EPCGlobal standards, the DS used in the project is original.
It should be noted that the ONS and Discovery services were not strictly necessary in the pilot project, as the supply chain involved a single manufacturer and a distributor, whose EPCIS addresses where known in advance. Nonetheless, we chose to implement them in order to test a full EPC Network, and also for future scalability.

C. Discovery Services Implementation

The module providing Discovery Services functionality for the project was developed to fulfill the following requirements:

- DS should provide up-to-date, dynamic routing information for EPCIS queries.
- DS should not replicate data stored on the EPCIS repositories, except for routing purposes.
- Routing granularity should be at least at company level: an EPCIS URL offered by the DS identifies a company. To achieve more granularity (specific sites, business steps, etc.), some EPCIS data replication is needed.
- In the project, communication between capturing applications and DS flows through the public Internet, therefore it should be encrypted to ensure confidentiality. Authorization and authentication are ensured for DS updates, but not for queries. In other words, DS replies to all queries made by any clients: but when clients use the provided information to query the actual EPCIS servers, these servers can enforce their own authorization policies.
- DS URLs should be registered in the ONS, so clients can find them by querying the ONS.

Fig. 2. Discovery Service Architecture

The DS acts as a directory lookup service. It has been developed as a web service that, given an EPC code, provides the address of the EPCIS where the tag with the specified code was last seen. Alternatively, the DS can provide the list of all the EPCISes where a certain tag has ever been seen. The DS is a centralized service for all the EPCISes implemented (see fig. 2).
When the client has obtained the addresses, it can then contact the EPCIS servers, querying them through the EPCIS Query interface. Access control is delegated to the EPCIS servers themselves. In this way the DS replies to any query made by a client: but when clients use the provided information to query the actual EPCIS servers, these servers can enforce their own authorization policies. This approach guarantees an high degree of privacy for the clients, who retain full control of their queries, but a lower one for the EPCIS servers, because anyone can see which servers contain information about an EPC (even if they are not authorized to access that information).
The next sections discuss the update and query procedures in detail.

1) Updating the DS
As mentioned in the Literature Review, there are two fundamentally different approaches to updating the DS information:

- The DS queries all the EPCIS servers to check if they have information about a specified EPC code, then it collects the replies and returns the list of URLs to the client. The advantages of this approach are that the DS does not store data internally (except maybe for caching), and the update process is transparent to the EPCIS servers. The downsides are that queries to the DS are slower, and the DS must know in advance the URLs of all the EPCIS servers.
- The EPCIS servers (or proxies on their behalf) notify the DS, either periodically or on each Capture operation, of the EPC codes they have information about. The DS stores the data locally and on each query it performs a local search. The advantages are faster responses, and reduced traffic on the DS. The main disadvantage is the need for data storage on the DS.

The proposed solution follows the latter approach, but it assign the DS update to an external proxy module. Proxy receives the capture request, converts it in the standard EPCIS Capture Interface format and forwards it to the appropriate EPCIS server. concurrently, the proxy checks whether the capture request can be relevant for the DS. If so, it sends the record data to the DS using its web service secure interface. The DS is notified only if the capture event is of type ``Object'', and if the capturing on the EPCIS was successful. The proxy uses the ONS to find the URLs of the DSes to be notified about the captured EPC.
The DS stores its data in a dedicated relational database. Records have the following attributes:

- ID unique record id
- EPC EPC code, either in SGTIN or SSCC format
- EPCIS Query Interface URL of the EPCIS that submitted this record
- TIME_STAMP when this record was inserted
- BIZ_STEP business step, as reported in the capture operation
- BIZ_LOCATION business location, as reported in the capture operation
- EPCIS_ACTION event action, as reported in the capture operation

The last 3 attributes provide additional details about the EPCIS event. The main benefits of the proposed data structure can be summarized as follows: They allow a higher level of granularity in the routing information: for example, a large organization could have different EPCIS servers, each containing information about events with a particular business location attribute. Moreover, a client could avoid querying the EPCIS server if all the data it needs are contained in these fields.
These attributes could be either omitted or easily certificate-protected for privacy concerns, to avoid disclosure of reserved data to non-authorized clients. In our project there were no such concerns because all parties agreed to share their EPCIS information.

2) Querying the DS
In the proposed architecture, clients and applications do not contact the DS directly: all their queries are made by means of a proxy module. In this way, the process of determining routing information through ONS and DS is completely transparent to the applications.
The proxy can provide three kinds of information: the address of the manufacturer's EPCIS for a given EPC code, the address of the EPCIS which has the most recent information about a given EPC code, or the addresses of all the EPCIS servers which have information about a given EPC code. In addition to the address, the other attributes described in the previous section are also returned to the client.
Upon receipt of a query on behalf of a client, the proxy first queries the ONS with the specified EPC code. The ONS leverages the hierarchical DNS structure, and the query is forwarded until a DNS server provides the required information (in this case the manufacturer's EPCIS URL and one or more DS URLs). If the client is interested only in the manufacturer's EPCIS URL, its request is matched and there is no need to contact the DS. Otherwise, the proxy queries each DS in the list returned by the ONS. Each DS searches its database and returns all records matching the specified EPC code. As alredy said, certificates have not been implemented at this stage to manage privacy issues, but could be easily scaled. The proxy finally merges the results from all DSes and returns them to the client.

IV. Findings

The experimental campaign took about 5 months, from May to September 2008. In that period, approx 12,000 cases and 1000 pallets were equipped with RFID tags and followed in the supply chain involved in the Pilot project.
The hardware employed in the project consisted of 8 RFID readers, three RFID printers and two mobile terminals also equipped with RFID readers. The devices were deployed at four different sites: a manufacturer's DC, a distributor's DC and its two retail stores. In each site there was a local application server installed, running the middleware software and capturing applications.
Either the retailer and the manufacturer installed their own EPCIS in EDP departments, located in Milan and Parma respectively. The Discovery Services and the ONS modules were located in RFID lab, Parma. All communication between the computers in the two companies and our lab flowed on the public Internet.
Various tweakings and enhancements to the existing network infrastructure within the two companies were needed in order to setup a fully functional EPC Network: mainly, configuring firewalls and enabling standard 802.11g wireless access.
The DS proved itself stable through the whole experimental campaign and its performance was more than adequate for the workload. Some performance statistics for the DS web services collected during the 5-months campaign are presented in table I.

Table 1. Performance statistics of the DS web services.

At the end of the campaign the DS database contained 56,841 records, with 13,126 unique EPC codes. Its final size was 48 MB.
The system was designed with extensibility and scalability in mind. Although in our project there is only one DS, the architecture supports multiple DSes registered in the ONS for each EPC code. Routing data such as EPCIS and DS URLs and ONS records, were not hardcoded in the system, even though they were actually known beforehand, but the whole supply chain was dynamic. This feature proved to be very useful also during the testing phase, when we changed the system configuration over and over, as the full network infrastructure was being built.
Existing best practices, already widely deployed, can be used to improve performance of DS queries, because they rely on the well-known HTTP/HTTPS protocols: technologies like load balancers, caching, message compression, etc. could thus be applied.

V. Conclusion

The definition and standardization of the Discovery Service component of EPC Network is still at a very early stage. This paper presents a possible implementation of the Discovery Service, tested within the first Italian RFID Supply Chain Pilot in the Fast Moving Consumer Goods industry. The pilot is the first Italian example of an implementation of RFID and EPC Network.
The main objective of this project was to test and check the technical feasibility and benefits of RFID technology and EPC network by in-field implementation. The flow of cases and pallets through the supply chain was traced through a manufacturer's DC, a distributor's DC and two of its retail stores. The data obtained were shared through an standard EPC Network architecture.
The proposed Discovery Service provides dynamic Track & Trace information, such as links to EPCIS servers, and is invoked as a Web Service by the Capturing and Accessing applications in the system. All requests to the DS are made through a proxy module. Regarding access policies, the DS tries to balance the need for security with the openness of the EPCIS system. The DS accepts any query without requiring authorization, but only authorized parties can insert records into the DS database. Other security policies are delegated to the EPCIS servers, which could restrict access with a finer level of granularity. The definition of such security mechanisms is one of the future developments of our research. in field tests have demonstrated the accessibility, the robustness as well as the reliability of the approach proposed. Moreover, the system was conceived with scalability as one of the primary concerns. We plan to extend the pilot project by adding new players to the supply chain, therefore increasing the number of EPCIS and DS servers.
A future research topic will be the design of a hierarchical architecture to manage large scale RFID infrastructures. This issue will be tackled in the second stage of RFID Logistics pilot project, which is expected for 2009. In this step, more manufacturers and retailers will be added, and new DS will be needed to manage appropriate routing to supply chain EPCIS servers.

References

[1] EPCglobal Inc., http://www.epcglobalinc.org/, accessed on Nov. 2008

[2] The EPCglobal Network - Overview of Design, Benefits, & Security, http://www.epcglobalinc.org/about/media centre/Network Security Final.pdf, accessed on November 2008

[3] M. Harrison, “EPC Information Service”, Proc. Auto-ID Labs Research Workshop, University of St. Gallen, Switzerland, Sep. 2004

[4] EPC Information Services (EPCIS) Version 1.0.1 Specification, http://www.epcglobalinc.org/standards/epcis/epcis 1 0 1-standard-20070921.pdf, accessed on November 2008

[5] F. Armenio et al. (2007,Sep.). The EPCglobal Architecture Framework, EPCglobal Inc., http://www.epcglobalinc.org/standards /architecture/architecture 1 2-framework-20070910.pdf, accessed on Nov. 2008

[6] RFID Logistics Pilot site, http://www.rfidlogisticspilot.com /index.php, accessed on Nov. 2008

[7] Sunghak Song et al. “Proxy based EPC Track&Trace Service”. IEEE International Conference on e-Business Engineering.

[8] C. Kuerschner, C. Condea, O. Kasten and F. Thiesse. “Discovery Service Design in the EPCglobal Network Towards Full Supply Chain Visibility”. Proc. The Internet of Things, 1st International Conf.. Zurich, Switzerland, Mar. 2008

[9] “The EPCglobal Network: Enhancing the Supply Chain”, Verisign, Whitepaper, http://www.verisign.com/stellent/groups/public/documents/white paper/002109.pdf, accessed on Nov. 2008

[10] J.J. Cantero et al. “Traceability applications based on Discovery Services”. IEEE International Conf. Emerging Technologies and Factory Automation, pp 1332-1337. Sep. 2008

[11] BRIDGE EU Project site, http://www.bridge-project.eu, accessed on Nov. 2008

[12] S. Beier, T. Grandison, K. Kailing and R. Rantzau. “Discovery Services - Enabling RFID Traceability in EPCglobal Networks”. Computer Society of India. 2006

[13] The Global RF Lab Alliance (GRFLA), http://www.grfla.org/, accessed on Nov. 2008

[14] Fosstrak Project, http://www.fosstrak.org, accessed on Nov. 2008