| PAWS | A. Mancuso, Ed. |
| Internet-Draft | |
| Intended status: Informational | S. Probasco |
| Expires: September 14, 2013 | B. Patil |
| March 13, 2013 |
Protocol to Access White Space (PAWS) Database: Use Cases and Requirements
draft-ietf-paws-problem-stmt-usecases-rqmts-15
Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space." The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. This document includes the problem statement for the development of a protocol to access a database of whitespace information followed by use cases and requirements for that protocol. Finally, requirements associated with the protocol are presented.
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].
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 September 14, 2013.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Wireless spectrum is a commodity that is regulated by governments. The spectrum is used for various purposes, which include, but are not limited to, entertainment (e.g., radio and television), communication (e.g., telephony and Internet access), military (e.g., radars etc.), and navigation (e.g., satellite communication, GPS). Portions of the radio spectrum that are assigned to a licensed (primary) user but are unused or unoccupied at specific locations and times are defined as "white space." The concept of allowing additional (secondary) transmissions (which may or may not be licensed) 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 assigned 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 assigned to them. The available spectrum for secondary transmissions 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 assigned 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 contains the spatial and temporal profile of all primary licensees' spectrum usage, and require secondary users to query the database for available spectrum that they can use at their location. Such databases can be accessible and queryable by secondary users on the Internet.
Any entity that is assigned spectrum that is not densely used may be asked by a governmental regulatory agency to share it to allow for more intensive use of the spectrum. Providing a mechanism by which secondary users share the spectrum with the primary user is attractive in many bands in many countries.
This document includes the problem statement followed by use cases and requirements associated with the use of white-space spectrum by secondary users via a database query protocol. The final sections include the requirements associated with such a protocol. Note that the IETF has undertaken to develop a database query protocol (see [I-D.ietf-paws-protocol]).
This document covers the requirements for a protocol to allow a device to access a database to obtain spectrum availability information. Such a protocol should allow a device to perform the following actions:
Note. The above protocol actions should explicitly or implicitly support the ability of devices to re-register and/or re-query the database when they change their locations or operating parameters. This will allow them to receive permission to operate in their new locations and/or with their new operating parameters, and to send acknowledgments to the database that include information on their new operating parameters.
The following topics are out of scope for this specification:
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. While databases are expected to support the rule set(s) of one or more regulatory domains, and the regulations and available spectrum associated with each rule set may vary, the fundamental operation of the protocol must be independent of any particular regulatory environment.
An example high-level architecture of the devices and databases is shown in Figure 1.
-----------
| Master |
|WS Device| ------------
|Lat: X |\ .---. /--------|Database A|
|Long: Y | \ ( ) / ------------
----------- \-------/ \/ o
( Internet) o
----------- /------( )\ o
| Master | / ( ) \ o
|WS Device|/ (_____) \ ------------
|Lat: X | \------|Database B|
|Long: Y | ------------
-----------
Figure 1: High-level View of White Space Database Architecture
Note that there could be multiple databases serving white space devices. In some countries, such as the U.S., the regulator has determined that multiple databases may provide service to White Space Devices.
A messaging interface between the white space devices and the database is required for operating a network using the white-space spectrum. The following sections discuss various aspects of such an interface and the need for a standard.
The use of white-space spectrum is currently approved or being considered in multiple regulatory domains, whose rules may differ. However, the need for devices that intend to use the spectrum to communicate with a database remains a common feature. The database implements rules that protect all primary users, independent of the characteristics of the white space devices. It also provides a way to specify a schedule of use, since some primary users (for example, wireless microphones) only operate in limited time slots.
Devices need to be able to query a database, directly or indirectly, over the public Internet and/or private IP networks prior to operating in available spectrum. Information about available spectrum, schedule, power, etc., are provided by the database as a response to the query from a device. The messaging interface needs to be:
The master device must obtain the address of a trusted database, which it will query for available white-space spectrum. If the master device uses a discovery service to locate a trusted database, it may perform the following steps (this description is intended as descriptive, not prescriptive):
Optionally, and in place of steps 1-2 above, the master device can be pre-configured with the address (e.g., URI) of one or more trusted databases. The master device can establish contact with one of these trusted databases.
The master device may register with the database before it queries the database for available spectrum. A registration process may consist of the following steps:
A protocol that enables a white space device to query a database to obtain information about available spectrum 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.
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.
There are many potential use cases for white-space spectrum - for example, providing broadband Internet access in urban and densely-populated hotspots as well as rural and remote, underserved areas. Available white-space spectrum may also be used to provide Internet 'backhaul' for traditional Wi-Fi hotspots or for use by towns and cities to monitor/control traffic lights, read utility meters, and the like. Still other use cases include the ability to offload data traffic from another Internet access network (e.g., 3G cellular network) or to deliver data, information, or a service to a user based on the user's location. Some of these use cases are described in the following sections.
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 using its connection to the Internet to query the database for available spectrum for itself and for one or more slave devices. These slave devices may be fixed or mobile, in close proximity with each other (indoor network or urban hotspot), or at a distance (rural or remote WAN). Once slave devices switch to white-space spectrum for their communications, they may connect through the master to the Internet or use white-space spectrum for intra-network communications only. The master device can continue to arbitrate and control white space communications by slave devices, and may notify them when they are required to change white-space frequencies or cease white space communications.
Figure 2 depicts the general architecture of such a simple master-slave network, in which the master device communicates on its own behalf and on behalf of slave devices with a database.
--------
|Slave |
|Device| \ \|/ ----------
| 1 | (Air) | |Database|
-------- \ | (----) /|--------|
| \ ------|------ ( ) /
| \| Master | / \
-------- /| |======= ( Internet )
|Slave | / | Device | \ /
|Device| (Air) | | ( )
| 2 | / |-----------| (----)
|------- /
o | /
o | (Air)
o | /
-------- /
|Slave | /
|Device| /
| n |
--------
Figure 2: Master-Slave White Space Network
The protocol requirements for these master-slave device and other similar scenarios is essentially the same: the protocol must support the ability of a master device to make available-spectrum query requests on behalf of slave devices, passing device identification, geolocation, and other slave device parameters to the database as required to obtain a list of white-space spectrum available for use by one or more slave devices. Of course, different use cases will use this spectrum information in different ways, and the details of master/slave communications may be different for different use cases.
Common steps may occur in master-slave networks include the following:
Note: Steps 5 through 7 may be repeated by the master device when it (or a slave device that uses the master as a proxy to communicate with the database) changes its location or operating parameters -- for example, after a master changes location, it may query the database for available spectrum at its new location, then acknowledge the subsequent response received from the database with information on the spectrum and power levels it is using at the new location.
This scenario is a variant of the master-slave network described in the previous use case. In this scenario, an access point (AP) offers a white space service that offloads Internet traffic as an alternative datapath to a more congested or costly Internet wire, wireless, or satellite service.
Figure 3 shows an example deployment of this scenario.
\|/
|
|--|----------|
\|/ /|Access Point |\
| (Air)--/ |-------------| \
--|------ / \ -----------
|Portable|/ \ (----) | Database|
| Device | \ ( ) /----------
|--------|\ \ / \
\ X( Internet )
\ / \ /
(Air) / ( )
\ / (----)
\ /
\|---------------|/
| Metered |
| Service |
|---------------|
Figure 3: Offloading Traffic to a White Space Network
A simplified operation scenario of offloading content, such as video stream, from a congested or costly Internet connection to a white space service provided by an AP consists of the following steps:
In this use case, an Internet connectivity service is provided to users over a common wireless standard, such as Wi-Fi, with a white space master/slave network providing backhaul connectivity to the Internet. Note that Wi-Fi is referenced in Figure 4 and the following discussion, but any other technology can be substituted in its place.
Figure 4 shows an example deployment of this scenario.
\|/ White \|/ \|/ Wi-Fi \|/
| Space | | |
| | | |-|----|
(----) |-|----| |-|------|-| | Wi-Fi|
( ) |Master| | Slave |--(Air)--| Dev |
/ \ | |--(Air)--| Bridge | |------|
( Internet )---| | | to Wi-Fi |
\ / |------| |----------| \|/
( ) \ |
(----) \(Air) |-|----|
\--| Wi-Fi|
| Dev |
|------|
Figure 4: White Space Network Used for Backhaul
Once the bridged device (WS + Wi-Fi) is connected to a master and WS network, a simplified operation scenario of backhaul for Wi-Fi consists of the following steps:
Organizations involved in handling emergency operations maintain an infrastructure that relies on dedicated spectrum for their operations. However, such infrastructures are often affected by the disasters they handle. To set up a replacement network, spectrum needs to be quickly cleared and reallocated to the crisis response organization. Automation of the this allocation and assignment is often the best solution. A preferred option is to make use of a robust protocol that has been adopted and implemented by radio manufacturers. A typical network topology solution might 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 can occur.
Figure 5 shows an example deployment of this scenario.
\|/
| ad hoc
|
|-|-------------|
| Master node | |------------|
\|/ | with | | Whitespace |
| ad hoc /| backhaul link | | Database |
| /---/ |---------------| |------------|
---|------------/ | \ /
| Master node | | | (--/--)
| without | | -----( )
| backhaul link | | Wireless / Private \
----------------\ | Access ( net or )
\ | \ Internet )
\ \|/ | ------( /
\ | ad hoc | | (------)
\ | | / \
\--|------------- /Satellite ----------
| Master node | / Link | Other |
| with |/ | nodes |
| backhaul link | ----------
-----------------
Figure 5: Rapid-deployed Network with Partly-connected Nodes
In the ad-hoc network, all nodes are master nodes that allocate RF channels from the database (as described in Section 4.1). However, the backhaul link may not be available to 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 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 utilize 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.
Available white-space spectrum can be deployed in novel ways to leverage the public use of hand-held and portable devices. One such use is white-space spectrum used for local TV transmission of audio-video content to portable devices used by individuals in attendance at an event. In this use case, audience members at a seminar, entertainment event, or other venue plug a miniature TV receiver fob into their laptop, computer tablet, cell phone, or other portable device. A master device obtains a list of available white-space spectrum (as described in , [SectMasterSlaveUse], then broadcasts audio-video content locally to the audience over one of the available frequencies. Audience members receive the content through their miniature TV receivers tuned to the appropriate white space band for display on their portable device monitors.
Figure 6 shows an example deployment of this scenario.
|------------|
|White Space |
| Database |
.---. / |------------|
|-----------| ( ) /
| Master | / \
| |========( Internet)
|-----------| \ /
| ( )
/|\ (---)
(White Space
Broadcast)
\|/ \|/ \|/ \|/ \|/ \|/ \|/
| | | | | | | .................
----- ----- ----- ----- ----- ----- -----
| | | | | | | | | | | | | |
| | | | | | | | | | | | | |
----- ----- ----- ----- ----- ----- -----
USB TV receivers connected to laptops, cellphone, tablets ....
Figure 6: White Space Used for Local TV Broadcast
This section contains operational requirements of a database-device system, independent of the requirements of the protocol for communication between the database and devices.
White space technology itself is expected to evolve and include attributes such as co-existence and interference avoidance, spectrum brokering, alternative spectrum bands, etc. The design of the data model and protocol should be cognizant of the evolving nature of white space technology and consider the following set of guidelines in the development of the data model and protocol:
This document makes no request of IANA.
PAWS is a protocol whereby a Master Device requests a schedule of available spectrum at its location (or location of its Slave Devices) before it (they) can operate using those frequencies. Whereas the information provided by the Database must be accurate and conform to applicable regulatory rules, the Database cannot enforce, through the protocol, that a client device uses only the spectrum it provided. In other words, devices can put energy in the air and cause interference without asking the Database. Hence, PAWS security considerations do not include protection against malicious use of the white-space spectrum.
Threat model for the PAWS protocol:
The security requirements arising from the above threats are captured in the requirements of
The authors acknowledge Gabor Bajko, Teco Boot, Nancy Bravin, Rex Buddenberg, Vincent Chen, Gerald Chouinard, Stephen Farrell, Michael Fitch, Joel M. Halpern, Jussi Kahtava, Paul Lambert, Barry Leiba, Subramanian Moonesamy, Pete Resnick, Brian Rosen, Andy Sago, Peter Stanforth, John Stine, and Juan Carlos Zuniga for their contributions to this document.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [I-D.ietf-paws-protocol] | Chen, V., Das, S., Zhu, L., Malyar, J. and P. McCann, "Protocol to Access Spectrum Database", Internet-Draft draft-ietf-paws-protocol-03, February 2013. |
| [WGS84] | National Imagery and Mapping Agency, "Department of Defense World Geodetic System 1984, Its Definition and Relationships with Local Geodetic Systems, NIMA TR8350.2 Third Edition Amendment 1", January 2000. |