Hi, I agree with Scott here. The FCC requirement seems to be superfluous but even then, the way the master would send the channel information to the slaves should be beyond the scope of PAWS. It will not use the protocol that needs to be defined to access the database.
In the IEEE 802.22 Standard, the base station regularly broadcasts a prioritized list of backup channels so that if the base station needs to change the channel of the network because the current channel (or its adjacent channels if the device EIRP is larger than 100 mW) becomes occupied by an incumbent as indicated by the database or some RF sensing scheme, the slave CPEs can all switch to the next channel. This process has nothing to do with the protocol used by the base station to access the database. Respectfully ... Gerald -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Monday, 06 February, 2012 15:40 To: [email protected]; [email protected]; [email protected] Subject: Re: [paws] UC&R I-D: section 4.3 (Hotspot: urban internet connectivity service) 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 _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
