Scott, Raj, all I don't see the need for steps 8, 9 and 11, where slaves query the master for frequencies. In this use case, all slaves only talk to masters, not to each other. By definition they must be using a WS channel allocated by the WSDB to the master WSD - they are part of the master network and using its frequencies. The master advertises its presence in some way on the WS (we don't need to know how or at what layer, but could be SSIDs, beacons, required timing information etc). There must be some sort of advertisement otherwise slaves can never connect. If the master drops use of a frequency that a slave was using, then, like in cellular mobile or Wi-Fi, the slave drops off the network shortly after failing to hear the master, and will have to rejoin using another frequency being transmitted by the master, if any. The slave never needs to ask for frequencies.
Have I missed something, or are we making the protocol unnecessarily complicated? Andy -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: 03 February 2012 21:42 To: [email protected] Subject: [paws] UC&R I-D: section 4.3 (Hotspot: urban internet connectivity service) 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 Hotspot 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: * now includes steps to change the availability of spectrum on short notice * clarification that in some cases a master may initialize over a white space channel * clarification that registration includes device location * clarification on the possible parameters in the channel request * clarification on the possible parameters in the channel response Our goal is that any discussion on this text will conclude by February 10. 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.3. Hotspot: urban internet connectivity service In this use case internet connectivity service is provided in a "hotspot" to local users. Typical deployment scenarios include urban areas where internet connectivity is provided to local businesses and residents, and campus environments where internet connectivity is provided to local buildings and relatively small outdoor areas. This deployment scenario is typically characterized by multiple masters (APs or hotspots) in close proximity, with low antenna height, cells with relatively small radius (a few kilometers or less), and limited numbers of available radio channels. Many of the masters/APs are assumed to be individually deployed and operated, i.e. there is no coordination between many of the masters/APs. The masters/APs in this scenario use a TDD radio technology and transmit at or below a relatively low transmit power threshold. Each master/AP has a connection to the internet and provides internet connectivity to multiple master and or slave devices. The figure below shows an example deployment of this scenario. -------- |Device|\ \|/ ---------- | 1 | (TDD AirIF) | |Database| -------- \ | .---. /--------- o \ |-|---------| ( ) / o | Master | / \ o / | |========( Internet ) o / |-----------| \ / -------- (TDD AirIF) ( ) |Device| / (----) | n | -------- Figure 3: Hotspot service using TV white space spectrum Once a master/AP has been correctly installed and configured, a simplified power up and operation scenario utilizing TV White Space to provide Internet connectivity service <Insert>to slave devices, including the ability to clear WSDs from select channels, is described. This scenario </Insert>consists of the following steps: 1. The master/AP 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). <Insert>A local regulator may identify exception cases where a Master may initialize over white space (e.g. the FCC allows a Master to initialize over TV white space in certain conditions)."</Insert> 2. The master/AP 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 Section 4.1 <Ed. Note>reference is to database discovery, will be updated in next version</Ed. Note>). 3. The master/AP registers with the trusted database according to regulatory domain requirements (see Section 4.2 <Ed. Note>reference is to registration, will be updated in next version</Ed. Note>). 4. Following the <Insert>successful</Insert> registration process, the master/AP 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/AP has met all regulatory domain requirements (e.g. been previously authenticated, etc), the database responds with a list of available white space channels that the master may use, and optionally a duration of time for their use<Insert>, associated maximum power levels or a notification of any additional requirement for sensing</Insert>. 6. Once the master/AP has met all regulatory domain requirements (e.g. authenticated the WS channel list response message from the database, etc), the AP selects an available WS channel(s) from the list. 7. The slave or user device scans the TV bands to locate a master/AP transmission, and associates with the AP. <Ed. Note>insert new step</Ed. Note> 8. The slave/user device queries the master for a channel list, providing to the master the slaves' Device ID and <Insert>optionally its</Insert> geolocation. 9. Once the master/AP has met all regulatory domain requirements (e.g. validating the Device ID with the trusted database, etc) the master provides the list of channels locally available to the slave/user device. If the channel that the user terminal is currently using is not included in the list of locally available channels, the slave/user device ceases all operation on its current channel. The slave/user device may scan for another AP transmission on a different channel. <Insert> 10. The master/AP 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/AP is not available, the master/AP must stop transmitting on that channel immediately.In addition or optionally, the database may send a message to the master/AP to rescind the availability of one or more channels. The master/AP 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/AP, steps 8 and 9 above. The frequency to repeat the process is determined by the local regulator. If the response from the master/AP 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. In addition or optionally, the database may send a message to the master/AP to rescind the availability of one or more channels. The master/AP must then notify the slave or user device of the rescinded channels. 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
