Subject: [Rfid] Re: A few fundamental questions

From: "P. Krishna" <[email-masked]>
Date: Wed, 19 Jan 2005 22:27:50 -0500

On Tue, 2005-01-18 at 15:31, Sapan Shah wrote:
> Krishna,
>
> I did go through the draft documents and it does look intersting.
> However
> have a few questions before I can move on with contributing on the
> specs.
>

Sapan,
First off, thank you for taking the time to read the draft. Now to your
questions ...

> I am considering a hetrogenous environment with readers of multiple
> brands
> and multiple standards installed in the same facility - so as to
> leverage
> the max out of the protocol specs and find out what can be missing - if
> there is anything.
>
> Let us say, we have like 3 readers that follow EPc Standards and 3
> Readers
> that follow ISO Standards. The Reader Network Controller - as the
> definition suggests will be / can be a software server as well. If we
> take
> this into consideration then on the EPC Front, The Device Management
> Layer
> within ALE / The RM and RP will be taking care of all the commands to be
> sent out to the reader. What is left out, will be the ISO Standards -
> which the RNC will be commanding. The EPc Standards, I dont think will
> support the RNC.
>
> Although, the IP based configuration that we are trying to specify over
> here is different in the aspects of Binary data being conveyed through
> IP
> Packets, would not it be a complicated situation, when the standards are
> recognized and accepted? I mean, If There are EPC Standards /
> Middlewares
> that already have their readers up and running on the network and they
> accept commands in a specific format. How do we plan to merge
> applications
> with them?
>
> Regards
> Sapan

You hit upon 2 basic questions:
(1) Under what circumstances do you use SLRRP? Is it _only_ for
multi-air-protocol or are there other circumstances too?

(2) Will there be cases where SLRRP and EPC RP are deployed in the same
infrastructure?

Lets first address (1): Why SLRRP?
a) One of the goals of SLRRP is to support all currently defined RFID
air protocols and be extensible to support future air protocols. Since,
it is being defined in a standards body (IETF) which is not defining air
protocols, the wire-line protocol does not need to be tied to an air
protocol. The other wire-line protocols defined in EPCGlobal and ISO are
defined for the specific air protocols defined in their respective
standards organization.

But wait - multi-air-protocol support is not the only reason for using
SLRRP.

b) Support for diversity of reader control requirements is the other
aspect. On one end of the spectrum are readers which when provided some
hints of the target singulation/RF environment from the RNC can
autonomously control the air-protocol/RF parameters. On the other end of
spectrum are readers that require real-time hand-holding in terms of
air-protocol/RF parameters. And there is a continuum in between the two
ends of spectrum in terms of reader control capabilities.

Now why is reader control important?
If there is just one reader in the facility and you have an application
connected to it, it doesn't matter how the reader is using up the RF
cycles to perform its task. However, as you increase the number of
readers in the facility, and if each reader has a task to perform, then
they start contending for the RF bandwidth. The RF control aspect is
important enough that the new air protocol Class 1 Gen 2 (currently
under the EPCGlobal umbrella, and soon to be passed over to ISO for
consideration as an ISO standard) has incorporated a number of knobs
that can be controlled to efficiently use the RF spectrum.

None of the other standard protocols provide a multi-air protocol
control interface - SLRRP provides a very granular interface for
control.

>From the above discussion it may seem that SLRRP is only relevant in
multi-reader environment. But thats not true either.

c) Diversity of application requirements: As you are very well aware
(from your epcis participation), that there are going to be a number of
applications that would be interested in accessing the RFID
infrastructure - access may mean visibility into the (synthesized or
raw) tag read data and/or performing other tag updates
(lock/unlock/writes/kill). There are two ends of the spectrum in terms
of implementing business logic based access rules/requirements. One end
is the application-assisted, and the other end is the autonomous. Let me
illustrate it using an example.

For example, if the business logic requires that whenever a tag with a
prefix of 'foo' shows up, the reader has to read the user memory area of
that tag.

Using the application-assist mode: The reader reports to the application
whenever it sees a matching tag, and then the application sends a read
command to read the user memory. The reader may then have to
re-singulate the tag, read the user memory and then report the result
back to the application.

Using the autonomous mode: An access-spec is created in the reader that
describes the target-tag and the operation to be performed on that tag.
So, whenever the reader sees the matching tag, it autonomously performs
the access operation then and there and sends the result back to the
application/server.

As deployments scale up in terms of tag traffic (volume), it should be
clear which would be the preferable approach.

None of the standards provide an interface to create/manage
'access-specs' at the readers. The irony is that in private some reader
vendors have admitted that this is good and required (or are in the
process of implementing such interfaces) - but its not reflected in any
of the standards.

Now coming to question (2):
You provided an interesting scenario where in a facility there are
readers talking SLRRP to the server and the other readers talking EPC RP
to the server.

You would want EPC RP for the subset of readers in the facility to which
the applications wanted to talk directly over http/xml; and those
readers were operating in a RF shielded environment and hence did not
require RF control, air-protocol control; and, if only operations to be
performed are reading/writing/killing tags; and if you wanted access
operations to be performed in an 'application-assisted' mode.

If all the above were true for all the readers in the facility, then yes
we would converge to using EPC RP - except of course we wont be able to
talk to those ISO readers in your example!

Please feel free to ask more questions. Looking forward to more
discussions.

Thanks & Regards,
Krishna

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

---

From: "P. Krishna" <[email-masked]>
Date: Thu, 20 Jan 2005 22:41:11 -0500

Great questions again Sapan.
 
I've updated the diagrams with my changes. RNC is not a dedicated hardware - nor are we introducing or specifying new elements into the network to support SLRRP. We coined the term RNC (reader control) to differentiate it from the traditional middleware functions (tag data processing). In both your diagrams, the RNC can be part of the middleware. The RNC is control and the data path interface for SLRRP - so if the middleware is the first-hop consumer of tag data from the reader, then obviously RNC is residing in the middleware.
 
As you can observe in the diagrams, I have shown some examples of EPC-based standards as the northbound interface of the middleware.
 
The other point you bring out in your diagrams which is quite orthogonal to this discussion. Its just FYI - there are readers in the marketplace that are 'multi-protocol' which means they are capable of inventorying tags of multiple protocols - however, the interface to them is not RP or any ISO protocol. The vendors have proprietary interface. 
 
Thanks,
/Krishna

________________________________

From: Sapan Shah [mailto:[email-masked]]
Sent: Wed 1/19/2005 10:31 PM
To: Sapan Shah
Cc: P. Krishna; [email-masked]
Subject: Re: [Rfid] Re: A few fundamental questions

Further,

I am attaching a diagram that I thought would help me clearing up with my
doubts.

>
> Krishna,
>
> I am confused - I believe SLRPP is for the communication between the
> reader and the RNC - a software application - as I take or a router, for
> example.
>
> ==
> Why would any air protocol matter to me? The readers are a set of devices
> which would have their own embedded code that will have the algorithm for
> interacting with/through the air protocol for reading the tags.
>
> As long as I have my reader on the network and my RNC (Any software that
> wants to read and process the tag list further) is able to send commands
> to the Reader, why would it matter to me as to what and how many air
> protocols are defined? I agree that RNC would be needed to control the
> read cycles so as to optimize the "Reader Network" efficiency, but again
> it doest it depend on the "air-protocols" per se'?
>
> I mean, All I would expect is sending a binary / ascii command to the
> reader and it responding back to me and the algorithm would be with me to
> contrl the network- Please correct me I am wrong.
>
>
>
> Regards
> Sapan
>
> Sapan Shah
> Patni Computer Systems Ltd
> http://www.patni.com
> 513-243-9071
>
>
>
>>> which

---

From: "Sapan Shah" <[email-masked]>
Date: Fri, 21 Jan 2005 00:51:53 -0500 (EST)

It makes sense. Let me try reading the draft again and I will check out,
 what it is like to understand this with the specified clarifications.

 Thanks
 Sapan

>> I've updated the diagrams with my changes. RNC is not a dedicated
>> hardware
>> - nor are we introducing or specifying new elements into the network to
>> support SLRRP. We coined the term RNC (reader control) to differentiate
>> it
>> from the traditional middleware functions (tag data processing). In both
>> your diagrams, the RNC can be part of the middleware. The RNC is control
>> and the data path interface for SLRRP - so if the middleware is the
>> first-hop consumer of tag data from the reader, then obviously RNC is
>> residing in the middleware.
>>
>> As you can observe in the diagrams, I have shown some examples of
>> EPC-based standards as the northbound interface of the middleware.
>>
>> The other point you bring out in your diagrams which is quite orthogonal
>> to this discussion. Its just FYI - there are readers in the marketplace
>> that are 'multi-protocol' which means they are capable of inventorying
>> tags of multiple protocols - however, the interface to them is not RP or
>> any ISO protocol. The vendors have proprietary interface.
>>
>> Thanks,
>> /Krishna
>>

---

From: "P. Krishna" <[email-masked]>
Date: Thu, 20 Jan 2005 23:44:50 -0500

From: Sapan Shah [mailto:[email-masked]]
Sent: Wed 1/19/2005 10:14 PM
To: P. Krishna
Cc: [email-masked]
Subject: Re: A few fundamental questions

Krishna,

==

==================
Hello Sapan,

As I mentioned in my previous reply to you, SLRRP is an interface to/from the readers. We coined the term RNC for the other end of the SLRRP interface. The examples given in the draft for RNC included dedicated hardware, router module, software on a server etc. However, SLRRP does not require a new entity called RNC to be introduced into the network. RNC is just a logical entity and is the control and the data path interface of SLRRP. RNC can be part of the middleware.

If you are an application, air-protocol should not matter to you - you shouldn't even care about specific readers. You can communicate over a higher-layer protocol like ALE or EPCIS to the middleware and query logical groups of readers for the tag data. 

However, the tag data is being acquired at the expense of RF bandwidth which is a valuable resource in a facility. Controlling read-cycles (i.e., start/stop) will certainly provide improvement over solutions that require the reader to be continuously ON. However, with increasing densities of reader deployment , just time-division multiplexing might not cut it. The user community, reader & tag vendors realized it and hence the output was a sophisticated air-protocol called C1G2 from EPC Global. There were some control knobs available in the Gen 1 protocols  but they were more to do with the singulation protocol (like, the control of the tree-walk for example - I've given an example for C1G1 in the draft). However, in the C1G2 protocol, not only are there knobs for controlling singulation, but also the RF parameters for the forward and reverse link. Some of the control can be done by the reader itself for problems dealing with a reader to multiple tag issue. However, when the problem is with interferece management due to multiple readers and multiple tags in a space, then either the readers sort them out or a controller device sorts it out. In either case, the readers might require some hand-holding - SLRRP provides a very granular interface for control and provides support for a range of reader control capabilities.

/Krishna