EPCglobal's low-level reader protocol is enabling technology innovation and differentiation in the RFID industry.
In April of this year, EPCglobal announced that it had ratified the low-level reader protocol (LLRP) standard, a specification for the network interface between the RFID reader and its controller. Having already standardized the tag and reader radio-frequency (RF) air-interface protocol with UHF Gen 2, this specification is the practical, logical next step in facilitating the adoption of RFID. What exactly is LLRP and why is it important? Let's take a closer look.
Standardized client-to-reader interface
The device operating an RFID reader can vary from a software application to middleware running on server hardware to programmable logic controllers (Figure 1). While the ultimate end business application these clients support may differ, the primary function of the interface between control device and reader remains the same. It commands the reader to inventory tags and otherwise access them. There are, of course, secondary support functions such as controlling the RF link to obtain optimal performance, determining RFID device capabilities, and handling errors or status.
Readers that pass EPCglobal's Gen 2 conformance and interoperability tests should work seamlessly at the tag and reader interface. However, the interface at the network or controlling side could be radically different. Consequently, committing to a particular system may end up being more of a marriage to proprietary technology than originally intended. With proprietary control software in place, the cost and time associated with changing to alternative readers or controlling software could be prohibitive, to say nothing of defeating the plug and play strategy critical to technology innovation and widespread technology adoption.
A standard network interface yields more than one advantage. At the front of a system deployment, it enables a standard test application to be used when comparing readers. A standard interface means the tools used to evaluate reader performance are the same for all candidates — an apples-to-apples comparison rather then the mix and match model available today. Using a common interface, users benefit from a much more accurate picture of specific reader performance, and thereby make better buying decisions.
EPCglobal is expected to have LLRP conformance certification procedures in place for readers by the fourth quarter. Similar to the testing being conducted today for the tag and reader air interface, readers that pass LLRP interface testing will connect seamlessly at the network level. For system architects, LLRP certification means complete confidence that those readers will work together with other system components.
LLRP will provide a common knowledge base to leverage during deployment of RFID systems. Like other standard network protocols, network sniffers and protocol analyzers are emerging to provide detailed information about the communications between reader and client.
Finally, at the back end of a deployment, people installing an RFID system will require the reader — any reader — to 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.
The right standard, right now
Other standards have been proposed for the controller-to-reader network interface, so why has LLRP won out? In part, it's because previous approaches did not go quite far enough to accommodate the needs of both reader and application software providers — needs that included the ability to better leverage the competitive advantages of their respective products. In creating this new standard, the EPCglobal working group — a consortium of reader and application software vendors — included in LLRP 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. These innovations will drive future developments of the standard.
LLRP's ability to poll the readers on the network for their particular capabilities (which may vary by vendor) is yet another reason for acceptance. 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.
LLRP is also modular with respect to air protocol. It allows basic configuration and operations independent of air protocol, supporting a simple configuration of readers without any knowledge of air protocol specifics. In LLRP 1.0, EPCglobal has developed a parameter set to control the full functionality of 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.
Improving RFID system performance and efficiency
LLRP specifies a binary protocol over TCP/IP. It is an asymmetric protocol where a client implementation of LLRP (application of software) speaks to a reader implementation of LLRP, with reader- or client-initiated connections. Through this connection, LLRP provides a rich set of control possibilities.
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 of 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 allows the reader to achieve peak performance without any constraints caused by the network or host latency.
For applications such as pharmaceutical lines where functions are time critical, this more autonomous procedure facilitates uninterrupted line operation (Figure 2). 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.
A closer look at LLRP
The LLRP protocol was designed to provide maximum performance flexibility. A typical LLRP sequence between an application software client and a reader involves the following processes:
Client polling the reader for its capabilities.
Setting the reader configuration.
Sending reader operation commands. These commands are called reader operation specifications (ROSpecs) and contain a list of sequential inventory operation commands called antenna inventory specifications (AISpec).
Sending the reader access specifications (AccessSpec) or commands that tell the reader which data access operations (both read and write) to perform on tags.
Obtaining reports back from the reader.
Reader operation specifications can be thought of as a collection of inventory settings and commands that the client software provides to the reader, along with instructions on when to start and stop those operations. Start operations may be triggered immediately, by setting a periodic timer, by sending an absolute start time, by direct instruction from the client software, or by a general-purpose input designated for that function. Operation commands sent to a reader may have durations bounded by stop triggers that can be tag-based (n tag observations), reader-based (n attempts to singulate a tag), time-based, host command-based, or general-purpose input control-based. A reader operation specification is independent of air protocol.
Each reader operation specification contains a number of antenna inventory specifications (AISpec) to instruct the reader on antenna settings and particulars about inventory operation, such as when to stop the inventory, or which antennas to use. The reader executes the AISpecs in order. Within the AISpec are inventory parameter specifications, which can be used to describe detailed RF and air-protocol specific configurations.
Gen 2 and other air protocols allow the reader to perform operations as tags are inventoried. In LLRP, the reader accesses individual tags via access specifications — commands instructing the reader to access a particular tag based on tag selection criteria (e.g., filter the tag). LLRP allows the tag selection criteria to be configurable by tag data pattern, antenna, or a specified reader operation specification, which, for example, could trigger based on a particular time (Figure 3).
An open source LLRP toolkit
While a standard network interface is an important development, not everyone wants to learn a binary protocol. Therefore, an effort is under way, led by Impinj, to create an open source programming toolkit for LLRP. Information about the toolkit can be found at http://sourceforge.net/projects/llrp-toolkit/.
Goals of the project are to:
Provide a toolkit for the development of LLRP-based applications and smart readers.
Accelerate integration of LLRP into open RFID frameworks.
Facilitate development of LLRP-based test tools.
Provide a human-readable form for LLRP messages to facilitate an LLRP community.
Simplify basic LLRP message transactions.
Enable a common framework for LLRP vendor extensions.
The toolkit will provide the following components:
Documentation on the toolkit architecture and usage model.
A human- and machine-readable description of the LLRP abstract protocol.
A human- and machine-readable description of the LLRP binary protocol binding.
Source code and libraries for creating LLRP frames from a TCP/IP socket interface.
Source code and libraries for marshalling LLRP binary frames to and from native language object.
Source code and libraries for marshalling LLRP native language objects into the human-readable description of the abstract protocol.
Reference code and libraries for performing LLRP message transactions.
In progress are C, C++, Perl and Java, with more libraries to come, such as possibly .NET.
LLRP, with its ability to enable technology innovation and differentiation via extensions, is now helping to move RFID toward widespread adoption. Realizing that goal will require the development of and support for an open-source programming toolkit for LLRP like the one being driven by Impinj, as well as introduction of LLRP-based readers.
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 has a master's degree in electrical engineering from the University of Southern California and a bachelor's degree in physics from the University of California at Riverside.
Paul Dietrich is Impinj's principal RFID reader software architect. His 15 years of experience in the networking and wireless industry covers digital communications, embedded software design and development, and systems architecture. With support from Impinj, Dietrich was instrumental in defining the EPCglobal low-level reader protocol standard. He holds a position on the EPCglobal Architecture review committee, where he develops, reviews and stewards the EPCglobal architecture. Dietrich has a Ph.D. in electrical and computer engineering from the University of California at San Diego, and was a post-doctoral researcher at the UCSD Center for Wireless Communications.
|General Device Capabilities||LLRP Capabilities||Regulatory Capabilities (Examples)|
|• Number of antennas |
• Number of general-purpose input ports
• Number of general-purpose output ports
• Device manufacturer
• Model number
• Firmware version
• Supported air protocols
• Receive sensitivity table
|• RF survey supported |
• Number of reader operation specifications supported
• Number of access specifications supported
|• Regulatory region supported |
• Transmit power table
• Transmit frequency table
• RF mode table