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
