One document matched: draft-patil-paws-problem-stmt-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC4861 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml'>
<!ENTITY RFC5222 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5222.xml'>
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc tocappendix="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info"
docName="draft-patil-paws-problem-stmt-02"
ipr="trust200902"
>
<front>
<title abbrev="PAWS: Problem Statement">Protocol to Access White Space
database: Problem statement</title>
<author role="editor" initials="B" surname="Patil"
fullname="Basavaraj Patil">
<organization>Nokia</organization>
<organization>Nokia</organization>
<address>
<postal>
<street>6021 Connection drive</street>
<city>Irving</city>
<region>TX</region>
<code>75039</code>
<country>USA</country>
</postal>
<email>basavaraj.patil@nokia.com</email>
</address>
</author>
<author fullname="Scott Probasco" initials="S" surname="Probasco">
<organization>Nokia</organization>
<address>
<postal>
<street>6021 Connection drive</street>
<city>Irving</city>
<region>TX</region>
<code>75039</code>
<country>USA</country>
</postal>
<email>scott.probasco@nokia.com</email>
</address>
</author>
<author initials="G" surname="Bajko" fullname="Gabor Bajko">
<organization>Nokia</organization>
<address>
<postal>
<street>323 Fairchild drive 6</street>
<city>Mountain view</city>
<region>CA</region>
<code>94043</code>
<country>USA</country>
</postal>
<email>gabor.bajko@nokia.com</email>
</address>
</author>
<author initials="B" surname="Rosen" fullname="Brian Rosen">
<organization>Neustar</organization>
<address>
<postal>
<street>470 Conrad Dr</street>
<city>Mars</city>
<region>PA</region>
<code>16046</code>
<country>USA</country>
</postal>
<email>brian.rosen@neustar.biz</email>
</address>
</author>
<date year="2011" />
<area>Operations and Management</area>
<workgroup>Individual Submission</workgroup>
<keyword>HTTP</keyword>
<keyword>White Space</keyword>
<keyword>Security</keyword>
<keyword>TLS</keyword>
<keyword>Protocol</keyword>
<abstract>
<t>
Governments around the world continue to search for new bands
of radio spectrum which can be used by the expanding wireless
communications industry to provide more services in the usable spectrum.
The concept of allowing secondary
transmissions (licensed or unlicensed) in frequencies occupied by a primary
user 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. This document discusses the problems that need to be
addressed for enabling the use of white space spectrum by
obtaining information from such a database.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
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<xref target="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 <xref target="ECC Report 159"/>
containing requirements for operation of cognitive radio systems
in the TV white space. Ofcom published in 2004 their Spectrum
Framework Review <xref target="Spectrum Framework Review" />
and their Digital Dividend Review <xref target="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.
</t>
<t>
The concept of allowing secondary transmissions
in frequencies occupied by a primary user 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. 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 it location. The database
intersects the exclusion zones with the querier location, and
returns the portion of the spectrum not in any exclusion zone.
Such methods of geospatial database query to avoid
interference have been shown to achieve favorable results, and
are thus the basis for rulings by the FCC and reports from ECC
and Ofcom. In any country, the rules for which 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.
</t>
<t>
In a typical implementation of geolocation and database to
access TV white space, a radio is configured with its
location in latitude and longitude. There are multiple ways to
configure this location information, e.g. programmed at
installation (e.g. for a fixed device) or determined by GPS
(e.g. for a or mobile device). At power-on, before the device
can transmit in TV white space frequencies, the device must
contact a database, provide its geolocation and receive in
return a list of unoccupied or "white space" spectrum (for
example, in a TV White space implementation, the list of
available channels at that location). The
device can then select one of the channels from the list (note
that it is possible they list is empty; there are no
unoccupied channels at the location of the device) and then
begins to transmit and receive on the selected channel. The
device must query the database again for a list of unoccupied
channels based on certain conditions, e.g. a fixed amount of
time has passed, the device has changed location beyond a
specified threshold. The basic scenario is that before
transmitting in TV white space, the device must get permission
from the database.
</t>
<t>This arrangement assumes that the device querying can
complete a query before it transmits, or some other entity is
able to query the database. A common arrangement for this kind
of service is a fixed tower with a wired infrastructure that
provides Internet service to a network of client devices. In
this scenario, the tower has Internet access from its upstream
service, and can query the database for channels within the
tower service area. It can then provide beacon service to its
clients, and assign them channels within the list of channels
that the tower gets from the database.</t>
<t>Another arrangement might be an ad-hoc mobile network where
one or more members of the ad hoc network have an independent
radio IP connection (perhaps a commercial cellular wireless data
network) which can be used to query the database over the
Internet.</t>
<t>A third possibility is a mechanism where the database is accessed
on a private IP network.</t>
<t>
The low frequencies of the TV bands (470-790 MHz) have good propagation
characteristics. At these low frequencies, a radio signal will
travel ~3 times further than traditional WLAN at 2.5 GHz,
assuming the same transmit power. Because of these
characteristics and new cognitive radio techniques, when TV
white space becomes available, this will enable new use cases
and new business opportunities. Not only is the capacity of
new spectrum needed, but this propagation trait by itself
makes TV white space attractive for providing broadband wireless access in rural,
sparsely populated areas, as well as for extended range home
hot-spot coverage (similar to WLAN today, but with improved
coverage). In addition to propagation characteristics, the
geolocation database may provide new capabilities for devices
that use TV white space. When a device using TV white space
registers its location in the database, this simple act makes
the location of the device available for location based
services.
</t>
<t>
Other spectrum that might also be available for sharing using
white space techniques exist in every country. A great many
primary users were allocated space a time when there were many
fewer potential users of the space, and the primary users are
not making efficient (in geospatial and time aspects) use of
the space. In the past, relocating existing primary users was
the only feasible alternative. Using white space techniques
to share spectrum without imposing burdens on the primary
users is more attractive.</t>
<t>
This document discusses the problem statement related to
enabling the "secondary" use of spectrum owned by a primary
user without causing interference to the primary user(s). One
approach to avoiding interference is to verify with a database
about the available channels and spectrum at a given
location. This document also identifies various issues that
need to be addressed by the protocol between a white space
device and such a database.
</t>
</section>
<section title="Terminology">
<t>
<list style="hanging">
<t hangText="White Space">
<vspace blankLines="1"/>
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.
</t>
<t hangText="TV White Space">
<vspace blankLines="1"/>
TV white space refers specifically to radio spectrum which has
been allocated for over the air television broadcast, but is not occupied by a TV
broadcast, or other licensed user (such as a wireless
microphone), at a specific location and time.
</t>
<t hangText="White Space Device">
<vspace blankLines="1"/>
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.
</t>
<t hangText="TV White Space">
<vspace blankLines="1"/>
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.
</t>
<t hangText="Database">
<vspace blankLines="1"/>
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.
</t>
<t hangText="Protected Entity">
<vspace blankLines="1"/>
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.
</t>
<t hangText="Protected Contour">
<vspace blankLines="1"/>
The exclusion area for a Protected Entity, held in the database and expressed as a polygon with geospatial points as the vertices.
</t>
</list>
</t>
</section>
<section title="Prior Work">
<section title="The concept of Cognitive Radio">
<t>
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.
</t>
</section>
<section title="Background information on white space in US">
<t>
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 :
<xref target="DTV" />.
</t>
<t>
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 <xref target="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.
</t>
</section>
<section title = "Air Interfaces">
<t>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.
</t>
</section>
</section>
<section title="Problem Statement">
<t>
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.
</t>
<t>
An example high-level architecture of the devices and
white space databases is shown in the figure below:
<figure title="High level view of the White space database
architecture"
anchor="fig:architecture">
<artwork><![CDATA[
-----------
|WS Device| ------------
|Lat: X |\ .---. /--------|Database X|
|Long: Y | \ ( ) / ------------
----------- \-------/ \/ o
( Internet ) o
----------- /------( )\ o
|WS Device| / (_____) \ ------------
|Lat: X |/ \--------|Database Y|
|Long: Y | ------------
-----------
]]></artwork></figure>
</t>
<t>
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.
</t>
<t>
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.
</t>
<section title="Global applicability">
<t>
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.
</t>
<t>
Devices need to be able to query a database, directly or
indirectly over the public Internet and/or private IP
networks prior to operating in
available spectrum. Information about available
spectrum, schedule, power, etc. are provided by the
database as a response to the query from a device.
The messaging interface needs to be:
</t>
<t>
<list style="numbers">
<t>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.
</t>
<t>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.</t>
<t>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.
</t>
<t>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.
</t>
</list>
</t>
</section>
<section title="Database discovery">
<t>
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.
</t>
<t>
A database discovery mechanism needs to be
specified. Reuse of existing mechanisms is an option and
could be adapted for meeting the specific needs of
cognitive radio technology.
</t>
</section>
<section title="Data model definition">
<t>
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 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.
</t>
<t>
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.
</t>
</section>
<section title="Protocol">
<t>
The protocol requirements are simple: registration and query
transactions are needed. In some circumstances, a registration
transaction is required prior to being able to query. The device
provides some identifying information, and the database responds
with an acknowledgement or error. The query protocol is a simple
query/response action (primarily location in, available spectrum
out), with some error conditions.</t>
<t>It may be possible to use existing protocols (e.g. LoST
<xref target="RFC5222"/>) or it may be more appropriate to define a
new protocol for this purpose. HTTP transport is probably
appropriate.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document has no requests to IANA.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
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 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.</t>
<t>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.</t>
<t>All communications between the device and the database
will require integrity protection.
</t>
<t>
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.
</t><t>
This
document describes the problems
that need to be addressed for a messaging interface between
white space devices and databases and does not by itself
raise any security concerns.
</t>
</section>
<section title="Summary">
<t>
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
locaion 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.
</t>
</section>
<section title="Acknowledgments">
<t>
Thanks to ABC, PQR and XYZ for their comments and input which have
helped in improving this document.
</t>
</section>
</middle>
<back>
<references title="Informative References">
<reference anchor='FCC ruling'>
<front>
<title>Unlicensed Operation in the TV Broadcast
Bands;
http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf </title>
<author><organization>Federal Communications
Commission</organization></author>
<date day='6' month='December' year='2010' />
</front>
<format type='PDF'
target='http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf' />
</reference>
<reference anchor='ECC Report 159'>
<front>
<title>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 </title>
<author><organization>Electronic Communications Committee (ECC)
within the European Conference of Postal and Telecommunications
Administrations (CEPT)</organization> </author>
<date month='January' year='2011' />
</front>
<format type='PDF'
target='http://www.erodocdb.dk/Docs/doc98/official/pdf/ECCREP159.PDF'
/>
</reference>
<reference anchor='Spectrum Framework Review'>
<front>
<title>Spectrum Framework Review;
http://stakeholders.ofcom.org.uk/consultations/sfr/ </title>
<author><organization>Ofcom - Independent regulator and
competition authority for the UK communications
industries</organization></author>
<date day='15' month='February' year='2005' />
</front>
<format type='HTML'
target='http://stakeholders.ofcom.org.uk/consultations/sfr/'
/>
</reference>
<reference anchor='DDR'>
<front>
<title>Digital Dividend Review; http://stakeholders.ofcom.org.uk/spectrum/project-pages/ddr/ </title>
<author><organization>Ofcom - Independent regulator and
competition authority for the UK communications
industries</organization></author>
</front>
<format type='HTML'
target='http://stakeholders.ofcom.org.uk/spectrum/project-pages/ddr/'
/>
</reference>
<reference anchor='DTV'>
<front>
<title>Digital TV Transition; http://www.dtv.gov</title>
</front>
<format type='HTML'
target='http://www.dtv.gov' />
</reference>
&RFC5222;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:38:36 |