Subject: [Rfid] Supported Reader Paradigms

From: Margaret Wasserman <[email-masked]>
Date: Thu, 21 Jul 2005 14:40:09 -0400

Discussing the management/monitoring side of readers reminded me of 
another issue that I wanted to raise with this group:  What paradigms 
should be supported for reader operations?

IMO, we should think carefully about the extent to which we expect 
RFID readers to be controlled in a top-down fashion (receiving 
commands from a "controller", whether those commands are immediate or 
trigger-based) vs. the extent that we expect readers to be autonomous 
and to operate based on configured policies or rules.

For example, it is quite possible to think of an RFID reader that 
reads pallet tags and passes them to an application, but that 
triggers local alarms (a flashing light, a buzzer?) if certain 
anomalous events occur, such as sensing a tag that is not programmed 
with an EPC ID or sensing a case-level or item-level tag when there 
is no pallet tag present in the field of view.   In both of these 
cases, the alarm might indicate that further intervention (such as 
using a fall-back barcode reader) is needed.

You could also picture a multi-antenna reader that report inbound 
items to middleware (items that are read outside the door and are 
later read inside the door), but that triggers an alarm if an item is 
moved in the opposite direction.

Could SLRRP support these types of operations?  If so, how?

Also, there is much to be said for having readers that continue to 
operate when they do not have network connectivity to the controller, 
storing events and reporting them if/when a connection is 
established.  Ideally, readers should be able to perform their tasks 
even if they are rebooted (due to a power outage, for example) and 
have not yet established a connection to a controller since 
rebooting.  They should come up performing their function, and store 
data for later retrieval by middleware or applications.

Could SLRRP support this type of autonomous operation?  If so, how?

_______________________________________________
Rfid mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rfid

---

From: "P. Krishna" <[email-masked]>
Date: Thu, 21 Jul 2005 23:58:45 -0400

> and to operate based on configured policies or rules.

Supporting a wide range of operational mode of the reader is certainly a
goal of SLRRP. If anybody has specific suggestions to augment/modify some of the 
commands/parameter structure, that would be really useful.

> using a fall-back barcode reader) is needed.

SLRRP has an ACL-type filter/operation structure in an access command. If folks are unclear about access, here are couple of links that explain the access operations in SLRRP.

http://www1.ietf.org/mail-archive/web/rfid/current/msg00125.html

http://www1.ietf.org/mail-archive/web/rfid/current/msg00128.html

As currently defined, the access command is more focussed on the followup access operations to be performed on the tags. The op-code is a byte wide, and each op-spec has its operation-specific parameters. We have currently defined only a handful of operations (all pertaining to the air-protocol specific tag memory access commands/operations).

To solve the above scenario, we need to define an op-spec that controls/manipulates GPIO on the reader upon detecting an incorrect tag pattern. I think thats a valid scenario - a similar request was posed by Rob of Intermec in an earlier email. If the requirements are well-scoped (like the above example, but with more details about GPIO addressing etc), then this group should be able to design it in slrrp.

> moved in the opposite direction.

This is entering the domain of inferring higher level events using read observations from multiple read points. This according to me is a higher level function.  Of course, for the specific deployment case where the direction has to be inferred from readpoints belonging to the same reader, the reader itself has the information and hence may have the logic built in to derive causality of observations. In the general case, where the readpoints could belong to more than one reader, the processing logic and communication requirements @ the reader layer to have distributed inference engines quickly become the dominant factor in the reader. 

Having said that, no,  SLRRP as currently defined does not support this specific operation. The general solution requires a causality rule to be set up at the reader - e.g.,  if ant1 of reader 1 saw the tag after ant2 of reader 2, then raise an alarm.

I am not convinced that such complicated inference engines need to be configured via a low-level device interface protocol.  SLRRP's responsibilities include controlling, operating the reader to perform RF operations (tag inventory, access, RF monitoring), and operate its I/O peripherals. Data (tag observations) from SLRRP can feed into the inference logic running on the reader - thats definitely possible. 

>Could SLRRP support this type of autonomous operation?  If so, how?

Yes. SLRRP does support autonomous operation however whether its the type you are talking about needs more discussion. SLRRP has primarily 4 types of commands - configuration, tag inventory, tag access, and the event reports. Amongst them, the only concerning ones are the last 3. The tag inventory command has a 'forever' bit which when set instructs the reader to run the inventory command with the last-configured singulation/RF/filter parameters forever till it receives a STOP_INVENTORY command. The tag access commands have been designed to operate in an autonomous mode - each command creates an access-spec @ the reader, which gets looked up till a STOP_ACCESS command is sent.  If you read the above links, it'll be clear. Reporting data if/when connection is established -thats an interesting requirement. The SLRRP spec as of now defines some triggers to send report back over the network link to the host/controller. Rob of Intermec had some ideas too. There are enough bits to support many different types of triggers. It'd be great if we can work together on ironing out the requirements on this front.

Regarding surviving reboot, power outage etc - thats clearly out of scope of an interface protocol. Its a reader design issue. And regarding losing network connection, by definition, the above autonomous operation should continue even when network connectivity is lost. 

Good discussion.

/Krishna