Subject: [Rfid] SLRRP-related questions

From: "Suresh Bhaskaran" <[email-masked]>
Date: Tue, 24 May 2005 16:45:05 -0700

Krishna, et. al:

Here are some questions I collected up relating to SLRRP:

1.	How do you set server IP address and port (into reader) if reader
initiates connection?! 

a.	(telnet is one way; web server is another?!) 

2.	What comes back as message sequence number if you have multiple
packet responses per command? 

a.	E.g. Inventory Access Report 

3.	Reader Status report comes asynchronously.  What is it's sequence
number? 

a.	(could set to 0) 

4.	What if Reader Status report comes asynchronously?  What happens? 
5.	What happens if Stop Inventory, and there is partial data to be
returned?! 
6.	Why does Access cmd and Inventory Cmd have both Antenna ID's?  Does
the Inventory Antenna override the Access Antenna?! 
7.	What if a stop Access is given in the middle of an Inventory cmd?
What happens?  Do the Access parameters "go away" in the middle of an
inventory? 
8.	How do you know how many Inventory Access reports are coming
(suppose a large report is fragmented into smaller pieces)? 

Thanks in advance.

Suresh

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

---

From: "P. Krishna" <[email-masked]>
Date: Wed, 25 May 2005 11:42:55 -0400

On Tue, 2005-05-24 at 19:45, Suresh Bhaskaran wrote:
>      1. How do you set server IP address and port (into reader) if
>         reader initiates connection?! 

This falls into the 'discovery and configuration' bucket and is not a
SLRRP protocol issue. In anycase, I can give you a brief overview of how
it can be addressed using DHCP. This is one of many ways to do it. 

A reader upon bootup DHCPs for an IP address. In the DHCP message the
reader also requests for a configuration file and maybe a tftp server IP
address from where to fetch the config file. 

The reader configuration file can contain 
- IP addresses of the upstream RNC(s) 
- NTP server
- operating profile, etc

The reader then initiates the connection to the RNC.

>      1. What comes back as message sequence number if you have
>         multiple packet responses per command? 

Its the message sequence number and not packet sequence number - its not
used for re-sequencing. Since we allow multiple outstanding commands in
the SLRRP channel, it is useful to correspond the response to the
command. An implementation in SLRRP layer may choose to make use of it
or not. Especially, for asynchronous responses, the message sequence
number has no relevance.

If there are multiple packet responses per command, they will contain
the same message sequence number. The underlying transport layer (TCP)
does the packet sequencing and presents the packets in 'transmitted'
order to the SLRRP layer at the receiving end. 

In the case of inventory-access-report, the message sequence number
corresponds only to the inventory command and not to the access
command(s). As you might be aware that each access command creates an
access-spec at the reader. We can multiple access-specs created at the
reader at any time. 

An inventory command on the other hand, causes the reader to send
over-the-air protocol commands to singulate/inventory the population of
tags. For any tags matching one or more of the the access-spec(s) stored
in the reader, a corresponding access operation (read user memory, lock,
etc) on the tag.

>      1. Reader Status report comes asynchronously.  What is it’s
>         sequence number? 
>              a. (could set to 0) 

Yes - it is set to 0 and ignored at the receiving end.

>      1. What if Reader Status report comes asynchronously?  What
>         happens? 

The role of SLRRP ends after it has conveyed the reader status report to
the RNC. What happens upon receipt of the reader status report, depends
on the implementation/logic residing in the RNC.

>      1. What happens if Stop Inventory, and there is partial data to
>         be returned?! 
A reader upon receiving a "Stop Inventory" command stops sending the
over-the-air commands - i.e., stops the singulation/inventory.

Its kind of decoupled from when data is sent back to the RNC.

The logic in the reader that drives when to send the data back to RNC is
determined by the configuration setting conveyed by the "Inventory and
Access Reporting Parameter" in "Set Reader Config" command. Let us
suppose that the RNC has conveyed to the reader to send the report every
inventory round. In the case of a premature termination of an inventory
round due to "stop inventory", the reader would declare the round is
over, and send the report back.

>      1. Why does Access cmd and Inventory Cmd have both Antenna ID’s? 
>         Does the Inventory Antenna override the Access Antenna?! 
A reader can have multiple antennas. Each antenna may be monitoring a
different physical region of a facility, each requiring a different
setting for inventory parameters (depending on the RF characteristics of
the physical coverage area, tag population/mobility, tag protocols to
inventory). 

Likewise, there may be different access operations to be performed by
each of these antennas. For example, antenna 1 monitors Dock Door 1
(DD1), antenna 2 monitors Dock Door 2 (DD2). For goods received at DD1,
the business logic would like to read the user memory in tags that match
pattern 123.*, and for goods shipped from DD2, the business logic would
like to read user memory in tags that match pattern 456.*.

SLRRP provides a flexibility to set up inventory parameters and
access-specs differently and separately for each antenna. 

No, inventory antenna does not override the access antenna.
Inventory and access are decoupled from each other. 

Inventory is the method to read the tags in the field of view. SLRRP
provides the interface to control how that inventory operation is
performed by each antenna of the reader. 
Access commands creates access-specs at the reader which is looked up
during inventory rounds to determine if there is any additional
tag-memory access operations to be performed.

There may be instances where there are access-specs created at the
reader. The RNC may have sent an inventory command which sets up the
reader to run 'forever' using the inventory-parameters; the reader in
turn performs the singulation using the parameters without any
subsequent tag-access operations and sends back the inventory report to
the RNC.

>      1. What if a stop Access is given in the middle of an Inventory
>         cmd?  What happens?  Do the Access parameters “go away” in the
>         middle of an inventory? 

Good question.

The deleted access-spec will stop taking effect from the next inventory
round. 

Similarly, for a new access-spec, we have text in Section 3.4.9 that
states that the new access-spec takes effect starting with the next
inventory round.

>      1. How do you know how many Inventory Access reports are coming
We have not specified the format of the inventory access report in V01
of the spec. It'll be addressed in the 02 version of the spec. There
will be a bit in the message that indicates if its the last 'piece' of
the report.

Thanks,
/Krishna

---

From: "Suresh Bhaskaran" <[email-masked]>
Date: Wed, 25 May 2005 14:49:08 -0700

Thanks Krishna (especially), and Ricardo, Howard, Scott, et. al.

The responses, and especially the info on the discovery were very useful.

Just to continue the conversation...

You (Krishna) mentioned that SLRRP allows multiple outstanding commands in
the SLRRP channel.  

Are multiple TCP/IP connections/sessions also allowed at the Reader?  Why or
why not?   

Please note:  I'm not trying here to "push" one way or the other.  However,
I am interested in the thinking process and tradeoffs that went into making
these decisions.

Also, if a connection is lost, is state (e.g. previous access specs)
maintained, or lost or reinitialized?

I *really* like the "lightweight" nature of SLRRP, and all the above
introduce another level of complexity, and I was just curious as to the
current thinking on these issues.

Suresh

-----Original Message-----
From: P. Krishna [mailto:[email-masked]] 
Sent: Wednesday, May 25, 2005 8:43 AM
To: Suresh Bhaskaran
Cc: [email-masked]
Subject: Re: [Rfid] SLRRP-related questions

>      1. Reader Status report comes asynchronously.  What is it's
>         sequence number? 
>              a. (could set to 0) 

>      1. Why does Access cmd and Inventory Cmd have both Antenna ID's? 

>         cmd?  What happens?  Do the Access parameters "go away" in the
>         middle of an inventory? 

Good question.

Thanks,
/Krishna

---

From: "P. Krishna" <[email-masked]>
Date: Wed, 25 May 2005 18:14:34 -0400

> Are multiple TCP/IP connections/sessions also allowed at the Reader?  Why or

SLRRP does not have a "session ID". By definition, a SLRRP channel is a
single session. If the Reader allows multiple SLRRP channels to exist,
then it is the responsibility of the Reader's design to handle it and is
outside the scope of SLRRP. 
To be clear, SLRRP does not require multiple sessions to be opened. 

> maintained, or lost or reinitialized?
That is beyond SLRRP too! SLRRP is an interface protocol - its
stateless. Its an end-node issue. The host and the reader are stateful
and should be keeping the state until and unless the node got
reset/rebooted or state-update from the other end-node.

> current thinking on these issues.

I am not inclined to add any complexity. If you think handling multiple
commands in flight is an issue, then lets discuss that. Here are my
thoughts ...

Some Readers internally have a serialized architecture (single
threaded), thereby allowing only a single command to be processed at a
time. This means the commands may need to buffered at the receive
interface of the Reader.

All the commands in SLRRP from the host require an response from the
reader. If the host chose to send multiple commands, then it is the
host's responsibility to keep track of the command fulfillment @ the
reader.

Allowing multiple commands in flight in an network interface protocol
does not (and should not) force multi-threaded design in a reader. On
the same token, a single-threaded reader design should not force the
interface protocol to be serialized (i.e., only one unacked command in
flight).

I hope this helps.

Thanks,
/Krishna