draft-ietf-paws-problem-stmt-usecases-rqmts-11.txt   draft-ietf-paws-problem-stmt-usecases-rqmts-12.txt 
PAWS Mancuso, Ed. PAWS Mancuso, Ed.
Internet-Draft Probasco Internet-Draft Probasco
Intended status: Informational Patil Intended status: Informational Patil
Expires: July 29, 2013 January 25, 2013 Expires: August 2, 2013 January 29, 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-11 draft-ietf-paws-problem-stmt-usecases-rqmts-12
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. An obvious
requirement is that these additional transmissions do not interfere requirement is that these additional transmissions do not interfere
with the assigned use of the spectrum. One approach to using white with the assigned use of the spectrum. One approach to using white
skipping to change at page 2, line 11 skipping to change at page 2, line 11
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 July 29, 2013. This Internet-Draft will expire on August 2, 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
skipping to change at page 3, line 16 skipping to change at page 3, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Introduction to white space . . . . . . . . . . . . . . . 4 1.1. Introduction to white space . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
2.1. Conventions Used in This Document . . . . . . . . . . . . 5 2.1. Conventions Used in This Document . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Services . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Services . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Protocol services . . . . . . . . . . . . . . . . . . . . 6 3.1. White space database discovery . . . . . . . . . . . . . . 6
3.1.1. White space database discovery . . . . . . . . . . . . 6 3.2. Device registration with trusted database . . . . . . . . 7
3.1.2. Device registration with trusted database . . . . . . 7
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Master-slave white space networks . . . . . . . . . . . . 8
4.1.1. Master-slave white space networks . . . . . . . . . . 8 4.2. Offloading: moving traffic to a white space network . . . 10
4.1.2. Offloading: moving traffic to a white space network . 10 4.3. White space serving as backhaul . . . . . . . . . . . . . 11
4.1.3. White space serving as backhaul . . . . . . . . . . . 11 4.4. Rapid network deployment during emergency scenario . . . . 12
4.1.4. Rapid network deployment during emergency scenario . . 12 4.5. White space used for local TV broadcaster . . . . . . . . 13
4.1.5. White space used for local TV broadcaster . . . . . . 13
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 14 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Global applicability . . . . . . . . . . . . . . . . . . . 15 5.1. Global applicability . . . . . . . . . . . . . . . . . . . 15
5.2. Database discovery . . . . . . . . . . . . . . . . . . . . 17 5.2. Database discovery . . . . . . . . . . . . . . . . . . . . 17
5.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.4. Data model definition . . . . . . . . . . . . . . . . . . 17 5.4. Data model definition . . . . . . . . . . . . . . . . . . 17
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Data Model Requirements . . . . . . . . . . . . . . . . . 17 6.1. Data Model Requirements . . . . . . . . . . . . . . . . . 17
6.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 19 6.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 19
6.3. Operational Requirements . . . . . . . . . . . . . . . . . 20 6.3. Operational Requirements . . . . . . . . . . . . . . . . . 20
6.4. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 22 6.4. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 25 9. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 25
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26
11.2. Informational References . . . . . . . . . . . . . . . . . 26 11.2. Informational References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
skipping to change at page 4, line 33 skipping to change at page 4, line 33
spectrum for secondary transmissions would then depend on the spectrum for secondary transmissions would then depend on the
location of the secondary user. The fundamental issue is how to 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. Academia and
Industry have studied multiple cognitive radio [2] mechanisms for use Industry have studied multiple cognitive radio [2] mechanisms for use
in such a scenario. One simple mechanism is to use a geospatial in such a scenario. One simple mechanism is to use a geospatial
database that contains the spatial and temporal profile of all database that contains the spatial and temporal profile of all
primary licensees' spectrum usage, and require secondary users to primary licensees' spectrum usage, and require secondary users to
query the database for available spectrum that they can use at their query the database for available spectrum that they can use at their
location. Such databases can be accessible and queryable by location. Such databases can be accessible and queryable by
secondary users on the Internet . 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. secondary users via a database query protocol. Note that the IETF
has undertaken to develop a white space database query protocol (see
Protocol to Access Spectrum Database [1].
1.2. Scope 1.2. Scope
1.2.1. In Scope 1.2.1. In Scope
This document covers the requirements for a protocol to allow a This document covers the requirements for a protocol to allow a
device to access a database to obtain spectrum availability device to access a database to obtain spectrum availability
information. Such a protocol should allow a device to perform the information. Such a protocol should allow a device to perform the
following actions: following actions:
skipping to change at page 5, line 47 skipping to change at page 6, line 5
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 A unique number for each master device. Device ID An identifier for each master 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.
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. Protocol Services
3.1. Protocol services A protocol solution must enable many different potential white space
services. This section describes the features required of the
A complete protocol solution must enable many different potential protocol.
white space services. This section describes the features required
of the protocol.
3.1.1. White space database discovery 3.1. White space database discovery
White space database discovery is preliminary to creating a radio A white space radio network is created by a master device. Before
network using white space; it is a prerequisite to the use cases the master device can transmit in white space spectrum, it MUST
below. The radio network is created by a master device. Before the obtain the address of a trusted white space database, which it will
master device can transmit in white space spectrum, it must contact a query for available white space spectrum. If the master device uses
trusted database where the device can learn if any spectrum is a discovery service to locate a trusted white space database, it
available for its use. The master device will need to discover a performs the following steps:
trusted database, using the following steps:
1. The master device is connected to the Internet. 1. The master device connects to the Internet.
2. The master device constructs and sends a service request over the 2. The master device constructs and sends a request over the
Internet. Internet to a trusted discovery service.
3. If no acceptable response is received within a pre-configured 3. 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. receive service from the database. If so, it establishes contact
with the trusted database, and establishes a white space network
(as described in the following use cases).
Optionally the radio device is pre-programmed with the Internet Optionally, and in place of steps 1 - 3 above, the master device can
address of at least one trusted database. The device can establish be pre-programmed with the Internet address of one or more one
contact with a trusted database using one of the pre-programmed trusted databases. The master device can establish contact with one
Internet addresses and establish a white space network (as described of these trusted databases and establish a white space network (as
in one of the following use cases). described in the following use cases).
3.1.2. Device registration with trusted database 3.2. Device registration with trusted database
In some regulatory domains, the master device must register with the In some regulatory domains, the master device must register with the
trusted database before it queries the database for available trusted database before it queries the database for available
spectrum. Different regulatory domains may have different device spectrum. Different regulatory domains may have different device
registration requirements. registration requirements.
Figure 1 (Figure 1) shows an example deployment of this scenario. Figure 1 (Figure 1) shows an example deployment of this scenario.
---------- ----------
\|/ |Database| \|/ |Database|
skipping to change at page 8, line 19 skipping to change at page 8, line 19
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. Use cases 4.1. Master-slave white space networks
4.1.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
skipping to change at page 10, line 9 skipping to change at page 10, line 9
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 4.1.1).
4. The master optionally registers with the trusted database (see 4. The master optionally registers with the trusted database (see
Section 4.1.2). Section 4.1.2).
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 WS channels based upon its geolocation. Query list of available white space spectrum based upon its
parameters may include the master's location, device identifier, geolocation. Query parameters may include the master's location,
and antenna height. device identifier, and antenna height. Note that the master may
relay available-spectrum requests to the database on behalf of
slave devices, then transmit the obtained available-spectrum
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 duration of time for its use. and a durations of time for spectrum use. If the master made
requests on behalf of slave devices, the master may transmit the
7. The slave devices may query the master for a channel list. The obtained available-spectrum lists to the slaves (or the master
master may relay available-spectrum requests to the database on may allocate spectrum to slaves from the obtained spectrum
behalf of slave devices, then transmit the obtained available- lists).
spectrum lists to the slaves (or the master may allocate spectrum
to slaves from the obtained spectrum lists).
8. Once a slave device has been allocated available white space 7. The master may inform the database of the spectrum and power
spectrum frequencies for communication over the network, it may level it selects from the available spectrum list. If a slave
inform the master of the frequencies and power level it has device has been allocated available white space spectrum, the
chosen, and the master may, in turn, relay such usage to the slave may inform the master of the spectrum and power level it
database. has chosen, and the master may, in turn, relay such slave device
usage to the database.
9. Further communication among masters and slaves over the network 8. Further communication among masters and slaves over the white
occurs via the selected/allocated white space spectrum space network may occur via the selected/allocated white space
frequencies. spectrum frequencies.
4.1.2. Offloading: moving traffic to a white space network 4.2. Offloading: moving traffic to a white space network
This scenario is a variant of the master-slave network described in This scenario is a variant of the master-slave network described in
the previous use case. In this scenario, an Internet connectivity the previous use case. In this scenario, an Internet connectivity
service is provided over white space as a supplemental or alternative service is provided over white space as a supplemental or alternative
datapath to a more costly Internet connection (metered wire service, datapath to a more costly Internet connection (metered wire service,
metered wireless service, metered satellite service). In a typical metered wireless service, metered satellite service). In a typical
deployment scenario, an end user has a primary Internet connection, deployment scenario, an end user has a primary Internet connection,
but may prefer to use a connection to the Internet provided by a but may prefer to use a connection to the Internet provided by a
local white space master device that is connected to the Internet. local white space master device that is connected to the Internet.
skipping to change at page 11, line 39 skipping to change at page 11, line 39
consists of the following steps: consists of the following steps:
1. The slave device connects to a metered Internet service, and 1. The slave device connects to a metered 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 2. The slave device switches mode and associates with a master white
space device.* space device.*
3. The master queries the database for available white space 3. The master queries the database for available white space
spectrum and relays it to the slave device as described in spectrum and relays it to the slave device as described in
Section 4.1.1.* Section 4.1.*
4. The slave uses available white space spectrum to communicate with 4. The slave uses available white space spectrum to communicate with
the master and connect to the Internet to stream the selected the master and connect to the Internet to stream the selected
video. video.
* Note that the slave device may query the database directly for * Note that the slave device can act as a master device to query the
available white space spectrum through its metered connection to the database directly for available white space spectrum through its
Internet, thus eliminating steps 2 and 3. metered connection to the Internet, thus eliminating steps 2 and 3.
4.1.3. White space serving as backhaul 4.3. White space serving as backhaul
In this use case, an Internet connectivity service is provided to In this use case, an Internet connectivity service is provided to
users over a common wireless standard, such as Wi-Fi, with a white users over a common wireless standard, such as Wi-Fi, with a white
space master/slave network providing backhaul connectivity to the space master/slave network providing backhaul connectivity to the
Internet. Note that Wi-Fi is referenced in Figure 4 (Figure 4) and Internet. Note that Wi-Fi is referenced in Figure 4 (Figure 4) and
the following discussion, but any other technology can be substituted the following discussion, but any other technology can be substituted
in its place. in its place.
Figure 4 (Figure 4) shows an example deployment of this scenario. Figure 4 (Figure 4) shows an example deployment of this scenario.
\|/ White \|/ \|/ Wi-Fi \|/ \|/ White \|/ \|/ Wi-Fi \|/
skipping to change at page 12, line 32 skipping to change at page 12, line 32
|------| |------|
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.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.1.4. Rapid network deployment during emergency scenario 4.4. Rapid network deployment during emergency scenario
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
skipping to change at page 13, line 35 skipping to change at page 13, line 35
\ | | / \ \ | | / \
\--|------------- /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 channels from the white space database (as described in Section 4.1).
Section 4.1.1). However, the backhaul link may not be available to However, the backhaul link may not be available to all nodes, such as
all nodes, such as depicted for the left node in the above figure. depicted for the left node in the above figure. To handle RF channel
To handle RF channel allocation for such nodes, a master node with a allocation for such nodes, a master node with a backhaul link relays
backhaul link relays or proxies the database query for them. So or proxies the database query for them. So master nodes without a
master nodes without a backhaul link follow the procedure as defined backhaul link follow the procedure as defined for clients. The ad-
for clients. The ad-hoc network radios utilize the provided RF hoc network radios utilize the provided RF channels. Details on
channels. Details on forming and maintenance of the ad-hoc network, forming and maintenance of the ad-hoc network, including repair of
including repair of segmented networks caused by segments operating segmented networks caused by segments operating on different RF
on different RF channels, is out of scope of spectrum allocation. channels, is out of scope of spectrum allocation.
4.1.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.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 (Figure 6) shows an example deployment of this scenario.
\|/ |------------| |------------|
| |White Space | |White Space |
| Database | | Database |
| .---. / |------------| .---. / |------------|
|-----------| ( ) / |-----------| ( ) /
| Master | / \ | Master | / \
| |========( Internet) | |========( Internet)
|-----------| \ / |-----------| \ /
| ( ) | ( )
/|\ (---) /|\ (---)
(White Space (White Space
Broadcast) Broadcast)
skipping to change at page 16, line 5 skipping to change at page 16, line 5
to specify a schedule of use, since some primary users (for example, to specify a schedule of use, since some primary users (for example,
wireless microphones) only operate in limited time slots. wireless microphones) only operate in limited time slots.
Devices need to be able to query a database, directly or indirectly, Devices need to be able to query a database, directly or indirectly,
over the public Internet and/or private IP networks prior to over the public Internet and/or private IP networks prior to
operating in available spectrum. Information about available operating in available spectrum. Information about available
spectrum, schedule, power, etc., are provided by the database as a spectrum, schedule, power, etc., are provided by the database as a
response to the query from a device. The messaging interface needs response to the query from a device. The messaging interface needs
to be: to be:
1. Radio/air interface agnostic - The radio/air interface technology 1. Radio/air interface agnostic - Any radio/air interface technology
used by the white space device in available spectrum can be IEEE used by a white space device can be IEEE 802.11af, IEEE
802.11af, IEEE 802.15.4m, IEEE 802.16, IEEE 802.22, LTE etc. 802.15.4m, IEEE 802.16, IEEE 802.22, LTE etc. However, the
However the messaging interface between the white space device messaging interface between a master white space device and the
and the database should be agnostic to the air interface while database should be agnostic to any air interface used for such
being cognizant of the characteristics of various air-interface messaging while being cognizant of the characteristics of various
technologies and the need to include relevant attributes in the air-interface technologies and the need to include any relevant
query to the database. attributes in the query to the database.
2. Spectrum agnostic - the spectrum used by primary and secondary 2. Spectrum agnostic - the spectrum used by primary and secondary
users varies by country. Some spectrum has an explicit notion of users varies by country. Some spectrum has an explicit notion of
a "channel": a defined swath of spectrum within a band that has a "channel": a defined swath of spectrum within a band that has
some assigned identifier. Other spectrum bands may be subject to some assigned identifier. Other spectrum bands may be subject to
white space sharing, but only have actual frequency low/high white space sharing, but only have actual frequency low/high
parameters to define primary and secondary use. The protocol parameters to define primary and secondary use. The protocol
should be able to be used in any spectrum band where white space should be able to be used in any spectrum band where white space
sharing is permitted. sharing is permitted.
skipping to change at page 19, line 11 skipping to change at page 19, line 11
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 device in the
acknowledgement message. acknowledgement message.
6.2. Protocol Requirements 6.2. Protocol Requirements
P.1 The address of a database (e.g., in form of a URI) can be P.1 The master device MUST identify a database to which it can
preconfigured in a master device. The master device MUST be able register, make spectrum availability requests, etc. The master
to contact a database using a pre-configured database address. device MAY select a database by discovery at run time or by means
The master device may validate the database against a list of of a pre-programmed URI address. The master device MAY validate
discovered or configured database addresses against a list of
approved databases maintained by a regulatory body. approved databases maintained 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 38 skipping to change at page 19, line 39
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.1.2)). database (see Device Registration (Section 3.2)).
P.8 The protocol MUST support a registration acknowledgement P.8 The protocol MUST support a registration acknowledgement
including appropriate result codes. indicating the success of failure of the master device
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. These parameters MAY include any
of the parameters and attributes required to be supported in the of the parameters and attributes required to be supported in the
Data Model Requirements. 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. These parameters MAY include
any of the parameters and attributes required to be supported in any of the parameters and attributes required to be supported in
the Data Model Requirements. the Data Model Requirements.
skipping to change at page 20, line 19 skipping to change at page 20, line 24
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 include a validated by the WSDB. The validation response MUST indicate the
response code. success or failure of the validation request.
P.15 The protocol between the master device and the database MUST
support the capability to change spectrum availability information
on short notice.
P.16 The protocol between the master device and the database MUST P.15 The protocol MUST support the capability for the database to
support a spectrum availability request which specifies a inform master devices of changes to spectrum availability
geographic location as an area as well as a point information in a timely manner.
6.3. Operational Requirements 6.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 to the
Internet. 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 or have the capability to
determine its location to the required accuracy. A mobile master determine its location. A mobile master device MUST have the
device MUST have the capability to determine its location to the capability to determine its location. Locations MUST be
required accuracy. determined to the accuracy required by the applicable regulatory
domain.
O.3 The master device MUST identify a database to which it will
register, make spectrum availability requests, etc... The master
device MAY select a database for service by discovery at runtime
or the master device MAY select a database for service by means of
a pre-programmed URI address.
O.4 The master device MUST implement at least one connection method O.3 The master device MAY contact a database directly for service or
to access the database. The master device MAY contact a database the master device MAY contact a database listing server first,
directly for service or the master device MAY contact a database followed by contact to a database.
listing server first followed by contact to a database.
O.5 The master device MUST obtain an information on the rule set of O.4 The master device MUST obtain information on the rule set of the
the regulatory body that applies to the master device at its regulatory body that applies to the master device at its current
current location (and/or the location of any slave devices on location (and/or the location of any slave devices on whose behalf
whose behalf the master device is operating). the master device is operating).
O.6 The master device MAY register with the database according to O.5 The master device MAY register with the database according to
local regulatory policy. Not all master devices will be required local regulatory policy. Not all master devices will be required
to register. Specific events will initiate registration, these to register. Specific events will initiate registration, these
events are determined by regulator policy (e.g., at power up, events are determined by regulator policy (e.g., at power up,
after movement, etc...). When local regulatory policy requires after movement, etc...). When local regulatory policy requires
registration, the master device MUST register with its most registration, the master device MUST register with its most
current and up-to-date information, and MUST include all variables current and up-to-date information, and MUST include all variables
mandated by local regulator policy. mandated by local regulator policy.
O.7 A master device MUST query the database for the available O.6 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. Parameters provided to the database
MAY include device location, accuracy of the location, antenna MAY include device location, accuracy of the location, antenna
characteristic information, device identifier of any slave device characteristic information, device identifier of any slave device
requesting spectrum information, etc. requesting spectrum information, etc.
O.8 The database MUST respond to an available spectrum list request O.7 The database MUST respond to an available spectrum list request
from an authenticated and authorized device and MAY also provide from an authenticated and authorized device and MAY also provide
time constraints, maximum output power, start and stop frequencies time constraints, maximum output power, start and stop frequencies
for each band in the list and any additional requirements for for each band in the list and any additional requirements for
sensing. sensing.
O.9 According to local regulator policy, a master device MAY inform O.8 According to local regulator policy, a master device MAY inform
the database of the actual frequency usage of the master and its the database of the actual frequency usage of the master and its
slaves. The master MUST include parameters required by local slaves. The master MUST include parameters required by local
regulatory policy, e.g., device ID, manufacturer's serial number, regulatory policy, e.g., device ID, manufacturer's serial number,
spectrum usage and power level information of the master and its spectrum usage and power level information of the master and its
slaves. slaves.
O.10 After connecting to a master device's radio network a slave O.9 After connecting to a master device's radio network a slave
device MUST query the master device for a list of available device MUST query the master device for a list of available
spectrum. The slave MUST include parameters required by local spectrum. The slave MUST include parameters required by local
regulatory policy, e.g., device ID, device location. regulatory policy, e.g., device ID, device location.
O.11 According to local regulatory policy, the master device MAY O.10 According to local regulatory policy, the master device MAY
query the database with parameters received from the slave device. query the database with parameters received from the slave device.
O.12 The database MUST respond to a query from the master device O.11 The database MUST respond to a query from the master device
containing parameters from a slave device. containing parameters from a slave device.
O.13 A master device MUST repeat the query to the database for the 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., available spectrum as often as required by the regulation (e.g.,
FCC requires once per day) to verify that the operating channels FCC requires once per day) to verify that the operating channels
continue to remain available. continue to remain available.
O.14 A master device which changes its location more than a O.13 A master device which changes its location more than a
threshold distance (specified by local regulatory policy) during threshold distance (specified by local regulatory policy) during
its operation, MUST query the database for available operating its operation, MUST query the database for available operating
spectrum each time it moves more than the threshold distance spectrum each time it moves more than the threshold distance
(e.g., FCC specifies 100m) from the location it previously made (e.g., FCC specifies 100m) from the location it previously made
the query. the query.
O.15 According to local regulator policy, a master device may O.14 According to local regulator policy, a master device may
contact a database via proxy service of another master device. contact a database via proxy service of another master device.
O.16 A master device MUST be able to query the whitespace database O.15 A master device MUST be able to query the whitespace database
for spectrum availability information for a specific expected for spectrum availability information for a specific expected
coverage area around its current location. coverage area around its current location.
O.17 A Master device MUST include its unique identity in all message O.16 A Master device MUST include its unique identity in all message
exchanges with the database. exchanges with the database.
O.17 In the case of a natural disaster,emergency services may need
to use distributed white space databases on short notice. The
database should support any emergency regulations adopted by
regulators to provide priority allocation of white space spectrum
to emergency services.
6.4. Guidelines 6.4. Guidelines
The current scope of the working group is limited and is reflected in The current scope of the working group is limited and is reflected in
the requirements captured in Section 6.1. However white space the requirements captured in Section 6.1. However white space
technology itself is expected to evolve and address other aspects technology itself is expected to evolve and address other aspects
such as co-existence and interference avoidance, spectrum brokering, such as co-existence and interference avoidance, spectrum brokering,
alternative spectrum bands, etc. The design of the data model and alternative spectrum bands, etc. The design of the data model and
protocol should be cognizant of the evolving nature of white space protocol should be cognizant of the evolving nature of white space
technology and consider the following set of guidelines in the technology and consider the following set of guidelines in the
development of the data model and protocol: development of the data model and protocol:
skipping to change at page 25, line 18 skipping to change at page 25, line 25
devices for reasons other than incumbent protection 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 an unsolicited message. A malicious node can pretend
to be the white space database with which a master device has to be the white space database with which a master device has
registered or obtained spectrum information from and send a registered or obtained spectrum information from and send a
revoke message to that device. This results in denial of revoke message to that device. This results in denial of
service to the master device. service to the master device.
Threat 7: Natural disaster resulting in inability to obtain
authorization for white space spectrum use by emergency responders
In the case of a sizable natural disaster a lot of Internet
infrastructure ceases to function, emergency services users
need to reconstitute quickly and will rely on establishing
radio WANs. In such cases, radio WAN gear that has been unused
suddenly needs to be pressed into action. And the radio WANs
need frequency authorizations to function. Regulatory entities
may also authorize usage of additional spectrum in the affected
areas. The white space radio entities may need to establish
communication with a database and obtain authorizations. In
cases where communication with the white space database fails,
the white space devices cannot utilize white space spectrum.
Emergency services, which require more spectrum precisely at
locations where network infrastructure is malfunctioning or
overloaded, backup communication spectrum and distributed white
space databases are needed to overcome such circumstances.
Alternatively there may be other mechanisms which allow the use
of spectrum by emergency service equipment without strict
authorization or with liberal interpretation of the regulatory
policy for white space usage.
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 6.1 (Section 6.1).
9. Summary and Conclusion 9. Summary and Conclusion
Wireless spectrum is a scarce resource. As the demand for spectrum Wireless spectrum is a scarce resource. As the demand for spectrum
grows, there is a need to more efficiently utilize the available and grows, there is a need to more efficiently utilize the available and
allocated spectrum. Cognitive radio technologies enable the allocated spectrum. Cognitive radio technologies enable the
efficient usage of spectrum via means such as sensing or by querying efficient usage of spectrum via means such as sensing or by querying
a database to determine available spectrum at a given location for a database to determine available spectrum at a given location for
 End of changes. 57 change blocks. 
160 lines changed or deleted 135 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/