Scott Good for me. A consequential revision would be consistent in the (old) 4.1.1 on database discovery. At step 3 it says "If at least one response is received, the master device evaluates the response(s) to determine if a trusted database can be identified where the master device is able to register and receive service from the database." I suggest the intent is the same and the application consistent across regulatory domains if "register and receive service" is changed to "receive service".
Regards Andy -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: 21 February 2012 16:46 To: Sago,AJ,Andy,COD R; [email protected] Subject: Re: [paws] UC&R I-D: section 4.1 (TVWS database discovery, device registration with trusted database) Hi Andy, All, Following up on your keen observation about registration as a pre-requisite. It may not be required in all regulatory domains, and also not for all device types. If there are no objections, I will make the following correction: Registration <delete>is</delete><insert>may be</insert> preliminary to creating a radio network using white space; <insert>in some regulatory domains, for some device types,</insert> it is a prerequisite to the use cases below. The radio network is created by a master device. Kind Regards, Scott On 2/2/12 1:02 PM, "ext [email protected]" <[email protected]> wrote: >Scott > >The Device Registration use case at 4.1.2 is shown as a pre-requisite, >but may not be required in all regulatory domains. I take your point >though that at present we only have firm requirements from the FCC. > >I guess that the left most device in the diagram in 4.1.2 should be >labelled slave, not master. > >There is a conflict between the use case (elsewhere) that allows for WS >backhaul, and step 1 of database discovery in 4.1.1. It is possible for >a master to send a service request to the database over the WS, if it >does so as a slave to another master on that master's allowed >frequencies. We could correct step 1 to reflect this as follows: > >1. The master device is connected to the internet by any means other >than using the <Delete>TV</Delete> white space radio. <Insert>An >exception is where the master device also has slave capabilities and is >already connected to the internet as a slave of the white space radio >network of another master.</Insert> > >Regards > >Andy > >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of >[email protected] >Sent: 02 February 2012 16:22 >To: [email protected] >Subject: [paws] UC&R I-D: section 4.1 (TVWS database discovery, device >registration with trusted database) > >Hello All, > >As editors of the problem statement, use cases & requirements draft we >are attempting to prepare a completed draft which could be ready for >working group last call before IETF83. In the coming days we will post >the sections of the draft to the mailing list. Our request is that you >review these sections and reply to the email with any comments. > >Below is the text for sections on protocol services (new section >numbering). This text has been marked up from version-02 as uploaded >January 26, 2012 to include the previous comments on the mail reflector >about use cases vs. protocol services, plus a few suggestions from the >editor (removing 'TV' since PAWS applies to all white space, correcting >for the fact that we only know at this time the FCC's specific >requirements for registration). > >Our goal is that any discussion on this text will conclude by February 9. >To be clear, approval of the document will go through the normal >process of last calls etc.. We are simply asking for your assistance in >preparing a complete & accurate document that could progress the work. >So please review the text and send your comments either directly to the >editor or to the mailing list. > >Kind Regards, >Raj & Scott > > > ><Insert> > >4.1 Protocol Services > >A complete protocol solution must provide all services that are >essential to enable the white space paradigm. Before a white space >device can request service from a white space database, such as a query >for a list of available channels, the white space device must first >locate or "discover" a suitable database. Additionally, some regulatory >authorities require the white space device to register with the >database as a first step. This section describes the services required from >the protocol. ></Insert> > >4.1.1. <Delete>TVWS</Delete><Insert>White space</Insert> database >discovery > ><Delete>This use case</Delete><Insert>White space database >discovery</Insert> is preliminary to creating a radio network using ><Delete>TV</Delete> > white space; it is a prerequisite to ><Delete>other</Delete><Insert>the</Insert> use cases ><Insert>below</Insert>. The radio > network is created by a master device. Before the master device can > transmit in <Delete>TV</Delete> white space spectrum, it must >contact a trusted > database where the device can learn if any channels are available for > it to use. The master device will need to discover a trusted > database in the relvant regulatory domain, using the following steps: > > 1. The master device is connected to the internet by any means other > than using the <Delete>TV</Delete> white space radio. > > 2. The master device constructs and sends a service request over the > Internet to discover availability of trusted databases in the > local <Insert>regulatory</Insert> domain and waits for responses. > > 3. If no acceptable response is received within a pre-configured > time limit, the master device concludes that no trusted database > is available. If at least one response is received, the master > device evaluates the response(s) to determine if a trusted > database can be identified where the master device is able to > register and receive service from the database. > > Optionally the radio device is pre-programmed with the internet > address of at least one trusted database. The device can establish > contact with a trusted database using one of the pre-programmed > internet addresses and establish a <Delete>TV</Delete> white space >network (as > described in one of the following use cases). > > Optionally the initial query will be made to a listing approved by > the national regulator for the domain of operation (e.g. a website > either hosted by or under control of the national regulator) which > maintains a list of <Delete>TV</Delete>WS databases and their >internet addresses. The > query results in the list of databases and their internet addresses > being sent to the master, which then evaluates the repsonse to > determine if a trusted database can be identified where the master > device is able to register and receive service from the database. > > >4.1.2. Device registration with trusted Database > > <Delete>This use case</Delete><Insert>Registration</Insert> is >preliminary to creating a radio network using <Delete>TV</Delete> > white space; it is a prerequisite to ><Delete>other</Delete><Insert>the</Insert> use cases ><Insert>below</Insert>. The radio > network is created by a master device. Before the master device can > transmit in <Delete>TV</Delete> white space spectrum, it must >contact a trusted > database where the device can learn if any channels are available for > it to use. Before the database will provide information on available > <Delete>TV</Delete><Insert>radio</Insert> channels, the master >device must register with the trusted > database. Specific requirements for registration come from > individual regulatory domains and may be different. > > The figure below shows an example deployment of this scenario. > > > > \|/ ---------- > | |Database| > | .---. /--------- > |-|---------| ( ) / > \|/ | Master | / \ > | / | |========( Internet ) > | / |-----------| \ / > +-|----+ (TDD AirIF) ( ) > |Master| / (----) > | | / > +------+ > > Figure 2: Example illustration of registration requirement in ><Delete>TV</Delete> > white space use-case > > A simplified operational scenario showing registration consists of > the following steps: > > 1. The master device must register with ><Delete>the</Delete><Insert>its</Insert> most current and up-to- > date information. Typically the master device will register > prior to operating in <Delete>TV</Delete> white space for the >first time after > power up, after changing location by a predetermined distance, > and after regular time intervals. > > 2. The master device shall provide to the database during > registration <Insert>all information required according to local >regulatory requirements. This information may include, but is not >limited to, </Insert><Delete>a minimum of</Delete> the Device ID, >serial number assigned by the manufacturer <Delete>and</Delete> the >device's location<Insert>, device antenna height above ground, name of >the individual or business that owns the device, name of a contact >person responsible for the device's operation, address for the > contact person, email address for the contact person and phone >number of the contact person.</Insert> > ><Delete> > 3. Depending upon regulatory domain requirements, the device may > also provide device antenna height above ground, name of the > individual or business that owns the device, name of a contact > person responsible for the device's operation, address for the > contact person, email address for the contact person and phone > number of the contact person to the database during registration. ></Delete> > >_______________________________________________ >paws mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
