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
