draft-ietf-paws-problem-stmt-usecases-rqmts-15.txt   rfc6953.txt 
PAWS A. Mancuso, Ed. Internet Engineering Task Force (IETF) A. Mancuso, Ed.
Internet-Draft Google Request for Comments: 6953 Google
Intended status: Informational S. Probasco Category: Informational S. Probasco
Expires: September 14, 2013 B. Patil ISSN: 2070-1721
March 13, 2013 B. Patil
Cisco Systems
May 2013
Protocol to Access White Space (PAWS) Database: Use Cases and Protocol to Access White-Space (PAWS) Databases:
Requirements Use Cases and Requirements
draft-ietf-paws-problem-stmt-usecases-rqmts-15
Abstract Abstract
Portions of the radio spectrum that are assigned to a particular use Portions of the radio spectrum that are assigned to a particular use
but are unused or unoccupied at specific locations and times are but are unused or unoccupied at specific locations and times are
defined as "white space." The concept of allowing additional defined as "white space". The concept of allowing additional
transmissions (which may or may not be licensed) in white space is a transmissions (which may or may not be licensed) in white space is a
technique to "unlock" existing spectrum for new use. This document technique to "unlock" existing spectrum for new use. This document
includes the problem statement for the development of a protocol to includes the problem statement for the development of a protocol to
access a database of whitespace information followed by use cases and access a database of white-space information followed by use cases
requirements for that protocol. Finally, requirements associated and requirements for that protocol. Finally, requirements associated
with the protocol are presented. with the protocol are presented.
Requirements Language Status of This Memo
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].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on September 14, 2013. 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.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 24 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Introduction to White Space . . . . . . . . . . . . . . . 3 1.1. Introduction to White Space . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 4 1.2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology Used in this Document . . . . . . . . . . . . . . 5 2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Global Applicability . . . . . . . . . . . . . . . . . . . 6 3.1. Global Applicability . . . . . . . . . . . . . . . . . . . 6
3.2. Database Discovery . . . . . . . . . . . . . . . . . . . . 7 3.2. Database Discovery . . . . . . . . . . . . . . . . . . . . 8
3.3. Device Registration . . . . . . . . . . . . . . . . . . . 8 3.3. Device Registration . . . . . . . . . . . . . . . . . . . 8
3.4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Data Model Definition . . . . . . . . . . . . . . . . . . 9 3.5. Data Model Definition . . . . . . . . . . . . . . . . . . 9
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Master-slave White Space Networks . . . . . . . . . . . . 9 4.1. Master-Slave White-Space Networks . . . . . . . . . . . . 9
4.2. Offloading: Moving Traffic to a White Space Network . . . 11 4.2. Offloading: Moving Traffic to a White-Space Network . . . 11
4.3. White Space Serving as Backhaul . . . . . . . . . . . . . 13 4.3. White Space Serving as Backhaul . . . . . . . . . . . . . 13
4.4. Rapid Network Deployment During Emergencies . . . . . . . 14 4.4. Rapid Network Deployment during Emergencies . . . . . . . 14
4.5. White Space Used for Local TV Broadcaster . . . . . . . . 15 4.5. White Space Used for Local TV Broadcaster . . . . . . . . 15
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Data Model Requirements . . . . . . . . . . . . . . . . . 16 5.1. Data Model Requirements . . . . . . . . . . . . . . . . . 16
5.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 17 5.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 17
5.3. Operational Requirements . . . . . . . . . . . . . . . . . 19 5.3. Operational Requirements . . . . . . . . . . . . . . . . . 19
5.4. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 19 5.4. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
8. Acknowledegements . . . . . . . . . . . . . . . . . . . . . . 22 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . . 22
9.2. Informational References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
1.1. Introduction to White Space 1.1. Introduction to White Space
Wireless spectrum is a commodity that is regulated by governments. Wireless spectrum is a commodity that is regulated by governments.
The spectrum is used for various purposes, which include, but are not The spectrum is used for various purposes, which include, but are not
limited to, entertainment (e.g., radio and television), communication limited to, entertainment (e.g., radio and television), communication
(e.g., telephony and Internet access), military (e.g., radars etc.), (e.g., telephony and Internet access), military (e.g., radars, etc.),
and navigation (e.g., satellite communication, GPS). Portions of the and navigation (e.g., satellite communication, GPS). Portions of the
radio spectrum that are assigned to a licensed (primary) user but are radio spectrum that are assigned to a licensed (primary) user but are
unused or unoccupied at specific locations and times are defined as unused or unoccupied at specific locations and times are defined as
"white space." The concept of allowing additional (secondary) "white space". The concept of allowing additional (secondary)
transmissions (which may or may not be licensed) in white space is a transmissions (which may or may not be licensed) in white space is a
technique to "unlock" existing spectrum for new use. technique to "unlock" existing spectrum for new use.
An obvious requirement is that these secondary transmissions do not An obvious requirement is that these secondary transmissions do not
interfere with the assigned use of the spectrum. One interesting interfere with the assigned use of the spectrum. One interesting
observation is that often, in a given physical location, the primary observation is that often, in a given physical location, the primary
user(s) may not be using the entire band assigned to them. The user(s) may not be using the entire band assigned to them. The
available spectrum for secondary transmissions would then depend on available spectrum for secondary transmissions would then depend on
the location of the secondary user. The fundamental issue is how to the location of the secondary user. The fundamental issue is how to
determine, for a specific location and specific time, if any of the determine, for a specific location and specific time, if any of the
assigned spectrum is available for secondary use. assigned spectrum is available for secondary use.
Academia and Industry have studied multiple cognitive radio [1] Academia and industry have studied multiple cognitive radio [CRADIO]
mechanisms for use in such a scenario. One simple mechanism is to mechanisms for use in such a scenario. One simple mechanism is to
use a geospatial database that contains the spatial and temporal use a geospatial database that contains the spatial and temporal
profile of all primary licensees' spectrum usage, and require profile of all primary licensees' spectrum usage, and require
secondary users to query the database for available spectrum that secondary users to query the database for available spectrum that
they can use at their location. Such databases can be accessible and they can use at their location. Such databases can be accessible and
queryable by secondary users on the Internet. queryable by secondary users on the Internet.
Any entity that is assigned spectrum that is not densely used may be 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 asked by a governmental regulatory agency to share it to allow for
more intensive use of the spectrum. Providing a mechanism by which more intensive use of the spectrum. Providing a mechanism by which
secondary users share the spectrum with the primary user is secondary users share the spectrum with the primary user is
attractive in many bands in many countries. attractive in many bands, in many countries.
This document includes the problem statement followed by use cases This document includes the problem statement followed by use cases
and requirements associated with the use of white-space spectrum by and requirements associated with the use of white-space spectrum by
secondary users via a database query protocol. The final sections secondary users via a database query protocol. The final sections
include the requirements associated with such a protocol. Note that include the requirements associated with such a protocol. Note that
the IETF has undertaken to develop a database query protocol (see the IETF has undertaken to develop a database query protocol (see
[I-D.ietf-paws-protocol]). [PAWS]).
1.2. Scope 1.2. Scope
1.2.1. In Scope 1.2.1. In Scope
This document covers the requirements for a protocol to allow a This document covers the requirements for a protocol to allow a
device to access a database to obtain spectrum availability device to access a database to obtain spectrum availability
information. Such a protocol should allow a device to perform the information. Such a protocol should allow a device to perform the
following actions: following actions:
skipping to change at page 4, line 30 skipping to change at page 4, line 30
a well-defined format for querying the database. a well-defined format for querying the database.
4. Receive in response to the query a list of available white-space 4. Receive in response to the query a list of available white-space
frequencies at the specified geolocation using a well-defined frequencies at the specified geolocation using a well-defined
format for the information. format for the information.
5. Send an acknowledgment to the database with information 5. Send an acknowledgment to the database with information
containing channels selected for use by the device and other containing channels selected for use by the device and other
device operation parameters. device operation parameters.
Note. The above protocol actions should explicitly or implicitly Note: The above protocol actions should explicitly or implicitly
support the ability of devices to re-register and/or re-query the support the ability of devices to re-register and/or re-query the
database when they change their locations or operating parameters. database when they change their locations or operating parameters.
This will allow them to receive permission to operate in their new This will allow them to receive permission to operate in their new
locations and/or with their new operating parameters, and to send locations and/or with their new operating parameters, and to send
acknowledgments to the database that include information on their new acknowledgments to the database that include information on their new
operating parameters. operating parameters.
1.2.2. Out of Scope 1.2.2. Out of Scope
The following topics are out of scope for this specification: The following topics are out of scope for this specification:
skipping to change at page 5, line 6 skipping to change at page 5, line 9
out of scope. out of scope.
2. A rogue device may operate without contacting the database to 2. A rogue device may operate without contacting the database to
obtain available spectrum. Hence, enforcement of spectrum usage obtain available spectrum. Hence, enforcement of spectrum usage
by devices is out of scope. by devices is out of scope.
3. The protocol defines communications between the database and 3. The protocol defines communications between the database and
devices. The protocol for communications between devices is out devices. The protocol for communications between devices is out
of scope. of scope.
4. Co-existence and interference avoidance of white space devices 4. Coexistence and interference avoidance of white-space devices
within the same spectrum is out of scope. within the same spectrum are out of scope.
5. Provisioning (releasing new spectrum for white space use) is out 5. Provisioning (releasing new spectrum for white-space use) is out
of scope. of scope.
2. Terminology Used in this Document 2. Conventions Used in This Document
Database A database is an entity that contains current information 2.1. Terminology
about available spectrum at a given location and time as well as
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 other types of information related to spectrum availability and
usage. usage.
Device Class Identifies classes of devices including fixed, mobile, Device Class: Identifies classes of devices including fixed, mobile,
portable, etc... May also indicate if the device is indoor or portable, etc. May also indicate if the device is indoor or
outdoor. outdoor.
Device ID An identifier for a device. Device ID: An identifier for a device.
Master Device A device that queries the database, on its own behalf Master Device: A device that queries the database, on its own behalf
and/or on behalf of a slave device, to obtain available spectrum and/or on behalf of a slave device, to obtain available spectrum
information. information.
Slave Device A device that queries the database through a master Slave Device: A device that queries the database through a master
device. device.
Trusted Database A database that is trusted by a device or provides Trusted Database: A database that is trusted by a device or provides
data objects that are trusted by a device. data objects that are trusted by a device.
White Space (WS) Radio spectrum that is available for secondary use White Space (WS): Radio spectrum that is available for secondary use
at a specific location and time. at a specific location and time.
White Space Device (WSD) A device that uses white-space spectrum as 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 a secondary user. A white-space device can be a fixed or portable
device such as an access point, base station, or cell phone. 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].
3. Problem Statement 3. Problem Statement
The use of white-space spectrum is enabled via the capability of a The use of white-space spectrum is enabled via the capability of a
device to query a database and obtain information about the device to query a database and obtain information about the
availability of spectrum for use at a given location. The databases availability of spectrum for use at a given location. The databases
are reachable via the Internet and the devices querying these are reachable via the Internet, and the devices querying these
databases are expected to have some form of Internet connectivity, databases are expected to have some form of Internet connectivity,
directly or indirectly. While databases are expected to support the directly or indirectly. While databases are expected to support the
rule set(s) of one or more regulatory domains, and the regulations rule set(s) of one or more regulatory domains, and the regulations
and available spectrum associated with each rule set may vary, the and available spectrum associated with each rule set may vary, the
fundamental operation of the protocol must be independent of any fundamental operation of the protocol must be independent of any
particular regulatory environment. particular regulatory environment.
An example high-level architecture of the devices and databases is An example of the high-level architecture of the devices and
shown in Figure 1. databases is shown in Figure 1.
----------- -----------
| Master | | Master |
|WS Device| ------------ |WS Device| ------------
|Lat: X |\ .---. /--------|Database A| |Lat: X |\ .---. /--------|Database A|
|Long: Y | \ ( ) / ------------ |Long: Y | \ ( ) / ------------
----------- \-------/ \/ o ----------- \-------/ \/ o
( Internet) o ( Internet) o
----------- /------( )\ o ----------- /------( )\ o
| Master | / ( ) \ o | Master | / ( ) \ o
|WS Device|/ (_____) \ ------------ |WS Device|/ (_____) \ ------------
|Lat: X | \------|Database B| |Lat: X | \------|Database B|
|Long: Y | ------------ |Long: Y | ------------
----------- -----------
Figure 1: High-level View of White Space Database Architecture Figure 1: High-Level View of White-Space Database Architecture
Note that there could be multiple databases serving white space Note that there could be multiple databases serving white-space
devices. In some countries, such as the U.S., the regulator has devices. In some countries, such as the U.S., the regulator has
determined that multiple databases may provide service to White Space determined that multiple databases may provide service to white-space
Devices. devices.
A messaging interface between the white space devices and the A messaging interface between the white-space devices and the
database is required for operating a network using the white-space database is required for operating a network using the white-space
spectrum. The following sections discuss various aspects of such an spectrum. The following sections discuss various aspects of such an
interface and the need for a standard. interface and the need for a standard.
3.1. Global Applicability 3.1. Global Applicability
The use of white-space spectrum is currently approved or being The use of white-space spectrum is currently approved or being
considered in multiple regulatory domains, whose rules may differ. considered in multiple regulatory domains, whose rules may differ.
However, the need for devices that intend to use the spectrum to However, the need for devices that intend to use the spectrum to
communicate with a database remains a common feature. The database communicate with a database remains a common feature. The database
implements rules that protect all primary users, independent of the implements rules that protect all primary users, independent of the
characteristics of the white space devices. It also provides a way characteristics of the white-space devices. It also provides a way
to specify a schedule of use, since some primary users (for example, to specify a schedule of use, since some primary users (for example,
wireless microphones) only operate in limited time slots. wireless microphones) only operate in limited time slots.
Devices need to be able to query a database, directly or indirectly, Devices need to be able to query a database, directly or indirectly,
over the public Internet and/or private IP networks prior to over the public Internet and/or private IP networks prior to
operating in available spectrum. Information about available operating in available spectrum. Information about available
spectrum, schedule, power, etc., are provided by the database as a spectrum, schedule, power, etc., are provided by the database as a
response to the query from a device. The messaging interface needs response to the query from a device. The messaging interface needs
to be: to be:
1. Interface agnostic - An interface between a master white space 1. Interface agnostic - An interface between a master white-space
device and database can be wired or unwired (e.g., a radio/air 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 interface technology such as IEEE 802.11af, IEEE 802.15.4m, IEEE
802.16, IEEE 802.22, LTE etc.) However, the messaging interface 802.16, IEEE 802.22, LTE, etc.) However, the messaging interface
between a master white space device and the database should be between a master white-space device and the database should be
agnostic to the interface used for such messaging while being agnostic to the interface used for such messaging while being
cognizant of the characteristics of the interface technology and cognizant of the characteristics of the interface technology and
the need to include any relevant attributes in the query to the the need to include any relevant attributes in the query to the
database. database.
2. Spectrum agnostic - the spectrum used by primary and secondary 2. Spectrum agnostic - The spectrum used by primary and secondary
users varies by country. Some spectrum has an explicit notion of users varies by country. Some spectrum bands have an explicit
a "channel": a defined swath of spectrum within a band that has notion of a "channel": a defined swath of spectrum within a band
some assigned identifier. Other spectrum bands may be subject to that has some assigned identifier. Other spectrum bands may be
white space sharing, but only have actual frequency low/high subject to white-space sharing, but only have actual frequency
parameters to define primary and secondary use. The protocol low/high parameters to define primary and secondary use. The
should be able to be used in any spectrum band where white space protocol should be able to be used in any spectrum band where
sharing is permitted. white-space sharing is permitted.
3. Globally applicable - A common messaging interface between white 3. Globally applicable - A common messaging interface between white-
space devices and databases will enable the use of such spectrum space devices and databases will enable the use of such spectrum
for various purposes on a global basis. Devices can operate in for various purposes on a global basis. Devices can operate in
any location where such spectrum is available and a common any location where such spectrum is available and a common
interface ensures uniformity in implementations and deployment. interface ensures uniformity in implementations and deployment.
To allow the global use of white space devices in different To allow the global use of white-space devices in different
countries (whatever the regulatory domain), the protocol should countries (whatever the regulatory domain), the protocol should
support the database communicating applicable regulatory rule set support the database that communicates the applicable regulatory
information to the white space device. rule-set information to the white-space device.
4. Flexible and extensible data structures - Different databases are 4. Built on flexible and extensible data structures - Different
likely to have different requirements for the kinds of data databases are likely to have different requirements for the kinds
required for registration (different regulatory rule sets that of data required for registration (different regulatory rule sets
apply to the registration of devices) and other messages sent by that apply to the registration of devices) and other messages
the device to the database. For instance, different regulators sent by the device to the database. For instance, different
might require different device-characteristic information to be regulators might require different device-characteristic
passed to the database. information to be passed to the database.
3.2. Database Discovery 3.2. Database Discovery
The master device must obtain the address of a trusted database, The master device must obtain the address of a trusted database,
which it will query for available white-space spectrum. If the which it will query for available white-space spectrum. If the
master device uses a discovery service to locate a trusted database, master device uses a discovery service to locate a trusted database,
it may perform the following steps (this description is intended as it may perform the following steps (this description is intended as
descriptive, not prescriptive): descriptive, not prescriptive):
1. The master device constructs and sends a request (e.g., over the 1. The master device constructs and sends a request (e.g., over the
Internet) to a trusted discovery service. Internet) to a trusted discovery service.
2. If no acceptable response is received within a pre-configured 2. If no acceptable response is received within a pre-configured
time limit, the master device concludes that no trusted database time limit, the master device concludes that no trusted database
is available. If at least one response is received, the master is available. If at least one response is received, the master
device evaluates the response(s) to determine if a trusted device evaluates the response(s) to determine if a trusted
database can be identified where the master device is able to database can be identified where the master device is able to
receive service from the database. If so, it establishes contact receive service from the database. If so, it establishes contact
with the trusted database. with the trusted database.
3. The master device establishes a white space network as described 3. The master device establishes a white-space network as described
in Section 4. in Section 4.
Optionally, and in place of steps 1-2 above, the master device can be 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 pre-configured with the address (e.g., URI) of one or more trusted
databases. The master device can establish contact with one of these databases. The master device can establish contact with one of these
trusted databases. trusted databases.
3.3. Device Registration 3.3. Device Registration
The master device may register with the database before it queries The master device may register with the database before it queries
the database for available spectrum. A registration process may the database for available spectrum. A registration process may
consist of the following steps: consist of the following steps:
1. The master device sends registration information to the database. 1. The master device sends registration information to the database.
This information may include the Device ID, serial number This information may include the device ID; serial number
assigned by the manufacturer, device location, device antenna assigned by the manufacturer; device location; device antenna
height above ground, name of the individual or business that owns height above ground; name of the individual or business that owns
the device, and the name, street and email address, and telephone the device; and the name, postal address, email address, and
number of a contact person responsible for the device's phone number of a contact person responsible for the device's
operation. operation.
2. The database responds to the registration request with an 2. The database responds to the registration request with an
acknowledgement to indicate the success of the registration acknowledgment to indicate the success of the registration
request or with an error if the registration was unsuccessful. request or with an error if the registration was unsuccessful.
Additional information may be provided by the database in its Additional information may be provided by the database in its
response to the master device. response to the master device.
3.4. Protocol 3.4. Protocol
A protocol that enables a white space device to query a database to A protocol that enables a white-space device to query a database to
obtain information about available spectrum is needed. A device may obtain information about available spectrum is needed. A device may
be required to register with the database with some credentials prior be required to register with the database with some credentials prior
to being allowed to query. The requirements for such a protocol are to being allowed to query. The requirements for such a protocol are
specified in this document. specified in this document.
3.5. Data Model Definition 3.5. Data Model Definition
The contents of the queries and response need to be specified. A The contents of the queries and response need to be specified. A
data model is required which enables the white space device to query data model is required; it must enable the white-space device to
the database while including all the relevant information such as query the database while including all the relevant information, such
geolocation, radio technology, power characteristics, etc., which may as geolocation, radio technology, power characteristics, etc., which
be country and spectrum and regulatory dependent. All databases are may be country, spectrum, and regulatory dependent. All databases
able to interpret the data model and respond to the queries using the are able to interpret the data model and respond to the queries using
same data model that is understood by all devices. the same data model that is understood by all devices.
4. Use Cases 4. Use Cases
There are many potential use cases for white-space spectrum - for There are many potential use cases for white-space spectrum -- for
example, providing broadband Internet access in urban and densely- example, providing broadband Internet access in urban and densely
populated hotspots as well as rural and remote, underserved areas. populated hotspots, as well as rural and remote, underserved areas.
Available white-space spectrum may also be used to provide Internet Available white-space spectrum may also be used to provide Internet
'backhaul' for traditional Wi-Fi hotspots or for use by towns and 'backhaul' for traditional Wi-Fi hotspots or for use by towns and
cities to monitor/control traffic lights, read utility meters, and cities to monitor/control traffic lights, read utility meters, and
the like. Still other use cases include the ability to offload data the like. Still other use cases include the ability to offload data
traffic from another Internet access network (e.g., 3G cellular traffic from another Internet access network (e.g., 3G cellular
network) or to deliver data, information, or a service to a user 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 based on the user's location. Some of these use cases are described
in the following sections. in the following sections.
4.1. Master-slave White Space Networks 4.1. Master-Slave White-Space Networks
There are a number of common scenarios in which a master white space 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 device will act as proxy or mediator for one or more slave devices
using its connection to the Internet to query the database for using its connection to the Internet to query the database for
available spectrum for itself and for one or more slave devices. available spectrum for itself and for one or more slave devices.
These slave devices may be fixed or mobile, in close proximity with These slave devices may be fixed or mobile, in close proximity with
each other (indoor network or urban hotspot), or at a distance (rural each other (indoor network or urban hotspot), or at a distance (rural
or remote WAN). Once slave devices switch to white-space spectrum or remote WAN). Once slave devices switch to white-space spectrum
for their communications, they may connect through the master to the for their communications, they may connect through the master to the
Internet or use white-space spectrum for intra-network communications Internet or use white-space spectrum for intra-network communications
only. The master device can continue to arbitrate and control white only. The master device can continue to arbitrate and control white-
space communications by slave devices, and may notify them when they space communications by slave devices, and it may notify them when
are required to change white-space frequencies or cease white space they are required to change white-space frequencies or cease white-
communications. space communications.
Figure 2 depicts the general architecture of such a simple master- Figure 2 depicts the general architecture of such a simple master-
slave network, in which the master device communicates on its own slave network in which the master device communicates with a database
behalf and on behalf of slave devices with a database. on its own behalf and on behalf of slave devices.
-------- --------
|Slave | |Slave |
|Device| \ \|/ ---------- |Device| \ \|/ ----------
| 1 | (Air) | |Database| | 1 | (Air) | |Database|
-------- \ | (----) /|--------| -------- \ | (----) /|--------|
| \ ------|------ ( ) / | \ ------|------ ( ) /
| \| Master | / \ | \| Master | / \
-------- /| |======= ( Internet ) -------- /| |======= ( Internet )
|Slave | / | Device | \ / |Slave | / | Device | \ /
|Device| (Air) | | ( ) |Device| (Air) | | ( )
| 2 | / |-----------| (----) | 2 | / |-----------| (----)
|------- / -------- /
o | / o | /
o | (Air) o | (Air)
o | / o | /
-------- / -------- /
|Slave | / |Slave | /
|Device| / |Device| /
| n | | n |
-------- --------
Figure 2: Master-Slave White Space Network Figure 2: Master-Slave White-Space Network
The protocol requirements for these master-slave device and other The protocol requirements for these master-slave devices and other
similar scenarios is essentially the same: the protocol must support similar scenarios is essentially the same: the protocol must support
the ability of a master device to make available-spectrum query the ability of a master device to make available-spectrum query
requests on behalf of slave devices, passing device identification, requests on behalf of slave devices, passing device identification,
geolocation, and other slave device parameters to the database as geolocation, and other slave device parameters to the database as
required to obtain a list of white-space spectrum available for use required to obtain a list of white-space spectrum available for use
by one or more slave devices. Of course, different use cases will by one or more slave devices. Of course, different use cases will
use this spectrum information in different ways, and the details of use this spectrum information in different ways, and the details of
master/slave communications may be different for different use cases. master/slave communications may be different for different use cases.
Common steps may occur in master-slave networks include the Common steps that may occur in master-slave networks include the
following: following:
1. The master device powers up. 1. The master device powers up.
2. Slave devices may power up and associate with the master device 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. via Wi-Fi or some other over-the-air, non-white-space spectrum.
Until the slave device is allocated white-space spectrum, any Until the slave device is allocated white-space spectrum, any
master-slave or slave-slave communications occurs over such non- master-slave or slave-slave communications occurs over such non-
white-space spectrum. white-space spectrum.
3. The master has Internet connectivity, determines (or knows) its 3. The master has Internet connectivity, determines (or knows) its
location, and establishes a connection to a trusted database (see location, and establishes a connection to a trusted database (see
Section 3.2). Section 3.2).
4. The master may register with the trusted database (see 4. The master may register with the trusted database (see
Section 3.3). Section 3.3).
5. The master sends a query to the trusted database requesting a 5. The master sends a query to the trusted database requesting a
list of available white-space spectrum based upon its list of available white-space spectrum based upon its
geolocation. Query parameters may include the master's location, geolocation. Query parameters may include the master's location,
device identifier, and antenna height. The master may send device identifier, and antenna height. The master may send
available-spectrum requests to the database on behalf of slave available-spectrum requests to the database on behalf of slave
devices. devices.
6. The database responds to the master's query with a list of 6. The database responds to the master's query with a list of
available white-space spectrum, associated maximum power levels, available white-space spectrum, associated maximum power levels,
and a durations of time for spectrum use. If the master made and durations of time for spectrum use. If the master made
requests on behalf of slave devices, the master may transmit the requests on behalf of slave devices, the master may transmit the
obtained available-spectrum lists to the slaves (or the master obtained available-spectrum lists to the slaves (or the master
may allocate spectrum to slaves from the obtained spectrum may allocate spectrum to slaves from the obtained spectrum
lists). lists).
7. The master may inform the database of the spectrum and power 7. The master may inform the database of the spectrum and power
level it selects from the available spectrum list. If a slave level it selects from the available spectrum list. If a slave
device has been allocated available white-space spectrum, the device has been allocated available white-space spectrum, the
slave may inform the master of the spectrum and power level it slave may inform the master of the spectrum and power level it
has chosen, and the master may, in turn, relay such slave device has chosen, and the master may, in turn, relay such slave device
usage to the database. usage to the database.
8. Further communication among masters and slaves over the white 8. Further communication among masters and slaves over the white-
space network may occur via the selected/allocated white-space space network may occur via the selected/allocated white-space
spectrum frequencies. spectrum frequencies.
Note: Steps 5 through 7 may be repeated by the master device when it 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 (or a slave device that uses the master as a proxy to communicate
with the database) changes its location or operating parameters -- with the database) changes its location or operating parameters --
for example, after a master changes location, it may query the for example, after a master changes location, it may query the
database for available spectrum at its new location, then acknowledge database for available spectrum at its new location, then acknowledge
the subsequent response received from the database with information the subsequent response received from the database with information
on the spectrum and power levels it is using at the new location. on the spectrum and power levels it is using at the new location.
4.2. Offloading: Moving Traffic to a White Space Network 4.2. Offloading: Moving Traffic to a White-Space Network
This scenario is a variant of the master-slave network described in This scenario is a variant of the master-slave network described in
the previous use case. In this scenario, an access point (AP) offers the previous use case. In this scenario, an access point (AP) offers
a white space service that offloads Internet traffic as an a white-space service that offloads Internet traffic as an
alternative datapath to a more congested or costly Internet wire, alternative data path to a more congested or costly Internet wire,
wireless, or satellite service. wireless, or satellite service.
Figure 3 shows an example deployment of this scenario. Figure 3 shows an example of deployment of this scenario.
\|/ \|/
| |
|--|----------| |--|----------|
\|/ /|Access Point |\ \|/ /|Access Point |\
| (Air)--/ |-------------| \ | (Air)--/ |-------------| \
--|------ / \ ----------- --|------ / \ -----------
|Portable|/ \ (----) | Database| |Portable|/ \ (----) | Database|
| Device | \ ( ) /---------- | Device | \ ( ) /----------
|--------|\ \ / \ |--------|\ \ / \
\ X( Internet ) \ X( Internet )
\ / \ / \ / \ /
(Air) / ( ) (Air) / ( )
\ / (----) \ / (----)
\ / \ /
\|---------------|/ \|---------------|/
| Metered | | Metered |
| Service | | Service |
|---------------| |---------------|
Figure 3: Offloading Traffic to a White Space Network Figure 3: Offloading Traffic to a White-Space Network
A simplified operation scenario of offloading content, such as video A simplified operation scenario of offloading content, such as video
stream, from a congested or costly Internet connection to a white stream, from a congested or costly Internet connection to a white-
space service provided by an AP consists of the following steps: space service provided by an AP consists of the following steps:
1. The AP contacts the database to determine channels it can use. 1. The AP contacts the database to determine channels it can use.
2. The portable device connects to a paid Internet service and 2. The portable device connects to a paid Internet service and
selects a video for streaming. selects a video for streaming.
3. The portable device determines if it can offload to a white space 3. The portable device determines if it can offload to a white-space
access point: AP:
A. If the portable device knows its location, it A. If the portable device knows its location, it
1. asks the database (using the paid service) for available 1. asks the database (using the paid service) for available
white-space spectrum; white-space spectrum;
2. listens for and connects to the AP over the permitted 2. listens for and connects to the AP over the permitted
white-space spectrum. white-space spectrum.
B. If the portable device does not have GPS or other means to B. If the portable device does not have GPS or other means to
skipping to change at page 13, line 17 skipping to change at page 13, line 17
3. uses the permitted white-space spectrum to connect to the 3. uses the permitted white-space spectrum to connect to the
AP. AP.
4. The portable device accesses the Internet through the AP to 4. The portable device accesses the Internet through the AP to
stream the selected video. stream the selected video.
4.3. White Space Serving as Backhaul 4.3. White Space Serving as Backhaul
In this use case, an Internet connectivity service is provided to In this use case, an Internet connectivity service is provided to
users over a common wireless standard, such as Wi-Fi, with a white users over a common wireless standard, such as Wi-Fi, with a white-
space master/slave network providing backhaul connectivity to the space master/slave network providing backhaul connectivity to the
Internet. Note that Wi-Fi is referenced in Figure 4 and the Internet. Note that Wi-Fi is referenced in Figure 4 and the
following discussion, but any other technology can be substituted in following discussion, but any other technology can be substituted in
its place. its place.
Figure 4 shows an example deployment of this scenario. Figure 4 shows an example of deployment of this scenario.
\|/ White \|/ \|/ Wi-Fi \|/ \|/ White \|/ \|/ Wi-Fi \|/
| Space | | | | Space | | |
| | | |-|----| | | | |-|----|
(----) |-|----| |-|------|-| | Wi-Fi| (----) |-|----| |-|------|-| | Wi-Fi|
( ) |Master| | Slave |--(Air)--| Dev | ( ) |Master| | Slave |--(Air)--| Dev |
/ \ | |--(Air)--| Bridge | |------| / \ | |--(Air)--| Bridge | |------|
( Internet )---| | | to Wi-Fi | ( Internet )---| | | to Wi-Fi |
\ / |------| |----------| \|/ \ / |------| |----------| \|/
( ) \ | ( ) \ |
(----) \(Air) |-|----| (----) \(Air) |-|----|
\--| Wi-Fi| \--| Wi-Fi|
| Dev | | Dev |
|------| |------|
Figure 4: White Space Network Used for Backhaul Figure 4: White-Space Network Used for Backhaul
Once the bridged device (WS + Wi-Fi) is connected to a master and WS Once the bridged device (Slave Bridge + Wi-Fi) is connected to a
network, a simplified operation scenario of backhaul for Wi-Fi master and WS network, a simplified operation scenario of backhaul
consists of the following steps: for Wi-Fi consists of the following steps:
1. A bridged slave device (WS + Wi-Fi) is connected to a master 1. A bridged slave device (Slave Bridge + Wi-Fi) is connected to a
device operating in the WS spectrum (the master obtains available master device operating in the WS spectrum (the master obtains
white-space spectrum as described in Section 4.1). available white-space spectrum as described in Section 4.1).
2. Once the slave device is connected to the master, the Wi-Fi 2. Once the slave device is connected to the master, the Wi-Fi
access point has Internet connectivity as well. access point has Internet connectivity as well.
3. End users attach to the Wi-Fi network via their Wi-Fi enabled 3. End users attach to the Wi-Fi network via their Wi-Fi-enabled
devices and receive Internet connectivity. devices and receive Internet connectivity.
4.4. Rapid Network Deployment During Emergencies 4.4. Rapid Network Deployment during Emergencies
Organizations involved in handling emergency operations maintain an Organizations involved in handling emergency operations maintain an
infrastructure that relies on dedicated spectrum for their infrastructure that relies on dedicated spectrum for their
operations. However, such infrastructures are often affected by the operations. However, such infrastructures are often affected by the
disasters they handle. To set up a replacement network, spectrum disasters they handle. To set up a replacement network, spectrum
needs to be quickly cleared and reallocated to the crisis response needs to be quickly cleared and reallocated to the crisis response
organization. Automation of the this allocation and assignment is organization. Automation of this allocation and assignment is often
often the best solution. A preferred option is to make use of a the best solution. A preferred option is to make use of a robust
robust protocol that has been adopted and implemented by radio protocol that has been adopted and implemented by radio
manufacturers. A typical network topology solution might include manufacturers. A typical network topology solution might include
wireless access links to the public Internet or private network, wireless access links to the public Internet or private network,
wireless ad-hoc network radios working independent of a fixed wireless ad hoc network radios working independently of a fixed
infrastructure, and satellite links for backup where lack of infrastructure, and satellite links for backup where lack of
coverage, overload, or outage of wireless access links can occur. coverage, overload, or outage of wireless access links can occur.
Figure 5 shows an example deployment of this scenario. Figure 5 shows an example of deployment of this scenario.
\|/ \|/
| ad hoc | ad hoc
| |
|-|-------------| |-|-------------|
| Master node | |------------| | Master node | |-------------|
\|/ | with | | Whitespace | \|/ | with | | White-Space |
| ad hoc /| backhaul link | | Database | | ad hoc /| backhaul link | | Database |
| /---/ |---------------| |------------| | /---/ |---------------| |-------------|
---|------------/ | \ / ---|------------/ | \ /
| Master node | | | (--/--) | Master node | | | (--/--)
| without | | -----( ) | without | | -----( )
| backhaul link | | Wireless / Private \ | backhaul link | | Wireless / Private \
----------------\ | Access ( net or ) ----------------\ | Access ( net or )
\ | \ Internet ) \ | \ Internet )
\ \|/ | ------( / \ \|/ | ------( /
\ | ad hoc | | (------) \ | ad hoc | | (------)
\ | | / \ \ | | / \
\--|------------- /Satellite ---------- \--|------------- /Satellite ----------
| Master node | / Link | Other | | Master node | / Link | Other |
| with |/ | nodes | | with |/ | nodes |
| backhaul link | ---------- | backhaul link | ----------
----------------- -----------------
Figure 5: Rapid-deployed Network with Partly-connected Nodes Figure 5: Rapidly Deployed Network with Partly Connected Nodes
In the ad-hoc network, all nodes are master nodes that allocate RF In the ad hoc network, all nodes are master nodes that allocate radio
channels from the database (as described in Section 4.1). However, frequency (RF) channels from the database (as described in
the backhaul link may not be available to all nodes, such as depicted Section 4.1). However, the backhaul link may not be available to all
for the left node in the above figure. To handle RF channel nodes, such as depicted for the left node in the above figure. To
allocation for such nodes, a master node with a backhaul link relays handle RF channel allocation for such nodes, a master node with a
or proxies the database query for them. So master nodes without a backhaul link relays or proxies the database query for them. So
backhaul link follow the procedure as defined for clients. The ad- master nodes without a backhaul link follow the procedure as defined
hoc network radios utilize the provided RF channels. Details on for clients. The ad hoc network radios utilize the provided RF
forming and maintenance of the ad-hoc network, including repair of channels. Details on forming and maintenance of the ad hoc network,
segmented networks caused by segments operating on different RF including repair of segmented networks caused by segments operating
channels, is out of scope of spectrum allocation. on different RF channels, is out of scope of spectrum allocation.
4.5. White Space Used for Local TV Broadcaster 4.5. White Space Used for Local TV Broadcaster
Available white-space spectrum can be deployed in novel ways to Available white-space spectrum can be deployed in novel ways to
leverage the public use of hand-held and portable devices. One such leverage the public use of hand-held and portable devices. One such
use is white-space spectrum used for local TV transmission of audio- use is white-space spectrum used for local TV transmission of audio-
video content to portable devices used by individuals in attendance video content to portable devices used by individuals in attendance
at an event. In this use case, audience members at a seminar, at an event. In this use case, audience members at a seminar,
entertainment event, or other venue plug a miniature TV receiver fob entertainment event, or other venue plug a miniature TV receiver fob
into their laptop, computer tablet, cell phone, or other portable into their laptop, computer tablet, cell phone, or other portable
device. A master device obtains a list of available white-space device. A master device obtains a list of available white-space
spectrum (as described in , (Section 4.1), then broadcasts audio- spectrum (as described in Section 4.1), then broadcasts audio-video
video content locally to the audience over one of the available content locally to the audience over one of the available
frequencies. Audience members receive the content through their frequencies. Audience members receive the content through their
miniature TV receivers tuned to the appropriate white space band for miniature TV receivers tuned to the appropriate white-space band for
display on their portable device monitors. display on the monitors of their portable devices.
Figure 6 shows an example deployment of this scenario. Figure 6 shows an example of deployment of this scenario.
|------------| |------------|
|White Space | |White-Space |
| Database | | Database |
.---. / |------------| .---. / |------------|
|-----------| ( ) / |-----------| ( ) /
| Master | / \ | Master | / \
| |========( Internet) | |========( Internet)
|-----------| \ / |-----------| \ /
| ( ) | ( )
/|\ (---) /|\ (---)
(White Space (White-Space
Broadcast) Broadcast)
\|/ \|/ \|/ \|/ \|/ \|/ \|/ \|/ \|/ \|/ \|/ \|/ \|/ \|/
| | | | | | | ................. | | | | | | | .................
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
USB TV receivers connected to laptops, cellphone, tablets .... USB TV receivers connected to laptops, cell phones, tablets ...
Figure 6: White Space Used for Local TV Broadcast Figure 6: White Space Used for Local TV Broadcast
5. Requirements 5. Requirements
5.1. Data Model Requirements 5.1. Data Model Requirements
D.1 The Data Model MUST support specifying the geolocation of the D.1 The data model MUST support specifying the geolocation of the
white-space device, the uncertainty in meters, the height & its white-space device, the uncertainty in meters, the height and
uncertainty, and confidence in percentage of the location its uncertainty, and the percentage of confidence in the
determination. The Data Model MUST support [WGS84]. location determination. The data model MUST support [WGS84].
D.2 The Data Model MUST support specifying the data and other D.2 The data model MUST support specifying the data and other
applicable requirements of the rule set that applies to the applicable requirements of the rule set that applies to the
white space device at a specified location. white-space device at a specified location.
D.3 The Data Model MUST support device description data that D.3 The data model MUST support device description data that
identifies a white-space device (serial number, certification identifies a white-space device (serial number, certification
IDs, etc.) and describes device characteristics, such as device IDs, etc.) and describes device characteristics, such as device
class (fixed, mobile, portable, indoor, outdoor, etc.), Radio class (fixed, mobile, portable, indoor, outdoor, etc.), Radio
Access Technology (RAT), etc. Access Technology (RAT), etc.
D.4 The Data Model MUST support specifying a manufacturer's D.4 The data model MUST support specifying a manufacturer's serial
serial number for a white-space device. number for a white-space device.
D.5 The Data Model MUST support specifying the antenna and D.5 The data model MUST support specifying the antenna- and
radiation related parameters of the white-space device, such radiation-related parameters of the white-space device, such as:
as:
antenna height antenna height
antenna gain antenna gain
maximum output power, EIRP (dBm) maximum output power, Equivalent Isotropic Radiated Power
(EIRP) in dBm (decibels referenced to 1 milliwatt)
antenna radiation pattern (directional dependence of the antenna radiation pattern (directional dependence of the
strength of the radio signal from the antenna) strength of the radio signal from the antenna)
spectrum mask with lowest and highest possible frequency spectrum mask with lowest and highest possible frequency
spectrum mask in dBr from peak transmit power in EIRP, with spectrum mask in dBr (decibels referenced to an arbitrary
specific power limit at any frequency linearly interpolated reference level) from peak transmit power in EIRP, with
between adjacent points of the spectrum mask specific power limit at any frequency linearly interpolated
between adjacent points of the spectrum mask
measurement resolution bandwidth for EIRP measurements measurement resolution bandwidth for EIRP measurements
D.6 The Data Model MUST support specifying owner and operator D.6 The data model MUST support specifying owner and operator
contact information for a transmitter. This includes the name contact information for a transmitter. This includes the name
of the transmitter owner, name of transmitter operator, postal of the transmitter owner and the name, postal address, email
address, email address and phone number of the transmitter address, and phone number of the transmitter operator.
operator.
D.7 The Data Model MUST support specifying spectrum availability. D.7 The data model MUST support specifying spectrum availability.
Spectrum units are specified by low and high frequencies and Spectrum units are specified by low and high frequencies and may
may have an optional channel identifier. The Data Model MUST have an optional channel identifier. The data model MUST
support a schedule including start time and stop time for support a schedule including start time and stop time for
spectrum unit availability. The Data Model MUST support spectrum unit availability. The data model MUST support maximum
maximum power level for each spectrum unit. power level for each spectrum unit.
D.8 The Data Model MUST support specifying spectrum availability D.8 The data model MUST support specifying spectrum availability
information for a single location and an area (e.g., a polygon information for a single location and an area (e.g., a polygon
defined by multiple location points or a geometric shape such defined by multiple location points or a geometric shape such as
as a circle). a circle).
D.9 The Data Model MUST support specifying the frequencies and D.9 The data model MUST support specifying the frequencies and power
power levels selected for use by a white-space device in the levels selected for use by a white-space device in the
acknowledgement message. acknowledgment message.
5.2. Protocol Requirements 5.2. Protocol Requirements
P.1 The master device identifies a database to which it can P.1 The master device identifies a database to which it can
register, make spectrum availability requests, etc. The protocol register, make spectrum availability requests, etc. The
MUST support the discovery of an appropriate database given a protocol MUST support the discovery of an appropriate database
location provided by the master device. The master device MAY given a location provided by the master device. The master
select a database by discovery at run time or by means of a pre- device MAY select a database by discovery at run time or by
programmed URI. The master device MAY validate discovered or means of a pre-programmed URI. The master device MAY validate
configured database addresses against a list of known databases discovered or configured database addresses against a list of
(e.g., a list of databases approved by a regulatory body). 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 P.2 The protocol MUST support the database informing the master of
the regulatory rules (rule set) that applies to the master device the regulatory rules (rule set) that applies to the master
(or any slave devices on whose behalf the master is contacting the device (or any slave devices on whose behalf the master is
database) at a specified location. contacting the database) at a specified location.
P.3 The protocol MUST provide the ability for the database to P.3 The protocol MUST provide the ability for the database to
authenticate the master device. authenticate the master device.
P.4 The protocol MUST provide the ability for the master device to P.4 The protocol MUST provide the ability for the master device to
verify the authenticity of the database with which it is verify the authenticity of the database with which it is
interacting. interacting.
P.5 The messages sent by the master device to the database and the 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 messages sent by the database to the master device MUST support
integrity protection. integrity protection.
P.6 The protocol MUST provide the capability for messages sent by P.6 The protocol MUST provide the capability for messages sent by
the master device and database to be encrypted. the master device and database to be encrypted.
P.7 Tracking of master or slave device uses of white space spectrum P.7 Tracking of master or slave device uses of white-space spectrum
by database administrators, regulatory agencies, and others who by database administrators, regulatory agencies, and others who
have access to white space database could be considered invasive have access to a white-space database could be considered
of privacy, including of privacy regulations in specific invasive of privacy, including privacy regulations in specific
environments. The PAWS protocol SHOULD support privacy-sensitive environments. The PAWS protocol SHOULD support privacy-
handling of device-provided data where such protection is sensitive handling of device-provided data where such
feasible, allowed, and desired. protection is feasible, allowed, and desired.
P.8 The protocol MUST support the master device registering with the P.8 The protocol MUST support the master device registering with
database (see Device Registration (Section 3.3)). the database; see Device Registration (Section 3.3).
P.9 The protocol MUST support a registration acknowledgement P.9 The protocol MUST support a registration acknowledgment
indicating the success or failure of the master device indicating the success or failure of the master device
registration. registration.
P.10 The protocol MUST support an available spectrum request from P.10 The protocol MUST support an available spectrum request from
the master device to the database, which may include one or more the master device to the database, which may include one or
of the data items listed in Data Model Requirements (Section 5.1). more of the data items listed in Data Model Requirements
The request may include data that the master device sends on its (Section 5.1). The request may include data that the master
own behalf and/or on behalf of one or more slave devices. 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 P.11 The protocol MUST support an available spectrum response from
the database to the master device, which may include one or more the database to the master device, which may include one or
of the data items listed in Data Model Requirements (Section 5.1). more of the data items listed in Data Model Requirements
The response may include data related to master and/or slave (Section 5.1). The response may include data related to master
device operation. and/or slave device operation.
P.12 The protocol MUST support a spectrum usage message from the P.12 The protocol MUST support a spectrum usage message from the
master device to the database, which may include one or more of master device to the database, which may include one or more of
the data items listed in Data Model Requirements (Section 5.1). the data items listed in Data Model Requirements (Section 5.1).
The message may include data that the master device sends on its The message may include data that the master device sends on
own behalf and/or on behalf of one or more slave devices. its own behalf and/or on behalf of one or more slave devices.
P.13 The protocol MUST support a spectrum usage message P.13 The protocol MUST support a spectrum usage message
acknowledgement. acknowledgment.
P.14 The protocol MUST support a validation request from the master P.14 The protocol MUST support a validation request from the master
device to the database to validate a slave device, which should device to the database to validate a slave device, which should
include information necessary to identify the slave device to the include information necessary to identify the slave device to
database. the database.
P.15 The protocol MUST support a validation response from the P.15 The protocol MUST support a validation response from the
database to the master to indicate if the slave device is database to the master to indicate if the slave device is
validated by the database. The validation response MUST indicate validated by the database. The validation response MUST
the success or failure of the validation request. indicate the success or failure of the validation request.
P.16 The protocol MUST support the capability for the database to P.16 The protocol MUST support the capability for the database to
inform master devices of changes to spectrum availability inform master devices of changes to spectrum availability
information. information.
5.3. Operational Requirements 5.3. Operational Requirements
This section contains operational requirements of a database-device This section contains operational requirements of a database-device
system, independent of the requirements of the protocol for system, independent of the requirements of the protocol for
communication between the database and devices. communication between the database and devices.
O.1 The master device must be able to connect to the database to O.1 The master device must be able to connect to the database to
send requests to the database and receive responses to, and send requests to the database and receive responses to, and
acknowledgements of, its requests from the database. acknowledgments of, its requests from the database.
O.2 A master device MUST be able to determine its location including O.2 A master device MUST be able to determine its location including
uncertainty and confidence level. A fixed master device may use a uncertainty and confidence level. A fixed master device may use
location programmed at installation. a location programmed at installation.
O.3 The master device MUST be configured to understand and comply O.3 The master device MUST be configured to understand and comply
with the requirements of the rule set of the regulatory body that with the requirements of the rule set of the regulatory body
apply to its operation at its location. that apply to its operation at its location.
O.4 A master device MUST query the database for the available O.4 A master device MUST query the database for the available
spectrum at a specified location before starting radio spectrum at a specified location before starting radio
transmission in white space at that location. transmission in white space at that location.
O.5 A master device MUST be able to query the database for the 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 available spectrum on behalf of a slave device at a specified
location before the slave device starts radio transmission in location before the slave device starts radio transmission in
white space at that location. white space at that location.
O.6 The database MUST respond to an available spectrum request. O.6 The database MUST respond to an available spectrum request.
5.4. Guidelines 5.4. Guidelines
White space technology itself is expected to evolve and include White-space technology itself is expected to evolve and include
attributes such as co-existence and interference avoidance, spectrum attributes such as coexistence and interference avoidance, spectrum
brokering, alternative spectrum bands, etc. The design of the data brokering, alternative spectrum bands, etc. The design of the data
model and protocol should be cognizant of the evolving nature of model and protocol should be cognizant of the evolving nature of
white space technology and consider the following set of guidelines white-space technology and consider the following set of guidelines
in the development of the data model and protocol: in the development of the data model and protocol:
1. The data model SHOULD provide a modular design separating out 1. The data model SHOULD provide a modular design separating
messaging specific, administrative specific, and spectrum messaging-specific, administrative-specific, and spectrum-
specific parts into separate modules. specific parts into distinct modules.
2. The protocol SHOULD support determination of which administrative
specific and spectrum specific modules are used.
6. IANA Considerations
This document makes no request of IANA. 2. The protocol SHOULD support determination of which
administrative-specific and spectrum-specific modules are used.
7. Security Considerations 6. Security Considerations
PAWS is a protocol whereby a Master Device requests a schedule of PAWS is a protocol whereby a master device requests a schedule of
available spectrum at its location (or location of its Slave Devices) available spectrum at its location (or the location of its slave
before it (they) can operate using those frequencies. Whereas the devices) before it (or they) can operate using those frequencies.
information provided by the Database must be accurate and conform to Whereas the information provided by the database must be accurate and
applicable regulatory rules, the Database cannot enforce, through the conform to applicable regulatory rules, the database cannot enforce,
protocol, that a client device uses only the spectrum it provided. through the protocol, that a client device uses only the spectrum it
In other words, devices can put energy in the air and cause provided. In other words, devices can put energy in the air and
interference without asking the Database. Hence, PAWS security cause interference without asking the database. Hence, PAWS security
considerations do not include protection against malicious use of the considerations do not include protection against malicious use of the
white-space spectrum. white-space spectrum.
Threat model for the PAWS protocol: Threat model for the PAWS protocol:
Assumptions: Assumptions:
The link between the master device and the database can be The link between the master device and the database can be
wired or wireless and provides IP connectivity. It is assumed wired or wireless and provides IP connectivity. It is assumed
that an attacker has full access to the network medium between that an attacker has full access to the network medium between
the master device and the database. The attacker may be able the master device and the database. The attacker may be able
to eavesdrop on any communications between these entities. to eavesdrop on any communications between these entities.
Threat 1: User modifies a device to masquerade as another valid Threat 1: User modifies a device to masquerade as another valid
certified device certified device
A master device identifies itself to the database in order to A master device identifies itself to the database in order to
obtain information about available spectrum. Without suitable obtain information about available spectrum. Without suitable
protection mechanisms, devices can listen to registration protection mechanisms, devices can listen to registration
exchanges, and later register with the database by claiming the exchanges and later register with the database by claiming the
identity of another device. identity of another device.
Threat 2: Spoofed database Threat 2: Spoofed database
A master device attempts to discovers a database(s) that it can
query for available spectrum information. An attacker may A master device attempts to discover a database (or databases)
attempt to spoof a database and provide responses to a master that it can query for available spectrum information. An
device that are malicious and result in the master device attacker may attempt to spoof a database and provide responses
causing interference to the primary user of the spectrum. 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 Threat 3: Modifying or jamming a query request
An attacker may modify or jam the query request sent by a An attacker may modify or jam the query request sent by a
master device to a database. The attacker may change the master device to a database. The attacker may change the
location of the device or its capabilities (transmit power, location of the device or its capabilities (transmit power,
antenna height etc.), and, as a result, the database responds antenna height, etc.), and, as a result, the database responds
with incorrect information about available spectrum or maximum with incorrect information about available spectrum or maximum
transmit power allowed. The result of such an attack is that transmit power allowed. The result of such an attack is that
the master device can cause interference to the primary user of the master device can cause interference to the primary user of
the spectrum. It may also result in a denial of service to the the spectrum. It may also result in a denial of service to the
master device if the modified database response indicates that master device if the modified database response indicates that
no channels are available to the master device or when a jammed no channels are available to the master device or when a jammed
query prevents the request from reaching the database. query prevents the request from reaching the database.
Threat 4: Modifying or jamming a query response Threat 4: Modifying or jamming a query response
An attacker may modify or jam the query response sent by the An attacker may modify or jam the query response sent by the
database to a master device. For example, an attacker may database to a master device. For example, an attacker may
modify the available spectrum or power level information modify the available spectrum or power-level information
carried in the database response. As a result, a master device carried in the database response. As a result, a master device
may use spectrum that is not available at a location or may may use spectrum that is not available at a location or may
transmit at a greater power level than allowed. Such transmit at a greater power level than allowed. Such
unauthorized use can result in interference to the primary user unauthorized use can result in interference to the primary user
of that spectrum. Alternatively, an attacker may modify a of that spectrum. Alternatively, an attacker may modify a
database response to indicate that no spectrum is available at database response to indicate that no spectrum is available at
a location (or jam the response), resulting in a denial of a location (or jam the response), resulting in a denial of
service to the master device. service to the master device.
Threat 5: Third party tracking of white space device location and Threat 5: Third-party tracking of white-space device location and
identity identity
A master device may provide its identity in addition to its A master device may provide its identity in addition to its
location in the query request. Such location/identity location in the query request. Such location/identity
information can be gleaned by an eavesdropper and used for information can be gleaned by an eavesdropper and used for
unauthorized tracking purposes. unauthorized tracking purposes.
Threat 6: Malicious individual acts as a database to terminate or Threat 6: Malicious individual acts as a database to terminate or
unfairly limit spectrum access of devices unfairly limit spectrum access of devices
A database may include a mechanism by which service and A database may include a mechanism by which service and
spectrum allocated to a master device can be revoked by sending spectrum allocated to a master device can be revoked by sending
a revoke message to a master device. A malicious user can a revoke message to a master device. A malicious user can
pretend to be a database and send a revoke message to that pretend to be a database and send a revoke message to that
device. This results in denial of service to the master device. This results in denial of service to the master
device. device.
The security requirements arising from the above threats are captured The security requirements arising from the above threats are captured
in the requirements of Section 5.2. in the requirements of Section 5.2.
skipping to change at page 22, line 14 skipping to change at page 22, line 5
A database may include a mechanism by which service and A database may include a mechanism by which service and
spectrum allocated to a master device can be revoked by sending spectrum allocated to a master device can be revoked by sending
a revoke message to a master device. A malicious user can a revoke message to a master device. A malicious user can
pretend to be a database and send a revoke message to that pretend to be a database and send a revoke message to that
device. This results in denial of service to the master device. This results in denial of service to the master
device. device.
The security requirements arising from the above threats are captured The security requirements arising from the above threats are captured
in the requirements of Section 5.2. in the requirements of Section 5.2.
8. Acknowledegements 7. Acknowledgments
The authors acknowledge Gabor Bajko, Teco Boot, Nancy Bravin, Rex The authors acknowledge Gabor Bajko, Teco Boot, Nancy Bravin, Rex
Buddenberg, Vincent Chen, Gerald Chouinard, Stephen Farrell, Michael Buddenberg, Vincent Chen, Gerald Chouinard, Stephen Farrell, Michael
Fitch, Joel M. Halpern, Jussi Kahtava, Paul Lambert, Barry Leiba, Fitch, Joel M. Halpern, Jussi Kahtava, Paul Lambert, Barry Leiba,
Subramanian Moonesamy, Pete Resnick, Brian Rosen, Andy Sago, Peter Subramanian Moonesamy, Pete Resnick, Brian Rosen, Andy Sago, Peter
Stanforth, John Stine, and Juan Carlos Zuniga for their contributions Stanforth, John Stine, and Juan Carlos Zuniga for their contributions
to this document. to this document.
9. References 8. References
9.1. Normative References
[I-D.ietf-paws-protocol] 8.1. Normative References
Chen, V., Das, S., Zhu, L., Malyar, J., and P. McCann,
"Protocol to Access Spectrum Database",
draft-ietf-paws-protocol-03 (work in progress),
February 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[WGS84] National Imagery and Mapping Agency, "Department of [WGS84] National Imagery and Mapping Agency, "Department of
Defense World Geodetic System 1984, Its Definition and Defense World Geodetic System 1984, Its Definition and
Relationships with Local Geodetic Systems, NIMA TR8350.2 Relationships with Local Geodetic Systems", NIMA
Third Edition Amendment 1", January 2000, <http:// TR8350.2 Third Edition Amendment 1, January 2000,
earth-info.nga.mil/GandG/publications/tr8350.2/ <http://earth-info.nga.mil/GandG/publications/tr8350.2/
wgs84fin.pdf>. wgs84fin.pdf>.
9.2. Informational References 8.2. Informative References
URIs [CRADIO] Cognitive Radio Technologies Proceeding (CRTP), "Federal
Communications Commission", ET Docket No. 03-108,
August 2010, <http://fcc.gov/oet/cognitiveradio>.
[1] <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.
Authors' Addresses Authors' Addresses
Anthony Mancuso (editor) Anthony Mancuso (editor)
Google Google
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US US
Email: amancuso@google.com EMail: amancuso@google.com
Scott Probasco Scott Probasco
Email: scott@probasco.me EMail: scott@probasco.me
Basavaraj Patil Basavaraj Patil
Cisco Systems
2250 East President George Bush Highway 2250 East President George Bush Highway
Richardson, TX 75082 Richardson, TX 75082
US US
Email: basavpat@cisco.com EMail: basavpat@cisco.com
 End of changes. 150 change blocks. 
351 lines changed or deleted 356 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/