ISO/IEC 15961:2004

Information technology - Radio frequency identification (RFID) for item management - Data protocol: application interface

The data protocol used to exchange information in a radio-frequency identification (RFID) system for item management is specified in ISO/IEC 15961:2004 and in ISO/IEC 15962:2004. Both are required for a complete understanding of the data protocol in its entirety; but each focuses on one particular interface: ISO/IEC 15961:2004 addresses the information interface with the application system. ISO/IEC 15962:2004 deals with the processing of data and its presentation to the RF tag, and the initial processing of data captured from the RF tag. ISO/IEC 15961:2004 focuses on the interface between the application and the data protocol processor, and includes the specification of the transfer syntax and definition of application commands and responses. It allows data and commands to be specified in a standardized way, independent of the particular air interface of ISO/IEC 18000. ISO/IEC 15961:2004 provides guidelines on how data shall be presented as objects; defines the structure of object identifiers, based on ISO/IEC 9834-1; specifies the commands that are supported for transferring data between the application and the RF tag; specifies the responses that are supported for transferring data between the RF tag and the application; provides a formal description of all the processes using ASN.1, as specified in ISO/IEC 8824-1; specifies the transfer syntax, based on the Basic Encoding Rules of ISO/IEC 8825-1, for data to be transferred from and to the application. It is expected that ISO/IEC 15961:2004 will be used as a reference to develop software appropriate for particular applications, or for particular RF equipment.

Technologies de l'information — Identification par radiofréquence (RFID) pour la gestion d'objets — Protocole de données: interface d'application

General Information

• Status: Withdrawn
• Publication Date: 17-Oct-2004
• Withdrawal Date: 17-Oct-2004
• ICS: 35.040 - Information coding
• ICS: 35.040.50 - Automatic identification and data capture techniques
• Technical Committee: ISO/IEC JTC 1/SC 31 - Automatic identification and data capture techniques
• Drafting Committee: ISO/IEC JTC 1/SC 31/WG 4 - Radio communications
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 08-Aug-2019
• Completion Date: 30-Oct-2025

Relations

• Revised: ISO/IEC 15961-2:2019 - Information technology - Data protocol for radio frequency identification (RFID) for item management - Part 2: Registration of RFID data constructs
• Effective Date: 15-Apr-2008
• Revised: ISO/IEC 15961-4:2016 - Information technology - Radio frequency identification (RFID) for item management: Data protocol - Part 4: Application interface commands for battery assist and sensor functionality
• Effective Date: 15-Apr-2008
• Revised: ISO/IEC 15961-3:2019 - Information technology - Data protocol for radio frequency identification (RFID) for item management - Part 3: RFID data constructs
• Effective Date: 15-Apr-2008
• Revised: ISO/IEC 15961-1:2013 - Information technology - Radio frequency identification (RFID) for item management: Data protocol - Part 1: Application interface
• Effective Date: 15-Apr-2008

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 15961
First edition
2004-10-15
Information technology — Radio
frequency identification (RFID) for item
management — Data protocol:
application interface
Technologies de l'information — Identification par radiofréquence
(RFID) pour la gestion d'objets — Protocole de données: interface
d'application
Reference number
©
ISO/IEC 2004
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO/IEC 2004
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2004 – All rights reserved

Contents Page
Foreword. v
Introduction . vi
1 Scope. 1
2 Normative references . 2
3 Terms, definitions and abbreviated terms. 2
3.1 Terms and definitions. 2
3.2 Abbreviated terms. 4
4 Protocol model . 4
4.1 Overview . 4
4.2 Layered protocol . 5
4.3 Functional processes . 6
5 Data structure. 9
5.1 Notation. 9
5.2 Structure of the transfer between ISO/IEC 15961 and ISO/IEC 15962 . 9
6 Abstract and transfer syntax . 9
6.1 Abstract syntax . 9
6.2 Transfer syntax . 14
7 Data flows and processes. 19
7.1 Establishing communications between the application and the RF tag. 19
7.2 Preparing the basic objects . 24
7.3 Application system services. 27
7.4 Data security. 29
8 Application commands and responses. 30
8.1 Final arc values of the command and response modules. 30
8.2 completionCode (elementName) . 31
8.3 executionCode (elementName) . 32
8.4 Command-related elementNames . 33
8.5 ConfigureAfiModules. 35
8.6 ConfigureStorageFormatModules. 37
8.7 InventoryTagsModules. 39
8.8 AddSingleObjectModules. 41
8.9 DeleteObjectModules. 43
8.10 ModifyObjectModules. 44
8.11 ReadSingleObjectModules. 46
8.12 ReadObjectIdsModules . 48
8.13 ReadAllObjectsModules. 49
8.14 ReadLogicalMemoryMapModules.51
8.15 InventoryAndReadObjectsModules .52
8.16 EraseMemoryModules. 55
8.17 GetApplication-basedSystemInformationModules . 56
8.18 AddMultipleObjectsModules. 57
8.19 ReadMultipleObjectsModules. 59
8.20 ReadFirstObjectModules. 61
8.21 Development commands. 63
© ISO/IEC 2004 – All rights reserved iii

9 Compliance, or classes of compliance, to this standard.63
9.1 Application compliance .63
9.2 Compliance of the Data Protocol Processor .63
9.3 Compliance of the RF tag and RF interrogator .63
Annex A (normative) First, Second and Third Arcs of Object Identifier Tree.65
Annex B (normative) Code Assignments for ApplicationFamilyId.67
Annex C (informative) Accommodating established data formats.69
Annex D (informative) Contact Addresses for Managers of Main Application Data Dictionaries .71
D.1 EAN.UCC System .71
D.2 Data Identifiers.71
D.3 IATA data elements .71
D.4 UPU data elements.71
Annex E (normative) Converting alphanumeric Data Identifiers to the final arc of the Object
Identifier .72
Annex F (informative) Relating data objects.73
F.1 Concatenation technique .73
F.2 Object identifier extension technique .73
Annex G (informative) Data security issues.75
G.1 Object identifier issues.75
G.2 The data object .75
G.3 Using the TagId.75
G.4 Advice on public key methods of encryption.76
Annex H (informative) Example of a transfer encoding.77
H.1 Functional description of the command.77
H.2 The abstract syntax for the AddMultipleObjects command .77
H.3 The AddMultipleObjects command with the data values.78
H.4 The transfer encoding for the example command.78
H.5 Functional description of the response.79
H.6 The abstract syntax for the AddMultipleObjects response .79
H.7 The AddMultipleObjects response with the data values.80
H.8 The transfer encoding for the example response.80
Annex I (informative) Guidance to implementers of development commands .81

iv © ISO/IEC 2004 – All rights reserved

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. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC 15961 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 31, Automatic identification and data capture techniques.
© ISO/IEC 2004 – All rights reserved v

Introduction
The technology of Radio Frequency Identification (RFID) is based on non-contact electronic communication
across an air interface. The structure of the bits stored on the memory of the RF tag is invisible and
accessible between the RF tag and the interrogator only by the use of the appropriate air interface protocol, as
specified in the appropriate part of ISO/IEC 18000. The transfer of data between the application and the
interrogator in open systems requires data to be presented in a consistent manner on any RF tag that is part
of that open system. Application commands from the application and responses from the interrogator also
require being processed in a standard way. This is not only to allow equipment to be interoperable, but in the
special case of data carrier, for the data to be encoded on the RF tag in one systems implementation for it to
be read at a later time in a completely different and unknown systems implementation. The data bits stored
on each RF tag must be formatted in such a way as to be reliably read at the point of use if the RF tag is to
fulfil its basic objective. The integrity of this is achieved through the use of a data protocol as specified in this
International Standard and ISO/IEC 15962.
Manufacturers of radio frequency identification equipment (interrogators, RF tags, etc) and the users of RFID
technology require a publicly available data protocol for RFID for item management. This International
Standard and ISO/IEC 15962 specify this data protocol, which is independent of any of the air interface
standards defined in ISO/IEC 18000. As such, the data protocol is a consistent component in the RFID
system that may independently evolve to include additional air interface protocols.
The transfer of data to and from the application, supported by appropriate application commands is the
subject of this International Standard. The companion International Standard, ISO/IEC 15962, specifies the
overall process and the methodologies developed to format the application data into a structure to store on the
RF tag.
vi © ISO/IEC 2004 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 15961:2004(E)

Information technology — Radio frequency identification (RFID) for
item management — Data protocol: application interface
1 Scope
The data protocol used to exchange information in an RFID system for item management is specified in this
International Standard and in ISO/IEC 15962. Both International Standards are required for a complete
understanding of the data protocol in its entirety; but each focuses on one particular interface:
• This International Standard addresses the information interface with the application system.
• ISO/IEC 15962 deals with the processing of data and its presentation to the RF tag, and the initial
processing of data captured from the RF tag.
This International Standard focuses on the interface between the application and the data protocol processor, and
includes the specification of the transfer syntax and definition of application commands and responses. It allows
data and commands to be specified in a standardised way, independent of the particular air interface of ISO/IEC
18000.
This International Standard
• provides guidelines on how data shall be presented as objects;
• defines the structure of object identifiers, based on ISO/IEC 9834-1;
• specifies the commands that are supported for transferring data between the application and the RF tag;
• specifies the responses that are supported for transferring data between the RF tag and the application;
• provides a formal description of all the processes using ASN.1, as specified in ISO/IEC 8824-1;
• specifies the transfer syntax, based on the Basic Encoding Rules of ISO/IEC 8825-1, for data to be
transferred from and to the application.
It is expected that this International Standard will be used as a reference to develop software appropriate for
particular applications, or for particular RF equipment.
NOTE Conventionally in International Standards, long numbers are separated by a space character as a "thousands
separator". This convention has not been followed in this International Standard, because the arcs of an object identifier are
defined by a space separator (according to ISO/IEC 8824 and ISO/IEC 8825). As the correct representation of these arcs is
vital to this International Standard, all numeric values have no space separators except to denote a node between two arcs of
an object identifier.
© ISO/IEC 2004 – All rights reserved 1

2 Normative references
The following referenced documents are indispensable for the application 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 8824-1, Information technology — Abstract Syntax Notation One (ASN.1) — Specification of basic
notation (equivalent to ITU-T Recommendation X.680)
ISO/IEC 8825-1, Information technology — ASN.1 encoding rules — Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) (equivalent to ITU-T Recommendation
X.690)
ISO/IEC 9834-1, Information technology — Open Systems Interconnection — Procedures for the operation of OSI
Registration Authorities: General procedures (equivalent to ITU-T Recommendation X.660)
ISO/IEC 15962:2004, Information technology — Radio frequency identification (RFID) for item management —
Data protocol: data encoding rules and logical memory functions
ISO/IEC 18000 (all parts), Information technology — Radio frequency identification for item management
ISO/IEC 19762-1, Information technology — Automatic identification and data capture (AIDC) techniques —
1)
Harmonized vocabulary — Part 1: General terms relating to AIDC
ISO/IEC 19762-3, Information technology — Automatic identification and data capture (AIDC) techniques —
1)
Harmonized vocabulary — Part 3: Radio frequency identification (RFID)
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 19762-1, 19762-3 and the following
apply.
NOTE: For terms defined below and in ISO/IEC 19762-1 or ISO/IEC 19762-3, the definitions given below apply.
3.1.1 Application command
The instruction issued from the application to the Data Protocol Processor in order to initiate an action or operation
with the RF tag(s) via the interrogator.

3.1.2 Application memory
The area on the RF tag available for storing data written to it. Sometimes known as user memory.

3.1.3 Arc
A specific branch of an object identifier tree, with new arcs added as required to define a particular object. The top
three arcs of all object identifiers compliant with ISO/IEC 9834-1 are defined in Annex A.
3.1.4 BER = Basic Encoding Rules
An ASN.1 encoding method.
3.1.5 Block
The minimum number of bytes on an RF tag that can be in a write transaction, or read transaction, across the air
interface.
1) To be published.
2 © ISO/IEC 2004 – All rights reserved

3.1.6 Command / Response Unit
That part of the Data Protocol Processor that processes application commands and sends responses to control
encoding, decoding, structuring of the Logical Memory and transfer to the Tag Driver.

3.1.7 Data carrier
A device or medium used to store data as a relay mechanism in an AIDC system, e.g. bar code, OCR character
string, RF tag.
3.1.8 Data compaction
A mechanism, or algorithm, to process the original data so that it is represented efficiently in fewer octets in a data
carrier than in the original presentation.

3.1.9 Data Compactor
The implementation of the data compaction process defined in ISO/IEC 15962.

3.1.10 Data Protocol Processor
The implementation of the processes defined in ISO/IEC 15962, including the Data Compactor, Formatter, Logical
Memory, and Command / Response Unit.

3.1.11 Element name
A component of a Reference Type or enumerated list in ASN.1 syntax.
3.1.12 Formatter
The implementation of the data formatting process defined in ISO/IEC 15962.
3.1.13 Logical Memory
A software analogue on the Data Protocol Processor of the Logical Memory Map.
3.1.14 Logical Memory Map
An array of contiguous octets of memory on the RF tag, representing the application (or user) memory to be used
exclusively for the encoding of objects, objectIds and their associated Precursor on the RF tag. The system
information (see 7.1.2) shall be defined by different means, or stored in a separate area on the RF tag. This can
be achieved by partitioning memory, partly for system information and mainly for the Logical Memory Map purpose.
3.1.15 Object
A well-defined piece of information, definition, or specification which requires a name in order to identify its use in
an instance of communication.
3.1.16 Object identifier
A value (distinguishable from all other such values) which is associated with an object.

3.1.17 OBJECT IDENTIFIER type
A simple ASN.1 type whose distinguished values are the set of all object identifiers allocated in accordance with the
rules of ISO/IEC 8824-1 (ITU-T X.680).
3.1.18 Octet
An ordered sequence of eight bits considered as a unit, equivalent to an 8-bit byte.
NOTE: The term is used in preference to "byte" in this International Standard and in the ASN.1 standards to
avoid confusion in cases where there is a hardware association e.g. 7-bit byte, 16-bit byte.
3.1.19 RELATIVE-OID type
A particular object identifier where a common root-OID (for the first and subsequent arcs) is implied, and remaining
arcs after the root-OID are defined by the RELATIVE-OID.
3.1.20 Response
The feedback received by the application from an application command sent to the Data Protocol Processor.
© ISO/IEC 2004 – All rights reserved 3

3.1.21 System information
Information held on the RF tag, or generated by unique features of the air interface, that specify Data Protocol
parameters to establish the Logical Memory and other formatting rules.
3.1.22 Tag Driver
The implementation of the process to transfer data between the Data Protocol Processor and the RF tag.

3.1.23 Transfer syntax
The abstract syntax and concrete syntax used in the transfer of data between open systems.
NOTE: The term "transfer syntax" is sometimes used to mean encoding rules, and sometimes used to mean
the representation of bits in data while in transit.

3.1.24 Type reference
A name, in ASN.1 syntax, associated uniquely with a characteristic e.g. ObjectId.

3.1.25 Unique item identifier
A code assigned to an item (for example a product, transport unit, returnable asset) that is unique within the
domain and scope of a code system. When used with this Data Protocol, the particular ObjectId that defines the
unique item identifier shall rely on the fact that each instance of its object shall be unique and unambiguous with all
others related objects. As the object is unique, its use in the RF tag confers uniqueness to the RF tag itself.

3.2 Abbreviated terms
BER Basic Encoding Rules (of ASN.1)
EAN.UCC EAN International & Uniform Code Council, Inc
IATA International Air Transport Association
UPU Universal Postal Union
4 Protocol model
4.1 Overview
RFID supports bit encodation in the RF tag memory. Unlike other data carrier standards prepared by ISO/IEC
JTC1 SC31 which require encodation schemes that are specific to the individual data carrier technology, ISO/IEC
18000 does not specify the interpretation of bits or octets encoded on the RF tag memory. However, as an RF tag
is a relay in a communication system, each tag used for open systems item management needs to have data
encoded in a consistent manner. The prime function of this International Standard is to specify a common interface
between the application programs and the RF interrogator. The prime function of ISO/IEC 15962 is to specify the
common encoding rules and logical memory functions.
RF tags utilise electronic memory, which is typically capable of increasing data capacity as new generations of
product are introduced. Differences in data capacity of each RF tag type, whether similar or dissimilar, are
recognised by the data protocol defined in these two International Standards.
Different application standards may have their own particular data sets or data dictionaries. Each major application
standard for item management needs to have its data treated in an unambiguous manner, avoiding confusion with
data from other applications and even with data from closed systems. The data protocol specified in these
International Standards ensures the unambiguous identification of data.
4 © ISO/IEC 2004 – All rights reserved

4.2 Layered protocol
The protocol layers of an implementation of RFID for item management are illustrated schematically in Figure 1.
Application data - existing format,
not Object based
Advice in
Data conversion between existing
and Object-based formats
Application capable of handling
data in Object-based format
Scope of
APPLICATION
Application Commands &
LAYER
Responses
Data Compactor
DATA
Scope of
Data Formatter
PROTOCOL
PROCESSOR
Logical Memory
Annexes
Tag Driver
of 15962
Air interface hardware / software
Scope of
AIR
INTERFACE
RF
tag
Figure 1 — Schematic of Protocol Layers for an Implementation of RFID for Item Management
The data protocol specified in this International Standard is independent of the different RF tag technologies
specified in ISO/IEC 18000, which is concerned with different air interface protocols that function between the
interrogator and the RF tag. This independence is achieved by implementing the standards at different levels in the
protocol hierarchy. The RFID data protocol defined in this International Standard is primarily concerned with the
upper layers as described below:
Application layer - as defined in this International Standard
• The RFID data protocol specifies how data is presented as objects, each uniquely identified with an object
identifier, which are meaningful to the application and can be encoded on the RF tag.
• This RFID data protocol defines application commands and responses so that application programs can
specify what data to transfer to and from the RF tag and to append, update or delete data on the RF tag.
• This RFID data protocol also defines error messages as responses to the application.
The application interface of this RFID data protocol is based on ASN.1, which:
• provides a means of defining the protocol which is independent of the host application, operating system,
and programming language and also independent of the specific command structures between the
interrogator and tag driver.
• identifies any data object distinctly from all others using object identifiers, even to enable different data
formats to be intermixed on the same RF tag.
© ISO/IEC 2004 – All rights reserved 5

• defines unambiguous commands and responses, so that they can be intermixed with data on the same
wired or wireless network.
• provides the abstract syntax for defining the commands and responses in a structured and consistent and
verifiable manner, and provides the transfer syntax that defines the byte stream transferred between the
processes of this International Standard and those of ISO/IEC 15962.
• enables implementation in a variety of computer languages through the use of compilers, alternatively
programs can be written from the specification. In either case there is a vital need for the transfer syntax to
be fully consistent and compliant to function in open systems where the sender and recipient can be
unknown to one another.
Data Protocol Processing - as defined in ISO/IEC 15962
• The RFID data protocol specifies how data is encoded, compacted and formatted on the RF tag and how
this data is retrieved from the RF tag to be meaningful to the application.
• This RFID data protocol provides for a set of schemes that compact the data to make more use of the
memory space.
• This RFID data protocol also supports various storage formats to enable efficient use of memory and
efficient access procedures.
All these features are described and specified later in this International Standard and its companion standard.
Figure 1, and the outline description above, applies to a general process. Different rules may apply to RF tags that
are capable of executing commands (see 7.3.3 of ISO/IEC 15962).
This RFID data protocol specifies the application level communication and the RF tag interrogator level rules for
data encoding, compaction and storage formats. This protocol may be implemented:
• on the same platform as the application.
• on a separate platform linked to the application platform e.g. linked via a serial link, LAN or internet
connection.
• on an embedded platform e.g. in a bar code printer/RFID encoder, in a bar code/RFID scanner, or a
dedicated RFID interrogator.
This RFID data protocol has been designed such that the actual platform on which it is implemented is transparent
to the application. It is also independent of the programming language used by the application. If both standards
are not implemented, care will need to be taken to maintain the functionality between the two standards. The
compliance clauses of both standards address these points in greater detail.
The rules specified in these International Standards create a complete independence between the application and
the technology of the air interface and RF tag. The type of RF tag used in an implementation can be changed
without requiring the application to change.
4.3 Functional processes
There are various functional processes that need to take place to write data to an RF tag and to read data from it.
Figure 2 shows a schematic of an implementation where the processing of the data protocol resides in the
interrogator. This illustration is provided to help with the understanding of the processes, and although a typical
implementation, many others are possibly compliant with this data protocol.
6 © ISO/IEC 2004 – All rights reserved

APPLICATION INTERROGATOR RF TAG
Tag Physical Memory
Decoder
AIR
Logical
Encoder
Memory
INTERFACE
Map
APPLICATION
COMMANDS
COMMANDS
Tag
Command / Driver
Response and
Unit Mapping
RESPONSES
Rules
APPLICATION
RESPONSES
Logical Memory
Note: The Logical Memory Map in the
Tag Physical Memory is given by the
Tag architecture and the mapping rules
in the Tag Driver. All the information in
DATA PROTOCOL PHYSICAL
the Logical Memory is represented in
PROCESSOR INTERROGATOR
the Logical Memory Map
ISO/IEC 15961 ISO/IEC 15962 ISO/IEC 15962 ISO/IEC 18000
Annexes
Figure 2 — Logical Functions and Interfaces
Application is the user application database and software.
The data flows between the application and the Data Protocol Processor are formatted according to this
International Standard and are uncompacted. However, there are numerous established systems where data
is formatted to be compliant, for example, with a bar code related syntax. It is therefore reasonable to insert
interface modules in the data flow to convert from and to existing application formats.
NOTE: Careful consideration should be given to the extent that established systems need to be
supported relative to the potential benefits to be gained from adopting the data protocol specified in this
International Standard and ISO/IEC 15962. This is because this protocol has been developed around the
features of RFID, such as selective read/write and the ability to lock data. Older protocols are unlikely to
support such features.
Interrogator is the module in which all the basic processing of the data protocol takes place and there is an
interface to the RF tag.
Data Protocol Processor provides all the processing, which is as specified in ISO/IEC 15962 and is required
for handling application data. It consists of the following components, all of which are described more fully
below: Command/Response Unit, Logical Memory, Encoder (which supports a Data Compactor and Formatter
function) and Decoder (which supports the inverse functions of the Encoder). The Data Protocol Processor
can physically reside anywhere between the application software and the tag driver but shall contain all the
components.
Command/Response Unit for receiving the application commands from the application in a format
specified in this International Standard, acting upon these commands where appropriate and converting
to the specific RF tag lower level command codes.
© ISO/IEC 2004 – All rights reserved 7

EXAMPLE:
An application command of write Data Object {name} is application related. The data protocol
recognises this and can format the data onto the Logical Memory in the Data Protocol Processor. The
information from the particular RF tag is required to set the parameters of the Logical Memory Map
(e.g. number of octets, whether a directory is in use, etc) on the RF Tag. The Tag Driver converts the
application command into a tag-specific command.
It can be seen from this example that there is a distinct boundary between the Data Protocol Processor
and the Tag Driver.
Logical Memory. This is an array of contiguous octets (or bytes) of memory acting as a common
representation of the Logical Memory Map in the user memory of the RF tag to which the object
identifiers and data objects are mapped in octets. The Logical Memory takes into account some
parameters of the real RF tag, for example the block size, the number of blocks and the storage format.
The Logical Memory ignores any detailed tag architecture.
The use of the Logical Memory means that an application can interface with an application-compliant RF
tag, but that individual RF tags can have completely different memory capacities and architectures. This
enables an implementation to benefit from new technological developments permitted within the
framework of ISO/IEC 18000, such as larger capacity or faster access RF tags, without changing the
application.
Encoder controls the process of writing data through the functional processes performed by the Data
Compactor Module and Formatter Module.
Data Compactor provides the standard compaction rules to reduce the number of octets stored on the
RF tag and transferred across the air interface. Numeric data, for example, is octet based to some coded
character set for the application, but can be encoded in a compact form on the RF tag memory.
Formatter provides the processes to place the object identifier and object (data) into an appropriate and
efficient format for storing on the Logical Memory.
NOTE: The physical mapping of bits to comply with the RF tag architecture is performed by the Tag
Driver.
Decoder controls the process of reading and interpreting data through the functional processes
performed by the Data De-compactor Module and De-formatter Module.
Tag Driver provides two main functions:
• It maps the contents of the Logical Memory to the Logical Memory Map of the RF tag in use.
• It provides facilities that accept the application commands of this data protocol, and converts them to
a format that results in calls to command codes supported by the particular RF Tag. For example, an
application command write Data Object {name} could result in the RF tag related command of write
(block #, data).
The description of the tag driver for particular RF tags is provided in annexes of ISO/IEC 15962. For the
purpose of ISO/IEC 15962, a tag driver is unique to a particular air interface type of RF tag as specified in the
appropriate part of ISO/IEC 18000. This is a logical representation; physical implementation could combine
features of different logical tag drivers. An interrogator may support one or many tag drivers.
RF Tag, although beyond the scope of these International Standards, is shown to complete the flow of data
and commands.
Logical Memory Map represents all the data in the Logical Memory of the Data Protocol Processor converted
(or mapped) to a location structure determined by the mapping rules in the Tag Driver and the architecture of
the RF tag.
8 © ISO/IEC 2004 – All rights reserved

5 Data structure
5.1 Notation
5.1.1 The octet: the basic unit for 8-bit coding
This International Standard supports binary, 7-bit, 8-bit and user data that may exceed 8-bits per character. The
common unit of coding is the octet (also known as the 8-bit byte). Binary data shall be padded with leading zero
bits until the binary value is octet aligned; 7-bit data shall be represented as octets with bit 8 (see 5.1.2) set to a
zero value. Data exceeding 8-bits shall be encoded in multiple octets.
An octet is represented as 2 hexadecimal characters with the values 0-9, A-F.
5.1.2 Bit ordering
Within each octet, the most significant bit is bit 8 and the least significant is bit 1. Accordingly, the weight allocated
to each bit is:
Bit Value bit 8 bit 7 bit 6 bit 5 bit 4 bit 3 bit 2 bit 1
Weight 128 64 32 16 8 4 2 1
5.1.3 Octet conversion
The 8-bit value is converted into the two hexadecimal characters with bit 8, bit 7, bit 6 and bit 5 having the weights
8, 4, 2 and 1 respectively to define the first hexadecimal character. Bit 4, bit 3, bit 2 and bit 1 retain the weights 8,
4, 2 and 1 respectively to define the second hexadecimal character.
5.2 Structure of the transfer between ISO/IEC 15961 and ISO/IEC 15962
All object identifiers, data, commands, and responses transferred between the application and the Data Protocol
Processor shall be octet aligned. This simplifies the construction of the transfer and aids parsing the octets. It has
no significance on the encoding efficiency on the RF tag itself, because the process by the Data Protocol Processor
(as specified in ISO/IEC 15962) controls the final encodation.
6 Abstract and transfer syntax
ASN.1 defines:
• an abstract syntax, which is effectively a data definition language used to define repetitive and
optional structures using a number of primitive data types. It is equivalent to high level programming
languages, but is independent (hence "abstract") from any of these.
• a transfer syntax from which the encoding rules are derived. These rules determine the bit pattern
representation during the transfer of data structures created using the abstract syntax.
6.1 Abstract syntax
The abstract syntax for this International Standard shall be ASN.1 as defined in ISO/IEC 8824-1. The notation shall
be as specified in that standard.
The syntax required for RFID for item management are specified in Clause 7.
© ISO/IEC 2004 – All rights reserved 9

6.1.1 Character set
The character set used to define an ASN.1 item shall consist of:
A to Z
a to z
0 to 9
: = , { } < . @ ( ) [ ] - ' "  & ^ * ; !

This character set is identical to that defined in ISO/IEC 8824-1.
6.1.2 Universal Types
ASN.1 supports a number of universal types that are fundamental to the syntax; sometimes called "built-in types".
Each has been assigned a class tag in ISO/IEC 8824-1 to unambiguously identify each type of data. Universal
types are shown in capital (uppercase) letters e.g. UNIVERSAL. The Universal Types used in this International
Standard, together with their Class Tags, are shown in Table 1.
Table 1 — Universal Types Used in this Standard
Universal Type Class Tag
BOOLEAN 1
INTEGER 2
OBJECT IDENTIFIER 6
OCTET STRING 4
RELATIVE-OID 13
(reserved for future commands)
SEQUENCE & SEQUENCE OF 16
6.1.3 Type references
In addition to the Universal Types, ASN.1 enables application specific types to be defined. When a type is defined,
it is given a name to reference it in another type assignment. Type references begin with an uppercase letter and
the complete name is shown without spaces. There are a few variants to the presentation of the subsequent
characters. This International Standard uses the convention of mixed upper and lowercase characters e.g.
TypeReference.
The TypeReference name is followed by the three character sequence ": : =" to separate it from its definition.
Examples of TypeReference names that are used in this International Standard are:
ApplicationFamilyId
ObjectId
StorageFormat
TagId
All the TypeReference names used in this International Standard are defined in the appropriate sub-clause.
6.1.4 Element names
The components or elements of a TypeReference or enumerated list are named using a lowercase letter at the
beginning, e.g. elementName. For some elements, further typing is required either to a TypeReference or a
Universal Type.
10 © ISO/IEC 2004 – All rights reserved

Examples of elementNames that are used in this International Standard are:
accessMethod
applicationFamilyId
applicationSubFamily
commandCode
compactParameter
object
objectId
tagId
NOTE: In this International Standard, some elementNames and TypeReference names are often the same
with the exception that the first letter is lowercas
...