From rfid-bounces@ietf.org Fri Apr 1 10:59:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07949; Fri, 1 Apr 2005 10:59:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHOfc-0007dH-AO; Fri, 01 Apr 2005 11:06:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHOXY-0005Jp-Vt; Fri, 01 Apr 2005 10:58:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHOXY-0005Jk-5W for rfid@megatron.ietf.org; Fri, 01 Apr 2005 10:58:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07866 for ; Fri, 1 Apr 2005 10:58:29 -0500 (EST) Received: from mse3fe1.mse3.exchange.ms ([69.25.50.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHOes-0007Yf-JJ for rfid@ietf.org; Fri, 01 Apr 2005 11:06:07 -0500 Received: from [192.168.1.45] ([157.130.221.86]) by mse3fe1.mse3.exchange.ms with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Apr 2005 10:59:14 -0500 Subject: RE: [Rfid] Config vs. control parameters in SLRRP From: Scott Barvick To: andrew.funk@radfly.com In-Reply-To: <200503301847.NAA27975@ietf.org> References: <200503301847.NAA27975@ietf.org> Content-Type: text/plain Message-Id: <1112371085.11607.156.camel@saco.revasystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Fri, 01 Apr 2005 10:58:05 -0500 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Apr 2005 15:59:14.0796 (UTC) FILETIME=[C0A4EAC0:01C536D3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7bit Great. I think we are in violent agreement here, and it looks like there is no hesitation to keep the group from straying into an artificially limited control protocol or inconsistencies between configuration and control. Andrew starts to bring up another topic I think we should explore. Margaret also listed it as one of the key things to figure out, and it is the time requirements on the control that is provided. I'll throw out there that I believe that we have a requirement to provide the ability to approach control at a read cycle level. This comes from the opportunity and need to control the richness of the parameters in the gen2 (and beyond) tags. This doesn't mean that every installation or application will need control on this level, but thinking about it at the per read cycle level will push us to think about such things as: - network topologies - communications overhead and delays - reader capabilities - air protocol command exposure - local, autonomous control requirements. Scott On Wed, 2005-03-30 at 13:47, Andrew Funk wrote: > I want to agree with Suresh here. I've never wanted to pull what we > are currently calling "configuration" out of the WG, but there has > been a strong desire to focus on one segment of the problem space in > order to make progress. Scott had suggested during the BOF that the > initial focus be on the "control" portion, to be followed up by the > configuration and management activity. > > If SLRRP is a baseline for the control portion, I had implied that we > should work through the proposed functionality and make sure that we > understand what should be embedded in control and what should be held > out for configuration. I'm very interested in making sure the right > protocols and standards are applied to the config side (be it SNMP, > CIM, whatever), so I believe that should be addressed in the WG as well. > > For example, there has already been extensive discussion of "access-specs". > One viewpoint holds those as configuration parameters, set-and-forget. > Another view has that as a parameterization of an inventory command, where > it might need to be changed on a transaction by transaction basis. If > we observe that both cases need to be supported by the work we do, we > will need to embody a set of default access-specs within any management > framework we work on (or endorse, if somebody else is already doing it > appropriately), and the capability, but not the requirement, to over-ride > or reset those within the control protocol. I don't view them as > exclusive capabilities. > > I'm going to finish by agreeing with Suresh again by stating that we need > to preserve the coherence of the functionality, but I do think that this > can be done by aligning the control protocol (SLRRP) with whatever mgmt > and configuration capability (MIBs,net-conf) are provided as well. Once > again, all excellent topics for this WG. > > -Andrew > Radfly > > -----Original Message----- > From: rfid-bounces@lists.ietf.org [mailto:rfid-bounces@lists.ietf.org] On > Behalf Of Scott Barvick > Sent: Wednesday, March 30, 2005 11:19 AM > To: Suresh Bhaskaran > Cc: rfid@ietf.org > Subject: RE: [Rfid] Config vs. control parameters in SLRRP > > We certainly want to make sure that we don't pull out things that are > needed. I just wanted to make sure that we discussed > messages/parameters/functions that might be in question. I wanted to > see if anyone had specifics that they wanted to discuss? > > For instance, I believe that the concept of access-specs belongs in the > protocol, even if there are similar higher level concepts that operate > within the configuration scope (SNMP, net-conf, etc). The working group > would get to the definitions of these operations after specifying the > control protocol. > > Scott > > On Wed, 2005-03-30 at 12:32, Suresh Bhaskaran wrote: > > I agree that configuration also needs to be thought about more. > > > > But artificially splitting (all of) configuration to "outside" the work > > group may destroy the coherence of the functions. I like the current > SLRRP > > spec because it "fits together", and I can "see" how it fits together. > > > > I think that element should be preserved when we "split off" configuration > > and "other functionalities" outside the group. > > > > What I loved about the spec the first time I read it was that I could see > > the big picture "at a glance"! > > > > That element should be preserved, I strongly feel. > > > > Suresh > > > > > > > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@ietf.org Mon Apr 4 13:00:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28273; Mon, 4 Apr 2005 13:00:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIV3u-0007dY-IX; Mon, 04 Apr 2005 13:08:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIUvl-0008W9-3f; Mon, 04 Apr 2005 13:00:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIUvj-0008Vh-Da for rfid@megatron.ietf.org; Mon, 04 Apr 2005 13:00:03 -0400 Received: from expredir5.cites.uiuc.edu (expredir5.cites.uiuc.edu [128.174.5.96]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28208 for ; Mon, 4 Apr 2005 13:00:00 -0400 (EDT) Received: from hamming.crhc.uiuc.edu (hamming.crhc.uiuc.edu [130.126.142.157]) by expredir5.cites.uiuc.edu (8.12.11/8.12.11) with ESMTP id j34H02Pn013221 for ; Mon, 4 Apr 2005 12:00:02 -0500 (CDT) Date: Mon, 4 Apr 2005 12:00:01 -0500 (CDT) From: Vartika Bhandari X-X-Sender: vbhandar@hamming.crhc.uiuc.edu To: rfid@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Rfid] RFID Simulation Models X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Hi, I am interested in RFID protocol simulation. Are there simulation models for RFID available? I would appreciate any information in this regard. Thanks, Vartika _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@ietf.org Mon Apr 4 17:59:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16506; Mon, 4 Apr 2005 17:59:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIZj7-00039l-Ic; Mon, 04 Apr 2005 18:07:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIZYP-0006ig-G7; Mon, 04 Apr 2005 17:56:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIZYP-0006ib-26 for rfid@megatron.ietf.org; Mon, 04 Apr 2005 17:56:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16292 for ; Mon, 4 Apr 2005 17:56:14 -0400 (EDT) Received: from mse3fe1.mse3.exchange.ms ([69.25.50.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIZgN-00033d-Tm for rfid@ietf.org; Mon, 04 Apr 2005 18:04:34 -0400 Received: from [192.168.1.44] ([157.130.221.86]) by mse3fe1.mse3.exchange.ms with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 17:57:09 -0400 Subject: Re: [Rfid] RFID Simulation Models From: "P. Krishna" To: Vartika Bhandari In-Reply-To: References: Content-Type: text/plain Message-Id: <1112651753.2817.827.camel@indus.revasystems.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 04 Apr 2005 17:55:53 -0400 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Apr 2005 21:57:09.0703 (UTC) FILETIME=[3FECED70:01C53961] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: rfid@ietf.org X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@ietf.org Errors-To: rfid-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Hi Vartika, To clarify, I think you are looking for the RF-network simulation. I am not aware of publicly available models. But I dont think it should be difficult to extend existing publicly available tools like NS to support rfid-reader-nodes and tags. If you are interested, here is a quick overview of the problem in hand ... The air-protocol specifies (i) the RF parameters for the forward and reverse link, (ii) the singulation protocol. (i) determines the link bandwidth, and also interference with other readers/tags. (ii) determines the tag-read rate. For example, the new C1G2 protocol uses a slotted-aloha type of protocol. So, a reader-model will entail modelling the 'coverage' and interference reach of the reader as function of the RF parameters; this may also require the tag's perspective by having a random function in the tag-node to determine if the tag gets 'energized' or not. And secondly, the singulation algorithm - which is very well defined in the protocols and is relatively simpler to code-up that state machine in the reader and tags. Feel free to contact me if you are interested in more details. Thanks, /Krishna On Mon, 2005-04-04 at 13:00, Vartika Bhandari wrote: > Hi, > I am interested in RFID protocol simulation. Are there simulation models for RFID available? I > would appreciate any information in this regard. > > Thanks, > Vartika > > > _______________________________________________ > Rfid mailing list > Rfid@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/rfid _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Fri Apr 22 05:04:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOu5W-0003HW-LM; Fri, 22 Apr 2005 05:04:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOu5T-0003HN-Cc for rfid@megatron.ietf.org; Fri, 22 Apr 2005 05:04:35 -0400 Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26655 for ; Fri, 22 Apr 2005 05:04:33 -0400 (EDT) Received: by wproxy.gmail.com with SMTP id 69so638546wri for ; Fri, 22 Apr 2005 02:04:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ZBPbAVs5Nja1QPE0sHpSYeV3+rKx/tFasNfyBdBUtSa4DBs5i7yJVVMyAF7vaF26ZX3+ExR0kYxPZVCusFoTmy/UR209BAW1vppK6nFMxHBEw2LTnwYxWiSWBsw5mrtCyYxoLWQ8SdbD8iF9SGMOIOJLdgnvb0s40mlTFYdnpEA= Received: by 10.54.21.59 with SMTP id 59mr340331wru; Fri, 22 Apr 2005 02:04:04 -0700 (PDT) Received: by 10.54.3.78 with HTTP; Fri, 22 Apr 2005 02:04:04 -0700 (PDT) Message-ID: Date: Fri, 22 Apr 2005 14:34:04 +0530 From: Prashant Agrawal To: rfid@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Cc: Subject: [Rfid] 13.56 MHz Reader to host protocol X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Prashant Agrawal List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org Dear ALL I am new to SLURP mailing lists and need some info. I read the draft version of SLURP and came to know that it is based on ISO 18000-6 and EPC Gen2 UHF frequencies. =20 We are working on 13.56 MHz side and wish to know whether there is a standard for "host to reader protocol" at this frequency. I belive that existing SLURP can be tweaked a bit to accomodate this frequency. In fact the reader to host protocol should be such that it can accomodate any frequency. Kindly let me know your views. --=20 Regards Prashant Agrawal NirmaLabs, NirmaUniversity SG Highway, Ahmedabad 382481 " If you do not aim for perfection, you will not achieve excellence" =20 - JRD Tata _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid From rfid-bounces@lists.ietf.org Fri Apr 22 07:47:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOwcg-00085U-Gt; Fri, 22 Apr 2005 07:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOwcf-00084z-CN for rfid@megatron.ietf.org; Fri, 22 Apr 2005 07:47:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08734 for ; Fri, 22 Apr 2005 07:47:00 -0400 (EDT) Received: from ms08.mse3.exchange.ms ([69.25.50.144]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOwoH-0008U8-Ts for rfid@ietf.org; Fri, 22 Apr 2005 07:59:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Rfid] 13.56 MHz Reader to host protocol Date: Fri, 22 Apr 2005 07:48:37 -0400 Message-ID: <0E03681B885F3B4296B999E34435A16E3DF8DC@ms08.mse3.exchange.ms> Thread-Topic: [Rfid] 13.56 MHz Reader to host protocol Thread-Index: AcVHGwn+ZnpqGh21RoGW53xXDFe6qwAFWALV From: "P. Krishna" To: "Prashant Agrawal" , X-Spam-Score: 0.5 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: X-BeenThere: rfid@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RFID Reader Operations, Management, and Administration Discussion List" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1503095359==" Sender: rfid-bounces@lists.ietf.org Errors-To: rfid-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1503095359== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C54731.38697127" This is a multi-part message in MIME format. ------_=_NextPart_001_01C54731.38697127 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hellp Prashant, Thanks for you interest in SLRRP. As you correctly observed that the = current version of the spec has defined parameters for C1G1 and C1G2 = protocols and they operate in the UHF frequencies. We have specifically = desinged SLRRP such that any new air protocol can be supported by = specifying the air-protocol specific parameter sets.=20 =20 It would be great if you could specify the commands and parameters for = the 13.56Mhz protocols. I can help you out if you have any questions on = slrrp design etc. Can you post to the list a pointer to the protocol = standards site? =20 Thanks, /Krishna ________________________________ From: rfid-bounces@lists.ietf.org on behalf of Prashant Agrawal Sent: Fri 4/22/2005 5:04 AM To: rfid@ietf.org Subject: [Rfid] 13.56 MHz Reader to host protocol Dear ALL I am new to SLURP mailing lists and need some info. I read the draft version of SLURP and came to know that it is based on ISO 18000-6 and EPC Gen2 UHF frequencies. We are working on 13.56 MHz side and wish to know whether there is a standard for "host to reader protocol" at this frequency. I belive that existing SLURP can be tweaked a bit to accomodate this frequency. In fact the reader to host protocol should be such that it can accomodate any frequency. Kindly let me know your views. -- Regards Prashant Agrawal NirmaLabs, NirmaUniversity SG Highway, Ahmedabad 382481 " If you do not aim for perfection, you will not achieve excellence" =20 - JRD Tata _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid ------_=_NextPart_001_01C54731.38697127 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= [Rfid] 13.56 MHz Reader to host protocol=0A= =0A= =0A=
=0A=
Hellp = Prashant,
=0A=
Thanks for you interest in = SLRRP. As you =0A= correctly observed that the current version of the spec has defined = parameters =0A= for C1G1 and C1G2 protocols and they operate in the UHF = frequencies. We =0A= have specifically desinged SLRRP such that any new air protocol can be = supported =0A= by specifying the air-protocol specific parameter sets.
=0A=
 
=0A=
It would be great if you = could =0A= specify the commands and parameters for the 13.56Mhz protocols. I = can help =0A= you out if you have any questions on slrrp design etc. Can you post to = the list =0A= a pointer to the protocol standards site?
=0A=
 
=0A=
Thanks,
=0A=
/Krishna
=0A=

=0A=
=0A= From: rfid-bounces@lists.ietf.org on = behalf of =0A= Prashant Agrawal
Sent: Fri 4/22/2005 5:04 AM
To: =0A= rfid@ietf.org
Subject: [Rfid] 13.56 MHz Reader to host =0A= protocol

=0A=
=0A=

Dear ALL

I am new to SLURP mailing lists and = need some =0A= info. I read the draft
version of SLURP and came to know that it is = based on =0A= ISO 18000-6 and
EPC Gen2 UHF frequencies.

We are working on = 13.56 MHz =0A= side and wish to know whether there is a
standard for "host to reader =0A= protocol" at this frequency. I belive
that existing SLURP can be = tweaked a =0A= bit to accomodate this frequency.
In fact the reader to host protocol = should =0A= be such that it can
accomodate any frequency.

Kindly let me = know your =0A= views.

--
Regards

Prashant =0A= Agrawal
NirmaLabs,
NirmaUniversity
SG Highway,
Ahmedabad =0A= 382481

" If you do not aim for perfection, you will not achieve =0A= excellence"
         &nbs= p;            = ;            =             &= nbsp;           &n= bsp;          
 = ;  =0A= - JRD = Tata

_______________________________________________
Rfid =0A= mailing list
Rfid@lists.ietf.org
https://www1.ietf.or= g/mailman/listinfo/rfid

=0A= =0A= =0A= ------_=_NextPart_001_01C54731.38697127-- --===============1503095359== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rfid mailing list Rfid@lists.ietf.org https://www1.ietf.org/mailman/listinfo/rfid --===============1503095359==--