Subject: [Rfid] Re: Rfid Digest, Vol 6, Issue 9

From: Larry Martin <[email-masked]>
Date: Tue, 22 Mar 2005 12:40:33 -0500

Hello -

Most people expect a binary protocol, and assume it will be faster; 
however, we all have had experience with packing, byte order and other 
issues making it difficult to maintain binary protocols.  Besides making 
it difficult for engineers, these issues make life hard for users when, 
for example, new server code makes it impossible to talk to client nodes 
until all clients are updated locally.  XML, as a tagged protocol, 
provides many synch points which software can use to parse incoming 
messages, making a more fault tolerant overall system.  As a human 
readable protocol, XML allows quick startup of engineering efforts, 
i.e., you don't have to write new PC software to debug the embedded 
interface.

As the former lead programmer for SAMSys, I designed and implemented a 
human readable HDLC protocol with tagged syntax for SAMSys' line of 
multifrequency, multiprotocol readers.  It's called CHUMP, some readers 
may be familiar with it.  It has been criticized for wasting serial line 
bandwidth, but nobody has ever convinced me that the protocol per se was 
the source of any bottlenecks.  To be fair, the processing overhead of 
text-binary conversion does slow things down on the slower targets (we 
started out with PIC processors), but those slower targets are also free 
to implement a subset of the protocol.

By using a human-readable protocol, SAMSys was able to concentrate on 
embedded development during the early years, and was not distracted by 
the vagaries of programming for the various flavors of Windows and 
Linux.  To be fair, again, SAMSys has been able to get by without a 
Windows API or application software, and that has made it harder for 
some integrators to adopt their devices (that is a whole separate 
discussion).

I think this group should carefully consider specifying a human readable 
protocol, and look forward to discussing the issue with the group.

Regards,
Larry Martin
www.GlueLogix.com
Embedded System Consulting Including RFID

>>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.
 >
> [snip]
 >
>>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
> 
> 
>  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
>  

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

---

From: Marshall Rose <[email-masked]>
Date: Wed, 23 Mar 2005 09:38:26 -0800

> issues making it difficult to maintain binary protocols.  Besides 
> making it difficult for engineers, these issues make life hard for 
> users when, for example, new server code makes it impossible to talk 
> to client nodes until all clients are updated locally.  XML, as a 
> tagged protocol, provides many synch points which software can use to 
> parse incoming messages, making a more fault tolerant overall system.  
> As a human readable protocol, XML allows quick startup of engineering 
> efforts, i.e., you don't have to write new PC software to debug the 
> embedded interface.

there are many advantages to text-based approaches, some of which you 
cite; however, in the absence of hardware acceleration, it is unclear 
whether a text-based approach will prove sufficiently scalable for the 
application domain under consideration.

krishna is right in asking whether someone has done some calculations 
and measurements to understand the size of the problem. based on the 
fan-out numbers that i heard in the bof, i remain unconvinced as to the 
suitability of a text-based approach.

for myself, i have found that the same engineers who can't implement 
binary protocols correctly, also have difficulty getting tags to close 
properly... in other words, the difference between theory and practice 
with respect to ease of implementation, tends to be much larger in 
practice than in theory...

/mtr

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 23 Mar 2005 14:27:58 -0500

Hi Marshall,

At 9:38 AM -0800 3/23/05, Marshall Rose wrote:
>krishna is right in asking whether someone has done some 
>calculations and measurements to understand the size of the problem. 
>based on the fan-out numbers that i heard in the bof, i remain 
>unconvinced as to the suitability of a text-based approach.

What fan out numbers did you hear at the BOF?  And were they based on 
any current or planned real-world deployments?

Here is my idea of some numbers:

EPC1 (EPC Global Class 1) readers running in a multi-tag search mode 
will max out at ~80-100 tags per second if a constant supply of new 
tags are moved into read range.

The EPC0 protocol is faster, allowing up to ~150-200 new tag reads a second.

These rates are very unlikely to be achieved on a sustained basis. 
Dock door readers tend to have bursts of activity when pallets are 
moved by their antennas, for instance, while conveyor belt readers 
are much more likely to read one tag every 100-200ms (5-10 tags per 
second), due to spacing between the boxes.

A tag read consists of 96-bits of tag data and some meta-data (where 
and when the tag was read).  In rare cases, there may also be some 
tag data includes (up to another 96 bits).  So, let's assume that 
each tag read represents 64 bytes of data to be transferred from the 
reader to the back office database (this is a huge over estimate).

The largest planned RFID installation that I have heard discussed 
includes <200 RFID readers in a single distribution center.  More 
typical installations are 10-50 readers at a single location.  At any 
given time, many of the fixed readers in a distribution center will 
be turned off, as the readers are only active when the dock door to 
which they are attached is open and/or when their conveyor belt is 
operational.  There are people considering ways to reduce the total 
number of readers in a distribution center by attaching them to 
forklifts (~50-100 per distribution center) instead of to dock doors, 
so that a larger percentage of the readers will be active at any 
given time.

So, let's say that you have 200 readers on a single LAN, each reading 
200 tags a second.  That would be 400x64 bytes of tag data, or 25,600 
bytes of real data.  If this were encapsulated in a way that only 
achieved 25% efficiency (75% network/protocol overhead), we would 
still only be talking about 102,400 bytes (819,600 bits) of data a 
second for the entire reader network -- less than a megabit.

So, I don't think that it could be total network traffic that folks 
are concerned with...  Is there some other scaling factor here that 
we should be considering?

Margaret

---

From: Marshall Rose <[email-masked]>
Date: Wed, 23 Mar 2005 11:54:09 -0800

> any current or planned real-world deployments?

i refer you to the minutes...

> given time, many of the fixed readers in a distribution center will be 
> turned off, as the readers are only active when the dock door to which 
> they are attached is open and/or when their conveyor belt is 
> so that a larger percentage of the readers will be active at any given 
> time.
>
> are concerned with...  Is there some other scaling factor here that we 
> should be considering?

there are two problems with this line of argument. first, it assumes an 
upper limit defined by a single data point. that's not an architectural 
assumption that i care to make.

second, it assumes that wire bandwidth is the only constraint. 
depending on the complexity of the textual encoding (e.g., xml content 
model, naming conventions, etc.), it is unclear to me that the wire 
would be the bottleneck. hence the remark in my earlier message about 
the feasibility of the text-based system in the absence of a hardware 
accelerator.

/mtr

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 23 Mar 2005 15:56:28 -0500

At 11:54 AM -0800 3/23/05, Marshall Rose wrote:
>there are two problems with this line of argument. first, it assumes 
>an upper limit defined by a single data point. that's not an 
>architectural assumption that i care to make.

So, would folks like to provide other real-world data points?

Or are we just going to go with the assumption that, despite current 
deployment plans (many of which go out two years or more), FCC & ETSI 
regulations and the laws of physics, 1000 readers will be deployed in 
a single location.  That certainly provides us with a more 
academically interesting problem to solve.

>depending on the complexity of the textual encoding (e.g., xml 
>content model, naming conventions, etc.), it is unclear to me that 
>the wire would be the bottleneck. hence the remark in my earlier 
>message about the feasibility of the text-based system in the 
>absence of a hardware accelerator.

Do you have any data on the amount of processing power required to 
process fixed-field protocols vs. the amount of processing required 
to run expat on canonical XML containing the same data?  Do we have 
any rules-of-thumb regarding memory utilization for one or the other?

I gave some data during the BOF on the capabilities of RFID 
equipment.  The two most common cases will be:  (1) a stand-alone 
("fixed") RFID reader, which has processing power and memory similar 
to a home gateway or wireless access point (for example, a Linux or 
WinCE box with a ~200+ MHz processor, 32MB of flash and 128MB of RAM) 
or (2) an embedded RFID reader that DSP-only and is embedded in a 
system that runs a host processor (a handheld WinCE computer or a 
special-purpose device like a printer or cash register).

Currently, most fixed readers are not CPU or memory-constrained, and 
the companies that build the most CPU or memory-constrained readers 
are known to be working on updates to faster processors, more memory 
and general-purpose operating systems like Linux or WinCE.  I don't 
know about the handheld computers, as we don't build those -- ask 
someone from Symbol or PSC.  It is difficult to characterize the 
special-purpose devices, and in many cases (printers, for example) 
these devices may not serve the same purpose as fixed RFID readers, 
and therefore may not be controlled using the same protocol.

Margaret

---

From: Scott Barvick <[email-masked]>
Date: Wed, 23 Mar 2005 18:28:29 -0500

Margaret,

I guess I view that if we agree that the current number of readers in a
facility is in the hundreds, we should be designing for the next step. 
Adding more readers won't require us to change the laws of physics or
regulations, but they will require a step up in the ability to
coordinate.  

If we also agree that there can be 200 readers in a facility even now,
and we agree that they need to be coordinated, then coordination will
necessarily happen over the air or over the IP network.  If it is
happening over the IP network then the ability to communicate that
control needs to be standardized in the IETF (possibly the control
itself e.g. OSPF but I'm not ready to go there yet).  No proprietary
coordination mechanism at such a large scale will survive the big
customers wanting a second source for their readers, and we know that
will happen as the industry matures.

On the platform discussion, I think the capabilities of the platform are
the next step in the discussion so it is good to see what input we can
get.

Scott

---

From: Marshall Rose <[email-masked]>
Date: Wed, 23 Mar 2005 16:17:42 -0800

> academically interesting problem to solve.

i find it difficult to believe that i have to explicitly argue that it 
is necessary to engineer for more than what is needed on March 23, 
2005... to argue the contrary is to advocate a specific disconnect from 
ietf practice. let's file that with the "64KB is enough memory for a 
desktop computer" assumption, or the "128 is a good upper limit for the 
number of end-systems on a physical segment" assumption.

in other words, if we want to plan for today only, then we should 
expect "obsolescence before deployment"...

>> message about the feasibility of the text-based system in the absence 
>> of a hardware accelerator.
>
> process fixed-field protocols vs. the amount of processing required to 
> run expat on canonical XML containing the same data?  Do we have any 
> rules-of-thumb regarding memory utilization for one or the other?

there is an entire industry of vendors who do nothing more than sell 
very powerful xml accelerators in hardware. these devices front-end 
large systems, not little readers, not embedded systems, they front-end 
medium- to big-iron. i suspect we might learn something from that. and, 
yes, they have tons of data on why you need that kind of investment for 
performance sake.

now, it's true that i don't have specific data on this problem, but 
then it's also true that there isn't a comprehensive xml solution to 
analyze.

in other words, don't ask me to measure non-existent things...

/mtr

---

From: "P. Krishna" <[email-masked]>
Date: Wed, 23 Mar 2005 19:24:12 -0500

Hi Margaret,

> The EPC0 protocol is faster, allowing up to ~150-200 new tag reads a second.

I have a huge problem with this type of analysis. Its like saying, for
example, today's state of the art ethernet switches can forward packets
only at the rate of 10 pkts/sec; so even if the link can run at a 1Gb/s,
I'm going to standardize the 'switch-management' protocol to match the
limited performance of the device, and not the target link capacity.

I would instead look at the capacity numbers of the air protocol itself:
EPC C0: ~600 tags/sec
EPC C1: ~400 tags/sec
ISO 180006c/EPC C1G2: ~1600 tags/sec

The current state of RFID industry is such that the standards are ahead
of the technology. This is quite normal in a nascent industry. But, I
dont think the industry can sit still and be content with it. You have
already seen the whole C1G2 effort in action. If the users were content
with the Gen1 protocols, why did the community push for the
super-charged Gen2 protocol? And, it wouldn't stop @ G2 either - there
will be more air-protocol improvements.

Now coming to XML versus binary discussion:
- It is so counter-intuitive to propose a solution that consumes more
network bandwidth and more processing power & memory at the reader. If
you are going to argue that XML is efficient in both those respects when
compared to binary, then I would like to learn more.

- I would like to repeat that our goal here is develop a scalable and
efficient solution that spans a wide range of reader capabilities. I
understand there are couple of reader manufacturers today who have linux
running on 200Mhz processors, and can even run the application software
on it. But if you are going to declare that, that indeed is going to be
the entire spectrum of readers, I would respectfully disagree.

- Now coming to the deployment size issue. You said ...

> a single location.  

Can you pls explain what has FCC got to do with limiting the number of
readers that can be deployed in a single facility? I am confused. What
new problems crop up when you have 1000 readers deployed instead of 200
readers which you claim is the maximum deployment size? 

One other problem with your analysis is maybe with your assumption of
reader models. The current reader models have multiple antennas, for
example 4. Even if they have 4 antennas, only one of them can be ON at
any time due to regulatory reasons; hence even if there are 800 antennas
(going by your 200 reader maximum) distributed in the facility, a
maximum of only 200 data acquisition points are active at any time. 

Now, lets consider an integrated reader mode. If you have readers with
integrated antennas, then 800 antennas corresponds to 800 readers or
data acquisition points. Now, you have potentially 800 readers sending
tag data. So, with same # of antennas in the facility, we can have two
different traffic numbers.

- The only reason I can think of why XML is proposed is for
extensibility reasons. [BTW, I just dont buy the 'readability'
requirements.].  If you agree, then I can argue that the added
complexity required to support extensibility (vendor extensions using
namespaces, attribtuts etc) requires you to use standard XML parsers,
for which there is a whole industry building hardware accelerators for! 

- BTW, I sat through a BoF at the recently concluded IETF - 6lowpan
which is IPv6 over low(cost, power etc) personal area networks. I
thought its great that IETF is thinking of solving problems for
'resource-contrained' devices. And, here you are proposing to employ a
solution that runs counter to that.

[Off-topic: I would say you were being generous with your C1 performance
numbers - we have a reader in our lab that does hmm.. <10 tags/sec when
the fluoroscent light is on - go figure!]

Thanks,
/Krishna

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 23 Mar 2005 21:35:01 -0500

Hi Marshall,

At 4:17 PM -0800 3/23/05, Marshall Rose wrote:
>>>  there are two problems with this line of argument. first, it 
>>>assumes an upper limit defined by a single data point. that's not 
>>>an architectural assumption that i care to make.
>>
>>  Or are we just going to go with the assumption that, despite 
>>current deployment plans (many of which go out two years or more), 
>>FCC & ETSI regulations and the laws of physics, 1000 readers will 
>>be deployed in a single location.  That certainly provides us with 
>>a more academically interesting problem to solve.
>
>i find it difficult to believe that i have to explicitly argue that 
>it is necessary to engineer for more than what is needed on March 
>23, 2005... to argue the contrary is to advocate a specific 
>disconnect from ietf practice. let's file that with the "64KB is 
>enough memory for a desktop computer" assumption, or the "128 is a 
>good upper limit for the number of end-systems on a physical 
>segment" assumption.
>

If we are going to write a protocol to manage RFID readers, I want us 
to make a protocol that is well-suited to the nature of RFID 
readers...

The limitations that I am citing are not the limitations of today -- 
today's performance is actually much lower in most cases, they are 
the theoretical limitations of the known RFID protocols and 
state-of-the-art RFID technologies.

RFID tags are low power, tiny, inexpensive (<$0.20) devices with 
limited capabilities.  They are only capable of communicating at very 
low bit rates.  In EPC1 (the protocol with which I am most familiar) 
the bit rate from the reader to the tag ranges from ~20 bits per 
second up to ~75 bits per second, and the return bit rate from the 
tag to the reader is twice that -- ~40 bits per second to ~150 bits 
per second.  The lower bit rates are used in Europe and other regions 
where the regulatory requirements are stricter, and the higher bit 
rates are used in the U.S., Canada and other regions where the 
regulatory requirements are less strict.

There is a well-defined protocol for communicating to the tags, and 
it is possible to do some analysis on the theoretical fastest read 
rate that one can achieve using EPC1 tags with various population 
sizes, etc.  That is the information that I tried to provide.  Vague 
statements about planning for future capabilities will not change the 
inherent limits of this protocol.

The EPC Gen2 protocol supports higher bit rates, but I believe that 
the maximum bit rates are still in the low 100's of bits per second. 
We have yet to see final tags for this protocol (it is still in the 
early stages of development) and it is possible that readers and tags 
will not support the highest bit rates while meeting regulatory 
requirements in the U.S. or other regions.

EPC Gen2 is also a heavier-weight protocol than EPC1, so despite the 
higher data rates to/from the tags, it may or may not achieve higher 
overall tag read rates.  I have yet to do the analysis to determine 
the theoretical limits of EPC Gen2, and would welcome input from 
someone who has.

The physics limits that I am discussing are somewhat harder to 
explain in an e-mail to people who may not have studied the physics 
of RFID, but I will try...

A full-power fixed RFID reader (30dBm with a 6dBi antenna) can 
comfortably fill a 6 or 9 cubic meter space with RF for each antenna 
that it has attached (1 meter high, 2 meters wide, 2-3 meters long), 
and most of the RFID readers that are used in large deployments (such 
as retail distribution centers) have 4 or more antennas.

So, a single reader could theoretically fill 24-36 cubic meters of 
space with RF, but this isn't usually the case, as a readers antennas 
are usually grouped (in a single dock door, two sides of adjacent 
dock doors, around the front of a fork lift, around a location on a 
conveyor belt, or across the opening to a pick bay, for instance). 
This is a nice arrangement, because a reader automatically 
synchronizes its own antennas (by switching between them), so the 
antennas of one reader won't conflict with each other even if their 
RF fields would overlap, and this type of configuration gives you 
more "geometry" to power and read the tags (being able to read tags 
on multiple surfaces of a box or pallet).  So, it is generally 
expected that there will be an average of one reader deployed for 
each dock door or pick bay door in a distribution center.   There may 
also be reader deployed every few meters along conveyor belts, or on 
every forklift (facing inward toward the forklifts payload).

Some of the "smart antenna" devices inherently have one antenna, so 
their antennas are not grouped this way.  In "smart antenna" 
deployments, there will a separate reader for every read point, and 
coordination will be required between them in order to get any 
"geometry" benefits.

The problem comes in when you have multiple active readers.  If two 
readers have overlapping RF fields, and a tag exists in the overlap, 
one of three things will happen:  (1) one reader's signal will be 
much stronger than the other (due to proximity) and that reader will 
read the tag, (2) the two reader's signals will combine in a way that 
makes them impossible to decode, and the tag will not hear commands 
from either reader, or (3) the two reader's signals may combine in a 
way that causes the tag to hear some commands, corrupted commands, or 
partial commands from the two readers.  In this case, the tag can 
become confused, respond inappropriately, misinterpret commands, 
erase its own data, or any number of other bad things...  So, it is 
rather important not to run readers in configuration where they will 
have overlapping RF fields operating at the same time.

This is a fundamental limit of the technology, and it is not 
substantially changed by EPC Gen2 or any other RFID protocols that I 
have heard discussed.

Although people will talk about having different readers running at 
different channels within the band, this really doesn't help, as the 
tags do not selectively tune to a particular channel -- they have a 
wide band receiver and receive all reader signals (and interference) 
across their entire band (which may be only a single regional band, 
or may span across the bands for EU (around 868MHz), the US (around 
915MHz) and Japan (around 950MHz)).

So there are really two practical choices:  (1) Synchronize adjacent 
readers (using time synchronization or wide-band listen-before-talk) 
to prevent two readers from occupying the same RF field at the same 
time, and/or (2) deploy readers so that their RF fields are not 
largely overlapping.  The first choice has the downside of 
drastically reducing the duty cycle of both readers, so there is no 
real advantage (in the number of readers that will be active at one 
time, or in the number of tags that will be read) to installing 
readers in a much denser deployments than I have described above.

In general, there is no known application to filling the volumetric 
space of an entire facility with RF, and the human dwell time and 
tissue heating regulations (CE, OSHA, etc.) in various regions make 
it _highly_ unlikely that this will ever be legal.  Please remember 
that these readers are running at much higher power than 802.11 
wireless APs, as they don't only communicate with the tags, they also 
power the tags.

Margaret

---

From: Larry Martin <[email-masked]>
Date: Wed, 23 Mar 2005 23:49:03 -0500

Whoever made the comment, two days ago, about 'religious discussions' 
was right on the money.  I am going to make a few short points and fade 
away ...

1.  I spend a lot of time staring at sniffers and analyzers of various 
sorts.  Human readability is a huge plus for me and, I believe, for the 
people who will be making this stuff work over the next five years.

2.  The difference in packet size for a given amount of information 
between binary and ASCII protocols is typically a factor of between two 
and three.  If half your network bandwidth is taken up with RFID data, 
you are going to be building subnets and concentrators anyway.  Human 
readability does not cost you a factor of ten in data size, i.e. it is 
not an overwhelming waste of bandwidth.  Conversely, choosing a binary 
protocol does not buy you a factor of 10 in data size, as compression might.

3.  Theoretical maximum air interface rate is a scam.  If you report, or 
even store, your data, you are taking compute cycles away from the air 
interface.  The readers that claim to approach air interface maximum 
rates do so by by reporting air interface time, "correcting" for the 
time they spend storing and/or reporting data.  Further, most of the tag 
detection events that occur in a tag/reader system are repeated reads of 
already known tags, which can be encoded as repeat counts rather than as 
unique events.  You are never going to see 1600 unique EPCs from one 
reader in one second, regardless of the air (or wire) protocol.

Larry.

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 24 Mar 2005 07:29:03 -0500

>ISO 180006c/EPC C1G2: ~1600 tags/sec

The way the tag protocols are defined, there is a degenerate 
mechanism in each protocol that can be used to read a tag if you know 
that there will only ever be one tag in the field at a time.  A 
degenerate search algorithm can be constructed by issuing that type 
of command over and over again to read the same tag, and setting the 
reader to simply count tag reads (not store the ID or timestamp 
information).  This is the moral equivalent of testing the speed of 
an TCP/IP stack with a kernel-level source/sync application that 
never reads or writes the data to or from a disk and never passes it 
up to the application layer.

BTW, the theoretical EPC C1 limit is much closer to 1000 reads per 
second.  Matrics claims to achieve that level with their AR-400 and I 
see no reason to doubt them.  We can almost reach that number if we 
count reads at the DSP level and don't bother to store the IDs and/or 
pass the reads to our higher level processor.  But, this number is 
not even remotely interesting to the question of how RFID systems 
will perform in real-world applications and/or to how a real-life 
RFID management application will scale.

These numbers cannot be achieved in any practical application of RFID 
-- not because of today's implementations, but because of inherent 
limits of the technology.  Even if you did find an application that 
consisted of reading the same tag over and over again as quickly as 
possible and just counting the number of times it was read, readers 
would report that information periodically as a single tag read with 
a large read count.

My more practical numbers attempted to report the theoretical upper 
limit of separate tag reads that can be achieved using an 
anti-collision search/verification algorithm, and therefore represent 
the largest amount of tag read data that will be generated by a 
single reader.  Please note, these are not the numbers that people 
are achieving today -- they are the numbers that can theoretically be 
achieved using today's and tomorrow's protocols.

>readers which you claim is the maximum deployment size?

The FCC requires random frequency hopping for readers at 400ms 
intervals.  In addition to significantly lowering the overall read 
rate (the numbers you've listed above can only be achieved if 
frequency hopping is disabled, among other things), this makes it 
impossible to engineer any channel separation between adjacent 
readers (to avoid the type of interference that the Josh presented at 
the BOF).  The FCC also forbids active coordination between the 
readers to share the RF band.  So, you are only left with the two 
choices in my earlier message (time-based or listen-based 
synchronization or physical separation).  This means that, while you 
could place 1000 readers in the same facility (opting for 
synchronization, rather than physical separation), they could not all 
be active at the same time.

>different traffic numbers.

This is only pertinent if you assume that all of the antennas will 
all be active at the same time.  If you still assume that there will 
be four-to-six antennas pointing at the same dock door, or at the 
same point on a conveyor belt (as is necessary to get the "geometry" 
that I discussed), then those groups of "smart antennas" will need to 
be synchronized  (just like four or six antennas attached to a single 
reader) so that only one of them is active in a given space at the 
same time.  I tried to explain that in my message, but perhaps I was 
too terse.

>for which there is a whole industry building hardware accelerators for!

Why are people so afraid of XML parsers?  There is also a whole 
industry building accelerators for TCP/IP, but I don't need one in my 
RFID reader. In fact, I've personally worked on a TCP/IP stack that 
runs on a DSP just fine.

In a past life, we worked on an expat-based XML parser for embedded 
use that was optimized to parse canonical XML -- its system 
requirements were not prohibitive, it did in-line, asynchronous 
parsing so that it didn't consume huge amounts of memory, and it 
didn't consume a prohibitive amount of processor time, either.

So far, several groups have implemented the IETF's NETCONF protocol 
(an XML-based configuration protocol) and they have not complained 
that it requires XML accelerators.  And, the applications area is 
happily standardizing XML-based protocols (such as XCAP) that are 
primarily for use on cell phones.  So, I think that this belief that 
"XML == need for XML accelerators" is way overblown.

In general, RFID readers do not need to have a real-time connection 
to the back office databases.  The readers timestamp their tag reads, 
so back office applications can get an accurate idea of when a tag 
was read (if they choose to access that information), even if that 
tag information is not reported to the back office immediately.  This 
is needed anyway, as fixed readers are increasingly expected to 
gather data off-line when the network is down and report it when 
networking connectivity is resumed.

BTW, the need for off-line operation is something that you should 
consider in constructing a reader control protocol.  Where possible, 
readers should be configured to operate autonomously when they cannot 
reach (or be reached by) the controller.  Customers will not want the 
network or the controller to represent a single point of failure in 
their RFID supply-chain system.

Margaret