Packaging / Aseptic Processing

Beyond Gen2: The Next Step Toward RFID Ubiquity

A look at how the tag can be decoupled from the application, and why.

By Thomas A. Polizzi, WCCN Publishing, Inc.

Editor’s note: For information on Tom Polizzi’s insider newsletter, "The WCCN Letter," and on Polizzi’s book, "RFID in the Enterprise," visit www.wccn.com.



By the fall of 2005, serious quantities of production level Gen2-compliant RFID tags will become available. This represents a major milestone for deployment of passive tags. Full implementations of the Gen2 standard (generally referred to as the Dense Reader implementation) represent the first implementation of an industrial strength passive tag air interface protocol that has virtually universal acceptance as the passive tag protocol for UHF band passive tags. That acceptance has been given by the major RFID suppliers, users, and, of critical importance, the International Standards Organization (ISO). Additionally, the expectation is that the Gen2 Standard will facilitate the creation of comparable passive tag standards for other frequency bands, such as the 13.56 MHz band. 

However, the existence and acceptance of Gen2 does not mean ubiquity has arrived. There are a few more milestones that have to be achieved.

Ubiquity is defined as: Tags sourced from any standards-compliant supplier should be productively and comprehensively accessible by any enterprise user’s RFID application. This requires more than the capability for any tag reader, sourced from any standards-compliant reader supplier, being able to read the tag procured from any standards-compliant tag supplier. What additionally is required is a means of decoupling all applications from the tag while, at the same time, allowing each specific application to interoperate properly with the tag. To accomplish this will require additional standards beyond Gen2. Equally as important, it will require universal acceptance of the additional standards.

Complicating achieving the acceptance of a tag-application decoupling protocol set is the desire for said set to be applicable for all passive tags — regardless of which band the tags are designed to operate in.

The good news is that a set of ISO application decoupling standards already exists. Below we describe how the decoupling is accomplished, and we elaborate on why this decoupling is necessary.

Gen2 standardization

What Gen2 standardizes is the radio-to-radio communications between Gen2-compliant tags procured from any supplier and Gen2-compliant Readers procured from any supplier. Additionally, Gen2 standardizes elements of the record format of the transmission.

The tendency is to say that Gen2 provides a standardized air interface. This is true. But it is more accurate to say that, in its full-function implementations, Gen2 provides industrial strength radio communications that have a high threshold for providing successful transmissions in an environment of intermittent radio interference, and the inevitable collisions of multiple tags attempting to transmit concurrently. Gen2 radios support reliable transmissions boasting data rates up to tenfold greater than previously possible. Additionally, the ISO version of Gen2 supports a formidable number of record formats — including many tag ID schema. Finally, Gen2 tags are “read many/write many” tags.

Compare this to the pre-Gen2 systems that charitably could be described as providing proprietary, error-prone, non-industrial strength radio communications, using a confusing array of radio methods, data record formats, and restricted read and write capabilities.

What Gen2 doesn’t do

However, the ability to exchange records between tags and readers that are separately sourced, and to recognize the record format of the transmitted record, does not translate into having meaningful and actionable information. Nor is it desirous to have all in-range tags always respond to a reader interrogation — swamping the reader and the operating application program with receipt of a plethora of unnecessary tag transmissions.

It would be far more preferable to be able to have the reader perform conditional interrogations — interrogations that order only tags attached to a specific category of objects to respond — and/or to respond with application required items of tag stored data that are not routinely transmitted when the tag is interrogated. Conversely, it is desirable to have the reader instruct a specific tag, or a category of tags, to store an item of application supplied data.

Stated succinctly, there is the need to provide (vertical) application control over the behavior of the tag. This is over and above the anti-collision control handled by Gen2.

But providing application control over tag behavior creates a problem. Tucking software into the tag to respond to commands of a specific application employed by a specific enterprise reduces — returns — the tag to a proprietary tag, which is as unacceptable as it is impractical. Imagine the number of various applications within a supply chain that would each require a huge amount of code to be tucked into each tag.

Enabling non-proprietary application control

The solution is to create a structure of meta commands to which the tags have been provisioned to respond. Such commands would be designed to have the tag perform discrete generic actions fundamental to any action that any application may require. Some of the generic actions to be performed would require parameter settings. The important thing is that these meta commands would be application-agnostic.

A specific application would be able to string combinations of the meta commands together (with parameter settings) to achieve the desired tag behavior.

By this approach, the tag would remain ubiquitous, yet would be able to provide meaningful and actionable information that is application-specific.

The standards to achieve this open system tag behavioral control functionality exist. They comprise the ISO 1596x standard series. We will describe the essence of this set of standardsat a very high level, taking a bit of poetic license, and omitting optional aspects and negatives of the standard that we expect to be expunged sooner or later.

The heart of the capability is specified in ISO 15962. The functionality it specifies is expected to reside in the tag reader, and includes an object-based protocol for processing data content. On the application side of 15962 implementations is a 15961 module that provides for converting the application-specific commands to a series of meta commands to be presented to 15962. The 15961 module converts the meta responses from the tags to application-specific formats.

Essentially, the 15961 module is the interface between the application and the 15962 module, with 15961 making the application transparent to the tag. The 15961 module can reside in the reader, or in an Edgeware server that is linked to the reader.

On the tag side of the in-reader 15962 module is what the specifications call the 15962 annexes; they are the tag drivers that include the logical memory mapping rules for the tag. The 15962 module, as specified, is capable of handling multiple tag drivers. Thus, conceptually, multiple proprietary tags could be supported. With the adoption of Gen2, in place of supporting multiple proprietary tags, we believe there will be instances of multiple drivers to support different versions of Gen2, as Gen2 is modified for technological advancements in the future. Those multiple drivers will provide an assured and proper method for maintaining backwards compatibility.

Naturally, the companion of the 15962 annex in the reader has to be present in the tag for this scheme to work. The specifications for the version of the annex in the tag call for providing an interface for customized in-tag processing. Unfortunately, until there is more (standards-making) consensus across the supply chain on just what data to store in the tag, and how to store it, we expect to see a great deal of customization being implemented. But the beauty of the 1596x approach is that it will be relatively easy to move to data content standardization as enterprises within the supply chain increasingly reconcile their individual data storage requirements with what is the universal supply chain requirement. In the meantime, Gen2 as encapsulated in ISO 18000-6c with ISO 1596x gets us close enough to workable ubiquity to say we have RFID deployment lift-off. Let the benefits begin.



Note: For readers interested in such detail, WCCN Publishing, in its RFID Handbook, "RFID in the Enterprise," has been able to map the 1596x standards into the standard OSI Reference model. The import of this is assurance that the 1596x functionality has been layered properly, sufficiently so that it can support different air interfaces. This is an important advantage as we attempt to integrate different tag types, operating in different frequencies (as is the case for pharmaceutical applications), into a single RFID infrastructure.


Thomas A. Polizzi is president and executive editor at WCCN Publishing Inc., publisher of the best-selling "RFID in the Enterprise Handbook" and "The WCCN Letter," a monthly devoted to RFID and wireless systems architectures and infrastructures. He can be reached at tpolizzi@wccn.com.

Free Subscriptions

Pharma Manufacturing Digital Edition

Access the entire print issue on-line and be notified each month via e-mail when your new issue is ready for you. Subscribe Today.

pharmamanufacturing.com E-Newsletters

A mix of feature articles and current new stories that are critical to staying up-to-date on the industry, delivered to your inbox. Choose from an assortment of different topics and frequencies. Subscribe Today.