draft-ietf-paws-problem-stmt-usecases-rqmts-08.txt   draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt 
Working Group Draft S. Probasco, Ed. PAWS Mancuso, Ed.
Internet-Draft B. Patil Internet-Draft Probasco
Intended status: Informational August 30, 2012 Intended status: Informational Patil
Expires: March 3, 2013 Expires: June 21, 2013 December 18, 2012
Protocol to Access White Space database: PS, use cases and rqmts Protocol to Access White Space (PAWS) Database: Use Cases and
draft-ietf-paws-problem-stmt-usecases-rqmts-08 Requirements
draft-ietf-paws-problem-stmt-usecases-rqmts-09
Abstract Abstract
[Editor's Note: This version is submitted for review. A final, post-
review version is anticipated that will supersede this version].
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 the with the assigned use of the spectrum. One approach to using white
white space spectrum at a given time and location is to verify with a space spectrum at a given time and location is to verify spectrum
database for available channels. availability with a database that manages spectrum sharing and
provides spectrum-availability information.
This document describes a number of possible use cases of white space This document describes a number of possible use cases of white space
spectrum and technology as well as a set of requirements for the spectrum and technology as well as a set of requirements for the
database query protocol. The concept of TV white spaces is described database query protocol. The concept of white spaces is described
including the problems that need to be addressed to enable white along with the problems that need to be addressed to enable white
space spectrum for additional uses without causing interference to space spectrum for additional uses without causing interference to
currently assigned use. Use of white space is enabled by querying a currently assigned use. Use of white space is enabled by querying a
database which stores information about the channel availability at database that stores information about spectrum availability at any
any given location and time. given location and time.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 March 3, 2013. This Internet-Draft will expire on June 21, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 9 skipping to change at page 3, line 9
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Introduction to white space . . . . . . . . . . . . . . . 4 1.1. Introduction to white space . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 6 1.2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 6 1.2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
2.1. Conventions Used in This Document . . . . . . . . . . . . 7 2.1. Conventions Used in This Document . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Use Cases and Protocol Services . . . . . . . . . . . . . . . 6
3.1. The concept of Cognitive Radio . . . . . . . . . . . . . . 8 3.1. Protocol services . . . . . . . . . . . . . . . . . . . . 6
3.2. Background information on white space in the US . . . . . 9 3.1.1. White space database discovery . . . . . . . . . . . . 7
3.3. Background information on white space in the UK . . . . . 9 3.1.2. Device registration with trusted database . . . . . . 7
3.4. Air Interfaces . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Use cases and protocol services . . . . . . . . . . . . . . . 10 3.2.1. Master-slave white space networks . . . . . . . . . . 8
4.1. Protocol services . . . . . . . . . . . . . . . . . . . . 10 3.2.2. Offloading: moving traffic to a white space network . 10
4.1.1. White space database discovery . . . . . . . . . . . . 10 3.2.3. White space serving as backhaul . . . . . . . . . . . 12
4.1.2. Device registration with trusted Database . . . . . . 11 3.2.4. Rapid network deployment during emergency scenario . . 12
4.2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.5. White space used for local TV broadcaster . . . . . . 13
4.2.1. Hotspot: urban Internet connectivity service . . . . . 12 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 14
4.2.2. Wide-Area or Rural Internet broadband access . . . . . 15 4.1. Global applicability . . . . . . . . . . . . . . . . . . . 15
4.2.3. Offloading: moving traffic to a white space network . 18 4.2. Database discovery . . . . . . . . . . . . . . . . . . . . 17
4.2.4. White space serving as backhaul . . . . . . . . . . . 20 4.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.5. Rapid deployed network for emergency scenario . . . . 21 4.4. Data model definition . . . . . . . . . . . . . . . . . . 17
4.2.6. Mobility . . . . . . . . . . . . . . . . . . . . . . . 22 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.7. Indoor Networking . . . . . . . . . . . . . . . . . . 25 5.1. Normative Requirements . . . . . . . . . . . . . . . . . . 17
4.2.8. Machine to Machine (M2M) . . . . . . . . . . . . . . . 26 5.2. Non-normative requirements . . . . . . . . . . . . . . . . 20
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 28 5.3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Global applicability . . . . . . . . . . . . . . . . . . . 29 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
5.2. Database discovery . . . . . . . . . . . . . . . . . . . . 30 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
5.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 31 8. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 26
5.4. Data model definition . . . . . . . . . . . . . . . . . . 31 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1. Normative Requirements . . . . . . . . . . . . . . . . . . 31 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
6.2. Non-normative requirements . . . . . . . . . . . . . . . . 34 10.2. Informational References . . . . . . . . . . . . . . . . . 26
6.3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
8. Security Considerations . . . . . . . . . . . . . . . . . . . 37
9. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 40
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
11.1. Normative References . . . . . . . . . . . . . . . . . . . 40
11.2. Informative References . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
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 user but are unused or radio spectrum that are assigned to a licensed (primary) user but are
unoccupied at specific locations and times are defined as "white unused or unoccupied at specific locations and times are defined as
space". The concept of allowing additional transmissions (which may "white space." The concept of allowing additional (secondary)
or may not be licensed) in white space is a technique to "unlock" transmissions (which may or may not be licensed) in white space is a
existing spectrum for new use. An obvious requirement is that these technique to "unlock" existing spectrum for new use. An obvious
additional transmissions do not interfere with the assigned use of requirement is that these secondary transmissions do not interfere
the spectrum. One interesting observation is that often, in a given with the assigned use of the spectrum. One interesting observation
physical location, the assigned user(s) may not be using the entire is that often, in a given physical location, the primary user(s) may
band assigned to them. The available spectrum for additional not be using the entire band assigned to them. The available
transmissions would then depend on the location of the additional spectrum for secondary transmissions would then depend on the
user. The fundamental issue is how to determine for a specific location of the secondary user. The fundamental issue is how to
location and specific time, if any of the assigned spectrum is determine, for a specific location and specific time, if any of the
available for additional use. Academia and Industry have studied assigned spectrum is available for secondary use. Academia and
multiple cognitive radio mechanisms for use in such a scenario. One Industry have studied multiple cognitive radio [1] mechanisms for use
simple mechanism is to use a geospatial database that records the in such a scenario. One simple mechanism is to use a geospatial
assigned users occupation, and require the additional users to check database that contains the spatial and temporal profile of all
the database prior to selecting what part of the spectrum they use. primary licensees' spectrum usage, and require secondary users to
Such databases could be available on the Internet for query by query the database for available spectrum that they can use at their
additional users. location. Such databases can be accessible and queryable by
secondary users on the Internet .
Spectrum useable for data communications, especially wireless Any entity that is assigned spectrum that is not densely used may be
Internet communications, is scarce. One area which has received much asked by a governmental regulatory agency to share it to allow for
attention globally is the TV white space: portions of the TV band more intensive use of the spectrum. Providing a mechanism by which
that are not used by broadcasters in a given area. In 2008 the secondary users share the spectrum with the primary user is
United States regulator (the FCC) took initial steps when they
published their first ruling on the use of TV white space, and then
followed it up with a ruling in 2010 [FCC Ruling] that established
the basic foundation for TV white space service in the US. In May
2012 the FCC issued minor updates further refining the previous
ruling [3MOO]. Finland passed an Act in 2009 enabling testing of
cognitive radio systems in the TV white space. The ECC has completed
Report 159 [ECC Report 159] containing requirements for operation of
cognitive radio systems in the TV white space. Ofcom published in
2004 their Spectrum Framework Review [Spectrum Framework Review] and
their Digital Dividend Review [DDR] in 2005, with proposals from 2009
onwards to access TV white space, leading to the 2011 Ofcom Statement
Implementing Geolocation [Ofcom Implementing] which has been followed
by draft requirements for TV white space devices [Ofcom
Requirements]. More countries are expected to provide access to
their TV spectrum in similar ways. Any entity that is assigned
spectrum that is not densely used may be asked to give it up in one
way or another for more intensive use. Providing a mechanism by
which additional users share the spectrum with the assigned user is
attractive in many bands in many countries. attractive in many bands in many countries.
Television transmission until now has primarily been analog. The This document includes the problem statement followed by use cases
switch to digital transmission has begun. As a result the spectrum and requirements associated with the use of white space spectrum by
assigned for television transmission can now be more effectively
used. Unused channels and bands between channels can be used by
additional users as long as they do not interfere with the service
for which that channel is assigned. While urban areas tend to have
dense usage of spectrum and a number of TV channels, the same is not
true in semi-rural, rural and remote areas. There can be a number of
unused TV channels in such areas that can be used for other services.
Figure 1 shows TV white space within the lower UHF band:
Avg |
usage| |-------------- White Space
| | | | | |
0.6| || || V V ||
| || ||| | ||
0.4| || |||| | ||
| || |||| | ||<----TV transmission
0.2| || |||| | ||
|----------------------------------------
400 500 600 700 800
Frequency in MHz ->
Figure 1: High level view of TV White Space
The fundamental issue is how to determine for a specific location and
specific time if any of the spectrum is available for additional use.
There are two dimensions of use that may be interesting: space (the
area in which an additional user would not interfere with the
assigned use), and time: when the additional transmission would not
interfere with the assigned use. In this discussion, we consider the
time element to be relatively long term (e.g. hours in a day) rather
than short term (e.g. fractions of a second). Location in this
discussion is geolocation: where the transmitters (and sometimes
receivers) are located relative to one another. In operation, the
database records the assigned user's transmitter (and some times
receiver) locations along with basic transmission characteristics
such as antenna height, and power. Using rules established by the
local regulator, the database calculates an exclusion zone for each
assigned user, and attaches a time schedule to that use. The
additional user queries the database with its location. The database
intersects the exclusion zones with the queried location, and returns
the portion of the spectrum not in any exclusion zone. Such methods
of geospatial database query to avoid interference have been shown to
achieve favorable results, and are thus the basis for rulings by the
FCC and reports from ECC and Ofcom. In any country, the rules for
which assigned entities are entitled to protection, how the exclusion
zones are calculated, and what the limits of use are by additional
users may vary. However, the fundamental notion of recording
assigned users, calculating exclusion zones, querying by location and
returning available spectrum (and the schedule for that spectrum) are
common.
This document includes the problem statement, use cases 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.
1.2. Scope 1.2. Scope
1.2.1. In Scope 1.2.1. In Scope
This document applies only to communications required for basic This document covers the requirements for a protocol to allow a
service in TV white spaces. The protocol will enable a white space device to access a database to obtain spectrum availability
radio device to complete the following tasks: information. Such a protocol should allow a device to perform the
following actions:
1. Determine the relevant white space database to query. 1. Determine the relevant white space database to query.
2. Connect to the database using a well-defined access method. 2. Connect to the database using a well-defined access method.
3. Register with the database using a well-defined protocol. 3. Register with the database using a well-defined protocol.
4. Provide its geolocation and perhaps other data to the database 4. 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.
5. Receive in response to the query a list of currently available 5. Receive in response to the query a list of available white space
white space channels or frequencies using a well-defined format frequencies using a well-defined format for the information.
for the information.
6. Send an acknowledgment to the database with information 6. Send an acknowledgment to the database with information
containing channels selected for use by the device. containing channels selected for use by the device.
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:
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.
Provisioning (releasing new spectrum for white space use)
2. Provisioning (releasing new spectrum for white space use).
2. Conventions and Terminology 2. Conventions and Terminology
2.1. Conventions Used in This Document 2.1. Conventions Used in This Document
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].
2.2. Terminology 2.2. Terminology
Database Database A database is an entity that contains current information
about available spectrum at a given location and time as well as
In the context of white space and cognitive radio technologies, other types of information related to spectrum availability and
the database is an entity which contains, but is not limited to, usage.
current information as required by by the regulatory policies
about available spectrum at any given location and time, and other
types of related (to the white space spectrum) or relevant
information.
Device Class
Identifies classes of devices defined by Regional Regulators,
including fixed, mobile, portable, etc... May also indicate if
the device is indoor or outdoor.
Device ID
A unique number for each master device and slave device that
identifies the manufacturer, model number and serial number.
Location Based Service
An application or device which provides data, information or
service to a user based on their location.
Master Device
A device which queries the WS Database to find out the available Device Class Identifies classes of devices including fixed, mobile,
operating channels. portable, etc... May also indicate if the device is indoor or
outdoor.
Protected Entity Device ID A unique number for each master device and slave device
that identifies the manufacturer, model number, and serial number.
An assigned user of white space spectrum which is afforded Location Based Service An application or device that provides data,
protection against interference by additional users (white space information, or a service to a user based on their location.
devices) for its use in a given area and time.
Protected Contour Master Device A device that queries a database to obtain available
spectrum information.
The exclusion area for a Protected Entity, held in the database Protected Entity An assigned (primary) user of radio spectrum that
and expressed as a polygon with geospatial points as the vertices. is afforded protection against interference by secondary users.
Slave Device Protected Contour The exclusion area for a Protected Entity,
recorded in the database, which can be expressed as a polygon with
geospatial points as vertices.
A device which uses the spectrum made available by a master Radio Access Technology The Radio Access Technology (RAT) used by a
device, and cannot query the database directly. device (which may be required under regulatory rules as part of a
device's registration information.
TV White Space Slave Device A device that queries the database through a Master
Device.
TV white space refers specifically to radio spectrum which has White Space (WS) Radio spectrum that is available for secondary use
been allocated for TV broadcast, but is not occupied by a TV
broadcast, or other assigned user (such as a wireless microphone),
at a specific location and time. at a specific location and time.
TV White Space Device (TVWSD) 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 White Space Device that operates in the TV bands. device such as an access point, base station, or cell phone.
White Space (WS)
Radio spectrum which is not fully occupied at a specific location
and time.
White Space Device (WSD)
A device which opportunistically uses some part of white space
spectrum. A white space device can be an access point, base
station, a portable device or similar. A white space device may
be required by local regulations to query a database with its
location to obtain information about available spectrum.
3. Prior Work
3.1. The concept of Cognitive Radio
A cognitive radio uses knowledge of the local radio environment to
dynamically adapt its own configuration and function properly in a
changing radio environment. Knowledge of the local radio environment
can come from various technology mechanisms including sensing
(attempting to ascertain primary users by listening for them within
the spectrum), location determination and Internet connectivity to a
database to learn the details of the local radio environment. White
Space is one implementation of cognitive radio. Because a cognitive
radio adapts itself to the available spectrum in a manner that
prevents the creation of harmful interference, the spectrum can be
shared among different radio users.
3.2. Background information on white space in the US
Television transmission in the United States has moved to the use of
digital signals as of June 12, 2009. Since June 13, 2009, all full-
power U.S. television stations have broadcast over-the-air signals in
digital only. An important benefit of the switch to all-digital
broadcasting is that it freed up parts of the valuable broadcast
spectrum. More information about the switch to digital transmission
is at [DTV].
Besides the switch to digital transmission for TV, the guard bands
that exist to protect the signals between stations can be used for
other purposes. The FCC has made this spectrum available for
unlicensed use and this is generally referred to as white space.
Please see the details of the FCC ruling and regulations in [FCC
Ruling]. The spectrum can be used to provide wireless broadband as
an example.
3.3. Background information on white space in the UK
Background information on white space in UK Since its launch in 2005,
Ofcom's Digital Dividend Review [DDR] has considered how to make the
spectrum freed up by digital switchover available for new uses,
including the capacity available within the spectrum that is retained
to carry the digital terrestrial television service. Similarly to
the US, this interleaved or guard spectrum occurs because not all the
spectrum in any particular location will be used for terrestrial
television and so is available for other services, as long as they
can interleave their usage around the existing users.
In its September 2011 Statement [Ofcom Implementing] Ofcom says that
a key element in enabling white space usage in the TV bands is the
definition and provision of a database which, given a device's
location, can tell the device which frequency channels and power
levels it is able to use without causing harmful interference to
other licensed users in the vicinity. Ofcom will specify
requirements to be met by such geolocation databases. It also says
that the technology has the possibility of being usefully applied
elsewhere in the radio spectrum to ensure it is used to maximum
benefit. For example, it may have potential in making spectrum
available for new uses following any switch to digital radio
services. Alternatively it may be helpful in exploiting some of the
public sector spectrum holdings. Ofcom will continue to consider
other areas of the radio spectrum where white space usage may be of
benefit.
3.4. Air Interfaces
Efforts are ongoing to specify air-interfaces for use in white space
spectrum. IEEE 802.11af, IEEE 802.15.4m and IEEE 802.22 are all
examples. Other air interfaces could be specified in the future such
as LTE.
4. Use cases and protocol services 3. Use Cases and Protocol Services
There are many potential use cases that could be considered for the There are many potential use cases for white space spectrum - for
TV white space spectrum. Providing broadband Internet access in example, providing broadband Internet access in urban and densely-
urban and densely populated hotspots, rural and underserved areas are populated hotspots as well as rural and underserved areas. Available
examples. Available channels may also be used to provide Internet white space spectrum may also be used to provide Internet 'backhaul'
'backhaul' for traditional Wi-Fi hotspots, or by towns and cities to for traditional Wi-Fi hotspots or for use by towns and cities to
monitor/control traffic lights or read utility meters. Still other monitor/control traffic lights, read utility meters, and the like.
use cases include the ability to offload data traffic from another Still other use cases include the ability to offload data traffic
Internet access network (e.g. 3G cellular network) or to deliver from another Internet access network (e.g., 3G cellular network) or
location based services. Some of these use cases are described in to deliver location-based services. Some of these use cases are
the following sections. described in the following sections.
4.1. Protocol services 3.1. Protocol services
A complete protocol solution must provide all services that are A complete protocol solution must enable all potential white space
essential to enable the white space paradigm. Before a white space services. This section describes the features required of the
device can begin operating it needs to know what channels are protocol.
available by sending a query to a white space database for a list of
available channels, the white space device must have the capability
to first locate or "discover" a suitable database. Additionally,
some regulatory authorities require the white space device to
register with the database as a first step. This section describes
the features required from the protocol.
4.1.1. White space database discovery 3.1.1. White space database discovery
White space database discovery is preliminary to creating a radio White space database discovery is preliminary to creating a radio
network using white space; it is a prerequisite to the use cases network using white space; it is a prerequisite to the use cases
below. The radio network is created by a master device. Before the below. The radio network is created by a master device. Before the
master device can transmit in white space spectrum, it must contact a master device can transmit in white space spectrum, it must contact a
trusted database where the device can learn if any channels are trusted database where the device can learn if any spectrum is
available for it to use. The master device will need to discover a available for its use. The master device will need to discover a
trusted database in the relevant regulatory domain, using the trusted database, using the following steps:
following steps:
1. The master device is connected to the Internet by any means other 1. The master device is connected to the Internet.
than using the white space radio. A local regulator may identify
exception cases where a master may initialize over white space
(e.g. the FCC allows a master to initialize over the TV white
space in certain conditions).
2. The master device constructs and sends a service request over the 2. The master device constructs and sends a service request over the
Internet to discover availability of trusted databases in the Internet to discover availability of trusted databases in the
local regulatory domain and waits for responses. local regulatory domain and waits for responses.
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.
Optionally the radio device is pre-programmed with the Internet Optionally the radio device is pre-programmed with the Internet
address of at least one trusted database. The device can establish address of at least one trusted database. The device can establish
contact with a trusted database using one of the pre-programmed contact with a trusted database using one of the pre-programmed
Internet addresses and establish a white space network (as described Internet addresses and establish a white space network (as described
in one of the following use cases). in one of the following use cases).
Optionally the initial query will be made to a listing approved by 3.1.2. Device registration with trusted database
the national regulator for the domain of operation (e.g. a website
either hosted by or under control of the national regulator) which
maintains a list of WS databases and their Internet addresses. The
query results in the list of databases and their Internet addresses
being sent to the master, which then evaluates the response to
determine if a trusted database can be identified where the master
device is able to register and receive service from the database.
4.1.2. Device registration with trusted Database
Registration may be preliminary to creating a radio network using In some regulatory domains, the master device must register with the
white space; in some regulatory domains, for some device types, it is trusted database before it queries the database for available
a prerequisite to the use cases below. The radio network is created spectrum. Different regulatory domains may have different device
by a master device. Before the master device can transmit in white registration requirements.
space spectrum, it must contact a trusted database where the device
can learn if any channels are available for it to use. Before the
database will provide information on available radio channels, the
master device must register with the trusted database. Specific
requirements for registration come from individual regulatory domains
and may be different.
Figure 2 shows an example deployment of this scenario. Figure 1 (Figure 1) shows an example deployment of this scenario.
\|/ ---------- \|/ ----------
| |Database| | |Database|
| .---. /--------- | .---. / ---------
|-|---------| ( ) / |-|---------| ( ) /
\|/ | Master | / \ | Master | / \
| / | |========( Internet ) | |========( Internet)
| / |-----------| \ / |-----------| \ /
+-|----+ (AirIF) ( ) ( )
|Master| / (----) (---)
| | /
+------+
Figure 2: Example illustration of registration requirement in white Figure 1: Example illustration of registration requirement in white
space use-case space use-case
A simplified operational scenario showing registration consists of A simplified operational scenario showing registration consists of
the following steps: the following steps:
1. The master device must register with its most current and up-to- 1. If required by the regulatory domain, the master device registers
date information. Typically the master device will register with its most current and up-to-date information. If subject to
prior to operating in white space for the first time after power registration, typically the master device will register after
up, after changing location by a predetermined distance, and power up, after changing location by a predetermined distance,
after regular time intervals. and after prescribed time intervals.
2. The master device shall provide to the database during
registration all information required according to local
regulatory requirements. This information may include, but is
not limited to, the Device ID, serial number assigned by the
manufacturer the device's location, device antenna height above
ground, name of the individual or business that owns the device,
name of a contact person responsible for the device's operation
address for the contact person, email address for the contact
person and phone number of the contact person.
3. The database shall respond to the registration request with an
acknowledgement code to indicate the success or failure of the
registration request. Additional information may be provided
according to local regulator requirements.
4.2. Use cases
4.2.1. Hotspot: urban Internet connectivity service
In this use case Internet connectivity service is provided in a
"hotspot" to local users. Typical deployment scenarios include urban
areas where Internet connectivity is provided to local businesses and
residents, and campus environments where Internet connectivity is
provided to local buildings and relatively small outdoor areas. This
deployment scenario is typically characterized by multiple masters
(APs or hotspots) in close proximity, with low antenna height, cells
with relatively small radius (a few kilometers or less), and limited
numbers of available radio channels. Many of the masters/APs are
assumed to be individually deployed and operated, i.e. there is no
coordination between many of the masters/APs. The masters/APs in
this scenario use a TDD radio technology. Each master/AP has a
connection to the Internet and may provide Internet connectivity to
other master and slave devices.
Figure 3 shows an example deployment of this scenario.
--------
|Device|\ \|/ ----------
| 1 | (TDD AirIF)\ | |Database|
-------- \ | (----) /---------
| \ |-|---------| ( ) /
| \| Master | / \
-------- /| |========( Internet )
|Device| /(TDD AirIF)/ |-----------| \ /
| 2 | / / ( )
------- / (----)
o | /
o | (TDD AirIF)
o | /
--------/
|Device|
| n |
--------
Figure 3: Hotspot service using TV white space spectrum
Once a master/AP has been correctly installed and configured, a
simplified power up and operation scenario utilizing TV White Space
to provide Internet connectivity service to slave devices, including
the ability to clear WSDs from select channels, is described. This
scenario consists of the following steps:
1. The master/AP powers up; however its WS radio and all other WS
capable devices will power up in idle/listen only mode (no
active transmissions on the WS frequency band). A local
regulator may identify exception cases where a master may
initialize over white space (e.g. the FCC allows a master to
initialize over TV white space in certain conditions).
2. The master/AP has Internet connectivity, determines its location
(either from location determination capability or from saved
value that was set during installation), and establishes a
connection to a trusted white space database (see
Section 4.1.1).
3. The master/AP registers with the trusted database according to
regulatory domain requirements (see Section 4.1.2).
4. Following the successful registration process (if registration
is required), the master/AP will send a query to the trusted
database requesting a list of available WS channels based upon
its geolocation. The complete set of parameters to be provided
from the master to the database is specified by the local
regulator. Parameters may include WSD location, accuracy of
that location, device antenna height, device identifier of a
slave device requesting channel information.
5. If the master/AP has met all regulatory domain requirements
(e.g. been previously authenticated, etc), the database responds
with a list of available white space channels that the master
may use, and optionally a duration of time for their use,
associated maximum power levels or a notification of any
additional requirements for sensing.
6. Once the master/AP has met all regulatory domain requirements
(e.g. authenticated the WS channel list response message from
the database, etc), the AP selects one or more available WS
channels from the list. Prior to initiating transmission, if
required by local regulation, the master/AP informs the database
of the frequencies and power level it has chosen. This
reporting of the frequencies and power levels to the database is
repeated for each slave device that associated with the master.
7. The slave or user device scans the TV bands to locate a
master/AP transmission, and associates with the AP.
8. The slave/user device queries the master for a channel list. In
the query the slave/user device provides attributes that are
defined by local regulations. These may include the slaves'
Device ID and its geolocation.
9. Once the master/AP has met all regulatory domain requirements
(e.g. validating the Device ID with the trusted database, etc)
the master provides the list of channels locally available to
the slave/user device. Prior to initiating transmission, if
required by local regulation, the slave device informs the
master/AP of the frequencies and power level it has chosen, and
the master/AP relays this information to the database.
10. The master sends an enabling signal to establish that the slave/
user device is still within reception range of the master. This
signal shall be encoded to ensure that the signal originates
from the master that provided the available list of channels.
11. Periodically, at an interval established by the local regulator,
the slave/user device must receive an enabling signal from the
master that provided the available list of channels or contact a
master to re-verify or re-establish the list of available
channels.
12. The master/AP must periodically repeat the process to request a
channel list from the database, steps 4 through 6 above. The
frequency to repeat the process is determined by the local
regulator. If the response from the database indicates a
channel being used by the master/AP is not available, the
master/AP must stop transmitting on that channel immediately.
In addition or optionally, the database may send a message to
the master/AP to rescind the availability of one or more
channels. The master/AP must stop transmitting on that channel
immediately.
13. The slave or user device must periodically repeat the process to 2. To register with the database, the master device sends the
request a channel list from the master/AP, steps 8 and 9 above. database the registration information required under regulatory
The frequency to repeat the process is determined by the local rules. This information may include the Device ID, serial number
regulator. If the response from the master/AP indicates that a assigned by the manufacturer, device location, device antenna
channel being used by the slave or user device is not available, height above ground, name of the individual or business that owns
the slave or user device must stop transmitting on that channel the device, and the name, street and email address, and telephone
immediately. In addition or optionally, the database may send a number of a contact person responsible for the device's
message to the master/AP to rescind the availability of one or operation.
more channels. The master/AP must then notify the slave or user
device of the rescinded channels. The slave or user device must
stop transmitting on that channel immediately.
4.2.2. Wide-Area or Rural Internet broadband access 3. The database responds to the registration request with an
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 according to regulatory requirements.
In this use case, Internet broadband access is provided as a Wide- 3.2. Use cases
Area Network (WAN) or Wireless Regional Area Network (WRAN). A
typical deployment scenario is a wide area or rural area, where
Internet broadband access is provided to local businesses and
residents from a master (i.e., BS) connected to the Internet. This
deployment scenario is typically characterized by one or more fixed
master(s)/BS(s), cells with relatively large radius (tens of
kilometers, up to 100 km), and a number of available radio channels.
Some of the masters/BSs may be deployed and operated by a single
entity, i.e., there can be centralized coordination between these
masters/BSs, whereas other masters/BSs may be deployed and operated
by operators competing for the radio channels where decentralized
coordination using the air-interface would be required. The BS in
this scenario uses a TDD radio technology and transmits at or below a
transmit power (EIRP) limit established by the local regulator. Each
base station has a connection to the Internet and may provide
Internet connectivity to multiple slaves/user devices. End-user
terminals or devices may be fixed or portable.
Figure 4 shows an example deployment of this scenario. 3.2.1. Master-slave white space networks
------- There are a number of common scenarios in which a master white space
|Slave|\ \|/ ---------- device will act as proxy or mediator for one or more slave devices
|Dev 1| (TDD AirIF) | |Database| using its connection to the Internet to query the database for
------- \ | .---. /---------- available spectrum for itself and for one or more slave devices.
o \ |-|---------| ( ) / These slave devices may be fixed or mobile, in close proximity with
o | Master | / \ each other (indoor network or urban hotspot), or at a distance (rural
o / | (BS) |========( Internet ) WAN). Once slave devices switch to white space spectrum for their
o / |-----------| \ / communications, they may connect through the master to the Internet
------- (TDD AirIF) ( ) or use white space spectrum for intra-network communications only.
|Slave| / (----) The master device can continue to arbitrate and control white space
|Dev n| communications by slave devices, and may notify them when they are
------- required to change white space frequencies or cease white space
communications.
Figure 4: Rural Internet broadband access using TV white space Figure 2 (Figure 2) depicts the general architecture such a simple
spectrum master-slave network, in which the master device communicates on its
own behalf and on behalf of slave devices with a white space
database.
--------
|Slave |
|Device| \ \|/ ----------
| 1 | (Air) | |Database|
-------- \ | (----) /|--------|
| \ ------|------ ( ) /
| \| Master | / \
-------- /| |======= ( Internet )
|Slave | / | Device | \ /
|Device| (Air) | | ( )
| 2 | / |-----------| (----)
|------- /
o | /
o | (Air)
o | /
-------- /
|Slave | /
|Device| /
| n |
--------
Once the master/BS has been professionally installed and configured, Figure 2: Master-Slave White Space Network
a simplified power up and operation scenario utilizing TV White Space
to provide rural Internet broadband access consists of the following
steps:
1. The master/BS powers up; however its WS radio and all other WS The protocol requirements for these master-slave device and other
capable devices will power up in idle/listen-only mode (no similar scenarios is essentially the same: the protocol must support
active transmissions on the WS frequency band). the ability of a master device to make available-spectrum query
requests on behalf of slave devices, passing device identification,
geolocation, and other slave device parameters to the database as
required to obtain a list of white space spectrum available for use
by one or more slave devices. Of course, different use cases will
use this spectrum information in different ways, and the details of
master/slave communications may be different for different use cases.
2. The master/BS has Internet connectivity, determines its location Common steps may occur in master-slave networks include the
(either from location determination capability or from a saved following:
value that was set during installation), and establishes a
connection to a trusted white space database (see
Section 4.1.1).
3. The master/BS registers with the trusted database service (see 1. The master device powers up.
Section 4.1.2). Meanwhile the DB administrator may be required
to store and forward the registration information to the
regulatory authority. If a trusted white space database service
is not discovered, further operation of the WRAN may be allowed
according to local regulator policy (in this case operation of
the WRAN is outside the scope of the PAWS protocol).
4. Following the successful registration process (if registration 2. Slave devices power up and associate with the master device via
is required), the master/BS will send a query to the trusted Wi-Fi or some other over-the-air non-white space spectrum. Until
database requesting a list of available WS channels based upon the slave device is allocated white space spectrum, any master-
its geolocation. The complete set of parameters to be provided slave or slave-slave communications occurs over such non-white
from the master to the database is specified by the local space spectrum.
regulator. Parameters may include WSD identifier, location,
accuracy of that location, device antenna height, etc...
5. If the master/BS has been previously authenticated, the database 3. The master has Internet connectivity, determines (or knows) its
responds with a list of available white space channels that may location, and establishes a connection to a trusted white space
be used by the master/BS and optionally a maximum transmit power database (see Section 4.1.1).
(EIRP) for each channel, a duration of time the channel may be
used or a notification of any additional requirement for
sensing.
6. Once the master/BS authenticates the WS channel list response 4. The master optionally registers with the trusted database (see
message from the database, the master/BS selects an available WS Section 4.1.2).
channel(s) from the list. Such selection may be improved based
on a set of queries to the DB involving a number of hypothetical
slave or user devices located at various locations over the
expected service area so that the final intersection of these
resulting WS channel lists allows the selection of a channel
that is likely available over the entire service area to avoid
potential interference at the time of slave/user terminal
association. The operator may also disallow some channels from
the list to suit local needs if required.
7. The slave or user device scans the TV bands to locate a WRAN 5. The master sends a query to the trusted database requesting a
transmission, and associates with the master/BS. list of available WS channels based upon its geolocation. Query
parameters may include the master's location, device identifier,
and antenna height.
8. In some regulatory domains, before a master device sends a 6. The database responds to the master's query with a list of
channel list, the slave/user device provides its geolocation to available white space spectrum, associated maximum power levels,
the BS which, in turn, queries the database for a list of and a duration of time for its use.
channels available at the slave's geolocation.
9. Once this list of available channels is received from the 7. The slave devices may query the master for a channel list. The
database by the master, the latter will decide, based on this master may relay available-spectrum requests to the database on
list of available channels and on the lists for all its other behalf of slave devices, then transmit the obtained available-
associated slaves/user devices whether it should: a) continue spectrum lists to the slaves (or the master may allocate spectrum
operation on its current channel if this channel is available to to slaves from the obtained spectrum lists).
all slaves/user devices, b) continue operation on its current
channel and not allow association with the new slave/user device
in case this channel is not available at its location or c)
change channel to accommodate the new slave. In the latter
case, the master will notify all its associated slaves/user
devices of the new channel to which they have to move.
10. The master/BS must periodically repeat the process to request a 8. Once a slave device has been allocated available white space
list of available channels from the database for itself and for spectrum frequencies for communication over the network, it may
all its associated slaves/user devices. If the response from inform the master of the frequencies and power level it has
the database indicates that the channel being used by the chosen, and the master may, in turn, relay such usage to the
master/BS is no longer available for its use, the master/BS must database.
indicate the new operating channel to all its slave/user
terminals, stop transmitting on the current channel and move to
the new operating channel immediately. If the channel that a
slave/user terminal is currently using is no longer included in
the list of locally available channels, the master may either
drop its association with the slave/user device so that this
device ceases all operation on its current channel or the master
may decide to move the entire cell to another channel to
accommodate the slave/user terminal and indicate the new
operating channel to all its slave/user devices before dropping
the link. The slave/user devices may then move to the
identified new operating channel or scan for another WRAN
transmission on a different channel. The frequency to repeat
the process is determined by the local regulator.
11. The slave/user device must transmit its new geographic location 9. Further communication among masters and slaves over the network
every time it changes so that the repeated process described occurs via the selected/allocated white space spectrum
under item 10 can rely on the most up-to-date geolocation of the frequencies.
slave/user device.
4.2.3. Offloading: moving traffic to a white space network 3.2.2. Offloading: moving traffic to a white space network
In this use case internet connectivity service is provided over TV This scenario is a variant of the master-slave network described in
white space as a supplemental or alternative datapath to a 3G or the previous use case. In this scenario, an Internet connectivity
other internet connection. In a typical deployment scenario an end service is provided over white space as a supplemental or alternative
user has a primary internet connection such as a 3G cellular packet datapath to a more costly Internet connection (metered wire service,
data subscription. The user wants to use a widget or application to metered wireless service, metered satellite service). In a typical
stream video from an online service (e.g. youtube) to their device. deployment scenario, an end user has a primary Internet connection,
Before the widget starts the streaming connection it checks but may prefer to use a connection to the Internet provided by a
connectivity options available at the current time and location. local white space master device that is connected to the Internet.
Both 3G cellular data is available as well as TVWS connectivity (the
user is within coverage of a TVWS master -- hotspot, WAN, WRAN or
similar). The user may decide for many and various reasons such as
cost, RF coverage, data caps, etc. to prefer the TVWS connection over
the 3G cellular data connection. Either by user selection,
preconfigured preferences, or other algorithm, the streaming session
is started over the TVWS internet connection instead of the 3G
cellular connection. This deployment scenario is typically
characterized by a TVWS master/AP providing local coverage in the
same geographical area as a 3G cellular system. The master/AP is
assumed to be individually deployed and operated, i.e. the master/AP
is deployed and operated by the user at his home or perhaps by a
small business such as a coffee shop. The master/AP has a connection
to the internet and provides internet connectivity to the slave/
end-user's device.
The figure below shows an example deployment of this scenario. Figure 3 (Figure 3) shows an example deployment of this scenario.
\|/ \|/
| |
| |
|-|---------| |------------|
| Master/AP |\ /| Master | \
/| Router | \ (Air)-/ |------------| \
Streaming/ |-----------| \ --------- / \ -----------
-------- / \ ----------- |Slave |/ \ (----) | Database|
|Slave/| / \ (----) | Database| |Device | \ ( ) /----------
|WS Dev| \ ( ) /---------- |-------|\ \ / \
------- \ \ / \ \ X( Internet )
\ X( Internet ) \ / \ /
\ / \ / (Air) / ( )
Signaling \|/ / ( )\ \ / (----)
\ | / (----) \---------- \ /
\ | / | YouTube| \|---------------|/
\|-|---------| / ---------- | Metered |
| | / | Service |
| 3G BTS |/ |---------------|
|-----------|
Figure 5: Offloading: moving traffic to a white space network Figure 3: Offloading Traffic to a White Space Network
Once a dual or multi mode device (3G + TVWS) is connected to a 3G A simplified operation scenario of offloading content, such as video
network, a simplified operation scenario of offloading selected stream, from the a metered Internet connection to the a WS connection
content such as video stream from the 3G connection to the TWVS consists of the following steps:
connection consists of the following steps:
1. The dual mode (or multi mode) device (3G + TVWS) is connected to 1. The slave device connects to a metered Internet service, and
a 3G network. The device has located a TVWS master/AP operating selects a video for streaming.
on an available channel and has associated or connected with the
TVWS master/AP.
2. The user activates a widget or application that streams video 2. The slave device switches mode and associates with a master white
from YouTube. The widget connects to YouTube over 3G cellular space device.*
data. The user browses content and searches for video
selections.
3. The user selects a video for streaming using the widget's 3. The master queries the database for available white space
controls. Before the widget initiates a streaming session, the spectrum and relays it to the slave device as described in
widget checks the available connections in the dual mode device Section 3.2.1.*
and finds a TVWS master/AP is connected.
4. Using either input from the user or pre-defined profile 4. The slave uses available white space spectrum to communicate with
preferences, the widget selects the TVWS master/AP as the the master and connect to the Internet to stream the selected
connection to stream the video. video.
4.2.4. White space serving as backhaul * Note that the slave device may query the database directly for
available white space spectrum through its metered connection to the
Internet, thus eliminating steps 2 and 3.
In this use case Internet connectivity service is provided to users 3.2.3. White space serving as backhaul
over a more common wireless standard such as Wi-Fi with white space
entities providing backhaul connectivity to the Internet. In a
typical deployment scenario an end user has a device with a radio
such as Wi-Fi. An Internet service provider or a small business
owner wants to provide Wi-Fi Internet connectivity service to their
customers. The location where Internet connectivity service via
Wi-Fi is to be provided is within the coverage area of a white space
master (e.g. Hotspot or Wide-Area/Rural network). The service
provider installs a white space slave device and connects it to the
Wi-Fi access point(s). Wi-Fi access points with an integrated white
space slave component may also be used. This deployment scenario is
typically characterized by a WS master/AP/BS providing local
coverage. The master/AP has a connection to the Internet and
provides Internet connectivity to slave devices that are within its
coverage area. The WS slave device is 'bridged' to a Wi-Fi network
thereby enabling Internet connectivity service to Wi-Fi devices. The
WS Master/AP/BS which has some form of Internet connectivity (wired
or wireless) queries the database and obtains available channel
information. It then provides service using those channels to slave
devices which are within its coverage area.
Figure 6 shows an example deployment of this scenario. In this use case, an Internet connectivity service is provided to
users over a common wireless standard, such as Wi-Fi, with a white
space master/slave network providing backhaul connectivity to the
Internet.
\|/ white \|/ \|/ Wi-Fi \|/ Figure 4 (Figure 4) shows an example deployment of this scenario.
| space | | | \|/ White \|/ \|/ Wi-Fi \|/
| | | |-|----| | Space | | |
|--------| |-|---------| |-|------|-| | Wi-Fi| | | | |-|----|
| | | Master | | Slave | | Dev | (----) |-|----| |-|------|-| | Wi-Fi|
|Internet|------| (AP/BS) | | Bridge | |------| ( ) |Master| | Slave |--(Air)--| Dev |
| | | | | to Wi-Fi | / \ | |--(Air)--| Bridge | |------|
|--------| |-----------| |----------| \|/ ( Internet )---| | | to Wi-Fi |
| \ / |------| |----------| \|/
|-|----| ( ) \ |
| Wi-Fi| (----) \(Air) |-|----|
| Dev | \--| Wi-Fi|
|------| | Dev |
|------|
Figure 6: WS 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 device (WS + Wi-Fi) is connected to a master device 1. A bridged slave device (WS + Wi-Fi) is connected to a master
operating in the WS spectrum. The bridged device operates as a device operating in the WS spectrum (the master obtains available
slave device in either Hotspot or Wide-Area/Rural Internet use white space spectrum as described in Section 3.2.1).
cases described above.
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.2.5. Rapid deployed network for emergency scenario 3.2.4. Rapid network deployment during emergency scenario
Organizations involved in handling emergency operations often have a
fully owned and controlled infrastructure, with dedicated spectrum,
for day to day operation. However, lessons learned from recent
disasters show such infrastructures are often highly affected by the
disaster itself. To set up a replacement quickly, there is a need
for fast reallocation of spectrum, where in certain cases spectrum
can be cleared for disaster relief. To utilize unused or cleared
spectrum quickly and reliably, automation of allocation, assignment
and configuration is needed. A preferred option is to make use of a
robust protocol, already adopted by radio manufacturers. This
approach does in no way imply such organizations for disaster relief
must compete on spectrum allocation with other white spaces users,
but they can. A typical network topology would include wireless
access links to the public Internet or private network, wireless ad
hoc network radios working independent of a fixed infrastructure and
satellite links for backup where lack of coverage, overload or outage
of wireless access links occur.
Figure 7 shows an example deployment of this scenario.
\|/
| ad hoc
|
|-|-------------|
| Master node | |------------|
\|/ | with | | Whitespace |
| ad hoc /| backhaul link | | Database |
| /------/ |---------------| |------------|
---|------------/ | \ /
| Master node | | | (--/--)
| without | | ------( )
| backhaul link | | Wireless / Private \
----------------\ | Access ( net or )
\ | \ Internet )
\ \|/ | -------( /\
\ | ad hoc | | (------) \---------
\ | | / | Other |
\--|------------- /Satellite | nodes |
| Master node | / Link ----------
| with |/
| backhaul link |
-----------------
Figure 7: Rapid deployed network with partly connected nodes
In the ad hoc network, all nodes are master nodes in a way that they
allocate RF channels from the white space database. However, the
backhaul link may not be available to all nodes, such as depicted for
the left node in Figure 7. To handle RF channel allocation for such
nodes, a master node with a backhaul link relays or proxies the
database query for them. So master nodes without a backhaul link
follow the procedure as defined for clients. The ad hoc network
radios utilize the provided RF channels. Details on forming and
maintenance of the ad hoc network, including repair of segmented
networks caused by segments operating on different RF channels, is
out of scope of spectrum allocation.
4.2.6. Mobility
In this use case, the user has a non-fixed (portable or mobile)
device and is riding in a vehicle. The user wants to have
connectivity to another device which is also moving. Typical
deployment scenarios include urban areas and rural areas where the
user may connect to other users while moving. This deployment
scenario is typically characterized by a master device with low
antenna height, Internet connectivity by some connection that does
not utilize TV white space, and some means to predict its path of
mobility. This knowledge of mobility could be simple (GPS plus
accelerometer), sophisticated (GPS plus routing and mapping function)
or completely specified by the user via user-interface.
Figure 8 shows an example deployment of this scenario.
\|/ \|/
| |
| |
+-|---------+ +-|---------+
| TVWS | | TVWS |
|Master Dev | |Master Dev |
+-----------+ +-----------+
\ (----) / \
\ ( ) / \ \|/
\ / \ / WS AirIF |
( Internet ) \ |
\ / \+-|--------+
( )\----------+ | TVWS |
(----) | Database | |Slave Dev |
+----------+ +----------+
Figure 8: Example illustration of mobility in TV white space use-case
A simplified operational scenario utilizing TV whitespace to provide
connectivity service in a mobility environment consists of the
following steps:
1. The mobile master device powers up with its WS radio in idle or
listen mode only (no active transmission on the WS frequency
band).
2. The mobile master has Internet connectivity, determines its
location, and establishes a connection to a trusted white space
database (see Section 4.1.1).
3. The mobile master registers with the trusted database according
to regulatory domain requirements (see Section 4.1.2).
4. Following the successful registration process (if registration
is required), the mobile master will send a query to the trusted
database requesting a list of available WS channels based upon
its current location, other parameters required by the local
regulator (see Section 4.2.1, step 4) and a prediction of its
future location. The current location is specified in latitude
and longitude. The method to specify the future location is
TBD, potential methods include movement vector (direction and
velocity), a set of latitude/longitude points which specify a
closed polygon where the future location is within the polygon,
or similar.
5. If the mobile master has met all regulatory domain requirements
(e.g. been previously authenticated, etc), the database responds
with a list of available white space channels that the mobile
master may use, and optional information which may include (1) a
duration of time for the use of each channel (2) a maximum
transmit power for each channel and (3) notification of any
additional requirement for sensing.
6. Once the mobile master has met all regulatory domain
requirements (e.g. authenticated the WS channel list response
message from the database, etc), the master selects one or more
available WS channel(s) from the list for use. At this point
the mobile master may begin direct communication with another
mobile master using methods outside the scope of PAWS.
7. The slave/user device scans to locate a mobile master
transmission, and associates with the mobile master.
8. The slave/user device queries the master for a channel list,
providing to the master the slave's device identification, and
optionally its geolocation and a prediction of its future
location.
9. Once the mobile master has met all regulatory domain
requirements (e.g. the slave's device identification is verified
by the database), the mobile master provides the list of
channels locally available to the slave/user device.
10. If the mobile master moves outside the predicted range of future
positions in step 4, it must repeat the process to request a
channel list from the database, steps 4 through 6 above. If the
response from the database indicates a channel being used by the
mobile master is not available, the master/AP must stop
transmitting on that channel immediately.
11. The slave or user device must periodically repeat the process to
request a channel list from the master/AP, steps 8 and 9 above.
The frequency to repeat the process is determined by the local
regulator. If the response from the master/AP indicates that a
channel being used by the slave or user device is not available,
the slave or user device must stop transmitting on that channel
immediately. In addition or optionally, the database may send a
message to the master/AP to rescind the availability of one or
more channels. The master/AP must then notify the slave or user
device of the rescinded channels. The slave or user device must
stop transmitting on that channel immediately.
4.2.7. Indoor Networking
In this use case, the users are inside a house or office. The users
want to have connectivity to the Internet or to equipment in the same
or other houses / offices. This deployment scenario is typically
characterized by master devices within buildings, that are connected
to the Internet using a method that does not utilize whitespace. The
master devices can establish whitespace links between themselves, or
between themselves and one or more user devices.
Figure 9 shows an example deployment of this scenario.
\|/
|
+-------+ |
|TVWS |\ +-|---------+
|Usr Dev| WS AirIF \ | TVWS |\
+-------+ X|Master Dev | \
/ +-----------+ \
+-------+ WS AirIF | \ +----------+
|TVWS |/ | \ (----) | Database |
|Usr Dev| | \ ( ) /----------+
+-------+ WS AirIF \ / \
| X( Internet )
| / \ /
+-------+ \|/ | / ( )
|TVWS |\ | | / (----)
|Usr Dev| WS AirIF | | /
+-------+ \ +-|---------+ /
\ | TVWS | /
|Master Dev |/
+-----------+
Figure 9: Example illustration of indoor TV white space use-case
A simplified operational scenario utilizing TV whitespace to provide
indoor networking consists of the following steps:
1. The master device powers up with its whitespace radio in idle or
listen mode only (no active transmission on the whitespace
frequency band).
2. The master device has Internet connectivity, determines its
location (either from location determination capability or from a
saved value that was set during installation), and establishes a
connection to a trusted white space database (see Section 4.1.1).
3. The master device registers with the trusted database according
to regulatory domain requirements (see Section 4.1.2).
4. Following the successful registration process (if registration is
required), the master device sends a query to the trusted
database requesting a list of available WS channels based upon
its geolocation. The complete set of parameters to be provided
from the master to the database is specified by the local
regulator. Parameters may include WSD location, accuracy of that
location, device antenna height, device identifier of a slave
device requesting channel information.
5. If the master has met all regulatory requirements, the database
responds with a list of available white space channels that the
master device may use, and optional information which may include
inter alia (1) a duration of time for the use of each channel
(channel validity time) (2) a maximum radiated power for each
channel, and (3) directivity and other antenna information.
6. Once the master device authenticates the whitespace channel list
response message from the database, the master device selects one
or more available whitespace channels from the list. At this
point the mobile master may begin direct communication with
another mobile master using methods outside the scope of PAWS.
7. The user device(s) scan(s) the white space bands to locate the
master device transmissions, and associates with the master.
4.2.8. Machine to Machine (M2M)
In this use case, each "machine" includes a white space slave device
and can be located anywhere, fixed or on the move. Each machine
needs to have connectivity to the Internet and or to other machines
in the vicinity. Machine communication over a TVWS channel, whether
to a master device or to another machine (slave device), is under the
control of a master device. This deployment scenario is typically
characterized by a master device with Internet connectivity by some
connection that does not utilize TV white space.
Figure 10 shows an example deployment of this scenario.
\|/ Organizations involved in handling emergency operations maintain an
| infrastructure that relies on dedicated spectrum for their
| operations. However, such infrastructures are often affected by the
+-|---------+ disasters they handle. To set up a replacement network, spectrum
| TVWS |\ needs to be quickly cleared and reallocated to the crisis response
/|Master Dev | \ organization. Automation of the this allocation and assignment is
/ +-----------+ \ often the best solution. A preferred option is to make use of a
WS AirIF \ +----------+ robust protocol that has been adopted and implemented by radio
+-------+ / \ (----) | Database | manufacturers. A typical network topology solution might include
|Machine| \ ( ) /----------+ wireless access links to the public Internet or private network,
+-------+ \ / \ wireless ad-hoc network radios working independent of a fixed
| X( Internet ) infrastructure, and satellite links for backup where lack of
WS AirIF \ / coverage, overload, or outage of wireless access links can occur.
| ( )
+-------+ (----)
|Machine|
+-------+ \ +-------+
WS AirIF-- |Machine|
+-------+
Figure 10: Example illustration of M2M TV white space use-case Figure 5 (Figure 5) shows an example deployment of this scenario.
\|/
| ad hoc
|
|-|-------------|
| Master node | |------------|
\|/ | with | | Whitespace |
| ad hoc /| backhaul link | | Database |
| /------/ |---------------| |------------|
---|------------/ | \ /
| Master node | | | (--/--)
| without | | -----( )
| backhaul link | | Wireless / Private \
----------------\ | Access ( net or )
\ | \ Internet )
\ \|/ | ------( /\
\ | ad hoc | | (------) \---------
\ | | / | Other |
\--|------------- /Satellite | nodes |
| Master node | / Link ----------
| with |/
| backhaul link |
-----------------
A simplified operational scenario utilizing TV whitespace to provide Figure 5: Rapid-deployed Network with Partly-connected Nodes
machine to machine connectivity consists of the following steps:
1. The master device powers up with its whitespace radio in idle or In the ad-hoc network, all nodes are master nodes that allocate RF
listen mode only (no active transmission on the whitespace channels from the white space database (as described in
frequency band). Section 3.2.1). However, the backhaul link may not be available to
all nodes, such as depicted for the left node in the above figure.
To handle RF channel allocation for such nodes, a master node with a
backhaul link relays or proxies the database query for them. So
master nodes without a backhaul link follow the procedure as defined
for clients. The ad-hoc network radios utilize the provided RF
channels. Details on forming and maintenance of the ad-hoc network,
including repair of segmented networks caused by segments operating
on different RF channels, is out of scope of spectrum allocation.
2. The master device has Internet connectivity, determines its 3.2.5. White space used for local TV broadcaster
location (either from location determination capability or from
saved value that was set during installation), and establishes a
connection to a trusted white space database (see Section 4.1.1).
3. The master/AP registers with the trusted database according to Available white space spectrum can be deployed in novel ways to
regulatory domain requirements (see Section 4.1.2). leverage the public use of hand-held and portable devices. One such
use is white space spectrum used for local TV transmission of audio-
video content to portable devices used by individuals in attendance
at an event. In this use case, audience members at a seminar,
entertainment event, or other venue plug a miniature TV receiver fob
into their laptop, computer tablet, cell phone, or other portable
device. A master device obtains a list of available white space
spectrum (as described in , (Section 3.2.1), then broadcasts audio-
video content locally to the audience over one of the available
frequencies. Audience members receive the content through their
miniature TV receivers tuned to the appropriate white space band for
display on their portable device monitors.
4. Following successful registration (if registration is required), Figure 6 (Figure 6) shows an example deployment of this scenario.
the master device sends its geolocation and location uncertainty
information, and optionally additional information which may
include (1) device ID and (2) antenna characteristics, to a
trusted database, requesting a list of available whitespace
channels based upon this information.
5. If the master has met all regulatory domain requirements, the \|/ |------------|
database responds with a list of available white space channels | |White Space |
that the master device may use, and optional information which | Database |
may include inter alia (1) a duration of time for the use of each | .---. / |------------|
channel (channel validity time) (2) a maximum radiated power for |-----------| ( ) /
each channel or a notification of any additional requirements for | Master | / \
sensing. | |========( Internet)
|-----------| \ /
| ( )
/|\ (---)
6. Once the master device authenticates the whitespace channel list (White Space
response message from the database, the master device selects one Broadcast)
or more available whitespace channels from the list.
7. The slave devices fitted to the machines scan the TV bands to \|/ \|/ \|/ \|/ \|/ \|/ \|/
locate the master transmissions, and associate with the master | | | | | | | .................
device. ----- ----- ----- ----- ----- ----- -----
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
----- ----- ----- ----- ----- ----- -----
USB TV receivers connected to laptops, cellphone, tablets ....
8. Further signaling can take place outside scope of PAWS to Figure 6: White Space Used for Local TV Broadcast
establish direct links among those slave devices that have
associated with the same master device. At all times these
direct links are under the control of the master device. For
example, common to all use cases, there may be a regulatory
requirement for transmissions from slave to master to cease
immediately if so requested by the master, or if connection to
the master is lost for more than a specified period of time.
When one of these conditions occurs, transmissions from slave to
slave would also cease. Various mechanisms could be used to
detect loss of signal from the master, for example by requiring
masters to transmit regular beacons if they allow slave to slave
communications. Direct slave to slave transmissions could only
restart if each slave subsequently restores its connection to the
same master, or each slave joins the network of another master.
5. Problem Statement 4. Problem Statement
The use of white space spectrum is enabled via the capability of a The use of white space spectrum is enabled via the capability of a
device to query a database and obtain information about the device to query a database and obtain information about the
availability of spectrum for use at a given location. The databases availability of spectrum for use at a given location. The databases
are reachable via the Internet and the devices querying these are reachable via the Internet and the devices querying these
databases are expected to have some form of Internet connectivity, databases are expected to have some form of Internet connectivity,
directly or indirectly. The databases may be country specific since directly or indirectly. The databases may be regulatory specific
the available spectrum and regulations may vary, but the fundamental since the available spectrum and regulations may vary, but the
operation of the protocol should be country independent. fundamental operation of the protocol should be regulatory
independent.
An example high-level architecture of the devices and white space An example high-level architecture of the devices and white space
databases is shown in Figure 11: databases is shown in Figure 7 (Figure 7).
-----------
----------- | Master |
| Master | |WS Device| ------------
|WS Device| ------------ |Lat: X |\ .---. /--------|Database X|
|Lat: X |\ .---. /--------|Database X| |Long: Y | \ ( ) / ------------
|Long: Y | \ ( ) / ------------ ----------- \-------/ \/ o
----------- \-------/ \/ o ( Internet) o
( Internet ) o ----------- /------( )\ o
----------- /------( )\ o | Master | / ( ) \
| Master | / ( ) \ |WS Device|/ (_____) \ ------------
|WS Device|/ (_____) \ ------------ |Lat: X | \--------|Database Y|
|Lat: X | \--------|Database Y| |Long: Y | ------------
|Long: Y | ------------ -----------
-----------
Figure 11: High level view of the White space database architecture Figure 7: High-level View of White Space Database Architecture
In Figure 11, note that there could be multiple databases serving In Figure 11, note that there could be multiple databases serving
white space devices. The databases are country specific since the white space devices. The databases are country specific since the
regulations and available spectrum may vary. In some countries, for regulations and available spectrum may vary. In some countries, for
example, the U.S., the regulator has determined that multiple, example, the U.S., the regulator has determined that multiple,
competing databases may provide service to White Space Devices. competing databases may provide service to White Space Devices.
A messaging interface between the white space devices and the A messaging interface between the white space devices and the
database is required for operating a network using the white space database is required for operating a network using the white space
spectrum. The following sections discuss various aspects of such an spectrum. The following sections discuss various aspects of such an
interface and the need for a standard. Other aspects of a solution interface and the need for a standard.
including provisioning the database, and calculating protected
contours are considered out of scope of the initial effort, as there
are significant differences between countries and spectrum bands.
5.1. Global applicability 4.1. Global applicability
The use of TV white space spectrum is currently approved by the FCC The use of white space spectrum is currently approved or being
in the United States. However regulatory bodies in other countries considered in multiple regulatory domains, whose rules may differ.
are also considering similar use of available spectrum. The However the need for devices that intend to use the spectrum to
principles of cognitive radio usage for such spectrum is generally communicate with a database remains a common feature. The database
the same. Some of the regulatory details may vary on a country implements rules that protect all primary users, independent of the
specific basis. However the need for devices that intend to use the characteristics of the white space devices. It also provides a way
spectrum to communicate with a database remains a common feature. to specify a schedule of use, since some primary users (for example,
The database provides a known, specifiable Protection Contour for the wireless microphones) only operate in limited time slots.
primary user, not dependent on the characteristics of the White Space
Device or its ability to sense the primary use. It also provides a
way to specify a schedule of use, because 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 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 - The radio/air interface technology
used by the white space device in available spectrum can be IEEE used by the white space device in available spectrum can be IEEE
802.11af, IEEE 802.15.4m, IEEE 802.16, IEEE 802.22, LTE etc. 802.11af, IEEE 802.15.4m, IEEE 802.16, IEEE 802.22, LTE etc.
However the messaging interface between the white space device However the messaging interface between the white space device
and the database should be agnostic to the air interface while and the database should be agnostic to the air interface while
being cognizant of the characteristics of various air-interface being cognizant of the characteristics of various air-interface
technologies and the need to include relevant attributes in the technologies and the need to include relevant attributes in the
skipping to change at page 30, line 34 skipping to change at page 16, line 31
be able to be used in any spectrum band where white space sharing be able to be used in any spectrum band where white space sharing
is permitted. is permitted.
3. Globally applicable - A common messaging interface between white 3. Globally applicable - A common messaging interface between white
space devices and databases will enable the use of such spectrum space devices and databases will enable the use of such spectrum
for various purposes on a global basis. Devices can operate in for various purposes on a global basis. Devices can operate in
any country where such spectrum is available and a common any country where such spectrum is available and a common
interface ensures uniformity in implementations and deployment. interface ensures uniformity in implementations and deployment.
Since the White Space Device must know its geospatial location to Since the White Space Device must know its geospatial location to
do a query, it is possible to determine which database, and which do a query, it is possible to determine which database, and which
rules, are applicable, even though they are country specific. rules, are applicable, even though they are country-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. Address regulatory requirements - Each country is likely to have 4. Flexible and extensible data structures - Different databases are
regulations that are unique to that country. The messaging likely to have different requirements for the kinds of data
interface needs to be flexible to accommodate the specific needs required for registration (different rule sets that apply to the
of a regulatory body in the country where the white space device registration of devices) and other messages sent by the device to
is operating and connecting to the relevant database. the database. For instance, different regulators might require
different device-characteristic information to be passed to the
database.
5.2. Database discovery 4.2. Database discovery
Another aspect of the problem space is the need to discover the Another aspect of the problem space is the need to discover the
database. A white space device needs to find the relevant database database. A white space device needs to find the relevant database
to query, based on its current location or for another location. to query, based on its current location or for another location.
Since the spectrum and databases are country specific, the device Since the spectrum and databases are regulatory-domain specific, the
will need to discover the relevant database. The device needs to device will need to discover the relevant database. The device needs
obtain the IP address of the specific database to which it can send to determine the location of the specific database to which it can
queries in addition to registering itself for operation and using the send queries in addition to registering itself for operation and
available spectrum. using the available spectrum.
5.3. Protocol 4.3. Protocol
A protocol that enables a white space device to query a database to A protocol that enables a white space device to query a database to
obtain information about available channels is needed. A device may obtain information about available spectrum is needed. A device may
be required to register with the database with some credentials prior be required to register with the database with some credentials prior
to being allowed to query. The requirements for such a protocol are to being allowed to query. The requirements for such a protocol are
specified in this document. specified in this document.
5.4. Data model definition 4.4. Data model definition
The contents of the queries and response need to be specified. A The contents of the queries and response need to be specified. A
data model is required which enables the white space device to query data model is required which enables the white space device to query
the database while including all the relevant information such as the database while including all the relevant information such as
geolocation, radio technology, power characteristics, etc. which may geolocation, radio technology, power characteristics, etc., which may
be country and spectrum and regulatory dependent. All databases are be country and spectrum and regulatory dependent. All databases are
able to interpret the data model and respond to the queries using the able to interpret the data model and respond to the queries using the
same data model that is understood by all devices. same data model that is understood by all devices.
Use of XML for specifying a data model is an attractive option. The 5. Requirements
intent is to evaluate the best option that meets the need for use
between white space devices and databases.
6. Requirements
6.1. Normative Requirements 5.1. Normative Requirements
D. Data Model Requirements: D. Data Model Requirements:
D.1: The Data Model MUST support specifying the location of the D.1 The Data Model MUST support specifying the geolocation of the
WSD, the uncertainty in meters, the height & its WSD, the uncertainty in meters, the height & its uncertainty,
uncertainty, and confidence in percentage of the location and confidence in percentage of the location determination.
determination. The Data Model MUST support both North The Data Model MUST support WGS84 (see NGA: DoD World Geodetic
American Datum of 1983 and WGS84. System 1984 [2]).
D.2: The Data Model MUST support specifying the regulatory domain D.2 The Data Model MUST support specifying the data and other
and its corresponding data requirements. applicable requirements of the rule set that applies to the
white space device at its current location.
D.3: The Data Model MUST support specifying an ID of the D.3 The Data Model MUST support device description data that
transmitter device. This ID would contain the ID of the identifies a device (serial number, certification IDs, etc.)
transmitter device that has been certified by a regulatory and describes device characteristics (device class, Radio
body for its regulatory domain. The Data Model MUST support Access Technology, etc.).
a device class. The Data Model MUST support specifying
information about the type of RAT of the transmitter device.
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 subject, 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)
spectrum mask with lowest and highest possible frequency spectrum mask with lowest and highest possible frequency
spectrum mask in dBr from peak transmit power in EIRP, spectrum mask in dBr from peak transmit power in EIRP, with
with specific power limit at any frequency linearly specific power limit at any frequency linearly interpolated
interpolated between adjacent points of the spectrum mask between adjacent points of the spectrum mask
measurement resolution bandwidth for EIRP measurements measurement resolution bandwidth for EIRP measurements
D.6: The Data Model MUST support specifying owner and operator D.6 The Data Model MUST support specifying owner and operator
contact information for a transmitter. This includes the contact information for a transmitter. This includes the name
name of the transmitter owner, name of transmitter operator, of the transmitter owner, name of transmitter operator, postal
postal address, email address and phone number of the address, email address and phone number of the transmitter
transmitter operator. operator.
D.7: The Data Model MUST support specifying spectrum D.7 The Data Model MUST support specifying spectrum availability.
availability. Spectrum units are specified by low and high Spectrum units are specified by low and high frequencies and
frequencies and may have an optional channel identifier. may have an optional channel identifier. The Data Model MUST
The Data Model MUST support a schedule including start time support a schedule including start time and stop time for
and stop time for spectrum unit availability. The Data spectrum unit availability. The Data Model MUST support
Model MUST support maximum power level for each spectrum maximum power level for each spectrum unit.
unit.
D.8: The Data Model MUST support specifying channel availability D.8 The Data Model MUST support specifying spectrum availability
information for a single location and an area (e.g. a information for a single location and an area (e.g., a polygon
polygon defined by multiple location points or a geometric defined by multiple location points or a geometric shape such
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.
P. Protocol Requirements: P. Protocol Requirements:
P.1: The protocol MUST provide a mechanism to enable WSD P.1 The address of a database (e.g., in form of a URI) can be
discovery. In some environments, a listing of the approved preconfigured in a master device. The master device MUST be
white space databases is maintained by the national able to contact a database using a pre-configured database
regulator. The protocol MUST support discovery of a address. The master device may validate the database against a
database using a listing approved by a national regulator. list of approved databases maintained by a regulatory body.
P.2: The address of a database (e.g. in form of a URI) can be P.2 The protocol must support the database informing the master
preconfigured in a master device. The master device MUST of the regulatory rules (rule set) that applies to the master
be able to contact a database using a pre-configured device (or any slave devices on whose behalf the master is
database address. contacting the database) at the current location or the master
(or slave) device(s).
P.3: The protocol MUST support determination of regulatory P.3 The protocol MUST provide the ability for the database to
domain governing its current location. authenticate the master device.
P.4: The protocol MUST provide the ability for the database to P.4 The protocol MUST provide the ability for the master device
authenticate the master device. to verify the authenticity of the database with which it is
interacting.
P.5: The protocol MUST provide the ability for the master device P.5 The messages sent by the master device to the database and
to verify the authenticity of the database with which it is the messages sent by the database to the master device MUST
interacting. support integrity protection.
P.6: The messages sent by the master device to the database and P.6 The protocol MUST provide the capability for messages sent by
the messages sent by the database to the master device MUST the master device and database to be encrypted.
support integrity protection.
P.7: The protocol MUST provide the capability for messages sent P.7 The protocol MUST support the master device registering with
by the master device and database to be encrypted. the database (see Device Registration (Section 3.1.2)).
P.8: The protocol MUST support the master device registering P.8 The protocol MUST support a registration acknowledgement
with the database. including appropriate result codes.
P.9: The protocol MUST support a registration acknowledgement P.9 The protocol MUST support an available spectrum request from
including appropriate result codes. the master device to the database. These parameters MAY
include any of the parameters and attributes required to be
supported in the Data Model Requirements.
P.10: The protocol MUST support a channel query request from the P.10 The protocol MUST support an available spectrum response
master device to the database. The channel query request from the database to the master device. These parameters MAY
message MUST include parameters as required by local include any of the parameters and attributes required to be
regulatory requirement. These parameters MAY include any supported in the Data Model Requirements.
of the parameters and attributes required to be supported
in the Data Model Requirements.
P.11: The protocol MUST support a channel query response from the P.11 The protocol MUST support a spectrum usage message from the
database to the master device. The channel query response master device to the database. These parameters MAY include
message MUST include parameters as required by local any of the parameters and attributes required to be supported
regulatory requirement. These parameters MAY include any in the Data Model Requirements.
of the parameters and attributes required to be supported
in the Data Model Requirements.
P.12: The protocol MUST support a channel usage message from the P.12 The protocol MUST support a spectrum usage message
master device to the database. The channel usage message acknowledgement.
MUST include parameters as required by local regulatory
requirement for the master and its associated slaves.
These parameters MAY include any of the parameters and
attributes required to be supported in the Data Model
Requirements.
P.13: The protocol MUST support a channel usage message P.13 The protocol MUST support a validation request from the
acknowledgement. master to the database to validate a slave device. The
validation request MUST include the slave device ID.
P.14: The protocol MUST support a validation request from the P.14 The protocol MUST support a validation response from the
master to the database to validate a slave device. The database to the master to indicate if the slave device is
validation request MUST include the slave device ID. validated by the WSDB. The validation response MUST include a
response code.
P.15: The protocol MUST support a validation response from the P.15 The protocol between the master device and the database MUST
database to the master to indicate if the slave device is support the capability to change spectrum availability
validated by the WSDB. The validation response MUST information on short notice.
include a response code.
P.16: The protocol between the master device and the database P.16 The protocol between the master device and the database MUST
MUST support the capability to change channel availability support a spectrum availability request which specifies a
information on short notice. geographic location as an area as well as a point.
P.17: The protocol between the master device and the database 5.2. Non-normative requirements
MUST support a channel availability request which specifies
a geographic location as an area as well as a point.
6.2. Non-normative requirements O. Operational Requirements
O. Operational Requirements: This section contains operational requirements of a white space
database-device system, independent of the requirements of the
protocol for communication between the white space database and
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 O.2 A master device MUST be able to determine its location
including uncertainty and confidence level. A fixed master including uncertainty and confidence level. A fixed master
device MAY use a location programmed at installation or have device MAY use a location programmed at installation or have
the capability to determine its location to the required the capability to determine its location to the required
accuracy. A mobile master device MUST have the capability to accuracy. A mobile master device MUST have the capability to
determine its location to the required accuracy. determine its location to the required accuracy.
O.3: The master device MUST identify a database to which it will O.3 The master device MUST identify a database to which it will
register, make channel requests, etc... The master device MAY register, make spectrum availability requests, etc... The
select a database for service by discovery at runtime or the master device MAY select a database for service by discovery at
master device MAY select a database for service by means of a runtime or the master device MAY select a database for service
pre-programmed URI address. by means of a pre-programmed URI address.
O.4: The master device MUST implement at least one connection O.4 The master device MUST implement at least one connection
method to access the database. The master device MAY contact method to access the database. The master device MAY contact a
a database directly for service (e.g. as defined by FCC) or database directly for service or the master device MAY contact
the master device MAY contact a listing server first followed a database listing server first followed by contact to a
by contact to a database (e.g. as defined by Ofcom). database.
O.5: The master device MUST obtain an indication about the O.5 The master device MUST obtain an information on the rule set
regulatory domain governing operation at its current location, of the regulatory body that applies to the master device at its
i.e. the master device MUST know if it operates under current location (and/or the location of any slave devices on
regulations from FCC, Ofcom, etc... whose behalf the master device is operating).
O.6: The master device MAY register with the database according to O.6 The master device MAY register with the database according to
local regulatory policy. Not all master devices will be local regulatory policy. Not all master devices will be
required to register. Specific events will initiate required to register. Specific events will initiate
registration, these events are determined by regulator policy registration, these events are determined by regulator policy
(e.g. at power up, after movement, etc...). When local (e.g., at power up, after movement, etc...). When local
regulatory policy requires registration, the master device regulatory policy requires registration, the master device MUST
MUST register with its most current and up-to-date register with its most current and up-to-date information, and
information, and MUST include all variables mandated by local MUST include all variables mandated by local regulator policy.
regulator policy.
O.7: A master device MUST query the database for the available O.7 A master device MUST query the database for the available
channels 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 transmission in white space. Parameters provided to the
database MAY include device location, accuracy of the database MAY include device location, accuracy of the location,
location, antenna characteristic information, device antenna characteristic information, device identifier of any
identifier of any slave device requesting channel information, slave device requesting spectrum information, etc.
etc...
O.8: The database MUST respond to an available channel list request O.8 The database MUST respond to an available spectrum list
from an authenticated and authorized device and MAY also request from an authenticated and authorized device and MAY
provide time constraints, maximum output power, start and stop also provide time constraints, maximum output power, start and
frequencies for each channel in the list and any additional stop frequencies for each band in the list and any additional
requirements for sensing. requirements for sensing.
O.9: According to local regulator policy, a master device MAY O.9 According to local regulator policy, a master device MAY
inform the database of the actual frequency usage of the inform the database of the actual frequency usage of the master
master and its slaves. The master MUST include parameters and its slaves. The master MUST include parameters required by
required by local regulatory policy, e.g. device ID, local regulatory policy, e.g., device ID, manufacturer's serial
manufacturer's serial number, channel usage and power level number, spectrum usage and power level information of the
information of the master and its slaves. master and its slaves.
O.10: After connecting to a master device's radio network a slave O.10 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
channels. 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.11 According to local regulatory policy, the master device MAY
query the database with parameters received from the slave query the database with parameters received from the slave
device. device.
O.12: The database MUST respond to a query from the master device O.12 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.13 A master device MUST repeat the query to the database for
available channels as often as required by the regulation the available spectrum as often as required by the regulation
(e.g., FCC requires once per day) to verify that the operating (e.g., FCC requires once per day) to verify that the operating
channels continue to remain available. channels continue to remain available.
O.14: A master device which changes its location more than a O.14 A master device which changes its location more than a
threshold distance (specified by local regulatory policy) threshold distance (specified by local regulatory policy)
during its operation, MUST query the database for available during its operation, MUST query the database for available
operating channels each time it moves more than the threshold operating spectrum each time it moves more than the threshold
distance (e.g., FCC specifies 100m) from the location it distance (e.g., FCC specifies 100m) from the location it
previously made the query. previously made the query.
O.15: According to local regulator policy, a master device may O.15 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.16 A master device MUST be able to query the whitespace
for channel availability information for a specific expected database for spectrum availability information for a specific
coverage area around its current location. expected coverage area around its current location.
O.17: A Master device MUST include its unique identity in all O.17 A Master device MUST include its unique identity in all
message exchanges with the database. message exchanges with the database.
6.3. Guidelines 5.3. 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:
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 has no requests to IANA.
8. Security Considerations This document makes no request of IANA.
Threat model for the PAWS protocol 7. Security Considerations
Assumptions: PAWS is a protocol whereby a Master Device requests a schedule of
available spectrum at its location (or location of its Slave Devices)
before it (they) can operate using those frequencies. Whereas the
information provided by the Database must be accurate and conform to
applicable regulatory rules, the Database cannot enforce, through the
protocol, that a client device uses only the spectrum it provided.
In other words, devices can put energy in the air and cause
interference without asking the Database. Hence, PAWS security
considerations do not include protection against malicious use of the
White Space spectrum.
It is assumed that an attacker has full access to the network medium Threat model for the PAWS protocol:
between the master device and the white space database. The attacker
may be able to eavesdrop on any communications between these
entities. The link between the master device and the white space
database can be wired or wireless and provides IP connectivity.
It is assumed that both the master device and the white space Assumptions:
database have NOT been compromised from a security standpoint.
Threat 1: User modifies a device to masquerade as another valid It is assumed that an attacker has full access to the network
certified device medium between the master device and the white space database.
The attacker may be able to eavesdrop on any communications
between these entities. The link between the master device and
the white space database can be wired or wireless and provides
IP connectivity.
Regulatory environments require that devices be certified and It is assumed that both the master device and the white space
register in ways that accurately reflect their certification. database have NOT been compromised from a security standpoint.
Without suitable protection mechanisms, devices could simply
listen to registration exchanges, and later registering claiming
to be those other devices. Such replays would allow 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 channels.
Threat 2: Spoofed white space database Threat 1: User modifies a device to masquerade as another valid
certified device
A master device discovers a white space database(s) through which Regulatory environments require that devices be certified and
it can query for channel information. The master device needs to register in ways that accurately reflect their certification.
ensure that the white space database with which it communicates Without suitable protection mechanisms, devices could simply
with is an authentic entity. The white space database needs to listen to registration exchanges, and later registering
provide its identity to the master device which can confirm the claiming to be those other devices. Such replays would allow
validity/authenticity of the database. An attacker may attempt to false registration, violating regulatory regimes. A white
spoof a white space database and provide responses to a master space database may be operated by a commercial entity which
device which are malicious and result in the master device causing restricts access only to authorized users. A master device MAY
interference to the primary user of the spectrum. need to identify itself to the database and be authorized to
obtain information about available spectrum.
Threat 3: Modifying a query request Threat 2: Spoofed white space database
An attacker may modify the query request sent by a master device A master device discovers a white space database(s) through
to a white space database. The attacker may change the location which it can query for available spectrum information. The
of the device or the capabilities in terms of its transmit power master device needs to ensure that the white space database
or antenna height etc. which could result in the database with which it communicates with is an authentic entity. The
responding with incorrect information about available channels or white space database needs to provide its identity to the
max transmit power allowed. The result of such an attack is that master device which can confirm the validity/authenticity of
the master device would cause interference to the primary user of the database. An attacker may attempt to spoof a white space
the spectrum. It could also result in a denial of service to the database and provide responses to a master device which are
master device by indicating that no channels are available. malicious and result in the master device causing interference
to the primary user of the spectrum.
Threat 4: Modifying a query response Threat 3: Modifying a query request
An attacker could modify the query response sent by the white An attacker may modify the query request sent by a master
space database to a master device. The channel information or device to a white space database. The attacker may change the
transmit power allowed type of parameters carried in the response location of the device or the capabilities in terms of its
could be modified by the attacker resulting in the master device transmit power or antenna height etc., which could result in
using channels that are not available at a location or the database responding with incorrect information about
transmitting at a greater power level than allowed resulting in available spectrum or max transmit power allowed. The result
interference to the primary user of that spectrum. Alternatively of such an attack is that the master device would cause
the attacker may indicate no channel availability at a location interference to the primary user of the spectrum. It could
resulting in a denial of service to the master device. also result in a denial of service to the master device by
indicating that no channels are available.
Threat 5: Unauthorized use of channels by an uncertified device Threat 4: Modifying a query response
An attacker may be a master device which is not certified for use An attacker could modify the query response sent by the white
by the relevant regulatory body. The attacker may listen to the space database to a master device. The available spectrum
communication between a valid master device and white space information or transmit power allowed type of parameters
database and utilize the information about available channels in carried in the response could be modified by the attacker
the response message by utilizing those channels. The result of resulting in the master device using spectrum that is not
such an attack is unauthorized use of channels by a master device available at a location or transmitting at a greater power
which is not certified to operate. The master device querying the level than allowed resulting in interference to the primary
white space database may be operated by a law-enforcement agency user of that spectrum. Alternatively the attacker may indicate
and the communications between the device and the database are no spectrum availability at a location resulting in a denial of
intended to be kept private. A malicious device should not be service to the master device.
able to eavesdrop on such communications.
Threat 6: 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 master A white space database in a regulatory domain may require a
device to provide its identity in addition to its location in the master device to provide its identity in addition to its
query request. Such location/identity information can be gleaned location in the query request. Such location/identity
by an eavesdropper and used for tracking purposes. A master information can be gleaned by an eavesdropper and used for
device may prefer to keep the location/identity information hidden tracking purposes. A master device may prefer to keep the
from eavesdroppers, hence the protocol should provide a means to location/identity information hidden from eavesdroppers, hence
protect the location and identity information of the master device the protocol should provide a means to protect the location and
and prevent tracking of locations associated with a white space identity information of the master device and prevent tracking
database query. When the master device sends both its identity of locations associated with a white space database query.
and location to the DB, the DB is able to track it. If a When the master device sends both its identity and location to
regulatory domain does not require the master device to provide the DB, the DB is able to track it. If a regulatory domain
its identity to the white space database, the master device may does not require the master device to provide its identity to
decide not to send its identity, to prevent being tracked by the the white space database, the master device may decide not to
DB. send its identity, to prevent being tracked by the DB.
Threat 7: Malicious individual acts as a PAWS entity (spoofing DB or Threat 6: Malicious individual acts as a PAWS entity (spoofing DB
as MiM) to terminate or unfairly limit spectrum access of devices for or as MiM) to terminate or unfairly limit spectrum access of
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 channels 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 to sending an unsolicited message. A malicious node can pretend
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 channel information from and send a revoke registered or obtained spectrum information from and send a
message to that device. This results in denial of service to the revoke message to that device. This results in denial of
master device. service to the master device.
Threat 8: Natural disaster resulting in inability to obtain Threat 7: Natural disaster resulting in inability to obtain
authorization for white space spectrum use by emergency responders authorization for white space spectrum use by emergency responders
In the case of a sizable natural disaster a lot of Internet In the case of a sizable natural disaster a lot of Internet
infrastructure ceases to function. Emergency services users need infrastructure ceases to function, emergency services users
to reconstitute quickly and will rely on establishing radio WANs. need to reconstitute quickly and will rely on establishing
The potential for lot of radio WAN gear that has been unused radio WANs. In such cases, radio WAN gear that has been unused
suddenly needs to be pressed into action. And the radio WANs need suddenly needs to be pressed into action. And the radio WANs
frequency authorizations to function. Regulatory entities may need frequency authorizations to function. Regulatory entities
also authorize usage of additional spectrum in the affected areas. may also authorize usage of additional spectrum in the affected
The white space radio entities may need to establish communication areas. The white space radio entities may need to establish
with a database and obtain authorizations. In cases where communication with a database and obtain authorizations. In
communication with the white space database fails, the white space cases where communication with the white space database fails,
devices cannot utilize white space spectrum. Emergency services, the white space devices cannot utilize white space spectrum.
which require more spectrum precisely at locations where network Emergency services, which require more spectrum precisely at
infrastructure is malfunctioning or overloaded, backup locations where network infrastructure is malfunctioning or
communication channels and distributed white space databases are overloaded, backup communication spectrum and distributed white
needed to overcome such circumstances. Alternatively there may be space databases are needed to overcome such circumstances.
other mechanisms which allow the use of spectrum by emergency Alternatively there may be other mechanisms which allow the use
service equipment without strict authorization or with liberal of spectrum by emergency service equipment without strict
interpretation of the regulatory policy for white space usage. 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. in the requirements of Section 6.1 (Section 5.1).
9. Summary and Conclusion 8. 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
opportunistic use. White space is the general term used to refer to opportunistic use. "White space" is the general term used to refer
the bands within the spectrum which is available for secondary use at to the bands within the spectrum which are available for secondary
a given location. In order to use this spectrum a device needs to use at a given location. In order to use this spectrum, a device
query a database which maintains information about the available needs to query a database that maintains information about the
channels within a band. A protocol is necessary for communication available spectrum within a band. A protocol is necessary for
between the devices and databases which would be globally applicable. communication between the devices and databases that is globally
applicable.
The document describes some examples of the role of the white space The document describes some examples of the role of the white space
database in the operation of a radio network and also shows examples database in the operation of a radio network, and also provides
of services provided to the user of a TVWS device. From these use examples of services provided to the user of a white space device.
cases, requirements are determined. These requirements are to be From these use cases, requirements are determined. These
used as input to the definition of a Protocol to Access White Space requirements are to be used as input for the development of a
database (PAWS). Protocol to Access White Space database (PAWS).
10. Acknowledgements 9. Acknowledgements
The authors acknowledge Gabor Bajko, Teco Boot, Nancy Bravin, Rex The authors acknowledge Gabor Bajko, Teco Boot, Nancy Bravin, Rex
Buddenberg, Gerald Chouinard, Stephen Farrell, Michael Fitch, Joel M. Buddenberg, Vincent Chen, Gerald Chouinard, Stephen Farrell, Michael
Halpern, Jussi Kahtava, Paul Lambert, Brian Rosen, Andy Sago, Peter Fitch, Joel M. Halpern, Jussi Kahtava, Paul Lambert, Pete Resnick,
Stanforth, John Stine and, Juan Carlos Zuniga for their contributions Brian Rosen, Andy Sago, Peter Stanforth, John Stine and, Juan Carlos
to this document. Zuniga for their contributions to this document.
11. References
11.1. Normative References
[802.11p] IEEE, "IEEE Standard for Information technology -
Telecommunications and information exchange between
systems - Local and metropolitan area networks - Specific
requirements; Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications; Amendment
6: Wireless Access in Vehicular Environments; http://
standards.ieee.org/getieee802/download/802.11p-2010.pdf",
July 2010.
[802.22] IEEE, "IEEE Standard for Information technology -
Telecommunications and information exchange between
systems - Wireless Regional Area Networks (WRAN) -
Specific requirements; Part 22: Cognitive Wireless RAN
Medium Access Control (MAC) and Physical Layer (PHY)
Specifications: Policies and Procedures for Operation in
the TV bands", July 2011.
[FCC47CFR90.210]
FCC, "Title 47 Telecommunication CFR Chapter I - Federal
Communication Commission Part 90 - Private Land Mobile
Radio Services - Section 210 Emission masks; http://
edocket.access.gpo.gov/cfr_2010/octqtr/pdf/
47cfr90.210.pdf", October 2010.
[RFC2119] IETF, "Key words for use in RFCs to Indicate Requirement
Levels;
http://www.rfc-editor.org/rfc/pdfrfc/rfc2119.txt.pdf",
March 1997.
11.2. Informative References
[3MOO] FCC, "Federal Communications Commission, Third Memorandum
Opinion and Order", April 2012.
[DDR] Ofcom - Independent regulator and competition authority 10. References
for the UK communications industries, "Digital Dividend
Review; http://stakeholders.ofcom.org.uk/spectrum/
project-pages/ddr/".
[DTV] "Digital TV Transition; http://www.dtv.gov". 10.1. Normative References
[ECC Report 159] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Electronic Communications Committee (ECC) within the Requirement Levels", BCP 14, RFC 2119, March 1997.
European Conference of Postal and Telecommunications
Administrations (CEPT), "TECHNICAL AND OPERATIONAL
REQUIREMENTS FOR THE POSSIBLE OPERATION OF COGNITIVE RADIO
SYSTEMS IN THE 'WHITE SPACES' OF THE FREQUENCY BAND 470-
590 MHZ; http://www.erodocdb.dk/Docs/doc98/official/pdf/
ECCREP159.PDF", January 2011.
[FCC Ruling] 10.2. Informational References
FCC, "Federal Communications Commission, "Unlicensed
Operation in the TV Broadcast Bands;
http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf"",
December 2010.
[Ofcom Implementing] [Home] "", <view-source:http://www.dtv.gov/>.
Ofcom, "Ofcom, "Implementing Geolocation; http://
stakeholders.ofcom.org.uk/consultations/geolocation/
statement/"", September 2011.
[Ofcom Requirements] URIs
Ofcom, "Ofcom, Regulatory requirements for white space
devices in the UHF TV band; http://www.cept.org/Documents/
se-43/6161/
SE43(12)Info11_Ofcom-regulatory-requirements-for-WSDs-in-
the-UHF-TV-band", July 2012.
[Spectrum Framework Review] [1] <http://en.wikipedia.org/wiki/Cognitive_radio>
Ofcom - Independent regulator and competition authority
for the UK communications industries, "Spectrum Framework
Review;
http://stakeholders.ofcom.org.uk/consultations/sfr/",
February 2005.
[TV Whitespace Tutorial Intro] [2] <http://earth-info.nga.mil/GandG/publications/tr8350.2/
IEEE 802 Executive Committee Study Group on TV White tr8350_2.html>
Spaces, "TV Whitespace Tutorial Intro; http://
grouper.ieee.org/groups/802/802_tutorials/2009-03/
2009-03-10%20TV%20Whitespace%20Tutorial%20r0.pdf",
March 2009.
Authors' Addresses Authors' Addresses
Scott Probasco (editor) Anthony Mancuso (editor)
Scott Probasco
Phone:
Fax:
Email: scott@probasco.me Email: scott@probasco.me
URI:
Basavaraj Patil Basavaraj Patil
Phone:
Fax:
Email: bpatil@ovi.com Email: bpatil@ovi.com
URI:
 End of changes. 199 change blocks. 
1510 lines changed or deleted 806 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/