Subject: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet broadband access)

From: <[email-masked]>
Date: Wed, 8 Feb 2012 17:54:46 +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 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>

---

From: Gerald Chouinard <[email-masked]>
Date: Wed, 8 Feb 2012 17:16:37 -0500

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.

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

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 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-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, 08 February, 2012 12:55
To: [email-masked]
Subject: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet
broadbandaccess)

Hello All,

Kind Regards,
Raj & Scott

      -------
      |Slave|\                \|/                             ----------

   8.  The slave/user

<Insert>

_______________________________________________
paws mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/paws

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 8 Feb 2012 14:41:50 -0800

namecalling nits below....

> sharing the same location as the base station as far as querying for the

IEEE 802 uses the terms _base station_ (BS) and _subscriber station_
(SS) (not slave).
> 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

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.  

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

---

From: Paul Lambert <[email-masked]>
Date: Wed, 8 Feb 2012 18:27:58 -0800

>the middle is known as RS, short for relay station.

Why copy terms from a dying standard ... versus using 802.11af terminology?

Paul

---

From: Gerald Chouinard <[email-masked]>
Date: Thu, 9 Feb 2012 10:05:44 -0500

Rex,

See my comments below.

Gerald

-----Original Message-----
From: Rex Buddenberg [mailto:[email-masked]] 
Sent: Wednesday, 08 February, 2012 17:42
To: Gerald Chouinard
Cc: [email-masked]; [email-masked]
Subject: Re: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet
broadbandaccess)

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)

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.

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.

---

From: Gerald Chouinard <[email-masked]>
Date: Thu, 9 Feb 2012 10:09:32 -0500

Paul,

802.11af is designed to address other use cases that the Wide-area or rural
broadband access case.

Gerald

-----Original Message-----
From: Paul Lambert [mailto:[email-masked]] 
Sent: Wednesday, 08 February, 2012 21:28
To: Rex Buddenberg; Gerald Chouinard
Cc: [email-masked]
Subject: RE: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet
broadbandaccess)

Paul

---

From: <[email-masked]>
Date: Fri, 10 Feb 2012 16:18:55 +0000

Hi,

Thank you Gerald, Rex and Paul for the review and comments.

The completed PAWS standard will support white space deployment of
multiple radio standards. In this case I believe it makes sense to try and
use terminology which is not specific to a particular radio technology.

Kind Regards,
Scott

---

From: <[email-masked]>
Date: Fri, 10 Feb 2012 16:18:53 +0000

Hi,

Thank you Gerald and Rex for the review and comments.

Regarding updating the geolocation of the slave at the master device, and
question if this is in scope of PAWS, I propose we could accept Gerald's
corrections to steps 8 & 11. If this function is indeed out of scope for
PAWS then I believe we will find there are no related requirements
identified to be included in section 6.

Regarding the relay concept, this is included in the "Rapid deployed
network for emergency scenario" use case, see Figure 7 in v-02. As this
will allow for appropriate requirements to be identified and included in
section 6, are you okay to not include this in the Wide-area use case?

Kind Regards,
Scott

On 2/9/12 9:05 AM, "ext Gerald Chouinard" <[email-masked]>
wrote:

>> geolocation of each slave device needs to be provided to the base
>>station
>so
>> slave devices.  This is the common list of channels that needs to be
>>sent
>to

---

From: Gerald Chouinard <[email-masked]>
Date: Fri, 10 Feb 2012 13:59:33 -0500

Scott,

Fine with me.

Gerald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, 10 February, 2012 11:19
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet
broadbandaccess)

Hi,

Kind Regards,
Scott