Hi Andy, I agree with you.
Kind Regards, Scott On 2/21/12 10:53 AM, "ext [email protected]" <[email protected]> wrote: >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
