Rex, See my comments below.
Gerald -----Original Message----- From: Rex Buddenberg [mailto:[email protected]] Sent: Wednesday, 08 February, 2012 17:42 To: Gerald Chouinard Cc: [email protected]; [email protected] Subject: Re: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet broadbandaccess) namecalling nits below.... On Wed, 2012-02-08 at 17:16 -0500, Gerald Chouinard wrote: > 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. IEEE 802 uses the terms _base station_ (BS) and _subscriber station_ (SS) (not slave). [Gerald] 802.22 uses base station (BS) and customer premise equipment (CPE) > > 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). In a pure IEEE 802.16 notion, this is entirely correct. > 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. But it is part of several standards and associated technologies. IEEE 802.16j (now that it's ratified, correctly termed IEEE 802.16-2009) comes to mind. [Gerald] In such case, a new use case for peer-to-peer and mesh networking for Wide-area and rural broadband access would need to be developed. This use case was developed for point-to-multipoint topology. > > 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 way out of this circle is to again ape IEEE 802.16. The device in the middle is known as RS, short for relay station. Further there's a lot of 'mesh' talk where all stations would be peers. In both cases, the RS or the peers would have to assume the responsibility of a BS. [Gerald] Again, a new use case would need to be developed to cover this case. As a result, the model for the PAWS would still be the BS acting as the master and its associated terminals being the slaves. > > 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 _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
