Information technology — Radio frequency identification for item management software system infrastructure — Part 5: Device interface

This document specifies an interface within the software system infrastructure (SSI) that provides radio frequency identification (RFID) system control components with low-level access to RFID interrogators for the purpose of optimizing RFID data access and control operations. This interface is designed to be modular with the ability to support multiple RFID air protocols. However, in this document, the only RFID air protocol supported is ISO/IEC 18000-63:2021.

Technologies de l'information — Identification de radiofréquence (RFID) pour la gestion d'élément — Infrastructure de systèmes logiciels — Partie 5: Interface de dispositif

General Information

Status
Published
Publication Date
15-Oct-2025
Current Stage
6060 - International Standard published
Start Date
16-Oct-2025
Due Date
28-Nov-2026
Completion Date
16-Oct-2025
Ref Project

Relations

Standard
ISO/IEC 24791-5:2025 - Information technology — Radio frequency identification for item management software system infrastructure — Part 5: Device interface Released:10/16/2025
English language
18 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)


International
Standard
ISO/IEC 24791-5
Second edition
Information technology — Radio
2025-10
frequency identification for item
management software system
infrastructure —
Part 5:
Device interface
Technologies de l'information — Identification de radiofréquence
(RFID) pour la gestion d'élément — Infrastructure de systèmes
logiciels —
Partie 5: Interface de dispositif
Reference number
© ISO/IEC 2025
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2025 – All rights reserved
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 Conformance . 2
6 Software system infrastructure architecture overview . 3
7 UML modelling . 3
8 Device interface . 4
8.1 General .4
8.2 Architecture .4
9 LLRP extensions abstract definitions . 4
9.1 General .4
9.2 LLRP data types .5
9.3 ObjectIdentifier field type .6
9.4 ISO15962Read parameter .6
9.4.1 General .6
9.4.2 Conformance requirement .6
9.5 OID parameter .7
9.5.1 General .7
9.5.2 Conformance requirement .7
9.6 ISO15962ReadResult parameter .8
9.6.1 General .8
9.6.2 Conformance requirement .8
9.7 ISO15962OIDReadResult parameter .9
9.7.1 General .9
9.7.2 Conformance requirement .9
9.8 ISO15962RawDataReadResult parameter .10
9.8.1 General .10
9.8.2 Conformance requirement .10
10 LLRP extensions binary encoding .11
10.1 General .11
10.2 ISO15962Read parameter .11
10.3 OID parameter .11
10.4 ISO15962ReadResult parameter . 12
10.5 ISO15962OIDReadResult parameter . 12
10.6 ISO15962RawDataReadResult parameter . 13
Annex A (informative) LLRP open source project references . 14
Annex B (informative) UTF-8 and 8859-1 conversion algorithms .15
Bibliography .18

© ISO/IEC 2025 – All rights reserved
iii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 31, Automatic identification and data capture techniques.
This second edition cancels and replaces the first edition (ISO/IEC 24791-5:2012), which has been technically
revised.
The main change is as follows: references to ISO/IEC 19762 and Type C of ISO/IEC 18000-63:2021 have been
corrected.
A list of all parts in the ISO/IEC 24791 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.

© ISO/IEC 2025 – All rights reserved
iv
Introduction
Radio frequency identification (RFID) air interface technology is based on non-contact electro-magnetic
communication among interrogators and tags. RFID software systems are composed of RFID interrogators,
intermediate software systems, and applications that provide control and coordination of air interface
operation, tag information exchange, and health and performance management of system components.
RFID technology is expected to increase effectiveness in many aspects of business by further advancing the
capabilities of automatic identification and data capture (AIDC). To achieve this goal through the successful
adoption of RFID technology into real business environments, RFID devices, software systems and business
applications must provide secure and interoperable services, interfaces and technologies. This is the goal
of the ISO/IEC 24791 series, which cover RFID software system infrastructure (SSI). The composition and
operations of SSI exist in systems that implement other RFID standards, such as the ISO/IEC 18000 series
which describes air interfaces, and ISO/IEC 15962, the ISO/IEC 15963 series and ISO/IEC 24753 which
describe data and interface functions.
The goal of this document is to define a device interface that provides RFID controlling software with low-
level access to RFID air interface hardware. This low-level access gives programmers a degree of control
over the sequencing of air protocol commands and direct access to air protocol command parameter. Using
this low-level interface, programmers can optimize RFID data access and control operations.
The interface defined by this document supports the following features:
— efficient, binary transfer syntax over transmission control protocol/internet protocol (TCP/IP);
— access to RFID air protocol commands and command parameters;
— support for optimized RFID tag access operations whereby multiple operations can be performed on a
tag with minimal tag state changes;
— direct read or write access to all data on an RFID tag;
— read one or more individual tag data items (encoded as defined by ISO/IEC 15962) as specified by their
'0 object identifier (OID) using uniform resource name (URN) notation;
— [optional] decode data items (encoded as defined by ISO/IEC 15962) into their Unicode representation
(UTF-8 encoded) – encoding data items is not supported;
— support for RFID air protocol type defined by Type C of ISO/IEC 18000-63:2021.
The interface defined in this document provides access to RFID air protocol commands and their respective
command parameters. Therefore, using this interface, tag memory banks can be locked, tags can be killed,
and raw-binary RFID tag data can be accessed directly on a tag for both reading and writing. In addition,
individual data items (encoded as defined by ISO/IEC 15962) can be read by specifying each data item’s OID.
Optionally, the interrogator can decode data items read into their character string representation. If the
interrogator cannot decode a data item, then it will return the entire encoded package within which the data
item resides. In this case, it is the responsibility of higher-level software to further decode the data item.
The interface does not support RFID tag data encoding. It is the responsibility of higher-level software (i.e.
software outside the interface defined by this document) to perform data encoding (e.g. by binary tag data
representation as defined by ISO/IEC 15962) that is stored on RFID tags.
This document is an extension to GS1™ LLRP. As does GS1™ LLRP, this document defines both the abstract
functional capabilities of the interrogator interface and the binary transfer syntax between the interrogator
and a controlling system device. The transfer syntax is defined to be communicated over TCP/IP.

© ISO/IEC 2025 – All rights reserved
v
International Standard ISO/IEC 24791-5:2025(en)
Information technology — Radio frequency identification for
item management software system infrastructure —
Part 5:
Device interface
1 Scope
This document specifies an interface within the software system infrastructure (SSI) that provides radio
frequency identification (RFID) system control components with low-level access to RFID interrogators for
the purpose of optimizing RFID data access and control operations. This interface is designed to be modular
with the ability to support multiple RFID air protocols. However, in this document, the only RFID air protocol
supported is ISO/IEC 18000-63:2021.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 8859-1, Information technology — 8-bit single-byte coded graphic character sets — Part 1: Latin
alphabet No. 1
ISO/IEC 19762, Information technology — Automatic identification and data capture (AIDC) techniques —
Vocabulary
GS1™ LLRP, Low Level Reader Protocol
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 19762 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
endpoint
one of two components that either implements and exposes an interface (3.1) to other components or uses
the interface of another component
3.2
interrogator
component that implements and exposes the interrogator interface (3.1) to other system components
3.3
client endpoint
component that uses the interrogator interface (3.1) to access interrogators

© ISO/IEC 2025 – All rights reserved
3.4
interface
shared boundary between two functional units, defined by various characteristics pertaining to the
functions, physical or software interconnections, signal exchanges, and other characteristics, as appropriate
3.5
interrogator controller
system component, possibly a distinct physical device, which is capable of exercising the data, control and
management of interrogators
3.6
data set
binary representation of a data element’s identifier and its associated data value that is encoded according
to the rules defined by the ISO/IEC 15962 standard access method
3.7
data item
pairing of a data element’s identifier and its associated data value that is encoded according to the rules in
ISO/IEC 15962, regardless of access method
3.8
encoded package
self-describing binary data from an RFID tag memory bank that, when given the memory bank’s data format
storage identifier (DFSID) (which defines the ISO/IEC 15962 access method and data format), decoding
software can fully decode the individual data item(s) (3.7) to extract the encapsulated data
4 Abbreviated terms
For the purposes of this document, the symbols and abbreviated terms given in ISO/IEC 19762 and the
following apply.
AFI Application field identifier
AIDC Automatic identification and data capture
DSFID Data storage format identifier
LLRP Low level reader protocol
RF Radio frequency
SSI Software system infrastructure
UML Unified modelling language
5 Conformance
In order to conform to this document, the requirements of GS1™ LLRP and the requirements of GS1™ LLRP
extensions defined in Clause 9 shall be met. Clause 9 is partitioned into subclauses and each subclause
includes a specific conformance requirement subclause. Therefore, conformance to Clause 9 is defined by
the "shall" statements of the conformance requirement subclauses of Clause 9. GS1™ LLRP also has specific
conformance requirement paragraphs. Conformance to GS1™ LLRP is defined by the "shall" statements of the
conformance requirement paragraphs found in GS1™ LLRP. While adherence to each subclause of Clause 9
is optional, once it has been decided to implement a subclause of Clause 9, the respective conformance
requirements shall be met.
© ISO/IEC 2025 – All rights reserved
6 Software system infrastructure architecture overview
ISO/IEC 24791-1 establishes the architecture for the software system infrastructure. The basic relationship
among the interfaces and implementations of the software system infrastructure is illustrated in Figure 1.
Figure 1 — Architecture overview including relationships to other RFID standards
The data interface, device interface and device management each provide one or more interfaces that allow a
client to communicate with a service-providing implementation, either within the same computing device or
across a network. These client and service implementations are consistently referred to as client endpoints
and services endpoints, respectively, and in general, the client endpoint accesses the capabilities provided by
the services endpoint. The interrogator implementation may have one or more interrogator controller that
implements the service. The specific standard defines the formats, procedures, operations and conformance
requirements of each interface.
7 UML modelling
Although Figure 1 provides a general overview of the relationship between the interfaces and
implementations in the SSI, unified modelling language (UML) is used in the remainder of the document to
graphically represent the organization and operation of the Device Interface and implementations so that a
precise and common understanding of the relationships among the components can be defined.
UML is a very rich language, but for simplicity only the physical diagram subset of the language is used
to represent the architecture of the software system infrastructure. Physical diagrams, comprised of
component diagrams and deployment diagrams, represent the relationships among the functions and the
interfaces provided by the SSI architectural elements as well as how these functions can exist in standards
conforming solutions, respectively. Refer to ISO/IEC 24791-1 for a more complete description how UML is
used in this document.
© ISO/IEC 2025 – All rights reserved
8 Device interface
8.1 General
This clause describes the device interface defined by this document in terms of the overall software system
infrastructure described in ISO/IEC 24791-1. Annex A provides further references to several open sources
projects that offer software libraries and utilities supporting this device interface.
8.2 Architecture
As defined in ISO/IEC 24791-1, the device interface defines data and control operation between the device
interface services endpoint on an RFID interrogator and the client endpoint typically on a different physical
device. A device interface component exposes an interface as represented in Figure 2 whereby a device
interface services endpoint provides services to a device interface client endpoint over an interface binding
as specified in Clause 10. The client and services endpoints may exist in a single device or may be accessed
across a network.
Figure 2 — Device interface representation
The device interface is responsible for supporting and exercising the capabilities provided by the RFID air
protocols to achieve the tag and sensor access goals of an RFID software system. In order to achieve this goal,
the standards provided for the data, control, and management functions at this level in the software system
infrastructure are air-protocol aware and capable of fully exercising specific features of the supported air
protocol standards. Equivalently, it is not a goal to provide a single, abstract interrogator interface that
provides a common interface regardless of the specific air protocol in use. Doing so would reduce the ability
of the software systems to access the specific features provided by existing and future air protocols.
The device interface supports requests for, and communication of, tag information between the services
endpoint on RFID interrogators and the client endpoint on upstream devices. The data functions include
capabilities such as reading, writing, filtering and reporting of tag and sensor data. Synchronous, event-
based and externally triggered operation may be supported for access requests.
The control functions in the architecture provide an interface for the device interface client to exercise
specific control over the access operations on an interrogator. This control is specific to each air protocol
and is intended to provide the necessary capabilities to allow for software system, interrogator and RF
environment optimization. The control function of the device interface also supports the delivery of system,
interrogator, tag and RF environment data from the services endpoint to the client endpoint. This data can
be used by implementations to provide the control required to achieve the desired system goals.
9 LLRP extensions abstract definitions
9.1 General
This document directly references and therefore utilizes the complete structure, definitions, formats and
procedures of the GS1 Low Level Reader Protocol (LLRP) specification with the addition of extensions that
provide support for reading and decoding RFID Type C of ISO/IEC 18000-63:2021 tag data formatted and
operated upon according to ISO/IEC 15962. If an implementation of this document is unable to decode a tag

© ISO/IEC 2025 – All rights reserved
data object, then it shall transfer to the client endpoint the raw, binary contents of the entire data set (i.e. the
data object and its associated header data such as precursor and length fields).
Tag data may be encoded according to ISO/IEC 15962 to represent different character sets (e.g. the default
ISO/IEC 8859-1, UTF-8 or application defined). Tag data encoded as UTF-8 (compaction code 111) is fully
compatible with this document and is transferred “as-is”. It is the responsibility of the client application
to convert this UTF-8 data to other character sets if needed. Tag data found to be encoded as application
defined (compaction code 000) cannot be decoded by an implementation of this document and as such, it
shall be transferred as raw, binary data. Tag data that is encoded with no directory, directory or tag data
profile access methods and with the following compaction codes (001, 010, 011, 100 and 101) when decoded
have the same single byte value on the tag and in UTF-8 format. If the compaction scheme is declared as
octet encoded (compaction code 110) then the encoding on the tag shall need to be converted to UTF-8 if any
byte value is in the range between 80 to FF . An example of the conversion algorithm is given in Annex B.
h h
The remainder of this document defines the ISO/IEC 24791-5 extensions to GS1™ LLRP. This clause provides
an abstract definition of interface parameters used to request and return decoded tag data. Clause 10 defines
the transfer syntax details required to implement these interface parameters.
When referring to GS1™ LLRP, it will be helpful to understand that there are several terms in GS1™ LLRP
that are synonymous with terms in this document, as follows:
— EPC (Electronic Product Code): identifier corresponding to the term "unique item identifier" (UII) as
defined by air protocol interface Type C of ISO/IEC 18000-63:2021 when memory bank 01 bit 17 is zero;
2 h
— EPC Memory Bank: equivalent to the term "UII memory bank" as defined by air protocol interface Type
C of ISO/IEC 18000-63:2021;
— Class 1, Gen 2 (C1G2): standard adopted as ISO/IEC 18000-63:2021;
— Reader: equivalent to an interrogator as defined in ISO/IEC 19762.
The ISO/IEC 15962 RFID tag data encoding rules are defined in terms of data items that represent a pairing
of the data item identifier (OID) and its associated data value. Data items, as defined by the ISO/IEC 15962
rules, include data encoded as either packed objects or concatenated data sets (i.e. two different access
methods defined by ISO/IEC 15962).
This document extends LLRP for the purpose of providing a client endpoint with the following specific
capabilities:
a) to request an interrogator to search a tag for one or more specific OIDs and to report back to the client
the occurrences of each OID as it is found on the tag;
b) to request an interrogator to report all OIDs found on a tag;
c) to request an interrogator to check for duplicate occurrences of one or more OIDs on a tag and return
the number of instances found;
d) to request for either raw or decoded data to be returned for each OID returned in the response to a
particular request.
Subclauses 9.2 to 9.8 provide abstract definitions of LLRP extensions designed to satisfy these capabilities.
Clause 10 provides the binary transfer syntax definition for these extensions.
The LLRP extensions defined in this document correspond to the section titled "Access Operation" of GS1™
LLR
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...