Internet DRAFT - draft-krishna-slrrp
draft-krishna-slrrp
SLRRP Working Group P. Krishna (Editor)
Internet-Draft Reva Systems Corp
Expires: Feb 15, 2006 David J. Husak
Reva Systems Corp
Aug 2005
Simple Lightweight RFID Reader Protocol
draft-krishna-slrrp-03.txt
Status of this Memo
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 becomes aware will
be disclosed, in accordance with Section 6 of BCP 79.
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 Feb 15, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005). 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
as 'controllers', to receive control commands and upload read tag
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 1]
Internet-Draft SLRRP Aug 2005
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 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. SLRRP Parameter Guidelines . . . . . . . . . . . . . . . . . 25
3.5.2. Identification Parameter . . . . . . . . . . . . . . . . . . 26
3.5.3. Network Interface Parameter . . . . . . . . . . . . . . . . . 27
3.5.4. Reader Device Config Parameter . . . . . . . . . . . . . . . 27
3.5.4.1. Antenna Configuration Parameter . . . . . . . . . . . . . . 28
3.5.4.2. Reader Capabilities Parameter . . . . . . . . . . . . . . . 29
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 2]
Internet-Draft SLRRP Aug 2005
3.5.4.3. Tag Parameter . . . . . . . . . . . . . . . . . . . . . . . 29
3.5.4.4. Tag Mask Parameter . . . . . . . . . . . . . . . . . . . . 29
3.5.5. Reader Operational Parameters . . . . . . . . . . . . . . . . 30
3.5.5.1. RF Receiver Parameters . . . . . . . . . . . . . . . . . . 30
3.5.5.2. RF Transmitter Parameters . . . . . . . . . . . . . . . . . 30
3.5.5.3. Frequency Hop Tables Parameters . . . . . . . . . . . . . . 31
3.5.5.4. Fixed Frequency Parameters . . . . . . . . . . . . . . . . 31
3.5.5.5. Inventory Operation Timing Parameter . . . . . . . . . . . 32
3.5.5.6. Trigger Parameter . . . . . . . . . . . . . . . . . . . . . 33
3.5.5.7. Trigger Value Parameter . . . . . . . . . . . . . . . . . . 33
3.5.6. Air Protocol Specific Parameters . . . . . . . . . . . . . . 34
3.5.6.1. EPC Class 1 Gen 2 Air Protocol . . . . . . . . . . . . . . 34
3.5.6.1.1. Inventory Command . . . . . . . . . . . . . . . . . . . . 34
3.5.6.1.1.1. EPC C1G2 RF Parameters . . . . . . . . . . . . . . . . 34
3.5.6.1.1.2. EPC C1G2 Singulation Parameters . . . . . . . . . . . . 35
3.5.6.1.1.3. EPC C1G2 Filter Parameters . . . . . . . . . . . . . . 36
3.5.6.1.1.4. EPC C1G2 Protocol Inventory Command Parameters . . . . 38
3.5.6.1.2. Access Command . . . . . . . . . . . . . . . . . . . . . 39
3.5.6.1.2.1. EPC C1G2 Target Tag Parameters . . . . . . . . . . . . 39
3.5.6.1.2.2. EPC C1G2 Tag Operations Parameters . . . . . . . . . . 40
3.5.6.1.2.3. EPC C1G2 Access Command Parameters . . . . . . . . . . 44
3.5.6.2. EPC Class 1 Gen 1 Air Protocol . . . . . . . . . . . . . . 45
3.5.6.2.1. Inventory Command . . . . . . . . . . . . . . . . . . . . 45
3.5.6.2.1.1. EPC C1G1 RF Parameters . . . . . . . . . . . . . . . . 45
3.5.6.2.1.2. EPC C1G1 Singulation Parameters . . . . . . . . . . . . 45
3.5.6.2.1.3. EPC C1G1 Filter Parameters . . . . . . . . . . . . . . 47
3.5.6.2.1.4. EPC C1G1 Protocol Inventory Command Parameters . . . . 48
3.5.6.2.2. Access Command . . . . . . . . . . . . . . . . . . . . . 49
3.5.6.2.2.1. EPC C1G1 Target Tag Parameters . . . . . . . . . . . . 49
3.5.6.2.2.2. EPC C1G1 Tag Operations Parameters . . . . . . . . . . 50
3.5.6.2.2.3. EPC C1G1 Access Command Parameters . . . . . . . . . . 52
3.5.7. Inventory and Access Reporting Parameters . . . . . . . . . . 52
3.5.7.1. Inventory and Access Report Parameter . . . . . . . . . . . 53
3.5.7.2. Inventory and Access Data Parameter . . . . . . . . . . . . 53
3.5.7.3. Tag Data Parameter . . . . . . . . . . . . . . . . . . . . 54
3.5.8. Statistics Parameters . . . . . . . . . . . . . . . . . . . . 55
3.5.9. Operation Error Parameter . . . . . . . . . . . . . . . . . . 55
3.5.9.1. Unspecified Error . . . . . . . . . . . . . . . . . . . . . 56
3.5.9.2. Unrecognized Parameter Error . . . . . . . . . . . . . . . 56
3.5.9.3. Unrecognized Message Error . . . . . . . . . . . . . . . . 57
3.5.9.4. Invalid Values Error . . . . . . . . . . . . . . . . . . . 57
3.5.9.5. Non-unique Antenna Identifier Error . . . . . . . . . . . . 57
3.6. Reader Operating Modes . . . . . . . . . . . . . . . . . . . . 57
3.6.1. Split Transmitter & Receiver Operation . . . . . . . . . . . 57
4. Security Considerations . . . . . . . . . . . . . . . . . . . . . 58
4.1. Threat Types . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2. Implementing Security Mechanisms . . . . . . . . . . . . . . . 59
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 59
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 59
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 3]
Internet-Draft SLRRP Aug 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 Feb 15, 2006 [Page 4]
Internet-Draft SLRRP Aug 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:
1) Network connectivity to readers:
* Connection establishment and state maintenance
* Managing reader power consumption for POE readers
* Security considerations
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
* Requesting and coordinating tag operations such as writing of
tag data, reading user memory, etc.
* Coordinating singulation parameters and/or state across readers
* Distributing reader-generated trigger events
SLRRP is meant to be generally applicable to readers employing any
standard air protocol, including those defined by ISO 18000-6, and
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 5]
Internet-Draft SLRRP Aug 2005
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 Feb 15, 2006 [Page 6]
Internet-Draft SLRRP Aug 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 Feb 15, 2006 [Page 7]
Internet-Draft SLRRP Aug 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 Feb 15, 2006 [Page 8]
Internet-Draft SLRRP Aug 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 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 Feb 15, 2006 [Page 9]
Internet-Draft SLRRP Aug 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
STOP_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 Feb 15, 2006 [Page 10]
Internet-Draft SLRRP Aug 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 Feb 15, 2006 [Page 11]
Internet-Draft SLRRP Aug 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 Feb 15, 2006 [Page 12]
Internet-Draft SLRRP Aug 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|V| Ver | Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Seq Num |x x x x x x x x x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: 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.
V (Vendor) bit: 1 bit
Setting this bit indicates that the vendor ID field is present in the
message header and that the message or message parameters contain
non-standard vendor specific extensions. Implementations may choose
to ignore any messages with the V bit set.
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.
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 13]
Internet-Draft SLRRP Aug 2005
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
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.
Vendor ID: 32 bits (Optional)
The presence of this field is indicated by the V or vendor bit being
set. The Vendor ID field and Vendor bit must be used when the message
or message parameters contain non-standard vendor specific
extensions. Implementations may chose ignore all or selected messages
with the Vendor bit set and the Vendor ID present. Responses to
messages ignored because of the Vendor bit being set must contain the
appropriate error code.
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
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 14]
Internet-Draft SLRRP Aug 2005
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
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 Report Parameter
0x00000080 EPC Class 1 Gen2 RF Parameter
0x00000100 Reader Status Report Parameter
Others Reserved
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 15]
Internet-Draft SLRRP Aug 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) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Air Protocol Specific RF Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Inventory and Access Report Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Reader Status Report Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Statistics 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.
Using this command any of the parameters can be sent to the reader, and
those values persist till they are changed using another
set_reader_config command or using other commands that carries the
parameter.
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 16]
Internet-Draft SLRRP Aug 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
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.
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 18000-6a
0x0010 ISO 18000-6b
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 17]
Internet-Draft SLRRP Aug 2005
0x0020 ISO 18000-6c
...
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.6.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 = 0xB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Feb 15, 2006 [Page 18]
Internet-Draft SLRRP Aug 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
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)
inventory rounds.
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: 16 bits
Defines the type of air protocol to be used in the operation. Values
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 19]
Internet-Draft SLRRP Aug 2005
are:
0x0001 EPCGlobal Class 0
0x0002 EPCGlobal Class 1
0x0004 EPCGlobal Class 1 Gen2 (C1G2)
0x0008 ISO 18000-6a
0x0010 ISO 18000-6b
0x0020 ISO 18000-6c
...
Air Protocol specific Access command parameter: Variable
For example, if C1G2 air protocol, then this field is the TLV that
carries the EPC C1G2 Access command parameter (defined in Section
3.5.6.1.2.3).
3.4.10. ACCESS_RESPONSE
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.
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 20]
Internet-Draft SLRRP Aug 2005
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." The
reader deletes the corresponding access-spec, and this access-spec will
stop taking effect from the next inventory round.
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Inventory and Access Data Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This command is issued by the reader to the RNC. The reader sends the
results of the Inventory and Access command. The Inventory and Access
Report parameter in the reader configuration will determine the
frequency and contents of this report. The Inventory and Access Data
parameter is specified in Section 3.5.6.2. The message sequence number
corresponds to the sequence number of the inventory command.
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 21]
Internet-Draft SLRRP Aug 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 Data 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 the RF environment. Since this command is an
asynchronous response from the reader, the message sequence number has
no relevance, and can be zeroed out by the reader.
The Reader Status Report parameter in the reader configuration will
determine the frequency and contents of the 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.
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 22]
Internet-Draft SLRRP Aug 2005
01 - Stop processing this SLRRP message and discard it, do not
process any further parameters within it, and report the
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 Parameter
0x2 - Network Interface Parameter
0x3 - Reader Device Config
0x4 - Antenna Parameter
0x5 - Reader Capabilities
0x6 - Tag Parameter
0x7 - Tag Mask Parameter
0x10 - RF Receiver
0x11 - RF Transmitter
0x12 - Frequency Hop Tables
0x13 - Fixed Frequency Table
0x14 - Inventory Operation Timing Parameter
0x15 - Trigger Parameter
0x16 - Trigger Value Parameter
0x20 - EPC Class 1 Gen 2 RF Parameters
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 23]
Internet-Draft SLRRP Aug 2005
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 18000-6a RF Parameters
0x31 - ISO 18000-6a Singulation Parameters
0x32 - ISO 18000-6a Filter Parameters
0x33 - ISO 18000-6a Inventory Command
0x34 - ISO 18000-6a Target Tag Parameters
0x35 - ISO 18000-6a Tag Operation Parameters
0x36 - ISO 18000-6a Access command
0x40 - ISO 18000-6b RF Parameters
0x41 - ISO 18000-6b Singulation Parameters
0x42 - ISO 18000-6b Filter Parameters
0x43 - ISO 18000-6b Inventory Command
0x44 - ISO 18000-6b Target Tag Parameters
0x45 - ISO 18000-6b Tag Operation Parameters
0x46 - ISO 18000-6b Access command
0x50 - ISO 18000-6c RF Parameters
0x51 - ISO 18000-6c Singulation Parameters
0x52 - ISO 18000-6c Filter Parameters
0x53 - ISO 18000-6c Inventory Command
0x54 - ISO 18000-6c Target Tag Parameters
0x55 - ISO 18000-6c Tag Operation Parameters
0x56 - ISO 18000-6c 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
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 24]
Internet-Draft SLRRP Aug 2005
0xA0 - Statistics
0xA1 - Inventory and Access Report Parameter
0xA2 - Reader Status Report Parameter
0xA3 - Inventory and Access Data parameter
0xA4 - Tag Data Parameter
0xA5 - RF Report Data Parameter
0xA6 - Reader Status Data Parameter
others - (reserved by IETF)
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. SLRRP Parameter Guidelines
The following rules apply to Parameters:
- Parameters may contain mandatory and optional fields.
- Parameter fields may be passed by value or by sub-parameter.
- Mandatory fields will always be present and optional fields may or may
not be present.
- Mandatory fields of fixed length will be passed by value only, using the
order, size and alignment defined in this document.
- A mandatory field of variable length must be passed by value if it is
the only field, mandatory or optional, of variable length in that
parameter.
- A parameter with multiple mandatory or optional fields of variable
length must pass them as a sub-parameters.
- A parameter containing a field of variable length being passed by value
may not contain sub-parameters.
- Optional fields will always be passed as sub-parameters.
The following rules apply to sub-parameters:
- Sub-parameters follow all parameter rules.
- A sub-parameter is a parameter that is encompassed within the length of
a preceeding parameter and adds to the dataset of the encapsulating
parameter.
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 25]
Internet-Draft SLRRP Aug 2005
ParameterA-length---------------------------+
Data |
ParameterB-length---+ |
Data <-+ |
ParameterC-length---------------+ |
Data | |
ParameterD-length---+ | |
Data <-+ <-+ <-+
- Sub-parameters may be mandatory or optional.
3.5.2. 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 Feb 15, 2006 [Page 26]
Internet-Draft SLRRP Aug 2005
3.5.3. Network Interface Parameter
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: 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.4. 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 and
fixed frequency parameters.
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 27]
Internet-Draft SLRRP Aug 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
Specified in 3.5.3.2
Frequency hop table parameters
Specified in 3.5.4.3.
Fixed frequency parameters
Specified in 3.5.4.4.
3.5.4.1. Antenna Configuration Parameter
This parameter defines a TLV that carries an antenna's configuration in
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 |x x x x| Type = 0x04 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 28]
Internet-Draft SLRRP Aug 2005
Antenna Gain: 16 bits
3.5.4.2. Reader Capabilities Parameter
This parameter defines a TLV that carries the capabilities of 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 |x x x x| Type = 0x05 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ReaderCapabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reader Capabilities: 32 bits
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
3.5.4.3. Tag Parameter
This parameter defines a TLV that carries the tag ID.
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 = 0x06 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
Tag ID: Variable length Byte array; MSB First ordered tag ID bytes.
3.5.4.4. Tag Mask Parameter
This parameter defines a TLV that carries the tag mask.
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 = 0x07 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 29]
Internet-Draft SLRRP Aug 2005
Tag Mask: Variable length Byte array; MSB First ordered tag mask bytes.
3.5.5. Reader Operational Parameters
3.5.5.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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S: Receiver state bit
ON or OFF.
Antenna ID: 8 bits
ID of the antenna.
Receiver Sensitivity: 8 bits
Receive sensitivity threshold.
3.5.5.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.
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 30]
Internet-Draft SLRRP Aug 2005
Transmit Power: 8 bits
Transmit power level
FHSeqID: 8 bits
This is the index of the hop table to be used by the reader.
3.5.5.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 |x x x x| Type = 0x12 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x| #FHSeq | FHSeqID | #of hops |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frequency 1 | Frequency 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frequency N-1 | Frequency N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
#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 on. If the reader has multiple frequency hop tables, each
table will be sent using this parameter.
3.5.5.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.
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 31]
Internet-Draft SLRRP Aug 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 = 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.5.5. Inventory Operation Timing Parameter
This parameter defines a TLV that carries the timing definition for the
inventory operation. It defines the start trigger, stop trigger for the
inventory operation, and also defines the number of rounds and the size
of each 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 | User | Type = 0x14 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trigger Parameter-Start (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trigger Parameter-Stop (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Round Size (Time) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Trigger Parameter-Start
This parameter defines the event that causes the inventory operation
to start at the reader. This is an optional field - if this field is
not present, then the reader starts the inventory operation
immediately upon receipt of the inventory command.
Trigger Parameter-Stop
This parameter defines the event that causes the inventory operation
to stop at the reader. This is an optional field - if this field is
not present, then the reader stops the inventory operation upon
receipt of a stop_inventory command.
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 32]
Internet-Draft SLRRP Aug 2005
Round Size: 32 bits
This basically sets the size of each inventory round. The unit of
time is microseconds.
3.5.5.6. Trigger Parameter
This parameter defines a TLV that carries the trigger definition. This
is used for controlling inventory and reporting operations.
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 = 0x15 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trigger Type | RFU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trigger Value Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Trigger Type Description
0x01 Every Inventory round
0x02 Every T time units, where T is specified by Trigger
Value.
0x03 Upon seeing a tag, whose pattern matches the value
specified in Trigger Value.
0x04 At time T, where T is specified by Trigger Value.
0x05 Immediate execution - i.e., do now.
0x06 After N inventory rounds, where, N is specified by
Trigger Value.
0x07 Externally defined trigger as specified by Trigger
Value.
0x08 Upon connection establishment to a host whose address is
specified by Trigger Value.
3.5.5.7. Trigger Value Parameter
This parameter defines a TLV that carries the trigger value as used in
the trigger parameter.
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 33]
Internet-Draft SLRRP Aug 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 = 0x16 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Trigger Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.5.6. Air Protocol Specific Parameters
3.5.6.1. EPC Class 1 Gen 2 Air Protocol
3.5.6.1.1. Inventory Command
This section presents the parameters pertaining to an inventory command.
3.5.6.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.
M: 2 bits
Number of subcarrier cycles per symbol. This along with the link
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 34]
Internet-Draft SLRRP Aug 2005
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.6.1.1.2. EPC C1G2 Singulation Parameters
These are singulation parameters that are particular to the 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sess#| I | S |M| Mob | Pop | Env |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm Description |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sess#: 4 bits
The session number to use at the tags.
I: 2 bits
00 : State A
01 : State B
11 : ignore
Inventoried state of the target tag population. If 11 is specified,
the reader ignores this field.
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 35]
Internet-Draft SLRRP Aug 2005
S: 2 bits
00 : SL
01 : ~SL
11 : ignore
State of the SL flag in the Tag. If 11 is specified, the reader
ignores this field.
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. An implementation may
also just have the starting Q value and not specify the rest.
3.5.6.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 Feb 15, 2006 [Page 36]
Internet-Draft SLRRP Aug 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) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The filter parameter consists of one filter-spec. For an inventory with
multiple filteres, multiple instances of filter parameters are sent. A
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.
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 37]
Internet-Draft SLRRP Aug 2005
3.5.6.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.
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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: C1G2 Filter Parameters (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: C1G2 RF Parameters (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: C1G2 Singulation Parameters (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: 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 also specify the number of rounds.
It is not necessary that the filter, RF and singulation parameters be
specified in each and every inventory command. They are optional
parameters. In cases where these parameters are fixed during
configuration, the inventory command just specifies (and hence controls)
the time in terms of lifetime of the command, start-time, round size and
number of rounds.
We also allow the flexibility to have the reader operate in an semi-
autonomous manner, where the RNC sends these 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 until a stop
command from RNC.
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 38]
Internet-Draft SLRRP Aug 2005
Inventory Operation Timing Parameter
This is the inventory operation timing parameter defined in 3.5.5.5.
Filter Parameters
This is the filter parameter TLV structure as defined in 3.5.6.1.1.3.
This defines the filter-spec for the N rounds, where N is the number
of rounds as specified in the inventory operation timing parameter.
RF Parameters
This is the RF parameter TLV structure as defined in 3.5.6.1.1.1.
This defines the RF parameters for N rounds.
Singulation Parameters
This is the singulation parameter as defined in 3.5.6.1.1.2. This
defines the singulation parameters for the rounds between the start
and end rounds.
3.5.6.1.2. Access Command
This section presents the parameters pertaining to an access command.
3.5.6.1.2.1. EPC C1G2 Target Tag Parameters
These parameters are sent as 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.6.1.2.2. These parameters
need not have been air protocol specific, however, the tag memory layout
is also being defined in the air protocols. This parameter is similar to
the selection filter parameter described in 3.5.6.1.2.3. However, since
these tags are stored in the reader's memory, and ternary comparisons
are to be allowed for, each bit i in the target tag is represented using
2 bits - bit i in mask, and bit i in tag pattern. If bit i in mask is
zero, the bit i of the target tag is a dont care (X); if the bit i in
mask is one, the bit i of the target tag is the bit i of the tag
pattern.
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 39]
Internet-Draft SLRRP Aug 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 = 0x24 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MB |X X X X X X X X X X X X X X| Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Tag Mask Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Tag Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The target tag parameter consists of a tag-spec, that contains the
following fields:
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
Pointer to the beginning of the pattern to match in memory.
Tag Mask Parameter: Mask pattern to be used
Tag Paramter: Tag pattern to be used
3.5.6.1.2.2. EPC C1G2 Tag Operations Parameters
This parameter is sent as part of the access-spec (section 3.5.6.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.6.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.
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 :
: :
Each operation is defined using an op-spec. The length of the op-spec is
specified as part of the op-spec.
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 40]
Internet-Draft SLRRP Aug 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 | Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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|x x x x x x| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Feb 15, 2006 [Page 41]
Internet-Draft SLRRP Aug 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|x x x| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |x x x x x x x x| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kill Password |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kill Password: 32 bits
Value of the kill password to be used/set.
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 42]
Internet-Draft SLRRP Aug 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 |x x x x x x x x| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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|x x x x x x| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Feb 15, 2006 [Page 43]
Internet-Draft SLRRP Aug 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|x x x x x x| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.6.1.2.3. EPC C1G2 Access Command Parameters
These are parameters specific to access procedures for the 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 Feb 15, 2006 [Page 44]
Internet-Draft SLRRP Aug 2005
3.5.6.2. EPC Class 1 Gen 1 Air Protocol
3.5.6.2.1. Inventory Command
This section presents the parameters pertaining to an inventory command
for the EPC C1G1 air protocol.
3.5.6.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.6.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 Feb 15, 2006 [Page 45]
Internet-Draft SLRRP Aug 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 Feb 15, 2006 [Page 46]
Internet-Draft SLRRP Aug 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.
3.5.6.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
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 47]
Internet-Draft SLRRP Aug 2005
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 x x x x x x x x| Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Tag Mask Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pointer: 16 bits
Pointer to the beginning of the pattern in memory.
Tag Mask Parameter: Mask to be used.
3.5.6.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 (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: C1G1 RF Parameters (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: C1G1 Singulation Parameters (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: 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.
It is not necessary that the filter, RF and singulation parameters be
specified in each and every inventory command. They are optional
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 48]
Internet-Draft SLRRP Aug 2005
parameters. In cases where these parameters are fixed during
configuration, the inventory command just specifies (and hence controls)
the time in terms of lifetime of the command, start-time, round size and
number of rounds.
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 until a stop
command from RNC.
Inventory Operation Timing Parameter
This is the inventory operation timing parameter defined in 3.5.5.5.
Filter Parameters
This is the filter parameter TLV structure as defined in 3.5.6.2.1.3.
This defines the filter-spec for the time-interval defined by the
timing parameter.
RF Parameters
This is the RF parameter TLV structure as defined in 3.5.6.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.6.2.1.2. This
defines the singulation parameters for the duration defined by the
timing parameter.
3.5.6.2.2. Access Command
This section presents the parameters pertaining to an access command.
3.5.6.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.6.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.6.2.2.3.
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 49]
Internet-Draft SLRRP Aug 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 = 0x74 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X X X X X X X X X X X X X X X X| Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Tag Mask Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Tag Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The target tag parameter consists of a tag-spec that contains the
following fields:
Pointer: 16 bits
Pointer to the beginning of the pattern in the tag memory.
Tag Mask Parameter: Mask to be used
Tag Parameter: Tag pattern to be used
Use of Mask and Tag Pattern is similar to C1G2 Target Tag Parameter.
3.5.6.2.2.2. EPC C1G1 Tag Operations Parameters
This parameter is sent as part of the access-spec (section 3.5.6.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.6.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.
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 :
: :
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:
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 50]
Internet-Draft SLRRP Aug 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode | Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 x x x x x x| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
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 | Type|x x x x x| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WordPtr | WriteData |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 3 bits
This determines the data to be written. The data to written at
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 51]
Internet-Draft SLRRP Aug 2005
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 |x x x x x x x x| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kill Password |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kill Password: 32 bits
Value of the kill password to be used/set. Up to 32 bits long.
3.5.6.2.2.3. EPC C1G1 Access Command Parameters
These are parameters specific to access procedures for the 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.7. Inventory and Access Reporting Parameters
This section presents the parameters pertaining to the inventory and
access reporting, that specify when and what to send in the report, and
also the format of the report.
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 52]
Internet-Draft SLRRP Aug 2005
3.5.7.1. Inventory and Access Report Parameter
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.
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 = 0xA1 | Length = 0x8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contents | RFU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trigger Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Contents: 8 bits
The contents of the report.
Contents Description
0x01 Send only inventoried tag list.
0x02 Send only access report.
0x04 Send access report and inventoried tag list.
0x08 Send only RF report.
0x10 Send Access, inventory and RF report.
Trigger Parameter
This parameter defines the event that causes the report to be sent by
the reader to the RNC.
3.5.7.2. Inventory and Access Data Parameter
This parameter defines a TLV that carries the data in the Inventory and
Access report sent from the reader to the RNC.
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 53]
Internet-Draft SLRRP Aug 2005
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|L| Type = 0xA3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Tag Data Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Access Report Data Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: RF Report Data Parameter (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There can be multiple instances of Tag Data Parameter - each instance
carrying one tag's tag ID. If the number of tags is large, the reader
can send over multiple packets. The 'L' bit in this TLV indicates if it
is the last piece of the report. Access report data parameter contains
the results of the access-spec actions that might have taken place -
e.g., successful writes, data from user memory, etc.
3.5.7.3. Tag Data Parameter
This parameter defines a TLV that carries one tag worth of data in the
Inventory and Access report sent from the reader to the RNC.
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 = 0xA4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TimeStamp Microseconds | RSSI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frequency | Tag Seen Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Tag ID :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Timestamp Seconds: 32 bits
Time in seconds at which the tag was read by the reader.
Timestamp microseconds: 24 bits
Time in microseconds to add to the "Timestamp seconds".
RSSI: 8 bits
The receive signal strength of the tag data as recorded by the
reader. If the reader does not support this feature, this field is
zeroed out.
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 54]
Internet-Draft SLRRP Aug 2005
Frequency: 16 bits
The transmit frequency when the tag was read. In case, the tag was
read multiple times, this field has the transmit frequency the last
time the tag was read.
Tag Seen Count: 16 bits
This is the number of times the tag was read since the last report.
Using this field results in smoothing and rate-limiting of the tag
data. For example, if a tag is seen N times during an inventory
round, only instance of the tag data parameter needs to be sent by
the reader with the value of N in this field.
Tag ID
The tag ID data.
3.5.8. Statistics Parameters
TBD.
3.5.9. Operation Error Parameter
This parameter is used in SLRRP for a message sender to report one or
more errors 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 :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 55]
Internet-Draft SLRRP Aug 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.9.1. Unspecified Error
This error cause is used to report an unspecified error by the sender.
There is no cause specific information.
3.5.9.2. Unrecognized Parameter Error
This error cause is used to report an unrecognized parameter. The
unrecognized parameter TLV is included as cause specific information.
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 56]
Internet-Draft SLRRP Aug 2005
3.5.9.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.9.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.9.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 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 Feb 15, 2006 [Page 57]
Internet-Draft SLRRP Aug 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 result 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 Feb 15, 2006 [Page 58]
Internet-Draft SLRRP Aug 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), Peter
Spreadborough (who gave invaluable feedback based on lessons learnt from
implementing SLRRP), and Suresh Bhaskaran (of Intelleflex). We also
Krishna (Editor), et al. Expires Feb 15, 2006 [Page 59]
Internet-Draft SLRRP Aug 2005
acknowledge the comments and feedback received on the IETF SLRRP mailing
list, some of which have been incorporated in the draft.
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 Feb 15, 2006 [Page 60]
Internet-Draft SLRRP Aug 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 Feb 15, 2006 [Page 61]
