One document matched: draft-ietf-paws-problem-stmt-usecases-rqmts-00.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 RFC4862 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.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-ietf-paws-problem-stmt-usecases-rqmts-00"
ipr="trust200902"
>
<front>
<title abbrev="PAWS: Problem, uses and requirements">Protocol to Access White Space
database: PS, use cases and rqmts</title>
<author role="editor" initials="S" surname="Probasco"
fullname="Scott 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 fullname="Gabor Bajko" initials="G" surname="Bajko">
<organization>Nokia</organization>
<address>
<postal>
<street>200 South Mathilda Ave</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>USA</country>
</postal>
<email>gabor.bajko@nokia.com</email>
</address>
</author>
<author fullname="Basavaraj Patil" initials="B" surname="Patil">
<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="Brian Rosen" initials="B" surname="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>Applications</area>
<workgroup>Working Group Draft</workgroup>
<keyword>HTTP</keyword>
<keyword>White Space</keyword>
<keyword>Security</keyword>
<keyword>TLS</keyword>
<keyword>Protocol</keyword>
<abstract>
<t>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.
</t>
<t>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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
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.
</t>
<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>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:</t>
<figure title="High level view of TV White Space"
anchor="fig:High level view">
<artwork><![CDATA[
Avg |
usage| |-------------- White Space
| | | | | |
0.6| || || V V ||
| || ||| | ||
0.4| || |||| | ||
| || |||| | ||<----TV transmission
0.2| || |||| | ||
|----------------------------------------
400 500 600 700 800
Frequency in MHz ->
]]></artwork></figure>
<t>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 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>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.
</t>
</section>
<section title="Conventions and Terminology">
<section title="Conventions Used in This Document">
<t>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].</t>
</section>
<section title="Terminology">
<t>
<list style="hanging">
<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="Location Based Service">
<vspace blankLines="1"/>
An application or device which provides data, information or
service to a user based on their location.
</t>
<t hangText="Master Device">
<vspace blankLines="1"/>
A device which queries the WS Database to find out the available operating channels.
</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>
<t hangText="Slave Device">
<vspace blankLines="1"/>
A device which uses the spectrum made available by a master device.</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="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="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>
</list>
</t>
</section>
</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="Use cases">
<t>
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.
</t>
<section title="TVWS database discovery">
<t>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 which can be an access point that establishes Hotspot coverage, a base station that establish cellular coverage, or a device that establishes a peer-to-peer or ad-hoc network. 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.</t>
<t>In the simplest case 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).</t>
<t>If the radio device (master) does not have a pre-programmed address for a trusted white space database, or if the trusted database at the pre-programmed address is not responsive, or perhaps the trusted database does not provide service for the radio device's current location, or at the user's choice, the device may attempt to "discover" a trusted database which provides service at the current location.</t>
<t>
<list style="numbers">
<t>The master is connected to the internet by any means other than using the TV white space radio.</t>
<t>The master constructs and broadcasts a query message over the internet and waits for responses.</t>
<t>If no acceptable response is received within a pre-configured time limit, the device concludes that no trusted database is available. If one or more response is received, the device evaluates the response to determine if a trusted database can be identified where the device is able to register and receive service from the database.</t></list></t>
</section>
<section title="Hotspot: urban internet connectivity service">
<t>In this use case internet connectivity service is provided in a "hotspot" to local users. Typical deployment scenarios include urban areas where internet connectivity is provided to local businesses and residents, and campus environments where internet connectivity is provided to local buildings and relatively small outdoor areas. This deployment scenario is typically characterized by multiple masters (APs or hotspots) in close proximity, with low antenna height, cells with relatively small radius (a few kilometers or less), and limited numbers of available radio channels. Many of the masters/APs are assumed to be individually deployed and operated, i.e. there is no coordination between many of the masters/APs. The masters/APs in this scenario use a TDD radio technology 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 end user or slave devices.</t>
<t>The figure below shows an example deployment of this scenario.
<figure title="Hotspot service using TV white space spectrum"
anchor="fig:Hotspot Service">
<artwork><![CDATA[
-------
|Slave|\ \|/ ----------
|Dev 1| (TDD AirIF) | |Database|
------- \ | .---. /---------
o \ |-|---------| ( ) /
o | Master | / \
o / | |========( Internet )
o / |-----------| \ /
------- (TDD AirIF) ( )
|Slave| / (----)
|Dev n|
-------
]]></artwork></figure>
</t>
<t>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:</t>
<t>
<list style="numbers">
<t>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).</t>
<t>The master/AP has Internet connectivity and
establishes a connection to a trusted white space database
(see use case "TVWS database discovery" above).</t>
<t>The master/AP registers its geolocation, address, contact information, etc. associated with the owner/operator of the master/AP with the trusted database administrator (if not currently registered). Depending upon local regulator policy, the DB administrator may be required to store and forward the registration information to the regulatory authority.</t>
<t>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.</t>
<t>If the master/AP has been previously authenticated, 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.</t>
<t>Once the master/AP authenticates the WS channel list response
message from the database, the AP selects an
available WS channel(s) from the list.</t>
<t>The master/AP acknowledges to the database which of the
available WS channels it has selected for its operation.
The database is updated with the information provided by
the master/AP.</t>
<t>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, based on the slaves' geolocation.</t>
<t>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.</t>
</list>
</t>
</section>
<section title="Wide-Area or Rural internet broadband access">
<t>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.</t>
<t>The figure below shows an example deployment of this scenario.
<figure title="Rural internet broadband access using TV white space spectrum"
anchor="fig:WRAN">
<artwork><![CDATA[
-------
|Slave|\ \|/ ----------
|Dev 1| (TDD AirIF) | |Database|
------- \ | .---. /----------
o \ |-|---------| ( ) /
o | Master | / \
o / | (BS) |========( Internet )
o / |-----------| \ /
------- (TDD AirIF) ( )
|Slave| / (----)
|Dev n|
-------
]]></artwork></figure>
</t>
<t>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:
</t>
<t>
<list style="numbers">
<t>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)
</t>
<t>The master/BS has internet connectivity and
establishes a connection to a trusted white space database
(see use case "TVWS database discovery" above).
</t>
<t>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). 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).
</t>
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
<t>The master/BS acknowledges to the database which of the
available WS channels the BS has selected for its operation.
The database is updated with the information provided by
the BS.
</t>
<t>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.
</t>
<t>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.
</t>
</list>
</t>
</section>
<section title="Offloading: moving traffic to a white space network">
<t>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 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.</t>
<t></t>
<t>The figure below shows an example deployment of this scenario.
<figure title="Offloading: moving traffic to a white space network"
anchor="fig:Offloading">
<artwork><![CDATA[
\|/
|
|
|-|---------|
| Master/AP |\
/| Router | \
Streaming/ |-----------| \
-------- / \ -----------
|Slave/| / \ (----) | Database |
|WS Dev| \ ( ) /----------
------- \ \ / \
\ X( Internet )
\ / \ /
Signaling \|/ / ( )\
\ | / (----) \----------
\ | / | YouTube |
\|-|---------| / ----------
| Master / | /
| 3G BTS |/
|-----------|
]]></artwork></figure>
</t>
<t>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:</t>
<t>
<list style="numbers">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
</section>
<section title="TVWS for backhaul">
<t>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</t>
<t></t>
<t>The figure below shows an example deployment of this scenario.
<figure title="TVWS for backhaul"
anchor="fig:backhaul">
<artwork><![CDATA[
\|/ white \|/ \|/ WiFi \|/
| space | | |
| | | |-|----|
|--------| |-|---------| |-|------|-| | WiFi |
| | | Master | | Slave | | Dev |
|internet|------| (AP/BS) | | Bridge | |------|
| | | | | to WiFi |
|--------| |-----------| |----------| \|/
|
|-|----|
| WiFi |
| Dev |
|------|
]]></artwork></figure>
</t>
<t>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:</t>
<t>
<list style="numbers">
<t>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.</t>
<t>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).</t>
<t>End users connect their WiFi device to the bridged device and receive internet connectivity.</t>
</list>
</t>
</section>
<section title="Location based service usage scenario">
<t>
The owner of a shopping mall wants to provide internet access
to customers when they are at the shopping mall. His internet
service provider (ISP) recommends using master/AP devices in
the TV white space frequency band since these radios will have
good propagation characteristics, and thus will require fewer
devices, and also because the frequency band used by traditional
Wi-Fi is crowded with users such as individual stores operating
their own Wi-Fi network and also Bluetooth devices. The ISP
installs APs in each large store in the mall, and
several other APs throughout the mall building. For each AP,
the professional installer programs the location (latitude and
longitude) of the device. Special tools are required to determine
the location, since typical GPS receivers do not function
indoors. When each AP is powered on, the radio does not transmit
initially. The AP contacts a white space database, using its wired
internet connection, and provides its programmed
location coordinates plus other information required by the
database. A reply is received by the AP from the database
containing a list of available channels where the AP can operate
its transmitter. The AP selects a channel for operation and
notifies the database, which records information about the AP
including the identity of the AP and its location coordinates.
The AP activates its radio and begins to function as a typical
wireless AP, providing internet access to connected devices.
</t>
<t>
A user has a slave device that is capable of operating in the TV white
spaces frequency band. A typical device would be a smartphone
with multiple radios, including a cellular radio, a Wi-Fi radio,
and TV white space radio. The user arrives at the shopping mall
and enters the building. The white space radio in the smartphone
is on, and is scanning for a master/AP. As the user gets near the
entrance to the shopping mall, the smartphone locates one of the
APs in the building and connects to it. The smartphone begins to
use this TVWS radio for internet access. This internet access does
not count against the users cellular data cap (the mall owner is
providing the internet access) and also the data rates are better
than cellular data. As the user walks throughout the mall the
smartphone moves between coverage of different APs, and the
smartphone connects to a new AP when the user and smartphone move
near it.
</t>
<t>
In order to encourage customers to come to the shopping mall, the
mall owner has a loyalty program where members register, build
points, and receive coupons and other notices from the shops in the
mall. Before installing the internet service in the mall, all
loyalty program information was mailed to the user, at an address
which was provided by the user when joining the loyalty program.
</t>
<t>
The ISP provider describes to the mall owner how the loyalty program
can be improved using the internet service provided by the APs in the
TV white space. A new app is developed for this loyalty program, and
promoted to users, asking them to install the app on their smartphone.
The app is provisioned with the user's loyalty program information.
When the user comes to the shopping mall, the smartphone locates the
master/AP providing internet service and connects to the AP. The app in the
smartphone sees that a radio connection to an AP in the TV white space
frequency band is now active. The app registers the identity of the AP
and forwards this to the home server for the loyalty program, using the
internet connection provided by the AP in the TV white space band. The
loyalty program server registers the identity of the user from the
loyalty program credentials and also the identity of the AP. Next the
loyalty program server contacts the TV white space database and requests
the location of the master/AP having the identity forwarded by the app and
smartphone. When the TV white space database replies with the location
coordinates of the AP, the loyalty program server knows the approximate
location of the user and smartphone. With this location information, the
loyalty program server can now forward loyalty program information to
the user. As the user moves through the mall, the smartphone connects to
different APs. The process is repeated, allowing the loyalty program to
delivery current location based information to the user.
</t>
<t>
<list style="numbers">
<t>The master create a TVWS network as described in use case "Hotspot: urban internet connectivity service."</t>
<t>An application running on the user's slave device (e.g. smartphone) determines that a network connection exists in the TVWS band. The identify of the master/AP is recorded by the application and forwarded to a server in the internet cloud.</t>
<t>The server queries the trusted white space database with the master identity provided by the application in the user's smartphone.</t>
<t>The trusted white space database replies to the server with the location of the master device.</t>
<t>The server uses the location of the master/AP to determine the approximate location of the user's smartphone. The server provides location-specific service to the user via the application running in the smartphone.</t>
</list>
</t>
</section>
<section title="Rapid deployed network for emergency scenario">
<t>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.</t>
<t>The figure below shows an example deployment of this scenario.
<figure title="Rapid deployed network with partly connected nodes"
anchor="fig:adhoc">
<artwork><![CDATA[
\|/
| 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 |
-----------------
]]></artwork></figure>
</t>
<t>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.</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>
</section>
<section title="Protocol">
<t>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.
</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 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.
</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>
<section title="Requirements">
<t>This section is the placeholder for the requirements derived from the use cases.</t>
</section>
<section title="IANA Considerations">
<t>This document has no requests to IANA.</t>
</section>
<section 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>
</section>
<section anchor="Summary" title="Summary and Conclusion">
<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
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.
</t>
<t>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).
</t>
</section>
<section title = "Acknowledgements">
<t>The authors acknowledge Gerald Chouinard and Teco Boot as contributors to this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='PAWS-PS'>
<front>
<title>Protocol to Access White Space database: Problem statement;
https://datatracker.ietf.org/doc/draft-patil-paws-problem-stmt/</title>
<author><organization>IETF</organization></author>
<date month='July' year='2011' />
</front>
<format type='PDF'
target='https://datatracker.ietf.org/doc/draft-patil-paws-problem-stmt/' />
</reference>
<reference anchor='RFC2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels;
http://www.rfc-editor.org/rfc/pdfrfc/rfc2119.txt.pdf</title>
<author><organization>IETF</organization></author>
<date month='March' year='1997' />
</front>
<format type='PDF'
target='http://www.rfc-editor.org/rfc/pdfrfc/rfc2119.txt.pdf' />
</reference>
</references>
<references title="Informative References">
<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>
<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='FCC Ruling'>
<front>
<title>Federal Communications Commission, "Unlicensed Operation in the TV Broadcast Bands;
http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf"</title>
<author><organization>FCC</organization></author>
<date month='December' year='2010' />
</front>
<format type='PDF'
target='http://grouper.ieee.org/groups/802/802_tutorials/2009-03/2009-03-10%20TV%20Whitespace%20Tutorial%20r0.pdf' />
</reference>
<reference anchor='RFC5222'>
<front>
<title>LoST: A Location-to-Service Translation Protocol;http://www.rfc-editor.org/rfc/pdfrfc/rfc5222.txt.pdf</title>
<author><organization>IETF, Hardie, T., Netwon, A., Schulzrinne, H., and H. Tschofenig</organization></author>
<date month='August' year='2008'/>
</front>
</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='TV Whitespace Tutorial Intro'>
<front>
<title>TV Whitespace Tutorial Intro;
http://grouper.ieee.org/groups/802/802_tutorials/2009-03/2009-03-10%20TV%20Whitespace%20Tutorial%20r0.pdf </title>
<author><organization>IEEE 802 Executive Committee Study
Group on TV White Spaces</organization></author>
<date month='March' year='2009' />
</front>
<format type='PDF'
target='http://grouper.ieee.org/groups/802/802_tutorials/2009-03/2009-03-10%20TV%20Whitespace%20Tutorial%20r0.pdf' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:45:10 |