Subject: [Rfid] draft-krishna-slrrp-02: Data "smoothing"

From: [email-masked]
Date: Fri, 24 Jun 2005 15:28:54 -0500

Does SLRRP provide a mechanism for "smoothing" RFID data - i.e., eliminating
duplicate reads?  If not, is there no concern about unnecessary network
traffic transmitting a significant amount of redundant data?
 
Rob
 
"This message is intended only for the named recipient. If you are not the
intended recipient you are notified that disclosing, copying, distributing
or taking any action in reliance on the contents of this information is
strictly prohibited."  
_______________________________________________
Rfid mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rfid

---

From: "P. Krishna" <[email-masked]>
Date: Sun, 26 Jun 2005 08:58:46 -0400

Rob,
We stayed away from defining an elaborate smoothing engine in SLRRP. Basically, there are 2 knobs we provide to control the traffic rate from the reader:
(i) the frequency (rate) of the inventory and access reports generated and transmitted by the reader to the RNC - this is controlled by defining 'triggers' in Section 3.5.6.1. The trigger is a byte wide - different types of triggers can be defined. We have currently defined only 2 types - one of them says send the report every inventory round, the other says send the report every T time units. We are open to defining more types of triggers. 
 
(ii) the frequency of the tag data itself inside the report: this seems to be the major concern of a RFID reader network.  Just so everybody is on the same page, I'll just illustrate with a simple example. A reader can see a tag many times (say 10 times) during an inventory round - a simple implementation is to have the report the tag 10 times in the report - i.e., if the tag data is 100B, then we are consuming 10 * 100B = 1 KB on the wire. If this happens to each and every tag seen by the reader, then we are consuming 10x of the bandwidth and there is "no" perceived extra information conveyed in the duplicate data.
 
There is a class of applications or hosts that is just interested in knowing a binary information per tag by the reader (i.e., has the reader seen it or not) - for them, sending 10 instances of each tag is a waste and redundant. Instead they would like a clean list of N tags 'observed' by the reader.
As you are aware that there is already a application-layer protocol (ALE) in EPCglobal that provides that interface - unfortunately I cannot go into those details in this mailing list. ALE provides the right reader interface to those applications.
 
We dont believe in wasting bandwidth on the network (its obvious from one of our design points - binary encoding). But, we also believe that there is 'rich' information in knowing how many times a tag was observed by the reader - this provides information of the quality of the read. An infrastructure device can do some richer inference from such information from multiplicity of readers. 
 
We have a 'RFU' (reserved for future use) field in the "Tag Data Parameter" (section 3.5.6.3) - we intend to use that field to send information like the "number of times the tag was seen", "the RF frequency at which it was captured" etc. So, if a tag is seen 10 times, we set the "number of times the tag was seen" for that tag to 10. This way, we are not sending 10x traffic, but still are able to convey the rich information up to the infrastructure device.
 
I hope that helps.
 
/Krishna

________________________________

From: [email-masked] on behalf of [email-masked]
Sent: Fri 6/24/2005 4:28 PM
To: [email-masked]
Subject: [Rfid] draft-krishna-slrrp-02: Data "smoothing"

Does SLRRP provide a mechanism for "smoothing" RFID data - i.e., eliminating duplicate reads?  If not, is there no concern about unnecessary network traffic transmitting a significant amount of redundant data?

Rob

"This message is intended only for the named recipient. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited."

---

From: [email-masked]
Date: Mon, 27 Jun 2005 19:07:57 -0500

Krishna,

I agree with your comments regarding the need to report tag read counts.  We
provide this capability today and our solutions providers find it useful.

3.5.4.5 describes Inventory timing parameters.  I suggest defining a value
(0 or -1, either number of rounds or round size) to indicate continuous,
non-stop reading (until inventory stop command).

Our experience is that there's a common use-case for continuous reading,
coupled with periodic reports and "tag seen" counts.

I think you need two more features:

-          An option to report "tag seen" immediately when seen for the
first time.

-          External triggered reads - i.e., don't read continuously but only
when triggered by a sensor.  This is necessary for European duty-cycle
regulatory requirements.  Otherwise, the interface can be the same: report
tags and counts periodically and optionally report tags immediately when
first seen.

Rob

   _____  

From: P. Krishna [mailto:[email-masked]] 
Sent: Sunday, June 26, 2005 7:59 AM
To: [email-masked]; [email-masked]
Subject: RE: [Rfid] draft-krishna-slrrp-02: Data "smoothing"

Rob,

We stayed away from defining an elaborate smoothing engine in SLRRP.
Basically, there are 2 knobs we provide to control the traffic rate from the
reader:

(i) the frequency (rate) of the inventory and access reports generated and
transmitted by the reader to the RNC - this is controlled by defining
'triggers' in Section 3.5.6.1. The trigger is a byte wide - different types
of triggers can be defined. We have currently defined only 2 types - one of
them says send the report every inventory round, the other says send the
report every T time units. We are open to defining more types of triggers. 

(ii) the frequency of the tag data itself inside the report: this seems to
be the major concern of a RFID reader network.  Just so everybody is on the
same page, I'll just illustrate with a simple example. A reader can see a
tag many times (say 10 times) during an inventory round - a simple
implementation is to have the report the tag 10 times in the report - i.e.,
if the tag data is 100B, then we are consuming 10 * 100B = 1 KB on the wire.
If this happens to each and every tag seen by the reader, then we are
consuming 10x of the bandwidth and there is "no" perceived extra information
conveyed in the duplicate data.

There is a class of applications or hosts that is just interested in knowing
a binary information per tag by the reader (i.e., has the reader seen it or
not) - for them, sending 10 instances of each tag is a waste and redundant.
Instead they would like a clean list of N tags 'observed' by the reader.

As you are aware that there is already a application-layer protocol (ALE) in
EPCglobal that provides that interface - unfortunately I cannot go into
those details in this mailing list. ALE provides the right reader interface
to those applications.

We dont believe in wasting bandwidth on the network (its obvious from one of
our design points - binary encoding). But, we also believe that there is
'rich' information in knowing how many times a tag was observed by the
reader - this provides information of the quality of the read. An
infrastructure device can do some richer inference from such information
from multiplicity of readers. 

We have a 'RFU' (reserved for future use) field in the "Tag Data Parameter"
(section 3.5.6.3) - we intend to use that field to send information like the
"number of times the tag was seen", "the RF frequency at which it was
captured" etc. So, if a tag is seen 10 times, we set the "number of times
the tag was seen" for that tag to 10. This way, we are not sending 10x
traffic, but still are able to convey the rich information up to the
infrastructure device.

I hope that helps.

/Krishna

 

   _____  

Rob

---

From: "P. Krishna" <[email-masked]>
Date: Mon, 27 Jun 2005 23:34:21 -0400

Hi Rob,
 
> I agree with your comments regarding the need to report tag read counts.  We provide this capability today and our solutions providers 

> find it useful.

Thats great.

> 3.5.4.5 describes Inventory timing parameters.  I suggest defining a value (0 or -1, either number of rounds or round size) to indicate 

> continuous, non-stop reading (until inventory stop command).

Looks like you figured it out in your next email !!

> Our experience is that there's a common use-case for continuous reading, coupled with periodic reports and "tag seen" counts.

Its good to know that we've covered the common use-case using slrrp while still being able to provide deeper controls when necessary.

> I think you need two more features:

Excellent suggestions. 

> -          An option to report "tag seen" immediately when seen for the first time.

Regarding "tag seen", do you see value in reporting as soon any tag is seen for the first  time? Or do you want to go to the extent of specifying a particular filter-pattern and only tags matching the pattern triggers a report? As I mentioned in an earlier email yesterday, we've just defined couple of triggers for reports and both are time-based.  The trigger field is a byte wide - we can define a lot more triggers. Its great you point this particular requirement out. What other triggers do you think we should support ? Just to be in sync, we are just talking about reporting triggers - i.e., when to send an inventory/access report back.

Following are the triggers:

- every inventory round

- every T time units

- as per your suggestion, upon seeing a tag for the first time
--> anything else?

Your second suggestion is external triggered reads ... 

> -          External triggered reads - i.e., don't read continuously but only when triggered by a sensor.  This is necessary for European 

> duty-cycle regulatory requirements.  Otherwise, the interface can be the same: report tags and counts periodically and optionally 

> report tags immediately when first seen.

Currently what we have defined is for the triggers to go back to the RNC via the Reader Status Report. This way if the RNC has to turn around and generate the inventory commands, it can do that - and the RNC remains cognizant of the RF usage in the network.

The other option is to extend the Inventory Timing operation parameter - in terms of start time, we have 2 options, a) to start now, or b) to start @ a specific time. We may want to extend this to "start upon a defined external trigger". The duration of the round & # of rounds are already defined in the timing operation parameter.

Let me know if this works for you.

Thank you for the input - looking forward to more suggestions from you.

Regards,

Krishna

---

From: [email-masked]
Date: Tue, 28 Jun 2005 19:35:42 -0500

Hi Rob,

> I agree with your comments regarding the need to report tag read counts.
We provide this capability today and our solutions providers 

Thats great.

> 3.5.4.5 describes Inventory timing parameters.  I suggest defining a value
(0 or -1, either number of rounds or round size) to indicate 

Its good to know that we've covered the common use-case using slrrp while
still being able to provide deeper controls when necessary.

Excellent suggestions. 

first time.

Regarding "tag seen", do you see value in reporting as soon any tag is seen
for the first  time? Or do you want to go to the extent of specifying a
particular filter-pattern and only tags matching the pattern triggers a
report? As I mentioned in an earlier email yesterday, we've just defined
couple of triggers for reports and both are time-based.  The trigger field
is a byte wide - we can define a lot more triggers. Its great you point this
particular requirement out. What other triggers do you think we should
support ? Just to be in sync, we are just talking about reporting triggers -
i.e., when to send an inventory/access report back.

[Rob] The Inventory command can filter tags with the air-protocol.  I think
that's enough.  I don't see the need for a reporting filter-pattern beyond
the air-protocol filter.  A higher-level filtering pattern can be left up to
ALE.  

- every inventory round

- every T time units

[Rob] I suppose you could trigger the report on an external I/O port.  I
can't say that I've seen a use case for it.

> -          External triggered reads - i.e., don't read continuously but
only when triggered by a sensor.  This is necessary for European 

> duty-cycle regulatory requirements.  Otherwise, the interface can be the
same: report tags and counts periodically and optionally 

> report tags immediately when first seen.

Currently what we have defined is for the triggers to go back to the RNC via
the Reader Status Report. This way if the RNC has to turn around and
generate the inventory commands, it can do that - and the RNC remains
cognizant of the RF usage in the network.

The other option is to extend the Inventory Timing operation parameter - in
terms of start time, we have 2 options, a) to start now, or b) to start @ a
specific time. We may want to extend this to "start upon a defined external
trigger". The duration of the round & # of rounds are already defined in the
timing operation parameter.

[Rob] "Start upon a defined external trigger" is what we need for the
European duty-cycle use case.  You need to be able to "debounce" the trigger
signal - a delay works well for this (i.e., trigger on I/O and then ignore
the I/O for some period of time). 

Regards,

Krishna