draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt   draft-ietf-paws-problem-stmt-usecases-rqmts-03.txt 
Working Group Draft S. Probasco, Ed. Working Group Draft S. Probasco, Ed.
Internet-Draft B. Patil Internet-Draft B. Patil
Intended status: Informational Nokia Intended status: Informational Nokia
Expires: July 30, 2012 January 27, 2012 Expires: September 1, 2012 February 29, 2012
Protocol to Access White Space database: PS, use cases and rqmts Protocol to Access White Space database: PS, use cases and rqmts
draft-ietf-paws-problem-stmt-usecases-rqmts-02 draft-ietf-paws-problem-stmt-usecases-rqmts-03
Abstract Abstract
Portions of the radio spectrum that are allocated to a licensed, Portions of the radio spectrum that are assigned to a particular use
primary user but are unused or unoccupied at specific locations and but are unused or unoccupied at specific locations and times are
times are defined as "white space". The concept of allowing defined as "white space". The concept of allowing additional
secondary transmissions (licensed or unlicensed) 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 secondary transmissions do not interfere requirement is that these additional transmissions do not interfere
with the primary use of the spectrum. One approach to using the with the assigned use of the spectrum. One approach to using the
white space spectrum at a given time and location is to verify with a white space spectrum at a given time and location is to verify with a
database available channels. database for available channels.
This document describes the concept of TV White Spaces. It also This document describes the concept of TV White Spaces. It also
describes the problems that need to be addressed for enabling the use describes the problems that need to be addressed to enable white
of the primary user owned white space spectrum for secondary users, space spectrum for additional uses, without causing interference to
without causing interference, by querying a database which knows the currently assigned use, by querying a database which stores
channel availability at any given location and time. A number of information about the channel availability at any given location and
possible use cases of this spectrum and derived requirements are also time. A number of possible use cases of white space spectrum and
described. technology as well as a set of requirements for the database query
protocol are also described.
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 July 30, 2012. This Internet-Draft will expire on September 1, 2012.
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
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 TV white space . . . . . . . . . . . . . . 4 1.1. Introduction to white space . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 6 1.2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 6 1.2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 6
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 7
2.1. Conventions Used in This Document . . . . . . . . . . . . 7 2.1. Conventions Used in This Document . . . . . . . . . . . . 7
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
3. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. The concept of Cognitive Radio . . . . . . . . . . . . . . 8 3.1. The concept of Cognitive Radio . . . . . . . . . . . . . . 8
3.2. Background information on white space in US . . . . . . . 8 3.2. Background information on white space in the US . . . . . 8
3.3. Air Interfaces . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Background information on white space in the UK . . . . . 9
4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Air Interfaces . . . . . . . . . . . . . . . . . . . . . . 9
4.1. TVWS database discovery . . . . . . . . . . . . . . . . . 9 4. Use cases and protocol services . . . . . . . . . . . . . . . 10
4.2. Device registration with trusted Database . . . . . . . . 10 4.1. Protocol services . . . . . . . . . . . . . . . . . . . . 10
4.3. Hotspot: urban internet connectivity service . . . . . . . 11 4.1.1. White space database discovery . . . . . . . . . . . . 10
4.4. Wide-Area or Rural internet broadband access . . . . . . . 13 4.1.2. Device registration with trusted Database . . . . . . 11
4.5. Offloading: moving traffic to a white space network . . . 15 4.2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 12
4.6. TVWS for backhaul . . . . . . . . . . . . . . . . . . . . 17 4.2.1. Hotspot: urban Internet connectivity service . . . . . 12
4.7. Rapid deployed network for emergency scenario . . . . . . 18 4.2.2. Wide-Area or Rural Internet broadband access . . . . . 15
4.8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.2.3. White space serving as backhaul . . . . . . . . . . . 18
4.9. Indoor Networking . . . . . . . . . . . . . . . . . . . . 21 4.2.4. Rapid deployed network for emergency scenario . . . . 19
4.10. Machine to Machine (M2M) . . . . . . . . . . . . . . . . . 23 4.2.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . 20
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 24 4.2.6. Indoor Networking . . . . . . . . . . . . . . . . . . 23
5.1. Global applicability . . . . . . . . . . . . . . . . . . . 25 4.2.7. Machine to Machine (M2M) . . . . . . . . . . . . . . . 24
5.2. Database discovery . . . . . . . . . . . . . . . . . . . . 26 5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 26
5.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.1. Global applicability . . . . . . . . . . . . . . . . . . . 27
5.4. Data model definition . . . . . . . . . . . . . . . . . . 27 5.2. Database discovery . . . . . . . . . . . . . . . . . . . . 28
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 29
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 5.4. Data model definition . . . . . . . . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 29
9. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 31 6.1. Normative Requirements . . . . . . . . . . . . . . . . . . 29
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 6.2. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 35
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
11.1. Normative References . . . . . . . . . . . . . . . . . . . 32 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35
11.2. Informative References . . . . . . . . . . . . . . . . . . 32 9. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.1. Normative References . . . . . . . . . . . . . . . . . . . 39
11.2. Informative References . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
1.1. Introduction to TV 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 The spectrum is used for various purposes, which include but are not
entertainment (e.g. radio and television), communication (telephony limited to entertainment (e.g. radio and television), communication
and Internet access), military (radars etc.) and, navigation (telephony and Internet access), military (radars etc.) and,
(satellite communication, GPS). Portions of the radio spectrum that navigation (satellite communication, GPS). Portions of the radio
are allocated to a licensed, primary user but are unused or spectrum that are assigned to a licensed user but are unused or
unoccupied at specific locations and times are defined as "white unoccupied at specific locations and times are defined as "white
space". The concept of allowing secondary transmissions (licensed or space". The concept of allowing additional transmissions (which may
unlicensed) in white space is a technique to "unlock" existing or may not be licensed) in white space is a technique to "unlock"
spectrum for new use. An obvious requirement is that these secondary existing spectrum for new use. An obvious requirement is that these
transmissions do not interfere with the primary use of the spectrum. additional transmissions do not interfere with the assigned use of
One interesting observation is that often, in a given physical the spectrum. One interesting observation is that often, in a given
location, the primary user(s) may not be using the entire band physical location, the assigned user(s) may not be using the entire
allocated to them. The available spectrum for a secondary use would band assigned to them. The available spectrum for additional
then depend on the location of the secondary user. The fundamental transmissions would then depend on the location of the additional
issue is how to determine for a specific location and specific time, user. The fundamental issue is how to determine for a specific
if any of the primary spectrum is available for secondary use. location and specific time, if any of the assigned spectrum is
Academia and Industry have studied multiple cognitive radio available for additional use. Academia and Industry have studied
mechanisms for use in such a scenario. One simple mechanism is to multiple cognitive radio mechanisms for use in such a scenario. One
use a geospatial database that records the primary users occupation, simple mechanism is to use a geospatial database that records the
and require the secondary users to check the database prior to assigned users occupation, and require the additional users to check
selecting what part of the spectrum they use. Such databases could the database prior to selecting what part of the spectrum they use.
be available on the Internet for query by secondary users. Such databases could be available on the Internet for query by
additional users.
Spectrum useable for data communications, especially wireless Spectrum useable for data communications, especially wireless
Internet communications, is scarce. One area which has received much Internet communications, is scarce. One area which has received much
attention globally is the TV white space: portions of the TV band attention globally is the TV white space: portions of the TV band
that are not used by broadcasters in a given area. In 2008 the that are not used by broadcasters in a given area. In 2008 the
United States regulator (the FCC) took initial steps when they United States regulator (the FCC) took initial steps when they
published their first ruling on the use of TV white space, and then published their first ruling on the use of TV white space, and then
followed it up with a final ruling in 2010 [FCC Ruling]. Finland followed it up with a final ruling in 2010 [FCC Ruling]. Finland
passed an Act in 2009 enabling testing of cognitive radio systems in passed an Act in 2009 enabling testing of cognitive radio systems in
the TV white space. The ECC has completed Report 159 [ECC Report the TV white space. The ECC has completed Report 159 [ECC Report
159] containing requirements for operation of cognitive radio systems 159] containing requirements for operation of cognitive radio systems
in the TV white space. Ofcom published in 2004 their Spectrum in the TV white space. Ofcom published in 2004 their Spectrum
Framework Review [Spectrum Framework Review] and their Digital Framework Review [Spectrum Framework Review] and their Digital
Dividend Review [DDR] in 2005, and have followed up with a proposal Dividend Review [DDR] in 2005, with proposals from 2009 onwards to
to access TV white space. More countries are expected to provide access TV white space, culminating in the 2011 Ofcom Statement
access to their TV spectrum in similar ways. Any entity holding Implementing Geolocation [Ofcom Implementing]. More countries are
spectrum that is not densely used may be asked to give it up in one expected to provide access to their TV spectrum in similar ways. Any
way or another for more intensive use. Providing a mechanism by entity that is assigned spectrum that is not densely used may be
which secondary users share the spectrum with the primary user is asked to give it up in one way or another for more intensive use.
attractive in many bands in many countries. Providing a mechanism by which additional users share the spectrum
with the assigned user is attractive in many bands in many countries.
Television transmission until now has primarily been analog. The Television transmission until now has primarily been analog. The
switch to digital transmission has begun. As a result the spectrum switch to digital transmission has begun. As a result the spectrum
allocated for television transmission can now be more effectively assigned for television transmission can now be more effectively
used. Unused channels and bands between channels can be used as long used. Unused channels and bands between channels can be used by
as they do not interfere with the primary service for which that additional users as long as they do not interfere with the service
channel is allocated. While urban areas tend to have dense usage of for which that channel is assigned. While urban areas tend to have
spectrum and a number of TV channels, the same is not true in rural dense usage of spectrum and a number of TV channels, the same is not
and semi-urban areas. There can be a number of unused TV channels in true in semi-rural, rural and remote areas. There can be a number of
such areas that can be used for other services. The figure below unused TV channels in such areas that can be used for other services.
shows TV white space within the lower UHF band: Figure 1 shows TV white space within the lower UHF band:
Avg | Avg |
usage| |-------------- White Space usage| |-------------- White Space
| | | | | | | | | | | |
0.6| || || V V || 0.6| || || V V ||
| || ||| | || | || ||| | ||
0.4| || |||| | || 0.4| || |||| | ||
| || |||| | ||<----TV transmission | || |||| | ||<----TV transmission
0.2| || |||| | || 0.2| || |||| | ||
|---------------------------------------- |----------------------------------------
400 500 600 700 800 400 500 600 700 800
Frequency in MHz -> Frequency in MHz ->
Figure 1: High level view of TV White Space Figure 1: High level view of TV White Space
The fundamental issue is how to determine for a specific location and The fundamental issue is how to determine for a specific location and
specific time if any of the spectrum is available for secondary use. specific time if any of the spectrum is available for additional use.
There are two dimensions of use that may be interesting: space (the There are two dimensions of use that may be interesting: space (the
area in which a secondary user would not interfere with a primary area in which an additional user would not interfere with the
user, and time: when the secondary use would not interfere with the assigned use), and time: when the additional transmission would not
primary use. In this discussion, we consider the time element to be interfere with the assigned use. In this discussion, we consider the
relatively long term (hours in a day) rather than short term time element to be relatively long term (hours in a day) rather than
(fractions of a second). Location in this discussion is geolocation: short term (fractions of a second). Location in this discussion is
where the transmitters (and sometimes receivers) are located relative geolocation: where the transmitters (and sometimes receivers) are
to one another. In operation, the database records the existing located relative to one another. In operation, the database records
user's transmitter (and some times receiver) locations along with the assigned user's transmitter (and some times receiver) locations
basic transmission characteristics such as antenna height, and along with basic transmission characteristics such as antenna height,
sometimes power. Using rules established by the regulator, the and sometimes power. Using rules established by the local regulator,
database calculates an exclusion zone for each authorized primary the database calculates an exclusion zone for each assigned user, and
user, and attaches a time schedule to that use. The secondary user attaches a time schedule to that use. The additional user queries
queries the database with its location. The database intersects the the database with its location. The database intersects the
exclusion zones with the queried location, and returns the portion of exclusion zones with the queried location, and returns the portion of
the spectrum not in any exclusion zone. Such methods of geospatial the spectrum not in any exclusion zone. Such methods of geospatial
database query to avoid interference have been shown to achieve database query to avoid interference have been shown to achieve
favorable results, and are thus the basis for rulings by the FCC and 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 reports from ECC and Ofcom. In any country, the rules for which
primary entities are entitled to protection, how the exclusion zones assigned entities are entitled to protection, how the exclusion zones
are calculated, and what the limits of use by secondary entities are are calculated, and what the limits of use are by additional users
may vary. However, the fundamental notion of recording primary may vary. However, the fundamental notion of recording assigned
users, calculating exclusion zones, querying by location and users, calculating exclusion zones, querying by location and
returning available spectrum (and the schedule for that spectrum) are returning available spectrum (and the schedule for that spectrum) are
common common.
This document includes the problem statement, use cases and This document includes the problem statement, use cases and
requirements associated with the use of white space spectrum by 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 applies only to communications required for basic
skipping to change at page 6, line 33 skipping to change at page 6, line 35
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 return a list of currently available white space using 5. Receive in response to the query a list of currently available
a well-defined format for returning information. white space channels or frequencies using a well-defined format
for the information.
As a result, some of the scenarios described in the following section As a result, some of the scenarios described in the following section
are out of scope for this specification (although they might be are out of scope for this specification (although they might be
addressed by future specifications). addressed by future specifications).
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:
TBD Co-existence and interference avoidance of white space devices
within the same spectrum
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
skipping to change at page 7, line 15 skipping to change at page 7, line 18
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
In the context of white space and cognitive radio technologies, In the context of white space and cognitive radio technologies,
the database is an entity which contains current information about the database is an entity which contains, but is not limited to,
available spectrum at any given location and other types of current information about available spectrum at any given location
information. and other types of related (to the white space spectrum) or
relevant information.
Device ID Device ID
A unique number for each master device and slave device that A unique number for each master device and slave device that
identifies the manufacturer, model number and serial number. identifies the manufacturer, model number and serial number.
Location Based Service Location Based Service
An application or device which provides data, information or An application or device which provides data, information or
service to a user based on their location. service to a user based on their location.
Master Device Master Device
A device which queries the WS Database to find out the available A device which queries the WS Database to find out the available
operating channels. operating channels.
Protected Entity Protected Entity
A primary user of white space spectrum which is afforded An assigned user of white space spectrum which is afforded
protection against interference by secondary users (white space protection against interference by additional users (white space
devices) for its use in a given area and time. devices) for its use in a given area and time.
Protected Contour Protected Contour
The exclusion area for a Protected Entity, held in the database The exclusion area for a Protected Entity, held in the database
and expressed as a polygon with geospatial points as the vertices. and expressed as a polygon with geospatial points as the vertices.
Slave Device Slave Device
A device which uses the spectrum made available by a master A device which uses the spectrum made available by a master
device. device.
TV White Space TV White Space
TV white space refers specifically to radio spectrum which has TV white space refers specifically to radio spectrum which has
been allocated for TV broadcast, but is not occupied by a TV been allocated for TV broadcast, but is not occupied by a TV
broadcast, or other licensed user (such as a wireless microphone), broadcast, or other assigned user (such as a wireless microphone),
at a specific location and time. at a specific location and time.
White Space TV White Space Device (TVWSD)
Radio spectrum which has been allocated for some primary use, but A White Space Device that operates in the TV bands.
is not fully occupied by that primary use at a specific location
White Space (WS)
Radio spectrum which is not fully occupied at a specific location
and time. and time.
White Space Device (WSD) White Space Device (WSD)
A device which is a secondary user of some part of white space A device which opportunistically uses some part of white space
spectrum. A white space device can be an access point, base spectrum. A white space device can be an access point, base
station, a portable device or similar. In this context, a white station, a portable device or similar. A white space device may
space device is required to query a database with its location to be required by local regulations to query a database with its
obtain information about available spectrum. location to obtain information about available spectrum.
3. Prior Work 3. Prior Work
3.1. The concept of Cognitive Radio 3.1. The concept of Cognitive Radio
A cognitive radio uses knowledge of the local radio environment to A cognitive radio uses knowledge of the local radio environment to
dynamically adapt its own configuration and function properly in a dynamically adapt its own configuration and function properly in a
changing radio environment. Knowledge of the local radio environment changing radio environment. Knowledge of the local radio environment
can come from various technology mechanisms including sensing can come from various technology mechanisms including sensing
(attempting to ascertain primary users by listening for them within (attempting to ascertain primary users by listening for them within
the spectrum), location determination and internet connectivity to a the spectrum), location determination and Internet connectivity to a
database to learn the details of the local radio environment. TV database to learn the details of the local radio environment. White
White Space is one implementation of cognitive radio. Because a Space is one implementation of cognitive radio. Because a cognitive
cognitive radio adapts itself to the available spectrum in a manner radio adapts itself to the available spectrum in a manner that
that prevents the creation of harmful interference, the spectrum can prevents the creation of harmful interference, the spectrum can be
be shared among different radio users. shared among different radio users.
3.2. Background information on white space in US 3.2. Background information on white space in the US
Television transmission in the United States has moved to the use of 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- 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 power U.S. television stations have broadcast over-the-air signals in
digital only. An important benefit of the switch to all-digital digital only. An important benefit of the switch to all-digital
broadcasting is that it freed up parts of the valuable broadcast broadcasting is that it freed up parts of the valuable broadcast
spectrum. More information about the switch to digital transmission spectrum. More information about the switch to digital transmission
is at : [DTV]. is at : [DTV].
With the switch to digital transmission for TV, the guard bands that Besides the switch to digital transmission for TV, the guard bands
existed to protect the signals between stations can now be used for that exist to protect the signals between stations can be used for
other purposes. The FCC has made this spectrum available for other purposes. The FCC has made this spectrum available for
unlicensed use and this is generally referred to as white space. unlicensed use and this is generally referred to as white space.
Please see the details of the FCC ruling and regulations in [FCC Please see the details of the FCC ruling and regulations in [FCC
Ruling]. The spectrum can be used to provide wireless broadband as Ruling]. The spectrum can be used to provide wireless broadband as
an example. The term "Super-Wifi" is also used to describe this an example.
spectrum and potential for providing wifi type of service.
3.3. Air Interfaces 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 Efforts are ongoing to specify air-interfaces for use in white space
spectrum. IEEEs 802.11af task group is currently working on one such spectrum. IEEE 802.11af, IEEE 802.15.4m and IEEE 802.22 are all
specification. IEEE 802.22 is another example. Other air interfaces examples. Other air interfaces could be specified in the future such
could be specified in the future such as LTE. as LTE.
4. Use cases 4. Use cases and protocol services
There are many potential use cases that could be considered for the There are many potential use cases that could be considered for the
TV white space spectrum. Providing broadband internet access in TV white space spectrum. Providing broadband Internet access in
hotspots, rural and underserved areas are examples. Available hotspots, rural and underserved areas are examples. Available
channels may also be used to provide internet 'backhaul' for channels may also be used to provide Internet 'backhaul' for
traditional Wi-Fi hotspots, or by towns and cities to monitor/control traditional Wi-Fi hotspots, or by towns and cities to monitor/control
traffic lights or read utility meters. Still other use cases include traffic lights or read utility meters. Still other use cases include
the ability to offload data traffic from another internet access the ability to offload data traffic from another Internet access
network (e.g. 3G cellular network) or to deliver location based network (e.g. 3G cellular network) or to deliver location based
services. Some of these use cases are described in the following services. Some of these use cases are described in the following
sections. sections.
4.1. TVWS database discovery 4.1. Protocol services
This use case is preliminary to creating a radio network using TV A complete protocol solution must provide all services that are
white space; it is a prerequisite to other use cases. The radio essential to enable the white space paradigm. Before a white space
network is created by a master device. Before the master device can device can request service from a white space database, such as a
transmit in TV white space spectrum, it must contact a trusted query for a list of available channels, the white space device must
database where the device can learn if any channels are available for first locate or "discover" a suitable database. Additionally, some
it to use. The master device will need to discover a trusted regulatory authorities require the white space device to register
database in the relvant regulatory domain, using the following steps: with the database as a first step. This section describes the
services required from the protocol.
1. The master device is connected to the internet by any means other 4.1.1. White space database discovery
than using the TV white space radio.
White space database discovery is preliminary to creating a radio
network using white space; it is a prerequisite to the use cases
below. The radio network is created by a master device. Before the
master device can transmit in white space spectrum, it must contact a
trusted database where the device can learn if any channels are
available for it to use. The master device will need to discover a
trusted database in the relevant regulatory domain, using the
following steps:
1. The master device is connected to the Internet by any means other
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 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
register and 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 TV white space network (as Internet addresses and establish a white space network (as described
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 Optionally the initial query will be made to a listing approved by
the national regulator for the domain of operation (e.g. a website the national regulator for the domain of operation (e.g. a website
either hosted by or under control of the national regulator) which either hosted by or under control of the national regulator) which
maintains a list of TVWS databases and their internet addresses. The maintains a list of WS databases and their Internet addresses. The
query results in the list of databases and their internet addresses query results in the list of databases and their Internet addresses
being sent to the master, which then evaluates the repsonse to being sent to the master, which then evaluates the response to
determine if a trusted database can be identified where the master determine if a trusted database can be identified where the master
device is able to register and receive service from the database. device is able to register and receive service from the database.
4.2. Device registration with trusted Database 4.1.2. Device registration with trusted Database
This use case is preliminary to creating a radio network using TV Registration may be preliminary to creating a radio network using
white space; it is a prerequisite to other use cases. The radio white space; in some regulatory domains, for some device types, it is
network is created by a master device. Before the master device can a prerequisite to the use cases below. The radio network is created
transmit in TV white space spectrum, it must contact a trusted by a master device. Before the master device can transmit in white
database where the device can learn if any channels are available for space spectrum, it must contact a trusted database where the device
it to use. Before the database will provide information on available can learn if any channels are available for it to use. Before the
TV channels, the master device must register with the trusted database will provide information on available radio channels, the
database. Specific requirements for registration come from master device must register with the trusted database. Specific
individual regulatory domains and may be different. requirements for registration come from individual regulatory domains
and may be different.
The figure below shows an example deployment of this scenario. Figure 2 shows an example deployment of this scenario.
\|/ ---------- \|/ ----------
| |Database| | |Database|
| .---. /--------- | .---. /---------
|-|---------| ( ) / |-|---------| ( ) /
\|/ | Master | / \ \|/ | Master | / \
| / | |========( Internet ) | / | |========( Internet )
| / |-----------| \ / | / |-----------| \ /
+-|----+ (TDD AirIF) ( ) +-|----+ (TDD AirIF) ( )
|Master| / (----) |Master| / (----)
| | / | | /
+------+ +------+
Figure 2: Example illustration of registration requirement in TV Figure 2: Example illustration of registration requirement in white
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 the most current and up-to- 1. The master device must register with its most current and up-to-
date information. Typically the master device will register date information. Typically the master device will register
prior to operating in TV white space for the first time after prior to operating in white space for the first time after power
power up, after changing location by a predetermined distance, up, after changing location by a predetermined distance, and
and after regular time intervals. after regular time intervals.
2. The master device shall provide to the database during 2. The master device shall provide to the database during
registration a minimum of the Device ID, serial number assigned registration all information required according to local
by the manufacturer and the device's location. 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. Depending upon regulatory domain requirements, the device may 3. The database shall respond to the registration request with an
also provide device antenna height above ground, name of the acknowledgement code to indicate the success or failure of the
individual or business that owns the device, name of a contact registration request. Additional information may be provided
person responsible for the device's operation, address for the according to local regulator requirements.
contact person, email address for the contact person and phone
number of the contact person to the database during registration.
4.3. Hotspot: urban internet connectivity service 4.2. Use cases
In this use case internet connectivity service is provided in a 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 "hotspot" to local users. Typical deployment scenarios include urban
areas where internet connectivity is provided to local businesses and areas where Internet connectivity is provided to local businesses and
residents, and campus environments where internet connectivity is residents, and campus environments where Internet connectivity is
provided to local buildings and relatively small outdoor areas. This provided to local buildings and relatively small outdoor areas. This
deployment scenario is typically characterized by multiple masters deployment scenario is typically characterized by multiple masters
(APs or hotspots) in close proximity, with low antenna height, cells (APs or hotspots) in close proximity, with low antenna height, cells
with relatively small radius (a few kilometers or less), and limited with relatively small radius (a few kilometers or less), and limited
numbers of available radio channels. Many of the masters/APs are numbers of available radio channels. Many of the masters/APs are
assumed to be individually deployed and operated, i.e. there is no assumed to be individually deployed and operated, i.e. there is no
coordination between many of the masters/APs. The masters/APs in coordination between many of the masters/APs. The masters/APs in
this scenario use a TDD radio technology and transmit at or below a this scenario use a TDD radio technology. Each master/AP has a
relatively low transmit power threshold. Each master/AP has a connection to the Internet and may provide Internet connectivity to
connection to the internet and provides internet connectivity to other master and slave devices.
multiple master and or slave devices.
The figure below shows an example deployment of this scenario. Figure 3 shows an example deployment of this scenario.
-------- --------
|Device|\ \|/ ---------- |Device|\ \|/ ----------
| 1 | (TDD AirIF) | |Database| | 1 | (TDD AirIF)\ | |Database|
-------- \ | .---. /--------- -------- \ | (----) /---------
o \ |-|---------| ( ) / | \ |-|---------| ( ) /
o | Master | / \ | \| Master | / \
o / | |========( Internet ) -------- /| |========( Internet )
o / |-----------| \ / |Device| /(TDD AirIF)/ |-----------| \ /
-------- (TDD AirIF) ( ) | 2 | / / ( )
|Device| / (----) ------- / (----)
o | /
o | (TDD AirIF)
o | /
--------/
|Device|
| n | | n |
-------- --------
Figure 3: Hotspot service using TV white space spectrum Figure 3: Hotspot service using TV white space spectrum
Once a master/AP has been correctly installed and configured, a Once a master/AP has been correctly installed and configured, a
simplified power up and operation scenario utilizing TV White Space simplified power up and operation scenario utilizing TV White Space
to provide Internet connectivity service consists of the following to provide Internet connectivity service to slave devices, including
steps: 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 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 capable devices will power up in idle/listen only mode (no
transmissions on the WS frequency band). 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 and establishes a 2. The master/AP has Internet connectivity, determines its location
connection to a trusted white space database (see Section 4.1). (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 3. The master/AP registers with the trusted database according to
regulatory domain requirements (see Section 4.2). regulatory domain requirements (see Section 4.1.2).
4. Following the registration process, the master/AP will send a 4. Following the successful registration process (if registration
query to the trusted database requesting a list of available WS is required), the master/AP will send a query to the trusted
channels based upon its geolocation. 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. 5. If the master/AP has met all regulatory domain requirements
been previously authenticated, etc), the database responds with a (e.g. been previously authenticated, etc), the database responds
list of available white space channels that the master may use, with a list of available white space channels that the master
and optionally a duration of time for their use. 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 6. Once the master/AP has met all regulatory domain requirements
(e.g. authenticated the WS channel list response message from the (e.g. authenticated the WS channel list response message from
database, etc), the AP selects an available WS channel(s) from the database, etc), the AP selects one or more available WS
the list. channels from the list.
7. The slave or user device scans the TV bands to locate a master/AP 7. The slave or user device scans the TV bands to locate a
transmission, and associates with the AP. The slave/user device master/AP transmission, and associates with the AP.
queries the master for a channel list, providing to the master
the slaves' Device ID and geolocation.
8. Once the master/AP has met all regulatory domain requirements 8. The slave/user device queries the master for a channel list. In
(e.g. validating the Device ID with the trusted database, etc) the query the slave/user device provides attributes that are
the master provides the list of channels locally available to the defined by local regulations. These may include the slaves'
slave/user device. If the channel that the user terminal is Device ID and its geolocation.
currently using is not included in the list of locally available
channels, the slave/user device ceases all operation on its
current channel. The slave/user device may scan for another AP
transmission on a different channel.
4.4. Wide-Area or Rural internet broadband access 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.
In this use case, internet broadband access is provided as a Wide- 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
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.2. Wide-Area or Rural Internet broadband access
In this use case, Internet broadband access is provided as a Wide-
Area Network (WAN) or Wireless Regional Area Network (WRAN). A Area Network (WAN) or Wireless Regional Area Network (WRAN). A
typical deployment scenario is a wide area or rural area, where typical deployment scenario is a wide area or rural area, where
internet broadband access is provided to local businesses and Internet broadband access is provided to local businesses and
residents from a master (i.e. BS) connected to the internet. This residents from a master (i.e., BS) connected to the Internet. This
deployment scenario is typically characterized by one or more fixed deployment scenario is typically characterized by one or more fixed
master(s)/BS(s), cells with relatively large radius (tens of master(s)/BS(s), cells with relatively large radius (tens of
kilometers, up to 100 km), and a number of available radio channels. 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 Some of the masters/BSs may be deployed and operated by a single
entity, i.e. there can be centralized coordination between these entity, i.e., there can be centralized coordination between these
masters/BSs, whereas other masters/BSs may be deployed and operated masters/BSs, whereas other masters/BSs may be deployed and operated
by operators competing for the radio channels in a license-exempt by operators competing for the radio channels where decentralized
TVWS environment where decentralized coordination using the air- coordination using the air-interface would be required. The BS in
interface would be required. The BS in this scenario use a TDD radio this scenario uses a TDD radio technology and transmits at or below a
technology and transmit at or below a transmit power limit transmit power (EIRP) limit established by the local regulator. Each
established by the local regulator. Each base station has a base station has a connection to the Internet and may provide
connection to the internet and provides internet connectivity to Internet connectivity to multiple slaves/user devices. End-user
multiple slave/end-user devices. End user terminals or devices may terminals or devices may be fixed or portable.
be fixed or portable.
The figure below shows an example deployment of this scenario. Figure 4 shows an example deployment of this scenario.
------- -------
|Slave|\ \|/ ---------- |Slave|\ \|/ ----------
|Dev 1| (TDD AirIF) | |Database| |Dev 1| (TDD AirIF) | |Database|
------- \ | .---. /---------- ------- \ | .---. /----------
o \ |-|---------| ( ) / o \ |-|---------| ( ) /
o | Master | / \ o | Master | / \
o / | (BS) |========( Internet ) o / | (BS) |========( Internet )
o / |-----------| \ / o / |-----------| \ /
------- (TDD AirIF) ( ) ------- (TDD AirIF) ( )
|Slave| / (----) |Slave| / (----)
|Dev n| |Dev n|
------- -------
Figure 4: Rural internet broadband access using TV white space Figure 4: Rural Internet broadband access using TV white space
spectrum spectrum
Once the master/BS has been professionally installed and configured, Once the master/BS has been professionally installed and configured,
a simplified power up and operation scenario utilizing TV White Space a simplified power up and operation scenario utilizing TV White Space
to provide rural internet broadband access consists of the following to provide rural Internet broadband access consists of the following
steps: steps:
1. The master/BS powers up; however its WS radio and all other WS 1. The master/BS powers up; however its WS radio and all other WS
capable devices will power up in idle/listen only mode (No active capable devices will power up in idle/listen-only mode (no
transmissions on the WS frequency band) active transmissions on the WS frequency band).
2. The master/BS has internet connectivity and establishes a
connection to a trusted white space database (see use case "TVWS
database discovery" above).
3. The master/BS registers its geolocation, address, contact
information, etc. associated with the owner/operator of the
master/BS with the trusted database service (if not currently
registered, see Section 4.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
administrator 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 registration process, the master/BS will send a
query to the trusted database requesting a list of available WS
channels based upon its geolocation.
5. If the master/BS has been previously authenticated, the database
responds with a list of available white space channels that may
be used and optionally a maximum transmit power (EIRP) for each
channel and a duration of time the channel may be used.
6. Once the master/BS authenticates the WS channel list response
message from the database, the master/BS selects an available WS
channel(s) from the list. The operator may 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
transmission, and associates with the master/BS. The slave/user
device provides its geolocation to the BS which, in turn, queries
the database for a list of channels available at the slaves'
geolocation.
8. Once this list of available channels is received from the
database by the master, the latter will decide, based on the list
of available channels for all its other associated slaves whether
it should continue operation on its current channel or change
channel to accommodate the new slave in case this channel is not
available at its location. The master will notify all its
associated slaves/user devices of the new channel to move to if
operation needs to change channel. If the channel that the user
terminal is currently using is not included in the list of
locally available channels, the master will drop its association
with the slave/user device so that it ceases all operation on its
current channel and indicate the new operating channel before
dropping the link if a change has been decided. The slave/user
device may move to the indicated new channel if so indicated or
scan for another WRAN transmission on a different channel.
4.5. Offloading: moving traffic to a white space network 2. The master/BS 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).
In this use case internet connectivity service is provided over TV 3. The master/BS registers with the trusted database service (see
white space as a supplemental or alternative datapath to a 3G or Section 4.1.2). Meanwhile the DB administrator may be required
other internet connection. In a typical deployment scenario an end to store and forward the registration information to the
user has a primary internet connection such as a 3G cellular packet regulatory authority. If a trusted white space database service
data subscription. The user wants to use a widget or application to is not discovered, further operation of the WRAN may be allowed
stream video from an online service (e.g. youtube) to their device. according to local regulator policy (in this case operation of
Before the widget starts the streaming connection it checks the WRAN is outside the scope of the PAWS protocol).
connectivity options available at the current time and location.
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. 4. Following the successful registration process (if registration
is required), the master/BS 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 identifier, location,
accuracy of that location, device antenna height, etc...
\|/ 5. If the master/BS has been previously authenticated, the database
| responds with a list of available white space channels that may
| be used by the master/BS and optionally a maximum transmit power
|-|---------| (EIRP) for each channel, a duration of time the channel may be
| Master/AP |\ used or a notification of any additional requirement for
/| Router | \ sensing.
Streaming/ |-----------| \
-------- / \ -----------
|Slave/| / \ (----) | Database |
|WS Dev| \ ( ) /----------
------- \ \ / \
\ X( Internet )
\ / \ /
Signaling \|/ / ( )\
\ | / (----) \----------
\ | / | YouTube |
\|-|---------| / ----------
| | /
| 3G BTS |/
|-----------|
Figure 5: Offloading: moving traffic to a white space network 6. Once the master/BS authenticates the WS channel list response
message from the database, the master/BS selects an available WS
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.
Once a dual or multi mode device (3G + TVWS) is connected to a 3G 7. The slave or user device scans the TV bands to locate a WRAN
network, a simplified operation scenario of offloading selected transmission, and associates with the master/BS.
content such as video stream from the 3G connection to the TWVS
connection consists of the following steps:
1. The dual mode (or multi mode) device (3G + TVWS) is connected to 8. The slave/user device provides its geolocation to the BS which,
a 3G network. The device has contacted a trusted database to in turn, queries the database for a list of channels available
discover the list of available TV channels at its current at the slave's geolocation.
location. The device has located a TVWS master/AP operating 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 9. Once this list of available channels is received from the
from YouTube. The widget connects to YouTube over 3G cellular database by the master, the latter will decide, based on this
data. The user browses content and searches for video list of available channels and on the lists for all its other
selections. associated slaves/user devices whether it should: a) continue
operation on its current channel if this channel is available to
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.
3. The user selects a video for streaming using the widget's 10. The master/BS must periodically repeat the process to request a
controls. Before the widget initiates a streaming session, the list of available channels from the database for itself and for
widget checks the available connections in the dual mode device all its associated slaves/user devices. If the response from
and finds a TVWS master/AP is connected. the database indicates that the channel being used by the
master/BS is no longer available for its use, the master/BS must
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 not 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.
4. Using either input from the user or pre-defined profile 11. The slave/user device must transmit its new geographic location
preferences, the widget selects the TVWS master/AP as the every time it changes so that the repeated process described
connection to stream the video. under item 10 can rely on the most up-to-date geolocation of the
slave/user device.
4.6. TVWS for backhaul 4.2.3. White space serving as backhaul
In this use case internet connectivity service is provided to users In this use case Internet connectivity service is provided to users
over a traditional wireless protocol, one common example is Wi-Fi. over a more common wireless standard such as Wi-Fi with white space
The TV white space network provides the "backhaul" or connection from entities providing backhaul connectivity to the Internet. In a
the Wi-Fi to the internet. In a typical deployment scenario an end typical deployment scenario an end user has a device with a radio
user has a device with a radio such as Wi-Fi. A service provider or such as Wi-Fi. An Internet service provider or a small business
shop owner wants to provide Wi-Fi internet service for their owner wants to provide Wi-Fi Internet connectivity service to their
customers. The location where the service provider wants to provide customers. The location where Internet connectivity service via
Wi-Fi is within range of a TVWS master (e.g. Hotspot or Wide-Area/ Wi-Fi is to be provided is within the coverage area of a white space
Rural network). The service provider installs a TVWS slave device master (e.g. Hotspot or Wide-Area/Rural network). The service
and connects this slave to a Wi-Fi access point. This deployment provider installs a white space slave device and connects it to the
scenario is typically characterized by a TVWS master/AP/BS providing Wi-Fi access point(s). Wi-Fi access points with an integrated white
local coverage. The master/AP has a connection to the internet and space slave component may also be used. This deployment scenario is
provides internet connectivity to the slave device. The slave device typically characterized by a WS master/AP/BS providing local
is then 'bridged' to a Wi-Fi network 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.
The figure below shows an example deployment of this scenario. Figure 5 shows an example deployment of this scenario.
\|/ white \|/ \|/ WiFi \|/ \|/ white \|/ \|/ Wi-Fi \|/
| space | | | | space | | |
| | | |-|----| | | | |-|----|
|--------| |-|---------| |-|------|-| | WiFi | |--------| |-|---------| |-|------|-| | Wi-Fi|
| | | Master | | Slave | | Dev | | | | Master | | Slave | | Dev |
|internet|------| (AP/BS) | | Bridge | |------| |Internet|------| (AP/BS) | | Bridge | |------|
| | | | | to WiFi | | | | | | to Wi-Fi |
|--------| |-----------| |----------| \|/ |--------| |-----------| |----------| \|/
| |
|-|----| |-|----|
| WiFi | | Wi-Fi|
| Dev | | Dev |
|------| |------|
Figure 6: TVWS for backhaul Figure 5: WS for backhaul
Once the bridged device (TVWS+WiFi) is connected to a master and TVWS Once the bridged device (WS + Wi-Fi) is connected to a master and WS
network, a simplified operation scenario of backhaul for WiFi network, a simplified operation scenario of backhaul for Wi-Fi
consists of the following steps: consists of the following steps:
1. A bridged device (TVWS+WiFi) is connected to a master device 1. A bridged device (WS + Wi-Fi) is connected to a master device
operating in the TVWS. The bridged device operates as a slave operating in the WS spectrum. The bridged device operates as a
device in either Hotspot or Wide-Area/Rural internet use cases slave device in either Hotspot or Wide-Area/Rural Internet use
described above. 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 configures its internet settings automatically based access point has Internet connectivity as well.
on the backhaul connection (i.e. it uses DHCP).
3. End users connect their WiFi device to the bridged device and 3. End users attach to the Wi-Fi network via their Wi-Fi enabled
receive internet connectivity. devices and receive Internet connectivity.
4.7. Rapid deployed network for emergency scenario 4.2.4. Rapid deployed network for emergency scenario
Organizations involved in handling emergency operations often have a Organizations involved in handling emergency operations often have a
fully owned and controlled infrastructure, with dedicated spectrum, fully owned and controlled infrastructure, with dedicated spectrum,
for day to day operation. However, lessons learned from recent for day to day operation. However, lessons learned from recent
disasters show such infrastructures are often highly affected by the disasters show such infrastructures are often highly affected by the
disaster itself. To set up a replacement quickly, there is a need disaster itself. To set up a replacement quickly, there is a need
for fast reallocation of spectrum, where in certain cases spectrum for fast reallocation of spectrum, where in certain cases spectrum
can be freed for disaster relief. To utilize free or freed spectrum can be cleared for disaster relief. To utilize unused or cleared
quickly and reliable, automation of allocation, assignment and spectrum quickly and reliably, automation of allocation, assignment
configuration is needed. A preferred option is make use of a robust and configuration is needed. A preferred option is to make use of a
protocol, already adopted by radio manufacturers. This approach does robust protocol, already adopted by radio manufacturers. This
in no way imply such organizations for disaster relief must compete approach does in no way imply such organizations for disaster relief
on spectrum allocation with other white spaces users, but they can. must compete on spectrum allocation with other white spaces users,
A typical network topology would include wireless access links to the but they can. A typical network topology would include wireless
public Internet or private network, wireless ad hoc network radios access links to the public Internet or private network, wireless ad
working independent of a fixed infrastructure and satellite links for hoc network radios working independent of a fixed infrastructure and
backup where lack of coverage, overload or outage of wireless access satellite links for backup where lack of coverage, overload or outage
links occur. of wireless access links occur.
The figure below shows an example deployment of this scenario. Figure 6 shows an example deployment of this scenario.
\|/ \|/
| ad hoc | ad hoc
| |
|-|-------------| |-|-------------|
| Master node | |------------| | Master node | |------------|
\|/ | with | | Whitespace | \|/ | with | | Whitespace |
| ad hoc /| backhaul link | | Database | | ad hoc /| backhaul link | | Database |
| /------/ |---------------| |------------| | /------/ |---------------| |------------|
---|------------/ | \ / ---|------------/ | \ /
skipping to change at page 19, line 28 skipping to change at page 20, line 32
\ | \ Internet ) \ | \ Internet )
\ \|/ | -------( /\ \ \|/ | -------( /\
\ | ad hoc | | (------) \--------- \ | ad hoc | | (------) \---------
\ | | / | Other | \ | | / | Other |
\--|------------- /Satellite | nodes | \--|------------- /Satellite | nodes |
| Master node | / Link ---------- | Master node | / Link ----------
| with |/ | with |/
| backhaul link | | backhaul link |
----------------- -----------------
Figure 7: Rapid deployed network with partly connected nodes Figure 6: Rapid deployed network with partly connected nodes
In the ad hoc network, all nodes are master nodes in a way that they 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 allocate RF channels from the white space database. However, the
backhaul link may not be available to all nodes, such as depicted for backhaul link may not be available to all nodes, such as depicted for
the left node in the figure. To handle RF channel allocation for the left node in Figure 6. To handle RF channel allocation for such
such nodes, a master node with a backhaul link relays or proxies the nodes, a master node with a backhaul link relays or proxies the
database query for them. So master nodes without a backhaul link database query for them. So master nodes without a backhaul link
follow the procedure as defined for clients. The ad hoc network follow the procedure as defined for clients. The ad hoc network
radios utilise the provided RF channels. Details on forming and radios utilize the provided RF channels. Details on forming and
maintenance of the ad hoc network, including repair of segmented maintenance of the ad hoc network, including repair of segmented
networks caused by segments operating on different RF channels, is networks caused by segments operating on different RF channels, is
out of scope of spectrum allocation. out of scope of spectrum allocation.
4.8. Mobility 4.2.5. Mobility
In this use case, the user has a non-fixed (portable or mobile) 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 device and is riding in a vehicle. The user wants to have
connectivity to another device which is also moving. Typical connectivity to another device which is also moving. Typical
deployment scenarios include urban areas and rural areas where the deployment scenarios include urban areas and rural areas where the
user may connect to other users in peer-to-peer or ad-hoc networks. user may connect to other users while moving. This deployment
This deployment scenario is typically characterized by a master scenario is typically characterized by a master device with low
device with low antenna height, internet connectivity by some antenna height, Internet connectivity by some connection that does
connection that does not utilize TV white space, and some means to not utilize TV white space, and some means to predict its path of
predict its path of mobility. This knowledge of mobility could be mobility. This knowledge of mobility could be simple (GPS plus
simple (GPS plus accelerometer), sophisticated (GPS plus routing and accelerometer), sophisticated (GPS plus routing and mapping function)
mapping function) or completely specified by the user via user- or completely specified by the user via user-interface.
interface.
The figure below shows an example deployment of this scenario. Figure 7 shows an example deployment of this scenario.
\|/ \|/ \|/ \|/
| TDD Air Interface | | TDD Air Interface |
| | | |
+-|---------+ +-|---------+ +-|---------+ +-|---------+
| TVWS | | TVWS | | TVWS | | TVWS |
|Master Dev | |Master Dev | |Master Dev | |Master Dev |
+-----------+ +-----------+ +-----------+ +-----------+
\ (----) / \ (----) /
\ ( ) / \ ( ) /
\ / \ / \ / \ /
( Internet ) ( Internet )
\ / \ /
( )\----------+ ( )\----------+
(----) | Database | (----) | Database |
+----------+ +----------+
Figure 8: Example illustration of mobility in TV white space use-case Figure 7: Example illustration of mobility in TV white space use-case
A simplified operational scenario utilizing TV whitespace to provide A simplified operational scenario utilizing TV whitespace to provide
peer-to-peer connectivity service in a mobility environment consists connectivity service in a mobility environment consists of the
of the following steps: following steps:
1. The mobile master device powers up with its WS radio in idle or 1. The mobile master device powers up with its WS radio in idle or
listen mode only (no active transmission on the WS frequency listen mode only (no active transmission on the WS frequency
band). band).
2. The mobile master has internet connectivity and establishes a 2. The mobile master has Internet connectivity, determines its
connection to a trusted white space database (see Section 4.1). 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 3. The mobile master registers with the trusted database according
to regulatory domain requirements (see Section 4.2). to regulatory domain requirements (see Section 4.1.2).
4. Following the registration process, the mobile master will send a 4. Following the successful registration process (if registration
query to the trusted database requesting a list of available WS is required), the mobile master will send a query to the trusted
channels based upon its current location and a prediction of its database requesting a list of available WS channels based upon
future location, extrapolated from the motion or mobility of the its current location, other parameters required by the local
device. The current location is specified in latitude and regulator (see Section 4.2.1, step 4) and a prediction of its
longitude. The method to specify the future location is TBD, future location. The current location is specified in latitude
potential methods include movement vector (direction and and longitude. The method to specify the future location is
velocity), a set of latitude/longitude points which specify a TBD, potential methods include movement vector (direction and
closed polygon where the future location is within the polygon, velocity), a set of latitude/longitude points which specify a
or similar. closed polygon where the future location is within the polygon,
or similar.
5. If the mobile master has met all regulatory domain requirements 5. If the mobile master has met all regulatory domain requirements
(e.g. been previously authenticated, etc), the database responds (e.g. been previously authenticated, etc), the database responds
with a list of available white space channels that the mobile with a list of available white space channels that the mobile
master may use, and optional information which may include (1) a master may use, and optional information which may include (1) a
duration of time for the use of each channel (2) a maximum duration of time for the use of each channel (2) a maximum
transmit power for each channel. 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 6. Once the mobile master has met all regulatory domain
(e.g. authenticated the WS channel list response message from the requirements (e.g. authenticated the WS channel list response
database, etc), the master selects an available WS channel(s) message from the database, etc), the master selects one or more
from the list for use. available WS channel(s) from the list for use.
7. The other user device in the peer-to-peer connection scans the TV 7. The slave/user device scans to locate a mobile master
bands to locate a mobile master transmission, and associates with transmission, and associates with the mobile master.
the mobile master. The slave/user device queries the master for
a channel list, based on the slave's device identification,
geolocation and optionally a prediction of its future location.
8. If required by local regulation, the master device verifies the 8. The slave/user device queries the master for a channel list,
slave's device identification with the database. providing to the master the slave's device identification, and
optionally its geolocation and a prediction of its future
location.
9. If allowed by local regulation (e.g. the slave's device 9. Once the mobile master has met all regulatory domain
identification is verified by the database), the mobile master requirements (e.g. the slave's device identification is verified
provides the list of channels locally available to the slave/user by the database), the mobile master provides the list of
device. If the channel that the slave/user terminal is currently channels locally available to the slave/user device.
using is not included in the list of locally available channels,
the slave/user device ceases all operation on its current
channel. The slave/user device may scan for another Master's
transmission on a different channel.
4.9. Indoor Networking 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.6. Indoor Networking
In this use case, the users are inside a house or office. The users 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 want to have connectivity to the Internet or to equipment in the same
or other houses / offices. This deployment scenario is typically or other houses / offices. This deployment scenario is typically
characterized by master devices within buildings, that are connected characterized by master devices within buildings, that are connected
to the Internet using a method that does not utilise TV whitespace. to the Internet using a method that does not utilize whitespace. The
The master devices can establish TV whitespace links between master devices can establish whitespace links between themselves, or
themselves, or between themselves and one or more user devices. between themselves and one or more user devices.
The figure below shows an example deployment of this scenario. Figure 8 shows an example deployment of this scenario.
\|/ \|/
| |
+-------+ | +-------+ |
|TVWS |\ +-|---------+ |TVWS |\ +-|---------+
|Usr Dev| WS AirIF \ | TVWS |\ |Usr Dev| WS AirIF \ | TVWS |\
+-------+ X|Master Dev | \ +-------+ X|Master Dev | \
/ +-----------+ \ / +-----------+ \
+-------+ WS AirIF | \ +----------+ +-------+ WS AirIF | \ +----------+
|TVWS |/ | \ (----) | Database | |TVWS |/ | \ (----) | Database |
skipping to change at page 22, line 26 skipping to change at page 23, line 43
| X( Internet ) | X( Internet )
| / \ / | / \ /
+-------+ \|/ | / ( ) +-------+ \|/ | / ( )
|TVWS |\ | | / (----) |TVWS |\ | | / (----)
|Usr Dev| WS AirIF | | / |Usr Dev| WS AirIF | | /
+-------+ \ +-|---------+ / +-------+ \ +-|---------+ /
\ | TVWS | / \ | TVWS | /
|Master Dev |/ |Master Dev |/
+-----------+ +-----------+
Figure 9: Example illustration of indoor TV white space use-case Figure 8: Example illustration of indoor TV white space use-case
A simplified operational scenario utilizing TV whitespace to provide A simplified operational scenario utilizing TV whitespace to provide
indoor networking consists of the following steps: indoor networking consists of the following steps:
1. The master device powers up with its whitespace radio in idle or 1. The master device powers up with its whitespace radio in idle or
listen mode only (no active transmission on the whitespace listen mode only (no active transmission on the whitespace
frequency band). frequency band).
2. The master device has internet connectivity and establishes a 2. The master device has Internet connectivity, determines its
connection to a trusted white space database (see Section 3.1 location (either from location determination capability or from a
above). 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 sends its geolocation and location uncertainty 3. The master device registers with the trusted database according
information, and optionally additional information which may to regulatory domain requirements (see Section 4.1.2).
include (1) device ID and (2) antenna characteristics, to a
trusted database, requesting a list of available whitespace
channels based upon this information.
4. The database responds with a list of available white space 4. Following the successful registration process (if registration is
channels that the master device may use, and optional information required), the master device sends a query to the trusted
which may include inter alia (1) a duration of time for the use database requesting a list of available WS channels based upon
of each channel (channel validity time) (2) a maximum radiated its geolocation. The complete set of parameters to be provided
power for each channel, (3) an indication of the quality of the from the master to the database is specified by the local
spectrum for each channel and (4) directivity and other antenna regulator. Parameters may include WSD location, accuracy of that
information. location, device antenna height, device identifier of a slave
device requesting channel information.
5. Once the master device authenticates the whitespace channel list 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 response message from the database, the master device selects one
or more available whitespace channels from the list. or more available whitespace channels from the list.
6. The user device(s) scan(s) the TV white space bands to locate the 7. The user device(s) scan(s) the white space bands to locate the
master device transmissions, and associates with the master. master device transmissions, and associates with the master.
4.10. Machine to Machine (M2M) 4.2.7. Machine to Machine (M2M)
In this use case, each "machine" includes a white space slave device In this use case, each "machine" includes a white space slave device
and can be located anywhere, fixed or on the move. Each machine and can be located anywhere, fixed or on the move. Each machine
needs to have connectivity to the internet and or to other machines needs to have connectivity to the Internet and or to other machines
in the vicinity. Machine communication over a TVWS channel, whether in the vicinity. Machine communication over a TVWS channel, whether
to a master device or to another machine (slave device), is under the to a master device or to another machine (slave device), is under the
control of a master device. This deployment scenario is typically control of a master device. This deployment scenario is typically
characterized by a master device with internet connectivity by some characterized by a master device with Internet connectivity by some
connection that does not utilize TV white space. connection that does not utilize TV white space.
The figure below shows an example deployment of this scenario. Figure 9 shows an example deployment of this scenario.
\|/ \|/
| |
| |
+-|---------+ +-|---------+
| TVWS |\ | TVWS |\
/|Master Dev | \ /|Master Dev | \
/ +-----------+ \ / +-----------+ \
WS AirIF \ +----------+ WS AirIF \ +----------+
+-------+ / \ (----) | Database | +-------+ / \ (----) | Database |
skipping to change at page 23, line 45 skipping to change at page 25, line 25
+-------+ \ / \ +-------+ \ / \
| X( Internet ) | X( Internet )
WS AirIF \ / WS AirIF \ /
| ( ) | ( )
+-------+ (----) +-------+ (----)
|Machine| |Machine|
+-------+ \ +-------+ +-------+ \ +-------+
WS AirIF-- |Machine| WS AirIF-- |Machine|
+-------+ +-------+
Figure 10: Example illustration of M2M TV white space use-case Figure 9: Example illustration of M2M TV white space use-case
A simplified operational scenario utilizing TV whitespace to provide A simplified operational scenario utilizing TV whitespace to provide
machine to machine connectivity consists of the following steps: machine to machine connectivity consists of the following steps:
1. The master device powers up with its whitespace radio in idle or 1. The master device powers up with its whitespace radio in idle or
listen mode only (no active transmission on the whitespace listen mode only (no active transmission on the whitespace
frequency band). frequency band).
2. The master device has internet connectivity and establishes a 2. The master device has Internet connectivity, determines its
connection to a trusted white space database (see Section 3.1 location (either from location determination capability or from
above). 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 sends its geolocation and location uncertainty 3. The master/AP registers with the trusted database according to
regulatory domain requirements (see Section 4.1.2).
4. Following successful registration (if registration is required),
the master device sends its geolocation and location uncertainty
information, and optionally additional information which may information, and optionally additional information which may
include (1) device ID and (2) antenna characteristics, to a include (1) device ID and (2) antenna characteristics, to a
trusted database, requesting a list of available whitespace trusted database, requesting a list of available whitespace
channels based upon this information. channels based upon this information.
4. The database responds with a list of available white space 5. If the master has met all regulatory domain requirements, the
channels that the master device may use, and optional information database responds with a list of available white space channels
which may include inter alia (1) a duration of time for the use that the master device may use, and optional information which
of each channel (channel validity time) (2) a maximum radiated may include inter alia (1) a duration of time for the use of each
power for each channel, (3) an indication of the quality of the channel (channel validity time) (2) a maximum radiated power for
spectrum for each channel and (4) directivity and other antenna each channel or a notification of any additional requirements for
information. sensing.
5. Once the master device authenticates the whitespace channel list 6. Once the master device authenticates the whitespace channel list
response message from the database, the master device selects one response message from the database, the master device selects one
or more available whitespace channels from the list. or more available whitespace channels from the list.
6. The slave devices fitted to the machines scan the TV bands to 7. The slave devices fitted to the machines scan the TV bands to
locate the master transmissions, and associate with the master locate the master transmissions, and associate with the master
device. Further signaling can take place outside scope of PAWS device.
to establish direct links among those slave devices that have
associated with the master device. 8. Further signaling can take place outside scope of PAWS to
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 5. 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 country specific since
the available spectrum and regulations may vary, but the fundamental the available spectrum and regulations may vary, but the fundamental
operation of the protocol should be country independent. operation of the protocol should be country 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 the figure below: databases is shown in Figure 10:
----------- -----------
|WS Device| ------------ |WS Device| ------------
|Lat: X |\ .---. /--------|Database X| |Lat: X |\ .---. /--------|Database X|
|Long: Y | \ ( ) / ------------ |Long: Y | \ ( ) / ------------
----------- \-------/ \/ o ----------- \-------/ \/ o
( Internet ) o ( Internet ) o
----------- /------( )\ o ----------- /------( )\ o
|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 10: High level view of the White space database architecture
In the figure above, note that there could be multiple databases In Figure 10, note that there could be multiple databases serving
serving white space devices. The databases are country specific white space devices. The databases are country specific since the
since the regulations and available spectrum may vary. In some regulations and available spectrum may vary. In some countries, for
countries, for example, the U.S., the regulator has determined that example, the U.S., the regulator has determined that multiple,
multiple, competing databases may provide service to White Space competing databases may provide service to White Space Devices.
Devices.
A messaging interface between the white space devices and the A messaging interface between the white space devices and the
database is required for operating a network using the white space database is required for operating a network using the white space
spectrum. The following sections discuss various aspects of such an spectrum. The following sections discuss various aspects of such an
interface and the need for a standard. Other aspects of a solution interface and the need for a standard. Other aspects of a solution
including provisioning the database, and calculating protected including provisioning the database, and calculating protected
contours are considered out of scope of the initial effort, as there contours are considered out of scope of the initial effort, as there
are significant differences between countries and spectrum bands. are significant differences between countries and spectrum bands.
5.1. Global applicability 5.1. Global applicability
The use of TV white space spectrum is currently approved by the FCC The use of TV white space spectrum is currently approved by the FCC
in the United States. However regulatory bodies in other countries in the United States. However regulatory bodies in other countries
are also considering similar use of available spectrum. The are also considering similar use of available spectrum. The
principles of cognitive radio usage for such spectrum is generally principles of cognitive radio usage for such spectrum is generally
the same. Some of the regulatory details may vary on a country the same. Some of the regulatory details may vary on a country
specific basis. However the need for devices that intend to use the specific basis. However the need for devices that intend to use the
spectrum to communicate with a database remains a common feature. spectrum to communicate with a database remains a common feature.
The database provides a known, specifiable Protection Contour for the The database provides a known, specifiable Protection Contour for the
primary user, not dependent on the characteristics of the White Space primary user, not dependent on the characteristics of the White Space
Device or it's ability to sense the primary use. It also provides a 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 way to specify a schedule of use, because some primary users (for
example, wireless microphones) only operate in limited time slots. 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 used by the white space device in available spectrum can be IEEE
802.11af, 802.16, 802.22, LTE etc. However the messaging 802.11af, IEEE 802.15.4m, IEEE 802.16, IEEE 802.22, LTE etc.
interface between the white space device and the database should However the messaging interface between the white space device
be agnostic to the air interface while being cognizant of the and the database should be agnostic to the air interface while
characteristics of various air-interface technologies and the being cognizant of the characteristics of various air-interface
need to include relevant attributes in the query to the database. technologies and the need to include relevant attributes in the
query to the database.
2. Spectrum agnostic - the spectrum used by primary and secondary 2. Spectrum agnostic - the spectrum used by primary and secondary
users varies by country. Some spectrum has an explicit notion of users varies by country. Some spectrum has an explicit notion of
a "channel" a defined swath of spectrum within a band that has a "channel" a defined swath of spectrum within a band that has
some assigned identifier. Other spectrum bands may be subject to some assigned identifier. Other spectrum bands may be subject to
white space sharing, but only have actual frequency low/high white space sharing, but only have actual frequency low/high
parameters to define protected entity use. The protocol should parameters to define protected entity use. The protocol should
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 it's geospatial location Since the White Space Device must know its geospatial location to
to do a query, it is possible to determine which database, and do a query, it is possible to determine which database, and which
which rules, are applicable, even though they are country rules, are applicable, even though they are country specific.
specific.
4. Address regulatory requirements - Each country will likely have 4. Address regulatory requirements - Each country will likely have
regulations that are unique to that country. The messaging regulations that are unique to that country. The messaging
interface needs to be flexible to accommodate the specific needs interface needs to be flexible to accommodate the specific needs
of a regulatory body in the country where the white space device of a regulatory body in the country where the white space device
is operating and connecting to the relevant database. is operating and connecting to the relevant database.
5.2. Database discovery 5.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 country specific, the device
will need to discover the relevant database. The device needs to will need to discover the relevant database. The device needs to
obtain the IP address of the specific database to which it can send obtain the IP address of the specific database to which it can send
queries in addition to registering itself for operation and using the queries in addition to registering itself for operation and using the
available spectrum. available spectrum.
5.3. Protocol 5.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 channels is needed. A device may
skipping to change at page 27, line 29 skipping to change at page 29, line 29
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 Use of XML for specifying a data model is an attractive option. The
intent is to evaluate the best option that meets the need for use intent is to evaluate the best option that meets the need for use
between white space devices and databases. between white space devices and databases.
6. Requirements 6. Requirements
This section is the placeholder for the requirements derived from the 6.1. Normative Requirements
use cases.
D. Data Model Requirements: D. Data Model Requirements:
D.1: The Data Model MUST support specifying the antenna and D.1: The Data Model MUST support specifying the location of the
radiation related parameters of the subject, such as: WSD, the uncertainty in meters, the height & its
uncertainty, and confidence in percentage for the location
determination. The Data Model MUST support both North
American Datum of 1983 and WGS84.
antenna height D.2: The Data Model MUST support specifying the URI address of a
white space database.
antenna gain D.3: The Data Model MUST support specifying the URI address of a
national listing service.
maximum output power, EIRP (dBm) D.4: The Data Model MUST support specifying the regulatory
domain and its corresponding data requirements.
antenna radiation pattern (directional dependence of the D.5: The Data Model MUST support specifying an ID of the
strength of the radio signal from the antenna transmitter device. This ID would contain the ID of the
transmitter device that has been certified by a regulatory
body for its regulatory domain. The Data Model MUST
support a device class.
spectrum mask with lowest and highest possible frequency D.6: The Data Model MUST support specifying a manufacturer's
serial number for a master device.
spectrum mask in dBr from peak transmit power in EIRP, D.7: The Data Model MUST support specifying the antenna and
with specific power limit at any frequency linearly radiation related parameters of the subject, such as:
interpolated between adjacent points of the spectrum mask
measurement resolution bandwidth for EIRP measurements
D.2: The Data Model MUST support specifying an ID of the antenna height
transmitter subject. This ID would contain the ID of the
transmitter device that has been certified by a regulatory
body for its regulatory domain.
D.3: The Data Model MUST support specifying a contact or a list antenna gain
of contacts of this transmitter. For example, facility or
on-site technical manager, administrator, any operational
contacts may be specified.
D.4: The Data Model MUST support specifying the location of the maximum output power, EIRP (dBm)
WSD, the uncertainty in meters and confidence in percentage
for the location determination.
D.5: The Data Model MUST support specifying a list of available antenna radiation pattern (directional dependence of the
channels and time constrains for the channel list strength of the radio signal from the antenna)
availability. Each channel in the list shall specify the
lower and upper frequency values for the channel and the
time intervals the channel is available.
D.6: The Data Model MUST support specifying channel availability spectrum mask with lowest and highest possible frequency
information for a single location and for multiple
locations. In the case of multiple locations, the database spectrum mask in dBr from peak transmit power in EIRP,
shall provide a channel list for each of the multiple with specific power limit at any frequency linearly
location. interpolated between adjacent points of the spectrum
mask
measurement resolution bandwidth for EIRP measurements
D.8: The Data Model MUST support specifying owner and operator
contact information for a transmitter. This includes the
name of the transmitter owner, name of transmitter
operator, postal address, email address and phone number of
the transmitter operator.
D.9: The Data Model MUST support specifying a list of available
channels. The Data Model MUST support specification of
this information by channel numbers and by start and stop
frequencies. The Data Model MUST support a channel
availability schedule and maximum power level for each
channel in the list.
D.10: The Data Model MUST support specifying channel availability
information for a single location and an area (e.g. a
polygon defined by multiple location points or a geometric
shape such as a circle).
P. Protocol Requirements: P. Protocol Requirements:
P.1: The protocol MUST provide a mechanism for the subject to P.1: The protocol MUST provide a message sequence for the master
discover the WS Database it has to use at a given location. device to discover a white space database that provides
service at its current location.
P.2: The protocol MUST support regulatory domain discovery. P.2: The protocol MUST support access of a database directly.
The protocol MUST support access of a database using a
listing approved by a national regulator.
P.3: The protocol between the master device and the WS Database P.3: The protocol MUST support determination of regulatory
MUST support pushing updates in channel availability domain governing its current location.
changes to subjects.
P.4: The protocol between the master device and the WS Database P.4: The protocol MUST provide the ability for the database to
MUST support mutual authentication and authorization. authenticate the master device.
P.5: The protocol between the master device and the WS Database P.5: The protocol MUST provide the ability for the master device
MUST support integrity and confidentiality protection. to verify the authenticity of the database with which it is
interacting.
P.6: The protocol MUST support both username/password and P.6: The messages sent by the master device to the database MUST
digital certificates based authentication. be integrity protected.
P.7: A master device MAY register with a trusted white space P.7: The messages sent by the database to the master device MUST
database. be integrity protected.
P.8: A master device MUST place its location into the query it P.8: The protocol MUST provide the capability for messages sent
makes to the whitespace database. by the master device and database to be encrypted.
P.9: A master device MUST be able to query the whitespace P.9: The protocol MUST support the master device registering
database for channel availability information for a with the database.
specific expected coverage area around its current
location.
P.10: A master device MUST send Device ID, searial number and P.10: The protocol MUST support a registration acknowledgement
device location in the query it makes to the database. including appropriate result codes.
P.11: A master device MAY send additional antenna characteristic P.11: The protocol MUST support a channel query request from the
information in the query it makes to the database. master device to the database. The channel query request
message MUST include parameters as required by local
regulatory requirement. These parameters MAY include
device location, device ID, manufacturer's serial number,
and antenna characteristic information.
P.12: A master device MUST be capable of validating the digital P.12: The protocol MUST support a channel query response from the
certificate of the WS Database. database to the master device. The channel query response
message MUST include parameters as required by local
regulatory requirement. These parameters MAY include
available channels, duration of time for their use,
associated maximum power levels, any additional sensing
requirements.
P.13: A master device MUST be capable of checking the validity of P.13: The protocol MUST support a channel query request from the
the WS Database certificate and whether it has been revoked slave device to the master device. The channel query
or not. request message MUST include parameters as required by
local regulatory requirement. These parameters MAY include
device ID and slave device location.
P.14: The protocol MUST support a validation request from the
master to the database to validate a slave device. The
validation request MUST include the slave device ID.
P.15: The protocol MUST support a validation response from the
database to the master. The validation response MUST
include a response code.
P.16: The protocol MUST support a channel query response from the
master device to the slave device. The channel query
response message MUST include parameters as required by
local regulatory requirement, including a response code and
sufficient information to decode an enabling signal.
P.17: The protocol MUST support an enabling signal sent from the
master to the slave. This signal MUST allow the slave
device to validate that a previously received available
channel list is still valid or not. This signal MUST be
encoded to allow the slave device to determine the identity
if the sending master device.
P.18: The protocol between the master device and the database
MUST support the capability to change channel availability
lists on short notice.
P.19: The protocol between the master device and the database
MUST support a channel availability request which specifies
a geographic location as an area as well as a point.
O. Operational Requirements: O. Operational Requirements:
O.1: A master device MUST query the WS Database for the O.1: The database and the master device MUST be connected to the
available channels as often as required by the regulation Internet.
(eg, FCC requires once per day) to verify that the
operating channels continue to remain available.
O.2: A master device MUST determine its location along with its O.2: A master device MUST be able to determine its location
uncertainty (e.g., FCC requires +/-50m) and confidence including uncertainty and confidence level. A fixed master
level (e.g., 95%) and send it to the database so that the device MAY use a location programmed at installation or
proper WSD position and buffer distance around the device have the capability determine its location to the required
can be added to make sure that the worst case situation accuracy. A mobile master device MUST have the capability
required by regulations is considered in the distance to determine its location to the required accuracy.
calculations taking place at the database.
O.3: A master device which changes its location during its O.3: The master device MUST identify a database for use. The
operation, MUST query the WS Database for available master device MAY select a database for service by
discovery at runtime or the master device MAY select a
database for service by means of a pre-programmed URI
address.
O.4: The master device MUST implement at least one connection
method to access the database. The master device MAY
contact a database directly for service (e.g. as defined by
FCC) or the master device MAY contact a listing server
first followed by contact to a database (e.g. as defined by
Ofcom).
O.5: The master device MUST obtain an indication the regulatory
domain governing operation at its current location, i.e.
the master device MUST know if it operates under
regulations from FCC, Ofcom, etc...
O.6: The master device MAY register with the database according
to local regulatory policy. Not all master devices will be
required to register. Specific events will initiate
registration, these events are determined by regulator
policy (e.g. at power up, after movement, etc...).
O.7: The master device MUST register with its most current and
up-to-date information, and MUST include all variables
mandated by local regulator policy.
O.8: A master device MUST query the database for the available
channels based on its current location before starting
radio transmission in white space. Parameters provided to
the database MAY include device location, accuracy of the
location, antenna characteristic information, device
identifier of any slave device requesting channel
information.
O.9: The database MUST respond to an available channel list
request from an authenticated and authorized device and MAY
also provide time constraints, maximum output power, start
and stop frequencies for each channel in the list and any
additional requirements for sensing.
O.10: After connecting to a master device's radio network a slave
device MUST query the master device for a list of available
channels. The slave MUST include parameters required by
local regulatory policy, e.g. device ID, device location.
O.11: According to local regulatory policy, the master device MAY
query the database with parameters received from the slave
device.
O.12: The database MUST respond to a query from the master device
containing parameters from a slave device.
O.13: After the master device has received a response from the
database, the master device MUST respond to the slave
device. If all regulatory requirements are met the
response will contain an available channel list. If
regulatory requirements are not met, the response MUST
contain at least a response code.
O.14: If a master device has provided an available channel list
to a slave device the master device MAY send a periodic
enabling signal to allow the slave device to confirm it is
still within reception range of the master device.
O.15: The enabling signal MUST be encoded so that the receiving
slave can determine the identity of the sending master.
O.16: Periodically, at an interval according to local
regulations, the slave device MUST either receive and
enabling signal or MUST successfully repeat the channel
request process or MUST cease transmission on the channel.
O.17: A master device MUST repeat the query to the database for
the available channels as often as required by the
regulation (e.g., FCC requires once per day) to verify that
the operating channels continue to remain available.
O.18: A master device which changes its location more than a
threshold distance (specified by local regulatory policy)
during its operation, MUST query the database for available
operating channels each time it moves more than the operating channels each time it moves more than the
distance specified by the regulation (e.g., FCC specifies threshold distance (e.g., FCC specifies 100m) from the
100m) from the location it previously made the query. location it previously made the query.
O.4: The WS Database MUST provide the available channel list O.19: If slave devices change their location during operation by
when requested from an authenticated and authorized device more than a limit specified by the local regulator, the
and MAY also provide time constraints, maximum output power slave device MUST query the master device for available
and start and stop frequencies for each channel in the operating channels.
list.
O.5: A master device MUST query the WS Database and include the O.20: According to local regulator policy, a master device may
FCC ID of the slave device in the query before allowing the contact a database via proxy service of another master
slave device to use the available channel. device.
O.6: A master device MUST be capable of validating the digital O.21: A master device MUST be able to query the whitespace
certificate of the WS Database and whether it has been database for channel availability information for a
revoked or not. specific expected coverage area around its current
location.
O.7: A master device MUST be able to determine its location O.22: A Master device MUST include its identity in messages sent
using latitude-longitude coordinates. to the database.
O.8: A master device MUST make a fresh query of the whitespace 6.2. Guidelines
database for the available channels within a particular
time interval, using a parameter sent by the database in
response to the previous query. On expiry of the time
interval then a master device MUST cease transmission in
the TVWS band if no successful query attempt has been made
or a query has been made but the database has not
responded.
O.9: If slave devices change their location during operation, The current scope of the working group is limited and is reflected in
the master device MUST query the whitespace database for the requirements captured in Section 6.1. However white space
available operating channels each time a slave device moves technology itself is expected to evolve and address other aspects
outside the reported coverage location area. such as co-existence and interference avoidance, spectrum brokering,
alternative spectrum bands, etc. The design of the data model and
protocol should be cognizant of the evolving nature of white space
technology and consider the following set of guidelines in the
development of the data model and protocol:
O.10: A master device MAY be able to indicate to slave devices 1. The data model SHOULD provide a modular design separating out
the start and stop frequencies it has available for messaging specific, administrative specific, and spectrum
operation and the maximum permitted powers for the slave specific parts into separate modules.
devices, and MAY be able to send additional optional
information. 2. The protocol SHOULD support determination of which administrative
specific and spectrum specific modules are used.
7. IANA Considerations 7. IANA Considerations
This document has no requests to IANA. This document has no requests to IANA.
8. Security Considerations 8. Security Considerations
The messaging interface between the white space device and the Threat model for the PAWS protocol
database needs to be secured. Both the queries and the responses
need to be delivered securely. The device must be certain it is
talking to a bona fide database authoritative for the location and
spectrum band the device operates on. The database may need to
restrict interactions to devices that it has some prior relationship
with, or may be restricted from providing service to devices that are
not authorized in some manner.
As the device will query with it's location, the location must be Assumptions:
protected against eavesdropping. Some regulations include personally
identifiable information as required elements of registration and/or
query and must similarly be protected.
All communications between the device and the database will require It is assumed that an attacker has full access to the network medium
integrity protection. 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.
Man-in-the-middle attacks could modify the content of a response It is assumed that both the master device and the white space
which can cause problems for other networks or devices operating at a database have NOT been compromised from a security standpoint.
given location. Interference as well as total loss of service could
result from malicious information being delivered to a white space Threat 1: User modifies a device to masquerade as another valid
device. certified device
Regulatory environments require that devices be certified and
register in ways that accurately reflect their certification.
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 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
A master device discovers a white space database(s) thru which it
can query for channel information. The master device needs to
ensure that the white space database with which it communicates
with is an authentic entity. The white space database needs to
provide its identity to the master device which can confirm the
validity/authenticity of the database. An attacker may attempt to
spoof a white space database and provide responses to a master
device which are malicious and result in the master device causing
interference to the primary user of the spectrum.
Threat 3: Modifying a query request
An attacker may modify the query request sent by a master device
to a white space database. The attacker may change the location
of the device or the capabilities in terms of its transmit power
or antenna height etc. which could result in the database
responding with incorrect information about available channels or
max transmit power allowed. The result of such an attack is that
the master device would cause interference to the primary user of
the spectrum. It could also result in a denial of service to the
master device by indicating that no channels are available.
Threat 4: Modifying a query response
An attacker could modify the query response sent by the white
space database to a master device. The channel information or
transmit power allowed type of parameters carried in the response
could be modified by the attacker resulting in the master device
using channels that are not available at a location or
transmitting at a greater power level than allowed resulting in
interference to the primary user of that spectrum. Alternatively
the attacker may indicate no channel availability at a location
resulting in a denial of service to the master device.
Threat 5: Unauthorized use of channels by an uncertified device
An attacker may be a master device which is not certified for use
by the relevant regulatory body. The attacker may listen to the
communication between a valid master device and white space
database and utilize the information about available channels in
the response message by utilizing those channels. The result of
such an attack is unauthorized use of channels by a master device
which is not certified to operate. The master device querying the
white space database may be operated by a law-enforcement agency
and the communications between the device and the database are
intended to be kept private. A malicious device should not be
able to eavesdrop on such communications.
Threat 6: Third party tracking of white space device location and
identity
A white space database in a regulatory domain may require a master
device to provide its identity in addition to its location in the
query request. Such location/identity information can be gleaned
by an eavesdropper and used for tracking purposes. A master
device may prefer to keep the location/identity information hidden
from eavesdroppers, hence the protocol should provide a means to
protect the location and identity information of the master device
and prevent tracking of locations associated with a white space
database query. When the master device sends both its identity
and location to the DB, the DB is able to track it. If a
regulatory domain does not require the master device to provide
its identity to the white space database, the master device may
decide not to send its identity, to prevent being tracked by the
DB.
Threat 7: Malicious individual acts as a PAWS entity (spoofing DB or
as MiM) to terminate or unfairly limit spectrum access of devices for
reasons other than incumbent protection
A white space database MAY include a mechanism by which service
and channels allocated to a master device can be revoked by
sending an unsolicited message. A malicious node can pretend to
be the white space database with which a master device has
registered or obtained channel information from and send a revoke
message to that device. This results in denial of service to the
master device.
Threat 8: Natural disaster resulting in inability to obtain
authorization for white space spectrum use by emergency responders
In the case of a sizable natural disaster a lot of Internet
infrastructure ceases to function. Emergency services users need
to reconstitute quickly and will rely on establishing radio WANs.
The potential for lot of radio WAN gear that has been unused
suddenly needs to be pressed into action. And the radio WANs need
frequency authorizations to function. Regulatory entities may
also authorize usage of additional spectrum in the affected areas.
The white space radio entities may need to establish communication
with a database and obtain authorizations. In cases where
communication with the white space database fails, the white space
devices cannot utilize white space spectrum. Emergency services,
which require more spectrum precisely at locations where network
infrastructure is malfunctioning or overloaded, backup
communication channels and distributed white space databases are
needed to overcome such circumstances. Alternatively there may be
other mechanisms which allow the use of spectrum by emergency
service equipment without strict authorization or with liberal
interpretation of the regulatory policy for white space usage.
The security requirements arising from the above threats are captured
in the requirements of section 6.1.
9. Summary and Conclusion 9. Summary and Conclusion
Wireless spectrum is a scarce resource. As the demand for spectrum Wireless spectrum is a scarce resource. As the demand for spectrum
grows, there is a need to more efficiently utilize the available and grows, there is a need to more efficiently utilize the available and
allocated spectrum. Cognitive radio technologies enable the allocated spectrum. Cognitive radio technologies enable the
efficient usage of spectrum via means such as sensing or by querying efficient usage of spectrum via means such as sensing or by querying
a database to determine available spectrum at a given location for a database to determine available spectrum at a given location for
secondary use. White space is the general term used to refer to the opportunistic use. White space is the general term used to refer to
bands within the spectrum which is available for secondary use at a the bands within the spectrum which is available for secondary use at
given location. In order to use this spectrum a device needs to a given location. In order to use this spectrum a device needs to
query a database which maintains information about the available query a database which maintains information about the available
channels within a band. A protocol is necessary for communication channels within a band. A protocol is necessary for communication
between the devices and databases which would be globally applicable. between the devices and databases which would be 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 an database in the operation of a radio network and also shows examples
examples of a services provided to the user of a TVWS device. From of services provided to the user of a TVWS device. From these use
these use cases requirements are determined. These requirements are cases, requirements are determined. These requirements are to be
to be used as input to the definition of a Protocol to Access White used as input to the definition of a Protocol to Access White Space
Space database (PAWS). database (PAWS).
10. Acknowledgements 10. Acknowledgements
The authors acknowledge Gerald Chouinard and Teco Boot as The authors acknowledge Gabor Bajko, Teco Boot, Nancy Bravin, Rex
contributors to this document. Buddenberg, Gerald Chouinard, Stephen Farrell, Michael Fitch, Joel M.
Halpern, Jussi Kahtava, Paul Lambert, Brian Rosen, Andy Sago, Peter
Stanforth, John Stine and, Juan Carlos Zuniga for their contributions
to this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[80211P] IEEE, "IEEE Standard for Information technology - [802.11p] IEEE, "IEEE Standard for Information technology -
Telecommunications and information exchange between Telecommunications and information exchange between
systems - Local and metropolitan area networks - Specific systems - Local and metropolitan area networks - Specific
requirements; Part 11: Wireless LAN Medium Access Control requirements; Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications; Amendment (MAC) and Physical Layer (PHY) Specifications; Amendment
6: Wireless Access in Vehicular Environments; http:// 6: Wireless Access in Vehicular Environments; http://
standards.ieee.org/getieee802/download/802.11p-2010.pdf", standards.ieee.org/getieee802/download/802.11p-2010.pdf",
July 2010. 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] [FCC47CFR90.210]
FCC, "Title 47 Telecommunication CFR Chapter I - Federal FCC, "Title 47 Telecommunication CFR Chapter I - Federal
Communication Commission Part 90 - Private Land Mobile Communication Commission Part 90 - Private Land Mobile
Radio Services - Section 210 Emission masks; http:// Radio Services - Section 210 Emission masks; http://
edocket.access.gpo.gov/cfr_2010/octqtr/pdf/ edocket.access.gpo.gov/cfr_2010/octqtr/pdf/
47cfr90.210.pdf", October 2010. 47cfr90.210.pdf", October 2010.
[PAWS-PS] IETF, "Protocol to Access White Space database: Problem [PAWS-PS] IETF, "Protocol to Access White Space database: Problem
statement; https://datatracker.ietf.org/doc/ statement; https://datatracker.ietf.org/doc/
draft-patil-paws-problem-stmt/", July 2011. draft-patil-paws-problem-stmt/", July 2011.
skipping to change at page 33, line 12 skipping to change at page 40, line 32
[FCC Ruling] [FCC Ruling]
FCC, "Federal Communications Commission, "Unlicensed FCC, "Federal Communications Commission, "Unlicensed
Operation in the TV Broadcast Bands; Operation in the TV Broadcast Bands;
http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf"", http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf"",
December 2010. December 2010.
[Ofcom Implementing] [Ofcom Implementing]
Ofcom, "Ofcom, "Implementing Geolocation; http:// Ofcom, "Ofcom, "Implementing Geolocation; http://
stakeholders.ofcom.org.uk/consultations/geolocation/ stakeholders.ofcom.org.uk/consultations/geolocation/
statement/ statement/"", September 2011.
?utm_source=updates&utm_medium=email&
utm_campaign=geolocation-statement"", September 2011.
[RFC5222] IETF, Hardie, T., Netwon, A., Schulzrinne, H., and H. [RFC5222] IETF, Hardie, T., Netwon, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation Proto Tschofenig, "LoST: A Location-to-Service Translation Proto
col;http://www.rfc-editor.org/rfc/pdfrfc/rfc5222.txt.pdf", col;http://www.rfc-editor.org/rfc/pdfrfc/rfc5222.txt.pdf",
August 2008. August 2008.
[Spectrum Framework Review] [Spectrum Framework Review]
Ofcom - Independent regulator and competition authority Ofcom - Independent regulator and competition authority
for the UK communications industries, "Spectrum Framework for the UK communications industries, "Spectrum Framework
Review; Review;
 End of changes. 196 change blocks. 
675 lines changed or deleted 1045 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/