RFC 7545
Protocol to Access White-Space (PAWS) Databases
Pages: 90
Proposed Standard
Proposed Standard
Part 1 of 4 – Pages 1 to 9
Internet Engineering Task Force (IETF) V. Chen, Ed. Request for Comments: 7545 Google Category: Standards Track S. Das ISSN: 2070-1721 Applied Communication Sciences L. Zhu Huawei J. Malyar iconectiv P. McCann Huawei May 2015 Protocol to Access White-Space (PAWS) DatabasesAbstract
Portions of the radio spectrum that are allocated to licensees are available for non-interfering use. This available spectrum is called "white space". Allowing secondary users access to available spectrum "unlocks" existing spectrum to maximize its utilization and to provide opportunities for innovation, resulting in greater overall spectrum utilization. One approach to managing spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White-Space (PAWS) Databases". Status of This Memo This is an Internet Standards Track document. 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). Further information on Internet Standards is available in 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/rfc7545.
Copyright Notice Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 2.1. Conventions Used in This Document . . . . . . . . . . . . 5 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Multi-ruleset Support . . . . . . . . . . . . . . . . . . 8 4. Protocol Functionalities . . . . . . . . . . . . . . . . . . 9 4.1. Database Discovery . . . . . . . . . . . . . . . . . . . 11 4.1.1. Preconfiguration . . . . . . . . . . . . . . . . . . 11 4.1.2. Configuration Update: Database URI Changes . . . . . 11 4.1.3. Error Handling . . . . . . . . . . . . . . . . . . . 12 4.2. PAWS Version . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Initialization . . . . . . . . . . . . . . . . . . . . . 12 4.3.1. INIT_REQ . . . . . . . . . . . . . . . . . . . . . . 13 4.3.2. INIT_RESP . . . . . . . . . . . . . . . . . . . . . . 14 4.4. Device Registration . . . . . . . . . . . . . . . . . . . 15 4.4.1. REGISTRATION_REQ . . . . . . . . . . . . . . . . . . 16 4.4.2. REGISTRATION_RESP . . . . . . . . . . . . . . . . . . 17 4.5. Available Spectrum Query . . . . . . . . . . . . . . . . 18 4.5.1. AVAIL_SPECTRUM_REQ . . . . . . . . . . . . . . . . . 21 4.5.2. AVAIL_SPECTRUM_RESP . . . . . . . . . . . . . . . . . 23 4.5.3. AVAIL_SPECTRUM_BATCH_REQ . . . . . . . . . . . . . . 26 4.5.4. AVAIL_SPECTRUM_BATCH_RESP . . . . . . . . . . . . . . 28 4.5.5. SPECTRUM_USE_NOTIFY . . . . . . . . . . . . . . . . . 29 4.5.6. SPECTRUM_USE_RESP . . . . . . . . . . . . . . . . . . 31 4.6. Device Validation . . . . . . . . . . . . . . . . . . . . 31 4.6.1. DEV_VALID_REQ . . . . . . . . . . . . . . . . . . . . 32 4.6.2. DEV_VALID_RESP . . . . . . . . . . . . . . . . . . . 33 5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 34 5.1. GeoLocation . . . . . . . . . . . . . . . . . . . . . . . 34 5.2. DeviceDescriptor . . . . . . . . . . . . . . . . . . . . 37 5.3. AntennaCharacteristics . . . . . . . . . . . . . . . . . 38 5.4. DeviceCapabilities . . . . . . . . . . . . . . . . . . . 39 5.5. DeviceOwner . . . . . . . . . . . . . . . . . . . . . . . 39 5.6. RulesetInfo . . . . . . . . . . . . . . . . . . . . . . . 40 5.7. DbUpdateSpec . . . . . . . . . . . . . . . . . . . . . . 41 5.8. DatabaseSpec . . . . . . . . . . . . . . . . . . . . . . 42 5.9. SpectrumSpec . . . . . . . . . . . . . . . . . . . . . . 42 5.10. SpectrumSchedule . . . . . . . . . . . . . . . . . . . . 44 5.11. Spectrum . . . . . . . . . . . . . . . . . . . . . . . . 44 5.12. SpectrumProfile . . . . . . . . . . . . . . . . . . . . . 50 5.13. FrequencyRange . . . . . . . . . . . . . . . . . . . . . 51 5.14. EventTime . . . . . . . . . . . . . . . . . . . . . . . . 51 5.15. GeoSpectrumSpec . . . . . . . . . . . . . . . . . . . . . 52 5.16. DeviceValidity . . . . . . . . . . . . . . . . . . . . . 53
5.17. Error Element . . . . . . . . . . . . . . . . . . . . . . 53
5.17.1. OUTSIDE_COVERAGE Error . . . . . . . . . . . . . . . 55
5.17.2. DATABASE_CHANGE Error . . . . . . . . . . . . . . . 56
5.17.3. MISSING Error . . . . . . . . . . . . . . . . . . . 56
6. Message Encoding . . . . . . . . . . . . . . . . . . . . . . 57
6.1. JSON-RPC Binding . . . . . . . . . . . . . . . . . . . . 57
6.1.1. Method Names . . . . . . . . . . . . . . . . . . . . 59
6.1.2. JSON Encoding of Data Models . . . . . . . . . . . . 59
6.2. Example Encoding: spectrum.paws.init Method . . . . . . . 61
6.3. Example Encoding: spectrum.paws.getSpectrum Method . . . 62
6.4. Example Encoding: DeviceOwner vCard . . . . . . . . . . . 66
7. HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . . . 66
8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 68
8.1. Defining Ruleset Identifiers . . . . . . . . . . . . . . 68
8.2. Defining New Message Parameters . . . . . . . . . . . . . 69
8.3. Defining Additional Error Codes . . . . . . . . . . . . . 69
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69
9.1. PAWS Ruleset ID Registry . . . . . . . . . . . . . . . . 70
9.1.1. Registration Template . . . . . . . . . . . . . . . . 70
9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 72
9.2. PAWS Parameters Registry . . . . . . . . . . . . . . . . 78
9.2.1. Registration Template . . . . . . . . . . . . . . . . 78
9.2.2. Initial Registry Contents . . . . . . . . . . . . . . 78
9.3. PAWS Error Code Registry . . . . . . . . . . . . . . . . 80
9.3.1. Registration Template . . . . . . . . . . . . . . . . 81
9.3.2. Initial Registry Contents . . . . . . . . . . . . . . 81
10. Security Considerations . . . . . . . . . . . . . . . . . . . 81
10.1. Assurance of Proper Database . . . . . . . . . . . . . . 83
10.2. Protection against Modification . . . . . . . . . . . . 84
10.3. Protection against Eavesdropping . . . . . . . . . . . . 84
10.4. Client Authentication Considerations . . . . . . . . . . 84
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 85
11.1. Normative References . . . . . . . . . . . . . . . . . . 85
11.2. Informative References . . . . . . . . . . . . . . . . . 86
Appendix A. Database Listing Server Support . . . . . . . . . . 88
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 89
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 90
1. Introduction
This section provides some high-level introductory material. Readers are strongly encouraged to read "Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements" [RFC6953] for use cases, requirements, and additional background. A geospatial database can track available spectrum (in accordance with the rules of one or more regulatory domains) and make this information available to devices. This approach shifts the complexity of spectrum-policy conformance out of the device and into the database. This approach also simplifies adoption of policy changes, limiting updates to a handful of databases, rather than numerous devices. It opens the door for innovations in spectrum management that can incorporate a variety of parameters, including user location and time. In the future, it also can include other parameters, such as user priority, signal type and power, spectrum supply and demand, payment or micro-auction bidding, and more. In providing this service, a database records and updates information necessary to protect primary users -- for example, this information may include parameters such as a fixed transmitter's call sign, its geolocation, antenna height, power, and periods of operation. The rules that the database is required to follow, including its schedule for obtaining and updating protection information, protection rules, and information reported to devices, vary according to regulatory domain. Such variations, however, should be handled by each database and hidden from devices to the maximum extent possible. This specification defines an extensible protocol, built on top of HTTP and TLS, to obtain available spectrum from a geospatial database by a device with geolocation capability. It enables a device to operate in a regulatory domain that implements this protocol.2. Conventions and Terminology
2.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
2.2. Terminology
Database or Spectrum 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 ID: An identifier for a device. EIRP: Effective Isotropically Radiated Power ETSI: European Telecommunications Standards Institute (http://www.etsi.org) FCC: The U.S. Federal Communications Commission (http://www.fcc.gov) Listing server: A server that provides the URIs for one or more Spectrum Databases. A regulator, for example, may operate a Database Listing Server to publish the list of authorized Spectrum Databases for its regulatory domain. 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. Regulatory Domain: A location where certain rules apply to the use of white-space spectrum, including the operation of Databases and devices involved in its use. A regulatory domain is normally defined by a unit of government for a particular country, but PAWS is agnostic as to how a regulatory domain is constructed. Ruleset: A ruleset represents a set of rules that governs the operation of white-space devices and Spectrum Databases. A regulatory authority can define its own set of rules or adopt an existing ruleset. When a Database or device is said to "support a ruleset", it means that it contains out-of-band knowledge of the rules and that its hardware and software implementations conform to those rules. Ruleset Identifier: A ruleset can be identified by an IANA- registered identifier (see PAWS Ruleset ID Registry (Section 9.1)). When a Database or device indicates it supports a ruleset identifier, it means that it conforms to the rules associated with that identifier. A regulatory authority can define and register its own ruleset identifiers, or it can use a previously registered identifier if it adopts an existing ruleset.
Slave Device: A device that queries the Database through a master
device.
3. Protocol Overview
A Master Device uses PAWS to obtain a schedule of available spectrum
at its location. The security necessary to ensure the accuracy,
privacy, and confidentiality of the device's location is described in
the Security Considerations (Section 10). This document assumes that
the Master Device and the Database are connected to the Internet.
A typical sequence of PAWS operations is outlined as follows. See
"Protocol Functionalities" (Section 4) and "Protocol Parameters"
(Section 5) for details:
1. The Master Device obtains (statically or dynamically) the URI
for a Database appropriate for its location, to which to send
subsequent PAWS messages.
2. The Master Device establishes an HTTPS session with the
Database.
3. The Master Device optionally sends an initialization message to
the Database to exchange capabilities.
4. If the Database receives an initialization message, it responds
with an initialization-response message in the body of the HTTP
response.
5. The Database may require the Master Device to be registered
before providing service.
6. The Master Device sends an available-spectrum request message to
the Database. The message may be on behalf of a Slave Device
that made a request to the Master Device.
7. If the Master Device is making a request on behalf of a Slave
Device, the Master Device may verify with the Database that the
Slave Device is permitted to operate.
8. The Database responds with an available-spectrum response
message in the body of the HTTP response.
9. The Master Device may send a spectrum-usage notification message
to the Database. The notification is purely informational; it
notifies the Database what spectrum the Master Device intends to
use and is not a request to the Database to get permission to
use that spectrum. Some Databases may require spectrum-usage
notification.
10. If the Database receives a spectrum-usage notification message,
it responds by sending the Master Device a spectrum-usage
acknowledgement message. Since the notification is purely
informational, the Master Device does not need to process the
database response.
Different regulatory domains may impose particular requirements, such
as requiring Master Devices to register with the Database, performing
Slave Device verification, and sending spectrum-usage notifications.
3.1. Multi-ruleset Support
For a Master Device that supports multiple rulesets and operates with
multiple Databases, PAWS supports the following sequence of
operations for each request by the Master Device:
1. The Master Device includes in its request its location and
optionally includes the identifier of all the rulesets it
supports and any parameter values it might need for the request.
2. The Database uses the device location and also may use the
ruleset list to determine its response, for example, to select
the list of required parameters.
3. If required parameters are missing from the request, the Database
responds with an error and a list of names of the missing
parameters.
4. The Master Device makes the request again, adding the missing
parameter values.
5. The Database responds to the request, including the identifier of
the applicable ruleset.
6. The Master Device uses the indicated ruleset to determine how to
interpret the database response.
NOTE: Some regulatory domains specify sets of requirements for device
behavior that may be complex and not easily parameterized. The
ruleset-id parameter provides a mechanism for the Database to inform
the Master Device of an applicable ruleset, and, for devices with
out-of-band knowledge of the particular regulatory domain requirements, to satisfy those requirements without having to specify the device-side behavior within the protocol. Ruleset identifiers will normally contain the name of the regulatory body that established the rules and version information, such as "FccTvBandWhiteSpace-2010". By separating the regulatory "authority" from the "ruleset-id", it allows the protocol to support multiple regulatory authorities that use the same device-side ruleset. It also allows support for a single authority to define multiple rulesets.
(page 9 continued on part 2)