summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6953.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6953.txt')
-rw-r--r--doc/rfc/rfc6953.txt1291
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc6953.txt b/doc/rfc/rfc6953.txt
new file mode 100644
index 0000000..41f917d
--- /dev/null
+++ b/doc/rfc/rfc6953.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Mancuso, Ed.
+Request for Comments: 6953 Google
+Category: Informational S. Probasco
+ISSN: 2070-1721
+ B. Patil
+ Cisco Systems
+ May 2013
+
+
+ Protocol to Access White-Space (PAWS) Databases:
+ Use Cases and Requirements
+
+Abstract
+
+ 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 white-space information followed by use cases
+ and requirements for that protocol. Finally, requirements associated
+ with the protocol are presented.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6953.
+
+
+
+
+
+
+
+
+
+
+
+
+Mancuso, et al. Informational [Page 1]
+
+RFC 6953 PAWS Use Cases and Requirements May 2013
+
+
+Copyright Notice
+
+ 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.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Introduction to White Space . . . . . . . . . . . . . . . 3
+ 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.2.1. In Scope . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.2.2. Out of Scope . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Conventions Used in This Document . . . . . . . . . . . . . . 5
+ 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
+ 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
+ 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.1. Global Applicability . . . . . . . . . . . . . . . . . . . 6
+ 3.2. Database Discovery . . . . . . . . . . . . . . . . . . . . 8
+ 3.3. Device Registration . . . . . . . . . . . . . . . . . . . 8
+ 3.4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 3.5. Data Model Definition . . . . . . . . . . . . . . . . . . 9
+ 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 4.1. Master-Slave White-Space Networks . . . . . . . . . . . . 9
+ 4.2. Offloading: Moving Traffic to a White-Space Network . . . 11
+ 4.3. White Space Serving as Backhaul . . . . . . . . . . . . . 13
+ 4.4. Rapid Network Deployment during Emergencies . . . . . . . 14
+ 4.5. White Space Used for Local TV Broadcaster . . . . . . . . 15
+ 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ 5.1. Data Model Requirements . . . . . . . . . . . . . . . . . 16
+ 5.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 17
+ 5.3. Operational Requirements . . . . . . . . . . . . . . . . . 19
+ 5.4. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
+ 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
+ 8.2. Informative References . . . . . . . . . . . . . . . . . . 22
+
+
+
+
+Mancuso, et al. Informational [Page 2]
+
+RFC 6953 PAWS Use Cases and Requirements May 2013
+
+
+1. Introduction
+
+1.1. Introduction to White Space
+
+ 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 [CRADIO]
+ 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
+ [PAWS]).
+
+
+
+
+
+
+
+Mancuso, et al. Informational [Page 3]
+
+RFC 6953 PAWS Use Cases and Requirements May 2013
+
+
+1.2. Scope
+
+1.2.1. In Scope
+
+ 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:
+
+ 1. Determine the relevant database to query.
+
+ 2. Connect to and optionally register with the database using a
+ well-defined protocol.
+
+ 3. Provide geolocation and perhaps other data to the database using
+ a well-defined format for querying the database.
+
+ 4. Receive in response to the query a list of available white-space
+ frequencies at the specified geolocation using a well-defined
+ format for the information.
+
+ 5. Send an acknowledgment to the database with information
+ containing channels selected for use by the device and other
+ device operation parameters.
+
+ 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.
+
+1.2.2. Out of Scope
+
+ The following topics are out of scope for this specification:
+
+ 1. It is the device's responsibility to query the database for new
+ spectrum when the device moves, changes operating parameters,
+ loses connectivity, etc. Other synchronization mechanisms are
+ out of scope.
+
+ 2. A rogue device may operate without contacting the database to
+ obtain available spectrum. Hence, enforcement of spectrum usage
+ by devices is out of scope.
+
+
+
+
+
+
+Mancuso, et al. Informational [Page 4]
+
+RFC 6953 PAWS Use Cases and Requirements May 2013
+
+
+ 3. The protocol defines communications between the database and
+ devices. The protocol for communications between devices is out
+ of scope.
+
+ 4. Coexistence and interference avoidance of white-space devices
+ within the same spectrum are out of scope.
+
+ 5. Provisioning (releasing new spectrum for white-space use) is out
+ of scope.
+
+2. Conventions Used in This Document
+
+2.1. Terminology
+
+ Database: A database is an entity that contains current information
+ about available spectrum at a given location and time, as well as
+ other types of information related to spectrum availability and
+ usage.
+
+ Device Class: Identifies classes of devices including fixed, mobile,
+ portable, etc. May also indicate if the device is indoor or
+ outdoor.
+
+ Device ID: An identifier for a device.
+
+ Master Device: A device that queries the database, on its own behalf
+ and/or on behalf of a slave device, to obtain available spectrum
+ information.
+
+ Slave Device: A device that queries the database through a master
+ device.
+
+ Trusted Database: A database that is trusted by a device or provides
+ data objects that are trusted by a device.
+
+ White Space (WS): Radio spectrum that is available for secondary use
+ at a specific location and time.
+
+ 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
+ device such as an access point, base station, or cell phone.
+
+2.2. Requirements Language
+
+ 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].
+
+
+
+
+Mancuso, et al. Informational [Page 5]
+
+RFC 6953 PAWS Use Cases and Requirements May 2013
+
+
+3. Problem Statement
+
+ 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 of the 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.
+
+3.1. Global Applicability
+
+ 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
+
+
+
+Mancuso, et al. Informational [Page 6]
+
+RFC 6953 PAWS Use Cases and Requirements May 2013
+
+
+ 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:
+
+ 1. Interface agnostic - An interface between a master white-space
+ device and database can be wired or unwired (e.g., a radio/air
+ interface technology such as IEEE 802.11af, IEEE 802.15.4m, IEEE
+ 802.16, IEEE 802.22, LTE, etc.) However, the messaging interface
+ between a master white-space device and the database should be
+ agnostic to the interface used for such messaging while being
+ cognizant of the characteristics of the interface technology and
+ the need to include any relevant attributes in the query to the
+ database.
+
+ 2. Spectrum agnostic - The spectrum used by primary and secondary
+ users varies by country. Some spectrum bands have 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 primary and secondary use. The
+ protocol should be able to be used in any spectrum band where
+ white-space sharing is permitted.
+
+ 3. 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 location where such spectrum is available and a common
+ interface ensures uniformity in implementations and deployment.
+ To allow the global use of white-space devices in different
+ countries (whatever the regulatory domain), the protocol should
+ support the database that communicates the applicable regulatory
+ rule-set information to the white-space device.
+
+ 4. Built on flexible and extensible data structures - Different
+ databases are likely to have different requirements for the kinds
+ of data required for registration (different regulatory rule sets
+ that apply to the registration of devices) and other messages
+ sent by the device to the database. For instance, different
+ regulators might require different device-characteristic
+ information to be passed to the database.
+
+
+
+Mancuso, et al. Informational [Page 7]
+
+RFC 6953 PAWS Use Cases and Requirements May 2013
+
+
+3.2. Database Discovery
+
+ 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):
+
+ 1. The master device constructs and sends a request (e.g., over the
+ Internet) to a trusted discovery service.
+
+ 2. If no acceptable response is received within a pre-configured
+ time limit, the master device concludes that no trusted database
+ is available. If at least one response is received, the master
+ device evaluates the response(s) to determine if a trusted
+ database can be identified where the master device is able to
+ receive service from the database. If so, it establishes contact
+ with the trusted database.
+
+ 3. The master device establishes a white-space network as described
+ in Section 4.
+
+ 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.
+
+3.3. Device Registration
+
+ 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:
+
+ 1. The master device sends registration information to the database.
+ This information may include the device ID; serial number
+ assigned by the manufacturer; device location; device antenna
+ height above ground; name of the individual or business that owns
+ the device; and the name, postal address, email address, and
+ phone number of a contact person responsible for the device's
+ operation.
+
+ 2. The database responds to the registration request with an
+ acknowledgment to indicate the success of the registration
+ request or with an error if the registration was unsuccessful.
+ Additional information may be provided by the database in its
+ response to the master device.
+
+
+
+
+
+Mancuso, et al. Informational [Page 8]
+
+RFC 6953 PAWS Use Cases and Requirements May 2013
+
+
+3.4. Protocol
+
+ 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.
+
+3.5. Data Model Definition
+
+ The contents of the queries and response need to be specified. A
+ data model is required; it must enable 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, 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.
+
+4. Use Cases
+
+ 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.
+
+4.1. Master-Slave White-Space Networks
+
+ 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 it may notify them when
+ they are required to change white-space frequencies or cease white-
+ space communications.
+
+
+
+
+Mancuso, et al. Informational [Page 9]
+
+RFC 6953 PAWS Use Cases and Requirements May 2013
+
+
+ Figure 2 depicts the general architecture of such a simple master-
+ slave network in which the master device communicates with a database
+ on its own behalf and on behalf of slave devices.
+
+ --------
+ |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 devices 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 that may occur in master-slave networks include the
+ following:
+
+ 1. The master device powers up.
+
+ 2. Slave devices may power up and associate with the master device
+ via Wi-Fi or some other over-the-air, non-white-space spectrum.
+ Until the slave device is allocated white-space spectrum, any
+ master-slave or slave-slave communications occurs over such non-
+ white-space spectrum.
+
+
+
+
+Mancuso, et al. Informational [Page 10]
+
+RFC 6953 PAWS Use Cases and Requirements May 2013
+
+
+ 3. The master has Internet connectivity, determines (or knows) its
+ location, and establishes a connection to a trusted database (see
+ Section 3.2).
+
+ 4. The master may register with the trusted database (see
+ Section 3.3).
+
+ 5. The master sends a query to the trusted database requesting a
+ list of available white-space spectrum based upon its
+ geolocation. Query parameters may include the master's location,
+ device identifier, and antenna height. The master may send
+ available-spectrum requests to the database on behalf of slave
+ devices.
+
+ 6. The database responds to the master's query with a list of
+ available white-space spectrum, associated maximum power levels,
+ and durations of time for spectrum use. If the master made
+ requests on behalf of slave devices, the master may transmit the
+ obtained available-spectrum lists to the slaves (or the master
+ may allocate spectrum to slaves from the obtained spectrum
+ lists).
+
+ 7. The master may inform the database of the spectrum and power
+ level it selects from the available spectrum list. If a slave
+ device has been allocated available white-space spectrum, the
+ slave may inform the master of the spectrum and power level it
+ has chosen, and the master may, in turn, relay such slave device
+ usage to the database.
+
+ 8. Further communication among masters and slaves over the white-
+ space network may occur via the selected/allocated white-space
+ spectrum frequencies.
+
+ 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.
+
+4.2. Offloading: Moving Traffic to a White-Space Network
+
+ 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 data path to a more congested or costly Internet wire,
+ wireless, or satellite service.
+
+
+
+Mancuso, et al. Informational [Page 11]
+
+RFC 6953 PAWS Use Cases and Requirements May 2013
+
+
+ Figure 3 shows an example of 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:
+
+ 1. The AP contacts the database to determine channels it can use.
+
+ 2. The portable device connects to a paid Internet service and
+ selects a video for streaming.
+
+ 3. The portable device determines if it can offload to a white-space
+ AP:
+
+ A. If the portable device knows its location, it
+
+ 1. asks the database (using the paid service) for available
+ white-space spectrum;
+
+ 2. listens for and connects to the AP over the permitted
+ white-space spectrum.
+
+ B. If the portable device does not have GPS or other means to
+ determine its position, it
+
+ 1. uses non-white-space spectrum to listen for and connect
+ to the AP;
+
+
+
+Mancuso, et al. Informational [Page 12]
+
+RFC 6953 PAWS Use Cases and Requirements May 2013
+
+
+ 2. asks the AP to query the database for permitted white-
+ space spectrum on its behalf;
+
+ 3. uses the permitted white-space spectrum to connect to the
+ AP.
+
+ 4. The portable device accesses the Internet through the AP to
+ stream the selected video.
+
+4.3. White Space Serving as Backhaul
+
+ 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 of 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 (Slave Bridge + Wi-Fi) is connected to a
+ master and WS network, a simplified operation scenario of backhaul
+ for Wi-Fi consists of the following steps:
+
+ 1. A bridged slave device (Slave Bridge + Wi-Fi) is connected to a
+ master device operating in the WS spectrum (the master obtains
+ available white-space spectrum as described in Section 4.1).
+
+ 2. Once the slave device is connected to the master, the Wi-Fi
+ access point has Internet connectivity as well.
+
+ 3. End users attach to the Wi-Fi network via their Wi-Fi-enabled
+ devices and receive Internet connectivity.
+
+
+
+Mancuso, et al. Informational [Page 13]
+
+RFC 6953 PAWS Use Cases and Requirements May 2013
+
+
+4.4. Rapid Network Deployment during Emergencies
+
+ 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 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 independently 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 of deployment of this scenario.
+
+ \|/
+ | ad hoc
+ |
+ |-|-------------|
+ | Master node | |-------------|
+ \|/ | with | | White-Space |
+ | 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: Rapidly Deployed Network with Partly Connected Nodes
+
+ In the ad hoc network, all nodes are master nodes that allocate radio
+ frequency (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
+
+
+
+Mancuso, et al. Informational [Page 14]
+
+RFC 6953 PAWS Use Cases and Requirements May 2013
+
+
+ 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.
+
+4.5. White Space Used for Local TV Broadcaster
+
+ 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 Section 4.1), 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 the monitors of their portable devices.
+
+ Figure 6 shows an example of deployment of this scenario.
+
+ |------------|
+ |White-Space |
+ | Database |
+ .---. / |------------|
+ |-----------| ( ) /
+ | Master | / \
+ | |========( Internet)
+ |-----------| \ /
+ | ( )
+ /|\ (---)
+
+ (White-Space
+ Broadcast)
+
+ \|/ \|/ \|/ \|/ \|/ \|/ \|/
+ | | | | | | | .................
+ ----- ----- ----- ----- ----- ----- -----
+ | | | | | | | | | | | | | |
+ | | | | | | | | | | | | | |
+ ----- ----- ----- ----- ----- ----- -----
+ USB TV receivers connected to laptops, cell phones, tablets ...
+
+ Figure 6: White Space Used for Local TV Broadcast
+
+
+
+Mancuso, et al. Informational [Page 15]
+
+RFC 6953 PAWS Use Cases and Requirements May 2013
+
+
+5. Requirements
+
+5.1. Data Model Requirements
+
+ D.1 The data model MUST support specifying the geolocation of the
+ white-space device, the uncertainty in meters, the height and
+ its uncertainty, and the percentage of confidence in the
+ location determination. The data model MUST support [WGS84].
+
+ D.2 The data model MUST support specifying the data and other
+ applicable requirements of the rule set that applies to the
+ white-space device at a specified location.
+
+ D.3 The data model MUST support device description data that
+ identifies a white-space device (serial number, certification
+ IDs, etc.) and describes device characteristics, such as device
+ class (fixed, mobile, portable, indoor, outdoor, etc.), Radio
+ Access Technology (RAT), etc.
+
+ D.4 The data model MUST support specifying a manufacturer's serial
+ number for a white-space device.
+
+ D.5 The data model MUST support specifying the antenna- and
+ radiation-related parameters of the white-space device, such as:
+
+ antenna height
+
+ antenna gain
+
+ maximum output power, Equivalent Isotropic Radiated Power
+ (EIRP) in dBm (decibels referenced to 1 milliwatt)
+
+ antenna radiation pattern (directional dependence of the
+ strength of the radio signal from the antenna)
+
+ spectrum mask with lowest and highest possible frequency
+
+ spectrum mask in dBr (decibels referenced to an arbitrary
+ reference level) from peak transmit power in EIRP, with
+ specific power limit at any frequency linearly interpolated
+ between adjacent points of the spectrum mask
+
+ measurement resolution bandwidth for EIRP measurements
+
+ D.6 The data model MUST support specifying owner and operator
+ contact information for a transmitter. This includes the name
+ of the transmitter owner and the name, postal address, email
+ address, and phone number of the transmitter operator.
+
+
+
+Mancuso, et al. Informational [Page 16]
+
+RFC 6953 PAWS Use Cases and Requirements May 2013
+
+
+ D.7 The data model MUST support specifying spectrum availability.
+ Spectrum units are specified by low and high frequencies and may
+ have an optional channel identifier. The data model MUST
+ support a schedule including start time and stop time for
+ spectrum unit availability. The data model MUST support maximum
+ power level for each spectrum unit.
+
+ D.8 The data model MUST support specifying spectrum availability
+ information for a single location and an area (e.g., a polygon
+ defined by multiple location points or a geometric shape such as
+ a circle).
+
+ D.9 The data model MUST support specifying the frequencies and power
+ levels selected for use by a white-space device in the
+ acknowledgment message.
+
+5.2. Protocol Requirements
+
+ P.1 The master device identifies a database to which it can
+ register, make spectrum availability requests, etc. The
+ protocol MUST support the discovery of an appropriate database
+ given a location provided by the master device. The master
+ device MAY select a database by discovery at run time or by
+ means of a pre-programmed URI. The master device MAY validate
+ discovered or configured database addresses against a list of
+ known databases (e.g., a list of databases approved by a
+ regulatory body).
+
+ P.2 The protocol MUST support the database informing the master of
+ the regulatory rules (rule set) that applies to the master
+ device (or any slave devices on whose behalf the master is
+ contacting the database) at a specified location.
+
+ P.3 The protocol MUST provide the ability for the database to
+ authenticate the master device.
+
+ P.4 The protocol MUST provide the ability for the master device to
+ verify the authenticity of the database with which it is
+ interacting.
+
+ P.5 The messages sent by the master device to the database and the
+ messages sent by the database to the master device MUST support
+ integrity protection.
+
+ P.6 The protocol MUST provide the capability for messages sent by
+ the master device and database to be encrypted.
+
+
+
+
+
+Mancuso, et al. Informational [Page 17]
+
+RFC 6953 PAWS Use Cases and Requirements May 2013
+
+
+ P.7 Tracking of master or slave device uses of white-space spectrum
+ by database administrators, regulatory agencies, and others who
+ have access to a white-space database could be considered
+ invasive of privacy, including privacy regulations in specific
+ environments. The PAWS protocol SHOULD support privacy-
+ sensitive handling of device-provided data where such
+ protection is feasible, allowed, and desired.
+
+ P.8 The protocol MUST support the master device registering with
+ the database; see Device Registration (Section 3.3).
+
+ P.9 The protocol MUST support a registration acknowledgment
+ indicating the success or failure of the master device
+ registration.
+
+ P.10 The protocol MUST support an available spectrum request from
+ the master device to the database, which may include one or
+ more of the data items listed in Data Model Requirements
+ (Section 5.1). The request may include data that the master
+ device sends on its own behalf and/or on behalf of one or more
+ slave devices.
+
+ P.11 The protocol MUST support an available spectrum response from
+ the database to the master device, which may include one or
+ more of the data items listed in Data Model Requirements
+ (Section 5.1). The response may include data related to master
+ and/or slave device operation.
+
+ P.12 The protocol MUST support a spectrum usage message from the
+ master device to the database, which may include one or more of
+ the data items listed in Data Model Requirements (Section 5.1).
+ The message may include data that the master device sends on
+ its own behalf and/or on behalf of one or more slave devices.
+
+ P.13 The protocol MUST support a spectrum usage message
+ acknowledgment.
+
+ P.14 The protocol MUST support a validation request from the master
+ device to the database to validate a slave device, which should
+ include information necessary to identify the slave device to
+ the database.
+
+ P.15 The protocol MUST support a validation response from the
+ database to the master to indicate if the slave device is
+ validated by the database. The validation response MUST
+ indicate the success or failure of the validation request.
+
+
+
+
+
+Mancuso, et al. Informational [Page 18]
+
+RFC 6953 PAWS Use Cases and Requirements May 2013
+
+
+ P.16 The protocol MUST support the capability for the database to
+ inform master devices of changes to spectrum availability
+ information.
+
+5.3. Operational Requirements
+
+ This section contains operational requirements of a database-device
+ system, independent of the requirements of the protocol for
+ communication between the database and devices.
+
+ O.1 The master device must be able to connect to the database to
+ send requests to the database and receive responses to, and
+ acknowledgments of, its requests from the database.
+
+ O.2 A master device MUST be able to determine its location including
+ uncertainty and confidence level. A fixed master device may use
+ a location programmed at installation.
+
+ O.3 The master device MUST be configured to understand and comply
+ with the requirements of the rule set of the regulatory body
+ that apply to its operation at its location.
+
+ O.4 A master device MUST query the database for the available
+ spectrum at a specified location before starting radio
+ transmission in white space at that location.
+
+ O.5 A master device MUST be able to query the database for the
+ available spectrum on behalf of a slave device at a specified
+ location before the slave device starts radio transmission in
+ white space at that location.
+
+ O.6 The database MUST respond to an available spectrum request.
+
+5.4. Guidelines
+
+ White-space technology itself is expected to evolve and include
+ attributes such as coexistence 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:
+
+ 1. The data model SHOULD provide a modular design separating
+ messaging-specific, administrative-specific, and spectrum-
+ specific parts into distinct modules.
+
+ 2. The protocol SHOULD support determination of which
+ administrative-specific and spectrum-specific modules are used.
+
+
+
+Mancuso, et al. Informational [Page 19]
+
+RFC 6953 PAWS Use Cases and Requirements May 2013
+
+
+6. Security Considerations
+
+ PAWS is a protocol whereby a master device requests a schedule of
+ available spectrum at its location (or the location of its slave
+ devices) before it (or 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:
+
+ Assumptions:
+
+ The link between the master device and the database can be
+ wired or wireless and provides IP connectivity. It is assumed
+ that an attacker has full access to the network medium between
+ the master device and the database. The attacker may be able
+ to eavesdrop on any communications between these entities.
+
+ Threat 1: User modifies a device to masquerade as another valid
+ certified device
+
+ A master device identifies itself to the database in order to
+ obtain information about available spectrum. Without suitable
+ protection mechanisms, devices can listen to registration
+ exchanges and later register with the database by claiming the
+ identity of another device.
+
+ Threat 2: Spoofed database
+
+ A master device attempts to discover a database (or databases)
+ that it can query for available spectrum information. An
+ attacker may attempt to spoof a database and provide responses
+ to a master device that are malicious and result in the master
+ device causing interference to the primary user of the
+ spectrum.
+
+ Threat 3: Modifying or jamming a query request
+
+ An attacker may modify or jam the query request sent by a
+ master device to a database. The attacker may change the
+ location of the device or its capabilities (transmit power,
+ antenna height, etc.), and, as a result, the database responds
+ with incorrect information about available spectrum or maximum
+
+
+
+Mancuso, et al. Informational [Page 20]
+
+RFC 6953 PAWS Use Cases and Requirements May 2013
+
+
+ transmit power allowed. The result of such an attack is that
+ the master device can cause interference to the primary user of
+ the spectrum. It may also result in a denial of service to the
+ master device if the modified database response indicates that
+ no channels are available to the master device or when a jammed
+ query prevents the request from reaching the database.
+
+ Threat 4: Modifying or jamming a query response
+
+ An attacker may modify or jam the query response sent by the
+ database to a master device. For example, an attacker may
+ modify the available spectrum or power-level information
+ carried in the database response. As a result, a master device
+ may use spectrum that is not available at a location or may
+ transmit at a greater power level than allowed. Such
+ unauthorized use can result in interference to the primary user
+ of that spectrum. Alternatively, an attacker may modify a
+ database response to indicate that no spectrum is available at
+ a location (or jam the response), resulting in a denial of
+ service to the master device.
+
+ Threat 5: Third-party tracking of white-space device location and
+ identity
+
+ A master device may provide its identity in addition to its
+ location in the query request. Such location/identity
+ information can be gleaned by an eavesdropper and used for
+ unauthorized tracking purposes.
+
+ Threat 6: Malicious individual acts as a database to terminate or
+ unfairly limit spectrum access of devices
+
+ A database may include a mechanism by which service and
+ spectrum allocated to a master device can be revoked by sending
+ a revoke message to a master device. A malicious user can
+ pretend to be a database and send a revoke message to that
+ device. This results in denial of service to the master
+ device.
+
+ The security requirements arising from the above threats are captured
+ in the requirements of Section 5.2.
+
+
+
+
+
+
+
+
+
+
+Mancuso, et al. Informational [Page 21]
+
+RFC 6953 PAWS Use Cases and Requirements May 2013
+
+
+7. Acknowledgments
+
+ 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.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [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,
+ <http://earth-info.nga.mil/GandG/publications/tr8350.2/
+ wgs84fin.pdf>.
+
+8.2. Informative References
+
+ [CRADIO] Cognitive Radio Technologies Proceeding (CRTP), "Federal
+ Communications Commission", ET Docket No. 03-108,
+ August 2010, <http://fcc.gov/oet/cognitiveradio>.
+
+ [PAWS] Chen, V., Ed., Das, S., Zhu, L., Malyar, J., and P.
+ McCann, "Protocol to Access Spectrum Database", Work
+ in Progress, May 2013.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mancuso, et al. Informational [Page 22]
+
+RFC 6953 PAWS Use Cases and Requirements May 2013
+
+
+Authors' Addresses
+
+ Anthony Mancuso (editor)
+ Google
+ 1600 Amphitheatre Parkway
+ Mountain View, CA 94043
+ US
+
+ EMail: amancuso@google.com
+
+
+ Scott Probasco
+
+ EMail: scott@probasco.me
+
+
+ Basavaraj Patil
+ Cisco Systems
+ 2250 East President George Bush Highway
+ Richardson, TX 75082
+ US
+
+ EMail: basavpat@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mancuso, et al. Informational [Page 23]
+