draft-ietf-paws-protocol-20.txt   rfc7545.txt 
PAWS V. Chen, Ed. Internet Engineering Task Force (IETF) V. Chen, Ed.
Internet-Draft Google Request for Comments: 7545 Google
Intended status: Standards Track S. Das Category: Standards Track S. Das
Expires: May 15, 2015 Applied Communication Sciences ISSN: 2070-1721 Applied Communication Sciences
L. Zhu L. Zhu
Huawei Huawei
J. Malyar J. Malyar
iconectiv iconectiv
P. McCann P. McCann
Huawei Huawei
November 11, 2014 May 2015
Protocol to Access White-Space (PAWS) Databases Protocol to Access White-Space (PAWS) Databases
draft-ietf-paws-protocol-20
Abstract Abstract
Portions of the radio spectrum that are allocated to licensees are Portions of the radio spectrum that are allocated to licensees are
available for non-interfering use. This available spectrum is called available for non-interfering use. This available spectrum is called
"White Space." Allowing secondary users access to available spectrum "white space". Allowing secondary users access to available spectrum
"unlocks" existing spectrum to maximize its utilization and to "unlocks" existing spectrum to maximize its utilization and to
provide opportunities for innovation, resulting in greater overall provide opportunities for innovation, resulting in greater overall
spectrum utilization. spectrum utilization.
One approach to managing spectrum sharing uses databases to report One approach to managing spectrum sharing uses databases to report
spectrum availability to devices. To achieve interoperability among spectrum availability to devices. To achieve interoperability among
multiple devices and databases, a standardized protocol must be multiple devices and databases, a standardized protocol must be
defined and implemented. This document defines such a protocol, the defined and implemented. This document defines such a protocol, the
"Protocol to Access White Space (PAWS) Databases". "Protocol to Access White-Space (PAWS) Databases".
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on May 15, 2015. 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 Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
2.1. Conventions Used in This Document . . . . . . . . . . . . 5 2.1. Conventions Used in This Document . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Multi-ruleset Support . . . . . . . . . . . . . . . . . . 7 3.1. Multi-ruleset Support . . . . . . . . . . . . . . . . . . 8
4. Protocol Functionalities . . . . . . . . . . . . . . . . . . 8 4. Protocol Functionalities . . . . . . . . . . . . . . . . . . 9
4.1. Database Discovery . . . . . . . . . . . . . . . . . . . 10 4.1. Database Discovery . . . . . . . . . . . . . . . . . . . 11
4.2. PAWS Version . . . . . . . . . . . . . . . . . . . . . . 11 4.1.1. Preconfiguration . . . . . . . . . . . . . . . . . . 11
4.3. Initialization . . . . . . . . . . . . . . . . . . . . . 11 4.1.2. Configuration Update: Database URI Changes . . . . . 11
4.3.1. INIT_REQ . . . . . . . . . . . . . . . . . . . . . . 12 4.1.3. Error Handling . . . . . . . . . . . . . . . . . . . 12
4.3.2. INIT_RESP . . . . . . . . . . . . . . . . . . . . . . 13 4.2. PAWS Version . . . . . . . . . . . . . . . . . . . . . . 12
4.4. Device Registration . . . . . . . . . . . . . . . . . . . 14 4.3. Initialization . . . . . . . . . . . . . . . . . . . . . 12
4.4.1. REGISTRATION_REQ . . . . . . . . . . . . . . . . . . 15 4.3.1. INIT_REQ . . . . . . . . . . . . . . . . . . . . . . 13
4.4.2. REGISTRATION_RESP . . . . . . . . . . . . . . . . . . 15 4.3.2. INIT_RESP . . . . . . . . . . . . . . . . . . . . . . 14
4.5. Available Spectrum Query . . . . . . . . . . . . . . . . 16 4.4. Device Registration . . . . . . . . . . . . . . . . . . . 15
4.5.1. AVAIL_SPECTRUM_REQ . . . . . . . . . . . . . . . . . 19 4.4.1. REGISTRATION_REQ . . . . . . . . . . . . . . . . . . 16
4.5.2. AVAIL_SPECTRUM_RESP . . . . . . . . . . . . . . . . . 21 4.4.2. REGISTRATION_RESP . . . . . . . . . . . . . . . . . . 17
4.5.3. AVAIL_SPECTRUM_BATCH_REQ . . . . . . . . . . . . . . 24 4.5. Available Spectrum Query . . . . . . . . . . . . . . . . 18
4.5.4. AVAIL_SPECTRUM_BATCH_RESP . . . . . . . . . . . . . . 27 4.5.1. AVAIL_SPECTRUM_REQ . . . . . . . . . . . . . . . . . 21
4.5.5. SPECTRUM_USE_NOTIFY . . . . . . . . . . . . . . . . . 28 4.5.2. AVAIL_SPECTRUM_RESP . . . . . . . . . . . . . . . . . 23
4.5.6. SPECTRUM_USE_RESP . . . . . . . . . . . . . . . . . . 29 4.5.3. AVAIL_SPECTRUM_BATCH_REQ . . . . . . . . . . . . . . 26
4.6. Device Validation . . . . . . . . . . . . . . . . . . . . 30 4.5.4. AVAIL_SPECTRUM_BATCH_RESP . . . . . . . . . . . . . . 28
4.6.1. DEV_VALID_REQ . . . . . . . . . . . . . . . . . . . . 31 4.5.5. SPECTRUM_USE_NOTIFY . . . . . . . . . . . . . . . . . 29
4.6.2. DEV_VALID_RESP . . . . . . . . . . . . . . . . . . . 32 4.5.6. SPECTRUM_USE_RESP . . . . . . . . . . . . . . . . . . 31
5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 32 4.6. Device Validation . . . . . . . . . . . . . . . . . . . . 31
5.1. GeoLocation . . . . . . . . . . . . . . . . . . . . . . . 32 4.6.1. DEV_VALID_REQ . . . . . . . . . . . . . . . . . . . . 32
5.2. DeviceDescriptor . . . . . . . . . . . . . . . . . . . . 35 4.6.2. DEV_VALID_RESP . . . . . . . . . . . . . . . . . . . 33
5.3. AntennaCharacteristics . . . . . . . . . . . . . . . . . 36 5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 34
5.4. DeviceCapabilities . . . . . . . . . . . . . . . . . . . 37 5.1. GeoLocation . . . . . . . . . . . . . . . . . . . . . . . 34
5.5. DeviceOwner . . . . . . . . . . . . . . . . . . . . . . . 37 5.2. DeviceDescriptor . . . . . . . . . . . . . . . . . . . . 37
5.6. RulesetInfo . . . . . . . . . . . . . . . . . . . . . . . 38 5.3. AntennaCharacteristics . . . . . . . . . . . . . . . . . 38
5.7. DbUpdateSpec . . . . . . . . . . . . . . . . . . . . . . 39 5.4. DeviceCapabilities . . . . . . . . . . . . . . . . . . . 39
5.8. DatabaseSpec . . . . . . . . . . . . . . . . . . . . . . 40 5.5. DeviceOwner . . . . . . . . . . . . . . . . . . . . . . . 39
5.9. SpectrumSpec . . . . . . . . . . . . . . . . . . . . . . 40 5.6. RulesetInfo . . . . . . . . . . . . . . . . . . . . . . . 40
5.10. SpectrumSchedule . . . . . . . . . . . . . . . . . . . . 42 5.7. DbUpdateSpec . . . . . . . . . . . . . . . . . . . . . . 41
5.11. Spectrum . . . . . . . . . . . . . . . . . . . . . . . . 42 5.8. DatabaseSpec . . . . . . . . . . . . . . . . . . . . . . 42
5.12. SpectrumProfile . . . . . . . . . . . . . . . . . . . . . 46 5.9. SpectrumSpec . . . . . . . . . . . . . . . . . . . . . . 42
5.13. FrequencyRange . . . . . . . . . . . . . . . . . . . . . 47 5.10. SpectrumSchedule . . . . . . . . . . . . . . . . . . . . 44
5.14. EventTime . . . . . . . . . . . . . . . . . . . . . . . . 48 5.11. Spectrum . . . . . . . . . . . . . . . . . . . . . . . . 44
5.15. GeoSpectrumSpec . . . . . . . . . . . . . . . . . . . . . 48 5.12. SpectrumProfile . . . . . . . . . . . . . . . . . . . . . 50
5.16. DeviceValidity . . . . . . . . . . . . . . . . . . . . . 49 5.13. FrequencyRange . . . . . . . . . . . . . . . . . . . . . 51
5.17. Error Element . . . . . . . . . . . . . . . . . . . . . . 50 5.14. EventTime . . . . . . . . . . . . . . . . . . . . . . . . 51
5.17.1. OUTSIDE_COVERAGE Error . . . . . . . . . . . . . . . 52 5.15. GeoSpectrumSpec . . . . . . . . . . . . . . . . . . . . . 52
5.17.2. DATABASE_CHANGE Error . . . . . . . . . . . . . . . 52 5.16. DeviceValidity . . . . . . . . . . . . . . . . . . . . . 53
5.17.3. MISSING Error . . . . . . . . . . . . . . . . . . . 52 5.17. Error Element . . . . . . . . . . . . . . . . . . . . . . 53
6. Message Encoding . . . . . . . . . . . . . . . . . . . . . . 53 5.17.1. OUTSIDE_COVERAGE Error . . . . . . . . . . . . . . . 55
6.1. JSON-RPC Binding . . . . . . . . . . . . . . . . . . . . 53 5.17.2. DATABASE_CHANGE Error . . . . . . . . . . . . . . . 56
6.1.1. Method Names . . . . . . . . . . . . . . . . . . . . 55 5.17.3. MISSING Error . . . . . . . . . . . . . . . . . . . 56
6.1.2. JSON Encoding of Data Models . . . . . . . . . . . . 55 6. Message Encoding . . . . . . . . . . . . . . . . . . . . . . 57
6.2. Example Encoding: spectrum.paws.init Method . . . . . . . 56 6.1. JSON-RPC Binding . . . . . . . . . . . . . . . . . . . . 57
6.3. Example Encoding: spectrum.paws.getSpectrum Method . . . 57 6.1.1. Method Names . . . . . . . . . . . . . . . . . . . . 59
6.4. Example Encoding: DeviceOwner vCard . . . . . . . . . . . 61 6.1.2. JSON Encoding of Data Models . . . . . . . . . . . . 59
7. HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . . . 61 6.2. Example Encoding: spectrum.paws.init Method . . . . . . . 61
8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 63 6.3. Example Encoding: spectrum.paws.getSpectrum Method . . . 62
8.1. Defining Ruleset Identifiers . . . . . . . . . . . . . . 63 6.4. Example Encoding: DeviceOwner vCard . . . . . . . . . . . 66
8.2. Defining New Message Parameters . . . . . . . . . . . . . 64 7. HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . . . 66
8.3. Defining Additional Error Codes . . . . . . . . . . . . . 64 8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 68
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 8.1. Defining Ruleset Identifiers . . . . . . . . . . . . . . 68
9.1. PAWS Ruleset ID Registry . . . . . . . . . . . . . . . . 65 8.2. Defining New Message Parameters . . . . . . . . . . . . . 69
9.1.1. Registration Template . . . . . . . . . . . . . . . . 65 8.3. Defining Additional Error Codes . . . . . . . . . . . . . 69
9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69
9.2. PAWS Parameters Registry . . . . . . . . . . . . . . . . 73 9.1. PAWS Ruleset ID Registry . . . . . . . . . . . . . . . . 70
9.2.1. Registration Template . . . . . . . . . . . . . . . . 73 9.1.1. Registration Template . . . . . . . . . . . . . . . . 70
9.2.2. Initial Registry Contents . . . . . . . . . . . . . . 73 9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 72
9.3. PAWS Error Code Registry . . . . . . . . . . . . . . . . 75 9.2. PAWS Parameters Registry . . . . . . . . . . . . . . . . 78
9.3.1. Registration Template . . . . . . . . . . . . . . . . 76 9.2.1. Registration Template . . . . . . . . . . . . . . . . 78
9.3.2. Initial Registry Contents . . . . . . . . . . . . . . 76 9.2.2. Initial Registry Contents . . . . . . . . . . . . . . 78
10. Security Considerations . . . . . . . . . . . . . . . . . . . 76 9.3. PAWS Error Code Registry . . . . . . . . . . . . . . . . 80
10.1. Assurance of Proper Database . . . . . . . . . . . . . . 78 9.3.1. Registration Template . . . . . . . . . . . . . . . . 81
10.2. Protection Against Modification . . . . . . . . . . . . 79 9.3.2. Initial Registry Contents . . . . . . . . . . . . . . 81
10.3. Protection Against Eavesdropping . . . . . . . . . . . . 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 81
10.4. Client Authentication Considerations . . . . . . . . . . 79 10.1. Assurance of Proper Database . . . . . . . . . . . . . . 83
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 80 10.2. Protection against Modification . . . . . . . . . . . . 84
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 80 10.3. Protection against Eavesdropping . . . . . . . . . . . . 84
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 80 10.4. Client Authentication Considerations . . . . . . . . . . 84
13.1. Normative References . . . . . . . . . . . . . . . . . . 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 85
13.2. Informative References . . . . . . . . . . . . . . . . . 81 11.1. Normative References . . . . . . . . . . . . . . . . . . 85
Appendix A. Database Listing Server Support . . . . . . . . . . 82 11.2. Informative References . . . . . . . . . . . . . . . . . 86
Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 83 Appendix A. Database Listing Server Support . . . . . . . . . . 88
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 91 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 89
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 90
1. Introduction 1. Introduction
[RFC Editor: In the Author's Addresses section, please list This section provides some high-level introductory material. Readers
"iconectiv" as "iconectiv (formerly Telcordia Interconnection
Solutions). One occurrence."]
This section provides some high level introductory material. Readers
are strongly encouraged to read "Protocol to Access White-Space are strongly encouraged to read "Protocol to Access White-Space
(PAWS) Databases: Use Cases and Requirements" [RFC6953] for use (PAWS) Databases: Use Cases and Requirements" [RFC6953] for use
cases, requirements, and additional background. cases, requirements, and additional background.
A geospatial database can track available spectrum (in accordance A geospatial database can track available spectrum (in accordance
with the rules of one or more regulatory domains) and make this with the rules of one or more regulatory domains) and make this
information available to devices. This approach shifts the information available to devices. This approach shifts the
complexity of spectrum-policy conformance out of the device and into complexity of spectrum-policy conformance out of the device and into
the database. This approach also simplifies adoption of policy the database. This approach also simplifies adoption of policy
changes, limiting updates to a handful of databases, rather than changes, limiting updates to a handful of databases, rather than
skipping to change at page 4, line 37 skipping to change at page 5, line 31
parameters, such as user priority, signal type and power, spectrum parameters, such as user priority, signal type and power, spectrum
supply and demand, payment or micro-auction bidding, and more. supply and demand, payment or micro-auction bidding, and more.
In providing this service, a database records and updates information In providing this service, a database records and updates information
necessary to protect primary users -- for example, this information necessary to protect primary users -- for example, this information
may include parameters such as a fixed transmitter's call sign, its may include parameters such as a fixed transmitter's call sign, its
geolocation, antenna height, power, and periods of operation. The geolocation, antenna height, power, and periods of operation. The
rules that the database is required to follow, including its schedule rules that the database is required to follow, including its schedule
for obtaining and updating protection information, protection rules, for obtaining and updating protection information, protection rules,
and information reported to devices, vary according to regulatory and information reported to devices, vary according to regulatory
domain. Such variations, however, should be handled by each domain. Such variations, however, should be handled by each database
database, and hidden from devices to the maximum extent possible. and hidden from devices to the maximum extent possible.
This specification defines an extensible protocol, built on top of This specification defines an extensible protocol, built on top of
HTTP and TLS, to obtain available spectrum from a geospatial database HTTP and TLS, to obtain available spectrum from a geospatial database
by a device with geolocation capability. It enables a device to by a device with geolocation capability. It enables a device to
operate in a regulatory domain that implements this protocol and operate in a regulatory domain that implements this protocol.
within which the device operates.
2. Conventions and Terminology 2. Conventions and Terminology
2.1. Conventions Used in This Document 2.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in "Key words for use in document are to be interpreted as described in "Key words for use in
RFCs to Indicate Requirement Levels" [RFC2119]. RFCs to Indicate Requirement Levels" [RFC2119].
2.2. Terminology 2.2. Terminology
Database or Spectrum Database: A database is an entity that contains Database or Spectrum Database: A Database is an entity that contains
current information about available spectrum at a given location current information about available spectrum at a given location
and time, as well as other types of information related to and time, as well as other types of information related to
spectrum availability and usage. spectrum availability and usage.
Device ID: An identifier for a device. Device ID: An identifier for a device.
EIRP: Effective isotropically radiated power EIRP: Effective Isotropically Radiated Power
ETSI: European Telecommunications Standards Institute ETSI: European Telecommunications Standards Institute
(http://www.etsi.org) (http://www.etsi.org)
FCC: The U.S. Federal Communications Commission FCC: The U.S. Federal Communications Commission
(http://www.fcc.gov) (http://www.fcc.gov)
Listing server: A server that provides the URIs for one or more Listing server: A server that provides the URIs for one or more
Spectrum Databases. A regulator, for example, may operate a Spectrum Databases. A regulator, for example, may operate a
Database Listing Server to publish the list of authorized Spectrum Database Listing Server to publish the list of authorized Spectrum
Databases for its regulatory domain. Databases for its regulatory domain.
Master Device: A device that queries the database, on its own behalf Master Device: A device that queries the Database, on its own behalf
and/or on behalf of a slave device, to obtain available spectrum and/or on behalf of a slave device, to obtain available spectrum
information. information.
Regulatory Domain: A location where certain rules apply to the use Regulatory Domain: A location where certain rules apply to the use
of white space spectrum, including the operation of databases and of white-space spectrum, including the operation of Databases and
devices involved in its use. A regulatory domain is normally devices involved in its use. A regulatory domain is normally
defined by a unit of government for a particular country, but PAWS defined by a unit of government for a particular country, but PAWS
is agnostic as to how a regulatory domain is constructed. is agnostic as to how a regulatory domain is constructed.
Ruleset: A ruleset represents a set of rules that governs the Ruleset: A ruleset represents a set of rules that governs the
operation of white space devices and Spectrum Databases. A operation of white-space devices and Spectrum Databases. A
regulatory authority can define its own set of rules or adopt an regulatory authority can define its own set of rules or adopt an
existing ruleset. When a Database or device is said to "support a existing ruleset. When a Database or device is said to "support a
ruleset", it means that it contains out-of-band knowledge of the ruleset", it means that it contains out-of-band knowledge of the
rules and that its hardware and software implementations conform rules and that its hardware and software implementations conform
to those rules. to those rules.
Ruleset Identifier: A ruleset can be identified by an IANA- Ruleset Identifier: A ruleset can be identified by an IANA-
registered identifier (see PAWS Ruleset ID Registry registered identifier (see PAWS Ruleset ID Registry
(Section 9.1)). When a Database or device indicates it supports a (Section 9.1)). When a Database or device indicates it supports a
ruleset identifier, it means that it conforms to the rules ruleset identifier, it means that it conforms to the rules
associated with that identifier. A regulatory authority can associated with that identifier. A regulatory authority can
define and register its own ruleset identifiers, or it can use a define and register its own ruleset identifiers, or it can use a
previously registered identifier if it adopts an existing ruleset. previously registered identifier if it adopts an existing ruleset.
Slave Device: A device that queries the database through a master Slave Device: A device that queries the Database through a master
device. device.
3. Protocol Overview 3. Protocol Overview
A Master Device uses PAWS to obtain a schedule of available spectrum A Master Device uses PAWS to obtain a schedule of available spectrum
at its location. The security necessary to ensure the accuracy, at its location. The security necessary to ensure the accuracy,
privacy, and confidentiality of the device's location is described in privacy, and confidentiality of the device's location is described in
the Security Considerations (Section 10). This document assumes that the Security Considerations (Section 10). This document assumes that
the Master Device and the Database are connected to the Internet. the Master Device and the Database are connected to the Internet.
A typical sequence of PAWS operations is outlined as follows. See A typical sequence of PAWS operations is outlined as follows. See
Protocol Functionalities (Section 4) and Protocol Parameters "Protocol Functionalities" (Section 4) and "Protocol Parameters"
(Section 5) for details: (Section 5) for details:
1. The Master Device obtains (statically or dynamically) the URI 1. The Master Device obtains (statically or dynamically) the URI
for a Database appropriate for its location, to which to send for a Database appropriate for its location, to which to send
subsequent PAWS messages. subsequent PAWS messages.
2. The Master Device establishes an HTTPS session with the 2. The Master Device establishes an HTTPS session with the
Database. Database.
3. The Master Device optionally sends an initialization message to 3. The Master Device optionally sends an initialization message to
skipping to change at page 7, line 9 skipping to change at page 8, line 6
that made a request to the Master Device. that made a request to the Master Device.
7. If the Master Device is making a request on behalf of a Slave 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 Device, the Master Device may verify with the Database that the
Slave Device is permitted to operate. Slave Device is permitted to operate.
8. The Database responds with an available-spectrum response 8. The Database responds with an available-spectrum response
message in the body of the HTTP response. message in the body of the HTTP response.
9. The Master Device may send a spectrum-usage notification message 9. The Master Device may send a spectrum-usage notification message
to the Database. The notification is purely informational for to the Database. The notification is purely informational; it
notifying the Database what spectrum it intends to use and is notifies the Database what spectrum the Master Device intends to
not a request to the Database to get permission to use that use and is not a request to the Database to get permission to
spectrum. Some databases may require spectrum-usage use that spectrum. Some Databases may require spectrum-usage
notification. notification.
10. If the Database receives a spectrum-usage notification message, 10. If the Database receives a spectrum-usage notification message,
it responds by sending the Master Device a spectrum-usage it responds by sending the Master Device a spectrum-usage
acknowledgement message. Since the notification is purely acknowledgement message. Since the notification is purely
informational, the Master Device does not need to process the informational, the Master Device does not need to process the
Database response. database response.
Different regulatory domains may impose particular requirements, such Different regulatory domains may impose particular requirements, such
as requiring Master Devices to register with the Database, performing as requiring Master Devices to register with the Database, performing
Slave Device verification, and sending spectrum usage notifications. Slave Device verification, and sending spectrum-usage notifications.
3.1. Multi-ruleset Support 3.1. Multi-ruleset Support
For a Master Device that supports multiple rulesets and operates with For a Master Device that supports multiple rulesets and operates with
multiple databases, PAWS supports the following sequence of multiple Databases, PAWS supports the following sequence of
operations for each request by the Master Device: operations for each request by the Master Device:
1. The Master Device includes in its request its location and 1. The Master Device includes in its request its location and
optionally includes the identifier of all the rulesets it optionally includes the identifier of all the rulesets it
supports and any parameter values it might need for the request supports and any parameter values it might need for the request.
2. The Database uses the device location and also may use the 2. The Database uses the device location and also may use the
ruleset list to determine its response, for example, to select ruleset list to determine its response, for example, to select
the list of required parameters the list of required parameters.
3. If required parameters are missing from the request, the Database 3. If required parameters are missing from the request, the Database
responds with an error and a list of names of the missing responds with an error and a list of names of the missing
parameters parameters.
4. The Master Device makes the request again, adding the missing 4. The Master Device makes the request again, adding the missing
parameter values parameter values.
5. The Database responds to the request, including the identifier of 5. The Database responds to the request, including the identifier of
the applicable ruleset the applicable ruleset.
6. The Master Device uses the indicated ruleset to determine how to 6. The Master Device uses the indicated ruleset to determine how to
interpret the Database response interpret the database response.
NOTE Some regulatory domains specify sets of requirements for device NOTE: Some regulatory domains specify sets of requirements for device
behavior that may be complex and not easily parameterized. The behavior that may be complex and not easily parameterized. The
ruleset-id parameter provides a mechanism for the Database to inform ruleset-id parameter provides a mechanism for the Database to inform
the Master Device of an applicable ruleset, and, for devices with the Master Device of an applicable ruleset, and, for devices with
out-of-band knowledge of the particular regulatory domain out-of-band knowledge of the particular regulatory domain
requirements, to satisfy those requirements without having to specify requirements, to satisfy those requirements without having to specify
the device-side behavior within the protocol. Ruleset identifiers the device-side behavior within the protocol. Ruleset identifiers
will normally contain the name of the regulatory body that will normally contain the name of the regulatory body that
established the rules and version information, such as established the rules and version information, such as
"FccTvBandWhiteSpace-2010". "FccTvBandWhiteSpace-2010".
By separating the regulatory "authority" from the "ruleset-id", it By separating the regulatory "authority" from the "ruleset-id", it
allows the protocol to support multiple regulatory authorities that allows the protocol to support multiple regulatory authorities that
use the same device-side ruleset. It also allows support for a use the same device-side ruleset. It also allows support for a
single authority to define multiple rulesets. single authority to define multiple rulesets.
4. Protocol Functionalities 4. Protocol Functionalities
PAWS consists of several components. As noted below, some regulatory PAWS consists of several components. As noted below, some regulatory
domains or Database implementations may mandate the use of a domains or database implementations may mandate the use of a
component, even when its use is not mandated by PAWS. component, even when its use is not mandated by PAWS.
o Database Discovery (Section 4.1) is a required component for the o Database Discovery (Section 4.1) is a required component for the
Master Device. Master Device.
o Initialization (Section 4.3) is a required component for the o Initialization (Section 4.3) is a required component for the
Database. Its use allows the Master Device to determine necessary Database. Its use allows the Master Device to determine necessary
information that have not been preconfigured. information that has not been preconfigured.
o Device Registration (Section 4.4) is an optional component for the o Device Registration (Section 4.4) is an optional component for the
Database. It can be implemented as a separate component or as Database. It can be implemented as a separate component or as
part of the Available Spectrum Query (Section 4.5) component. It part of the Available Spectrum Query (Section 4.5) component. It
is used by the Master Device when the Database requires it. Note is used by the Master Device when the Database requires it. Note
that some regulators require device registration for only specific that some regulators require device registration for only specific
device types, such as higher-power fixed (as opposed to mobile) device types, such as higher-power fixed (as opposed to mobile)
devices to allow them to contact the operators to resolve any devices, to allow them to contact the operators to resolve any
interference issues. interference issues.
o Available Spectrum Query (Section 4.5) is a required component for o Available Spectrum Query (Section 4.5) is a required component for
the Master Device and the Database. the Master Device and the Database.
o Spectrum Use Notify (Section 4.5.5) is an optional component for o Spectrum Use Notify (Section 4.5.5) is an optional component for
the Master Device and the Database. When it is required, the the Master Device and the Database. When it is required, the
Database informs the Master Device via its response to the Database informs the Master Device via its response to the
Available Spectrum Query (Section 4.5). Available Spectrum Query (Section 4.5).
o Device Validation (Section 4.6) as a separate component is o Device Validation (Section 4.6) as a separate component is
optional for the Master Device and Database. When implemented by optional for the Master Device and Database. When implemented by
the Database, its use allows the Master Device to validate Slave the Database, its use allows the Master Device to validate Slave
Devices without having to use the full Available Spectrum Query. Devices without having to use the full Available Spectrum Query.
This section describes the protocol components and their messages. This section describes the protocol components and their messages.
Protocol Parameters (Section 5) contains a more thorough discussion "Protocol Parameters" (Section 5) contains a more thorough discussion
of the parameters that make up the PAWS request and response of the parameters that make up the PAWS request and response
messages. Message Encoding (Section 6) provides examples of message messages. "Message Encoding" (Section 6) provides examples of
encodings. HTTPS Binding (Section 7) describes the use of HTTPS message encodings. "HTTPS Binding" (Section 7) describes the use of
("HTTP Over TLS" [RFC2818]) for transferring PAWS messages and HTTPS ("HTTP Over TLS" [RFC2818]) for transferring PAWS messages and
optional device authentication. optional device authentication.
The parameter tables in this section and Protocol Parameters The parameter tables in this section and "Protocol Parameters"
(Section 5) are for reference and contain the name of each parameter, (Section 5) are for reference and contain the name of each parameter,
the data type of each parameter, and whether the existence of the the data type of each parameter, and whether the existence of the
parameter is required for the protocol transaction in question. The parameter is required for the protocol transaction in question. The
diagrams are loosely based on UML, and the data types are defined diagrams are loosely based on the Unified Modeling Language (UML),
either in Protocol Parameters (Section 5) or are one of the following and the data types are defined either in "Protocol Parameters"
primitive or structured types: (Section 5) or are one of the following primitive or structured
types:
string: A string, as defined by JSON [RFC7159], restricted to the string: A string, as defined by JSON [RFC7159], restricted to the
UTF-8 encoding. UTF-8 encoding.
int: A number, as defined by JSON [RFC7159], without a fractional or int: A number, as defined by JSON [RFC7159], without a fractional or
exponent part. exponent part.
float: A number, as defined by JSON [RFC7159]. float: A number, as defined by JSON [RFC7159].
boolean: A boolean, as defined by JSON [RFC7159]. boolean: A boolean, as defined by JSON [RFC7159].
skipping to change at page 9, line 51 skipping to change at page 10, line 50
o All parameter names are case sensitive. Unless stated otherwise, o All parameter names are case sensitive. Unless stated otherwise,
all string values are case sensitive. all string values are case sensitive.
o All timestamps are in UTC and are expressed using exactly the o All timestamps are in UTC and are expressed using exactly the
form, YYYY-MM-DDThh:mm:ssZ, as defined by "Date and Time on the form, YYYY-MM-DDThh:mm:ssZ, as defined by "Date and Time on the
Internet: Timestamps" [RFC3339]. Internet: Timestamps" [RFC3339].
In some cases, specific rulesets may place additional requirements on In some cases, specific rulesets may place additional requirements on
message parameters. These additional requirements will be documented message parameters. These additional requirements will be documented
in the IANA PAWS Ruleset ID Registry. (Section 9.1). When a request in the IANA PAWS Ruleset ID Registry (Section 9.1). When a request
message sent to the Database has missing parameters, whether they are message sent to the Database has missing parameters, whether they are
required by PAWS or the applicable ruleset, the Database returns the required by PAWS or the applicable ruleset, the Database returns the
MISSING (Section 5.17.3) error, along with data indicating the MISSING error (see Section 5.17.3), along with data indicating the
missing parameters. missing parameters.
4.1. Database Discovery 4.1. Database Discovery
Preconfiguration 4.1.1. Preconfiguration
The Master Device can be provisioned statically (preconfigured) with The Master Device can be provisioned statically (preconfigured) with
the URI of one or more Databases. For example, in a particular the URI of one or more Databases. For example, in a particular
regulatory domain, there may be a number of certified Databases that regulatory domain, there may be a number of certified Databases that
any device operating in that domain is permitted to connect to, and any device operating in that domain is permitted to connect to, and
those URIs can be preconfigured in the device. those URIs can be preconfigured in the device.
Listing Server Support: As an alternative to preconfiguring devices Listing Server Support: As an alternative to preconfiguring devices
with a list of certified Databases, some regulatory domains support with a list of certified Databases, some regulatory domains support
the preconfiguration of devices with the URI of a certified listing the preconfiguration of devices with the URI of a certified listing
server, to which devices can connect to obtain the list of certified server, to which devices can connect to obtain the list of certified
Databases. See Listing Server Support (Appendix A) for further Databases. See "Database Listing Server Support" (Appendix A) for
information. further information.
Configuration Update: Database URI changes 4.1.2. Configuration Update: Database URI Changes
To adapt to changes in the list of certified or approved databases, To adapt to changes in the list of certified or approved Databases,
the device needs to update its preconfigured list of databases. the device needs to update its preconfigured list of Databases.
A Database MAY change its URI, but before it changes its URI, it MUST A Database MAY change its URI, but before it changes its URI, it MUST
indicate so by including the URI of one or more alternate databases indicate the upcoming change by including the URI of one or more
using DbUpdateSpec (Section 5.7) in its responses to devices. The alternate Databases using DbUpdateSpec (Section 5.7) in its responses
Database MUST reply with DbUpdateSpec for a minimum of 2 weeks before to devices. The Database MUST reply with DbUpdateSpec for a minimum
disabling the old URI. A device will update its preconfigured entry of 2 weeks before disabling the old URI. A device will update its
for the Database sending the DbUpdateSpec by replacing this entry preconfigured entry for the Database sending the DbUpdateSpec by
with the alternate databases listed in the DbUpdateSpec; the list of replacing this entry with the alternate Databases listed in the
alternate databases does not affect any other entries. Note that the DbUpdateSpec; the list of alternate Databases does not affect any
ordering of databases in the list does not imply any preference and other entries. Note that the ordering of Databases in the list does
does not need to remain the same for every request. The device not imply any preference and does not need to remain the same for
SHOULD detect infinite redirection loops; if a suitable database every request. The device SHOULD detect infinite redirection loops;
cannot be contacted, the device MUST treat this as equivalent to a if a suitable Database cannot be contacted, the device MUST treat
response indicating no available spectrum. This database-change this as equivalent to a response indicating no available spectrum.
mechanism is used, for example, before a Database ceases operation; This database-change mechanism is used, for example, before a
it is not intended to be used for dynamic load balancing. Database ceases operation; it is not intended to be used for dynamic
load balancing.
Error Handling 4.1.3. Error Handling
The device SHOULD select another database from its list of The device SHOULD select another Database from its list of
preconfigured databases if: preconfigured Databases if:
o The selected database is unreachable or does not respond. o The selected Database is unreachable or does not respond.
o The selected database returns an UNSUPPORTED error (see Error o The selected Database returns an UNSUPPORTED error (see "Error
Codes (Section 5.17)), which indicates the database does not Codes" (Section 5.17)), which indicates the Database does not
support the device (based on its device type, model, etc.) or support the device (based on its device type, model, etc.) or
supports none of the rulesets specified in the request. supports none of the rulesets specified in the request.
If a suitable database cannot be contacted, the device MUST treat If a suitable Database cannot be contacted, the device MUST treat
this as equivalent to a response indicating no available spectrum. this as equivalent to a response indicating no available spectrum.
If the device had previously contacted a database to get available If the device had previously contacted a Database to get available
spectrum, but subsequently fails to contact a suitable database, the spectrum, but subsequently fails to contact a suitable Database, the
spectrum the device is currently using can be used for as long as the spectrum the device is currently using can be used for as long as the
spectrum data is valid; but after that period, the device will no spectrum data is valid. However, after that period, the device will
longer have valid spectrum to use. Some regulatory domains may have no longer have valid spectrum to use. Some regulatory domains may
specific rules regarding how long the spectrum data remains valid in have specific rules regarding how long the spectrum data remains
these cases. valid in these cases.
4.2. PAWS Version 4.2. PAWS Version
PAWS version uses a "<major>.<minor>" numbering scheme to indicate PAWS version uses a "<major>.<minor>" numbering scheme to indicate
versions of the protocol. The protocol versioning policy is intended versions of the protocol. The protocol versioning policy is intended
to allow the device or Database to indicate the format of a message to allow the device or Database to indicate the format of a message
and its understanding of PAWS functionality defined by that version. and its understanding of PAWS functionality defined by that version.
No change is made to the version string for the addition of message No change is made to the version string for the addition of message
components which only add to extensible parameter values. The components that only add to extensible parameter values. The <minor>
<minor> number is incremented when the changes made to the protocol number is incremented when the changes made to the protocol add
add functionalities (methods), but do not change the existing functionalities (methods) but do not change the existing
functionalities. The <major> number is incremented when incompatible functionalities. The <major> number is incremented when incompatible
changes are made to existing functionality. changes are made to existing functionality.
The current PAWS version is "1.0". The current PAWS version is "1.0".
4.3. Initialization 4.3. Initialization
A Master Device SHOULD use the initialization procedure to exchange A Master Device SHOULD use the initialization procedure to exchange
capability information with the Database whenever the Master Device capability information with the Database whenever the Master Device
powers up or initiates communication with the Database. The powers up or initiates communication with the Database. The
initialization response informs the Master Device of specific initialization response informs the Master Device of specific
parameterized-rule values for each supported ruleset, such as parameterized-rule values for each supported ruleset, such as
threshold distances and time periods beyond which the device must threshold distances and time periods beyond which the device must
update its available-spectrum data (see RuleSetInfo (Section 5.6)). update its available-spectrum data (see "RuleSetInfo" (Section 5.6)).
When parameterized-rule values are not preconfigured for the When parameterized-rule values are not preconfigured for the
applicable ruleset at the specified location, a Master Device MUST applicable ruleset at the specified location, a Master Device MUST
use the initialization procedure. use the initialization procedure.
It is important to note that, when parameterized-rule values are It is important to note that, when parameterized-rule values are
preconfigured in a Master Device, they are preconfigured on a per- preconfigured in a Master Device, they are preconfigured on a per-
ruleset basis. That is, values preconfigured for one ruleset is not ruleset basis. That is, values preconfigured for one ruleset are not
applicable to any other ruleset. applicable to any other ruleset.
For database implementations that require it, the initialization For database implementations that require it, the initialization
message also enables extra database-specific or ruleset-specific message also enables extra database-specific or ruleset-specific
handshake parameters to be communicated before allowing available- handshake parameters to be communicated before allowing available-
spectrum requests. spectrum requests.
The Initialization request procedure is depicted in Figure 1. The Initialization request procedure is depicted in Figure 1.
o INIT_REQ (Section 4.3.1) is the initialization request message o INIT_REQ (Section 4.3.1) is the initialization request message
skipping to change at page 12, line 39 skipping to change at page 13, line 46
Figure 1 Figure 1
4.3.1. INIT_REQ 4.3.1. INIT_REQ
The initialization request message allows the Master Device to The initialization request message allows the Master Device to
initiate exchange of capabilities with the Database. initiate exchange of capabilities with the Database.
+---------------------------------------+ +---------------------------------------+
|INIT_REQ | |INIT_REQ |
+----------------------------+----------| +----------------------------+----------|
|deviceDesc:DeviceDescriptor | required | |deviceDesc:DeviceDescriptor | REQUIRED |
|location:GeoLocation | required | |location:GeoLocation | REQUIRED |
|.......................................| |.......................................|
|*other:any | optional | |*other:any | OPTIONAL |
+----------------------------+----------+ +----------------------------+----------+
Parameters: Parameters:
deviceDesc: The DeviceDescriptor (Section 5.2) for the device is deviceDesc: The DeviceDescriptor (Section 5.2) for the device is
REQUIRED. If the device descriptor does not contain any ruleset REQUIRED. If the device descriptor does not contain any ruleset
IDs, the Master Device is asking the Database to return a IDs, the Master Device is asking the Database to return a
RulesetInfo (Section 5.6) list that specifies the rulesets that it RulesetInfo (Section 5.6) list that specifies the rulesets that it
supports at the specified location. supports at the specified location.
location: The GeoLocation (Section 5.1) of the device is REQUIRED. location: The GeoLocation (Section 5.1) of the device is REQUIRED.
If the location is outside all regulatory domain supported by the If the location is outside all regulatory domain supported by the
skipping to change at page 13, line 7 skipping to change at page 14, line 14
Parameters: Parameters:
deviceDesc: The DeviceDescriptor (Section 5.2) for the device is deviceDesc: The DeviceDescriptor (Section 5.2) for the device is
REQUIRED. If the device descriptor does not contain any ruleset REQUIRED. If the device descriptor does not contain any ruleset
IDs, the Master Device is asking the Database to return a IDs, the Master Device is asking the Database to return a
RulesetInfo (Section 5.6) list that specifies the rulesets that it RulesetInfo (Section 5.6) list that specifies the rulesets that it
supports at the specified location. supports at the specified location.
location: The GeoLocation (Section 5.1) of the device is REQUIRED. location: The GeoLocation (Section 5.1) of the device is REQUIRED.
If the location is outside all regulatory domain supported by the If the location is outside all regulatory domain supported by the
Database, the Database MUST respond with an OUTSIDE_COVERAGE Database, the Database MUST respond with an OUTSIDE_COVERAGE error
(Table 1) error. (see Table 1).
other: The Master Device MAY specify additional handshake parameters other: The Master Device MAY specify additional handshake parameters
in the INIT_REQ message. The Database MUST ignore all parameters in the INIT_REQ message. The Database MUST ignore all parameters
it does not understand. To simplify its initialization logic, a it does not understand. To simplify its initialization logic, a
Master Device that supports multiple Databases and rulesets can Master Device that supports multiple Databases and rulesets can
include the union of all required parameters for all its supported include the union of all required parameters for all its supported
rulesets. Consult the PAWS Parameters Registry (Section 9.2) for rulesets. Consult the PAWS Parameters Registry (Section 9.2) for
possible additional parameters. possible additional parameters.
4.3.2. INIT_RESP 4.3.2. INIT_RESP
The initialization response message communicates database parameters The initialization response message communicates database parameters
to the requesting device. This response is returned only when there to the requesting device. This response is returned only when there
is at least one ruleset. Otherwise, the Database returns an error is at least one ruleset. Otherwise, the Database returns an error
response, as described in INIT_REQ (Section 4.3.1). response, as described in INIT_REQ (Section 4.3.1).
+---------------------------------------+ +---------------------------------------+
|INIT_RESP | |INIT_RESP |
+----------------------------+----------+ 1..* +-------------+ +----------------------------+----------+ 1..* +-------------+
|rulesetInfos:list | required |------->| RulesetInfo | |rulesetInfos:list | REQUIRED |------->| RulesetInfo |
|databaseChange:DbUpdateSpec | optional | +-------------+ |databaseChange:DbUpdateSpec | OPTIONAL | +-------------+
|.......................................| |.......................................|
|*other:any | optional | |*other:any | OPTIONAL |
+----------------------------+----------+ +----------------------------+----------+
Parameters: Parameters:
rulesetInfos: A RulesetInfo (Section 5.6) list MUST be included in rulesetInfos: A RulesetInfo (Section 5.6) list MUST be included in
the response. Each RulesetInfo corresponds to a ruleset supported the response. Each RulesetInfo corresponds to a ruleset supported
by the Database and is applicable to the location specified in the by the Database and is applicable to the location specified in the
INIT_REQ (Section 4.3.1) message. INIT_REQ (Section 4.3.1) message.
If the device included a list of ruleset IDs in the If the device included a list of ruleset IDs in the
DeviceDescriptor of its INIT_REQ message, each RulesetInfo in the DeviceDescriptor of its INIT_REQ message, each RulesetInfo in the
response MUST match one of the specified ruleset IDs. response MUST match one of the specified ruleset IDs.
If the DeviceDescriptor did not contain any ruleset IDs, the If the DeviceDescriptor did not contain any ruleset IDs, the
Database SHOULD include in the rulesetInfos list a RulesetInfo for Database SHOULD include in the rulesetInfos list a RulesetInfo for
each ruleset it supports at the specified location. each ruleset it supports at the specified location.
If the Database does not support the device or supports none of If the Database does not support the device or supports none of
the rulesets specified in the DeviceDescriptor, it MUST instead the rulesets specified in the DeviceDescriptor, it MUST instead
return an error with the UNSUPPORTED (Table 1) code in the error return an error with the UNSUPPORTED code (see Table 1) in the
response. error response.
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) to notify the Master Device of a change to the (Section 5.7) to notify the Master Device of a change to the
Database URI, providing one or more alternate database URIs. The database URI, providing one or more alternate database URIs. The
device needs to update its preconfigured entry for the responding device needs to update its preconfigured entry for the responding
database with the alternate databases listed in the DbUpdateSpec. Database with the alternate Databases listed in the DbUpdateSpec.
other: The Database MAY include additional handshake parameters in other: The Database MAY include additional handshake parameters in
the INIT_RESP (Section 4.3.2) message. The Master Device MUST the INIT_RESP (Section 4.3.2) message. The Master Device MUST
ignore all parameters it does not understand. Consult the PAWS ignore all parameters it does not understand. Consult the PAWS
Parameters Registry (Section 9.2) for possible additional Parameters Registry (Section 9.2) for possible additional
parameters. parameters.
4.4. Device Registration 4.4. Device Registration
Some rulesets require a Master Device to send its registration Some rulesets require a Master Device to send its registration
information to the Database in order to establish certain operational information to the Database in order to establish certain operational
parameters. FCC rules, for example, require that a 'Fixed Device' parameters. FCC rules, for example, require that a 'Fixed Device'
register its owner and operator contact information, its device register its owner and operator contact information, its device
identifier, its location, and its antenna height (see FCC CFR47-15H identifier, its location, and its antenna height (see FCC CFR47-15H
[FCC-CFR47-15H]). [FCC-CFR47-15H]).
The Database MAY implement device registration as a separate Device The Database MAY implement device registration as a separate Device
Registration request, or as part of the Spectrum Availability Registration request, or as part of the available-spectrum request.
request. If the Database does not implement a separate Device If the Database does not implement a separate Device Registration
Registration request, it MUST return an error with the UNIMPLEMENTED request, it MUST return an error with the UNIMPLEMENTED code (see
(Table 1) code in the error-response message. Table 1) in the error-response message.
The Device Registration request procedure is depicted in Figure 2. The Device Registration request procedure is depicted in Figure 2.
o REGISTRATION_REQ (Section 4.4.1) is the device-registration o REGISTRATION_REQ (Section 4.4.1) is the device-registration
request message request message
o REGISTRATION_RESP (Section 4.4.2) is the device-registration o REGISTRATION_RESP (Section 4.4.2) is the device-registration
response message response message
+---------------+ +-------------------+ +---------------+ +-------------------+
| Master Device | | Spectrum Database | | Master Device | | Spectrum Database |
+---------------+ +-------------------+ +---------------+ +-------------------+
| | | |
| REGISTRATION_REQ | | REGISTRATION_REQ |
|------------------------>| |------------------------>|
| | | |
| REGISTRATION_RESP | | REGISTRATION_RESP |
|<------------------------| |<------------------------|
| | | |
skipping to change at page 15, line 14 skipping to change at page 16, line 26
4.4.1. REGISTRATION_REQ 4.4.1. REGISTRATION_REQ
The registration request message contains the required registration The registration request message contains the required registration
parameters. A parameter marked as optional may be required by some parameters. A parameter marked as optional may be required by some
rulesets. rulesets.
+-------------------------------------------+ +-------------------------------------------+
|REGISTRATION_REQ | |REGISTRATION_REQ |
+-------------------------------+-----------+ +-------------------------------+-----------+
|deviceDesc:DeviceDescriptor | required | |deviceDesc:DeviceDescriptor | REQUIRED |
|location:GeoLocation | required | |location:GeoLocation | REQUIRED |
|deviceOwner:DeviceOwner | optional | |deviceOwner:DeviceOwner | OPTIONAL |
|antenna:AntennaCharacteristics | optional | |antenna:AntennaCharacteristics | OPTIONAL |
|...........................................| |...........................................|
|*other:any | optional | |*other:any | OPTIONAL |
+-------------------------------+-----------+ +-------------------------------+-----------+
Parameters: Parameters:
deviceDesc: The DeviceDescriptor (Section 5.2) for the Master Device deviceDesc: The DeviceDescriptor (Section 5.2) for the Master Device
is REQUIRED. The ruleset IDs included in the DeviceDescriptor is REQUIRED. The ruleset IDs included in the DeviceDescriptor
indicate the rulesets for which the device wishes to register. indicate the rulesets for which the device wishes to register.
location: The GeoLocation (Section 5.1) for the device is REQUIRED. location: The GeoLocation (Section 5.1) for the device is REQUIRED.
More precisely, this is the location at which the device intends More precisely, this is the location at which the device intends
to operate. If the location is outside all regulatory domains to operate. If the location is outside all regulatory domains
supported by the Database, the Database MUST respond with an supported by the Database, the Database MUST respond with an
OUTSIDE_COVERAGE (Table 1) error. OUTSIDE_COVERAGE error (see Table 1).
deviceOwner: The DeviceOwner (Section 5.5) information is OPTIONAL. deviceOwner: The DeviceOwner (Section 5.5) information is OPTIONAL.
Some rulesets may require deviceOwner information under certain Some rulesets may require deviceOwner information under certain
conditions. See PAWS Ruleset ID Registry (Section 9.1) for conditions. See PAWS Ruleset ID Registry (Section 9.1) for
ruleset-specific requirements. ruleset-specific requirements.
antenna: The AntennaCharacteristics (Section 5.3) is OPTIONAL. antenna: The AntennaCharacteristics (Section 5.3) is OPTIONAL.
other: Rulesets and database implementations may require additional other: Rulesets and database implementations may require additional
registration parameters. To simplify its registration logic, the registration parameters. To simplify its registration logic, the
skipping to change at page 16, line 5 skipping to change at page 17, line 18
required by all supported rulesets. The Database MUST ignore all required by all supported rulesets. The Database MUST ignore all
parameters it does not understand. Consult the PAWS Parameters parameters it does not understand. Consult the PAWS Parameters
Registry (Section 9.2) for possible additional parameters. Registry (Section 9.2) for possible additional parameters.
4.4.2. REGISTRATION_RESP 4.4.2. REGISTRATION_RESP
The registration response message acknowledges successful The registration response message acknowledges successful
registration by including a RulesetInfo message for each ruleset in registration by including a RulesetInfo message for each ruleset in
which the registration is accepted. If the Database accepts the which the registration is accepted. If the Database accepts the
registration for none of the specified rulesets, the Database MUST registration for none of the specified rulesets, the Database MUST
return the NOT_REGISTERED error (See Error Codes (Section 5.17)). return the NOT_REGISTERED error (see "Error Codes" (Section 5.17)).
+---------------------------------------+ +---------------------------------------+
|REGISTRATION_RESP | |REGISTRATION_RESP |
+----------------------------+----------+ 1..* +-------------+ +----------------------------+----------+ 1..* +-------------+
|rulesetInfos:list | required |------->| RulesetInfo | |rulesetInfos:list | REQUIRED |------->| RulesetInfo |
|databaseChange:DbUpdateSpec | optional | +-------------+ |databaseChange:DbUpdateSpec | OPTIONAL | +-------------+
|............................|..........| |............................|..........|
|*other:any | optional | |*other:any | OPTIONAL |
+----------------------------+----------+ +----------------------------+----------+
Parameters: Parameters:
rulesetInfos: A RulesetInfo (Section 5.6) list MUST be included in rulesetInfos: A RulesetInfo (Section 5.6) list MUST be included in
the response. Each entry corresponds to a ruleset for which the the response. Each entry corresponds to a ruleset for which the
registration was accepted. The list MUST contain at least one registration was accepted. The list MUST contain at least one
entry. entry.
Each RulesetInfo in the response MUST match one of the ruleset IDs Each RulesetInfo in the response MUST match one of the ruleset IDs
specified in the DeviceDescriptor of REGISTRATION_REQ. specified in the DeviceDescriptor of REGISTRATION_REQ.
If the Database does not support the device or supports none of If the Database does not support the device or supports none of
the rulesets specified in the DeviceDescriptor, it MUST instead the rulesets specified in the DeviceDescriptor, it MUST instead
return an error with the UNSUPPORTED (Table 1) code in the error return an error with the UNSUPPORTED code (see Table 1) in the
response. error response.
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) to notify the Master Device of a change to the (Section 5.7) to notify the Master Device of a change to the
Database URI, providing one or more alternate database URIs. The database URI, providing one or more alternate database URIs. The
device needs to update its preconfigured entry for the responding device needs to update its preconfigured entry for the responding
database with the alternate databases listed in the DbUpdateSpec. Database with the alternate Databases listed in the DbUpdateSpec.
other: Database implementations MAY return additional parameters in other: Database implementations MAY return additional parameters in
the registration response. The Master Device MUST ignore any the registration response. The Master Device MUST ignore any
parameters it does not understand. Consult the PAWS Parameters parameters it does not understand. Consult the PAWS Parameters
Registry (Section 9.2) for possible additional parameters. Registry (Section 9.2) for possible additional parameters.
4.5. Available Spectrum Query 4.5. Available Spectrum Query
To obtain the available spectrum from the Database, a Master Device To obtain the available spectrum from the Database, a Master Device
sends a request that contains its geolocation and any parameters sends a request that contains its geolocation and any parameters
skipping to change at page 17, line 50 skipping to change at page 19, line 30
| (SPECTRUM_USE_RESP) | | (SPECTRUM_USE_RESP) |
|<---------------------------| |<---------------------------|
| | | |
Figure 3 Figure 3
1. First, the Master Device sends an available-spectrum request 1. First, the Master Device sends an available-spectrum request
message to the Database. message to the Database.
2. The Database MUST respond with an error using the NOT_REGISTERED 2. The Database MUST respond with an error using the NOT_REGISTERED
(Table 1) code if: code (see Table 1) if:
* registration information is required, and * registration information is required, and
* the request does not include registration information, and * the request does not include registration information, and
* the device has not previously registered with the Database * the device has not previously registered with the Database
3. If the location specified in the request is outside the 3. If the location specified in the request is outside the
regulatory domain supported by the Database, the Database MUST regulatory domain supported by the Database, the Database MUST
respond with an OUTSIDE_COVERAGE (Table 1) error. If some, but respond with an OUTSIDE_COVERAGE error (see Table 1). If some,
not all, locations within a batch request are outside the but not all, locations within a batch request are outside the
regulatory domain supported by the Database, the Database MUST regulatory domain supported by the Database, the Database MUST
return an OK response with available spectrum for only the valid return an OK response with available spectrum for only the valid
locations; otherwise, if all locations within a batch request are locations; otherwise, if all locations within a batch request are
outside the regulatory domain, the Database MUST respond with an outside the regulatory domain, the Database MUST respond with an
OUTSIDE_COVERAGE error. OUTSIDE_COVERAGE error.
4. The Database MAY perform other validation of the request, (e.g., 4. The Database MAY perform other validation of the request, (e.g.,
checking for missing required parameters, authorizations). If checking for missing required parameters or authorizations). If
validation fails, the Database returns an appropriate error code validation fails, the Database returns an appropriate error code
(Table 1). If the request is missing required parameters, the (Table 1). If the request is missing required parameters, the
Database MUST respond with a MISSING (Table 1) error and SHOULD Database MUST respond with a MISSING error (see Table 1) and
include a list of the missing parameters. SHOULD include a list of the missing parameters.
5. If the request is valid, the Database responds with an available- 5. If the request is valid, the Database responds with an available-
spectrum response message. If the ruleset requires that devices spectrum response message. If the ruleset requires that devices
must report anticipated spectrum usage, the Database will must report anticipated spectrum usage, the Database will
indicate so in the response message. indicate so in the response message.
6. If the available-spectrum response indicates that the Master 6. If the available-spectrum response indicates that the Master
Device must send a spectrum-usage notification message, the Device must send a spectrum-usage notification message, the
Master Device sends the notification message to the Database. Master Device sends the notification message to the Database.
Even when not required by the database, the Master Device MAY Even when not required by the Database, the Master Device MAY
send a notification message. send a notification message.
7. If the Database receives a spectrum-usage notification message, 7. If the Database receives a spectrum-usage notification message,
it MUST send a spectrum-usage acknowledgment message to the it MUST send a spectrum-usage acknowledgment message to the
Master Device. Master Device.
The procedure for a Master Device asking for available spectrum on The procedure for a Master Device to ask for available spectrum on
behalf of a Slave Device is similar, except that the process is behalf of a Slave Device is similar, except that the process is
initiated by the Slave Device. The device identifier, capabilities, initiated by the Slave Device. The device identifier, capabilities,
and characteristics communicated in the AVAIL_SPECTRUM_REQ message and characteristics communicated in the AVAIL_SPECTRUM_REQ message
MUST be those of the Slave Device, and: MUST be those of the Slave Device, and:
o The "masterDeviceLocation" field specifying the location of the o The "masterDeviceLocation" field specifying the location of the
Master Device is REQUIRED. Master Device is REQUIRED.
o The "location" field specifying the location of the Slave Device o The "location" field specifying the location of the Slave Device
is OPTIONAL, since the Slave Device may not have location-sensing is OPTIONAL, since the Slave Device may not have location-sensing
capabilities. capabilities.
Although the communication and protocol between the Slave Device and Although the communication and protocol between the Slave Device and
Master Device is outside the scope of this document (represented as Master Device are outside the scope of this document (represented as
dotted lines), the expected message sequence is shown in Figure 4. dotted lines), the expected message sequence is shown in Figure 4.
+------------+ +---------------+ +-------------------+ +------------+ +---------------+ +-------------------+
|Slave Device| | Master Device | | Spectrum Database | |Slave Device| | Master Device | | Spectrum Database |
+------------+ +---------------+ +-------------------+ +------------+ +---------------+ +-------------------+
| | | | | |
| AVAIL_SPEC_REQ | | | AVAIL_SPEC_REQ | |
|................>| | |................>| |
| | | | | |
| | AVAIL_SPECTRUM_REQ | | | AVAIL_SPECTRUM_REQ |
skipping to change at page 20, line 10 skipping to change at page 21, line 42
The request message for the Available Spectrum Query protocol MUST The request message for the Available Spectrum Query protocol MUST
include a geolocation. Rulesets may mandate that it be the device's include a geolocation. Rulesets may mandate that it be the device's
current location or allow it to be an anticipated location. A current location or allow it to be an anticipated location. A
parameter marked as optional may be required by some rulesets. parameter marked as optional may be required by some rulesets.
+----------------------------------------------------+ +----------------------------------------------------+
|AVAIL_SPECTRUM_REQ | |AVAIL_SPECTRUM_REQ |
+----------------------------------+-----------------+ +----------------------------------+-----------------+
|deviceDesc:DeviceDescriptor | see description | |deviceDesc:DeviceDescriptor | see description |
|location:GeoLocation | see description | |location:GeoLocation | see description |
|owner:DeviceOwner | optional | |owner:DeviceOwner | OPTIONAL |
|antenna:AntennaCharacteristics | optional | |antenna:AntennaCharacteristics | OPTIONAL |
|capabilities:DeviceCapabilities | optional | |capabilities:DeviceCapabilities | OPTIONAL |
|masterDeviceDesc:DeviceDescriptor | optional | |masterDeviceDesc:DeviceDescriptor | OPTIONAL |
|masterDeviceLocation:GeoLocation | see description | |masterDeviceLocation:GeoLocation | see description |
|requestType:string | optional | |requestType:string | OPTIONAL |
|..................................|.................| |..................................|.................|
|*other:any | optional | |*other:any | OPTIONAL |
+----------------------------------+-----------------+ +----------------------------------+-----------------+
Parameters: Parameters:
deviceDesc: The DeviceDescriptor (Section 5.2) for the device deviceDesc: The DeviceDescriptor (Section 5.2) for the device
requesting available spectrum. When the request is made by a requesting available spectrum. When the request is made by a
Master Device on its own behalf, the descriptor is that of the Master Device on its own behalf, the descriptor is that of the
Master Device and it is REQUIRED. When the request is made on Master Device, and it is REQUIRED. When the request is made on
behalf of a Slave Device, the descriptor is that of the Slave behalf of a Slave Device, the descriptor is that of the Slave
Device, and it is REQUIRED if the "requestType" parameter is not Device, and it is REQUIRED if the "requestType" parameter is not
specified. The deviceDesc parameter may be OPTIONAL for some specified. The deviceDesc parameter may be OPTIONAL for some
values of requestType. values of requestType.
location: The GeoLocation (Section 5.1) for the device requesting location: The GeoLocation (Section 5.1) for the device requesting
available spectrum. More precisely, this is the location at which available spectrum. More precisely, this is the location at which
the device intends to operate. When the request is made by the the device intends to operate. When the request is made by the
Master Device on its own behalf, the location is that of the Master Device on its own behalf, the location is that of the
Master Device and it is REQUIRED. When the request is made by the Master Device, and it is REQUIRED. When the request is made by
Master Device on behalf of a Slave Device, the location is that of the Master Device on behalf of a Slave Device, the location is
the Slave Device, and it is OPTIONAL (see also that of the Slave Device, and it is OPTIONAL (see also
masterDeviceLocation). The location may be an anticipated masterDeviceLocation). The location may be an anticipated
position of the device to support mobile devices, but its use position of the device to support mobile devices, but its use
depends on the ruleset. If the location specifies a region, depends on the ruleset. If the location specifies a region,
rather than a point, the Database MAY return an error with the rather than a point, the Database MAY return an error with the
UNIMPLEMENTED (Table 1) code, if it does not implement query by UNIMPLEMENTED code (see Table 1), if it does not implement query
region. by region.
NOTE: Technically, this is the location of the radiation center of NOTE: Technically, this is the location of the radiation center of
the device's antenna, but that distinction may be relevant only the device's antenna, but that distinction may be relevant only
for fixed devices. for fixed devices.
owner: The DeviceOwner (Section 5.5) information MAY be included to owner: The DeviceOwner (Section 5.5) information MAY be included to
register the device with the Database. This enables the device to register the device with the Database. This enables the device to
register and get spectrum-availability information in a single register and get spectrum-availability information in a single
request. Some rulesets mandate registration for specific device request. Some rulesets mandate registration for specific device
types. types.
skipping to change at page 21, line 23 skipping to change at page 23, line 9
specified capabilities. specified capabilities.
masterDeviceDesc: When the request is made by the Master Device on masterDeviceDesc: When the request is made by the Master Device on
behalf of a Slave Device, the Master Device MAY provide its own behalf of a Slave Device, the Master Device MAY provide its own
descriptor. descriptor.
masterDeviceLocation: When the request is made by the Master Device masterDeviceLocation: When the request is made by the Master Device
on behalf of a Slave Device, the Master Device MUST provide its on behalf of a Slave Device, the Master Device MUST provide its
own GeoLocation (Section 5.1). own GeoLocation (Section 5.1).
requestType: The request type is OPTIONAL, which may be used to requestType: The request type is OPTIONAL; it may be used to modify
modify the request, but its use depends on the applicable ruleset. the request, but its use depends on the applicable ruleset. The
The request type may be used, for example, to indicate that the request type may be used, for example, to indicate that the
response should include generic Slave Device parameters without response should include generic Slave Device parameters without
having to specify the device descriptor for a specific device. having to specify the device descriptor for a specific device.
When requestType is missing, the request is for a specific device When requestType is missing, the request is for a specific device
(Master or Slave), so deviceDesc is REQUIRED. The maximum length (Master or Slave), so deviceDesc is REQUIRED. The maximum length
of the value is 64 octets. See IANA Ruleset Registry, Initial of the value is 64 octets. See the specifics in the Initial
Registry Contents (Section 9.1.2) for ruleset specifics. Registry Contents (Section 9.1.2) for the Ruleset ID Registry.
other: Rulesets and database implementations may require additional other: Rulesets and database implementations may require additional
request parameters. The Database MUST ignore all parameters it request parameters. The Database MUST ignore all parameters it
does not understand. Consult the PAWS Parameters Registry does not understand. Consult the PAWS Parameters Registry
(Section 9.2) for possible additional parameters. (Section 9.2) for possible additional parameters.
4.5.2. AVAIL_SPECTRUM_RESP 4.5.2. AVAIL_SPECTRUM_RESP
The response message for the Available Spectrum Query contains one or The response message for the Available Spectrum Query contains one or
more SpectrumSpec (Section 5.9) elements, one for each ruleset more SpectrumSpec (Section 5.9) elements, one for each ruleset
supported at the location specified in the corresponding supported at the location specified in the corresponding
AVAIL_SPECTRUM_REQ (Section 4.5.1) request. Each SpectrumSpec AVAIL_SPECTRUM_REQ (Section 4.5.1) message. Each SpectrumSpec
element contains a list of one or more spectrum schedules, element contains a list of one or more spectrum schedules,
representing permissible power levels over time: representing permissible power levels over time:
o Each spectrum schedule specifies permissible power level for a o Each spectrum schedule specifies the permissible power level for a
duration defined by a pair of start and stop times. The power duration defined by a pair of start and stop times. The power
levels refer to permissible EIRP over a resolution bandwidth. levels refer to permissible EIRP over a resolution bandwidth.
o Within each list of schedules, event-time intervals MUST be o Within each list of schedules, event-time intervals MUST be
disjoint and MUST be sorted in increasing time. disjoint and MUST be sorted in increasing time.
o A gap in the time schedule means no spectrum is available for that o A gap in the time schedule means no spectrum is available for that
time interval. time interval.
Consider a Database that provides a schedule of available spectrum Consider a Database that provides a schedule of available spectrum
for the next 24 hours. If spectrum availability were to be different for the next 24 hours. If spectrum availability were to be different
at different times of day, the response would contain a list of at different times of day, the response would contain a list of
schedules, each transition representing some change to the spectrum schedules, each transition representing some change to the spectrum
availability. A device might use different strategies to select availability. A device might use different strategies to select
which spectrum to use, e.g.: which spectrum to use, e.g.:
o Always use the frequencies that permit the highest power o Always use the frequencies that permit the highest power
o Use the frequencies that are available for the longest period of
time.
o Use the frequencies that is available for the longest period of o Just use the first set of frequencies that matches its needs.
time
o Just use the first set of frequencies that matches its needs
+---------------------------------------+ +---------------------------------------+
|AVAIL_SPECTRUM_RESP | |AVAIL_SPECTRUM_RESP |
+----------------------------+----------+ +----------------------------+----------+
|timestamp:string | required | |timestamp:string | REQUIRED |
|deviceDesc:DeviceDescriptor | required | |deviceDesc:DeviceDescriptor | REQUIRED |
|spectrumSpecs:list | required |-------+ |spectrumSpecs:list | REQUIRED |-------+
|............................|..........| | |............................|..........| |
|databaseChange:DbUpdateSpec | optional | | |databaseChange:DbUpdateSpec | OPTIONAL | |
|*other:any | optional | | |*other:any | OPTIONAL | |
+----------------------------+----------+ | 1..* +----------------------------+----------+ | 1..*
V V
+-----------------------------------+ +-----------------------------------+
|SpectrumSpec | |SpectrumSpec |
+------------------------+----------+ +------------------------+----------+
|rulesetInfo:RulesetInfo | required | |rulesetInfo:RulesetInfo | REQUIRED |
|spectrumSchedules:list | required |-+ |spectrumSchedules:list | REQUIRED |-+
|timeRange:EventTime | optional | | |timeRange:EventTime | OPTIONAL | |
|frequencyRanges:list | optional | | |frequencyRanges:list | OPTIONAL | |
|needsSpectrumReport:bool| optional | | |needsSpectrumReport:bool| OPTIONAL | |
|maxTotalBwHz:float | optional | | |maxTotalBwHz:float | OPTIONAL | |
|maxContiguousBwHz:float | optional | | |maxContiguousBwHz:float | OPTIONAL | |
+------------------------+----------+ | +------------------------+----------+ |
+--------------------+ +--------------------+
| 1..* | 1..*
V V
+-------------------------------+ +-------------------------------+
|SpectrumSchedule | |SpectrumSchedule |
+--------------------+----------+ +--------------------+----------+
|eventTime:EventTime | required | |eventTime:EventTime | REQUIRED |
|spectra:list | required | |spectra:list | REQUIRED |
+--------------------+----------+ +--------------------+----------+
Parameters: Parameters:
timestamp: Timestamp of the response is expressed in UTC using the timestamp: Timestamp of the response is expressed in UTC using the
form, YYYY-MM-DDThh:mm:ssZ, as defined by "Date and Time on the form, YYYY-MM-DDThh:mm:ssZ, as defined by "Date and Time on the
Internet: Timestamps" [RFC3339]. This can be used by the device Internet: Timestamps" [RFC3339]. This can be used by the device
as a reference for the start and stop times in the spectrum as a reference for the start and stop times in the spectrum
schedules. schedules.
deviceDesc: The Database MUST include the DeviceDescriptor deviceDesc: The Database MUST include the DeviceDescriptor
(Section 5.2) specified in the AVAIL_SPECTRUM_REQ message. (Section 5.2) specified in the AVAIL_SPECTRUM_REQ message.
spectrumSpecs: The SpectrumSpec (Section 5.9) list MUST include at spectrumSpecs: The SpectrumSpec (Section 5.9) list MUST include at
least one entry. Each entry contains the schedules of available least one entry. Each entry contains the schedules of available
spectrum for a ruleset. The Database MAY return more than one spectrum for a ruleset. The Database MAY return more than one
SpectrumSpec to represent available spectrum for multiple rulesets SpectrumSpec to represent available spectrum for multiple rulesets
at the specified location. at the specified location.
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) to notify the device of a change to the Database (Section 5.7) to notify the device of a change to the database
URI, providing one or more alternate database URIs. The device URI, providing one or more alternate database URIs. The device
needs to update its preconfigured entry for the responding needs to update its preconfigured entry for the responding
database with the alternate databases listed in the DbUpdateSpec. Database with the alternate Databases listed in the DbUpdateSpec.
other: Database implementations MAY return additional parameters in other: Database implementations MAY return additional parameters in
the response. The device MUST ignore any parameters that it does the response. The device MUST ignore any parameters that it does
not understand. Consult the PAWS Parameters Registry not understand. Consult the PAWS Parameters Registry
(Section 9.2) for possible additional parameters and requirements (Section 9.2) for possible additional parameters and requirements
they place on the device. they place on the device.
4.5.2.1. Update Requirements 4.5.2.1. Update Requirements
When the stop time specified in the schedule has been reached, the When the stop time specified in the schedule has been reached, the
device: device:
o MUST obtain a new spectrum-availability schedule, either by using o MUST obtain a new spectrum-availability schedule, either by using
the next one in the list (if provided) or making another Available the next one in the list (if provided) or making another Available
Spectrum Query (Section 4.5). Spectrum Query (Section 4.5).
o If the device is unable to contact the Database to obtain a new o If the device is unable to contact the Database to obtain a new
schedule, it MUST treat this as equivalent to a response with no schedule, it MUST treat this as equivalent to a response with no
available spectrum. available spectrum.
Some rulesets also mandate that a device must obtain a new specturm- Some rulesets also mandate that a device must obtain a new spectrum-
availability schedule if the device moves beyond a threshold distance availability schedule if the device moves beyond a threshold distance
(established by the ruleset) away from the actual location and all (established by the ruleset) from the actual location and all
anticipated location(s) it reported in previous AVAIL_SPECTRUM_REQ or anticipated location(s) it reported in previous AVAIL_SPECTRUM_REQ or
AVAIL_SPECTRUM_BATCH_REQ requests (see "maxLocationChange" in AVAIL_SPECTRUM_BATCH_REQ messages (see "maxLocationChange" in
RulesetInfo (Section 5.6)). If the device is unable to contact the RulesetInfo (Section 5.6)). If the device is unable to contact the
Database to obtain a new schedule, it MUST treat this as equivalent Database to obtain a new schedule, it MUST treat this as equivalent
to a response with no available spectrum. to a response with no available spectrum.
NOTE: The ruleset determines required device behavior when spectrum NOTE: The ruleset determines required device behavior when spectrum
is no longer available. The ruleset also governs whether a device is no longer available. The ruleset also governs whether a device
may request and use spectrum at anticipated locations beyond the may request and use spectrum at anticipated locations beyond the
threshold distance from its current location. threshold distance from its current location.
4.5.3. AVAIL_SPECTRUM_BATCH_REQ 4.5.3. AVAIL_SPECTRUM_BATCH_REQ
The Database MAY implement the batch request that allows multiple The Database MAY implement the batch request that allows multiple
locations to be specified. This enables a portable Master Device, locations to be specified. This enables a portable Master Device,
for example, to get available spectrum for a sequence of anticipated for example, to get available spectrum for a sequence of anticipated
locations using a single request. The Database interprets each locations using a single request. The Database interprets each
location in the batch request as if it were an independent request location in the batch request as if it were an independent request
and returns results consistent with multiple individual and returns results consistent with multiple individual
AVAIL_SPECTRUM_REQ (Section 4.5.1) requests, but returns these AVAIL_SPECTRUM_REQ (Section 4.5.1) messages, but it returns these
results in a batched response (Section 4.5.4). The request message results in a batched response (Section 4.5.4). The request message
for the batch Available Spectrum Query protocol MUST include at least for the batch Available Spectrum Query protocol MUST include at least
one GeoLocation (Section 5.1). If the Database does not implement one GeoLocation (Section 5.1). If the Database does not implement
batch requests, it MUST return an UNIMPLEMENTED (Table 1) error. batch requests, it MUST return an UNIMPLEMENTED error (see Table 1).
NOTE: Whether anticipated locations are allowed depends on the NOTE: Whether anticipated locations are allowed depends on the
specified ruleset. A parameter marked as optional may be required by specified ruleset. A parameter marked as optional may be required by
some rulesets. some rulesets.
+---------------------------------------------------+ +---------------------------------------------------+
|AVAIL_SPECTRUM_BATCH_REQ | |AVAIL_SPECTRUM_BATCH_REQ |
+---------------------------------+-----------------+ +---------------------------------+-----------------+
|deviceDesc:DeviceDescriptor | see description | |deviceDesc:DeviceDescriptor | see description |
|locations:list | required |--+ |locations:list | REQUIRED |--+
|owner:DeviceOwner | optional | | |owner:DeviceOwner | OPTIONAL | |
|antenna:AntennaCharacteristics | optional | | |antenna:AntennaCharacteristics | OPTIONAL | |
|capabilities:DeviceCapabilities | optional | | |capabilities:DeviceCapabilities | OPTIONAL | |
|masterDeviceDesc:DeviceDescriptor| optional | | |masterDeviceDesc:DeviceDescriptor| OPTIONAL | |
|masterDeviceLocation:GeoLocation | see description | | |masterDeviceLocation:GeoLocation | see description | |
|requestType:string | optional | | |requestType:string | OPTIONAL | |
+.................................+.................+ | +.................................+.................+ |
|*other:any | optional | | |*other:any | OPTIONAL | |
+---------------------------------+-----------------+ | +---------------------------------+-----------------+ |
| |
1..* V 1..* V
+-------------+ +-------------+
| GeoLocation | | GeoLocation |
+-------------+ +-------------+
Parameters: Parameters:
deviceDesc: The DeviceDescriptor (Section 5.2) for the device deviceDesc: The DeviceDescriptor (Section 5.2) for the device
requesting available spectrum. When the request is made by a requesting available spectrum. When the request is made by a
Master Device on its own behalf, the descriptor is that of the Master Device on its own behalf, the descriptor is that of the
Master Device and it is REQUIRED. When the request is made on Master Device, and it is REQUIRED. When the request is made on
behalf of a Slave Device, the descriptor is that of the Slave behalf of a Slave Device, the descriptor is that of the Slave
Device, and it is REQUIRED if the "requestType" parameter is not Device, and it is REQUIRED if the "requestType" parameter is not
specified. The deviceDesc parameter may be OPTIONAL for some specified. The deviceDesc parameter may be OPTIONAL for some
values of requestType. values of requestType.
locations: The GeoLocation (Section 5.1) list for the device is locations: The GeoLocation (Section 5.1) list for the device is
REQUIRED. This allows the device to specify its actual location REQUIRED. This allows the device to specify its actual location
plus additional anticipated locations. At least one location MUST plus additional anticipated locations. At least one location MUST
be included. This specification places no upper limit on the be included. This specification places no upper limit on the
number of locations, but the Database MAY restrict the number of number of locations, but the Database MAY restrict the number of
locations it supports by returning a response with fewer locations locations it supports by returning a response with fewer locations
than specified in the request. If the locations specify regions, than specified in the request. If the locations specify regions,
rather than points, the Database MAY return an error with the rather than points, the Database MAY return an error with the
UNIMPLEMENTED (Table 1) code, if it does not implement query by UNIMPLEMENTED code (see Table 1), if it does not implement query
region. When the request is made by a Master Device on its own by region. When the request is made by a Master Device on its own
behalf, the locations are those of the Master Device. When the behalf, the locations are those of the Master Device. When the
request is made by the Master Device on behalf of a Slave Device, request is made by the Master Device on behalf of a Slave Device,
the locations are those of the Slave Device (see also the locations are those of the Slave Device (see also
masterDeviceLocation). masterDeviceLocation).
owner: The DeviceOwner (Section 5.5) information MAY be included to owner: The DeviceOwner (Section 5.5) information MAY be included to
register the device with the Database. This enables the device to register the device with the Database. This enables the device to
register and get spectrum-availability information in a single register and get spectrum-availability information in a single
request. Some rulesets mandate registration for specific device request. Some rulesets mandate registration for specific device
types. types.
skipping to change at page 26, line 34 skipping to change at page 27, line 43
masterDeviceDesc: When the request is made by the Master Device on masterDeviceDesc: When the request is made by the Master Device on
behalf of a Slave Device, the Master Device MAY provide its own behalf of a Slave Device, the Master Device MAY provide its own
descriptor. descriptor.
masterDeviceLocation: When the request is made by the Master Device masterDeviceLocation: When the request is made by the Master Device
on behalf of a Slave Device, the Master Device MUST provide its on behalf of a Slave Device, the Master Device MUST provide its
own GeoLocation (Section 5.1). own GeoLocation (Section 5.1).
requestType: The request type is an OPTIONAL parameter that may be requestType: The request type is an OPTIONAL parameter that may be
used to modify the request, but its use depends on applicable the used to modify the request, but its use depends on the applicable
ruleset. The request type may be used, for example, to request ruleset. The request type may be used, for example, to request
generic Slave Device parameters without having to specify the generic Slave Device parameters without having to specify the
device descriptor for a specific device. When the requestType device descriptor for a specific device. When the requestType
parameter is missing, the request is for a specific device (Master parameter is missing, the request is for a specific device (Master
or Slave), so deviceDesc is REQUIRED. The maximum length is 64 or Slave), so deviceDesc is REQUIRED. The maximum length is 64
octets. See IANA Ruleset Registry, Initial Registry Contents octets. See the ruleset specifics in the Initial Registry
(Section 9.1.2) for ruleset specifics. Contents (Section 9.1.2) for the Ruleset ID Registry.
other: Rulesets and database implementations may require additional other: Rulesets and database implementations may require additional
request parameters. The Database MUST ignore all parameters it request parameters. The Database MUST ignore all parameters it
does not understand. Consult the PAWS Parameters Registry does not understand. Consult the PAWS Parameters Registry
(Section 9.2) for possible additional parameters. (Section 9.2) for possible additional parameters.
4.5.4. AVAIL_SPECTRUM_BATCH_RESP 4.5.4. AVAIL_SPECTRUM_BATCH_RESP
The response message for the batch Available Spectrum Query contains The response message for the batch Available Spectrum Query contains
a schedule of available spectrum for the device at multiple a schedule of available spectrum for the device at multiple
locations. locations.
+---------------------------------------+ +---------------------------------------+
|AVAIL_SPECTRUM_BATCH_RESP | |AVAIL_SPECTRUM_BATCH_RESP |
+----------------------------+----------+ +----------------------------+----------+
|timestamp:string | required | |timestamp:string | REQUIRED |
|deviceDesc:DeviceDescriptor | required | |deviceDesc:DeviceDescriptor | REQUIRED |
|geoSpectrumSpecs:list | required |-------+ |geoSpectrumSpecs:list | REQUIRED |-------+
|............................|..........| | |............................|..........| |
|databaseChange:DbUpdateSpec | optional | | |databaseChange:DbUpdateSpec | OPTIONAL | |
|*other:any | optional | | |*other:any | OPTIONAL | |
+----------------------------+----------+ | 0..* +----------------------------+----------+ | 0..*
V V
+---------------------------------+ +---------------------------------+
|GeoSpectrumSpec | |GeoSpectrumSpec |
+----------------------+----------+ +----------------------+----------+
|location:GeoLocation | required | |location:GeoLocation | REQUIRED |
|spectrumSpecs:list | required | |spectrumSpecs:list | REQUIRED |
+----------------------+----------+ +----------------------+----------+
Parameters: Parameters:
timestamp: Timestamp of the response of the form, YYYY-MM- timestamp: Timestamp of the response of the form,
DDThh:mm:ssZ, as defined by "Date and Time on the Internet: YYYY-MM-DDThh:mm:ssZ, as defined by "Date and Time on the
Timestamps" [RFC3339]. This can be used by the device as a Internet: Timestamps" [RFC3339]. This can be used by the device
reference for the start and stop times in the spectrum schedules. as a reference for the start and stop times in the spectrum
schedules.
deviceDesc: The Database MUST include the DeviceDescriptor deviceDesc: The Database MUST include the DeviceDescriptor
(Section 5.2) specified in the AVAIL_SPECTRUM_BATCH_REQ message. (Section 5.2) specified in the AVAIL_SPECTRUM_BATCH_REQ message.
geoSpectrumSpecs: The geoSpectrumSpecs (Section 5.15) list is geoSpectrumSpecs: The geoSpectrumSpecs (Section 5.15) list is
REQUIRED (although it MAY be empty if spectrum is unavailable). REQUIRED (although it MAY be empty if spectrum is unavailable).
For each location, the Database MAY return one or more For each location, the Database MAY return one or more
SpectrumSpecs (Section 5.9) to represent available spectrum for SpectrumSpecs (Section 5.9) to represent available spectrum for
one or more rulesets. The Database MAY return available spectrum one or more rulesets. The Database MAY return available spectrum
for fewer locations than requested. The order of the entries in for fewer locations than requested. The order of the entries in
the list is not significant and the device MUST use the location the list is not significant, and the device MUST use the location
value in each GeoSpectrumSpec entry to match available spectrum to value in each GeoSpectrumSpec entry to match available spectrum to
a location. a location.
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) to notify the device of a change to the Database (Section 5.7) to notify the device of a change to the database
URI, providing one or more alternate database URIs. The device URI, providing one or more alternate database URIs. The device
needs to update its preconfigured entry for the responding needs to update its preconfigured entry for the responding
database with the alternate databases listed in the DbUpdateSpec. Database with the alternate Databases listed in the DbUpdateSpec.
other: Database implementations MAY return additional parameters in other: Database implementations MAY return additional parameters in
the response. Consult the PAWS Parameters Registry (Section 9.2) the response. Consult the PAWS Parameters Registry (Section 9.2)
for possible additional parameters and requirements they place on for possible additional parameters and requirements they place on
the device. the device.
See Update Requirements (Section 4.5.2.1) for when the device must See "Update Requirements" (Section 4.5.2.1) for when the device must
update its available spectrum data. update its available spectrum data.
4.5.5. SPECTRUM_USE_NOTIFY 4.5.5. SPECTRUM_USE_NOTIFY
The spectrum-use notification message indicates the spectrum The spectrum-use notification message indicates the spectrum
anticipated to be used by the device. anticipated to be used by the device.
+---------------------------------------------------+ +---------------------------------------------------+
|SPECTRUM_USE_NOTIFY | |SPECTRUM_USE_NOTIFY |
+---------------------------------+-----------------+ +---------------------------------+-----------------+
|deviceDesc:DeviceDescriptor | required | |deviceDesc:DeviceDescriptor | REQUIRED |
|location:GeoLocation | see description | |location:GeoLocation | see description |
|masterDeviceDesc:DeviceDescriptor| optional | |masterDeviceDesc:DeviceDescriptor| OPTIONAL |
|masterDeviceLocation:GeoLocation | see description | |masterDeviceLocation:GeoLocation | see description |
|spectra:list | required |--+ |spectra:list | REQUIRED |--+
|...................................................| | |...................................................| |
|*other:any | optional | | |*other:any | OPTIONAL | |
+---------------------------------+-----------------+ | 0..* +---------------------------------+-----------------+ | 0..*
V V
+--------------------------------+ +--------------------------------+
|Spectrum | |Spectrum |
+---------------------+----------+ +---------------------+----------+
|resolutionBwHz:float | required | |resolutionBwHz:float | REQUIRED |
|profiles:list | required | |profiles:list | REQUIRED |
+---------------------+----------+ +---------------------+----------+
Parameters: Parameters:
deviceDesc: The DeviceDescriptor (Section 5.2) for the device is deviceDesc: The DeviceDescriptor (Section 5.2) for the device is
REQUIRED. REQUIRED.
location: The GeoLocation (Section 5.1) for the device. When the location: The GeoLocation (Section 5.1) for the device. When the
notification is made by a Master Device on its own behalf, the notification is made by a Master Device on its own behalf, the
location is that of the Master Device and is REQUIRED. When the location is that of the Master Device and is REQUIRED. When the
notification is made by a Master Device on behalf of a Slave notification is made by a Master Device on behalf of a Slave
Device, the location is that of the Slave Device and is OPTIONAL, Device, the location is that of the Slave Device and is OPTIONAL
but may be required by some rulesets. but may be required by some rulesets.
spectra: The Spectrum (Section 5.11) list is REQUIRED, and specifies spectra: The Spectrum (Section 5.11) list is REQUIRED and specifies
the spectrum anticipated to be used by the device, which includes the spectrum anticipated to be used by the device; this includes
profiles of frequencies and power levels. The list MAY be empty, profiles of frequencies and power levels. The list MAY be empty,
if the device decides not to use any spectrum. For consistency, if the device decides not to use any spectrum. For consistency,
the resolution bandwidth value, "resolutionBwHz" MUST match that the resolution bandwidth value, "resolutionBwHz", MUST match that
from one of the Spectrum (Section 5.11) elements in the from one of the Spectrum (Section 5.11) elements in the
corresponding AVAIL_SPECTRUM_RESP message, and the maximum power corresponding AVAIL_SPECTRUM_RESP message, and the maximum power
levels in the Spectrum element MUST be expressed as power (EIRP) levels in the Spectrum element MUST be expressed as power (EIRP)
over the specified "resolutionBwHz" value. The actual bandwidth over the specified "resolutionBwHz" value. The actual bandwidth
to be used (as computed from the start and stop frequencies) MAY to be used (as computed from the start and stop frequencies) MAY
be different from the "resolutionBwHz" value. As an example, when be different from the "resolutionBwHz" value. As an example, when
the ruleset expresses maximum power spectral density in terms of the ruleset expresses maximum power spectral density in terms of
maximum power over any 100 kHz band, then the "resolutionBwHz" maximum power over any 100 kHz band, then the "resolutionBwHz"
value should be set to 100 kHz, even though the actual bandwidth value should be set to 100 kHz, even though the actual bandwidth
used can be 20 kHz. used can be 20 kHz.
skipping to change at page 29, line 42 skipping to change at page 31, line 13
ignore all parameters it does not understand. ignore all parameters it does not understand.
4.5.6. SPECTRUM_USE_RESP 4.5.6. SPECTRUM_USE_RESP
The spectrum-use response message simply acknowledges receipt of the The spectrum-use response message simply acknowledges receipt of the
notification. notification.
+---------------------------------------+ +---------------------------------------+
|SPECTRUM_USE_RESP | |SPECTRUM_USE_RESP |
+----------------------------+----------+ +----------------------------+----------+
|databaseChange:DbUpdateSpec | optional | |databaseChange:DbUpdateSpec | OPTIONAL |
|.......................................| |.......................................|
|*other:any | optional | |*other:any | OPTIONAL |
+----------------------------+----------+ +----------------------------+----------+
Parameters: Parameters:
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) to notify the device of a change to the Database (Section 5.7) to notify the device of a change to the database
URI, providing one or more alternate database URIs. The device URI, providing one or more alternate database URIs. The device
needs to update its preconfigured entry for the responding needs to update its preconfigured entry for the responding
database with the alternate databases listed in the DbUpdateSpec. Database with the alternate Databases listed in the DbUpdateSpec.
other: Database implementations MAY return additional parameters in other: Database implementations MAY return additional parameters in
the response. Consult the PAWS Parameters Registry (Section 9.2) the response. Consult the PAWS Parameters Registry (Section 9.2)
for possible additional parameters. for possible additional parameters.
4.6. Device Validation 4.6. Device Validation
A Slave Device needs a Master Device to ask the Database on its A Slave Device needs a Master Device to ask the Database on its
behalf for available spectrum. Depending on the ruleset, the Master behalf for available spectrum. Depending on the ruleset, the Master
Device also must validate with the Database that the Slave Device is Device also must validate with the Database that the Slave Device is
skipping to change at page 30, line 32 skipping to change at page 31, line 51
When validating one or more Slave Devices, the Master Device sends When validating one or more Slave Devices, the Master Device sends
the Database a request that includes the device identifier -- and any the Database a request that includes the device identifier -- and any
other parameters required by the ruleset -- for each Slave Device. other parameters required by the ruleset -- for each Slave Device.
The Database MUST return a response with an entry for each device to The Database MUST return a response with an entry for each device to
indicate whether it is permitted to use the spectrum. indicate whether it is permitted to use the spectrum.
A typical sequence for using the Device Validation request is A typical sequence for using the Device Validation request is
illustrated in Figure 5, where the Master Device already has a valid illustrated in Figure 5, where the Master Device already has a valid
set of available spectrum for Slave Devices. Note that the set of available spectrum for Slave Devices. Note that the
communication and protocol between the Slave Device and Master Device communication and protocol between the Slave Device and Master Device
is outside the scope of this document. are outside the scope of this document.
o DEV_VALID_REQ (Section 4.6.1) is the device-validation request o DEV_VALID_REQ (Section 4.6.1) is the device-validation request
message message.
o DEV_VALID_RESP (Section 4.6.2) is the device-validation response o DEV_VALID_RESP (Section 4.6.2) is the device-validation response
message message.
+------------+ +---------------+ +-------------------+ +------------+ +---------------+ +-------------------+
|Slave Device| | Master Device | | Spectrum Database | |Slave Device| | Master Device | | Spectrum Database |
+------------+ +---------------+ +-------------------+ +------------+ +---------------+ +-------------------+
| | | | | |
| AVAIL_SPEC_REQ | | | AVAIL_SPEC_REQ | |
|................>| | |................>| |
| | | | | |
| | DEV_VALID_REQ | | | DEV_VALID_REQ |
| |-------------------------->| | |-------------------------->|
| | | | | |
skipping to change at page 31, line 36 skipping to change at page 32, line 43
Figure 5 Figure 5
4.6.1. DEV_VALID_REQ 4.6.1. DEV_VALID_REQ
This request is used by a Master Device to determine which Slave This request is used by a Master Device to determine which Slave
Devices are permitted to operate. Devices are permitted to operate.
+---------------------------------------------+ +---------------------------------------------+
|DEV_VALID_REQ | |DEV_VALID_REQ |
+----------------------------------+----------+ +----------------------------------+----------+
|deviceDescs:list | required |---+ |deviceDescs:list | REQUIRED |---+
|masterDeviceDesc:DeviceDescriptor | optional | | |masterDeviceDesc:DeviceDescriptor | OPTIONAL | |
+----------------------------------+----------+ | +----------------------------------+----------+ |
V 1..* V 1..*
+----------------------+ +----------------------+
|DeviceDescriptor | |DeviceDescriptor |
+----------------------+ +----------------------+
Parameters: Parameters:
deviceDescs: A DeviceDescriptor (Section 5.2) list is REQUIRED, deviceDescs: A DeviceDescriptor (Section 5.2) list is REQUIRED; it
which specifies the list of Slave Devices that are to be specifies the list of Slave Devices that are to be validated.
validated.
masterDeviceDesc: The Master Device MAY provide its own descriptor. masterDeviceDesc: The Master Device MAY provide its own descriptor.
4.6.2. DEV_VALID_RESP 4.6.2. DEV_VALID_RESP
+---------------------------------------+ +---------------------------------------+
|DEV_VALID_RESP | |DEV_VALID_RESP |
+----------------------------+----------+ +----------------------------+----------+
|deviceValidities:list | required |---- |deviceValidities:list | REQUIRED |----
|databaseChange:DbUpdateSpec | optional | | |databaseChange:DbUpdateSpec | OPTIONAL | |
+----------------------------+----------+ | +----------------------------+----------+ |
V 1..* V 1..*
+---------------------------------------+ +---------------------------------------+
|DeviceValidity | |DeviceValidity |
+----------------------------+----------+ +----------------------------+----------+
|deviceDesc:DeviceDescriptor | required | |deviceDesc:DeviceDescriptor | REQUIRED |
|isValid:boolean | required | |isValid:boolean | REQUIRED |
|reason:string | optional | |reason:string | OPTIONAL |
+----------------------------+----------+ +----------------------------+----------+
Parameters: Parameters:
deviceValidities: A DeviceValidities (Section 5.16) list is REQUIRED deviceValidities: A DeviceValidities (Section 5.16) list is REQUIRED
to report the list of Slave Devices and whether each listed device to report the list of Slave Devices and whether each listed device
is valid. The number of entries MUST match the number of is valid. The number of entries MUST match the number of
DeviceDescriptors (Section 5.2) listed in the DEV_VALID_REQ DeviceDescriptors (Section 5.2) listed in the DEV_VALID_REQ
message. message.
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) to notify the device of a change to the Database (Section 5.7) to notify the device of a change to the database
URI, providing one or more alternate database URIs. The device URI, providing one or more alternate database URIs. The device
needs to update its preconfigured entry for the responding needs to update its preconfigured entry for the responding
database with the alternate databases listed in the DbUpdateSpec. Database with the alternate Databases listed in the DbUpdateSpec.
5. Protocol Parameters 5. Protocol Parameters
This section presents more details of the parameters that make up the This section presents more details of the parameters that make up the
PAWS request and response messages. It also includes a sub-section PAWS request and response messages. It also includes a subsection
defining response codes. that defines response codes.
5.1. GeoLocation 5.1. GeoLocation
GeoLocation is used to specify one of the following: GeoLocation is used to specify one of the following:
o A single point with optional uncertainty o a single point with optional uncertainty
o A region described by a polygon o a region described by a polygon
These are represented using geometric shapes defined in Section 5 of These are represented using geometric shapes defined in Section 5 of
"GEOPRIV Presence Information Data Format Location Object" [RFC5491], "GEOPRIV Presence Information Data Format Location Object" [RFC5491],
where: where:
o A "point" with uncertainty is represented using the Ellipse shape o A "point" with uncertainty is represented using the Ellipse shape.
o A region is represented using the Polygon shape o A region is represented using the Polygon shape.
The coordinates are expressed using the WGS84 datum [WGS-84], and The coordinates are expressed using the WGS84 datum [WGS-84], and
units are degrees or meters. GeoLocation MAY also include a units are degrees or meters. GeoLocation MAY also include a
confidence level, expressed as a percentage. The confidence and confidence level, expressed as a percentage. The confidence and
uncertainty parameters may be required by some rulesets (see also uncertainty parameters may be required by some rulesets (see also
Uncertainty and Confidence [I-D.ietf-geopriv-uncertainty]). [RFC7459]).
The data model for GeoLocation is illustrated below: The data model for GeoLocation is illustrated below:
+------------------------------------+ +------------------------------------+
|GeoLocation | |GeoLocation |
+------------------+-----------------+ +------------------+-----------------+
|point:Ellipse | see description | |point:Ellipse | see description |
|region:Polygon | see description | |region:Polygon | see description |
|confidence:int | optional | |confidence:int | OPTIONAL |
+------------------+-----------------+ +------------------+-----------------+
Note: point and region are mutually exclusive. Exactly one must Note: Point and region are mutually exclusive. Exactly one must
be present. be present.
+-------------------------------+ +-------------------------------+
|Ellipse | |Ellipse |
+--------------------+----------+ +--------------------+----------+
|center:Point | required |--+ |center:Point | REQUIRED |--+
|semiMajorAxis:float | optional | | |semiMajorAxis:float | OPTIONAL | |
|semiMinorAxis:float | optional | | |semiMinorAxis:float | OPTIONAL | |
|orientation:float | optional | | |orientation:float | OPTIONAL | |
+--------------------+----------+ v +--------------------+----------+ v
+---------------------------+ +---------------------------+
|Point | |Point |
+----------------+----------+ +----------------+----------+
|latitude:float | required | |latitude:float | REQUIRED |
|longitude:float | required | |longitude:float | REQUIRED |
+----------------+----------+ +----------------+----------+
+-------------------------------+ +-------------------------------+
|Polygon | |Polygon |
+-------------------+-----------+ 4..* +---------------------------+ +-------------------+-----------+ 4..* +---------------------------+
|exterior:list | required |------>|Point | |exterior:list | REQUIRED |------>|Point |
+-------------------+-----------+ +----------------+----------+ +-------------------+-----------+ +----------------+----------+
|latitude:float | required | |latitude:float | REQUIRED |
|longitude:float | required | |longitude:float | REQUIRED |
+----------------+----------+ +----------------+----------+
Parameters: Parameters:
point: If present, it specifies the GeoLocation as a point. point: If present, it specifies the GeoLocation as a point.
Paradoxically, a "point" is parameterized using an Ellipse, where Paradoxically, a "point" is parameterized using an Ellipse, where
the center represents the location of the point and the distances the center represents the location of the point and the distances
along the major and minor axes represent the uncertainty. The along the major and minor axes represent the uncertainty. The
uncertainty values may be required, depending on the ruleset. uncertainty values may be required, depending on the ruleset.
Exactly one of "point" or "region" MUST be present. Exactly one of "point" or "region" MUST be present.
skipping to change at page 34, line 22 skipping to change at page 36, line 12
region: If present, it specifies the GeoLocation as a region. region: If present, it specifies the GeoLocation as a region.
Exactly one of "point" or "region" MUST be present. Exactly one of "point" or "region" MUST be present.
center: The center refers to the location of a GeoLocation point and center: The center refers to the location of a GeoLocation point and
is represented as the center of an ellipse. is represented as the center of an ellipse.
latitude, longitude: Floating-point numbers that express the latitude, longitude: Floating-point numbers that express the
latitude and longitude in degrees using the WGS84 datum [WGS-84]. latitude and longitude in degrees using the WGS84 datum [WGS-84].
semiMajorAxis, semiMinorAxis: This OPTIONAL parameter expresses the semiMajorAxis, semiMinorAxis: This OPTIONAL parameter expresses the
location uncertainty, expressed in meters. It is parameterized location uncertainty, in meters. It is parameterized using
using distances along the major and minor axes of the ellipse. distances along the major and minor axes of the ellipse. The
The default value for each parameter is 0. default value for each parameter is 0.
orientation: This defines the orientation of the ellipse, expressed orientation: This defines the orientation of the ellipse, expressed
as the rotation, in degrees, of the semi-major axis from North as the rotation, in degrees, of the semi-major axis from North
towards the East. For example, when the uncertainty is greatest towards the East. For example, when the uncertainty is greatest
along the North-South direction, orientation is 0 degrees; along the North-South direction, orientation is 0 degrees;
conversely, if the uncertainty is greatest along the East-West conversely, if the uncertainty is greatest along the East-West
direction, orientation is 90 degrees. When orientation is not direction, orientation is 90 degrees. When orientation is not
present, the default value is 0. present, the default value is 0.
exterior: When GeoLocation describes a region, the "exterior" exterior: When GeoLocation describes a region, the "exterior"
parameter refers to a list of latitude/longitude points that parameter refers to a list of latitude and longitude points that
represents the vertices of a polygon. The first and last points represents the vertices of a polygon. The first and last points
MUST be the same. Thus, a minimum of 4 points is required. The MUST be the same. Thus, a minimum of 4 points is required. The
following polygon restrictions from [RFC5491] apply: following polygon restrictions from [RFC5491] apply:
* A connecting line MUST NOT cross another connecting line of the * A connecting line SHALL NOT cross another connecting line of
same polygon. the same polygon.
* The vertices MUST be defined in a counter-clockwise direction, * The vertices MUST be defined in a counter-clockwise direction,
looking at them from above. looking at them from above.
* The edges of a polygon are defined by the shortest path between * The edges of a polygon are defined by the shortest path between
two points in space (not a geodesic curve). Consequently, the two points in space (not a geodesic curve). Consequently, the
length between two adjacent vertices SHOULD be restricted to a length between two adjacent vertices SHOULD be restricted to a
maximum of 130 km. maximum of 130 km.
* All vertices are assumed to be at the same altitude.
* Polygon shapes SHOULD be restricted to a maximum of 15 vertices * Polygon shapes SHOULD be restricted to a maximum of 15 vertices
(16 points that includes the repeated vertex). (16 points that includes the repeated vertex).
Additionally, all vertices are assumed to be at the same altitude.
confidence: The location confidence level, as a percentage, MAY be confidence: The location confidence level, as a percentage, MAY be
provided. When this parameter is not provided, the default value provided. When this parameter is not provided, the default value
is 95. Valid values range from 0 to 100, but, in practice, is 95. Valid values range from 0 to 100, but, in practice, 100%
100-percent confidence is not achievable. The confidence value is confidence is not achievable. The confidence value is meaningful
meaningful only when GeoLocation refers to a point with only when GeoLocation refers to a point with uncertainty.
uncertainty.
5.2. DeviceDescriptor 5.2. DeviceDescriptor
The device descriptor contains parameters that identify the specific The device descriptor contains parameters that identify the specific
device, such as its manufacturer serial number, manufacturer's ID, device, such as its manufacturer serial number, manufacturer's ID,
and any other device characteristics required by ruleset. and any other device characteristics required by ruleset.
+--------------------------------+ +--------------------------------+
|DeviceDescriptor | |DeviceDescriptor |
+---------------------+----------+ +---------------------+----------+
|serialNumber:string | optional | |serialNumber:string | OPTIONAL |
|manufacturerId:string| optional | |manufacturerId:string| OPTIONAL |
|modelId:string | optional | 1..* |modelId:string | OPTIONAL | 1..*
|rulesetIds:list | optional |------>string |rulesetIds:list | OPTIONAL |------>string
|.....................|..........| |.....................|..........|
|*other:any | optional | |*other:any | OPTIONAL |
+---------------------+----------+ +---------------------+----------+
Parameters: Parameters:
serialNumber: The manufacturer's device serial number is OPTIONAL, serialNumber: The manufacturer's device serial number is OPTIONAL,
although rulesets typically require it. Its maximum length is 64 although rulesets typically require it. Its maximum length is 64
octets. octets.
manufacturerId: The manufacturer's ID is OPTIONAL, but may be manufacturerId: The manufacturer's ID is OPTIONAL but may be
required by some rulesets. This represents the name of the device required by some rulesets. This represents the name of the device
manufacturer, and therefore ought to be consistent across all manufacturer, and therefore ought to be consistent across all
devices from the same manufacturer and distinct from that of other devices from the same manufacturer and distinct from that of other
manufacturers. Its maximum length is 64 octets. manufacturers. Its maximum length is 64 octets.
modelId: The device's model ID is OPTIONAL, but may be required by modelId: The device's model ID is OPTIONAL but may be required by
some rulesets. Its maximum length is 64 octets. some rulesets. Its maximum length is 64 octets.
rulesetIds: The list of identifiers for rulesets supported by the rulesetIds: The list of identifiers for rulesets supported by the
device (see Ruleset ID Registry (Section 9.1)). A Database MAY device (see Ruleset ID Registry (Section 9.1)). A Database MAY
require that the device provides this list before servicing the require that the device provides this list before servicing the
device requests. If the Database supports none of the rulesets device requests. If the Database supports none of the rulesets
specified in the list, the Database MAY refuse to service the specified in the list, the Database MAY refuse to service the
device requests. See RulesetInfo (Section 5.6) for discussion on device requests. See RulesetInfo (Section 5.6) for discussion on
ruleset identifier. If present, the list MUST contain at least ruleset identifiers. If present, the list MUST contain at least
one entry. one entry.
other: Depending on the ruleset, other parameters may be required. other: Depending on the ruleset, other parameters may be required.
The Database MUST ignore all parameters in the message it does not The Database MUST ignore all parameters in the message it does not
understand. See PAWS Parameters Registry (Section 9.2) for understand. See PAWS Parameters Registry (Section 9.2) for
additional valid parameters and for the process for extending the additional valid parameters and for the process for extending the
message with more parameters. Additionally, see PAWS Ruleset ID message with more parameters. Additionally, see PAWS Ruleset ID
Registry (Section 9.1) for the valid set of parameters for each Registry (Section 9.1) for the valid set of parameters for each
ruleset. ruleset.
skipping to change at page 36, line 26 skipping to change at page 38, line 16
Antenna characteristics provide additional information, such as the Antenna characteristics provide additional information, such as the
antenna height, antenna type, etc. Whether antenna characteristics antenna height, antenna type, etc. Whether antenna characteristics
must be provided in a request depends on the device type and ruleset. must be provided in a request depends on the device type and ruleset.
Additionally, a parameter marked as optional may be required by some Additionally, a parameter marked as optional may be required by some
rulesets. rulesets.
+------------------------------------+ +------------------------------------+
|AntennaCharacteristics | |AntennaCharacteristics |
+-------------------------+----------+ +-------------------------+----------+
|height:float | optional | |height:float | OPTIONAL |
|heightType:enum | optional | |heightType:enum | OPTIONAL |
|heightUncertainty:float | optional | |heightUncertainty:float | OPTIONAL |
|.........................|..........| |.........................|..........|
|*characteristics: | optional | |*characteristics: | OPTIONAL |
| various | | | various | |
+-------------------------+----------+ +-------------------------+----------+
Parameters: Parameters:
height: The antenna height in meters. Note that the height may be height: The antenna height in meters. Note that the height may be
negative. negative.
heightType: Valid values are: heightType: Valid values are:
AGL Above ground level (default) AGL - Above Ground Level (default)
AMSL Above mean sea level AMSL - Above Mean Sea Level
heightUncertainty: The height uncertainty in meters. heightUncertainty: The height uncertainty in meters.
NOTE: Depending on the ruleset, additional antenna characteristics NOTE: Depending on the ruleset, additional antenna characteristics
may be required, such as: may be required, such as:
o antenna direction o antenna direction
o antenna radiation pattern o antenna radiation pattern
o antenna gain o antenna gain
o antenna polarization o antenna polarization
These are not defined by the base protocol, but may be added to the These are not defined by the base protocol but may be added to the
PAWS Parameters Registry (Section 9.2), as needed. PAWS Parameters Registry, as needed.
5.4. DeviceCapabilities 5.4. DeviceCapabilities
Device capabilities provide additional information that may be used Device capabilities provide additional information that may be used
by the device to provide additional information to the Database that by the device to provide additional information to the Database that
can help it to determine available spectrum. If the Database does can help it to determine available spectrum. If the Database does
not support device capabilities it MUST ignore the parameter not support device capabilities, it MUST ignore the parameter
altogether. altogether.
+-------------------------------+ +-------------------------------+
|DeviceCapabilities | |DeviceCapabilities |
+---------------------+---------+ +---------------------+---------+
|frequencyRanges:list |optional |--+ |frequencyRanges:list |OPTIONAL |--+
|.....................|.........| | |.....................|.........| |
|*other:any |optional | | |*other:any |OPTIONAL | |
+---------------------+---------+ | 0..* +---------------------+---------+ | 0..*
V V
+--------------------------------+ +--------------------------------+
|FrequencyRange | |FrequencyRange |
+----------------------+---------+ +----------------------+---------+
|startHz:float |required | |startHz:float |REQUIRED |
|stopHz:float |required | |stopHz:float |REQUIRED |
+----------------------+---------+ +----------------------+---------+
Parameters: Parameters:
frequencyRanges: Optional FrequencyRange (Section 5.13) list. Each frequencyRanges: Optional FrequencyRange (Section 5.13) list. Each
FrequencyRange element contains start and stop frequencies in FrequencyRange element contains start and stop frequencies in
which the device can operate. When specified, the Database SHOULD which the device can operate. When specified, the Database SHOULD
NOT return available spectrum that falls outside these ranges. NOT return available spectrum that falls outside these ranges.
other Consult the PAWS Parameters Registry (Section 9.2) for other Consult the PAWS Parameters Registry (Section 9.2) for
skipping to change at page 38, line 8 skipping to change at page 39, line 48
5.5. DeviceOwner 5.5. DeviceOwner
DeviceOwner contains information on device ownership that is provided DeviceOwner contains information on device ownership that is provided
as part of device registration. Some rulesets may require additional as part of device registration. Some rulesets may require additional
parameters. parameters.
+-----------------------------+ +-----------------------------+
|DeviceOwner | |DeviceOwner |
+------------------+----------+ +------------------+----------+
|owner:vcard | required | |owner:vcard | REQUIRED |
|operator:vcard | optional | |operator:vcard | OPTIONAL |
+------------------+----------+ +------------------+----------+
Parameters: Parameters:
owner: The vCard contact information for the individual or business owner: The vCard contact information for the individual or business
that owns the device is REQUIRED. that owns the device is REQUIRED.
operator: The vCard contact information for the device operator is operator: The vCard contact information for the device operator is
OPTIONAL, but may be required by specific rulesets. OPTIONAL but may be required by specific rulesets.
See PAWS Ruleset ID Registry (Section 9.1) for ruleset-specific See PAWS Ruleset ID Registry (Section 9.1) for ruleset-specific
requirements on mandatory vCard properties. Depending on the requirements on mandatory vCard properties. Depending on the
ruleset, the Database may be required to validate the device-owner ruleset, the Database may be required to validate the device-owner
information. In these cases, the Database MUST respond with an information. In these cases, the Database MUST respond with an
INVALID_VALUE error (see Error Codes (Section 5.17)) if validation INVALID_VALUE error (see "Error Codes" (Section 5.17)) if validation
fails. fails.
All contact information MUST be expressed using the structure defined All contact information MUST be expressed using the structure defined
by the "vCard Format Specification" [RFC6350], encoded in JSON by the "vCard Format Specification" [RFC6350], encoded in JSON
[RFC7095]. Note that the vCard specification defines maximum lengths [RFC7095]. Note that the vCard specification defines maximum lengths
for each parameter. for each parameter.
5.6. RulesetInfo 5.6. RulesetInfo
RulesetInfo contains parameters for the ruleset of a regulatory RulesetInfo contains parameters for the ruleset of a regulatory
domain that is communicated using the Initialization component domain that is communicated using the Initialization (Section 4.3),
(Section 4.3), Device Registration (Section 4.4), and Available Device Registration (Section 4.4), and Available Spectrum Query
Spectrum Query (Section 4.5) components. (Section 4.5) components.
+------------------------------------------+ +------------------------------------------+
|RulesetInfo | |RulesetInfo |
+------------------------------------------+ +------------------------------------------+
|authority:string | required | |authority:string | REQUIRED |
|rulesetId:string | required | |rulesetId:string | REQUIRED |
|maxLocationChange:float | see description | |maxLocationChange:float | see description |
|maxPollingSecs:int | see description | |maxPollingSecs:int | see description |
|..........................................| |..........................................|
|*other:any | optional | |*other:any | OPTIONAL |
+------------------------+-----------------+ +------------------------+-----------------+
Parameters: Parameters:
authority: A string that indicates the regulatory domain to which authority: A string that indicates the regulatory domain to which
the ruleset applies is REQUIRED. It will normally be a 2-letter the ruleset applies is REQUIRED. It will normally be a 2-letter
country code defined by Country Codes - ISO 3166 [ISO3166-1]. country code defined by Country Codes - ISO 3166 [ISO3166-1].
rulesetId: The ID of a ruleset for the specified authority (see rulesetId: The ID of a ruleset for the specified authority (see
Ruleset ID Registry (Section 9.1)). The device can use this to Ruleset ID Registry (Section 9.1)). The device can use this to
determine additional device behavior required by the associated determine additional device behavior required by the associated
ruleset. To define new ruleset IDs, see Defining Ruleset ruleset. To define new ruleset IDs, see "Defining Ruleset
Identifiers (Section 8.1). Identifiers" (Section 8.1).
maxLocationChange: The maximum location change in meters is REQUIRED maxLocationChange: The maximum location change in meters is REQUIRED
for Initialization Response (Section 4.3.2), but OPTIONAL for the Initialization Response (Section 4.3.2), but OPTIONAL
otherwise. Some regulatory domains mandate that, when the device otherwise. Some regulatory domains mandate that, when the device
changes location by more than this specified distance, it contact changes location by more than this specified distance, it contact
the Database to get the available spectrum for the new location. the Database to get the available spectrum for the new location.
If this value is provided by the Database within the context of an If this value is provided by the Database within the context of an
Available Spectrum Response (Section 4.5.2), it takes precedence Available Spectrum Response (Section 4.5.2), it takes precedence
over the value within the Initialization Response (Section 4.3.2). over the value within the Initialization Response (Section 4.3.2).
maxPollingSecs: The maximum duration, in seconds, between requests maxPollingSecs: The maximum duration, in seconds, between requests
for available spectrum is REQUIRED for the Initialization Response for available spectrum is REQUIRED for the Initialization Response
(Section 4.3.2), but OPTIONAL otherwise. The device MUST contact (Section 4.3.2), but OPTIONAL otherwise. The device MUST contact
the Database to get available spectrum no less frequently than the Database to get available spectrum no less frequently than
this duration. If this value is provided within the context of an this duration. If this value is provided within the context of an
Available Spectrum Response (Section 4.5.2), it takes precedence Available Spectrum Response (Section 4.5.2), it takes precedence
over the value within the Initialization Response (Section 4.3.2). over the value within the Initialization Response (Section 4.3.2).
other: Depending on the ruleset, other parameters may be required. other: Depending on the ruleset, other parameters may be required.
Devices MUST ignore all parameters in the message it does not The device MUST ignore all parameters in the message it does not
understand. Consult the PAWS Parameters Registry (Section 9.2) understand. Consult the PAWS Parameters Registry (Section 9.2)
for possible additional parameters. for possible additional parameters.
5.7. DbUpdateSpec 5.7. DbUpdateSpec
This element is provided by the Database to notify devices of an This element is provided by the Database to notify devices of an
upcoming change to the Database URI. upcoming change to the database URI.
+-------------------------------+ +-------------------------------+
|DbUpdateSpec | |DbUpdateSpec |
+---------------------+---------+ +--------------------------+ +---------------------+---------+ +--------------------------+
|databases:list |required |------>|DatabaseSpec | |databases:list |REQUIRED |------>|DatabaseSpec |
+---------------------+---------+ 1..* +---------------+----------+ +---------------------+---------+ 1..* +---------------+----------+
|name:string | required | |name:string | REQUIRED |
|uri:string | required | |uri:string | REQUIRED |
+---------------+----------+ +---------------+----------+
Parameters: Parameters:
databases: List of one or more DatabaseSpec (Section 5.8) entries. databases: List of one or more DatabaseSpec (Section 5.8) entries.
A device needs to update its preconfigured entry for the A device needs to update its preconfigured entry for the
responding database with the alternate databases listed in the responding Database with the alternate Databases listed in the
DbUpdateSpec. DbUpdateSpec.
5.8. DatabaseSpec 5.8. DatabaseSpec
This element contains the name and URI of a database. This element contains the name and URI of a Database.
+--------------------------+ +--------------------------+
|DatabaseSpec | |DatabaseSpec |
+---------------+----------+ +---------------+----------+
|name:string | required | |name:string | REQUIRED |
|uri:string | required | |uri:string | REQUIRED |
+---------------+----------+ +---------------+----------+
Parameters: Parameters:
name: The display name. Its maximum length is 64 octets. name: The display name. Its maximum length is 64 octets.
uri: The corresponding URI of the database. Its maximum length is uri: The corresponding URI of the Database. Its maximum length is
1024 octets. 1024 octets.
5.9. SpectrumSpec 5.9. SpectrumSpec
The SpectrumSpec element encapsulates the schedule of available The SpectrumSpec element encapsulates the schedule of available
spectrum for a ruleset. spectrum for a ruleset.
+---------------------------------------+ +---------------------------------------+
|SpectrumSpec | |SpectrumSpec |
+----------------------------+----------+ +----------------------------+----------+
|rulesetInfo:RulesetInfo | required | |rulesetInfo:RulesetInfo | REQUIRED |
|spectrumSchedules:list | required |-----+ |spectrumSchedules:list | REQUIRED |-----+
|timeRange:EventTime | optional | | |timeRange:EventTime | OPTIONAL | |
|frequencyRanges:list | optional | | |frequencyRanges:list | OPTIONAL | |
|needsSpectrumReport:boolean | optional | | |needsSpectrumReport:boolean | OPTIONAL | |
|maxTotalBwHz:float | optional | | |maxTotalBwHz:float | OPTIONAL | |
|maxContiguousBwHz:float | optional | | |maxContiguousBwHz:float | OPTIONAL | |
+----------------------------+----------+ | +----------------------------+----------+ |
| 1..* | 1..*
V V
+-------------------------------+ +-------------------------------+
|SpectrumSchedule | |SpectrumSchedule |
+--------------------+----------+ +--------------------+----------+
|eventTime:EventTime | required | |eventTime:EventTime | REQUIRED |
|spectra:list | required | |spectra:list | REQUIRED |
+--------------------+----------+ +--------------------+----------+
Parameters: Parameters:
rulesetInfo: RulesetInfo (Section 5.6) is REQUIRED to identify the rulesetInfo: RulesetInfo (Section 5.6) is REQUIRED to identify the
regulatory domain and ruleset to which the spectrum schedule regulatory domain and ruleset to which the spectrum schedule
applies (see Ruleset ID Registry (Section 9.1)). The device needs applies (see Ruleset ID Registry (Section 9.1)). The device needs
to use the corresponding ruleset to interpret the response. to use the corresponding ruleset to interpret the response.
Values provided within rulesetInfo, such as maxLocationChange, Values provided within rulesetInfo, such as maxLocationChange,
take precedence over the values provided by the Initialization take precedence over the values provided by the Initialization
skipping to change at page 41, line 26 skipping to change at page 43, line 26
REQUIRED. At least one schedule MUST be included. More than one REQUIRED. At least one schedule MUST be included. More than one
schedule MAY be included to represent future changes to the schedule MAY be included to represent future changes to the
available spectrum. How far in advance a schedule may be provided available spectrum. How far in advance a schedule may be provided
depends on the ruleset. If more than one schedule is included, depends on the ruleset. If more than one schedule is included,
the eventTime intervals MUST be disjoint and MUST be sorted in the eventTime intervals MUST be disjoint and MUST be sorted in
increasing time. A gap in the time schedule indicates no increasing time. A gap in the time schedule indicates no
available spectrum during that time-interval gap. available spectrum during that time-interval gap.
timeRange: The time range for which the specification is timeRange: The time range for which the specification is
comprehensive is OPTIONAL. When specified, any gaps in time comprehensive is OPTIONAL. When specified, any gaps in time
intervals within the "spectrumSchedules" element that overlaps intervals within the spectrumSchedules element that overlap with
with the range specified by "timeRange" are interpreted by the the range specified by "timeRange" are interpreted by the device
device as time intervals in which there is no available spectrum. as time intervals in which there is no available spectrum.
frequencyRanges: The frequency ranges for which the specification is frequencyRanges: Specifying the frequency ranges for which the
comprehensive is OPTIONAL. It is a list of disjoint specification is comprehensive is OPTIONAL. It is a list of
FrequencyRange (Section 5.13) entries. When specified, it disjoint FrequencyRange (Section 5.13) entries. When specified,
typically corresponds to the frequency ranges governed by the it typically corresponds to the frequency ranges governed by the
ruleset, e.g., for TV whitespace, the frequency ranges can ruleset, e.g., for TV white space, the frequency ranges can
correspond to the VHF and UHF bands of the associated regulatory correspond to the VHF and UHF bands of the associated regulatory
domain. A device can combine this information with the available- domain. A device can combine this information with the available-
spectrum specification within the "spectrumSchedules" element to spectrum specification within the spectrumSchedules element to
distinguish between "unavailable spectrum" and "spectrum for which distinguish between "unavailable spectrum" and "spectrum for which
no information has been provided". no information has been provided".
needsSpectrumReport: The Database MAY return true for this parameter needsSpectrumReport: The Database MAY return true for this parameter
if spectrumSchedules list is non-empty; otherwise, the Database if spectrumSchedules list is non-empty; otherwise, the Database
MAY omit this parameter altogether, in which case, the default MAY omit this parameter altogether, in which case, the default
value is false. If this parameter is present and its value is value is false. If this parameter is present and its value is
true, the device sends a SPECTRUM_USE_NOTIFY (Section 4.5.5) true, the device sends a SPECTRUM_USE_NOTIFY (Section 4.5.5)
message to the Database; otherwise, the device SHOULD NOT send the message to the Database; otherwise, the device SHOULD NOT send the
SPECTRUM_USE_NOTIFY message. Some rulesets mandate this value to SPECTRUM_USE_NOTIFY message. Some rulesets mandate this value be
be true. set to true.
maxTotalBwHz: The Database MAY return a constraint on the maximum maxTotalBwHz: The Database MAY return a constraint on the maximum
total bandwidth (in Hertz) allowed, which may or may not be total bandwidth (in hertz) allowed, which may or may not be
contiguous. Some rulesets mandate the Database to return this contiguous. Some rulesets mandate the Database to return this
parameter. When present in the response, the device needs to parameter. When present in the response, the device needs to
apply this constraint to its spectrum-selection logic to ensure apply this constraint to its spectrum-selection logic to ensure
total bandwidth does not exceed this value. total bandwidth does not exceed this value.
maxContiguousBwHz: The Database MAY return a constraint on the maxContiguousBwHz: The Database MAY return a constraint on the
maximum contiguous bandwidth (in Hertz) allowed. Some rulesets maximum contiguous bandwidth (in hertz) allowed. Some rulesets
mandate the Database to return this parameter. When present in mandate the Database to return this parameter. When present in
the response, the device needs to apply this constraint to its the response, the device needs to apply this constraint to its
spectrum-selection logic to ensure no single block of spectrum has spectrum-selection logic to ensure no single block of spectrum has
bandwidth that exceeds this value. bandwidth that exceeds this value.
5.10. SpectrumSchedule 5.10. SpectrumSchedule
The SpectrumSchedule element combines EventTime (Section 5.14) with The SpectrumSchedule element combines EventTime (Section 5.14) with
Spectrum (Section 5.11) to define a time period in which the spectrum Spectrum (Section 5.11) to define a time period in which the spectrum
is valid. is valid.
+-------------------------------+ +-------------------------------+
|SpectrumSchedule | |SpectrumSchedule |
+--------------------+----------+ +--------------------+----------+
|eventTime:EventTime | required | +--------------------+ |eventTime:EventTime | REQUIRED | +--------------------+
|spectra:list | required |------->|Spectrum | |spectra:list | REQUIRED |------->|Spectrum |
+--------------------+----------+ 0..* +--------------------+ +--------------------+----------+ 0..* +--------------------+
|resolutionBwHz:float| |resolutionBwHz:float|
|profiles:list | |profiles:list |
+--------------------+ +--------------------+
Parameters: Parameters:
eventTime: The EventTime (Section 5.14) is REQUIRED to express eventTime: The EventTime (Section 5.14) is REQUIRED to express
"when" this specification is valid. "when" this specification is valid.
skipping to change at page 42, line 49 skipping to change at page 45, line 5
spectrum. spectrum.
5.11. Spectrum 5.11. Spectrum
Available spectrum can be characterized by an ordered list of Available spectrum can be characterized by an ordered list of
spectrum profiles that defines permissible power levels over a set of spectrum profiles that defines permissible power levels over a set of
frequency ranges. Each Spectrum element defines permissible power frequency ranges. Each Spectrum element defines permissible power
levels as maximum power spectral densities over a specified levels as maximum power spectral densities over a specified
resolution bandwidth, "resolutionBwHz". Note that the spectrum resolution bandwidth, "resolutionBwHz". Note that the spectrum
profiles represent the "availability mask", as defined by the profiles represent the "availability mask", as defined by the
governing rule set; they are not intended to encode device-level governing ruleset; they are not intended to encode device-level
transmission-mask requirements. transmission-mask requirements.
NOTE: Within the contexts of the AVAIL_SPECTRUM_RESP (Section 4.5.2), NOTE: Within the contexts of the AVAIL_SPECTRUM_RESP (Section 4.5.2),
AVAIL_SPECTRUM_BATCH_RESP (Section 4.5.4), and SPECTRUM_USE_NOTIFY AVAIL_SPECTRUM_BATCH_RESP (Section 4.5.4), and SPECTRUM_USE_NOTIFY
(Section 4.5.5) messages, the power levels expressed within the (Section 4.5.5) messages, the power levels expressed within the
Spectrum messages refer to EIRP. Future extensions of PAWS may use Spectrum messages refer to EIRP. Future extensions of PAWS may use
Spectrum in other contexts for other definitions of power levels. Spectrum in other contexts for other definitions of power levels.
o To support a ruleset that defines different "wide-band" and o To support a ruleset that defines different "wide-band" and
"narrow-band" power levels, PAWS allows multiple Spectrum elements "narrow-band" power levels, PAWS allows multiple Spectrum elements
skipping to change at page 44, line 8 skipping to change at page 46, line 8
o Gaps in frequencies between consecutive spectrum profiles o Gaps in frequencies between consecutive spectrum profiles
represent unavailability for those frequencies. represent unavailability for those frequencies.
The following figure illustrates the Spectrum element and the The following figure illustrates the Spectrum element and the
SpectrumProfile list. SpectrumProfile list.
+-------------------------------+ +-------------------------------+
|Spectrum | |Spectrum |
+---------------------+---------+ +---------------------+---------+
|resolutionBwHz:float |required | |resolutionBwHz:float |REQUIRED |
|profiles:list |required |---+ |profiles:list |REQUIRED |---+
+---------------------+---------+ | 0..* +---------------------+---------+ | 0..*
V V
+-----------------------------+ +-----------------------------+
|SpectrumProfile | |SpectrumProfile |
+-------------------+---------+ +-------------------+---------+
|list |required | |list |REQUIRED |
+-------------------+---------+ +-------------------+---------+
| |
V 2..* V 2..*
+--------------------------+ +--------------------------+
|SpectrumProfilePoint | |SpectrumProfilePoint |
+----------------+---------+ +----------------+---------+
|hz:float |required | |hz:float |REQUIRED |
|dbm:float |required | |dbm:float |REQUIRED |
+----------------+---------+ +----------------+---------+
Parameters: Parameters:
resolutionBwHz: This parameter defines the resolution bandwidth (in resolutionBwHz: This parameter defines the resolution bandwidth (in
Hertz) over which permissible power spectral density is defined. hertz) over which permissible power spectral density is defined.
For example, FCC regulation would require one spectrum For example, FCC regulation would require one spectrum
specification at a bandwidth of 6MHz, and ETSI regulation would specification at a bandwidth of 6 MHz, and ETSI regulation would
require two specifications, at 0.1MHz and 8MHz. require two specifications, at 0.1 MHz and 8 MHz.
profiles: A SpectrumProfile (Section 5.12) list specifies profiles: A SpectrumProfile (Section 5.12) list specifies
permissible power levels over a set of frequency ranges. The list permissible power levels over a set of frequency ranges. The list
MAY be empty if there is no available spectrum. MAY be empty if there is no available spectrum.
The following example shows permitted power spectral densities for a The following example shows permitted power spectral densities for a
single resolution bandwidth of 6MHz (for illustrative purposes only): single resolution bandwidth of 6 MHz (for illustrative purposes
only):
[ [
{ {
"resolutionBwHz": 6e6, "resolutionBwHz": 6e6,
"profiles": [ "profiles": [
[ [
{"hz": 5.18e8, "dbm": 30.0}, {"hz": 5.18e8, "dbm": 30.0},
{"hz": 5.30e8, "dbm": 30.0} {"hz": 5.30e8, "dbm": 30.0}
], ],
... ...
skipping to change at page 45, line 4 skipping to change at page 47, line 21
"resolutionBwHz": 6e6, "resolutionBwHz": 6e6,
"profiles": [ "profiles": [
[ [
{"hz": 5.18e8, "dbm": 30.0}, {"hz": 5.18e8, "dbm": 30.0},
{"hz": 5.30e8, "dbm": 30.0} {"hz": 5.30e8, "dbm": 30.0}
], ],
... ...
] ]
} }
] ]
This is interpreted as: This is interpreted as:
o Over any 6MHz within the frequency range, [518MHz, 530MHz), o Over any 6 MHz within the frequency range [518 MHz, 530 MHz),
maximum permitted power is 30.0dBm (1000mW) maximum permitted power is 30.0 dBm (1000 mW)
Consider now an example with two different sets of permitted power Consider now an example with two different sets of permitted power
spectral densities for the same set of frequencies over different spectral densities for the same set of frequencies over different
resolution bandwidths (for illustrative purposes only): resolution bandwidths (for illustrative purposes only):
[ [
{ {
"resolutionBwHz": 6e6, "resolutionBwHz": 6e6,
"profiles": [ "profiles": [
[ [
skipping to change at page 45, line 35 skipping to change at page 48, line 4
"resolutionBwHz": 1e5, "resolutionBwHz": 1e5,
"profiles": [ "profiles": [
[ [
{"hz": 5.18e8, "dbm": 27.0}, {"hz": 5.18e8, "dbm": 27.0},
{"hz": 5.30e8, "dbm": 27.0} {"hz": 5.30e8, "dbm": 27.0}
], ],
... ...
] ]
} }
] ]
This is interpreted as: This is interpreted as:
o Over any 6MHz within the frequency range, [518MHz, 530MHz), o Over any 6 MHz within the frequency range [518 MHz, 530 MHz),
maximum permitted power is 30.0dBm (1000mW), and maximum permitted power is 30.0 dBm (1000 mW), and
o Over any 100 kHz within the frequency range, [518MHz, 530MHz), o Over any 100 kHz within the frequency range [518 MHz, 530 MHz),
maximum permitted power is 27.0dBm (500mW) maximum permitted power is 27.0 dBm (500 mW)
This would allow, for example, operating two 100kHz sub-channels This would allow, for example, operating two 100 kHz sub-channels
within the indicated 12MHz range at 500mW each, totaling 1000mW. Of within the indicated 12 MHz range at 500 mW each, totaling 1000 mW.
course, many combinations are possible, as long as they satisfy both Of course, many combinations are possible, as long as they satisfy
conditions. both conditions.
The following example encodes multiple (two) spectrum profiles, each The following example encodes multiple (two) spectrum profiles, each
having a gap from 530 MHz to 536 MHz (for illustrative purposes having a gap from 530 MHz to 536 MHz (for illustrative purposes
only): only):
[ [
{ {
"resolutionBwHz": 6e6, "resolutionBwHz": 6e6,
"profiles": [ "profiles": [
[ [
skipping to change at page 47, line 17 skipping to change at page 50, line 31
o The first frequency is inclusive; the last frequency is exclusive. o The first frequency is inclusive; the last frequency is exclusive.
NOTE: This encoding allows presentation of "ramps" where the slope of NOTE: This encoding allows presentation of "ramps" where the slope of
a line segment may be finite and non-zero. a line segment may be finite and non-zero.
The following figure illustrates the SpectrumProfile element. The following figure illustrates the SpectrumProfile element.
+-------------------------------+ +-------------------------------+
|SpectrumProfile | |SpectrumProfile |
+---------------------+---------+ +---------------------+---------+
|list |required |---+ |list |REQUIRED |---+
+---------------------+---------+ | 2..* +---------------------+---------+ | 2..*
V V
+--------------------------+ +--------------------------+
|SpectrumProfilePoint | |SpectrumProfilePoint |
+----------------+---------+ +----------------+---------+
|hz:float |required | |hz:float |REQUIRED |
|dbm:float |required | |dbm:float |REQUIRED |
+----------------+---------+ +----------------+---------+
Parameters of each point in the profile: Parameters of each point in the profile:
hz: The frequency, in Hertz, at which the power level is defined. hz: The frequency, in hertz, at which the power level is defined.
dbm: The power level, expressed as dBm per resolution bandwidth, as dbm: The power level, expressed as dBm per resolution bandwidth, as
defined by the "resolutionBwHz" element of the enclosing Spectrum defined by the resolutionBwHz element of the enclosing Spectrum
(Section 5.11) element. (Section 5.11) element.
5.13. FrequencyRange 5.13. FrequencyRange
FrequencyRange specifies a frequency range. FrequencyRange specifies a frequency range.
+--------------------------------+ +--------------------------------+
|FrequencyRange | |FrequencyRange |
+----------------------+---------+ +----------------------+---------+
|startHz:float |required | |startHz:float |REQUIRED |
|stopHz:float |required | |stopHz:float |REQUIRED |
+----------------------+---------+ +----------------------+---------+
Parameters: Parameters:
startHz: The inclusive start of the frequency range (in Hertz) is startHz: The inclusive start of the frequency range (in hertz) is
REQUIRED. REQUIRED.
stopHz: The exclusive end of the frequency range (in Hertz) is stopHz: The exclusive end of the frequency range (in hertz) is
REQUIRED. REQUIRED.
5.14. EventTime 5.14. EventTime
The EventTime element specifies the start and stop times of an The EventTime element specifies the start and stop times of an
"event". This is used to indicate the time period for which a "event". This is used to indicate the time period for which a
Spectrum (Section 5.11) is valid. Spectrum (Section 5.11) is valid.
+---------------------------+ +---------------------------+
|EventTime | |EventTime |
+-----------------+---------+ +-----------------+---------+
|startTime:string |required | |startTime:string |REQUIRED |
|stopTime:string |required | |stopTime:string |REQUIRED |
+-----------------+---------+ +-----------------+---------+
Parameters: Parameters:
startTime: The inclusive start of the event is REQUIRED. startTime: The inclusive start of the event is REQUIRED.
stopTime: The exclusive end of the event is REQUIRED. stopTime: The exclusive end of the event is REQUIRED.
Both times are expressed using the format, YYYY-MM-DDThh:mm:ssZ, as Both times are expressed using the format, YYYY-MM-DDThh:mm:ssZ, as
defined by "Date and Time on the Internet: Timestamps" [RFC3339]. defined by "Date and Time on the Internet: Timestamps" [RFC3339].
The times MUST be expressed using UTC. The times MUST be expressed using UTC.
A device that does not have access to the current date and time MUST A device that does not have access to the current date and time MUST
use the timestamp at the top-level of the response message as a use the timestamp at the top level of the response message as a
substitute for the current time (see Available Spectrum Response substitute for the current time (see "Available Spectrum Response"
(Section 4.5.2) and Available Spectrum Batch Response (Section 4.5.2) and "Available Spectrum Batch Response"
(Section 4.5.4)). E.g., (Section 4.5.4)). For example,
o (startTime - timestamp) gives the duration that a device must wait o (startTime - timestamp) gives the duration that a device must wait
before the event becomes "active". If the value is zero or before the event becomes "active". If the value is zero or
negative, the event is already active. negative, the event is already active.
o If the event is already active, (stopTime - timestamp) is the o If the event is already active, (stopTime - timestamp) is the
duration that the event remains active. If the value is zero or duration that the event remains active. If the value is zero or
negative, the event is no longer active and MUST be ignored. negative, the event is no longer active and MUST be ignored.
5.15. GeoSpectrumSpec 5.15. GeoSpectrumSpec
The GeoSpectrumSpec element encapsulates the available spectrum for a The GeoSpectrumSpec element encapsulates the available spectrum for a
location. It is returned within a AVAIL_SPECTRUM_BATCH_RESP location. It is returned within an AVAIL_SPECTRUM_BATCH_RESP
(Section 4.5.4) batch response that contains multiple GeoSpectrumSpec (Section 4.5.4) batch response that contains multiple GeoSpectrumSpec
entries, each matching a location provided in the batch request. entries, each matching a location provided in the batch request.
+----------------------------------+ +----------------------------------+
|GeoSpectrumSpec | |GeoSpectrumSpec |
+-----------------------+----------+ +-----------------------+----------+
|location:GeoLocation | required | |location:GeoLocation | REQUIRED |
|spectrumSpecs:list | required |-------+ |spectrumSpecs:list | REQUIRED |-------+
+-----------------------+----------+ | +-----------------------+----------+ |
| 1..* | 1..*
V V
+--------------+ +--------------+
| SpectrumSpec | | SpectrumSpec |
+--------------+ +--------------+
Parameters: Parameters:
location: The GeoLocation (Section 5.1) identifies the location at location: The GeoLocation (Section 5.1) identifies the location at
skipping to change at page 49, line 35 skipping to change at page 53, line 13
included to support multiple rulesets at a location. included to support multiple rulesets at a location.
5.16. DeviceValidity 5.16. DeviceValidity
The DeviceValidity element is used to indicate whether a device is The DeviceValidity element is used to indicate whether a device is
valid. See Section 4.6.2. valid. See Section 4.6.2.
+---------------------------------------+ +---------------------------------------+
|DeviceValidity | |DeviceValidity |
+----------------------------+----------+ +----------------------------+----------+
|deviceDesc:DeviceDescriptor | required | |deviceDesc:DeviceDescriptor | REQUIRED |
|isValid:boolean | required | |isValid:boolean | REQUIRED |
|reason:string | optional | |reason:string | OPTIONAL |
+----------------------------+----------+ +----------------------------+----------+
Parameters: Parameters:
deviceDesc: The DeviceDescriptor (Section 5.2) that was used to deviceDesc: The DeviceDescriptor (Section 5.2) that was used to
check for validity is REQUIRED. check for validity is REQUIRED.
isValid: This is a REQUIRED boolean value that indicates whether the isValid: This is a REQUIRED boolean value that indicates whether the
device is valid. device is valid.
skipping to change at page 50, line 13 skipping to change at page 53, line 38
length is 128 octets. length is 128 octets.
5.17. Error Element 5.17. Error Element
If the Database responds to a PAWS request message with an error, it If the Database responds to a PAWS request message with an error, it
MUST include an Error element. MUST include an Error element.
+----------------------------------+ +----------------------------------+
|Error | |Error |
+----------------+-----------------+ +----------------+-----------------+
|code:int | required | |code:int | REQUIRED |
|message:string | optional | |message:string | OPTIONAL |
|data:any | see description | |data:any | see description |
+----------------+-----------------+ +----------------+-----------------+
Parameters: Parameters:
code: An integer code that indicates the error type is REQUIRED. code: An integer code that indicates the error type is REQUIRED.
Values MUST be within the range, -32768 to 32767, inclusive. Values MUST be within the range -32768 to 32767, inclusive.
message: A description of the error is OPTIONAL. It MAY be in any message: A description of the error is OPTIONAL. It MAY be in any
language. Its maximum length is 128 octets. language. Its maximum length is 128 octets.
data: The Database MAY include additional data. For some errors, data: The Database MAY include additional data. For some errors,
additional data may be required (see Table 1). The device MUST additional data may be required (see Table 1). The device MUST
ignore any data parameters it does not understand. ignore any data parameters it does not understand.
The following table lists predefined and reserved error codes. They The following table lists predefined and reserved error codes. They
are loosely grouped into the following categories: are loosely grouped into the following categories:
skipping to change at page 50, line 45 skipping to change at page 54, line 24
-200s: Indicates that the device request contains an error that -200s: Indicates that the device request contains an error that
needs to be modified before making another request. needs to be modified before making another request.
-300s: Indicates authorization-related issues. -300s: Indicates authorization-related issues.
Values that are not defined explicitly in the Error Codes Values that are not defined explicitly in the Error Codes
Table (Table 1) below are unassigned. To define new error codes, see Table (Table 1) below are unassigned. To define new error codes, see
PAWS Error Code Registry (Section 9.3). PAWS Error Code Registry (Section 9.3).
Code Name Description & Additional parameters Code Name Description and Additional Parameters
------ ---------------- --------------------------------------------- ------ ---------------- ---------------------------------------------
0 (reserved) 0 (reserved)
-100 (reserved) -100 (reserved)
-101 VERSION The Database does not support the specified -101 VERSION The Database does not support the specified
version of the message. This error does not version of the message. This error does not
use any additional data. use any additional data.
-102 UNSUPPORTED The Database does not support the device. For -102 UNSUPPORTED The Database does not support the device.
example, it supports none of the ruleset For example, it supports none of the rulesets
specified in the request or does not support specified in the request or does not support
the device, based on its device type, model, the device, based on its device type, model,
etc. This error does not use any additional etc. This error does not use any additional
data. data.
-103 UNIMPLEMENTED The Database does not implement the optional -103 UNIMPLEMENTED The Database does not implement the optional
request or optional feature. This error does request or optional feature. This error does
not use any additional data. not use any additional data.
-104 OUTSIDE_COVERAGE The specified geolocation is outside the -104 OUTSIDE_COVERAGE The specified geolocation is outside the
coverage area of the Database. The Database coverage area of the Database. The Database
MAY include a DbUpdateSpec (Section 5.7) to MAY include a DbUpdateSpec (Section 5.7) to
provide a list of alternate databases that provide a list of alternate Databases that
might be appropriate for the requested might be appropriate for the requested
location. See OUTSIDE_COVERAGE Error (Section location. See OUTSIDE_COVERAGE Error
5.17.1) for more details. (Section 5.17.1) for more details.
-105 DATABASE_CHANGE The Database has changed its URI. The
-105 DATABASE_CHANGE The Database has changed its URI. The
Database MAY include a DbUpdateSpec (Section Database MAY include a DbUpdateSpec (Section
5.7) in the error response to provide devices 5.7) in the error response to provide devices
with one or more alternate database URIs. The with one or more alternate database URIs.
device needs to update its preconfigured The device needs to update its preconfigured
entry for the responding database with the entry for the responding Database with the
alternate databases listed in the alternate Databases listed in the
DbUpdateSpec. See DATABASE_CHANGE Error DbUpdateSpec. See DATABASE_CHANGE Error
(Section 5.17.2) for more details. (Section 5.17.2) for more details.
-200 (reserved) -200 (reserved)
-201 MISSING A required parameter is missing. The Database -201 MISSING A required parameter is missing. The
MUST include a list of the required parameter Database MUST include a list of the required
names. The Database MAY include only names of parameter names. The Database MAY include
parameters that are missing, but MAY include only names of parameters that are missing,
a full list. Including the full list of but MAY include a full list. Including the
missing parameters may reduce the number of full list of missing parameters may reduce
re-queries from the device. See MISSING Error the number of re-queries from the device.
(Section 5.17.3) for more details. See MISSING Error (Section 5.17.3) for more
-202 INVALID_VALUE A parameter value is invalid in some way. The details.
Database SHOULD include a message indicating -202 INVALID_VALUE A parameter value is invalid in some way.
which parameter and why its value is invalid. The Database SHOULD include a message
This error does not use any additional data. indicating which parameter and why its value
is invalid. This error does not use any
additional data.
-300 (reserved) -300 (reserved)
-301 UNAUTHORIZED The device is not authorized to used the -301 UNAUTHORIZED The device is not authorized to used the
Database. Authorization may be determined by Database. Authorization may be determined
the ruleset or be dependent on prior by the ruleset or be dependent on prior
arrangement between the device and Database. arrangement between the device and Database.
This error does not use any additional data. This error does not use any additional data.
-302 NOT_REGISTERED Device registration required, but the device -302 NOT_REGISTERED Device registration required, but the device
is not registered. This error does not use is not registered. This error does not use
any additional data. any additional data.
-32000 (reserved) Reserved for JSON-RPC error codes. -32000 (reserved) Reserved for JSON-RPC error codes.
to to
-32768 -32768
Table 1: Error Codes Table 1: Error Codes
5.17.1. OUTSIDE_COVERAGE Error 5.17.1. OUTSIDE_COVERAGE Error
When the error code is OUTSIDE_COVERAGE, the Database MAY include an When the error code is OUTSIDE_COVERAGE, the Database MAY include an
ErrorData element within its Error response as the "data" parameter, ErrorData element within its Error response as the "data" parameter,
and, if present, the ErrorData contains a DbUpdateSpec (Section 5.7) and, if present, the ErrorData contains a DbUpdateSpec (Section 5.7)
element that provides a list of alternate databases that might be element that provides a list of alternate Databases that might be
appropriate for the requested location. appropriate for the requested location.
+---------------------------+ +---------------------------+
|Error | |Error |
+----------------+----------+ +----------------+----------+
|code:int | required | |code:int | REQUIRED |
|message:string | optional | +-----------------------------+ |message:string | OPTIONAL | +-----------------------------+
|data:ErrorData | optional |--->|ErrorData | |data:ErrorData | OPTIONAL |--->|ErrorData |
+----------------+----------+ +------------------+----------+ +----------------+----------+ +------------------+----------+
|spec:DbUpdateSpec | optional | |spec:DbUpdateSpec | OPTIONAL |
+------------------+----------+ +------------------+----------+
5.17.2. DATABASE_CHANGE Error 5.17.2. DATABASE_CHANGE Error
When the error code is DATABASE_CHANGE, the Database MAY include an When the error code is DATABASE_CHANGE, the Database MAY include an
ErrorData element within its Error response as the "data" parameter, ErrorData element within its Error response as the "data" parameter,
and, if present, the ErrorData contains a DbUpdateSpec (Section 5.7) and, if present, the ErrorData contains a DbUpdateSpec (Section 5.7)
element that provides a list of alternate databases. element that provides a list of alternate Databases.
+---------------------------+ +---------------------------+
|Error | |Error |
+----------------+----------+ +----------------+----------+
|code:int | required | |code:int | REQUIRED |
|message:string | optional | +-----------------------------+ |message:string | OPTIONAL | +-----------------------------+
|data:ErrorData | optional |--->|ErrorData | |data:ErrorData | OPTIONAL |--->|ErrorData |
+----------------+----------+ +------------------+----------+ +----------------+----------+ +------------------+----------+
|spec:DbUpdateSpec | required | |spec:DbUpdateSpec | REQUIRED |
+------------------+----------+ +------------------+----------+
5.17.3. MISSING Error 5.17.3. MISSING Error
When the error code is MISSING, the Database MUST include an When the error code is MISSING, the Database MUST include an
ErrorData element within its Error response as the "data" parameter, ErrorData element within its Error response as the "data" parameter,
and the ErrorData element MUST include a list of the missing required and the ErrorData element MUST include a list of the missing required
parameters and MAY include the list of all required parameters. parameters and MAY include the list of all required parameters.
+---------------------------+ +---------------------------+
|Error | |Error |
+----------------+----------+ +----------------+----------+
|code:int | required | |code:int | REQUIRED |
|message:string | optional | +---------------------------+ |message:string | OPTIONAL | +---------------------------+
|data:ErrorData | required |--->|ErrorData | |data:ErrorData | REQUIRED |--->|ErrorData |
+----------------+----------+ +----------------+----------+ 1..* +----------------+----------+ +----------------+----------+ 1..*
|parameters:list | required |--+ |parameters:list | REQUIRED |--+
+----------------+----------+ | +----------------+----------+ |
v v
string string
Parameters: Parameters:
parameters: List of one or more parameter names (strings). The name parameters: List of one or more parameter names (strings). The name
of a parameter is expressed using dotted notation, when of a parameter is expressed using dotted notation, when
appropriate, e.g., "deviceDesc.serialNumber". appropriate, e.g., "deviceDesc.serialNumber".
6. Message Encoding 6. Message Encoding
PAWS is encoded using JSON-RPC [JSON-RPC] (see also "The JavaScript PAWS is encoded using JSON-RPC [JSON-RPC] (see also "The JavaScript
Object Notation (JSON) Data Interchange Format" [RFC7159]). Each Object Notation (JSON) Data Interchange Format" [RFC7159]). Each
component described in Protocol Functionalities (Section 4) component described in Protocol Functionalities (Section 4)
corresponds to one or more JSON-RPC methods. This section discusses corresponds to one or more JSON-RPC methods. This section discusses
how to encode the data models presented in Section 4 and Section 5 how to encode the data models presented in Sections 4 and 5 into JSON
into JSON and provides some example encodings. The JSON examples may and provides some example encodings. The JSON examples may contain
contain ellipses (...) to represent additional properties or elements ellipses (...) to represent additional properties or elements that
that have been omitted in order to make the examples more concise. have been omitted in order to make the examples more concise.
6.1. JSON-RPC Binding 6.1. JSON-RPC Binding
The JSON-RPC [JSON-RPC] protocol consists of two basic objects, The JSON-RPC [JSON-RPC] protocol consists of two basic objects,
Request and Response: Request and Response:
o The JSON-RPC Request object encapsulates a PAWS functionality o The JSON-RPC Request object encapsulates a PAWS functionality
(operation) and the request message (operation) and the request message.
o The JSON-RPC Response object encapsulates a PAWS response message o The JSON-RPC Response object encapsulates a PAWS response message
and Error element and an Error element.
The Database and device MUST support JSON-RPC 2.0 encoding, with the The Database and device MUST support JSON-RPC 2.0 encoding, with the
restriction that the "id" parameter in the messages MUST be a string. restriction that the "id" parameter in the messages MUST be a string.
The device should generate the "id" uniquely enough to allow the use The device should generate the "id" uniquely enough to allow the use
of JSON-RPC batch. of JSON-RPC batch.
The JSON-RPC Request for PAWS has the following form: The JSON-RPC Request for PAWS has the following form:
{ {
"jsonrpc": "2.0", "jsonrpc": "2.0",
"method": "spectrum.paws.methodName", "method": "spectrum.paws.methodName",
"params": <PAWS_REQ>, "params": <PAWS_REQ>,
"id": "idString" "id": "idString"
} }
where "method" is the name of a PAWS functionality (operation), and where "method" is the name of a PAWS functionality (operation), and
<PAWS_REQ> represents one of the PAWS request messages associated <PAWS_REQ> represents one of the PAWS request messages associated
with the method (see Section 4.3 through Section 4.6). Method names with the method (see Sections 4.3 through 4.6). Method names are
are defined with the prefix, "spectrum.paws.". defined with the prefix "spectrum.paws.".
The non-error JSON-RPC Response for PAWS has the following form: The non-error JSON-RPC Response for PAWS has the following form:
{ {
"jsonrpc": "2.0", "jsonrpc": "2.0",
"result": <PAWS_RESP>, "result": <PAWS_RESP>,
"id": "idString" "id": "idString"
} }
where <PAWS_RESP> represents one of the PAWS response messages where <PAWS_RESP> represents one of the PAWS response messages
skipping to change at page 54, line 44 skipping to change at page 58, line 32
"message": "An appropriate error message.", "message": "An appropriate error message.",
"data": { ... } "data": { ... }
}, },
"id": "idString" "id": "idString"
} }
where the "error" object corresponds to the Error Element where the "error" object corresponds to the Error Element
(Section 5.17), and "code" is an error code described in the same (Section 5.17), and "code" is an error code described in the same
section. The Database SHOULD attempt to use the most specific section. The Database SHOULD attempt to use the most specific
applicable PAWS error code. When an accurate one is not available, applicable PAWS error code. When an accurate one is not available,
it SHOULD fall back to standard JSONRPC error codes as defined in it SHOULD fall back to standard JSON-RPC error codes as defined in
JSONRPC specification. For example, if the Database receives invalid the JSON-RPC specification. For example, if the Database receives
JSON from the device, it should respond with "-32700", signifying a invalid JSON from the device, it should respond with "-32700",
parse error. As a last resort, the Database MAY send a suitable HTTP signifying a parse error. As a last resort, the Database MAY send a
5xx response. suitable HTTP 5xx response.
6.1.1. Method Names 6.1.1. Method Names
Table 2 defines the method name, request object, and response object Table 2 defines the method name, request object, and response object
for each functionality defined in Protocol Functionalities for each functionality defined in Protocol Functionalities
(Section 4). (Section 4).
+------------------------+--------------------+---------------------+ +-------------------------------------------------------------------+
| Method Name | Request | Response | | Method Name |
+------------------------+--------------------+---------------------+ | Request |
| spectrum.paws.init | INIT_REQ (Section | INIT_RESP (Section | | Response |
| | 4.3.1) | 4.3.2) | +-------------------------------------------------------------------+
| spectrum.paws.register | REGISTRATION_REQ | REGISTRATION_RESP | | spectrum.paws.init |
| | (Section 4.4.1) | (Section 4.4.2) | | INIT_REQ (Section 4.3.1) |
| spectrum.paws.getSpect | AVAIL_SPECTRUM_REQ | AVAIL_SPECTRUM_RESP | | INIT_RESP (Section 4.3.2) |
| rum | (Section 4.5.1) | (Section 4.5.2) | | |
| spectrum.paws.getSpect | AVAIL_SPECTRUM_BAT | AVAIL_SPECTRUM_BATC | | spectrum.paws.register |
| rumBatch | CH_REQ (Section | H_RESP (Section | | REGISTRATION_REQ (Section 4.4.1) |
| | 4.5.3) | 4.5.4) | | REGISTRATION_RESP (Section 4.4.2) |
| spectrum.paws.notifySp | SPECTRUM_USE_NOTIF | SPECTRUM_USE_RESP | | |
| ectrumUse | Y (Section 4.5.5) | (Section 4.5.6) | | spectrum.paws.getSpectrum |
| spectrum.paws.verifyDe | DEV_VALID_REQ | DEV_VALID_RESP | | AVAIL_SPECTRUM_REQ (Section 4.5.1) |
| vice | (Section 4.6.1) | (Section 4.6.2) | | AVAIL_SPECTRUM_RESP (Section 4.5.2) |
+------------------------+--------------------+---------------------+ | |
| spectrum.paws.getSpectrumBatch |
| AVAIL_SPECTRUM_BATCH_REQ (Section 4.5.3) |
| AVAIL_SPECTRUM_BATCH_RESP (Section 4.5.4) |
| |
| spectrum.paws.notifySpectrumUse |
| SPECTRUM_USE_NOTIFY (Section 4.5.5) |
| SPECTRUM_USE_RESP (Section 4.5.6) |
| |
| spectrum.paws.verifyDevice |
| DEV_VALID_REQ (Section 4.6.1) |
| DEV_VALID_RESP (Section 4.6.2) |
+-------------------------------------------------------------------+
Table 2 Table 2: Method Names
6.1.2. JSON Encoding of Data Models 6.1.2. JSON Encoding of Data Models
JSON [RFC7159] encoding of the data models described in Section 4 and JSON [RFC7159] encoding of the data models described in Sections 4
Section 5 is straightforward: and 5 is straightforward:
o Each data model describes the contents of a JSON object o Each data model describes the contents of a JSON object.
o Each parameter of a data model corresponds to a member of the o Each parameter of a data model corresponds to a member of the
corresponding JSON object: corresponding JSON object:
* The parameter name of the data model is the same as the member * The parameter name of the data model is the same as the member
name of the JSON object name of the JSON object.
* The parameter data type describes the type of the member value * The parameter data type describes the type of the member value.
o Primitive types map to JSON type, as described in Section 4, o Primitive types map to JSON type, as described in Section 4 and
repeated here: repeated here:
string: A JSON string, restricted to UTF-8 encoding string: A JSON string, restricted to UTF-8 encoding
int: A JSON number, without a fractional or exponent part int: A JSON number, without a fractional or exponent part
float: A JSON number float: A JSON number
boolean: One of the JSON values, true or false boolean: One of the JSON values, true or false
o The list type maps to a JSON array, except that all values in the o The list type maps to a JSON array, except that all values in the
array are of the same type array are of the same type.
o When the parameter data type refers to another data model, that o When the parameter data type refers to another data model, that
data model describes a nested JSON object data model describes a nested JSON object.
o The encoded JSON object for each of the Request and Response o The encoded JSON object for each of the Request and Response
message listed in the Method Names Table (Table 2) also includes message listed in the Method Names Table (Table 2) also includes
the following members: the following members:
type: The name of the message, e.g., "INIT_REQ" type: The name of the message, e.g., "INIT_REQ"
version: The PAWS version, e.g., "1.0" version: The PAWS version, e.g., "1.0"
See the following sections for examples. See the following sections for examples.
6.2. Example Encoding: spectrum.paws.init Method 6.2. Example Encoding: spectrum.paws.init Method
An example of the "spectrum.paws.init" JSON-RPC request is shown An example of the "spectrum.paws.init" JSON-RPC request is shown
below; below.
{ {
"jsonrpc": "2.0", "jsonrpc": "2.0",
"method": "spectrum.paws.init", "method": "spectrum.paws.init",
"params": { "params": {
"type": "INIT_REQ", "type": "INIT_REQ",
"version": "1.0", "version": "1.0",
"deviceDesc": { "deviceDesc": {
"serialNumber": "XXX", "serialNumber": "XXX",
"fccId": "YYY", "fccId": "YYY",
skipping to change at page 56, line 49 skipping to change at page 61, line 30
}, },
"location": { "location": {
"point": { "point": {
"center": {"latitude": 37.0, "longitude": -101.3} "center": {"latitude": 37.0, "longitude": -101.3}
} }
} }
}, },
"id": "xxxxxx" "id": "xxxxxx"
} }
An example of the corresponding JSON-RPC response is shown below: An example of the corresponding JSON-RPC response is shown below.
{ {
"jsonrpc": "2.0", "jsonrpc": "2.0",
"result": { "result": {
"type": "INIT_RESP", "type": "INIT_RESP",
"version": "1.0", "version": "1.0",
"rulesetInfos": [ "rulesetInfos": [
{ {
"authority": "us", "authority": "us",
"rulesetId": "FccTvBandWhiteSpace-2010", "rulesetId": "FccTvBandWhiteSpace-2010",
skipping to change at page 58, line 4 skipping to change at page 62, line 35
}, },
"antenna": {"height": 10.2, "heightType": "AGL"} "antenna": {"height": 10.2, "heightType": "AGL"}
}, },
"id": "xxxxxx" "id": "xxxxxx"
} }
The following example "spectrum.paws.getSpectrum" JSON-RPC response The following example "spectrum.paws.getSpectrum" JSON-RPC response
contains: contains:
o A schedule with two time ranges o A schedule with two time ranges
o A spectrum profile for one resolution bandwidth (6 MHz) o A spectrum profile for one resolution bandwidth (6 MHz)
o The power levels for two frequency segments are shown: o The power levels for two frequency segments:
* From 518 MHz to 542 MHz * From 518 MHz to 542 MHz
* From 620 MHz to 626 MHz * From 620 MHz to 626 MHz
o In practice, each "profiles" list contains (frequency, power) o In practice, each "profiles" list contains (frequency, power)
points to cover all frequencies governed by the associated points to cover all frequencies governed by the associated
ruleset. See the Spectrum (Section 5.11) section for a more ruleset. See "Spectrum" (Section 5.11) for a more detailed
detailed discussion on the representation. discussion on the representation.
{ {
"jsonrpc": "2.0", "jsonrpc": "2.0",
"result": { "result": {
"type": "AVAIL_SPECTRUM_RESP", "type": "AVAIL_SPECTRUM_RESP",
"version": "1.0", "version": "1.0",
"timestamp": "2013-03-02T14:30:21Z", "timestamp": "2013-03-02T14:30:21Z",
"deviceDesc": { "deviceDesc": {
"serialNumber": "XXX", "serialNumber": "XXX",
"fccId": "YYY", "fccId": "YYY",
skipping to change at page 62, line 6 skipping to change at page 66, line 46
7. HTTPS Binding 7. HTTPS Binding
This section describes the use of "HTTP Over TLS" [RFC2818] (HTTPS) This section describes the use of "HTTP Over TLS" [RFC2818] (HTTPS)
as the transfer mechanism for PAWS. TLS provides message integrity as the transfer mechanism for PAWS. TLS provides message integrity
and confidentiality between the Master Device and the Database, but and confidentiality between the Master Device and the Database, but
only when best current practices are adopted, including use of only when best current practices are adopted, including use of
recommended cipher suites and modes of operation. Consequently, to recommended cipher suites and modes of operation. Consequently, to
improve PAWS security and interoperability, implementations of the improve PAWS security and interoperability, implementations of the
Database and Master Device MUST follow best current practices defined Database and Master Device MUST follow best current practices defined
by Recommendations for Secure Use of TLS and DTLS by "Recommendations for Secure Use of Transport Layer Security (TLS)
[I-D.ietf-uta-tls-bcp]. and Datagram Transport Layer Security (DTLS)" [RFC7525].
Depending on prior relationship between a database and device, the Depending on a prior relationship between a Database and device, the
server MAY require client authentication, as described in the server MAY require client authentication, as described in the
"Transport Layer Security (TLS) Protocol" [RFC5246], to authenticate "Transport Layer Security (TLS) Protocol" [RFC5246], to authenticate
the device. When client authentication is required, the database the device. When client authentication is required, the Database
MUST specify, by prior arrangement, acceptable root Certificate MUST specify, by prior arrangement, acceptable root Certification
Authorities (CAs) to serve as trust anchors for device certificates. Authorities (CAs) to serve as trust anchors for device certificates.
To enable databases to handle large numbers of requests from large To enable Databases to handle large numbers of requests from large
numbers of devices, the Database MAY support and devices SHOULD numbers of devices, the Database MAY support and devices SHOULD
support "Stateless TLS Session Resumption" [RFC5077]. support "Stateless TLS Session Resumption" [RFC5077].
A PAWS request message is carried in the body of an HTTP POST A PAWS request message is carried in the body of an HTTP POST
request. A PAWS response message is carried in the body of an HTTP request. A PAWS response message is carried in the body of an HTTP
response. A PAWS response SHOULD include a Content-Length header. response. A PAWS response SHOULD include a Content-Length header.
The POST method is the only method REQUIRED for PAWS. If a database The POST method is the only method REQUIRED for PAWS. If a Database
chooses to support GET, it MUST be an escaped URI, but the encoding chooses to support GET, it MUST be an escaped URI, but the encoding
of the URI is outside the scope of this document. The database MAY of the URI is outside the scope of this document. The Database MAY
refuse to support the GET request by returning an HTTP error code, refuse to support the GET request by returning an HTTP error code,
such as 405 (method not allowed). such as 405 (method not allowed).
The Database MAY redirect a PAWS request by returning a HTTP 3xx The Database MAY redirect a PAWS request by returning a HTTP 3xx
response (as defined by "HTTP/1.1: Semantics and Content" [RFC7231], response (as defined by Section 6.4 of "HTTP/1.1: Semantics and
Section 6.4). The Database MUST provide the redirect URI in the Content" [RFC7231]). The Database MUST provide the redirect URI in
Location header of the 3xx response, and the device MUST handle the Location header of the 3xx response, and the device MUST handle
redirects by using the Location header provided by the Database. redirects by using the Location header provided by the Database.
When redirecting, the device MUST observe the delay indicated by the When redirecting, the device MUST observe the delay indicated by the
Retry-After header. The device MUST authenticate the Database that Retry-After header. The device MUST authenticate the Database that
returns the redirect response before following the redirect. Also, returns the redirect response before following the redirect. Also,
the device MUST authenticate the Database indicated in the redirect. the device MUST authenticate the Database indicated in the redirect.
Since the device may communicate with a Database (which it Since the device may communicate with a Database (which it
authenticated) without user interaction, when the response code is authenticated) without user interaction, when the response code is
301 (Moved Permanently), the device MAY redirect without asking a 301 (Moved Permanently), the device MAY redirect without asking a
user for confirmation, even thought it is in response to an HTTP POST user for confirmation, even thought it is in response to an HTTP POST
method. method.
The Database SHOULD use HTTP status code "307 Temporary Redirect" to The Database SHOULD use HTTP status code "307 Temporary Redirect" to
indicate that the device SHOULD resubmit the same request to an indicate that the device SHOULD resubmit the same request to an
alternate URI. The device MAY revert to the original URI for the alternate URI. The device MAY revert to the original URI for the
very next request, or MAY continue to use the alternate URI for a very next request, or it MAY continue to use the alternate URI for a
period of time, e.g.,: period of time, e.g.,:
o For the remainder of its session, or o For the remainder of its session, or
o For a fixed period of time, or o For a fixed period of time, or
o Until power cycled, or o Until power cycled, or
o Until it receives another redirect o Until it receives another redirect
However, the device does not need to modify its stored list of URIs. However, the device does not need to modify its stored list of URIs.
For a minimum of two weeks before the URI of the Database changes For a minimum of two weeks before the URI of the Database changes
permanently, it MUST use the database-change (DbUpdateSpec permanently, it MUST use the database-change (DbUpdateSpec
skipping to change at page 63, line 14 skipping to change at page 68, line 7
o For a fixed period of time, or o For a fixed period of time, or
o Until power cycled, or o Until power cycled, or
o Until it receives another redirect o Until it receives another redirect
However, the device does not need to modify its stored list of URIs. However, the device does not need to modify its stored list of URIs.
For a minimum of two weeks before the URI of the Database changes For a minimum of two weeks before the URI of the Database changes
permanently, it MUST use the database-change (DbUpdateSpec permanently, it MUST use the database-change (DbUpdateSpec
(Section 5.7)) mechanism to notify devices, as described in the (Section 5.7)) mechanism to notify devices, as described in
Configuration Update portion of the Database Discovery (Section 4.1) "Configuration Update: Database URI Changes" (Section 4.1.2). After
section. After the Database has moved, requests to the original URI the Database has moved, requests to the original URI MAY return HTTP
MAY return HTTP status code "301 Moved Permanently" to indicate that status code 301 (Moved Permanently) to indicate that the device
the device SHOULD resubmit the request, and all future requests, to SHOULD resubmit the request, and all future requests, to the
the indicated alternate URI. indicated alternate URI.
8. Extensibility 8. Extensibility
This section describes procedures for extending PAWS. No extensions This section describes procedures for extending PAWS. No extensions
should be made that would return sensitive device-specific should be made that would return sensitive device-specific
information in Database responses. information in database responses.
8.1. Defining Ruleset Identifiers 8.1. Defining Ruleset Identifiers
A ruleset represents a set of device-side requirements for which the A ruleset represents a set of device-side requirements for which the
device has been certified. It typically corresponds to, but is not device has been certified. It typically corresponds to, but is not
limited to, a set of rules that govern a specific set of radio limited to, a set of rules that govern a specific set of radio
spectrum for a regulatory domain. spectrum for a regulatory domain.
Ruleset identifiers are defined and registered in the Ruleset ID Ruleset identifiers are defined and registered in the Ruleset ID
Registry following the procedure in Section 9.1. Ruleset ID values Registry following the procedure in Section 9.1. Ruleset ID values
MUST conform to the ruleset-id ABNF. If the Ruleset ID requires MUST conform to the ruleset-id ABNF. If the Ruleset ID requires
additional parameters, they are registered in the PAWS Parameters additional parameters, they are registered in the PAWS Parameters
Registry, as described by Section 9.2. Registry, as described by Section 9.2. The ABNF syntax [RFC5234] is
as follows.
ruleset-id = 1*64ruleset-char ruleset-id = 1*64ruleset-char
ruleset-char = ALPHA / DIGIT / "_" / "." ruleset-char = ALPHA / DIGIT / "_" / "."
When defining a Ruleset ID: When defining a Ruleset ID:
o It can be useful for the identifier to be descriptive of the set o It can be useful for the identifier to be descriptive of the set
of rules that allow a device to operate within one or more of rules that allow a device to operate within one or more
regulatory domains. For example, it might include the name of a regulatory domains. For example, it might include the name of a
regulatory body or a certification process. regulatory body or a certification process.
o The identifier SHOULD include some sort of version information, o The identifier SHOULD include some sort of version information,
such as a year and/or version number. such as a year and/or version number.
o The maximum length of the identifier is 64 octets. o The maximum length of the identifier is 64 octets.
8.2. Defining New Message Parameters 8.2. Defining New Message Parameters
New request or response parameters for use with PAWS are defined and New request or response parameters for use with PAWS are defined and
registered in the parameters registry following the procedure in registered in the parameters registry following the procedure in
Section 9.2. Section 9.2.
Parameter names MUST conform to the param-name ABNF and parameter Parameter names MUST conform to the param-name ABNF, and parameter
values syntax MUST be well-defined (e.g., using ABNF, or a reference values syntax MUST be well-defined (e.g., using ABNF or a reference
to the syntax of an existing parameter). to the syntax of an existing parameter).
param-name = 1*64name-char param-name = 1*64name-char
name-char = ALPHA / DIGIT / "_" name-char = ALPHA / DIGIT / "_"
Parameter names use lowerCamelCase by convention. The maximum length Parameter names use lowerCamelCase by convention. The maximum length
of a name is 64 octets. of a name is 64 octets.
Unregistered vendor-specific parameter extensions that are not Unregistered vendor-specific parameter extensions that are not
commonly applicable, and are specific to the implementation details commonly applicable and are specific to the implementation details of
of the Database where they are used SHOULD use a vendor-specific the Database where they are used SHOULD use a vendor-specific prefix
prefix that is not likely to conflict with other registered values that is not likely to conflict with other registered values (e.g.,
(e.g., begin with 'companyname'). begin with 'companyname').
8.3. Defining Additional Error Codes 8.3. Defining Additional Error Codes
Additional error codes can be registered to extend the set listed in Additional error codes can be registered to extend the set listed in
Section 5.17, following the procedures in Section 9.3. If the error Section 5.17, following the procedures in Section 9.3. If the error
code requires additional response parameters, they are registered in code requires additional response parameters, they are registered in
the PAWS Parameters Registry, as described by Section 9.2. the PAWS Parameters Registry, as described by Section 9.2.
By convention, the error code is a negative integer value, using one By convention, the error code is a negative integer value, using one
of the range of values defined in Error Codes (Section 5.17). If an of the range of values defined in Error Codes (Section 5.17). If an
appropriate category does not exist, a value from a different range appropriate category does not exist, a value from a different range
may be used. may be used.
9. IANA Considerations 9. IANA Considerations
[RFC Editor/IANA: Please replace "[[ this document ]]" with the RFC
number of this document as indicated below, and remove this note
prior to publication]
There are three registries associated with PAWS: There are three registries associated with PAWS:
o PAWS Ruleset ID Registry (Section 9.1) o PAWS Ruleset ID Registry (Section 9.1)
o PAWS Parameter Registry (Section 9.2) o PAWS Parameter Registry (Section 9.2)
o PAWS Error Code Registry (Section 9.3)
Prior to registration, the registrant is encouraged to post to the o PAWS Error Code Registry (Section 9.3)
paws@ietf.org mailing list, including the specification or its draft,
to get early feedback.
All registries use the Specification Required policy [RFC5226], with All registries use the Specification Required policy [RFC5226], with
a Designated Expert appointed by the IESG. Specific criteria that a Designated Expert appointed by the IESG. Specific criteria that
the Designated Expert should use in assessing registrations are given the Designated Expert should use in assessing registrations are given
below in the description of each registry. The Designated Expert below in the description of each registry. The Designated Expert
should take advice from the community through the paws@ietf.org should take advice from the community through the paws@ietf.org
mailing list, and the registrant is encouraged to post to the mailing mailing list, and the registrant is encouraged to post to the mailing
list before formally requesting the registration from IANA. The list before formally requesting the registration from IANA. The
intention is that new registrations will be accompanied by a intention is that new registrations will be accompanied by a
published specification. But in order to allow for the allocation of published specification. But in order to allow for the allocation of
values prior to publication of the specification, the Designated values prior to publication of the specification, the Designated
Expert can approve allocations once it seems clear that the Expert can approve allocations once it seems clear that the
specification will be published. Upon approval, IANA will post each specification will be published. Upon approval, IANA will post the
registration template that is not included in the text of an RFC. registrations that are not intended to be published in an RFC.
9.1. PAWS Ruleset ID Registry 9.1. PAWS Ruleset ID Registry
This specification establishes the PAWS Ruleset ID Registry. This specification establishes the "PAWS Ruleset ID Registry".
Ruleset type names for inclusion in PAWS messages are registered on Ruleset type names for inclusion in PAWS messages are registered on
the advice of one or more Designated Experts, with Specification the advice of one or more Designated Experts, with Specification
Required [RFC5226]. The specification must include a reference to Required [RFC5226]. The specification must include a reference to
the regulatory domain to which it applies. To increase the regulatory domain to which it applies. To increase
interoperability, it is more desirable to have fewer rulesets than to interoperability, it is more desirable to have fewer rulesets than to
have many rulesets with small variations. Consequently, the have many rulesets with small variations. Consequently, the
Designated Expert should avoid duplication and should encourage the Designated Expert should avoid duplication and should encourage the
registrant to look for alternatives if there are only small registrant to look for alternatives if there are only small
variations from an existing ruleset. The Designated Expert should variations from an existing ruleset. The Designated Expert should
ensure that the proposed registration is complete with respect to its ensure that the proposed registration is complete with respect to its
associated regulatory domain and may seek an expert familiar with associated regulatory domain and may seek an expert familiar with
those rules to participate in the review on the paws@ietf.org mailing those rules to participate in the review on the paws@ietf.org mailing
list. list.
The PAWS Ruleset ID Registry will include the following: 'Ruleset The PAWS Ruleset ID Registry includes the following: 'Ruleset
identifier', 'Specification document(s)', and 'Template'. The Identifier', 'Reference', and 'Template'. The Template column will
Template column will include links to the registration templates, include links to the registration templates, either posted by IANA or
either posted by IANA or the relevant sections of RFCs. linked to the relevant sections of RFCs.
9.1.1. Registration Template 9.1.1. Registration Template
Ruleset identifier: The name of the ruleset. See [[ this document Ruleset identifier: The name of the ruleset. See Section 8.1 of RFC
]], Section 8.1 for the format requirements of this identifier. 7545 for the format requirements of this identifier.
Specification document(s): Reference to the document that specifies Specification document(s): Reference to the document that specifies
the parameter, preferably including a URI that can be used to the parameter, preferably including a URI that can be used to
retrieve a copy of the document. An indication of the relevant retrieve a copy of the document. An indication of the relevant
sections also may be included, but is not required. sections also may be included but is not required.
Additional Parameter Requirements: Listing of additional parameter Additional Parameter Requirements: Listing of additional parameter
requirements to associate with the ruleset. Note that new requirements to associate with the ruleset. Note that new
parameters are registered separately in the PAWS Parameters parameters are registered separately in the PAWS Parameters
Registry, as described by Section 8.2. Two types of additional Registry, as described by Section 8.2. Two types of additional
parameter requirements are: parameter requirements are:
* Addition of new parameters to existing structures, or * Addition of new parameters to existing structures, or
modification of the REQUIRED and OPTIONAL requirements for modification of the REQUIRED and OPTIONAL requirements for
existing parameters. existing parameters.
skipping to change at page 66, line 50 skipping to change at page 71, line 45
include a structure name in its heading and have the following include a structure name in its heading and have the following
columns: columns:
Parameter name: Name of the parameter. Parameter name: Name of the parameter.
Type: Data type of the parameter value. Type: Data type of the parameter value.
Additional requirements: Additional requirements on the parameter Additional requirements: Additional requirements on the parameter
value. value.
IANA will post each registration template that is not included in the IANA will post each registration template that is not intended to be
text of an RFC. published in an RFC.
Note that the Additional Parameter Requirements section can be quite Note that the Additional Parameter Requirements section can be quite
extensive, so it will not appear directly in the IANA Ruleset ID extensive, so it will not appear directly in the IANA Ruleset ID
Registry table. The table, however, does contain a link to the full Registry table. The table, however, will contain a link to the full
registration template for easy access to the additional requirements. registration template for easy access to the additional requirements.
9.1.2. Initial Registry Contents 9.1.2. Initial Registry Contents
The PAWS Ruleset ID Registry enables protocol extensibility to The PAWS Ruleset ID Registry enables protocol extensibility to
support any regulatory domain and ruleset. The initial contents of support any regulatory domain and ruleset. The initial contents of
the registry, however, include only FCC-specific and ETSI-specific the registry, however, include only FCC-specific and ETSI-specific
entries, because, as of this writing, they are the only regulatory entries, because, as of this writing, they are the only regulatory
domains that have finalized rules. There is no intent to restrict domains that have finalized rules. There is no intent to restrict
the protocol to any particular set of authorities. the protocol to any particular set of authorities.
skipping to change at page 67, line 31 skipping to change at page 72, line 26
9.1.2.1. Federal Communications Commission (FCC) 9.1.2.1. Federal Communications Commission (FCC)
For the additional parameters that start with the "fcc" prefix, see For the additional parameters that start with the "fcc" prefix, see
PAWS Parameters Registry Initial Contents (Section 9.2.2) for more PAWS Parameters Registry Initial Contents (Section 9.2.2) for more
information. information.
Ruleset identifier: FccTvBandWhiteSpace-2010 Ruleset identifier: FccTvBandWhiteSpace-2010
Specification document(s): This ruleset refers to the FCC rules for Specification document(s): This ruleset refers to the FCC rules for
TV-band White Space operations established in the Code of Federal TV-band white-space operations established in the Code of Federal
Regulations (CFR), Title 47, Part 15, Subpart H [FCC-CFR47-15H]. Regulations (CFR), Title 47, Part 15, Subpart H [FCC-CFR47-15H].
Additional Parameter Requirements Additional Parameter Requirements
Each of the following tables defines additional parameters for the Each of the following tables defines additional parameters for the
indicated PAWS message. Note that the Requirement column lists FCC, indicated PAWS message. Note that the Requirement column lists FCC,
not PAWS, requirements/optionality rules. not PAWS, requirements/optionality rules.
The FCC requires registration of "Fixed Devices". Additionally, The FCC requires registration of "Fixed Devices". Additionally,
deviceOwner is required in the registration request: deviceOwner is required in the registration request:
skipping to change at page 68, line 30 skipping to change at page 73, line 30
| deviceDesc | DeviceDescriptor (Section | REQUIRED | | | deviceDesc | DeviceDescriptor (Section | REQUIRED | |
| | 5.2) | | | | | 5.2) | | |
+---------------+-----------------------------+-------------+-------+ +---------------+-----------------------------+-------------+-------+
DeviceDescriptor (Section 5.2) DeviceDescriptor (Section 5.2)
+-------------------+--------+-------------+------------------------+ +-------------------+--------+-------------+------------------------+
| Parameter Name | Type | Requirement | Notes | | Parameter Name | Type | Requirement | Notes |
+-------------------+--------+-------------+------------------------+ +-------------------+--------+-------------+------------------------+
| serialNumber | string | REQUIRED | Specifies a device's | | serialNumber | string | REQUIRED | Specifies a device's |
| | | | serial number. See [[ | | | | | serial number. See |
| | | | this document ]], |
| | | | Section 5.2. | | | | | Section 5.2. |
| fccId | string | REQUIRED | Specifies a device's | | fccId | string | REQUIRED | Specifies a device's |
| | | | FCC certification ID | | | | | FCC certification ID |
| | | | (Section 9.2.2.1). | | | | | (Section 9.2.2.1). |
| fccTvbdDeviceType | string | REQUIRED | Specifies the FCC | | fccTvbdDeviceType | string | REQUIRED | Specifies the FCC |
| | | | Device Type (Section | | | | | Device Type (Section |
| | | | 9.2.2.2) of TV-band | | | | | 9.2.2.2) of TV-band |
| | | | White Space device, as | | | | | white-space device, as |
| | | | defined by the FCC | | | | | defined by the FCC |
| | | | rules. | | | | | rules. |
+-------------------+--------+-------------+------------------------+ +-------------------+--------+-------------+------------------------+
The following table lists additional requirements for DeviceOwner The following table lists additional requirements for DeviceOwner
(Section 5.5) parameter values. (Section 5.5) parameter values.
DeviceOwner (Section 5.5) DeviceOwner (Section 5.5)
+-----------+-------+-----------------------------------------------+ +-----------+-------+-----------------------------------------------+
| Parameter | Type | Additional Requirement | | Parameter | Type | Additional Requirement |
| Name | | | | Name | | |
+-----------+-------+-----------------------------------------------+ +-----------+-------+-----------------------------------------------+
| owner | vCard | The owner is required to contain the | | owner | vCard | The owner is required to contain the |
skipping to change at page 69, line 13 skipping to change at page 74, line 15
(Section 5.5) parameter values. (Section 5.5) parameter values.
DeviceOwner (Section 5.5) DeviceOwner (Section 5.5)
+-----------+-------+-----------------------------------------------+ +-----------+-------+-----------------------------------------------+
| Parameter | Type | Additional Requirement | | Parameter | Type | Additional Requirement |
| Name | | | | Name | | |
+-----------+-------+-----------------------------------------------+ +-----------+-------+-----------------------------------------------+
| owner | vCard | The owner is required to contain the | | owner | vCard | The owner is required to contain the |
| | | formatted name of an individual or | | | | formatted name of an individual or |
| | | organization using the "fn" property. When | | | | organization using the "fn" property. When |
| | | the name is that of an organization, the | | | | the name is that of an organization, the |
| | | entry also is required to contain the "kind" | | | | entry also is required to contain the "kind" |
| | | property, with a value of "org". | | | | property, with a value of "org". |
| operator | vCard | The operator entry is required to contain the | | operator | vCard | The operator entry is required to contain the |
| | | following properties for the contact person | | | | following properties for the contact person |
| | | responsible for the device's operation: "fn", | | | | responsible for the device's operation: "fn", |
| | | "adr", "tel", and "email". | | | | "adr", "tel", and "email". |
+-----------+-------+-----------------------------------------------+ +-----------+-------+-----------------------------------------------+
9.1.2.2. European Telecommunications Standards Institute (ETSI) 9.1.2.2. European Telecommunications Standards Institute (ETSI)
skipping to change at page 69, line 38 skipping to change at page 74, line 40
Ruleset identifier: ETSI-EN-301-598-1.1.1 Ruleset identifier: ETSI-EN-301-598-1.1.1
Specification document(s): This ruleset refers to the ETSI Specification document(s): This ruleset refers to the ETSI
Harmonised Standard [ETSI-EN-301-598] established by ETSI. Harmonised Standard [ETSI-EN-301-598] established by ETSI.
Additional Parameter Requirements Additional Parameter Requirements
Each of the following tables defines additional parameters for the Each of the following tables defines additional parameters for the
indicated PAWS message. Note that the Requirement column lists ETSI, indicated PAWS message. Note that the Requirement column lists ETSI,
not PAWS, requirements/optionality rules, not PAWS, requirements/optionality rules.
DeviceDescriptor (Section 5.2)
+-------------------------+-------+-------------+-------------------+ +-------------------------------------------------------------------+
| Parameter Name | Type | Requirement | Notes | | Parameter Name |
+-------------------------+-------+-------------+-------------------+ | Type |
| serialNumber | strin | REQUIRED | Specifies a | | Requirement |
| | g | | device's serial | | Notes |
| | | | number. See [[ | +-------------------------------------------------------------------+
| | | | this document ]], | | serialNumber |
| | | | Section 5.2. | | string |
| manufacturerId | strin | REQUIRED | Specifies a | | REQUIRED |
| | g | | device's | | Specifies a device's serial number (Section 5.2). |
| | | | manufacturer's | | |
| | | | identifier. See | | manufacturerId |
| | | | [[ this document | | string |
| | | | ]], Section 5.2. | | REQUIRED |
| modelId | strin | REQUIRED | Specifies a | | Specifies a device's manufacturer's identifier |
| | g | | device's model | | (Section 5.2). |
| | | | identifier. See | | |
| | | | [[ this document | | modelId |
| | | | ]], Section 5.2. | | string |
| etsiEnDeviceType | strin | REQUIRED | Specifies the | | REQUIRED |
| | g | | device's ETSI | | Specifies a device's model identifier (Section 5.2). |
| | | | device type | | |
| | | | (Section | | etsiEnDeviceType |
| | | | 9.2.2.3). | | string |
| etsiEnDeviceEmissionsCl | strin | REQUIRED | Specifies the | | REQUIRED |
| ass | g | | device's ETSI | | Specifies the device's ETSI device type (Section 9.2.2.3). |
| | | | device emissions | | |
| | | | class (Section | | etsiEnDeviceEmissionsClass |
| | | | 9.2.2.4). | | string |
| etsiEnTechnologyId | strin | REQUIRED | Specifies the | | REQUIRED |
| | g | | device's ETSI | | Specifies the device's ETSI device emissions class |
| | | | technology ID | | (Section 9.2.2.4). |
| | | | (Section | | |
| | | | 9.2.2.5). | | etsiEnTechnologyId |
| etsiEnDeviceCategory | strin | REQUIRED | Specifies the | | string |
| | g | | device's ETSI | | REQUIRED |
| | | | device category | | Specifies the device's ETSI technology ID (Section 9.2.2.5). |
| | | | (Section | | |
| | | | 9.2.2.6). | | etsiEnDeviceCategory |
+-------------------------+-------+-------------+-------------------+ | string |
| REQUIRED |
| Specifies the device's ETSI device category (Section 9.2.2.6). |
+-------------------------------------------------------------------+
AVAIL_SPECTRUM_REQ (Section 4.5.1) AVAIL_SPECTRUM_REQ (Section 4.5.1)
+-------------+--------+-------------+------------------------------+ +-------------+--------+-------------+------------------------------+
| Parameter | Type | Requirement | Notes | | Parameter | Type | Requirement | Notes |
| Name | | | | | Name | | | |
+-------------+--------+-------------+------------------------------+ +-------------+--------+-------------+------------------------------+
| requestType | string | OPTIONAL | Modifies the available- | | requestType | string | OPTIONAL | Modifies the available- |
| | | | spectrum request type. If | | | | | spectrum request type. If |
| | | | specified, the only valid | | | | | specified, the only valid |
| | | | value is, "Generic Slave", | | | | | value is, "Generic Slave", |
| | | | and the Database is required | | | | | and the Database is required |
| | | | to respond with generic | | | | | to respond with generic |
| | | | operating parameters for any | | | | | operating parameters for any |
| | | | Slave Device. | | | | | Slave Device. |
+-------------+--------+-------------+------------------------------+ +-------------+--------+-------------+------------------------------+
Available Spectrum Batch Request (Section 4.5.3) Available Spectrum Batch Request (Section 4.5.3)
+-------------+--------+-------------+------------------------------+ +-------------+--------+-------------+------------------------------+
| Parameter | Type | Requirement | Notes | | Parameter | Type | Requirement | Notes |
| Name | | | | | Name | | | |
+-------------+--------+-------------+------------------------------+ +-------------+--------+-------------+------------------------------+
| requestType | string | OPTIONAL | Modifies the available- | | requestType | string | OPTIONAL | Modifies the available- |
| | | | spectrum request type. If | | | | | spectrum request type. If |
| | | | specified, the only valid | | | | | specified, the only valid |
| | | | value is, "Generic Slave", | | | | | value is, "Generic Slave", |
| | | | and the Database is required | | | | | and the Database is required |
| | | | to respond with generic | | | | | to respond with generic |
| | | | operating parameters for any | | | | | operating parameters for any |
| | | | Slave Device. | | | | | Slave Device. |
+-------------+--------+-------------+------------------------------+ +-------------+--------+-------------+------------------------------+
The following tables define additional requirements for the The following tables define additional requirements for the
DeviceDescriptor (Section 5.2) and RulesetInfo (Section 5.6) DeviceDescriptor (Section 5.2) and RulesetInfo (Section 5.6)
parameters that appear in the AVAIL_SPECTRUM_RESP (Section 4.5.2) and parameters that appear in the AVAIL_SPECTRUM_RESP (Section 4.5.2) and
AVAIL_SPECTRUM_BATCH_RESP (Section 4.5.4) messages. Note that this AVAIL_SPECTRUM_BATCH_RESP (Section 4.5.4) messages. Note that this
means the Database is modifying the DeviceDescriptor sent by the means the Database is modifying the DeviceDescriptor sent by the
Master Device to return device-specific restrictions. Master Device to return device-specific restrictions.
DeviceDescriptor (Section 5.2) +-------------------------------------------------------------------+
| Parameter Name |
+--------------------------------+-------+----------+---------------+ | Type |
| Parameter Name | Type | Requirem | Notes | | Requirement |
| | | ent | | | Notes |
+--------------------------------+-------+----------+---------------+ +-------------------------------------------------------------------+
| needsSpectrumReport | boole | REQUIRED | The Database | | needsSpectrumReport |
| | an | | is required | | boolean |
| | | | to set this | | REQUIRED |
| | | | to true to | | The Database is required to set this to true to indicate that |
| | | | indicate that | | the device must report spectrum usage. |
| | | | the device | | |
| | | | must report | | maxTotalBwHz |
| | | | spectrum | | float |
| | | | usage. | | REQUIRED |
| maxTotalBwHz | float | REQUIRED | Specifies a | | Specifies a constraint on total allowed bandwidth. |
| | | | constraint on | | |
| | | | total allowed | | maxContiguousBwHz |
| | | | bandwidth. | | float |
| maxContiguousBwHz | float | REQUIRED | Specifies a | | REQUIRED |
| | | | constraint on | | Specifies a constraint on total allowed contiguous |
| | | | total allowed | | bandwidth. |
| | | | contiguous | | |
| | | | bandwidth. | | etsiEnSimultaneousChannelOpera |
| etsiEnSimultaneousChannelOpera | strin | REQUIRED | Specifies a | | string |
| tionRestriction | g | | constraint on | | REQUIRED |
| | | | simultaneous | | Specifies a constraint on simultaneous channel operation |
| | | | channel | | (Section 9.2.2.7). If it is not provided, the default value |
| | | | operation | | is "0". |
| | | | (Section | +-------------------------------------------------------------------+
| | | | 9.2.2.7). If |
| | | | it is not |
| | | | provided, the |
| | | | default value |
| | | | is "0". |
+--------------------------------+-------+----------+---------------+
RulesetInfo (Section 5.6) RulesetInfo (Section 5.6)
+-------------------+-------+-------------+-------------------------+ +-------------------+-------+-------------+-------------------------+
| Parameter Name | Type | Requirement | Notes | | Parameter Name | Type | Requirement | Notes |
+-------------------+-------+-------------+-------------------------+ +-------------------+-------+-------------+-------------------------+
| maxLocationChange | float | OPTIONAL | Specifies a constraint | | maxLocationChange | float | OPTIONAL | Specifies a constraint |
| | | | on maximum location | | | | | on maximum location |
| | | | changes. | | | | | changes. |
+-------------------+-------+-------------+-------------------------+ +-------------------+-------+-------------+-------------------------+
9.2. PAWS Parameters Registry 9.2. PAWS Parameters Registry
This specification establishes the PAWS Parameters Registry. This specification establishes the "PAWS Parameters Registry".
Additional parameters for inclusion in PAWS requests, responses, or Additional parameters for inclusion in PAWS requests, responses, or
sub-messages are registered on the advice of one or more Designated sub-messages are registered on the advice of one or more Designated
Experts, with Specification Required [RFC5226]. Experts, with Specification Required [RFC5226].
The Designated Expert should avoid duplication, i.e., avoid adding a The Designated Expert should avoid duplication, i.e., avoid adding a
new parameter when an existing one suffices. When a set of new parameter when an existing one suffices. When a set of
parameters is added in support of a new ruleset (Section 9.1), the parameters is added in support of a new ruleset (Section 9.1), the
parameters should share a common prefix that reflects the ruleset ID. parameters should share a common prefix that reflects the ruleset ID.
The prefix may be omitted, of course, if a parameter has more general The prefix may be omitted, of course, if a parameter has more general
applicability. Similarly, when a parameter is not associated with a applicability. Similarly, when a parameter is not associated with a
ruleset, the Designated Expert should ensure that the parameter name ruleset, the Designated Expert should ensure that the parameter name
does not have a prefix used by existing ruleset parameters (e.g., does not have a prefix that is used by existing ruleset parameters
"fcc", "etsi") or are the initials of an organization that has not (e.g., "fcc", "etsi") or that is the initials of an organization that
yet registered anything, but reasonably might. has not yet registered anything, but reasonably might.
The PAWS Parameters Registry will include the following: 'Parameter The PAWS Parameters Registry includes the following: 'Parameter
name', 'Parameter usage location', and 'Specification document(s)'. name', 'Parameter usage location', and 'Specification document(s)'.
9.2.1. Registration Template 9.2.1. Registration Template
Parameter name: The name of the parameter (e.g., "example"). Parameter name: The name of the parameter (e.g., "example").
Parameter usage location: The location(s) where the parameter can be Parameter usage location: The location(s) where the parameter can be
used. The possible locations are the named structures defined in used. The possible locations are the named structures defined in
Protocol Functionalities (Section 4) and Protocol Parameters "Protocol Functionalities" (Section 4) and "Protocol Parameters"
(Section 5). (Section 5).
Specification document(s): Reference to the document that specifies Specification document(s): Reference to the document that specifies
the parameter, preferably including a URI that can be used to the parameter, preferably including a URI that can be used to
retrieve a copy of the document. An indication of the relevant retrieve a copy of the document. An indication of the relevant
sections also may be included, but is not required. sections also may be included, but is not required.
9.2.2. Initial Registry Contents 9.2.2. Initial Registry Contents
The PAWS Parameters Registry enables protocol extensibility to The PAWS Parameters Registry enables protocol extensibility to
support any regulatory domain and ruleset. The initial contents of support any regulatory domain and ruleset. The initial contents of
the registry, however, include only FCC-specific and ETSI-specific the registry, however, include only FCC-specific and ETSI-specific
entries, because, as of this writing, they are the only regulatory entries, because, as of this writing, they are the only regulatory
domains that have established rules. There is no intent to restrict domains that have established rules. There is no intent to restrict
the protocol to any particular set of authorities. the protocol to any particular set of authorities.
The PAWS Parameters Registry's initial contents are listed below; The initial contents of the PAWS Parameters Registry are listed
each section corresponds to a row of the registry. below; each section corresponds to a row of the registry.
9.2.2.1. FCC ID 9.2.2.1. FCC ID
Parameter name: fccId Parameter name: fccId
Parameter usage location: DeviceDescriptor (Section 5.2) Parameter usage location: DeviceDescriptor (Section 5.2)
Specification document(s): [[ this document ]] Specifies the Specification document(s): This document. Specifies the device's
device's FCC certification identifier. A valid FCC ID is limited FCC certification identifier. A valid FCC ID is limited to 19
to 19 characters in the ASCII value range, as proposed in FCC characters in the ASCII value range, as proposed in FCC
Administration Topics Review [FCC-Review-2012-10]. For the Administration Topics Review [FCC-Review-2012-10]. For the
purposes of the PAWS protocol, the maximum length of the fccId purposes of the PAWS protocol, the maximum length of the fccId
value is 32 octets. value is 32 octets.
9.2.2.2. FCC Device Type 9.2.2.2. FCC Device Type
Parameter name: fccTvbdDeviceType Parameter name: fccTvbdDeviceType
Parameter usage location: DeviceDescriptor (Section 5.2) Parameter usage location: DeviceDescriptor (Section 5.2)
Specification document(s): [[ this document ]] Specifies the TV Band Specification document(s): This document. Specifies the TV-band
White Space device type, as defined by the FCC. Valid values are white-space device type, as defined by the FCC. Valid values are
"FIXED", "MODE_1", "MODE_2". "FIXED", "MODE_1", and "MODE_2".
9.2.2.3. ETSI Device Type 9.2.2.3. ETSI Device Type
Parameter name: etsiEnDeviceType Parameter name: etsiEnDeviceType
Parameter usage location: DeviceDescriptor (Section 5.2) Parameter usage location: DeviceDescriptor (Section 5.2)
Specification document(s): Specifies the White Space Device type, as Specification document(s): Specifies the white-space device type, as
defined by the ETSI Harmonised Standard [ETSI-EN-301-598]. Valid defined by the ETSI Harmonised Standard [ETSI-EN-301-598]. Valid
values are single-letter strings, such as "A", "B", etc. Consult values are single-letter strings, such as "A", "B", etc. Consult
the documentation for details about the device types. the documentation for details about the device types.
9.2.2.4. ETSI Device Emissions Class 9.2.2.4. ETSI Device Emissions Class
Parameter name: etsiEnDeviceEmissionsClass Parameter name: etsiEnDeviceEmissionsClass
Parameter usage location: DeviceDescriptor (Section 5.2) Parameter usage location: DeviceDescriptor (Section 5.2)
Specification document(s): Specifies the White Space Device Specification document(s): Specifies the white-space device
emissions class, as defined by the ETSI Harmonised Standard emissions class, as defined by the ETSI Harmonised Standard
[ETSI-EN-301-598], that characterises the out-of-block emissions [ETSI-EN-301-598], that characterizes the out-of-block emissions
of the device. The values are represented by numeric strings, of the device. The values are represented by numeric strings,
such as "1", "2", "3", etc. Consult the documentation for details such as "1", "2", "3", etc. Consult the documentation for details
about emissions classes about emissions classes.
9.2.2.5. ETSI Technology Identifier 9.2.2.5. ETSI Technology Identifier
Parameter name: etsiEnTechnologyId Parameter name: etsiEnTechnologyId
Parameter usage location: DeviceDescriptor (Section 5.2) Parameter usage location: DeviceDescriptor (Section 5.2)
Specification document(s): Specifies the White Space Device Specification document(s): Specifies the white-space device
technology identifier, as defined by the ETSI Harmonised Standard technology identifier, as defined by the ETSI Harmonised Standard
[ETSI-EN-301-598]. The maximum length of the string value is 64 [ETSI-EN-301-598]. The maximum length of the string value is 64
octets. Consult the documentation for valid values. octets. Consult the documentation for valid values.
9.2.2.6. ETSI Device Category 9.2.2.6. ETSI Device Category
Parameter name: etsiEnDeviceCategory Parameter name: etsiEnDeviceCategory
Parameter usage location: DeviceDescriptor (Section 5.2) Parameter usage location: DeviceDescriptor (Section 5.2)
Specification document(s): Specifies the White Space Device Specification document(s): Specifies the white-space device
category, as defined by the ETSI Harmonised Standard category, as defined by the ETSI Harmonised Standard
[ETSI-EN-301-598]. Valid values are the strings, "master" and [ETSI-EN-301-598]. Valid values are the strings "master" and
"slave". It is case insensitive. "slave". It is case insensitive.
9.2.2.7. ETSI Simultaneous Channel Operation Restriction 9.2.2.7. ETSI Simultaneous Channel Operation Restriction
Parameter name: etsiEnSimultaneousChannelOperationRestriction Parameter name: etsiEnSimultaneousChannelOperationRestriction
Parameter usage location: SpectrumSpec (Section 5.9) Parameter usage location: SpectrumSpec (Section 5.9)
Specification document(s): Specifies the constraint on the device Specification document(s): Specifies the constraint on the device
maximum total EIRP, as defined by the ETSI Harmonised Standard maximum total EIRP, as defined by the ETSI Harmonised Standard
[ETSI-EN-301-598]. The values are represented by numeric strings, [ETSI-EN-301-598]. The values are represented by numeric strings,
such as "0", "1", etc. Consult the documentation for the such as "0", "1", etc. Consult the documentation for the
specification of the power constraint corresponding to each specification of the power constraint corresponding to each
parameter value. parameter value.
9.3. PAWS Error Code Registry 9.3. PAWS Error Code Registry
This specification establishes the PAWS Error Code Registry. This specification establishes the "PAWS Error Code Registry".
Additional error codes for inclusion in PAWS error messages are Additional error codes for inclusion in PAWS error messages are
registered on the advice of one or more Designated Experts, with registered on the advice of one or more Designated Experts, with
Specification Required [RFC5226]. Specification Required [RFC5226].
Error codes are intended to be used for automated error handling by Error codes are intended to be used for automated error handling by
devices. Before approval, the Designated Expert should consider devices. Before approval, the Designated Expert should consider
whether a device would handle the new error code differently from an whether a device would handle the new error code differently from an
existing error code, or whether the difference could be communicated existing error code, or whether the difference could be communicated
effectively to the end-user via the "reason" parameter of the Error effectively to the end-user via the "reason" parameter of the Error
(Section 5.17) object. (Section 5.17) object.
The PAWS Error Code Registry will include the following: 'Code', The PAWS Error Code Registry includes the following: 'Code', 'Name',
'Name', 'Description and Additional parameters'. 'Description and Additional Parameters', and 'Specification
Document(s)'.
9.3.1. Registration Template 9.3.1. Registration Template
Code: Integer value of the error code. The value MUST be an Code: Integer value of the error code. The value MUST be an
unassigned value in the range -32768 to 32767, inclusive. unassigned value in the range -32768 to 32767, inclusive.
Name: Name of the error. Name: Name of the error.
Description and Additional parameters: Description of the error and Description and Additional Parameters: Description of the error and
its associated parameters, if any. It also lists additional its associated parameters, if any. It also lists additional
parameters that are returned in the data portion of the error (See parameters that are returned in the data portion of the error (see
Section 5.17). New parameters MUST be registered separately in Section 5.17). New parameters MUST be registered separately in
the PAWS Parameters Registry, as described by Section 9.2. the PAWS Parameters Registry, as described by Section 9.2.
9.3.2. Initial Registry Contents 9.3.2. Initial Registry Contents
Initial registry contents are defined in the Table of Error Codes Initial registry contents are defined in the Error Codes
(Table 1). Table (Table 1).
The registry will also include the error-code categories describing The registry will also include the error-code categories describing
-100s, -200s, and -300s as a note (see Error Codes (Section 5.17)). -100s, -200s, and -300s as a note (see "Error Codes" (Section 5.17)).
10. Security Considerations 10. Security Considerations
PAWS is a protocol whereby a Master Device requests a schedule of PAWS is a protocol whereby a Master Device requests a schedule of
available spectrum at its location (or location of its Slave Devices) available spectrum at its location (or location of its Slave Devices)
before it (they) can operate using those frequencies. Whereas the before it (they) can operate using those frequencies. Whereas the
information provided by the Database must be accurate and conform to information provided by the Database must be accurate and conform to
the applicable ruleset, the Database cannot enforce, through the the applicable ruleset, the Database cannot enforce, through the
protocol, that a client device uses only the spectrum it provided. protocol, that a client device uses only the spectrum it provided.
In other words, devices can put energy in the air and cause In other words, devices can put energy in the air and cause
interference without asking the Database. Hence, PAWS security interference without asking the Database. Hence, PAWS security
considerations do not include protection against malicious use of the considerations do not include protection against malicious use of the
White Space spectrum. For more detailed information on specific white-space spectrum. For more detailed information on specific
requirements and security considerations associated with PAWS, see requirements and security considerations associated with PAWS, see
"Protocol to Access White Space database: PAWS Use Cases and "Protocol to Access White-Space (PAWS) Databases: Use Cases and
Requirements" [RFC6953]. Requirements" [RFC6953].
By using PAWS, the Master Device and the Database expose themselves By using PAWS, the Master Device and the Database expose themselves
to the following risks: to the following risks:
o Accuracy: The Master Device receives incorrect spectrum- o Accuracy: The Master Device receives incorrect spectrum-
availability information. availability information.
o Privacy: o Privacy:
o
* An unauthorized entity intercepts identifying data for the * An unauthorized entity intercepts identifying data for the
Master Device or its Slave Devices, such as serial number and Master Device or its Slave Devices, such as serial number and
location. location.
* Where databases are required to take device registrations and/ * Where Databases are required to take device registrations and/
or maintain request logs, unauthorized access to such or maintain request logs, there could be unauthorized access to
information. such information.
Protection from these risks depends on the success of the following Protection from these risks depends on the success of the following
steps: steps:
1. The Master Device must determine the address of a proper 1. The Master Device must determine the address of a proper
database. Database.
2. The Master Device must connect to the proper database. 2. The Master Device must connect to the proper Database.
3. The Database must determine or compute accurate spectrum- 3. The Database must determine or compute accurate spectrum-
availability information. availability information.
4. PAWS messages must be transmitted unmodified between the Database 4. PAWS messages must be transmitted unmodified between the Database
and the Master Device. and the Master Device.
5. PAWS messages must be encrypted between the Database and the 5. PAWS messages must be encrypted between the Database and the
Master Device to prevent exposing private information. Master Device to prevent exposing private information.
6. For a Slave Device, the spectrum-availability information also 6. For a Slave Device, the spectrum-availability information also
must be transmitted unmodified and secure between the Master must be transmitted unmodified and securely between the Master
Device and the Slave Device. Device and the Slave Device.
7. When a Listing Server is required, any attack that would prevent 7. When a Listing Server is required, any attack that would prevent
reaching a Listing Server would result in all devices relying on reaching a Listing Server would result in all devices relying on
that Listing Server ceasing their use of any Whitespace. that Listing Server ceasing their use of any white space.
8. No future extensions to PAWS can allow the return of sensitive 8. No future extensions to PAWS can allow the return of sensitive
information, such as device information or logs information, such as device information or logs.
9. The Database must not allow unauthorized access to device 9. The Database must not allow unauthorized access to device
information and request logs and should publish and implement information and request logs and should publish and implement
privacy policies regarding their use. privacy policies regarding their use.
Of these, only steps 1, 2, 4, 5 and 8 are within the scope of this Of these, only steps 1, 2, 4, 5, and 8 are within the scope of this
document. This document addresses Step 1 by allowing static document. This document addresses step 1 by allowing static
provisioning of one or more trusted Databases; dynamic provisioning provisioning of one or more trusted Databases; dynamic provisioning
is out of scope. Step 3 is dependent on specific database is out of scope. Step 3 is dependent on specific database
implementations and rulesets and is outside the scope of this implementations and rulesets and is outside the scope of this
document. Step 6 requires a protocol between master and slave document. Step 6 requires a protocol between master and slave
devices and is thus outside the scope of this document. devices and is thus outside the scope of this document.
Use of "HTTP Over TLS" [RFC2818], assuming the PKI used is not Use of "HTTP Over TLS" [RFC2818], assuming the PKI used is not
compromised, ensures steps 2, 4, and 5, as detailed in the following compromised, ensures steps 2, 4, and 5, as detailed in the following
sections: sections:
o Assurance of Proper Database (Section 10.1) o "Assurance of Proper Database" (Section 10.1)
o Protection Against Modification (Section 10.2) o "Protection against Modification" (Section 10.2)
o Protection Against Eavesdropping (Section 10.3) o "Protection against Eavesdropping" (Section 10.3)
Any specification for an alternate transport MUST define mechanisms Any specification for an alternate transport MUST define mechanisms
that ensure each of these steps. that ensure each of these steps.
In addition to the privacy risks described above, information In addition to the privacy risks described above, information
provided in DeviceDescriptor (Section 5.2) and DeviceOwner provided in DeviceDescriptor (Section 5.2) and DeviceOwner
(Section 5.5), along with device location, may allow a Database (Section 5.5), along with device location, may allow a database
administrator to track the activity and location of a device and its administrator to track the activity and location of a device and its
user over time. Risks of secondary use of such tracking information, user over time. Risks of secondary use of such tracking information,
including sharing with third parties, require out-of-band mitigation, including sharing with third parties, require out-of-band mitigation,
such as public statements or contractual terms. Furthermore, while such as public statements or contractual terms. Furthermore, while
it is understandable that regulators require DeviceOwner information it is understandable that regulators require DeviceOwner information
for higher-power fixed white space devices, for privacy concerns, for higher-power fixed white-space devices, for privacy concerns,
regulators should not require DeviceOwner information for mobile regulators should not require DeviceOwner information for mobile
devices. Similarly, regulators should require, and implementations devices. Similarly, regulators should require, and implementations
should provide, device location at a level of granularity only as should provide, device location at a level of granularity only as
precise as necessary to support accurate database responses. precise as necessary to support accurate database responses.
10.1. Assurance of Proper Database 10.1. Assurance of Proper Database
This document assumes that the Database is contacted using a domain This document assumes that the Database is contacted using a domain
name or an IP address. Using HTTP over TLS, the Database name or an IP address. Using HTTP over TLS, the Database
authenticates its identity, either as a domain name or IP address, to authenticates its identity, either as a domain name or IP address, to
the Master Device by presenting a certificate containing that the Master Device by presenting a certificate containing that
identifier as a "subjectAltName" (i.e., as a dNSName or IP address). identifier as a "subjectAltName" (i.e., as a dNSName or IP address).
If the Master Device has external information as to the expected If the Master Device has external information as to the expected
identity or credentials of the proper database (e.g., a certificate identity or credentials of the proper Database (e.g., a certificate
fingerprint), checks of the subjectAltName MAY be omitted. Note that fingerprint), checks of the subjectAltName MAY be omitted. Note that
in order for the presented certificate to be valid at the client, the in order for the presented certificate to be valid at the client, the
client must be able to validate the certificate. In particular, the client must be able to validate the certificate. In particular, the
validation path of the certificate must end in one of the client's validation path of the certificate must end in one of the client's
trust anchors, even if that trust anchor is the Database certificate trust anchors, even if that trust anchor is the Database's
itself. A Master Device should allow for the fact that a Database certificate. A Master Device should allow for the fact that a
can change its certificate authorities (CAs) over time. Database can change its Certification Authorities (CAs) over time.
10.2. Protection Against Modification 10.2. Protection against Modification
To prevent a PAWS response message from being modified en route, To prevent a PAWS response message from being modified en route,
messages must be transmitted over an integrity-protected channel. messages must be transmitted over an integrity-protected channel.
Using HTTP over TLS, the channel will be protected by appropriate Using HTTP over TLS, the channel will be protected by appropriate
cypher suites. cipher suites.
10.3. Protection Against Eavesdropping 10.3. Protection against Eavesdropping
Using HTTP over TLS, messages protected by appropriate cypher suites Using HTTP over TLS, messages protected by appropriate cipher suites
are also protected from eavesdropping or otherwise unrestricted are also protected from eavesdropping or otherwise unrestricted
reading by unauthorized parties en route. reading by unauthorized parties en route.
10.4. Client Authentication Considerations 10.4. Client Authentication Considerations
Although the Database can inform a device of available spectrum it Although the Database can inform a device of available spectrum it
can use, the Database cannot enforce that the Master Device uses any/ can use, the Database cannot enforce that the Master Device uses only
only those frequencies. Indeed, a malicious device can operate (or any of) those frequencies. Indeed, a malicious device can
without ever contacting a database. Note also that, whereas a operate without ever contacting a Database. Note also that, whereas
malicious device may send fraudulent SPECTRUM_USE_NOTIFY a malicious device may send fraudulent SPECTRUM_USE_NOTIFY
(Section 4.5.5) messages, in the regulatory domains that have (Section 4.5.5) messages, in the regulatory domains that have
established rules, such notifications do not change the available- established rules, such notifications do not change the available-
spectrum answers, so no harm can result from such messages. spectrum answers, so no harm can result from such messages.
Consequently, client authentication is not required for the core PAWS Consequently, client authentication is not required for the core PAWS
(although it may be required by specific regulatory domains). (although it may be required by specific regulatory domains).
Depending on a prior relationship between a Database and Master Depending on a prior relationship between a Database and Master
Device, the Database MAY require client authentication. TLS provides Device, the Database MAY require client authentication. TLS provides
client authentication, but there are some considerations: client authentication, but there are some considerations:
o The Database must nominate acceptable CAs and the Master Device o The Database must nominate acceptable CAs, and the Master Device
must have a certificate rooted at one of those CAs. must have a certificate rooted at one of those CAs.
o As indicated in Section 3.2 of "HTTP Over TLS" [RFC2818], the TLS o As indicated in Section 3.2 of "HTTP Over TLS" [RFC2818], the TLS
client authentication procedure only determines that the device client authentication procedure only determines that the device
has a certificate chain rooted in an appropriate CA (or a self- has a certificate chain rooted in an appropriate CA (or a self-
signed certificate). The database would not know what the client signed certificate). The Database would not know what the client
identity ought to be, unless it has some external source of identity ought to be, unless it has some external source of
information. Distribution and management of such information, information. Distribution and management of such information,
including revocation lists, are outside the scope of this including revocation lists, are outside the scope of this
document. document.
o Authentication schemes are secure only to the extent that secrets o Authentication schemes are secure only to the extent that secrets
or certificates are kept secure. When there are a vast number of or certificates are kept secure. When there are a vast number of
deployed devices using PAWS, the possibility that device keys will deployed devices using PAWS, the possibility that device keys will
not leak becomes small. Implementations should consider how to not leak becomes small. Implementations should consider how to
manage the system in the eventuality that there is a leak. manage the system in the eventuality that there is a leak.
11. Contributors 11. References
This document draws heavily from the following Internet Draft
documents, draft-das-paws-protocol and draft-wei-paws-framework. The
editor would like to specifically call out and thank the contributing
authors of these two documents.
Donald Joslyn
Spectrum Bridge Inc.
1064 Greenwood Blvd.
Lake Mary, FL 32746
U.S.A.
Email: d.joslyn at spectrumbridge dot com
Xinpeng Wei
Huawei
Phone: +86 13436822355
Email: weixinpeng@huawei.com
12. Acknowledgments
The authors gratefully acknowledge the contributions of: Gabor Bajko,
Ray Bellis, Teco Boot, Nancy Bravin, Rex Buddenberg, Gerald
Chouinard, Stephen Farrell, Michael Fitch, Joel M. Halpern, Daniel
Harasty, Michael Head, Jussi Kahtava, Warren Kumari, Kalle Kulsmanen,
Paul Lambert, Andy Lee, Anthony Mancuso, Basavaraj Patil, Scott
Probasco, Brian Rosen, Andy Sago, Peter Stanforth, John Stine, and
Juan Carlos Zuniga.
13. References
13.1. Normative References
[I-D.ietf-uta-tls-bcp] 11.1. Normative References
Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of TLS and DTLS", draft-
ietf-uta-tls-bcp-06 (work in progress), October 2014.
[JSON-RPC] [JSON-RPC]
"JSON-RPC 2.0 Specification", "JSON-RPC 2.0 Specification",
<http://www.jsonrpc.org/specification>. <http://www.jsonrpc.org/specification>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Internet: Timestamps", RFC 3339, July 2002. Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<http://www.rfc-editor.org/info/rfc3339>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008. Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
January 2008, <http://www.rfc-editor.org/info/rfc5077>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009. RFC 5491, DOI 10.17487/RFC5491, March 2009,
<http://www.rfc-editor.org/info/rfc5491>.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
August 2011. DOI 10.17487/RFC6350, August 2011,
<http://www.rfc-editor.org/info/rfc6350>.
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
January 2014. DOI 10.17487/RFC7095, January 2014,
<http://www.rfc-editor.org/info/rfc7095>.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014. Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
(HTTP/1.1): Semantics and Content", RFC 7231, June 2014. Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>.
13.2. Informative References [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
11.2. Informative References
[ETSI-EN-301-598] [ETSI-EN-301-598]
European Telecommunication Standards Institute (ETSI), European Telecommunication Standards Institute (ETSI),
"ETSI EN 301 598 (V1.1.1): White Space Devices (WSD); "ETSI EN 301 598 (V1.1.1): White Space Devices (WSD);
Wireless Access Systems operating in the 470 MHz to 790 Wireless Access Systems operating in the 470 MHz to 790
MHz frequency band; Harmonized EN covering the essential MHz TV broadcast band; Harmonized EN covering the
requirements of article 3.2 of the R&TTE Directive", April essential requirements of article 3.2 of the R&TTE
2014, <http://www.etsi.org/deliver/ Directive", April 2014, <http://www.etsi.org/deliver/
etsi_en/301500_301599/301598/01.01.01_60/ etsi_en/301500_301599/301598/01.01.01_60/
en_301598v010101p.pdf>. en_301598v010101p.pdf>.
[FCC-CFR47-15H] [FCC-CFR47-15H]
U. S. Government, "Electronic Code of Federal Regulations, U. S. Government, "Electronic Code of Federal Regulations,
Title 47, Part 15, Subpart H: Television Band Devices", Title 47, Part 15, Subpart H: Television Band Devices",
December 2010, <http://www.ecfr.gov/cgi-bin/ December 2010, <http://www.ecfr.gov/cgi-bin/
text-idx?rgn=div6&view=text&node=47:1.0.1.1.16.8>. text-idx?rgn=div6&view=text&node=47:1.0.1.1.16.8>.
[FCC-Review-2012-10] [FCC-Review-2012-10]
Federal Communications Commission, "Administration Topics Federal Communications Commission, "Administration Topics
Review", October 2012, Review", October 2012,
<http://transition.fcc.gov/bureaus/oet/ea/presentations/ <http://transition.fcc.gov/bureaus/oet/ea/presentations/
files/oct12/2b-TCB-Admin-Issues-Oct-2012-GT.pdf>. files/oct12/2b-TCB-Admin-Issues-Oct-2012-GT.pdf>.
[I-D.ietf-geopriv-uncertainty]
Thomson, M. and J. Winterbottom, "Representation of
Uncertainty and Confidence in PIDF-LO", draft-ietf-
geopriv-uncertainty-04 (work in progress), October 2014.
[ISO3166-1] [ISO3166-1]
"Country Codes", "Country Codes",
<http://www.iso.org/iso/country_codes.htm>. <http://www.iso.org/iso/country_codes.htm>.
[RFC6953] Mancuso, A., Probasco, S., and B. Patil, "Protocol to [RFC6953] Mancuso, A., Ed., Probasco, S., and B. Patil, "Protocol to
Access White-Space (PAWS) Databases: Use Cases and Access White-Space (PAWS) Databases: Use Cases and
Requirements", RFC 6953, May 2013. Requirements", RFC 6953, DOI 10.17487/RFC6953, May 2013,
<http://www.rfc-editor.org/info/rfc6953>.
[RFC7459] Thomson, M. and J. Winterbottom, "Representation of
Uncertainty and Confidence in the Presence Information
Data Format Location Object (PIDF-LO)", RFC 7459,
DOI 10.17487/RFC7459, February 2015,
<http://www.rfc-editor.org/info/rfc7459>.
[WGS-84] National Imagery and Mapping Agency, "Department of [WGS-84] National Imagery and Mapping Agency, "Department of
Defense World Geodetic System 1984, Its Definition and Defense World Geodetic System 1984, Its Definition and
Relationships with Local Geodetic Systems, NIMA TR8350.2 Relationships with Local Geodetic Systems", NIMA TR8350.2,
Third Edition Amendment 1", January 2000, <http://earth- Third Edition, Amendment 1, January 2000,
info.nga.mil/GandG/publications/tr8350.2/tr8350_2.html>. <http://earth-info.nga.mil/GandG/publications/tr8350.2/
tr8350_2.html>.
Appendix A. Database Listing Server Support Appendix A. Database Listing Server Support
As discussed in Database Discovery (Section 4.1), some regulatory As discussed in "Database Discovery" (Section 4.1), some regulatory
domains support the preconfiguration of devices with the URI of a domains support the preconfiguration of devices with the URI of a
listing server, to which devices can connect to obtain a list of listing server, to which devices can connect to obtain a list of
databases certified by the regulatory domain. Regulatory domains may Databases certified by the regulatory domain. Regulatory domains may
require the device to periodically contact the Database Listing require the device to periodically contact the Database Listing
Server to validate and/or update its list of certified databases. If Server to validate and/or update its list of certified Databases. If
the device is unable to validate its list of certified databases the device is unable to validate its list of certified Databases
within the required period, regulatory rules may require the device within the required period, regulatory rules may require the device
to treat this inability as equivalent to the device having no to treat this inability as equivalent to the device having no
available spectrum. available spectrum.
A sample JSON response from a Database Listing Server might be A sample JSON response from a Database Listing Server might be
represented as follows: represented as follows:
{ {
"lastUpdateTime": "2014-06-28T10:00:00Z", "lastUpdateTime": "2014-06-28T10:00:00Z",
"maxRefreshMinutes": 1440 "maxRefreshMinutes": 1440
skipping to change at page 83, line 23 skipping to change at page 88, line 39
"uri": "https://example.some.operator.com", "uri": "https://example.some.operator.com",
"protocol": "paws" "protocol": "paws"
}, },
... ...
] ]
}, },
... ...
] ]
} }
In parameters in this sample message are: The parameters in this sample message are:
lastUpdateTime The time at which the database entries were last lastUpdateTime: The time at which the database entries were last
updated. updated.
maxRefreshMinutes The maximum interval, expressed in minutes, that maxRefreshMinutes: The maximum interval, expressed in minutes, that
is allowed between device requests to the Database Listing Server. is allowed between device requests to the Database Listing Server.
dbs A list of entries for certified databases, each containing the dbs: A list of entries for certified Databases, each containing the
following following
name The name of the database operator. name: The name of the database operator.
uris One or more URIs for each database, allowing a database to uris: One or more URIs for each Database, allowing a Database to
support more than one protocol. support more than one protocol.
uri, protocol Each protocol supported by a certified database is uri, protocol: Each protocol supported by a certified Database is
associated with a separate URI (PAWS protocol URI shown). associated with a separate URI (PAWS protocol URI shown).
Appendix B. Changes / Author Notes. Acknowledgments
[RFC Editor: Remove this section before publication.]
Changes from 15:
o More precise language: "supports none of the ruleset" instead of
"does not support any ruleset", where it makes sense.
o Batch request: Change MAY to MUST when some locations are
acceptable
o Remove explicit mention of OCSP and leave it up the the TLS best
practices draft
o Define power levels are EIRP for consistency
Changes from 14:
o Clarified why spectrum-notify is "informational"
o Clarified that device registration is typically only required for
fixed devices
o Global statement about timestamp format and must be UTC
o Global statement about MISSING error returned, whether it's
required by PAWS or ruleset
o Clarified UNSUPPORTED error
o Mandate that Database-change must be included in all responses a
minimum of 2 weeks before change
o Clarified that preconfigured values are ruleset specific
(INIT_RESP)
o Added reference to FCC ruleset for registration of Fixed Devices
o Make deviceOwner and serialNumber optional at PAWS level and
required on a per-ruleset basis
o Update description for "location" to be where device intends to
operate, rather than "current location"
o For REGISTRATION_RESP, add clarification that when it is returned,
it will have at least one RulesetInfo. Otherwise, it's an
UNSUPPORTED error.
o Clarified that, when a Master Device asks for spectrum on behalf
of a Slave Device, there are 2 locations in the message and
changed masterDeviceLocation to be required
o Indicate that power levels are typically EIRP (as opposed to
conducted power to the antenna)
o Added description for a "schedule"
o Add intro to DEVICE_VALID_REQ
o TLS: Follow best practices to improve security and interop.
Reference draft-ietf-uta-tls-bcp
o TLS: Use OCSP for better performance; RFC6960
o TLS: When using client auth, Database determines acceptable root
CAs
o Extensibility: Add statement that no extensions that return device
information will not be accepted
o Clarify IANA instructions for the Ruleset ID Registry
o Security: Acknowledge that unauthorized access to device
registration, other sensitive device info is a risk, and indicate
that privacy policies must be published and implement to control
access.
o
Changes from 13:
o Clarification in IANA Section 9
o Use full method name in description of the JSON examples in
Section 6
o Ask RFC Editor to give full iconectiv name in the Addresses
section
o Add URI to ETSC and FCC
Changes from 12:
o Define primitive types in Section 4, specifying UTF-8 for strings
and remove UTF-8 references elsewhere.
o Replace or rephrase "parameter" when reference is to higher-level
structure.
o Replace "MUST" with non-2119 language (maximum length is xxx
octets.
o Rephrase statements that reflected regulatory, not PAWS
requirements (e.g., deletion of "MUST" or "MAY" and rephrasing as
a regulatory requirement).
o Replace "Paws protocol (redundant) to "PAWS"
o Change "geo-location" to "geolocation"
o General references to "Database" changed to "database."
o Simplify Section 6 by showing several JSON encoding examples.
o Change "Device" to "device"
o Moved treatment of List Server as discovery mechanism to
Appendix and added JSON-encoded DB List Server response example.
Changes from 11:
o Change "regulatory rules" to "ruleset"
o Change "regulatory specifics" to "ruleset specifics"
o Change "regulatory-specific" to "ruleset-specific"
o Change "regulatory domain" to "ruleset" where appropriate
o Replace "depends on regulatory domain" to "optional" in tables
o Add "optional" to "*other" in tables
o Change "regulators" to "regulatory domains"
o Change "REQUIRED" error name to "MISSING"
o Changed the IANA instructions and added DE instructions to each
section
o Reformat and reorder IANA sections
Changes from 10:
o Ruleset Name change: ETSI-EN-301-598-1.0.9 and update reference to
PDF
o Add new ETSI parameter:
etsiEnSimultaneousChannelOperationRestriction
o Separate protocol requirements from regulatory requirements
Changes from 09:
o Updated format of the IANA section
Changes from 08:
o Fix JSON typos.
o Added note that JSON schema is not intended to be formally
validated
o Finalize paws-iana-review@ietf.org as the email for updating the
PAWS IANA registries
o URLs to URIs
o Typo fixes
Changes from 07:
o Propose ruleset ID name for ETSI: ETSI-EN-301-598-1.0.0-draft
o Change TBD email address to paws-iana-review@ietf.org for
proposing changes to the PAWS IANA registries
o Moved discussion of required vCard properties to regulatory-
specific sections
o Fixed vCard examples for organization names: Use "fn" property,
but set "kind" to "org".
o Shorten parameter names:
* freqHz -> hz
* powerDbmPerBw -> dbm
Changes from 06:
o Multi-ruleset support:
* Changed RulesetInfo to have single ruleset ID
* Changed INIT_RESP to return a list of RulesetInfo parameters,
rather than a single one
* Changed REGISTRATION_RESP to return a list of RulesetInfo
parameters to indicate the regulatory domains for which
registration was accepted
* Added SpectrumSpec (Section 5.9) parameter to represent
available-spectrum specification for one regulatory domain,
allowing AVAIL_SPECTRUM_RESP and AVAIL_SPECTRUM_BATCH_RESP to
include answers for multiple regulatory domains
* Changed GeoSpectrumSchedule to GeoSpectrumSpec (Section 5.15)
for supporting batch responses to represent available spectrum
for multiple regulatory domains at a location
o To avoid ambiguity or redundant information, clarified that:
* Event-time intervals within a single set of schedules MUST be
disjoint
* A single Spectrum element MUST cover the entire range of
frequencies governed by a ruleset, rather than splitting them
to present a "channelized" view
o Add "ruleset" to Terminology section
o Sync Terminology section with Use Case document
o Add "masterDeviceDesc" to Device Validate request
o Add "masterDeviceLocation" to the AVAIL_SPECTRUM requests and the
SPECTRUM_NOTIFY message. Change "location" to be the location of
the Slave Device, if the request is made by a Master Device on
behalf of a Slave Device
o Update vCard reference and example
o Add jsonrpc 2.0 to all sample messages
o Clarify that Listing Servers may be preconfigured in a device
o Clarify meaning of maximum power levels vs bandwidth, including
renaming parameter names:
o
* maxPowerDBm -> powerDbmPerBw
* bandwidth -> resolutionBwHz
o Explicitly allowed generic JSON-RPC error codes as possible codes.
o Replace SHALL with MUST for consistency
o Replace URI with URL for consistency
o Reduce clutter in JSON encoding examples by removing string-
concatenation characters
o Changed "depends" to "depends on regulatory rules" in several
places
Changes from 05:
o Remove requirement for JSON-RPC 1.0
o More typo fixes and clarifications
Changes from 04:
o Add "masterDeviceDesc" parameter to the available-spectrum
requests to allow both Master and Slave device descriptors when
the Master is making the request on behalf of a Slave.
o Add "requestType" parameter to the available-spectrum requests to
support requesting generic operating parameters for any Slave
Device.
o Add DbUpdateSpec as optional parameter to all response messages
and to the error response to allow a Device to detect a database
change at any stage of the control flow.
o For the OUTSIDE_COVERAGE error, added ability to return a list of
alternate databases
o Explicitly allow JSON-RPC v2.0 and v1.0 encodings
o Relaxed language that state, "MUST stop operation" to "MUST cease
use of spectrum under rules for database-managed spectrum". I.e.,
the device may have other fallback strategies allowed by
regulators.
Changes from 03:
o Expanded the Database Discovery mechanism to describe in more
detail pre-configuration with URLs of databases and database-
listing servers, including mechanisms for updating the
configurations when things change
* Add database-change field to Available Spectrum Response
(Section 4.5.2)
o Added fields that are anticipated to be needed by the ETSI
harmonized standard for White Space Devices:
* Added bandwidth constraints to the Available Spectrum Response
(Section 4.5.2)
* Updated Available Spectrum Response to return RulesetInfo,
rather than just a ruleset identifier
* Added optional device-manufacturer and device-model IDs to the
DeviceDescriptor (Section 5.2) message. Also moved fccId from
this message to the IANA section.
* Expanded IANA (Section 9) sections
o Clarified restrictions on the specification of the vertices of a
Polygon.
o Changed default confidence level to 95% for a point with
uncertainty
o Clarified how devices without absolute time source can use the
timestamps in the response messages
o Change method names to start with "spectrum.paws." prefix
o Added maximum string lengths
o Updated author contact info
o More typo fixes
Changes from 02:
o Added timestamp to the AVAIL_SPECTRUM_RESP (Section 4.5.2) and
AVAIL_SPECTRUM_BATCH_RESP (Section 4.5.4) data models to serve as
a reference for the event times in the response. This was
accidentally omitted (but was specified in their JSON encodings
(Section 6)).
o Fixed typos throughout the JSON encoding (Section 6) sections,
typically adding missing commas.
Changed from 01:
o Added a description of message sequences to support multiple
rulesets and multiple jurisdictions Section 3.1.
o Modified DeviceDescriptor (Section 5.2) to add rulesetIds
parameter
o Modified RulesetInfo (Section 5.6), AvailableSpectrumResponse
(Section 4.5.2) to add rulesetId parameter.
o Add Extensibility (Section 8) section.
o Filled in IANA (Section 9) section.
o Removed blank Example Messages section
Changes from 00:
o Add JSON encoding The authors gratefully acknowledge the contributions of: Gabor Bajko,
Ray Bellis, Teco Boot, Nancy Bravin, Rex Buddenberg, Gerald
Chouinard, Stephen Farrell, Michael Fitch, Joel M. Halpern, Daniel
Harasty, Michael Head, Jussi Kahtava, Kalle Kulsmanen, Warren Kumari,
Paul Lambert, Andy Lee, Anthony Mancuso, Basavaraj Patil, Scott
Probasco, Brian Rosen, Andy Sago, Peter Stanforth, John Stine, and
Juan Carlos Zuniga.
o Adopt RFC5491 for GeoLocation Contributors
o Adopt vCard for contact information This document draws heavily from draft-das-paws-protocol and
draft-wei-paws-framework. The editor would like to specifically call
out and thank the contributing authors of those two documents.
o Add Response Code section and update text referencing the defined Donald Joslyn
response codes Spectrum Bridge Inc.
1064 Greenwood Blvd.
Lake Mary, FL 32746
United States
EMail: d.joslyn@spectrumbridge.com
o Change DeviceIdentifier to be DeviceDescriptor, allowing Xinpeng Wei
identifiers and device-characteristic fields to be included. Huawei
Phone: +86 13436822355
EMail: weixinpeng@huawei.com
Authors' Addresses Authors' Addresses
Vincent Chen (editor) Vincent Chen (editor)
Google Google
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US United States
Email: vchen@google.com EMail: vchen@google.com
Subir Das Subir Das
Applied Communication Sciences Applied Communication Sciences
150 Mount Airy Road 150 Mount Airy Road
Basking Ridge, NJ 07920 Basking Ridge, NJ 07920
U.S.A. United States
Email: sdas at appcomsci dot com EMail: sdas@appcomsci.com
Lei Zhu Lei Zhu
Huawei Huawei
Phone: +86 13910157020 Phone: +86 13910157020
Email: lei.zhu@huawei.com EMail: lei.zhu@huawei.com
John Malyar John Malyar
iconectiv iconectiv (formerly Telcordia Interconnection Solutions)
444 Hoes Lane/RRC 4E1106 444 Hoes Lane/RRC 4E1106
Piscataway, NJ 08854 Piscataway, NJ 08854
U.S.A. United States
Email: jmalyar at iconectiv dot com EMail: jmalyar@iconectiv.com
Peter J. McCann Peter J. McCann
Huawei Huawei
400 Crossing Blvd, 2nd Floor 400 Crossing Blvd, 2nd Floor
Bridgewater, NJ 08807 Bridgewater, NJ 08807
USA United States
Phone: +1 908 541 3563 Phone: +1 908 541 3563
Email: peter.mccann@huawei.com EMail: peter.mccann@huawei.com
 End of changes. 396 change blocks. 
1200 lines changed or deleted 856 lines changed or added

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