LLRP Reader

From RifidiWiki

Jump to: navigation, search


Introduction

There has been a lot of buzz in the RFID world as of late around LLRP (Low Level Reader Protocol). It is an EPC Ratified Standard that describes a protocol for client to reader communication. It is called "Low Level" because it allows control of Air Protocol (such as class 1 gen 2) parameters as well as control of other hardware aspects of the reader. LLRP communicates via Messages -- the basic data unit -- that are encoded in a binary format and are sent over TCP. Using these messages, the client can control the various dynamic data structures (ROSpecs, AccessSpecs, etc.) and configure the reader.

Network Protocol
TCP/IP
Communication
Bit encoded messages over TCP

Basis of Virtual Reader

The LLRP virtual reader is based on the EPCGlobal spec found at EPCGlobal's website. Currently there are no hardware readers available.

Documentation

Client Tools

There are very few client tools available at the moment, as there are no hardware readers available. Because all LLRP commands are bit-encoded, communication with an LLRP reader is not trivial and it is not possible to simply telnet into the reader and issue commands.

LLRPHelloWorld
A simple client developed for testing Rifid's LLRP reader that uses a java client library.
XML Messages
A collection of LLRP XML Messages that can be used to get started with LLRP

Reader Design

This section will give a brief overview of how the hardware reader operates for the purposes of emulation. It is the output of Stage 1 in the Stages of Building a Reader.

Communication

The LLRP Spec requires that LLRP Readers use bit encoded messages over a TCP connection. It explains how to build the messages by specifying in which order bits should be placed. To assist with the binary encoding/decoding of all the LLRP messages and parameters, see the LLRP-TK Sourceforge page.

LLRP readers use a TCP connection to communicate with the client. Additionally, readers may implement a secure connection using TLS.

LLRP Communication Layer

The LLRP specification requires that readers implement an "LLRP Layer" above the TCP stack. This means that LLRP Messages, (i.e. ADD_ROSPEC, GET_READER_CONFIG) may not be sent until an LLRP connection has been established. To establish this connection, a reader must either be commanded to accept incoming connections on a given port, or to connect to a client at a given IP and port. The method for specifying this connection information is left up to the vendor (LLRP Specification, 18.1).

Rifidi Admin Console

To command the rifidi reader to either accept connections or make connections, a basic admin console has been provided. To use it, start the rifidi reader, and telnet into the reader. Then issue one of two commands:

For the (normal) ServerMode
In this mode the Reader works as a Server, listening for incoming connections on the given Port

  • mode server [PORT]
For the ClientMode
In this mode the Reader works as a Client and tries to establish a connection to the ClientApplication which is running on the given IP and Port
  • mode client [IP] [PORT]

Memory Model

The memory model of LLRP Readers is complex and different from other readers. There are two main data structures defined in the LLRP spec. The first is the ROSpec (Reader Operations Specification). The most important aspect of the ROSpec is that it contains contains a list of one or more of AISpecs (which define how to read EPC tags from the antennas) and RFSurveySpec (which define how to get operation information about the antennas such as power levels). In addition it contains a ReportSpec that has the parameters describing what information a report will contain. The other main data structure is the AccessSpec which defines how to read non-EPC information on a tag (such as user defined data) as well as how to perform other operations on a tag, such as writing and killing. Currently the Rifidi virtual LLRP reader only supports ROSpecs with AISpecs (that is it supports getting epc numbers from tags).

It may help to imagine ROSpecs as processes inside an operating system. A ROSpec is like a single process, and it moves between three states -- disabled, inactive, and active. When the ROSpec is added to the reader, it is added in the disabled state. Then, a message from the client --the ENABLE_ROSPEC message -- moves the ROSpec to the inactive state. After that, a trigger event (time based, message based, etc) moves the ROSpec into the active state, where it begins executing. When the ROSpec is executing, it goes through its list of specs to executes (AI and/or RFSurvey) and executes each one sequentially. It keeps repeating this cycle until its ROSpec stop trigger fires, at which time it moves back to the inactive state.

Tags are sent back as part of a Report Message. It is possible to specify what information reports contain through the RoReportSpec parameter in the ROSpec parameter. For example, reports can contain information about the tags besides the EPC number, such as "time last seen" and "number of times the tag was read". Reports are sent back either at the completion of an AISpec, the completion of a ROSpec, or after N tags are read; however a reader may accumulate tag reports for efficiency purposes. Once a tag is sent in a report, it is "deleted" from tag memory. This prevents the results of a single tag read from being a part of two reports. However if the same tag is read again after a tag read, it will appear in the next report.

Getting Tags

To get tags from a LLRP reader, a client must setup and send a ROSpec (which includes an AISpec) and begin the execution of it.

  1. Client Connects - In this stage, the client connects to the reader at the specified IP and port. Messages may now be sent between the client and the reader.
  2. Create ROSpec - In this stage, the client constructs the ROSpec object, which consists of numerous parameters specifying how the reader should read tags and send back results to the client. It is only through a ROSpec that a client can set up a reader. There is no concept of "telnetting" to the reader and using a command line in LLRP.
  3. Add ROSpec - In this stage, an ADD_ROSPEC message, which contains the newly created ROSpec, is sent to the reader to add it to its list of "ROSpecs to be processed." When a ROSpec is added, it is added to the reader's "disabled" queue.
  4. Enable ROSpec - A ROSpec must be enabled before it can be executed. The ENABLE_ROSPEC is a message sent from the client to the reader that moves the ROSpec from the "disabled" queue to the reader's "enabled" queue
  5. Start ROSpec - Once a ROSpec is enabled, it is listening for a start trigger. The simplest way to issue a start trigger is to send the START_ROSPEC message which will cause a reader to begin execution.
  6. Receive Reports from reader - When a ROSPec is in the execution phase, it can begin to send reports back to the client. Reports contain the information about the tags that the reader has seen, such as the EPC number, the first and last seen time, and the number of times the tag has been seen.

Autonomous Mode

The LLRP reader can be put in autonomous mode by specifying the stop trigger for an AISpec, the most straight-forward of which is the Time based trigger. For example, the the time based trigger is used, an AISpec will stop executing after N seconds. If the ROReport is configured to be sent after the AISpec stops execution, it will be sent then. After the execution of all the AISpecs, a ROSpec will stop. If there are no other ROSpecs waiting, it will begin to execute again. Thus if the Reader has only one ROSpec that has one AISpec, reports will be sent every N seconds.

On-Demand Mode

There is also a concept of an on-demand mode for getting tags, using the GET_REPORT message. If the reader is set to not send back reports at the end of a ROSpec or and AISpec (i.e. reporttrigger is null), then the reader is in an on-demand, or polling mode. Reports can only be obtained through the use of the GET_REPORT command.

Login

There is no concept of a "login" in the LLRP specification, as there is in some other readers such as the Alien or the Symbol. However, it would be possible to implement one through the use of custom messages.

Supported Features

The following is a list of important features of the LLRP reader that are properly emulated by Rifidi

Messages Supported

All LLRP Messages are supported, however some of the parameters inside the messages may not affect the reader. For example, the reader will not processes RFSurvesSpec parameters because the Rifidi Emulator does not emulate RF Functionality.

Features Supported

  • Autonomous Mode & On-demand Mode as described in the Memory Model section above is supported.
  • It is possible to read from more than on antenna and to specify which antennas to read from in the AISpec.
  • Getting and Setting of Configuration Variables
  • Getting of Capabilities
  • Event Notifications
  • LLRP Connection Layer
  • Start and Stop Triggers for ROSpecs and AISpecs
  • GPIO
    • Enabling GPI Ports (using SET_READER_CONFIG)
    • Writing to GPO Ports (using SET_READER_CONFIG)
    • ROSpec start and stop trigger and AISPec stop trigger on GPI event
  • Access specs
    • Read non-epc memory
    • Write memory
    • Lock tag
    • Kill tag

Bugs and Unsupported Features

LLRP Toolkit

Rifidi currently uses the toolkit developed at the University of Arkansas. However, there are a few limitations with this library that is being addressed by AutoID at MIT.

  • Unsigned data types are not supported because java does not support them

Other Unsupported Features

  • RFSurvey Specs

Other Resources

Retrieved from "http://wiki.rifidi.net/index.php?title=LLRP_Reader&oldid=19893"
Personal tools