LLRP (Low Level Reader Protocol)

What is LLRP?

Low Level Reader Protocol (LLRP) is a standardised binary protocol for controlling UHF RFID readers. Originally ratified by EPCglobal in 2007 and now maintained by GS1 as ISO/IEC 24791-2, LLRP defines how a host application communicates with a reader to configure inventory operations, access tag memory, and receive tag reports.

Before LLRP, every UHF reader manufacturer had its own proprietary control API. A deployment using Impinj readers could not be switched to Zebra hardware without rewriting the host software. LLRP solved this by providing a single, vendor-neutral protocol that all major reader manufacturers implement, making it possible to write reader-agnostic RFID middleware and applications.

How it works

LLRP uses a TCP client-server model. The reader acts as the server, listening on TCP port 5084 by default. The host application is the client - it connects to the reader, sends configuration and control messages, and receives tag report data in response.

• Binary message framing: LLRP messages are binary-encoded with a fixed header containing a message type, length, and message ID. The structure is defined in an XML schema (LLRP.org schema), but the wire format is compact binary - not XML text. This makes LLRP efficient on the wire while keeping message definitions human-readable.
• Reader as server: The reader opens the TCP socket and waits for connections. The host application initiates the connection. This means the application must know the reader's IP address, but the reader does not need to know anything about the application in advance.
• Request-response and asynchronous reports: Most LLRP messages follow a request-response pattern (the application sends a command; the reader sends an acknowledgement). Tag reports, however, are asynchronous - the reader sends RO_ACCESS_REPORT messages as tags are read, without waiting for a request.
• ROSpec and AccessSpec configuration: All reader behaviour is controlled through Reader Operation Specifications (ROSpecs) and Access Specifications (AccessSpecs), which are uploaded to the reader before inventory begins. These define which antennas to use, how long to inventory, what to do when a tag is seen, and what tag data to report.

Key message types

ROSpec and AccessSpec

The two core configuration objects in LLRP are ROSpec and AccessSpec. Together they define everything the reader does during an inventory session.

• ROSpec (Reader Operation Specification): Defines when and how the reader inventories. An ROSpec contains one or more AI Specs (Antenna Inventory Specs) that specify which antennas to use and how to cycle through them, plus Report Specs that define what data to include in each tag report (EPC, TID, user memory, RSSI, phase, Doppler, timestamp). ROSpecs can be triggered immediately, on a schedule, or by an external GPIO event.
• AccessSpec: Defines tag-level operations to perform when a specific tag is seen. AccessSpecs support read (retrieve memory bank contents), write (program EPC or user memory), lock (protect memory banks or kill password), and kill (permanently disable a tag). An AccessSpec can target any matching tag or be triggered only for tags with a specific EPC.
• Lifecycle: Both object types follow the same lifecycle - add, enable, start, stop, disable, delete. This gives the host application fine-grained control over reader behaviour without needing to disconnect and reconnect.

LLRP in practice

LLRP is supported by all major UHF reader manufacturers as their standard control interface:

• Impinj Speedway (R420, R120, xPortal): Impinj readers implement LLRP as the primary protocol. Impinj also publishes the Octane SDK, which wraps LLRP in a higher-level C# and Java API, and ItemSense / Impinj IoT Device Interface for cloud-connected deployments.
• Zebra FX series (FX7500, FX9600): Zebra fixed readers support LLRP alongside Zebra's own RFID3 API. LLRP is the recommended protocol for multi-vendor or middleware deployments.
• ThingMagic (Mercury series): ThingMagic readers support LLRP and also expose a proprietary TMR (ThingMagic Reader) API for advanced features not covered by LLRP.
• Other vendors: Jadak, Feig, Indy/Samtec, and most other UHF fixed reader vendors implement LLRP. Handheld readers vary - some support LLRP over Wi-Fi when docked, but not all mobile readers expose LLRP.

In practice, most deployments use LLRP for initial connection, ROSpec configuration, and tag reporting, then switch to vendor-specific extensions for features like GPIO control, antenna multiplexer management, or firmware updates.

Advantages

• Vendor-neutral reader control: Write middleware once and deploy against readers from any manufacturer. Swapping reader hardware requires only a connection string change, not application rewrites.
• Standardised tag reporting: Tag data - EPC, TID, RSSI, antenna port, timestamp - is reported in a consistent format regardless of reader brand.
• All major manufacturers support it: Impinj, Zebra, ThingMagic, Feig, Jadak, and others all implement LLRP, making it the lingua franca of UHF reader control.
• Flexible inventory configuration: ROSpecs allow fine-grained control over antenna cycling, RF power per antenna, singulation algorithm, session flags, and report triggers.
• Tag memory operations: AccessSpecs provide a standard way to read, write, lock, and kill tags - covering the full EPC Gen 2 tag command set.
• Open standard: The LLRP specification is freely available from GS1. No licensing fees or proprietary SDKs required to implement a basic LLRP client.

Limitations

• Complex message structure: LLRP messages are verbose and deeply nested. Even a simple inventory ROSpec requires constructing a multi-level binary structure. Most teams use an existing LLRP library rather than implementing the protocol from scratch.
• TCP only: LLRP is designed for TCP/IP networks. It is not suitable for serial connections or resource-constrained embedded systems that cannot run a TCP stack.
• UHF readers only: LLRP is an EPC Gen 2 / UHF protocol. It does not apply to HF, LF, or NFC readers, which have their own separate standards and APIs.
• Steep learning curve: The specification runs to hundreds of pages. Understanding ROSpec lifecycle, trigger types, and AccessSpec interaction requires significant investment before a working implementation is running.
• Vendor extensions are common: The base LLRP standard does not cover all reader capabilities. Vendors add proprietary custom extensions for GPIO, antenna multiplexers, Impinj-specific features like low duty cycle mode, and direction-finding. Using these extensions ties you back to a specific vendor.
• No built-in security: Base LLRP runs over plain TCP with no authentication or encryption. TLS wrapping is possible but not part of the standard; most deployments rely on network-level security instead.

Common applications

• Multi-vendor reader deployments: Warehouses, distribution centres, and retail environments that deploy readers from multiple manufacturers use LLRP to present a uniform interface to their middleware layer.
• RFID middleware platforms: Platforms such as EPCIS event generators, MQTT bridges, and filtering/collection servers connect to readers via LLRP and translate raw tag reads into business events.
• Warehouse and DC reader management: Fixed readers at dock doors, conveyor belts, and portal frames are configured and monitored centrally via LLRP. A single management application can reconfigure antenna power, poll reader health, and start/stop inventory across a fleet.
• Retail inventory systems: Store-level inventory counting and replenishment systems use LLRP to collect reads from fixed readers at shelf edges or store portals and feed them into inventory platforms.
• Reader-agnostic software products: ISVs building RFID software for resale implement LLRP so their product works with the widest range of customer-supplied reader hardware.

LLRP vs proprietary reader APIs

Related