One document matched: draft-krishna-slrrp-01.txt
Differences from draft-krishna-slrrp-00.txt
SLRRP Working Group P. Krishna (Editor)
Internet-Draft Reva Systems Corp
Expires: Oct 15, 2005 David J. Husak
Reva Systems Corp
Mar 2005
Simple Lightweight RFID Reader Protocol
draft-krishna-slrrp-01.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions of
section 3 of RFC 3667. By submitting this Internet-Draft, each author
represents that any applicable patent or other IPR claims of which he or
she is aware have been or will be disclosed, and any of which he or she
become aware will be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on Oct 15, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Radio Frequency Identification (RFID) is a technique whereby a device,
known as an RFID 'reader', can remotely sense the presence of, and
access embedded memory on, a transponder known as a 'tag'. Tags may be
affixed to objects as a means of tracking the location and movement of
said objects within facilities equipped with RFID readers. Typically,
readers communicate with upstream devices, in this document referred to
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 1]
Internet-Draft SLRRP Mar 2005
as 'controllers', to receive control commands and upload read tag
information.
This draft specifies the Simple Lightweight RFID Reader Protocol, or
SLRRP (pronounced 'slurp'), to be used to convey configuration, control,
status, and tag information between controllers and readers in an IP-
based network.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . . . . 7
1.1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2. Organization of this document . . . . . . . . . . . . . . . . . 7
1.3. Scope of SLRRP . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2. Overview of RFID Infrastructure . . . . . . . . . . . . . . . . . 8
2.1. Generalized view of the Topology . . . . . . . . . . . . . . . 8
2.2. Communication between the Reader and the Tags . . . . . . . . . 9
2.3. Communication between the Reader Network Controllers and
Readers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Protocol Definition . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2. TCP Session Management . . . . . . . . . . . . . . . . . . . . 12
3.2.1. RNC Discovery . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2. TCP Session Establishment and Authentication . . . . . . . . 12
3.2.3. TCP Session Termination . . . . . . . . . . . . . . . . . . . 13
3.3. SLRRP Message Format . . . . . . . . . . . . . . . . . . . . . 13
3.4. SLRRP Message Types . . . . . . . . . . . . . . . . . . . . . . 14
3.4.1. GET_READER_INFO . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.2. GET_READER_INFO_RESPONSE . . . . . . . . . . . . . . . . . . 16
3.4.3. SET_READER_CONFIG . . . . . . . . . . . . . . . . . . . . . . 16
3.4.4. SET_READER_CONFIG_RESPONSE . . . . . . . . . . . . . . . . . 17
3.4.5. INVENTORY . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.6. INVENTORY_RESPONSE . . . . . . . . . . . . . . . . . . . . . 18
3.4.7. STOP_INVENTORY . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.8. STOP_INVENTORY_RESPONSE . . . . . . . . . . . . . . . . . . . 19
3.4.9. ACCESS . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4.10. ACCESS_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 20
3.4.11. STOP_ACCESS . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4.12. STOP_ACCESS_RESPONSE . . . . . . . . . . . . . . . . . . . . 21
3.4.13. INVENTORY_ACCESS_REPORT . . . . . . . . . . . . . . . . . . 21
3.4.14. READER_STATUS_REPORT . . . . . . . . . . . . . . . . . . . . 22
3.5. SLRRP Parameters . . . . . . . . . . . . . . . . . . . . . . . 22
3.5.1. Identification Parameter . . . . . . . . . . . . . . . . . . 25
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 2]
Internet-Draft SLRRP Mar 2005
3.5.2. Power Parameter . . . . . . . . . . . . . . . . . . . . . . . 26
3.5.3. Reader Device Config Parameter . . . . . . . . . . . . . . . 26
3.5.3.1. Antenna Configuration Parameters . . . . . . . . . . . . . 28
3.5.4. Reader Operational Parameters . . . . . . . . . . . . . . . . 28
3.5.4.1. RF Receiver Parameters . . . . . . . . . . . . . . . . . . 28
3.5.4.2. RF Transmitter Parameters . . . . . . . . . . . . . . . . . 29
3.5.4.3. Frequency Hop Tables Parameters . . . . . . . . . . . . . . 30
3.5.4.4. Fixed Frequency Parameters . . . . . . . . . . . . . . . . 31
3.5.4.5. Inventory Operation Timing Parameter . . . . . . . . . . . 31
3.5.5. Air Protocol Specific Parameters . . . . . . . . . . . . . . 32
3.5.5.1. EPC Class 1 Gen 2 Air Protocol . . . . . . . . . . . . . . 32
3.5.5.1.1. Inventory Command . . . . . . . . . . . . . . . . . . . . 32
3.5.5.1.1.1. EPC C1G2 RF Parameters . . . . . . . . . . . . . . . . 32
3.5.5.1.1.2. EPC C1G2 Singulation Parameters . . . . . . . . . . . . 33
3.5.5.1.1.3. EPC C1G2 Filter Parameters . . . . . . . . . . . . . . 34
3.5.5.1.1.4. EPC C1G2 Protocol Inventory Command Parameters . . . . 35
3.5.5.1.2. Access Command . . . . . . . . . . . . . . . . . . . . . 37
3.5.5.1.2.1. EPC C1G2 Target Tag Parameters . . . . . . . . . . . . 37
3.5.5.1.2.2. EPC C1G2 Tag Operations Parameters . . . . . . . . . . 38
3.5.5.1.2.3. EPC C1G2 Access Command Parameters . . . . . . . . . . 42
3.5.5.2. EPC Class 1 Gen 1 Air Protocol . . . . . . . . . . . . . . 43
3.5.5.2.1. Inventory Command . . . . . . . . . . . . . . . . . . . . 43
3.5.5.2.1.1. EPC C1G1 RF Parameters . . . . . . . . . . . . . . . . 43
3.5.5.2.1.2. EPC C1G1 Singulation Parameters . . . . . . . . . . . . 43
3.5.5.2.1.3. EPC C1G1 Filter Parameters . . . . . . . . . . . . . . 46
3.5.5.2.1.4. EPC C1G1 Protocol Inventory Command Parameters . . . . 47
3.5.5.2.2. Access Command . . . . . . . . . . . . . . . . . . . . . 48
3.5.5.2.2.1. EPC C1G1 Target Tag Parameters . . . . . . . . . . . . 48
3.5.5.2.2.2. EPC C1G1 Tag Operations Parameters . . . . . . . . . . 49
3.5.5.2.2.3. EPC C1G1 Access Command Parameters . . . . . . . . . . 52
3.5.6. Tag Inventory and Access Reporting Parameters . . . . . . . . 52
3.5.7. Statistics Parameters . . . . . . . . . . . . . . . . . . . . 52
3.5.8. Operation Error Parameter . . . . . . . . . . . . . . . . . . 52
3.5.8.1. Unspecified Error . . . . . . . . . . . . . . . . . . . . . 53
3.5.8.2. Unrecognized Parameter Error . . . . . . . . . . . . . . . 54
3.5.8.3. Unrecognized Message Error . . . . . . . . . . . . . . . . 54
3.5.8.4. Invalid Values Error . . . . . . . . . . . . . . . . . . . 54
3.5.8.5. Non-unique Antenna Identifier Error . . . . . . . . . . . . 54
3.6. Reader Operating Modes . . . . . . . . . . . . . . . . . . . . 54
3.6.1. Split Transmitter & Receiver Operation . . . . . . . . . . . 54
4. Security Considerations . . . . . . . . . . . . . . . . . . . . . 55
4.1. Threat Types . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2. Implementing Security Mechanisms . . . . . . . . . . . . . . . 56
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 56
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 56
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 3]
Internet-Draft SLRRP Mar 2005
1. Introduction
Radio Frequency Identification (RFID) is a technique whereby a device,
known as an RFID 'reader', can remotely sense the presence of, and
access embedded memory on, a transponder, known as a 'tag'. Tags may be
affixed to objects as a means to track the location and movement of said
objects within facilities equipped with readers. Tags may also include
environmental sensors that may capture and report conditions to which
the tag has been subjected. The tags can be stationary (attached to
fixed locations in a facility) or mobile (attached to things moving
about the facility). The readers can be stationary (attached to doors,
walls, shelving, or scaffolding) or mobile (handheld, or vehicle-
mounted).
Particular attention has been recently focused on new-generation RFID
technology employing low-cost, passive tags operating in worldwide
unlicensed UHF spectrum. Early adopters of this technology from a wide
variety of industries (including retail, military, healthcare and
manufacturing) are very enthusiastic about the potential of RFID to
create operational efficiencies, improve productivity, and enhance
safety factors, based on the following characteristics of an RFID
system:
* The ability of readers to single-out individual tags among large
aggregations
* The ability of readers to read tags rapidly (100s to 1000s per
second)
* The ability to read tags out of line-of-sight
* The ability of the tags to carry unique, serialized object
identifiers
* The ability of tags to include read/write storage
* The applicability of cryptographic technology to secure tag data
and system communication
Recently, as a result of the development of standard RF (air) protocols
and through the application of low-cost embedded computing technology,
the implementation of RFID readers has evolved from peripherals,
typically connected to a host computer via a serial port; to standalone
devices supporting TCP/IP stacks, connected via wired (Ethernet) or
wireless (802.11) LAN technology to enterprise computing resources
supporting RFID-enabled client applications. This evolution has been
accompanied by substantial reader price reductions, as reader
manufacturers prepare for large-volume deployments of the technology.
For RFID systems to successfully meet client application requirements,
high-quality tag scan data must be reliably and economically produced.
These systems may require readers deployed in large numbers, and the
operation of those readers will need to be effectively coordinated,
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 4]
Internet-Draft SLRRP Mar 2005
controlled and managed.
We envision a typical RFID deployment comprising of a network of RFID
readers controlled by one or more reader network controller (RNC)
elements. RNCs provide the control and data path interface to a reader
network and may be software/middleware on a server, embedded software in
a router/switch, or a standalone device. The RNCs are connected to
hosts/servers running client applications or integration middleware that
consume the acquired tag data and management applications that control
and monitor the operation of the reader network..
This draft specifies a controller-to-reader protocol (the Simple
Lightweight RFID Reader Protocol, or SLRRP (pronounced 'slurp') for use
in an IP-based network to convey configuration, control, status, and tag
information to and from readers. This protocol has the following
characteristics:
* Maximizes tag data good-put to client applications;
* Allows for efficient implementation on readers;
* Supports large numbers of readers in an environment;
* Supports authentication and security mechanisms appropriate to a
wide range of deployment scenarios.
Following are the system functions that are instrumented and controlled
through SLRRP and cooperating protocols:
1) Management of a network of readers:
* Discovery
* Firmware/software configuration
* Health monitoring
* Connectivity monitoring
* Statistics gathering
* Configuration and profile management
* Managing reader power consumption
* Security
2) RF-domain control:
* Allocating RF spectrum utilization across readers
* RF monitoring including interference detection and measurement
* Reader co-monitoring
* Controlling air protocol-specific RF parameters such as
backscatter modulation and data rates
3) Air protocol control:
* Controlling air protocol parameters
* Controlling tag access and tag state across readers
* Coordinating singulation parameters and/or state across readers
* Distributing reader-generated trigger events
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 5]
Internet-Draft SLRRP Mar 2005
SLRRP is meant to be generally applicable to readers employing any
standard air protocol, including those defined by ISO 18000-6, and
EPCglobal 1st and 2nd generation protocols, through the definition of
air-protocol-specific modules within SLRRP.
| | |
| | | High-layer Protocols
| | |/
| | |
+--------------+
| Reader |
| Network |
| Controller |
+--------------+
|
|
| SLRRP Control/Signaling
|/ & Data (over TCP/IP)
|
|
+------|---------+
+----------------+|
+----------------+||
| Readers ||+
| with Antennae |+
+----------------+
|
|
| Air Protocol
|/
|
|
+----+ +----+ +----+ +----+
|Tags| |Tags| |Tags| |Tags|
+----+ +----+ +----+ +----+
+----+ +----+ +----+ +----+
|Tags| |Tags| |Tags| |Tags|
+----+ +----+ +----+ +----+
Figure 1 Layers
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 6]
Internet-Draft SLRRP Mar 2005
1.1. Definitions and Acronyms
1.1.1. Definitions
Air Protocol
The definition of interaction between tags and readers in the RF
domain.
Attribute Value Pair
The variable length concatenation of a unique Attribute (represented
by an integer) and a Value containing the actual value identified by
the attribute. Multiple AVPs make up Messages between the readers and
RNC.
RFID Reader
The RFID reader is a device that runs the appropriate air protocol to
communicate with the tag.
Reader Network Controller
Logical or physical entity providing control and data path interface
to a reader network.
Singulation
The algorithm and process by which readers select a single tag from
among an population of tags to conduct a data transaction.
Tag
A transponder.
1.1.2. Acronyms
AVP Attribute Value Pair
EPC Electronic Products Code
ISO International Standards Organization
RFID Radio Frequency Identification Device
RNC RFID Reader Network Controller
TLS Transport Layer Security
1.2. Organization of this document
After introductory and informational material in Sections 1 and 2,
Section 3 describes the message formats and parameters used for SLRRP
communication between a Reader and a Reader Network Controller. Section
4 describes the security considerations in SLRRP.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 7]
Internet-Draft SLRRP Mar 2005
1.3. Scope of SLRRP
SLRRP is specifically concerned with providing the formats and
procedures of communications between an RFID Reader and Reader Network
Controller. This protocol runs over TCP (it is assumed that the readers
have a TCP/IP protocol stack on the network side), and it is assumed
that a scalable IP address allocation mechanism such as DHCP will be
used in the networks that support a large number of readers. [However,
it may be appropriate for another document produced in this working
group to specify the Reader Network Controller discovery mechanisms to
be used so that additional RNC functionality can be provided (e.g. load
balancing of served Reader load among Reader Network Controllers).]
1.4. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD
NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear
in this document, are to be interpreted as described in RFC2119 [2].
2. Overview of RFID Infrastructure
2.1. Generalized view of the Topology
RFID infrastructure consists of network elements that participate in the
acquisition and transmission of tag data.
<------------ Tag Data Transport Network --------->
- - - - - - Tag
/ \ --
/ \ /--Reader--- / \ Tag
Client-----\ /---- ----\/ / \
/ \ / \ --Reader--/ \ Tag
Client-----| | | | | |
| IP |--RNC--| IP |--Reader--| RF | Tag
Client-----| Network| | Network| | |
\ / \ /---Reader--\ / Tag
Client-----/ \---- / ----/\ \ /
\ Client--RNC / \--Reader--- \ / Tag
\ / --
- - - - - - Tag
Figure 2 RFID Infrastructure
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 8]
Internet-Draft SLRRP Mar 2005
The consumers of the tag data are the client network elements (e.g.,
end-user applications). The network elements between the tag and the
clients form the conduit to transport tag data over the network to the
applications. The elements in the Tag Data Transport Network include
tags, readers, and reader network controllers.
Depending on the facility size, volume of tag traffic, and client
network element requirements, the Tag Data Transport Network will have a
multiplicity of readers and reader network controllers.
2.2. Communication between the Reader and the Tags
A RFID reader reads the RFID tags in its field of view. The process of
reading each tag is accomplished by performing a series of tag collision
resolutions (singulation), and then accessing the data storage on the
singulated tag. That tag may then be 'set aside' while further
singulations are carried out, and the balance of the population is
accessed.
There are a variety of algorithms used for singulation, which may or may
not be dictated by the air protocol in use. Performance of the
singulation process may be critical to the success of an RFID system,
especially in the context of challenging RF environments, densely-
populated or fast-moving tagged objects.
The system singulation rate and tag access latency are key performance
parameters. It is anticipated that overall system performance may be
optimized by the application and tuning the RF, singulation and
population-thinning aspects of singulation algorithms within and across
readers.
It is also the case that tags may vary in data organization and storage
capabilities, including, for example, the integration of environmental
sensors. The tag may carry a generally-accessible identifier or other
capability indicator to allow the system to retrieve this data. Tags may
also require cryptographic keys or passwords for the retrieval of data.
2.3. Communication between the Reader Network Controllers and Readers
The communication between the reader network controllers (RNCs) and
readers includes commands from RNC to the reader, and responses from
readers to RNC. The commands can be grouped into tag control commands
and reader control commands.
A typical timeline of both SLRRP and air protocol interactions between
an RNC a reader and a population of tags is depicted in Figure 3, below.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 9]
Internet-Draft SLRRP Mar 2005
The general SLRRP operation consists of a reader configuration phase,
followed by one or more ACCESS commands, which parameterize subsequent
tag data accesses, followed by a series of INVENTORY commands, which
actually cause the reading operations to occur, which ultimately produce
INVENTORY_ACCESS_REPORTs which carry the tag data to the RNC from the
reader. Subsequent ACCESS commands may add to, or subtract from, the set
of active access parameters, and may also be used to perform specific
tag operations, such as writing, killing, or concealing a tag.
INVENTORY commands carry the RF, state and singulation parameters to be
used during reader operations subsequent to receipt of the command.
INVENTORY commands may be halted or preempted by subsequently received
INVENTORY commands.
The specific mapping of SLRRP commands and events to reader-to-tag
interactions is dependent on the particular air protocol in use.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 10]
Internet-Draft SLRRP Mar 2005
RNC Reader Tag(s)
| GET_READER_INFO | |
|<----------------------->| |
| SET_READER_CONFIG | |
|------------------------>| |
| | |
| ACCESS | |
|------------------------>| |
| ACCESS | |
|------------------------>| |
| ACCESS | |
|------------------------>| / Air Protocol \ |
| INVENTORY | \ Dependent / |
|------------------------>| |
| |------------------------>|
| |<------------------------|
| |------------------------>|
| INVEN_ACCESS_REPORT |<------------------------|
|<------------------------| ... |
| INVEN_ACCESS_REPORT | ... |
|<------------------------| ... |
| INVEN_ACCESS_REPORT |<------------------------|
|<------------------------| |
| |<------------------------|
| ACCESS | |
|------------------------>| |
| INVENTORY | |
|------------------------>| |
| |------------------------>|
| INVEN_ACCESS_REPORT |<------------------------|
|<------------------------| |
| INVENTORY | |
|------------------------>| |
| |------------------------>|
| |<------------------------|
| |------------------------>|
| INVENTORY |<------------------------|
|------------------------>| ... |
| |------------------------>|
| |<------------------------|
| |------------------------>|
| INVEN_ACCESS_REPORT |<------------------------|
|<------------------------| |
| INVEN_ACCESS_REPORT | |
|<------------------------| |
Figure 3 SLRRP Operation
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 11]
Internet-Draft SLRRP Mar 2005
3. Protocol Definition
3.1. Overview
SLRRP uses messages for the configuration of readers, data acquisition
commands from RNC to readers, and the transmission of reader status, RF
state information and tag data from readers to RNC.
+------------------------------------------------+
| Reader configuration, SLRRP channel |
| management, tag data acquisition commands, |
| tag data, RF state information. |
+------------------------------------------------+
| SLRRP Channel |
+------------------------------------------------+
| Packet Transport (TCP over IP) |
+------------------------------------------------+
| Layer 2 medium - e.g., 802.3, 802.11 |
+------------------------------------------------+
Figure 4 SLRRP Protocol Structure
All values are placed into their respective fields and sent in network
order (high order octets first).
3.2. TCP Session Management
3.2.1. RNC Discovery
Readers discover the IP address and port in use by the reader network
controller through means specified outside this document. In the most
simple operation, the readers would be configured with one or more RNC
IP addresses (and ports). More dynamic and scalable operations will be
specified to allow the readers to dynamically discover the servicing RNC
IP address and port. Reader discovery and connection initiation to the
RNCs is required in order to achieve the goals of scalable deployment.
3.2.2. TCP Session Establishment and Authentication
The reader initiates the TCP connection to the RNC. If the RNC can
accept the connection, it does so. Once the connection is established,
authentication MUST be executed over the connection as described in the
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 12]
Internet-Draft SLRRP Mar 2005
Security section. Unsuccessful authentication at either endpoint MUST
result in the immediate termination of the TCP session and no exchange
of SLRRP protocol messages.
3.2.3. TCP Session Termination
Either the reader or the RNC may close the TCP session. In either case,
it is expected that the reader will restart the discovery and initiation
process. The reader MUST implement an exponential backoff algorithm for
connection retries in order to not flood the RNC with unsuccessful
connection attempts. The backoff algorithm MAY stop increasing the retry
delay at a value not less than 1 minute.
3.3. SLRRP Message Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x| Ver | Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Seq Num |x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Message Value :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 SLRRP Message Format
x bits
The x bits are reserved for future extensions. All reserved bits MUST
be set to 0 on outgoing messages and ignored on incoming messages.
Ver: 3 bits
The version of SLRRP. Implementations of SLRRP based on this
specification are use the value 0x1. Other values are reserved for
future use.
Message Type: 8 bits
Is the type of SLRRP message being carried in the message.
Message Length: 16 bits
This value represents the size of the message in bytes including the
Message Type, Message Length, Message Seq Num and Message Value
fields. Therefore, if the Message Value field is zero-length, the
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 13]
Internet-Draft SLRRP Mar 2005
Length field will be set to 7
Message Seq Num: 16 bits
As stated earlier, the communications between the RNC and the reader
is primarily of a request-response type - requests/commands from the
RNC to the reader, and response from the reader to the RNC. In order
to facilitate multiple outstanding commands/requests from RNC, SLRRP
uses a Message sequence number in each message. The Message sequence
number is used to correspond a response with the original request.
This sequence number is local to the SLRRP channel.
Message Value: variable length
Dependent on the Message Type.
3.4. SLRRP Message Types
This section details the individual messages used by SLRRP. These
messages are composed in a standard message format, as described in
Section 3.3, consisting of message types and message values. Some
message types use parameter blocks in the message values. The parameter
descriptions are presented in Section 3.5.
The following SLRRP message types are defined in this section:
Type Message Name
----- -------------------------
0x00 - (reserved by IETF)
0x01 - GET_READER_INFO
0x02 - GET_READER_INFO_RESPONSE
0x03 - SET_READER_CONFIG
0x04 - SET_READER_CONFIG_RESPONSE
0x10 - INVENTORY
0x11 - INVENTORY_RESPONSE
0x12 - STOP_INVENTORY
0x13 - STOP_INVENTORY_RESPONSE
0x18 - ACCESS
0x19 - ACCESS_RESPONSE
0x1A - STOP_ACCESS
0x1B - STOP_ACCESS_RESPONSE
0x20 - INVENTORY_ACCESS_REPORT
0x21 - READER_STATUS_REPORT
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 14]
Internet-Draft SLRRP Mar 2005
3.4.1. GET_READER_INFO
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x| Ver | Type= 0x01 | Message Length = 0xB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Seq Num |x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This command is issued by the RNC to get the current configuration
information of the reader.
Requested Data: 32 bits
Each bit indicates the parameter of interest to RNC that has to be
returned by the reader. If multiple bits are set, the corresponding
parameters are returned.
Requested Data Returned Data
-------------- -------------
0x00000000 All Parameters
0x00000001 Statistics Parameter
0x00000002 Identification Parameter
0x00000004 Network Interface Parameter
0x00000008 Reader Device Config Parameter
0x00000010 RF Receiver Parameter
0x00000020 RF Transmitter Parameter
0x00000040 Inventory and Access Reporting Parameter
0x00000080 EPC Class 1 Gen2 RF Parameter
Others Reserved
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 15]
Internet-Draft SLRRP Mar 2005
3.4.2. GET_READER_INFO_RESPONSE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x| Ver | Type= 0x02 | Message Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Seq Num |x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
: Requested Parameters or Operation Error Parameters :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
This is the response by the reader to the GET_READER_INFO command.
3.4.3. SET_READER_CONFIG
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x| Ver | Type= 0x03 | Message Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Seq Num |x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Network Interface Parameter (optional) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RF Receiver Parameter (optional) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RF Transmitter Parameter (optional) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Inventory and Access Reporting Parameter (optional) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Statistics Parameter (optional) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Air Protocol Specific RF Parameter (optional) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This command is issued by the RNC to the reader. This command sets the
reader configuration using the parameters specified in this command.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 16]
Internet-Draft SLRRP Mar 2005
3.4.4. SET_READER_CONFIG_RESPONSE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x| Ver | Type= 0x04 | Message Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Seq Num |x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation Error Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is the response by the reader to a SET_READER_CONFIG command. If
all the parameters specified in the SET_READER_CONFIG command are
successfully set, then there are no operation error parameters in the
response, and the message length is 0x7.
3.4.5. INVENTORY
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x| Ver | Type= 0x10 | Message Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Seq Num |x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Antenna ID |x x x x x x x x| Air Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Air Protocol specific Inventory Command Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This command is issued by the RNC to the reader. This command starts the
execution of the inventory command at the antenna of the reader using
the parameters passed in this command.
Antenna ID: 8 bits
ID of the antenna where the inventory command has to be executed.
Air Protocol: 16 bits
Defines the type of air protocol to be used in the operation. Values
are:
0x0001 EPCGlobal Class 0
0x0002 EPCGlobal Class 1
0x0004 EPCGlobal Class 1 Gen2 (C1G2)
0x0008 ISO 18006-a
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 17]
Internet-Draft SLRRP Mar 2005
0x0010 ISO 18006-b
...
Air Protocol specific Inventory command parameter: Variable
If C1G2, then this field is the TLV that carries the EPC C1G2
Inventory command parameter (defined in Section 3.5.5.1.1).
3.4.6. INVENTORY_RESPONSE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x| Ver | Type= 0x11 | Message Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Seq Num |x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operation Error Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is the response by the reader to an INVENTORY command. If all the
parameters specified in the INVENTORY command are successfully set, then
there are no operation error parameters in the response, and the message
length is 0x7.
3.4.7. STOP_INVENTORY
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x| Ver | Type= 0x12 | Message Length = 0x7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Seq Num |x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Antenna ID |x x x x x x x x x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This command is issued by the RNC to the reader. This command stops the
execution of the inventory command at the antenna of the reader.
Antenna ID: 8 bits
ID of the antenna where the stop inventory command has to be
executed.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 18]
Internet-Draft SLRRP Mar 2005
3.4.8. STOP_INVENTORY_RESPONSE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x| Ver | Type= 0x13 | Message Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Seq Num |x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operation Error Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is the response by the reader to a STOP_INVENTORY command. If there
was an INVENTORY command that the reader was presently executing, and
the reader was successful in stopping that execution, then there are no
operation error parameters in the response, and the message length is
0x7. Else, an appropriate error parameter is sent.
3.4.9. ACCESS
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x| Ver | Type= 0x18 | Message Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Seq Num |x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Antenna ID |x x x x x x x x| Air Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Air Protocol specific Access Command Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Antenna ID: 8 bits
ID of the antenna where the access command has to be executed.
Air Protocol specific Access command parameter: Variable
If C1G2, then this field is the TLV that carries the EPC C1G2 Access
command parameter (defined in Section 3.5.5.1.2.3).
This command creates a new access-spec at the reader. The reader
executes this access-spec till it gets a STOP_ACCESS from the RNC. An
access-spec contains a 2-tuple <target tag spec, operation spec> that
describes the operations (described in operation spec) to be performed
at the tags (described in target tag spec).
The access-spec will take effect with the next (and subsequent)
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 19]
Internet-Draft SLRRP Mar 2005
inventory rounds.
3.4.10. ACCESS_RESPONSE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x| Ver | Type= 0x19 | Message Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Seq Num |x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access ID |x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation Error Parameter (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is the response by the reader to an ACCESS command. If the
parameters passed in that ACCESS command were successfully accepted and
set at the reader, then the reader assigns an ID to the access-spec and
returns the ID in this ACCESS_RESPONSE message. However, if the access-
spec was not successfully created at the reader, the reader sends a NULL
access ID and includes an operation error parameter describing the error
in the message.
3.4.11. STOP_ACCESS
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x| Ver | Type= 0x1A | Message Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Seq Num |x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access ID |x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This command is issued by the RNC to the reader. This command stops the
execution of the access command corresponding to the ID "access ID."
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 20]
Internet-Draft SLRRP Mar 2005
3.4.12. STOP_ACCESS_RESPONSE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x| Ver | Type= 0x1B | Message Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Seq Num |x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation Error Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is the response by the reader to a STOP_ACCESS command. If there
was an access-spec at the reader corresponding to the Access ID passed
in the STOP_ACCESS command, and the reader was successful in deleting
that access-spec, then there are no operation error parameters in the
response, and the message length is 0x7. Else, an appropriate error
parameter is sent.
3.4.13. INVENTORY_ACCESS_REPORT
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x| Ver | Type= 0x20 | Message Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Seq Num |x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Tag Report Data Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This command is issued by the reader to the RNC. The reader sends the
results of the Inventory and Access command. The results are sent back
every round - the size of the round is defined in the inventory command.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 21]
Internet-Draft SLRRP Mar 2005
3.4.14. READER_STATUS_REPORT
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|x|x|x|x| Ver | Type= 0x21 | Message Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Seq Num |x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Reader Status Report Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This command is issued by the reader asynchronously to the RNC.
Status report message may be sent by the reader due to critical events
such as reboot, fault-detection in a reader functional block, buffer
overflow, or due to the activation of an reader accessory trigger input
(e.g. motion detection), or due to performance monitoring events such as
abnormalities in RF environment.
Reader configuration will determine the maximum frequency and/or pacing
of status reports.
3.5. SLRRP Parameters
SLRRP Parameters are defined in the following Type-Length-Value (TLV)
format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A | User | Parameter Type | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Parameter Value :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A: 2 bits
The two bits specify the action that must be taken if the processing
endpoint does not recognize the Parameter Type.
00 - Stop processing this SLRRP message and discard it, do not
process any further parameters within it.
01 - Stop processing this SLRRP message and discard it, do not
process any further parameters within it, and report the
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 22]
Internet-Draft SLRRP Mar 2005
unrecognized parameter in an 'Unrecognized Parameter' error (see
Section 3.5.8.2).
10 - Skip this parameter and continue processing.
11 - Skip this parameter and continue processing, but report the
unrecognized parameter in an 'Unrecognized Parameter' error (see
Section 3.5.8.2).
User: 4 bits
User defined bits.
Parameter Type: 10 bits
The Type field is a 10 bit identifier of the type of parameter. It
takes a value of 0 to 1023.
The value of 1023 is reserved for IETF-defined extensions. Values
other than those defined in specific SLRRP parameter description are
reserved by IETF. (Additional types, when needed, will be defined in
the future through appropriate IETF/IANA procedures.)
The values of parameter types are defined as follows:
Value Parameter Type
----- ----------
0x0 - (reserved by IETF)
0x1 - Identification
0x2 - Network Interface Parameter
0x3 - Reader Device Config
0x4 - Antenna Parameter
0x10 - RF Receiver
0x11 - RF Transmitter
0x12 - Frequency Hop Tables
0x13 - Fixed Frequency Table
0x20 - EPC Class 1 Gen 2 RF Parameters
0x21 - EPC C1G2 Singulation Parameters
0x22 - EPC C1G2 Filter Parameters
0x23 - EPC ClG2 Inventory Command
0x24 - EPC C1G2 Target Tag Parameters
0x25 - EPC C1G2 Tag Operation Parameters
0x26 - EPC C1G2 Access Command
0x30 - ISO 18006a RF Parameters
0x31 - ISO 18006a Singulation Parameters
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 23]
Internet-Draft SLRRP Mar 2005
0x32 - ISO 18006a Filter Parameters
0x33 - ISO 18006a Inventory Command
0x34 - ISO 18006a Target Tag Parameters
0x35 - ISO 18006a Tag Operation Parameters
0x36 - ISO 18006a Access command
0x40 - ISO 18006b RF Parameters
0x41 - ISO 18006b Singulation Parameters
0x42 - ISO 18006b Filter Parameters
0x43 - ISO 18006b Inventory Command
0x44 - ISO 18006b Target Tag Parameters
0x45 - ISO 18006b Tag Operation Parameters
0x46 - ISO 18006b Access command
0x50 - ISO 18006c RF Parameters
0x51 - ISO 18006c Singulation Parameters
0x52 - ISO 18006c Filter Parameters
0x53 - ISO 18006c Inventory Command
0x54 - ISO 18006c Target Tag Parameters
0x55 - ISO 18006c Tag Operation Parameters
0x56 - ISO 18006c Access command
0x60 - EPC Class 0 RF Parameters
0x61 - EPC Class 0 Singulation Parameters
0x62 - EPC Class 0 Filter Parameters
0x63 - EPC Class 0 Inventory Command
0x64 - EPC Class 0 Target Tag Parameters
0x65 - EPC Class 0 Tag Operation Parameters
0x66 - EPC Class 0 Access command
0x70 - EPC Class 1 Gen 1 RF Parameters
0x71 - EPC C1G1 Singulation Parameters
0x72 - EPC C1G1 Filter Parameters
0x73 - EPC C1G1 Inventory Command
0x74 - EPC C1G1 Target Tag Parameters
0x75 - EPC C1G1 Tag Operation Parameters
0x76 - EPC C1G1 Access command
0x90 - Operation Error Parameter
0xA0 - Inventory and Access Report Parameter
0xA1 - Statistics
0xA2 - Reader Status Report Parameter
others - (reserved by IETF)
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 24]
Internet-Draft SLRRP Mar 2005
Parameter Length: 16 bits
The Parameter Length field contains the size of the parameter in
bytes, including the Parameter Type, Parameter Length, and Parameter
Value fields. Thus, a parameter with a zero-length Parameter Value
field would have a Length field of 4.
Parameter Value: variable-length
The Parameter Value field contains the actual information to be
transferred in the parameter.
3.5.1. Identification Parameter
This parameter defines a TLV that carries an identification parameter
that is unique within the scope of the Tag Data Transport Network. The
identifier could be the reader MAC address, serial number, or EPC, but
the specific convention for readers in a Tag Data Transport Network MUST
be known so that uniqueness can be guaranteed.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A | IDType| Type = 0x1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reader ID [0:31] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reader ID [32:63] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Reader ID [64:96] :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
ID Type: 4 bits
Type of the ID used to identify the reader.
IDType ID
0x0 MAC address
0x1 EPC
0x2 Other Numbering (Binary)
0x3 ASCII String
Length: 16 bits
Length of the ID (bytes)
Reader ID: Variable
Contains the reader identifier.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 25]
Internet-Draft SLRRP Mar 2005
3.5.2. Network Interface Parameters
Certain reader devices may be powered using Power-over-Ethernet (PoE,
802.3af). This parameter defines a TLV that enables the reader to report
its power requirements. The RNC device may or may not be the power
source to the PoE reader. This TLV carries information regarding the
power requirements of the reader in different operating modes. This
allows the RNC to monitor and manage the power budgets of a reader
network when manipulating the readers to ensure that the total power
budget for the PoE port is not exceeded.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A |x x x x| Type = 0x2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode |x x x x x x x x x x x x| Power Requirement |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mode |x x x x x x x x x x x x| Power Requirement |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: :
Mode: 4 bits
Operating mode of the reader.
0x0: Standby mode (TX Power = OFF, RX = OFF)
0x1: RX Only (TX Power = OFF, RX = ON)
0x2: Full Power (TX Power = FULL, RX = ON)
0x3: Half Power (TX Power = HALF, RX = ON)
Additional modes may be defined later.
Power Requirement: 16 bits
This contains the power requirement in Watts*10.
3.5.3. Reader Device Config Parameter
This parameter defines the TLV that carries the configuration
information of the reader:
- Number of antennas and types of antennas
- Capabilities of the reader device
- Frequency hop table parameters
- Fixed frequency parameters
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 26]
Internet-Draft SLRRP Mar 2005
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A |x x x x| Type = 0x3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reader Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Antenna Configuration Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Frequency Hop Tables Parameters :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Fixed Frequency Parameters :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Antenna Configuration Parameter
Specified in 3.5.3.1.
Reader Capabilities
Each bit reflects the ability of the reader pertaining to that
capability.
0x1 : Control Power
0x2 : Independent Rx and Tx control
0x4 : Write tag
0x8 : Kill tag
Frequency hop table parameters
Specified in 3.5.4.3.
Fixed frequency parameters
Specified in 3.5.4.4.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 27]
Internet-Draft SLRRP Mar 2005
3.5.3.1. Antenna Configuration Parameters
This parameter defines a TLV that carries the antenna configuration
parameters for the reader.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A |User |S| Type = 0x04 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x| #of Antennas |x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Antenna ID | AntennaType | Antenna Gain |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Antenna ID | AntennaType | Antenna Gain |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: . . . . : . . . . : . . . . :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Antenna ID: 8 bits
ID of the antenna.
Antenna Type: 8 bits
Type of antenna. Values are:
0x1 : Vertical Polarization
0x2 : Horizontal Polarization
0x3 : Circular Polarization
Antenna Gain: 16 bits
3.5.4. Reader Operational Parameters
3.5.4.1. RF Receiver Parameters
This parameter defines a TLV that carries the RF receiver parameters.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A |User |S| Type = 0x10 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Antenna ID | Sensitivity |x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 28]
Internet-Draft SLRRP Mar 2005
User: 3 bits
User defined bits.
S: Receiver state bit
ON or OFF.
Antenna ID: 8 bits
ID of the antenna.
Receiver Sensitivity: 8 bits
Receive sensitivity threshold.
3.5.4.2. RF Transmitter Parameters
This parameter defines a TLV that carries the RF transmitter
parameters.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A |User |S| Type = 0x11 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Antenna ID |Transmit Power | FHSeqID |x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
User: 3 bits
User defined bits.
S: Transmitter state bit
ON or OFF
Antenna ID: 8 bits
ID of the antenna.
Transmit Power: 8 bits
Transmit power level
FHSeqID: 8 bits
This is the index of the hop table to be used by the reader.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 29]
Internet-Draft SLRRP Mar 2005
3.5.4.3. Frequency Hop Tables Parameters
This parameter defines a TLV that carries the frequency hop table
parameters. This is used for readers operating in regions with frequency
hopping regulatory requirements.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A |User |S| Type = 0x12 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x| #FHSeq | FHSeqID | #of hops |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frequency 1 | Frequency 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frequency N-1 | Frequency N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FHSeqID | #of Hops | Frequency 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Frequency 2 | Frequency 3 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
#FHSeq: 8 bits
This is the number of frequency hop tables maintained at the reader.
FHSeqID: 8 bits
This is the index of the current hop table being used by the reader.
#of hops: 8bits
The number of hops in this hop table.
This is followed by the listing of the frequencies in order for the
table. Index 0 for this table has frequency 1, index 1 has frequency 2,
and so and so forth.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 30]
Internet-Draft SLRRP Mar 2005
3.5.4.4. Fixed Frequency Parameters
This parameter defines a TLV that carries the fixed frequency parameter.
It lists the frequencies that can be used by the reader.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A |User |S| Type = 0x13 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x x x x x x x x x x x x x x x x x| #of Freqs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frequency 1 | Frequency 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frequency N-1 | Frequency N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.5.4.5. Inventory Operation Timing Parameter
This parameter defines a TLV that carries the timing definition for the
inventory operation. It defines the start-time of the round, number of
rounds and the size of the round.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A |N| User| Type = 0x14 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Round # | End Round # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Round Size (Time) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
N: 1 bit
This is the 'start-now' bit. If this bit is set, the inventory round
starts as soon as the reader receives the command. If this bit is not
set, then the start time field is the round starting time.
Start Time: 32 bits
This is the starting time of the inventory operation.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 31]
Internet-Draft SLRRP Mar 2005
Start Round#: 16 bits
The starting round number where the parameters are to be used.
End Round#: 16 bits
The ending round number up to which the parameters are to be used.
Round Size: 32 bits
This basically determines the size of each round. The units of time
is microseconds.
3.5.5. Air Protocol Specific Parameters
3.5.5.1. EPC Class 1 Gen 2 Air Protocol
3.5.5.1.1. Inventory Command
This section presents the parameters pertaining to an inventory command.
3.5.5.1.1.1. EPC C1G2 RF Parameters
These are RF control parameters that are specific to C1G2 air protocol.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A | User | Type = 0x20 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PIE | PIE |Fwd|P| M | TRCal |D| RFU |
| Rate | Ratio |Mod|X| | |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIE Rate: 5 bits
The Tari period time.
PIE Ratio: 5 bits
Ratio of the 0 bit period and 1 bit period.
Fwd Mod: 2 bits
ASK or BPSK.
P-X: 1 bit
Extended preamble or not. Extended preamble is useful for slow
readers, where the reader instructs the tag to use extended preamble
on the reverse link.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 32]
Internet-Draft SLRRP Mar 2005
M: 2 bits
Number of subcarrier cycles per symbol. This along with the link
frequency determines the reverse link rate.
TRCal: 5 bits
The Tag->reader calibration symbol length. The reverse link frequency
is computed using TRCal and DR (divide ratio).
DR: 1 bit
Divide ratio to use - only two values have been specified - 64/3 and
8.
3.5.5.1.1.2. EPC C1G2 Singulation Parameters
These are singulation parameters that are particular to C1G2 air
protocol. The singulation protocol employs the Q algorithm. The Q
algorithm specifies how the value of Q is updated during the
interrogation round. The goal is to maximize the tag acquisition rate
given a target singulation environment. A target singulation environment
depends on (a) mobility of the tag, (b) tag population, and (c) RF
environment. The optimal choice of a Q-manipulation algorithm depends on
the target environment.
Using this singulation parameter TLV, we provide the flexibility in the
reader protocol to either specify the Q-manipulation algorithm to use in
a particular round, or just specify the parameter-set that describes the
target singulation environment.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A | User | Type = 0x21 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x|Sess#|I|S|M| Mob | Pop | Env |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm Description |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sess#: 4 bits
The session number to use at the tags.
I: 1 bit
Inventoried state of the target tag population: A or B.
S: 1 bit
SL or ~SL tags
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 33]
Internet-Draft SLRRP Mar 2005
M: 1 bit
The mode of transmitting requested adjustment protocol to use in this
round.
M=0: Specify the algorithm
M=1: Specify the tuple that describes the target singulation
environment. The reader uses its own intelligence to
determine the algorithm based on the environment details
sent by the RNC.
Mob: 8 bits
Encoding of the expected tag mobility in the field of view of the
reader.
Pop: 8 bits
Encoding of the expected tag population in the field of view of the
reader.
Env: 8 bits
Encoding of the expected RF environment in the field of view of the
reader.
Q-algorithm: 32 bits
Description of the Q-algorithm to use. This is used if M was
specified to be 0. One example of describing the algorithm is
specification of starting Q value, QStepUpSize, QStepDownSize for a
linear increase, linear decrease algorithm.
3.5.5.1.1.3. EPC C1G2 Filter Parameters
These are parameters specific to C1G2 filter(in particular the
parameters for the select command) operation, and are sent with each
inventory command from the RNC to the reader. This sets up the target
tag population that gets inventoried. The parameter set supports
multiple filters to be sent. Multiple filters are used by the reader to
perform union/intersection operations by issuing successive select
command with the masks.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 34]
Internet-Draft SLRRP Mar 2005
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A | User | Type = 0x22 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|T| Action|MB | Pointer | MaskLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Mask (up to 255 bits long) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|T| Action|MB | Pointer | MaskLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Mask (up to 255 bits long) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The filter parameter consists of one or more filter-specs. Each filter
spec contains the following fields:
T: 1 bit
Truncate bit. This is set if the RNC is interested in only a
truncated portion of the tag to be backscattered by the tag. The
portion that gets backscattered includes the portion of the tag ID
following the mask. This bit has to be set only in the last filter-
spec.
Action: 4 bits
This describes the action for matching and non-matching tags - e.g.,
do nothing, assert or deassert SL, assign inventoried S0/S1/S2/S3 to
A or B.
MB: 2 bits
The tag memory bank.
Pointer: 16 bits
EBV encoding of the pointer to the beginning of the pattern in
memory.
MaskLength: 8 bits
Length of the mask.
Mask: up to 255 bits
Mask to be used.
3.5.5.1.1.4. EPC C1G2 Protocol Inventory Command Parameters
These are parameters specific to C1G2 inventory protocol, and are sent
with each inventory command from the RNC to the reader.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 35]
Internet-Draft SLRRP Mar 2005
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A |L| User| Type = 0x23 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Inventory Operation Timing Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Selection Filter Parameters :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RF Parameters :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Singulation Parameters :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Inventory Operation Timing Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:
:
In the EPC Gen2 protocol, inventory is done in terms of rounds. Using
the above TLV, we provide the capability to define parameters for each
round. In order to support the scenario where there are multiple rounds
that use the same parameters, we use start and end round numbers.
We also allow the flexibility to have the reader operate in an semi-
autonomous manner, where the RNC sends this inventory command parameters
and the reader inventories continuously till it gets a stop command from
RNC. This is done by specifying the lifetime of the inventory command
parameters (L bit).
L: 1 bit
L=0: Execute this command set once.
L=1: Repeat this sequence of inventory commands forever till a stop
command from RNC.
Inventory Operation Timing Parameter
This is the inventory operation timing parameter defined in 3.5.4.5.
Selection Filter Parameters
This is the selection filter parameter TLV structure as defined in
3.5.5.1.1.3. This defines the filter-spec for the rounds between the
start and end rounds.
RF Parameters
This is the RF parameter TLV structure as defined in 3.5.5.1.1.1.
This defines the RF parameters for the rounds between the start and
end rounds.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 36]
Internet-Draft SLRRP Mar 2005
Singulation Parameters
This is the singulation parameter as defined in 3.5.5.1.1.2. This
defines the singulation parameters for the rounds between the start
and end rounds.
3.5.5.1.2. Access Command
This section presents the parameters pertaining to an access command.
3.5.5.1.2.1. EPC C1G2 Target Tag Parameters
These parameters are sent part of the access command. They describe the
target tag population on which certain operations have to be performed.
Operations are described in 3.5.5.1.2.2. These parameters need not have
been air protocol specific, however, the tag memory layout are also
being defined in the air protocols. This parameter is similar to the
selection filter parameters described in 3.5.5.1.1.3.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A | User | Type = 0x24 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BoolOper |MB | Pointer | MaskLength :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Mask (up to 255 bits long) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
The target tag parameter consists of one or more tag-specs. Each tag
spec contains the following fields:
BoolOper: 6 bits
Each tag-spec specifies the boolOper to be used when including this
tag-spec.
0x1 : OR
0x2 : AND
0x3 : XOR
0x4 : NOR
0x5 : NAND
0x6 : XNOR
For example, if the tag parameter block had only one tag-spec.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 37]
Internet-Draft SLRRP Mar 2005
Suppose the tag-spec has a mask value of 0x1111, mask length of 16
and the BoolOper of 0x4, the final target-tag-filter to be used for
this access-spec is 0xffff NOR 0x1111 = 0xeeee.
Let us suppose, if the tag parameter block had two tag-specs.
BoolOper = 0x4, MB = 0, Pointer = 0, MaskLen = 16, Mask = 0x1111
BoolOper = 0x1, MB = 0, Pointer = 0, MaskLen = 16, Mask = 0x3333
All tags matching 0xeeee and 0x3333 will be operated on using this
access-spec.
MB: 2 bits
The tag memory bank. This tells the reader which portion of the
memory is the tag-spec interested in. There are 4 banks defined in
the C1G2 spec - user, EPC, TID and reserved.
Pointer: 16 bits
EBV encoding of the pointer to the beginning of the pattern in
memory.
MaskLength: 8 bits
Length of the mask.
Mask: up to 255 bits
Mask to be used.
3.5.5.1.2.2. EPC C1G2 Tag Operations Parameters
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A | User | Type = 0x25 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Op-specs :
: :
This parameter is sent as part of the access-spec (section 3.5.5.1.2.3)
in the access command. There can be one or more operations performed on
a tag. This parameter describes the set of operations to be performed on
a tag that matches the target tag-spec (section 3.5.5.1.2.1). The key
point to note is that the ordering of the operations in this parameter
is the exact order in which the reader performs these operations on the
tag.
Each operation is defined using an op-spec each 8 bytes long. Only the
block write op-spec may be more 8 bytes long. The length of that op-spec
is specified as part of the op-spec.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 38]
Internet-Draft SLRRP Mar 2005
Each op-spec has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode | |
+-+-+-+-+-+-+-+-+ |
| Operation-Specific Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OpCode Operation
0x0 Undefined
0x1 Read
0x2 Write
0x3 Kill
0x4 Lock
0x5 Block Erase
0x6 Block Write
Following are the op-specs for the different access operations:
Read Op-spec
------------
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 0x1 | MB| RFU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WordPtr | Word Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MB: 2 bits
Memory bank
RFU: 22 bits
Reserved for future use.
WordPtr: 16 bits
Starting word address.
Word Count: 16 bits
Number of 16-bit words to be read.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 39]
Internet-Draft SLRRP Mar 2005
Write Op-spec
-------------
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 0x2 | MB| Type| RFU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WordPtr | WriteData |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MB: 2bits
Memory bank
Type: 3 bits
This determines the data to be written. The data to written at
the target Location could either be the WriteData (passed in
this op-spec), or could be data that is present at the reader
(e.g., current time, sensor data).
000: Write WriteData.
001: Write timestamp
010: Write sensor data.
WriteData: 16 bits
Data to be written to the tag.
Kill Op-spec
------------
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 0x3 | RFU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kill Password |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kill Password: 32 bits
Value of the kill password to be used/set.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 40]
Internet-Draft SLRRP Mar 2005
Lock Op-spec
------------
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 0x4 | RFU | Lock Command Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Password |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lock Command Payload: 20 bits
First 10 bits are the mask bits, and the last 10 bits are action
bits. They basically describe the access privilege updates
(read/write/permalock) to be performed in various locations of
the memory. The five data fields for which we can define access
control using the lock command are: Kill password, access
password, EPC memory, TID memory and User memory.
Access Password: 32 bits
A reader can perform lock operation on a tag only if the tag is
in "secured" state. The tag enters secured state only using the
Access password (if a non-zero value).
BlockErase Op-spec
------------------
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 0x5 | MB| RFU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WordPtr | WordCount |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MB: 2 bits
Memory bank
WordPtr : 16 bits
Start word address for the block erase.
WordCount : 16 bits
Number of 16-bit words to be erased.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 41]
Internet-Draft SLRRP Mar 2005
BlockWrite Op-spec
------------------
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 0x6 | MB| RFU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WordPtr | WordCount |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: WriteData :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MB: 2 bits
Memory bank
WordPtr: 16 bits
Start word address for the block write.
WordCount: 16 bits
Number of 16-bit words to be written.
WriteData: Variable
Shall be a 16 x WordCount bits in length.
3.5.5.1.2.3. EPC C1G2 Access Command Parameters
These are parameters specific to access procedures for EPC C1G2 air
protocol.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A | User | Type = 0x26 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: EPC C1G2 Target Tag Parameters :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: EPC C1G2 Tag Operations Parameters :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 42]
Internet-Draft SLRRP Mar 2005
3.5.5.2. EPC Class 1 Gen 1 Air Protocol
3.5.5.2.1. Inventory Command
This section presents the parameters pertaining to an inventory command
for EPC C1G1 air protocol.
3.5.5.2.1.1. EPC C1G1 RF Parameters
These are RF control parameters that are specific to C1G1 air protocol.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A | User | Type = 0x70 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fwd Link|M| RFU |
| Rate | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fwd Link Rate: 5 bits
This specifies the link rate from the reader to the tag. The reverse
link rate is a factor of the forward link rate.
M: 1 bit
This is the reader data modulation. The standard specifies 2
alternatives - M = 0: Standard: Tdata0 = 1/8th of T0 (master clock
interval), Tdata1 - 3/8th of T0. M = 1: Alternative: Tdata0 = 1/4th
of T0, and Tdata1 = 1/2 of T0.
3.5.5.2.1.2. EPC C1G1 Singulation Parameters
These are singulation parameters that are particular to the C1G1 air
protocol. The singulation protocol employs a set of commands that
performs a tree-traversal. The goal is to maximize the tag acquisition
rate given a target singulation environment. A target singulation
environment depends on (a) mobility of the tag, (b) tag population, and
(c) RF environment. The optimal choice of sequence of commands to be
used during singulation depends on the target environment.
Using this singulation parameter TLV, we provide the flexibility in the
reader protocol to either specify the tree-traversal algorithm to use in
a particular round, or just specify the parameter-set that describes the
target singulation environment.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 43]
Internet-Draft SLRRP Mar 2005
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A | User | Type = 0x71 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x|M| Mob | Pop | Env |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm Description |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M: 1 bit
The mode of transmitting requested adjustment protocol to use in this
round.
M=0: Specify the algorithm that specifies the sequence of
commands to be sent over the air during singulation.
M=1: Specify the tuple that describes the target singulation
environment. The reader uses its own intelligence to
determine the algorithm based on the environment details
sent by the RNC.
Mob: 8 bits
Encoding of the expected tag mobility in the field of view of the
reader.
Pop: 8 bits
Encoding of the expected tag population in the field of view of the
reader.
Env: 8 bits
Encoding of the expected RF environment in the field of view of the
reader.
Tree Traversal Algorithm: 32 bits
Description of the tree traversal algorithm to use. This is used if M
was specified to be 0. The basic commands specified in the C1G1 spec
are described below. These commands are sent by the reader to the
tags. With each command is a filter definition specified as <PTR,
LEN, VALUE>, where PTR = starting memory location, LEN = length of
the filter, and the VALUE = value of the filter.
ScrollID
Tags that match the filter specified in the command scroll back the
tag memory.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 44]
Internet-Draft SLRRP Mar 2005
Quiet
Sets the tags that match the filter to sleep state. The tags start
responding only upon getting a Talk or due to power up.
Talk
This command wakes up the tags that match the filter.
PingID
The tags that match the filter specified in the command send a
response back with a byte of the tag memory starting from the
location LOC, where LOC = PTR+LEN. The tag responds at the time slot
corresponding to targetBin, where targetBin = 3 bits = Tag memory
contents in locations [PTR+2:PTR]. After sending the PingID, the
reader monitors for backscatter in each of the following 8 time
slots. If there are multiple tags responding in the same slot, the
reader senses collision. If no collision,the reader can send a
ScrollID command with the <PTR, LEN, VALUE>. This command basically
divides the tags in the field of view that matches <PTR, LEN, VALUE>
into 8 regions. Each command instance also yields at least 3 new bits
of the tag memory that were not known. Algorithmically speaking, the
followup action to a PingID response can either be breadth-first
search or depth-first search. The reader can maintain information
about the progress through the tree by storing tree regions (i.e.,
filters) where contention were detected but not resolved.
ScrollAllID
This command from the reader causes a scroll of all tags in the field
of view irrespective of whether they match the filter or not.
PingScrollID
This is an optional combination command to do a scroll+quiet
operation on tags that matched the filter.
One example of command combinations is presented as follows.
Single tag inventory (e.g., conveyor belt)
In such an environment, there is no tag collision to worry - neither
do we worry about tag responding multiple times because the tag is in
the FOV for a very limited time. The goal is capture the tag as soon
as possible. For such a case, the command sequence could be a <T *
Talk followed by S * ScrollID> commands, where T,S >= 1.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 45]
Internet-Draft SLRRP Mar 2005
3.5.5.2.1.3. EPC C1G1 Filter Parameters
These are parameters specific to C1G1 tag filter mask to be used during
singulation and are sent with each inventory command from the RNC to the
reader. This sets up the starting point in the tree during the
singulation.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A | User | Type = 0x72 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x| Pointer | MaskLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask (up to 96 bits long) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pointer: 16 bits
Pointer to the beginning of the pattern in memory.
MaskLength: 8 bits
Length of the mask.
Mask: up to 96 bits
Mask to be used.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 46]
Internet-Draft SLRRP Mar 2005
3.5.5.2.1.4. EPC C1G1 Protocol Inventory Command Parameters
These are parameters specific to C1G1 inventory protocol, and are sent
with each inventory command from the RNC to the reader.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A |L| User| Type = 0x73 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Inventory Operation Timing Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: C1G1 Filter Parameters :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: C1G1 RF Parameters :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: C1G1 Singulation Parameters :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Inventory Operation Timing Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:
:
Inventory is done in terms of rounds. Using the above TLV, we provide
the capability to define parameters for each round. In order to support
the scenario where there are multiple rounds that use the same
parameters, we use start and end round numbers.
We also allow the flexibility to have the reader operate in an semi-
autonomous manner, where the RNC sends this inventory command parameters
and the reader inventories continuously till it gets a stop command from
RNC. This is done by specifying the lifetime of the inventory command
parameters (L bit).
L: 1 bit
L=0: Execute this command set once.
L=1: Repeat this sequence of inventory commands forever till a stop
command from RNC.
Inventory Operation Timing Parameter
This is the inventory operation timing parameter defined in 3.5.4.5.
Filter Parameters
This is the filter parameter TLV structure as defined in 3.5.5.2.1.3.
This defines the filter-spec for the time-interval defined by the
timing parameter.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 47]
Internet-Draft SLRRP Mar 2005
RF Parameters
This is the RF parameter TLV structure as defined in 3.5.5.2.1.1.
This defines the RF parameters for the duration defined by the timing
parameter.
Singulation Parameters
This is the singulation parameter as defined in 3.5.5.2.1.2. This
defines the singulation parameters for the duration defined by the
timing parameter.
3.5.5.2.2. Access Command
This section presents the parameters pertaining to an access command.
3.5.5.2.2.1. EPC C1G1 Target Tag Parameters
These parameters are sent part of the access command. They describe the
target tag population on which certain operations have to be performed.
Operations are described in 3.5.5.2.2.2. These parameters need not have
been air protocol specific, however, the tag memory layout are also
being defined in the air protocols. This parameter is similar to the
selection filter parameters described in 3.5.5.2.1.3.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A | User | Type = 0x74 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BoolOper |x x| Pointer | MaskLength :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Mask (up to 96 bits long) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
The target tag parameter consists of one or more tag-specs. Each tag
spec contains the following fields:
BoolOper: 6 bits
Each tag-spec specifies the boolOper to be used when including this
tag-spec.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 48]
Internet-Draft SLRRP Mar 2005
0x1 : OR
0x2 : AND
0x3 : XOR
0x4 : NOR
0x5 : NAND
0x6 : XNOR
For example, if the tag parameter block had only one tag-spec.
Suppose, the tag-spec has a mask value of 0x1111, mask length of 16
and the BoolOper of 0x4, the final target-tag-filter to be used for
this access-spec is 0xffff NOR 0x1111 = 0xeeee.
Let us suppose, if the tag parameter block had two tag-specs.
BoolOper = 0x4, MB = 0, Pointer = 0, MaskLen = 16, Mask = 0x1111
BoolOper = 0x1, MB = 0, Pointer = 0, MaskLen = 16, Mask = 0x3333
All tags matching 0xeeee and 0x3333 will be operated on using this
access-spec.
Pointer: 16 bits
Pointer to the beginning of the pattern in the tag memory.
MaskLength: 8 bits
Length of the mask.
Mask: up to 96 bits
Mask to be used.
3.5.5.2.2.2. EPC C1G1 Tag Operations Parameters
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A | User | Type = 0x75 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Op-specs :
: :
This parameter is sent as part of the access-spec (section 3.5.5.2.2.3)
in the access command. There can be one or more operations performed on
a tag. This parameter describes the set of operations to be performed on
a tag that matches the target tag-spec (section 3.5.5.2.2.1). The key
point to note is that the ordering of the operations in this parameter
is the exact order in which the reader performs these operations on the
tag.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 49]
Internet-Draft SLRRP Mar 2005
Each operation is defined using an op-spec each 8 bytes long. The length
of that op-spec is specified as part of the op-spec.
Each op-spec has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode | |
+-+-+-+-+-+-+-+-+ |
| Operation-Specific Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OpCode Operation
0x0 Undefined
0x1 Read
0x2 Write
0x3 Kill
Following are the op-specs for the different access operations:
Read Op-spec
------------
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 0x1 |x x| RFU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WordPtr | Word Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RFU: 22 bits
Reserved for future use.
WordPtr: 16 bits
Starting word address.
Word Count: 16 bits
Number of 16-bit words to be read.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 50]
Internet-Draft SLRRP Mar 2005
Write Op-spec
-------------
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 0x2 |x x| Type| RFU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WordPtr | WriteData |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 3 bits
This determines the data to be written. The data to written at
the target Location could either be the WriteData (passed in
this op-spec), or could be data that is present at the reader
(e.g., current time, sensor data).
000: Write WriteData.
001: Write timestamp
010: Write sensor data.
WriteData: 16 bits
Data to be written to the tag.
Kill Op-spec
------------
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode = 0x3 | RFU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kill Password |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kill Password: 32 bits
Value of the kill password to be used/set. Up to 32 bits long.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 51]
Internet-Draft SLRRP Mar 2005
3.5.5.2.2.3. EPC C1G1 Access Command Parameters
These are parameters specific to access procedures for EPC C1G1 air
protocol.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A | User | Type = 0x76 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: EPC C1G1 Target Tag Parameters :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: EPC C1G1 Tag Operations Parameters :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.5.6. Tag Inventory and Access Reporting Parameters
This parameter defines a TLV that carries the Tag inventory and access
reporting parameters. This describes the contents of the report sent by
the reader, and also, defines the events (timers or triggers) that cause
the report to be sent. The contents of the report can include (a) tag
data inventoried, (b) tag access results, and (c) RF report.
TBD.
3.5.7. Statistics Parameters
TBD.
3.5.8. Operation Error Parameter
This parameter is used in SLRRP for a message sender to report an
error(s) to a message receiver.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x90 | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: one or more Error Causes :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 52]
Internet-Draft SLRRP Mar 2005
Length: 16 bits (unsigned integer)
Indicates the entire length of the parameter in number of octets.
Error causes are defined as variable-length parameters using the
following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code | Cause Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Cause-specific Information :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cause Code: 16 bits (unsigned integer)
Defines the type of error condition being reported.
Cause Code
Value Cause Code
--------- ----------------
0 Unspecified Error
1 Unrecognized Parameter
2 Unrecognized Message
3 Invalid Values
4 Non-unique Antenna Identifier
other values Reserved by IETF
Cause Length: 16 bits (unsigned integer)
Set to the size of the parameter in bytes, including the Cause Code,
Cause Length, and Cause-Specific Information fields.
Cause-specific Information: variable length
This field carries the details of the error condition.
The following subsections define specific error causes.
3.5.8.1. Unspecified Error
This error cause is used to report an unspecified error by the sender.
There is no cause specific information.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 53]
Internet-Draft SLRRP Mar 2005
3.5.8.2. Unrecognized Parameter Error
This error cause is used to report an unrecognized parameter. The
unrecognized parameter TLV is included as cause specific information.
3.5.8.3. Unrecognized Message Error
This error cause is used to report an unrecognized message. The
unrecognized message TLV is included as cause specific information.
3.5.8.4. Invalid Values Error
This error cause is used to report one or more invalid values found in a
received parameter. The offending TLV that contains the invalid value(s)
is included as cause specific information.
3.5.8.5. Non-unique Antenna Identifier Error
This error cause is used by a Reader to indicate to a RNC that the
antenna identifier it chose the reader has already been used by another
antenna in the reader. There is no cause specific information.
3.6. Reader Operating Modes
In this section, we will list the various reader operating modes
possible using SLRRP protocol messages.
3.6.1. Split Transmitter & Receiver Operation
+-------+-------+--------------+
| Rx | Tx | Mode |
| State | State | |
+-------+-------+--------------+
| 0 | 0 |Antenna is OFF|
+-------+-------+--------------+
| 0 | 1 | Tx ON only |
+-------+-------+--------------+
| 1 | 0 | RF ON only |
+-------+-------+--------------+
| 1 | 1 | Normal |
+-------+-------+--------------+
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 54]
Internet-Draft SLRRP Mar 2005
4. Security Considerations
4.1. Threat Types
Threats to the system are enumerated below. It is possible that certain
environments will not perceive all of the following as threats and will,
therefore, not implement all of the solutions presented.
4.1.1. Security Threat 1
Threat: Reader registration/deregistration flooding or spoofing
Security mechanism in response: Reader Network Controller authenticates
the Reader
4.1.2. Security Threat 2
Threat: Reader registers with a malicious Reader Network Controller
Security mechanism in response: Reader authenticates the Reader Network
Controller
Threats 1 and 2 taken together results in mutual authentication of the
Reader Network Controller and the Reader.
4.1.3. Security Threat 3
Threat: Replay attack
Security mechanism in response: Security protocol which has protection
from replay attacks
4.1.4. Security Threat 4
Threat: Corrupted data which causes a Reader or Reader Network
Controller to receive misinformation during command or response
communication
Security mechanism in response: Security protocol which supports
integrity protection
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 55]
Internet-Draft SLRRP Mar 2005
4.1.5. Security Threat 5
Threat: Eavesdropper snooping on control or tag data information
Security mechanism in response: Security protocol which supports data
confidentiality
To summarize, the threats require security mechanisms which support
authentication, integrity, data confidentiality, protection from replay
attacks.
For SLRRP, we need to authenticate the following:
Reader <---- Reader Network Controller (RNC authenticates the Reader)
Reader Network Controller <----> Reader (mutual authentication)
4.2. Implementing Security Mechanisms
We do not define any new security mechanisms specifically for responding
to these threats. Rather we use existing IETF security protocols to
provide the security services required. TLS supports all these
requirements and MUST be implemented. The TLS_RSA_WITH_AES_128_CBC_SHA
ciphersuite MUST be supported at a minimum by implementers of TLS as
described in RFC2246[3] for SLRRP. Implementers MAY also support any
other ciphersuite.
Reader Network Controllers and Readers SHOULD possess a site certificate
whose subject corresponds to their Identification Parameter. All SLRRP
elements that support TLS MUST have a mechanism for validating
certificates received during TLS negotiation; this entails possession of
one or more root certificates issued by certificate authorities
(preferably well-known distributors of site certificates comparable to
those that issue root certificates for web browsers).
5. IANA Considerations
This document has no actions for IANA.
6. Acknowledgments
The authors would like to thank Jeff Fischer for guiding us on the Gen2
air protocol details. We also acknowledge the comments and improvements
suggested by Mike Grady (who also did the bulk of the initial internet-
draft formatting), Scott Barvick (who wrote the security section), and
Peter Spreadborough (who gave invaluable feedback based on lessons
learnt from implementing SLRRP).
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 56]
Internet-Draft SLRRP Mar 2005
7. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9,
RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P.
Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
Author's Addresses
P. Krishna
Reva Systems Corp
100 Apollo Dr
Chelmsford, MA 01824
Phone: +1 978-244-0010 x206
Email: pkrishna@revasystems.com
David J. Husak
Reva Systems Corp
100 Apollo Dr
Chelmsford, MA 01824
Phone: +1 978-244-0010 x202
Email: dhusak@revasystems.com
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 57]
Internet-Draft SLRRP Mar 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Krishna (Editor), et al. Expires Oct 15, 2005 [Page 58]
| PAFTECH AB 2003-2026 | 2026-04-24 02:46:58 |