Protocol to Access White Space database: PS, use cases and rqmts
draft-ietf-paws-problem-stmt-usecases-rqmts-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 6953.
|
|
|---|---|---|---|
| Authors | Scott Probasco , Basavaraj Patil | ||
| Last updated | 2011-10-17 (Latest revision 2011-09-09) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 6953 (Informational) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Peter Saint-Andre | ||
| Send notices to | paws-chairs@tools.ietf.org, draft-ietf-paws-problem-stmt-usecases-rqmts@tools.ietf.org |
draft-ietf-paws-problem-stmt-usecases-rqmts-02
Working Group Draft S. Probasco, Ed.
Internet-Draft B. Patil
Intended status: Informational Nokia
Expires: July 30, 2012 January 27, 2012
Protocol to Access White Space database: PS, use cases and rqmts
draft-ietf-paws-problem-stmt-usecases-rqmts-02
Abstract
Portions of the radio spectrum that are allocated to a licensed,
primary user but are unused or unoccupied at specific locations and
times are defined as "white space". The concept of allowing
secondary transmissions (licensed or unlicensed) in white space is a
technique to "unlock" existing spectrum for new use. An obvious
requirement is that these secondary transmissions do not interfere
with the primary use of the spectrum. One approach to using the
white space spectrum at a given time and location is to verify with a
database available channels.
This document describes the concept of TV White Spaces. It also
describes the problems that need to be addressed for enabling the use
of the primary user owned white space spectrum for secondary users,
without causing interference, by querying a database which knows the
channel availability at any given location and time. A number of
possible use cases of this spectrum and derived requirements are also
described.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 30, 2012.
Copyright Notice
Probasco & Patil Expires July 30, 2012 [Page 1]
Internet-Draft PAWS: Problem, uses and requirements January 2012
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Probasco & Patil Expires July 30, 2012 [Page 2]
Internet-Draft PAWS: Problem, uses and requirements January 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Introduction to TV white space . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 6
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6
2.1. Conventions Used in This Document . . . . . . . . . . . . 7
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
3. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. The concept of Cognitive Radio . . . . . . . . . . . . . . 8
3.2. Background information on white space in US . . . . . . . 8
3.3. Air Interfaces . . . . . . . . . . . . . . . . . . . . . . 9
4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. TVWS database discovery . . . . . . . . . . . . . . . . . 9
4.2. Device registration with trusted Database . . . . . . . . 10
4.3. Hotspot: urban internet connectivity service . . . . . . . 11
4.4. Wide-Area or Rural internet broadband access . . . . . . . 13
4.5. Offloading: moving traffic to a white space network . . . 15
4.6. TVWS for backhaul . . . . . . . . . . . . . . . . . . . . 17
4.7. Rapid deployed network for emergency scenario . . . . . . 18
4.8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.9. Indoor Networking . . . . . . . . . . . . . . . . . . . . 21
4.10. Machine to Machine (M2M) . . . . . . . . . . . . . . . . . 23
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Global applicability . . . . . . . . . . . . . . . . . . . 25
5.2. Database discovery . . . . . . . . . . . . . . . . . . . . 26
5.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.4. Data model definition . . . . . . . . . . . . . . . . . . 27
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 27
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 31
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.1. Normative References . . . . . . . . . . . . . . . . . . . 32
11.2. Informative References . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Probasco & Patil Expires July 30, 2012 [Page 3]
Internet-Draft PAWS: Problem, uses and requirements January 2012
1. Introduction
1.1. Introduction to TV white space
Wireless spectrum is a commodity that is regulated by governments.
The spectrum is used for various purposes, which include
entertainment (e.g. radio and television), communication (telephony
and Internet access), military (radars etc.) and, navigation
(satellite communication, GPS). Portions of the radio spectrum that
are allocated to a licensed, primary user but are unused or
unoccupied at specific locations and times are defined as "white
space". The concept of allowing secondary transmissions (licensed or
unlicensed) in white space is a technique to "unlock" existing
spectrum for new use. An obvious requirement is that these secondary
transmissions do not interfere with the primary use of the spectrum.
One interesting observation is that often, in a given physical
location, the primary user(s) may not be using the entire band
allocated to them. The available spectrum for a secondary use would
then depend on the location of the secondary user. The fundamental
issue is how to determine for a specific location and specific time,
if any of the primary spectrum is available for secondary use.
Academia and Industry have studied multiple cognitive radio
mechanisms for use in such a scenario. One simple mechanism is to
use a geospatial database that records the primary users occupation,
and require the secondary users to check the database prior to
selecting what part of the spectrum they use. Such databases could
be available on the Internet for query by secondary users.
Spectrum useable for data communications, especially wireless
Internet communications, is scarce. One area which has received much
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
United States regulator (the FCC) took initial steps when they
published their first ruling on the use of TV white space, and then
followed it up with a final ruling in 2010 [FCC Ruling]. Finland
passed an Act in 2009 enabling testing of cognitive radio systems in
the TV white space. The ECC has completed Report 159 [ECC Report
159] containing requirements for operation of cognitive radio systems
in the TV white space. Ofcom published in 2004 their Spectrum
Framework Review [Spectrum Framework Review] and their Digital
Dividend Review [DDR] in 2005, and have followed up with a proposal
to access TV white space. More countries are expected to provide
access to their TV spectrum in similar ways. Any entity holding
spectrum that is not densely used may be asked to give it up in one
way or another for more intensive use. Providing a mechanism by
which secondary users share the spectrum with the primary user is
attractive in many bands in many countries.
Probasco & Patil Expires July 30, 2012 [Page 4]
Internet-Draft PAWS: Problem, uses and requirements January 2012
Television transmission until now has primarily been analog. The
switch to digital transmission has begun. As a result the spectrum
allocated for television transmission can now be more effectively
used. Unused channels and bands between channels can be used as long
as they do not interfere with the primary service for which that
channel is allocated. While urban areas tend to have dense usage of
spectrum and a number of TV channels, the same is not true in rural
and semi-urban areas. There can be a number of unused TV channels in
such areas that can be used for other services. The figure below
shows TV white space within the lower UHF band:
Avg |
usage| |-------------- White Space
| | | | | |
0.6| || || V V ||
| || ||| | ||
0.4| || |||| | ||
| || |||| | ||<----TV transmission
0.2| || |||| | ||
|----------------------------------------
400 500 600 700 800
Frequency in MHz ->
Figure 1: High level view of TV White Space
The fundamental issue is how to determine for a specific location and
specific time if any of the spectrum is available for secondary use.
There are two dimensions of use that may be interesting: space (the
area in which a secondary user would not interfere with a primary
user, and time: when the secondary use would not interfere with the
primary use. In this discussion, we consider the time element to be
relatively long term (hours in a day) rather than short term
(fractions of a second). Location in this discussion is geolocation:
where the transmitters (and sometimes receivers) are located relative
to one another. In operation, the database records the existing
user's transmitter (and some times receiver) locations along with
basic transmission characteristics such as antenna height, and
sometimes power. Using rules established by the regulator, the
database calculates an exclusion zone for each authorized primary
user, and attaches a time schedule to that use. The secondary user
queries the database with its location. The database intersects the
exclusion zones with the queried location, and returns the portion of
the spectrum not in any exclusion zone. Such methods of geospatial
database query to avoid interference have been shown to achieve
favorable results, and are thus the basis for rulings by the FCC and
Probasco & Patil Expires July 30, 2012 [Page 5]
Internet-Draft PAWS: Problem, uses and requirements January 2012
reports from ECC and Ofcom. In any country, the rules for which
primary entities are entitled to protection, how the exclusion zones
are calculated, and what the limits of use by secondary entities are
may vary. However, the fundamental notion of recording primary
users, calculating exclusion zones, querying by location and
returning available spectrum (and the schedule for that spectrum) are
common
This document includes the problem statement, use cases and
requirements associated with the use of white space spectrum by
secondary users via a database query protocol.
1.2. Scope
1.2.1. In Scope
This document applies only to communications required for basic
service in TV white space. The protocol will enable a white space
radio device to complete the following tasks:
1. Determine the relevant white space database to query.
2. Connect to the database using a well-defined access method.
3. Register with the database using a well-defined protocol.
4. Provide its geolocation and perhaps other data to the database
using a well-defined format for querying the database.
5. Receive in return a list of currently available white space using
a well-defined format for returning information.
As a result, some of the scenarios described in the following section
are out of scope for this specification (although they might be
addressed by future specifications).
1.2.2. Out of Scope
The following topics are out of scope for this specification:
TBD
2. Conventions and Terminology
Probasco & Patil Expires July 30, 2012 [Page 6]
Internet-Draft PAWS: Problem, uses and requirements January 2012
2.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2.2. Terminology
Database
In the context of white space and cognitive radio technologies,
the database is an entity which contains current information about
available spectrum at any given location and other types of
information.
Device ID
A unique number for each master device and slave device that
identifies the manufacturer, model number and serial number.
Location Based Service
An application or device which provides data, information or
service to a user based on their location.
Master Device
A device which queries the WS Database to find out the available
operating channels.
Protected Entity
A primary user of white space spectrum which is afforded
protection against interference by secondary users (white space
devices) for its use in a given area and time.
Protected Contour
The exclusion area for a Protected Entity, held in the database
and expressed as a polygon with geospatial points as the vertices.
Slave Device
A device which uses the spectrum made available by a master
device.
Probasco & Patil Expires July 30, 2012 [Page 7]
Internet-Draft PAWS: Problem, uses and requirements January 2012
TV White Space
TV white space refers specifically to radio spectrum which has
been allocated for TV broadcast, but is not occupied by a TV
broadcast, or other licensed user (such as a wireless microphone),
at a specific location and time.
White Space
Radio spectrum which has been allocated for some primary use, but
is not fully occupied by that primary use at a specific location
and time.
White Space Device (WSD)
A device which is a secondary user of some part of white space
spectrum. A white space device can be an access point, base
station, a portable device or similar. In this context, a white
space device is required to query a database with its location to
obtain information about available spectrum.
3. Prior Work
3.1. The concept of Cognitive Radio
A cognitive radio uses knowledge of the local radio environment to
dynamically adapt its own configuration and function properly in a
changing radio environment. Knowledge of the local radio environment
can come from various technology mechanisms including sensing
(attempting to ascertain primary users by listening for them within
the spectrum), location determination and internet connectivity to a
database to learn the details of the local radio environment. TV
White Space is one implementation of cognitive radio. Because a
cognitive radio adapts itself to the available spectrum in a manner
that prevents the creation of harmful interference, the spectrum can
be shared among different radio users.
3.2. Background information on white space in US
Television transmission in the United States has moved to the use of
digital signals as of June 12, 2009. Since June 13, 2009, all full-
power U.S. television stations have broadcast over-the-air signals in
digital only. An important benefit of the switch to all-digital
broadcasting is that it freed up parts of the valuable broadcast
spectrum. More information about the switch to digital transmission
is at : [DTV].
Probasco & Patil Expires July 30, 2012 [Page 8]
Internet-Draft PAWS: Problem, uses and requirements January 2012
With the switch to digital transmission for TV, the guard bands that
existed to protect the signals between stations can now be used for
other purposes. The FCC has made this spectrum available for
unlicensed use and this is generally referred to as white space.
Please see the details of the FCC ruling and regulations in [FCC
Ruling]. The spectrum can be used to provide wireless broadband as
an example. The term "Super-Wifi" is also used to describe this
spectrum and potential for providing wifi type of service.
3.3. Air Interfaces
Efforts are ongoing to specify air-interfaces for use in white space
spectrum. IEEEs 802.11af task group is currently working on one such
specification. IEEE 802.22 is another example. Other air interfaces
could be specified in the future such as LTE.
4. Use cases
There are many potential use cases that could be considered for the
TV white space spectrum. Providing broadband internet access in
hotspots, rural and underserved areas are examples. Available
channels may also be used to provide internet 'backhaul' for
traditional Wi-Fi hotspots, or by towns and cities to monitor/control
traffic lights or read utility meters. Still other use cases include
the ability to offload data traffic from another internet access
network (e.g. 3G cellular network) or to deliver location based
services. Some of these use cases are described in the following
sections.
4.1. TVWS database discovery
This use case is preliminary to creating a radio network using TV
white space; it is a prerequisite to other use cases. The radio
network is created by a master device. Before the master device can
transmit in TV 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 relvant regulatory domain, using the following steps:
1. The master device is connected to the internet by any means other
than using the TV white space radio.
2. The master device constructs and sends a service request over the
Internet to discover availability of trusted databases in the
local domain and waits for responses.
Probasco & Patil Expires July 30, 2012 [Page 9]
Internet-Draft PAWS: Problem, uses and requirements January 2012
3. If no acceptable response is received within a pre-configured
time limit, the master device concludes that no trusted database
is available. If at least one response is received, the master
device evaluates the response(s) to determine if a trusted
database can be identified where the master device is able to
register and receive service from the database.
Optionally the radio device is pre-programmed with the internet
address of at least one trusted database. The device can establish
contact with a trusted database using one of the pre-programmed
internet addresses and establish a TV white space network (as
described in one of the following use cases).
Optionally the initial query will be made to a listing approved by
the national regulator for the domain of operation (e.g. a website
either hosted by or under control of the national regulator) which
maintains a list of TVWS databases and their internet addresses. The
query results in the list of databases and their internet addresses
being sent to the master, which then evaluates the repsonse to
determine if a trusted database can be identified where the master
device is able to register and receive service from the database.
4.2. Device registration with trusted Database
This use case is preliminary to creating a radio network using TV
white space; it is a prerequisite to other use cases. The radio
network is created by a master device. Before the master device can
transmit in TV white space spectrum, it must contact a trusted
database where the device can learn if any channels are available for
it to use. Before the database will provide information on available
TV channels, the master device must register with the trusted
database. Specific requirements for registration come from
individual regulatory domains and may be different.
The figure below shows an example deployment of this scenario.
Probasco & Patil Expires July 30, 2012 [Page 10]
Internet-Draft PAWS: Problem, uses and requirements January 2012
\|/ ----------
| |Database|
| .---. /---------
|-|---------| ( ) /
\|/ | Master | / \
| / | |========( Internet )
| / |-----------| \ /
+-|----+ (TDD AirIF) ( )
|Master| / (----)
| | /
+------+
Figure 2: Example illustration of registration requirement in TV
white space use-case
A simplified operational scenario showing registration consists of
the following steps:
1. The master device must register with the most current and up-to-
date information. Typically the master device will register
prior to operating in TV white space for the first time after
power up, after changing location by a predetermined distance,
and after regular time intervals.
2. The master device shall provide to the database during
registration a minimum of the Device ID, serial number assigned
by the manufacturer and the device's location.
3. Depending upon regulatory domain requirements, the device may
also provide 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 to the database during registration.
4.3. Hotspot: urban internet connectivity service
In this use case internet connectivity service is provided in a
"hotspot" to local users. Typical deployment scenarios include urban
areas where internet connectivity is provided to local businesses and
residents, and campus environments where internet connectivity is
provided to local buildings and relatively small outdoor areas. This
deployment scenario is typically characterized by multiple masters
(APs or hotspots) in close proximity, with low antenna height, cells
with relatively small radius (a few kilometers or less), and limited
numbers of available radio channels. Many of the masters/APs are
assumed to be individually deployed and operated, i.e. there is no
coordination between many of the masters/APs. The masters/APs in
Probasco & Patil Expires July 30, 2012 [Page 11]
Internet-Draft PAWS: Problem, uses and requirements January 2012
this scenario use a TDD radio technology and transmit at or below a
relatively low transmit power threshold. Each master/AP has a
connection to the internet and provides internet connectivity to
multiple master and or slave devices.
The figure below shows an example deployment of this scenario.
--------
|Device|\ \|/ ----------
| 1 | (TDD AirIF) | |Database|
-------- \ | .---. /---------
o \ |-|---------| ( ) /
o | Master | / \
o / | |========( Internet )
o / |-----------| \ /
-------- (TDD AirIF) ( )
|Device| / (----)
| n |
--------
Figure 3: Hotspot service using TV white space spectrum
Once a master/AP has been correctly installed and configured, a
simplified power up and operation scenario utilizing TV White Space
to provide Internet connectivity service consists of the following
steps:
1. The master/AP powers up; however its WS radio and all other WS
capable devices will power up in idle/listen only mode (no active
transmissions on the WS frequency band).
2. The master/AP has Internet connectivity and establishes a
connection to a trusted white space database (see Section 4.1).
3. The master/AP registers with the trusted database according to
regulatory domain requirements (see Section 4.2).
4. Following the registration process, the master/AP will send a
query to the trusted database requesting a list of available WS
channels based upon its geolocation.
5. If the master/AP has met all regulatory domain requirements (e.g.
been previously authenticated, etc), the database responds with a
list of available white space channels that the master may use,
and optionally a duration of time for their use.
Probasco & Patil Expires July 30, 2012 [Page 12]
Internet-Draft PAWS: Problem, uses and requirements January 2012
6. Once the master/AP has met all regulatory domain requirements
(e.g. authenticated the WS channel list response message from the
database, etc), the AP selects an available WS channel(s) from
the list.
7. The slave or user device scans the TV bands to locate a master/AP
transmission, and associates with the AP. The slave/user device
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
(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. If the channel that the user terminal is
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
In this use case, internet broadband access is provided as a Wide-
Area Network (WAN) or Wireless Regional Area Network (WRAN). A
typical deployment scenario is a wide area or rural area, where
internet broadband access is provided to local businesses and
residents from a master (i.e. BS) connected to the internet. This
deployment scenario is typically characterized by one or more fixed
master(s)/BS(s), cells with relatively large radius (tens of
kilometers, up to 100 km), and a number of available radio channels.
Some of the masters/BSs may be deployed and operated by a single
entity, i.e. there can be centralized coordination between these
masters/BSs, whereas other masters/BSs may be deployed and operated
by operators competing for the radio channels in a license-exempt
TVWS environment where decentralized coordination using the air-
interface would be required. The BS in this scenario use a TDD radio
technology and transmit at or below a transmit power limit
established by the local regulator. Each base station has a
connection to the internet and provides internet connectivity to
multiple slave/end-user devices. End user terminals or devices may
be fixed or portable.
The figure below shows an example deployment of this scenario.
Probasco & Patil Expires July 30, 2012 [Page 13]
Internet-Draft PAWS: Problem, uses and requirements January 2012
-------
|Slave|\ \|/ ----------
|Dev 1| (TDD AirIF) | |Database|
------- \ | .---. /----------
o \ |-|---------| ( ) /
o | Master | / \
o / | (BS) |========( Internet )
o / |-----------| \ /
------- (TDD AirIF) ( )
|Slave| / (----)
|Dev n|
-------
Figure 4: Rural internet broadband access using TV white space
spectrum
Once the master/BS has been professionally installed and configured,
a simplified power up and operation scenario utilizing TV White Space
to provide rural internet broadband access consists of the following
steps:
1. The master/BS powers up; however its WS radio and all other WS
capable devices will power up in idle/listen only mode (No 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.
Probasco & Patil Expires July 30, 2012 [Page 14]
Internet-Draft PAWS: Problem, uses and requirements January 2012
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
In this use case internet connectivity service is provided over TV
white space as a supplemental or alternative datapath to a 3G or
other internet connection. In a typical deployment scenario an end
user has a primary internet connection such as a 3G cellular packet
data subscription. The user wants to use a widget or application to
stream video from an online service (e.g. youtube) to their device.
Before the widget starts the streaming connection it checks
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
Probasco & Patil Expires July 30, 2012 [Page 15]
Internet-Draft PAWS: Problem, uses and requirements January 2012
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.
\|/
|
|
|-|---------|
| Master/AP |\
/| Router | \
Streaming/ |-----------| \
-------- / \ -----------
|Slave/| / \ (----) | Database |
|WS Dev| \ ( ) /----------
------- \ \ / \
\ X( Internet )
\ / \ /
Signaling \|/ / ( )\
\ | / (----) \----------
\ | / | YouTube |
\|-|---------| / ----------
| | /
| 3G BTS |/
|-----------|
Figure 5: Offloading: moving traffic to a white space network
Once a dual or multi mode device (3G + TVWS) is connected to a 3G
network, a simplified operation scenario of offloading selected
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
a 3G network. The device has contacted a trusted database to
discover the list of available TV channels at its current
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
from YouTube. The widget connects to YouTube over 3G cellular
data. The user browses content and searches for video
selections.
Probasco & Patil Expires July 30, 2012 [Page 16]
Internet-Draft PAWS: Problem, uses and requirements January 2012
3. The user selects a video for streaming using the widget's
controls. Before the widget initiates a streaming session, the
widget checks the available connections in the dual mode device
and finds a TVWS master/AP is connected.
4. Using either input from the user or pre-defined profile
preferences, the widget selects the TVWS master/AP as the
connection to stream the video.
4.6. TVWS for backhaul
In this use case internet connectivity service is provided to users
over a traditional wireless protocol, one common example is Wi-Fi.
The TV white space network provides the "backhaul" or connection from
the Wi-Fi to the internet. In a typical deployment scenario an end
user has a device with a radio such as Wi-Fi. A service provider or
shop owner wants to provide Wi-Fi internet service for their
customers. The location where the service provider wants to provide
Wi-Fi is within range of a TVWS master (e.g. Hotspot or Wide-Area/
Rural network). The service provider installs a TVWS slave device
and connects this slave to a Wi-Fi access point. This deployment
scenario is typically characterized by a TVWS master/AP/BS providing
local coverage. The master/AP has a connection to the internet and
provides internet connectivity to the slave device. The slave device
is then 'bridged' to a Wi-Fi network
The figure below shows an example deployment of this scenario.
\|/ white \|/ \|/ WiFi \|/
| space | | |
| | | |-|----|
|--------| |-|---------| |-|------|-| | WiFi |
| | | Master | | Slave | | Dev |
|internet|------| (AP/BS) | | Bridge | |------|
| | | | | to WiFi |
|--------| |-----------| |----------| \|/
|
|-|----|
| WiFi |
| Dev |
|------|
Figure 6: TVWS for backhaul
Once the bridged device (TVWS+WiFi) is connected to a master and TVWS
network, a simplified operation scenario of backhaul for WiFi
consists of the following steps:
Probasco & Patil Expires July 30, 2012 [Page 17]
Internet-Draft PAWS: Problem, uses and requirements January 2012
1. A bridged device (TVWS+WiFi) is connected to a master device
operating in the TVWS. The bridged device operates as a slave
device in either Hotspot or Wide-Area/Rural internet use cases
described above.
2. Once the slave device is connected to the master, the Wi-Fi
access point configures its internet settings automatically based
on the backhaul connection (i.e. it uses DHCP).
3. End users connect their WiFi device to the bridged device and
receive internet connectivity.
4.7. Rapid deployed network for emergency scenario
Organizations involved in handling emergency operations often have a
fully owned and controlled infrastructure, with dedicated spectrum,
for day to day operation. However, lessons learned from recent
disasters show such infrastructures are often highly affected by the
disaster itself. To set up a replacement quickly, there is a need
for fast reallocation of spectrum, where in certain cases spectrum
can be freed for disaster relief. To utilize free or freed spectrum
quickly and reliable, automation of allocation, assignment and
configuration is needed. A preferred option is make use of a robust
protocol, already adopted by radio manufacturers. This approach does
in no way imply such organizations for disaster relief must compete
on spectrum allocation with other white spaces users, but they can.
A typical network topology would include wireless access links to the
public Internet or private network, wireless ad hoc network radios
working independent of a fixed infrastructure and satellite links for
backup where lack of coverage, overload or outage of wireless access
links occur.
The figure below shows an example deployment of this scenario.
Probasco & Patil Expires July 30, 2012 [Page 18]
Internet-Draft PAWS: Problem, uses and requirements January 2012
\|/
| ad hoc
|
|-|-------------|
| Master node | |------------|
\|/ | with | | Whitespace |
| ad hoc /| backhaul link | | Database |
| /------/ |---------------| |------------|
---|------------/ | \ /
| Master node | | | (--/--)
| without | | ------( )
| backhaul link | | Wireless / Private \
----------------\ | Access ( net or )
\ | \ Internet )
\ \|/ | -------( /\
\ | ad hoc | | (------) \---------
\ | | / | Other |
\--|------------- /Satellite | nodes |
| Master node | / Link ----------
| with |/
| backhaul link |
-----------------
Figure 7: Rapid deployed network with partly connected nodes
In the ad hoc network, all nodes are master nodes in a way that they
allocate RF channels from the white space database. However, the
backhaul link may not be available to all nodes, such as depicted for
the left node in the figure. To handle RF channel allocation for
such nodes, a master node with a backhaul link relays or proxies the
database query for them. So master nodes without a backhaul link
follow the procedure as defined for clients. The ad hoc network
radios utilise the provided RF channels. Details on forming and
maintenance of the ad hoc network, including repair of segmented
networks caused by segments operating on different RF channels, is
out of scope of spectrum allocation.
4.8. Mobility
In this use case, the user has a non-fixed (portable or mobile)
device and is riding in a vehicle. The user wants to have
connectivity to another device which is also moving. Typical
deployment scenarios include urban areas and rural areas where the
user may connect to other users in peer-to-peer or ad-hoc networks.
This deployment scenario is typically characterized by a master
device with low antenna height, internet connectivity by some
connection that does not utilize TV white space, and some means to
Probasco & Patil Expires July 30, 2012 [Page 19]
Internet-Draft PAWS: Problem, uses and requirements January 2012
predict its path of mobility. This knowledge of mobility could be
simple (GPS plus accelerometer), sophisticated (GPS plus routing and
mapping function) or completely specified by the user via user-
interface.
The figure below shows an example deployment of this scenario.
\|/ \|/
| TDD Air Interface |
| |
+-|---------+ +-|---------+
| TVWS | | TVWS |
|Master Dev | |Master Dev |
+-----------+ +-----------+
\ (----) /
\ ( ) /
\ / \ /
( Internet )
\ /
( )\----------+
(----) | Database |
+----------+
Figure 8: Example illustration of mobility in TV white space use-case
A simplified operational scenario utilizing TV whitespace to provide
peer-to-peer connectivity service in a mobility environment consists
of the following steps:
1. The mobile master device powers up with its WS radio in idle or
listen mode only (no active transmission on the WS frequency
band).
2. The mobile master has internet connectivity and establishes a
connection to a trusted white space database (see Section 4.1).
3. The mobile master registers with the trusted database according
to regulatory domain requirements (see Section 4.2).
4. Following the registration process, the mobile master will send a
query to the trusted database requesting a list of available WS
channels based upon its current location and a prediction of its
future location, extrapolated from the motion or mobility of the
device. The current location is specified in latitude and
longitude. The method to specify the future location is TBD,
potential methods include movement vector (direction and
velocity), a set of latitude/longitude points which specify a
Probasco & Patil Expires July 30, 2012 [Page 20]
Internet-Draft PAWS: Problem, uses and requirements January 2012
closed polygon where the future location is within the polygon,
or similar.
5. If the mobile master has met all regulatory domain requirements
(e.g. been previously authenticated, etc), the database responds
with a list of available white space channels that the mobile
master may use, and optional information which may include (1) a
duration of time for the use of each channel (2) a maximum
transmit power for each channel.
6. Once the mobile master has met all regulatory domain requirements
(e.g. authenticated the WS channel list response message from the
database, etc), the master selects an available WS channel(s)
from the list for use.
7. The other user device in the peer-to-peer connection scans the TV
bands to locate a mobile master transmission, and associates with
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
slave's device identification with the database.
9. If allowed by local regulation (e.g. the slave's device
identification is verified by the database), the mobile master
provides the list of channels locally available to the slave/user
device. If the channel that the slave/user terminal is 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 Master's
transmission on a different channel.
4.9. Indoor Networking
In this use case, the users are inside a house or office. The users
want to have connectivity to the internet or to equipment in the same
or other houses / offices. This deployment scenario is typically
characterized by master devices within buildings, that are connected
to the Internet using a method that does not utilise TV whitespace.
The master devices can establish TV whitespace links between
themselves, or between themselves and one or more user devices.
The figure below shows an example deployment of this scenario.
Probasco & Patil Expires July 30, 2012 [Page 21]
Internet-Draft PAWS: Problem, uses and requirements January 2012
\|/
|
+-------+ |
|TVWS |\ +-|---------+
|Usr Dev| WS AirIF \ | TVWS |\
+-------+ X|Master Dev | \
/ +-----------+ \
+-------+ WS AirIF | \ +----------+
|TVWS |/ | \ (----) | Database |
|Usr Dev| | \ ( ) /----------+
+-------+ WS AirIF \ / \
| X( Internet )
| / \ /
+-------+ \|/ | / ( )
|TVWS |\ | | / (----)
|Usr Dev| WS AirIF | | /
+-------+ \ +-|---------+ /
\ | TVWS | /
|Master Dev |/
+-----------+
Figure 9: Example illustration of indoor TV white space use-case
A simplified operational scenario utilizing TV whitespace to provide
indoor networking consists of the following steps:
1. The master device powers up with its whitespace radio in idle or
listen mode only (no active transmission on the whitespace
frequency band).
2. The master device has internet connectivity and establishes a
connection to a trusted white space database (see Section 3.1
above).
3. The master device sends its geolocation and location uncertainty
information, and optionally additional information which may
include (1) device ID and (2) antenna characteristics, to a
trusted database, requesting a list of available whitespace
channels based upon this information.
4. 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, (3) an indication of the quality of the
spectrum for each channel and (4) directivity and other antenna
information.
Probasco & Patil Expires July 30, 2012 [Page 22]
Internet-Draft PAWS: Problem, uses and requirements January 2012
5. Once the master device authenticates the whitespace channel list
response message from the database, the master device selects one
or more available whitespace channels from the list.
6. The user device(s) scan(s) the TV white space bands to locate the
master device transmissions, and associates with the master.
4.10. Machine to Machine (M2M)
In this use case, each "machine" includes a white space slave device
and can be located anywhere, fixed or on the move. Each machine
needs to have connectivity to the internet and or to other machines
in the vicinity. Machine communication over a TVWS channel, whether
to a master device or to another machine (slave device), is under the
control of a master device. This deployment scenario is typically
characterized by a master device with internet connectivity by some
connection that does not utilize TV white space.
The figure below shows an example deployment of this scenario.
\|/
|
|
+-|---------+
| TVWS |\
/|Master Dev | \
/ +-----------+ \
WS AirIF \ +----------+
+-------+ / \ (----) | Database |
|Machine| \ ( ) /----------+
+-------+ \ / \
| X( Internet )
WS AirIF \ /
| ( )
+-------+ (----)
|Machine|
+-------+ \ +-------+
WS AirIF-- |Machine|
+-------+
Figure 10: Example illustration of M2M TV white space use-case
A simplified operational scenario utilizing TV whitespace to provide
machine to machine connectivity consists of the following steps:
1. The master device powers up with its whitespace radio in idle or
listen mode only (no active transmission on the whitespace
frequency band).
Probasco & Patil Expires July 30, 2012 [Page 23]
Internet-Draft PAWS: Problem, uses and requirements January 2012
2. The master device has internet connectivity and establishes a
connection to a trusted white space database (see Section 3.1
above).
3. The master device sends its geolocation and location uncertainty
information, and optionally additional information which may
include (1) device ID and (2) antenna characteristics, to a
trusted database, requesting a list of available whitespace
channels based upon this information.
4. 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, (3) an indication of the quality of the
spectrum for each channel and (4) directivity and other antenna
information.
5. Once the master device authenticates the whitespace channel list
response message from the database, the master device selects one
or more available whitespace channels from the list.
6. The slave devices fitted to the machines scan the TV bands to
locate the master transmissions, and associate with the master
device. Further signaling can take place outside scope of PAWS
to establish direct links among those slave devices that have
associated with the master device.
5. Problem Statement
The use of white space spectrum is enabled via the capability of a
device to query a database and obtain information about the
availability of spectrum for use at a given location. The databases
are reachable via the Internet and the devices querying these
databases are expected to have some form of Internet connectivity,
directly or indirectly. The databases may be country specific since
the available spectrum and regulations may vary, but the fundamental
operation of the protocol should be country independent.
An example high-level architecture of the devices and white space
databases is shown in the figure below:
Probasco & Patil Expires July 30, 2012 [Page 24]
Internet-Draft PAWS: Problem, uses and requirements January 2012
-----------
|WS Device| ------------
|Lat: X |\ .---. /--------|Database X|
|Long: Y | \ ( ) / ------------
----------- \-------/ \/ o
( Internet ) o
----------- /------( )\ o
|WS Device| / (_____) \ ------------
|Lat: X |/ \--------|Database Y|
|Long: Y | ------------
-----------
Figure 11: High level view of the White space database architecture
In the figure above, note that there could be multiple databases
serving white space devices. The databases are country specific
since the regulations and available spectrum may vary. In some
countries, for example, the U.S., the regulator has determined that
multiple, competing databases may provide service to White Space
Devices.
A messaging interface between the white space devices and the
database is required for operating a network using the white space
spectrum. The following sections discuss various aspects of such an
interface and the need for a standard. Other aspects of a solution
including provisioning the database, and calculating protected
contours are considered out of scope of the initial effort, as there
are significant differences between countries and spectrum bands.
5.1. Global applicability
The use of TV white space spectrum is currently approved by the FCC
in the United States. However regulatory bodies in other countries
are also considering similar use of available spectrum. The
principles of cognitive radio usage for such spectrum is generally
the same. Some of the regulatory details may vary on a country
specific basis. However the need for devices that intend to use the
spectrum to communicate with a database remains a common feature.
The database provides a known, specifiable Protection Contour for the
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
way to specify a schedule of use, because some primary users (for
example, wireless microphones) only operate in limited time slots.
Devices need to be able to query a database, directly or indirectly
over the public Internet and/or private IP networks prior to
operating in available spectrum. Information about available
Probasco & Patil Expires July 30, 2012 [Page 25]
Internet-Draft PAWS: Problem, uses and requirements January 2012
spectrum, schedule, power, etc. are provided by the database as a
response to the query from a device. The messaging interface needs
to be:
1. Radio/air interface agnostic - The radio/air interface technology
used by the white space device in available spectrum can be
802.11af, 802.16, 802.22, LTE etc. However the messaging
interface between the white space device and the database should
be agnostic to the air interface while being cognizant of the
characteristics of various air-interface technologies and the
need to include relevant attributes in the query to the database.
2. Spectrum agnostic - the spectrum used by primary and secondary
users varies by country. Some spectrum has an explicit notion of
a "channel" a defined swath of spectrum within a band that has
some assigned identifier. Other spectrum bands may be subject to
white space sharing, but only have actual frequency low/high
parameters to define protected entity use. The protocol should
be able to be used in any spectrum band where white space sharing
is permitted.
3. Globally applicable - A common messaging interface between white
space devices and databases will enable the use of such spectrum
for various purposes on a global basis. Devices can operate in
any country where such spectrum is available and a common
interface ensures uniformity in implementations and deployment.
Since the White Space device must know it's geospatial location
to do a query, it is possible to determine which database, and
which rules, are applicable, even though they are country
specific.
4. Address regulatory requirements - Each country will likely have
regulations that are unique to that country. The messaging
interface needs to be flexible to accommodate the specific needs
of a regulatory body in the country where the white space device
is operating and connecting to the relevant database.
5.2. Database discovery
Another aspect of the problem space is the need to discover the
database. A white space device needs to find the relevant database
to query based on its current location or for another location.
Since the spectrum and databases are country specific, the device
will need to discover the relevant database. The device needs to
obtain the IP address of the specific database to which it can send
queries in addition to registering itself for operation and using the
available spectrum.
Probasco & Patil Expires July 30, 2012 [Page 26]
Internet-Draft PAWS: Problem, uses and requirements January 2012
5.3. Protocol
A protocol that enables a white space device to query a database to
obtain information about available channels is needed. A device may
be required to register with the database with some credentials prior
to being allowed to query. The requirements for such a protocol are
specified in this document.
5.4. Data model definition
The contents of the queries and response need to be specified. A
data model is required which enables the white space device to query
the database while including all the relevant information such as
geolocation, radio technology, power characteristics, etc. which may
be country and spectrum and regulatory dependent. All databases are
able to interpret the data model and respond to the queries using the
same data model that is understood by all devices.
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
between white space devices and databases.
6. Requirements
This section is the placeholder for the requirements derived from the
use cases.
D. Data Model Requirements:
D.1: The Data Model MUST support specifying the antenna and
radiation related parameters of the subject, such as:
antenna height
antenna gain
maximum output power, EIRP (dBm)
antenna radiation pattern (directional dependence of the
strength of the radio signal from the antenna
spectrum mask with lowest and highest possible frequency
spectrum mask in dBr from peak transmit power in EIRP,
with specific power limit at any frequency linearly
interpolated between adjacent points of the spectrum mask
Probasco & Patil Expires July 30, 2012 [Page 27]
Internet-Draft PAWS: Problem, uses and requirements January 2012
measurement resolution bandwidth for EIRP measurements
D.2: The Data Model MUST support specifying an ID of the
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
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
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
channels and time constrains for the channel list
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
information for a single location and for multiple
locations. In the case of multiple locations, the database
shall provide a channel list for each of the multiple
location.
P. Protocol Requirements:
P.1: The protocol MUST provide a mechanism for the subject to
discover the WS Database it has to use at a given location.
P.2: The protocol MUST support regulatory domain discovery.
P.3: The protocol between the master device and the WS Database
MUST support pushing updates in channel availability
changes to subjects.
P.4: The protocol between the master device and the WS Database
MUST support mutual authentication and authorization.
P.5: The protocol between the master device and the WS Database
MUST support integrity and confidentiality protection.
Probasco & Patil Expires July 30, 2012 [Page 28]
Internet-Draft PAWS: Problem, uses and requirements January 2012
P.6: The protocol MUST support both username/password and
digital certificates based authentication.
P.7: A master device MAY register with a trusted white space
database.
P.8: A master device MUST place its location into the query it
makes to the whitespace database.
P.9: A master device MUST be able to query the whitespace
database for channel availability information for a
specific expected coverage area around its current
location.
P.10: A master device MUST send Device ID, searial number and
device location in the query it makes to the database.
P.11: A master device MAY send additional antenna characteristic
information in the query it makes to the database.
P.12: A master device MUST be capable of validating the digital
certificate of the WS Database.
P.13: A master device MUST be capable of checking the validity of
the WS Database certificate and whether it has been revoked
or not.
O. Operational Requirements:
O.1: A master device MUST query the WS Database for the
available channels as often as required by the regulation
(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
uncertainty (e.g., FCC requires +/-50m) and confidence
level (e.g., 95%) and send it to the database so that the
proper WSD position and buffer distance around the device
can be added to make sure that the worst case situation
required by regulations is considered in the distance
calculations taking place at the database.
O.3: A master device which changes its location during its
operation, MUST query the WS Database for available
operating channels each time it moves more than the
distance specified by the regulation (e.g., FCC specifies
100m) from the location it previously made the query.
Probasco & Patil Expires July 30, 2012 [Page 29]
Internet-Draft PAWS: Problem, uses and requirements January 2012
O.4: The WS Database MUST provide the available channel list
when requested from an authenticated and authorized device
and MAY also provide time constraints, maximum output power
and start and stop frequencies for each channel in the
list.
O.5: A master device MUST query the WS Database and include the
FCC ID of the slave device in the query before allowing the
slave device to use the available channel.
O.6: A master device MUST be capable of validating the digital
certificate of the WS Database and whether it has been
revoked or not.
O.7: A master device MUST be able to determine its location
using latitude-longitude coordinates.
O.8: A master device MUST make a fresh query of the whitespace
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 master device MUST query the whitespace database for
available operating channels each time a slave device moves
outside the reported coverage location area.
O.10: A master device MAY be able to indicate to slave devices
the start and stop frequencies it has available for
operation and the maximum permitted powers for the slave
devices, and MAY be able to send additional optional
information.
7. IANA Considerations
This document has no requests to IANA.
8. Security Considerations
The messaging interface between the white space device and the
database needs to be secured. Both the queries and the responses
need to be delivered securely. The device must be certain it is
Probasco & Patil Expires July 30, 2012 [Page 30]
Internet-Draft PAWS: Problem, uses and requirements January 2012
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
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
integrity protection.
Man-in-the-middle attacks could modify the content of a response
which can cause problems for other networks or devices operating at a
given location. Interference as well as total loss of service could
result from malicious information being delivered to a white space
device.
9. Summary and Conclusion
Wireless spectrum is a scarce resource. As the demand for spectrum
grows, there is a need to more efficiently utilize the available and
allocated spectrum. Cognitive radio technologies enable the
efficient usage of spectrum via means such as sensing or by querying
a database to determine available spectrum at a given location for
secondary use. White space is the general term used to refer to the
bands within the spectrum which is available for secondary use at a
given location. In order to use this spectrum a device needs to
query a database which maintains information about the available
channels within a band. A protocol is necessary for communication
between the devices and databases which would be globally applicable.
The document describes some examples of the role of the white space
database in the operation of a radio network and also shows an
examples of a services provided to the user of a TVWS device. From
these use cases requirements are determined. These requirements are
to be used as input to the definition of a Protocol to Access White
Space database (PAWS).
10. Acknowledgements
The authors acknowledge Gerald Chouinard and Teco Boot as
contributors to this document.
Probasco & Patil Expires July 30, 2012 [Page 31]
Internet-Draft PAWS: Problem, uses and requirements January 2012
11. References
11.1. Normative References
[80211P] IEEE, "IEEE Standard for Information technology -
Telecommunications and information exchange between
systems - Local and metropolitan area networks - Specific
requirements; Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications; Amendment
6: Wireless Access in Vehicular Environments; http://
standards.ieee.org/getieee802/download/802.11p-2010.pdf",
July 2010.
[FCC47CFR90.210]
FCC, "Title 47 Telecommunication CFR Chapter I - Federal
Communication Commission Part 90 - Private Land Mobile
Radio Services - Section 210 Emission masks; http://
edocket.access.gpo.gov/cfr_2010/octqtr/pdf/
47cfr90.210.pdf", October 2010.
[PAWS-PS] IETF, "Protocol to Access White Space database: Problem
statement; https://datatracker.ietf.org/doc/
draft-patil-paws-problem-stmt/", July 2011.
[RFC2119] IETF, "Key words for use in RFCs to Indicate Requirement
Levels;
http://www.rfc-editor.org/rfc/pdfrfc/rfc2119.txt.pdf",
March 1997.
11.2. Informative References
[DDR] Ofcom - Independent regulator and competition authority
for the UK communications industries, "Digital Dividend
Review; http://stakeholders.ofcom.org.uk/spectrum/
project-pages/ddr/".
[DTV] "Digital TV Transition; http://www.dtv.gov".
[ECC Report 159]
Electronic Communications Committee (ECC) within the
European Conference of Postal and Telecommunications
Administrations (CEPT), "TECHNICAL AND OPERATIONAL
REQUIREMENTS FOR THE POSSIBLE OPERATION OF COGNITIVE RADIO
SYSTEMS IN THE 'WHITE SPACES' OF THE FREQUENCY BAND 470-
590 MHZ; http://www.erodocdb.dk/Docs/doc98/official/pdf/
ECCREP159.PDF", January 2011.
[FCC Ruling]
Probasco & Patil Expires July 30, 2012 [Page 32]
Internet-Draft PAWS: Problem, uses and requirements January 2012
FCC, "Federal Communications Commission, "Unlicensed
Operation in the TV Broadcast Bands;
http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf"",
December 2010.
[Ofcom Implementing]
Ofcom, "Ofcom, "Implementing Geolocation; http://
stakeholders.ofcom.org.uk/consultations/geolocation/
statement/
?utm_source=updates&utm_medium=email&
utm_campaign=geolocation-statement"", September 2011.
[RFC5222] IETF, Hardie, T., Netwon, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation Proto
col;http://www.rfc-editor.org/rfc/pdfrfc/rfc5222.txt.pdf",
August 2008.
[Spectrum Framework Review]
Ofcom - Independent regulator and competition authority
for the UK communications industries, "Spectrum Framework
Review;
http://stakeholders.ofcom.org.uk/consultations/sfr/",
February 2005.
[TV Whitespace Tutorial Intro]
IEEE 802 Executive Committee Study Group on TV White
Spaces, "TV Whitespace Tutorial Intro; http://
grouper.ieee.org/groups/802/802_tutorials/2009-03/
2009-03-10%20TV%20Whitespace%20Tutorial%20r0.pdf",
March 2009.
Authors' Addresses
Scott Probasco (editor)
Nokia
6021 Connection drive
Irving, TX 75039
USA
Email: scott.probasco@nokia.com
Probasco & Patil Expires July 30, 2012 [Page 33]
Internet-Draft PAWS: Problem, uses and requirements January 2012
Basavaraj Patil
Nokia
6021 Connection drive
Irving, TX 75039
USA
Email: basavaraj.patil@nokia.com
Probasco & Patil Expires July 30, 2012 [Page 34]