Industry standards ease task of embedding RFID

Industrial Embedded Systems — December 17, 2007

When Lego engineered its form of childrenís building blocks, one particular aspect made the company stand out from the rest – a simple, elegant interface standardized and engineered to exacting specifications. As anyone who has ever played with Legos can attest, these building blocks fit together perfectly; itís very rare to have a connection that doesnít work properly. With that simple interface between blocks, an entire market was born, in large part because the connection works well consistently.

Similarly, technology adoption usually accelerates once standard interfaces are put into place, particularly if that standard is well thought out and considers the needs of all parties. Recognizing this truth, end users, reader vendors, and application software vendors came together under the auspices of EPCglobal to create a new standard for the network connection between RFID readers and their controllers, often called clients. The output of this EPCglobal working group is the LLRP standard for the client-reader interface, which EPCglobal ratified in April of 2007. With tag and reader interface standardization (the UHF Gen 2 air interface protocol) already in place, this specification was the logical next step in facilitating RFID adoption.

So why is the development of LLRP important, and how does it work?

Simpler client-reader connection enables innovation

The way an RFID reader is used and the device controlling it can vary; these aspects depend mostly on the application (see Figure 1 for an example). But while the end businesses these clients support may differ, the function of the interface between the controlling device and the reader remains the same – commanding the reader to inventory tags and otherwise access them. (Of course, there are secondary support functions, such as controlling the RF link to obtain optimal performance, determining RFID device capabilities, receiving status, and handling errors.)

Figure 1: an RFID reader is used and the device controlling it can vary; these aspects depend mostly on the application

LLRP eliminates the task of writing numerous proprietary protocol interfaces that all support the same functionality, thereby removing the mechanical aspects of an implementation and allowing solution providers to focus on the application itself. At the same time, both reader vendors and application software vendors still wanted to differentiate their products. So in creating this new standard, the advocating group included a rich set of vendor extension points that allow reader vendors the flexibility to innovate and differentiate their products, yet still operate within the standardized network framework.

With clearly defined extension points, the controlling software can more easily expose extensions unique to particular products. End users also can propose extensions for features specific to their enterprise. Innovations created under these scenarios will likely drive future developments of the standard.

LLRP increases modularity

LLRP supports an ability to poll the readers on a network for their particular capabilities, which may vary by vendor. By allowing the readers to respond with their individual characteristics, the client software can be written so as to maintain common core functionality, yet still take advantage of extensions where available.

In addition, LLRP allows basic configuration and operations independent of the air protocol, supporting simple reader configuration without any knowledge of air protocol specifics. In LLRP 1.0.1, EPCglobal has developed a parameter set to control the full functionality of UHF Gen 2 readers. For protocol-specific operation, LLRPís Gen 2 parameter set provides simple access to Gen 2 functionality, such as read, write, lock, and kill, as well as simple methods to select the Gen 2 link parameters. And as the UHF Gen 2 specification evolves, LLRP can be easily extended to provide support for future enhancements.

LLRP improves RFID system performance and efficiency

One key advantage for LLRP is that it does not rely on real-time interaction between the application software and the reader, yet the readers can still be commanded to perform all the Gen 2 time-critical functions. The reader application software can pass operational rules to the reader in non-real time, and then trigger those rules to activate in real time. This declarative method of operation enables the reader to achieve peak performance without any constraints caused by network or host latency.

For applications such as pharmaceutical lines where functions are time-critical, this autonomous procedure facilitates uninterrupted line operation. The reader can operate without a real-time control interface from the host. Alternatively, for applications such as a dock door in an isolated area where accommodating a controlling computer is not feasible, the ability to remotely control the reader operation via common network connections brings about cost savings and security advantages.

Common LLRP interface provides advantages

A common client-reader interface provides many advantages, including:

n   Any tool used to evaluate reader performance is the same for all candidates; with common comparison tools, users benefit from a much more accurate picture of specific reader performance, and thereby make more informed choices.

n   By providing a consistent client-programming model for controlling applications, LLRP enables these applications to expose a richer set of features across unique reader platforms. Rather than making readers a commodity item, LLRP increases reader differentiation because reader performance as seen through the controlling software will be more apparent and easier to compare.

n   LLRP will provide a common knowledge base to leverage during RFID systems deployment. The RFID reader vendor and client communities are already working to create an open source programming toolkit for LLRP (see And like other standard network protocols, network sniffer and protocol analyzers are emerging to provide detailed information about the communications between reader and client.

n   At the back end of a deployment, users installing an RFID system will require that any reader perform certain tasks particular to their usage model. If the network interface is standard, they wonít have to learn multiple systems; they will only need LLRP proficiency.


Sidebar 1: A brief LLRP Overview

LLRP facilitates RFID, enabling applications

It is the responsibility of the application software to determine what to do with information received from the tags. The data might enter a closed system where the tags are used as data storage devices and not subject to as many standards, or the data might enter an open system such as a supply chain where other standards are already in place to facilitate data use. (See In either case, easing RFID reader implementation into a network helps the bottom line.

In the end, RFID is an enabling technology. The capability to tag any item with an inexpensive communications circuit and then read that tag with a sophisticated communications circuit (reader) supports endless applications, ranging from supply-chain management to asset tracking to authenticating frequently counterfeited pharmaceuticals. Applications are limited only by the imagination of the solutions provider.

Just as the fantastic creations now made with Lego blocks likely surpass the original inventorís wildest dreams, there are bound to be RFID applications that no one has ever considered. But when they are, current standard interfaces such as LLRP will free developers to create elegant solutions, rather than bog them down with the mechanics of connecting the various blocks.

Ann De Vries is a senior technical writer at Impinj in Seattle. Before joining Impinj, she held engineering management and design positions at General Instrument and TRW. She received a masterís degree in Electrical Engineering from the University of Southern California (Los Angeles), a bachelorís degree in Physics from the University of California, Riverside, and a certificate in Technical Communication from the University of Washington.