Hello, Reply comments are inline below.
Kind Regards, Scott On 2/6/12 5:00 PM, "ext Paul Lambert" <[email protected]> wrote: > >Comments inline below. > >Paul > > >>-----Original Message----- >>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. >[Paul] >Remove TDD - not necessary and may not always be correct >Remove low power threshold ... unnecessary, what do you mean by "low" Scott>The intent here was to describe the first and most simplest use cases. Indeed the radio duplex may not always be TDD, but is the simplest case and is good as a first example since only one white space channel is required to deploy a network. Can be removed if the group desires, but I think TDD is a useful clarification for a first simple use case. "Low power threshold" is undefined, good clarification to remove this. >May or may not provide Internet .... >> Each master/AP has a >> connection to the internet and <may provide> internet connectivity to >> <other> master and slave devices. Scott>I agree with you. > > >> >> 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 >[Paul] >Remove TDD Scott>Suggest to keep this for this simple use case, as above. >Add Connection from Device-to-Device Scott>I agree with you. >> >> 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: >[Paul] >What this all about? Clearing devices from channels has nothing to do >with the regulatory requirements >Please remove "clearlin devices" Scott>This was added based on discussion on the reflector (http://www.ietf.org/mail-archive/web/paws/current/msg00538.html) and based on requirements from Ofcom, see Implementing Geolocation §3.41 and §3.45(c). >Remove "simplified" - simplified from what ... Scott>Simplified in this case means that the use case does not try to cover all possible events, just focus on a simple scenario in order to derive the corresponding requirements. > > Change to: > > Once a master/AP has been correctly installed and configured, the >master may provide Internet connectivity through a start-up process that >checks the database for available channels and enables any slave devices. >This scenario 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> >[Paul] >I do not see that this is necessary. If a master is connecting to a DB >over WS, then it had to first act as a slave. Acting as a simultaneous >slave and master is a much cleaner architectural model than having a >master sometimes violate the basic premise of WS operation (transmit when >not enabled). > >Remove portions in 1 between the inserts. >Add another scenario for enablement of a Master device if you want to >better describe this process Scott>This text was added to address FCC §15.711(e). The behavior is different from a slave in this case, the master must request and receive a channel list from the database, not from the (other) master. > >> >> 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>). >[Paul] >Needs to have determination of correct database before connecting. Scott>I agree with you, this is in section 4.1 database discovery. > > > >> >> 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>. >[Paul] >Requirement for sensing????? >Why would this be in the response. If it's a regulation - the device >would already know this and be ready to sense. >Please remove above text on sensing. >If you are trying to describe use of sensing - please add a new secenario. Scott>This sensing text comes from Ofcom's Implementing Geolocation §2.15 (4th bullet). > >> >> 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. >[Paul] >Strike "an" -- "AP selects one or more available WS channels ... Scott>I agree with you. > >What about the AP sending an enabling signal ... missing a step here ... Scott>Good comment, will add this. >> >> 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> >[Paul] Needs to check not for an AP, but a specific enabling >signal/message/field. >It may be possible to have a device that looks a lot like an AP, but is a >slave device. Scott>This text appears to fulfill both FCC and Ofcom requirements. FCC precludes peer-to-peer thus the slave (Mode I) device must find a master. Ofcom allows slave-to-slave but only under control of the same master. Also Ofcom does not require an enabling signal. > > >> >> 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. >[Paul] >What about the model/device type? Scott>The Device ID includes manufacturer, model number and serial number. But you have a good point, this should be clarified. > >Can we make the Device ID optional based on regulatory requirements.... >Possible text: > 8. The slave device > sends a request to the master for the list of available channels. > The slave device may optionally include device model/type, device Id, > device operating modes and device geolocation. Regulatory domains > will have specific requirements for inclusion of various device >attributes. Scott>Clarifying the attributes are based on local regulatory requirement is good, will add this. I don't know what are the device operating modes nor which regulatory requirement these are addressing, can you please clarify? > > >> >> 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. >[Paul] >? Except for a rare race condition - it's not possible to not have the >channel being used by an AP not be on the list of available channels. > >Change to: > > 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. Scott>I agree with you. > >> >><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
