Individual Submission S. Probasco, Ed.
Internet-Draft G. Bajko
Intended status: Informational B. Patil
Expires: January 13, 2012 Nokia
July 12, 2011
Protocol to Access White Space database: Use cases and requirements
draft-probasco-paws-overview-usecases-01
Abstract
Wireless spectrum is a commodity that is regulated by governments.
The spectrum is used for various purposes which include entertainment
(eg. radio and television), communication (telephony and Internet
access), military (radars etc.) and, navigation (satellite
communication, GPS). Portions of the radio spectrum that are unused
or unoccupied at specific locations and times are defined as "white
space". TV White space refers to those unused channels, within the
range allocated for TV transmission, that can be used without
interfering with the primary purpose for which it is allocated.
This document describes examples of how a radio system might operate
using TV white space spectrum and associated requirements. Not only
does it describe the operation of a radio system, but also how the
radio system including a white space database enables additional
services.
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 January 13, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
Probasco, et al. Expires January 13, 2012 [Page 1]
Internet-Draft PAWS: Use Cases July 2011
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Conventions Used in This Document . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. TVWS database discovery . . . . . . . . . . . . . . . . . 5
3.2. Hot-Spot: urban internet connectivity service . . . . . . 5
3.3. Wide-Area or Rural internet broadband access . . . . . . . 7
3.4. Offloading: moving traffic to a white space network . . . 9
3.5. TVWS for backhaul . . . . . . . . . . . . . . . . . . . . 11
3.6. Location based service usage scenario . . . . . . . . . . 12
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Master . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Database . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. Security . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Probasco, et al. Expires January 13, 2012 [Page 2]
Internet-Draft PAWS: Use Cases July 2011
1. Introduction
Wireless spectrum is a commodity that is regulated by governments.
The spectrum is used for various purposes which include entertainment
(eg. radio and television), communication (telephony and Internet
access), military (radars etc.) and, navigation (satellite
communication, GPS). Additionally spectrum is allocated for use
either on a license basis or for unlicensed use. 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
Regulatory entities in several countries including the US, Canada,
UK, Finland to name a few are specifying the regulations for the use
of TV white space. The availability of TV white space opens up the
potential for its use for various purposes. Regulation may mandate
its use for certain specific applications or services.
This document describes an example of how a radio system might
operate using TV white space spectrum. Not only does it describe the
operation of a radio system for providing Internet access at a hot
spot or in a rural area, but also how the radio system including a
white space database enables location based services. The
description is high level and generic, it is not meant to be specific
Probasco, et al. Expires January 13, 2012 [Page 3]
Internet-Draft PAWS: Use Cases July 2011
to any particular radio technology.
2. Conventions and Terminology
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
The Terminology Section of the latest version of
draft-patil-paws-problem-stmt [PAWS-PS] shall be included by
reference.
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.
Slave Device
A device which uses the spectrum made available by a master
device.
3. Use cases
There are many potential use cases that could be considered for the
TV white space spectrum. Providing broadband internet access in hot
spots, rural and underserved areas are examples. Available channels
may also be used to provide internet 'backhaul' for traditional Wi-Fi
hot spots, 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.
Probasco, et al. Expires January 13, 2012 [Page 4]
Internet-Draft PAWS: Use Cases July 2011
3.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 which can be an access point
that establishes Hot Spot 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 trasmit 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.
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).
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.
1. The master is connected to the internet by any means other than
using the TV white space radio.
2. The master constructs and broadcasts a query message over the
internet and waits for responses.
3. 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.
3.2. Hot-Spot: urban internet connectivity service
In this use case internet connectivity service is provided in a "hot
spot" 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 hot spots) in close proximity, with low antenna height, cells
with relatively small radius (a few kilometers or less), and limited
Probasco, et al. Expires January 13, 2012 [Page 5]
Internet-Draft PAWS: Use Cases July 2011
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.
The figure below shows an example deployment of this scenario.
-------
|Slave|\ \|/ ----------
|Dev 1| (TDD AirIF) | |Database|
------- \ | .---. /---------
o \ |-|---------| ( ) /
o | Master | / \
o / | |========( Internet )
o / |-----------| \ /
------- (TDD AirIF) ( )
|Slave| / (----)
|Dev n|
-------
Figure 2: Hot-spot 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 use case "TVWS
database discovery" above).
3. 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.
Probasco, et al. Expires January 13, 2012 [Page 6]
Internet-Draft PAWS: Use Cases July 2011
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 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.
6. 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.
7. 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.
8. 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.
9. 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.
3.3. 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 Netwowk (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 kilometers up to 100
km), and many available radio channels. Many of the masters/BSs are
assumed to be deployed and operated by a single entity, i.e. there is
coordination between many of the masters/BSs. The BS in this
scenario use a TDD radio technology and transmit at or below a
transmit power threshold 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, et al. Expires January 13, 2012 [Page 7]
Internet-Draft PAWS: Use Cases July 2011
-------
|Slave|\ \|/ ----------
|Dev 1| (TDD AirIF) | |Database|
------- \ | .---. /----------
o \ |-|---------| ( ) /
o | Master | / \
o / | (BS) |========( Internet )
o / |-----------| \ /
------- (TDD AirIF) ( )
|Slave| / (----)
|Dev n|
-------
Figure 3: 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). 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, et al. Expires January 13, 2012 [Page 8]
Internet-Draft PAWS: Use Cases July 2011
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 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.
8. The slave or user device scans the TV bands to locate a WRAN
transmission, and associates with the master/BS. The slave/user
device queries the master for a channel list, based on the
slaves' geolocation.
9. The master provides the list of channels locally availabe 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 WRAN
transmission on a different channel.
3.4. 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 -- hot spot, WAN, WRAN or
similar). The user may decide for many and various reasons such as
cost, RF coverage, data caps, etc... to prefer the TVWS connection
over the 3G cellular data connection. Either by user selection,
preconfigured preferences, or other algorithm, the streaming session
is started over the TVWS internet connection instead of the 3G
cellular connection. This deployment scenario is typically
characterized by a TVWS master/AP providing local coverage in the
same geographical area as a 3G cellular system. The master/AP is
assumed to be individually deployed and operated, i.e. the master/AP
is deployed and operated by the user at his home or perhaps by a
small business such as a coffee shop. The master/AP has a connection
to the internet and provides internet connectivity to the slave/
end-user's device.
The figure below shows an example deployment of this scenario.
Probasco, et al. Expires January 13, 2012 [Page 9]
Internet-Draft PAWS: Use Cases July 2011
\|/
|
|
|-|---------|
| Master/AP |\
/| Router | \
Streaming/ |-----------| \
-------- / \ -----------
|Slave/| / \ (----) | Database |
|WS Dev| \ ( ) /----------
------- \ \ / \
\ X( Internet )
\ / \ /
Signaling \|/ / ( )\
\ | / (----) \----------
\ | / | YouTube |
\|-|---------| / ----------
| Master / | /
| 3G BTS |/
|-----------|
Figure 4: 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 is 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.
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
Probasco, et al. Expires January 13, 2012 [Page 10]
Internet-Draft PAWS: Use Cases July 2011
connection to stream the video.
3.5. 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. Hot-Spot or Wide-Area/
Rural network). The service provider installs a TVWS slave device
and connect 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 5: 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:
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 Hot-Spot or Wide-Area/Rural internet use cases
described above.
Probasco, et al. Expires January 13, 2012 [Page 11]
Internet-Draft PAWS: Use Cases July 2011
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.
3.6. Location based service usage scenario
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, via a URL 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.
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.
Probasco, et al. Expires January 13, 2012 [Page 12]
Internet-Draft PAWS: Use Cases July 2011
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.
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.
1. The master create a TVWS network as described in use case "Hot-
Spot: urband internet connectivity service."
2. 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.
3. The server queries the trusted white space database with the
master identity provided by the application in the user's
smartphone.
4. The trusted white space database replies to the server with the
location of the master device.
Probasco, et al. Expires January 13, 2012 [Page 13]
Internet-Draft PAWS: Use Cases July 2011
5. 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.
4. Requirements
4.1. Master
1. A master device MUST include, directly or indirectly, its antenna
height in the query to the WS Database.
2. A master device MUST query the WS Database for the available
channels at least once a day to verify that the operating
channels continue to remain available.
3. A master device MUST determine its location with at least =/-50
meters accuracy and MUST place that location into the query it
makes to the WS Database.
4. A master device MAY indicate the accuracy by which it determined
its location in the query to the WS Database.
5. A master device which changes its location during operation MUST
query the WS Database for available operating channels each time
it moves more than 100 meters from the location it previously
made the query.
6. A master device MUST be able to receive channel availability
updates from a WS Database.
7. A master device MUST be able to query the WS Database for channel
availability information for multiple locations.
8. A master device MUST be able to query the WS Database for channel
availability information for a specific area around its current
location.
9. 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.
4.2. Database
1. The WS Database MUST provide the available channel list when
requested and MAY also provide time constraints for the channel
list and maximum output power to the master device.
Probasco, et al. Expires January 13, 2012 [Page 14]
Internet-Draft PAWS: Use Cases July 2011
4.3. Security
1. The protocol between the master device and the WS Database MUST
support mutual authentication and authorization.
2. The protocol between the master device and the WS Database MUST
support integrity and confidentiality protection.
3. The WS Database MUST support both username/password and digital
certificates based authentication of the master device.
4. A master device MUST be capable to validate the digital
certificate of the WS Database.
5. A master device MUST be capable to check the validity of the WS
Database certificate and whether it has been revoked or not.
5. IANA Considerations
This document has no requests to IANA.
6. Security Considerations
The messaging interface between the master and the database must be
secure to ensure confidentiality, authenticity and integrity of the
data exchanged between devices. A master queries a database with
information which identifies owner/operator of the device and also
the location of the device. Such information can reasonably
considered to be sensitive information which must remain
confidential. A well-functioning white space network relies upon
trusted devices exchanging trusted information, thus each participant
in the protocol exchange must be authenticated. A white space
network must ensure the protection of the primary user of the radio
spectrum, therefore the integrity of the message exchange must be
ensured.
7. Summary and Conclusion
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).
Probasco, et al. Expires January 13, 2012 [Page 15]
Internet-Draft PAWS: Use Cases July 2011
8. Acknowledgements
The authors acknowledge Tom Derryberry as contributor to version 00
of this document.
9. References
9.1. Normative References
[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.
9.2. Informative References
[FCC Ruling]
FCC, "Federal Communications Commission, "Unlicensed
Operation in the TV Broadcast Bands;
http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf",
December 2010.
[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, et al. Expires January 13, 2012 [Page 16]
Internet-Draft PAWS: Use Cases July 2011
Gabor Bajko
Nokia
200 South Mathilda Ave
Sunnyvale, CA 94086
USA
Email: gabor.bajko@nokia.com
Basavaraj Patil
Nokia
6021 Connection drive
Irving, TX 75039
USA
Email: basavaraj.patil@nokia.com
Probasco, et al. Expires January 13, 2012 [Page 17]