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

From: "P. Krishna" <[email-masked]>
Date: Fri, 25 Mar 2005 08:27:20 -0500

Hi Margaret,
 
> 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.

Let me first synch up with you regarding what I mean by access-specs. You were pretty close with your examples, but just to be clear, here it is. Access-spec is basically a set of actions to be taken by the reader upon seeing the tag that matches the tag-spec specified in the access-spec.There will be a multitude of applications requiring (or setting) a wide variety of information from (to) tags, and also with a diverse set of requirements ranging from one-time actions on a specific tag to a set of persistent rules/actions that need to happen day-in day-out on a family of tags.The access-spec comprises of 2 blocks: target tag-spec (which is like a filter-spec), and the tag operations spec (op-spec). 

Having said that, I beg to differ with you. I think we are jumping to a solution without fully appreciating the subtleties of a large RFID infrastructure. 
 
First off, in a large network of readers, its asking too much for an application to target access-specs to a specific reader - instead, the applications would target access-specs to a specific region associated with the business rules embedded in the access-specs. The parallel being, just like when you want to go to cnn.com, you dont type the IP address of a specific server, instead, there is a functional entity in the network that maps that cnn.com name to a specific server depending on 'network conditions', which results in successive accesses to cnn.com leading you to different IP addresses.
 
[I am going to use the term antennas instead of readers in my example. As you know there is a 1->M mapping between readers to antennas, where M >= 1.]
 
Let me further illustrate with a RFID example. Lets take a simple dock door example, which is covered by N antennas, N/2 on each side of the dock-door. Lets say, there is an application X that wants to write some state information in the user memory of all pallet tags entering that dock door. The network infrastructure translates that to an access-spec to be programmed at a specific antenna (s). The choice of which reader/antenna(s) may be based on load-balancing, taking current RF issues into account; however, you would like the flexibility to move the access-spec to another antenna dynamically, if the previous antenna's behavior changes (for example, somebody parked a forklift in front of the antenna), or that antenna was in boresight of a roguely behaving antenna, reader/antenna failure.
 
If events like reader/antenna failures were the only ones that cause access-specs to be moved, then you are right in treating access-rules as a configuration, and hence by definition doesn't change often - thus, can be managed by the logical entity that performs management, configuration functions. However, I think (and you would agree) that the entropy of a RFID network is quite high - and the only way to monitor any of changes in behavior (other than failures) is by tracking the observations (or lack of it) made by the antenna/reader. Interestingly, observations made by the antenna/reader are the results of inventory and access operations (in the form of tag lists, results of access operations), and also includes any RF monitoring results (narrowband, wideband, etc). This implies that the access-spec monitoring/managing has to happen on the data-path. 
 
Based on that, my inclination/recommendation would be to perform access-spec management on the same logical-channel as the control commands, and data. 
 
I understand you are close to the action with regards to whats happening today in terms of deployments - and thats an important input to consider in our designs. However, we cannot afford to focus our solutions to solely solve the current problems - if we are to believe that RFID is going to be deployed in large-scale, good network engineering has to be an important consideration.
 
BTW, I totally agree with you that we dont want to invent solutions for configuration/mgmt functions - we can look @ SNMP, DHCP, Netconf etc.
 
/Krishna

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

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 25 Mar 2005 09:48:07 -0500

At 8:27 AM -0500 3/25/05, P. Krishna wrote:
Based on that, my inclination/recommendation would be to perform 
access-spec management on the same logical-channel as the control 
commands, and data.

I don't understand the term "access-spec".  What does this mean to you?

I assume that "tag-spec" means a set of information (protocol, ID 
mask, time stamp, perhaps data mask) to which a particular tag can be 
compared?  Would it also include metadata (see below)?

I prefer to think of reader "intelligence" as falling into two major 
categories:

     - filtering (for which you set "filters")
     - event-based actions (for which you set "policies" or "rules" -- 
in event/action pairs, perhaps)

Filtering can be done at more than one level (what gets stored in the 
reader's database and what the reader reports upstream, for example). 
It needs to be possible to filter both on the tag contents (ID and 
data) and on other metadata about the tag (which antenna it was read 
on, how many times it was read, when it was read, which protocol the 
tag supports, etc.).  So, a user should be able to set up a filter 
(if desired) that will result in only seeing EPC1 tags that were read 
on antenna 1 since 2pm that have tag ID's that start with 0x1234.

Event-based actions can take many forms and can be triggered by many 
actions.  Which events and actions apply to a given reader may be a 
function of the reader's hardware capabilities, location or attached 
peripheral devices.

Most RFID readers (even embedded ones) have GPIO (General Purpose 
I/O) lines that are capable of send or receiving signals in response 
to particular events.  A reader can know when it's dock door is open 
and/or can notice when a box passes an electric eye.  A reader can 
also activate a diverter, open a locked door or trigger an alarm 
based on tag reads or other inputs.

Events could include:  particular tag reads (including tag contents 
and metadata as indicated above), a GPIO line transition (from 
high-to-low or low-to-high), a threshold event (number of tag reads 
per second, number not yet transmitted upstream, length of time with 
no tag read, length of time with no upstream content, tag database 
more than 1/2 full, etc.), a network event (like the link going up or 
down), etc.

I am not sure how the idea that filters and/or policies should be set 
via the control channel stems from your example.  If you set the 
"access-spec" on a reader, you do want that rule to remain active 
until it is changed, not just to persist across the lifetime of a 
particular command, a particular TCP connection, and you wouldn't 
want it to be lost of the reader was rebooted.  So, it needs to be 
stored in the reader's persistent configuration, even if it may be 
changed later.  IMO, as little as possible about the operation of the 
reader should be tied to its ability to maintain an active TCP 
connection to a controller.

I agree that these applications and the rules controlling them will 
get more complex over time, but I do not see a reason to believe that 
they will get more complex than the routing policy in a high-end 
enterprise router.  I also don't see that the RFID system is likely 
to be more dynamic than an campus-wide 802.11 wireless network.  The 
world has quite a bit of experience managing those things, and I 
think we can learn a great deal from how it has been done.  Routers 
run continuously without the need for an ongoing connection with a 
controller, and I don't understand why RFID readers would be any 
different.

The IETF has done a lot of work in this area related to managing 
filters, events and policy on networking equipment, and I think that 
some of that work might be applied (directly or indirectly) to RFID 
readers.  Examples include:

SNMPCONF (see: http://www.ietf.org/html.charters/snmpconf-charter.html)
RMON MIB (see: http://www.ietf.org/html.charters/rmonmib-charter.html)
Entity MIB and the Entity State MIB (see: 
http://www.ietf.org/html.charters/entmib-charter.html)
CAPWAP (see: http://www.ietf.org/html.charters/capwap-charter.html)
COPS-PR (see: http://www.ietf.org/html.charters/rap-charter.html)
NETCONF (see: http://www.ietf.org/html.charters/netconf-charter.html)

The cable labs folks have pretty much written the book on 
standards-based, large-scale provisioning. So for configuration, I 
think we should consider the mechanisms defined in the DOCSIS 1.1's 
provisioning system.

Unless we carefully consider this existing work, I think we run two 
risks:  (1) reinventing a lot of things that already exist, (2) 
defining an RFID reader configuration/management/control system that 
is considerably behind the state-of-the-art.

I am still somewhat uncertain regarding the need for a control 
protocol at the per-read-iteration level (as opposed to periodic 
changes in configuration that will allow for tuning ongoing 
autonomous operation of the reader), but if we think that a control 
protocol is needed, I think that we have to answer several questions 
before we can make intelligent decisions about its properties:

(1) How many readers will need to be controlled by a single 
controller (this doesn't necessarily relate to how many will be in a 
particular building).  This might allow us to set some goals for the 
scalability of the protocol.

(2) How far away (in the network topology) will controllers be from 
the RFID readers?  Is network bandwidth through switches/routers the 
only concern, or may the controllers be across a WAN?

(3) How reliable does the system need to be?  Is it acceptable if the 
RFID system (or parts of it) does not operate if the network (or 
parts of it) are down?

(4) What level of real-time control is actually needed?  Do 
controller need to control readers at the per-read-cycle level?  Or 
do they only need periodic access ot the readers to set filters and 
policies and/or retrieve tag data?

BTW, rather than using the term "antennas", perhaps we could agree to 
use the term "read points", which I think better captures the concept 
-- a dock door may have 4 or 6 read-points (antennas attached to 1-6 
different readers).

Margaret

---

From: Scott Barvick <[email-masked]>
Date: Mon, 28 Mar 2005 13:30:37 -0500

Margaret,

Perhaps we are converging here.   The originally proposal was for a
split between what I loosely called 'configuration' and 'control'.  I
consider the first set of concepts you discuss to be in the
'configuration' category.  These are things that you would set a reader
to do essentially autonomously and these things would not change
frequently.   The filters, policies, certain GPIO actions, etc to me
fall into these categories.   I also completely agree that we would not
attempt to invent anything here if the existing efforts you reference
cover them.  Perhaps as a working group we would need to choose one and
define the profiles, MIB(s), service definition, etc for the use of that
existing infrastructure.

The second category of effort that you offer tentative support for (did
I overinterpret your words in my attempt to get to convergence?) is the
control protocol that operates at a time scale that is much closer to
the per-read-iteration level as you put it.  This is what we attempt to
define as the proposed scope for the WG in the BoF and subsequent mails.
http://www1.ietf.org/mail-archive/web/rfid/current/msg00067.html

At the BoF, we had folks from the reader and tag communities that
indicated that this was necessary to achieve proper operation in
emerging styles of reader deployment.  You also described in your
presentation a wide variety of reader architectures.  Do you think that
you could agree that there is a need for this type of control in certain
deployments and/or reader architectures given what we heard from a the
community?  I am not saying that every reader will need this type of
control, but I interpret the statements in the BoF and subsequently on
the list to show that there is a need for this type of control protocol
to exist.

If we can get to consensus on the need for this protocol, the technical
points/TBDs that you bring up are good ones:
1) scale
2) topology
3) reliability
4) real-timeliness

Thanks,
Scott