draft-ietf-paws-problem-stmt-usecases-rqmts-13.txt   draft-ietf-paws-problem-stmt-usecases-rqmts-14.txt 
PAWS Mancuso, Ed.
PAWS A. Mancuso, Ed.
Internet-Draft Google Internet-Draft Google
Intended status: Informational Probasco Intended status: Informational S. Probasco
Expires: August 18, 2013 Patil Expires: September 5, 2013 B. Patil
February 14, 2013 March 4, 2013
Protocol to Access White Space (PAWS) Database: Use Cases and Protocol to Access White Space (PAWS) Database: Use Cases and
Requirements Requirements
draft-ietf-paws-problem-stmt-usecases-rqmts-13 draft-ietf-paws-problem-stmt-usecases-rqmts-14
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 whitespace information followed by use cases and
skipping to change at page 1, line 45 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2013. This Internet-Draft will expire on September 5, 2013.
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
skipping to change at page 2, line 40 skipping to change at page 2, line 40
3.5. Data Model Definition . . . . . . . . . . . . . . . . . . 8 3.5. Data Model Definition . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . 18 5.3. Operational Requirements . . . . . . . . . . . . . . . . . 19
5.4. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 19 5.4. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. Acknowledegements . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledegements . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informational References . . . . . . . . . . . . . . . . . 22 9.2. Informational References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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
skipping to change at page 3, line 47 skipping to change at page 3, line 47
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 white-space database query the IETF has undertaken to develop a database query protocol (see
protocol (see [I-D.ietf-paws-protocol]). [I-D.ietf-paws-protocol]).
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:
1. Determine the relevant white-space database to query. 1. Determine the relevant database to query.
2. Connect to and optionally register with the database using a 2. Connect to and optionally register with the database using a
well-defined protocol. well-defined protocol.
3. Provide its geolocation and perhaps other data to the database 3. Provide geolocation and perhaps other data to the database using
using 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 using a well-defined format for the information. frequencies at the specified geolocation using a well-defined
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 it changes it location or operating parameters, to database when they change their locations or operating parameters.
receive permission to operate in its new location and/or with its new This will allow them to receive permission to operate in their new
operating parameters, and send an acknowledgment to the database that locations and/or with their new operating parameters, and to send
includes information on its new operating parameters. acknowledgments to the database that include information on their new
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:
1. Co-existence and interference avoidance of white space devices 1. Co-existence and interference avoidance of white space devices
within the same spectrum. within the same spectrum.
2. Provisioning (releasing new spectrum for white space use). 2. Provisioning (releasing new spectrum for white space use).
skipping to change at page 4, line 46 skipping to change at page 5, line 4
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:
1. Co-existence and interference avoidance of white space devices 1. Co-existence and interference avoidance of white space devices
within the same spectrum. within the same spectrum.
2. Provisioning (releasing new spectrum for white space use). 2. Provisioning (releasing new spectrum for white space use).
2. Terminology Used in this Document 2. Terminology Used in this Document
Database A database is an entity that contains current information Database A database is an entity that contains current information
about available spectrum at a given location and time as well as 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 each master 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
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.
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 should be regulatory fundamental operation of the protocol must be independent of any
independent. particular regulatory environment.
An example high-level architecture of the devices and white-space An example high-level architecture of the devices and databases is
databases is shown in Figure 1. shown in Figure 1.
----------- -----------
| Master | | Master |
|WS Device| ------------ |WS Device| ------------
|Lat: X |\ .---. /--------|Database X| |Lat: X |\ .---. /--------|Database A|
|Long: Y | \ ( ) / ------------ |Long: Y | \ ( ) / ------------
----------- \-------/ \/ o ----------- \-------/ \/ o
( Internet) o ( Internet) o
----------- /------( )\ o ----------- /------( )\ o
| Master | / ( ) \ | Master | / ( ) \ o
|WS Device|/ (_____) \ ------------ |WS Device|/ (_____) \ ------------
|Lat: X | \--------|Database Y| |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
skipping to change at page 7, line 39 skipping to change at page 7, line 39
4. Flexible and extensible data structures - Different databases are 4. Flexible and extensible data structures - Different databases are
likely to have different requirements for the kinds of data likely to have different requirements for the kinds of data
required for registration (different regulatory rule sets that required for registration (different regulatory rule sets that
apply to the registration of devices) and other messages sent by apply to the registration of devices) and other messages sent by
the device to the database. For instance, different regulators the device to the database. For instance, different regulators
might require different device-characteristic information to be might require different device-characteristic information to be
passed to the database. passed to the database.
3.2. Database Discovery 3.2. Database Discovery
The master device must obtain the address of a trusted white-space The master device must obtain the address of a trusted database,
database, which it will query for available white-space spectrum. If which it will query for available white-space spectrum. If the
the master device uses a discovery service to locate a trusted white- master device uses a discovery service to locate a trusted database,
space database, it performs the following steps: 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 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 - 3 above, the master device can Optionally, and in place of steps 1-2 above, the master device can be
be pre-programmed with the location (e.g., Internet address) of one pre-configured with the address (e.g., URI) of one or more trusted
or more one trusted databases. The master device can establish databases. The master device can establish contact with one of these
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
skipping to change at page 9, line 37 skipping to change at page 9, line 38
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 may notify them when they
are required to change white-space frequencies or cease white space are required to change white-space frequencies or cease white space
communications. 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 on its own
behalf and on behalf of slave devices with a white-space database. behalf and on behalf of slave devices with a database.
-------- --------
|Slave | |Slave |
|Device| \ \|/ ---------- |Device| \ \|/ ----------
| 1 | (Air) | |Database| | 1 | (Air) | |Database|
-------- \ | (----) /|--------| -------- \ | (----) /|--------|
| \ ------|------ ( ) / | \ ------|------ ( ) /
| \| Master | / \ | \| Master | / \
-------- /| |======= ( Internet ) -------- /| |======= ( Internet )
|Slave | / | Device | \ / |Slave | / | Device | \ /
skipping to change at page 10, line 43 skipping to change at page 10, line 43
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 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 power up and associate with the master device via 2. Slave devices may power up and associate with the master device
Wi-Fi or some other over-the-air non-white-space spectrum. Until via Wi-Fi or some other over-the-air non-white-space spectrum.
the slave device is allocated white-space spectrum, any master- Until the slave device is allocated white-space spectrum, any
slave or slave-slave communications occurs over such non-white- master-slave or slave-slave communications occurs over such non-
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 white-space location, and establishes a connection to a trusted database (see
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.
skipping to change at page 12, line 27 skipping to change at page 12, line 27
\ / (----) \ / (----)
\ / \ /
\|---------------|/ \|---------------|/
| 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 the 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: access point:
skipping to change at page 14, line 48 skipping to change at page 14, line 48
\ | | / \ \ | | / \
\--|------------- /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: Rapid-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 RF
channels from the white-space database (as described in Section 4.1). channels from the database (as described in Section 4.1). However,
However, the backhaul link may not be available to all nodes, such as the backhaul link may not be available to all nodes, such as depicted
depicted for the left node in the above figure. To handle RF channel for the left node in the above figure. To handle RF channel
allocation for such nodes, a master node with a backhaul link relays allocation for such nodes, a master node with a backhaul link relays
or proxies the database query for them. So master nodes without a or proxies the database query for them. So master nodes without a
backhaul link follow the procedure as defined for clients. The ad- backhaul link follow the procedure as defined for clients. The ad-
hoc network radios utilize the provided RF channels. Details on hoc network radios utilize the provided RF channels. Details on
forming and maintenance of the ad-hoc network, including repair of forming and maintenance of the ad-hoc network, including repair of
segmented networks caused by segments operating on different RF segmented networks caused by segments operating on different RF
channels, is out of scope of spectrum allocation. 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
skipping to change at page 16, line 16 skipping to change at page 16, line 16
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 & its
uncertainty, and confidence in percentage of the location uncertainty, and confidence in percentage of the location
determination. The Data Model MUST support [WGS84]. 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 its current 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 number for a white-space device. serial number for a white-space device.
skipping to change at page 17, line 31 skipping to change at page 17, line 31
as a circle). as 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 levels selected for use by a white-space device in the power levels selected for use by a white-space device in the
acknowledgement message. acknowledgement 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 protocol
must support the discovery of an appropriate database given a MUST support the discovery of an appropriate database given a
location provided by the master device. The master device may location provided by the master device. The master device MAY
select a database by discovery at run time or by means of a pre- select a database by discovery at run time or by means of a pre-
programmed URI address. The master device may validate discovered programmed URI. The master device MAY validate discovered or
or configured database addresses against a list of known databases configured database addresses against a list of known databases
(e.g., a list of databases approved by a regulatory body). (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 device
(or any slave devices on whose behalf the master is contacting the (or any slave devices on whose behalf the master is contacting the
database) at the current location or the master (or slave) database) at a specified location.
device(s).
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 The protocol MUST support the master device registering with the P.7 Tracking of master or slave device uses of white space spectrum
by database administrators, regulatory agencies, and others who
have access to white space database could be considered invasive
of privacy, including of 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)). database (see Device Registration (Section 3.3)).
P.8 The protocol MUST support a registration acknowledgement P.9 The protocol MUST support a registration acknowledgement
indicating the success or failure of the master device indicating the success or failure of the master device
registration. registration.
P.9 The protocol MUST support an available spectrum request from the P.10 The protocol MUST support an available spectrum request from
master device to the database, which may include one or more of the master device to the database, which may include one or more
the data items listed in Data Model Requirements (Section 5.1). 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.10 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 more
of the data items listed in Data Model Requirements (Section 5.1). 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.11 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
own behalf and/or on behalf of one or more slave devices.
P.12 The protocol MUST support a spectrum usage message P.13 The protocol MUST support a spectrum usage message
acknowledgement. acknowledgement.
P.13 The protocol MUST support a validation request from the master P.14 The protocol MUST support a validation request from the master
to the database to validate a slave device. The validation device to the database to validate a slave device, which should
request MUST include the slave device ID. include information necessary to identify the slave device to the
database.
P.14 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 indicate
the success or failure of the validation request. the success or failure of the validation request.
P.15 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 in a timely manner. information.
5.3. Operational Requirements 5.3. Operational Requirements
This section contains operational requirements of a white-space This section contains operational requirements of a database-device
database-device system, independent of the requirements of the system, independent of the requirements of the protocol for
protocol for communication between the white-space database and communication between the database and devices.
devices.
O.1 The database and the master device MUST be connected (e.g., O.1 The master device must be able to connect to the database to
through the Internet). send requests to the database and receive responses to, and
acknowledgements 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 a
location programmed at installation. 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 that
apply to its operation at its location. 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 based on its current location before starting radio spectrum at a specified location before starting radio
transmission in white space. transmission in white space at that location.
O.5 The database MUST respond to an available spectrum list request. 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 After connecting to a master device, a slave device MUST query O.6 The database MUST respond to an available spectrum request.
the master device for a list of available spectrum. The master
device then queries the database on behalf of the slave device for
an available spectrum list, using parameters received from the
slave device. After the master device receives a response to its
request for an available spectrum list on behalf of a slave
device, the master device MUST relay the response to the slave
device.
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 co-existence 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:
skipping to change at page 20, line 22 skipping to change at page 20, line 33
protocol, that a client device uses only the spectrum it provided. protocol, that a client device uses only the spectrum it provided.
In other words, devices can put energy in the air and cause In other words, devices can put energy in the air and cause
interference without asking the Database. Hence, PAWS security 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 white-space database The link between the master device and the database can be
can be wired or wireless and provides IP connectivity. It is wired or wireless and provides IP connectivity. It is assumed
assumed that an attacker has full access to the network medium that an attacker has full access to the network medium between
between the master device and the white-space database. The the master device and the database. The attacker may be able
attacker may be able to eavesdrop on any communications between to eavesdrop on any communications between these entities.
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 white-space database Threat 2: Spoofed database
A master device attempts to discovers a database(s) that it can
A master device attempts to discovers a white-space database(s) query for available spectrum information. An attacker may
that it can query for available spectrum information. An attempt to spoof a database and provide responses to a master
attacker may attempt to spoof a white-space database and device that are malicious and result in the master device
provide responses to a master device that are malicious and causing interference to the primary user of the spectrum.
result in the master device causing interference to the primary
user of the spectrum.
Threat 3: Modifying a query request Threat 3: Modifying or jamming a query request
An attacker may modify the query request sent by a master An attacker may modify or jam the query request sent by a
device to a white-space 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. no channels are available to the master device or when a jammed
query prevents the request from reaching the database.
Threat 4: Modifying a query response Threat 4: Modifying or jamming a query response
An attacker may modify the query response sent by the white- An attacker may modify or jam the query response sent by the
space database to a master device. For example, an attacker database to a master device. For example, an attacker may
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, resulting in a denial of service to the master a location (or jam the response), resulting in a denial of
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 white space database to Threat 6: Malicious individual acts as a database to terminate or
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 white-space database may include a mechanism by which service spectrum allocated to a master device can be revoked by sending
and spectrum allocated to a master device can be revoked by a revoke message to a master device. A malicious user can
sending a revoke message to a master device. A malicious user pretend to be a database and send a revoke message to that
can pretend to be a white-space database and send a revoke device. This results in denial of service to the master
message to that device. This results in denial of service to device.
the master 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 8. Acknowledegements
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
skipping to change at page 22, line 26 skipping to change at page 22, line 41
February 2013. 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 TR8350.2
Third Edition Amendment 1", January 2000, <http:// Third Edition Amendment 1", January 2000, <http://
earth-info.nga.mil/GandG/publications/tr8350.2/ earth-info.nga.mil/GandG/publications/tr8350.2/
tr8350_2.html>. wgs84fin.pdf>.
9.2. Informational References 9.2. Informational References
URIs URIs
[1] <http://fcc.gov/oet/cognitiveradio/> [1] <http://fcc.gov/oet/cognitiveradio/>
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
Phone:
Fax:
Email: amancuso@google.com Email: amancuso@google.com
URI:
Scott Probasco Scott Probasco
Phone:
Fax:
Email: scott@probasco.me Email: scott@probasco.me
URI:
Basavaraj Patil Basavaraj Patil
Phone:
Fax:
Email: bpatil@ovi.com Email: bpatil@ovi.com
URI:
 End of changes. 64 change blocks. 
140 lines changed or deleted 145 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/