Subject: Re: [paws] UC&R I-D: section 4.3 (Hotspot: urban internet connectivity service)

From: <[email-masked]>
Date: Mon, 6 Feb 2012 20:58:58 +0000

Scott

Thanks for the explanation, sorry I hadn't spotted this difference UK-US.

Regards

Andy

-----Original Message-----
From: [email-masked] <[email-masked]>
Sent: 06 February 2012 20:39
To: Sago,AJ,Andy,COD R <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: 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-masked]" <[email-masked]> 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-masked] [mailto:[email-masked]] On Behalf Of
>[email-masked]
>Sent: 03 February 2012 21:42
>To: [email-masked]
>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-masked]
>https://www.ietf.org/mailman/listinfo/paws