Subject: [paws] UC&R I-D: section 4.9 (Indoor networking)

From: <[email-masked]>
Date: Wed, 8 Feb 2012 21:16:14 +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 Indoor Networking 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:

* includes relevant updates from comments to the Hotspot use case
* removes "an indication of the quality of the spectrum for each channel"
from the database response message. If there is a regulatory requirement
for this, the text should not be deleted.

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.9.  Indoor Networking

   In this use case, the users are inside a house or office.  The users
   want to have connectivity to the internet or to equipment in the same
   or other houses / offices.  This deployment scenario is typically
   characterized by master devices within buildings, that are connected
   to the Internet using a method that does not utilise TV whitespace.
   The master devices can establish TV whitespace links between
   themselves, or between themselves and one or more user devices.

   The figure below shows an example deployment of this scenario.

                       \|/
                        |
 +-------+              |
 |TVWS   |\           +-|---------+
 |Usr Dev|  WS AirIF \ |   TVWS    |\
 +-------+           X|Master Dev | \
                    / +-----------+  \
 +-------+  WS AirIF          |        \               +----------+
 |TVWS   |/                  |         \      (----)  | Database |
 |Usr Dev|                   |          \    (      ) /----------+
 +-------+               WS AirIF        \  /        \
                             |            X( Internet )
                             |           /  \        /
 +-------+             \|/   |          /    (      )
 |TVWS   |\             |    |         /      (----)
 |Usr Dev|  WS AirIF    |    |        /
 +-------+          \ +-|---------+  /
                     \|   TVWS    | /
                      |Master Dev |/
                      +-----------+

     Figure 9: Example illustration of indoor TV white space use-case

   A simplified operational scenario utilizing TV whitespace to provide
   indoor networking consists of the following steps:

   1.  The master device powers up with its whitespace radio in idle or
       listen mode only (no active transmission on the whitespace
       frequency band).

   2.  The master device 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 3.1 above
<Ed.
Note>reference is to database discovery, will be updated in next
version</Ed. Note>).

<Insert>
3. The master device registers with the trusted database according to
       regulatory domain requirements (see Section 4.1.2).
</Insert>

4. <Insert>Following the successful registration process,</Insert>The
master device sends <Insert>a query to the trusted database requesting a
list of available WS
       channels based upon its geolocation. 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><Delete>its geolocation and
location uncertainty
       information, and optionally additional information which may
       include (1) device ID and (2) antenna characteristics, to a
       trusted database, requesting a list of available whitespace
       channels based upon this information.</Delete>

5. <Insert>If the master has met all regulatory requirements,</Insert>The
database responds with a list of available white space
       channels that the master device may use, and optional information
       which may include inter alia (1) a duration of time for the use
       of each channel (channel validity time) (2) a maximum radiated
       power for each channel, <Delete>(3) an indication of the quality of
the
       spectrum for each channel</Delete> and (4) directivity and other
antenna
       information.

6.  Once the master device authenticates the whitespace channel list
       response message from the database, the master device selects one
       or more available whitespace channels from the list.

7.  The user device(s) scan(s) the TV white space bands to locate the
       master device transmissions, and associates with the master.