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

From: <[email-masked]>
Date: Fri, 3 Feb 2012 21:41:44 +0000

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>

---

From: <[email-masked]>
Date: Mon, 6 Feb 2012 12:10:35 +0000

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

    --------
    |Device|\                 \|/                            ----------

   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>.

   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.

<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

---

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

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.
>
>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.
>
>review the text and send your comments either directly to the editor or
>to the mailing list.
>
>Kind Regards,
>Raj & Scott
>
>
>
>
>
>
>
>space (e.g. the FCC allows a Master to initialize over TV white space in
>certain conditions)."</Insert>
>
>       regulatory domain requirements (see Section 4.2 <Ed.
>Note>reference is to registration, will be updated in next version</Ed.
>Note>).
>
>       and optionally a duration of time for their use<Insert>,
>associated maximum power levels or a notification of any additional
>requirement for sensing</Insert>.
>
>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>
>

---

From: Paul Lambert <[email-masked]>
Date: Mon, 6 Feb 2012 15:00:04 -0800

Comments inline below.

Paul

>   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"
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.

>    |  1   | (TDD AirIF)       |                             |Database|
[Paul]
Remove TDD
Add Connection from Device-to-Device
>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"
Remove "simplified" - simplified from what ...

 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:

>       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

>Note>reference is to database discovery, will be updated in next
[Paul] 
Needs to have determination of correct database before connecting.

>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>
>
[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.

>       database, etc), the AP selects an available WS channel(s) from
[Paul] 
Strike "an" --  "AP selects one or more available WS channels ...

What about the AP sending an enabling signal ... missing a step here ...
>       transmission, and associates with the AP. <Ed. Note>insert new
[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.

>       the slaves' Device ID and <Insert>optionally its</Insert>
[Paul] 
What about the model/device type?

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.

>       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:

       slave/user device.  

>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.

>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>
>

---

From: Nancy Bravin <[email-masked]>
Date: Mon, 6 Feb 2012 15:13:05 -0800

HI Guys, in addition there are a few places where it still says TV White Space which I though was going to be eliminated and changed to White Space…
It may be deleted by suggested edits by Paul, but we need to be careful to watch for those errors…SIncerely, Nancy

---

From: <[email-masked]>
Date: Tue, 7 Feb 2012 15:26:27 +0000

Hello,

Reply comments are inline below.

Kind Regards,
Scott

>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.

>>   <other> master and slave devices.
Scott>I agree with you.
>>          Figure 3: Hotspot service using TV white space spectrum
Scott>Suggest to keep this for this simple use case, as above.
>Add Connection from Device-to-Device
Scott>I agree with you.
>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.
>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).
>
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.

>Needs to have determination of correct database before connecting.
Scott>I agree with you, this is in section 4.1 database discovery.
>Why would this be in the response.  If it's a regulation - the device
>would already know this and be ready to sense.
Scott>This sensing text comes from Ofcom's Implementing Geolocation §2.15
(4th bullet).
>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.
>It may be possible to have a device that looks a lot like an AP, but is a
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.
>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.
>	will have specific requirements for inclusion of various device
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?
>?  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:
>
Scott>I agree with you.

---

From: <[email-masked]>
Date: Tue, 7 Feb 2012 15:44:17 +0000

Hi Nancy,

Yes we have discussed removing some of the TV white space emphasis, but my
understanding was that we did not intend to expunge TV white space from
the document. Clearly PAWS should work for bands other than TV, but also
TV is the first commercial opportunity.

Kind Regards,
Scott

On 2/6/12 5:13 PM, "ext Nancy Bravin" <[email-masked]> wrote:

>HI Guys, in addition there are a few places where it still says TV White
>Space which I though was going to be eliminated and changed to White
>SpaceŠ
>It may be deleted by suggested edits by Paul, but we need to be careful
>to watch for those errorsŠSIncerely, Nancy
>
>>master sometimes violate the basic premise of WS operation (transmit
>>when not enabled).
>>

---

From: Nancy Bravin <[email-masked]>
Date: Tue, 7 Feb 2012 08:07:30 -0800

Hi Scott,

The reason I mention this is
There are discussions going on in the Congress and Senate about White Space, as we noted as well from Rex, so how to not limit
this to TVWS when in fact rules may change quickly and there may be more shared spectrum ….from other spectrum users that are not
from TVWS. I think we should think in those terms. 
In my opinion we may want to be a little more open to where the spectrum comes from, and globally they could come
from other than TVWS as well depending on how much spectrum is used infrequently to allow such use. 
SIncerely, Nancy

---

From: Gerald Chouinard <[email-masked]>
Date: Wed, 8 Feb 2012 10:20:49 -0500

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-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, 06 February, 2012 15:40
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [paws] UC&R I-D: section 4.3 (Hotspot: urban internet
connectivity service)

Hello Andy,

Kind Regards,
Scott