draft-ietf-paws-problem-stmt-usecases-rqmts-12.txt   draft-ietf-paws-problem-stmt-usecases-rqmts-13.txt 
PAWS Mancuso, Ed. PAWS Mancuso, Ed.
Internet-Draft Probasco Internet-Draft Google
Intended status: Informational Patil Intended status: Informational Probasco
Expires: August 2, 2013 January 29, 2013 Expires: August 18, 2013 Patil
February 14, 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-12 draft-ietf-paws-problem-stmt-usecases-rqmts-13
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. An obvious technique to "unlock" existing spectrum for new use. This document
requirement is that these additional transmissions do not interfere includes the problem statement for the development of a protocol to
with the assigned use of the spectrum. One approach to using white access a database of whitespace information followed by use cases and
space spectrum at a given time and location is to verify spectrum requirements for that protocol. Finally, requirements associated
availability with a database that manages spectrum sharing and with the protocol are presented.
provides spectrum-availability information. The IETF has undertaken
to develop a Protocol to Access Spectrum Database [1] for such a
management database.
This document describes a number of possible use cases of white space
spectrum and technology as well as a set of requirements for the
database query protocol. The concept of white spaces is described
along with the problems that need to be addressed to enable white
space spectrum for additional uses without causing interference to
currently assigned use. Use of white space is enabled by querying a
database that stores information about spectrum availability at any
given location and time.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 2, line 11 skipping to change at page 1, line 45
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 2, 2013. This Internet-Draft will expire on August 18, 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
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 3, line 7 skipping to change at page 2, line 19
(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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Introduction to white space . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . 5 1.2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 2. Terminology Used in this Document . . . . . . . . . . . . . . 4
2.1. Conventions Used in This Document . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Global Applicability . . . . . . . . . . . . . . . . . . . 6
3. Protocol Services . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Database Discovery . . . . . . . . . . . . . . . . . . . . 7
3.1. White space database discovery . . . . . . . . . . . . . . 6 3.3. Device Registration . . . . . . . . . . . . . . . . . . . 8
3.2. Device registration with trusted database . . . . . . . . 7 3.4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5. Data Model Definition . . . . . . . . . . . . . . . . . . 8
4.1. Master-slave white space networks . . . . . . . . . . . . 8 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Offloading: moving traffic to a white space network . . . 10 4.1. Master-slave White Space Networks . . . . . . . . . . . . 9
4.3. White space serving as backhaul . . . . . . . . . . . . . 11 4.2. Offloading: Moving Traffic to a White Space Network . . . 11
4.4. Rapid network deployment during emergency scenario . . . . 12 4.3. White Space Serving as Backhaul . . . . . . . . . . . . . 13
4.5. White space used for local TV broadcaster . . . . . . . . 13 4.4. Rapid Network Deployment During Emergencies . . . . . . . 14
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 14 4.5. White Space Used for Local TV Broadcaster . . . . . . . . 15
5.1. Global applicability . . . . . . . . . . . . . . . . . . . 15 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. Database discovery . . . . . . . . . . . . . . . . . . . . 17 5.1. Data Model Requirements . . . . . . . . . . . . . . . . . 16
5.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 17
5.4. Data model definition . . . . . . . . . . . . . . . . . . 17 5.3. Operational Requirements . . . . . . . . . . . . . . . . . 18
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.4. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Data Model Requirements . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6.3. Operational Requirements . . . . . . . . . . . . . . . . . 20 8. Acknowledegements . . . . . . . . . . . . . . . . . . . . . . 21
6.4. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9.2. Informational References . . . . . . . . . . . . . . . . . 22
9. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . . 26
11.2. Informational References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
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. An obvious technique to "unlock" existing spectrum for new use.
requirement is that these secondary transmissions do not interfere
with the assigned use of the spectrum. One interesting observation An obvious requirement is that these secondary transmissions do not
is that often, in a given physical location, the primary user(s) may interfere with the assigned use of the spectrum. One interesting
not be using the entire band assigned to them. The available observation is that often, in a given physical location, the primary
spectrum for secondary transmissions would then depend on the user(s) may not be using the entire band assigned to them. The
location of the secondary user. The fundamental issue is how to available spectrum for secondary transmissions would then depend on
the location of the secondary user. The fundamental issue is how to
determine, for a specific location and specific time, if any of the determine, for a specific location and specific time, if any of the
assigned spectrum is available for secondary use. Academia and assigned spectrum is available for secondary use.
Industry have studied multiple cognitive radio [2] mechanisms for use
in such a scenario. One simple mechanism is to use a geospatial Academia and Industry have studied multiple cognitive radio [1]
database that contains the spatial and temporal profile of all mechanisms for use in such a scenario. One simple mechanism is to
primary licensees' spectrum usage, and require secondary users to use a geospatial database that contains the spatial and temporal
query the database for available spectrum that they can use at their profile of all primary licensees' spectrum usage, and require
location. Such databases can be accessible and queryable by secondary users to query the database for available spectrum that
secondary users on the Internet. they can use at their location. Such databases can be accessible and
queryable by secondary users on the Internet.
Any entity that is assigned spectrum that is not densely used may be 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. Note that the IETF secondary users via a database query protocol. The final sections
has undertaken to develop a white space database query protocol (see include the requirements associated with such a protocol. Note that
Protocol to Access Spectrum Database [1]. the IETF has undertaken to develop a white-space database query
protocol (see [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 white-space 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 its geolocation and perhaps other data to the database
using a well-defined format for querying the database. using 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 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. containing channels selected for use by the device and other
device operation parameters.
Note. The above protocol actions should explicitly or implicitly
support the ability of devices to re-register and/or re-query the
database when it changes it location or operating parameters, to
receive permission to operate in its new location and/or with its new
operating parameters, and send an acknowledgment to the database that
includes information on its 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).
2. Conventions and Terminology 2. Terminology Used in this Document
2.1. Conventions Used in This Document
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].
2.2. Terminology
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.
skipping to change at page 6, line 17 skipping to change at page 5, line 21
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.
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. Protocol Services 3. Problem Statement
A protocol solution must enable many different potential white space The use of white-space spectrum is enabled via the capability of a
services. This section describes the features required of the device to query a database and obtain information about the
protocol. availability of spectrum for use at a given location. The databases
are reachable via the Internet and the devices querying these
databases are expected to have some form of Internet connectivity,
directly or indirectly. While databases are expected to support the
rule set(s) of one or more regulatory domains, and the regulations
and available spectrum associated with each rule set may vary, the
fundamental operation of the protocol should be regulatory
independent.
3.1. White space database discovery An example high-level architecture of the devices and white-space
databases is shown in Figure 1.
A white space radio network is created by a master device. Before -----------
the master device can transmit in white space spectrum, it MUST | Master |
obtain the address of a trusted white space database, which it will |WS Device| ------------
query for available white space spectrum. If the master device uses |Lat: X |\ .---. /--------|Database X|
a discovery service to locate a trusted white space database, it |Long: Y | \ ( ) / ------------
performs the following steps: ----------- \-------/ \/ o
( Internet) o
----------- /------( )\ o
| Master | / ( ) \
|WS Device|/ (_____) \ ------------
|Lat: X | \--------|Database Y|
|Long: Y | ------------
-----------
1. The master device connects to the Internet. Figure 1: High-level View of White Space Database Architecture
2. The master device constructs and sends a request over the Note that there could be multiple databases serving white space
Internet to a trusted discovery service. devices. In some countries, such as the U.S., the regulator has
determined that multiple databases may provide service to White Space
Devices.
3. If no acceptable response is received within a pre-configured A messaging interface between the white space devices and the
database is required for operating a network using the white-space
spectrum. The following sections discuss various aspects of such an
interface and the need for a standard.
3.1. Global Applicability
The use of white-space spectrum is currently approved or being
considered in multiple regulatory domains, whose rules may differ.
However, the need for devices that intend to use the spectrum to
communicate with a database remains a common feature. The database
implements rules that protect all primary users, independent of the
characteristics of the white space devices. It also provides a way
to specify a schedule of use, since some primary users (for example,
wireless microphones) only operate in limited time slots.
Devices need to be able to query a database, directly or indirectly,
over the public Internet and/or private IP networks prior to
operating in available spectrum. Information about available
spectrum, schedule, power, etc., are provided by the database as a
response to the query from a device. The messaging interface needs
to be:
1. Interface agnostic - An interface between a master white space
device and database can be wired or unwired (e.g., a radio/air
interface technology such as IEEE 802.11af, IEEE 802.15.4m, IEEE
802.16, IEEE 802.22, LTE etc.) However, the messaging interface
between a master white space device and the database should be
agnostic to the interface used for such messaging while being
cognizant of the characteristics of the interface technology and
the need to include any relevant attributes in the query to the
database.
2. Spectrum agnostic - the spectrum used by primary and secondary
users varies by country. Some spectrum has an explicit notion of
a "channel": a defined swath of spectrum within a band that has
some assigned identifier. Other spectrum bands may be subject to
white space sharing, but only have actual frequency low/high
parameters to define primary and secondary use. The protocol
should be able to be used in any spectrum band where white space
sharing is permitted.
3. Globally applicable - A common messaging interface between white
space devices and databases will enable the use of such spectrum
for various purposes on a global basis. Devices can operate in
any location where such spectrum is available and a common
interface ensures uniformity in implementations and deployment.
To allow the global use of white space devices in different
countries (whatever the regulatory domain), the protocol should
support the database communicating applicable regulatory rule set
information to the white space device.
4. Flexible and extensible data structures - Different databases are
likely to have different requirements for the kinds of data
required for registration (different regulatory rule sets that
apply to the registration of devices) and other messages sent by
the device to the database. For instance, different regulators
might require different device-characteristic information to be
passed to the database.
3.2. Database Discovery
The master device must obtain the address of a trusted white-space
database, which it will query for available white-space spectrum. If
the master device uses a discovery service to locate a trusted white-
space database, it performs the following steps:
1. The master device constructs and sends a request (e.g., over the
Internet) to a trusted discovery service.
2. If no acceptable response is received within a pre-configured
time limit, the master device concludes that no trusted database 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, and establishes a white space network with the trusted database.
(as described in the following use cases).
Optionally, and in place of steps 1 - 3 above, the master device can 3. The master device establishes a white space network as described
be pre-programmed with the Internet address of one or more one in Section 4.
trusted databases. The master device can establish contact with one
of these trusted databases and establish a white space network (as
described in the following use cases).
3.2. Device registration with trusted database Optionally, and in place of steps 1 - 3 above, the master device can
be pre-programmed with the location (e.g., Internet address) of one
or more one trusted databases. The master device can establish
contact with one of these trusted databases.
In some regulatory domains, the master device must register with the 3.3. Device Registration
trusted database before it queries the database for available
spectrum. Different regulatory domains may have different device
registration requirements.
Figure 1 (Figure 1) shows an example deployment of this scenario. The master device may register with the database before it queries
the database for available spectrum. A registration process may
consist of the following steps:
---------- 1. The master device sends registration information to the database.
\|/ |Database| This information may include the Device ID, serial number
| .---. / --------- assigned by the manufacturer, device location, device antenna
|--|--------| ( ) / height above ground, name of the individual or business that owns
| Master | / \ the device, and the name, street and email address, and telephone
| |========( Internet) number of a contact person responsible for the device's
|-----------| \ / operation.
( )
(---)
Figure 1: Example illustration of registration requirement in white 2. The database responds to the registration request with an
space use-case acknowledgement to indicate the success of the registration
request or with an error if the registration was unsuccessful.
Additional information may be provided by the database in its
response to the master device.
A simplified operational scenario showing registration consists of 3.4. Protocol
the following steps:
1. If required by the regulatory domain, the master device registers A protocol that enables a white space device to query a database to
with its most current and up-to-date information. If subject to obtain information about available spectrum is needed. A device may
registration, typically the master device will register after be required to register with the database with some credentials prior
power up, after changing location by a predetermined distance, to being allowed to query. The requirements for such a protocol are
and after prescribed time intervals. specified in this document.
2. To register with the database, the master device sends 3.5. Data Model Definition
registration information to the database. This information may
include the Device ID, serial number assigned by the
manufacturer, device location, device antenna height above
ground, name of the individual or business that owns the device,
and the name, street and email address, and telephone number of a
contact person responsible for the device's operation.
3. The database responds to the registration request with an The contents of the queries and response need to be specified. A
acknowledgement to indicate the success of the registration data model is required which enables the white space device to query
request or with an error if the registration was unsuccessful. the database while including all the relevant information such as
Additional information may be provided by the database in its geolocation, radio technology, power characteristics, etc., which may
response according to regulatory requirements. be country and spectrum and regulatory dependent. All databases are
able to interpret the data model and respond to the queries using the
same data model that is understood by all devices.
4. Use Cases 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 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 (Figure 2) depicts the general architecture such a simple Figure 2 depicts the general architecture of such a simple master-
master-slave network, in which the master device communicates on its slave network, in which the master device communicates on its own
own behalf and on behalf of slave devices with a white space behalf and on behalf of slave devices with a white-space database.
database.
-------- --------
|Slave | |Slave |
|Device| \ \|/ ---------- |Device| \ \|/ ----------
| 1 | (Air) | |Database| | 1 | (Air) | |Database|
-------- \ | (----) /|--------| -------- \ | (----) /|--------|
| \ ------|------ ( ) / | \ ------|------ ( ) /
| \| Master | / \ | \| Master | / \
-------- /| |======= ( Internet ) -------- /| |======= ( Internet )
|Slave | / | Device | \ / |Slave | / | Device | \ /
skipping to change at page 9, line 33 skipping to change at page 10, line 33
| 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 device 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 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 power up and associate with the master device via
Wi-Fi or some other over-the-air non-white space spectrum. Until Wi-Fi or some other over-the-air non-white-space spectrum. Until
the slave device is allocated white space spectrum, any master- the slave device is allocated white-space spectrum, any master-
slave or slave-slave communications occurs over such non-white slave or slave-slave communications occurs over such non-white-
space spectrum. 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 white-space
database (see Section 4.1.1). database (see Section 3.2).
4. The master optionally registers with the trusted database (see 4. The master may register with the trusted database (see
Section 4.1.2). 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. Note that the master may device identifier, and antenna height. The master may send
relay available-spectrum requests to the database on behalf of available-spectrum requests to the database on behalf of slave
slave devices, then transmit the obtained available-spectrum devices.
lists to the slaves (or the master may allocate spectrum to
slaves from the obtained spectrum lists).
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 a 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.
4.2. Offloading: moving traffic to a white space network Note: Steps 5 through 7 may be repeated by the master device when it
(or a slave device that uses the master as a proxy to communicate
with the database) changes its location or operating parameters --
for example, after a master changes location, it may query the
database for available spectrum at its new location, then acknowledge
the subsequent response received from the database with information
on the spectrum and power levels it is using at the new location.
4.2. Offloading: Moving Traffic to a White Space Network
This scenario is a variant of the master-slave network described in This scenario is a variant of the master-slave network described in
the previous use case. In this scenario, an Internet connectivity the previous use case. In this scenario, an access point (AP) offers
service is provided over white space as a supplemental or alternative a white space service that offloads Internet traffic as an
datapath to a more costly Internet connection (metered wire service, alternative datapath to a more congested or costly Internet wire,
metered wireless service, metered satellite service). In a typical wireless, or satellite service.
deployment scenario, an end user has a primary Internet connection,
but may prefer to use a connection to the Internet provided by a
local white space master device that is connected to the Internet.
Figure 3 (Figure 3) shows an example deployment of this scenario. Figure 3 shows an example deployment of this scenario.
\|/ \|/
| |
| |--|----------|
|------------| \|/ /|Access Point |\
/| Master | \ | (Air)--/ |-------------| \
(Air)-/ |------------| \ --|------ / \ -----------
--------- / \ ----------- |Portable|/ \ (----) | Database|
|Slave |/ \ (----) | 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 the a metered Internet connection to the a WS connection stream, from the a congested or costly Internet connection to a white
consists of the following steps: space service provided by an AP consists of the following steps:
1. The slave device connects to a metered Internet service, and 1. The AP contacts the database to determine channels it can use.
2. The portable device connects to a paid Internet service and
selects a video for streaming. selects a video for streaming.
2. The slave device switches mode and associates with a master white 3. The portable device determines if it can offload to a white space
space device.* access point:
3. The master queries the database for available white space A. If the portable device knows its location, it
spectrum and relays it to the slave device as described in
Section 4.1.*
4. The slave uses available white space spectrum to communicate with 1. asks the database (using the paid service) for available
the master and connect to the Internet to stream the selected white-space spectrum;
video.
* Note that the slave device can act as a master device to query the 2. listens for and connects to the AP over the permitted
database directly for available white space spectrum through its white-space spectrum.
metered connection to the Internet, thus eliminating steps 2 and 3.
4.3. White space serving as backhaul B. If the portable device does not have GPS or other means to
determine its position, it
1. uses non-white-space spectrum to listen for and connect
to the AP;
2. asks the AP to query the database for permitted white-
space spectrum on its behalf;
3. uses the permitted white-space spectrum to connect to the
AP.
4. The portable device accesses the Internet through the AP to
stream the selected video.
4.3. White Space Serving as Backhaul
In this use case, an Internet connectivity service is provided to 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 (Figure 4) and Internet. Note that Wi-Fi is referenced in Figure 4 and the
the following discussion, but any other technology can be substituted following discussion, but any other technology can be substituted in
in its place. its place.
Figure 4 (Figure 4) shows an example deployment of this scenario. Figure 4 shows an example 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) |-|----|
skipping to change at page 12, line 32 skipping to change at page 13, line 46
|------| |------|
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 (WS + Wi-Fi) is connected to a master and WS
network, a simplified operation scenario of backhaul for Wi-Fi network, a simplified operation scenario of backhaul for Wi-Fi
consists of the following steps: consists of the following steps:
1. A bridged slave device (WS + Wi-Fi) is connected to a master 1. A bridged slave device (WS + Wi-Fi) is connected to a master
device operating in the WS spectrum (the master obtains available device operating in the WS spectrum (the master obtains available
white space spectrum as described in Section 4.1). 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 emergency scenario 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 the this allocation and assignment is
often the best solution. A preferred option is to make use of a often the best solution. A preferred option is to make use of a
robust protocol that has been adopted and implemented by radio robust 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 independent 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 (Figure 5) shows an example deployment of this scenario. Figure 5 shows an example deployment of this scenario.
\|/ \|/
| ad hoc | ad hoc
| |
|-|-------------| |-|-------------|
| Master node | |------------| | Master node | |------------|
\|/ | with | | Whitespace | \|/ | with | | Whitespace |
| ad hoc /| backhaul link | | Database | | ad hoc /| backhaul link | | Database |
| /---/ |---------------| |------------| | /---/ |---------------| |------------|
---|------------/ | \ / ---|------------/ | \ /
| Master node | | | (--/--) | Master node | | | (--/--)
skipping to change at page 13, line 35 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 white-space database (as described in Section 4.1).
However, the backhaul link may not be available to all nodes, such as However, the backhaul link may not be available to all nodes, such as
depicted for the left node in the above figure. To handle RF channel depicted 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
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 content locally to the audience over one of the available video 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 their portable device monitors.
Figure 6 (Figure 6) shows an example deployment of this scenario. Figure 6 shows an example deployment of this scenario.
|------------| |------------|
|White Space | |White Space |
| Database | | Database |
.---. / |------------| .---. / |------------|
|-----------| ( ) / |-----------| ( ) /
| Master | / \ | Master | / \
| |========( Internet) | |========( Internet)
|-----------| \ / |-----------| \ /
| ( ) | ( )
skipping to change at page 14, line 40 skipping to change at page 16, line 5
\|/ \|/ \|/ \|/ \|/ \|/ \|/ \|/ \|/ \|/ \|/ \|/ \|/ \|/
| | | | | | | ................. | | | | | | | .................
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
USB TV receivers connected to laptops, cellphone, tablets .... USB TV receivers connected to laptops, cellphone, tablets ....
Figure 6: White Space Used for Local TV Broadcast Figure 6: White Space Used for Local TV Broadcast
5. Problem Statement 5. Requirements
The use of white space spectrum is enabled via the capability of a
device to query a database and obtain information about the
availability of spectrum for use at a given location. The databases
are reachable via the Internet and the devices querying these
databases are expected to have some form of Internet connectivity,
directly or indirectly. The databases may be regulatory specific
since the available spectrum and regulations may vary, but the
fundamental operation of the protocol should be regulatory
independent.
An example high-level architecture of the devices and white space
databases is shown in Figure 7 (Figure 7).
-----------
| Master |
|WS Device| ------------
|Lat: X |\ .---. /--------|Database X|
|Long: Y | \ ( ) / ------------
----------- \-------/ \/ o
( Internet) o
----------- /------( )\ o
| Master | / ( ) \
|WS Device|/ (_____) \ ------------
|Lat: X | \--------|Database Y|
|Long: Y | ------------
-----------
Figure 7: High-level View of White Space Database Architecture
In Figure 11, note that there could be multiple databases serving
white space devices. The databases are locale specific since the
regulations and available spectrum may vary. In some countries, for
example, the U.S., the regulator has determined that multiple
databases may provide service to White Space Devices.
A messaging interface between the white space devices and the
database is required for operating a network using the white space
spectrum. The following sections discuss various aspects of such an
interface and the need for a standard.
5.1. Global applicability
The use of white space spectrum is currently approved or being
considered in multiple regulatory domains, whose rules may differ.
However, the need for devices that intend to use the spectrum to
communicate with a database remains a common feature. The database
implements rules that protect all primary users, independent of the
characteristics of the white space devices. It also provides a way
to specify a schedule of use, since some primary users (for example,
wireless microphones) only operate in limited time slots.
Devices need to be able to query a database, directly or indirectly,
over the public Internet and/or private IP networks prior to
operating in available spectrum. Information about available
spectrum, schedule, power, etc., are provided by the database as a
response to the query from a device. The messaging interface needs
to be:
1. Radio/air interface agnostic - Any radio/air interface technology
used by a white space device can be IEEE 802.11af, IEEE
802.15.4m, IEEE 802.16, IEEE 802.22, LTE etc. However, the
messaging interface between a master white space device and the
database should be agnostic to any air interface used for such
messaging while being cognizant of the characteristics of various
air-interface technologies and the need to include any relevant
attributes in the query to the database.
2. Spectrum agnostic - the spectrum used by primary and secondary
users varies by country. Some spectrum has an explicit notion of
a "channel": a defined swath of spectrum within a band that has
some assigned identifier. Other spectrum bands may be subject to
white space sharing, but only have actual frequency low/high
parameters to define primary and secondary use. The protocol
should be able to be used in any spectrum band where white space
sharing is permitted.
3. Globally applicable - A common messaging interface between white
space devices and databases will enable the use of such spectrum
for various purposes on a global basis. Devices can operate in
any locale where such spectrum is available and a common
interface ensures uniformity in implementations and deployment.
Since the White Space Device must know its geospatial location to
do a query, it is possible to determine which database, and which
rules, are applicable, even though they are locale specific.
Note that although a device may know its geolocation, it may not
know the country or regulatory domain that it is in. Further,
even if the device knows this information, it may not be
sufficient for the device to know its expected behaviour in its
domain of operation since one domain may adopt a rule set for
white space device operation from another regulatory domain
(Brazil may adopt the "FccWhitespace2010" US rule set). To allow
the global use of white space devices in different countries
(whatever the regulatory domain), the protocol should support the
Database communicating applicable rule set information to the
white space device.
4. Flexible and extensible data structures - Different databases are
likely to have different requirements for the kinds of data
required for registration (different rule sets that apply to the
registration of devices) and other messages sent by the device to
the database. For instance, different regulators might require
different device-characteristic information to be passed to the
database.
5.2. Database discovery
Another aspect of the problem space is the need to discover the
database. A white space device needs to find the relevant database
to query, based on its current location or for another location.
Since the spectrum and databases are domain specific, the device will
need to discover the relevant database. The device needs to
determine the location of the specific database to which it can send
queries in addition to registering itself for operation and using the
available spectrum.
5.3. Protocol
A protocol that enables a white space device to query a database to
obtain information about available spectrum is needed. A device may
be required to register with the database with some credentials prior
to being allowed to query. The requirements for such a protocol are
specified in this document.
5.4. Data model definition
The contents of the queries and response need to be specified. A
data model is required which enables the white space device to query
the database while including all the relevant information such as
geolocation, radio technology, power characteristics, etc., which may
be country and spectrum and regulatory dependent. All databases are
able to interpret the data model and respond to the queries using the
same data model that is understood by all devices.
6. Requirements
6.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
WSD, the uncertainty in meters, the height & its uncertainty, white-space device, the uncertainty in meters, the height & its
and confidence in percentage of the location determination. uncertainty, and confidence in percentage of the location
The Data Model MUST support WGS84 (see NGA: DoD World Geodetic determination. The Data Model MUST support [WGS84].
System 1984 [3]).
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 its current 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 device (serial number, certification IDs, etc.) identifies a white-space device (serial number, certification
and describes device characteristics, such as or device class IDs, etc.) and describes device characteristics, such as device
(fixed, mobile, portable, indoor, outdoor, etc.), Radio Access class (fixed, mobile, portable, indoor, outdoor, etc.), Radio
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.
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 subject, such as: radiation related parameters of the white-space device, such
as:
antenna height antenna height
antenna gain antenna gain
maximum output power, EIRP (dBm) maximum output power, EIRP (dBm)
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)
skipping to change at page 19, line 6 skipping to change at page 17, line 24
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 power level for each spectrum unit. maximum 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 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 device in the power levels selected for use by a white-space device in the
acknowledgement message. acknowledgement message.
6.2. Protocol Requirements 5.2. Protocol Requirements
P.1 The master device MUST identify 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 master register, make spectrum availability requests, etc. The protocol
device MAY select a database by discovery at run time or by means must support the discovery of an appropriate database given a
of a pre-programmed URI address. The master device MAY validate location provided by the master device. The master device may
discovered or configured database addresses against a list of select a database by discovery at run time or by means of a pre-
approved databases maintained by a regulatory body. programmed URI address. The master device may validate discovered
or configured database addresses against a list of known databases
(e.g., a list of databases approved by a regulatory body).
P.2 The protocol must support the database informing the master of 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 the current location or the master (or slave)
device(s). 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.
skipping to change at page 19, line 39 skipping to change at page 18, line 13
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 The protocol MUST support the master device registering with the
database (see Device Registration (Section 3.2)). database (see Device Registration (Section 3.3)).
P.8 The protocol MUST support a registration acknowledgement P.8 The protocol MUST support a registration acknowledgement
indicating the success of 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.9 The protocol MUST support an available spectrum request from the
master device to the database. These parameters MAY include any master device to the database, which may include one or more of
of the parameters and attributes required to be supported in the the data items listed in Data Model Requirements (Section 5.1).
Data Model Requirements.
P.10 The protocol MUST support an available spectrum response from P.10 The protocol MUST support an available spectrum response from
the database to the master device. These parameters MAY include the database to the master device, which may include one or more
any of the parameters and attributes required to be supported in of the data items listed in Data Model Requirements (Section 5.1).
the Data Model Requirements.
P.11 The protocol MUST support a spectrum usage message from the P.11 The protocol MUST support a spectrum usage message from the
master device to the database. These parameters MAY include any master device to the database, which may include one or more of
of the parameters and attributes required to be supported in the the data items listed in Data Model Requirements (Section 5.1).
Data Model Requirements.
P.12 The protocol MUST support a spectrum usage message P.12 The protocol MUST support a spectrum usage message
acknowledgement. acknowledgement.
P.13 The protocol MUST support a validation request from the master P.13 The protocol MUST support a validation request from the master
to the database to validate a slave device. The validation to the database to validate a slave device. The validation
request MUST include the slave device ID. request MUST include the slave device ID.
P.14 The protocol MUST support a validation response from the P.14 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 WSDB. The validation response MUST indicate the validated by the database. The validation response MUST indicate
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.15 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 in a timely manner.
6.3. Operational Requirements 5.3. Operational Requirements
This section contains operational requirements of a white space This section contains operational requirements of a white-space
database-device system, independent of the requirements of the database-device system, independent of the requirements of the
protocol for communication between the white space database and protocol for communication between the white-space database and
devices. devices.
O.1 The database and the master device MUST be connected to the O.1 The database and the master device MUST be connected (e.g.,
Internet. through the Internet).
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 or have the capability to location programmed at installation.
determine its location. A mobile master device MUST have the
capability to determine its location. Locations MUST be
determined to the accuracy required by the applicable regulatory
domain.
O.3 The master device MAY contact a database directly for service or
the master device MAY contact a database listing server first,
followed by contact to a database.
O.4 The master device MUST obtain information on the rule set of the
regulatory body that applies to the master device at its current
location (and/or the location of any slave devices on whose behalf
the master device is operating).
O.5 The master device MAY register with the database according to O.3 The master device MUST be configured to understand and comply
local regulatory policy. Not all master devices will be required with the requirements of the rule set of the regulatory body that
to register. Specific events will initiate registration, these apply to its operation at its location.
events are determined by regulator policy (e.g., at power up,
after movement, etc...). When local regulatory policy requires
registration, the master device MUST register with its most
current and up-to-date information, and MUST include all variables
mandated by local regulator policy.
O.6 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 based on its current location before starting radio
transmission in white space. Parameters provided to the database transmission in white space.
MAY include device location, accuracy of the location, antenna
characteristic information, device identifier of any slave device
requesting spectrum information, etc.
O.7 The database MUST respond to an available spectrum list request
from an authenticated and authorized device and MAY also provide
time constraints, maximum output power, start and stop frequencies
for each band in the list and any additional requirements for
sensing.
O.8 According to local regulator policy, a master device MAY inform
the database of the actual frequency usage of the master and its
slaves. The master MUST include parameters required by local
regulatory policy, e.g., device ID, manufacturer's serial number,
spectrum usage and power level information of the master and its
slaves.
O.9 After connecting to a master device's radio network a slave
device MUST query the master device for a list of available
spectrum. The slave MUST include parameters required by local
regulatory policy, e.g., device ID, device location.
O.10 According to local regulatory policy, the master device MAY
query the database with parameters received from the slave device.
O.11 The database MUST respond to a query from the master device
containing parameters from a slave device.
O.12 A master device MUST repeat the query to the database for the
available spectrum as often as required by the regulation (e.g.,
FCC requires once per day) to verify that the operating channels
continue to remain available.
O.13 A master device which changes its location more than a
threshold distance (specified by local regulatory policy) during
its operation, MUST query the database for available operating
spectrum each time it moves more than the threshold distance
(e.g., FCC specifies 100m) from the location it previously made
the query.
O.14 According to local regulator policy, a master device may
contact a database via proxy service of another master device.
O.15 A master device MUST be able to query the whitespace database
for spectrum availability information for a specific expected
coverage area around its current location.
O.16 A Master device MUST include its unique identity in all message O.5 The database MUST respond to an available spectrum list request.
exchanges with the database.
O.17 In the case of a natural disaster,emergency services may need O.6 After connecting to a master device, a slave device MUST query
to use distributed white space databases on short notice. The the master device for a list of available spectrum. The master
database should support any emergency regulations adopted by device then queries the database on behalf of the slave device for
regulators to provide priority allocation of white space spectrum an available spectrum list, using parameters received from the
to emergency services. 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.
6.4. Guidelines 5.4. Guidelines
The current scope of the working group is limited and is reflected in White space technology itself is expected to evolve and include
the requirements captured in Section 6.1. However white space attributes such as co-existence and interference avoidance, spectrum
technology itself is expected to evolve and address other aspects brokering, alternative spectrum bands, etc. The design of the data
such as co-existence and interference avoidance, spectrum brokering, model and protocol should be cognizant of the evolving nature of
alternative spectrum bands, etc. The design of the data model and white space technology and consider the following set of guidelines
protocol should be cognizant of the evolving nature of white space in the development of the data model and protocol:
technology and consider the following set of guidelines in the
development of the data model and protocol:
1. The data model SHOULD provide a modular design separating out 1. The data model SHOULD provide a modular design separating out
messaging specific, administrative specific, and spectrum messaging specific, administrative specific, and spectrum
specific parts into separate modules. specific parts into separate modules.
2. The protocol SHOULD support determination of which administrative 2. The protocol SHOULD support determination of which administrative
specific and spectrum specific modules are used. specific and spectrum specific modules are used.
7. IANA Considerations 6. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
8. Security Considerations 7. 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 location of its Slave Devices)
before it (they) can operate using those frequencies. Whereas the before it (they) can operate using those frequencies. Whereas the
information provided by the Database must be accurate and conform to information provided by the Database must be accurate and conform to
applicable regulatory rules, the Database cannot enforce, through the applicable regulatory rules, the Database cannot enforce, through the
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:
It is assumed that an attacker has full access to the network The link between the master device and the white-space database
medium between the master device and the white space database. can be wired or wireless and provides IP connectivity. It is
The attacker may be able to eavesdrop on any communications assumed that an attacker has full access to the network medium
between these entities. The link between the master device and between the master device and the white-space database. The
the white space database can be wired or wireless and provides attacker may be able to eavesdrop on any communications between
IP connectivity. these entities.
It is assumed that both the master device and the white space
database have NOT been compromised from a security standpoint.
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
Regulatory environments require that devices be certified and A master device identifies itself to the database in order to
register in ways that accurately reflect their certification. obtain information about available spectrum. Without suitable
Without suitable protection mechanisms, devices could simply protection mechanisms, devices can listen to registration
listen to registration exchanges, and later registering exchanges, and later register with the database by claiming the
claiming to be those other devices. Such replays would allow identity of another device.
false registration, violating regulatory regimes. A white
space database may be operated by a commercial entity which
restricts access only to authorized users. A master device MAY
need to identify itself to the database and be authorized to
obtain information about available spectrum.
Threat 2: Spoofed white space database Threat 2: Spoofed white-space database
A master device discovers a white space database(s) through A master device attempts to discovers a white-space database(s)
which it can query for available spectrum information. The that it can query for available spectrum information. An
master device needs to ensure that the white space database attacker may attempt to spoof a white-space database and
with which it communicates with is an authentic entity. The provide responses to a master device that are malicious and
white space database needs to provide its identity to the result in the master device causing interference to the primary
master device which can confirm the validity/authenticity of user of the spectrum.
the database. An attacker may attempt to spoof a white space
database and provide responses to a master device which are
malicious and result in the master device causing interference
to the primary user of the spectrum.
Threat 3: Modifying a query request Threat 3: Modifying a query request
An attacker may modify the query request sent by a master An attacker may modify the query request sent by a master
device to a white space database. The attacker may change the device to a white-space database. The attacker may change the
location of the device or the capabilities in terms of its location of the device or its capabilities (transmit power,
transmit power or antenna height etc., which could result in antenna height etc.), and, as a result, the database responds
the database responding with incorrect information about with incorrect information about available spectrum or maximum
available spectrum or max transmit power allowed. The result transmit power allowed. The result of such an attack is that
of such an attack is that the master device would cause the master device can cause interference to the primary user of
interference to the primary user of the spectrum. It could the spectrum. It may also result in a denial of service to the
also result in a denial of service to the master device by master device if the modified database response indicates that
indicating that no channels are available. no channels are available to the master device.
Threat 4: Modifying a query response Threat 4: Modifying a query response
An attacker could modify the query response sent by the white An attacker may modify the query response sent by the white-
space database to a master device. The available spectrum space database to a master device. For example, an attacker
information or transmit power allowed type of parameters may modify the available spectrum or power level information
carried in the response could be modified by the attacker carried in the database response. As a result, a master device
resulting in the master device using spectrum that is not may use spectrum that is not available at a location or may
available at a location or transmitting at a greater power transmit at a greater power level than allowed. Such
level than allowed resulting in interference to the primary unauthorized use can result in interference to the primary user
user of that spectrum. Alternatively the attacker may indicate of that spectrum. Alternatively, an attacker may modify a
no spectrum availability at a location resulting in a denial of database response to indicate that no spectrum is available at
service to the master device. a location, resulting in a denial of 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 white space database in a regulatory domain may require a A master device may provide its identity in addition to its
master device to 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
tracking purposes. A master device may prefer to keep the unauthorized tracking purposes.
location/identity information hidden from eavesdroppers, hence
the protocol should provide a means to protect the location and
identity information of the master device and prevent tracking
of locations associated with a white space database query.
When the master device sends both its identity and location to
the DB, the DB is able to track it. If a regulatory domain
does not require the master device to provide its identity to
the white space database, the master device may decide not to
send its identity, to prevent being tracked by the DB.
Threat 6: Malicious individual acts as a PAWS entity (spoofing DB Threat 6: Malicious individual acts as a white space database to
or as MiM) to terminate or unfairly limit spectrum access of terminate or unfairly limit spectrum access of devices
devices for reasons other than incumbent protection
A white space database MAY include a mechanism by which service A white-space database may include a mechanism by which service
and spectrum allocated to a master device can be revoked by and spectrum allocated to a master device can be revoked by
sending an unsolicited message. A malicious node can pretend sending a revoke message to a master device. A malicious user
to be the white space database with which a master device has can pretend to be a white-space database and send a revoke
registered or obtained spectrum information from and send a message to that device. This results in denial of service to
revoke message to that device. This results in denial of the master device.
service to 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 6.1 (Section 6.1). in the requirements of Section 5.2.
9. Summary and Conclusion
Wireless spectrum is a scarce resource. As the demand for spectrum
grows, there is a need to more efficiently utilize the available and
allocated spectrum. Cognitive radio technologies enable the
efficient usage of spectrum via means such as sensing or by querying
a database to determine available spectrum at a given location for
opportunistic use. "White space" is the general term used to refer
to the bands within the spectrum which are available for secondary
use at a given location. In order to use this spectrum, a device
needs to query a database that maintains information about the
available spectrum within a band. A protocol is necessary for
communication between the devices and databases that is globally
applicable.
The document describes some examples of the role of the white space
database in the operation of a radio network, and also provides
examples of services provided to the user of a white space device.
From these use cases, requirements are determined. These
requirements are to be used as input for the development of a
Protocol to Access White Space database (PAWS).
10. Acknowledgements 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, Pete Resnick, Fitch, Joel M. Halpern, Jussi Kahtava, Paul Lambert, Barry Leiba,
Brian Rosen, Andy Sago, Peter Stanforth, John Stine and, Juan Carlos Subramanian Moonesamy, Pete Resnick, Brian Rosen, Andy Sago, Peter
Zuniga for their contributions to this document. Stanforth, John Stine, and Juan Carlos Zuniga for their contributions
to this document.
11. References 9. References
11.1. Normative References 9.1. Normative References
[I-D.ietf-paws-protocol]
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.
11.2. Informational References [WGS84] National Imagery and Mapping Agency, "Department of
Defense World Geodetic System 1984, Its Definition and
URIs Relationships with Local Geodetic Systems, NIMA TR8350.2
Third Edition Amendment 1", January 2000, <http://
earth-info.nga.mil/GandG/publications/tr8350.2/
tr8350_2.html>.
[1] <https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/> 9.2. Informational References
[2] <http://en.wikipedia.org/wiki/Cognitive_radio> URIs
[3] <http://earth-info.nga.mil/GandG/publications/tr8350.2/ [1] <http://fcc.gov/oet/cognitiveradio/>
tr8350_2.html>
Authors' Addresses Authors' Addresses
Anthony Mancuso (editor) Anthony Mancuso (editor)
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Phone:
Fax:
Email: amancuso@google.com
URI:
Scott Probasco Scott Probasco
Phone: Phone:
Fax: Fax:
Email: scott@probasco.me Email: scott@probasco.me
URI: URI:
Basavaraj Patil Basavaraj Patil
 End of changes. 124 change blocks. 
588 lines changed or deleted 442 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/