Subject: [Rfid] Newcomer Thoughts on SLRRP

From: "Suresh Bhaskaran" <[email-masked]>
Date: Wed, 23 Mar 2005 17:44:24 -0800

Hello Group,

I am a recent "newcomer" to SLRRP - I just read the document in great detail
yesterday.  I had a lot of "lights" go on when I read the document.  And
wanted to share some thoughts.

I am with Intelleflex, a long-range tag (semi-active) and reader solution
provider.  I am working *now* on putting in some new "class 3" features on
our reader, and am leading a software team here.

I emphasize the "now", because that is where I find SLRRP very attractive
(in terms of ideas and concrete specification, not necessarily as a standard
- since waiting for a standard may take a *long* time).

The things I liked (first impression) about SLRRP:

-          easy to *understand* and to implement (58 pages of text vs. EPC
global of 240 pages RP plus another 120 for RM).

-          Very cogent and coherent

-          At the "right" level (for us - Intelleflex): I like the fact that
multi-reader coordination at the RF level is thought about in this interface

-          I like the fact that it supports C1G2

-          I like the technical tradeoff exchanges in this forum - seem to
be at the right level for us.

-          I like the well thought-out "Select" command.  I have felt that
this is a *key* command.  Also, I like the fact that there is thinking at
the Q-value level for anti-collision

-          I like the fact that there has been some "sensor data" thinking
in the spec.  

Having said that, I am facing some challenges/tradeoffs relating to the
actual implementation.

If I am implementing *now*, then one option is to "hedge" my bets by using
the SLRRP "byte stream", but encapsulated in the XML format (for EPC
Global).  

All the middleware vendors we've talked to are so used to building "device
connectors" onto a new reader interface that they are willing to proceed
with a reader partner even if they are not (currently) EPC Global compliant.

But the challenge is to pick an API implementation (between reader and
host/middleware/rnc) so that a firmware upgrade on installed devices in the
future will not force the middleware partners to redo their host software.

So. the challenge is to pick an implementation (of the reader/host API)
*now* that is least resistant to future change.  

Any those are my thoughts and some of the issues I am struggling with.

Any feedback?

Suresh Bhaskaran

Software Manager

Intelleflex Corporation

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

---

From: Scott Barvick <[email-masked]>
Date: Thu, 24 Mar 2005 10:18:40 -0500

Suresh,

Glad to have you on the list.   As you will have noticed, the spec does
not have support for class 3 tags yet.   Are you using ISO standards or
looking forward to the EPCGlobal class 3 effort, or neither (e.g.
proprietary air protocol in advance of EPCGlobal class3)?

In any case, it would be a very interesting exercise to add the class 3
support to the current form of the SLRRP draft.  When we added the C0/C1
support, it took very little time once we understood the specific
capabilities of the protocol(s) beyond simple reading and writing.   If
it is proprietary, it would be a good example to push vendor extension
capabilities which I'll admit are not fully formed in the draft.  

We'll help if this is something you might want to do, and it could even
be done incrementally on the list to help pull out the specific
challenges.

Scott

On Wed, 2005-03-23 at 20:44, Suresh Bhaskaran wrote:
> Hello Group,
> 
>  
> 
> I am a recent “newcomer” to SLRRP – I just read the document in great
> detail yesterday.  I had a lot of “lights” go on when I read the
> document.  And wanted to share some thoughts.
> 
>  
> 
> I am with Intelleflex, a long-range tag (semi-active) and reader
> solution provider.  I am working *now* on putting in some new “class
> 3” features on our reader, and am leading a software team here.
> 
>  
> 
> I emphasize the “now”, because that is where I find SLRRP very
> attractive (in terms of ideas and concrete specification, not
> necessarily as a standard – since waiting for a standard may take a
> *long* time).
> 
>  
> 
> -         easy to *understand* and to implement (58 pages of text vs.
> EPC global of 240 pages RP plus another 120 for RM).
> 
> -         At the “right” level (for us – Intelleflex): I like the fact
> that multi-reader coordination at the RF level is thought about in
> this interface
> 
> -         I like the technical tradeoff exchanges in this forum – seem
> to be at the right level for us.
> 
> -         I like the well thought-out “Select” command.  I have felt
> that this is a *key* command.  Also, I like the fact that there is
> thinking at the Q-value level for anti-collision
> 
> -         I like the fact that there has been some “sensor data”
> thinking in the spec.  
> 
>  
> 
> Having said that, I am facing some challenges/tradeoffs relating to
> the actual implementation.
> 
>  
> 
> If I am implementing *now*, then one option is to “hedge” my bets by
> using the SLRRP “byte stream”, but encapsulated in the XML format (for
> EPC Global).  
> 
>  
> 
> All the middleware vendors we’ve talked to are so used to building
> “device connectors” onto a new reader interface that they are willing
> to proceed with a reader partner even if they are not (currently) EPC
> Global compliant.  
> 
>  
> 
> host/middleware/rnc) so that a firmware upgrade on installed devices
> in the future will not force the middleware partners to redo their
> host software.
> 
>  
> 
> So… the challenge is to pick an implementation (of the reader/host
> API) *now* that is least resistant to future change.  
> 
>  
> 
> ______________________________________________________________________