draft-ietf-paws-protocol-08.txt   draft-ietf-paws-protocol-09.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: July 18, 2014 Applied Communication Sciences Expires: August 3, 2014 Applied Communication Sciences
L. Zhu L. Zhu
Huawei Huawei
J. Malyar J. Malyar
iconectiv (formerly Telcordia iconectiv (formerly Telcordia
Interconnection Solutions) Interconnection Solutions)
P. McCann P. McCann
Huawei Huawei
January 14, 2014 January 30, 2014
Protocol to Access White-Space (PAWS) Databases Protocol to Access White-Space (PAWS) Databases
draft-ietf-paws-protocol-08 draft-ietf-paws-protocol-09
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 49 skipping to change at page 1, line 49
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 July 18, 2014. This Internet-Draft will expire on August 3, 2014.
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 3, line 31 skipping to change at page 3, line 31
6.1. JSON-RPC Binding . . . . . . . . . . . . . . . . . . . . 48 6.1. JSON-RPC Binding . . . . . . . . . . . . . . . . . . . . 48
6.2. init Method . . . . . . . . . . . . . . . . . . . . . . . 49 6.2. init Method . . . . . . . . . . . . . . . . . . . . . . . 49
6.2.1. INIT_REQ Parameters . . . . . . . . . . . . . . . . . 49 6.2.1. INIT_REQ Parameters . . . . . . . . . . . . . . . . . 49
6.2.2. INIT_RESP Parameters . . . . . . . . . . . . . . . . 51 6.2.2. INIT_RESP Parameters . . . . . . . . . . . . . . . . 51
6.3. register Method . . . . . . . . . . . . . . . . . . . . . 52 6.3. register Method . . . . . . . . . . . . . . . . . . . . . 52
6.3.1. REGISTRATION_REQ Parameters . . . . . . . . . . . . . 52 6.3.1. REGISTRATION_REQ Parameters . . . . . . . . . . . . . 52
6.3.2. REGISTRATION_RESP Parameters . . . . . . . . . . . . 53 6.3.2. REGISTRATION_RESP Parameters . . . . . . . . . . . . 53
6.4. getSpectrum Method . . . . . . . . . . . . . . . . . . . 54 6.4. getSpectrum Method . . . . . . . . . . . . . . . . . . . 54
6.4.1. AVAIL_SPECTRUM_REQ Parameters . . . . . . . . . . . . 55 6.4.1. AVAIL_SPECTRUM_REQ Parameters . . . . . . . . . . . . 55
6.4.2. AVAIL_SPECTRUM_RESP Parameters . . . . . . . . . . . 57 6.4.2. AVAIL_SPECTRUM_RESP Parameters . . . . . . . . . . . 57
6.5. getSpectrumBatch Method . . . . . . . . . . . . . . . . . 60 6.5. getSpectrumBatch Method . . . . . . . . . . . . . . . . . 61
6.5.1. AVAIL_SPECTRUM_BATCH_REQ Parameters . . . . . . . . . 60 6.5.1. AVAIL_SPECTRUM_BATCH_REQ Parameters . . . . . . . . . 62
6.5.2. AVAIL_SPECTRUM_BATCH_RESP Parameters . . . . . . . . 62 6.5.2. AVAIL_SPECTRUM_BATCH_RESP Parameters . . . . . . . . 64
6.6. notifySpectrumUse Method . . . . . . . . . . . . . . . . 65 6.6. notifySpectrumUse Method . . . . . . . . . . . . . . . . 67
6.6.1. SPECTRUM_USE_NOTIFY Parameters . . . . . . . . . . . 66 6.6.1. SPECTRUM_USE_NOTIFY Parameters . . . . . . . . . . . 67
6.6.2. SPECTRUM_USE_RESP Parameters . . . . . . . . . . . . 67 6.6.2. SPECTRUM_USE_RESP Parameters . . . . . . . . . . . . 69
6.7. verifyDevice Method . . . . . . . . . . . . . . . . . . . 68 6.7. verifyDevice Method . . . . . . . . . . . . . . . . . . . 70
6.7.1. DEV_VALID_REQ Parameters . . . . . . . . . . . . . . 68 6.7.1. DEV_VALID_REQ Parameters . . . . . . . . . . . . . . 70
6.7.2. DEV_VALID_RESP Parameters . . . . . . . . . . . . . . 69 6.7.2. DEV_VALID_RESP Parameters . . . . . . . . . . . . . . 71
6.8. Sub-message Schemas . . . . . . . . . . . . . . . . . . . 71 6.8. Sub-message Schemas . . . . . . . . . . . . . . . . . . . 73
6.8.1. GeoLocation . . . . . . . . . . . . . . . . . . . . . 71 6.8.1. GeoLocation . . . . . . . . . . . . . . . . . . . . . 73
6.8.2. DeviceDescriptor . . . . . . . . . . . . . . . . . . 73 6.8.2. DeviceDescriptor . . . . . . . . . . . . . . . . . . 75
6.8.3. AntennaCharacteristics . . . . . . . . . . . . . . . 74 6.8.3. AntennaCharacteristics . . . . . . . . . . . . . . . 76
6.8.4. DeviceCapabilities . . . . . . . . . . . . . . . . . 75 6.8.4. DeviceCapabilities . . . . . . . . . . . . . . . . . 77
6.8.5. DeviceOwner . . . . . . . . . . . . . . . . . . . . . 76 6.8.5. DeviceOwner . . . . . . . . . . . . . . . . . . . . . 78
6.8.6. RulesetInfo . . . . . . . . . . . . . . . . . . . . . 77 6.8.6. RulesetInfo . . . . . . . . . . . . . . . . . . . . . 79
6.8.7. DbUpdateSpec . . . . . . . . . . . . . . . . . . . . 78 6.8.7. DbUpdateSpec . . . . . . . . . . . . . . . . . . . . 80
6.8.8. DatabaseSpec . . . . . . . . . . . . . . . . . . . . 79 6.8.8. DatabaseSpec . . . . . . . . . . . . . . . . . . . . 81
6.8.9. Spectrum . . . . . . . . . . . . . . . . . . . . . . 79 6.8.9. Spectrum . . . . . . . . . . . . . . . . . . . . . . 81
6.8.10. FrequencyRange . . . . . . . . . . . . . . . . . . . 81 6.8.10. FrequencyRange . . . . . . . . . . . . . . . . . . . 83
6.8.11. EventTime . . . . . . . . . . . . . . . . . . . . . . 81 6.8.11. EventTime . . . . . . . . . . . . . . . . . . . . . . 84
6.8.12. SpectrumSchedule . . . . . . . . . . . . . . . . . . 82 6.8.12. SpectrumSchedule . . . . . . . . . . . . . . . . . . 84
6.8.13. SpectrumSpec . . . . . . . . . . . . . . . . . . . . 83 6.8.13. SpectrumSpec . . . . . . . . . . . . . . . . . . . . 85
6.8.14. GeoSpectrumSpec . . . . . . . . . . . . . . . . . . . 84 6.8.14. GeoSpectrumSpec . . . . . . . . . . . . . . . . . . . 86
6.8.15. DeviceValidity . . . . . . . . . . . . . . . . . . . 85 6.8.15. DeviceValidity . . . . . . . . . . . . . . . . . . . 87
6.8.16. Additional Properties . . . . . . . . . . . . . . . . 85 6.8.16. Additional Properties . . . . . . . . . . . . . . . . 88
7. HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . . . 85 7. HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . . . 88
8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 87 8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 90
8.1. Defining New Message Parameters . . . . . . . . . . . . . 87 8.1. Defining New Message Parameters . . . . . . . . . . . . . 90
8.2. Defining Ruleset Identifiers . . . . . . . . . . . . . . 87 8.2. Defining Ruleset Identifiers . . . . . . . . . . . . . . 90
8.3. Defining Additional Error Codes . . . . . . . . . . . . . 88 8.3. Defining Additional Error Codes . . . . . . . . . . . . . 91
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 91
9.1. PAWS Parameters Registry . . . . . . . . . . . . . . . . 88 9.1. PAWS Parameters Registry . . . . . . . . . . . . . . . . 91
9.1.1. Registration Template . . . . . . . . . . . . . . . . 89 9.1.1. Registration Template . . . . . . . . . . . . . . . . 91
9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 89 9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 92
9.2. PAWS Ruleset ID Registry . . . . . . . . . . . . . . . . 90 9.2. PAWS Ruleset ID Registry . . . . . . . . . . . . . . . . 93
9.2.1. Registration Template . . . . . . . . . . . . . . . . 91 9.2.1. Registration Template . . . . . . . . . . . . . . . . 94
9.2.2. Initial Registry Contents . . . . . . . . . . . . . . 91 9.2.2. Initial Registry Contents . . . . . . . . . . . . . . 94
9.3. PAWS Error Code Registry . . . . . . . . . . . . . . . . 93 9.3. PAWS Error Code Registry . . . . . . . . . . . . . . . . 96
9.3.1. Registration Template . . . . . . . . . . . . . . . . 94 9.3.1. Registration Template . . . . . . . . . . . . . . . . 96
9.3.2. Initial Registry Contents . . . . . . . . . . . . . . 94 9.3.2. Initial Registry Contents . . . . . . . . . . . . . . 97
10. Security Considerations . . . . . . . . . . . . . . . . . . . 94 10. Security Considerations . . . . . . . . . . . . . . . . . . . 97
10.1. Assurance of Proper Database . . . . . . . . . . . . . . 95 10.1. Assurance of Proper Database . . . . . . . . . . . . . . 98
10.2. Protection Against Modification . . . . . . . . . . . . . 96 10.2. Protection Against Modification . . . . . . . . . . . . . 98
10.3. Protection Against Eavesdropping . . . . . . . . . . . . 96 10.3. Protection Against Eavesdropping . . . . . . . . . . . . 98
10.4. Client Authentication Considerations . . . . . . . . . . 96 10.4. Client Authentication Considerations . . . . . . . . . . 99
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 96 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 99
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 97 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 100
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 97 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 100
13.1. Normative References . . . . . . . . . . . . . . . . . . 97 13.1. Normative References . . . . . . . . . . . . . . . . . . 100
13.2. Informative References . . . . . . . . . . . . . . . . . 98 13.2. Informative References . . . . . . . . . . . . . . . . . 101
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 99 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 102
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 105
1. Introduction 1. Introduction
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 (PAWS) are strongly encouraged to read Protocol to Access White-Space (PAWS)
Databases: Use Cases and Requirements [RFC6953] for use cases, Databases: Use Cases and Requirements [RFC6953] for use cases,
requirements, and additional background. requirements, and additional background.
A geospatial database can track available spectrum (in accordance A geospatial database can track available spectrum (in accordance
with the rules of one or more regulatory domains) and make this with the rules of one or more regulatory domains) and make this
skipping to change at page 6, line 15 skipping to change at page 6, line 15
2.2. Terminology 2.2. Terminology
Database or Spectrum Database: A database is an entity that contains Database or Spectrum Database: A database is an entity that contains
current information about available spectrum at a given location current information about available spectrum at a given location
and time, as well as other types of information related to and time, as well as other types of information related to
spectrum availability and usage. spectrum availability and usage.
Device ID An identifier for a device. Device ID An identifier for a device.
EIRP: Effective isotropically radiated power EIRP: Effective isotropically radiated power
ETSI: European Telecommunications Standards Institute ETSI: European Telecommunications Standards Institute
FCC: Federal Communications Commission FCC: Federal Communications Commission
Listing server: A server that provides the URLs for one or more Listing server: A server that provides the URIs for one or more
Spectrum Databases. A regulator, for example, may operate a Spectrum Databases. A regulator, for example, may operate a
Database Listing Server to publish the list of authorized Spectrum Database Listing Server to publish the list of authorized Spectrum
Databases for its regulatory domain. Databases for its regulatory domain.
Master Device: A device that queries the database, on its own behalf Master Device: A device that queries the database, on its own behalf
and/or on behalf of a slave device, to obtain available spectrum and/or on behalf of a slave device, to obtain available spectrum
information. information.
Ruleset: A set of rules that governs operations of white space Ruleset: A set of rules that governs operations of white space
devices and Spectrum Databases within a regulatory domain. The devices and Spectrum Databases within a regulatory domain. The
same set of rules may be used by more than one regulatory domain. same set of rules may be used by more than one regulatory domain.
Slave Device: A device that queries the database through a master Slave Device: A device that queries the database through a master
skipping to change at page 9, line 35 skipping to change at page 9, line 35
Master Device retrieves its preconfigured list of databases from a Master Device retrieves its preconfigured list of databases from a
listing server, the device SHOULD check the listing server listing server, the device SHOULD check the listing server
periodically to update its list. periodically to update its list.
A Database MAY indicate that its URI will be changing by including A Database MAY indicate that its URI will be changing by including
the URI of one or more alternate databases (See DbUpdateSpec the URI of one or more alternate databases (See DbUpdateSpec
(Section 5.7)) in its responses to a Device. Before a Database (Section 5.7)) in its responses to a Device. Before a Database
ceases operation, for example, it MUST include DbUpdateSpec in its ceases operation, for example, it MUST include DbUpdateSpec in its
responses to notify Devices. A Device MUST update its preconfigured responses to notify Devices. A Device MUST update its preconfigured
list of databases to replace (only) its entry for the responding list of databases to replace (only) its entry for the responding
Database with the URLs of the alternate databases; the list of Database with the URIs of the alternate databases; the list of
alternate databases MUST NOT affect any other entries. alternate databases MUST NOT affect any other entries.
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 may indicate that the database does
skipping to change at page 10, line 13 skipping to change at page 10, line 13
Device may continue to operate during such period, but MUST cease use Device may continue to operate during such period, but MUST cease use
of the spectrum under rules for database-managed spectrum at or of the spectrum under rules for database-managed spectrum at or
before the expiration of the grace period. If a grace period is not before the expiration of the grace period. If a grace period is not
provided by the applicable regulatory domain, an operating Device provided by the applicable regulatory domain, an operating Device
that fails to contact a suitable database MUST immediately cease use that fails to contact a suitable database MUST immediately cease use
of the spectrum under rules for database-managed spectrum. of the spectrum under rules for database-managed spectrum.
4.1.1. Listing Server 4.1.1. Listing Server
Within a regulatory domain that has a Database Listing Server, a Within a regulatory domain that has a Database Listing Server, a
Device MUST use it to determine the URLs of databases for the domain. Device MUST use it to determine the URIs of databases for the domain.
The URI of the Listing Server for a regulatory domain MAY be The URI of the Listing Server for a regulatory domain MAY be
preconfigured in the device. Where allowed by the regulator, the preconfigured in the device. Where allowed by the regulator, the
Device MAY save the database list and SHOULD contact the Database Device MAY save the database list and SHOULD contact the Database
Listing Server periodically to update its list. The time between Listing Server periodically to update its list. The time between
such updates MUST be no longer than one week, or any update interval such updates MUST be no longer than one week, or any update interval
required by the applicable regulatory domain, whichever is shorter. required by the applicable regulatory domain, whichever is shorter.
If the Device is unable to contact the Database Listing Server to If the Device is unable to contact the Database Listing Server to
obtain the list of databases for the domain, the Device MUST NOT obtain the list of databases for the domain, the Device MUST NOT
operate under rules for database-managed spectrum. If an operating operate under rules for database-managed spectrum. If an operating
skipping to change at page 12, line 45 skipping to change at page 12, line 45
rulesetInfos: A list of RulesetInfo (Section 5.6) parameters MUST be rulesetInfos: A list of RulesetInfo (Section 5.6) parameters MUST be
included in the response. Each RulesetInfo parameter corresponds included in the response. Each RulesetInfo parameter corresponds
to a regulatory domain supported by the Database and is applicable to a regulatory domain supported by the Database and is applicable
to the location specified in the INIT_REQ (Section 4.2.1) message. to the location specified in the INIT_REQ (Section 4.2.1) message.
If the Device included a list of ruleset IDs in the If the Device included a list of ruleset IDs in the
DeviceDescriptor parameter of its INIT_REQ message, each DeviceDescriptor parameter of its INIT_REQ message, each
RulesetInfo parameter in the response MUST match one of the RulesetInfo parameter in the response MUST match one of the
specified ruleset IDs. specified ruleset IDs.
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) parameter to notify the Device of a change to the (Section 5.7) parameter to notify the Device of a change to the
Database URI, providing one or more alternate database URLs. The Database URI, providing one or more alternate database URIs. The
Device SHOULD use the information to update its list of Device SHOULD use the information to update its list of
preconfigured databases to replace (only) its entry for the preconfigured databases to replace (only) its entry for the
responding database with the list of alternate URLs. responding database with the list of alternate URIs.
other: Depending on the regulatory domain or database other: Depending on the regulatory domain or database
implementation, the Database MAY include additional handshake implementation, the Database MAY include additional handshake
parameters in the INIT_RESP (Section 4.2.2) message. The Master parameters in the INIT_RESP (Section 4.2.2) message. The Master
Device MUST ignore all parameters it does not understand. Device MUST ignore all parameters it does not understand.
4.3. Device Registration 4.3. Device Registration
When a regulatory domain requires registration of a Master Device, When a regulatory domain requires registration of a Master Device,
the Device MUST send its registration information to the Database to the Device MUST send its registration information to the Database to
skipping to change at page 15, line 22 skipping to change at page 15, line 22
+----------------------------+----------+ +----------------------------+----------+
Parameters: Parameters:
rulesetInfos: A list of RulesetInfo (Section 5.6) parameters MUST be rulesetInfos: A list of RulesetInfo (Section 5.6) parameters MUST be
included in the response, each of which corresponds to a included in the response, each of which corresponds to a
regulatory domain for which the registration was accepted. The regulatory domain for which the registration was accepted. The
list MUST contain at least one entry. list MUST contain at least one entry.
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) parameter to notify the Device of a change to the (Section 5.7) parameter to notify the Device of a change to the
Database URI, providing one or more alternate database URLs. The Database URI, providing one or more alternate database URIs. The
Device SHOULD use the information to update its list of Device SHOULD use the information to update its list of
preconfigured databases to replace (only) its entry for the preconfigured databases to replace (only) its entry for the
responding database with the list of alternate URLs. responding database with the list of alternate URIs.
other: Database implementations MAY return additional parameters in other: Database implementations MAY return additional parameters in
the registration response. Consult the PAWS Parameters Registry the registration response. Consult the PAWS Parameters Registry
(Section 9.1) for possible additional parameters and requirements (Section 9.1) for possible additional parameters and requirements
they place on the Device. they place on the Device.
4.4. Available Spectrum Query 4.4. Available Spectrum Query
To obtain the available spectrum from the Database, a Master Device To obtain the available spectrum from the Database, a Master Device
sends a request that contains its geo-location and any parameters sends a request that contains its geo-location and any parameters
required by the regulatory rules (such as device identifier, required by the regulatory rules (such as device identifier,
skipping to change at page 21, line 7 skipping to change at page 21, line 7
(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 is REQUIRED and spectrumSpecs: The SpectrumSpec (Section 5.9) list is REQUIRED and
MUST include at least one entry. Each entry contains the MUST include at least one entry. Each entry contains the
schedules of available spectrum for a regulatory domain. The schedules of available spectrum for a regulatory domain. The
Database MAY return more than one SpectrumSpec to represent Database MAY return more than one SpectrumSpec to represent
available spectrum for multiple regulatory domains at the available spectrum for multiple regulatory domains at the
specified location. specified location.
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) parameter to notify the Device of a change to the (Section 5.7) parameter to notify the Device of a change to the
Database URI, providing one or more alternate database URLs. The Database URI, providing one or more alternate database URIs. The
Device SHOULD use the information to update its list of Device SHOULD use the information to update its list of
preconfigured databases to replace (only) its entry for the preconfigured databases to replace (only) its entry for the
responding database with the list of alternate URLs. responding database with the list of alternate URIs.
other: Database implementations MAY return additional parameters in other: Database implementations MAY return additional parameters in
the response. Consult the PAWS Parameters Registry (Section 9.1) the response. Consult the PAWS Parameters Registry (Section 9.1)
for possible additional parameters and requirements they place on for possible additional parameters and requirements they place on
the Device. the Device.
4.4.2.1. Update Requirements 4.4.2.1. Update Requirements
When the stop time specified in the schedule has been reached, the When the stop time specified in the schedule has been reached, the
Device: Device:
o MUST obtain a new spectrum-availability schedule, either by using o MUST obtain a new spectrum-availability schedule, either by using
skipping to change at page 24, line 30 skipping to change at page 24, line 30
|spectrumSpecs:list | required | |spectrumSpecs:list | required |
+----------------------+----------+ +----------------------+----------+
Parameters: Parameters:
timestamp: Timestamp of the response of the form, YYYY-MM- timestamp: Timestamp of the response of the form, YYYY-MM-
DDThh:mm:ssZ, as defined by Date and Time on the Internet: DDThh:mm:ssZ, as defined by Date and Time on the Internet:
Timestamps [RFC3339]. This SHOULD be used by the Device as a Timestamps [RFC3339]. This SHOULD be used by the Device as a
reference for the start and stop times in the spectrum schedules. 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_BATCH_REQ message.
geoSpectrumSpecs: The geoSpectrumSpecs (Section 5.15) list is geoSpectrumSpecs: The geoSpectrumSpecs (Section 5.15) list is
REQUIRED (though it MAY be empty if spectrum is unavailable). For REQUIRED (though it MAY be empty if spectrum is unavailable). For
each location, the Database MAY return one or more SpectrumSpec each location, the Database MAY return one or more SpectrumSpec
(Section 5.9) parameters to represent available spectrum for one (Section 5.9) parameters to represent available spectrum for one
or more regulatory domains. The Database MAY return available or more regulatory domains. The Database MAY return available
spectrum for fewer locations than requested. The Device MUST NOT spectrum for fewer locations than requested. The Device MUST NOT
make any assumptions on the order of the entries in the list and make any assumptions on the order of the entries in the list and
MUST use the location value in each GeoSpectrumSpec entry to match MUST use the location value in each GeoSpectrumSpec entry to match
available spectrum to a location. available spectrum to a location.
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) parameter to notify the Device of a change to the (Section 5.7) parameter to notify the Device of a change to the
Database URI, providing one or more alternate database URLs. The Database URI, providing one or more alternate database URIs. The
Device SHOULD use the information to update its list of Device SHOULD use the information to update its list of
preconfigured databases to replace (only) its entry for the preconfigured databases to replace (only) its entry for the
responding database with the list of alternate URLs. responding database with the list of alternate URIs.
other: Database implementations MAY return additional parameters in other: Database implementations MAY return additional parameters in
the response. Consult the PAWS Parameters Registry (Section 9.1) the response. Consult the PAWS Parameters Registry (Section 9.1)
for possible additional parameters and requirements they place on for possible additional parameters and requirements they place on
the Device. the Device.
See Update Requirements (Section 4.4.2.1) for when the Device must See Update Requirements (Section 4.4.2.1) for when the Device must
update its available spectrum data. update its available spectrum data.
4.4.5. SPECTRUM_USE_NOTIFY 4.4.5. SPECTRUM_USE_NOTIFY
skipping to change at page 26, line 31 skipping to change at page 26, line 31
+----------------------------+----------+ +----------------------------+----------+
|databaseChange:DbUpdateSpec | optional | |databaseChange:DbUpdateSpec | optional |
|.......................................| |.......................................|
|*other:any | | |*other:any | |
+----------------------------+----------+ +----------------------------+----------+
Parameters: Parameters:
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) parameter to notify the Device of a change to the (Section 5.7) parameter to notify the Device of a change to the
Database URI, providing one or more alternate database URLs. The Database URI, providing one or more alternate database URIs. The
Device SHOULD use the information to update its list of Device SHOULD use the information to update its list of
preconfigured databases to replace (only) its entry for the preconfigured databases to replace (only) its entry for the
responding database with the list of alternate URLs. responding database with the list of alternate URIs.
other: Database implementations MAY return additional parameters in other: Database implementations MAY return additional parameters in
the response. Consult the PAWS Parameters Registry (Section 9.1) the response. Consult the PAWS Parameters Registry (Section 9.1)
for possible additional parameters and requirements they place on for possible additional parameters and requirements they place on
the Device. the Device.
4.5. Device Validation 4.5. Device Validation
Typically, a Slave Device needs a Master Device to ask the Database Typically, a Slave Device needs a Master Device to ask the Database
on its behalf for available spectrum. Depending on the regulatory on its behalf for available spectrum. Depending on the regulatory
domain, the Master Device also must validate with the Database that domain, the Master Device also must validate with the Database that
skipping to change at page 28, line 40 skipping to change at page 28, line 40
+----------------------------+----------+ +----------------------------+----------+
|deviceValidities:list | required |---- |deviceValidities:list | required |----
|databaseChange:DbUpdateSpac | optional | | |databaseChange:DbUpdateSpac | optional | |
+----------------------------+----------+ | +----------------------------+----------+ |
V 1..* V 1..*
+---------------------------------------+ +---------------------------------------+
|DeviceValidity | |DeviceValidity |
+----------------------------+----------+ +----------------------------+----------+
|deviceDesc:DeviceDescriptor | required | |deviceDesc:DeviceDescriptor | required |
|isValid:boolean | required | |isValid:boolean | required |
|reason:string | optional |
+----------------------------+----------+ +----------------------------+----------+
Parameters: Parameters:
deviceValidities: A DeviceValidities (Section 5.16) list is REQUIRED deviceValidities: A DeviceValidities (Section 5.16) list is REQUIRED
to report the list of Slave Devices and whether each listed Device to report the list of Slave Devices and whether each listed Device
is valid. The number of entries MUST match the number of is valid. The number of entries MUST match the number of
DeviceDescriptors (Section 5.2) listed in the DEV_VALID_REQ DeviceDescriptors (Section 5.2) listed in the DEV_VALID_REQ
message. message.
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) parameter to notify the Device of a change to the (Section 5.7) parameter to notify the Device of a change to the
Database URI, providing one or more alternate database URLs. The Database URI, providing one or more alternate database URIs. The
Device SHOULD use the information to update its list of Device SHOULD use the information to update its list of
preconfigured databases to replace (only) its entry for the preconfigured databases to replace (only) its entry for the
responding database with the list of alternate URLs. responding database with the list of alternate URIs.
5. Protocol Parameters 5. Protocol Parameters
This section presents more details of the parameters that make up the This section presents more details of the parameters that make up the
PAWS request and response messages. It also includes a sub-section PAWS request and response messages. It also includes a sub-section
defining response codes. defining response codes.
5.1. GeoLocation 5.1. GeoLocation
This parameter is used to specify the geo-location of the Device. It This parameter is used to specify the geo-location of the Device. It
skipping to change at page 35, line 39 skipping to change at page 35, line 39
database-managed spectrum. If this value is provided within the database-managed spectrum. If this value is provided within the
context of an Available Spectrum Response (Section 4.4.2), it context of an Available Spectrum Response (Section 4.4.2), it
takes precedence over the value within the Initialization takes precedence over the value within the Initialization
Response. Response.
other: This message is intended to be extensible with other other: This message is intended to be extensible with other
regulatory-specific parameters. Devices MUST ignore all regulatory-specific parameters. Devices MUST ignore all
parameters in the message it does not understand. parameters in the message it does not understand.
5.7. DbUpdateSpec 5.7. DbUpdateSpec
This message is provided by the Database to notify devices of an This element is provided by the Database to notify devices of an
upcoming change to the Database URL. upcoming change to the Database URI.
+-------------------------------+ +-------------------------------+
|DbUpdateSpec | |DbUpdateSpec |
+---------------------+---------+ +--------------------------+ +---------------------+---------+ +--------------------------+
|databases:list |required |------>|DatabaseSpec | |databases:list |required |------>|DatabaseSpec |
+---------------------+---------+ 1..* +---------------+----------+ +---------------------+---------+ 1..* +---------------+----------+
|name:string | required | |name:string | required |
|uri:string | required | |uri:string | required |
+---------------+----------+ +---------------+----------+
Parameters: Parameters:
databases: List of one or more DatabaseSpec (Section 5.8) entries. databases: List of one or more DatabaseSpec (Section 5.8) entries.
A Device SHOULD update its preconfigured list of databases to A Device SHOULD update its preconfigured list of databases to
replace (only) the database that provided the response with the replace (only) the database that provided the response with the
specified entries. specified entries.
5.8. DatabaseSpec 5.8. DatabaseSpec
This message contains the name and URI of a database. This element contains the name and URI of a database.
+--------------------------+ +--------------------------+
|DatabaseSpec | |DatabaseSpec |
+---------------+----------+ +---------------+----------+
|name:string | required | |name:string | required |
|uri:string | required | |uri:string | required |
+---------------+----------+ +---------------+----------+
Parameters: Parameters:
skipping to change at page 39, line 46 skipping to change at page 39, line 46
resolutionBwHz: This parameter is REQUIRED to define the resolution resolutionBwHz: This parameter is REQUIRED to define the resolution
bandwidth (in Hertz) over which permissible power spectral density bandwidth (in Hertz) over which permissible power spectral density
is defined. For example, FCC regulation would require one is defined. For example, FCC regulation would require one
spectrum specification at a bandwidth of 6MHz, and ETSI regulation spectrum specification at a bandwidth of 6MHz, and ETSI regulation
would require two specifications, at 0.1MHz and 8MHz. This would require two specifications, at 0.1MHz and 8MHz. This
parameter MAY be empty if there is no available spectrum. parameter MAY be empty if there is no available spectrum.
profiles: A SpectrumProfile (Section 5.12) list is REQUIRED to profiles: A SpectrumProfile (Section 5.12) list is REQUIRED to
specify permissible power levels over a set of frequency ranges. specify permissible power levels over a set of frequency ranges.
The list MAY be empty if there is no available spectrum. The list MAY be empty if there is no available spectrum.
Consider the following example with different permitted power Consider the following example with two different sets of permitted
spectral densities for the same set of frequencies over different power spectral densities for the same set of frequencies over
resolution bandwidths (for illustrative purposes only): different resolution bandwidths (for illustrative purposes only):
[ [
"spectrum": { {
"resolutionBwHz": 6e6, "resolutionBwHz": 6e6,
"profiles": [ "profiles": [
[ [
{"hz": 5.18e8, "dbm": 30.0}, {"hz": 5.18e8, "dbm": 30.0},
{"hz": 5.24e8, "dbm": 30.0}, {"hz": 5.24e8, "dbm": 30.0}
], ],
... ...
] ]
}, },
"spectrum": { {
"resolutionBwHz": 1e5, "resolutionBwHz": 1e5,
"profiles": [ "profiles": [
[ [
{"hz": 5.18e8, "dbm": 27.0}, {"hz": 5.18e8, "dbm": 27.0},
{"hz": 5.24e8, "dbm": 27.0}, {"hz": 5.24e8, "dbm": 27.0}
], ],
... ...
] ]
} }
] ]
This is interpreted as: This is interpreted as:
o Over any 6MHz within the frequency range, [518MHz, 524MHz), o Over any 6MHz within the frequency range, [518MHz, 524MHz),
maximum permitted power is 30.0dBm (1000mW), and maximum permitted power is 30.0dBm (1000mW), and
o Over any 100 kHz within the frequency range, [518MHz, 524MHz), o Over any 100 kHz within the frequency range, [518MHz, 524MHz),
maximum permitted power is 27.0dBm (500mW) maximum permitted power is 27.0dBm (500mW)
This would allow, for example, operating two 100kHz sub-channels This would allow, for example, operating two 100kHz sub-channels
within the indicated 6MHz range at 500mW each, totaling 1000mW. Of within the indicated 6MHz range at 500mW each, totaling 1000mW. Of
course, many combinations are possible, as long as they satisfy both course, many combinations are possible, as long as they satisfy both
conditions. conditions.
The following example illustrates multiple spectrum profiles that has The following example encodes multiple (two) spectrum profiles, each
a gap from 530 MHz to 536 MHz: having a gap from 530 MHz to 536 MHz (for illustrative purposes
only):
[ [
"spectrum": { {
"resolutionBwHz": 6e6, "resolutionBwHz": 6e6,
"profiles": [ "profiles": [
[ [
{"hz": 5.18e8, "dbm": 30.0}, {"hz": 5.18e8, "dbm": 30.0},
{"hz": 5.24e8, "dbm": 30.0}, {"hz": 5.24e8, "dbm": 30.0},
{"hz": 5.24e8, "dbm": 36.0}, {"hz": 5.24e8, "dbm": 36.0},
{"hz": 5.30e8, "dbm": 36.0}, {"hz": 5.30e8, "dbm": 36.0}
], ],
[ [
{"hz": 5.36e8, "dbm": 30.0}, {"hz": 5.36e8, "dbm": 30.0},
{"hz": 5.42e8, "dbm": 30.0}, {"hz": 5.42e8, "dbm": 30.0}
], ],
... ...
] ]
}, },
"spectrum": { {
"resolutionBwHz": 1e5, "resolutionBwHz": 1e5,
"profiles": [ "profiles": [
[ [
{"hz": 5.18e8, "dbm": 27.0}, {"hz": 5.18e8, "dbm": 27.0},
{"hz": 5.24e8, "dbm": 27.0}, {"hz": 5.24e8, "dbm": 27.0},
{"hz": 5.24e8, "dbm": 30.0}, {"hz": 5.24e8, "dbm": 30.0},
{"hz": 5.30e8, "dbm": 30.0}, {"hz": 5.30e8, "dbm": 30.0}
], ],
[ [
{"hz": 5.36e8, "dbm": 27.0}, {"hz": 5.36e8, "dbm": 27.0},
{"hz": 5.42e8, "dbm": 27.0}, {"hz": 5.42e8, "dbm": 27.0}
], ],
... ...
] ]
} }
] ]
5.12. SpectrumProfile 5.12. SpectrumProfile
A spectrum profile is characterized by an ordered list of (frequency, A spectrum profile is characterized by an ordered list of (frequency,
power) points that represents the shape of maximum permissible power power) points that represents the shape of maximum permissible power
skipping to change at page 45, line 41 skipping to change at page 45, line 41
-104 OUTSIDE_COVERAGE The specified geo-location is outside the -104 OUTSIDE_COVERAGE The specified geo-location is outside the
coverage area of the Database. The Database MAY coverage area of the Database. The Database MAY
include a list of alternate databases that include a list of alternate databases that
might be appropriate for the requested might be appropriate for the requested
location. See OUTSIDE_COVERAGE Error location. See OUTSIDE_COVERAGE Error
(Section 5.17.1). (Section 5.17.1).
-105 DATABASE_CHANGE The Database has changed its URI. The Database -105 DATABASE_CHANGE The Database has changed its URI. The Database
MAY include a DbUpdateSpec (Section 5.7) MAY include a DbUpdateSpec (Section 5.7)
parameter in the error response to provide parameter in the error response to provide
devices with one or more alternate database devices with one or more alternate database
URLs. The Device SHOULD use the information to URIs. The Device SHOULD use the information to
update its list of preconfigured databases to update its list of preconfigured databases to
replace (only) its entry for the responding replace (only) its entry for the responding
Database with the list of alternate database Database with the list of alternate database
URLs. See DATABASE_CHANGE Error URIs. See DATABASE_CHANGE Error
(Section 5.17.2). (Section 5.17.2).
-200 (reserved) -200 (reserved)
-201 REQUIRED A required parameter is missing. The Database -201 REQUIRED A required parameter is missing. The Database
MUST include a list of the required parameter MUST include a list of the required parameter
names. The Database MAY include only names of names. The Database MAY include only names of
parameters that are missing, but MAY include a parameters that are missing, but MAY include a
full list. Including the full list of missing full list. Including the full list of missing
parameters may reduce the number of re-queries parameters may reduce the number of re-queries
from the Device. See REQUIRED Error from the Device. See REQUIRED Error
(Section 5.17.3). (Section 5.17.3).
skipping to change at page 46, line 29 skipping to change at page 46, line 29
arrangement between the Device and Database. arrangement between the Device and Database.
-302 NOT_REGISTERED Device registration required, but the Device is -302 NOT_REGISTERED Device registration required, but the Device is
not registered. not registered.
Table 1: Error Codes Table 1: Error Codes
5.17.1. OUTSIDE_COVERAGE Error 5.17.1. OUTSIDE_COVERAGE Error
When the error code is OUTSIDE_COVERAGE, the Database MAY include an When the error code is OUTSIDE_COVERAGE, the Database MAY include an
ErrorData element within its Error response as the "data" field, and, ErrorData element within its Error response as the "data" field, and,
if present, the ErrorData MAY include a list of DatabaseSpec if present, the ErrorData MAY include a DbUpdateSpec (Section 5.7)
(Section 5.8) entries that might be appropriate for the requested element that provides a list of alternate databases that might be
location. appropriate for the requested location.
+---------------------------+ +---------------------------+
|Error | |Error |
+----------------+----------+ +----------------+----------+
|code:int | required | |code:int | required |
|message:string | optional | +-----------------------------+ |message:string | optional | +-----------------------------+
|data:ErrorData | optional |--->|ErrorData | |data:ErrorData | optional |--->|ErrorData |
+----------------+----------+ +------------------+----------+ +----------------+----------+ +------------------+----------+
|databases:list | optional | |spec:DbUpdateSpec | optional |
+------------------+----------+ +------------------+----------+
5.17.2. DATABASE_CHANGE Error 5.17.2. DATABASE_CHANGE Error
When the error code is DATABASE_CHANGE, the Database MAY include an When the error code is DATABASE_CHANGE, the Database MAY include an
ErrorData element within its Error response as the "data" field, and, ErrorData element within its Error response as the "data" field, and,
if present, the ErrorData MUST include a DbUpdateSpec (Section 5.7) if present, the ErrorData MUST include a DbUpdateSpec (Section 5.7)
element that provides a list of alternate databases. element that provides a list of alternate databases.
+---------------------------+ +---------------------------+
skipping to change at page 47, line 47 skipping to change at page 47, line 47
appropriate, e.g., "deviceDesc.serialNumber". appropriate, e.g., "deviceDesc.serialNumber".
6. Message Encoding 6. Message Encoding
The PAWS protocol is encoded using JSON-RPC [JSON-RPC] (see also The PAWS protocol is encoded using JSON-RPC [JSON-RPC] (see also
JavaScript Object Notation (JSON) [RFC4627]). Each component JavaScript Object Notation (JSON) [RFC4627]). Each component
described in Protocol Functionalities (Section 4) corresponds to one described in Protocol Functionalities (Section 4) corresponds to one
or more JSON-RPC methods. This section provides the JSON schema for or more JSON-RPC methods. This section provides the JSON schema for
each of the protocol messages and parameters defined in sections each of the protocol messages and parameters defined in sections
Protocol Functionalities (Section 4) and Protocol Parameters Protocol Functionalities (Section 4) and Protocol Parameters
(Section 5). JSON schemas are presented in accordance with A JSON (Section 5). JSON schemas are expressed using the format described
Media Type for Describing the Structure and Meaning of JSON Documents by JSON Schema [I-D.zyp-json-schema], but are not intended to be used
[I-D.zyp-json-schema]. for formal validation.
NOTE: In general, all messages defined in this section are extensible NOTE: In general, all messages defined in this section are extensible
by adding additional properties to support regulatory-specific and by adding additional properties to support regulatory-specific and
database-specific requirements. In all cases, the Device or Database database-specific requirements. In all cases, the Device or Database
MUST ignore any parameter it does not understand. MUST ignore any parameter it does not understand.
NOTE: The JSON examples in this section may contain ellipses (...) to
represent additional properties or elements that have been omitted in
order to make the examples more concise.
6.1. JSON-RPC Binding 6.1. JSON-RPC Binding
The JSON-RPC [JSON-RPC] protocol consists of two basic objects, The JSON-RPC [JSON-RPC] protocol consists of two basic objects,
Request and Response: Request and Response:
o The JSON-RPC Request object encapsulates a PAWS functionality o The JSON-RPC Request object encapsulates a PAWS functionality
(operation) and the request message (operation) and the request message
o The JSON-RPC Response object encapsulates a PAWS response message o The JSON-RPC Response object encapsulates a PAWS response message
and Error element and Error element
The Database and Device MUST support JSON-RPC 2.0 encoding. The Database and Device MUST support JSON-RPC 2.0 encoding.
The JSON-RPC Request for PAWS has the following the following forms: The JSON-RPC Request for PAWS has the following the following forms:
{ {
"jsonrpc": "2.0", "jsonrpc": "2.0",
"method": string, "method": "string",
"params": <PAWS_REQ>, "params": <PAWS_REQ>,
"id": string "id": "string"
} }
where "method" is the name of a PAWS functionality (operation), and where "method" is the name of a PAWS functionality (operation), and
<PAWS_REQ> represents one of the PAWS request objects associated with <PAWS_REQ> represents one of the PAWS request objects associated with
the method. Method names are defined with the prefix, the method. Method names are defined with the prefix,
"spectrum.paws.". "spectrum.paws.".
The non-error JSON-RPC Response for PAWS has the following forms: The non-error JSON-RPC Response for PAWS has the following forms:
{ {
"jsonrpc": "2.0", "jsonrpc": "2.0",
"result": <PAWS_RESP>, "result": <PAWS_RESP>,
"id": string "id": "string"
} }
where <PAWS_RESP> represents one of the PAWS response objects where <PAWS_RESP> represents one of the PAWS response objects
associated with the method. associated with the method.
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": integer, "code": "integer",
"message": string, "message": "string",
"data": object, "data": "object"
}, },
"id": string "id": "string"
} }
where the Error object and error codes are described by Error Element where the Error object and error codes are described by Error Element
(Section 5.17). The Database SHOULD attempt to use the most specific (Section 5.17). The Database SHOULD attempt to use the most specific
applicable PAWS error code. When an accurate one is not available, applicable PAWS error code. When an accurate one is not available,
it SHOULD fall back to standard JSONRPC error codes as defined in it SHOULD fall back to standard JSONRPC error codes as defined in
JSONRPC specification. For example, if the Database receives invalid JSONRPC specification. For example, if the Database receives invalid
JSON from the Device, it should respond with "-32700", signifying a JSON from the Device, it should respond with "-32700", signifying a
parse error. As a last resort, the Database MAY send a suitable HTTP parse error. As a last resort, the Database MAY send a suitable HTTP
5xx response. 5xx response.
skipping to change at page 54, line 37 skipping to change at page 54, line 37
} }
} }
} }
Example "register" JSON-RPC response: Example "register" JSON-RPC response:
{ {
"jsonrpc": "2.0", "jsonrpc": "2.0",
"result": { "result": {
"type": "REGISTRATION_RESP", "type": "REGISTRATION_RESP",
"version": "1.0" "version": "1.0",
"rulesetInfos": [ "rulesetInfos": [
{ {
"authority": "us", "authority": "us",
... ...
} }
] ]
}, },
"id": "xxxxxx" "id": "xxxxxx"
} }
skipping to change at page 58, line 44 skipping to change at page 58, line 44
}, },
"databaseChange": { "databaseChange": {
"type": "DbUpdateSpec", "type": "DbUpdateSpec",
"description": "Indicates that the Database URI will be "description": "Indicates that the Database URI will be
changing. Devices need to update their configurations", changing. Devices need to update their configurations",
"required": false "required": false
} }
} }
} }
Example "getSpectrum" JSON-RPC response: The following example "getSpectrum" JSON-RPC response contains:
o A schedule with two time ranges
o A spectrum profile for one resolution bandwidth (6 MHz)
The schemas for these (and other) nested objects may be found in the
Sub-message Schemas (Section 6.8) section.
{ {
"jsonrpc": "2.0", "jsonrpc": "2.0",
"result": { "result": {
"type": "AVAIL_SPECTRUM_RESP", "type": "AVAIL_SPECTRUM_RESP",
"version": "1.0", "version": "1.0",
"timestamp": "2013-03-02T14:30:21Z", "timestamp": "2013-03-02T14:30:21Z",
"deviceDesc": { "deviceDesc": {
"serialNumber": "XXX", "serialNumber": "XXX",
"fccId": "YYY", "fccId": "YYY",
skipping to change at page 59, line 19 skipping to change at page 59, line 25
{ {
"rulesetInfo": { "rulesetInfo": {
"authority": "us", "authority": "us",
... ...
}, },
"needsSpectrumReport": false, "needsSpectrumReport": false,
"spectrumSchedules": [ "spectrumSchedules": [
{ {
"eventTime": { "eventTime": {
"startTime": "2013-03-02T14:30:21Z", "startTime": "2013-03-02T14:30:21Z",
"stopTime": "2013-03-02T20:00:00Z", "stopTime": "2013-03-02T20:00:00Z"
}, },
"spectra": [ "spectra": [
{ {
"resolutionBwHz": 6e6, "resolutionBwHz": 6e6,
"profiles": [ "profiles": [
... ...
[ [
{"hz":5.18e8, "dbm":30.0}, {"hz":5.18e8, "dbm":30.0},
{"hz":5.36e8, "dbm":30.0}, {"hz":5.36e8, "dbm":30.0},
{"hz":5.36e8, "dbm":36.0}, {"hz":5.36e8, "dbm":36.0},
{"hz":5.42e8, "dbm":36.0} {"hz":5.42e8, "dbm":36.0}
], ],
[ [
{"hz":6.20e8, "dbm":30.0}, {"hz":6.20e8, "dbm":30.0},
{"hz":6.26e8, "dbm":30.0}, {"hz":6.26e8, "dbm":30.0}
],
...
]
}
]
},
{
"eventTime": {
"startTime": "2013-03-02T22:00:00Z",
"stopTime": "2013-03-03T14:30:21Z"
},
"spectra": [
...
]
}
]
}
]
},
"id": "xxxxxx"
}
The following example "getSpectrum" JSON-RPC response includes a
spectrum profile that contains specifications for two different
bandwidth resolutions (6 MHz and 100 kHz):
{
"jsonrpc": "2.0",
"result": {
"type": "AVAIL_SPECTRUM_RESP",
"version": "1.0",
"timestamp": "2013-03-02T14:30:21Z",
"deviceDesc": {
"serialNumber": "XXX",
...
},
"spectrumSpecs": [
{
"rulesetInfo": {
"authority": "xx",
...
},
"needsSpectrumReport": false,
"spectrumSchedules": [
{
"eventTime": {
"startTime": "2013-03-02T14:30:21Z",
"stopTime": "2013-03-02T20:00:00Z"
},
"spectra": [
{
"resolutionBwHz": 6e6,
"profiles": [
...
[
{"hz":5.18e8, "dbm":30.0},
{"hz":5.36e8, "dbm":30.0},
{"hz":5.36e8, "dbm":36.0},
{"hz":5.42e8, "dbm":36.0}
],
[
{"hz":6.20e8, "dbm":30.0},
{"hz":6.26e8, "dbm":30.0}
], ],
... ...
] ]
}, },
{ {
"resolutionBwHz": 1e5, "resolutionBwHz": 1e5,
"profiles": [ "profiles": [
... ...
[ [
{"hz":5.18e8, "dbm":27.0}, {"hz":5.18e8, "dbm":27.0},
{"hz":5.36e8, "dbm":27.0}, {"hz":5.36e8, "dbm":27.0},
{"hz":5.36e8, "dbm":30.0}, {"hz":5.36e8, "dbm":30.0},
{"hz":5.42e8, "dbm":30.0} {"hz":5.42e8, "dbm":30.0}
], ],
[ [
{"hz":6.20e8, "dbm":27.0}, {"hz":6.20e8, "dbm":27.0},
{"hz":6.26e8, "dbm":27.0}, {"hz":6.26e8, "dbm":27.0}
], ],
... ...
] ]
} }
] ]
}, },
{ {
"eventTime": { "eventTime": {
"startTime": "2013-03-02T22:00:00Z", "startTime": "2013-03-02T22:00:00Z",
"stopTime": "2013-03-03T14:30:21Z", "stopTime": "2013-03-03T14:30:21Z"
}, },
"spectra": [ "spectra": [
... ...
] ]
} }
], ]
} }
] ]
}, },
"id": "xxxxxx" "id": "xxxxxx"
} }
6.5. getSpectrumBatch Method 6.5. getSpectrumBatch Method
This section describes the encoding for the JSON-RPC This section describes the encoding for the JSON-RPC
"spectrum.paws.getSpectrumBatch" method that represents the multiple- "spectrum.paws.getSpectrumBatch" method that represents the multiple-
location query of the Available Spectrum Query functionality location query of the Available Spectrum Query functionality
(Section 4.4) that enables a Device to obtain a set of available (Section 4.4) that enables a Device to obtain a set of available
spectrum for multiple locations from the Database. spectrum for multiple locations from the Database.
6.5.1. AVAIL_SPECTRUM_BATCH_REQ Parameters 6.5.1. AVAIL_SPECTRUM_BATCH_REQ Parameters
The JSON encoding of the Batch Available Spectrum request The JSON encoding of the Batch Available Spectrum request
AVAIL_SPECTRUM_BATCH_REQ (Section 4.4.3) is described by the AVAIL_SPECTRUM_BATCH_REQ (Section 4.4.3) is described by the
following schema. This an OPTIONAL feature of the Database. following schema. This an OPTIONAL feature of the Database.
{ {
"name": "AVAIL_SPECTRUM_BATCH_REQ", "name": "AVAIL_SPECTRUM_BATCH_REQ",
"type": "object", "type": "object",
"properties": { "properties": {
"type": "AVAIL_SPECTRUM_BATCH_REQ", "type": "AVAIL_SPECTRUM_BATCH_REQ",
"version": { "version": {
"type": "string", "type": "string",
"required": true "required": true
},
"deviceDesc": {
"type": "DeviceDescriptor",
"description": "Descriptor of the device for which to
determine available spectrum.",
"required": true
}, },
"deviceDesc": { "locations": {
"type": "DeviceDescriptor", "type": "array",
"description": "Descriptor of the device for which to "description": "At least one device location is required.
determine available spectrum.", Additional (anticipated) locations can also be included,
"required": true as permitted by regulatory domain. When the request is
}, made by a Master Device on behalf of a Slave Device, these
"locations": { are locations of the Slave Device.",
"type": "array", "items": "GeoLocation",
"description": "At least one device location is required. "required": true
Additional (anticipated) locations can also be included, },
as permitted by regulatory domain. When the request is "owner": {
made by a Master Device on behalf of a Slave Device, these "type": "DeviceOwner",
are locations of the Slave Device.", "description": "May be required if the Device is not yet
"items": "GeoLocation", registered or if the DB does not implement a separate
"required": true device-registration request. Also depends on device type
}, and regulatory domain",
"owner": { "required": false
"type": "DeviceOwner", },
"description": "May be required if the Device is not yet "antenna": {
registered or if the DB does not implement a separate "type": "AntennaCharacteristics",
device-registration request. Also depends on device type "description": "Antenna characteristics, including its
and regulatory domain", height and height type. May required depending on
"required": false device type and regulatory domain",
}, "required": false
"antenna": {
"type": "AntennaCharacteristics", },
"description": "Antenna characteristics, including its "capabilities": {
height and height type. May required depending on "type": "DeviceCapabilities",
device type and regulatory domain","AntennaCharacteristics", "description": "The Database SHOULD NOT return spectrum that
"required": false is incompatible with the specified capabilities.",
}, "required": false
"capabilities": { },
"type": "DeviceCapabilities", "masterDeviceDesc": {
"description": "The Database SHOULD NOT return spectrum that "type": "DeviceDescriptor",
is incompatible with the specified capabilities.", "description": "When the request is made by a Master Device
"required": false on behalf of a Slave Device, this is the descriptor of
}, the Master Device.",
"masterDeviceDesc": { "required": false
"type": "DeviceDescriptor", },
"description": "When the request is made by a Master Device "masterDeviceLocation": {
on behalf of a Slave Device, this is the descriptor of "type": "GeoLocation",
the Master Device.", "description": "When the request is made by a Master Device
"required": false on behalf of a Slave Device, this is the location of
}, the Master Device.",
"masterDeviceLocation": { "required": false
"type": "GeoLocation", },
"description": "When the request is made by a Master Device "requestType": {
on behalf of a Slave Device, this is the location of "type": "string",
the Master Device.", "description": "Optional value that modifies the request.
"required": false Valid values depends on regulatory domain.",
}, "required": false
"requestType": { }
"type": "string", }
"description": "Optional value that modifies the request. }
Valid values depends on regulatory domain.",
"required": false
}
}
}
Example "getSpectrumBatch" JSON-RPC request: Example "getSpectrumBatch" JSON-RPC request:
{ {
"jsonrpc": "2.0", "jsonrpc": "2.0",
"method": "spectrum.paws.getSpectrumBatch", "method": "spectrum.paws.getSpectrumBatch",
"params": { "params": {
"type": "AVAIL_SPECTRUM_BATCH_REQ", "type": "AVAIL_SPECTRUM_BATCH_REQ",
"version": "1.0", "version": "1.0",
"deviceDesc": { "deviceDesc": {
skipping to change at page 63, line 45 skipping to change at page 65, line 45
}, },
"databaseChange": { "databaseChange": {
"type": "DbUpdateSpec", "type": "DbUpdateSpec",
"description": "Indicates that the Database URI will be "description": "Indicates that the Database URI will be
changing. Devices need to update their configurations", changing. Devices need to update their configurations",
"required": false "required": false
} }
} }
} }
Example "getSpectrumBatch" JSON-RPC response: The following example "getSpectrumBatch" JSON-RPC response
illustrates a batch response that contains spectrum specifications
for two locations:
{ {
"jsonrpc": "2.0", "jsonrpc": "2.0",
"result": { "result": {
"type": "AVAIL_SPECTRUM_BATCH_RESP", "type": "AVAIL_SPECTRUM_BATCH_RESP",
"version": "1.0", "version": "1.0",
"timestamp": "2013-03-02T14:30:21Z", "timestamp": "2013-03-02T14:30:21Z",
"deviceDesc": { "deviceDesc": {
"serialNumber": "XXX", "serialNumber": "XXX",
"fccId": "YYY", "fccId": "YYY",
skipping to change at page 64, line 27 skipping to change at page 66, line 29
{ {
"rulesetInfo": { "rulesetInfo": {
"authority": "us", "authority": "us",
... ...
}, },
"needsSpectrumReport": false, "needsSpectrumReport": false,
"spectrumSchedules": [ "spectrumSchedules": [
{ {
"eventTime": { "eventTime": {
"startTime": "2013-03-02T14:30:21Z", "startTime": "2013-03-02T14:30:21Z",
"stopTime": "2013-03-02T20:00:00Z", "stopTime": "2013-03-02T20:00:00Z"
}, },
"spectra": [ "spectra": [
{ {
"resolutionBwHz": 6e6, "resolutionBwHz": 6e6,
"profiles": [ "profiles": [
... ...
[ [
{"hz":5.18e8, "dbm":30.0}, {"hz":5.18e8, "dbm":30.0},
{"hz":5.36e8, "dbm":30.0}, {"hz":5.36e8, "dbm":30.0},
{"hz":5.36e8, "dbm":36.0}, {"hz":5.36e8, "dbm":36.0},
{"hz":5.42e8, "dbm":36.0} {"hz":5.42e8, "dbm":36.0}
], ],
[ [
{"hz":6.20e8, "dbm":30.0}, {"hz":6.20e8, "dbm":30.0},
{"hz":6.26e8, "dbm":30.0}, {"hz":6.26e8, "dbm":30.0}
],
...
]
},
{
"resolutionBwHz": 1e5,
"profiles": [
...
[
{"hz":5.18e8, "dbm":27.0},
{"hz":5.36e8, "dbm":27.0},
{"hz":5.36e8, "dbm":30.0},
{"hz":5.42e8, "dbm":30.0}
],
[
{"hz":6.20e8, "dbm":27.0},
{"hz":6.26e8, "dbm":27.0},
], ],
... ...
] ]
}, }
] ]
}, },
{ {
"eventTime": { "eventTime": {
"startTime": "2013-03-02T22:00:00Z", "startTime": "2013-03-02T22:00:00Z",
"stopTime": "2013-03-03T14:30:21Z", "stopTime": "2013-03-03T14:30:21Z"
}, },
"spectra": [ "spectra": [
... ...
] ]
} }
], ]
} }
] ]
}, },
{ {
"location": { "location": {
"point": { "point": {
"center": {"latitude": 37.0005, "longitude": -101.3005} "center": {"latitude": 37.0005, "longitude": -101.3005}
} }
}, },
"spectrumSpecs": [ "spectrumSpecs": [
... ...
] ]
} }
], ]
}, },
"id": "xxxxxx" "id": "xxxxxx"
} }
6.6. notifySpectrumUse Method 6.6. notifySpectrumUse Method
This section describes the encoding for the JSON-RPC This section describes the encoding for the JSON-RPC
"spectrum.paws.notifySpectrumUse" method that represents the "spectrum.paws.notifySpectrumUse" method that represents the
Spectrum-usage notification of the Available Spectrum Query Spectrum-usage notification of the Available Spectrum Query
functionality (Section 4.4.5) that notifies the Database of functionality (Section 4.4.5) that notifies the Database of
skipping to change at page 66, line 30 skipping to change at page 68, line 23
}, },
"deviceDesc": { "deviceDesc": {
"type": "DeviceDescriptor", "type": "DeviceDescriptor",
"required": true "required": true
}, },
"location": { "location": {
"type": "GeoLocation", "type": "GeoLocation",
"description": "The location of the Device. When the "description": "The location of the Device. When the
notification is made by a Master Device on behalf notification is made by a Master Device on behalf
of a Slave Device, this is the location of the of a Slave Device, this is the location of the
Slave Device." Slave Device.",
"required": false "required": false
}, },
"masterDeviceLocation": { "masterDeviceLocation": {
"type": "GeoLocation", "type": "GeoLocation",
"description": "When the notification is made by the "description": "When the notification is made by the
Master Device on behalf of a Slave Device, this is Master Device on behalf of a Slave Device, this is
the location of the Master Device." the location of the Master Device.",
"required": false "required": false
}, },
"spectra": { "spectra": {
"type": "array", "type": "array",
"description": "The spectrum anticipated to be used by "description": "The spectrum anticipated to be used by
the Device.", the Device.",
"items": "Spectrum", "items": "Spectrum",
"required": true "required": true
} }
} }
skipping to change at page 67, line 30 skipping to change at page 69, line 30
}, },
"spectra": [ "spectra": [
{ {
"resolutionBwHz": 6e6, "resolutionBwHz": 6e6,
"profiles": [ "profiles": [
[ [
{"hz":5.18e8, "dbm":30.0}, {"hz":5.18e8, "dbm":30.0},
{"hz":5.24e8, "dbm":30.0} {"hz":5.24e8, "dbm":30.0}
] ]
] ]
}, }
] ]
}, },
"id": "xxxxxx" "id": "xxxxxx"
} }
6.6.2. SPECTRUM_USE_RESP Parameters 6.6.2. SPECTRUM_USE_RESP Parameters
The JSON encoding of the Spectrum-usage response SPECTRUM_USE_RESP The JSON encoding of the Spectrum-usage response SPECTRUM_USE_RESP
(Section 4.4.6) is described by the following schema: (Section 4.4.6) is described by the following schema:
skipping to change at page 68, line 10 skipping to change at page 70, line 10
"required": true "required": true
} }
} }
} }
Example "notifySpectrumUse" JSON-RPC response: Example "notifySpectrumUse" JSON-RPC response:
{ {
"jsonrpc": "2.0", "jsonrpc": "2.0",
"result": { "result": {
"type": "SPECTRUM_USE_RESP", "type": "SPECTRUM_USE_RESP",
"version": "1.0", "version": "1.0"
}, },
"id": "xxxxxx" "id": "xxxxxx"
} }
6.7. verifyDevice Method 6.7. verifyDevice Method
This section describes the encoding for the JSON-RPC This section describes the encoding for the JSON-RPC
"spectrum.paws.verifyDevice" method that represents the Device "spectrum.paws.verifyDevice" method that represents the Device
Validation functionality (Section 4.5). This is used by a Master Validation functionality (Section 4.5). This is used by a Master
Device to validate Slave Devices. Device to validate Slave Devices.
skipping to change at page 75, line 18 skipping to change at page 77, line 18
"properties": { "properties": {
"height": { "height": {
"description": "Height of the antenna, in meters", "description": "Height of the antenna, in meters",
"type": "number", "type": "number",
"required": false "required": false
}, },
"heightType": { "heightType": {
"description": "Reference type for height: "description": "Reference type for height:
Above Ground Level (AGL), or Above Mean Sea Above Ground Level (AGL), or Above Mean Sea
Level (AMSL).", Level (AMSL).",
"type": "string", "enum": ["AGL","AMSL"],
"enum": "["AGL","AMSL"]",
"default": "AGL", "default": "AGL",
"required": false "required": false
}, },
"heightUncertainty": { "heightUncertainty": {
"description": "Uncertainty of the height measurement, "description": "Uncertainty of the height measurement,
in meters.", in meters.",
"type": "number", "type": "number",
"required": false "required": false
} }
} }
skipping to change at page 76, line 4 skipping to change at page 77, line 52
"description": "Device capabilities to help DB determine "description": "Device capabilities to help DB determine
available spectrum. The DB SHOULD NOT return available available spectrum. The DB SHOULD NOT return available
spectrum that falls outside the given frequency ranges.", spectrum that falls outside the given frequency ranges.",
"properties": { "properties": {
"frequencyRanges": { "frequencyRanges": {
"type": "array", "type": "array",
"items": "FrequencyRange", "items": "FrequencyRange",
"required": false "required": false
} }
} }
} }
6.8.5. DeviceOwner 6.8.5. DeviceOwner
The DeviceOwner (Section 5.5) parameter contains device-owner The DeviceOwner (Section 5.5) parameter contains device-owner
information required as part of device registration. Regulatory information required as part of device registration. Regulatory
domains MAY require additional parameters. JSON encoding of vCard is domains MAY require additional parameters. JSON encoding of vCard is
described in jCard: The JSON format for vCard described in jCard: The JSON format for vCard [RFC7095].
[I-D.ietf-jcardcal-jcard].
{ {
"name": "DeviceOwner", "name": "DeviceOwner",
"type": "object", "type": "object",
"description": "Device-owner information required as part of "description": "Device-owner information required as part of
Device registration. Regulatory domains MAY require Device registration. Regulatory domains MAY require
additional parameters.", additional parameters.",
"properties": { "properties": {
"owner": { "owner": {
"type": "vCard", "type": "vCard",
skipping to change at page 80, line 30 skipping to change at page 82, line 30
"required": true "required": true
} }
} }
} }
{ {
"name": "SpectrumProfile", "name": "SpectrumProfile",
"type": "array", "type": "array",
"description": "A list of (frequency, power) points. A minimum of "description": "A list of (frequency, power) points. A minimum of
two entries is required.", two entries is required.",
"item": "SpectrumProfilePoint", "item": "SpectrumProfilePoint"
} }
{ {
"name": "SpectrumProfilePoint", "name": "SpectrumProfilePoint",
"type": "object", "type": "object",
"description": "A point defined by a frequency and power level "description": "A point defined by a frequency and power level
at that frequency.", at that frequency.",
"properties": { "properties": {
"hz": { "hz": {
"type": "number", "type": "number",
skipping to change at page 81, line 5 skipping to change at page 83, line 5
}, },
"dbm": { "dbm": {
"type": "number", "type": "number",
"description": "Power (dBm) per resolution bandwidth as "description": "Power (dBm) per resolution bandwidth as
defined by enclosing resolutionBwHz.", defined by enclosing resolutionBwHz.",
"required": true "required": true
} }
} }
} }
Example: The following example Spectrum message for a resolution bandwidth of
6 MHz. This example contains power levels for only two frequency
segments:
o From 518 MHz to 542 MHz
o From 620 MHz to 626 MHz
In practice, this message would contain more (frequency, power)
points to cover all frequencies governed by the associated regulatory
domain. See the Spectrum (Section 5.11) section for a more detailed
discussion on the representation.
{ {
"resolutionBwHz": 6e6, "resolutionBwHz": 6e6,
"profiles": [ "profiles": [
[ [
{"hz":5.18e8, "dbm":30.0}, {"hz":5.18e8, "dbm":30.0},
{"hz":5.36e8, "dbm":30.0}, {"hz":5.36e8, "dbm":30.0},
{"hz":5.36e8, "dbm":36.0}, {"hz":5.36e8, "dbm":36.0},
{"hz":5.42e8, "dbm":36.0} {"hz":5.42e8, "dbm":36.0}
], ],
[ [
{"hz":6.20e8, "dbm":30.0}, {"hz":6.20e8, "dbm":30.0},
{"hz":6.26e8, "dbm":30.0}, {"hz":6.26e8, "dbm":30.0}
] ]
] ]
} }
6.8.10. FrequencyRange 6.8.10. FrequencyRange
The FrequencyRange (Section 5.13) element describes a frequency range The FrequencyRange (Section 5.13) element describes a frequency range
and permissible power level within the specified range. and permissible power level within the specified range.
{ {
skipping to change at page 83, line 7 skipping to change at page 85, line 30
power levels; one spectrum object per resolutionBwHz. The power levels; one spectrum object per resolutionBwHz. The
list MAY be empty when there is no available spectrum.", list MAY be empty when there is no available spectrum.",
"items": "Spectrum", "items": "Spectrum",
"required": true "required": true
} }
} }
} }
6.8.13. SpectrumSpec 6.8.13. SpectrumSpec
The JSON encoding of the Available Spectrum response message The JSON encoding of the SpectrumSpec (Section 5.9) element is
AVAIL_SPECTRUM_RESP (Section 4.4.2) is described by the following described by the following schema:
schema:
{ {
"name": "SpectrumSpec", "name": "SpectrumSpec",
"type": "object", "type": "object",
"description": "The SpectrumSpec element represents schedules of "description": "The SpectrumSpec element represents schedules of
available spectrum for a regulatory-domain ruleset.", available spectrum for a regulatory-domain ruleset.",
"properties": { "properties": {
"rulesetInfo": { "rulesetInfo": {
"type": "RulesetInfo", "type": "RulesetInfo",
"description": "Indicates the active regulatory domain and "description": "Indicates the active regulatory domain and
skipping to change at page 83, line 46 skipping to change at page 86, line 20
"description": "The time range for which the spectrumSchedules "description": "The time range for which the spectrumSchedules
is comprehensive", is comprehensive",
"required": false "required": false
}, },
"frequencyRanges": { "frequencyRanges": {
"type": "array", "type": "array",
"description": "The frequency ranges for which the "description": "The frequency ranges for which the
spectrumSchedules is comprehensive", spectrumSchedules is comprehensive",
"items": "FrequencyRange", "items": "FrequencyRange",
"required": false "required": false
} },
"needsSpectrumReport": { "needsSpectrumReport": {
"type": "boolean", "type": "boolean",
"description": "For regulatory domains that require a "description": "For regulatory domains that require a
spectrum-usage report from devices, the Database MUST spectrum-usage report from devices, the Database MUST
return true for this parameter.", return true for this parameter.",
"default": false, "default": false,
"required": false "required": false
}, },
"maxTotalBwHz": { "maxTotalBwHz": {
"type": "number", "type": "number",
skipping to change at page 85, line 38 skipping to change at page 88, line 33
"description": "If the device identifier is not valid, "description": "If the device identifier is not valid,
the Database MAY include a reason. The reason MAY be the Database MAY include a reason. The reason MAY be
in any language.", in any language.",
"required": false "required": false
} }
} }
} }
6.8.16. Additional Properties 6.8.16. Additional Properties
Note that A JSON Media Type for Describing the Structure and Meaning The Database or Device MAY include additional properties not
of JSON [I-D.zyp-json-schema] allows, as default behavior, the explicitly listed in the schema elaborated in this document. The
inclusion of additional properties by instances that are not Database and Device MUST ignore any such additional properties (and
explicitly defined in the JSON schema that the instance implements. their associated values) that they do not understand.
The schema elaborated in this document adopts this default behavior.
Hence, the instance MAY provide additional properties and associated
values (which may be "any" JSON type) not explicitly listed in this
schema. Further note that the Database and Device MUST ignore any
such additional properties and their associated values that it does
not understand.
7. HTTPS Binding 7. HTTPS Binding
This section describes the use of HTTP over TLS (HTTPS) HTTP Over TLS This section describes the use of HTTP over TLS (HTTPS) HTTP Over TLS
[RFC2818] as the transport mechanism for the PAWS protocol. TLS [RFC2818] as the transport mechanism for the PAWS protocol. TLS
provides message integrity and confidentiality between the Master provides message integrity and confidentiality between the Master
Device and the Database. The Master Device MUST implement server Device and the Database. The Master Device MUST implement server
authentication, as described in Section 3.1 of HTTP Over TLS authentication, as described in Section 3.1 of HTTP Over TLS
[RFC2818]. The Device uses the URI determined (either statically [RFC2818]. The Device uses the URI determined (either statically
configured or dynamically discovered) to authenticate the server. configured or dynamically discovered) to authenticate the server.
The Device SHOULD fail a request if server authentication fails. The Device SHOULD fail a request if server authentication fails.
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
skipping to change at page 86, line 27 skipping to change at page 89, line 15
To enable databases to handle large numbers of requests from large To enable databases to handle large numbers of requests from large
numbers of devices, the Database MAY support and Devices SHOULD numbers of devices, the Database MAY support and Devices SHOULD
support Stateless TLS Session Resumption [RFC5077]. support Stateless TLS Session Resumption [RFC5077].
A PAWS request message is carried in the body of an HTTP POST A PAWS request message is carried in the body of an HTTP POST
request. A PAWS response message is carried in the body of an HTTP request. A PAWS response message is carried in the body of an HTTP
response. A PAWS response SHOULD include a Content-Length header. response. A PAWS response SHOULD include a Content-Length header.
The POST method is the only method REQUIRED for PAWS. If a database The POST method is the only method REQUIRED for PAWS. If a database
chooses to support GET, it MUST be an escaped URL, but the encoding chooses to support GET, it MUST be an escaped URI, but the encoding
of the URL is outside the scope of this document. The database MAY of the URI is outside the scope of this document. The database MAY
refuse to support the GET request by returning an HTTP error code, refuse to support the GET request by returning an HTTP error code,
such as 404 (not found). such as 404 (not found).
The Database MAY redirect a PAWS request by returning a HTTP 3xx The Database MAY redirect a PAWS request by returning a HTTP 3xx
response (as defined by HTTP/1.1 [RFC2616]). The Database MUST response (as defined by HTTP/1.1 [RFC2616]). The Database MUST
provide the redirect URI in the Location header of the 3xx response, provide the redirect URI in the Location header of the 3xx response,
and the Device MUST handle redirects by using the Location header and the Device MUST handle redirects by using the Location header
provided by the Database. When redirecting, the Device MUST observe provided by the Database. When redirecting, the Device MUST observe
the delay indicated by the Retry-After header. The Device MUST the delay indicated by the Retry-After header. The Device MUST
authenticate the Database that returns the redirect response before authenticate the Database that returns the redirect response before
following the redirect. Also, the Device MUST authenticate the following the redirect. Also, the Device MUST authenticate the
Database indicated in the redirect. Since the Device may communicate Database indicated in the redirect. Since the Device may communicate
with a Database (which it authenticated) without user interaction, with a Database (which it authenticated) without user interaction,
when the response code is 301 (Moved Permanently), the Device MAY when the response code is 301 (Moved Permanently), the Device MAY
redirect without asking a user for confirmation (note that this redirect without asking a user for confirmation (note that this
represents an exception to the HTTP/1.1 [RFC2616] requirements for represents an exception to the HTTP/1.1 [RFC2616] requirements for
HTTP POST methods). HTTP POST methods).
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 URL. The Device MAY revert to the original URL for the alternate URI. The Device MAY revert to the original URI for the
very next request, or MAY continue to use the alternate URL 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, it SHOULD NOT modify its stored list of URLs. However, it SHOULD NOT modify its stored list of URIs.
The Database SHOULD use HTTP status code "301 Moved Permanently" to The Database SHOULD use HTTP status code "301 Moved Permanently" to
indicate that the Device SHOULD resubmit this request, and all future indicate that the Device SHOULD resubmit this request, and all future
requests, to an alternate URL. If the Device maintains a list of requests, to an alternate URI. If the Device maintains a list of
available URLs, it SHOULD replace only the current URL with the available URIs, it SHOULD replace only the current URI with the
alternate URL. alternate URI.
8. Extensibility 8. Extensibility
8.1. Defining New Message Parameters 8.1. Defining New Message Parameters
New request or response parameters for use with the PAWS protocol are New request or response parameters for use with the PAWS protocol are
defined and registered in the parameters registry following the defined and registered in the parameters registry following the
procedure in Section 9.1. procedure in Section 9.1.
Parameter names MUST conform to the param-name ABNF and parameter Parameter names MUST conform to the param-name ABNF and parameter
skipping to change at page 88, line 40 skipping to change at page 91, line 29
9. IANA Considerations 9. IANA Considerations
9.1. PAWS Parameters Registry 9.1. PAWS Parameters Registry
This specification establishes the PAWS Parameters Registry. This specification establishes the PAWS Parameters Registry.
Additional parameters for inclusion in the PAWS protocol requests, Additional parameters for inclusion in the PAWS protocol requests,
responses, or sub-messages are registered through the Specification responses, or sub-messages are registered through the Specification
Required [RFC5226] process, after a two-week review period on the Required [RFC5226] process, after a two-week review period on the
[paws-iana-TBD]@ietf.org mailing list, on the advice of one or more paws-iana-review@ietf.org mailing list, on the advice of one or more
Designated Experts. To allow for the allocation of values prior to Designated Experts. To allow for the allocation of values prior to
publication, the Designated Expert(s) may approve registration once publication, the Designated Expert(s) may approve registration once
they are satisfied that such a specification will be published. they are satisfied that such a specification will be published.
Registration requests must be sent to the [paws-iana-TBD]@ietf.org Registration requests must be sent to the paws-iana-review@ietf.org
mailing list for review and comment, with an appropriate subject mailing list for review and comment, with an appropriate subject
(e.g., "Request for parameter: example"). [[ Editor's Note: The name (e.g., "Request for parameter: example").
of the mailing list should be determined in consultation with the
IESG and IANA. Suggested name: paws-ext-review. ]]
Within the review period, the Designated Expert(s) will either Within the review period, the Designated Expert(s) will either
approve or deny the registration request, communicating this decision approve or deny the registration request, communicating this decision
to the review list and IANA. Denials should include an explanation to the review list and IANA. Denials should include an explanation
and, if applicable, suggestions as to how to make the request and, if applicable, suggestions as to how to make the request
successful. successful.
IANA must only accept registry updates from the Designated Expert(s), IANA must only accept registry updates from the Designated Expert(s),
and should direct all requests for registration to the review mailing and should direct all requests for registration to the review mailing
list. list.
skipping to change at page 91, line 7 skipping to change at page 93, line 40
category, as defined by the ETSI Harmonised Standard category, as defined by the ETSI Harmonised Standard
[ETSI-EN-301-598]. Valid values are the strings, "master" and [ETSI-EN-301-598]. Valid values are the strings, "master" and
"slave". It is case insensitive. "slave". It is case insensitive.
9.2. PAWS Ruleset ID Registry 9.2. PAWS Ruleset ID Registry
This specification establishes the PAWS Ruleset ID Registry. This specification establishes the PAWS Ruleset ID Registry.
Ruleset type names for inclusion in the PAWS protocol messages are Ruleset type names for inclusion in the PAWS protocol messages are
registered through the Specification Required [RFC5226] process, registered through the Specification Required [RFC5226] process,
after a two-week review period on the [paws-iana-TBD]@ietf.org after a two-week review period on the paws-iana-review@ietf.org
mailing list, on the advice of one or more Designated Experts. To mailing list, on the advice of one or more Designated Experts. To
allow for the allocation of values prior to publication, the allow for the allocation of values prior to publication, the
Designated Expert(s) may approve registration once they are satisfied Designated Expert(s) may approve registration once they are satisfied
that such a specification will be published. that such a specification will be published.
Registration requests must be sent to the [paws-iana-TBD]@ietf.org Registration requests must be sent to the paws-iana-review@ietf.org
mailing list for review and comment, with an appropriate subject mailing list for review and comment, with an appropriate subject
(e.g., "Request for parameter: example"). [[ Editor's Note: The name (e.g., "Request for parameter: example").
of the mailing list should be determined in consultation with the
IESG and IANA. Suggested name: paws-ext-review. ]]
Within the review period, the Designated Expert(s) will either Within the review period, the Designated Expert(s) will either
approve or deny the registration request, communicating this decision approve or deny the registration request, communicating this decision
to the review list and IANA. Denials should include an explanation to the review list and IANA. Denials should include an explanation
and, if applicable, suggestions as to how to make the request and, if applicable, suggestions as to how to make the request
successful. successful.
IANA must only accept registry updates from the Designated Expert(s), IANA must only accept registry updates from the Designated Expert(s),
and should direct all requests for registration to the review mailing and should direct all requests for registration to the review mailing
list. list.
skipping to change at page 92, line 18 skipping to change at page 95, line 4
PAWS Parameters Registry Initial Contents (Section 9.1.2) for more PAWS Parameters Registry Initial Contents (Section 9.1.2) for more
information. information.
Ruleset name: FccTvBandWhiteSpace-2010 Ruleset name: FccTvBandWhiteSpace-2010
Additional message parameters: Additional message parameters:
deviceDesc: The DeviceDescriptor (Section 5.2) parameter is deviceDesc: The DeviceDescriptor (Section 5.2) parameter is
REQUIRED for Available Spectrum Request (Section 4.4.1) and REQUIRED for Available Spectrum Request (Section 4.4.1) and
Available Spectrum Batch Request (Section 4.4.3). Available Spectrum Batch Request (Section 4.4.3).
fccId: Specifies a device's FCC certification ID. It is a fccId: Specifies a device's FCC certification ID. It is a
required parameter in DeviceDescriptor (Section 5.2). required parameter in DeviceDescriptor (Section 5.2).
fccTvbdDeviceType: Specifies the type of TV-band White Space fccTvbdDeviceType: Specifies the type of TV-band White Space
device, as defined by the FCC rules. It is a required device, as defined by the FCC rules. It is a required
parameter in DeviceDescriptor (Section 5.2). parameter in DeviceDescriptor (Section 5.2).
Specification document(s): [[ this document ]] This ruleset refers Specification document(s): This ruleset refers to the FCC rules for
to the FCC rules for TV-band White Space operations established in TV-band White Space operations established in the Code of Federal
the Code of Federal Regulations (CFR), Title 47, Part 15, Subpart Regulations (CFR), Title 47, Part 15, Subpart H [FCC-CFR47-15H].
H [FCC-CFR47-15H].
Additional DeviceOwner (Section 5.5) requirements: Additional DeviceOwner (Section 5.5) requirements:
owner: The owner vCard [RFC6350] entry MUST include the formatted owner: The owner vCard [RFC6350] entry MUST include the formatted
name of an individual or organization using the "fn" property. name of an individual or organization using the "fn" property.
When the name is that of an organization, the entry also MUST When the name is that of an organization, the entry also MUST
include the "kind" property, with a value of "org". include the "kind" property, with a value of "org".
operator: The operator vCard [RFC6350] entry MUST include the operator: The operator vCard [RFC6350] entry MUST include the
following properties: following properties:
fn: Formatted name of a contact person responsible for the fn: Formatted name of a contact person responsible for the
skipping to change at page 93, line 46 skipping to change at page 96, line 28
(Section 4.4.2) and AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4). (Section 4.4.2) and AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4).
Specification document(s): This ruleset refers to the ETSI Specification document(s): This ruleset refers to the ETSI
Harmonised Standard [ETSI-EN-301-598] established by ETSI. Harmonised Standard [ETSI-EN-301-598] established by ETSI.
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 the PAWS protocol error Additional error codes for inclusion in the PAWS protocol error
message are registered through the Specification Required [RFC5226] message are registered through the Specification Required [RFC5226]
process, after a two-week review period on the [paws-iana-TBD]@ process, after a two-week review period on the
ietf.org mailing list, on the advice of one or more Designated paws-iana-review@ietf.org mailing list, on the advice of one or more
Experts. To allow for the allocation of values prior to publication, Designated Experts. To allow for the allocation of values prior to
the Designated Expert(s) may approve registration once they are publication, the Designated Expert(s) may approve registration once
satisfied that such a specification will be published. they are satisfied that such a specification will be published.
Registration requests must be sent to the [paws-iana-TBD]@ietf.org Registration requests must be sent to the paws-iana-review@ietf.org
mailing list for review and comment, with an appropriate subject mailing list for review and comment, with an appropriate subject
(e.g., "Request for parameter: example"). [[ Editor's Note: The name (e.g., "Request for parameter: example").
of the mailing list should be determined in consultation with the
IESG and IANA. Suggested name: paws-ext-review. ]]
Within the review period, the Designated Expert(s) will either Within the review period, the Designated Expert(s) will either
approve or deny the registration request, communicating this decision approve or deny the registration request, communicating this decision
to the review list and IANA. Denials should include an explanation to the review list and IANA. Denials should include an explanation
and, if applicable, suggestions as to how to make the request and, if applicable, suggestions as to how to make the request
successful. successful.
IANA must only accept registry updates from the Designated Expert(s), IANA must only accept registry updates from the Designated Expert(s),
and should direct all requests for registration to the review mailing and should direct all requests for registration to the review mailing
list. list.
skipping to change at page 97, line 31 skipping to change at page 100, line 19
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
[FCC-CFR47-15H]
U. S. Government, "Electronic Code of Federal Regulations,
Title 47, Part 15, Subpart H: Television Band Devices",
December 2010, <http://www.ecfr.gov/cgi-bin/
text-idx?rgn=div6&view=text&node=47:1.0.1.1.16.8>.
[I-D.ietf-jcardcal-jcard]
Kewisch, P., "jCard: The JSON format for vCard",
draft-ietf-jcardcal-jcard-07 (work in progress),
October 2013.
[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,
<http://www.itu.int/rec/T-REC-X.520-200811-I>. <http://www.itu.int/rec/T-REC-X.520-200811-I>.
[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.
skipping to change at page 98, line 34 skipping to change at page 101, line 8
(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.
[WGS-84] National Imagery and Mapping Agency, "Department of [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
Defense World Geodetic System 1984, Its Definition and January 2014.
Relationships with Local Geodetic Systems, NIMA TR8350.2
Third Edition Amendment 1", January 2000, <http://
earth-info.nga.mil/GandG/publications/tr8350.2/
tr8350_2.html>.
13.2. Informative References 13.2. Informative References
[ETSI-EN-301-598] [ETSI-EN-301-598]
European Telecommunication Standards Institute (ETSI), European Telecommunication Standards Institute (ETSI),
"Draft ETSI EN 301 598 (V1.0.0): White Space Devices "Draft ETSI EN 301 598 (V1.0.0): White Space Devices
(WSD); Wireless Access Systems operating in the 470 MHz to (WSD); Wireless Access Systems operating in the 470 MHz to
790 MHz frequency band; Harmonized EN covering the 790 MHz frequency band; Harmonized EN covering the
essential requirements of article 3.2 of the R&TTE essential requirements of article 3.2 of the R&TTE
Directive", July 2013, <http://www.etsi.org/deliver/ Directive", July 2013, <http://www.etsi.org/deliver/
etsi_en/301500_301599/301598/01.00.00_20/ etsi_en/301500_301599/301598/01.00.00_20/
en_301598v010000a.pdf>. en_301598v010000a.pdf>.
[FCC-CFR47-15H]
U. S. Government, "Electronic Code of Federal Regulations,
Title 47, Part 15, Subpart H: Television Band Devices",
December 2010, <http://www.ecfr.gov/cgi-bin/
text-idx?rgn=div6&view=text&node=47:1.0.1.1.16.8>.
[FCC-Review-2012-10] [FCC-Review-2012-10]
Federal Communications Commission, "Administration Topics Federal Communications Commission, "Administration Topics
Review", October 2012, <http://transition.fcc.gov/bureaus/ Review", October 2012, <http://transition.fcc.gov/bureaus/
oet/ea/presentations/files/oct12/ oet/ea/presentations/files/oct12/
2b-TCB-Admin-Issues-Oct-2012-GT.pdf>. 2b-TCB-Admin-Issues-Oct-2012-GT.pdf>.
[I-D.das-paws-protocol] [I-D.das-paws-protocol]
Das, S., Malyar, J., and D. Joslyn, "Device to Database Das, S., Malyar, J., and D. Joslyn, "Device to Database
Protocol for White Space", draft-das-paws-protocol-02 Protocol for White Space", draft-das-paws-protocol-02
(work in progress), July 2012. (work in progress), July 2012.
skipping to change at page 99, line 42 skipping to change at page 102, line 18
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006. JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC6953] Mancuso, A., Probasco, S., and B. Patil, "Protocol to [RFC6953] Mancuso, A., Probasco, S., and B. Patil, "Protocol to
Access White-Space (PAWS) Databases: Use Cases and Access White-Space (PAWS) Databases: Use Cases and
Requirements", RFC 6953, May 2013. Requirements", RFC 6953, May 2013.
[WGS-84] National Imagery and Mapping Agency, "Department of
Defense World Geodetic System 1984, Its Definition and
Relationships with Local Geodetic Systems, NIMA TR8350.2
Third Edition Amendment 1", January 2000, <http://
earth-info.nga.mil/GandG/publications/tr8350.2/
tr8350_2.html>.
Appendix A. Changes / Author Notes. Appendix A. Changes / Author Notes.
Changes from 08:
o Fix JSON typos.
o Added note that JSON schema is not intended to be formally
validated
o Finalize paws-iana-review@ietf.org as the email for updating the
PAWS IANA registries
o URLs to URIs
o Typo fixes
Changes from 07: Changes from 07:
o Propose ruleset ID name for ETSI: ETSI-EN-301-598-1.0.0-draft o Propose ruleset ID name for ETSI: ETSI-EN-301-598-1.0.0-draft
o Change TBD email address to paws-iana-TBD@ietf.org for proposing o Change TBD email address to paws-iana-review@ietf.org for
changes to the PAWS IANA registries proposing changes to the PAWS IANA registries
o Moved discussion of required vCard properties to regulatory- o Moved discussion of required vCard properties to regulatory-
specific sections specific sections
o Fixed vCard examples for organization names: Use "fn" property, o Fixed vCard examples for organization names: Use "fn" property,
but set "kind" to "org". but set "kind" to "org".
o Shorten parameter names: o Shorten parameter names:
* freqHz -> hz * freqHz -> hz
* powerDbmPerBw -> dbm * powerDbmPerBw -> dbm
Changes from 06: Changes from 06:
o Multi-ruleset support: o Multi-ruleset support:
* Changed RulesetInfo to have single ruleset ID * Changed RulesetInfo to have single ruleset ID
* Changed INIT_RESP to return a list of RulesetInfo parameters, * Changed INIT_RESP to return a list of RulesetInfo parameters,
rather than a single one rather than a single one
* Changed REGISTRATION_RESP to return a list of RulesetInfo * Changed REGISTRATION_RESP to return a list of RulesetInfo
parameters to indicate the regulatory domains for which parameters to indicate the regulatory domains for which
registration was accepted registration was accepted
* Added SpectrumSpec (Section 5.9) parameter to represent * Added SpectrumSpec (Section 5.9) parameter to represent
available-spectrum specification for one regulatory domain, available-spectrum specification for one regulatory domain,
allowing AVAIL_SPECTRUM_RESP and AVAIL_SPECTRUM_BATCH_RESP to allowing AVAIL_SPECTRUM_RESP and AVAIL_SPECTRUM_BATCH_RESP to
 End of changes. 100 change blocks. 
284 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/