Scott, I agree with your proposed changes except for items 8 and 11.
In the case of the Wide-area or Rural internet broadband access, the geolocation of each slave device needs to be provided to the base station so that it can query the DB for the channel availability at each slave location. These slave devices could be located as far as 30 km, thus not sharing the same location as the base station as far as querying for the available channels. The network topology here is a point-to-multipoint star model (i.e., a slave, once it knows its available channels, is not supposed to go on its own and operate on any of these channels, it will continue to operate on the same channel as that of the base station since it is part of this star network and needs to be in contact with the base station). If a slave device were to operate on a different channel in a peer-to-peer fashion, it would also have to stay in touch with the master/BS and thus have double modem construction to operate on both channels at the same time. Such peer-to-peer topology is not part of this use case. In this model, the slave device does not need to know the list of available channels, it only needs to know its operating channel which has to be the same as that of the base station and a few backup channels so that, if the current operating channels is to be freed by the base station, upon a trigger from the base station to move out of the channel, the slave device knows where to fall back to continue operating with the base station. This way, the short time to free the channel to avoid interference to the incumbent can be met while the communication with the base station can continue in a transparent way to the terminal user. The base station, however, needs to query the DB for each and every of its slave devices so that it can find the cross-section of all the available channels returned by the DB for all its slave devices which will define the channels that can be used by all the slave devices (i.e., available to the BS and all its slave devices) and this will constitute the list of the operating channel and the backup channels that the BS needs to signal to its slave devices. This is the common list of channels that needs to be sent to the slave devices, not the list of available channels for each device coming from the DB. As a consequence, The text in item 8 should stay as is except for changing "BS" for "Master/BS" if it is needed for consistency. With respect to item 11, here is what I would suggest: 11. The slave or user device must transmit its new geographic location every time it changes so that the repeated process described under item 10 for the master/BS can rely on the most up-to-date geolocation of the slave or user device. One could also argue that this function of updating the geolocation information of the slave at the master/BS is nor related to the protocol to be developed and is therefore beyond the scope of PAWS. Respectfully, Gerald -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Wednesday, 08 February, 2012 12:55 To: [email protected] Subject: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet broadbandaccess) 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 section on the Wide-Area or Rural use case (new section numbering is NOT shown, all use cases will be moved to section 4.2 Use cases in the next version). This text has been marked up from version-02 as uploaded January 26, 2012 as follows: * include applicable comments from Hotspot use case Our goal is that any discussion on this text will conclude by February 15. 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 4.4. Wide-Area or Rural internet broadband access In this use case, internet broadband access is provided as a Wide- Area Network (WAN) or Wireless Regional Area Network (WRAN). A typical deployment scenario is a wide area or rural area, where internet broadband access is provided to local businesses and residents from a master (i.e. BS) connected to the internet. This deployment scenario is typically characterized by one or more Fixed master(s)/BS(s), cells with relatively large radius (tens of kilometers, up to 100 km), and a number of available radio channels. Some of the masters/BSs may be deployed and operated by a single entity, i.e. there can be centralized coordination between these masters/BSs, whereas other masters/BSs may be deployed and operated by operators competing for the radio channels in a license-exempt TVWS environment where decentralized coordination using the air-interface would be required. The BS in this scenario use a TDD radio technology and transmit at or below a transmit power limit established by the local regulator. Each base station has a connection to the internet and <Insert>may</Insert> provide<Delete>s</Delete> internet connectivity to multiple slave/end-user devices. End user terminals or devices may be fixed or portable. The figure below shows an example deployment of this scenario. ------- |Slave|\ \|/ ---------- |Dev 1| (TDD AirIF) | |Database| ------- \ | .---. /---------- o \ |-|---------| ( ) / o | Master | / \ o / | (BS) |========( Internet ) o / |-----------| \ / ------- (TDD AirIF) ( ) |Slave| / (----) |Dev n| ------- Figure 4: Rural internet broadband access using TV white space spectrum Once the master/BS has been professionally installed and configured, a simplified power up and operation scenario utilizing TV White Space to provide rural internet broadband access consists of the following steps: 1. The master/BS powers up; however its WS radio and all other WS capable devices will power up in idle/listen only mode (No active transmissions on the WS frequency band) 2. The master/BS has internet connectivity <Insert>, determines its location (either from location determination capability or from saved value that was set during installation), </Insert> and establishes a connection to a trusted white space database (see <Delete>use case</Delete> "TVWS database discovery" above). 3. The master/BS registers <Delete>its geolocation, address, contact information, etc. associated with the owner/operator of the master/BS</Delete> with the trusted database service (<Delete>if not currently registered, </Delete>see Section 4.2<Ed. Note>reference is to registration, will be updated in next version</Ed. Note>). Meanwhile the DB administrator may be required to store and forward the registration information to the regulatory authority. If a trusted white space database administrator is not discovered, further operation of the WRAN may be allowed according to local regulator policy (in this case operation of the WRAN is outside the scope of the PAWS protocol). 4. Following the <Insert>successful</Insert> registration process, the master/BS will send a query to the trusted database requesting a list of available WS channels based upon its geolocation. <Insert>The complete set of parameters to be provided from the master to the database is specified by the local regulator. Parameters may include WSD location, accuracy of of that location, device antenna height, device identifier of a slave device requesting channel information.</Insert> 5. If the master/BS has been previously authenticated, the database responds with a list of available white space channels that may be used and optionally a maximum transmit power (EIRP) for each channel <Delete>and</Delete> a duration of time the channel may be used <Insert>or a notification of any additional requirement for sensing</Insert>. 6. Once the master/BS authenticates the WS channel list response message from the database, the master/BS selects an available WS channel(s) from the list. The operator may disallow some channels from the list to suit local needs if required. 7. The slave or user device scans the TV bands to locate a WRAN transmission, and associates with the master/BS.<Ed. Note>insert new step</Ed. Note> 8. The slave/user device <Delete>provides its geolocation to the BS which, in turn,</Delete> queries the <Delete>database</Delete><Insert>master</Insert> for a list of channels available at the slaves' Geolocation <Insert>providing to the master the slave's Device ID and optionally its geolocation.</Insert>. 9. Once this list of available channels is received from the database by the master, the latter will decide, based on the list of available channels for all its other associated slaves whether it should continue operation on its current channel or change channel to accommodate the new slave in case this channel is not available at its location. The master will notify all its associated slaves/user devices of the new channel to move to if operation needs to change channel. If the channel that the user terminal is currently using is not included in the list of locally available channels, the master will drop its association with the slave/user device so that it ceases all operation on its current channel and indicate the new operating channel before dropping the link if a change has been decided. The slave/user device may move to the indicated new channel if so indicated or scan for another WRAN transmission on a different channel. <Insert> 10. The master/BS must periodically repeat the process to request a channel list from the database, steps 4 through 6 above. The frequency to repeat the process is determined by the local regulator. If the response from the database indicates a channel being used by the master/BS is not available, the master/BS must stop transmitting on that channel immediately. 11. The slave or user device must periodically repeat the process to request a channel list from the master/BS, steps 8 and 9 above. The frequency to repeat the process is determined by the local regulator. If the response from the master/BS indicates that a channel being used by the slave or user device is not available, the slave or user device must stop transmitting on that channel immediately. </Insert> _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
