Data and Network Standards
EPCglobal standards
As small scale RFID implementations emerged earlier, it is understandable that the development of data and network standards began later than the definition of air interface standards. Also, it is obvious that the topic is heavily driven by EPCglobal, since the vision of having worldwide access to product information can only be realised by standardised infrastructure. First steps of defining a software architecture were taken by the Auto ID Center. After its take over by EPCglobal a set of standards has been worked out and released. The activities have been implemented partly without taking into account existing ISO standards. However, EPCglobal Standards are royalty free, which cannot be said about every ISO standard.
- Architectural Framework Document
The Architectural Framework Document (AFD) defines and describes the EPCglobal architecture framework which is a collection of interrelated standards for hardware, software, and data interfaces, together with core services that are operated by
EPCglobal and its delegates, all in service of a common goal of
enhancing the supply chain through the use of Electronic Product Codes
(EPCs). The document outlines the top level architecture of core
services that are operated by EPCglobal and enumerates. At a high
level, it also displays all hardware, software, and data standards that
are part of the EPCglobal Architecture Framework and how they are
related. Additionally, the design principles that underlie all parts of
the framework are explained.
The current version of the specification was published on 10 September
2007.
- EPC Tag Data Standard
The EPC Tag Data Standard (TDS) defines the overall structure of the
Electronic Product Code (EPC), i.e. the particular portion of EPC tag
data standardised by EPCglobal. It specifies different coding schemes
combining existing numbering structures like the GS1 family of coding
schemes with the US Department of Defence’s CAGE/DoDAAC scheme.
For each of these coding schemes, there are binary representations for
use on RFID tags (i.e. the EPC Tag Encodings) and text representations
for use within information system layers of the EPC Systems Network
(i.e. the EPC URI or Uniform Resource Identifier Encodings). Last but
not least, rules for converting one representation into another exist
as well. The EPC URI Encodings provide means for application software
to process EPC Tag Encodings either at the bit level or at various
other levels of semantic abstraction independent of tag variations
(i.e. the EPC Pure Identity URI). Moreover, a pattern URI
representation is defined that does not represent a single EPC, but
rather refers to a set of EPCs.
The current version 1.3 of the specification comprises encodings for
EPCs of 96 to 202 bits length.
It cannot be assumed that all worldwide market segments will accept the
EPCglobal schemes; rather it is very likely that important market
players will set up their own numbering standards. Many ISO air
interface standards support permanent UIDs, having the advantage that
the uniqueness of the identifier is guaranteed by the semiconductor
supplier. Hence, there is no need to program unique codes outside the
semi-conductor foundries. To avoid interoperability problems, superior
ISO standards like ISO15963 are of major advantage.
- EPC Tag Data Translation Standard
EPC Tag Data Translation (TDT) specification is concerned with a machine-readable version of the EPC tag data standards specification. The machine-readable version can be used for validation of EPC formats as well as for automatic translation between different levels of representation in a consistent way. The specification describes how to interpret the machine-readable version. It contains details of the structure and elements of the machine-readable mark-up files and provides guidance on how it might be used in automatic translation or validation software, either standalone or embedded in other systems. A software implementation of this standard may automatically become aware of new EPC formats enabling translation and validation. It might do so by providing these formats with an updated version of the TDT mark-up files (published by EPCglobal) comprising new EPC formats.
The current version 1.0 of the TDT specification is compatible to TDS 1.1 revision 1.27.
-
Reader Protocol Standard
The RFID reader transforms information transferred via air interface into a digital domain. Reader Interface Standards define the designs of data exchange, configuration and reader management functions. Often, many different types of readers are required within one single RFID project. Modules inserted in printers or mobile computers, desk top terminals or enormous standalone readers at doc-doors ask for a modular concept and specific means to ensure quality and reliability aspects.
The reader protocol (RP) standard defines the protocol by which tag readers interact with EPCglobal compliant software applications (e.g. an EPC-aware middleware). The terms “tag reader” or “reader” include RFID tag readers, supporting any combination of RF protocols, fixed and handheld, etc. It also includes readers of other kinds of tags, such as barcodes. Tag readers, despite their name, may also have the ability to write data into tags. In particular, the Reader Protocol is intended to provide complete access to all capabilities of the UHF Class 1 Gen 2 Tag Protocol including modulation formats, data rates sessions, and passwords, as well as reading, writing, locking, and killing tags. The latest working draft version 1.1 of the reader protocol specification does not fully realise this goal, but it is the intent of EPCglobal to address this issue in the next version of the protocol.
An important goal of the reader protocol is to insulate software applications from knowing the details of how reader and tags interact. Readers may employ a variety of protocols to interact with tags, but the same reader protocol is used for communication between application and reader.Only a minimum set of commands specified by the standard is obligatory to be supported by a reader. Therefore, most of the commands are optional and compliant readers may differ heavily in their supported functionality: A high-end reader may asynchronously inform the application of tags entering or leaving the reader’s field, while a low-end reader needs to be polled for current tags. The reader protocol conformance requirements will be developed to categorise readers by their functionality.
The specification provides means (and a compliant reader may support these) to control the smoothing of tag events, to filter and aggregate captured EPC data.
The current version of the RP specification is 1.1. The protocol is unaware of air interface and also supports existing HF protocols or a barcode reader.
EPCglobal decided to add an additional reader protocol standard, the so-called low level reader protocol which is described below. Therefore, the standardisation working groups will deliver two different documents: The High Level Reader Protocol (HLRP) and the Low Level Reader Protocol (LLRP). HLRP is sought to be the next version of RP 1.1. As a high level reader protocol, HLRP is unaware of air protocols.
In contrast to this, LLRP is a low level reader protocol.
- Low Level Reader Protocol Standard
The Low Level Reader Protocol (LLRP) specifies an interface between
RFID readers and clients. In contrast to RP 1.1, the LLRP explicitly
controls the RFID air protocol operation timing and the access to air
protocol command parameters, even though only UHF Class 1 Gen2 specific
parameters are currently supported.
The LLRP allows retrieving reader device capabilities, which are needed
to command a reader to inventory tags, read tag data, write tags, and
execute protocol-dependent commands such as “kill” and “lock”.
Additionally, for enhancing the simultaneous operation of RFID readers
in a dense environment, it provides means to control the forward and
reverse RF link operation to manage RF power levels and spectrum
utilisation, and assess RF interference.
The communication performed by LLRP is based on messages and the only
encoding specified is a binary one.
The current version of the LLRP specification is 1.0.
The structure of the standard is well-organised. The standard is open
for adding support of additional air interfaces. The handling of
optional commands has been improved. The complete function set of Gen2
air interface standard is supported. Secure data transfer to the back
end systems is foreseen as optional. Management functions such as
firmware update and diagnosis are described.
It has to be noted that for the implementation of the complete
functionality a certain level of computing power is needed. Binary
binding for the protocol has been chosen to limit hardware costs
resulting in high implementation efforts.
- Reader Management Standard
The Reader Management (RM) standard defines the wire protocol used by management software to monitor the operating status and health of EPC- global compliant tag readers. It complements the RP which defines the collection of tag data between reader and application.
The specification provides means to query the configuration of a reader, such as its identity or number of antennas, and to monitor its operational status like the number of tags read, the status of communication channels, antenna connectivity, or transmit power levels. The protocol also allows controlling the configuration of a reader, e.g. enabling or disabling specific antennas or features, and may support access to additional management functions including discovery, firmware configuration and updates, and managing reader power consumption.
The consequent separation of reader protocol standards and reader management standards permits that applications supporting critical business processes like supply chains and manufacturing lines become controlled by RFID. In this case specific system management software can be used in order to guarantee a high level of system availability at low service cost. Reader suppliers, who do not want to support this specific market segment, might choose not to implement that standard.
-
Application Level Events Standard
The Application Level Events (ALE) standard specifies an interface
through which clients may obtain filtered, consolidated EPC data from
various sources. Its role in the EPCglobal framework is “Filtering
& Collection”, i.e. reducing the volume of data that comes directly
from EPC data sources (readers) into coarser “events” of interest to
applications. The ALE interface also provides independence between the
components performing the Filtering & Collection of EPC data and
the applications that depend on the data (similarly the reader protocol
decouples the infrastructure components that acquire the raw EPC data
from the Filtering & Collection components). Therefore, it
abstracts multiple readers of different kinds to a single, logical data
source.
ALE provides declarative means for client applications to specify what
mode of processing to perform on EPC data, including filtering,
aggregation, grouping, counting and differential analysis (i.e.
reporting only changes in the set of read EPCs). Client applications
may choose to request the processed data on demand or as standing
request (“synchronous” or “asynchronous” delivery). Both requests and
reports containing processed data poses standardised representations
that are forward compatible with future revisions of the
standard.
However, the current version 1.0 of the ALE specification lacks the
functionality for writing EPCs and for accessing user data on tags. For
this reason it may only be applied to use cases where tags are
inventoried (i.e. EPCs carried on tags are read). Both issues, as well
as security and role management are to be addressed in the up-coming
version 1.1 of the ALE standard.
The ALE standard 1.0 was released in September 2005 and is used
frequently. The event methodology is very efficient and well accepted.
The standard is open to all available air interface standards.
- Object Naming Service Standard
The Object Naming Service (ONS) Standard specifies how the Domain
Name System is used to locate authoritative metadata and services
associated with a given EPC. In particular, the specification explains
how the EPC Manager Number and object class parts contained in the
SGTIN EPC scheme are transformed into a domain name. This domain name
is resolved by the EPCglobal ONS root server (which is in fact a DNS
server). For further resolving of the SGTIN object class encoded, the
domain name then is delegated to the ONS/DNS server of the
corresponding EPC Manager. The current version 1.0 of the ONS
specification only addresses the ONS lookup mechanism for the SGTIN EPC
scheme. Future work by the ONS Working Group will address how ONS is
used for other namespaces that build the EPC and that are outlined in
the EPCglobal TDS.
The principle of ONS is that product information shall be found on
request. As a precondition, this information has to be made available
by the participants of the supply chain. However, for this purpose a
tremendous amount of data management efforts have to be met and a
commitment for making data available outside the company is needed as
well. Today, ONS servers are provided by the US company VeriSign
only.
- EPCglobal Certificate Profile Standard
The EPCglobal architecture framework document describes how security
functions such as authentication, access control, validation, and
privacy protection of individuals and corporations will be distributed
across many of the roles/interfaces operating within the EPCglobal
network. For instance, EPCIS interface responsibilities may include
means for mutual authentication of two parties exchanging EPCIS data
via that interface.
The authentication of entities (subscribers, services, physical
devices) operating within the EPCglobal network serves as the
foundation of any security function incorporated into the network. The
EPCglobal architecture allows the use of a variety of authentication
technologies via its defined interfaces. It is expected, however, that
the X.509 authentication framework will be widely employed within the
EPCglobal network.
To ensure broad interoperability and rapid deployment while ensuring
secure usage, the Certificate Profile Standard defines a profile of
X.509 certificate issuance and usage by entities in the EPCglobal
network. The document specifies the signature algorithms and minimum
key lengths to use as well as the certificate profile for the different
types of entities.
The current version of the specification is 1.0.
By this standard the basic security mechanisms between the software
components of the EPCglobal framework are defined. It does not specify
any security related to the air interface.
- EPC Information Services
The goal of EPC Information Services (EPCIS) standards is to enable
disparate applications to leverage EPC data by EPC-related data
sharing, both within and across enterprises. Ultimately, this mode of
sharing is aimed at allowing participants in the EPCglobal Network to
gain a shared view of the disposition of EPC-bearing objects within a
relevant business context.
The currently unreleased specification is intended to provide only a
basic capability that the user community has identified as a minimally
useful set and is expected to be extended in follow-on versions of the
standard.Via the defined EPCIS capture interface an application can
communicate EPC-related business events to an EPCIS Repository for
storing. An event contains data representing four dimensions (“what,
when, where, and why”): (1) the object(s) or other entities that are
the subject of the event (“what?”); (2) the date and time (“when?”);
(3) the location at which the event occurred (“where?”); (4) the
business context (“why?”).
The EPCIS Repository stores these events plus metadata concerning
the locations and business contexts referred to in the events and
provides the EPCIS Query Interface whereby an application can request
and query for event and metadata. In the first version of this
specification there will be no standard way of defining these metadata
though.
The current version of the specification is 1.0.
An important aspect which has to be considered according to EPCIS and
ONS is the management of reference databases which are not located in
EU countries. E.g. EPCglobal has authorised the US company VeriSign to
manage the reference database for RFID tags.
ISO/IEC Standards
In order to secure interoperability of RFID related software and the uniqueness of serial numbers, ISO defined a set of data and network standards. All ISO air interface standards are supported. These standards have been available before EPCglobal activities started. ISO standards represent a set of minimum requirements and deliberately do not define very specific rules for software implementation to broaden the field of applications the standards may be applied to.
- ISO/IEC 15961 (reader interface standard)
The data protocol used to exchange information in a radio-frequency
identification (RFID) system for item management is specified in
ISO/IEC 15961 and in ISO/IEC 15962. Both are required for a complete
understanding of the data protocol in its entirety; but each focuses on
one particular interface: ISO/IEC 15961 addresses the information
interface with the application system, whereas ISO/IEC 15962 deals with
the basic processing of data and its presentation to the RF tag.ISO/IEC
15961 “Radio frequency identification (RFID) for item management – Data
protocol: application interface” focuses on the interface between the
application and the data protocol processor, i.e. an intelligent reader
or a middleware. It includes the specification of the transfer syntax
and definition of application commands and responses.
The standard provides guidelines how tag data shall be presented as
objects made up of fundamental primitive types and how these objects
are identified. The defined commands allow reading, modifying, and
deleting the existing objects and creating new objects on a specific
tag. Data and commands are specified in a standardised way, independent
of the particular air interface of ISO/IEC 18000.
ISO/IEC 15961 is expected to serve as a standardised interface which
software for particular RFID applications is based on.
The current version of the specification is ISO/IEC 15961:2004. It is a
very basic rule set to define read and write commands. Neither
communication bindings nor air interface specific commands are
represented. The quite abstract approach results in high complexity
which renders the implementation of the standard in current
interrogator firmware practically impossible. In contrast to most
interfaces specified by EPCglobal, ISO 15961 does only provide a
synchronous interaction mode. The standard has not been reflected in
available products up to now.
ISO/IEC 15961 is a three-piece document:
-ISO/IEC NP 15961-1 information technology — Radio frequency identification (RFID) for item management — data protocol — Part 1: Application interface.This part defines the transfer of data to and from theapplication, supported by appropriate application commands and responses.
-ISO/IEC CD 15961-2
information technology — radio frequency identification (RFID) for item
management — data protocol — Part 2: registration of RFID data
constructs.
This part defines the registration procedure of RFID data constructs to
ensure that the data protocol supports new applications, in a
relatively straightforward manner, as they adopt RFID technology. This
can be achieved by the registration authority publishing regular
updates of RFID data constructs that have been assigned, and for a
means of incorporating these updates into the processes of ISO/IEC
15961-1.
-ISO/IEC CD 15961-3 Information technology — radio frequency
identification (RFID) for item management — data protocol — Part 3:
RFID data constructs.
This part defines the RFID data constructs and the rules that govern
their use.
- ISO/IEC 15962 (data standard)
ISO/IEC 15962 “Radio frequency identification (RFID) for item
management – Data protocol: data encoding rules and logical memory
functions” focuses on encoding the transfer syntax, as defined in
ISO/IEC 15961 according to the application commands defined in that
standard. It defines how objects including their software analogue of
the physical memory of the RF tag being addressed by the interrogator.
Furthermore, it describes the so-called tag driver as an interface to
the air interface definitions of ISO/IEC 18000.
As a consequence, tags will not only contain user data, but also
metadata allowing an interpretation of the tag data as objects. The
structure of a specific object is determined by its object identifier
included in the metadata. Object identifiers are structured
hierarchically and therefore ensure the uniqueness of data
objects.
The current version of the specification is ISO/IEC 15962:2004.
This standard defines rules for optimised memory access even for user.
For very small memories the concept is too complex, thus it suits
applications with tags holding big amounts of user data.
- ISO/IEC 15963 (data standard)
ISO/IEC 15963:2004 “Radio frequency identification for item
management – Unique identification for RF tags” describes numbering
systems available for the identification of RF tags.
Unique IDs are required as part of the write operation to RFID tags.
These IDs guarantee that the information written to a tag is written to
the correct data carrier (tag) unambiguously. Also, unique IDs are
required in many read situations where the contents of a tag are tied
to a specific item and that item needs to be identified
unambiguously.
The specification differentiates between permanent unique and virtual
IDs. Permanent unique IDs are completely and globally unique and shall
be programmed into the tag. A virtual tag ID is a temporary ID that may
vary over the life of the tag and that needs to be unique only for all
tags present to a specific interrogator at a given time. The standard
outlines advantages and disadvantages of these two types of IDs.
The current version of the specification is ISO/IEC 15963:2004.
This standard both supports permanent unique IDs programmed into the
chips by semiconductor suppliers (ISO UIDs) as well as virtual IDs
(EPCglobal Gen 2 Standard). Furthermore, it defines an allocation
class, i.e. an identification of the identifier issuer, for EAN.UCC or
EPCglobal, respectively.
- ISO/IEC 24791 (all categories)
ISO/IEC 24791 “Radio Frequency Identification (RFID) for item management – Software system infrastructure” (formerly known as ISO/IEC 24752) is an extension to ISO/IEC 15961 and 15962 and defines the software infrastructure that readers are embedded in. The six parts comprise the areas architecture, data management, device management, application interface, device interface, and security. This sort of specification has only just begun. By comparing the ISO with the EPCglobal architecture, big gaps necessary to be filled can be found, especially between ISO 15961 and ISO 15962. Furthermore, efforts are made to incorporate EPCglobal standards, i.e. an alignment with EPCglobal has been initiated.
See more(ISO/IEC 15961)
