    Internet Engineering Task Force (IETF)                   A. Mancuso, Ed.
    Request for Comments: 6953                                        Google
    Category: Informational                                      S. Probasco
    ISSN: 2070-1721
                                                                    B. Patil
                                                               Cisco Systems
                                                                    May 2013

                Protocol to Access White-Space (PAWS) Databases:
                           Use Cases and Requirements

    Abstract

       Portions of the radio spectrum that are assigned to a particular use
       but are unused or unoccupied at specific locations and times are
       defined as "white space".  The concept of allowing additional
       transmissions (which may or may not be licensed) in white space is a
       technique to "unlock" existing spectrum for new use.  This document
       includes the problem statement for the development of a protocol to
       access a database of white-space information followed by use cases
       and requirements for that protocol.  Finally, requirements associated
       with the protocol are presented.

    Status of This Memo

       This document is not an Internet Standards Track specification; it is
       published for informational purposes.

       This document is a product of the Internet Engineering Task Force
       (IETF).  It represents the consensus of the IETF community.  It has
       received public review and has been approved for publication by the
       Internet Engineering Steering Group (IESG).  Not all documents
       approved by the IESG are a candidate for any level of Internet
       Standard; see Section 2 of RFC 5741.

       Information about the current status of this document, any errata,
       and how to provide feedback on it may be obtained at
       http://www.rfc-editor.org/info/rfc6953.

    Mancuso, et al.               Informational                     [Page 1]

    RFC 6953             PAWS Use Cases and Requirements            May 2013

    Copyright Notice

       Copyright (c) 2013 IETF Trust and the persons identified as the
       document authors.  All rights reserved.

       This document is subject to BCP 78 and the IETF Trust's Legal
       Provisions Relating to IETF Documents
       (http://trustee.ietf.org/license-info) in effect on the date of
       publication of this document.  Please review these documents
       carefully, as they describe your rights and restrictions with respect
       to this document.  Code Components extracted from this document must
       include Simplified BSD License text as described in Section 4.e of
       the Trust Legal Provisions and are provided without warranty as
       described in the Simplified BSD License.

    Table of Contents

       1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
         1.1.  Introduction to White Space  . . . . . . . . . . . . . . .  3
         1.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
           1.2.1.  In Scope . . . . . . . . . . . . . . . . . . . . . . .  4
           1.2.2.  Out of Scope . . . . . . . . . . . . . . . . . . . . .  4
       2.  Conventions Used in This Document  . . . . . . . . . . . . . .  5
         2.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
         2.2.  Requirements Language  . . . . . . . . . . . . . . . . . .  5
       3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  6
         3.1.  Global Applicability . . . . . . . . . . . . . . . . . . .  6
         3.2.  Database Discovery . . . . . . . . . . . . . . . . . . . .  8
         3.3.  Device Registration  . . . . . . . . . . . . . . . . . . .  8
         3.4.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . .  9
         3.5.  Data Model Definition  . . . . . . . . . . . . . . . . . .  9
       4.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
         4.1.  Master-Slave White-Space Networks  . . . . . . . . . . . .  9
         4.2.  Offloading: Moving Traffic to a White-Space Network  . . . 11
         4.3.  White Space Serving as Backhaul  . . . . . . . . . . . . . 13
         4.4.  Rapid Network Deployment during Emergencies  . . . . . . . 14
         4.5.  White Space Used for Local TV Broadcaster  . . . . . . . . 15
       5.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16
         5.1.  Data Model Requirements  . . . . . . . . . . . . . . . . . 16
         5.2.  Protocol Requirements  . . . . . . . . . . . . . . . . . . 17
         5.3.  Operational Requirements . . . . . . . . . . . . . . . . . 19
         5.4.  Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 19
       6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
       7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
       8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
         8.1.  Normative References . . . . . . . . . . . . . . . . . . . 22
         8.2.  Informative References . . . . . . . . . . . . . . . . . . 22

    Mancuso, et al.               Informational                     [Page 2]

    RFC 6953             PAWS Use Cases and Requirements            May 2013

    1.  Introduction

    1.1.  Introduction to White Space

       Wireless spectrum is a commodity that is regulated by governments.
       The spectrum is used for various purposes, which include, but are not
       limited to, entertainment (e.g., radio and television), communication
       (e.g., telephony and Internet access), military (e.g., radars, etc.),
       and navigation (e.g., satellite communication, GPS).  Portions of the
       radio spectrum that are assigned to a licensed (primary) user but are
       unused or unoccupied at specific locations and times are defined as
       "white space".  The concept of allowing additional (secondary)
       transmissions (which may or may not be licensed) in white space is a
       technique to "unlock" existing spectrum for new use.

       An obvious requirement is that these secondary transmissions do not
       interfere with the assigned use of the spectrum.  One interesting
       observation is that often, in a given physical location, the primary
       user(s) may not be using the entire band assigned to them.  The
       available spectrum for secondary transmissions would then depend on
       the location of the secondary user.  The fundamental issue is how to
       determine, for a specific location and specific time, if any of the
       assigned spectrum is available for secondary use.

       Academia and industry have studied multiple cognitive radio [CRADIO]
       mechanisms for use in such a scenario.  One simple mechanism is to
       use a geospatial database that contains the spatial and temporal
       profile of all primary licensees' spectrum usage, and require
       secondary users to query the database for available spectrum that
       they can use at their location.  Such databases can be accessible and
       queryable by secondary users on the Internet.

       Any entity that is assigned spectrum that is not densely used may be
       asked by a governmental regulatory agency to share it to allow for
       more intensive use of the spectrum.  Providing a mechanism by which
       secondary users share the spectrum with the primary user is
       attractive in many bands, in many countries.

       This document includes the problem statement followed by use cases
       and requirements associated with the use of white-space spectrum by
       secondary users via a database query protocol.  The final sections
       include the requirements associated with such a protocol.  Note that
       the IETF has undertaken to develop a database query protocol (see
       [PAWS]).

    Mancuso, et al.               Informational                     [Page 3]

    RFC 6953             PAWS Use Cases and Requirements            May 2013

    1.2.  Scope

    1.2.1.  In Scope

       This document covers the requirements for a protocol to allow a
       device to access a database to obtain spectrum availability
       information.  Such a protocol should allow a device to perform the
       following actions:

       1.  Determine the relevant database to query.

       2.  Connect to and optionally register with the database using a
           well-defined protocol.

       3.  Provide geolocation and perhaps other data to the database using
           a well-defined format for querying the database.

       4.  Receive in response to the query a list of available white-space
           frequencies at the specified geolocation using a well-defined
           format for the information.

       5.  Send an acknowledgment to the database with information
           containing channels selected for use by the device and other
           device operation parameters.

       Note: The above protocol actions should explicitly or implicitly
       support the ability of devices to re-register and/or re-query the
       database when they change their locations or operating parameters.
       This will allow them to receive permission to operate in their new
       locations and/or with their new operating parameters, and to send
       acknowledgments to the database that include information on their new
       operating parameters.

    1.2.2.  Out of Scope

       The following topics are out of scope for this specification:

       1.  It is the device's responsibility to query the database for new
           spectrum when the device moves, changes operating parameters,
           loses connectivity, etc.  Other synchronization mechanisms are
           out of scope.

       2.  A rogue device may operate without contacting the database to
           obtain available spectrum.  Hence, enforcement of spectrum usage
           by devices is out of scope.

    Mancuso, et al.               Informational                     [Page 4]

    RFC 6953             PAWS Use Cases and Requirements            May 2013

       3.  The protocol defines communications between the database and
           devices.  The protocol for communications between devices is out
           of scope.

       4.  Coexistence and interference avoidance of white-space devices
           within the same spectrum are out of scope.

       5.  Provisioning (releasing new spectrum for white-space use) is out
           of scope.

    2.  Conventions Used in This Document

    2.1.  Terminology

       Database:  A database is an entity that contains current information
          about available spectrum at a given location and time, as well as
          other types of information related to spectrum availability and
          usage.

       Device Class:  Identifies classes of devices including fixed, mobile,
          portable, etc.  May also indicate if the device is indoor or
          outdoor.

       Device ID:  An identifier for a device.

       Master Device:  A device that queries the database, on its own behalf
          and/or on behalf of a slave device, to obtain available spectrum
          information.

       Slave Device:  A device that queries the database through a master
          device.

       Trusted Database:  A database that is trusted by a device or provides
          data objects that are trusted by a device.

       White Space (WS):  Radio spectrum that is available for secondary use
          at a specific location and time.

       White-Space Device (WSD):  A device that uses white-space spectrum as
          a secondary user.  A white-space device can be a fixed or portable
          device such as an access point, base station, or cell phone.

    2.2.  Requirements Language

       The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
       document are to be interpreted as described in RFC 2119 [RFC2119].

    Mancuso, et al.               Informational                     [Page 5]

    RFC 6953             PAWS Use Cases and Requirements            May 2013

    3.  Problem Statement

       The use of white-space spectrum is enabled via the capability of a
       device to query a database and obtain information about the
       availability of spectrum for use at a given location.  The databases
       are reachable via the Internet, and the devices querying these
       databases are expected to have some form of Internet connectivity,
       directly or indirectly.  While databases are expected to support the
       rule set(s) of one or more regulatory domains, and the regulations
       and available spectrum associated with each rule set may vary, the
       fundamental operation of the protocol must be independent of any
       particular regulatory environment.

       An example of the high-level architecture of the devices and
       databases is shown in Figure 1.

                     -----------
                     | Master  |
                     |WS Device|                              ------------
                     |Lat: X   |\           .---.    /--------|Database A|
                     |Long: Y  | \         (     )  /         ------------
                     -----------  \-------/       \/               o
                                         ( Internet)               o
                     -----------  /------(         )\              o
                     | Master  | /        (       )  \             o
                     |WS Device|/          (_____)    \       ------------
                     |Lat: X   |                       \------|Database B|
                     |Long: Y  |                              ------------
                     -----------

          Figure 1: High-Level View of White-Space Database Architecture

       Note that there could be multiple databases serving white-space
       devices.  In some countries, such as the U.S., the regulator has
       determined that multiple databases may provide service to white-space
       devices.

       A messaging interface between the white-space devices and the
       database is required for operating a network using the white-space
       spectrum.  The following sections discuss various aspects of such an
       interface and the need for a standard.

    3.1.  Global Applicability

       The use of white-space spectrum is currently approved or being
       considered in multiple regulatory domains, whose rules may differ.
       However, the need for devices that intend to use the spectrum to
       communicate with a database remains a common feature.  The database

    Mancuso, et al.               Informational                     [Page 6]

    RFC 6953             PAWS Use Cases and Requirements            May 2013

       implements rules that protect all primary users, independent of the
       characteristics of the white-space devices.  It also provides a way
       to specify a schedule of use, since some primary users (for example,
       wireless microphones) only operate in limited time slots.

       Devices need to be able to query a database, directly or indirectly,
       over the public Internet and/or private IP networks prior to
       operating in available spectrum.  Information about available
       spectrum, schedule, power, etc., are provided by the database as a
       response to the query from a device.  The messaging interface needs
       to be:

       1.  Interface agnostic - An interface between a master white-space
           device and database can be wired or unwired (e.g., a radio/air
           interface technology such as IEEE 802.11af, IEEE 802.15.4m, IEEE
           802.16, IEEE 802.22, LTE, etc.)  However, the messaging interface
           between a master white-space device and the database should be
           agnostic to the interface used for such messaging while being
           cognizant of the characteristics of the interface technology and
           the need to include any relevant attributes in the query to the
           database.

       2.  Spectrum agnostic - The spectrum used by primary and secondary
           users varies by country.  Some spectrum bands have an explicit
           notion of a "channel": a defined swath of spectrum within a band
           that has some assigned identifier.  Other spectrum bands may be
           subject to white-space sharing, but only have actual frequency
           low/high parameters to define primary and secondary use.  The
           protocol should be able to be used in any spectrum band where
           white-space sharing is permitted.

       3.  Globally applicable - A common messaging interface between white-
           space devices and databases will enable the use of such spectrum
           for various purposes on a global basis.  Devices can operate in
           any location where such spectrum is available and a common
           interface ensures uniformity in implementations and deployment.
           To allow the global use of white-space devices in different
           countries (whatever the regulatory domain), the protocol should
           support the database that communicates the applicable regulatory
           rule-set information to the white-space device.

       4.  Built on flexible and extensible data structures - Different
           databases are likely to have different requirements for the kinds
           of data required for registration (different regulatory rule sets
           that apply to the registration of devices) and other messages
           sent by the device to the database.  For instance, different
           regulators might require different device-characteristic
           information to be passed to the database.

    Mancuso, et al.               Informational                     [Page 7]

    RFC 6953             PAWS Use Cases and Requirements            May 2013

    3.2.  Database Discovery

       The master device must obtain the address of a trusted database,
       which it will query for available white-space spectrum.  If the
       master device uses a discovery service to locate a trusted database,
       it may perform the following steps (this description is intended as
       descriptive, not prescriptive):

       1.  The master device constructs and sends a request (e.g., over the
           Internet) to a trusted discovery service.

       2.  If no acceptable response is received within a pre-configured
           time limit, the master device concludes that no trusted database
           is available.  If at least one response is received, the master
           device evaluates the response(s) to determine if a trusted
           database can be identified where the master device is able to
           receive service from the database.  If so, it establishes contact
           with the trusted database.

       3.  The master device establishes a white-space network as described
           in Section 4.

       Optionally, and in place of steps 1-2 above, the master device can be
       pre-configured with the address (e.g., URI) of one or more trusted
       databases.  The master device can establish contact with one of these
       trusted databases.

    3.3.  Device Registration

       The master device may register with the database before it queries
       the database for available spectrum.  A registration process may
       consist of the following steps:

       1.  The master device sends registration information to the database.
           This information may include the device ID; serial number
           assigned by the manufacturer; device location; device antenna
           height above ground; name of the individual or business that owns
           the device; and the name, postal address, email address, and
           phone number of a contact person responsible for the device's
           operation.

       2.  The database responds to the registration request with an
           acknowledgment to indicate the success of the registration
           request or with an error if the registration was unsuccessful.
           Additional information may be provided by the database in its
           response to the master device.

    Mancuso, et al.               Informational                     [Page 8]

    RFC 6953             PAWS Use Cases and Requirements            May 2013

    3.4.  Protocol

       A protocol that enables a white-space device to query a database to
       obtain information about available spectrum is needed.  A device may
       be required to register with the database with some credentials prior
       to being allowed to query.  The requirements for such a protocol are
       specified in this document.

    3.5.  Data Model Definition

       The contents of the queries and response need to be specified.  A
       data model is required; it must enable the white-space device to
       query the database while including all the relevant information, such
       as geolocation, radio technology, power characteristics, etc., which
       may be country, spectrum, and regulatory dependent.  All databases
       are able to interpret the data model and respond to the queries using
       the same data model that is understood by all devices.

    4.  Use Cases

       There are many potential use cases for white-space spectrum -- for
       example, providing broadband Internet access in urban and densely
       populated hotspots, as well as rural and remote, underserved areas.
       Available white-space spectrum may also be used to provide Internet
       'backhaul' for traditional Wi-Fi hotspots or for use by towns and
       cities to monitor/control traffic lights, read utility meters, and
       the like.  Still other use cases include the ability to offload data
       traffic from another Internet access network (e.g., 3G cellular
       network) or to deliver data, information, or a service to a user
       based on the user's location.  Some of these use cases are described
       in the following sections.

    4.1.  Master-Slave White-Space Networks

       There are a number of common scenarios in which a master white-space
       device will act as proxy or mediator for one or more slave devices
       using its connection to the Internet to query the database for
       available spectrum for itself and for one or more slave devices.
       These slave devices may be fixed or mobile, in close proximity with
       each other (indoor network or urban hotspot), or at a distance (rural
       or remote WAN).  Once slave devices switch to white-space spectrum
       for their communications, they may connect through the master to the
       Internet or use white-space spectrum for intra-network communications
       only.  The master device can continue to arbitrate and control white-
       space communications by slave devices, and it may notify them when
       they are required to change white-space frequencies or cease white-
       space communications.

    Mancuso, et al.               Informational                     [Page 9]

    RFC 6953             PAWS Use Cases and Requirements            May 2013

       Figure 2 depicts the general architecture of such a simple master-
       slave network in which the master device communicates with a database
       on its own behalf and on behalf of slave devices.

              --------
              |Slave |
              |Device| \             \|/                          ----------
              |  1   |  (Air)         |                           |Database|
              --------       \        |                 (----)   /|--------|
                 |            \ ------|------          (      ) /
                 |             \|  Master   |         /        \
               --------        /|           |======= ( Internet )
               |Slave |       / |  Device   |         \        /
               |Device|  (Air)  |           |          (      )
               |  2   | /       |-----------|           (----)
               --------        /
                 o   |        /
                 o   |     (Air)
                 o   |      /
               --------    /
               |Slave |   /
               |Device|  /
               |  n   |
               --------

                    Figure 2: Master-Slave White-Space Network

       The protocol requirements for these master-slave devices and other
       similar scenarios is essentially the same: the protocol must support
       the ability of a master device to make available-spectrum query
       requests on behalf of slave devices, passing device identification,
       geolocation, and other slave device parameters to the database as
       required to obtain a list of white-space spectrum available for use
       by one or more slave devices.  Of course, different use cases will
       use this spectrum information in different ways, and the details of
       master/slave communications may be different for different use cases.

       Common steps that may occur in master-slave networks include the
       following:

       1.  The master device powers up.

       2.  Slave devices may power up and associate with the master device
           via Wi-Fi or some other over-the-air, non-white-space spectrum.
           Until the slave device is allocated white-space spectrum, any
           master-slave or slave-slave communications occurs over such non-
           white-space spectrum.

    Mancuso, et al.               Informational                    [Page 10]

    RFC 6953             PAWS Use Cases and Requirements            May 2013

       3.  The master has Internet connectivity, determines (or knows) its
           location, and establishes a connection to a trusted database (see
           Section 3.2).

       4.  The master may register with the trusted database (see
           Section 3.3).

       5.  The master sends a query to the trusted database requesting a
           list of available white-space spectrum based upon its
           geolocation.  Query parameters may include the master's location,
           device identifier, and antenna height.  The master may send
           available-spectrum requests to the database on behalf of slave
           devices.

       6.  The database responds to the master's query with a list of
           available white-space spectrum, associated maximum power levels,
           and durations of time for spectrum use.  If the master made
           requests on behalf of slave devices, the master may transmit the
           obtained available-spectrum lists to the slaves (or the master
           may allocate spectrum to slaves from the obtained spectrum
           lists).

       7.  The master may inform the database of the spectrum and power
           level it selects from the available spectrum list.  If a slave
           device has been allocated available white-space spectrum, the
           slave may inform the master of the spectrum and power level it
           has chosen, and the master may, in turn, relay such slave device
           usage to the database.

       8.  Further communication among masters and slaves over the white-
           space network may occur via the selected/allocated white-space
           spectrum frequencies.

       Note: Steps 5 through 7 may be repeated by the master device when it
       (or a slave device that uses the master as a proxy to communicate
       with the database) changes its location or operating parameters --
       for example, after a master changes location, it may query the
       database for available spectrum at its new location, then acknowledge
       the subsequent response received from the database with information
       on the spectrum and power levels it is using at the new location.

    4.2.  Offloading: Moving Traffic to a White-Space Network

       This scenario is a variant of the master-slave network described in
       the previous use case.  In this scenario, an access point (AP) offers
       a white-space service that offloads Internet traffic as an
       alternative data path to a more congested or costly Internet wire,
       wireless, or satellite service.

    Mancuso, et al.               Informational                    [Page 11]

    RFC 6953             PAWS Use Cases and Requirements            May 2013

       Figure 3 shows an example of deployment of this scenario.

                                  \|/
                                   |
                                |--|----------|
              \|/              /|Access Point |\
               |       (Air)--/ |-------------| \
             --|------ /                         \               -----------
            |Portable|/                           \      (----)  | Database|
            | Device |                             \    (      ) /----------
            |--------|\                             \  /        \
                       \                             X( Internet )
                        \                           /  \        /
                         (Air)                     /    (      )
                            \                     /      (----)
                             \                   /
                              \|---------------|/
                               |    Metered    |
                               |    Service    |
                               |---------------|

               Figure 3: Offloading Traffic to a White-Space Network

       A simplified operation scenario of offloading content, such as video
       stream, from a congested or costly Internet connection to a white-
       space service provided by an AP consists of the following steps:

       1.  The AP contacts the database to determine channels it can use.

       2.  The portable device connects to a paid Internet service and
           selects a video for streaming.

       3.  The portable device determines if it can offload to a white-space
           AP:

           A.  If the portable device knows its location, it

               1.  asks the database (using the paid service) for available
                   white-space spectrum;

               2.  listens for and connects to the AP over the permitted
                   white-space spectrum.

           B.  If the portable device does not have GPS or other means to
               determine its position, it

               1.  uses non-white-space spectrum to listen for and connect
                   to the AP;

    Mancuso, et al.               Informational                    [Page 12]

    RFC 6953             PAWS Use Cases and Requirements            May 2013

               2.  asks the AP to query the database for permitted white-
                   space spectrum on its behalf;

               3.  uses the permitted white-space spectrum to connect to the
                   AP.

       4.  The portable device accesses the Internet through the AP to
           stream the selected video.

    4.3.  White Space Serving as Backhaul

       In this use case, an Internet connectivity service is provided to
       users over a common wireless standard, such as Wi-Fi, with a white-
       space master/slave network providing backhaul connectivity to the
       Internet.  Note that Wi-Fi is referenced in Figure 4 and the
       following discussion, but any other technology can be substituted in
       its place.

       Figure 4 shows an example of deployment of this scenario.
                             \|/   White      \|/    \|/     Wi-Fi \|/
                              |    Space       |      |             |
                              |                |      |           |-|----|
                (----)      |-|----|         |-|------|-|         | Wi-Fi|
               (      )     |Master|         | Slave    |--(Air)--| Dev  |
              /        \    |      |--(Air)--| Bridge   |         |------|
             ( Internet )---|      |         | to Wi-Fi |
              \        /    |------|         |----------|           \|/
               (      )                                  \           |
                (----)                                    \(Air)   |-|----|
                                                                \--| Wi-Fi|
                                                                   | Dev  |
                                                                   |------|

                  Figure 4: White-Space Network Used for Backhaul

       Once the bridged device (Slave Bridge + Wi-Fi) is connected to a
       master and WS network, a simplified operation scenario of backhaul
       for Wi-Fi consists of the following steps:

       1.  A bridged slave device (Slave Bridge + Wi-Fi) is connected to a
           master device operating in the WS spectrum (the master obtains
           available white-space spectrum as described in Section 4.1).

       2.  Once the slave device is connected to the master, the Wi-Fi
           access point has Internet connectivity as well.

       3.  End users attach to the Wi-Fi network via their Wi-Fi-enabled
           devices and receive Internet connectivity.

    Mancuso, et al.               Informational                    [Page 13]

    RFC 6953             PAWS Use Cases and Requirements            May 2013

    4.4.  Rapid Network Deployment during Emergencies

       Organizations involved in handling emergency operations maintain an
       infrastructure that relies on dedicated spectrum for their
       operations.  However, such infrastructures are often affected by the
       disasters they handle.  To set up a replacement network, spectrum
       needs to be quickly cleared and reallocated to the crisis response
       organization.  Automation of this allocation and assignment is often
       the best solution.  A preferred option is to make use of a robust
       protocol that has been adopted and implemented by radio
       manufacturers.  A typical network topology solution might include
       wireless access links to the public Internet or private network,
       wireless ad hoc network radios working independently of a fixed
       infrastructure, and satellite links for backup where lack of
       coverage, overload, or outage of wireless access links can occur.

       Figure 5 shows an example of deployment of this scenario.

                                    \|/
                                     | ad hoc
                                     |
                                   |-|-------------|
                                   | Master node   |    |-------------|
              \|/                  | with          |    | White-Space |
               | ad hoc           /| backhaul link |    | Database    |
               |             /---/ |---------------|    |-------------|
            ---|------------/                |      \           /
            | Master node   |                |       |      (--/--)
            | without       |                |        -----(       )
            | backhaul link |                |  Wireless  / Private \
            ----------------\                |    Access (   net or  )
                             \                |           \ Internet )
                              \    \|/        |      ------(        /
                               \    | ad hoc  |      |      (------)
                                \   |         |      /          \
                                 \--|-------------  /Satellite   ----------
                                 | Master node   | / Link        | Other  |
                                 | with          |/              | nodes  |
                                 | backhaul link |               ----------
                                 -----------------

          Figure 5: Rapidly Deployed Network with Partly Connected Nodes

       In the ad hoc network, all nodes are master nodes that allocate radio
       frequency (RF) channels from the database (as described in
       Section 4.1).  However, the backhaul link may not be available to all
       nodes, such as depicted for the left node in the above figure.  To
       handle RF channel allocation for such nodes, a master node with a

    Mancuso, et al.               Informational                    [Page 14]

    RFC 6953             PAWS Use Cases and Requirements            May 2013

       backhaul link relays or proxies the database query for them.  So
       master nodes without a backhaul link follow the procedure as defined
       for clients.  The ad hoc network radios utilize the provided RF
       channels.  Details on forming and maintenance of the ad hoc network,
       including repair of segmented networks caused by segments operating
       on different RF channels, is out of scope of spectrum allocation.

    4.5.  White Space Used for Local TV Broadcaster

       Available white-space spectrum can be deployed in novel ways to
       leverage the public use of hand-held and portable devices.  One such
       use is white-space spectrum used for local TV transmission of audio-
       video content to portable devices used by individuals in attendance
       at an event.  In this use case, audience members at a seminar,
       entertainment event, or other venue plug a miniature TV receiver fob
       into their laptop, computer tablet, cell phone, or other portable
       device.  A master device obtains a list of available white-space
       spectrum (as described in Section 4.1), then broadcasts audio-video
       content locally to the audience over one of the available
       frequencies.  Audience members receive the content through their
       miniature TV receivers tuned to the appropriate white-space band for
       display on the monitors of their portable devices.

       Figure 6 shows an example of deployment of this scenario.

                                                    |------------|
                                                    |White-Space |
                                                    | Database   |
                                          .---.   / |------------|
                  |-----------|          (     ) /
                  |  Master   |         /       \
                  |           |========( Internet)
                  |-----------|         \       /
                        |                (     )
                       /|\                (---)

                  (White-Space
                   Broadcast)

             \|/   \|/   \|/   \|/   \|/   \|/   \|/
              |     |     |     |     |     |     |     .................
            ----- ----- ----- ----- ----- ----- -----
            |   | |   | |   | |   | |   | |   | |   |
            |   | |   | |   | |   | |   | |   | |   |
            ----- ----- ----- ----- ----- ----- -----
           USB TV receivers connected to laptops, cell phones, tablets ...

                 Figure 6: White Space Used for Local TV Broadcast

    Mancuso, et al.               Informational                    [Page 15]

    RFC 6953             PAWS Use Cases and Requirements            May 2013

    5.  Requirements

    5.1.  Data Model Requirements

       D.1  The data model MUST support specifying the geolocation of the
            white-space device, the uncertainty in meters, the height and
            its uncertainty, and the percentage of confidence in the
            location determination.  The data model MUST support [WGS84].

       D.2  The data model MUST support specifying the data and other
            applicable requirements of the rule set that applies to the
            white-space device at a specified location.

       D.3  The data model MUST support device description data that
            identifies a white-space device (serial number, certification
            IDs, etc.) and describes device characteristics, such as device
            class (fixed, mobile, portable, indoor, outdoor, etc.), Radio
            Access Technology (RAT), etc.

       D.4  The data model MUST support specifying a manufacturer's serial
            number for a white-space device.

       D.5  The data model MUST support specifying the antenna- and
            radiation-related parameters of the white-space device, such as:

               antenna height

               antenna gain

               maximum output power, Equivalent Isotropic Radiated Power
               (EIRP) in dBm (decibels referenced to 1 milliwatt)

               antenna radiation pattern (directional dependence of the
               strength of the radio signal from the antenna)

               spectrum mask with lowest and highest possible frequency

               spectrum mask in dBr (decibels referenced to an arbitrary
               reference level) from peak transmit power in EIRP, with
               specific power limit at any frequency linearly interpolated
               between adjacent points of the spectrum mask

               measurement resolution bandwidth for EIRP measurements

       D.6  The data model MUST support specifying owner and operator
            contact information for a transmitter.  This includes the name
            of the transmitter owner and the name, postal address, email
            address, and phone number of the transmitter operator.

    Mancuso, et al.               Informational                    [Page 16]

    RFC 6953             PAWS Use Cases and Requirements            May 2013

       D.7  The data model MUST support specifying spectrum availability.
            Spectrum units are specified by low and high frequencies and may
            have an optional channel identifier.  The data model MUST
            support a schedule including start time and stop time for
            spectrum unit availability.  The data model MUST support maximum
            power level for each spectrum unit.

       D.8  The data model MUST support specifying spectrum availability
            information for a single location and an area (e.g., a polygon
            defined by multiple location points or a geometric shape such as
            a circle).

       D.9  The data model MUST support specifying the frequencies and power
            levels selected for use by a white-space device in the
            acknowledgment message.

    5.2.  Protocol Requirements

       P.1   The master device identifies a database to which it can
             register, make spectrum availability requests, etc.  The
             protocol MUST support the discovery of an appropriate database
             given a location provided by the master device.  The master
             device MAY select a database by discovery at run time or by
             means of a pre-programmed URI.  The master device MAY validate
             discovered or configured database addresses against a list of
             known databases (e.g., a list of databases approved by a
             regulatory body).

       P.2   The protocol MUST support the database informing the master of
             the regulatory rules (rule set) that applies to the master
             device (or any slave devices on whose behalf the master is
             contacting the database) at a specified location.

       P.3   The protocol MUST provide the ability for the database to
             authenticate the master device.

       P.4   The protocol MUST provide the ability for the master device to
             verify the authenticity of the database with which it is
             interacting.

       P.5   The messages sent by the master device to the database and the
             messages sent by the database to the master device MUST support
             integrity protection.

       P.6   The protocol MUST provide the capability for messages sent by
             the master device and database to be encrypted.

    Mancuso, et al.               Informational                    [Page 17]

    RFC 6953             PAWS Use Cases and Requirements            May 2013

       P.7   Tracking of master or slave device uses of white-space spectrum
             by database administrators, regulatory agencies, and others who
             have access to a white-space database could be considered
             invasive of privacy, including privacy regulations in specific
             environments.  The PAWS protocol SHOULD support privacy-
             sensitive handling of device-provided data where such
             protection is feasible, allowed, and desired.

       P.8   The protocol MUST support the master device registering with
             the database; see Device Registration (Section 3.3).

       P.9   The protocol MUST support a registration acknowledgment
             indicating the success or failure of the master device
             registration.

       P.10  The protocol MUST support an available spectrum request from
             the master device to the database, which may include one or
             more of the data items listed in Data Model Requirements
             (Section 5.1).  The request may include data that the master
             device sends on its own behalf and/or on behalf of one or more
             slave devices.

       P.11  The protocol MUST support an available spectrum response from
             the database to the master device, which may include one or
             more of the data items listed in Data Model Requirements
             (Section 5.1).  The response may include data related to master
             and/or slave device operation.

       P.12  The protocol MUST support a spectrum usage message from the
             master device to the database, which may include one or more of
             the data items listed in Data Model Requirements (Section 5.1).
             The message may include data that the master device sends on
             its own behalf and/or on behalf of one or more slave devices.

       P.13  The protocol MUST support a spectrum usage message
             acknowledgment.

       P.14  The protocol MUST support a validation request from the master
             device to the database to validate a slave device, which should
             include information necessary to identify the slave device to
             the database.

       P.15  The protocol MUST support a validation response from the
             database to the master to indicate if the slave device is
             validated by the database.  The validation response MUST
             indicate the success or failure of the validation request.

    Mancuso, et al.               Informational                    [Page 18]

    RFC 6953             PAWS Use Cases and Requirements            May 2013

       P.16  The protocol MUST support the capability for the database to
             inform master devices of changes to spectrum availability
             information.

    5.3.  Operational Requirements

       This section contains operational requirements of a database-device
       system, independent of the requirements of the protocol for
       communication between the database and devices.

       O.1  The master device must be able to connect to the database to
            send requests to the database and receive responses to, and
            acknowledgments of, its requests from the database.

       O.2  A master device MUST be able to determine its location including
            uncertainty and confidence level.  A fixed master device may use
            a location programmed at installation.

       O.3  The master device MUST be configured to understand and comply
            with the requirements of the rule set of the regulatory body
            that apply to its operation at its location.

       O.4  A master device MUST query the database for the available
            spectrum at a specified location before starting radio
            transmission in white space at that location.

       O.5  A master device MUST be able to query the database for the
            available spectrum on behalf of a slave device at a specified
            location before the slave device starts radio transmission in
            white space at that location.

       O.6  The database MUST respond to an available spectrum request.

    5.4.  Guidelines

       White-space technology itself is expected to evolve and include
       attributes such as coexistence and interference avoidance, spectrum
       brokering, alternative spectrum bands, etc.  The design of the data
       model and protocol should be cognizant of the evolving nature of
       white-space technology and consider the following set of guidelines
       in the development of the data model and protocol:

       1.  The data model SHOULD provide a modular design separating
           messaging-specific, administrative-specific, and spectrum-
           specific parts into distinct modules.

       2.  The protocol SHOULD support determination of which
           administrative-specific and spectrum-specific modules are used.

    Mancuso, et al.               Informational                    [Page 19]

    RFC 6953             PAWS Use Cases and Requirements            May 2013

    6.  Security Considerations

       PAWS is a protocol whereby a master device requests a schedule of
       available spectrum at its location (or the location of its slave
       devices) before it (or they) can operate using those frequencies.
       Whereas the information provided by the database must be accurate and
       conform to applicable regulatory rules, the database cannot enforce,
       through the protocol, that a client device uses only the spectrum it
       provided.  In other words, devices can put energy in the air and
       cause interference without asking the database.  Hence, PAWS security
       considerations do not include protection against malicious use of the
       white-space spectrum.

       Threat model for the PAWS protocol:

          Assumptions:

             The link between the master device and the database can be
             wired or wireless and provides IP connectivity.  It is assumed
             that an attacker has full access to the network medium between
             the master device and the database.  The attacker may be able
             to eavesdrop on any communications between these entities.

          Threat 1: User modifies a device to masquerade as another valid
          certified device

             A master device identifies itself to the database in order to
             obtain information about available spectrum.  Without suitable
             protection mechanisms, devices can listen to registration
             exchanges and later register with the database by claiming the
             identity of another device.

          Threat 2: Spoofed database

             A master device attempts to discover a database (or databases)
             that it can query for available spectrum information.  An
             attacker may attempt to spoof a database and provide responses
             to a master device that are malicious and result in the master
             device causing interference to the primary user of the
             spectrum.

          Threat 3: Modifying or jamming a query request

             An attacker may modify or jam the query request sent by a
             master device to a database.  The attacker may change the
             location of the device or its capabilities (transmit power,
             antenna height, etc.), and, as a result, the database responds
             with incorrect information about available spectrum or maximum

    Mancuso, et al.               Informational                    [Page 20]

    RFC 6953             PAWS Use Cases and Requirements            May 2013

             transmit power allowed.  The result of such an attack is that
             the master device can cause interference to the primary user of
             the spectrum.  It may also result in a denial of service to the
             master device if the modified database response indicates that
             no channels are available to the master device or when a jammed
             query prevents the request from reaching the database.

          Threat 4: Modifying or jamming a query response

             An attacker may modify or jam the query response sent by the
             database to a master device.  For example, an attacker may
             modify the available spectrum or power-level information
             carried in the database response.  As a result, a master device
             may use spectrum that is not available at a location or may
             transmit at a greater power level than allowed.  Such
             unauthorized use can result in interference to the primary user
             of that spectrum.  Alternatively, an attacker may modify a
             database response to indicate that no spectrum is available at
             a location (or jam the response), resulting in a denial of
             service to the master device.

          Threat 5: Third-party tracking of white-space device location and
          identity

             A master device may provide its identity in addition to its
             location in the query request.  Such location/identity
             information can be gleaned by an eavesdropper and used for
             unauthorized tracking purposes.

          Threat 6: Malicious individual acts as a database to terminate or
          unfairly limit spectrum access of devices

             A database may include a mechanism by which service and
             spectrum allocated to a master device can be revoked by sending
             a revoke message to a master device.  A malicious user can
             pretend to be a database and send a revoke message to that
             device.  This results in denial of service to the master
             device.

       The security requirements arising from the above threats are captured
       in the requirements of Section 5.2.

    Mancuso, et al.               Informational                    [Page 21]

    RFC 6953             PAWS Use Cases and Requirements            May 2013

    7.  Acknowledgments

       The authors acknowledge Gabor Bajko, Teco Boot, Nancy Bravin, Rex
       Buddenberg, Vincent Chen, Gerald Chouinard, Stephen Farrell, Michael
       Fitch, Joel M. Halpern, Jussi Kahtava, Paul Lambert, Barry Leiba,
       Subramanian Moonesamy, Pete Resnick, Brian Rosen, Andy Sago, Peter
       Stanforth, John Stine, and Juan Carlos Zuniga for their contributions
       to this document.

    8.  References

    8.1.  Normative References

       [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

       [WGS84]    National Imagery and Mapping Agency, "Department of
                  Defense World Geodetic System 1984, Its Definition and
                  Relationships with Local Geodetic Systems", NIMA
                  TR8350.2 Third Edition Amendment 1, January 2000,
                  <http://earth-info.nga.mil/GandG/publications/tr8350.2/
                  wgs84fin.pdf>.

    8.2.  Informative References

       [CRADIO]   Cognitive Radio Technologies Proceeding (CRTP), "Federal
                  Communications Commission", ET Docket No. 03-108,
                  August 2010, <http://fcc.gov/oet/cognitiveradio>.

       [PAWS]     Chen, V., Ed., Das, S., Zhu, L., Malyar, J., and P.
                  McCann, "Protocol to Access Spectrum Database", Work
                  in Progress, May 2013.

    Mancuso, et al.               Informational                    [Page 22]

    RFC 6953             PAWS Use Cases and Requirements            May 2013

    Authors' Addresses

       Anthony Mancuso (editor)
       Google
       1600 Amphitheatre Parkway
       Mountain View, CA  94043
       US

       EMail: amancuso@google.com

       Scott Probasco

       EMail: scott@probasco.me

       Basavaraj Patil
       Cisco Systems
       2250 East President George Bush Highway
       Richardson, TX  75082
       US

       EMail: basavpat@cisco.com

    Mancuso, et al.               Informational                    [Page 23]