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

From: "P. Krishna" <[email-masked]>
Date: Thu, 24 Mar 2005 00:50:16 -0500

Hi Larry,
At least you are consistent and persistent with your readability criteria. I cannot argue with you on the basis of which is easier to read - obviously ascii is easier to read - but what you are suggesting here is that the encoding of a protocol be chosen based on the ease of debugging. Is that correct?
 
> 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.

You make three interesting points here. 
1) You can never design a reader that can keep up with the air protocol's maximum rate. I dont agree with that. You are describing a particularly poor design, where the same processing engine is time-shared between the air protocol state machine and tag data processing and reporting. There are already designs which use DSPs for air-protocol, and general purpose CPU for data processing. I dont see why if properly designed, a reader becomes the bottleneck.
 
2) Maximum air interface rate is a scam. What is the point in defining a specification for an air protocol if you apriori know that those numbers are 'theoretical' and never going to be met? I think by calling it a scam, you are questioning the standards body's integrity?
 
3) You will never have 1600 unique EPCs in a reader's field of view.
As you are well aware, readers can be at different locations in a facility or may even be in a truck. In a facility, readers can be at dock doors, around conveyor belts, monitoring an open storage area, shelves etc etc. Today, pallets and cases get tagged. Are we going to stop at that - no - next is item-level tagging. 
 
Let us look at the numbers Margaret presented in her email:
> 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),

Using 6 cubic meter volume of RF: suppose this reader is monitoring an area full of DVDs. [There are retailers that are tagging DVDs today.]
Each DVD case is roughly 19cm x 13cm x 1.5cm = 370 cubic cm. We can fill about 16000 DVDs in 6 cubic meter space. Q.E.D.

Thanks,
/Krishna

________________________________

From: Larry Martin [mailto:[email-masked]]
Sent: Wed 3/23/2005 11:49 PM
To: P. Krishna
Cc: [email-masked]
Subject: Re: [Rfid] Re: Rfid Digest, Vol 6, Issue 9

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.

P. Krishna wrote:
> Hi Margaret,
>
>
>>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.
>>
>
>
> 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 ...
>
>
>>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. 
>
>
> 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
>
>
>
>

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

---

From: Larry Martin <[email-masked]>
Date: Thu, 24 Mar 2005 08:23:02 -0500

Hi, Krishna -

P. Krishna wrote:
> Hi Larry,
> At least you are consistent and persistent with your readability 
> criteria. I cannot argue with you on the basis of which is easier to 
> read - obviously ascii is easier to read - but what you are suggesting 
> here is that the encoding of a protocol be chosen based on the ease of 
> debugging. Is that correct?
>  
Obviously readability should not be the only criterion.  But as people 
point out, RFID technology is in its infancy.  Which is going to be 
better for the adoption and development of the industry - readable or 
unreadable protocols? With a readable protocol, I can tap the system at 
any point with simple tools and verify my datastream.  With a binary 
protocol, I cannot do that until I first write or buy software to 
interpret the datastream.

Database people have been doing this way longer than we have, and their 
interchange standard is ASCII.

> 1) You can never design a reader that can keep up with the air 
> protocol's maximum rate. I dont agree with that. You are describing a 
> particularly poor design, where the same processing engine is 
> time-shared between the air protocol state machine and tag data 
> processing and reporting. There are already designs which use DSPs for 
> air-protocol, and general purpose CPU for data processing. I dont see 
> why if properly designed, a reader becomes the bottleneck.
>  
DSPs are not magic.  Even a DSP must report results, taking time from 
the air interface.

> 2) Maximum air interface rate is a scam. What is the point in defining a 
> specification for an air protocol if you apriori know that those numbers 
> are 'theoretical' and never going to be met? I think by calling it a 
> scam, you are questioning the standards body's integrity?
>  
No I am not questioning anyone's integrity.  But I am questioning the 
leap of judgement that assumes 1600 potential tags per second on the air 
interface equates to a requirement to support 1600 unique EPC's on the 
wire per second, every second.  First, as Margaret noted, the data 
pattern is bursty and not sustained.  Second, tags consume power.  1600 
tags at 10 mW per tag would consume 16 watts, and the FCC limits us to 1 
watt.  Third, tags mask each other magnetically.  Fourth, higher 
bitrates inherently diminish the robustness of the datalink, just as 
with your modem.  Remember, tags can only load or not-load their 
antennas in order to create data.  Tags do not have access to the 
complicated modulation schemes that make gigabit Ethernet and other high 
speed communication channels work.  Finally, most tag reads are repeats, 
which would only be reported as unique EPC numbers in the proverbial 
"poor design".

These are physical limitations beyond the scope of the standards bodies, 
whose job is to establish a framework in which our implementations can 
move forward.

> Using 6 cubic meter volume of RF: suppose this reader is monitoring an 
> area full of DVDs. [There are retailers that are tagging DVDs today.]
> Each DVD case is roughly 19cm x 13cm x 1.5cm = 370 cubic cm. We can fill 
> about 16000 DVDs in 6 cubic meter space. Q.E.D.
>  
Think about it - are you proposing to flood your network with the 
contents of the DVD storage room, over and over, 24x7?  No, you are 
going to have a local node that tracks current IDs and notifies upstream 
nodes of changes.  The only time that lots of data are generated is when 
you periodically re-inventory the room, maybe for audit purposes, maybe 
after a power loss.

> /Krishna

This is a fun topic.  We are bringing up a number of points about RFID 
technology that are important to consider in the definition of an RFID 
protocol.  But as other members have pointed out, we can't afford to tie 
up the group with an extended discussion of this one point.  I'm a bit 
sorry to have jumped in, and am now jumping out.

Regards,
Larry.
www.GlueLogix.com

---

From: "P. Krishna" <[email-masked]>
Date: Thu, 24 Mar 2005 09:45:05 -0500

> sorry to have jumped in, and am now jumping out.

Hi Larry,
I thought it was a very healthy discussion. Discussions like this have
resulted in good network protocol designs in the past, and we should
continue to do so. 

We are at the nascent stages of this work group effort - this is where
we collectively brainstorm through the requirements, goals of this
effort. And obviously, there are going to be different perspectives to
the scope of the problem - hopefully, we can combine them into something
that is useful to the industry.

/Krishna

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 24 Mar 2005 09:51:40 -0500

At 12:50 AM -0500 3/24/05, P. Krishna wrote:
>  that it has attached (1 meter high, 2 meters wide, 2-3 meters long),

Using 6 cubic meter volume of RF: suppose this reader is monitoring 
an area full of DVDs. [There are retailers that are tagging DVDs 
today.]
Each DVD case is roughly 19cm x 13cm x 1.5cm = 370 cubic cm. We can 
fill about 16000 DVDs in 6 cubic meter space. Q.E.D.

DVDs are reflective and contain metal.  So, you could not read even a 
single case of DVDs using a single antenna.  That's where the 
"geometry" that I discussed in my previous message comes in, but even 
that won't allow you to read tags packed so densely between 
reflective/metal objects.

Instead, you will have a case tag on each side of a case of CDs, and 
the readers in the warehouse or distribution center will be set-up to 
filter for and return the case tags.  The item-level tagging only 
becomes useful at the POS terminal (i.e. cash register) and or theft 
prevention system, where you will generally be reading one (or a 
small number) of tags at a time.

Margaret

---

From: "P. Krishna" <[email-masked]>
Date: Thu, 24 Mar 2005 10:54:02 -0500

Hi Margaret,
In my past emails, I have not presented any aggregate network bandwidth
requirements, because I dont think neither I or you can sit and predict
what that is going to be for all applications and deployments. 

The only numbers I presented was the air-protocol rates (as can be
derived from the standards). 

You are driving at 2 basic points:

1) Data rate from the reader is low today, and will continue to remain
so.

I agree with you that in most applications today we will not see
sustained 'new' activity in the reader's field of view at the maximum
air-protocol rate. Moreover, some readers may even filter out redundant
reads, and hence keeping the 'average' traffic down. But, the difficulty
I have is in projecting the number of readers with concurrent peak
activities. We can come up with some maximum number of concurrent
activity for a set of readers that share the same RF space based on
limited channel capacity, interference issues; but, now are we saying
that the entire facility is only 1 RF space - are we going to disallow
facility configurations, that have RF isolation between regions with
multiple readers.

2) There are only 2 ways to control and manage the readers: time-based
with listen-before-talk and physical separation. So why bother having a
protocol to control them actively?  For time-based, just send some
schedules down to the reader, and then off they go. As you said it in
your presentation, "Set and forget". 

That is indeed a valid mode of operation, and, we clearly state in our
objectives that we will have support for autonomous readers. However,
that is not the only one possible solution.

If you look at US deployments, FCC disallows manipulating channel usage
to avoid interference. So, the controls that we have are 'time-domain'
multiplexing, and knobs in the air-protocol, and may be others.
Specifically, talking about Gen 2, it has features like flexible
backscatter capability, session control, and others that can be
exploited to extract efficiencies in the RF usage.

If you look at ETSI, they have fixed frequencies, not freq hopping. So,
in addition to time domain, and air protocol knobs, we also have the
freq domain to manipulate. Then there is the listen-before-talk issue -
if not properly done, its more destructive than constructive.

As stated clearly in the Bof, and the charter, our goal is provide a
control protocol that supports existing and new air protocols. In that
respect, we cannot pigeon hole ourselves to a narrow set of applications
and deployments. We can start at that point, but, our design should
allow for extending the protocol to support new features/protocols.

One other point I would like to make is that a reader is a gateway node
between applications and the tags. At the end of the day, what needs to
ultimately transported/conveyed are the tag data information back to the
applications. The applications in turn have to convey to the readers the
data that it is interested in. One thing we highlight using our draft is
that in a fully operational facility, you are not going to have readers
communicate tag ID (or EPC ID) back to the application, and then the
application turn around and take subsequent actions on the tag (e.g.,
kill, lock, read some portion of the memory). Rather, you will have some
cognizance in the readers to turn around and perform all access
operations that need to be performed on the tag as and when it gets
singulated. There may be some readers that do not have any specific
access rules programmed, and there may be some other readers that do
have access rules programmed. In order to facilitate that, the
applications require the capability of managing access rules at the
readers.

Thank you,
/Krishna

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 24 Mar 2005 15:05:59 -0500

Hi Krishna,

The discussions about bandwidth were only my attempt to provide some 
basis for my belief that we do not have to worry that network 
bandwidth will prohibit the use of XML vs. a more "efficient" (in 
terms of payload size) binary encoding.  They were not meant to imply 
that readers won't need to be centrally configured and managed.

Even if there are only 50 per store and a few hundred per 
distribution center, that adds up to tens of thousands of readers for 
a large retailer, and those readers will need to have features that 
make them extremely easy to install/provision (like cable modems, for 
example) and allow centralized control over both networking and RF 
configuration details.

At 10:54 AM -0500 3/24/05, P. Krishna wrote:
>One thing we highlight using our draft is

I completely agree with this.  RFID readers will need to have 
multi-layer filtering (at least what goes into the local tag database 
and what comes out of it) and complex policies about what to do when 
specific events occur (based on read thresholds, reading specific tag 
ids, etc.).  And, yes, we do need a mechanism to manage those filters 
and policies.

IMO, we should look at how the filters and policies are configured 
for routers and switches.  I think that this is largely done using 
SNMP today, although some routing/switching companies are moving to 
NETCONF.

Margaret