draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt   draft-ietf-paws-problem-stmt-usecases-rqmts-10.txt 
PAWS Mancuso, Ed. PAWS Mancuso, Ed.
Internet-Draft Probasco Internet-Draft Probasco
Intended status: Informational Patil Intended status: Informational Patil
Expires: June 21, 2013 December 18, 2012 Expires: July 18, 2013 January 14, 2013
Protocol to Access White Space (PAWS) Database: Use Cases and Protocol to Access White Space (PAWS) Database: Use Cases and
Requirements Requirements
draft-ietf-paws-problem-stmt-usecases-rqmts-09 draft-ietf-paws-problem-stmt-usecases-rqmts-10
Abstract Abstract
[Editor's Note: This version is submitted for review. A final, post-
review version is anticipated that will supersede this version].
Portions of the radio spectrum that are assigned to a particular use Portions of the radio spectrum that are assigned to a particular use
but are unused or unoccupied at specific locations and times are but are unused or unoccupied at specific locations and times are
defined as "white space." The concept of allowing additional defined as "white space." The concept of allowing additional
transmissions (which may or may not be licensed) in white space is a transmissions (which may or may not be licensed) in white space is a
technique to "unlock" existing spectrum for new use. An obvious technique to "unlock" existing spectrum for new use. An obvious
requirement is that these additional transmissions do not interfere requirement is that these additional transmissions do not interfere
with the assigned use of the spectrum. One approach to using white with the assigned use of the spectrum. One approach to using white
space spectrum at a given time and location is to verify spectrum space spectrum at a given time and location is to verify spectrum
availability with a database that manages spectrum sharing and availability with a database that manages spectrum sharing and
provides spectrum-availability information. provides spectrum-availability information.
skipping to change at page 2, line 12 skipping to change at page 2, line 12
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 21, 2013. This Internet-Draft will expire on July 18, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 24 skipping to change at page 3, line 24
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Use Cases and Protocol Services . . . . . . . . . . . . . . . 6 3. Use Cases and Protocol Services . . . . . . . . . . . . . . . 6
3.1. Protocol services . . . . . . . . . . . . . . . . . . . . 6 3.1. Protocol services . . . . . . . . . . . . . . . . . . . . 6
3.1.1. White space database discovery . . . . . . . . . . . . 7 3.1.1. White space database discovery . . . . . . . . . . . . 7
3.1.2. Device registration with trusted database . . . . . . 7 3.1.2. Device registration with trusted database . . . . . . 7
3.2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Master-slave white space networks . . . . . . . . . . 8 3.2.1. Master-slave white space networks . . . . . . . . . . 8
3.2.2. Offloading: moving traffic to a white space network . 10 3.2.2. Offloading: moving traffic to a white space network . 10
3.2.3. White space serving as backhaul . . . . . . . . . . . 12 3.2.3. White space serving as backhaul . . . . . . . . . . . 12
3.2.4. Rapid network deployment during emergency scenario . . 12 3.2.4. Rapid network deployment during emergency scenario . . 12
3.2.5. White space used for local TV broadcaster . . . . . . 13 3.2.5. White space used for local TV broadcaster . . . . . . 14
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 14 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Global applicability . . . . . . . . . . . . . . . . . . . 15 4.1. Global applicability . . . . . . . . . . . . . . . . . . . 15
4.2. Database discovery . . . . . . . . . . . . . . . . . . . . 17 4.2. Database discovery . . . . . . . . . . . . . . . . . . . . 17
4.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4. Data model definition . . . . . . . . . . . . . . . . . . 17 4.4. Data model definition . . . . . . . . . . . . . . . . . . 17
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Normative Requirements . . . . . . . . . . . . . . . . . . 17 5.1. Normative Requirements . . . . . . . . . . . . . . . . . . 17
5.2. Non-normative requirements . . . . . . . . . . . . . . . . 20 5.2. Non-normative requirements . . . . . . . . . . . . . . . . 20
5.3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 22 5.3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
skipping to change at page 6, line 36 skipping to change at page 6, line 36
at a specific location and time. at a specific location and time.
White Space Device (WSD) A device that uses white space spectrum as White Space Device (WSD) A device that uses white space spectrum as
a secondary user. A white space device can be a fixed or portable a secondary user. A white space device can be a fixed or portable
device such as an access point, base station, or cell phone. device such as an access point, base station, or cell phone.
3. Use Cases and Protocol Services 3. Use Cases and Protocol Services
There are many potential use cases for white space spectrum - for There are many potential use cases for white space spectrum - for
example, providing broadband Internet access in urban and densely- example, providing broadband Internet access in urban and densely-
populated hotspots as well as rural and underserved areas. Available populated hotspots as well as rural and remote, underserved areas.
white space spectrum may also be used to provide Internet 'backhaul' Available white space spectrum may also be used to provide Internet
for traditional Wi-Fi hotspots or for use by towns and cities to 'backhaul' for traditional Wi-Fi hotspots or for use by towns and
monitor/control traffic lights, read utility meters, and the like. cities to monitor/control traffic lights, read utility meters, and
Still other use cases include the ability to offload data traffic the like. Still other use cases include the ability to offload data
from another Internet access network (e.g., 3G cellular network) or traffic from another Internet access network (e.g., 3G cellular
to deliver location-based services. Some of these use cases are network) or to deliver location-based services. Some of these use
described in the following sections. cases are described in the following sections.
3.1. Protocol services 3.1. Protocol services
A complete protocol solution must enable all potential white space A complete protocol solution must enable all potential white space
services. This section describes the features required of the services. This section describes the features required of the
protocol. protocol.
3.1.1. White space database discovery 3.1.1. White space database discovery
White space database discovery is preliminary to creating a radio White space database discovery is preliminary to creating a radio
skipping to change at page 8, line 52 skipping to change at page 8, line 52
3.2. Use cases 3.2. Use cases
3.2.1. Master-slave white space networks 3.2.1. Master-slave white space networks
There are a number of common scenarios in which a master white space There are a number of common scenarios in which a master white space
device will act as proxy or mediator for one or more slave devices device will act as proxy or mediator for one or more slave devices
using its connection to the Internet to query the database for using its connection to the Internet to query the database for
available spectrum for itself and for one or more slave devices. available spectrum for itself and for one or more slave devices.
These slave devices may be fixed or mobile, in close proximity with These slave devices may be fixed or mobile, in close proximity with
each other (indoor network or urban hotspot), or at a distance (rural each other (indoor network or urban hotspot), or at a distance (rural
WAN). Once slave devices switch to white space spectrum for their or remote WAN). Once slave devices switch to white space spectrum
communications, they may connect through the master to the Internet for their communications, they may connect through the master to the
or use white space spectrum for intra-network communications only. Internet or use white space spectrum for intra-network communications
The master device can continue to arbitrate and control white space only. The master device can continue to arbitrate and control white
communications by slave devices, and may notify them when they are space communications by slave devices, and may notify them when they
required to change white space frequencies or cease white space are required to change white space frequencies or cease white space
communications. communications.
Figure 2 (Figure 2) depicts the general architecture such a simple Figure 2 (Figure 2) depicts the general architecture such a simple
master-slave network, in which the master device communicates on its master-slave network, in which the master device communicates on its
own behalf and on behalf of slave devices with a white space own behalf and on behalf of slave devices with a white space
database. database.
-------- --------
|Slave | |Slave |
|Device| \ \|/ ---------- |Device| \ \|/ ----------
| 1 | (Air) | |Database| | 1 | (Air) | |Database|
-------- \ | (----) /|--------| -------- \ | (----) /|--------|
| \ ------|------ ( ) / | \ ------|------ ( ) /
| \| Master | / \ | \| Master | / \
-------- /| |======= ( Internet ) -------- /| |======= ( Internet )
|Slave | / | Device | \ / |Slave | / | Device | \ /
|Device| (Air) | | ( ) |Device| (Air) | | ( )
| 2 | / |-----------| (----) | 2 | / |-----------| (----)
|------- / |------- /
o | / o | /
o | (Air) o | (Air)
o | / o | /
-------- / -------- /
|Slave | / |Slave | /
|Device| / |Device| /
| n | | n |
-------- --------
Figure 2: Master-Slave White Space Network Figure 2: Master-Slave White Space Network
The protocol requirements for these master-slave device and other The protocol requirements for these master-slave device and other
similar scenarios is essentially the same: the protocol must support similar scenarios is essentially the same: the protocol must support
the ability of a master device to make available-spectrum query the ability of a master device to make available-spectrum query
requests on behalf of slave devices, passing device identification, requests on behalf of slave devices, passing device identification,
geolocation, and other slave device parameters to the database as geolocation, and other slave device parameters to the database as
required to obtain a list of white space spectrum available for use required to obtain a list of white space spectrum available for use
skipping to change at page 11, line 9 skipping to change at page 11, line 9
the previous use case. In this scenario, an Internet connectivity the previous use case. In this scenario, an Internet connectivity
service is provided over white space as a supplemental or alternative service is provided over white space as a supplemental or alternative
datapath to a more costly Internet connection (metered wire service, datapath to a more costly Internet connection (metered wire service,
metered wireless service, metered satellite service). In a typical metered wireless service, metered satellite service). In a typical
deployment scenario, an end user has a primary Internet connection, deployment scenario, an end user has a primary Internet connection,
but may prefer to use a connection to the Internet provided by a but may prefer to use a connection to the Internet provided by a
local white space master device that is connected to the Internet. local white space master device that is connected to the Internet.
Figure 3 (Figure 3) shows an example deployment of this scenario. Figure 3 (Figure 3) shows an example deployment of this scenario.
\|/ \|/
| |
| |
|------------| |------------|
/| Master | \ /| Master | \
(Air)-/ |------------| \ (Air)-/ |------------| \
--------- / \ ----------- --------- / \ -----------
|Slave |/ \ (----) | Database| |Slave |/ \ (----) | Database|
|Device | \ ( ) /---------- |Device | \ ( ) /----------
|-------|\ \ / \ |-------|\ \ / \
\ X( Internet ) \ X( Internet )
\ / \ / \ / \ /
(Air) / ( ) (Air) / ( )
\ / (----) \ / (----)
\ / \ /
\|---------------|/ \|---------------|/
| Metered | | Metered |
| Service | | Service |
|---------------| |---------------|
Figure 3: Offloading Traffic to a White Space Network Figure 3: Offloading Traffic to a White Space Network
A simplified operation scenario of offloading content, such as video A simplified operation scenario of offloading content, such as video
stream, from the a metered Internet connection to the a WS connection stream, from the a metered Internet connection to the a WS connection
consists of the following steps: consists of the following steps:
1. The slave device connects to a metered Internet service, and 1. The slave device connects to a metered Internet service, and
selects a video for streaming. selects a video for streaming.
skipping to change at page 12, line 10 skipping to change at page 12, line 10
* Note that the slave device may query the database directly for * Note that the slave device may query the database directly for
available white space spectrum through its metered connection to the available white space spectrum through its metered connection to the
Internet, thus eliminating steps 2 and 3. Internet, thus eliminating steps 2 and 3.
3.2.3. White space serving as backhaul 3.2.3. White space serving as backhaul
In this use case, an Internet connectivity service is provided to In this use case, an Internet connectivity service is provided to
users over a common wireless standard, such as Wi-Fi, with a white users over a common wireless standard, such as Wi-Fi, with a white
space master/slave network providing backhaul connectivity to the space master/slave network providing backhaul connectivity to the
Internet. Internet. Note that Wi-Fi is referenced in Figure 4 (Figure 4) and
the following discussion, but any other technology can be substituted
in its place.
Figure 4 (Figure 4) shows an example deployment of this scenario. Figure 4 (Figure 4) shows an example deployment of this scenario.
\|/ White \|/ \|/ Wi-Fi \|/ \|/ White \|/ \|/ Wi-Fi \|/
| Space | | | | Space | | |
| | | |-|----| | | | |-|----|
(----) |-|----| |-|------|-| | Wi-Fi| (----) |-|----| |-|------|-| | Wi-Fi|
( ) |Master| | Slave |--(Air)--| Dev | ( ) |Master| | Slave |--(Air)--| Dev |
/ \ | |--(Air)--| Bridge | |------| / \ | |--(Air)--| Bridge | |------|
( Internet )---| | | to Wi-Fi | ( Internet )---| | | to Wi-Fi |
\ / |------| |----------| \|/ \ / |------| |----------| \|/
skipping to change at page 13, line 11 skipping to change at page 13, line 13
organization. Automation of the this allocation and assignment is organization. Automation of the this allocation and assignment is
often the best solution. A preferred option is to make use of a often the best solution. A preferred option is to make use of a
robust protocol that has been adopted and implemented by radio robust protocol that has been adopted and implemented by radio
manufacturers. A typical network topology solution might include manufacturers. A typical network topology solution might include
wireless access links to the public Internet or private network, wireless access links to the public Internet or private network,
wireless ad-hoc network radios working independent of a fixed wireless ad-hoc network radios working independent of a fixed
infrastructure, and satellite links for backup where lack of infrastructure, and satellite links for backup where lack of
coverage, overload, or outage of wireless access links can occur. coverage, overload, or outage of wireless access links can occur.
Figure 5 (Figure 5) shows an example deployment of this scenario. Figure 5 (Figure 5) shows an example deployment of this scenario.
\|/ \|/
| ad hoc | ad hoc
| |
|-|-------------| |-|-------------|
| Master node | |------------| | Master node | |------------|
\|/ | with | | Whitespace | \|/ | with | | Whitespace |
| ad hoc /| backhaul link | | Database | | ad hoc /| backhaul link | | Database |
| /------/ |---------------| |------------| | /---/ |---------------| |------------|
---|------------/ | \ / ---|------------/ | \ /
| Master node | | | (--/--) | Master node | | | (--/--)
| without | | -----( ) | without | | -----( )
| backhaul link | | Wireless / Private \ | backhaul link | | Wireless / Private \
----------------\ | Access ( net or ) ----------------\ | Access ( net or )
\ | \ Internet ) \ | \ Internet )
\ \|/ | ------( /\ \ \|/ | ------( /
\ | ad hoc | | (------) \--------- \ | ad hoc | | (------)
\ | | / | Other | \ | | / \
\--|------------- /Satellite | nodes | \--|------------- /Satellite ----------
| Master node | / Link ---------- | Master node | / Link | Other |
| with |/ | with |/ | nodes |
| backhaul link | | backhaul link | ----------
----------------- -----------------
Figure 5: Rapid-deployed Network with Partly-connected Nodes Figure 5: Rapid-deployed Network with Partly-connected Nodes
In the ad-hoc network, all nodes are master nodes that allocate RF In the ad-hoc network, all nodes are master nodes that allocate RF
channels from the white space database (as described in channels from the white space database (as described in
Section 3.2.1). However, the backhaul link may not be available to Section 3.2.1). However, the backhaul link may not be available to
all nodes, such as depicted for the left node in the above figure. all nodes, such as depicted for the left node in the above figure.
To handle RF channel allocation for such nodes, a master node with a To handle RF channel allocation for such nodes, a master node with a
backhaul link relays or proxies the database query for them. So backhaul link relays or proxies the database query for them. So
master nodes without a backhaul link follow the procedure as defined master nodes without a backhaul link follow the procedure as defined
skipping to change at page 26, line 44 skipping to change at page 26, line 44
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informational References 10.2. Informational References
[Home] "", <view-source:http://www.dtv.gov/>.
URIs URIs
[1] <http://en.wikipedia.org/wiki/Cognitive_radio> [1] <http://en.wikipedia.org/wiki/Cognitive_radio>
[2] <http://earth-info.nga.mil/GandG/publications/tr8350.2/ [2] <http://earth-info.nga.mil/GandG/publications/tr8350.2/
tr8350_2.html> tr8350_2.html>
Authors' Addresses Authors' Addresses
Anthony Mancuso (editor) Anthony Mancuso (editor)
 End of changes. 14 change blocks. 
86 lines changed or deleted 82 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/