RE: [Rfid] Supported Reader Paradigms

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

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.

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

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.

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

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. 

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

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