RE: [Rfid] Control Plane Architectural Elements

[Margaret Wasserman <margaret at thingmagic.com>]

Hi Krishna,

Yes, I saw your response earlier.  Thanks for reminding me about it.

Your response addressed the question of whether the reader can be set 
to run autonomously without continuous commands sent from the 
controller to the reader.  I didn't remember that SLRRP included this 
functionality, so it may be time for me to re-read the SLRRP document.

I do think that we should define how/if a reader is expected to 
continue this autonomous operation across a reboot (there are 
tradeoffs on both sides), but that is a detail, perhaps.

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.

In fact, it might even make sense to break the data and events out 
into separate sub-systems and maintain separate concepts of tag data 
consumers and event consumers.

Margaret


At 8:47 AM -0400 7/23/05, P. Krishna wrote:

> but I think that this same type of
>  autonomous operation would also be valuable for basic readers that
>  only implement the lower-level reader control protocol (the RP level
>  in the EPC Global architecture).

>  Margaret



Pls see ...

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

This msg was sent couple of days ago and addresses the same concern 
raised in this email.

/Krishna


_______________________________________________
Rfid mailing list
Rfid at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/rfid