Subject: [Rfid] Reader Protocol

From: "Eric S. Crawley" <[email-masked]>
Date: Mon, 21 Mar 2005 21:56:53 -0500

OK, so it sounds like dividing the problem space into two areas, reader
protocol and management has a  bit of consensus.  Let's dive into the reader
protocol a bit.

What do we want for a reader protocol?  I would propose that you want a
efficient, simple-to-implement protocol that rides over a well known
transport.  The readers are going to vary from very simple Ethernet powered
devices to PC Cards in a laptop to hefty systems with lots of memory and
compute power...a wide range from multiple manufacturers.

Krishna's draft (draft-krishna-slrrp-01.txt) goes into great detail on one
example over TCP using traditional binary protocol techniques.  My
understanding is that the EPCGlobal data definitions have been defined in
XML (please correct me if I don't have that right).  So, are there other
possibilities that should be considered?  Should the XML just be plopped
into TCP byte streams?  Are the gains in using XML worth the overhead?

Thoughts? Opinions? Options?

    Eric

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

---

From: "P. Krishna" <[email-masked]>
Date: Tue, 22 Mar 2005 01:00:28 -0500

> compute power...a wide range from multiple manufacturers.

Hi Eric,
Very good points regarding the versatility in the reader configurations and hence
capabilities. This should get reflected in the network-side reader protocol that
provides a granular yet efficient (to support the simple, low-end) interface. 
 
I would like to take this opportunity to provide a quick overview of the communication
requirements for the reader control protocol (not management or configuration). 
 
One of the goals of this effort is to support the currently defined and future
air-protocols. For the uninitiated, there are multiple air protocols at various stages
of deployments/standardizations worldwide. Some examples are EPCGlobal Class 0, 0+, 1,
Class 1 Gen2; ISO 18006a, 18006b, 18006c. 
 
There are at least 3 ways to design a reader control protocol to support multiple air 
protocols:
(i)   Make the reader protocol air-protocol agnostic - i.e., have abstract commands.
(ii)  Make the reader protocol air-ptotocol aware - i.e., force each command to have 
      air-protocol specific parameters passed.
(iii) Have a granular interface - allow the flexibility to have at one end of the spectrum,
      abstract commands for readers that can make autonomous decisisions, and at the other
      end of the spectrum, be able to control the air-protocol parameters at a very fine 
      granularity for readers that support such a model of operation.
 
We believe that option (iii) is the best alternative. Towards that end, in the SLRRP draft,
we defined air-protocol specific parameters for couple of protocols (Class 1 Gen 2 and Class 1
Gen 1), and also took a stab at abstractions for singulation parameters to make it protocol
independent. The work is far from complete. 
 
This however just covers the control portion. There is more importantly the
data portion. Data portion pertains to the access operations (read/write/lock etc) on tag memory 
contents. Unfortunately, the way RFID air-protocol standards have evolved till date, the tag-data layout 
is tied to the air-protocol - the network equivalent of this phenomena is that the "application 
data layout" is dependent on the mac protocol - yes its sounds bizarre, but its true. For example,
some of the upcoming protocols in the near future (Class 2) will have more memory richness than
the the Class 1 Gen 2 memory. If it was an issue of just tag memory, then we could have dealt it
as a flat memory and addressed them - however, there is another twist - different tag manufacturers
may enable/disable optional features/memory locations. This introduces some unique data management 
problems that have not been encountered even in the current RFID landscape. Definitely, this information
does not reside in the reader - its an application domain problem and the hosts have to communicate
the data-access operations to the reader which acts as the gateway.
 
Summarizing ... following are the 2 types of air-protocol specific items that gets communicated over the 
network side protocol like SLRRP:
 (a) Tag memory layout and contents: This is the 'data' portion. The
 memory layout is different for different air-protocols, and the memory layout may change across tag
 manufacturers. The tag memory contents include:
 * passwords (for accessing, lock, kill),
 * the item identifier (or also called the EPC code),
 * user memory (which can contain sensor data, timestamp, or other useful
 information that makes sense to be carried along with the consumer
 item),
 * TID: this has the information of the tag manufacturer (_not_ the
 manufacturer of the consumer item, but the manufacturer of the tag)
 In order to access (read/write) the tag memory, the reader sends over-the-air air-protocol
 specific commands, with the data. 
 
 The host communicates to the reader, the access operations along with associated data; the
 reader returns the results of the access operations (could be acks/naks and the
 contents of the desired tag memory locations).
 This I believe is one of the most important requirements - as stated in the Bof, ultimately, 
 its the communication between the Applications and the Tags that needs to be facilitated using 
 the network infrastructure.
 
 (b) Air-protocol specific control parameters: This is the 'control'
 portion. These are parameters that are applied by the reader during the air-protocol
 interactions, for single reader to multiple tag interference, and
 reader to reader interference management. This problem was presented in great detail
 (may be more than necessary for the target audience) by Todd (Impinj) and Kevin (Matrics). 
 In a recent email,  Kevin again highlighted the importance of interference management.

> Thoughts? Opinions? Options?

 I am not clear about what you meant by EPCGlobal data definitions in XML? They have
 couple of protocols that use XML encoding. I dont think there are any 'data' defined
 in XML. 
 
 XML is 'cool' and has benefits, such as extensibility and human readability. 
 I dont think human readability is a goal or requirement for this reader protocol. I have
 my opinions regarding xml and extensibility especially in the reader-protocol space. I just want
 to make one point that XML is not magic - it does not automagically enable extensibility. 
 Extensibility is achieved when both parties on the either side of the link implement the changes 
 in XSD associated with the XML changes - how different is it from binary codes that are agreed upon 
 by both the parties.  
 
 I would like to hear what other people have to say about this issue.
 
Thanks,
/Krishna