Re: [Rfid] Control Plane Architectural Elements

> There are three other parts of the operational mode that I am
> discussing that I do not think are captured in SLRRP:
> (1) I do not believe that the control and data connections should be
> conflated the way that they are in SLRRP.  Even if we decide that a
> reader can only be controlled by a single controller, it should be
> possible for a reader to send tag data to more than one consumer and
> to maintain different filters and different event lists for different
> consumers. In addition to improving the scaling properties of the
> system, this would reduce the brittleness of the system (caused by
> the dependence on a single controller being up at all times).
> (2) It should not be necessary for a reader to maintain connectivity
> to the consumer(s) in order for the consumer(s) to see all of the
> applicable tag reads and events.  If connectivity is lost, I believe
> that readers should cache tag reads and events until the connectivity
> can be reestablished (or until the cache wraps, of course).
> (3) I'd also like to see the reader support multiple paradigms for
> how tag reads and events are sent to consumers, including (at least):
> the reader and consumer maintain a constant connection over which tag
>reads and events are transmitted as they occur, the consumer polls
> the reader periodically for tag reads and events, and the reader
>actively notifies the consumer when tag reads or events of interest
>occur (sensor tripped, first tag detected, timeout expired, etc.).
>After such a notification, the consumer could poll for tag reads,
>establish a connection to receive tag reads, or do whatever made
>sense.

(2) and (3) pertain to the control/config of the rate @ which tags/events are reported back to the consumer. This is covered in Section 3.5.6 (specifically 3.5.6.1) of slrrp 02 draft. 

We have a byte wide field for triggers - we have defined 2 triggers - one is timeout, the other is every inventory round.

Triggers like "sensor tripped, first tag detected, when connected" are amongst the ones that are going to be added to the trigger definition. We had some other reader vendors ask for them too. We would like to add them in 03 version - would you or anybody else be interested in participating in that effort ?

Regarding your concern (1):
I think there is a subtle misunderstanding. I'll try to clear it. You are treating SLRRP as a logical channel between  a network of readers and a network of consumers. In that regards, you are overestimating what the capability of a "device interface protocol" is. By definition, SLRRP is a protocol between 2 physical end-points - one RNC  (or as you call it, consumer) and one reader. If you leave it at that, then its up to the consumer what data events & the rate it subscribes to, and what configurations/controls it wants to enable at the reader. 

If there are multiple consumers and 1 reader, and you want all of them to interact with the reader, then you may have multiple slrrp connections opened - any conflicts in configuration, operational-setting is the responsibility at the layer of the network of consumers. 

In SLRRP, at the command level, we already have built in 2 broadly different types - one for control (using inventory and access commands), and one for data (using inventory/access reports commands) - each one has independent set of parameters. At the slrrp level, you can have one consumer only sending control commands; another consumer just configure the reader for the data/event reports. SLRRP doesn't disallow that.
It is a reader design issue if it wants to allow for multiple slrrp connections or not. Likewise it is a design issue at the layer of the network of consumers to decide for each consumer what path to enable (control or data or both) to each reader. Once that layer has decided, then each consumer uses SLRRP to communicate with the reader.

Pls see the following for a similar discussion that took place sometime back on this list ...

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

Thanks,

/Krishna
<http://www1.ietf.org/mail-archive/web/rfid/current/msg00112.html>  