From mailman-bounces@ietf.org Sat Jan 1 05:22:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05863 for ; Sat, 1 Jan 2005 05:22:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ckgau-0006Vq-GI for rfid-archive@ietf.org; Sat, 01 Jan 2005 05:34:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ckg5H-00025d-U4 for rfid-archive@ietf.org; Sat, 01 Jan 2005 05:02:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: lists.ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: rfid-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sat, 01 Jan 2005 05:00:34 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your lists.ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@lists.ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@lists.ietf.org. Thanks! Passwords for rfid-archive@ietf.org: List Password // URL ---- -------- rfid@lists.ietf.org uvudec https://www1.ietf.org/mailman/options/rfid/rfid-archive%40ietf.org From rfid-bounces@ietf.org Tue Jan 11 15:22:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23492; Tue, 11 Jan 2005 15:22:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoSlA-0005nS-7E; Tue, 11 Jan 2005 15:37:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoSVk-0008H3-Vn; Tue, 11 Jan 2005 15:21:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoSM4-0007pq-9U for rfid@megatron.ietf.org; Tue, 11 Jan 2005 15:11:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22138 for ; Tue, 11 Jan 2005 15:11:02 -0500 (EST) Received: from charles.revasystems.com ([65.209.89.90]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoSZs-0005XE-Nz for rfid@ietf.org; Tue, 11 Jan 2005 15:25:24 -0500 Received: from [192.168.1.44] (indus [192.168.1.44]) by charles.revasystems.com (Postfix) with ESMTP id 4A7883BE7C for ; Tue, 11 Jan 2005 15:10:29 -0500 (EST) From: "P. Krishna" To: rfid@ietf.org Content-Type: multipart/mixed; boundary="=-ty60tfzq2hvcwdON3Rt3" Message-Id: <1105474229.2160.0.camel@indus.revasystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 11 Jan 2005 15:10:29 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: a2f8b5c13cb50b767f4d1ce8eae32ade X-Mailman-Approved-At: Tue, 11 Jan 2005 15:21:03 -0500 Subject: [Rfid] C1G1 support added X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9735b516e8159ed41d62dc4143ea3afd --=-ty60tfzq2hvcwdON3Rt3 Content-Type: text/plain Content-Transfer-Encoding: 7bit Folks, Attached is the updated SLRRP draft. I've added support for the EPCGlobal Class 1 Gen1 protocol. It is captured in Section 3.5.5.2. Looking forward to comments. Thanks, Krishna --=-ty60tfzq2hvcwdON3Rt3 Content-Disposition: attachment; filename=draft-krishna-slrrp-00.txt Content-Type: text/plain; name=draft-krishna-slrrp-00.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 C1G2 RF Parameters . . . . . . . . . . . . . . . 32 3.5.5.1.1.2. EPC C1G2 Singulation Parameters . . . . . . . . . . 33 3.5.5.1.1.3. EPC C1G2 Filter Parameters . . . . . . . . . . . . . 35 3.5.5.1.1.4. EPC C1G2 Protocol Inventory Command Parameters . . . 36 3.5.5.1.2. Access Command . . . . . . . . . . . . . . . . . . . . 37 3.5.5.1.2.1. EPC C1G2 Target Tag Parameters . . . . . . . . . . . 37 3.5.5.1.2.2. EPC C1G2 Tag Operations Parameters . . . . . . . . . 39 3.5.5.1.2.3. EPC C1G2 Access Command Parameters . . . . . . . . . 43 3.5.5.2. EPC Class 1 Gen 1 Air Protocol . . . . . . . . . . . . . 43 3.5.5.2.1. Inventory Command . . . . . . . . . . . . . . . . . . 43 3.5.5.2.1.1. EPC C1G1 RF Parameters . . . . . . . . . . . . . . . 43 3.5.5.2.1.2. EPC C1G1 Singulation Parameters . . . . . . . . . . 44 3.5.5.2.1.3. EPC C1G1 Filter Parameters . . . . . . . . . . . . . 46 3.5.5.2.1.4. EPC C1G1 Protocol Inventory Command Parameters . . . 46 3.5.5.2.2. Access Command . . . . . . . . . . . . . . . . . . . . 48 3.5.5.2.2.1. EPC C1G1 Target Tag Parameters . . . . . . . . . . . 48 3.5.5.2.2.2. EPC C1G1 Tag Operations Parameters . . . . . . . . . 49 3.5.6. Tag Data Reporting Parameters . . . . . . . . . . . . . . 52 3.5.7. Statistics Parameters . . . . . . . . . . . . . . . . . . 52 3.5.8. Operation Error Parameter . . . . . . . . . . . . . . . . 52 3.5.8.1. Unspecified Error . . . . . . . . . . . . . . . . . . . 53 3.5.8.2. Unrecognized Parameter Error . . . . . . . . . . . . . . 54 3.5.8.3. Unrecognized Message Error . . . . . . . . . . . . . . . 54 3.5.8.4. Invalid Values Error . . . . . . . . . . . . . . . . . . 54 3.5.8.5. Non-unique Antenna Identifier Error . . . . . . . . . . 54 3.6. Reader Operating Modes . . . . . . . . . . . . . . . . . . . 54 3.6.1. Split Transmitter & Receiver Operation . . . . . . . . . . 54 4. Security Considerations . . . . . . . . . . . . . . . . . . . 55 4.1. Threat Types . . . . . . . . . . . . . . . . . . . . . . . . 55 4.2. Implementing Security Mechanisms . . . . . . . . . . . . . . 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Krishna (Editor), et al. Expires 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 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 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 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-----\ /---- ----\/ / \ / \---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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ........... Message 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 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 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 Gen 1 RF Parameters 0x71 - EPC C1G1 Singulation Parameters 0x72 - EPC C1G1 Filter Parameters 0x73 - EPC C1G1 Inventory Command 0x74 - EPC C1G1 Target Tag Parameters 0x75 - EPC C1G1 Tag Operation Parameters 0x76 - EPC C1G1 Access command 0x90 - Operation Error Parameter 0xA0 - 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 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. 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 C1G2 Singulation Parameters These are singulation parameters that are particular to C1G2 air protocol. The singulation protocol employs the Q algorithm. The Q algorithm specifies how the value of Q is updated during the interrogation round. The goal is to maximize the tag acquisition rate given a target singulation environment. A target singulation environment depends on (a) mobility of the tag, (b) tag population, and (c) RF environment. The optimal choice of a Q-manipulation algorithm depends on the target environment. Using this singulation parameter TLV, we provide the flexibility in the reader protocol to either specify the Q-manipulation algorithm to use in a particular round, or just specify the parameter-set that describes the target singulation environment. 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 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. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A | User | Type = 0x22 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|T| Action|MB | Pointer | MaskLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Mask (up to 255 bits long) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|T| Action|MB | Pointer | MaskLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Mask (up to 255 bits long) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The filter parameter consists of one or more filter-specs. Each filter spec contains the following fields: T: 1 bit Truncate bit. This is set if the RNC is interested in only a truncated portion of the tag to be backscattered by the tag. The portion that gets backscattered includes the portion of the tag ID following the mask. This bit has to be set only in the last filter- spec. Action: 4 bits This describes the action for matching and non-matching tags - e.g., do nothing, assert or deassert SL, assign inventoried S0/S1/S2/S3 to A or B. MB: 2 bits The tag memory bank. Pointer: 16 bits EBV encoding of the pointer to the beginning of the pattern in memory. MaskLength: 8 bits Length of the mask. 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 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 C1G2 Target Tag Parameters These parameters are sent part of the access command. They describe the target tag population on which certain operations have to be performed. Operations are described in 3.5.5.1.2.2. These parameters need not have been air protocol specific, however, the tag memory layout are also being defined in the air protocols. This parameter is similar to the selection filter parameters described in 3.5.5.1.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 C1G2 Tag Operations Parameters 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A | User | Type = 0x25 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Op-specs : : : This parameter is sent as part of the access-spec (section 3.5.5.1.2.3) in the access command. There can be one or more operations performed on a tag. This parameter describes the set of operations to be performed on a tag that matches the target tag-spec (section 3.5.5.1.2.1). The key point to note is that the ordering of the operations in this parameter is the exact order in which the reader performs these operations on the tag. Each operation is defined using an op-spec each 8 bytes long. Only the block write op-spec may be more 8 bytes long. The length of that op-spec is specified as part of the op-spec. 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 C1G2 Access Command Parameters These are parameters specific to access procedures for EPC C1G2 air protocol. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A | User | Type = 0x26 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : EPC C1G2 Target Tag Parameters : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : EPC C1G2 Tag Operations Parameters : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.5.5.2. EPC Class 1 Gen 1 Air Protocol 3.5.5.2.1. Inventory Command This section presents the parameters pertaining to an inventory command for EPC C1G1 air protocol. 3.5.5.2.1.1. EPC C1G1 RF Parameters These are RF control parameters that are specific to C1G1 air protocol. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A | User | Type = 0x70 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fwd Link|M| RFU | | Rate | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fwd Link Rate: 5 bits This specifies the link rate from the reader to the tag. The reverse link rate is a factor of the forward link rate. M: 1 bit This is the reader data modulation. The standard specifies 2 alternatives - M = 0: Standard: Tdata0 = 1/8th of T0 (master clock interval), Tdata1 - 3/8th of T0. M = 1: Alternative: Tdata0 = 1/4th of T0, and Tdata1 = 1/2 of T0. Krishna (Editor), et al. Expires May 15, 2005 [Page 43] Internet-Draft SLRRP Oct 2004 3.5.5.2.1.2. EPC C1G1 Singulation Parameters These are singulation parameters that are particular to the C1G1 air protocol. The singulation protocol employs a set of commands that performs a tree-traveral. 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 lgorithm 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 = 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. Krishna (Editor), et al. Expires May 15, 2005 [Page 44] Internet-Draft SLRRP Oct 2004 Tree Traversal Algorithm: 32 bits Description of the tree traveral 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 , 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. 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 . This command basically divides the tags in the field of view that matches 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. Couple of examples of command combinations are presented as follows. Krishna (Editor), et al. Expires May 15, 2005 [Page 45] Internet-Draft SLRRP Oct 2004 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 commands, where T,S >= 1. 3.5.5.2.1.3. EPC C1G1 Filter Parameters These are parameters specific to C1G1 tag filter mask to be used during singulation and are sent with each inventory command from the RNC to the reader. This sets up the starting point in the tree during the singulation. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A | User | Type = 0x22 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x x x x x x x x| Pointer | MaskLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mask (up to 96 bits long) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pointer: 16 bits Pointer to the beginning of the pattern in memory. MaskLength: 8 bits Length of the mask. Mask: up to 96 bits Mask to be used. 3.5.5.2.1.4. EPC C1G1 Protocol Inventory Command Parameters These are parameters specific to C1G1 inventory protocol, and are sent with each inventory command from the RNC to the reader. Krishna (Editor), et al. Expires May 15, 2005 [Page 46] 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 |L| User| Type = 0x23 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Start Round # | End Round # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Round Size (Time) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Filter Parameters : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : RF Parameters : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Singulation Parameters : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Start Round # | End Round # : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Round Size (Time) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : 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. 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. Krishna (Editor), et al. Expires May 15, 2005 [Page 47] Internet-Draft SLRRP Oct 2004 Filter Parameters This is the filter parameter TLV structure as defined in 3.5.5.2.1.3. This defines the filter-spec for the rounds between the start and end rounds. RF Parameters This is the RF parameter TLV structure as defined in 3.5.5.2.1.1. This defines the RF parameters for the rounds between the start and end rounds. Singulation Parameters This is the singulation parameter as defined in 3.5.5.2.1.2. This defines the singulation parameters for the rounds between the start and end rounds. 3.5.5.2.2. Access Command This section presents the parameters pertaining to an access command. 3.5.5.2.2.1. EPC C1G1 Target Tag Parameters These parameters are sent part of the access command. They describe the target tag population on which certain operations have to be performed. Operations are described in 3.5.5.2.2.2. These parameters need not have been air protocol specific, however, the tag memory layout are also being defined in the air protocols. This parameter is similar to the selection filter parameters described in 3.5.5.2.2.3. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A | User | Type = 0x24 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BoolOper |MB | Pointer | MaskLength : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Mask (up to 96 bits long) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : The target tag parameter consists of one or more tag-specs. Each tag spec contains the following fields: BoolOper: 6 bits Each tag-spec specifies the boolOper to be used when including this tag-spec. Krishna (Editor), et al. Expires May 15, 2005 [Page 48] Internet-Draft SLRRP Oct 2004 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. MaskLength: 8 bits Length of the mask. Mask: up to 96 bits Mask to be used. 3.5.5.2.2.2. EPC C1G1 Tag Operations Parameters 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A | User | Type = 0x25 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Op-specs : : : This parameter is sent as part of the access-spec (section 3.5.5.2.2.3) in the access command. There can be one or more operations performed on Krishna (Editor), et al. Expires May 15, 2005 [Page 49] Internet-Draft SLRRP Oct 2004 a tag. This parameter describes the set of operations to be performed on a tag that matches the target tag-spec (section 3.5.5.2.2.1). The key point to note is that the ordering of the operations in this parameter is the exact order in which the reader performs these operations on the tag. Each operation is defined using an op-spec each 8 bytes long. The length of that op-spec is specified as part of the op-spec. Each op-spec has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpCode | | +-+-+-+-+-+-+-+-+ | | Operation-Specific Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OpCode Operation 0x0 Undefined 0x1 Read 0x2 Write 0x3 Kill Following are the op-specs for the different access operations: Read Op-spec ------------ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpCode = 0x1 | MB| RFU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WordPtr | Word Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MB: 2 bits Memory bank RFU: 22 bits Reserved for future use. WordPtr: 16 bits Starting word address. Krishna (Editor), et al. Expires May 15, 2005 [Page 50] Internet-Draft SLRRP Oct 2004 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. WriteData: 16 bits Data to be written to the tag. Kill Op-spec ------------ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OpCode = 0x3 | RFU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kill Password | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Kill Password: 32 bits Value of the kill password to be used/set. Up to 32 bits long. Krishna (Editor), et al. Expires May 15, 2005 [Page 51] Internet-Draft SLRRP Oct 2004 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 52] 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. Krishna (Editor), et al. Expires May 15, 2005 [Page 53] Internet-Draft SLRRP Oct 2004 3.5.8.2. Unrecognized Parameter Error This error cause is used to report an unrecognized parameter. The unrecognized parameter TLV is included as cause specific information. 3.5.8.3. Unrecognized Message Error This error cause is used to report an unrecognized message. The unrecognized message TLV is included as cause specific information. 3.5.8.4. Invalid Values Error This error cause is used to report one or more invalid values found in a received parameter. The offending TLV that contains the invalid value(s) is included as cause specific information. 3.5.8.5. Non-unique Antenna Identifier Error This error cause is used by a Reader to indicate to a RNC that the antenna identifier it chose the reader has already been used by another antenna in the reader. There is no cause specific information. 3.6. Reader Operating Modes In this section, we will list the various reader operating modes possible using SLRRP protocol messages. 3.6.1. Split Transmitter & Receiver Operation +-------+-------+--------------+ | Rx | Tx | Mode | | State | State | | +-------+-------+--------------+ | 0 | 0 |Antenna is OFF| +-------+-------+--------------+ | 0 | 1 | Tx ON only | +-------+-------+--------------+ | 1 | 0 | RF ON only | +-------+-------+--------------+ | 1 | 1 | Normal | +-------+-------+--------------+ Krishna (Editor), et al. Expires May 15, 2005 [Page 54] 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 55] 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 56] 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 57] 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 58] --=-ty60tfzq2hvcwdON3Rt3 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid --=-ty60tfzq2hvcwdON3Rt3-- From rfid-bounces@ietf.org Sat Jan 15 04:27:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25836; Sat, 15 Jan 2005 04:27:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpkRx-0004J1-0Q; Sat, 15 Jan 2005 04:42:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpkCZ-0008MQ-RW; Sat, 15 Jan 2005 04:26:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpkB9-00083H-IH for rfid@megatron.ietf.org; Sat, 15 Jan 2005 04:25:07 -0500 Received: from tsmtp3.ldap.isp (smtp.terra.es [213.4.129.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25712 for ; Sat, 15 Jan 2005 04:25:04 -0500 (EST) Received: from proxy ([81.60.108.253]) by tsmtp3.ldap.isp (terra.es) with ESMTP id IACQ5M02.3T9 for ; Sat, 15 Jan 2005 10:24:58 +0100 Message-ID: <00d901c4f9f9$382183f0$0201a8c0@proxy> From: "Moises" To: Date: Fri, 14 Jan 2005 06:23:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Content-Transfer-Encoding: 7bit Subject: [Rfid] RFID X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Hi, I would like to take a look to a technical documents that refer to range rfid (theorical and practical). The objetive is obtaint the longest range with little passive tags. Can anybody send me bibliography and references? Thanks in advance Moises _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@ietf.org Sun Jan 16 23:29:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15180; Sun, 16 Jan 2005 23:29:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqOkr-0001fw-3Y; Sun, 16 Jan 2005 23:44:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqORs-0002Rp-5n; Sun, 16 Jan 2005 23:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqONH-00024D-3H for rfid@megatron.ietf.org; Sun, 16 Jan 2005 23:20:19 -0500 Received: from relay0.EECS.Berkeley.EDU (relay0.EECS.Berkeley.EDU [169.229.60.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14742 for ; Sun, 16 Jan 2005 23:20:16 -0500 (EST) From: jsmith@EECS.Berkeley.EDU Received: from EECS.Berkeley.EDU (imap4.CS.Berkeley.EDU [169.229.60.23]) by relay0.EECS.Berkeley.EDU (8.13.3/8.12.10) with ESMTP id j0H4KHJO016344 for ; Sun, 16 Jan 2005 20:20:17 -0800 (PST) Received: from [128.32.33.54] by imap4.CS.Berkeley.EDU (mshttpd); Sun, 16 Jan 2005 20:20:17 -0800 To: rfid@ietf.org Message-ID: <763b7775c9f3.75c9f3763b77@EECS.Berkeley.EDU> Date: Sun, 16 Jan 2005 20:20:17 -0800 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.16 (built May 14 2003) MIME-Version: 1.0 Content-Language: en X-Accept-Language: en Priority: normal Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Rfid] Slrrp-Draft X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit All: I am trying to get up to speed on the Slrrp protocol and have read the draft: draft-krishna-slrrp-00.txt. I find that I am seriously in need of a introductory document, i. e. what levels of support are contemplated (command by command, continuous inventory with deltas, etc) and how high level controls and low level controls are going to be intermingled. For example, is it going to be possible to simply ask for an inventory process to run and report new tags, but to also control the precise times that a reader will be running, (for air interface control)? What processes are available for discovery? (capabilities both of the reader, and of the tag addressed) This is probably a religious point, but direct binary coded interfaces with fixed fields seem to be losing mind share to XML, (less efficient, but extensible). Is the efficiency worth the price in flexibility? Steve Smith _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@ietf.org Mon Jan 17 18:12:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04243; Mon, 17 Jan 2005 18:12:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqgHs-000595-5S; Mon, 17 Jan 2005 18:27:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqg1S-0004Aq-Se; Mon, 17 Jan 2005 18:10:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqg0f-0003dW-EA for rfid@megatron.ietf.org; Mon, 17 Jan 2005 18:10:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03915 for ; Mon, 17 Jan 2005 18:10:06 -0500 (EST) Received: from charles.revasystems.com ([65.209.89.90]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqgFo-00055d-87 for rfid@ietf.org; Mon, 17 Jan 2005 18:25:48 -0500 Received: from [192.168.1.44] (indus [192.168.1.44]) by charles.revasystems.com (Postfix) with ESMTP id 9C35C3BE52; Mon, 17 Jan 2005 18:09:29 -0500 (EST) Subject: Re: [Rfid] Slrrp-Draft From: "P. Krishna" To: "Prof. Steve Smith" In-Reply-To: <763b7775c9f3.75c9f3763b77@EECS.Berkeley.EDU> References: <763b7775c9f3.75c9f3763b77@EECS.Berkeley.EDU> Content-Type: text/plain; charset=utf-8 Message-Id: <1106003369.2812.27.camel@indus.revasystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 17 Jan 2005 18:09:29 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA03915 Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Content-Transfer-Encoding: quoted-printable On Sun, 2005-01-16 at 23:20, jsmith@EECS.Berkeley.EDU wrote: > All: >=20 > I am trying to get up to speed on the Slrrp protocol and have read the = draft:=20 > draft-krishna-slrrp-00.txt. I find that I am seriously in need of a in= troductory document, i. e. what levels of support are contemplated (comm= and by command, continuous inventory with deltas, etc) and how high level= controls and low level controls are going to be intermingled. For examp= le, is it going to be possible to simply ask for an inventory process to = run and report new tags, but to also control the precise times that a rea= der will be running, (for air interface control)? What processes are ava= ilable for discovery? (capabilities both of the reader, and of the tag ad= dressed) >=20 > This is probably a religious point, but direct binary coded interfaces = with fixed fields seem to be losing mind share to XML, (less efficient, b= ut extensible). Is the efficiency worth the price in flexibility? >=20 > Steve Smith >=20 =EF=BB=BFSteve, Thank you for taking the time to read the draft. Very good questions. Fundamentally, SLRRP provides a network-centric interface to/from readers and addresses scalability and flexibility in the following dimensions: - Air protocols - Reader density - Number of applications - Diversity of application requirements - Diversity of tag capabilities - Diversity of reader capabilities=20 I will describe how SLRRP addresses each of the above. Hopefully, by doing so, I would have answered your questions too.=20 So, what do we mean by network-centric? Until recently, development of=20 readers and reader technology has focused on the needs of specific=20 applications. Let's call this "application-centric" focus. This was a=20 good thing, and enabled people to develop applications and systems that=20 utilized RFID data and information. In some ways, this evolution=20 reflects the early days of computer networking. At that time, each new=20 "application" of connected computing required a new network to be setup=20 and configured. This rapidly evolved to the point that the network=20 became "infrastructure" and devices created connections as applications=20 required them. A network-centric RFID infrastructure would support=20 acquisition of tags for a variety of application needs; in essence, the=20 RFID equipment becomes a tag acquisition network and becomes=20 part of the enterprise computing environment. Readers are deployed in=20 increasing numbers and become edge devices of this network, and devices=20 (Reader Network Controllers, or RNCs) operate these readers. SLRRP is=20 designed to enable and support this evolution to a network-centric=20 model. One of the keys to SLRRP is the decoupling of the commands and parameters. This allows for a common command structure, and=20 extensibility comes in the form of parameters, which allows for support of new air protocols to be implemented as plugins in terms of new=20 parameters. SLRRP has 3 types of messages: (a) configuration,=20 (b) inventory and (c) access.=20 (a) Configuration: GET_READER_INFO: This message queries the reader about its identification, POE requirements, reader capabilities, device=20 configuration (e.g., antenna properties), RF receiver operational=20 parameters (sensitivity), RF transmitter operational parameters (tx=20 power, FH sequence being used) frequency hop table information (if in=20 freq-hop regions), fixed frequency list(if in Europe), statistics, tag=20 inventory and access report format/structure. Using this command, we can query the reader capabilities. We have currently defined the following capabilities that can be expressed using SLRRP: control power, independent RX and TX control, write tags, kill=20 tags. I am sure there is more. The capabilities vector is 32 bits wide, which gives us 2^32 capabilities that can be described and expressed by the readers. SET_READER_INFO: This message sets the reader's configuration,=20 specifically, RF Receive sensitivity, TX transmit power, the FH sequence to use, the desired contents in the inventory and access report, reset=20 statistics, air-protocol specific RF parameters. Using this command, we can set the air-protocol specific RF parameters.=20 For example, in C1G2 protocol, if the target RF environment is fairly=20 constant (yeah right !! ;) ), then during the configuration phase=20 itself, we can set the RF parameters(e.g., PIE rate, PIE ratio, ASK or=20 BPSK, TRCal, divide ratio) to be used during tag inventory. These parameters are used by the reader in the subsequent inventory rounds=20 till an inventory command with new RF parameters are received by the=20 reader. (b) Inventory: INVENTORY: This message sets the parameters to be used during the inventory rounds. In order to support a scalable RFID infrastructure in=20 terms of reader density, there has to be a tight control of the RF=20 cycles by the readers. To that respect, we convey the following=20 parameters for an inventory command:=20 (i) Target Tag filter: Subset of tag population to be inventoried. For=20 example, in C1G2 it will be used in the Select command; in C1G1 it is=20 the starting point in the tree) (ii) RF parameters: The RF parameters that are part of the air protocol (iii) Singulation: The singulation algorithm parameters that can be set=20 during each inventory round - e.g., in C1G2 it specifies the target tag=20 population's state(A or B, SL or ~SL tags). Continuing with the C1G2 example, this singulation parameter also provides the flexibility of=20 specifying the Q-algorithm to be used each round in one of two ways -=20 (1) sophisticated reader: to which we describe the target singulation=20 environment in the form of a tuple , or (2) simple reader: to which we describe=20 the Q-manipulation algorithm state machine. This command provides the capability of=20 - setting a round size in terms of time - control the filter, rf and singulation parameters each round.=20 There is a 'lifetime bit' in the command that allows the reader to=20 continue operating on the inventory command forever.=20 This allows for a very flexible inventory process - command-by-command or continuous inventory with deltas. We don't have to set the parameters for each round - for example, we can choose to persist with parameters=20 like RF, but change only tag filter and singulation parameters. (c) Access:=20 ACCESS: This message creates a new access-spec at the reader.=20 Access-spec is basically a set of actions to be taken by the reader upon seeing the tag that matches the tag-spec specified in the access-spec.=20 The design of this aspect of the protocol takes into account the=20 scalability requirements in the applications space. There will be a=20 multitude of applications requiring a wide variety of information from tags, and also with a diverse set of requirements ranging from one-time=20 actions on a specific tag to a set of persistent rules/actions that need to happen day-in day-out on a family of tags. Each access command adds an access-spec to the reader. Its akin to an=20 Access-control-list(ACL) [we were almost tempted to call this list a TCL (tag control list)] or a routing table stored in a reader. This allows=20 for the reader to perform the access operations on the tag as and when it gets inventoried.=20 The access-spec comprises of 2 parameter blocks: target tag-spec (which=20 is like a filter-spec), and the tag operations spec (op-spec).=20 One question that you raised is that of tag capabilities discovery. That is a very important question, especially in the light of TID specific to C1G2. There are two ways to implement tag capabilities usage: (option i) Reader has the tag-capabilities (for example, based on TID) table: as=20 and when, it reads the tag, it looks up the capabilities-table to=20 determine what actions it can perform on the tag; and if possible and=20 permissible, then performs the access operations that is specified in=20 the access-spec. (option ii) The RNC has the tag-capabilities table:=20 based on which it performs the sanity check of the access operations=20 that can be performed on the tag and thus programs the correct access-spec at the reader. The reader upon seeing a tag, now doesn't=20 need to perform the capabilities check; it just looks up the access-spec and performs the access operation. We allow for both the options (i and ii). As can be observed, SLRRP=20 provides a versatile interface to program the access-specs at the reader.=20 Following is an example of TID-based access operation using SLRRP. In this example, I'll use option (ii).=20 Suppose, an application requires the following business logic: - Dock-door reader to write current timestamp and dock door # in the=20 user-memory of pallet tags. As you know, the user-memory and block write capabilities are optional=20 for C1 tags in G2. Lets say, this dock-door sees tags from manufacturers foo1, foo2 and others. And lets suppose, the TID table looks as=20 follows: =20 TID User Memory BlockWriteCapability foo1 Yes Yes =20 foo2 No No =20 * Yes No // This entry is for the rest of TIDs. The RNC using SLRRP would create 3 access-specs at the reader: access-spec1:=20 tag-spec: Matches TID=3Dfoo1 and type=3Dpallet op-spec: Block Write time and dock door # to user memory access-spec2:tag-spec: Matches TID=3Dfoo2 and type=3Dpallet op-spec: no op. access-spec3:tag-spec: Matches TID=3D* and type=3Dpallet op-spec: Write time and dock door # to user memory I hope the above discussion helped you understand SLRRP better. If you=20 and the group think it will help, we can work together to publish a=20 separate draft that provides the problem statement and introduction=20 material to SLRRP? Looking forward to more discussions. Thanks, /Krishna _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@ietf.org Mon Jan 17 22:47:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22158; Mon, 17 Jan 2005 22:47:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqka8-0002cY-P4; Mon, 17 Jan 2005 23:03:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqkJp-0001zd-F5; Mon, 17 Jan 2005 22:46:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqkHv-0001iA-Hu for rfid@megatron.ietf.org; Mon, 17 Jan 2005 22:44:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22070 for ; Mon, 17 Jan 2005 22:44:12 -0500 (EST) Received: from reh001-1.rex001.exchangebyregister.com ([64.78.19.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqkX6-0002Xk-R9 for rfid@ietf.org; Mon, 17 Jan 2005 22:59:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Rfid] Slrrp-Draft Date: Mon, 17 Jan 2005 19:43:43 -0800 Message-ID: Thread-Topic: [Rfid] Slrrp-Draft Thread-Index: AcT8TSIS6OJGCjR9SbG3dfB4FW0PpQAu3lDg From: "Scott Barvick" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Steve, =20 Thanks again for the input. I'll respond to the XML question here. I = don't think it really is religious because the SLRRP goals of = efficiency, ubiquity, tight control, and achieving the network-centric = focus that Krishna discusses in his response essentially require binary = coding. The binary style of IETF protocols continues to be the = standard for IP communications infrastructure with enough proven = solutions for flexibility in versioning, vendor extensions, and = parameter selection to provide confidence in this approach. BTW, I'll = be the first to admit that the current draft has not sufficiently = addressed all of the above requirements, so there are many opportunities = for contribution. =20 Scott ________________________________ From: rfid-bounces@lists.ietf.org on behalf of jsmith@EECS.Berkeley.EDU Sent: Sun 1/16/2005 11:20 PM To: rfid@ietf.org Subject: [Rfid] Slrrp-Draft All: I am trying to get up to speed on the Slrrp protocol and have read the = draft: draft-krishna-slrrp-00.txt. I find that I am seriously in need of a = introductory document, i. e. what levels of support are contemplated = (command by command, continuous inventory with deltas, etc) and how high = level controls and low level controls are going to be intermingled. For = example, is it going to be possible to simply ask for an inventory = process to run and report new tags, but to also control the precise = times that a reader will be running, (for air interface control)? What = processes are available for discovery? (capabilities both of the reader, = and of the tag addressed) This is probably a religious point, but direct binary coded interfaces = with fixed fields seem to be losing mind share to XML, (less efficient, = but extensible). Is the efficiency worth the price in flexibility? Steve Smith _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@ietf.org Mon Jan 17 23:39:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25953; Mon, 17 Jan 2005 23:39:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqlOY-0003n1-4p; Mon, 17 Jan 2005 23:55:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cql6C-0002Ps-7b; Mon, 17 Jan 2005 23:36:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cql4Q-0001Yr-Eg for rfid@megatron.ietf.org; Mon, 17 Jan 2005 23:34:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25647 for ; Mon, 17 Jan 2005 23:34:19 -0500 (EST) Received: from reh001-1.rex001.exchangebyregister.com ([64.78.19.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqlJb-0003fo-7b for rfid@ietf.org; Mon, 17 Jan 2005 23:50:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Rfid] RFID Date: Mon, 17 Jan 2005 20:33:49 -0800 Message-ID: Thread-Topic: [Rfid] RFID Thread-Index: AcT65G8LL28e6+NuSJ2HpeBAoYFwvACMY/yA From: "P. Krishna" To: "Moises" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Some good places with references ... =20 EPCGlobal - http://www.epcglobalinc.org/standards_technology/specifications.html =20 AutoId labs http://www.autoidlabs.org/researcharchive =20 I hope this helps. =20 /Krishna ________________________________ From: rfid-bounces@lists.ietf.org on behalf of Moises Sent: Fri 1/14/2005 12:23 AM To: rfid@ietf.org Subject: [Rfid] RFID Hi, I would like to take a look to a technical documents that refer to = range rfid (theorical and practical). The objetive is obtaint the longest range with little passive tags. Can anybody send me bibliography and references? Thanks in advance Moises _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@ietf.org Tue Jan 18 18:31:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18285; Tue, 18 Jan 2005 18:31:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr34P-0000Ai-K9; Tue, 18 Jan 2005 18:47:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr2nW-0003cp-TT; Tue, 18 Jan 2005 18:30:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr2iS-0002Qt-WB for rfid@megatron.ietf.org; Tue, 18 Jan 2005 18:24:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17569 for ; Tue, 18 Jan 2005 18:24:48 -0500 (EST) Received: from sandesh.patni.com ([208.250.32.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr2xm-0008Q5-UF for rfid@ietf.org; Tue, 18 Jan 2005 18:40:44 -0500 Received: from onsitemail.patni.com ([192.168.175.202]) by sandesh.patni.com (8.12.11/8.12.11) with ESMTP id j0INMmdu018043 for ; Tue, 18 Jan 2005 18:22:48 -0500 Received: from onsitemail.patni.com (localhost [127.0.0.1]) by onsitemail.patni.com (8.12.8/8.12.8) with ESMTP id j0J0YDcr024383 for ; Tue, 18 Jan 2005 19:34:33 -0500 Received: (from apache@localhost) by onsitemail.patni.com (8.12.8/8.12.8/Submit) id j0J0XfFc024335; Tue, 18 Jan 2005 19:33:41 -0500 Received: from 208.250.32.6 (SquirrelMail authenticated user shahsapa) by 192.168.175.202 with HTTP; Tue, 18 Jan 2005 19:33:41 -0500 (EST) Message-ID: <11994.208.250.32.6.1106094821.squirrel@192.168.175.202> Date: Tue, 18 Jan 2005 19:33:41 -0500 (EST) From: "Sapan Shah" To: rfid@ietf.org User-Agent: SquirrelMail/1.4.1-2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 0.8 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 8bit Subject: [Rfid] (no subject) X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 8bit Folks, I did go through the draft documents and it does look intersting. However have a few questions before I can move on with contributing on the specs. I am considering a hetrogenous environment with readers of multiple brands and multiple standards installed in the same facility - so as to leverage the max out of the protocol specs and find out what can be missing - if there is anything. Let us say, we have like 3 readers that follow EPc Standards and 3 Readers that follow ISO Standards. The Reader Network Controller - as the definition suggests will be / can be a software server as well. If we take this into consideration then on the EPC Front, The Device Management Layer within ALE / The RM and RP will be taking care of all the commands to be sent out to the reader. What is left out, will be the ISO Standards - which the RNC will be commanding. The EPc Standards, I dont think will support the RNC. Although, the IP based configuration that we are trying to specify over here is different in the aspects of Binary data being conveyed through IP Packets, would not it be a complicated situation, when the standards are recognized and accepted? I mean, If There are EPC Standards / Middlewares that already have their readers up and running on the network and they accept commands in a specific format. How do we plan to merge applications with them? Sapan _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@ietf.org Tue Jan 18 18:32:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18318; Tue, 18 Jan 2005 18:32:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr34w-0000BL-HG; Tue, 18 Jan 2005 18:48:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr2nY-0003dM-9K; Tue, 18 Jan 2005 18:30:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr2j2-0002Yd-09 for rfid@megatron.ietf.org; Tue, 18 Jan 2005 18:25:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17606 for ; Tue, 18 Jan 2005 18:25:24 -0500 (EST) Received: from sandesh.patni.com ([208.250.32.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr2yN-0008Qa-RN for rfid@ietf.org; Tue, 18 Jan 2005 18:41:20 -0500 Received: from onsitemail.patni.com ([192.168.175.202]) by sandesh.patni.com (8.12.11/8.12.11) with ESMTP id j0INNS80018068 for ; Tue, 18 Jan 2005 18:23:28 -0500 Received: from onsitemail.patni.com (localhost [127.0.0.1]) by onsitemail.patni.com (8.12.8/8.12.8) with ESMTP id j0J0Yrcr024433 for ; Tue, 18 Jan 2005 19:35:13 -0500 Received: (from apache@localhost) by onsitemail.patni.com (8.12.8/8.12.8/Submit) id j0J0YX34024415; Tue, 18 Jan 2005 19:34:33 -0500 Received: from 208.250.32.6 (SquirrelMail authenticated user shahsapa) by 192.168.175.202 with HTTP; Tue, 18 Jan 2005 19:34:33 -0500 (EST) Message-ID: <12016.208.250.32.6.1106094873.squirrel@192.168.175.202> Date: Tue, 18 Jan 2005 19:34:33 -0500 (EST) From: "Sapan Shah" To: rfid@ietf.org User-Agent: SquirrelMail/1.4.1-2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 0.8 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 8bit Subject: [Rfid] Fundamental Questions X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 8bit Folks, I did go through the draft documents and it does look intersting. However have a few questions before I can move on with contributing on the specs. I am considering a hetrogenous environment with readers of multiple brands and multiple standards installed in the same facility - so as to leverage the max out of the protocol specs and find out what can be missing - if there is anything. Let us say, we have like 3 readers that follow EPc Standards and 3 Readers that follow ISO Standards. The Reader Network Controller - as the definition suggests will be / can be a software server as well. If we take this into consideration then on the EPC Front, The Device Management Layer within ALE / The RM and RP will be taking care of all the commands to be sent out to the reader. What is left out, will be the ISO Standards - which the RNC will be commanding. The EPc Standards, I dont think will support the RNC. Although, the IP based configuration that we are trying to specify over here is different in the aspects of Binary data being conveyed through IP Packets, would not it be a complicated situation, when the standards are recognized and accepted? I mean, If There are EPC Standards / Middlewares that already have their readers up and running on the network and they accept commands in a specific format. How do we plan to merge applications with them? Sapan _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@ietf.org Tue Jan 18 18:32:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18363; Tue, 18 Jan 2005 18:32:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr35K-0000Bv-1o; Tue, 18 Jan 2005 18:48:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr2nY-0003dW-GX; Tue, 18 Jan 2005 18:30:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cr2jg-0002cD-BA for rfid@megatron.ietf.org; Tue, 18 Jan 2005 18:26:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17751 for ; Tue, 18 Jan 2005 18:26:05 -0500 (EST) Received: from sandesh.patni.com ([208.250.32.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cr2z2-0008S0-Cq for rfid@ietf.org; Tue, 18 Jan 2005 18:42:00 -0500 Received: from onsitemail.patni.com ([192.168.175.202]) by sandesh.patni.com (8.12.11/8.12.11) with ESMTP id j0INO9JL018133 for ; Tue, 18 Jan 2005 18:24:09 -0500 Received: from onsitemail.patni.com (localhost [127.0.0.1]) by onsitemail.patni.com (8.12.8/8.12.8) with ESMTP id j0J0ZYcr024473 for ; Tue, 18 Jan 2005 19:35:54 -0500 Received: (from apache@localhost) by onsitemail.patni.com (8.12.8/8.12.8/Submit) id j0J0ZELe024460; Tue, 18 Jan 2005 19:35:14 -0500 Received: from 208.250.32.6 (SquirrelMail authenticated user shahsapa) by 192.168.175.202 with HTTP; Tue, 18 Jan 2005 19:35:14 -0500 (EST) Message-ID: <12018.208.250.32.6.1106094914.squirrel@192.168.175.202> Date: Tue, 18 Jan 2005 19:35:14 -0500 (EST) From: "Sapan Shah" To: rfid@ietf.org User-Agent: SquirrelMail/1.4.1-2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 0.8 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 8bit Subject: [Rfid] Fundamental Questions X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 8bit Folks, I did go through the draft documents and it does look intersting. However have a few questions before I can move on with contributing on the specs. I am considering a hetrogenous environment with readers of multiple brands and multiple standards installed in the same facility - so as to leverage the max out of the protocol specs and find out what can be missing - if there is anything. Let us say, we have like 3 readers that follow EPc Standards and 3 Readers that follow ISO Standards. The Reader Network Controller - as the definition suggests will be / can be a software server as well. If we take this into consideration then on the EPC Front, The Device Management Layer within ALE / The RM and RP will be taking care of all the commands to be sent out to the reader. What is left out, will be the ISO Standards - which the RNC will be commanding. The EPc Standards, I dont think will support the RNC. Although, the IP based configuration that we are trying to specify over here is different in the aspects of Binary data being conveyed through IP Packets, would not it be a complicated situation, when the standards are recognized and accepted? I mean, If There are EPC Standards / Middlewares that already have their readers up and running on the network and they accept commands in a specific format. How do we plan to merge applications with them? Sapan _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@ietf.org Wed Jan 19 21:07:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20023; Wed, 19 Jan 2005 21:07:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrRyi-0006KZ-Im; Wed, 19 Jan 2005 21:23:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrRiB-0007i9-NS; Wed, 19 Jan 2005 21:06:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrRgV-0007PH-KW for rfid@megatron.ietf.org; Wed, 19 Jan 2005 21:04:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19861 for ; Wed, 19 Jan 2005 21:04:29 -0500 (EST) Received: from sandesh.patni.com ([208.250.32.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrRw4-0006GA-I6 for rfid@ietf.org; Wed, 19 Jan 2005 21:20:37 -0500 Received: from onsitemail.patni.com ([192.168.175.202]) by sandesh.patni.com (8.12.11/8.12.11) with ESMTP id j0K22Q6W011537; Wed, 19 Jan 2005 21:02:26 -0500 Received: from onsitemail.patni.com (localhost [127.0.0.1]) by onsitemail.patni.com (8.12.8/8.12.8) with ESMTP id j0K3Dvcr016123; Wed, 19 Jan 2005 22:14:17 -0500 Received: (from apache@localhost) by onsitemail.patni.com (8.12.8/8.12.8/Submit) id j0K3DPcG016063; Wed, 19 Jan 2005 22:13:25 -0500 Received: from 208.250.32.6 (SquirrelMail authenticated user shahsapa) by 192.168.175.202 with HTTP; Wed, 19 Jan 2005 22:13:25 -0500 (EST) Message-ID: <14822.208.250.32.6.1106190805.squirrel@192.168.175.202> In-Reply-To: <1106168360.11949.44.camel@indus.revasystems.com> References: <54861.208.250.32.6.1106080308.squirrel@192.168.175.202> <1106085695.2812.273.camel@indus.revasystems.com> <1106166748.11949.38.camel@indus.revasystems.com> <56871.208.250.32.6.1106171588.squirrel@192.168.175.202> <1106168360.11949.44.camel@indus.revasystems.com> Date: Wed, 19 Jan 2005 22:13:25 -0500 (EST) From: "Sapan Shah" To: "P. Krishna" User-Agent: SquirrelMail/1.4.1-2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 0.8 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 8bit Cc: rfid@ietf.org Subject: [Rfid] Re: A few fundamental questions X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 8bit Krishna, I am confused - I believe SLRPP is for the communication between the reader and the RNC - a software application - as I take or a router, for example. == Why would any air protocol matter to me? The readers are a set of devices which would have their own embedded code that will have the algorithm for interacting with/through the air protocol for reading the tags. As long as I have my reader on the network and my RNC (Any software that wants to read and process the tag list further) is able to send commands to the Reader, why would it matter to me as to what and how many air protocols are defined? I agree that RNC would be needed to control the read cycles so as to optimize the "Reader Network" efficiency, but again it doest it depend on the "air-protocols" per se'? I mean, All I would expect is sending a binary / ascii command to the reader and it responding back to me and the algorithm would be with me to contrl the network- Please correct me I am wrong. Regards Sapan Sapan Shah Patni Computer Systems Ltd http://www.patni.com 513-243-9071 > On Tue, 2005-01-18 at 15:31, Sapan Shah wrote: >> Krishna, >> >> I did go through the draft documents and it does look intersting. >> However >> have a few questions before I can move on with contributing on the >> specs. >> > > Sapan, > First off, thank you for taking the time to read the draft. Now to your > questions ... > >> I am considering a hetrogenous environment with readers of multiple >> brands >> and multiple standards installed in the same facility - so as to >> leverage >> the max out of the protocol specs and find out what can be missing - if >> there is anything. >> >> Let us say, we have like 3 readers that follow EPc Standards and 3 >> Readers >> that follow ISO Standards. The Reader Network Controller - as the >> definition suggests will be / can be a software server as well. If we >> take >> this into consideration then on the EPC Front, The Device Management >> Layer >> within ALE / The RM and RP will be taking care of all the commands to be >> sent out to the reader. What is left out, will be the ISO Standards - >> which _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@ietf.org Wed Jan 19 21:09:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20273; Wed, 19 Jan 2005 21:09:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrS0S-0006Mx-NB; Wed, 19 Jan 2005 21:25:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrRiC-0007ig-Tg; Wed, 19 Jan 2005 21:06:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrRhO-0007Vs-HE for rfid@megatron.ietf.org; Wed, 19 Jan 2005 21:05:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19903 for ; Wed, 19 Jan 2005 21:05:24 -0500 (EST) Received: from sandesh.patni.com ([208.250.32.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrRwy-0006Gw-Ts for rfid@ietf.org; Wed, 19 Jan 2005 21:21:33 -0500 Received: from onsitemail.patni.com ([192.168.175.202]) by sandesh.patni.com (8.12.11/8.12.11) with ESMTP id j0K23RXA011640; Wed, 19 Jan 2005 21:03:27 -0500 Received: from onsitemail.patni.com (localhost [127.0.0.1]) by onsitemail.patni.com (8.12.8/8.12.8) with ESMTP id j0K3Ewcr016208; Wed, 19 Jan 2005 22:15:18 -0500 Received: (from apache@localhost) by onsitemail.patni.com (8.12.8/8.12.8/Submit) id j0K3ESYB016187; Wed, 19 Jan 2005 22:14:28 -0500 Received: from 208.250.32.6 (SquirrelMail authenticated user shahsapa) by 192.168.175.202 with HTTP; Wed, 19 Jan 2005 22:14:28 -0500 (EST) Message-ID: <14826.208.250.32.6.1106190868.squirrel@192.168.175.202> In-Reply-To: <1106168360.11949.44.camel@indus.revasystems.com> References: <54861.208.250.32.6.1106080308.squirrel@192.168.175.202> <1106085695.2812.273.camel@indus.revasystems.com> <1106166748.11949.38.camel@indus.revasystems.com> <56871.208.250.32.6.1106171588.squirrel@192.168.175.202> <1106168360.11949.44.camel@indus.revasystems.com> Date: Wed, 19 Jan 2005 22:14:28 -0500 (EST) From: "Sapan Shah" To: "P. Krishna" User-Agent: SquirrelMail/1.4.1-2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 0.8 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 8bit Cc: rfid@ietf.org Subject: [Rfid] Re: A few fundamental questions X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 8bit Krishna, I am confused - I believe SLRPP is for the communication between the reader and the RNC - a software application - as I take or a router, for example. == Why would any air protocol matter to me? The readers are a set of devices which would have their own embedded code that will have the algorithm for interacting with/through the air protocol for reading the tags. As long as I have my reader on the network and my RNC (Any software that wants to read and process the tag list further) is able to send commands to the Reader, why would it matter to me as to what and how many air protocols are defined? I agree that RNC would be needed to control the read cycles so as to optimize the "Reader Network" efficiency, but again it doest it depend on the "air-protocols" per se'? I mean, All I would expect is sending a binary / ascii command to the reader and it responding back to me and the algorithm would be with me to contrl the network- Please correct me I am wrong. Regards Sapan Sapan Shah Patni Computer Systems Ltd http://www.patni.com 513-243-9071 > On Tue, 2005-01-18 at 15:31, Sapan Shah wrote: >> Krishna, >> >> I did go through the draft documents and it does look intersting. >> However >> have a few questions before I can move on with contributing on the >> specs. >> > > Sapan, > First off, thank you for taking the time to read the draft. Now to your > questions ... > >> I am considering a hetrogenous environment with readers of multiple >> brands >> and multiple standards installed in the same facility - so as to >> leverage >> the max out of the protocol specs and find out what can be missing - if >> there is anything. >> >> Let us say, we have like 3 readers that follow EPc Standards and 3 >> Readers >> that follow ISO Standards. The Reader Network Controller - as the >> definition suggests will be / can be a software server as well. If we >> take >> this into consideration then on the EPC Front, The Device Management >> Layer >> within ALE / The RM and RP will be taking care of all the commands to be >> sent out to the reader. What is left out, will be the ISO Standards - >> which _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@ietf.org Wed Jan 19 21:25:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21184; Wed, 19 Jan 2005 21:25:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrSG3-0006hk-Vi; Wed, 19 Jan 2005 21:41:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrRzN-0002KO-Ds; Wed, 19 Jan 2005 21:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrRxV-00020G-H1 for rfid@megatron.ietf.org; Wed, 19 Jan 2005 21:22:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20984 for ; Wed, 19 Jan 2005 21:22:03 -0500 (EST) Received: from sandesh.patni.com ([208.250.32.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrSD5-0006bn-JZ for rfid@ietf.org; Wed, 19 Jan 2005 21:38:12 -0500 Received: from onsitemail.patni.com ([192.168.175.202]) by sandesh.patni.com (8.12.11/8.12.11) with ESMTP id j0K2K5ox012565; Wed, 19 Jan 2005 21:20:05 -0500 Received: from onsitemail.patni.com (localhost [127.0.0.1]) by onsitemail.patni.com (8.12.8/8.12.8) with ESMTP id j0K3Vacr017112; Wed, 19 Jan 2005 22:31:56 -0500 Received: (from apache@localhost) by onsitemail.patni.com (8.12.8/8.12.8/Submit) id j0K3V6qd017070; Wed, 19 Jan 2005 22:31:06 -0500 Received: from 208.250.32.6 (SquirrelMail authenticated user shahsapa) by 192.168.175.202 with HTTP; Wed, 19 Jan 2005 22:31:06 -0500 (EST) Message-ID: <16067.208.250.32.6.1106191866.squirrel@192.168.175.202> In-Reply-To: <14822.208.250.32.6.1106190805.squirrel@192.168.175.202> References: <54861.208.250.32.6.1106080308.squirrel@192.168.175.202><1106085695.2812.273.camel@indus.revasystems.com><1106166748.11949.38.camel@indus.revasystems.com><56871.208.250.32.6.1106171588.squirrel@192.168.175.202><1106168360.11949.44.camel@indus.revasystems.com> <14822.208.250.32.6.1106190805.squirrel@192.168.175.202> Date: Wed, 19 Jan 2005 22:31:06 -0500 (EST) Subject: Re: [Rfid] Re: A few fundamental questions From: "Sapan Shah" To: "Sapan Shah" User-Agent: SquirrelMail/1.4.1-2 MIME-Version: 1.0 Content-Type: multipart/mixed;boundary="----=_20050119223106_24110" X-Priority: 3 Importance: Normal X-Spam-Score: 0.8 (/) X-Scan-Signature: 6f51ba5266426a53fc06c7d32a3c18b6 Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 4da339c42fe5be09fa120bb0fcc4a575 ------=_20050119223106_24110 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Further, I am attaching a diagram that I thought would help me clearing up with my doubts. > > Krishna, > > I am confused - I believe SLRPP is for the communication between the > reader and the RNC - a software application - as I take or a router, for > example. > > == > Why would any air protocol matter to me? The readers are a set of devices > which would have their own embedded code that will have the algorithm for > interacting with/through the air protocol for reading the tags. > > As long as I have my reader on the network and my RNC (Any software that > wants to read and process the tag list further) is able to send commands > to the Reader, why would it matter to me as to what and how many air > protocols are defined? I agree that RNC would be needed to control the > read cycles so as to optimize the "Reader Network" efficiency, but again > it doest it depend on the "air-protocols" per se'? > > I mean, All I would expect is sending a binary / ascii command to the > reader and it responding back to me and the algorithm would be with me to > contrl the network- Please correct me I am wrong. > > > > Regards > Sapan > > Sapan Shah > Patni Computer Systems Ltd > http://www.patni.com > 513-243-9071 > > > >> On Tue, 2005-01-18 at 15:31, Sapan Shah wrote: >>> Krishna, >>> >>> I did go through the draft documents and it does look intersting. >>> However >>> have a few questions before I can move on with contributing on the >>> specs. >>> >> >> Sapan, >> First off, thank you for taking the time to read the draft. Now to your >> questions ... >> >>> I am considering a hetrogenous environment with readers of multiple >>> brands >>> and multiple standards installed in the same facility - so as to >>> leverage >>> the max out of the protocol specs and find out what can be missing - if >>> there is anything. >>> >>> Let us say, we have like 3 readers that follow EPc Standards and 3 >>> Readers >>> that follow ISO Standards. The Reader Network Controller - as the >>> definition suggests will be / can be a software server as well. If we >>> take >>> this into consideration then on the EPC Front, The Device Management >>> Layer >>> within ALE / The RM and RP will be taking care of all the commands to >>> be >>> sent out to the reader. What is left out, will be the ISO Standards - >>> which > > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid > ------=_20050119223106_24110 Content-Type: application/msword; name="Clarifying Scenarios.doc" Content-Disposition: attachment; filename="Clarifying Scenarios.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAALQAAAAAAAAAA EAAALwAAAAEAAAD+////AAAAACwAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEACyAJBAAA8BK/AAAAAAAAEAAAAAAABAAAZwUAAA4AYmpiauAA4AAAAAAAAAAAAAAAAAAAAAAA AAAJBBYAIhAAAIJqAQCCagEAOwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKwEAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAEwBAAAAAAAATAEAAEwB AAAAAAAATAEAAAAAAADYBAAAAAAAANgEAAAAAAAA2AQAABQAAAAAAAAAAAAAAOwEAAAAAAAAUgkA AAAAAABSCQAAAAAAAFIJAAAAAAAAUgkAAAwAAABeCQAAFAAAAOwEAAAAAAAAGCEAAPgAAAB+CQAA AAAAAH4JAAAAAAAAfgkAAAAAAAB+CQAAAAAAAH4JAAAAAAAAwRoAAAAAAADBGgAAAAAAAMEaAAAA AAAAlyAAAAIAAACZIAAAAAAAAJkgAAAAAAAAmSAAAAAAAACZIAAAAAAAAJkgAAAAAAAAmSAAACQA AAAQIgAAIAIAADAkAABqAAAAvSAAABUAAAAAAAAAAAAAAAAAAAAAAAAA2AQAAAAAAADBGgAAAAAA AAAAAAAAAAAAAAAAAAAAAACFFgAAPAQAAMEaAAAAAAAAwRoAAAAAAADBGgAAAAAAAL0gAAAAAAAA NRwAAAAAAABMAQAAAAAAAEwBAAAAAAAAfgkAAAAAAAAAAAAAAAAAAH4JAAAHDQAA0iAAABYAAAA1 HAAAAAAAADUcAAAAAAAANRwAAAAAAADBGgAAWAAAAEwBAACOAgAAfgkAAAAAAADYBAAAAAAAAH4J AAAAAAAAlyAAAAAAAAAAAAAAAAAAADUcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAwRoAAAAAAACXIAAAAAAAADUcAABuAQAANRwAAAAAAACjHQAA HgAAAFsgAAAsAAAA2gMAAP4AAADYBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlyAAAAAAAAB+CQAAAAAAAHIJAAAMAAAAwKicYpb+ xAHsBAAAZgQAAFIJAAAAAAAAGRsAABAAAACHIAAACAAAAAAAAAAAAAAAlyAAAAAAAADoIAAAMAAA ABghAAAAAAAAjyAAAAgAAACaJAAAAAAAACkbAAAMAQAAmiQAAAAAAACXIAAAAAAAADUcAAAAAAAA 7AQAAAAAAADsBAAAAAAAAEwBAAAAAAAATAEAAAAAAABMAQAAAAAAAEwBAAAAAAAAAgDZAAAACAgI CAgICAgICAgICAgICAgIU2NlbmFyaW8gMQ0MCAgICAgICAgICAgICAgICAgIU2NlbmFyaW8gMg1F UEMgUmVhZGVyDQ1FUEMgUmVhZGVyDQ1JU08gUmVhZGVyDQ1STkMNDVNMUlBQDQ1FUEMgVEFnDQ1F UEMgVEFnDQ1FUEMgVEFnDQ1JU08gVGFnDQ1BaXIgcHJvdG9jb2xzDQ1FUEMgU3RhbmRhcmQgTWlk ZGxld2FyZQ0NV2hlcmUgZG9lcyB0aGlzIGZpdD8NDVdoZXJlIGRvZXMgdGhpcyBmaXQ/DQ1NdWx0 aXBsZSBzdGFuZGFyZHMgTWlkZGxld2FyZQ0NQWlyIHByb3RvY29scw0NSVNPIFRhZw0NRVBDIFRB Zw0NRVBDIFRBZw0NRVBDIFRBZw0NU0xSUFANDVJOQw0NSVNPIFJlYWRlcg0NRVBDIFJlYWRlcg0N RVBDIFJlYWRlcg0NDQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAS BAAAHgQAADAEAABnBQAA9QD1AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUA2oAAAAAVQgBbUgABG5IAAR1CAEEAAQAAB0E AAA7BAAARgQAAEcEAABSBAAAUwQAAF4EAABfBAAAYwQAAGQEAABqBAAAawQAAHMEAAB0BAAAfAQA AH0EAACFBAAAhgQAAI4EAACPBAAAnQQAAJ4EAAC2BAAAtwQAAMwEAADNBAAA4gQAAOMEAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAA AAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD7 AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAA AAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAA AAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAA AAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPYAAAAAAAAA AAAAAAD7AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAMkAWEkAQABAAAAAQEAABwABAAAOwQA AGYFAAD+/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEBAuMEAAABBQAA AgUAABAFAAARBQAAGQUAABoFAAAiBQAAIwUAACsFAAAsBQAANAUAADUFAAA7BQAAPAUAAEAFAABB BQAATAUAAE0FAABYBQAAWQUAAGQFAABlBQAAZgUAAGcFAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPYAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAQAABAAAAyQBYSQBAAEAAAAYIAAxkGgBH7DQ LyCw4D0hsAgHIrAIByOQoAUkkKAFJbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAA8ACgABAGkA DwADAAAAAAAAAAAASAAAQPH/AgBIAAwABgBOAG8AcgBtAGEAbAAAAA4AAAADJAMSZGgBAQBhJAMc AE9KAwBRSgMAX0gBBGFKGABtSAkEc0gJBHRICQRKAAFAAQACAEoADQAJAEgAZQBhAGQAaQBuAGcA IAAxAAAAEAABAAYkAROk8AAUpDwAQCYAFgA1CIFDSiAAS0ggAFwIgV5KAgBhSiAASgACQAEAAgBK AA0ACQBIAGUAYQBkAGkAbgBnACAAMgAAAB4AAgADJAAFJAEGJAEKJgELRgIAEmTwAAEAQCYBYSQA CABDShwAYUoUAAAAAAAAAAAAAAAAAAAAPABBQPL/oQA8AAwAFgBEAGUAZgBhAHUAbAB0ACAAUABh AHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAAAAAAAAAAAAAAAAAAAMAAAAGAAAACQAAAApAAAA MAAAADkAAABCAAAASwAAAFQAAABjAAAAfAAAAJIAAACoAAAAxwAAANYAAADfAAAA6AAAAPEAAAD6 AAAAAQEAAAYBAAASAQAAHgEAACoBAABnAQAAAQAAAAAAAAAAAP////8CBAAAAAAAAAEAAAAAAAAA AAD/////AwQAAAAAAAABAAAAAAAAAAAA/////wQEAAAAAAAAAQAAAAAAAAAAAP////8LBAAAAAAA AAEAAAAAAAAAAAD/////DQQAAAAAAAABAAAAAAAAAAAA/////w4EAAAAAAAAAQAAAAAAAAAAAP// //8PBAAAAAAAAAEAAAAAAAAAAAD/////EAQAAAAAAAABAAAAAAAAAAAA/////xEEAAAAAAAAAQAA AAAAAAAAAP////8SBAAAAAAAAAEAAAAAAAAAAAD/////EwQAAAAAAAABAAAAAAAAAAAA/////xUE AAAAAAAAAQAAAAAAAAAAAP////9LBAAAAAAAAAEAAAAAAAAAAAD/////SQQAAAAAAAABAAAAAAAA AAAA/////0gEAAAAAAAAAQAAAAAAAAAAAP////9HBAAAAAAAAAEAAAAAAAAAAAD/////RgQAAAAA AAABAAAAAAAAAAAA/////0UEAAAAAAAAAQAAAAAAAAAAAP////9EBAAAAAAAAAEAAAAAAAAAAAD/ ////QwQAAAAAAAABAAAAAAAAAAAA/////0IEAAAAAAAAAQAAAAAAAAAAAP////88BAAAAAAAAAEA AAAAAAAAAAD/////OwQAAAAAAAABAAAAAAAAAAAA/////zoEAAAAAAAA/////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAMAAAAGAAAACQAAAApAAAAMAAAADkAAABCAAAASwAAAFQAAABjAAAAfAAAAJIA AACoAAAAxwAAANYAAADfAAAA6AAAAPEAAAD6AAAAAQEAAAYBAAASAQAAHgEAACoBAAAtAQAAAAAA AAAIAQAAAAAIAgAAAAAIAwAAAAAIBAAAAAAIBQAAAAAIBgAAAAAIBwAAAAAICAAAAAAICQAAAAAI CgAAAAAICwAAAAAIDAAAAAAIDQAAAAAIDgAAAAAIDwAAAAAIEAAAAAAIEQAAAAAIEgAAAAAIEwAA AAAIFAAAAAAIFQAAAAAIFgAAAAAIFwAAAAAI//8AAAAAAAAAAGcBAAAGAAAQAAAAAP////8AAAAA HQAAADsAAABGAAAARwAAAFIAAABTAAAAXgAAAF8AAABjAAAAZAAAAGoAAABrAAAAcwAAAHQAAAB8 AAAAfQAAAIUAAACGAAAAjgAAAI8AAACdAAAAngAAALYAAAC3AAAAzAAAAM0AAADiAAAA4wAAAAEB AAACAQAAEAEAABEBAAAZAQAAGgEAACIBAAAjAQAAKwEAACwBAAA0AQAANQEAADsBAAA8AQAAQAEA AEEBAABMAQAATQEAAFgBAABZAQAAZAEAAGUBAABoAQAACAAAAAEwAAAAAAAAAIAAAACAGgECIAIw AAAAAAAAAIAAAAAAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAA AAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAA AIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAA AACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACA mAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAA AAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAA AAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAA AIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAA AACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACA mgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAA AAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAw AAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAA AAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAA AIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAA AACAmgAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAAAQAAGcFAAAEAAAAAAQAAOME AABnBQAABQAAAAcAAAAABAAAZgUAAAYAAAAPAADwOAAAAAAABvAYAAAAAggAAAIAAABLAAAAAQAA AAEAAABMAAAAQAAe8RAAAAD//wAAAAD/AICAgAD3AAAQAA8AAvC+DAAAEAAI8AgAAAAlAAAASwQA AA8AA/D0CwAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAA DwAE8EgAAAASAArwCAAAAAIEAAAACgAAIwAL8AwAAACAAAAAAQCKAAIEAAAAABDwBAAAAAkAAAAA ABHwBAAAAAkAAAAAAA3wBAAAAAAAAQAPAATwSAAAABIACvAIAAAAAwQAAAAKAAAjAAvwDAAAAIAA AAACAIoAAwQAAAAAEPAEAAAACwAAAAAAEfAEAAAADgAAAAAADfAEAAAAAAACAA8ABPBIAAAAEgAK 8AgAAAAEBAAAAAoAACMAC/AMAAAAgAAAAAMAigAEBAAAAAAQ8AQAAAAKAAAAAAAR8AQAAAANAAAA AAAN8AQAAAAAAAMADwAE8EgAAABCAQrwCAAAAAYEAACACgAAQwAL8BgAAABEAQQAAAB/AQAAAQC/ AQAAEAD/ARAAEAAAABDwBAAAAAcAAAAAABHwBAAAAAoAAAAPAATwSAAAAEIBCvAIAAAABwQAAIAK AABDAAvwGAAAAEQBBAAAAH8BAAABAL8BAAAQAP8BEAAQAAAAEPAEAAAACAAAAAAAEfAEAAAADAAA AA8ABPBIAAAAQgEK8AgAAAAIBAAAgAoAAEMAC/AYAAAARAEEAAAAfwEAAAEAvwEAABAA/wEQABAA AAAQ8AQAAAAGAAAAAAAR8AQAAAAJAAAADwAE8EgAAABCAQrwCAAAAAkEAAAACgAAQwAL8BgAAABE AQQAAAB/AQAAAQC/AQAAEAD/ARAAEAAAABDwBAAAAAUAAAAAABHwBAAAAAgAAAAPAATwSAAAAEIB CvAIAAAACgQAAIAKAABDAAvwGAAAAEQBBAAAAH8BAAABAL8BAAAQAP8BEAAQAAAAEPAEAAAABAAA AAAAEfAEAAAACAAAAA8ABPBCAAAAEgAK8AgAAAALBAAAAAoAABMAC/AGAAAAgAAAAAQAAAAQ8AQA AAAOAAAAAAAR8AQAAAAKAAAAAAAN8AQAAAAAAAQADwAE8GYAAADyAwrwCAAAAA0EAAAACgAAcwAL 8CoAAACAAAAABQCKAA0EAABHAfMwAABIAYjD//+BAf//AAC/ARAAEAB/AwAADAAAABDwBAAAABAA AAAAABHwBAAAAAwAAAAAAA3wBAAAAAAABQAPAATwSAAAABIACvAIAAAADgQAAAAKAAAjAAvwDAAA AIAAAAAGAIoADgQAAAAAEPAEAAAAAwAAAAAAEfAEAAAADwAAAAAADfAEAAAAAAAGAA8ABPBIAAAA EgAK8AgAAAAPBAAAAAoAACMAC/AMAAAAgAAAAAcAigAPBAAAAAAQ8AQAAAACAAAAAAAR8AQAAAAL AAAAAAAN8AQAAAAAAAcADwAE8EgAAAASAArwCAAAABAEAAAACgAAIwAL8AwAAACAAAAACACKABAE AAAAABDwBAAAAAEAAAAAABHwBAAAAAsAAAAAAA3wBAAAAAAACAAPAATwSAAAABIACvAIAAAAEQQA AAAKAAAjAAvwDAAAAIAAAAAJAIoAEQQAAAAAEPAEAAAAAAAAAAAAEfAEAAAACwAAAAAADfAEAAAA AAAJAA8ABPBgAAAA8gMK8AgAAAASBAAAAAoAAGMAC/AkAAAAgAAAAAoARwEhmAAASAHgBgAAgQH/ /wAAvwEQABAAfwMAAAwAAAAQ8AQAAAARAAAAAAAR8AQAAAALAAAAAAAN8AQAAAAAAAoADwAE8EIA AAASAArwCAAAABMEAAAACgAAEwAL8AYAAACAAAAACwAAABDwBAAAAA8AAAAAABHwBAAAAA0AAAAA AA3wBAAAAAAACwAPAATwSAAAAEIBCvAIAAAAFAQAAIAKAABDAAvwGAAAAEQBBAAAAH8BAAABAL8B AAAQAP8BEAAQAAAAEPAEAAAADQAAAAAAEfAEAAAACAAAAA8ABPBgAAAA8gMK8AgAAAAVBAAAAAoA AGMAC/AkAAAAgAAAAAwARwEgcwAASAEY6P//gQH//wAAvwEQABAAfwMAAAwAAAAQ8AQAAAAMAAAA AAAR8AQAAAAKAAAAAAAN8AQAAAAAAAwADwAE8EgAAAASAArwCAAAADoEAAAACgAAIwAL8AwAAACA AAAAGACKADoEAAAAABDwBAAAACMAAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAAGAAPAATwSAAAABIA CvAIAAAAOwQAAAAKAAAjAAvwDAAAAIAAAAAXAIoAOwQAAAAAEPAEAAAAIgAAAAAAEfAEAAAAAwAA AAAADfAEAAAAAAAXAA8ABPBIAAAAEgAK8AgAAAA8BAAAAAoAACMAC/AMAAAAgAAAABYAigA8BAAA AAAQ8AQAAAAhAAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAABYADwAE8EgAAABCAQrwCAAAAD0EAACA CgAAQwAL8BgAAABEAQQAAAB/AQAAAQC/AQAAEAD/ARAAEAAAABDwBAAAACAAAAAAABHwBAAAAAMA AAAPAATwSAAAAEIBCvAIAAAAPgQAAIAKAABDAAvwGAAAAEQBBAAAAH8BAAABAL8BAAAQAP8BEAAQ AAAAEPAEAAAAHwAAAAAAEfAEAAAAAwAAAA8ABPBIAAAAQgEK8AgAAAA/BAAAgAoAAEMAC/AYAAAA RAEEAAAAfwEAAAEAvwEAABAA/wEQABAAAAAQ8AQAAAAeAAAAAAAR8AQAAAADAAAADwAE8EgAAABC AQrwCAAAAEAEAAAACgAAQwAL8BgAAABEAQQAAAB/AQAAAQC/AQAAEAD/ARAAEAAAABDwBAAAAB0A AAAAABHwBAAAAAMAAAAPAATwSAAAAEIBCvAIAAAAQQQAAIAKAABDAAvwGAAAAEQBBAAAAH8BAAAB AL8BAAAQAP8BEAAQAAAAEPAEAAAAHAAAAAAAEfAEAAAAAwAAAA8ABPBCAAAAEgAK8AgAAABCBAAA AAoAABMAC/AGAAAAgAAAABUAAAAQ8AQAAAAbAAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAABUADwAE 8GYAAADyAwrwCAAAAEMEAAAACgAAcwAL8CoAAACAAAAAFACKAEMEAABHAfMwAABIAYjD//+BAf// AAC/ARAAEAB/AwAADAAAABDwBAAAABoAAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAAFAAPAATwSAAA ABIACvAIAAAARAQAAAAKAAAjAAvwDAAAAIAAAAATAIoARAQAAAAAEPAEAAAAGQAAAAAAEfAEAAAA AwAAAAAADfAEAAAAAAATAA8ABPBIAAAAEgAK8AgAAABFBAAAAAoAACMAC/AMAAAAgAAAABIAigBF BAAAAAAQ8AQAAAAYAAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAABIADwAE8EgAAAASAArwCAAAAEYE AAAACgAAIwAL8AwAAACAAAAAEQCKAEYEAAAAABDwBAAAABcAAAAAABHwBAAAAAMAAAAAAA3wBAAA AAAAEQAPAATwSAAAABIACvAIAAAARwQAAAAKAAAjAAvwDAAAAIAAAAAQAIoARwQAAAAAEPAEAAAA FgAAAAAAEfAEAAAAAwAAAAAADfAEAAAAAAAQAA8ABPBgAAAA8gMK8AgAAABIBAAAAAoAAGMAC/Ak AAAAgAAAAA8ARwEhmAAASAHgBgAAgQH//wAAvwEQABAAfwMAAAwAAAAQ8AQAAAAVAAAAAAAR8AQA AAADAAAAAAAN8AQAAAAAAA8ADwAE8EIAAAASAArwCAAAAEkEAAAACgAAEwAL8AYAAACAAAAADgAA ABDwBAAAABQAAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAADgAPAATwSAAAAEIBCvAIAAAASgQAAIAK AABDAAvwGAAAAEQBBAAAAH8BAAABAL8BAAAQAP8BEAAQAAAAEPAEAAAAEwAAAAAAEfAEAAAAAwAA AA8ABPBgAAAA8gMK8AgAAABLBAAAAAoAAGMAC/AkAAAAgAAAAA0ARwEMxP//SAE2AgAAgQH//wAA vwEQABAAfwMAAAwAAAAQ8AQAAAASAAAAAAAR8AQAAAADAAAAAAAN8AQAAAAAAA0ADwAE8EIAAAAS AArwCAAAAAEEAAAADgAAUwAL8B4AAAC/AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/AwEAAQAAABHw BAAAAAEAAABvAAXwYAAAAAAAF/AIAAAAAgAAAA0EAAAAABfwCAAAAAMAAAASBAAAAAAX8AgAAAAF AAAAFQQAAAAAF/AIAAAADAAAAEMEAAAAABfwCAAAAA0AAABIBAAAAAAX8AgAAAAOAAAASwQAAAAA AAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAA AA8AAAAQAAAAEQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAA KQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAAGcBAAARBAAA6BcAAGwbAAAgHAAA1BwAAHQAAQAA ABAEAAD8EgAAbBsAADQXAADUHAAAdAABAAAADwQAABAOAAC4GgAASBIAACAcAAB0AAEAAAAOBAAA 9AsAAFAZAAAsEAAAuBoAAHQAAQAAAAoEAACwEwAAqAwAALATAADgEAAAdAAAAAAACQQAAIwKAADg EAAA1BwAAOAQAAB0AAAAAAAIBAAAjAoAAOAQAACMCgAAzBUAAHQAAAAAAAYEAACwEwAA4BAAALAT AADMFQAAdAAAAAAABwQAANQcAADgEAAA1BwAAMwVAAB0AAAAAAACBAAAcAgAAMwVAADEDgAANBcA AHQAAQAAAAQEAAAEGgAAzBUAAFggAAA0FwAAdAABAAAAAwQAAOAQAADMFQAANBcAADQXAAB0AAEA AAAVBAAAHAIAAOAQAAAkCQAAzBUAAHQAAAAAABQEAAAQDgAAeA8AABAOAADgEAAAdAAAAAAACwQA APwSAABACwAAUBkAAKgMAAB0AAAAAAATBAAACAcAABAOAACUEQAAeA8AAHQAAAAAAA0EAAD0CwAA SBIAAFAZAABkFAAAdAABAAAAEgQAANACAADoFwAAjAoAAAQaAAB0AAAAAABLBAAABBoAAPQLAAAM IQAA4BAAAHQAAAAAAEoEAADYCQAAeA8AANgJAADgEAAAdAAAAAAASQQAAOT9//8QDgAAjAoAAHgP AAB0AAAAAABIBAAAmP7//+gXAABUBgAABBoAAHQAAAAAAEcEAACwEwAAbBsAAOgXAADUHAAAdAAB AAAARgQAAMQOAABsGwAA/BIAANQcAAB0AAEAAABFBAAA2AkAALgaAAAQDgAAIBwAAHQAAQAAAEQE AAC8BwAAUBkAAPQLAAC4GgAAdAABAAAAQwQAALwHAABIEgAAGBUAAGQUAAB0AAEAAABCBAAAxA4A AEALAAAYFQAAqAwAAHQAAAAAAEEEAAB4DwAAqAwAAHgPAADgEAAAdAAAAAAAQAQAAFQGAADgEAAA nBgAAOAQAAB0AAAAAAA/BAAAVAYAAOAQAABUBgAAzBUAAHQAAAAAAD4EAACcGAAA4BAAAJwYAADM FQAAdAAAAAAAPQQAAHgPAADgEAAAeA8AAMwVAAB0AAAAAAA8BAAAzBUAAMwVAAAgHAAANBcAAHQA AQAAADsEAACoDAAAzBUAAPwSAAA0FwAAdAABAAAAOgQAADgEAADMFQAAjAoAADQXAAB0AAEAAAAA AAAAOwAAAG8AAAByAAAAeAAAAHsAAACBAAAAhAAAAB4BAAAhAQAAJwEAACoBAAAwAQAAMwEAAGgB AAAHAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAAAAAADsAAABoAQAABwAHAAAAAAAAAAAAAQAA AAEAAAACAAAAAgAAAAMAAAADAAAABAAAAAQAAAAFAAAABQAAAAYAAAAGAAAABwAAAAcAAAAIAAAA CAAAAAkAAAAJAAAACgAAAAoAAAALAAAACwAAAAwAAAANAAAADgAAAA4AAAAPAAAADwAAABAAAAAQ AAAAEQAAABEAAAASAAAAOgAAADsAAABFAAAARgAAAEYAAABHAAAAYwEAAGQBAABlAQAAaAEAAAQA AwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAAD AAQAAwAEAAMABAAHAAQAAwAEAAMABAADAAQAAwD//wQAAAALAFMAaABhAGgALAAgAFMAYQBwAGEA bgBkAEMAOgBcAEQAbwBjAHUAbQBlAG4AdABzACAAYQBuAGQAIABTAGUAdAB0AGkAbgBnAHMAXABu AGcAcAB0AGEAaABzAFwAQQBwAHAAbABpAGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIA bwBzAG8AZgB0AFwAVwBvAHIAZABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAg AG8AZgAgAEQAbwBjAHUAbQBlAG4AdAAxAC4AYQBzAGQACwBTAGgAYQBoACwAIABTAGEAcABhAG4A NgBEADoAXAB1AHMAZQByAHMAXABuAGcAcAB0AGEAaABzAFwATQB5ACAARABvAGMAdQBtAGUAbgB0 AHMAXABDAGwAYQByAGkAZgB5AGkAbgBnACAAUwBjAGUAbgBhAHIAaQBvAHMALgBkAG8AYwABALpV ymiIZgAh/w8CAP8P/w//D/8P/w//D/8PAAABAAAAABABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4Ro ARGEmP4VxgUAAWgBBl6EaAFghJj+AgAAAC4AAQAAAAAQAQMAAAAAAAAAAAAAAAAAAAAAABgAAA+E GAMRhFD+FcYFAAEYAwZehBgDYIRQ/gQAAAAuAAEALgABAAAAABABAwUAAAAAAAAAAAAAAAAAAAAA GAAAD4TIBBGECP4VxgUAAaAFBl6EyARghAj+BgAAAC4AAQAuAAIALgABAAAAABABAwUHAAAAAAAA AAAAAAAAAAAAGAAAD4TABhGEeP0VxgUAAQgHBl6EwAZghHj9CAAAAC4AAQAuAAIALgADAC4AAQAA AAAQAQMFBwkAAAAAAAAAAAAAAAAAABgAAA+EuAgRhOj8FcYFAAHYCQZehLgIYITo/AoAAAAuAAEA LgACAC4AAwAuAAQALgABAAAAABABAwUHCQsAAAAAAAAAAAAAAAAAGAAAD4SwChGEWPwVxgUAAUAL Bl6EsApghFj8DAAAAC4AAQAuAAIALgADAC4ABAAuAAUALgABAAAAABABAwUHCQsNAAAAAAAAAAAA AAAAGAAAD4SoDBGEyPsVxgUAARAOBl6EqAxghMj7DgAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAG AC4AAQAAAAAQAQMFBwkLDQ8AAAAAAAAAAAAAABgAAA+EoA4RhDj7FcYFAAF4DwZehKAOYIQ4+xAA AAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgABAAAAABABAwUHCQsNDxEAAAAAAAAAAAAA GAAAD4TgEBGEYPoVxgUAAUgSBl6E4BBghGD6EgAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4A BwAuAAgALgACAAAAulXKaAAAAAAAAAAAAAAAALpVymgAAAAAAAAAAAAAAAD/////////////AQAA AAAA//8BAAAAAAD/QAMAAAAeAAAAOgAAAHCOdAABAGgAOgAAAAEAAAA6AAAAAAAAAAIQAAAAAAAA AGcBAABgAAAIAEAAAP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA//8BAAAA AAD//wAAAgD//wAAAAD//wAAAgD//wAAAAAEAAAARxaQAQAAAgIGAwUEBQIDBId6ACAAAACACAAA AAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEH BgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgIC BId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAAAEEmkAEAAAILBgMCAgICAgQHAAAA AAAAAAAAAAAAAAAAEwAAAAAAAABUAHIAZQBiAHUAYwBoAGUAdAAgAE0AUwAAACIABABxCIgYAPDQ AgAAaAEAAAAAOp2RZlKdkWYAAAAAAQAUAAAACAAAADAAAAABAAEAAAAEAAMQAQAAAAAAAAAAAAAA AQABAAAAAQAAAAAAAAAhAwDwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIB6AFtAC0AIGB cjAAAAAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAygxEA8BAACAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD//xIAAAAAAAAACgBTAGMAZQBuAGEAcgBpAG8AIAAxAAAAAAAA AAsAUwBoAGEAaAAsACAAUwBhAHAAYQBuAAsAUwBoAGEAaAAsACAAUwBhAHAAYQBuAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADg hZ/y+U9oEKuRCAArJ7PZMAAAAHgBAAARAAAAAQAAAJAAAAACAAAAmAAAAAMAAACsAAAABAAAALgA AAAFAAAAzAAAAAYAAADYAAAABwAAAOQAAAAIAAAA+AAAAAkAAAAMAQAAEgAAABgBAAAKAAAANAEA AAwAAABAAQAADQAAAEwBAAAOAAAAWAEAAA8AAABgAQAAEAAAAGgBAAATAAAAcAEAAAIAAADkBAAA HgAAAAsAAABTY2VuYXJpbyAxAAAeAAAAAQAAAABjZW4eAAAADAAAAFNoYWgsIFNhcGFuAB4AAAAB AAAAAGhhaB4AAAABAAAAAGhhaB4AAAALAAAATm9ybWFsLmRvdAAAHgAAAAwAAABTaGFoLCBTYXBh bgAeAAAAAgAAADEAYWgeAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDkuMAAAQAAAAAB4QcsCAAAAQAAA AAAE/neT/sQBQAAAAAB8P0OW/sQBAwAAAAEAAAADAAAACAAAAAMAAAAwAAAAAwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQACAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1ZwuGxCT lwgAKyz5rjAAAAAEAQAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAjAAAAAYAAACUAAAAEQAAAJwA AAAXAAAApAAAAAsAAACsAAAAEAAAALQAAAATAAAAvAAAABYAAADEAAAADQAAAMwAAAAMAAAA4wAA AAIAAADkBAAAHgAAABQAAABHRSBBaXJjcmFmdCBFbmdpbmVzAAMAAAABAAAAAwAAAAEAAAADAAAA OgAAAAMAAADAHQkACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAAsAAABT Y2VuYXJpbyAxAAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAD+////CgAAAAsAAAAM AAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoA AAAbAAAA/v///x0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAD+////JQAAACYAAAAnAAAAKAAA ACkAAAAqAAAAKwAAAP7////9////LgAAAP7////+/////v////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAA AAAAAADgSaRilv7EATAAAACAAAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIA////////////////AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAAAJokAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0A ZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEFAAAA//// //////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIhAAAAAAAAAFAFMA dQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAKAACAQIAAAAEAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwA AAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAJAAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgEBAAAABgAAAP////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAagAAAAAAAABPAGIAagBlAGMAdABQAG8AbwBs AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgABAP////////// /////wAAAAAAAAAAAAAAAAAAAAAAAAAA4EmkYpb+xAHgSaRilv7EAQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAQAAAP7///////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkIERv Y3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA== ------=_20050119223106_24110 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid ------=_20050119223106_24110-- From rfid-bounces@ietf.org Wed Jan 19 22:28:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25899; Wed, 19 Jan 2005 22:28:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrTFH-0008GM-Dc; Wed, 19 Jan 2005 22:44:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrSxI-0002Iv-0R; Wed, 19 Jan 2005 22:25:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrSwl-0002D1-Ml for rfid@megatron.ietf.org; Wed, 19 Jan 2005 22:25:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25784 for ; Wed, 19 Jan 2005 22:25:21 -0500 (EST) Received: from ms08.mse3.exchange.ms ([69.25.50.144]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrTCM-0008Cs-Cp for rfid@ietf.org; Wed, 19 Jan 2005 22:41:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Jan 2005 22:27:50 -0500 Message-ID: <0E03681B885F3B4296B999E34435A16E3DF6EE@ms08.mse3.exchange.ms> Thread-Topic: A few fundamental questions Thread-Index: AcT+oATQcociGm3EQXGlK8Y641gs8A== From: "P. Krishna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 32a65c0bf5eb4ec26489239c7cdd0636 Subject: [Rfid] Re: A few fundamental questions X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0229059618==" Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 This is a multi-part message in MIME format. --===============0229059618== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FEA0.04D2E360" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4FEA0.04D2E360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Tue, 2005-01-18 at 15:31, Sapan Shah wrote: > Krishna, > > I did go through the draft documents and it does look intersting. > However > have a few questions before I can move on with contributing on the > specs. > Sapan, First off, thank you for taking the time to read the draft. Now to your questions ... > I am considering a hetrogenous environment with readers of multiple > brands > and multiple standards installed in the same facility - so as to > leverage > the max out of the protocol specs and find out what can be missing - = if > there is anything. > > Let us say, we have like 3 readers that follow EPc Standards and 3 > Readers > that follow ISO Standards. The Reader Network Controller - as the > definition suggests will be / can be a software server as well. If we > take > this into consideration then on the EPC Front, The Device Management > Layer > within ALE / The RM and RP will be taking care of all the commands to = be > sent out to the reader. What is left out, will be the ISO Standards - > which the RNC will be commanding. The EPc Standards, I dont think will > support the RNC. > > Although, the IP based configuration that we are trying to specify = over > here is different in the aspects of Binary data being conveyed through > IP > Packets, would not it be a complicated situation, when the standards = are > recognized and accepted? I mean, If There are EPC Standards / > Middlewares > that already have their readers up and running on the network and they > accept commands in a specific format. How do we plan to merge > applications > with them? > > Regards > Sapan You hit upon 2 basic questions: (1) Under what circumstances do you use SLRRP? Is it _only_ for multi-air-protocol or are there other circumstances too? (2) Will there be cases where SLRRP and EPC RP are deployed in the same infrastructure? Lets first address (1): Why SLRRP? a) One of the goals of SLRRP is to support all currently defined RFID air protocols and be extensible to support future air protocols. Since, it is being defined in a standards body (IETF) which is not defining air protocols, the wire-line protocol does not need to be tied to an air protocol. The other wire-line protocols defined in EPCGlobal and ISO are defined for the specific air protocols defined in their respective standards organization. But wait - multi-air-protocol support is not the only reason for using SLRRP. b) Support for diversity of reader control requirements is the other aspect. On one end of the spectrum are readers which when provided some hints of the target singulation/RF environment from the RNC can autonomously control the air-protocol/RF parameters. On the other end of spectrum are readers that require real-time hand-holding in terms of air-protocol/RF parameters. And there is a continuum in between the two ends of spectrum in terms of reader control capabilities. Now why is reader control important? If there is just one reader in the facility and you have an application connected to it, it doesn't matter how the reader is using up the RF cycles to perform its task. However, as you increase the number of readers in the facility, and if each reader has a task to perform, then they start contending for the RF bandwidth. The RF control aspect is important enough that the new air protocol Class 1 Gen 2 (currently under the EPCGlobal umbrella, and soon to be passed over to ISO for consideration as an ISO standard) has incorporated a number of knobs that can be controlled to efficiently use the RF spectrum. None of the other standard protocols provide a multi-air protocol control interface - SLRRP provides a very granular interface for control. >From the above discussion it may seem that SLRRP is only relevant in multi-reader environment. But thats not true either. c) Diversity of application requirements: As you are very well aware (from your epcis participation), that there are going to be a number of applications that would be interested in accessing the RFID infrastructure - access may mean visibility into the (synthesized or raw) tag read data and/or performing other tag updates (lock/unlock/writes/kill). There are two ends of the spectrum in terms of implementing business logic based access rules/requirements. One end is the application-assisted, and the other end is the autonomous. Let me illustrate it using an example. For example, if the business logic requires that whenever a tag with a prefix of 'foo' shows up, the reader has to read the user memory area of that tag. Using the application-assist mode: The reader reports to the application whenever it sees a matching tag, and then the application sends a read command to read the user memory. The reader may then have to re-singulate the tag, read the user memory and then report the result back to the application. Using the autonomous mode: An access-spec is created in the reader that describes the target-tag and the operation to be performed on that tag. So, whenever the reader sees the matching tag, it autonomously performs the access operation then and there and sends the result back to the application/server. As deployments scale up in terms of tag traffic (volume), it should be clear which would be the preferable approach. None of the standards provide an interface to create/manage 'access-specs' at the readers. The irony is that in private some reader vendors have admitted that this is good and required (or are in the process of implementing such interfaces) - but its not reflected in any of the standards. Now coming to question (2): You provided an interesting scenario where in a facility there are readers talking SLRRP to the server and the other readers talking EPC RP to the server. You would want EPC RP for the subset of readers in the facility to which the applications wanted to talk directly over http/xml; and those readers were operating in a RF shielded environment and hence did not require RF control, air-protocol control; and, if only operations to be performed are reading/writing/killing tags; and if you wanted access operations to be performed in an 'application-assisted' mode. If all the above were true for all the readers in the facility, then yes we would converge to using EPC RP - except of course we wont be able to talk to those ISO readers in your example! Please feel free to ask more questions. Looking forward to more discussions. Thanks & Regards, Krishna ------_=_NextPart_001_01C4FEA0.04D2E360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
=0A=

On Tue, 2005-01-18 at 15:31, Sapan Shah wrote:
> =0A= Krishna,
>
> I did go through the draft documents and it = does look =0A= intersting.
> However
> have a few questions before I can = move on =0A= with contributing on the
> specs.
>

Sapan,
First = off, =0A= thank you for taking the time to read the draft. Now to = your
questions =0A= ...

> I am considering a hetrogenous environment with readers = of =0A= multiple
> brands
> and multiple standards installed in the = same =0A= facility - so as to
> leverage
> the max out of the protocol = specs =0A= and find out what can be missing - if
> there is = anything.
>
> =0A= Let us say, we have like 3 readers that follow EPc Standards and = 3
> =0A= Readers
> that follow ISO Standards. The Reader Network Controller = - as =0A= the
> definition suggests will be / can be a software server as = well. If =0A= we
> take
> this into consideration then on the EPC Front, = The =0A= Device Management
> Layer
> within ALE / The RM and RP will = be =0A= taking care of all the commands to be
> sent out to the reader. = What is =0A= left out, will be the ISO Standards -
> which the RNC will be = commanding. =0A= The EPc Standards, I dont think will
> support the = RNC.
>
> =0A= Although, the IP based configuration that we are trying to specify = over
> =0A= here is different in the aspects of Binary data being conveyed = through
> =0A= IP
> Packets, would not it be a complicated situation, when the = standards =0A= are
> recognized and accepted? I mean, If There are EPC Standards =0A= /
> Middlewares
> that already have their readers up and = running on =0A= the network and they
> accept commands in a specific format. How = do we =0A= plan to merge
> applications
> with them?
>
> =0A= Regards
> Sapan

You hit upon 2 basic questions:
(1) = Under what =0A= circumstances do you use SLRRP? Is it _only_ for
multi-air-protocol = or are =0A= there other circumstances too?

(2) Will there be cases where = SLRRP and =0A= EPC RP are deployed in the same
infrastructure?

Lets first = address =0A= (1): Why SLRRP?
a) One of the goals of SLRRP is to support all = currently =0A= defined RFID
air protocols and be extensible to support future air = protocols. =0A= Since,
it is being defined in a standards body (IETF) which is not = defining =0A= air
protocols, the wire-line protocol does not need to be tied to an =0A= air
protocol. The other wire-line protocols defined in EPCGlobal and = ISO =0A= are
defined for the specific air protocols defined in their =0A= respective
standards organization.

But wait - = multi-air-protocol =0A= support is not the only reason for using
SLRRP.

b) Support for =0A= diversity of reader control requirements is the other
aspect. On one = end of =0A= the spectrum are readers which when provided some
hints of the target =0A= singulation/RF environment from the RNC can
autonomously control the =0A= air-protocol/RF parameters. On the other end of
spectrum are readers = that =0A= require real-time hand-holding in terms of
air-protocol/RF = parameters. And =0A= there is a continuum in between the two
ends of spectrum in terms of = reader =0A= control capabilities.

Now why is reader control important?
If = there is =0A= just one reader in the facility and you have an application
connected = to it, =0A= it doesn't matter how the reader is using up the RF
cycles to perform = its =0A= task. However, as you increase the number of
readers in the facility, = and if =0A= each reader has a task to perform, then
they start contending for the = RF =0A= bandwidth. The RF control aspect is
important enough that the new air =0A= protocol Class 1 Gen 2 (currently
under the EPCGlobal umbrella, and = soon to =0A= be passed over to ISO for
consideration as an ISO standard) has = incorporated =0A= a number of knobs
that can be controlled to efficiently use the RF =0A= spectrum.

None of the other standard protocols provide a = multi-air =0A= protocol
control interface - SLRRP provides a very granular interface =0A= for
control.

From the above discussion it may seem that SLRRP = is only =0A= relevant in
multi-reader environment. But thats not true = either.

c) =0A= Diversity of application requirements: As you are very well = aware
(from your =0A= epcis participation), that there are going to be a number = of
applications =0A= that would be interested in accessing the RFID
infrastructure - = access may =0A= mean visibility into the (synthesized or
raw) tag read data and/or = performing =0A= other tag updates
(lock/unlock/writes/kill). There are two ends of = the =0A= spectrum in terms
of implementing business logic based access =0A= rules/requirements. One end
is the application-assisted, and the = other end is =0A= the autonomous. Let me
illustrate it using an example.

For = example, if =0A= the business logic requires that whenever a tag with a
prefix of = 'foo' shows =0A= up, the reader has to read the user memory area of
that = tag.

Using the =0A= application-assist mode: The reader reports to the = application
whenever it =0A= sees a matching tag, and then the application sends a read
command to = read =0A= the user memory. The reader may then have to
re-singulate the tag, = read the =0A= user memory and then report the result
back to the = application.

Using =0A= the autonomous mode: An access-spec is created in the reader = that
describes =0A= the target-tag and the operation to be performed on that tag.
So, = whenever =0A= the reader sees the matching tag, it autonomously performs
the access =0A= operation then and there and sends the result back to =0A= the
application/server.

As deployments scale up in terms of = tag =0A= traffic (volume), it should be
clear which would be the preferable =0A= approach.

None of the standards provide an interface to =0A= create/manage
'access-specs' at the readers. The irony is that in = private =0A= some reader
vendors have admitted that this is good and required (or = are in =0A= the
process of implementing such interfaces) - but its not reflected = in =0A= any
of the standards.


Now coming to question (2):
You = provided =0A= an interesting scenario where in a facility there are
readers talking = SLRRP =0A= to the server and the other readers talking EPC RP
to the = server.

You =0A= would want EPC RP for the subset of readers in the facility to = which
the =0A= applications wanted to talk directly over http/xml; and those
readers = were =0A= operating in a RF shielded environment and hence did not
require RF = control, =0A= air-protocol control; and, if only operations to be
performed are =0A= reading/writing/killing tags; and if you wanted access
operations to = be =0A= performed in an 'application-assisted' mode.

If all the above = were true =0A= for all the readers in the facility, then yes
we would converge to = using EPC =0A= RP - except of course we wont be able to
talk to those ISO readers in = your =0A= example!

Please feel free to ask more questions. Looking forward = to =0A= more
discussions.

Thanks & =0A= Regards,
Krishna

------_=_NextPart_001_01C4FEA0.04D2E360-- --===============0229059618== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid --===============0229059618==-- From rfid-bounces@ietf.org Thu Jan 20 23:25:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14640; Thu, 20 Jan 2005 23:25:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrqcA-0006Oh-JZ; Thu, 20 Jan 2005 23:41:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrqIi-0000Ew-DR; Thu, 20 Jan 2005 23:21:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrpdM-0002g6-P0 for rfid@megatron.ietf.org; Thu, 20 Jan 2005 22:38:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11250 for ; Thu, 20 Jan 2005 22:38:49 -0500 (EST) Received: from ms08.mse3.exchange.ms ([69.25.50.144]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crpt9-0005Nq-AS for rfid@ietf.org; Thu, 20 Jan 2005 22:55:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C4FF6B.0D1B4A04" Subject: RE: [Rfid] Re: A few fundamental questions Date: Thu, 20 Jan 2005 22:41:11 -0500 Message-ID: <0E03681B885F3B4296B999E34435A16E3DF6F8@ms08.mse3.exchange.ms> X-MS-Has-Attach: yes Thread-Topic: [Rfid] Re: A few fundamental questions Thread-Index: AcT/aUBlqyCj6EkFQw2UhTmwStdRPw== From: "P. Krishna" To: "Sapan Shah" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a1acaa54b4cde5ab4439a319e9b7f91 X-Mailman-Approved-At: Thu, 20 Jan 2005 23:21:08 -0500 Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 19fc2b47780353ba1ee25032fbc339e7 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4FF6B.0D1B4A04 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C4FF6B.0D1B4A04" ------_=_NextPart_002_01C4FF6B.0D1B4A04 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Great questions again Sapan. =20 I've updated the diagrams with my changes. RNC is not a dedicated = hardware - nor are we introducing or specifying new elements into the = network to support SLRRP. We coined the term RNC (reader control) to = differentiate it from the traditional middleware functions (tag data = processing). In both your diagrams, the RNC can be part of the = middleware. The RNC is control and the data path interface for SLRRP - = so if the middleware is the first-hop consumer of tag data from the = reader, then obviously RNC is residing in the middleware. =20 As you can observe in the diagrams, I have shown some examples of = EPC-based standards as the northbound interface of the middleware. =20 The other point you bring out in your diagrams which is quite orthogonal = to this discussion. Its just FYI - there are readers in the marketplace = that are 'multi-protocol' which means they are capable of inventorying = tags of multiple protocols - however, the interface to them is not RP or = any ISO protocol. The vendors have proprietary interface.=20 =20 Thanks, /Krishna ________________________________ From: Sapan Shah [mailto:sapan.shah@patni.com] Sent: Wed 1/19/2005 10:31 PM To: Sapan Shah Cc: P. Krishna; rfid@ietf.org Subject: Re: [Rfid] Re: A few fundamental questions Further, I am attaching a diagram that I thought would help me clearing up with = my doubts. > > Krishna, > > I am confused - I believe SLRPP is for the communication between the > reader and the RNC - a software application - as I take or a router, = for > example. > > =3D=3D > Why would any air protocol matter to me? The readers are a set of = devices > which would have their own embedded code that will have the algorithm = for > interacting with/through the air protocol for reading the tags. > > As long as I have my reader on the network and my RNC (Any software = that > wants to read and process the tag list further) is able to send = commands > to the Reader, why would it matter to me as to what and how many air > protocols are defined? I agree that RNC would be needed to control the > read cycles so as to optimize the "Reader Network" efficiency, but = again > it doest it depend on the "air-protocols" per se'? > > I mean, All I would expect is sending a binary / ascii command to the > reader and it responding back to me and the algorithm would be with me = to > contrl the network- Please correct me I am wrong. > > > > Regards > Sapan > > Sapan Shah > Patni Computer Systems Ltd > http://www.patni.com > 513-243-9071 > > > >> On Tue, 2005-01-18 at 15:31, Sapan Shah wrote: >>> Krishna, >>> >>> I did go through the draft documents and it does look intersting. >>> However >>> have a few questions before I can move on with contributing on the >>> specs. >>> >> >> Sapan, >> First off, thank you for taking the time to read the draft. Now to = your >> questions ... >> >>> I am considering a hetrogenous environment with readers of multiple >>> brands >>> and multiple standards installed in the same facility - so as to >>> leverage >>> the max out of the protocol specs and find out what can be missing - = if >>> there is anything. >>> >>> Let us say, we have like 3 readers that follow EPc Standards and 3 >>> Readers >>> that follow ISO Standards. The Reader Network Controller - as the >>> definition suggests will be / can be a software server as well. If = we >>> take >>> this into consideration then on the EPC Front, The Device Management >>> Layer >>> within ALE / The RM and RP will be taking care of all the commands = to >>> be >>> sent out to the reader. What is left out, will be the ISO Standards = - >>> which > > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid > ------_=_NextPart_002_01C4FF6B.0D1B4A04 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [Rfid] Re: A few fundamental questions=0A= =0A= =0A=
=0A=
Great = questions again =0A= Sapan.
=0A=
 
=0A=
I've updated the diagrams = with my changes. =0A= RNC is not a dedicated hardware - nor are we introducing or specifying = new =0A= elements into the network to support SLRRP. We coined the term RNC = (reader =0A= control) to differentiate it from the traditional middleware functions = (tag data =0A= processing). In both your diagrams, the RNC can be part of the =0A= middleware. The RNC is control and the data path interface for SLRRP - = so if the =0A= middleware is the first-hop consumer of tag data from the reader, then = obviously =0A= RNC is residing in the middleware.
=0A=
 
=0A=
As you can observe in the = diagrams, I have =0A= shown some examples of EPC-based standards as the northbound interface = of the =0A= middleware.
=0A=
 
=0A=
The other point you bring out = in your =0A= diagrams which is quite orthogonal to this discussion. Its just FYI - = there are =0A= readers in the marketplace that are 'multi-protocol' which means they = are =0A= capable of inventorying tags of multiple protocols - however, the = interface to =0A= them is not RP or any ISO protocol. The vendors = have proprietary =0A= interface.
=0A=
 
=0A=
Thanks,
=0A=
/Krishna
=0A=

=0A=
=0A= From: Sapan Shah =0A= [mailto:sapan.shah@patni.com]
Sent: Wed 1/19/2005 10:31 =0A= PM
To: Sapan Shah
Cc: P. Krishna; =0A= rfid@ietf.org
Subject: Re: [Rfid] Re: A few fundamental =0A= questions

=0A=
=0A=

Further,

I am attaching a diagram that I = thought would =0A= help me clearing up with my
doubts.



>
> =0A= Krishna,
>
> I am confused - I believe SLRPP is for the =0A= communication between the
> reader and the RNC - a software = application - =0A= as I take or a router, for
> example.
>
> = =3D=3D
> Why would =0A= any air protocol matter to me? The readers are a set of devices
> = which =0A= would have their own embedded code that will have the algorithm = for
> =0A= interacting with/through the air protocol for reading the = tags.
>
> =0A= As long as I have my reader on the network and my RNC (Any software = that
> =0A= wants to read and process the tag list further) is able to send = commands
> =0A= to the Reader, why would it matter to me as to what and how many = air
> =0A= protocols are defined? I agree that RNC would be needed to control = the
> =0A= read cycles so as to optimize the "Reader Network" efficiency, but = again
> =0A= it doest it depend on the "air-protocols" per se'?
>
> I = mean, All I =0A= would expect is sending a binary / ascii command to the
> reader = and it =0A= responding back to me and the algorithm would be with me to
> = contrl the =0A= network- Please correct me I am wrong.
>
>
>
> =0A= Regards
> Sapan
>
> Sapan Shah
> Patni Computer = Systems =0A= Ltd
> http://www.patni.com
> =0A= 513-243-9071
>
>
>
>> On Tue, 2005-01-18 at = 15:31, =0A= Sapan Shah wrote:
>>> = Krishna,
>>>
>>> I did =0A= go through the draft documents and it does look = intersting.
>>> =0A= However
>>> have a few questions before I can move on with =0A= contributing on the
>>> =0A= specs.
>>>
>>
>> Sapan,
>> First = off, =0A= thank you for taking the time to read the draft. Now to your
>> =0A= questions ...
>>
>>> I am considering a hetrogenous =0A= environment with readers of multiple
>>> = brands
>>> and =0A= multiple standards installed in the same facility - so as = to
>>> =0A= leverage
>>> the max out of the protocol specs and find out = what can =0A= be missing - if
>>> there is =0A= anything.
>>>
>>> Let us say, we have like 3 = readers =0A= that follow EPc Standards and 3
>>> Readers
>>> = that =0A= follow ISO Standards. The Reader Network Controller - as = the
>>> =0A= definition suggests will be / can be a software server as well. If =0A= we
>>> take
>>> this into consideration then on = the EPC =0A= Front, The Device Management
>>> Layer
>>> = within ALE / =0A= The RM and RP will be taking care of all the commands to
>>> =0A= be
>>> sent out to the reader. What is left out, will be the = ISO =0A= Standards -
>>> which
>
> =0A= _______________________________________________
> Rfid mailing =0A= list
> Rfid@lists.ietf.org
> https://www1.ietf.or= g/mailman/listinfo/rfid
>

=0A= =0A= =0A= ------_=_NextPart_002_01C4FF6B.0D1B4A04-- ------_=_NextPart_001_01C4FF6B.0D1B4A04 Content-Type: application/msword; name="Clarifying Scenarios.doc" Content-Transfer-Encoding: base64 Content-Description: Clarifying Scenarios.doc Content-Disposition: attachment; filename="Clarifying Scenarios.doc" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAANwAAAAAAAAAA EAAAOQAAAAEAAAD+////AAAAADYAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEANUAJBAAA8BK/AAAAAAAAEAAAAAAABgAAsAkAAA4AYmpias8yzzIAAAAAAAAAAAAAAAAAAAAA AAAJBBYAIhIAAK1YAACtWAAAPQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcgEAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAIgAAAAAAOoBAAAAAAAA6gEAAOoB AAAAAAAA6gEAAAAAAAB2BQAAAAAAAHYFAAAAAAAAdgUAABQAAAAAAAAAAAAAAIoFAAAAAAAA7gsA AAAAAADuCwAAAAAAAO4LAAAAAAAA7gsAAAwAAAD6CwAAFAAAAIoFAAAAAAAAICQAAPgAAAAaDAAA AAAAABoMAAAAAAAAGgwAAAAAAAAaDAAAAAAAABoMAAAAAAAAex4AAAAAAAB7HgAAAAAAAHseAAAA AAAAnyMAAAIAAAChIwAAAAAAAKEjAAAAAAAAoSMAAAAAAAChIwAAAAAAAKEjAAAAAAAAoSMAACQA AAAYJQAAUgIAAGonAAByAAAAxSMAABUAAAAAAAAAAAAAAAAAAAAAAAAAdgUAAAAAAAB7HgAAAAAA AAAAAAAAAAAAAAAAAAAAAAADGgAAeAQAAHseAAAAAAAAex4AAAAAAAB7HgAAAAAAAMUjAAAAAAAA AAAAAAAAAADqAQAAAAAAAOoBAAAAAAAAGgwAAAAAAAAAAAAAAAAAABoMAADpDQAA2iMAABYAAAAj IAAAAAAAACMgAAAAAAAAIyAAAAAAAAB7HgAAWAAAAOoBAACOAgAAGgwAAAAAAAB2BQAAAAAAABoM AAAAAAAAnyMAAAAAAAAAAAAAAAAAACMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAex4AAAAAAACfIwAAAAAAACMgAABcAAAAIyAAAAAAAAB/IAAA HgAAADcjAAAsAAAAeAQAAP4AAAB2BQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcyMAAAAAAAAaDAAAAAAAAA4MAAAMAAAAQKSWfGr/ xAEAAAAAAAAAAO4LAAAAAAAA0x4AABAAAABjIwAACAAAAAAAAAAAAAAAnyMAAAAAAADwIwAAMAAA ACAkAAAAAAAAayMAAAgAAADcJwAAAAAAAOMeAAAwAQAA3CcAABAAAABzIwAAAAAAAAAAAAAAAAAA igUAAAAAAACKBQAAAAAAAOoBAAAAAAAA6gEAAAAAAADqAQAAAAAAAOoBAAAAAAAAAAAAAAAAAAAA AAAAAAAAANwnAAAAAAAAAAAAAAAAAAB2BQAAAAAAAHMjAAAsAAAAex4AAAAAAAB7HgAAAAAAACMg AAAAAAAAex4AAAAAAAB7HgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAex4A AAAAAAB7HgAAAAAAAHseAAAAAAAAxSMAAAAAAADFIwAAAAAAAIoFAAAAAAAAigUAAGQGAADuCwAA AAAAAAAAAAAAAAAAEyAAABAAAACKBQAAAAAAAIoFAAAAAAAA7gsAAAAAAAACAAEBAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgICAgI CAgICAgICFNjZW5hcmlvIDENCAgICAgICAgMCAgICAgICAgICAgICAgICAgIU2NlbmFyaW8gMg1F UEMgUmVhZGVyDQ1FUEMgUmVhZGVyDQ1JU08gUmVhZGVyDQ1STkMNDVNMUlBQDQ1FUEMgVEFnDQ1F UEMgVEFnDQ1FUEMgVEFnDQ1JU08gVGFnDQ1BaXIgcHJvdG9jb2xzDQ1FUEMgU3RhbmRhcmQgTWlk ZGxld2FyZQ0NUk5DIGlzIGEgbG9naWNhbCBlbnRpdHkuIEl0IGNhbiBiZSBydW5uaW5nIGluIHRo ZSBtaWRkbGV3YXJlIHRvIHByb3ZpZGUgdGhlIFNMUlJQIGludGVyZmFjZS4NDUFMRS9FUENJUyBl dGMNDU11bHRpcGxlIHN0YW5kYXJkcyBNaWRkbGV3YXJlDQ1BaXIgcHJvdG9jb2xzDQ1JU08gVGFn DQ1FUEMgVEFnDQ1FUEMgVEFnDQ1FUEMgVEFnDQ1TTFJQUA0NQUxFL0VQQ0lTDQ1JU08gUmVhZGVy DQ1FUEMgUmVhZGVyDQ1FUEMgUmVhZGVyDQ0NDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAAwI AAAXCAAAHggAAB8IAAAgCAAAJQgAADIIAABhCAAAZQgAALkIAAAUCQAAFQkAABYJAAAXCQAAJQkA AH8JAACJCQAAsAkAAPLu4NLu4PLuzu7Oys7uzu7O7gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG FmirKIYAAAYWaDR+XAAAGgNqAAAAABZo0imCAFUIAW1IAARuSAAEdQgBABoDagAAAAAWaDR+XABV CAFtSAAEbkgABHUIAQAGFmjeGtkAABoDagAAAAAWaN4a2QBVCAFtSAAEbkgABHUIARIABgAAFwgA AD0IAABICAAASQgAAFQIAABVCAAAYAgAAGEIAABlCAAAZggAAGwIAABtCAAAdQgAAHYIAAB+CAAA fwgAAIcIAACICAAAkAgAAJEIAACfCAAAoAgAALgIAAC5CAAAFgkAABcJAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAA AAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAAD7AAAAAAAAAAAA AAAA6wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsA AAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAA AAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAA APsAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAEAAADJAFhJAEACgAAAyQAEmTwAAEAYSQAZ2Q0flwAAAEAAAABAQAAGgAGAAA9CAAA rwkAAP39AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAQAAQECFwkAACUJAAAm CQAARAkAAEUJAABTCQAAVAkAAFwJAABdCQAAZQkAAGYJAABuCQAAbwkAAHcJAAB4CQAAfgkAAH8J AACJCQAAigkAAJUJAACWCQAAoQkAAKIJAACtCQAArgkAAK8JAACwCQAA+gAAAAAAAAAAAAAAAPgA AAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAA AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAA APgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAADzAAAA AAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAA AAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4 AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAQEAAAQAAAMkAWEkAQABAAAABAAAZ2Q0flwAABogADGQaAEfsNAv ILDgPSGwCAcisAgHI5CgBSSQoAUlsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAA8AEgABAJwADwADAAAAAAAA AAAAUAAAQPH/AgBQAAwAAAAAAAAAAAAGAE4AbwByAG0AYQBsAAAADgAAAAMkAxJkaAEBAGEkAxwA T0oDAFFKAwBfSAEEYUoYAG1ICQRzSAkEdEgJBFIAAUABAAIAUgANAAAAAAAAAAAACQBIAGUAYQBk AGkAbgBnACAAMQAAABAAAQAGJAETpPAAFKQ8AEAmABYANQiBQ0ogAEtIIABcCIFeSgIAYUogAFIA AkABAAIAUgANAAAAAAAAAAAACQBIAGUAYQBkAGkAbgBnACAAMgAAAB4AAgADJAAFJAEGJAEKJgEL RgIAEmTwAAEAQCYBYSQACABDShwAYUoUAAAAAAAAAAAAAAAAAAAARABBQPL/oQBEAAwBAAAAAAAA AAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAFYAaUDz /7MAVgAMAQAAAAAAAAAADABUAGEAYgBsAGUAIABOAG8AcgBtAGEAbAAAACAAOlYLABf2AwAANNYG AAEFAwAANNYGAAEKA2wAYfYDAAACAAsAAAAoAGtA9P/BACgAAAEAAAAAAAAAAAcATgBvACAATABp AHMAdAAAAAIADAAAAAAAAAAAAAwAAAAYAAAAJAAAACkAAAAwAAAAOQAAAEIAAABLAAAAVAAAAGMA AAB8AAAA2gAAAOkAAAAIAQAAFwEAACABAAApAQAAMgEAADsBAABCAQAATQEAAFkBAABlAQAAcQEA ALABAAABAAAAAAAAAAAA/////wIEAAAAAAAAAQAAAAAAAAAAAP////8DBAAAAAAAAAEAAAAAAAAA AAD/////BAQAAAAAAAABAAAAAAAAAAAA/////1UEAAAAAAAAAQAAAAAAAAAAAP////8NBAAAAAAA AAEAAAAAAAAAAAD/////DgQAAAAAAAABAAAAAAAAAAAA/////w8EAAAAAAAAAQAAAAAAAAAAAP// //8QBAAAAAAAAAEAAAAAAAAAAAD/////EQQAAAAAAAABAAAAAAAAAAAA/////xIEAAAAAAAAAQAA AAAAAAAAAP////8TBAAAAAAAAAEAAAAAAAAAAAD/////VgQAAAAAAAABAAAAAAAAAAAA/////1EE AAAAAAAAAQAAAAAAAAAAAP////9JBAAAAAAAAAEAAAAAAAAAAAD/////SAQAAAAAAAABAAAAAAAA AAAA/////0cEAAAAAAAAAQAAAAAAAAAAAP////9GBAAAAAAAAAEAAAAAAAAAAAD/////RQQAAAAA AAABAAAAAAAAAAAA/////0QEAAAAAAAAAQAAAAAAAAAAAP////9DBAAAAAAAAAEAAAAAAAAAAAD/ ////TwQAAAAAAAABAAAAAAAAAAAA/////zwEAAAAAAAAAQAAAAAAAAAAAP////87BAAAAAAAAAEA AAAAAAAAAAD/////OgQAAAAAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAYAAAAJAAA ACkAAAAwAAAAOQAAAEIAAABLAAAAVAAAAGMAAAB8AAAA2gAAAOkAAAAIAQAAFwEAACABAAApAQAA MgEAADsBAABCAQAATQEAAFkBAABlAQAAcQEAAHQBAAAAAAAAABABAAAAABACAAAAABADAAAAABAE AAAAABAFAAAAABAGAAAAABAHAAAAABAIAAAAABAJAAAAABAKAAAAAAALAAAAAAAMAAAAABANAAAA AAAOAAAAABAPAAAAABAQAAAAABARAAAAABASAAAAABATAAAAABAUAAAAABAVAAAAABAWAAAAABAX AAAAABD//wAAAAAAAAAAsAEAAAQAABIAAAAA/////wAAAAAXAAAAPQAAAEgAAABJAAAAVAAAAFUA AABgAAAAYQAAAGUAAABmAAAAbAAAAG0AAAB1AAAAdgAAAH4AAAB/AAAAhwAAAIgAAACQAAAAkQAA AJ8AAACgAAAAuAAAALkAAAAWAQAAFwEAACUBAAAmAQAARAEAAEUBAABTAQAAVAEAAFwBAABdAQAA ZQEAAGYBAABuAQAAbwEAAHcBAAB4AQAAfgEAAH8BAACJAQAAigEAAJUBAACWAQAAoQEAAKIBAACt AQAArgEAALEBAAAIAAAAATAAAAAAAAAAgAAAAIAAAAAAAAAAAIAACAAAAAEwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAA AAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAIAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA AAAAgAeYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA AIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA gACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACA AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAA mAAAAAAwAAAAAAAAAIAAAACAAAAAMAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAeY AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAB5gA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIADmAAA AAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAA ADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAA MAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAA AAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAA AAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAB5gAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAAADAAAAAAAAAA gAAAAIAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACA AAAAgAAAAAAAAAAAgAAABgAAsAkAAAUAAAAABgAAFwkAALAJAAAGAAAACAAAAAAGAACvCQAABwAA AA8AAPA4AAAAAAAG8BgAAAACCAAAAgAAAFcAAAABAAAAAQAAAFgAAABAAB7xEAAAAP////////// gICAAPcAABAADwAC8KANAAAQAAjwCAAAACcAAABXBAAADwAD8PYMAAAPAATwKAAAAAEACfAQAAAA AAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATwSAAAABIACvAIAAAAEwQAAAAKAAAj AAvwDAAAAIAAAAALAIoAEwQAAAAAEPAEAAAAEgAAAAAAEfAEAAAAEAAAAAAADfAEAAAAAAALAA8A BPBCAAAAEgAK8AgAAABJBAAAAAoAABMAC/AGAAAAgAAAAA4AAAAQ8AQAAAAWAAAAAAAR8AQAAAAJ AAAAAAAN8AQAAAAAAA4ADwAE8EgAAAASAArwCAAAAAIEAAAACgAAIwAL8AwAAACAAAAAAQCKAAIE AAAAABDwBAAAAAgAAAAAABHwBAAAAAsAAAAAAA3wBAAAAAAAAQAPAATwSAAAABIACvAIAAAAAwQA AAAKAAAjAAvwDAAAAIAAAAACAIoAAwQAAAAAEPAEAAAACgAAAAAAEfAEAAAAEAAAAAAADfAEAAAA AAACAA8ABPBIAAAAEgAK8AgAAAAEBAAAAAoAACMAC/AMAAAAgAAAAAMAigAEBAAAAAAQ8AQAAAAJ AAAAAAAR8AQAAAAPAAAAAAAN8AQAAAAAAAMADwAE8EgAAABCAQrwCAAAAAYEAACACgAAQwAL8BgA AABEAQQAAAB/AQAAAQC/AQAAEAD/ARAAEAAAABDwBAAAAAYAAAAAABHwBAAAAAwAAAAPAATwSAAA AEIBCvAIAAAABwQAAIAKAABDAAvwGAAAAEQBBAAAAH8BAAABAL8BAAAQAP8BEAAQAAAAEPAEAAAA BwAAAAAAEfAEAAAADgAAAA8ABPBIAAAAQgEK8AgAAAAIBAAAgAoAAEMAC/AYAAAARAEEAAAAfwEA AAEAvwEAABAA/wEQABAAAAAQ8AQAAAAFAAAAAAAR8AQAAAALAAAADwAE8EgAAABCAQrwCAAAAAkE AAAACgAAQwAL8BgAAABEAQQAAAB/AQAAAQC/AQAAEAD/ARAAEAAAABDwBAAAAAQAAAAAABHwBAAA AAoAAAAPAATwSAAAAEIBCvAIAAAACgQAAIAKAABDAAvwGAAAAEQBBAAAAH8BAAABAL8BAAAQAP8B EAAQAAAAEPAEAAAADwAAAAAAEfAEAAAADAAAAA8ABPBgAAAA8gMK8AgAAAANBAAAAAoAAGMAC/Ak AAAAgAAAAAUAigANBAAARwFy7///gQH//wAAvwEQABAAfwMAAAwAAAAQ8AQAAAATAAAAAAAR8AQA AAAXAAAAAAAN8AQAAAAAAAUADwAE8EgAAAASAArwCAAAAA4EAAAACgAAIwAL8AwAAACAAAAABgCK AA4EAAAAABDwBAAAAAMAAAAAABHwBAAAABAAAAAAAA3wBAAAAAAABgAPAATwSAAAABIACvAIAAAA DwQAAAAKAAAjAAvwDAAAAIAAAAAHAIoADwQAAAAAEPAEAAAAAgAAAAAAEfAEAAAADAAAAAAADfAE AAAAAAAHAA8ABPBIAAAAEgAK8AgAAAAQBAAAAAoAACMAC/AMAAAAgAAAAAgAigAQBAAAAAAQ8AQA AAABAAAAAAAR8AQAAAAMAAAAAAAN8AQAAAAAAAgADwAE8EgAAAASAArwCAAAABEEAAAACgAAIwAL 8AwAAACAAAAACQCKABEEAAAAABDwBAAAAAAAAAAAABHwBAAAAAwAAAAAAA3wBAAAAAAACQAPAATw ZgAAAPIDCvAIAAAAEgQAAAAKAABzAAvwKgAAAIAAAAAKAIoAEgQAAEcBIZgAAEgB4AYAAIEB//8A AL8BEAAQAH8DAAAMAAAAEPAEAAAACwAAAAAAEfAEAAAAEQAAAAAADfAEAAAAAAAKAA8ABPBIAAAA EgAK8AgAAAA6BAAAAAoAACMAC/AMAAAAgAAAABgAigA6BAAAAAAQ8AQAAAAlAAAAAAAR8AQAAAAD AAAAAAAN8AQAAAAAABgADwAE8EgAAAASAArwCAAAADsEAAAACgAAIwAL8AwAAACAAAAAFwCKADsE AAAAABDwBAAAACQAAAAAABHwBAAAAAMAAAAAAA3wBAAAAAAAFwAPAATwSAAAABIACvAIAAAAPAQA AAAKAAAjAAvwDAAAAIAAAAAWAIoAPAQAAAAAEPAEAAAAIwAAAAAAEfAEAAAAAwAAAAAADfAEAAAA AAAWAA8ABPBIAAAAQgEK8AgAAAA9BAAAgAoAAEMAC/AYAAAARAEEAAAAfwEAAAEAvwEAABAA/wEQ ABAAAAAQ8AQAAAAiAAAAAAAR8AQAAAADAAAADwAE8EgAAABCAQrwCAAAAD4EAACACgAAQwAL8BgA AABEAQQAAAB/AQAAAQC/AQAAEAD/ARAAEAAAABDwBAAAACEAAAAAABHwBAAAAAMAAAAPAATwSAAA AEIBCvAIAAAAPwQAAIAKAABDAAvwGAAAAEQBBAAAAH8BAAABAL8BAAAQAP8BEAAQAAAAEPAEAAAA IAAAAAAAEfAEAAAAAwAAAA8ABPBIAAAAQgEK8AgAAABABAAAAAoAAEMAC/AYAAAARAEEAAAAfwEA AAEAvwEAABAA/wEQABAAAAAQ8AQAAAAfAAAAAAAR8AQAAAADAAAADwAE8EgAAABCAQrwCAAAAEEE AACACgAAQwAL8BgAAABEAQQAAAB/AQAAAQC/AQAAEAD/ARAAEAAAABDwBAAAAB4AAAAAABHwBAAA AAMAAAAPAATwZgAAAPIDCvAIAAAAQwQAAAAKAABzAAvwKgAAAIAAAAAUAIoAQwQAAEcBqPv//0gB SGwAAIEB//8AAL8BEAAQAH8DAAAMAAAAEPAEAAAAFwAAAAAAEfAEAAAABQAAAAAADfAEAAAAAAAU AA8ABPBIAAAAEgAK8AgAAABEBAAAAAoAACMAC/AMAAAAgAAAABMAigBEBAAAAAAQ8AQAAAAdAAAA AAAR8AQAAAAEAAAAAAAN8AQAAAAAABMADwAE8EgAAAASAArwCAAAAEUEAAAACgAAIwAL8AwAAACA AAAAEgCKAEUEAAAAABDwBAAAABwAAAAAABHwBAAAAAQAAAAAAA3wBAAAAAAAEgAPAATwSAAAABIA CvAIAAAARgQAAAAKAAAjAAvwDAAAAIAAAAARAIoARgQAAAAAEPAEAAAAGwAAAAAAEfAEAAAABAAA AAAADfAEAAAAAAARAA8ABPBIAAAAEgAK8AgAAABHBAAAAAoAACMAC/AMAAAAgAAAABAAigBHBAAA AAAQ8AQAAAAaAAAAAAAR8AQAAAAEAAAAAAAN8AQAAAAAABAADwAE8GAAAADyAwrwCAAAAEgEAAAA CgAAYwAL8CQAAACAAAAADwBHASGYAABIAeAGAACBAf//AAC/ARAAEAB/AwAADAAAABDwBAAAABkA AAAAABHwBAAAAAQAAAAAAA3wBAAAAAAADwAPAATwSAAAAEIBCvAIAAAASgQAAIAKAABDAAvwGAAA AEQBBAAAAH8BAAABAL8BAAAQAP8BEAAQAAAAEPAEAAAAGAAAAAAAEfAEAAAACQAAAA8ABPBuAAAA ogwK8AgAAABPBAAAAAoAADMAC/ASAAAAgAAAABUAigBPBAAA/wEAAAgAQwAi8RgAAAB/BQAACAC/ BQAACAD/BQAACAA/BgAACAAAABDwBAAAABEAAAAAABHwBAAAAAQAAAAAAA3wBAAAAAAAFQAPAATw SAAAAEIBCvAIAAAAUAQAAIAKAABDAAvwGAAAAEQBBAAAAH8BAAABAL8BAAAQAP8BEAAQAAAAEPAE AAAAEAAAAAAAEfAEAAAABAAAAA8ABPBoAAAAogwK8AgAAABRBAAAAAoAACMAC/AMAAAAgAAAAA0A /wEAAAgAQwAi8RgAAAB/BQAACAC/BQAACAD/BQAACAA/BgAACAAAABDwBAAAABQAAAAAABHwBAAA AAQAAAAAAA3wBAAAAAAADQAPAATwSAAAAEIBCvAIAAAAUgQAAIAKAABDAAvwGAAAAEQBBAAAAH8B AAABAL8BAAAQAP8BEAAQAAAAEPAEAAAAFQAAAAAAEfAEAAAAAwAAAA8ABPBoAAAAogwK8AgAAABV BAAAAAoAACMAC/AMAAAAgAAAAAQA/wEAAAgAQwAi8RgAAAB/BQAACAC/BQAACAD/BQAACAA/BgAA CAAAABDwBAAAAA4AAAAAABHwBAAAABAAAAAAAA3wBAAAAAAABAAPAATwaAAAAKIMCvAIAAAAVgQA AAAKAAAjAAvwDAAAAIAAAAAMAP8BAAAIAEMAIvEYAAAAfwUAAAgAvwUAAAgA/wUAAAgAPwYAAAgA AAAQ8AQAAAANAAAAAAAR8AQAAAAGAAAAAAAN8AQAAAAAAAwADwAE8EIAAAASAArwCAAAAFcEAAAA CgAAMwAL8BIAAAC/AQAAEADOAQYAAAD/AQgACAAAABDwBAAAAAwAAAAAABHwBAAAAAMAAAAPAATw QgAAABIACvAIAAAAAQQAAAAOAABTAAvwHgAAAL8BAAAQAMsBAAAAAP8BAAAIAAQDCQAAAD8DAQAB AAAAEfAEAAAAAQAAAE8ABfBAAAAAAAAX8AgAAAACAAAADQQAAAAAF/AIAAAAAwAAABIEAAAAABfw CAAAAAwAAABDBAAAAAAX8AgAAAANAAAASAQAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAH AAAACAAAAAkAAAAKAAAACwAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAIAAAACEA AAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAA ADAAAAAxAAAAsAEAABEEAADoFwAAbBsAACAcAADUHAAAdAABAAAAEAQAAPwSAABsGwAANBcAANQc AAB0AAEAAAAPBAAAEA4AALgaAABIEgAAIBwAAHQAAQAAAA4EAAD0CwAAUBkAACwQAAC4GgAAdAAB AAAACQQAAIwKAADgEAAA1BwAAOAQAAB0AAAAAAAIBAAAjAoAAOAQAACMCgAAzBUAAHQAAAAAAAYE AACwEwAA4BAAALATAADMFQAAdAAAAAAABwQAANQcAADgEAAA1BwAAMwVAAB0AAAAAAACBAAAcAgA AMwVAADEDgAANBcAAHQAAQAAAAQEAAAEGgAAzBUAAFggAAA0FwAAdAABAAAAAwQAAOAQAADMFQAA NBcAADQXAAB0AAEAAAASBAAA0AIAAOgXAACMCgAABBoAAHQAAQAAAFcEAADEDgAATwkAAJQRAAC3 CgAAdAAAAAAAVgQAADQXAAB/BgAAKCMAALcKAAB0AAAAAABVBAAAxA4AAE8JAACUEQAAtwoAAHQA AAAAAAoEAAAsEAAAtwoAACwQAACHDQAAdAAAAAAAUAQAAHgPAABjBAAAeA8AAOcHAAB0AAAAAABP BAAAeA8AAMsFAAAYFQAAqwcAAHQAAQAAABMEAACMCgAA5wcAABgVAAC3CgAAdAABAAAADQQAAPwS AAC3CgAAWCAAANMMAAB0AAEAAABRBAAAeA8AALwHAACAFgAAnAkAAHQAAAAAAFIEAADEDgAACAcA AMQOAACMCgAAdAAAAAAASQQAAHAIAACMCgAAGBUAAKgMAAB0AAAAAABDBAAALBAAABAOAACIHQAA LBAAAHQAAQAAAEoEAADYCQAAqAwAANgJAADgEAAAdAAAAAAASAQAAJj+///oFwAAVAYAAAQaAAB0 AAAAAABHBAAAsBMAAGwbAADoFwAA1BwAAHQAAQAAAEYEAADEDgAAbBsAAPwSAADUHAAAdAABAAAA RQQAANgJAAC4GgAAEA4AACAcAAB0AAEAAABEBAAAvAcAAFAZAAD0CwAAuBoAAHQAAQAAAEEEAAB4 DwAAqAwAAHgPAADgEAAAdAAAAAAAQAQAAFQGAADgEAAAnBgAAOAQAAB0AAAAAAA/BAAAVAYAAOAQ AABUBgAAzBUAAHQAAAAAAD4EAACcGAAA4BAAAJwYAADMFQAAdAAAAAAAPQQAAHgPAADgEAAAeA8A AMwVAAB0AAAAAAA8BAAAzBUAAMwVAAAgHAAANBcAAHQAAQAAADsEAACoDAAAzBUAAPwSAAA0FwAA dAABAAAAOgQAADgEAADMFQAAjAoAADQXAAB0AAEAAAAAAAAAPQAAAHEAAAB0AAAAegAAAH0AAACD AAAAhgAAAGEBAABkAQAAagEAAG0BAABzAQAAdgEAALEBAAAHAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAAAAAAD0AAACxAQAABwAHAAAAAAAXAAAAMgAAADwAAAA9AAAARwAAAEkAAABTAAAAVQAA AF8AAABhAAAAZAAAAGYAAABrAAAAbQAAAHQAAAB2AAAAfQAAAH8AAACGAAAAiAAAAI8AAACRAAAA ngAAAKAAAAC3AAAAFwEAACQBAAAmAQAAQwEAAEUBAABSAQAAVAEAAFsBAABdAQAAZAEAAGYBAABt AQAAbwEAAHYBAAB4AQAAfQEAAH8BAACIAQAAigEAAJQBAACWAQAAoAEAAKIBAACsAQAAsQEAAAUA BwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAH AAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAAAAAAPQAAALEBAAAHAAcA //8GAAAACwBTAGgAYQBoACwAIABTAGEAcABhAG4AAAALAFMAaABhAGgALAAgAFMAYQBwAGEAbgAA AA8ASwBhAHYAaQB0AGgAYQAgAEsAcgBpAHMAaABuAGEAAAABALpVymiIZgAh/w8CAP8P/w//D/8P /w//D/8PAAABAAAAABABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFg hJj+AgAAAC4AAQAAAAAQAQMAAAAAAAAAAAAAAAAAAAAAABgAAA+EGAMRhFD+FcYFAAEYAwZehBgD YIRQ/gQAAAAuAAEALgABAAAAABABAwUAAAAAAAAAAAAAAAAAAAAAGAAAD4TIBBGECP4VxgUAAaAF Bl6EyARghAj+BgAAAC4AAQAuAAIALgABAAAAABABAwUHAAAAAAAAAAAAAAAAAAAAGAAAD4TABhGE eP0VxgUAAQgHBl6EwAZghHj9CAAAAC4AAQAuAAIALgADAC4AAQAAAAAQAQMFBwkAAAAAAAAAAAAA AAAAABgAAA+EuAgRhOj8FcYFAAHYCQZehLgIYITo/AoAAAAuAAEALgACAC4AAwAuAAQALgABAAAA ABABAwUHCQsAAAAAAAAAAAAAAAAAGAAAD4SwChGEWPwVxgUAAUALBl6EsApghFj8DAAAAC4AAQAu AAIALgADAC4ABAAuAAUALgABAAAAABABAwUHCQsNAAAAAAAAAAAAAAAAGAAAD4SoDBGEyPsVxgUA ARAOBl6EqAxghMj7DgAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4AAQAAAAAQAQMFBwkLDQ8A AAAAAAAAAAAAABgAAA+EoA4RhDj7FcYFAAF4DwZehKAOYIQ4+xAAAAAuAAEALgACAC4AAwAuAAQA LgAFAC4ABgAuAAcALgABAAAAABABAwUHCQsNDxEAAAAAAAAAAAAAGAAAD4TgEBGEYPoVxgUAAUgS Bl6E4BBghGD6EgAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAgALgACAAAAulXKaAAA AAAAAAAAAAAAALpVymgAAAAAAAAAAAAAAAD/////////////AQAAAAAA//8BAAAAAAAFAAAABAAA AAgAAADlAAAAAAAAAAQAAAA0flwA0imCAKsohgDeGtkASkDhAP9AAYABACAAAAAgAAAAHO6PAAEA AQAgAAAAAAAAACAAAAAAAAAAAhAAAAAAAAAAsAEAAEAAABAAQAAA//8BAAAABwBVAG4AawBuAG8A dwBuAP//AQAIAAAAAAAAAAAAAAD//wEAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAQAAABH FpABAAACAgYDBQQFAgMEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcA IABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5 AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQQByAGkA YQBsAAAAQSaQAQAAAgsGAwICAgICBIcCAAAAAAAAAAAAAAAAAACfAAAAAAAAAFQAcgBlAGIAdQBj AGgAZQB0ACAATQBTAAAAIgAEAHEIiBgA8NACAABoAQAAAAA6nZFmpaWRhgAAAAACAFsAAAAJAAAA NAAAAAEAAQAAAAQAAxABAAAACQAAADQAAAABAAEAAAABAAAAAAAAACEDAPAQAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAgHoAW0ALQAgYFyNAAAAAAAAAAAAAAAAAAAPAAAADwAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAA AAAAAAAAATODEQDwEAAI3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAAAAAAo8P8PAQAB PwAA5AQAAP///3////9/////f////3////9/////f////3/SKYIA//8SAAAAAAAAAAoAUwBjAGUA bgBhAHIAaQBvACAAMQAAAAAAAAALAFMAaABhAGgALAAgAFMAYQBwAGEAbgAPAEsAYQB2AGkAdABo AGEAIABLAHIAaQBzAGgAbgBhAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAYAAAABAAAAAAAMAAAA AAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EI ACsns9kwAAAAeAEAABEAAAABAAAAkAAAAAIAAACYAAAAAwAAAKwAAAAEAAAAuAAAAAUAAADMAAAA BgAAANgAAAAHAAAA5AAAAAgAAAD0AAAACQAAAAwBAAASAAAAGAEAAAoAAAA0AQAADAAAAEABAAAN AAAATAEAAA4AAABYAQAADwAAAGABAAAQAAAAaAEAABMAAABwAQAAAgAAAOQEAAAeAAAACwAAAFNj ZW5hcmlvIDEAAB4AAAABAAAAAGNlbh4AAAAMAAAAU2hhaCwgU2FwYW4AHgAAAAEAAAAAaGFoHgAA AAEAAAAAaGFoHgAAAAcAAABOb3JtYWwAYR4AAAAQAAAAS2F2aXRoYSBLcmlzaG5hAB4AAAACAAAA MgB2aR4AAAAUAAAATWljcm9zb2Z0IFdvcmQgMTAuMABAAAAAAOJptgwAAABAAAAAAAT+d5P+xAFA AAAAANbrdmr/xAEDAAAAAQAAAAMAAAAJAAAAAwAAADQAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3VnC4bEJOXCAArLPmuMAAA AAQBAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACMAAAABgAAAJQAAAARAAAAnAAAABcAAACkAAAA CwAAAKwAAAAQAAAAtAAAABMAAAC8AAAAFgAAAMQAAAANAAAAzAAAAAwAAADjAAAAAgAAAOQEAAAe AAAAFAAAAEdFIEFpcmNyYWZ0IEVuZ2luZXMAAwAAAAEAAAADAAAAAQAAAAMAAAA8AAAAAwAAAEEK CgALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAACwAAAFNjZW5hcmlvIDEA DBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAD+////CwAAAAwAAAANAAAADgAA AA8AAAAQAAAAEQAAAP7///8TAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAA HQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAA/v///ycAAAAoAAAAKQAAACoAAAAr AAAALAAAAC0AAAD+////LwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAAP7////9////OAAAAP7/ ///+/////v////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAABDVpHxq /8QBOgAAAIAAAAAAAAAARABhAHQAYQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAKAAAAABAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAQEAAAAGAAAA/////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAADsJwAAAAAAAFcAbwByAGQARABvAGMA dQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBAgAA AAUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACISAAAAAAAA BQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAACgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAmAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBt AGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAQQAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAC4AAAAAEAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIA////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB AAAA/v////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////wEA /v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0IFdvcmQgRG9jdW1lbnQACgAA AE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ------_=_NextPart_001_01C4FF6B.0D1B4A04 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid ------_=_NextPart_001_01C4FF6B.0D1B4A04-- From rfid-bounces@ietf.org Thu Jan 20 23:50:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15931; Thu, 20 Jan 2005 23:50:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crr09-00074w-Ot; Fri, 21 Jan 2005 00:06:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crqgf-0004LL-8j; Thu, 20 Jan 2005 23:46:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crqd6-00039F-PO for rfid@megatron.ietf.org; Thu, 20 Jan 2005 23:42:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15497 for ; Thu, 20 Jan 2005 23:42:38 -0500 (EST) Received: from sandesh.patni.com ([208.250.32.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crqsu-0006jk-BO for rfid@ietf.org; Thu, 20 Jan 2005 23:59:01 -0500 Received: from onsitemail.patni.com ([192.168.175.202]) by sandesh.patni.com (8.12.11/8.12.11) with ESMTP id j0L4ea8s032663; Thu, 20 Jan 2005 23:40:36 -0500 Received: from onsitemail.patni.com (localhost [127.0.0.1]) by onsitemail.patni.com (8.12.8/8.12.8) with ESMTP id j0L5qOcr026769; Fri, 21 Jan 2005 00:52:44 -0500 Received: (from apache@localhost) by onsitemail.patni.com (8.12.8/8.12.8/Submit) id j0L5prcR026712; Fri, 21 Jan 2005 00:51:53 -0500 Received: from 208.250.32.6 (SquirrelMail authenticated user shahsapa) by 192.168.175.202 with HTTP; Fri, 21 Jan 2005 00:51:53 -0500 (EST) Message-ID: <8109.208.250.32.6.1106286713.squirrel@192.168.175.202> In-Reply-To: <7946.208.250.32.6.1106286579.squirrel@192.168.175.202> References: <0E03681B885F3B4296B999E34435A16E3DF6F9@ms08.mse3.exchange.ms> <7946.208.250.32.6.1106286579.squirrel@192.168.175.202> Date: Fri, 21 Jan 2005 00:51:53 -0500 (EST) Subject: RE: [Rfid]A few fundamental questions From: "Sapan Shah" To: "P. Krishna" User-Agent: SquirrelMail/1.4.1-2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 0.8 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 8bit Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 8bit It makes sense. Let me try reading the draft again and I will check out, what it is like to understand this with the specified clarifications. Thanks Sapan > >> Great questions again Sapan. >> >> I've updated the diagrams with my changes. RNC is not a dedicated >> hardware >> - nor are we introducing or specifying new elements into the network to >> support SLRRP. We coined the term RNC (reader control) to differentiate >> it >> from the traditional middleware functions (tag data processing). In both >> your diagrams, the RNC can be part of the middleware. The RNC is control >> and the data path interface for SLRRP - so if the middleware is the >> first-hop consumer of tag data from the reader, then obviously RNC is >> residing in the middleware. >> >> As you can observe in the diagrams, I have shown some examples of >> EPC-based standards as the northbound interface of the middleware. >> >> The other point you bring out in your diagrams which is quite orthogonal >> to this discussion. Its just FYI - there are readers in the marketplace >> that are 'multi-protocol' which means they are capable of inventorying >> tags of multiple protocols - however, the interface to them is not RP or >> any ISO protocol. The vendors have proprietary interface. >> >> Thanks, >> /Krishna >> >> ________________________________ >> >> From: Sapan Shah [mailto:sapan.shah@patni.com] >> Sent: Wed 1/19/2005 10:31 PM >> To: Sapan Shah >> Cc: P. Krishna; rfid@ietf.org >> Subject: Re: [Rfid] Re: A few fundamental questions >> >> >> >> Further, >> >> I am attaching a diagram that I thought would help me clearing up with >> my >> doubts. >> >> >> >> >> > > _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@ietf.org Fri Jan 21 00:05:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16805; Fri, 21 Jan 2005 00:05:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrrEZ-0007NB-Un; Fri, 21 Jan 2005 00:21:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crqqu-0006C9-F6; Thu, 20 Jan 2005 23:56:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrqnH-0005FS-8T for rfid@megatron.ietf.org; Thu, 20 Jan 2005 23:53:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16141 for ; Thu, 20 Jan 2005 23:53:08 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crr35-00078M-BT for rfid@ietf.org; Fri, 21 Jan 2005 00:09:31 -0500 Received: from ms08.mse3.exchange.ms ([69.25.50.144]) by mx2.foretec.com with esmtp (Exim 4.24) id 1CrqnF-0003nN-Pg for rfid@ietf.org; Thu, 20 Jan 2005 23:53:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Jan 2005 23:44:50 -0500 Message-ID: <0E03681B885F3B4296B999E34435A16E3DF6FA@ms08.mse3.exchange.ms> Thread-Topic: A few fundamental questions Thread-Index: AcT/beSoUKAMXVogSEuJmUd5mVo/pA== From: "P. Krishna" To: "Sapan Shah" X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: rfid@ietf.org Subject: [Rfid] RE: A few fundamental questions X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0577196363==" Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 This is a multi-part message in MIME format. --===============0577196363== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FF73.F0DC48C0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4FF73.F0DC48C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: Sapan Shah [mailto:sapan.shah@patni.com] Sent: Wed 1/19/2005 10:14 PM To: P. Krishna Cc: rfid@ietf.org Subject: Re: A few fundamental questions Krishna, I am confused - I believe SLRPP is for the communication between the reader and the RNC - a software application - as I take or a router, for example. =3D=3D Why would any air protocol matter to me? The readers are a set of = devices which would have their own embedded code that will have the algorithm = for interacting with/through the air protocol for reading the tags. As long as I have my reader on the network and my RNC (Any software that wants to read and process the tag list further) is able to send commands to the Reader, why would it matter to me as to what and how many air protocols are defined? I agree that RNC would be needed to control the read cycles so as to optimize the "Reader Network" efficiency, but again it doest it depend on the "air-protocols" per se'? I mean, All I would expect is sending a binary / ascii command to the reader and it responding back to me and the algorithm would be with me = to contrl the network- Please correct me I am wrong. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Hello Sapan, As I mentioned in my previous reply to you, SLRRP is an interface = to/from the readers. We coined the term RNC for the other end of the = SLRRP interface. The examples given in the draft for RNC included = dedicated hardware, router module, software on a server etc. However, = SLRRP does not require a new entity called RNC to be introduced into the = network. RNC is just a logical entity and is the control and the data = path interface of SLRRP. RNC can be part of the middleware. If you are an application, air-protocol should not matter to you - you = shouldn't even care about specific readers. You can communicate over a = higher-layer protocol like ALE or EPCIS to the middleware and query = logical groups of readers for the tag data.=20 However, the tag data is being acquired at the expense of RF bandwidth = which is a valuable resource in a facility. Controlling read-cycles = (i.e., start/stop) will certainly provide improvement over solutions = that require the reader to be continuously ON. However, with increasing = densities of reader deployment , just time-division multiplexing might = not cut it. The user community, reader & tag vendors realized it and = hence the output was a sophisticated air-protocol called C1G2 from EPC = Global. There were some control knobs available in the Gen 1 protocols = but they were more to do with the singulation protocol (like, the = control of the tree-walk for example - I've given an example for C1G1 in = the draft). However, in the C1G2 protocol, not only are there knobs for = controlling singulation, but also the RF parameters for the forward and = reverse link. Some of the control can be done by the reader itself for = problems dealing with a reader to multiple tag issue. However, when the = problem is with interferece management due to multiple readers and = multiple tags in a space, then either the readers sort them out or a = controller device sorts it out. In either case, the readers might = require some hand-holding - SLRRP provides a very granular interface for = control and provides support for a range of reader control capabilities. /Krishna =20 =20 =20 ------_=_NextPart_001_01C4FF73.F0DC48C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: A few fundamental questions=0A= =0A= =0A=
=0A=
 
=0A=

=0A=
=0A= From: Sapan Shah =0A= [mailto:sapan.shah@patni.com]
Sent: Wed 1/19/2005 10:14 =0A= PM
To: P. Krishna
Cc: = rfid@ietf.org
Subject: Re: A =0A= few fundamental questions

=0A=

=0A=

Krishna,

I am confused - I believe SLRPP is for = the =0A= communication between the
reader and the RNC - a software application = - as I =0A= take or a router, for
example.

=3D=3D
Why would any air = protocol matter =0A= to me? The readers are a set of devices
which would have their own = embedded =0A= code that will have the algorithm for
interacting with/through the = air =0A= protocol for reading the tags.

As long as I have my reader on the = network =0A= and my RNC (Any software that
wants to read and process the tag list = further) =0A= is able to send commands
to the Reader, why would it matter to me as = to what =0A= and how many air
protocols are defined? I agree that RNC would be = needed to =0A= control the
read cycles so as to optimize the "Reader Network" = efficiency, =0A= but again
it doest it depend on the "air-protocols" per se'?

I = mean, =0A= All I would expect is sending a binary / ascii command to the
reader = and it =0A= responding back to me and the algorithm would be with me to
contrl = the =0A= network- Please correct me I am wrong.

=0A=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Hello = Sapan,

=0A=

As I mentioned in my previous reply to you, SLRRP is = an =0A= interface to/from the readers. We coined the term RNC for the other = end of =0A= the SLRRP interface. The examples given in the draft for RNC included = dedicated =0A= hardware, router module, software on a server etc. However, SLRRP does = not =0A= require a new entity called RNC to be introduced into the network. RNC = is just a =0A= logical entity and is the control and the data path interface of SLRRP. = RNC can =0A= be part of the middleware.

=0A=

If you are an application, air-protocol should not = matter to you =0A= - you shouldn't even care about specific readers. You can communicate = over a =0A= higher-layer protocol like ALE or EPCIS to the middleware and query = logical =0A= groups of readers for the tag data.

=0A=

However, the tag data is being acquired at the expense = of RF =0A= bandwidth which is a valuable resource in a facility. Controlling = read-cycles =0A= (i.e., start/stop) will certainly provide improvement over solutions = that =0A= require the reader to be continuously ON. However, with increasing =0A= densities of reader deployment , just time-division multiplexing might = not cut =0A= it. The user community, reader & tag vendors realized it and = hence the =0A= output was a sophisticated air-protocol called C1G2 from EPC Global. = There were =0A= some control knobs available in the Gen 1 protocols  but they = were =0A= more to do with the singulation protocol (like, the control of the = tree-walk for =0A= example - I've given an example for C1G1 in the draft). However, in the = C1G2 =0A= protocol, not only are there knobs for controlling singulation, but also = the RF =0A= parameters for the forward and reverse link. Some of the control can be = done by =0A= the reader itself for problems dealing with a reader to = multiple =0A= tag issue. However, when the problem is with interferece management = due to =0A= multiple readers and multiple tags in a space, then either the readers = sort them =0A= out or a controller device sorts it out. In either case, the readers = might =0A= require some hand-holding - SLRRP provides a very granular interface for = control =0A= and provides support for a range of reader control = capabilities.

=0A=

/Krishna

=0A=

 

=0A=

 

=0A=

 

=0A= =0A= =0A= ------_=_NextPart_001_01C4FF73.F0DC48C0-- --===============0577196363== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid --===============0577196363==-- From rfid-bounces@ietf.org Fri Jan 21 08:43:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10003; Fri, 21 Jan 2005 08:43:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrzKZ-0003Rx-1X; Fri, 21 Jan 2005 09:00:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crz2C-0004yL-J9; Fri, 21 Jan 2005 08:41:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Crz0S-0004co-2C for rfid@megatron.ietf.org; Fri, 21 Jan 2005 08:39:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09802 for ; Fri, 21 Jan 2005 08:39:18 -0500 (EST) Received: from mse3fe1.mse3.exchange.ms ([69.25.50.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrzGK-0003LF-By for rfid@ietf.org; Fri, 21 Jan 2005 08:55:45 -0500 Received: from [192.168.1.45] ([157.130.221.86]) by mse3fe1.mse3.exchange.ms with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Jan 2005 08:41:48 -0500 From: Scott Barvick To: rfid@ietf.org Content-Type: text/plain Message-Id: <1106314726.4795.196.camel@saco.revasystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 21 Jan 2005 08:38:46 -0500 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jan 2005 13:41:48.0640 (UTC) FILETIME=[F4A2DE00:01C4FFBE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Subject: [Rfid] Discovery/scalability discussion X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit I'd like to see if have any experience on the list concerning the state of the art and RFCs on the topic of scalable deployment of large numbers of devices (readers in our case) and the discovery and connection to a service providing device (the SLRRP RNC). This should have more to do with being a good network citizen and not much to do with RFID proper. I expect there to be good analogies in the IP phone, CAPWAP, even access routing spaces, but I haven't kept up on the RFCs and I'm not quite sure of the implementation state of things like Zeroconf/SLP/etc. A couple points here. o The current draft specifies connection initiation by the reader assuming that it has discovered its upstream RNC. This was chosen expecting that the most scalable operation was to have the readers obtain their IP address, then discover the RNC service, then connect to the provider of that service. Other initiation sequences are possible and the SLRRP protocol doesn't/shouldn't care who initiated the TCP connection. o We may decide to not cover discovery in the SLRRP spec (leaving it for a subsequent document), but I've had private comments on the connection wording so a discussion about those words at least is necessary. However, it seems possible that we can get close on the discovery plan so that we will have confidence in the SLRRP operations such as authentication and connection management. Thoughts? Scott _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@ietf.org Mon Jan 24 22:55:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07277; Mon, 24 Jan 2005 22:55:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtI4E-00064l-1S; Mon, 24 Jan 2005 23:12:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtHlR-0008FF-9c; Mon, 24 Jan 2005 22:53:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtHkm-000827-Hg for rfid@megatron.ietf.org; Mon, 24 Jan 2005 22:52:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06796 for ; Mon, 24 Jan 2005 22:52:29 -0500 (EST) Received: from smtp2.server.rpi.edu ([128.113.2.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtI1O-0005u4-Pp for rfid@ietf.org; Mon, 24 Jan 2005 23:09:44 -0500 Received: from JIANGS2 (vpn-798.nss.rpi.edu [128.113.211.48]) by smtp2.server.rpi.edu (8.13.0/8.13.0) with SMTP id j0P3pxSq004111 for ; Mon, 24 Jan 2005 22:51:59 -0500 Message-ID: <000801c50291$3af40030$30d37180@JIANGS2> From: "Kenneth Jiang" To: Date: Mon, 24 Jan 2005 22:51:57 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) X-Spam-Score: 0.5 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [Rfid] Basic Questions X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1263504623==" Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 This is a multi-part message in MIME format. --===============1263504623== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C50267.4EB6D860" This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C50267.4EB6D860 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Everyone: I'm new to RFID, and I'm using Sensormatic Agile2 reader for my project. = I'm using 96 bits tag, and I'm trying to understand all the key query = commands are supported by Agile2 protocols. I am able to read and write = the tag_id to the tags, as well as lock the tags, but I could not figure = out a way to unlock the tag or kill the tag. Does anyone have experience = with Agile2 reader? Please help me out with the "lock", "password" and = "kill" commands. I'd be really appreciated if anyone could help me out. = Thanks in advance. Regards, __________________________ Shen-Yuan Jiang Rensselaer Polytechnic Institute 021 Clement, E-Complex 1999 Burdett Avenue Troy, New York 12180 (518) 276-7952 ------=_NextPart_000_0005_01C50267.4EB6D860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Everyone:
 
I'm new to RFID, and I'm using = Sensormatic Agile2=20 reader for my project. I'm using 96 bits tag, and I'm trying to = understand all=20 the key query commands are supported by Agile2 protocols. I am able to = read and=20 write the tag_id to the tags, as well as lock the tags, but I could not = figure=20 out a way to unlock the tag or kill the tag. Does anyone have experience = with=20 Agile2 reader? Please help me out with the "lock", "password" and "kill" = commands. I'd be really appreciated if anyone could help me out. Thanks = in=20 advance.
 
Regards,
__________________________
Shen-Yuan = Jiang
Rensselaer Polytechnic Institute
021 Clement, = E-Complex
1999=20 Burdett Avenue
Troy, New York 12180
(518)=20 276-7952
------=_NextPart_000_0005_01C50267.4EB6D860-- --===============1263504623== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid --===============1263504623==-- From rfid-bounces@ietf.org Tue Jan 25 00:18:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12309; Tue, 25 Jan 2005 00:18:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtJN1-0000Nu-Ot; Tue, 25 Jan 2005 00:36:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtJ4p-0005mn-8g; Tue, 25 Jan 2005 00:17:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtJ3v-0005GC-Uf for rfid@megatron.ietf.org; Tue, 25 Jan 2005 00:16:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12209 for ; Tue, 25 Jan 2005 00:16:20 -0500 (EST) Received: from ms08.mse3.exchange.ms ([69.25.50.144]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtJKY-0000IC-VA for rfid@ietf.org; Tue, 25 Jan 2005 00:33:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Rfid] Basic Questions Date: Tue, 25 Jan 2005 00:17:53 -0500 Message-ID: <0E03681B885F3B4296B999E34435A16E3DF707@ms08.mse3.exchange.ms> Thread-Topic: [Rfid] Basic Questions Thread-Index: AcUCnTh3Yz5FxGLMQmy7lLilPPpE2Q== From: "P. Krishna" To: "Kenneth Jiang" , X-Spam-Score: 0.8 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1684145854==" Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 This is a multi-part message in MIME format. --===============1684145854== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5029D.5E97EB57" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5029D.5E97EB57 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Ken, This is not the right forum to ask product-specific questions. You are = better off contacting the customer service folks @ Tyco/ADT to get your = questions answered. =20 Thanks, /Krishna ________________________________ From: rfid-bounces@lists.ietf.org on behalf of Kenneth Jiang Sent: Mon 1/24/2005 10:51 PM To: rfid@ietf.org Subject: [Rfid] Basic Questions Hi Everyone: =20 I'm new to RFID, and I'm using Sensormatic Agile2 reader for my project. = I'm using 96 bits tag, and I'm trying to understand all the key query = commands are supported by Agile2 protocols. I am able to read and write = the tag_id to the tags, as well as lock the tags, but I could not figure = out a way to unlock the tag or kill the tag. Does anyone have experience = with Agile2 reader? Please help me out with the "lock", "password" and = "kill" commands. I'd be really appreciated if anyone could help me out. = Thanks in advance. =20 Regards, __________________________ Shen-Yuan Jiang Rensselaer Polytechnic Institute 021 Clement, E-Complex 1999 Burdett Avenue Troy, New York 12180 (518) 276-7952 ------_=_NextPart_001_01C5029D.5E97EB57 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A=
Hello = Ken,
=0A=
This is not the right forum = to ask =0A= product-specific questions. You are better off contacting the customer = service =0A= folks @ Tyco/ADT to get your questions answered.
=0A=
 
=0A=
Thanks,
=0A=
/Krishna
=0A=

=0A=
=0A= From: rfid-bounces@lists.ietf.org on = behalf of =0A= Kenneth Jiang
Sent: Mon 1/24/2005 10:51 PM
To: =0A= rfid@ietf.org
Subject: [Rfid] Basic = Questions

=0A=
=0A=
Hi Everyone:
=0A=
 
=0A=
I'm new to RFID, and I'm using = Sensormatic Agile2 =0A= reader for my project. I'm using 96 bits tag, and I'm trying to = understand all =0A= the key query commands are supported by Agile2 protocols. I am able to = read and =0A= write the tag_id to the tags, as well as lock the tags, but I could not = figure =0A= out a way to unlock the tag or kill the tag. Does anyone have experience = with =0A= Agile2 reader? Please help me out with the "lock", "password" and "kill" =0A= commands. I'd be really appreciated if anyone could help me out. Thanks = in =0A= advance.
=0A=
 
=0A=
Regards,
=0A=
__________________________
Shen-Yuan =0A= Jiang
Rensselaer Polytechnic Institute
021 Clement, = E-Complex
1999 =0A= Burdett Avenue
Troy, New York 12180
(518) =0A= 276-7952
=0A= ------_=_NextPart_001_01C5029D.5E97EB57-- --===============1684145854== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid --===============1684145854==--