draft-ietf-paws-protocol-14.txt   draft-ietf-paws-protocol-15.txt 
PAWS V. Chen, Ed. PAWS V. Chen, Ed.
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track S. Das Intended status: Standards Track S. Das
Expires: February 1, 2015 Applied Communication Sciences Expires: February 27, 2015 Applied Communication Sciences
L. Zhu L. Zhu
Huawei Huawei
J. Malyar J. Malyar
iconectiv iconectiv
P. McCann P. McCann
Huawei Huawei
July 31, 2014 August 26, 2014
Protocol to Access White-Space (PAWS) Databases Protocol to Access White-Space (PAWS) Databases
draft-ietf-paws-protocol-14 draft-ietf-paws-protocol-15
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.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 1, 2015. This Internet-Draft will expire on February 27, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Conventions Used in This Document . . . . . . . . . . . . 5 2.1. Conventions Used in This Document . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Multi-ruleset Support . . . . . . . . . . . . . . . . . . 7 3.1. Multi-ruleset Support . . . . . . . . . . . . . . . . . . 7
4. Protocol Functionalities . . . . . . . . . . . . . . . . . . 8 4. Protocol Functionalities . . . . . . . . . . . . . . . . . . 8
4.1. Database Discovery . . . . . . . . . . . . . . . . . . . 9 4.1. Database Discovery . . . . . . . . . . . . . . . . . . . 10
4.2. PAWS Version . . . . . . . . . . . . . . . . . . . . . . 10 4.2. PAWS Version . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Initialization . . . . . . . . . . . . . . . . . . . . . 11 4.3. Initialization . . . . . . . . . . . . . . . . . . . . . 11
4.3.1. INIT_REQ . . . . . . . . . . . . . . . . . . . . . . 11 4.3.1. INIT_REQ . . . . . . . . . . . . . . . . . . . . . . 12
4.3.2. INIT_RESP . . . . . . . . . . . . . . . . . . . . . . 12 4.3.2. INIT_RESP . . . . . . . . . . . . . . . . . . . . . . 13
4.4. Device Registration . . . . . . . . . . . . . . . . . . . 13 4.4. Device Registration . . . . . . . . . . . . . . . . . . . 14
4.4.1. REGISTRATION_REQ . . . . . . . . . . . . . . . . . . 14 4.4.1. REGISTRATION_REQ . . . . . . . . . . . . . . . . . . 15
4.4.2. REGISTRATION_RESP . . . . . . . . . . . . . . . . . . 15 4.4.2. REGISTRATION_RESP . . . . . . . . . . . . . . . . . . 15
4.5. Available Spectrum Query . . . . . . . . . . . . . . . . 16 4.5. Available Spectrum Query . . . . . . . . . . . . . . . . 16
4.5.1. AVAIL_SPECTRUM_REQ . . . . . . . . . . . . . . . . . 19 4.5.1. AVAIL_SPECTRUM_REQ . . . . . . . . . . . . . . . . . 19
4.5.2. AVAIL_SPECTRUM_RESP . . . . . . . . . . . . . . . . . 21 4.5.2. AVAIL_SPECTRUM_RESP . . . . . . . . . . . . . . . . . 21
4.5.3. AVAIL_SPECTRUM_BATCH_REQ . . . . . . . . . . . . . . 23 4.5.3. AVAIL_SPECTRUM_BATCH_REQ . . . . . . . . . . . . . . 24
4.5.4. AVAIL_SPECTRUM_BATCH_RESP . . . . . . . . . . . . . . 26 4.5.4. AVAIL_SPECTRUM_BATCH_RESP . . . . . . . . . . . . . . 26
4.5.5. SPECTRUM_USE_NOTIFY . . . . . . . . . . . . . . . . . 27 4.5.5. SPECTRUM_USE_NOTIFY . . . . . . . . . . . . . . . . . 27
4.5.6. SPECTRUM_USE_RESP . . . . . . . . . . . . . . . . . . 28 4.5.6. SPECTRUM_USE_RESP . . . . . . . . . . . . . . . . . . 28
4.6. Device Validation . . . . . . . . . . . . . . . . . . . . 29 4.6. Device Validation . . . . . . . . . . . . . . . . . . . . 29
4.6.1. DEV_VALID_REQ . . . . . . . . . . . . . . . . . . . . 30 4.6.1. DEV_VALID_REQ . . . . . . . . . . . . . . . . . . . . 30
4.6.2. DEV_VALID_RESP . . . . . . . . . . . . . . . . . . . 31 4.6.2. DEV_VALID_RESP . . . . . . . . . . . . . . . . . . . 31
5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 31 5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 31
5.1. GeoLocation . . . . . . . . . . . . . . . . . . . . . . . 31 5.1. GeoLocation . . . . . . . . . . . . . . . . . . . . . . . 31
5.2. DeviceDescriptor . . . . . . . . . . . . . . . . . . . . 34 5.2. DeviceDescriptor . . . . . . . . . . . . . . . . . . . . 34
5.3. AntennaCharacteristics . . . . . . . . . . . . . . . . . 35 5.3. AntennaCharacteristics . . . . . . . . . . . . . . . . . 35
skipping to change at page 3, line 33 skipping to change at page 3, line 33
6.2. Example Encoding: spectrum.paws.init Method . . . . . . . 55 6.2. Example Encoding: spectrum.paws.init Method . . . . . . . 55
6.3. Example Encoding: spectrum.paws.getSpectrum Method . . . 56 6.3. Example Encoding: spectrum.paws.getSpectrum Method . . . 56
6.4. Example Encoding: DeviceOwner vCard . . . . . . . . . . . 60 6.4. Example Encoding: DeviceOwner vCard . . . . . . . . . . . 60
7. HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . . . 60 7. HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . . . 60
8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 62 8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 62
8.1. Defining Ruleset Identifiers . . . . . . . . . . . . . . 62 8.1. Defining Ruleset Identifiers . . . . . . . . . . . . . . 62
8.2. Defining New Message Parameters . . . . . . . . . . . . . 63 8.2. Defining New Message Parameters . . . . . . . . . . . . . 63
8.3. Defining Additional Error Codes . . . . . . . . . . . . . 63 8.3. Defining Additional Error Codes . . . . . . . . . . . . . 63
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63
9.1. PAWS Ruleset ID Registry . . . . . . . . . . . . . . . . 64 9.1. PAWS Ruleset ID Registry . . . . . . . . . . . . . . . . 64
9.1.1. Registration Template . . . . . . . . . . . . . . . . 64 9.1.1. Registration Template . . . . . . . . . . . . . . . . 65
9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 66 9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 66
9.2. PAWS Parameters Registry . . . . . . . . . . . . . . . . 72 9.2. PAWS Parameters Registry . . . . . . . . . . . . . . . . 73
9.2.1. Registration Template . . . . . . . . . . . . . . . . 72 9.2.1. Registration Template . . . . . . . . . . . . . . . . 73
9.2.2. Initial Registry Contents . . . . . . . . . . . . . . 72 9.2.2. Initial Registry Contents . . . . . . . . . . . . . . 73
9.3. PAWS Error Code Registry . . . . . . . . . . . . . . . . 74 9.3. PAWS Error Code Registry . . . . . . . . . . . . . . . . 75
9.3.1. Registration Template . . . . . . . . . . . . . . . . 75 9.3.1. Registration Template . . . . . . . . . . . . . . . . 76
9.3.2. Initial Registry Contents . . . . . . . . . . . . . . 75 9.3.2. Initial Registry Contents . . . . . . . . . . . . . . 76
10. Security Considerations . . . . . . . . . . . . . . . . . . . 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 76
10.1. Assurance of Proper Database . . . . . . . . . . . . . . 77 10.1. Assurance of Proper Database . . . . . . . . . . . . . . 78
10.2. Protection Against Modification . . . . . . . . . . . . 77 10.2. Protection Against Modification . . . . . . . . . . . . 78
10.3. Protection Against Eavesdropping . . . . . . . . . . . . 77 10.3. Protection Against Eavesdropping . . . . . . . . . . . . 78
10.4. Client Authentication Considerations . . . . . . . . . . 77 10.4. Client Authentication Considerations . . . . . . . . . . 79
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 78 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 79
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 78 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 80
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 79 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 80
13.1. Normative References . . . . . . . . . . . . . . . . . . 79 13.1. Normative References . . . . . . . . . . . . . . . . . . 80
13.2. Informative References . . . . . . . . . . . . . . . . . 80 13.2. Informative References . . . . . . . . . . . . . . . . . 81
Appendix A. Database Listing Server Support . . . . . . . . . . 81 Appendix A. Database Listing Server Support . . . . . . . . . . 82
Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 82 Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 83
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 91
1. Introduction 1. Introduction
[RFC Editor: In the Author's Addresses section, please list [RFC Editor: In the Author's Addresses section, please list
"iconectiv" as "iconectiv (formerly Telcordia Interconnection "iconectiv" as "iconectiv (formerly Telcordia Interconnection
Solutions). One occurrence."] Solutions). One occurrence."]
This section provides some high level introductory material. Readers 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
skipping to change at page 4, line 27 skipping to change at page 4, line 27
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
numerous devices. It opens the door for innovations in spectrum numerous devices. It opens the door for innovations in spectrum
management that can incorporate a variety of parameters, including management that can incorporate a variety of parameters, including
user location and time. In the future, it also can include other user location and time. In the future, it also can include other
parameters, such as user priority, time, signal type and power, parameters, such as user priority, signal type and power, spectrum
spectrum supply and demand, payment or micro-auction bidding, and supply and demand, payment or micro-auction bidding, and more.
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, and hidden from devices to the maximum extent possible. database, 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 and
within which the device is authorized to operate. 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
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.
skipping to change at page 7, line 6 skipping to change at page 7, line 9
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 valid. Slave Device is valid.
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. to the Database. The notification is purely informational for
notifying the Database what spectrum it intends to use and is
not a request to the Database to get permission to use that
spectrum.
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.
skipping to change at page 8, line 30 skipping to change at page 8, line 36
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 have 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. device types, such as higher-power fixed (as opposed to mobile)
devices to allow them to contact the operators to resolve any
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
skipping to change at page 9, line 30 skipping to change at page 9, line 38
boolean: A boolean, as defined by JSON [RFC7159]. boolean: A boolean, as defined by JSON [RFC7159].
list: A structured type that represents a list of elements, as list: A structured type that represents a list of elements, as
defined by JSON [RFC7159] array type. All elements of the list defined by JSON [RFC7159] array type. All elements of the list
are of the same data type, which is indicated in its diagram and are of the same data type, which is indicated in its diagram and
description. The diagram notation and description may include description. The diagram notation and description may include
additional constraints, such as minimum or maximum number of additional constraints, such as minimum or maximum number of
elements. elements.
NOTE: All parameter names are case sensitive. Unless stated Also:
otherwise, all string values are case sensitive.
o All parameter names are case sensitive. Unless stated otherwise,
all string values are case sensitive.
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
Internet: Timestamps" [RFC3339].
In some cases, specific rulesets may place additional requirements on
message parameters. These additional requirements will be documented
in the IANA PAWS Ruleset ID Registry. (Section 9.1). When a request
message sent to the Database has missing parameters, whether they are
required by PAWS or the applicable ruleset, the Database returns the
MISSING (Section 5.17.3) error, along with data indicating the
missing parameters.
4.1. Database Discovery 4.1. Database Discovery
Preconfiguration 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.
skipping to change at page 10, line 4 skipping to change at page 10, line 25
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 Listing Server Support (Appendix A) for further
information. information.
Configuration Update: Database URI changes 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 so by including the URI of one or more alternate databases
using DbUpdateSpec (Section 5.7) in its responses to devices. A using DbUpdateSpec (Section 5.7) in its responses to devices. The
device will update its preconfigured entry for the Database sending Database MUST reply with DbUpdateSpec for a minimum of 2 weeks before
the DbUpdateSpec by replacing this entry with the alternate databases disabling the old URI. A device will update its preconfigured entry
listed in the DbUpdateSpec; the list of alternate databases does not for the Database sending the DbUpdateSpec by replacing this entry
affect any other entries. Note that the ordering of databases in the with the alternate databases listed in the DbUpdateSpec; the list of
list does not imply any preference and does not need to remain the alternate databases does not affect any other entries. Note that the
same for every request. The device SHOULD detect infinite ordering of databases in the list does not imply any preference and
redirection loops; if a suitable database cannot be contacted, the does not need to remain the same for every request. The device
device MUST treat this as equivalent to a response indicating no SHOULD detect infinite redirection loops; if a suitable database
available spectrum. This database-change mechanism is used, for cannot be contacted, the device MUST treat this as equivalent to a
example, before a Database ceases operation; it is not intended to be response indicating no available spectrum. This database-change
used for dynamic load balancing. mechanism is used, for example, before a Database ceases operation;
it is not intended to be used for dynamic load balancing.
Error Handling 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 may indicate that the database does Codes (Section 5.17)), which indicates the database does not
not support the regulatory domain where the device is located. support the device (based on its device type, model, etc.) or does
not support any 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; but after that period, the device will no
longer have valid spectrum to use. Some regulatory domains may have longer have valid spectrum to use. Some regulatory domains may have
specific rules regarding how long the spectrum data remains valid in specific rules regarding how long the spectrum data remains valid in
these cases. these cases.
skipping to change at page 11, line 16 skipping to change at page 11, line 41
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, such as threshold distances and time parameterized-rule values for each supported ruleset, such as
periods beyond which the device must update its available-spectrum threshold distances and time periods beyond which the device must
data (see RuleSetInfo (Section 5.6)). When a Master Device is not update its available-spectrum data (see RuleSetInfo (Section 5.6)).
configured manually with these parameterized-rule values, it MUST use When parameterized-rule values are not preconfigured for the
the initialization procedure. For database implementations that applicable ruleset at the specified location, a Master Device MUST
require it, the initialization message also enables extra database- use the initialization procedure.
specific or ruleset-specific handshake parameters to be communicated
before allowing available-spectrum requests. It is important to note that, when parameterized-rule values are
preconfigured in a Master Device, they are preconfigured on a per-
ruleset basis. That is, values preconfigured for one ruleset is not
applicable to any other ruleset.
For database implementations that require it, the initialization
message also enables extra database-specific or ruleset-specific
handshake parameters to be communicated before allowing available-
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
o INIT_RESP (Section 4.3.2) is the initialization response message o INIT_RESP (Section 4.3.2) is the initialization response message
+---------------+ +-------------------+ +---------------+ +-------------------+
| Master Device | | Spectrum Database | | Master Device | | Spectrum Database |
+---------------+ +-------------------+ +---------------+ +-------------------+
skipping to change at page 13, line 40 skipping to change at page 14, line 20
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. identifier, its location, and its antenna height (see 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 Spectrum Availability
request. If the Database does not implement a separate Device request. If the Database does not implement a separate Device
Registration request, it MUST return an error with the UNIMPLEMENTED Registration request, it MUST return an error with the UNIMPLEMENTED
(Table 1) code in the error-response message. (Table 1) code 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
skipping to change at page 14, line 32 skipping to change at page 15, line 16
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 | required | |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. If indicate the rulesets for which the device wishes to register.
the registration information is unacceptable for all of the
rulesets supported by the Database, the Database MUST return an
error message with an appropriate error code. Otherwise, the
Database MUST return, in its response, a RulesetInfo (Section 5.6)
list that specifies all rulesets for which device registration was
accepted.
location: The GeoLocation (Section 5.1) for the device is REQUIRED. location: The GeoLocation (Section 5.1) for the device is REQUIRED.
If the location is outside all regulatory domains supported by the More precisely, this is the location at which the device intends
Database, the Database MUST respond with an OUTSIDE_COVERAGE to operate. If the location is outside all regulatory domains
(Table 1) error. supported by the Database, the Database MUST respond with an
OUTSIDE_COVERAGE (Table 1) error.
deviceOwner: The DeviceOwner (Section 5.5) information is REQUIRED. deviceOwner: The DeviceOwner (Section 5.5) information is OPTIONAL.
Some rulesets may require deviceOwner information under certain
conditions. See PAWS Ruleset ID Registry (Section 9.1) for
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
Master Device MAY send a union of the registration information Master Device MAY send a union of the registration information
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.
skipping to change at page 15, line 43 skipping to change at page 16, line 24
|*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
specified in the DeviceDescriptor of REGISTRATION_REQ.
If the Database does not support the device or any of the rulesets
specified in the DeviceDescriptor, it MUST instead return an error
with the UNSUPPORTED (Table 1) code in the 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.
skipping to change at page 18, line 20 skipping to change at page 18, line 38
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.
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 asking for available spectrum on behalf of a Slave The procedure for a Master Device asking for available spectrum on
Device is similar, except that the process is initiated by the Slave behalf of a Slave Device is similar, except that the process is
Device. The device identifier, capabilities, and characteristics initiated by the Slave Device. The device identifier, capabilities,
communicated in the AVAIL_SPECTRUM_REQ message MUST be those of the and characteristics communicated in the AVAIL_SPECTRUM_REQ message
Slave Device, but the location MUST be that of the Master Device. MUST be those of the Slave Device, and:
o The "masterDeviceLocation" field specifying the location of the
Master Device is REQUIRED.
o The "location" field specifying the location of the Slave Device
is OPTIONAL, since the Slave Device may not have location-sensing
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 is 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 | |
|................>| | |................>| |
skipping to change at page 19, line 46 skipping to change at page 20, line 14
+----------------------------------------------------+ +----------------------------------------------------+
|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 | optional | |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. The location SHOULD be the current location available spectrum. This is the location at which the device
of the device, but more precisely, the location of the radiation intends to operate, but more precisely, the location of the
center of the device's antenna. When the request is made by the radiation center of the device's antenna. When the request is
Master Device on its own behalf, the location is that of the made by the Master Device on its own behalf, the location is that
Master Device and it is REQUIRED. When the request is made by the of the Master Device and it is REQUIRED. When the request is made
Master Device on behalf of a Slave Device, the location is that of by 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 (Table 1) code, if it does not implement query by
region. region.
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
skipping to change at page 20, line 48 skipping to change at page 21, line 16
(Section 5.4) to limit the available-spectrum response to the (Section 5.4) to limit the available-spectrum response to the
spectrum that is compatible with its capabilities. The Database spectrum that is compatible with its capabilities. The Database
SHOULD NOT return spectrum that is not compatible with the SHOULD NOT return spectrum that is not compatible with the
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 MAY provide its own on behalf of a Slave Device, the Master Device MUST provide its
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, which may be used to
modify the request, but its use depends on the applicable ruleset. modify the request, but its use depends on the applicable ruleset.
The request type may be used, for example, to indicate that the 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 IANA Ruleset Registry, Initial
Registry Contents (Section 9.1.2) for ruleset specifics. Registry Contents (Section 9.1.2) for ruleset specifics.
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
skipping to change at page 21, line 27 skipping to change at page 21, line 43
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) request. 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
duration defined by a pair of start and stop times. The power
levels typically 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
for the next 24 hours. If spectrum availability were to be different
at different times of day, the response would contain a list of
schedules, each transition representing some change to the spectrum
availability. A device might use different strategies to select
which spectrum to use, e.g.:
o Always use the frequencies that permit the highest power
o Use the frequencies that is available for the longest period of
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..*
skipping to change at page 22, line 39 skipping to change at page 23, line 5
V V
+-------------------------------+ +-------------------------------+
|SpectrumSchedule | |SpectrumSchedule |
+--------------------+----------+ +--------------------+----------+
|eventTime:EventTime | required | |eventTime:EventTime | required |
|spectra:list | required | |spectra:list | required |
+--------------------+----------+ +--------------------+----------+
Parameters: Parameters:
timestamp: Timestamp of the response of the form, YYYY-MM- timestamp: Timestamp of the response is expressed using 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_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.
skipping to change at page 24, line 22 skipping to change at page 24, line 37
+---------------------------------------------------+ +---------------------------------------------------+
|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 | optional | | |masterDeviceLocation:GeoLocation | see description | |
|requestType:string | optional | | |requestType:string | optional | |
+.................................+.................+ | +.................................+.................+ |
|*other:any | optional | | |*other:any | optional | |
+---------------------------------+-----------------+ | +---------------------------------+-----------------+ |
| |
1..* V 1..* V
+-------------+ +-------------+
| GeoLocation | | GeoLocation |
+-------------+ +-------------+
skipping to change at page 25, line 30 skipping to change at page 25, line 44
(Section 5.4) to limit the available-spectrum response to the (Section 5.4) to limit the available-spectrum response to the
spectrum that is compatible with its capabilities. The Database spectrum that is compatible with its capabilities. The Database
SHOULD NOT return spectrum that is not compatible with the SHOULD NOT return spectrum that is not compatible with the
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 MAY provide its own on behalf of a Slave Device, the Master Device MUST provide its
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 applicable the
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 IANA Ruleset Registry, Initial Registry Contents
(Section 9.1.2) for ruleset specifics. (Section 9.1.2) for ruleset specifics.
skipping to change at page 27, line 26 skipping to change at page 27, line 35
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 | optional | |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 |
skipping to change at page 28, line 26 skipping to change at page 28, line 33
expresses maximum power spectral density in terms of maximum power expresses maximum power spectral density in terms of maximum power
over any 100 kHz band, then the "resolutionBwHz" value should be over any 100 kHz band, then the "resolutionBwHz" value should be
set to 100 kHz, even though the actual bandwidth used can be 20 set to 100 kHz, even though the actual bandwidth used can be 20
kHz. kHz.
masterDeviceDesc: When the notification is made by the Master Device masterDeviceDesc: When the notification is made by the Master Device
on behalf of a Slave Device, the Master Device MAY provide its own on behalf of a Slave Device, the Master Device MAY provide its own
descriptor. descriptor.
masterDeviceLocation: When the notification is made by the Master masterDeviceLocation: When the notification is made by the Master
Device on behalf of a Slave Device, the Master Device MAY include Device on behalf of a Slave Device, the Master Device MUST include
its own GeoLocation (Section 5.1). its own GeoLocation (Section 5.1).
other: Depending on the ruleset, other parameters may be required. other: Depending on the ruleset, other parameters may be required.
To simplify its logic, the device MAY include the union of all To simplify its logic, the device MAY include the union of all
parameters required by all supported rulesets. The Database MUST parameters required by all supported rulesets. The Database MUST
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
skipping to change at page 30, line 30 skipping to change at page 30, line 30
|................>| (SPECTRUM_USE_NOTIFY) | |................>| (SPECTRUM_USE_NOTIFY) |
| |-------------------------->| | |-------------------------->|
| | | | | |
| | (SPECTRUM_USE_RESP) | | | (SPECTRUM_USE_RESP) |
| |<--------------------------| | |<--------------------------|
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
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 |
+----------------------+ +----------------------+
skipping to change at page 34, line 24 skipping to change at page 34, line 24
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 | required | |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 REQUIRED. serialNumber: The manufacturer's device serial number is OPTIONAL,
Its maximum length is 64 octets, conforming to the X.520 although rulesets typically require it. Its maximum length is 64
[ITUT.X520.2008] recommendations. 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.
skipping to change at page 37, line 20 skipping to change at page 37, line 20
+------------------+----------+ +------------------+----------+
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.
NOTE: Depending on the ruleset, the Database may be required to See PAWS Ruleset ID Registry (Section 9.1) for ruleset-specific
validate the device-owner information. In these cases, the Database requirements on mandatory vCard properties. Depending on the
MUST respond with an INVALID_VALUE error (see Error Codes ruleset, the Database may be required to validate the device-owner
(Section 5.17)) if validation fails. See PAWS Ruleset ID Registry information. In these cases, the Database MUST respond with an
(Section 9.1) for ruleset-specific requirements on mandatory vCard INVALID_VALUE error (see Error Codes (Section 5.17)) if validation
properties. 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, conforming to X.520 [ITUT.X520.2008] for each parameter, conforming to X.520 [ITUT.X520.2008]
recommendations. recommendations.
5.6. RulesetInfo 5.6. RulesetInfo
RulesetInfo contains parameters for the ruleset of a regulatory RulesetInfo contains parameters for the ruleset of a regulatory
skipping to change at page 50, line 4 skipping to change at page 50, line 4
PAWS Error Code Registry (Section 9.3). PAWS Error Code Registry (Section 9.3).
Code Name Description & Additional parameters Code Name Description & 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. For
example, it does not support the ruleset example, it does not support any ruleset
specified in the request. This error does not specified in the request or does not support
use any additional data. the device, based on its device type, model,
etc. This error does not use any additional
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 (Section
5.17.1) for more details. 5.17.1) for more details.
skipping to change at page 52, line 47 skipping to change at page 52, line 47
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 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
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"
} }
skipping to change at page 53, line 26 skipping to change at page 53, line 26
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
associated with the method. associated with the method, and "id" is copied from the request.
The error JSON-RPC Response for PAWS has the following form: The error JSON-RPC Response for PAWS has the following form:
{ {
"jsonrpc": "2.0", "jsonrpc": "2.0",
"error": { "error": {
"code": -102, "code": -102,
"message": "An appropriate error message.", "message": "An appropriate error message.",
"data": { ... } "data": { ... }
}, },
skipping to change at page 60, line 50 skipping to change at page 60, line 50
["email", {}, "text", "j.frax@rackafrax.com"] ["email", {}, "text", "j.frax@rackafrax.com"]
] ]
] ]
} }
} }
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. The and confidentiality between the Master Device and the Database, but
Master Device MUST implement server authentication, as described in only when best current practices are adopted, including use of
Section 3.1 of "HTTP Over TLS" [RFC2818]. The device uses the URI recommended cipher suites and modes of operation. Consequently, to
determined (either statically configured or dynamically discovered) improve PAWS security and interoperability, implementations of the
to authenticate the server. The device SHOULD fail a request if Database and Master Device MUST follow best current practices defined
server authentication fails. by Recommendations for Secure Use of TLS and DTLS
[I-D.ietf-uta-tls-bcp]. Additionally, to improve performance, the
Master Device SHOULD use Online Certificate Status Protocol - OCSP
[RFC6960] to check the validity of the Database certificate, rather
than downloading Certificate Revocation Lists (CRLs).
Depending on prior relationship between a database and device, the Depending on 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. the device. When client authentication is required, the database
MUST specify, by prior arrangement, acceptable root Certificate
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
skipping to change at page 62, line 4 skipping to change at page 62, line 10
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 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.
Before the URL of the Database changes permanently, it SHOULD use the For a minimum of two weeks before the URI of the Database changes
database-change (DbUpdateSpec (Section 5.7)) mechanism to notify permanently, it MUST use the database-change (DbUpdateSpec
devices, as described in the Configuration Update portion of the (Section 5.7)) mechanism to notify devices, as described in the
Database Discovery (Section 4.1) section. After the Database has Configuration Update portion of the Database Discovery (Section 4.1)
moved, requests to the original URL MAY return HTTP status code "301 section. After the Database has moved, requests to the original URI
Moved Permanently" to indicate that the device SHOULD resubmit the MAY return HTTP status code "301 Moved Permanently" to indicate that
request, and all future requests, to the indicated alternate URI. the device SHOULD resubmit the request, and all future requests, to
the indicated alternate URI.
8. Extensibility 8. Extensibility
This section describes procedures for extending PAWS. No extensions
should be made that would return sensitive device-specific
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
skipping to change at page 64, line 41 skipping to change at page 64, line 49
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 will include the following: 'Ruleset
identifier', 'Specification document(s)', and 'Additional Parameter identifier', 'Specification document(s)', and 'Template'. The
Requirements'. Template column will include links to the registration templates,
either posted by IANA or 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 [[ this document
]], Section 8.1 for the format requirements of this identifier. ]], Section 8.1 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.
skipping to change at page 66, line 5 skipping to change at page 66, line 11
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 included in the
text of an RFC. text of an RFC.
Note that the Additional Parameter Requirements section can be quite
extensive, so it will not appear directly in the IANA Ruleset ID
Registry table. The table, however, does contain a link to the full
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.
The initial contents of the PAWS Ruleset ID Registry are listed The initial contents of the PAWS Ruleset ID Registry are listed
skipping to change at page 66, line 33 skipping to change at page 66, line 44
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,
deviceOwner is required in the registration request:
Registration Request (Section 4.4.1)
+-------------+-------------------+-------------+-------------------+
| Parameter | Type | Requirement | Notes |
| Name | | | |
+-------------+-------------------+-------------+-------------------+
| deviceOwner | DeviceOwner | REQUIRED | For registering |
| | (Section 5.5) | | Fixed Devices |
+-------------+-------------------+-------------+-------------------+
Available Spectrum Request (Section 4.5.1) Available Spectrum Request (Section 4.5.1)
+---------------+-----------------------------+-------------+-------+ +---------------+-----------------------------+-------------+-------+
| Parameter | Type | Requirement | Notes | | Parameter | Type | Requirement | Notes |
| Name | | | | | Name | | | |
+---------------+-----------------------------+-------------+-------+ +---------------+-----------------------------+-------------+-------+
| deviceDesc | DeviceDescriptor (Section | REQUIRED | | | deviceDesc | DeviceDescriptor (Section | REQUIRED | |
| | 5.2) | | | | | 5.2) | | |
+---------------+-----------------------------+-------------+-------+ +---------------+-----------------------------+-------------+-------+
skipping to change at page 67, line 4 skipping to change at page 67, line 24
Available Spectrum Request (Section 4.5.1) Available Spectrum Request (Section 4.5.1)
+---------------+-----------------------------+-------------+-------+ +---------------+-----------------------------+-------------+-------+
| Parameter | Type | Requirement | Notes | | Parameter | Type | Requirement | Notes |
| Name | | | | | Name | | | |
+---------------+-----------------------------+-------------+-------+ +---------------+-----------------------------+-------------+-------+
| deviceDesc | DeviceDescriptor (Section | REQUIRED | | | deviceDesc | DeviceDescriptor (Section | REQUIRED | |
| | 5.2) | | | | | 5.2) | | |
+---------------+-----------------------------+-------------+-------+ +---------------+-----------------------------+-------------+-------+
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 | | | |
+---------------+-----------------------------+-------------+-------+ +---------------+-----------------------------+-------------+-------+
| 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 |
| | | | serial number. See [[ |
| | | | this document ]], |
| | | | 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. |
+-------------------+--------+-------------+------------------------+ +-------------------+--------+-------------+------------------------+
skipping to change at page 69, line 9 skipping to change at page 70, line 9
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) DeviceDescriptor (Section 5.2)
+-------------------------+-------+-------------+-------------------+ +-------------------------+-------+-------------+-------------------+
| Parameter Name | Type | Requirement | Notes | | Parameter Name | Type | Requirement | Notes |
+-------------------------+-------+-------------+-------------------+ +-------------------------+-------+-------------+-------------------+
| serialNumber | strin | REQUIRED | Specifies a |
| | g | | device's serial |
| | | | number. See [[ |
| | | | this document ]], |
| | | | Section 5.2. |
| manufacturerId | strin | REQUIRED | Specifies a | | manufacturerId | strin | REQUIRED | Specifies a |
| | g | | device's | | | g | | device's |
| | | | manufacturer's | | | | | manufacturer's |
| | | | identifier. See | | | | | identifier. See |
| | | | [[ this document | | | | | [[ this document |
| | | | ]], Section 5.2. | | | | | ]], Section 5.2. |
| modelId | strin | REQUIRED | Specifies a | | modelId | strin | REQUIRED | Specifies a |
| | g | | device's model | | | g | | device's model |
| | | | identifier. See | | | | | identifier. See |
| | | | [[ this document | | | | | [[ this document |
skipping to change at page 74, line 34 skipping to change at page 75, line 34
[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 Effective isotropically radiated power (EIRP), as maximum total EIRP, as defined by the ETSI Harmonised Standard
defined by the ETSI Harmonised Standard [ETSI-EN-301-598]. The [ETSI-EN-301-598]. The values are represented by numeric strings,
values are represented by numeric strings, such as "0", "1", etc. such as "0", "1", etc. Consult the documentation for the
Consult the documentation for the specification of the power specification of the power constraint corresponding to each
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
skipping to change at page 76, line 5 skipping to change at page 77, line 5
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 database: PAWS 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: An unauthorized entity intercepts identifying data for o Privacy:
the Master Device or its Slave Devices, such as serial number and
location. o
* An unauthorized entity intercepts identifying data for the
Master Device or its Slave Devices, such as serial number and
location.
* Where databases are required to take device registrations and/
or maintain request logs, unauthorized access to 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-
skipping to change at page 76, line 34 skipping to change at page 77, line 42
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 secure 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 Whitespace.
Of these, only steps 1, 2, 4, and 5 are within the scope of this 8. No future extensions to PAWS can allow the return of sensitive
information, such as device information or logs
9. The Database must not allow unauthorized access to device
information and request logs and should publish and implement
privacy policies regarding their use.
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] ensures steps 2, 4, and 5, as Use of "HTTP Over TLS" [RFC2818], assuming the PKI used is not
detailed in the following sections: compromised, ensures steps 2, 4, and 5, as detailed in the following
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.
skipping to change at page 78, line 5 skipping to change at page 79, line 22
(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
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
skipping to change at page 79, line 9 skipping to change at page 80, line 31
Chouinard, Stephen Farrell, Michael Fitch, Joel M. Halpern, Daniel Chouinard, Stephen Farrell, Michael Fitch, Joel M. Halpern, Daniel
Harasty, Michael Head, Jussi Kahtava, Warren Kumari, Kalle Kulsmanen, Harasty, Michael Head, Jussi Kahtava, Warren Kumari, Kalle Kulsmanen,
Paul Lambert, Andy Lee, Anthony Mancuso, Basavaraj Patil, Scott Paul Lambert, Andy Lee, Anthony Mancuso, Basavaraj Patil, Scott
Probasco, Brian Rosen, Andy Sago, Peter Stanforth, John Stine, and Probasco, Brian Rosen, Andy Sago, Peter Stanforth, John Stine, and
Juan Carlos Zuniga. Juan Carlos Zuniga.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-uta-tls-bcp]
Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of TLS and DTLS", draft-
ietf-uta-tls-bcp-02 (work in progress), August 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, March 1997.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
skipping to change at page 79, line 40 skipping to change at page 81, line 20
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[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, March 2009.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
August 2011. August 2011.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, June 2013.
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
January 2014. January 2014.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014. Interchange Format", RFC 7159, March 2014.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231, June 2014. (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
13.2. Informative References 13.2. Informative References
skipping to change at page 80, line 32 skipping to change at page 82, line 14
[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] [I-D.ietf-geopriv-uncertainty]
Thomson, M. and J. Winterbottom, "Representation of Thomson, M. and J. Winterbottom, "Representation of
Uncertainty and Confidence in PIDF-LO", draft-ietf- Uncertainty and Confidence in PIDF-LO", draft-ietf-
geopriv-uncertainty-01 (work in progress), July 2014. geopriv-uncertainty-02 (work in progress), August 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>.
[ITUT.X520.2008] [ITUT.X520.2008]
International Telecommunication Union, "ITU-T International Telecommunication Union, "ITU-T
Recommendation X.520: Information technology - Open Recommendation X.520: Information technology - Open
Systems Interconnection - The Directory: Selected Systems Interconnection - The Directory: Selected
attribute types", November 2008, attribute types", November 2008,
skipping to change at page 82, line 20 skipping to change at page 83, line 46
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. Appendix B. Changes / Author Notes.
[RFC Editor: Remove this section before publication.] [RFC Editor: Remove this section before publication.]
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: Changes from 13:
o Clarification in IANA Section 9 o Clarification in IANA Section 9
o Use full method name in description of the JSON examples in o Use full method name in description of the JSON examples in
Section 6 Section 6
o Ask RFC Editor to give full iconectiv name in the Addresses o Ask RFC Editor to give full iconectiv name in the Addresses
section section
 End of changes. 65 change blocks. 
143 lines changed or deleted 345 lines changed or added

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