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
AbstractPortions 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.
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. 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
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]).
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. RFC2119].
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.
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.
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.
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.
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.
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;
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. 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.
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
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. 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
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.
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.
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.
P.16 The protocol MUST support the capability for the database to inform master devices of changes to spectrum availability information.
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.
[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>. [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.