Hello Andy, These steps are meant to address the FCC requirements in ยง15.711(b)(3)(iv) where the slave device may only transmit upon receiving a list of available channels from a master. Certainly this requirement, and thus steps 8, 9 & 11, may not apply in all parts of the world.
Kind Regards, Scott On 2/6/12 6:10 AM, "ext [email protected]" <[email protected]> wrote: >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
