Subject: [Rfid] Slrrp-Draft

From: [email-masked]
Date: Sun, 16 Jan 2005 20:20:17 -0800

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/rfid

---

From: "P. Krishna" <[email-masked]>
Date: Mon, 17 Jan 2005 18:09:29 -0500

> 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…

Steve,
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 

I will describe how SLRRP addresses each of the above. Hopefully, by
doing so, I would have answered your questions too. 

So, what do we mean by network-centric? Until recently, development of 
readers and reader technology has focused on the needs of specific 
applications.  Let's call this "application-centric" focus. This was a 
good thing, and enabled people to develop applications and systems that 
utilized RFID data and information. In some ways, this evolution 
reflects the early days of computer networking.  At that time, each new 
"application" of connected computing required a new network to be setup 
and configured.  This rapidly evolved to the point that the network 
became "infrastructure" and devices created connections as applications 
required them.  A network-centric RFID infrastructure would support 
acquisition of tags for a variety of application needs; in essence, the 
RFID equipment becomes a tag acquisition network and becomes 
part of the enterprise computing environment. Readers are deployed in 
increasing numbers and become edge devices of this network, and devices 
(Reader Network Controllers, or RNCs) operate these readers.  SLRRP is 
designed to enable and support this evolution to a network-centric 
model.

One of the keys to SLRRP is the decoupling of the commands and
parameters.  This allows for a common command structure, and 
extensibility comes in the form of  parameters, which allows for support
of new air protocols to be implemented as plugins  in terms of new 
parameters. SLRRP has 3 types of messages: (a) configuration, 
(b) inventory and (c) access. 

(a) Configuration:
GET_READER_INFO: This message queries the reader about its
identification, POE requirements, reader capabilities, device 
configuration (e.g., antenna properties), RF receiver operational 
parameters (sensitivity), RF transmitter operational parameters (tx 
power, FH sequence being used) frequency hop table information (if in 
freq-hop regions), fixed frequency list(if in Europe), statistics, tag 
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 
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, 
specifically, RF Receive sensitivity, TX transmit power, the FH sequence
to use, the desired contents in the inventory and access report, reset 
statistics, air-protocol specific RF parameters.

Using this command, we can set the air-protocol specific RF parameters. 
For example, in C1G2 protocol, if the target RF environment is fairly 
constant (yeah right !! ;) ), then during the configuration phase 
itself, we can set the RF parameters(e.g., PIE rate, PIE ratio, ASK or 
BPSK, TRCal, divide ratio) to be used during tag inventory. These
parameters are used by the reader in the subsequent inventory rounds 
till an inventory command with new RF parameters are received by the 
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 
terms of reader density, there has to be a tight control of the RF 
cycles by the readers. To that respect, we convey the following 
parameters for an inventory command: 
(i)  Target Tag filter: Subset of tag population to be inventoried. For 
example, in C1G2 it will be used in the Select command; in C1G1 it is 
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 
during each inventory round - e.g., in C1G2 it specifies the target tag 
population's state(A or B, SL or ~SL tags). Continuing with the C1G2
example, this singulation parameter also provides the flexibility of 
specifying the Q-algorithm to be used each round in one of two ways - 
(1) sophisticated reader: to which we describe the target singulation 
environment in the form of a tuple <tag mobility, tag population, RF 
interference environment>, or (2) simple reader: to which we describe 
the Q-manipulation algorithm state machine.

This command provides the capability of 
- setting a round size in terms of time
- control the filter, rf and singulation parameters each round. 

There is a 'lifetime bit' in the command that allows the reader to 
continue operating on the inventory command forever. 

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 
like RF, but change only tag filter and singulation parameters.

(c) Access: 

ACCESS: This message creates a new access-spec at the reader. 
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. 
The design of this aspect of the protocol takes into account the 
scalability requirements in the applications space. There will be a 
multitude of applications requiring a wide variety of information from
tags, and also with a diverse set of requirements ranging from one-time 
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 
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 
for the reader to perform the access operations on the tag as and when
it gets inventoried. 

The access-spec comprises of 2 parameter blocks: target tag-spec (which 
is like a filter-spec), and the tag operations spec (op-spec). 

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 
and when, it reads the tag, it looks up the capabilities-table to 
determine what actions it can perform on the tag; and if possible and 
permissible, then performs the access operations that is specified in 
the access-spec. (option ii) The RNC has the tag-capabilities table: 
based on which it performs the sanity check of the access operations 
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 
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 
provides a versatile interface to program the access-specs at the
reader. 

Following is an example of TID-based access operation using
SLRRP. In this example, I'll use option (ii). 

Suppose, an application requires the following business logic:
- Dock-door reader to write current timestamp and dock door # in the 
user-memory of pallet tags.

As you know, the user-memory and block write capabilities are optional 
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 
follows:   

TID    User Memory   BlockWriteCapability
foo1      Yes              Yes  
foo2      No                No    
*         Yes               No    // This entry is for the rest of TIDs.

The RNC using SLRRP would create 3 access-specs at the reader:

access-spec1: 
tag-spec: Matches TID=foo1 and type=pallet
op-spec: Block Write time and dock door # to user memory

access-spec2:tag-spec: Matches TID=foo2 and type=pallet
op-spec: no op.

access-spec3:tag-spec: Matches TID=* and type=pallet
op-spec: Write time and dock door # to user memory

I hope the above discussion helped you understand SLRRP better.  If you 
and the group think it will help, we can work together to publish a 
separate draft that provides the problem statement and introduction 
material to SLRRP?

Looking forward to more discussions.

Thanks,
/Krishna