ROMA Working Group P. Krishna (Editor) Internet-Draft Reva Systems Corp Expires: May 15, 2005 David J. Husak Reva Systems Corp Oct 2004 Simple Lightweight RFID Reader Protocol draft-krishna-slrrp-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 15, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Radio Frequency Identification (RFID) is a technique whereby a device, known as an RFID 'reader', can remotely sense the presence of, and access embedded memory on, a transponder known as a 'tag'. Tags may be affixed to objects as a means of tracking the location and movement of said objects within facilities equipped with RFID readers. Typically, readers communicate with upstream devices, in this document referred to Krishna (Editor), et al. Expires May 15, 2005 [Page 1] Internet-Draft SLRRP Oct 2004 as 'controllers', to receive control commands and upload read tag information. This draft specifies the Simple Lightweight RFID Reader Protocol, or SLRRP (pronounced 'slurp'), to be used to convey configuration, control, status, and tag information between controllers and readers in an IP- based network. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . . . . 7 1.1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Organization of this document . . . . . . . . . . . . . . . . . 7 1.3. Scope of SLRRP . . . . . . . . . . . . . . . . . . . . . . . . 8 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Overview of RFID Infrastructure . . . . . . . . . . . . . . . . . 8 2.1. Generalized view of the Topology . . . . . . . . . . . . . . . 8 2.2. Communication between the Reader and the Tags . . . . . . . . . 9 2.3. Communication between the Reader Network Controllers and Readers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Protocol Definition . . . . . . . . . . . . . . . . . . . . . . . 12 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. TCP Session Management . . . . . . . . . . . . . . . . . . . . 12 3.2.1. RNC Discovery . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.2. TCP Session Establishment and Authentication . . . . . . . . 12 3.2.3. TCP Session Termination . . . . . . . . . . . . . . . . . . . 13 3.3. SLRRP Message Format . . . . . . . . . . . . . . . . . . . . . 13 3.4. SLRRP Message Types . . . . . . . . . . . . . . . . . . . . . . 15 3.4.1. GET_READER_INFO . . . . . . . . . . . . . . . . . . . . . . . 16 3.4.2. GET_READER_INFO_RESPONSE . . . . . . . . . . . . . . . . . . 17 3.4.3. SET_READER_CONFIG . . . . . . . . . . . . . . . . . . . . . . 18 3.4.4. SET_READER_CONFIG_RESPONSE . . . . . . . . . . . . . . . . . 18 3.4.5. INVENTORY . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.4.6. INVENTORY_RESPONSE . . . . . . . . . . . . . . . . . . . . . 19 3.4.7. STOP_INVENTORY . . . . . . . . . . . . . . . . . . . . . . . 20 3.4.8. STOP_INVENTORY_RESPONSE . . . . . . . . . . . . . . . . . . . 20 3.4.9. ACCESS . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.4.10. ACCESS_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 21 3.4.11. STOP_ACCESS . . . . . . . . . . . . . . . . . . . . . . . . 22 3.4.12. STOP_ACCESS_RESPONSE . . . . . . . . . . . . . . . . . . . . 22 3.4.13. INVENTORY_ACCESS_REPORT . . . . . . . . . . . . . . . . . . 22 3.4.14. READER_STATUS_REPORT . . . . . . . . . . . . . . . . . . . . 23 3.5. SLRRP Parameters . . . . . . . . . . . . . . . . . . . . . . . 23 Krishna (Editor), et al. Expires May 15, 2005 [Page 2] Internet-Draft SLRRP Oct 2004 3.5.1. Identification Parameter . . . . . . . . . . . . . . . . . . 26 3.5.2. Power Parameter . . . . . . . . . . . . . . . . . . . . . . . 27 3.5.3. Reader Device Config Parameter . . . . . . . . . . . . . . . 27 3.5.4. Reader Operational Parameters . . . . . . . . . . . . . . . . 29 3.5.4.1. RF Receiver Parameters . . . . . . . . . . . . . . . . . . 29 3.5.4.2. RF Transmitter Parameters . . . . . . . . . . . . . . . . . 30 3.5.4.3. Frequency Hop Tables Parameters . . . . . . . . . . . . . . 31 3.5.4.4. Fixed Frequency Parameters . . . . . . . . . . . . . . . . 32 3.5.5. Air Protocol Specific Parameters . . . . . . . . . . . . . . 32 3.5.5.1. EPC Class 1 Gen 2 Air Protocol . . . . . . . . . . . . . . 32 3.5.5.1.1. Inventory Command . . . . . . . . . . . . . . . . . . . . 32 3.5.5.1.1.1. EPC Class 1 Gen 2 RF Parameters . . . . . . . . . . . . 32 3.5.5.1.1.2. EPC Class 1 Gen 2 Singulation Parameters . . . . . . . 33 3.5.5.1.1.3. EPC Class 1 Gen 2 Selection Filter Parameters . . . . . 35 3.5.5.1.1.4. EPC Class 1 Gen 2 Protocol Inventory Command Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.5.5.1.2. Access Command . . . . . . . . . . . . . . . . . . . . . 37 3.5.5.1.2.1. EPC Class 1 Gen 2 Target Tag Parameters . . . . . . . . 37 3.5.5.1.2.2. EPC Class 1 Gen 2 Tag Operations Parameters . . . . . . 39 3.5.5.1.2.3. EPC Class 1 Gen 2 Access Command Parameters . . . . . . 43 3.5.6. Tag Data Reporting Parameters . . . . . . . . . . . . . . . . 43 3.5.7. Statistics Parameters . . . . . . . . . . . . . . . . . . . . 43 3.5.8. Operation Error Parameter . . . . . . . . . . . . . . . . . . 43 3.5.8.1. Unspecified Error . . . . . . . . . . . . . . . . . . . . . 44 3.5.8.2. Unrecognized Parameter Error . . . . . . . . . . . . . . . 44 3.5.8.3. Unrecognized Message Error . . . . . . . . . . . . . . . . 45 3.5.8.4. Invalid Values Error . . . . . . . . . . . . . . . . . . . 45 3.5.8.5. Non-unique Antenna Identifier Error . . . . . . . . . . . . 45 3.6. Reader Operating Modes . . . . . . . . . . . . . . . . . . . . 45 3.6.1. Split Transmitter & Receiver Operation . . . . . . . . . . . 45 4. Security Considerations . . . . . . . . . . . . . . . . . . . . . 46 4.1. Threat Types . . . . . . . . . . . . . . . . . . . . . . . . . 46 4.2. Implementing Security Mechanisms . . . . . . . . . . . . . . . 47 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 47 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 47 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Krishna (Editor), et al. Expires May 15, 2005 [Page 3] Internet-Draft SLRRP Oct 2004 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 techno logy 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 May 15, 2005 [Page 4] Internet-Draft SLRRP Oct 2004 controlled and managed. We envision a typical RFID deployment comprising of a network of RFID readers controlled by one or more reader network controller elements (which may be software in a server, embedded software in a router/switch, or a standalone device). These controller elements in turn are connected to hosts/servers running client applications that ultimately consume the acquired tag data and management applications that control and monitor the operation of the reader network. This draft specifies a controller-to-reader protocol (the Simple Lightweight RFID Reader Protocol, or SLRRP (pronounced 'slurp') for use in an IP-based network to convey configuration, control, status, and tag information to and from readers. This protocol has the following characteristics: * Maximizes tag data good-put to client applications; * Allows for efficient implementation on readers; * Supports large numbers of readers in an environment; * Supports authentication and security mechanisms appropriate to a wide range of deployment scenarios. Following are the system functions that are instrumented and controlled through SLRRP and cooperating protocols: 1) Management of a network of readers: * Discovery * Firmware/software configuration * Health monitoring * Connectivity monitoring * Statistics gathering * Configuration and profile management * Managing reader power consumption * Security 2) RF-domain control: * Allocating RF spectrum utilization across readers * RF monitoring including interference detection and measurement * Reader co-monitoring * Controlling air protocol-specific RF parameters such as backscatter modulation and data rates 3) Air protocol control: * Controlling air protocol parameters * Controlling tag access and tag state across readers * Coordinating singulation parameters and/or state across readers * Distributing reader-generated trigger events Krishna (Editor), et al. Expires May 15, 2005 [Page 5] Internet-Draft SLRRP Oct 2004 SLRRP is meant to be generally applicable to readers employing any standard air protocol, including those defined by ISO 18000-6, and EPCglobal 1st and 2nd generation protocols, through the definition of air-protocol-specific modules within SLRRP. | | | | | | High-layer Protocols | | |/ | | | +--------------+ | Reader | | Network | | Controller | +--------------+ | | | SLRRP Control/Signaling |/ & Data (over TCP/IP) | | +------|---------+ +----------------+| +----------------+|| | Readers ||+ | with Antennae |+ +----------------+ | | | Air Protocol |/ | | +----+ +----+ +----+ +----+ |Tags| |Tags| |Tags| |Tags| +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+ |Tags| |Tags| |Tags| |Tags| +----+ +----+ +----+ +----+ Figure 1 Layers Krishna (Editor), et al. Expires May 15, 2005 [Page 6] Internet-Draft SLRRP Oct 2004 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. 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 May 15, 2005 [Page 7] Internet-Draft SLRRP Oct 2004 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 i nterpreted 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-----\ /---- ----\/ / \ / \---RNC---/ \ --Reader--/ \ Tag Client-----| | | | | | |IP Cloud|--RNC--|IP Cloud|--Reader--|RF Cloud| Tag Client-----| | | | | | \ /---RNC---\ /---Reader--\ / Tag Client-----/ \---- ----/\ \ / \ / \--Reader--- \ / Tag \ / -- - - - - - - Tag Figure 2 RFID Infrastructure Krishna (Editor), et al. Expires May 15, 2005 [Page 8] Internet-Draft SLRRP Oct 2004 The consumers of the tag data are the client network elements (e.g., end-user applications). The network elements between the tag and the clients form the conduit to transport tag data over the network to the applications. The elements in the Tag Data Transport Network include tags, readers, and reader network controllers. Depending on the facility size, volume of tag traffic, and client network element requirements, the Tag Data Transport Network will have a multiplicity of readers and reader network controllers. 2.2. Communication between the Reader and the Tags A RFID reader reads the RFID tags in its field of view. The process of reading each tag is accomplished by performing a series of tag collision resolutions (singulation), and then accessing the data storage on the singulated tag. That tag may then be 'set aside' while further singulations are carried out, and the balance of the population is accessed. There are a variety of algorithms used for singulation, which may or may not be dictated by the air protocol in use. Performance of the singulation process may be critical to the success of an RFID system, especially in the context of challenging RF environments, densely- populated or fast-moving tagged objects. The system singulation rate and tag access latency are key performance parameters. It is anticipated that overall system performance may be optimized by the application and tuning the RF, singulation and population-thinning aspects of singulation algorithms within and across readers. It is also the case that tags may vary in data organization and storage capabilities, including, for example, the integration of environmental sensors. The tag may carry a generally-accessible identifier or other capability indicator to allow the system to retrieve this data. Tags may also require cryptographic keys or passwords for the retrieval of data. 2.3. Communication between the Reader Network Controllers and Readers The communication between the reader network controllers (RNCs) and readers includes commands from RNC to the reader, and responses from readers to RNC. The commands can be grouped into tag control commands and reader control commands. A typical timeline of both SLRRP and air protocol interactions between an RNC a reader and a population of tags is depicted in Figure 3, below. Krishna (Editor), et al. Expires May 15, 2005 [Page 9] Internet-Draft SLRRP Oct 2004 The general SLRRP operation consists of a reader configuration phase, followed by one or more ACCESS commands, which parameterize subsequent tag data accesses, followed a series of INVENTORY commands, which actually cause the reading operations to occur, which ultimately produce INVENTORY_ACCESS_REPORTs which carry the tag data to the RNC from the reader. Subsequent ACCESS commands may add to, or subtract from, the set of active access parameters, and may also be used to perform specific tag operations, such as writing, killing, or concealing a tag. INVENTORY commands carry the RF, state and singulation parameters to be used during reader operations subsequent to receipt of the command. INVENTORY commands may be halted or preempted by subsequently received INVENTORY commands. sp 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 May 15, 2005 [Page 10] Internet-Draft SLRRP Oct 2004 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 May 15, 2005 [Page 11] Internet-Draft SLRRP Oct 2004 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 and tag data from readers to RNC. +------------------------------------------------+ | Reader configuration, SLRRP channel | | management, tag data acquisition commands, | | tag data, RF state information. | +------------------------------------------------+ | SLRRP Channel | | (reliable) | +------------------------------------------------+ | 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, Krishna (Editor), et al. Expires May 15, 2005 [Page 12] Internet-Draft SLRRP Oct 2004 authentication MUST be executed over the connection as described in the 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 backup 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|L|x|x|x| Ver | Total Length (Optional) | Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length | Message Seq Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Message Value : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 SLRRP Message Format Compound bit (C) Indicates if this is a compound message. A compound message carries multiple SLRRP messages. Typically this feature is used when RNC sends multiple messages that need to be executed by the reader. The order of messages in the compound message is the order in which the receiving node executes the messages. The C bit is also used by the receiving node to send back multiple responses in the same message. If the C bit is not set, it indicates that only one message is sent. Length bit (L) Indicates if the Total Length field is present or not. 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. Krishna (Editor), et al. Expires May 15, 2005 [Page 13] Internet-Draft SLRRP Oct 2004 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. Total Length: 16 bits Indicates the total length of the message in octets. This is an optional field. It may be useful in simplifying the design of SLRRP receiver state machines especially for compound messages. However, if C=0 (i.e., it is not a compound message), the Total Length field does not add any value more than the Message Length field in the only message carried by the SLRRP message. Message Type: 8 bits Is the type of SLRRP message being carried in the message. In the case of a compound message, there will be multiple messages sent, each with a Message Type. 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 5. Message Seq Num: 16 bits As stated earlier, the communications between the RNC and the reader is primarily of a request-response type - requests/commands from the RNC to the reader, and response from the reader to the RNC. In order to facilitate multiple outstanding commands/requests from RNC, SLRRP uses a Message sequence number in each message. The Message sequence number is used to correspond a response with the original request. This sequence number is local to the SLRRP channel. Message Value: variable length Dependent on the Message Type. Krishna (Editor), et al. Expires May 15, 2005 [Page 14] Internet-Draft SLRRP Oct 2004 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|L|x|x|x| Ver | Total Length (Optional) | Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length | Message Seq Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........... Message Value ............... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .......... | Message Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | ................. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........... Message Value ............... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 SLRRP Message Format Example of a Compound Message (C=1) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|x|x|x| Ver | Message Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | Message Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........... Me ssage Value ............... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........... Message Value ............... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 SLRRP Message Format Example of a Simple Message (C=0) 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 Krishna (Editor), et al. Expires May 15, 2005 [Page 15] Internet-Draft SLRRP Oct 2004 0x02 - GET_READER_INFO_RESPONSE 0x03 - SET_READER_CONFIG 0x04 - SET_READER_CONFIG_RESPONSE 0x10 - INVENTORY 0x11 - INVENTORY_RESPONSE 0x12 - STOP_INVENTORY 0x13 - STOP_INVENTORY_RESPONSE 0x18 - ACCESS 0x19 - ACCESS_RESPONSE 0x1A - STOP_ACCESS 0x1B - STOP_ACCESS_RESPONSE 0x20 - INVENTORY_ACCESS_REPORT 0x21 - READER_STATUS_REPORT 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|x|x|x| Ver | Type= 0x01 | Message Length = 0xB | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | Requested Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requested Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This command is issued by the RNC to get the current configuration information of the reader. Requested Data: 48 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 -------------- ------------- 0x000000 All Parameters 0x000001 Statistics Parameter 0x000002 Identification Parameter 0x000004 Network Interface Parameter 0x000008 Reader Device Config Parameter 0x000010 RF Receiver Parameter 0x000020 RF Transmitter Parameter 0x000040 Tag Data Reporting Parameter Krishna (Editor), et al. Expires May 15, 2005 [Page 16] Internet-Draft SLRRP Oct 2004 0x000080 EPC Class 1 Gen2 RF Parameter Others Reserved 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|x|x|x| Ver | Type= 0x02 | Message Length = Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : Requested Parameters or Operation Error Parameters : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : This is the response by the reader to the GET_READER_INFO command. Krishna (Editor), et al. Expires May 15, 2005 [Page 17] Internet-Draft SLRRP Oct 2004 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|x|x|x| Ver | Type= 0x03 | Message Length = Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : Network Interface Parameter (optional) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : RF Receiver Parameter (optional) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : RF Transmitter Parameter (optional) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Tag Data Reporting Parameter (optional) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Statistics Parameter (optional) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Air Protocol Specific RF Parameter (optional) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This command is issued by the RNC to the reader. This command sets the reader configuration using the parameters specified in this command. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|x|x|x| Ver | Type= 0x04 | Message Length = Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : | 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 0x5. Krishna (Editor), et al. Expires May 15, 2005 [Page 18] Internet-Draft SLRRP Oct 2004 3.4.5. INVENTORY 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|x|x|x| Ver | Type= 0x10 | Message Length = Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | Air Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Air Protocol specific Inventory Command Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This command is issued by the RNC to the reader. This command starts the execution of the inventory command at the reader using the parameters passed in this command. Air Protocol: 16 bits Defines the type of air protocol to be used in the operation. Values are: 0x1 EPCGlobal Class 0 0x2 EPCGlobal Class 1 0x3 EPCGlobal Class 1 Gen2 (C1G2) 0x4 ISO 18006-a 0x5 ISO 18006-b ... Air Protocol specific Inventory command parameter: Variable If C1G2, then this field is the TLV that carries the EPC C1G2 Inventory command parameter (defined in Section 3.5.5.1.1). 3.4.6. INVENTORY_RESPONSE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|x|x|x| Ver | Type= 0x11 | Message Length = Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : 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 Krishna (Editor), et al. Expires May 15, 2005 [Page 19] Internet-Draft SLRRP Oct 2004 length is 0x5. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|x|x|x| Ver | Type= 0x12 | Message Length = 0x5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This command is issued by the RNC to the reader. This command stops the execution of the inventory command at the reader. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|x|x|x| Ver | Type= 0x13 | Message Length = Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : 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 0x5. Else, an appropriate error parameter is sent. Krishna (Editor), et al. Expires May 15, 2005 [Page 20] Internet-Draft SLRRP Oct 2004 3.4.9. ACCESS 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|x|x|x| Ver | Type= 0x18 | Message Length = Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | Air Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Air Protocol specific Access Command Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Air Protocol specific Access command parameter: Variable If C1G2, then this field is the TLV that carries the EPC C1G2 Access command parameter (defined in Section 3.5.5.1.2.3). This command creates a new access-spec at the reader. The reader executes this access-spec till it gets a STOP_ACCESS from the RNC. An access-spec contains a 2-tuple 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. 3.4.10. ACCESS_RESPONSE 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|x|x|x|x|x|x| Type= 0x19 | Message Length = Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | Access ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operation Error Parameter (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This is the response by the reader to an ACCESS command. If the parameters passed in that ACCESS command were successfully accepted and set at the reader, then the reader assigns an ID to the access-spec and returns the ID in this ACCESS_RESPONSE message. However, if the access- spec was not successfully created at the reader, the reader sends a NULL access ID and includes an operation error parameter describing the error in the message. Krishna (Editor), et al. Expires May 15, 2005 [Page 21] Internet-Draft SLRRP Oct 2004 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|x|x|x|x|x|x| Type= 0x1A | Message Length = Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | Access ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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." 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|x|x|x|x|x|x| Type= 0x1B | Message Length = Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : | 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 0x5. 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 +-+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|x|x|x|x|x|x| Type= 0x20 | Message Length = Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : Tag Report Data Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This command is issued by the reader to the RNC. The reader sends the results of the Inventory and Access command. The results are sent back Krishna (Editor), et al. Expires May 15, 2005 [Page 22] Internet-Draft SLRRP Oct 2004 every round - the size of the round is defined in the inventory command. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|x|x|x|x|x|x| Type= 0x21 | Message Length = Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : Reader Status Report Parameter : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This command is issued by the reader asynchronously to the RNC. Status report message may be sent by the reader due to critical events such as reboot, fault-detection in a reader functional block, buffer overflow, or due to the activation of an reader accessory trigger input (e.g. motion detection), or due to performance monitoring events such as abnormalities in RF environment. Reader configuration will determine the maximum frequency and/or pacing of status reports. 3.5. SLRRP Parameters SLRRP Parameters are defined in the following Type-Length-Value (TLV) format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A | User | Parameter Type | Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Parameter Value : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A: 2 bits The two bits specify the action that must be taken if the processing endpoint does not recognize the Parameter Type. 00 - Stop processing this SLRRP message and discard it, do not process any further parameters within it. Krishna (Editor), et al. Expires May 15, 2005 [Page 23] Internet-Draft SLRRP Oct 2004 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 0x2 - Power Parameter 0x3 - Reader Device Config 0x4 - Reader Operating State 0x10 - RF Receiver 0x11 - RF Transmitter 0x12 - Frequency Hop Tables 0x13 - Fixed Frequency Table 0x20 - EPC Class 1 Gen 2 RF Parameters 0x21 - EPC Class 1 Gen 2 Singulation Parameters 0x22 - EPC Class 1 Gen 2 Filter Parameters 0x23 - EPC Class 1 Gen 2 Inventory Command 0x24 - EPC Class 1 Gen 2 Target Tag Parameters 0x25 - EPC Class 1 Gen 2 Tag Operation Parameters 0x26 - EPC Class 1 Gen 2 Access Command Krishna (Editor), et al. Expires May 15, 2005 [Page 24] Internet-Draft SLRRP Oct 2004 0x30 - ISO 18006a RF Parameters 0x31 - ISO 18006a Singulation Parameters 0x32 - ISO 18006a Filter Parameters 0x33 - ISO 18006a Inventory Command 0x34 - ISO 18006a Target Tag Parameters 0x35 - ISO 18006a Tag Operation Parameters 0x36 - ISO 18006a Access command 0x40 - ISO 18006b RF Parameters 0x41 - ISO 18006b Singulation Parameters 0x42 - ISO 18006b Filter Parameters 0x43 - ISO 18006b Inventory Command 0x44 - ISO 18006b Target Tag Parameters 0x45 - ISO 18006b Tag Operation Parameters 0x46 - ISO 18006b Access command 0x50 - ISO 18006c RF Parameters 0x51 - ISO 18006c Singulation Parameters 0x52 - ISO 18006c Filter Parameters 0x53 - ISO 18006c Inventory Command 0x54 - ISO 18006c Target Tag Parameters 0x55 - ISO 18006c Tag Operation Parameters 0x56 - ISO 18006c Access command 0x60 - EPC Class 0 RF Parameters 0x61 - EPC Class 0 Singulation Parameters 0x62 - EPC Class 0 Filter Parameters 0x63 - EPC Class 0 Inventory Command 0x64 - EPC Class 0 Target Tag Parameters 0x65 - EPC Class 0 Tag Operation Parameters 0x66 - EPC Class 0 Access command 0x70 - EPC Class 1 RF Parameters 0x71 - EPC Class 1 Singulation Parameters 0x72 - EPC Class 1 Filter Parameters 0x73 - EPC Class 1 Inventory Command 0x74 - EPC Class 1 Target Tag Parameters 0x75 - EPC Class 1 Tag Operation Parameters 0x76 - EPC Class 1 Access command 0x90 - Operation Error Parameter 0xA0 - Tag Data Reporting 0xA1 - Statistics others - (reserved by IETF) Krishna (Editor), et al. Expires May 15, 2005 [Page 25] Internet-Draft SLRRP Oct 2004 Parameter Length: 16 bits The Parameter Length field contains the size of the parameter in bytes, including the Parameter Type, Parameter Length, and Parameter Value fields. Thus, a parameter with a zero-length Parameter Value field would have a Length field of 4. Parameter Value: variable-length The Parameter Value field contains the actual information to be transferred in the parameter. 3.5.1. Identification Parameter This parameter defines a TLV that carries an identification parameter that is unique within the scope of the Tag Data Transport Network. The identifier could be the reader MAC address, serial number, or EPC, but the specific convention for readers in a Tag Data Transport Network MUST be known so that uniqueness can be guaranteed. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A | IDType| Type = 0x1 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reader ID [0:31] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reader ID [32:63] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Reader ID [64:96] : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : ID Type: 4 bits Type of the ID used to identify the reader. IDType ID 0x0 MAC address 0x1 EPC 0x2 Other Numbering (Binary) 0x3 ASCII String Length: 16 bits Length of the ID (bytes) Reader ID: Variable Contains the OID of the reader. Krishna (Editor), et al. Expires May 15, 2005 [Page 26] Internet-Draft SLRRP Oct 2004 3.5.2. Network Interface Parameters Certain reader devices may be powered using Power-over-Ethernet (PoE, 802.3af). This parameter defines a TLV that enables the reader to report its power requirements. The RNC device may or may not be the power source to the PoE reader. This TLV carries information regarding the power requirements of the reader in different operating modes. This allows the RNC device to monitor and manage the power budgets of a reader network when manipulating the readers to ensure that the total power budget for the PoE port is not exceeded. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A |x x x x| Type = 0x2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mode |x x x x x x x x x x x x| Power Requirement | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mode |x x x x x x x x x x x x| Power Requirement | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : Mode: 4 bits Operating mode of the reader. 0x0: Standby mode (TX Power = OFF, RX = OFF) 0x1: RX Only (TX Power = OFF, RX = ON) 0x2: Full Power (TX Power = FULL, RX = ON) 0x3: Half Power (TX Power = HALF, RX = ON) Additional modes may be defined later. Power Requirement: 16 bits This contains the power requirement in Watts*10. 3.5.3. Reader Device Config Parameter This parameter defines the TLV that carries the configuration information of the reader: Krishna (Editor), et al. Expires May 15, 2005 [Page 27] Internet-Draft SLRRP Oct 2004 - Number of antennas - Types of antennas - Capabilities of the reader device - Frequency hop table parameters - Fixed frequency 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 |x x x x| Type = 0x3 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x x x x x x x x| #of Antennas |x x x x x x x x x x x x x x x x| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Antenna ID | AntennaType | Antenna Gain | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Antenna ID | AntennaType | Antenna Gain | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : . . . . : . . . . : . . . . : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reader Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Frequency Hop Tables Parameters : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Fixed Frequency Parameters : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Antenna ID: 8 bits ID of the antenna. Antenna Type Type of antenna. Values are: 0x1 : Vertical Polarization 0x2 : Horizontal Polarization 0x3 : Circular Polarization Antenna Gain: 16 bits Boresight gain of the antenna. Reader Capabilities Each bit reflects the ability of the reader pertaining to that capability. Krishna (Editor), et al. Expires May 15, 2005 [Page 28] Internet-Draft SLRRP Oct 2004 0x1 : Control Power 0x2 : Independent Rx and Tx control 0x4 : Write tag 0x8 : Kill tag Frequency hop table parameters Specified in 3.5.4.3. Fixed frequency parameters Specified in 3.5.4.4. 3.5.4. Reader Operational Parameters 3.5.4.1. RF Receiver Parameters This parameter defines a TLV that carries the RF receiver parameters. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A |User |S| Type = 0x10 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Antenna ID | Sensitivity |x x x x x x x x x x x x x x x x| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ User: 3 bits User defined bits. S: Receiver state bit ON or OFF. Antenna ID: 8 bits ID of the antenna. Receiver Sensitivity: 8 bits Receive sensitivity threshold. Krishna (Editor), et al. Expires May 15, 2005 [Page 29] Internet-Draft SLRRP Oct 2004 3.5.4.2. RF Transmitter Parameters This parameter defines a TLV that carries the RF transmitter parameters. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A |User |S| Type = 0x11 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Antenna ID |Transmit Power | FHSeqID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ User: 3 bits User defined bits. S: Transmitter state bit ON or OFF Antenna ID: 8 bits ID of the antenna. Transmit Power: 8 bits Transmit power level FHSeqID: 8 bits This is the index of the hop table to be used by the reader. Krishna (Editor), et al. Expires May 15, 2005 [Page 30] Internet-Draft SLRRP Oct 2004 3.5.4.3. Frequency Hop Tables Parameters This parameter defines a TLV that carries the frequency hop table 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 = 0x12 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x x x x x x x x| #FHSeq | FHSeqID | #of hops | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frequency 1 | Frequency 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frequency N-1 | Frequency N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FHSeqID | #of Hops | Frequency 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Frequency 2 | Frequency 3 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ #FHSeq: 8 bits This is the number of frequency hop tables maintained at the reader. FHSeqID: 8 bits This is the index of the current hop table being used by the reader. #of hops: 8bits The number of hops in this hop table. This is followed by the listing of the frequencies in order for the table. Index 0 for this table has frequency 1, index 1 has frequency 2, and so and so forth. Krishna (Editor), et al. Expires May 15, 2005 [Page 31] Internet-Draft SLRRP Oct 2004 3.5.4.4. Fixed Frequency Parameters This parameter defines a TLV that carries the fixed frequency parameter. It lists the frequencies that can be used by the reader. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A |User |S| Type = 0x13 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x x x x x x x x x x x x x x x x x x x x x x x x| #of Freqs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frequency 1 | Frequency 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frequency N-1 | Frequency N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.5.5. Air Protocol Specific Parameters 3.5.5.1. EPC Class 1 Gen 2 Air Protocol 3.5.5.1.1. Inventory Command This section presents the parameters pertaining to an inventory command. 3.5.5.1.1.1. EPC Class 1 Gen 2 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. Krishna (Editor), et al. Expires May 15, 2005 [Page 32] Internet-Draft SLRRP Oct 2004 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 frequency determines the reverse link rate. TRCal: 5 bits The Tag->reader calibration symbol length. The reverse link frequency is computed using TRCal and DR (divide ratio). DR: 1 bit Divide ratio to use - only two values have been specified - 64/3 and 8. 3.5.5.1.1.2. EPC Class 1 Gen 2 Singulation Parameters These are singulation parameters that are particular to C1G2 air protocol. The singulation protocol employs the Q algorithm. The Q algorithm specifies how the value of Q is updated during the interrogation round. The goal is to maximize the tag acquisition rate given a target singulation environment. A target singulation environment depends on (a) mobility of the tag, (b) tag population, and (c) RF environment. The optimal choice of a Q-manipulation algorithm depends on the target environment. Using this singulation parameter TLV, we provide the flexibility in the reader protocol to either specify the Q-manipulation algorithm to use in a particular round, or just specify the parameter-set that describes the target singulation environment. Krishna (Editor), et al. Expires May 15, 2005 [Page 33] Internet-Draft SLRRP Oct 2004 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A | User | Type = 0x21 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x x|Sess#|I|S|M| Mob | Pop | Env | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm Description | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sess#: 4 bits The session number to use at the tags. I: 1 bit Inventoried state of the target tag population: A or B. S: 1 bit SL or ~SL tags 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. Krishna (Editor), et al. Expires May 15, 2005 [Page 34] Internet-Draft SLRRP Oct 2004 3.5.5.1.1.3. EPC Class 1 Gen 2 Selection 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. 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 = 0x2 2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|T| Action|MB | Pointer | MaskLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Mask (up to 255 bits long) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|T| Action|MB | Pointer | MaskLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Mask (up to 255 bits long) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The filter parameter consists of one or more filter-specs. Each filter spec contains the following fields: T: 1 bit Truncate bit. This is set if the RNC is interested in only a truncated portion of the tag to be backscattered by the tag. The portion that gets backscattered includes the portion of the tag ID following the mask. This bit has to be set only in the last filter- spec. Action: 4 bits This describes the action for matching and non-matching tags - e.g., do nothing, assert or deassert SL, assign inventoried S0/S1/S2/S3 to A or B. MB: 2 bits The tag memory bank. Pointer: 16 bits EBV encoding of the pointer to the beginning of the pattern in memory. MaskLength: 8 bits Length of the mask. Krishna (Editor), et al. Expires May 15, 2005 [Page 35] Internet-Draft SLRRP Oct 2004 Mask: up to 255 bits Mask to be used. 3.5.5.1.1.4. EPC Class 1 Gen 2 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Round # | End Round # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Round Size (Time) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Selection Filter Parameters : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : RF Parameters : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Singulation Parameters : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Start Round # | End Round # : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Round Size (Time) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : In the EPC Gen2 protocol, inventory is done in terms of rounds. Using the above TLV, we provide the capability to define parameters for each round. In order to support the scenario where there are multiple rounds that use the same parameters, we use start and end round numbers. We also allow the flexibility to have the reader operate in an semi- autonomous manner, where the RNC sends this inventory command parameters and the reader inventories continuously till it gets a stop command from RNC. This is done by specifying the lifetime of the inventory command parameters (L bit). L: 1 bit L=0: Execute this command set once. L=1: Repeat this sequence of inventory commands forever till a stop command from RNC. Krishna (Editor), et al. Expires May 15, 2005 [Page 36] Internet-Draft SLRRP Oct 2004 Start Round#: 16 bits The starting round number where the parameters are to be used. End Round#: 16 bits The ending round number up to which the parameters are to be used. Round Size: 32 bits This basically determines the size of each round. The units of time is microseconds. Selection Filter Parameters This is the selection filter parameter TLV structure as defined in 3.5.5.1.1.3. This defines the filter-spec for the rounds between the start and end rounds. RF Parameters This is the RF parameter TLV structure as defined in 3.5.5.1.1.1. This defines the RF parameters for the rounds between the start and end rounds. Singulation Parameters This is the singulation parameter as defined in 3.5.5.1.1.2. This defines the singulation parameters for the rounds between the start and end rounds. 3.5.5.1.2. Access Command This section presents the parameters pertaining to an access command. 3.5.5.1.2.1. EPC Class 1 Gen 2 Target Tag Parameters These parameters are sent part of the access command. They describe the target tag population on which certain operations have to be performed. Operations are described in 3.5.5.1.2.2. These parameters need not have been air protocol specific, however, the tag memory layout are also being defined in the air protocols. This parameter is similar to the selection filter parameters described in 3.5.5.1.2.3. Krishna (Editor), et al. Expires May 15, 2005 [Page 37] Internet-Draft SLRRP Oct 2004 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A | User | Type = 0x24 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BoolOper |MB | Pointer | MaskLength : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Mask (up to 255 bits long) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : The target tag parameter consists of one or more tag-specs. Each tag spec contains the following fields: BoolOper: 6 bits Each tag-spec specifies the boolOper to be used when including this tag-spec. 0x1 : OR 0x2 : AND 0x3 : XOR 0x4 : NOR 0x5 : NAND 0x6 : XNOR For example, if the tag parameter block had only one tag-spec. Suppose, the tag-spec has a mask value of 0x1111, mask length of 16 and the BoolOper of 0x4, the final target-tag-filter to be used for this access-spec is 0xffff NOR 0x1111 = 0xeeee. Let us suppose, if the tag parameter block had two tag-specs. BoolOper = 0x4, MB = 0, Pointer = 0, MaskLen = 16, Mask = 0x1111 BoolOper = 0x1, MB = 0, Pointer = 0, MaskLen = 16, Mask = 0x3333 All tags matching 0xeeee and 0x3333 will be operated on using this access-spec. MB: 2 bits The tag memory bank. This tells the reader which portion of the memory is the tag-spec interested in. There are 4 banks defined in the C1G2 spec - user, EPC, TID and reserved. Pointer: 16 bits EBV encoding of the pointer to the beginning of the pattern in memory. Krishna (Editor), et al. Expires May 15, 2005 [Page 38] Internet-Draft SLRRP Oct 2004 MaskLength: 8 bits Length of the mask. Mask: up to 255 bits Mask to be used. 3.5.5.1.2.2. EPC Class 1 Gen 2 Tag Operations Parameters 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A | User | Type = 0x25 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Op-specs : : : This parameter is sent as part of the access-spec (section 3.5.5.1.2.3) in the access command. There can be one or more operations performed on a tag. This parameter describes the set of operations to be performed on a tag that matches the target tag-spec (section 3.5.5.1.2.1). The key point to note is that the ordering of the operations in this parameter is the exact order in which the reader performs these operations on the tag. Each operation is defined using an op-spec each 8 bytes long. Only the block write op-spec may be more 8 bytes long. The length of that op-spec is specified as part of the op-spec. Each op-spec has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpCode | | +-+-+-+-+-+-+-+-+ | | Operation-Specific Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OpCode Operation 0x0 Undefined 0x1 Read 0x2 Write 0x3 Kill 0x4 Lock 0x5 Block Erase 0x6 Block Write Krishna (Editor), et al. Expires May 15, 2005 [Page 39] Internet-Draft SLRRP Oct 2004 Following are the op-specs for the different access operations: Read Op-spec ------------ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpCode = 0x1 | MB| RFU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WordPtr | Word Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MB: 2 bits Memory bank RFU: 22 bits Reserved for future use. WordPtr: 16 bits Starting word address. Word Count: 16 bits Number of 16-bit words to be read. Write Op-spec ------------- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpCode = 0x2 | MB| Type| RFU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WordPtr | WriteData | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MB: 2bits Memory bank Type: 3 bits This determines the data to be written. The data to written at the target Location could either be the WriteData (passed in this op-spec), or could be data that is present at the reader (e.g., current time, sensor data). 000: Write WriteData. 001: Write timestamp 010: Write sensor data. Krishna (Editor), et al. Expires May 15, 2005 [Page 40] Internet-Draft SLRRP Oct 2004 WriteData: 16 bits Data to be written to the tag. Kill Op-spec ------------ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpCode = 0x3 | RFU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kill Password | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Kill Password: 32 bits Value of the kill password to be used/set. Lock Op-spec ------------ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpCode = 0x4 | RFU | Lock Command Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Access Password | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lock Command Payload: 20 bits First 10 bits are the mask bits, and the last 10 bits are action bits. They basically describe the access privilege updates (read/write/permalock) to be performed in various locations of the memory. The five data fields for which we can define access control using the lock command are: Kill password, access password, EPC memory, TID memory and User memory. Access Password: 32 bits A reader can perform lock operation on a tag only if the tag is in "secured" state. The tag enters secured state only using the Access password (if a non-zero value). Krishna (Editor), et al. Expires May 15, 2005 [Page 41] Internet-Draft SLRRP Oct 2004 BlockErase Op-spec ------------------ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpCode = 0x5 | MB| RFU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WordPtr | WordCount | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MB: 2 bits Memory bank WordPtr : 16 bits Start word address for the block erase. WordCount : 16 bits Number of 16-bit words to be erased. BlockWrite Op-spec ------------------ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpCode = 0x6 | MB| RFU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WordPtr | WordCount | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : WriteData : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MB: 2 bits Memory bank WordPtr: 16 bits Start word address for the block write. WordCount: 16 bits Number of 16-bit words to be written. WriteData: Variable Shall be a 16 x WordCount bits in length. Krishna (Editor), et al. Expires May 15, 2005 [Page 42] Internet-Draft SLRRP Oct 2004 3.5.5.1.2.3. EPC Class 1 Gen 2 Access Command Parameters These are parameters specific to access procedures for EPC C1G2 air protocol. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A | User | Type = 0x26 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : EPC C1G2 Target Tag Parameters : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : EPC C1G2 Tag Operations Parameters : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.5.6. Tag Data Reporting Parameters This parameter defines a TLV that carries the Tag data reporting parameters. TBD. 3.5.7. Statistics Parameters TBD. 3.5.8. Operation Error Parameter This parameter is used in SLRRP for a message sender to report an error(s) to a message receiver. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x90 | Length=variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : one or more Error Causes : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 May 15, 2005 [Page 43] Internet-Draft SLRRP Oct 2004 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Cause-specific Information : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Cause Code: 16 bits (unsigned integer) Defines the type of error condition being reported. Cause Code Value Cause Code --------- ---------------- 0 Unspecified Error 1 Unrecognized Parameter 2 Unrecognized Message 3 Invalid Values 4 Non-unique Antenna Identifier other values Reserved by IETF Cause Length: 16 bits (unsigned integer) Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields. Cause-specific Information: variable length This field carries the details of the error condition. The following subsections define specific error causes. 3.5.8.1. Unspecified Error This error cause is used to report an unspecified error by the sender. There is no cause specific information. 3.5.8.2. Unrecognized Parameter Error This error cause is used to report an unrecognized parameter. The unrecognized parameter TLV is included as cause specific information. Krishna (Editor), et al. Expires May 15, 2005 [Page 44] Internet-Draft SLRRP Oct 2004 3.5.8.3. Unrecognized Message Error This error cause is used to report an unrecognized message. The unrecognized message TLV is included as cause specific information. 3.5.8.4. Invalid Values Error This error cause is used to report one or more invalid values found in a received parameter. The offending TLV that contains the invalid value(s) is included as cause specific information. 3.5.8.5. Non-unique Antenna Identifier Error This error cause is used by a Reader to indicate to a RNC that the antenna identifier it chose the reader has already been used by another antenna in the reader. There is no cause specific information. 3.6. Reader Operating Modes In this section, we will list the various reader operating modes possible using SLRRP protocol messages. 3.6.1. Split Transmitter & Receiver Operation +-------+-------+--------------+ | Rx | Tx | Mode | | State | State | | +-------+-------+--------------+ | 0 | 0 |Antenna is OFF| +-------+-------+--------------+ | 0 | 1 | Tx ON only | +-------+-------+--------------+ | 1 | 0 | RF ON only | +-------+-------+--------------+ | 1 | 1 | Normal | +-------+-------+--------------+ Krishna (Editor), et al. Expires May 15, 2005 [Page 45] Internet-Draft SLRRP Oct 2004 4. Security Considerations 4.1. Threat Types Threats to the system are enumerated below. It is possible that certain environments will not perceive all of the following as threats and will, therefore, not implement all of the solutions presented. 4.1.1. Security Threat 1 Threat: Reader registration/deregistration flooding or spoofing Security mechanism in response: Reader Network Controller authenticates the Reader 4.1.2. Security Threat 2 Threat: Reader registers with a malicious Reader Network Controller Security mechanism in response: Reader authenticates the Reader Network Controller Threats 1 and 2 taken together results in mutual authentication of the Reader Network Controller and the Reader. 4.1.3. Security Threat 3 Threat: Replay attack Security mechanism in response: Security protocol which has protection from replay attacks 4.1.4. Security Threat 4 Threat: Corrupted data which causes a Reader or Reader Network Controller to receive misinformation during command or response communication Security mechanism in response: Security protocol which supports integrity protection Krishna (Editor), et al. Expires May 15, 2005 [Page 46] Internet-Draft SLRRP Oct 2004 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 internet-draft formatting) and Scott Barvick. Krishna (Editor), et al. Expires May 15, 2005 [Page 47] Internet-Draft SLRRP Oct 2004 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 May 15, 2005 [Page 48] Internet-Draft SLRRP Oct 2004 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 May 15, 2005 [Page 49]