draft-ietf-paws-protocol-06.txt   draft-ietf-paws-protocol-07.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: December 21, 2013 Applied Communication Sciences Expires: June 5, 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
June 19, 2013 December 2, 2013
Protocol to Access Spectrum Database Protocol to Access White-Space (PAWS) Databases
draft-ietf-paws-protocol-06 draft-ietf-paws-protocol-07
Abstract Abstract
Portions of the radio spectrum that are allocated to licensees are Portions of the radio spectrum that are allocated to licensees are
available for non-interfering use. This available spectrum is called available for non-interfering use. This available spectrum is called
"White Space." Allowing secondary users access to available spectrum "White Space." Allowing secondary users access to available spectrum
"unlocks" existing spectrum to maximize its utilization and to "unlocks" existing spectrum to maximize its utilization and to
provide opportunities for innovation, resulting in greater overall provide opportunities for innovation, resulting in greater overall
spectrum utilization. spectrum utilization.
One approach to manage spectrum sharing uses databases to report One approach to manage spectrum sharing uses databases to report
spectrum availability to devices. To achieve interoperability among spectrum availability to devices. To achieve interoperability among
multiple devices and databases, a standardized protocol must be multiple devices and databases, a standardized protocol must be
defined and implemented. This document defines such a protocol, the defined and implemented. This document defines such a protocol, the
"Protocol to Access White Space database" (PAWS). "Protocol to Access White Space (PAWS) Databases".
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 21, 2013. This Internet-Draft will expire on June 5, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 5
2.1. Conventions Used in This Document . . . . . . . . . . . . 5 2.1. Conventions Used in This Document . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Multi-ruleset Support . . . . . . . . . . . . . . . . . . 7 3.1. Multi-ruleset Support . . . . . . . . . . . . . . . . . . 7
4. Protocol Functionalities . . . . . . . . . . . . . . . . . . . 8 4. Protocol Functionalities . . . . . . . . . . . . . . . . . . 8
4.1. Database Discovery . . . . . . . . . . . . . . . . . . . . 8 4.1. Database Discovery . . . . . . . . . . . . . . . . . . . 8
4.1.1. Listing Server . . . . . . . . . . . . . . . . . . . . 10 4.1.1. Listing Server . . . . . . . . . . . . . . . . . . . 10
4.2. Initialization . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Initialization . . . . . . . . . . . . . . . . . . . . . 11
4.2.1. INIT_REQ . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.1. INIT_REQ . . . . . . . . . . . . . . . . . . . . . . 11
4.2.2. INIT_RESP . . . . . . . . . . . . . . . . . . . . . . 12 4.2.2. INIT_RESP . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Device Registration . . . . . . . . . . . . . . . . . . . 12 4.3. Device Registration . . . . . . . . . . . . . . . . . . . 13
4.3.1. REGISTRATION_REQ . . . . . . . . . . . . . . . . . . . 13 4.3.1. REGISTRATION_REQ . . . . . . . . . . . . . . . . . . 13
4.3.2. REGISTRATION_RESP . . . . . . . . . . . . . . . . . . 14 4.3.2. REGISTRATION_RESP . . . . . . . . . . . . . . . . . . 14
4.4. Available Spectrum Query . . . . . . . . . . . . . . . . . 14 4.4. Available Spectrum Query . . . . . . . . . . . . . . . . 15
4.4.1. AVAIL_SPECTRUM_REQ . . . . . . . . . . . . . . . . . . 17 4.4.1. AVAIL_SPECTRUM_REQ . . . . . . . . . . . . . . . . . 18
4.4.2. AVAIL_SPECTRUM_RESP . . . . . . . . . . . . . . . . . 19 4.4.2. AVAIL_SPECTRUM_RESP . . . . . . . . . . . . . . . . . 19
4.4.3. AVAIL_SPECTRUM_BATCH_REQ . . . . . . . . . . . . . . . 21 4.4.3. AVAIL_SPECTRUM_BATCH_REQ . . . . . . . . . . . . . . 21
4.4.4. AVAIL_SPECTRUM_BATCH_RESP . . . . . . . . . . . . . . 23 4.4.4. AVAIL_SPECTRUM_BATCH_RESP . . . . . . . . . . . . . . 23
4.4.5. SPECTRUM_USE_NOTIFY . . . . . . . . . . . . . . . . . 25 4.4.5. SPECTRUM_USE_NOTIFY . . . . . . . . . . . . . . . . . 25
4.4.6. SPECTRUM_USE_RESP . . . . . . . . . . . . . . . . . . 26 4.4.6. SPECTRUM_USE_RESP . . . . . . . . . . . . . . . . . . 26
4.5. Device Validation . . . . . . . . . . . . . . . . . . . . 26 4.5. Device Validation . . . . . . . . . . . . . . . . . . . . 26
4.5.1. DEV_VALID_REQ . . . . . . . . . . . . . . . . . . . . 27 4.5.1. DEV_VALID_REQ . . . . . . . . . . . . . . . . . . . . 28
4.5.2. DEV_VALID_RESP . . . . . . . . . . . . . . . . . . . . 28 4.5.2. DEV_VALID_RESP . . . . . . . . . . . . . . . . . . . 28
5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 28 5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 29
5.1. GeoLocation . . . . . . . . . . . . . . . . . . . . . . . 28 5.1. GeoLocation . . . . . . . . . . . . . . . . . . . . . . . 29
5.2. DeviceDescriptor . . . . . . . . . . . . . . . . . . . . . 30 5.2. DeviceDescriptor . . . . . . . . . . . . . . . . . . . . 31
5.3. AntennaCharacteristics . . . . . . . . . . . . . . . . . . 31 5.3. AntennaCharacteristics . . . . . . . . . . . . . . . . . 32
5.4. FrequencyRange . . . . . . . . . . . . . . . . . . . . . . 32 5.4. DeviceCapabilities . . . . . . . . . . . . . . . . . . . 33
5.5. DeviceCapabilities . . . . . . . . . . . . . . . . . . . . 33 5.5. DeviceOwner . . . . . . . . . . . . . . . . . . . . . . . 34
5.6. DeviceOwner . . . . . . . . . . . . . . . . . . . . . . . 34 5.6. RulesetInfo . . . . . . . . . . . . . . . . . . . . . . . 34
5.7. RulesetInfo . . . . . . . . . . . . . . . . . . . . . . . 34 5.7. DbUpdateSpec . . . . . . . . . . . . . . . . . . . . . . 36
5.8. DbUpdateSpec . . . . . . . . . . . . . . . . . . . . . . . 36 5.8. DatabaseSpec . . . . . . . . . . . . . . . . . . . . . . 36
5.9. DatabaseSpec . . . . . . . . . . . . . . . . . . . . . . . 36 5.9. SpectrumSpec . . . . . . . . . . . . . . . . . . . . . . 36
5.10. Spectrum . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.10. SpectrumSchedule . . . . . . . . . . . . . . . . . . . . 38
5.11. EventTime . . . . . . . . . . . . . . . . . . . . . . . . 37 5.11. Spectrum . . . . . . . . . . . . . . . . . . . . . . . . 39
5.12. SpectrumSchedule . . . . . . . . . . . . . . . . . . . . . 38 5.12. SpectrumProfile . . . . . . . . . . . . . . . . . . . . . 41
5.13. GeoSpectrumSchedule . . . . . . . . . . . . . . . . . . . 38 5.13. FrequencyRange . . . . . . . . . . . . . . . . . . . . . 42
5.14. DeviceValidity . . . . . . . . . . . . . . . . . . . . . . 39 5.14. EventTime . . . . . . . . . . . . . . . . . . . . . . . . 43
5.15. Error Element . . . . . . . . . . . . . . . . . . . . . . 40 5.15. GeoSpectrumSpec . . . . . . . . . . . . . . . . . . . . . 43
5.15.1. OUTSIDE_COVERAGE Error . . . . . . . . . . . . . . . . 42 5.16. DeviceValidity . . . . . . . . . . . . . . . . . . . . . 44
5.15.2. DATABASE_CHANGE Error . . . . . . . . . . . . . . . . 42 5.17. Error Element . . . . . . . . . . . . . . . . . . . . . . 45
5.15.3. REQUIRED Error . . . . . . . . . . . . . . . . . . . . 42 5.17.1. OUTSIDE_COVERAGE Error . . . . . . . . . . . . . . . 46
6. Message Encoding . . . . . . . . . . . . . . . . . . . . . . . 43 5.17.2. DATABASE_CHANGE Error . . . . . . . . . . . . . . . . 47
6.1. JSON-RPC Binding . . . . . . . . . . . . . . . . . . . . . 43 5.17.3. REQUIRED Error . . . . . . . . . . . . . . . . . . . 47
6.2. init Method . . . . . . . . . . . . . . . . . . . . . . . 44 6. Message Encoding . . . . . . . . . . . . . . . . . . . . . . 47
6.2.1. INIT_REQ Parameters . . . . . . . . . . . . . . . . . 45 6.1. JSON-RPC Binding . . . . . . . . . . . . . . . . . . . . 48
6.2.2. INIT_RESP Parameters . . . . . . . . . . . . . . . . . 46 6.2. init Method . . . . . . . . . . . . . . . . . . . . . . . 49
6.3. register Method . . . . . . . . . . . . . . . . . . . . . 47 6.2.1. INIT_REQ Parameters . . . . . . . . . . . . . . . . . 49
6.3.1. REGISTRATION_REQ Parameters . . . . . . . . . . . . . 47 6.2.2. INIT_RESP Parameters . . . . . . . . . . . . . . . . 51
6.3.2. REGISTRATION_RESP Parameters . . . . . . . . . . . . . 48 6.3. register Method . . . . . . . . . . . . . . . . . . . . . 52
6.4. getSpectrum Method . . . . . . . . . . . . . . . . . . . . 49 6.3.1. REGISTRATION_REQ Parameters . . . . . . . . . . . . . 52
6.4.1. AVAIL_SPECTRUM_REQ Parameters . . . . . . . . . . . . 49 6.3.2. REGISTRATION_RESP Parameters . . . . . . . . . . . . 53
6.4.2. AVAIL_SPECTRUM_RESP Parameters . . . . . . . . . . . . 51 6.4. getSpectrum Method . . . . . . . . . . . . . . . . . . . 54
6.5. getSpectrumBatch Method . . . . . . . . . . . . . . . . . 54 6.4.1. AVAIL_SPECTRUM_REQ Parameters . . . . . . . . . . . . 55
6.5.1. AVAIL_SPECTRUM_BATCH_REQ Parameters . . . . . . . . . 54 6.4.2. AVAIL_SPECTRUM_RESP Parameters . . . . . . . . . . . 57
6.5.2. AVAIL_SPECTRUM_BATCH_RESP Parameters . . . . . . . . . 56 6.5. getSpectrumBatch Method . . . . . . . . . . . . . . . . . 60
6.6. notifySpectrumUse Method . . . . . . . . . . . . . . . . . 59 6.5.1. AVAIL_SPECTRUM_BATCH_REQ Parameters . . . . . . . . . 60
6.6.1. SPECTRUM_USE_NOTIFY Parameters . . . . . . . . . . . . 59 6.5.2. AVAIL_SPECTRUM_BATCH_RESP Parameters . . . . . . . . 62
6.6.2. SPECTRUM_USE_RESP Parameters . . . . . . . . . . . . . 61 6.6. notifySpectrumUse Method . . . . . . . . . . . . . . . . 65
6.7. verifyDevice Method . . . . . . . . . . . . . . . . . . . 62 6.6.1. SPECTRUM_USE_NOTIFY Parameters . . . . . . . . . . . 66
6.7.1. DEV_VALID_REQ Parameters . . . . . . . . . . . . . . . 62 6.6.2. SPECTRUM_USE_RESP Parameters . . . . . . . . . . . . 67
6.7.2. DEV_VALID_RESP Parameters . . . . . . . . . . . . . . 63 6.7. verifyDevice Method . . . . . . . . . . . . . . . . . . . 68
6.8. Sub-message Schemas . . . . . . . . . . . . . . . . . . . 65 6.7.1. DEV_VALID_REQ Parameters . . . . . . . . . . . . . . 68
6.8.1. GeoLocation . . . . . . . . . . . . . . . . . . . . . 65 6.7.2. DEV_VALID_RESP Parameters . . . . . . . . . . . . . . 69
6.8.2. DeviceDescriptor . . . . . . . . . . . . . . . . . . . 67 6.8. Sub-message Schemas . . . . . . . . . . . . . . . . . . . 71
6.8.3. AntennaCharacteristics . . . . . . . . . . . . . . . . 68 6.8.1. GeoLocation . . . . . . . . . . . . . . . . . . . . . 71
6.8.4. DeviceCapabilities . . . . . . . . . . . . . . . . . . 69 6.8.2. DeviceDescriptor . . . . . . . . . . . . . . . . . . 73
6.8.5. DeviceOwner . . . . . . . . . . . . . . . . . . . . . 70 6.8.3. AntennaCharacteristics . . . . . . . . . . . . . . . 74
6.8.6. RulesetInfo . . . . . . . . . . . . . . . . . . . . . 71 6.8.4. DeviceCapabilities . . . . . . . . . . . . . . . . . 75
6.8.7. DbUpdateSpec . . . . . . . . . . . . . . . . . . . . . 72 6.8.5. DeviceOwner . . . . . . . . . . . . . . . . . . . . . 76
6.8.8. DatabaseSpec . . . . . . . . . . . . . . . . . . . . . 73 6.8.6. RulesetInfo . . . . . . . . . . . . . . . . . . . . . 77
6.8.9. Spectrum . . . . . . . . . . . . . . . . . . . . . . . 73 6.8.7. DbUpdateSpec . . . . . . . . . . . . . . . . . . . . 78
6.8.10. FrequencyRange . . . . . . . . . . . . . . . . . . . . 74 6.8.8. DatabaseSpec . . . . . . . . . . . . . . . . . . . . 79
6.8.11. EventTime . . . . . . . . . . . . . . . . . . . . . . 75 6.8.9. Spectrum . . . . . . . . . . . . . . . . . . . . . . 79
6.8.12. SpectrumSchedule . . . . . . . . . . . . . . . . . . . 76 6.8.10. FrequencyRange . . . . . . . . . . . . . . . . . . . 81
6.8.13. GeoSpectrumSchedule . . . . . . . . . . . . . . . . . 77 6.8.11. EventTime . . . . . . . . . . . . . . . . . . . . . . 81
6.8.14. DeviceValidity . . . . . . . . . . . . . . . . . . . . 77 6.8.12. SpectrumSchedule . . . . . . . . . . . . . . . . . . 82
6.8.15. Additional Properties . . . . . . . . . . . . . . . . 78 6.8.13. SpectrumSpec . . . . . . . . . . . . . . . . . . . . 83
7. HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . . . 78 6.8.14. GeoSpectrumSpec . . . . . . . . . . . . . . . . . . . 84
8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 80 6.8.15. DeviceValidity . . . . . . . . . . . . . . . . . . . 85
8.1. Defining New Message Parameters . . . . . . . . . . . . . 80 6.8.16. Additional Properties . . . . . . . . . . . . . . . . 85
8.2. Defining Ruleset Identifiers . . . . . . . . . . . . . . . 80 7. HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . . . 85
8.3. Defining Additional Error Codes . . . . . . . . . . . . . 81 8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 87
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 8.1. Defining New Message Parameters . . . . . . . . . . . . . 87
9.1. PAWS Parameters Registry . . . . . . . . . . . . . . . . . 81 8.2. Defining Ruleset Identifiers . . . . . . . . . . . . . . 87
9.1.1. Registration Template . . . . . . . . . . . . . . . . 82 8.3. Defining Additional Error Codes . . . . . . . . . . . . . 88
9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 88
9.2. PAWS Ruleset ID Registry . . . . . . . . . . . . . . . . . 83 9.1. PAWS Parameters Registry . . . . . . . . . . . . . . . . 88
9.2.1. Registration Template . . . . . . . . . . . . . . . . 84 9.1.1. Registration Template . . . . . . . . . . . . . . . . 89
9.2.2. Initial Registry Contents . . . . . . . . . . . . . . 84 9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 89
9.3. PAWS Error Code Registry . . . . . . . . . . . . . . . . . 86 9.2. PAWS Ruleset ID Registry . . . . . . . . . . . . . . . . 90
9.3.1. Registration Template . . . . . . . . . . . . . . . . 87 9.2.1. Registration Template . . . . . . . . . . . . . . . . 91
9.3.2. Initial Registry Contents . . . . . . . . . . . . . . 87 9.2.2. Initial Registry Contents . . . . . . . . . . . . . . 91
10. Security Considerations . . . . . . . . . . . . . . . . . . . 87 9.3. PAWS Error Code Registry . . . . . . . . . . . . . . . . 93
10.1. Assurance of Proper Database . . . . . . . . . . . . . . . 88 9.3.1. Registration Template . . . . . . . . . . . . . . . . 94
10.2. Protection Against Modification . . . . . . . . . . . . . 88 9.3.2. Initial Registry Contents . . . . . . . . . . . . . . 94
10.3. Protection Against Eavesdropping . . . . . . . . . . . . . 88 10. Security Considerations . . . . . . . . . . . . . . . . . . . 94
10.4. Client Authentication Considerations . . . . . . . . . . . 89 10.1. Assurance of Proper Database . . . . . . . . . . . . . . 95
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 89 10.2. Protection Against Modification . . . . . . . . . . . . . 95
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 90 10.3. Protection Against Eavesdropping . . . . . . . . . . . . 95
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 90 10.4. Client Authentication Considerations . . . . . . . . . . 96
13.1. Normative References . . . . . . . . . . . . . . . . . . . 90 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 96
13.2. Informative References . . . . . . . . . . . . . . . . . . 91 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 97
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . . 92 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 97
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 94 13.1. Normative References . . . . . . . . . . . . . . . . . . 97
13.2. Informative References . . . . . . . . . . . . . . . . . 98
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 99
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 102
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 are strongly encouraged to read Protocol to Access White-Space (PAWS)
database: PS, use cases and rqmts [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
information available to devices. This approach shifts the information available to devices. This approach shifts the
complexity of spectrum-policy conformance out of the device and into complexity of spectrum-policy conformance out of the device and into
the Database. This approach also simplifies adoption of policy the Database. This approach also simplifies adoption of policy
changes, limiting updates to a handful of databases, rather than changes, limiting updates to a handful of databases, rather than
numerous devices. It opens the door for innovations in spectrum numerous devices. It opens the door for innovations in spectrum
management that can incorporate a variety of parameters, including management that can incorporate a variety of parameters, including
skipping to change at page 6, line 7 skipping to change at page 6, line 7
2.1. Conventions Used in This Document 2.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in Key words for use in document are to be interpreted as described in Key words for use in
RFCs to Indicate Requirement Levels [RFC2119]. RFCs to Indicate Requirement Levels [RFC2119].
2.2. Terminology 2.2. Terminology
Database or Spectrum Database: A database that provides spectrum Database or Spectrum Database: A database is an entity that contains
availability information to devices. current information about available spectrum at a given location
Database Listing Server A service that provides the URLs for one or and time, as well as other types of information related to
more Spectrum Databases. A regulator, for example, may operate a spectrum availability and usage.
Database Listing Server to publish the list of authorized Spectrum Device ID An identifier for a device.
Databases for its regulatory domain. 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
Master Device: A device with geo-location capability that queries a Listing server: A server that provides the URLs for one or more
database to find available spectrum. Spectrum Databases. A regulator, for example, may operate a
Slave Device: A device without geo-location capability that uses the Database Listing Server to publish the list of authorized Spectrum
spectrum made available by a Master Device. It does not query the Databases for its regulatory domain.
Database directly. Master Device: A device that queries the database, on its own behalf
and/or on behalf of a slave device, to obtain available spectrum
information.
Ruleset: A set of rules that governs operations of white space
devices and Spectrum Databases within a regulatory domain. The
same set of rules may be used by more than one regulatory domain.
Slave Device: A device that queries the database through a master
device.
3. Protocol Overview 3. Protocol Overview
A Master Device uses the PAWS protocol to obtain a schedule of A Master Device uses the PAWS protocol to obtain a schedule of
available spectrum at its location. The security necessary to ensure available spectrum at its location. The security necessary to ensure
the accuracy, privacy, and confidentiality of the Device's location the accuracy, privacy, and confidentiality of the Device's location
is described in the Security Considerations (Section 10). This is described in the Security Considerations (Section 10). This
document assumes that the Master Device and the Database are document assumes that the Master Device and the Database are
connected to the Internet. connected to the Internet.
skipping to change at page 7, line 16 skipping to change at page 7, line 22
message in the body of the HTTP response. message in the body of the HTTP response.
9. Depending on regulatory domain requirements and database 9. Depending on regulatory domain requirements and database
implementation, the Master Device sends a spectrum-usage implementation, the Master Device sends a spectrum-usage
notification message to the Database. notification message to the Database.
10. If the Database receives a spectrum-usage notification message, 10. If the Database receives a spectrum-usage notification message,
it responds by sending the Master Device a spectrum-usage it responds by sending the Master Device a spectrum-usage
acknowledgement message. acknowledgement message.
3.1. Multi-ruleset Support 3.1. Multi-ruleset Support
For a Master Device that supports multiple rule sets and operates For a Master Device that supports multiple rulesets and operates with
with multiple databases in multiple regulatory domains, the PAWS multiple databases in multiple regulatory domains, the PAWS protocol
protocol supports the following sequence of operations for each supports the following sequence of operations for each request by the
request by the Master Device: Master Device:
1. The Master Device includes in its request its location and 1. The Master Device includes in its request its location and
optionally includes the identifier of one or more of the rule optionally includes the identifier of all the rulesets it
sets it supports and any parameter values it might need for the supports and any parameter values it might need for the request
request 2. The Database uses the device location and also may use the
2. The Database may use the rule-set list to determine its response, ruleset list to determine its response, for example, to select
for example, to select the list of required parameters the list of required parameters
3. If required parameters are missing from the request, the Database 3. If required parameters are missing from the request, the Database
responds with a REQUIRED error and a list of names of the missing responds with a REQUIRED error and a list of names of the missing
parameters parameters
4. The Master Device makes the request again, adding the missing 4. The Master Device makes the request again, adding the missing
parameter values parameter values
5. The Database responds to the request, including the identifier of 5. The Database responds to the request, including the identifier of
the applicable rule set the applicable ruleset
6. The Master Device uses the indicated rule set to determine how to 6. The Master Device uses the indicated ruleset to determine how to
interpret the Database response interpret the Database response
NOTE: Regulatory rules contain many device-only requirements that NOTE: Regulatory rules contain many device-only requirements that
govern device behavior, independent of any database rules. These govern device behavior, independent of any database rules. These
requirements may be complex and involve device behavior that are not requirements may be complex and involve device behavior that are not
easily parameterized. The ruleset-id parameter provides a mechanism easily parameterized. The ruleset-id parameter provides a mechanism
for the Database to inform the Master Device of the applicable rule for the Database to inform the Master Device of the applicable
set without having to express device-side behavior within the ruleset without having to express device-side behavior within the
protocol. The rule-set identifier is a string value that contains protocol. The ruleset identifier is a string value that contains the
the name of regulatory body that established the rules and version name of regulatory body that established the rules and version
information, such as "FccTvBandWhiteSpace-2010". information, such as "FccTvBandWhiteSpace-2010".
By separating the regulatory "authority" from the "ruleset-id", it By separating the regulatory "authority" from the "ruleset-id", it
allows the protocol to support multiple regulatory authorities that allows the protocol to support multiple regulatory authorities that
use the same device-side rule set. It also allows support for a use the same device-side ruleset. It also allows support for a
single authority to define multiple rule sets. single authority to define multiple rulesets.
4. Protocol Functionalities 4. Protocol Functionalities
The PAWS protocol consists of several components: The PAWS protocol consists of several components:
o Database Discovery (Section 4.1) MUST be supported by the Master o Database Discovery (Section 4.1) MUST be supported by the Master
Device Device
o Initialization (Section 4.2) MAY be used by the Master Device and o Initialization (Section 4.2) MAY be used by the Master Device and
MUST be implemented by the Database. MUST be implemented by the Database.
o Device Registration (Section 4.3) MAY be used by the Master Device o Device Registration (Section 4.3) MAY be used by the Master Device
and MAY be implemented by the Database as a separate component or and MAY be implemented by the Database as a separate component or
as part of the Available Spectrum Query (Section 4.4) component. as part of the Available Spectrum Query (Section 4.4) component.
o Available Spectrum Query (Section 4.4) MUST be supported by Master o Available Spectrum Query (Section 4.4) MUST be supported by Master
Device and the Database. Device and the Database.
o Spectrum Use Notify (Section 4.4.5) MAY be used by the Master
Device and the Database. If the regulatory domain requires
notification, it MUST be used by the Master Device and MUST be
implemented by the Database.
o Device Validation (Section 4.5) MAY be used by the Master Device. o Device Validation (Section 4.5) MAY be used by the Master Device.
If the regulatory domain requires device validation, it MUST be If the regulatory domain requires device validation, it MUST be
implemented by the Database and MUST be used by the Master Device. implemented by the Database and MUST be used by the Master Device.
This section describes the protocol components and their messages. This section describes the protocol components and their messages.
Protocol Parameters (Section 5) contains a more thorough discussion Protocol Parameters (Section 5) contains a more thorough discussion
of the parameters that comprise the PAWS request and response of the parameters that comprise the PAWS request and response
messages. Message Encoding (Section 6) provides details of the messages. Message Encoding (Section 6) provides details of the
message encodings. HTTPS Binding (Section 7) describes the use of message encodings. HTTPS Binding (Section 7) describes the use of
HTTPS (HTTP Over TLS [RFC2818]) for transporting PAWS messages and HTTPS (HTTP Over TLS [RFC2818]) for transporting PAWS messages and
skipping to change at page 8, line 39 skipping to change at page 8, line 48
4.1. Database Discovery 4.1. Database Discovery
Different regulators may have different requirements for the approval Different regulators may have different requirements for the approval
and operation of databases, such as: and operation of databases, such as:
o A regulator may only allow a limited number of certified databases o A regulator may only allow a limited number of certified databases
to operate. It also may require the certification of each device- to operate. It also may require the certification of each device-
to-database pairing. to-database pairing.
o A regulator may maintain a trusted website that lists all approved o A regulator may maintain a trusted website that lists all approved
databases. It also may mandate how devices use the listing databases, known as the Listing Server. It also may mandate how
service. devices use the listing server.
o A regulator may allow each database to define its own terms of o A regulator may allow each database to define its own terms of
use, so that, for example, an approved device may not be able to use, so that, for example, an approved device may not be able to
access all approved databases. access all approved databases.
Prior to sending PAWS messages, a Device MUST determine the URI for a Prior to sending PAWS messages, a Device MUST determine the URI for a
Database that provides service at its current location. Database that provides service at its current location.
o A Device SHOULD support operation in any regulatory environment.
Preconfiguration Preconfiguration
The Master Device MAY be provisioned statically with the URI of one The Master Device MAY be provisioned statically with the URI of one
or more Databases. For operation in regulatory domains that do not or more Databases. For operation in regulatory domains that do not
have a listing server, the device SHOULD be provisioned with the URI have a listing server, the device SHOULD be provisioned with the URI
of all the databases for which it is certified or otherwise permitted of all the databases for which it is certified or otherwise permitted
to operate. The Device also SHOULD be provisioned with the URI of to operate. The Device also SHOULD be provisioned with the URI of
listing servers approved by regulators. listing servers approved by regulators.
Configuration Update Configuration Update
To adapt to changes in the list of certified or approved databases, To adapt to changes in the list of certified or approved databases,
the Device SHOULD be able to update its preconfigured list of the Device SHOULD update its preconfigured list of databases. If the
databases. If the Master Device retrieves its preconfigured list of Master Device retrieves its preconfigured list of databases from a
databases from a listing service, the device SHOULD check the service 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.8)) 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 SHOULD include DbUpdateSpec in its ceases operation, for example, it MUST include DbUpdateSpec in its
responses to notify Devices. A Device SHOULD be able to update its responses to notify Devices. A Device MUST update its preconfigured
preconfigured list of databases to replace (only) its entry for the list of databases to replace (only) its entry for the responding
responding Database with the URIs of the alternate databases; the Database with the URLs of the alternate databases; the list of
list of alternate databases SHOULD 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.15)), which may indicate that the database does Codes (Section 5.17)), which may indicate that the database does
not support the regulatory domain where the device is located. not support the regulatory domain where the device is located.
If a suitable database cannot be contacted, the Device SHALL NOT If a suitable database cannot be contacted, the Device MUST NOT
operate under rules for database-managed spectrum. If the Device is operate under rules for database-managed spectrum. If the Device is
already operating when it fails to contact a suitable database, and already operating when it fails to contact a suitable database, and
if the applicable regulatory domain provides a grace period, the if the applicable regulatory domain provides a grace period, the
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 URIs of databases for the domain. Device MUST use it to determine the URLs of databases for the domain.
Where allowed by the regulator, the Device MAY save the database list The URI of the Listing Server for a regulatory domain MAY be
and SHOULD contact the Database Listing Server periodically to update preconfigured in the device. Where allowed by the regulator, the
its list. The time between such updates SHALL be no longer than one Device MAY save the database list and SHOULD contact the Database
week, or any update interval required by the applicable regulatory Listing Server periodically to update its list. The time between
domain, whichever is shorter. such updates MUST be no longer than one week, or any update interval
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 SHALL 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
Device attempting to update the available spectrum from a Database Device attempting to update the available spectrum from a Database
fails to contact the Database Listing Server to validate the Database fails to contact the Database Listing Server to validate the Database
that provides the available spectrum, the operating Device MUST that provides the available spectrum, the operating Device MUST
immediately cease use of the spectrum under rules for database- immediately cease use of the spectrum under rules for database-
managed spectrum. managed spectrum.
The Database Listing request procedure is depicted in Figure 1. The Database Listing request procedure is depicted in Figure 1.
o LISTING_REQ is the database-listing request message o LISTING_REQ is the database-listing request message
skipping to change at page 10, line 52 skipping to change at page 11, line 13
Specific message formats are defined by the regulators. Specific message formats are defined by the regulators.
4.2. Initialization 4.2. Initialization
A Master Device SHOULD use the initialization procedure to exchange A Master Device SHOULD use the initialization procedure to exchange
capability information with the Database whenever the Master Device capability information with the Database whenever the Master Device
powers up or initiates communication with the Database. The powers up or initiates communication with the Database. The
initialization response informs the Master Device of specific initialization response informs the Master Device of specific
regulatory-dependent parameterized-rule values, such as threshold regulatory-dependent parameterized-rule values, such as threshold
distances and time periods beyond which the Device must update its distances and time periods beyond which the Device must update its
available-spectrum data (see RuleSetInfo (Section 5.7)). The Master available-spectrum data (see RuleSetInfo (Section 5.6)). The Master
Device MAY manually configure these parameterized-rule values. The Device MAY manually configure these parameterized-rule values. The
initialization message also represents extension points for database initialization message also represents extension points for database
implementations or regulatory domains that require the extra implementations or regulatory domains that require the extra
handshake. handshake.
The Initialization request procedure is depicted in Figure 2. The Initialization request procedure is depicted in Figure 2.
o INIT_REQ (Section 4.2.1) is the initialization request message o INIT_REQ (Section 4.2.1) is the initialization request message
o INIT_RESP (Section 4.2.2) is the initialization response message o INIT_RESP (Section 4.2.2) is the initialization response message
+---------------+ +-------------------+ +---------------+ +-------------------+
skipping to change at page 11, line 37 skipping to change at page 11, line 47
The initialization request message allows the Master Device to The initialization request message allows the Master Device to
initiate exchange of capabilities with the Database. initiate exchange of capabilities with the Database.
+---------------------------------------+ +---------------------------------------+
|INIT_REQ | |INIT_REQ |
+----------------------------+----------| +----------------------------+----------|
|deviceDesc:DeviceDescriptor | required | |deviceDesc:DeviceDescriptor | required |
|location:GeoLocation | required | |location:GeoLocation | required |
|.......................................| |.......................................|
|*other:any | depends | |*other:any | |
+----------------------------+----------+ +----------------------------+----------+
Parameters: Parameters:
deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is
REQUIRED. If the Database does not support the device or any of REQUIRED. If the Database does not support the device or any of
the rule sets specified in the device descriptor, it MUST return the rulesets specified in the device descriptor, it MUST return an
an error with the UNSUPPORTED (Table 1) code in the error error with the UNSUPPORTED (Table 1) code in the error response.
response. If the device descriptor does not contain any ruleset IDs, the
Database SHOULD return a list of RulesetInfo (Section 5.6)
parameters for each regulatory domain it supports at the specified
location.
location: The GeoLocation (Section 5.1) for the Device is REQUIRED. location: The GeoLocation (Section 5.1) for the Device is REQUIRED.
other: Depending on the regulatory domain or database other: Depending on the regulatory domain or database
implementation, the Master Device MAY specify additional handshake implementation, the Master Device MAY specify additional handshake
parameters in the INIT_REQ message. The Database MUST ignore all parameters in the INIT_REQ message. The Database MUST ignore all
parameters it does not understand. parameters it does not understand.
4.2.2. INIT_RESP 4.2.2. INIT_RESP
The initialization response message communicates database parameters The initialization response message communicates database parameters
to the requesting device. to the requesting device.
skipping to change at page 12, line 17 skipping to change at page 12, line 26
parameters in the INIT_REQ message. The Database MUST ignore all parameters in the INIT_REQ message. The Database MUST ignore all
parameters it does not understand. parameters it does not understand.
4.2.2. INIT_RESP 4.2.2. INIT_RESP
The initialization response message communicates database parameters The initialization response message communicates database parameters
to the requesting device. to the requesting device.
+---------------------------------------+ +---------------------------------------+
|INIT_RESP | |INIT_RESP |
+----------------------------+----------+ +----------------------------+----------+ 1..* +-------------+
|rulesetInfo:RulesetInfo | required | |rulesetInfos:list | required |------->| RulesetInfo |
|databaseChange:DbUpdateSpec | optional | |databaseChange:DbUpdateSpec | optional | +-------------+
|.......................................| |.......................................|
|*other:any | depends | |*other:any | |
+----------------------------+----------+ +----------------------------+----------+
Parameters: Parameters:
rulesetInfo: This RulesetInfo (Section 5.7) parameter MUST be rulesetInfos: A list of RulesetInfo (Section 5.6) parameters MUST be
included in the response. This parameter specifies the regulatory included in the response. Each RulesetInfo parameter corresponds
domain and parameters applicable for that domain. The Database to a regulatory domain supported by the Database and is applicable
MUST include the "authority" field that defines the regulatory to the location specified in the INIT_REQ (Section 4.2.1) message.
domain for the location specified in the INIT_REQ (Section 4.2.1) If the Device included a list of ruleset IDs in the
message. DeviceDescriptor parameter of its INIT_REQ message, each
RulesetInfo parameter in the response MUST match one of the
specified ruleset IDs.
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.8) 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 URIs. The Database URI, providing one or more alternate database URLs. 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 URIs. responding database with the list of alternate URLs.
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
establish certain operational parameters. FCC rules, for example, establish certain operational parameters. FCC rules, for example,
skipping to change at page 13, line 33 skipping to change at page 14, line 5
|<------------------------| |<------------------------|
| | | |
Figure 3 Figure 3
4.3.1. REGISTRATION_REQ 4.3.1. REGISTRATION_REQ
The registration request message contains the required registration The registration request message contains the required registration
parameters. parameters.
+---------------------------------------+ +--------------------------------------------------------------+
|REGISTRATION_REQ | |REGISTRATION_REQ |
+----------------------------+----------+ +-------------------------------+------------------------------+
|deviceDesc:DeviceDescriptor | required | |deviceDesc:DeviceDescriptor | required |
|location:GeoLocation | required | |location:GeoLocation | required |
|deviceOwner:DeviceOwner | required | |deviceOwner:DeviceOwner | required |
|.......................................| |antenna:AntennaCharacteristics | depends on regulatory domain |
|*other:any | depends | |..............................................................|
+----------------------------+----------+ |*other:any | |
+-------------------------------+------------------------------+
Parameters: Parameters:
deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is
REQUIRED. REQUIRED. The ruleset IDs included in the this parameter indicate
the regulatory domains for which the Device wishes to register.
If the registration information is unacceptable for all of the
regulatory domains supported by the Database, the Database MUST
return an error message with an appropriate error code.
Otherwise, the Database MUST return, in its response, a list of
RulesetInfo (Section 5.6) parameters for all regulatory domains
for which device registration was accepted.
location: The GeoLocation (Section 5.1) for the Device is REQUIRED. location: The GeoLocation (Section 5.1) for the Device is REQUIRED.
deviceOwner: The DeviceOwner (Section 5.5) information is REQUIRED.
deviceOwner: The DeviceOwner (Section 5.6) information is REQUIRED. antenna: Depending on the regulatory domain, the
AntennaCharacteristics (Section 5.3) MAY be required.
other: Regulatory domains and database implementations MAY require other: Regulatory domains and database implementations MAY require
additional registration parameters. To simplify its registration additional registration parameters. To simplify its registration
logic, the Device MAY send a union of the registration information logic, the Device MAY send a union of the registration information
required by all supported regulatory domains. The Database MUST required by all supported regulatory domains. The Database MUST
ignore all parameters it does not understand. Consult the PAWS ignore all parameters it does not understand. Consult the PAWS
Parameters Registry (Section 9.1) for possible additional Parameters Registry (Section 9.1) for possible additional
parameters. parameters.
4.3.2. REGISTRATION_RESP 4.3.2. REGISTRATION_RESP
The registration response message simply acknowledges receipt of the The registration response message acknowledges successful
request and is otherwise empty. Future extensions may add parameters registration by including a RulesetInfo message for each regulatory
to this message. domain in which the registration is accepted. If the Database
accepts the registration for none of the regulatory domains it
supports, the Database MUST return an error.
+---------------------------------------+ +---------------------------------------+
|REGISTRATION_RESP | |REGISTRATION_RESP |
+----------------------------+----------+ +----------------------------+----------+ 1..* +-------------+
|databaseChange:DbUpdateSpec | optional | |rulesetInfos:list | required |------->| RulesetInfo |
|databaseChange:DbUpdateSpec | optional | +-------------+
|............................|..........| |............................|..........|
|*other:any | depends | |*other:any | |
+----------------------------+----------+ +----------------------------+----------+
Parameters: Parameters:
rulesetInfos: A list of RulesetInfo (Section 5.6) parameters MUST be
included in the response, each of which corresponds to a
regulatory domain for which the registration was accepted. The
list MUST contain at least one entry.
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.8) 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 URIs. The Database URI, providing one or more alternate database URLs. 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 URIs. responding database with the list of alternate URLs.
other: Database implementations MAY return addtional 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,
capabilities, and characteristics). The Database returns a response capabilities, and characteristics). The Database returns a response
skipping to change at page 16, line 28 skipping to change at page 17, line 19
6. If the available-spectrum response indicates that the Master 6. If the available-spectrum response indicates that the Master
Device must send a spectrum-usage notification message, the Device must send a spectrum-usage notification message, the
Master Device MUST send the notification message to the Database. Master Device MUST send the notification message to the Database.
7. If the Database receives a spectrum-usage notification message, 7. If the Database receives a spectrum-usage notification message,
it MUST send a spectrum-usage acknowledgment message to the it MUST send a spectrum-usage acknowledgment message to the
Master Device. Master Device.
The procedure for asking for available spectrum on behalf of a Slave The procedure for asking for available spectrum on behalf of a Slave
Device is similar, except that the process is initiated by the Slave Device is similar, except that the process is initiated by the Slave
Device. The device identifier, capabilities, and characteristics Device. The device identifier, capabilities, and characteristics
communicated in the AVAIL_SPECTRUM_REQ message SHALL be those of the communicated in the AVAIL_SPECTRUM_REQ message MUST be those of the
Slave Device, but the location SHALL be that of the Master Device. Slave Device, but the location MUST be that of the Master Device.
Although the communication and protocol between the Slave Device and Although the communication and protocol between the Slave Device and
Master Device is outside the scope of this document, the expected Master Device is outside the scope of this document, the expected
message sequence is shown in Figure 5. message sequence is shown in Figure 5.
+------------+ +---------------+ +-------------------+ +------------+ +---------------+ +-------------------+
|Slave Device| | Master Device | | Spectrum Database | |Slave Device| | Master Device | | Spectrum Database |
+------------+ +---------------+ +-------------------+ +------------+ +---------------+ +-------------------+
| | | | | |
| AVAIL_SPEC_REQ | | | AVAIL_SPEC_REQ | |
|................>| | |................>| |
skipping to change at page 17, line 40 skipping to change at page 18, line 15
4.4.1. AVAIL_SPECTRUM_REQ 4.4.1. AVAIL_SPECTRUM_REQ
The request message for the Available Spectrum Query protocol MUST The request message for the Available Spectrum Query protocol MUST
include the Device's geo-location. If allowed by the regulatory include the Device's geo-location. If allowed by the regulatory
domain, the location MAY be an anticipated location. domain, the location MAY be an anticipated location.
+-----------------------------------------------------------------+ +-----------------------------------------------------------------+
|AVAIL_SPECTRUM_REQ | |AVAIL_SPECTRUM_REQ |
+----------------------------------+------------------------------+ +----------------------------------+------------------------------+
|deviceDesc:DeviceDescriptor | optional | |deviceDesc:DeviceDescriptor | optional |
|location:GeoLocation | required | |location:GeoLocation | optional |
|antenna:AntennaCharacteristics | depends on regulatory domain |
|owner:DeviceOwner | depends on regulatory domain | |owner:DeviceOwner | depends on regulatory domain |
|antenna:AntennaCharacteristics | depends on regulatory domain |
|capabilities:DeviceCapabilities | optional | |capabilities:DeviceCapabilities | optional |
|masterDeviceDesc:DeviceDescriptor | optional | |masterDeviceDesc:DeviceDescriptor | optional |
|masterDeviceLocation:GeoLocation | optional |
|requestType:string | optional | |requestType:string | optional |
|..................................|..............................| |..................................|..............................|
|*other:any | depends | |*other:any | |
+----------------------------------+------------------------------+ +----------------------------------+------------------------------+
Parameters: Parameters:
deviceDesc: The DeviceDescriptor (Section 5.2) for the Device deviceDesc: The DeviceDescriptor (Section 5.2) for the Device
requesting available spectrum. When the request is made by a requesting available spectrum. When the request is made by a
Master Device on its own behalf, the descriptor is that of the Master Device on its own behalf, the descriptor is that of the
Master Device and it is REQUIRED. When the request is made on Master Device and it is REQUIRED. When the request is made on
behalf of a Slave Device, the descriptor is that of the Slave behalf of a Slave Device, the descriptor is that of the Slave
Device, and it is REQUIRED if the "requestType" parameter is not Device, and it is REQUIRED if the "requestType" parameter is not
specified. The deviceDesc parameter may be OPTIONAL for some specified. The deviceDesc parameter may be OPTIONAL for some
values of requestType. values of requestType.
location: The GeoLocation (Section 5.1) for the Master Device is location: The GeoLocation (Section 5.1) for the Device requesting
REQUIRED. The location SHOULD be the current location of the available spectrum. The location SHOULD be the current location
Device, but more precisely, the location of the radiation center of the Device, but more precisely, the location of the radiation
of the Device's antenna. When the request is made by the Master center of the Device's antenna. When the request is made by the
Device on behalf of a Slave Device, the location is that of the Master Device on its own behalf, the location is that of the
Master Device. Depending on the regulatory domain, the location Master Device and it is REQUIRED. When the request is made by the
MAY be an anticipated position of the Device to support mobile Master Device on behalf of a Slave Device, the location is that of
devices. If the location specifies a region, rather than a point, the Slave Device and it is OPTIONAL (see also the
the Database MAY return an error with the UNIMPLEMENTED (Table 1) masterDeviceLocation parameter). Depending on the regulatory
code, if it does not support query by region. domain, the location MAY be an anticipated position of the Device
antenna: Depending on the device type and regulatory domain, the to support mobile devices. If the location specifies a region,
AntennaCharacteristics (Section 5.3) MAY be required. rather than a point, the Database MAY return an error with the
UNIMPLEMENTED (Table 1) code, if it does not support query by
region.
owner: Depending on the device type and regulatory domain, the owner: Depending on the device type and regulatory domain, the
DeviceOwner (Section 5.6) information MAY be included to register DeviceOwner (Section 5.5) information MAY be included to register
the Device with the Database. This enables the Device to register the Device with the Database. This enables the Device to register
and get spectrum-availability information in a single request. and get spectrum-availability information in a single request.
antenna: Depending on the device type and regulatory domain, the
AntennaCharacteristics (Section 5.3) MAY be required.
capabilities: The Master Device MAY include its DeviceCapabilities capabilities: The Master Device MAY include its DeviceCapabilities
(Section 5.5) to limit the available-spectrum response to the (Section 5.4) to limit the available-spectrum response to the
spectrum that is compatible with its capabilities. The Database spectrum that is compatible with its capabilities. The Database
SHOULD NOT return spectrum that is not compatible with the SHOULD NOT return spectrum that is not compatible with the
specified capabilities. specified capabilities.
masterDeviceDesc: Depending on regulatory rules, when the request is masterDeviceDesc: Depending on regulatory rules and Database
made by the Master Device on behalf of a Slave Device, the Master implementations, when the request is made by the Master Device on
Device MAY be required to provide its own descriptor. behalf of a Slave Device, the Master Device MAY be required to
provide its own descriptor.
masterDeviceLocation: Depending on regulatory rules, when the
request is made by the Master Device on behalf of a Slave Device,
the GeoLocation (Section 5.1) of the Master Device MAY be
required.
requestType: The request type is an OPTIONAL parameter that may be requestType: The request type is an OPTIONAL parameter that may be
used to modify the request, but its use depends on applicable used to modify the request, but its use depends on applicable
regulatory rules. The request type may be used, for example, to regulatory rules. The request type may be used, for example, to
request generic Slave Device parameters without having to specify request generic Slave Device parameters without having to specify
the device descriptor for a specific device. When the requestType the device descriptor for a specific device. When the requestType
parameter is missing, the request is for a specific device (Master parameter is missing, the request is for a specific device (Master
or Slave), so the deviceDesc parameter is REQUIRED. See IANA or Slave), so the deviceDesc parameter is REQUIRED. See IANA
Ruleset Registry, Initial Registry Contents (Section 9.2.2) for Ruleset Registry, Initial Registry Contents (Section 9.2.2) for
regulatory specifics. regulatory specifics.
other: Regulatory domains and database implementations MAY require other: Regulatory domains and database implementations MAY require
additional request parameters. The Database MUST ignore all additional request parameters. The Database MUST ignore all
parameters it does not understand. Consult the PAWS Parameters parameters it does not understand. Consult the PAWS Parameters
Registry (Section 9.1) for possible additional parameters. Registry (Section 9.1) for possible additional parameters.
4.4.2. AVAIL_SPECTRUM_RESP 4.4.2. AVAIL_SPECTRUM_RESP
The response message for the Available Spectrum Query contains a The response message for the Available Spectrum Query contains one or
schedule of available spectrum for the Device. more SpectrumSpec (Section 5.9) elements, one for each regulatory
domain supported at the location specified in the corresponding
AVAIL_SPECTRUM_REQ (Section 4.4.1) request. Each SpectrumSpec
element contains a list of one or more spectrum schedules,
representing permissible power levels over time:
o Within each list of schedules, event-time intervals MUST be
disjoint and SHOULD be sorted in increasing time
o A gap in the time schedule means no spectrum is available for that
time interval
+---------------------------------------+ +---------------------------------------+
|AVAIL_SPECTRUM_RESP | |AVAIL_SPECTRUM_RESP |
+----------------------------+----------+ +----------------------------+----------+
|timestamp:string | required | |timestamp:string | required |
|deviceDesc:DeviceDescriptor | required | |deviceDesc:DeviceDescriptor | required |
|spectrumSchedules:list | required |-------+ |spectrumSpecs:list | required |-------+
|needsSpectrumReport:bool | optional | |
|maxTotalBwHz:float | optional | |
|maxContiguousBwHz:float | optional | |
|rulesetInfo:RulesetInfo | optional | |
|............................|..........| |
|location:GeoLocation | optional | |
|............................|..........| | |............................|..........| |
|databaseChange:DbUpdateSpec | optional | | |databaseChange:DbUpdateSpec | optional | |
|*other:any | depends | | |*other:any | | |
+----------------------------+----------+ | 0..* +----------------------------+----------+ | 1..*
V V
+-----------------------------+ +-----------------------------------+
|SpectrumSchedule | |SpectrumSpec |
+------------------+----------+ +------------------------+----------+
|time:EventTime | required | |rulesetInfo:RulesetInfo | required |
|spectrum:Spectrum | required | |spectrumSchedules:list | required |-+
+------------------+----------+ |timeRange:EventTime | optional | |
|frequencyRanges:list | optional | |
|needsSpectrumReport:bool| optional | |
|maxTotalBwHz:float | optional | |
|maxContiguousBwHz:float | optional | |
+------------------------+----------+ |
+--------------------+
| 1..*
V
+-------------------------------+
|SpectrumSchedule |
+--------------------+----------+
|eventTime:EventTime | required |
|spectra: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_REQ message.
spectrumSchedules: The SpectrumSchedule (Section 5.12) list is spectrumSpecs: The SpectrumSpec (Section 5.9) list is REQUIRED and
REQUIRED (though it MAY be empty if no spectrum is available). MUST include at least one entry. Each entry contains the
The Database MAY return more than one SpectrumSchedule schedules of available spectrum for a regulatory domain. The
(Section 6.8.12) to represent future changes to the available Database MAY return more than one SpectrumSpec to represent
spectrum. How far in advance a schedule may be provided depends available spectrum for multiple regulatory domains at the
on the regulatory domain. specified location.
needsSpectrumReport: For regulatory domains that require a spectrum-
usage report from devices, the Database MUST return true for this
parameter if spectrumSchedules list is non-empty; otherwise, the
Database MAY return false or omit this parameter altogether. If
the spectrumSchedules list is empty, the Database SHOULD NOT
return true. If this parameter is present and its value is true,
the Device MUST send a SPECTRUM_USE_NOTIFY (Section 4.4.5) message
to the Database; otherwise, the Device SHOULD NOT send the
SPECTRUM_USE_NOTIFY message.
maxTotalBwHz: The Database MAY return a constraint on the maximum
total bandwidth (in Hertz) allowed, which may or may not be
contiguous. A regulatory domain MAY require the Database to
return this parameter. When present in the response, the Device
MUST apply this constraint to its spectrum-selection logic to
ensure total bandwidth does not exceed this value.
maxContiguousBwHz: The Database MAY return a constraint on the
maximum contiguous bandwidth (in Hertz) allowed. A regulatory
domain MAY require this Database to return this parameter. When
present in the response, the Device MUST apply this constraint to
its spectrum-selection logic to ensure no single block of spectrum
has bandwidth that exceeds this value.
rulesetInfo: The Database SHOULD return the RulesetInfo
(Section 6.8.6) parameter that identifies the applicable
regulatory authority and rule set for the response (see Ruleset ID
Registry (Section 9.2)). If included, the Device MUST use the
corresponding rule set to interpret the response. Values provided
within this parameter, such as maxLocationChange, take precedence
over the values provided by the Initialization Procedure
(Section 4.2).
location: The Database MAY copy other elements from the request,
such as the GeoLocation (Section 5.1) of the Device. The Device
MUST ignore any parameters it does not understand.
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.8) 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 URIs. The Database URI, providing one or more alternate database URLs. 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 URIs. responding database with the list of alternate URLs.
other: Database implementations MAY return addtional 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
the next one in the list (if provided) or making another Available the next one in the list (if provided) or making another Available
skipping to change at page 21, line 4 skipping to change at page 21, line 26
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
the next one in the list (if provided) or making another Available the next one in the list (if provided) or making another Available
Spectrum Query (Section 4.4) Spectrum Query (Section 4.4)
o If the new schedule indicates the in-use spectrum is no longer o If the new schedule indicates the in-use spectrum is no longer
available, the Device MUST immediately cease use of that spectrum available, the Device MUST immediately cease use of that spectrum
under rules for database-managed spectrum. under rules for database-managed spectrum.
o If the Device is unable to contact the Database to obtain a new o If the Device is unable to contact the Database to obtain a new
schedule, the Device MUST immeidately cease use of that spectrum schedule, the Device MUST immediately cease use of that spectrum
under rules for database-managed spectrum. under rules for database-managed spectrum.
When the Device moves beyond a threshold distance (established by When the Device moves beyond a threshold distance (established by
regulatory rules) away from the actual location and all anticipated regulatory rules) away from the actual location and all anticipated
location(s) it reported in previous AVAIL_SPECTRUM_REQ or location(s) it reported in previous AVAIL_SPECTRUM_REQ or
AVAIL_SPECTRUM_BATCH_REQ requests (see "maxLocationChange" in AVAIL_SPECTRUM_BATCH_REQ requests (see "maxLocationChange" in
RulesetInfo (Section 5.7)), it: RulesetInfo (Section 5.6)), it:
o MUST obtain a new spectrum-availability schedule by making another o MUST obtain a new spectrum-availability schedule by making another
Available Spectrum Query (Section 4.4). Available Spectrum Query (Section 4.4).
o If the new response indicates the in-use spectrum is no longer o If the new response indicates the in-use spectrum is no longer
available, the Device MUST stop operation immediately. available, the Device MUST stop operation immediately.
o If the Device is unable to contact the Database to obtain a new o If the Device is unable to contact the Database to obtain a new
schedule, depending on the regulatory domain, the Device MUST schedule, depending on the regulatory domain, the Device MUST
immediately cease use of the spectrum under rules of database- immediately cease use of the spectrum under rules of database-
managed spectrum. managed spectrum.
NOTE: Regulatory rules govern whether a device may request and use NOTE: Regulatory rules govern whether a device may request and use
spectrum at anticipated locations beyond the threashold distance from spectrum at anticipated locations beyond the threshold distance from
its current location. its current location.
4.4.3. AVAIL_SPECTRUM_BATCH_REQ 4.4.3. AVAIL_SPECTRUM_BATCH_REQ
The Database MAY support the batch request that allows multiple The Database MAY support the batch request that allows multiple
locations to be specified. This allows a portable Master Device to locations to be specified. This allows a portable Master Device to
get available spectrum for a sequence of anticipated locations using get available spectrum for a sequence of anticipated locations using
a single request. The Database MUST interpret each location in the a single request. The Database MUST interpret each location in the
batch request as if it were an independent request and MUST return batch request as if it were an independent request and MUST return
results consistent with multiple individual AVAIL_SPECTRUM_REQ results consistent with multiple individual AVAIL_SPECTRUM_REQ
(Section 4.4.1) requests. The request message for the batch (Section 4.4.1) requests. The request message for the batch
Available Spectrum Query protocol MUST include at least one Available Spectrum Query protocol MUST include at least one
GeoLocation (Section 5.1). If the Database does not support batch GeoLocation (Section 5.1). If the Database does not support batch
requests, it MUST return a UNIMPLEMENTED (Table 1) error. requests, it MUST return a UNIMPLEMENTED (Table 1) error.
+----------------------------------------------------------------+ +----------------------------------------------------------------+
|AVAIL_SPECTRUM_BATCH_REQ | |AVAIL_SPECTRUM_BATCH_REQ |
+---------------------------------+------------------------------+ +---------------------------------+------------------------------+
|deviceDesc:DeviceDescriptor | optional | |deviceDesc:DeviceDescriptor | optional |
|locations:list | required |--+ |locations:list | required |--+
|antenna:AntennaCharacteristics | depends on regulatory domain | |
|owner:DeviceOwner | depends on regulatory domain | | |owner:DeviceOwner | depends on regulatory domain | |
|antenna:AntennaCharacteristics | depends on regulatory domain | |
|capabilities:DeviceCapabilities | optional | | |capabilities:DeviceCapabilities | optional | |
|masterDeviceDesc:DeviceDescriptor| optional | | |masterDeviceDesc:DeviceDescriptor| optional | |
|masterDeviceLocation:GeoLocation | optional | |
|requestType:string | optional | | |requestType:string | optional | |
+.................................+..............................+ | +.................................+..............................+ |
|*other:any | depends | | |*other:any | | |
+---------------------------------+------------------------------+ | +---------------------------------+------------------------------+ |
| |
1..* V 1..* V
+-------------+ +-------------+
| GeoLocation | | GeoLocation |
+-------------+ +-------------+
Parameters: Parameters:
deviceDesc: The DeviceDescriptor (Section 5.2) for the Device deviceDesc: The DeviceDescriptor (Section 5.2) for the Device
requesting available spectrum. When the request is made by a requesting available spectrum. When the request is made by a
Master Device on its own behalf, the descriptor is that of the Master Device on its own behalf, the descriptor is that of the
Master Device and it is REQUIRED. When the request is made on Master Device and it is REQUIRED. When the request is made on
behalf of a Slave Device, the descriptor is that of the Slave behalf of a Slave Device, the descriptor is that of the Slave
Device, and it is REQUIRED if the "requestType" parameter is not Device, and it is REQUIRED if the "requestType" parameter is not
specified. The deviceDesc parameter may be OPTIONAL for some specified. The deviceDesc parameter may be OPTIONAL for some
values of requestType. values of requestType.
locations: The GeoLocation (Section 5.1) list for the Master Device locations: The GeoLocation (Section 5.1) list for the Device is
is REQUIRED. This allows the Device to specify its actual REQUIRED. This allows the Device to specify its actual location
location plus additional anticipated locations, when allowed by plus additional anticipated locations, when allowed by the
the regulatory domain. At least one location MUST be included. regulatory domain. At least one location MUST be included. This
This specification places no upper limit on the number of specification places no upper limit on the number of locations,
locations, but the Database MAY restrict the number of locations but the Database MAY restrict the number of locations it supports
it supports by returning a response with fewer locations than by returning a response with fewer locations than specified in the
specified in the request. request. If the locations specify regions, rather than points,
antenna: Depending on the device type and regulatory domain, the the Database MAY return an error with the UNIMPLEMENTED (Table 1)
AntennaCharacteristics (Section 5.3) MAY be required. code, if it does not support query by region. When the request is
made by a Master Device on its own behalf, the locations are those
of the Master Device. When the request is made by the Master
Device on behalf of a Slave Device, the locations are those of the
Slave Device (see also the masterDeviceLocation parameter).
owner: Depending on the device type and regulatory domain, the owner: Depending on the device type and regulatory domain, the
DeviceOwner (Section 5.6) information MAY be included to register DeviceOwner (Section 5.5) information MAY be included to register
the Device with the Database. This enables the Device to register the Device with the Database. This enables the Device to register
and get spectrum-availability information in a single request. and get spectrum-availability information in a single request.
antenna: Depending on the device type and regulatory domain, the
AntennaCharacteristics (Section 5.3) MAY be required.
capabilities: The Master Device MAY include its DeviceCapabilities capabilities: The Master Device MAY include its DeviceCapabilities
(Section 5.5) to limit the available-spectrum response to the (Section 5.4) to limit the available-spectrum response to the
spectrum that is compatible with its capabilities. The Database spectrum that is compatible with its capabilities. The Database
SHOULD NOT return spectrum that is not compatible with the SHOULD NOT return spectrum that is not compatible with the
specified capabilities. specified capabilities.
masterDeviceDesc: Depending on regulatory rules, when the request is masterDeviceDesc: Depending on regulatory rules, when the request is
made by the Master Device on behalf of a Slave Device, the Master made by the Master Device on behalf of a Slave Device, the Master
Device MAY BE REQUIRED to provide its own descriptor. Device MAY BE REQUIRED to provide its own descriptor.
masterDeviceLocation: Depending on regulatory rules and Database
implementations, when the request is made by the Master Device on
behalf of a Slave Device, the GeoLocation (Section 5.1) for the
Master Device MAY be required.
requestType: The request type is an OPTIONAL parameter that may be requestType: The request type is an OPTIONAL parameter that may be
used to modify the request, but its use depends on applicable used to modify the request, but its use depends on applicable
regulatory rules. The request type may be used, for example, to regulatory rules. The request type may be used, for example, to
request generic Slave Device parameters without having to specify request generic Slave Device parameters without having to specify
the device descriptor for a specific device. When the requestType the device descriptor for a specific device. When the requestType
parameter is missing, the request is for a specific device (Master parameter is missing, the request is for a specific device (Master
or Slave), so the deviceDesc parameter is REQUIRED. See IANA or Slave), so the deviceDesc parameter is REQUIRED. See IANA
Ruleset Registry, Initial Registry Contents (Section 9.2.2) for Ruleset Registry, Initial Registry Contents (Section 9.2.2) for
regulatory specifics. regulatory specifics.
other: Regulatory domains and database implementations MAY require other: Regulatory domains and database implementations MAY require
skipping to change at page 23, line 33 skipping to change at page 24, line 10
The response message for the batch Available Spectrum Query contains The response message for the batch Available Spectrum Query contains
a schedule of available spectrum for the Device at multiple a schedule of available spectrum for the Device at multiple
locations. locations.
+---------------------------------------+ +---------------------------------------+
|AVAIL_SPECTRUM_BATCH_RESP | |AVAIL_SPECTRUM_BATCH_RESP |
+----------------------------+----------+ +----------------------------+----------+
|timestamp:string | required | |timestamp:string | required |
|deviceDesc:DeviceDescriptor | required | |deviceDesc:DeviceDescriptor | required |
|geoSpectrumSchedules:list | required |-------+ |geoSpectrumSpecs:list | required |-------+
|needsSpectrumReport:bool | optional | |
|maxTotalBwHz:float | optional | |
|maxContiguousBwHz:float | optional | |
|rulesetInfo:RulesetInfo | optional | |
|............................|..........| | |............................|..........| |
|databaseChange:DbUpdateSpec | optional | | |databaseChange:DbUpdateSpec | optional | |
|*other:any | depends | | |*other:any | | |
+----------------------------+----------+ | 0..* +----------------------------+----------+ | 0..*
V V
+---------------------------------+ +---------------------------------+
|GeoSpectrumSchedule | |GeoSpectrumSpec |
+----------------------+----------+ +----------------------+----------+
|location:GeoLocation | required | |location:GeoLocation | required |
|spectrumSchedule: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_REQ message.
geoSpectrumSchedules: The geoSpectrumSchedule (Section 5.13) 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 more than one each location, the Database MAY return one or more SpectrumSpec
GeoSpectrumSchedule (Section 6.8.13) to represent future changes (Section 5.9) parameters to represent available spectrum for one
to the available spectrum. How far in advance a schedule may be or more regulatory domains. The Database MAY return available
provided depends on the regulatory domain. The Database MAY spectrum for fewer locations than requested. The Device MUST NOT
return available spectrum for fewer locations than requested. The make any assumptions on the order of the entries in the list and
Device MUST NOT make any assumptions on the order of the entries MUST use the location value in each GeoSpectrumSpec entry to match
in the list and MUST use the location value in each available spectrum to a location.
GeoSpectrumSchedule entry to match available spectrum to a
location.
needsSpectrumReport: For regulatory domains that require a spectrum-
usage report from devices, the Database MUST return true for this
parameter if spectrumSchedules list is non-empty; otherwise, the
Database MAY return false or omit this parameter altogether. If
the spectrumSchedules list is empty, the Database SHOULD NOT
return true. If this parameter is present and its value is true,
the Device MUST send a SPECTRUM_USE_NOTIFY (Section 4.4.5) message
to the Database; otherwise, the Device SHOULD NOT send the
SPECTRUM_USE_NOTIFY message.
maxTotalBwHz: The Database MAY return a constraint on the maximum
total bandwidth (in Hertz) allowed, which may or may not be
contiguous. A regulatory domain MAY require the Database to
return this parameter. When present in the response, the Device
MUST apply this constraint to its spectrum-selection logic to
ensure total bandwidth does not exceed this value.
maxContiguousBwHz: The Database MAY return a constraint on the
maximum contiguous bandwidth (in Hertz) allowed. A regulatory
domain MAY require this Database to return this parameter. When
present in the response, the Device MUST apply this constraint to
its spectrum-selection logic to ensure no single block of spectrum
has bandwidth that exceeds this value.
rulesetInfo: The Database SHOULD return the RulesetInfo
(Section 6.8.6) parameter that identifies the applicable
regulatory authority and rule set for the response (see Ruleset ID
Registry (Section 9.2)). If included, the Device MUST use the
corresponding rule set to interpret the response. Values provided
within this parameter, such as maxLocationChange, take precedence
over the values provided by the Initialization Procedure
(Section 4.2).
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.8) 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 URIs. The Database URI, providing one or more alternate database URLs. 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 URIs. responding database with the list of alternate URLs.
other: Database implementations MAY return addtional 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
The spectrum-use notification message MUST contain the geo-location The spectrum-use notification message MUST contain the geo-location
of the Device and parameters required by the regulatory domain. of the Device and parameters required by the regulatory domain.
+---------------------------------------+ +--------------------------------------------+
|SPECTRUM_USE_NOTIFY | |SPECTRUM_USE_NOTIFY |
+----------------------------+----------+ +---------------------------------+----------+
|deviceDesc:DeviceDescriptor | required | |deviceDesc:DeviceDescriptor | required |
|location:GeoLocation | required | |location:GeoLocation | required |
|spectra:list | required |-------+ |masterDeviceLocation:GeoLocation | optional |
|.......................................| | |spectra:list | required |-------+
|*other:any | depends | | |............................................| |
+----------------------------+----------+ | 0..* |*other:any | | |
V +---------------------------------+----------+ | 0..*
V
+--------------------------------+ +--------------------------------+
|Spectrum | |Spectrum |
+---------------------+----------+ +---------------------+----------+
|bandwidth:float | required | |resolutionBwHz:float | required |
|frequencyRanges:list | required | |profiles:list | required |
+---------------------+----------+ +---------------------+----------+
Parameters: Parameters:
deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is
REQUIRED. REQUIRED.
location: The GeoLocation (Section 5.1) for the Master Device is location: The GeoLocation (Section 5.1) for the Device. When the
REQUIRED. notification is made by a Master Device on its own behalf, the
spectra: The Spectrum (Section 5.10) list is REQUIRED, and specifies location is that of the Master Device and is REQUIRED. When the
notification is made by a Master Device on behalf of a Slave
Device, the location is that of the Slave Device and MAY be
required, depending on regulatory rules.
spectra: The Spectrum (Section 5.11) list is REQUIRED, and specifies
the spectrum anticipated to be used by the Device, which includes the spectrum anticipated to be used by the Device, which includes
frequency ranges and maximum power levels. The list MAY be empty, profiles of frequencies and power levels. The list MAY be empty,
if the Device decides not to use any spectrum. For consistency, if the Device decides not to use any spectrum. For consistency,
the "bandwidth" value SHOULD match that from one of the Spectrum the resolution bandwidth value, "resolutionBwHz" SHOULD match that
(Section 5.10) elements in the corresponding AVAIL_SPECTRUM_RESP from one of the Spectrum (Section 5.11) elements in the
message, and the maximum power levels in the Spectrum element MUST corresponding AVAIL_SPECTRUM_RESP message, and the maximum power
be expressed as total power (EIRP) computed over the specified levels in the Spectrum element MUST be expressed as power over the
"bandwidth" value. The actual bandwidth to be used (as computed specified "resolutionBwHz" value. The actual bandwidth to be used
from the start and stop frequencies) MAY be different from the (as computed from the start and stop frequencies) MAY be different
"bandwidth" value. As an example, when regulatory rules express from the "resolutionBwHz" value. As an example, when regulatory
maximum power spectral density in terms of maximum power over any rules express maximum power spectral density in terms of maximum
100 kHz band, then the "bandwidth" value should be set to 100 kHz, power over any 100 kHz band, then the "resolutionBwHz" value
even though the actual bandwidth used can be 20 kHz. should be set to 100 kHz, even though the actual bandwidth used
can be 20 kHz.
masterDeviceLocation: Depending on regulatory rules, when the
notification is made by the Master Device on behalf of a Slave
Device, the GeoLocation (Section 5.1) for the Master Device MAY be
required.
other: Depending on the regulatory domain, other parameters MAY be other: Depending on the regulatory domain, other parameters MAY be
required. To simplify its logic, the Device MAY include the union required. To simplify its logic, the Device MAY include the union
of all parameters required by all supported regulatory domains. of all parameters required by all supported regulatory domains.
The Database MUST ignore all parameters it does not understand. The Database MUST ignore all parameters it does not understand.
4.4.6. SPECTRUM_USE_RESP 4.4.6. SPECTRUM_USE_RESP
The spectrum-use response message simply acknowledges receipt of the The spectrum-use response message simply acknowledges receipt of the
notification. notification.
+-------------------------------------+ +---------------------------------------+
|SPECTRUM_USE_RESP | |SPECTRUM_USE_RESP |
+--------------------------+----------+ +----------------------------+----------+
+--------------------------+----------+ |databaseChange:DbUpdateSpec | optional |
|.......................................|
|*other:any | |
+----------------------------+----------+
Parameters:
databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) parameter to notify the Device of a change to the
Database URI, providing one or more alternate database URLs. The
Device SHOULD use the information to update its list of
preconfigured databases to replace (only) its entry for the
responding database with the list of alternate URLs.
other: Database implementations MAY return additional parameters in
the response. Consult the PAWS Parameters Registry (Section 9.1)
for possible additional parameters and requirements they place on
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
the Slave Device is permitted to operate. When regulatory rules the Slave Device is permitted to operate. When regulatory rules
allow a Master Device to "cache" the available spectrum for a period allow a Master Device to "cache" the available spectrum for a period
of time, the Master Device MAY use the simpler Device Validation of time, the Master Device MAY use the simpler Device Validation
component, instead of the full Available Spectrum Query component, to component, instead of the full Available Spectrum Query component, to
skipping to change at page 27, line 34 skipping to change at page 28, line 7
|................>| (SPECTRUM_USE_NOTIFY) | |................>| (SPECTRUM_USE_NOTIFY) |
| |-------------------------->| | |-------------------------->|
| | | | | |
| | (SPECTRUM_USE_RESP) | | | (SPECTRUM_USE_RESP) |
| |<--------------------------| | |<--------------------------|
Figure 6 Figure 6
4.5.1. DEV_VALID_REQ 4.5.1. DEV_VALID_REQ
+-------------------------------------+ +---------------------------------------------+
|DEV_VALID_REQ | |DEV_VALID_REQ |
+--------------------------+----------+ +----------------------------------+----------+
|deviceDescs:list | required |---- |deviceDescs:list | required |---+
+--------------------------+----------+ | |masterDeviceDesc:DeviceDescriptor | optional | |
V 1..* +----------------------------------+----------+ |
V 1..*
+----------------------+ +----------------------+
|DeviceDescriptor | |DeviceDescriptor |
+----------------------+ +----------------------+
Parameters: Parameters:
deviceDescs: A DeviceDescriptor (Section 5.2) list is REQUIRED, deviceDescs: A DeviceDescriptor (Section 5.2) list is REQUIRED,
which specifies the list of Slave Devices that to be validated. which specifies the list of Slave Devices that to be validated.
masterDeviceDesc: Depending on regulatory rules, when the request is
made by the Master Device on behalf of a Slave Device, the Master
Device MAY be required to provide its own descriptor.
4.5.2. DEV_VALID_RESP 4.5.2. DEV_VALID_RESP
+---------------------------------------+ +---------------------------------------+
|DEV_VALID_RESP | |DEV_VALID_RESP |
+----------------------------+----------+ +----------------------------+----------+
|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 |
+----------------------------+----------+ +----------------------------+----------+
Parameters: Parameters:
deviceValidities: A DeviceValidities (Section 5.14) 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.8) 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 URIs. The Database URI, providing one or more alternate database URLs. 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 URIs. responding database with the list of alternate URLs.
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 29, line 13 skipping to change at page 29, line 38
where: where:
o A "point" with uncertainty is represented using the Ellipse shape o A "point" with uncertainty is represented using the Ellipse shape
o A region is represented using the Polygon shape o A region is represented using the Polygon shape
The coordinates are expressed using the WGS84 datum [WGS-84], and The coordinates are expressed using the WGS84 datum [WGS-84], and
units are degrees or meters. The parameter MAY also include a units are degrees or meters. The parameter MAY also include a
confidence level, expressed as a percentage. The data model for confidence level, expressed as a percentage. The data model for
GeoLocation is illustrated below: GeoLocation is illustrated below:
+-------------------------------+ +-------------------------------------------------+
|GeoLocation | |GeoLocation |
+------------------+------------+ +------------------+------------------------------+
|point:Ellipse | optional | |point:Ellipse | optional |
|region:Polygon | optional | |region:Polygon | optional |
|confidence:int | depends | |confidence:int | depends on regulatory domain |
+------------------+------------+ +------------------+------------------------------+
Note: point and polygon are mutually exclusive. Note: point and region are mutually exclusive, but one of them must
be present.
+-------------------------------+ +---------------------------------------------------+
|Ellipse | |Ellipse |
+--------------------+----------+ +---------------------------+ +--------------------+------------------------------+
|center:Point | required |--->|Point | |center:Point | required |--+
|semiMajorAxis:float | depends | +----------------+----------+ |semiMajorAxis:float | depends on regulatory domain | |
|semiMinorAxis:float | depends | |latitude:float | required | |semiMinorAxis:float | depends on regulatory domain | |
|orientation:float | optional | |longitude:float | required | |orientation:float | optional | |
+--------------------+----------+ +----------------+----------+ +--------------------+------------------------------+ v
+---------------------------+
|Point |
+----------------+----------+
|latitude:float | required |
|longitude:float | required |
+----------------+----------+
+-------------------------------+ +-------------------------------+
|Polygon | |Polygon |
+-------------------+-----------+ 4..* +---------------------------+ +-------------------+-----------+ 4..* +---------------------------+
|exterior:list | required |------>|Point | |exterior:list | required |------>|Point |
+-------------------+-----------+ +----------------+----------+ +-------------------+-----------+ +----------------+----------+
|latitude:float | required | |latitude:float | required |
|longitude:float | required | |longitude:float | required |
+----------------+----------+ +----------------+----------+
Parameters: Parameters:
point: If present, it indicates that the GeoLocation represents a point: If present, it indicates that the GeoLocation represents a
point. Paradoxically, a "point" is parameterized using an point. Paradoxically, a "point" is parameterized using an
Ellipse, where the center represents the location of the point and Ellipse, where the center represents the location of the point and
the distances along the major and minor axes represent the the distances along the major and minor axes represent the
uncertainty. The uncertainty values MAY be required, depending on uncertainty. The uncertainty values MAY be required, depending on
the regulatory domain. the regulatory domain. Exactly one of "point" or "region" MUST be
present.
region: If present, it indicates that the GeoLocation represents a region: If present, it indicates that the GeoLocation represents a
region. Database support for regions is OPTIONAL. region. Exactly one of "point" or "region" MUST be present.
center: The center refers to the location of a GeoLocation point and center: The center refers to the location of a GeoLocation point and
is represented as the center of an ellipse. REQUIRED. is represented as the center of an ellipse.
latitude, longitude: Floating-point numbers that express the latitude, longitude: Floating-point numbers that express the
latitude and longitude in degrees using the WGS84 datum [WGS-84]. latitude and longitude in degrees using the WGS84 datum [WGS-84].
REQUIRED.
semiMajorAxis, semiMinorAxis: If required by the regulatory domain, semiMajorAxis, semiMinorAxis: If required by the regulatory domain,
the location uncertainty, in meters, is parameterized using the location uncertainty, in meters, is parameterized using
distances along the major and minor axes of the ellipse. When distances along the major and minor axes of the ellipse. When
uncertainty is optional, the default value of each is 0. uncertainty is optional, the default value of each is 0.
orientation: This defines the orientation of the ellipse, expressed orientation: This defines the orientation of the ellipse, expressed
as the rotation, in degrees, of the semi-major axis from North as the rotation, in degrees, of the semi-major axis from North
towards the East. For example, when the uncertainty is greatest towards the East. For example, when the uncertainty is greatest
along the North-South direction, orientation is 0 degrees; along the North-South direction, orientation is 0 degrees;
conversely, if the uncertainty is greatest along the East-West conversely, if the uncertainty is greatest along the East-West
direction, orientation is 90 degrees. When orientation is not direction, orientation is 90 degrees. When orientation is not
present, the orientation SHALL be interpreted as 0. present, the orientation MUST be interpreted as 0.
exterior: When GeoLocation describes a region, the "exterior" field exterior: When GeoLocation describes a region, the "exterior" field
refers to a list of latitude/longitude points that represents the refers to a list of latitude/longitude points that represents the
vertices of a polygon. The first and last points MUST be the vertices of a polygon. The first and last points MUST be the
same. Thus, a minimum of 4 points is required. The following same. Thus, a minimum of 4 points is required. The following
polygon restrictions from [RFC5491] apply: polygon restrictions from [RFC5491] apply:
* A connecting line SHALL NOT cross another connecting line of * A connecting line MUST NOT cross another connecting line of the
the same polygon. same polygon.
* The vertices MUST be defined in a counter-clockwise direction. * The vertices MUST be defined in a counter-clockwise direction.
* The edges of a polygon are defined by the shortest path between * The edges of a polygon are defined by the shortest path between
two points in space (not a geodesic curve). Consequently, the two points in space (not a geodesic curve). Consequently, the
length between two adjacent vertices SHOULD be restricted to a length between two adjacent vertices SHOULD be restricted to a
maximum of 130 km. maximum of 130 km.
* All vertices are assumed to be at the same altitude. * All vertices are assumed to be at the same altitude.
* Polygon shapes SHOULD be restricted to a maximum of 15 vertices * Polygon shapes SHOULD be restricted to a maximum of 15 vertices
(16 points that includes the repeated vertex). (16 points that includes the repeated vertex).
confidence: The location confidence level, as an integer percentage, confidence: The location confidence level, as an integer percentage,
MAY be required, depending on the regulatory domain. When the MAY be required, depending on the regulatory domain. When the
parameter is optional and not provided, its value SHALL be parameter is optional and not provided, its value MUST be
interpreted as 95. Valid values range from 0 to 99, since, in interpreted as 95. Valid values range from 0 to 99, since, in
practice, 100-percent confidence is not achievable. The practice, 100-percent confidence is not achievable. The
confidence value is meaningful only when GeoLocation refers to a confidence value is meaningful only when GeoLocation refers to a
point with uncertainty. point with uncertainty.
5.2. DeviceDescriptor 5.2. DeviceDescriptor
The device descriptor contains parameters that identify the specific The device descriptor contains parameters that identify the specific
device, such as its manufacturer serial number, regulatory-specific device, such as its manufacturer serial number, regulatory-specific
ID (e.g., FCC ID), and any other device characteristics required by ID (e.g., FCC ID), and any other device characteristics required by
skipping to change at page 31, line 15 skipping to change at page 32, line 4
+--------------------------------+ +--------------------------------+
|DeviceDescriptor | |DeviceDescriptor |
+---------------------+----------+ +---------------------+----------+
|serialNumber:string | required | |serialNumber:string | required |
|manufacturerId:string| optional | |manufacturerId:string| optional |
|modelId:string | optional | 1..* |modelId:string | optional | 1..*
|rulesetIds:list | optional |------>string |rulesetIds:list | optional |------>string
|.....................|..........| |.....................|..........|
|*other:any | | |*other:any | |
+---------------------+----------+ +---------------------+----------+
Parameters: Parameters:
serialNumber: The manufacturer's device serial number is REQUIRED. serialNumber: The manufacturer's device serial number is REQUIRED.
The length of the value SHALL NOT exceed 64 characters, conforming The length of the value MUST NOT exceed 64 characters, conforming
to the X.520 [ITUT.X520.2008] recommendations. to the X.520 [ITUT.X520.2008] recommendations.
manufacturerId: The manufacturer's ID may be REQUIRED, depending on manufacturerId: The manufacturer's ID may be REQUIRED, depending on
the regulatory domain. This SHOULD represent the name of the the regulatory domain. This SHOULD represent the name of the
device manufacturer, SHOULD be consistent across all devices from device manufacturer, SHOULD be consistent across all devices from
the same manufacturer, and SHOULD be distinct from that of other the same manufacturer, and SHOULD be distinct from that of other
manufacturers. The string value SHALL NOT exceed 64 characters in manufacturers. The string value MUST NOT exceed 64 characters in
length. length.
modelId: The device's model ID may be REQUIRED, depending on the modelId: The device's model ID may be REQUIRED, depending on the
regulatory domain. The string value SHALL NOT exceed 64 regulatory domain. The string value MUST NOT exceed 64 characters
characters in length. in length.
rulesetIds: The list of identifiers for rule sets supported by the rulesetIds: The list of identifiers for rulesets supported by the
device (see Ruleset ID Registry (Section 9.2)). A Database MAY device (see Ruleset ID Registry (Section 9.2)). A Database MAY
require that the device provides this list before servicing the require that the device provides this list before servicing the
device requests. If the Database does not support any of the rule device requests. If the Database does not support any of the
sets specified in the list, the Database MAY refuse to service the rulesets specified in the list, the Database MAY refuse to service
device requests. See Section 5.7 for discussion on rule-set the device requests. See RulesetInfo (Section 5.6) for discussion
identifier. If present, the list MUST contains at least one on ruleset identifier. If present, the list MUST contain at least
entry. one entry.
other: Depending on the regulatory domain, other parameters may be other: Depending on the regulatory domain, other parameters may be
required. The Database MUST ignore all parameters in the message required. The Database MUST ignore all parameters in the message
it does not understand. See PAWS Parameters Registry it does not understand. See PAWS Parameters Registry
(Section 9.1) for additional valid parameters and for the process (Section 9.1) for additional valid parameters and for the process
for extending the message with more parameters. Additionally, see for extending the message with more parameters. Additionally, see
PAWS Ruleset ID Registry (Section 9.2) for the valid set of PAWS Ruleset ID Registry (Section 9.2) for the valid set of
parameters for each ruleset. parameters for each ruleset.
5.3. AntennaCharacteristics 5.3. AntennaCharacteristics
skipping to change at page 32, line 35 skipping to change at page 33, line 23
heightUncertainty: The height uncertainty in meters. Whether this heightUncertainty: The height uncertainty in meters. Whether this
is required depends on the regulatory domain. is required depends on the regulatory domain.
Depending on the regulatory authority, additional antenna Depending on the regulatory authority, additional antenna
characteristics may be required, such as: characteristics may be required, such as:
o antenna direction o antenna direction
o antenna radiation pattern o antenna radiation pattern
o antenna gain o antenna gain
o antenna polarization o antenna polarization
5.4. FrequencyRange 5.4. DeviceCapabilities
The FrequencyRange parameter specifies the maximum permissible power
levels within a frequency range.
+---------------------------+
|FrequencyRange |
+-----------------+---------+
|startHz:float |required |
|stopHz:float |required |
|maxPowerDBm:float|optional |
|channelId:string |optional |
+-----------------+---------+
Parameters:
startHz: The inclusive start of the frequency range (in Hertz) is
REQUIRED.
stopHz: The exclusive end of the frequency range (in Hertz) is
REQUIRED.
maxPowerDBm: The maximum total power level (EIRP) -- computed over
the corresponding operating bandwidth -- that is permitted within
the frequency range. Depending on the context in which the
FrequencyRange element appears, maxPowerDBm may be REQUIRED. For
example, it is REQUIRED in the AVAIL_SPECTRUM_RESP
(Section 4.4.2), AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4), and
SPECTRUM_USE_NOTIFY (Section 4.4.5) messages, but it SHOULD NOT be
present (it is not applicable) when the FrequencyRange element
appears in Device Capabilities (Section 5.5).
channelId: The server MAY include a channel identifier, when
applicable. When it is included, the Master Device SHOULD treat
it as informative. The length of the identifier SHALL NOT exceed
16.
NOTE: (maxPowerDBm / bandwidth) defines the maximum permitted EIRP
spectral density.
5.5. DeviceCapabilities
Device capabilities provide additional information that MAY be used Device capabilities provide additional information that MAY be used
by the Device to provide additional information to the Database that by the Device to provide additional information to the Database that
may help it to determine available spectrum. If the Database does may help it to determine available spectrum. If the Database does
not support device capabilities it MUST ignore the parameter not support device capabilities it MUST ignore the parameter
altogether. altogether.
+-------------------------------+ +-------------------------------+
|DeviceCapabilities | |DeviceCapabilities |
+---------------------+---------+ +---------------------------+ +---------------------+---------+
|frequencyRanges:list |optional |------>|FrequencyRange | |frequencyRanges:list |optional |--+
+---------------------+---------+ 0..* +-----------------+---------+ +---------------------+---------+ | 0..*
|startHz:float |required | V
|stopHz:float |required | +--------------------------------+
|maxPowerDBm:float|unused | |FrequencyRange |
|channelId:string |optional | +----------------------+---------+
+-----------------+---------+ |startHz:float |required |
|stopHz:float |required |
+----------------------+---------+
Parameters: Parameters:
frequencyRanges: Optional FrequencyRange (Section 5.4) list. Each frequencyRanges: Optional FrequencyRange (Section 5.13) list. Each
FrequencyRange element MUST contain start and stop frequencies, FrequencyRange element MUST contain start and stop frequencies,
and optionally, channel IDs, in which the Device can operate. and optionally, channel IDs, in which the Device can operate.
When specified, the Database SHOULD NOT return available spectrum When specified, the Database SHOULD NOT return available spectrum
that falls outside these ranges (or channel IDs). that falls outside these ranges (or channel IDs).
5.6. DeviceOwner 5.5. DeviceOwner
This parameter contains device-owner information required as part of This parameter contains device-owner information required as part of
device registration. Regulatory domains MAY require additional device registration. Regulatory domains MAY require additional
parameters. parameters.
+-----------------------------+ +-----------------------------+
|DeviceOwner | |DeviceOwner |
+------------------+----------+ +------------------+----------+
|owner:vcard | required | |owner:vcard | required |
|operator:vcard | optional | |operator:vcard | optional |
skipping to change at page 34, line 42 skipping to change at page 34, line 42
fn Full name of an individual fn Full name of an individual
org Name of the organization org Name of the organization
adr Address fields adr Address fields
tel Telephone numbers tel Telephone numbers
email Email addresses email Email addresses
Note that the vCard specification defines maximum lengths for each Note that the vCard specification defines maximum lengths for each
field, conforming to X.520 [ITUT.X520.2008] recommendations. field, conforming to X.520 [ITUT.X520.2008] recommendations.
5.7. RulesetInfo 5.6. RulesetInfo
This contains parameters for the rule set of a regulatory domain that This contains parameters for the ruleset of a regulatory domain that
is communicated using the Initialization component (Section 4.2) and is communicated using the Initialization component (Section 4.2),
Available Spectrum Query (Section 4.4) components. Device Registration (Section 4.3), and Available Spectrum Query
(Section 4.4) components.
+-----------------------------------+ +-----------------------------------+
|RulesetInfo | |RulesetInfo |
+-----------------------------------+ +-----------------------------------+
|authority:string | required | |authority:string | required |
|rulesetId:string | required |
|maxLocationChange:float | optional | |maxLocationChange:float | optional |
|maxPollingSecs:int | optional | |maxPollingSecs:int | optional |
|rulesetIds: list | optional |
|...................................| |...................................|
|*other:any | depends | |*other:any | |
+------------------------+----------+ +------------------------+----------+
Parameters: Parameters:
authority: A string that indicates the regulatory domain to which authority: A string that indicates the regulatory domain to which
the rule set applies is REQUIRED. It MUST be a 2-letter country the ruleset applies is REQUIRED. It MUST be a 2-letter country
code defined by Country Codes - ISO 3166 [ISO3166-1]. The Device code defined by Country Codes - ISO 3166 [ISO3166-1]. The Device
SHOULD use this to determine additional device behavior required SHOULD use this to determine additional device behavior required
by the associated regulatory domain. by the associated regulatory domain.
rulesetId: The ID of a ruleset for the specified authority (see
Ruleset ID Registry (Section 9.2)).
maxLocationChange: The maximum location change in meters is REQUIRED maxLocationChange: The maximum location change in meters is REQUIRED
for Initialization Response (Section 4.2.2), but OPTIONAL for Initialization Response (Section 4.2.2), but OPTIONAL
otherwise. When the Device changes location by more than this otherwise. When the Device changes location by more than this
specified distance, it MUST contact the Database to get the specified distance, it MUST contact the Database to get the
available spectrum for the new location. If the Device is using available spectrum for the new location. If the Device is using
spectrum that is no longer available, it MUST immediately cease spectrum that is no longer available, it MUST immediately cease
use of the spectrum under rules for database-managed spectrum. If use of the spectrum under rules for database-managed spectrum. If
this value is provided within the context of an Available Spectrum this value is provided within the context of an Available Spectrum
Response (Section 4.4.2), it takes precedence over the value Response (Section 4.4.2), it takes precedence over the value
within the Initialization Response. within the Initialization Response.
skipping to change at page 35, line 43 skipping to change at page 35, line 45
for available spectrum is REQUIRED for the Initialization Response for available spectrum is REQUIRED for the Initialization Response
(Section 4.2.2), but OPTIONAL otherwise. The Device MUST contact (Section 4.2.2), but OPTIONAL otherwise. The Device MUST contact
the Database to get available spectrum no less frequently than the Database to get available spectrum no less frequently than
this duration. If the new spectrum information indicates that the this duration. If the new spectrum information indicates that the
Device is using spectrum that is no longer available, it MUST Device is using spectrum that is no longer available, it MUST
immediately cease use of those frequencies under rules for immediately cease use of those frequencies under rules for
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.
rulesetIds: Within the context of the Initialization Response
(Section 4.2.2), the Database SHOULD include the identifier of one
or more applicable rule sets (see Ruleset ID Registry
(Section 9.2)) it supports for the device's location. The Device
MAY use the rule-set identifiers to determine parameters to
include in subsequent requests. Within the context of the
Available Spectrum (Section 4.4.2) responses, the Database SHOULD
include the identifier of the rule set that it used to determine
the available-spectrum response. If included, the Device MUST use
the specified rule set to interpret the response. If the Device
does not support the indicated rule set, it MUST NOT operate in
the spectrum governed by the rule set.
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.8. DbUpdateSpec 5.7. DbUpdateSpec
This message is provided by the Database to notify devices of an This message is provided by the Database to notify devices of an
upcoming change to the Database URL. upcoming change to the Database URL.
+-------------------------------+ +-------------------------------+
|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.9) 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.9. DatabaseSpec 5.8. DatabaseSpec
This message contains the name and URI of a database. This message contains the name and URI of a database.
+--------------------------+ +--------------------------+
|DatabaseSpec | |DatabaseSpec |
+---------------+----------+ +---------------+----------+
|name:string | required | |name:string | required |
|uri:string | required | |uri:string | required |
+---------------+----------+ +---------------+----------+
Parameters: Parameters:
name: The display name for a database. name: The display name for a database.
uri: The corresponding URI of the database. uri: The corresponding URI of the database.
5.10. Spectrum 5.9. SpectrumSpec
Available spectrum can be logically characterized by a list of The SpectrumSpec element encapsulates the schedule of available
frequency ranges and permissible power levels for each range. spectrum for a regulatory domain.
+---------------------------------------+
|SpectrumSpec |
+----------------------------+----------+
|rulesetInfo:RulesetInfo | required |
|spectrumSchedules:list | required |-----+
|timeRange:EventTime | optional | |
|frequencyRanges:list | optional | |
|needsSpectrumReport:boolean | optional | |
|maxTotalBwHz:float | optional | |
|maxContiguousBwHz:float | optional | |
+----------------------------+----------+ |
| 1..*
V
+-------------------------------+
|SpectrumSchedule |
+--------------------+----------+
|eventTime:EventTime | required |
|spectra:list | required |
+--------------------+----------+
Parameters:
rulesetInfo: The RulesetInfo (Section 5.6) is REQUIRED to identify
the regulatory domain and ruleset for which the spectrum schedule
applies (see Ruleset ID Registry (Section 9.2)). The Device MUST
use the corresponding ruleset to interpret the response. Values
provided within this parameter, such as maxLocationChange, take
precedence over the values provided by the Initialization
Procedure (Section 4.2).
spectrumSchedules: The SpectrumSchedule (Section 5.10) list is
REQUIRED. At least one schedule MUST be included. More than one
schedule MAY be included to represent future changes to the
available spectrum. How far in advance a schedule may be provided
depends on the regulatory domain. If more than one schedule is
included, the eventTime intervals MUST be disjoint and SHOULD be
sorted in increasing time. A gap in the time schedule indicates
no available spectrum during that time-interval gap.
timeRange: The time range for which the specification is
comprehensive is OPTIONAL. When specified, any gaps in time
intervals within the "spectrumSchedules" element MUST be
interpreted by the Device as time intervals in which there are no
available spectrum.
frequencyRanges: The frequency ranges for which the specification is
comprehensive is OPTIONAL. It is a list of FrequencyRange
(Section 5.13) entries, and the ranges MUST be disjoint. When
specified, it SHOULD correspond to the frequency ranges governed
by the ruleset. A Device may combine this information with the
available-spectrum specification within the "spectrumSchedules"
element to distinguish between "unavailable spectrum" and
"spectrum for which no information has been provided".
needsSpectrumReport: For regulatory domains that require a spectrum-
usage report from devices, the Database MUST return true for this
parameter if spectrumSchedules list is non-empty; otherwise, the
Database MAY return false or omit this parameter altogether. If
this parameter is present and its value is true, the Device MUST
send a SPECTRUM_USE_NOTIFY (Section 4.4.5) message to the
Database; otherwise, the Device SHOULD NOT send the
SPECTRUM_USE_NOTIFY message.
maxTotalBwHz: The Database MAY return a constraint on the maximum
total bandwidth (in Hertz) allowed, which may or may not be
contiguous. A regulatory domain MAY require the Database to
return this parameter. When present in the response, the Device
MUST apply this constraint to its spectrum-selection logic to
ensure total bandwidth does not exceed this value.
maxContiguousBwHz: The Database MAY return a constraint on the
maximum contiguous bandwidth (in Hertz) allowed. A regulatory
domain MAY require this Database to return this parameter. When
present in the response, the Device MUST apply this constraint to
its spectrum-selection logic to ensure no single block of spectrum
has bandwidth that exceeds this value.
5.10. SpectrumSchedule
The SpectrumSchedule element combines EventTime (Section 5.14) with
Spectrum (Section 5.11) to define a time period in which the spectrum
is valid.
+-------------------------------+
|SpectrumSchedule |
+--------------------+----------+
|eventTime:EventTime | required | +--------------------+
|spectra:list | required |------->|Spectrum |
+--------------------+----------+ 0..* +--------------------+
|resolutionBwHz:float|
|profiles:list |
+--------------------+
Parameters:
eventTime: The EventTime (Section 5.14) is REQUIRED to express
"when" this specification is valid.
spectra: Spectrum (Section 5.11) list is REQUIRED to specify the
available spectrum and permissible power levels, one per
resolutionBwHz. The list MAY be empty when there is no available
spectrum.
5.11. Spectrum
Available spectrum can be characterized by an ordered list of
spectrum profiles that defines permissible power levels over a set of
frequency ranges. Each Spectrum element defines permissible power
levels as maximum power spectral densities over a specified
resolution bandwidth, "resolutionBwHz". Note that the spectrum
profiles represent the "availability mask", as defined by the
governing rule set; they are not intended to encode device-level
transmission-mask requirements.
o To support regulatory rules that define different "wide-band" and
"narrow-band" power levels, PAWS allows multiple Spectrum elements
to be included in the available-spectrum response, each with a
different resolution bandwidth.
o When multiple Spectrum elements are included in the response, they
represent a logical AND condition, such that the Device MUST
satisfy all the conditions.
o Each Spectrum element MUST cover the range of frequencies governed
by a ruleset, rather than splitting the frequencies across
multiple Spectrum elements for the same resolution bandwidth.
o Each spectrum profile represents the maximum permissible power
spectral density over a contiguous range of frequencies.
o When multiple spectrum profiles are included, they MUST be
disjoint and SHOULD be ordered in non-decreasing frequency value.
o Gaps in frequencies between consecutive spectrum profiles
represent unavailability for those frequencies.
The following figure illustrates the Spectrum element and the
SpectrumProfile list.
+-------------------------------+ +-------------------------------+
|Spectrum | |Spectrum |
+---------------------+---------+ +---------------------+---------+
|bandwidth:float |required | +---------------------------+ |resolutionBwHz:float |required |
|frequencyRanges:list |required |------>|FrequencyRange | |profiles:list |required |---+
+---------------------+---------+ 0..* +-----------------+---------+ +---------------------+---------+ | 0..*
|startHz:float |required | V
|stopHz:float |required | +-----------------------------+
|maxPowerDBm:float|optional | |SpectrumProfile |
|channelId:string |optional | +-------------------+---------+
+-----------------+---------+ |list |required |
+-------------------+---------+
|
V 2..*
+------------------------------+
|freqHz:float |required |
|powerDbmPerBw:float |required |
+--------------------+---------+
Parameters: Parameters:
bandwidth: This parameter is REQUIRED to define the operating psdBandwidthHz: This parameter is REQUIRED to define the resolution
bandwidth (in Hertz) for which permissible power levels is to be bandwidth (in Hertz) over which permissible power spectral density
specified. For example, FCC regulation would require only one is defined. For example, FCC regulation would require one
spectrum specification at 6MHz bandwidth, but Ofcom regulation spectrum specification at a bandwidth of 6MHz, and ETSI regulation
would require 2 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.
frequencyRanges: A FrequencyRange (Section 5.4) list is REQUIRED to profiles: A SpectrumProfile (Section 5.12) list is REQUIRED to
specify frequency ranges and permissible power levels. The list specify permissible power levels over a set of frequency ranges.
MAY be empty if there is no available spectrum. The list MAY be empty if there is no available spectrum.
5.11. EventTime Consider the following example with different permitted power
spectral densities for the same set of frequencies over different
resolution bandwidths (for illustrative purposes only):
[
"spectrum": {
"resolutionBwHz": 6e6,
"profiles": [
[
{"freqHz": 5.18e8, "powerDbmPerBw": 30.0},
{"freqHz": 5.24e8, "powerDbmPerBw": 30.0},
],
...
]
},
"spectrum": {
"resolutionBwHz": 1e5,
"profiles": [
[
{"freqHz": 5.18e8, "powerDbmPerBw": 27.0},
{"freqHz": 5.24e8, "powerDbmPerBw": 27.0},
],
...
]
}
]
This is interpreted as:
o Over any 6MHz within the frequency range, [518MHz, 524MHz),
maximum permitted power is 30.0dBm (1000mW), and
o Over any 100 kHz within the frequency range, [518MHz, 524MHz),
maximum permitted power is 27.0dBm (500mW)
This would allow, for example, operating two 100kHz sub-channels
within the indicated 6MHz range at 500mW each, totaling 1000mW. Of
course, many combinations are possible, as long as they satisfy both
conditions.
The following example illustrates multiple spectrum profiles that has
a gap from 530 MHz to 536 MHz:
[
"spectrum": {
"resolutionBwHz": 6e6,
"profiles": [
[
{"freqHz": 5.18e8, "powerDbmPerBw": 30.0},
{"freqHz": 5.24e8, "powerDbmPerBw": 30.0},
{"freqHz": 5.24e8, "powerDbmPerBw": 36.0},
{"freqHz": 5.30e8, "powerDbmPerBw": 36.0},
],
[
{"freqHz": 5.36e8, "powerDbmPerBw": 30.0},
{"freqHz": 5.42e8, "powerDbmPerBw": 30.0},
],
...
]
},
"spectrum": {
"resolutionBwHz": 1e5,
"profiles": [
[
{"freqHz": 5.18e8, "powerDbmPerBw": 27.0},
{"freqHz": 5.24e8, "powerDbmPerBw": 27.0},
{"freqHz": 5.24e8, "powerDbmPerBw": 30.0},
{"freqHz": 5.30e8, "powerDbmPerBw": 30.0},
],
[
{"freqHz": 5.36e8, "powerDbmPerBw": 27.0},
{"freqHz": 5.42e8, "powerDbmPerBw": 27.0},
],
...
]
}
]
5.12. SpectrumProfile
A spectrum profile is characterized by an ordered list of (frequency,
power) points that represents the shape of maximum permissible power
levels over a range of frequencies.
o It MUST contain a minimum of two entries.
o The entries in the list MUST be ordered in non-decreasing
frequency values.
o Two consecutive points MAY have the same frequency value to
represent a "step function".
o Three or more points MAY NOT share the same frequency value.
o The first frequency is inclusive; the last frequency is exclusive.
The following figure defines the SpectrumProfile element.
+-------------------------------+
|SpectrumProfile |
+---------------------+---------+
|list |required |---+
+---------------------+---------+ | 2..*
V
+------------------------------+
|freqHz:float |required |
|powerDbmPerBw:float |required |
+--------------------+---------+
Parameters of each point in the profile:
freqHz: The frequency, in Hertz, at which the power level is
defined.
powerDbmPerBw: The power level, express as dBm per resolution
bandwidth, as defined by the "resolutionBwHz" element of the
enclosing Spectrum (Section 5.11) element.
5.13. FrequencyRange
The FrequencyRange parameter specifies a frequency range.
+--------------------------------+
|FrequencyRange |
+----------------------+---------+
|startHz:float |required |
|stopHz:float |required |
+----------------------+---------+
Parameters:
startHz: The inclusive start of the frequency range (in Hertz) is
REQUIRED.
stopHz: The exclusive end of the frequency range (in Hertz) is
REQUIRED.
5.14. EventTime
The EventTime element specifies the start and stop times of an The EventTime element specifies the start and stop times of an
"event". This is used to indicate the time period for which a "event". This is used to indicate the time period for which a
Spectrum (Section 5.10) is valid. Spectrum (Section 5.11) is valid.
+---------------------------+ +---------------------------+
|EventTime | |EventTime |
+-----------------+---------+ +-----------------+---------+
|startTime:string |required | |startTime:string |required |
|stopTime:string |required | |stopTime:string |required |
+-----------------+---------+ +-----------------+---------+
Parameters: Parameters:
skipping to change at page 38, line 14 skipping to change at page 43, line 39
substitute for the current time (see Available Spectrum Response substitute for the current time (see Available Spectrum Response
(Section 4.4.2) and Available Spectrum Batch Response (Section 4.4.2) and Available Spectrum Batch Response
(Section 4.4.4)). E.g., (Section 4.4.4)). E.g.,
o (startTime - timestamp) gives the duration that a device must wait o (startTime - timestamp) gives the duration that a device must wait
before the event becomes "active". If the value is zero or before the event becomes "active". If the value is zero or
negative, the event is already active. negative, the event is already active.
o If the event is already active, (stopTime - timestamp) is the o If the event is already active, (stopTime - timestamp) is the
duration that the event remains active. If the value is zero or duration that the event remains active. If the value is zero or
negative, the event is no longer active and MUST be ignored. negative, the event is no longer active and MUST be ignored.
5.12. SpectrumSchedule 5.15. GeoSpectrumSpec
The SpectrumSchedule element combines EventTime with Spectrum to
define a time period in which the spectrum is valid.
+-------------------------------+
|SpectrumSchedule |
+--------------------+----------+
|eventTime:EventTime | required | +--------------------+
|spectra:list | required |------->|Spectrum |
+--------------------+----------+ 0..* +--------------------+
|bandwidth:float |
|frequencyRanges:list|
+--------------------+
Parameters:
eventTime: The EventTime (Section 5.11) is REQUIRED to express
"when" this specification is valid.
spectra: Spectrum (Section 5.10) list is REQUIRED to specify the
available spectrum and permissible power levels, one per
bandwidth. The list MAY be empty when there is no available
spectrum.
5.13. GeoSpectrumSchedule
The GeoSpectrumSchedule element encapsulates the schedule of The GeoSpectrumSpec element encapsulates the available spectrum for a
available spectrum at a location. location. It is returned within a AVAIL_SPECTRUM_BATCH_RESP
(Section 4.4.4) batch response that contains one GeoSpectrumSpec
parameter for each location in the request.
+----------------------------------+ +----------------------------------+
|GeoSpectrumSchedule | |GeoSpectrumSpec |
+-----------------------+----------+ +-----------------------+----------+
|location:GeoLocation | required | |location:GeoLocation | required |
|spectrumSchedules:list | required |----------+ |spectrumSpecs:list | required |-------+
+-----------------------+----------+ | +-----------------------+----------+ |
| 0..* | 1..*
V V
+-----------------------------+ +--------------+
|SpectrumSchedule | | SpectrumSpec |
+------------------+----------+ +--------------+
|time:EventTime | required |
|spectrum:Spectrum | required |
+------------------+----------+
Parameters: Parameters:
location: The GeoLocation (Section 5.1) is REQUIRED to identify the location: The GeoLocation (Section 5.1) is REQUIRED to identify the
location at which the spectrum schedule applies. location at which the spectrum schedule applies.
spectrumSchedules: The SpectrumSchedule (Section 5.12) list is spectrumSpecs: The SpectrumSpec (Section 5.9) list is REQUIRED. At
REQUIRED. At least one schedule MUST be included (though it MAY least one entry MUST be included. Each entry represents schedules
be empty if there is no available spectrum). More than one of available spectrum for a regulatory domain. More than one
schedule MAY be included to represent future changes to the entry MAY be included to support multiple regulatory domains at a
available spectrum. location.
5.14. DeviceValidity 5.16. DeviceValidity
The DeviceValidity element is used to indicate whether a device is The DeviceValidity element is used to indicate whether a device is
valid. See Section 4.5.2. valid. See Section 4.5.2.
+---------------------------------------+ +---------------------------------------+
|DeviceValidity | |DeviceValidity |
+----------------------------+----------+ +----------------------------+----------+
|deviceDesc:DeviceDescriptor | required | |deviceDesc:DeviceDescriptor | required |
|isValid:boolean | required | |isValid:boolean | required |
|reason:string | optional | |reason:string | optional |
skipping to change at page 40, line 4 skipping to change at page 44, line 46
|isValid:boolean | required | |isValid:boolean | required |
|reason:string | optional | |reason:string | optional |
+----------------------------+----------+ +----------------------------+----------+
Parameters: Parameters:
deviceDesc: The DeviceDescriptor (Section 5.2) that was used to deviceDesc: The DeviceDescriptor (Section 5.2) that was used to
check for validity is REQUIRED. check for validity is REQUIRED.
isValid: A REQUIRED boolean value that indicates whether the Device isValid: A REQUIRED boolean value that indicates whether the Device
is valid. is valid.
reason: If the device identifier is not valid, the Database MAY reason: If the device identifier is not valid, the Database MAY
include a reason. The reason MAY be in any language. The length include a reason. The reason MAY be in any language. The length
of the value SHALL NOT exceed 128 characters. of the value MUST NOT exceed 128 characters.
5.15. Error Element 5.17. Error Element
If the Database responds to a PAWS request message with an error, it If the Database responds to a PAWS request message with an error, it
MUST include an Error element. MUST include an Error element.
+---------------------------+ +---------------------------+
|Error | |Error |
+----------------+----------+ +----------------+----------+
|code:int | required | |code:int | required |
|message:string | optional | |message:string | optional |
|data:any | optional | |data:any | optional |
+----------------+----------+ +----------------+----------+
Parameters: Parameters:
code: An integer code that indicates the error type. code: An integer code that indicates the error type.
message: A description of the error. It MAY be in any language. message: A description of the error. It MAY be in any language.
The length of the value SHALL NOT exceed 128 characters. The length of the value MUST NOT exceed 128 characters.
data: The Database MAY include additional data. For some errors, data: The Database MAY include additional data. For some errors,
additional data may be required. The Device MUST ignore any data additional data may be required. The Device MUST ignore any data
parameters it does not understand. parameters it does not understand.
The following table defines valid error codes. They are loosely The following table defines valid error codes. They are loosely
grouped into the following categories: grouped into the following categories:
-100s: Indicates compatibility issues, e.g., version mismatch, -100s: Indicates compatibility issues, e.g., version mismatch,
unsupported or unimplemented features. unsupported or unimplemented features.
-200s: Indicates that the Device request contains an error that -200s: Indicates that the Device request contains an error that
needs to be modified before making another request. needs to be modified before making another request.
-300s: Indicates authorization-related issues. -300s: Indicates authorization-related issues.
Code Name Description Code Name Description
---- ---------------- ----------------------------------------------- ---- ---------------- -----------------------------------------------
-100 (reserved) -100 (reserved)
-101 VERSION The Database does not support the specified -101 VERSION The Database does not support the specified
version of the message. version of the message.
-102 UNSUPPORTED The Database does not support the Device. For -102 UNSUPPORTED The Database does not support the Device. For
example, it does not support the regulatory example, it does not support the regulatory
domain specified in the request. domain specified in the request.
-103 UNIMPLEMENTED The Database does not implement the optional -103 UNIMPLEMENTED The Database does not implement the optional
request or optional feature. request or optional feature.
-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 coverage area of the Database. The Database MAY
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.15.1). (Section 5.17.1).
-105 DATABASE_CHANGE The Database has changed its URI. The Database
MAY include a DbUpdateSpec (Section 5.8) -105 DATABASE_CHANGE The Database has changed its URI. The Database
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
URIs. The Device SHOULD use the information to URLs. 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
URIs. See DATABASE_CHANGE Error URLs. See DATABASE_CHANGE Error
(Section 5.15.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.15.3). (Section 5.17.3).
-202 INVALID_VALUE A parameter value is invalid in some way. The -202 INVALID_VALUE A parameter value is invalid in some way. The
Database SHOULD include a message indicating Database SHOULD include a message indicating
which parameter and why its value is invalid. which parameter and why its value is invalid.
-300 (reserved) -300 (reserved)
-301 UNAUTHORIZED The Device is not authorized to used the -301 UNAUTHORIZED The Device is not authorized to used the
Database. Authorization may be determined by Database. Authorization may be determined by
regulatory rules or be dependent on prior regulatory rules or be dependent on prior
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.15.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 list of DatabaseSpec
(Section 5.9) entries that might be appropriate for the requested (Section 5.8) entries that might be appropriate for the requested
location. 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 | |databases:list | optional |
+------------------+----------+ +------------------+----------+
5.15.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.8) 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.
+---------------------------+ +---------------------------+
|Error | |Error |
+----------------+----------+ +----------------+----------+
|code:int | required | |code:int | required |
|message:string | optional | +-----------------------------+ |message:string | optional | +-----------------------------+
|data:ErrorData | optional |--->|ErrorData | |data:ErrorData | optional |--->|ErrorData |
+----------------+----------+ +------------------+----------+ +----------------+----------+ +------------------+----------+
|spec:DbUpdateSpec | required | |spec:DbUpdateSpec | required |
+------------------+----------+ +------------------+----------+
5.15.3. REQUIRED Error 5.17.3. REQUIRED Error
When the error code is REQUIRED, the Database MUST include an When the error code is REQUIRED, the Database MUST include an
ErrorData element within its Error response as the "data" field, and ErrorData element within its Error response as the "data" field, and
the ErrorData element MUST include a list of the missing required the ErrorData element MUST include a list of the missing required
parameters and MAY include the list of all required parameters. parameters and MAY include the list of all required parameters.
+---------------------------+ +---------------------------+
|Error | |Error |
+----------------+----------+ +----------------+----------+
|code:int | required | |code:int | required |
skipping to change at page 44, line 41 skipping to change at page 49, line 18
"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.15). (Section 5.17). The Database SHOULD attempt to use the most specific
applicable PAWS error code. When an accurate one is not available,
it SHOULD fall back to standard JSONRPC error codes as defined in
JSONRPC specification. For example, if the Database receives invalid
JSON from the Device, it should respond with "-32700", signifying a
parse error. As a last resort, the Database MAY send a suitable HTTP
5xx response.
Depending on prior arrangement between a Database and Device, the Depending on prior arrangement between a Database and Device, the
Request and Response objects MAY contain additional parameters. The Request and Response objects MAY contain additional parameters. The
Database or Device MUST ignore all parameters it does not understand. Database or Device MUST ignore all parameters it does not understand.
6.2. init Method 6.2. init Method
This section describes the encoding for the JSON-RPC This section describes the encoding for the JSON-RPC
"spectrum.paws.init" method that represents the Initialization "spectrum.paws.init" method that represents the Initialization
functionality (Section 4.2). functionality (Section 4.2).
6.2.1. INIT_REQ Parameters 6.2.1. INIT_REQ Parameters
The JSON encoding of the Initialization request message INIT_REQ The JSON encoding of the Initialization request message INIT_REQ
(Section 4.2.1) is described by the following schema: (Section 4.2.1) is described by the following schema:
{ {
"name": "INIT_REQ", "name": "INIT_REQ",
"type": "object", "type": "object",
"properties": { "properties": {
"type": "INIT_REQ", "type": "INIT_REQ",
"version": { "version": {
"type": "string", "type": "string",
"required": true "required": true
}, },
"deviceDesc": { "deviceDesc": {
"type": "DeviceDescriptor", "type": "DeviceDescriptor",
"required": true "required": true
}, },
"location": { "location": {
"type": "GeoLocation", "type": "GeoLocation",
"description": "The location SHOULD be the current location " + "description": "The location SHOULD be the current location
"of the Device's antenna. Depending on the regulatory " + of the Device's antenna. Depending on the regulatory
"domain, the location MAY be the anticipated position of " + domain, the location MAY be the anticipated position of
"the Device.", the Device.",
"required": true "required": true
} }
} }
} }
Example "init" JSON-RPC request: Example "init" JSON-RPC request:
{ {
"jsonrpc": "2.0",
"method": "spectrum.paws.init", "method": "spectrum.paws.init",
"params": { "params": {
"type": "INIT_REQ", "type": "INIT_REQ",
"version": "1.0", "version": "1.0",
"deviceDesc": { "deviceDesc": {
"serialNumber": "XXX", "serialNumber": "XXX",
"fccId": "YYY", "fccId": "YYY",
... ...
}, },
"location": { "location": {
"point": { "point": {
"center": {"latitude": 37.0, "longitude": -101.3} "center": {"latitude": 37.0, "longitude": -101.3}
} }
} }
} },
"id": "xxxxxx" "id": "xxxxxx"
} }
6.2.2. INIT_RESP Parameters 6.2.2. INIT_RESP Parameters
The JSON encoding of the Initialization response message INIT_RESP The JSON encoding of the Initialization response message INIT_RESP
(Section 4.2.2) is described by the following schema: (Section 4.2.2) is described by the following schema:
{ {
"name": "INIT_RESP", "name": "INIT_RESP",
"type": "object", "type": "object",
skipping to change at page 46, line 21 skipping to change at page 51, line 19
{ {
"name": "INIT_RESP", "name": "INIT_RESP",
"type": "object", "type": "object",
"properties": { "properties": {
"type": "INIT_RESP", "type": "INIT_RESP",
"version": { "version": {
"type": "string", "type": "string",
"required": true "required": true
}, },
"rulesetInfo": { "rulesetInfos": {
"type": "RulesetInfo", "type": "array",
"description": "Indicates the active regulatory domain and " + "description": "List of regulatory domains and associated
"attributes that define the applicable rule set that " + attributes that govern the device at the location specified
"govern the device", by the device. The list MUST have at least one entry.",
"items": "RulesetInfo",
"required": true "required": true
}, },
"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 "init" JSON-RPC response: Example "init" JSON-RPC response:
{ {
"jsonrpc": "2.0",
"result": { "result": {
"type": "INIT_RESP", "type": "INIT_RESP",
"version": "1.0", "version": "1.0",
"rulesetInfo": { "rulesetInfos": [
{
"authority": "us",
...
},
... ...
} ]
}, },
"id": "xxxxxx" "id": "xxxxxx"
} }
6.3. register Method 6.3. register Method
This section describes the encoding for the JSON-RPC This section describes the encoding for the JSON-RPC
"spectrum.paws.register" method that represents Device Registration "spectrum.paws.register" method that represents Device Registration
functionality (Section 4.3). functionality (Section 4.3).
6.3.1. REGISTRATION_REQ Parameters 6.3.1. REGISTRATION_REQ Parameters
The JSON encoding of the Registration request message The JSON encoding of the Registration request message
REGISTRATION_REQ (Section 4.3.1) is described by the following REGISTRATION_REQ (Section 4.3.1) is described by the following
schema: schema:
{ {
"name": "REGISTRATION_REQ", "name": "REGISTRATION_REQ",
"type": "object", "type": "object",
"properties": { "properties": {
"type": "REGISTRATION_REQ", "type": "REGISTRATION_REQ",
"version": { "version": {
"type": "string", "type": "string",
"required": true "required": true
}, },
"deviceDesc": { "deviceDesc": {
"type": "DeviceDescriptor", "type": "DeviceDescriptor",
"required": true "required": true
}, },
"deviceOwner": { "location": {
"type": "DeviceOwner", "type": "GeoLocation",
"required": true "description": "The location SHOULD be the current location
}, of the Device's antenna. Depending on the regulatory
"location": { domain, the location MAY be the anticipated position of
"type": "GeoLocation", the Device.",
"description": "The location SHOULD be the current location " + "required": true
"of the Device's antenna. Depending on the regulatory " + },
"domain, the location MAY be the anticipated position of " + "deviceOwner": {
"the Device.", "type": "DeviceOwner",
"required": true "required": true
}, },
"antenna": { "antenna": {
"type": "AntennaCharacteristics", "type": "AntennaCharacteristics",
"description": "Antenna characteristics, including its " + "description": "Antenna characteristics, including its
"height and height type", height and height type",
"required": false "required": false
} }
} }
} }
Example "register" JSON-RPC request: Example "register" JSON-RPC request:
{ {
"jsonrpc": "2.0",
"method": "spectrum.paws.register", "method": "spectrum.paws.register",
"params": { "params": {
"type": "REGISTRATION_REQ", "type": "REGISTRATION_REQ",
"version": "1.0", "version": "1.0",
"deviceDesc": { "deviceDesc": {
"serialNumber": "XXX", "serialNumber": "XXX",
"fccId": "YYY", "fccId": "YYY",
... ...
}, },
"deviceOwner": { "deviceOwner": {
"owner": { "owner": [
"fn": "John A. Smith", "vcard", [
"org": { ["version", {}, "text", "4.0"],
"text": "ACME" ["org", {}, "text", "Racafrax, Inc."]
}, ]
"adr": { ],
"street": "1234 A Street", "operator": [
"locality": "San Jose", "vcard", [
"region": "CA", ["version", {}, "text", "4.0"],
"code": "94423", ["fn", {}, "text", "John Frax"],
"country": "US" ["adr", {}, "text",
}, ["", "", "100 Main Street",
"tel": { "Summersville", "CA", "90034", "USA"
"uri": "tel:+1-333-555-1212" ]
}, ],
"email": { ["tel", {}, "uri", "tel:+1-213-555-1212"],
"text": "j.smith@email.com" ["email", {}, "text", "j.frax@rackafrax.com"]
} ]
} ]
}, },
"location": { "location": {
"point": { "point": {
"center": {"latitude": 37.0, "longitude": -101.3} "center": {"latitude": 37.0, "longitude": -101.3}
} }
}, },
"antenna": {"height": 10.2, "heightType": "AGL"} "antenna": {"height": 10.2, "heightType": "AGL"}
}, },
"id": "xxxxxx" "id": "xxxxxx"
} }
skipping to change at page 49, line 14 skipping to change at page 54, line 14
{ {
"name": "REGISTRATION_RESP", "name": "REGISTRATION_RESP",
"type": "object", "type": "object",
"properties": { "properties": {
"type": "REGISTRATION_RESP", "type": "REGISTRATION_RESP",
"version": { "version": {
"type": "string", "type": "string",
"required": true "required": true
}, },
"rulesetInfos": {
"type": "array",
"description": "List of regulatory domains for which device
registration was successful. The list MUST have at
least one entry.",
"items": "RulesetInfo",
"required": true
},
"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 "register" JSON-RPC response: Example "register" JSON-RPC response:
{ {
"jsonrpc": "2.0",
"result": { "result": {
"type": "REGISTRATION_RESP", "type": "REGISTRATION_RESP",
"version": "1.0" "version": "1.0"
"rulesetInfos": [
{
"authority": "us",
...
}
]
}, },
"id": "xxxxxx" "id": "xxxxxx"
} }
6.4. getSpectrum Method 6.4. getSpectrum Method
This section describes the encoding for the JSON-RPC This section describes the encoding for the JSON-RPC
"spectrum.paws.getSpectrum" method that represents the single- "spectrum.paws.getSpectrum" method that represents the single-
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 from the Database. spectrum from the Database.
6.4.1. AVAIL_SPECTRUM_REQ Parameters 6.4.1. AVAIL_SPECTRUM_REQ Parameters
The JSON encoding of the Available Spectrum request message The JSON encoding of the Available Spectrum request message
AVAIL_SPECTRUM_REQ (Section 4.4.1) is described by the following AVAIL_SPECTRUM_REQ (Section 4.4.1) is described by the following
schema: schema:
{ {
"name": "AVAIL_SPECTRUM_REQ", "name": "AVAIL_SPECTRUM_REQ",
"type": "object", "type": "object",
"properties": { "properties": {
"type": "AVAIL_SPECTRUM_REQ", "type": "AVAIL_SPECTRUM_REQ",
"version": { "version": {
"type": "string", "type": "string",
"required": true "required": true
}, },
"deviceDesc": { "deviceDesc": {
"type": "DeviceDescriptor", "type": "DeviceDescriptor",
"description": "Descriptor of the device for which to " + "description": "Descriptor of the device for which to
"determine available spectrum.", determine available spectrum.",
"required":false "required": false
}, },
"location": { "location": {
"type": "GeoLocation", "type": "GeoLocation",
"description": "The location SHOULD be the current location " + "description": "The location SHOULD be the current location
"of the Device's antenna. Depending on the regulatory " + of the Device's antenna. Depending on the regulatory
"domain, the location MAY be the anticipated position of " + domain, the location MAY be the anticipated position of
"the Device.", the Device. When request is made by a Master Device on
"required": false behalf of a Slave Device, this is the location of the
}, Slave Device.",
"antenna": { "required": false
"type": "AntennaCharacteristics", },
"description": "Antenna characteristics, including its " + "owner": {
"height and height type. May required depending on " + "type": "DeviceOwner",
"device type and regulatory domain", "description": "May be required if the Device is not yet
"required":false registered or if the DB does not implement a separate
}, device-registration request. Also depends on device type
"owner": { and regulatory domain",
"type": "DeviceOwner", "required": false
"description": "May be required if the Device is not yet " + },
"registered or if the DB does not implement a separate " + "antenna": {
"device-registration request. Also depends on device type " + "type": "AntennaCharacteristics",
"and regulatory domain", "description": "Antenna characteristics, including its
"required": false height and height type. May required depending on
}, device type and regulatory domain",
"capabilities": { "required": false
"type": "DeviceCapabilities",
"description": "The Database SHOULD NOT return spectrum that " + },
"is incompatible with the specified capabilities.", "capabilities": {
"required": false "type": "DeviceCapabilities",
}, "description": "The Database SHOULD NOT return spectrum that
"masterDeviceDesc": { is incompatible with the specified capabilities.",
"type": "DeviceDescriptor", "required": false
"description": "When the request is make by a Master Device " + },
"on behalf of a Slave Device, this is the descriptor of " + "masterDeviceDesc": {
"the Master Device.", "type": "DeviceDescriptor",
"required":true "description": "When the request is made by a Master Device
}, on behalf of a Slave Device, this is the descriptor of
"requestType": { the Master Device.",
"type": "string", "required": false
"description": "Optional value that modifies the request. " + },
"Valid values depends on regulatory domain.", "masterDeviceLocation": {
"required": false "type": "GeoLocation",
"description": "When the request is made by a Master Device
on behalf of a Slave Device, this is the location of
the Master Device.",
"required": false
},
"requestType": {
"type": "string",
"description": "Optional value that modifies the request.
Valid values depends on regulatory domain.",
"required": false
}
} }
} }
}
Example "getSpectrum" JSON-RPC request: Example "getSpectrum" JSON-RPC request:
{ {
"jsonrpc": "2.0",
"method": "spectrum.paws.getSpectrum", "method": "spectrum.paws.getSpectrum",
"params": { "params": {
"type": "AVAIL_SPECTRUM_REQ", "type": "AVAIL_SPECTRUM_REQ",
"version": "1.0", "version": "1.0",
"deviceDesc": { "deviceDesc": {
"serialNumber": "XXX", "serialNumber": "XXX",
"fccId": "YYY", "fccId": "YYY",
... ...
}, },
"location": { "location": {
"point": { "point": {
"center": {"latitude": 37.0, "longitude": -101.3} "center": {"latitude": 37.0, "longitude": -101.3}
} }
}, },
"antenna": {"height": 10.2, "heightType": "AGL"} "antenna": {"height": 10.2, "heightType": "AGL"}
} },
"id": "xxxxxx", "id": "xxxxxx"
} }
6.4.2. AVAIL_SPECTRUM_RESP Parameters 6.4.2. AVAIL_SPECTRUM_RESP Parameters
The JSON encoding of the Available Spectrum response message The JSON encoding of the Available Spectrum response message
AVAIL_SPECTRUM_RESP (Section 4.4.2) is described by the following AVAIL_SPECTRUM_RESP (Section 4.4.2) is described by the following
schema: schema:
{ {
"name": "AVAIL_SPECTRUM_RESP", "name": "AVAIL_SPECTRUM_RESP",
"type": "object", "type": "object",
"properties": { "properties": {
"type": "AVAIL_SPECTRUM_RESP", "type": "AVAIL_SPECTRUM_RESP",
"version": { "version": {
"type": "string", "type": "string",
"required": true "required": true
}, },
"timestamp": { "timestamp": {
"type": "string", "type": "string",
"description": "Timestamp of the response, using " + "description": "Timestamp of the response, using
"YYYY-MM-DDThh:mm:ssZ RFC3339 format. This SHOULD be used " + YYYY-MM-DDThh:mm:ssZ RFC3339 format. This SHOULD be used
"by the Device as a reference for the start and stop times " + by the Device as a reference for the start and stop times
"in the spectrum schedule", in the spectrum schedule",
"format": "date-time", "format": "date-time",
"required": true "required": true
}, },
"deviceDesc": { "deviceDesc": {
"type": "DeviceDescriptor", "type": "DeviceDescriptor",
"required": true "required": true
}, },
"spectrumSchedules": { "spectrumSpecs": {
"type": "array", "type": "array",
"description": "The Database MAY return more than one " + "description": "The Database MAY return more than one
"schedule to represent future changes to the available " + SpectrumSpec to represent available spectrum for multiple
"spectrum. This array MAY be empty if no spectrum is " + regulatory domains at the specified location.",
"is available.", "items": "SpectrumSpec",
"items": "SpectrumSchedule", "required": true
"required": true },
}, "databaseChange": {
"needsSpectrumReport": { "type": "DbUpdateSpec",
"type": "boolean", "description": "Indicates that the Database URI will be
"description": "For regulatory domains that require a " + changing. Devices need to update their configurations",
"spectrum-usage report from devices, the Database MUST " + "required": false
"return true for this parameter.", }
"default": false, }
"required": false }
},
"maxTotalBwHz": {
"type": "number",
"description": "Constraint on total bandwidth allowed, " +
"summed across all blocks of spectrum.",
"required": false
},
"maxContiguousBwHz": {
"type": "number",
"description": "Constraint on bandwidth allowed for " +
"any single block of spectrum.",
"required": false
},
"rulesetInfo": {
"type": "RulesetInfo",
"description": "Indicates the active regulatory domain and " +
"attributes that define the applicable rule set that " +
"govern the device",
"required": false
},
"databaseChange": {
"type": "DbUpdateSpec",
"description": "Indicates that the Database URI will be " +
"changing. Devices need to update their configurations",
"required": false
}
}
}
Example "getSpectrum" JSON-RPC response: Example "getSpectrum" JSON-RPC response:
{ {
"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",
... ...
}, },
"spectrumSchedules": [ "spectrumSpecs": [
{ {
"eventTime": { "rulesetInfo": {
"startTime": "2013-03-02T14:30:21Z", "authority": "us",
"stopTime": "2013-03-02T20:00:00Z", ...
}, },
"spectra": [ "needsSpectrumReport": false,
{ "spectrumSchedules": [
"bandwidth": 6e6, {
"frequencyRanges": [ "eventTime": {
{"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":30.0}, "startTime": "2013-03-02T14:30:21Z",
{"startHz":5.36e8, "stopHz":5.42e8, "maxPowerDBm":36.0}, "stopTime": "2013-03-02T20:00:00Z",
...
]
}, },
{ "spectra": [
"bandwidth": 1e5, {
"frequencyRanges": [ "resolutionBwHz": 6e6,
{"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":27.0}, "profiles": [
{"startHz":5.36e8, "stopHz":5.42e8, "maxPowerDBm":33.0}, ...
... [
] {"freqHz":5.18e8, "powerDbmPerBw":30.0},
} {"freqHz":5.36e8, "powerDbmPerBw":30.0},
] {"freqHz":5.36e8, "powerDbmPerBw":36.0},
}, {"freqHz":5.42e8, "powerDbmPerBw":36.0}
{ ],
"eventTime": { [
"startTime": "2013-03-02T22:00:00Z", {"freqHz":6.20e8, "powerDbmPerBw":30.0},
"stopTime": "2013-03-03T14:30:21Z", {"freqHz":6.26e8, "powerDbmPerBw":30.0},
}, ],
"spectra": [ ...
... ]
] },
{
"resolutionBwHz": 1e5,
"profiles": [
...
[
{"freqHz":5.18e8, "powerDbmPerBw":27.0},
{"freqHz":5.36e8, "powerDbmPerBw":27.0},
{"freqHz":5.36e8, "powerDbmPerBw":30.0},
{"freqHz":5.42e8, "powerDbmPerBw":30.0}
],
[
{"freqHz":6.20e8, "powerDbmPerBw":27.0},
{"freqHz":6.26e8, "powerDbmPerBw":27.0},
],
...
]
}
]
},
{
"eventTime": {
"startTime": "2013-03-02T22:00:00Z",
"stopTime": "2013-03-03T14:30:21Z",
},
"spectra": [
...
]
}
],
} }
], ]
"needsSpectrumReport": false
}, },
"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,", "owner": {
"items": "GeoLocation", "type": "DeviceOwner",
"required": true "description": "May be required if the Device is not yet
}, registered or if the DB does not implement a separate
"antenna": { device-registration request. Also depends on device type
"type": "AntennaCharacteristics", and regulatory domain",
"description": "Antenna characteristics, including its " + "required": false
"height and height type. May required depending on " + },
"device type and regulatory domain","AntennaCharacteristics", "antenna": {
"required": false "type": "AntennaCharacteristics",
}, "description": "Antenna characteristics, including its
"owner": { height and height type. May required depending on
"type": "DeviceOwner", device type and regulatory domain","AntennaCharacteristics",
"description": "May be required if the Device is not yet " + "required": false
"registered or if the DB does not implement a separate " + },
"device-registration request. Also depends on device type " + "capabilities": {
"and regulatory domain", "type": "DeviceCapabilities",
"required": false "description": "The Database SHOULD NOT return spectrum that
}, is incompatible with the specified capabilities.",
"capabilities": { "required": false
"type": "DeviceCapabilities", },
"description": "The Database SHOULD NOT return spectrum that " + "masterDeviceDesc": {
"is incompatible with the specified capabilities.", "type": "DeviceDescriptor",
"required": false "description": "When the request is made by a Master Device
}, on behalf of a Slave Device, this is the descriptor of
"masterDeviceDesc": { the Master Device.",
"type": "DeviceDescriptor", "required": false
"description": "When the request is make by a Master Device " + },
"on behalf of a Slave Device, this is the descriptor of " + "masterDeviceLocation": {
"the Master Device.", "type": "GeoLocation",
"required":true "description": "When the request is made by a Master Device
}, on behalf of a Slave Device, this is the location of
"requestType": { the Master Device.",
"type": "string", "required": false
"description": "Optional value that modifies the request. " + },
"Valid values depends on regulatory domain.", "requestType": {
"required": false "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",
"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": {
"serialNumber": "XXX", "serialNumber": "XXX",
"fccId": "YYY", "fccId": "YYY",
... ...
}, },
"locations": [ "locations": [
skipping to change at page 56, line 29 skipping to change at page 62, line 40
} }
}, },
{ {
"point": { "point": {
"center": {"latitude": 37.0005, "longitude": -101.3005} "center": {"latitude": 37.0005, "longitude": -101.3005}
} }
}, },
... ...
], ],
"antenna": {"height": 10.2, "heightType": "AGL"} "antenna": {"height": 10.2, "heightType": "AGL"}
} },
"id": "xxxxxx", "id": "xxxxxx"
} }
6.5.2. AVAIL_SPECTRUM_BATCH_RESP Parameters 6.5.2. AVAIL_SPECTRUM_BATCH_RESP Parameters
The JSON encoding of the Batch Available Spectrum response The JSON encoding of the Batch Available Spectrum response
AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4) is described by the AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4) is described by the
following schema: following schema:
{ {
"name": "AVAIL_SPECTRUM_BATCH_RESP", "name": "AVAIL_SPECTRUM_BATCH_RESP",
"type": "object", "type": "object",
"properties": { "properties": {
"type": "AVAIL_SPECTRUM_BATCH_RESP", "type": "AVAIL_SPECTRUM_BATCH_RESP",
"version": { "version": {
"type": "string", "type": "string",
"required": true "required": true
}, },
"timestamp": { "timestamp": {
"type": "string", "type": "string",
"description": "Timestamp of the response, using " + "description": "Timestamp of the response, using
"YYYY-MM-DDThh:mm:ssZ RFC3339 format. This SHOULD be used " + YYYY-MM-DDThh:mm:ssZ RFC3339 format. This SHOULD be used
"by the Device as a reference for the start and stop times " + by the Device as a reference for the start and stop times
"in the spectrum schedule", in the spectrum schedule",
"format": "date-time", "format": "date-time",
"required": true "required": true
}, },
"deviceDesc": { "deviceDesc": {
"type": "DeviceDescriptor", "type": "DeviceDescriptor",
"required": true "required": true
}, },
"geoSpectrumSchedules": { "geoSpectrumSpecs": {
"type": "array", "type": "array",
"description": "For each location, the Database MAY return " + "description": "A list of locations and available spectrum at
"more than one schedule to represent future changes " + each location. For each location, there may be more than
"to the available spectrum. This array MAY be empty if " + one SpectrumSpec element to support more than one ruleset
"there is no available spectrum.", at that location.",
"items": "GeoSpectrumSchedule", "items": "GeoSpectrumSpec",
"required": true "required": true
}, },
"needsSpectrumReport": { "databaseChange": {
"type": "boolean", "type": "DbUpdateSpec",
"description": "For regulatory domains that require a " + "description": "Indicates that the Database URI will be
"spectrum-usage report from devices, the Database MUST " + changing. Devices need to update their configurations",
"return true for this parameter.", "required": false
"default": false, }
"required": false }
}, }
"maxTotalBwHz": {
"type": "number",
"description": "Constraint on total bandwidth allowed, " +
"summed across all blocks of spectrum.",
"required": false
},
"maxContiguousBwHz": {
"type": "number",
"description": "Constraint on bandwidth allowed for " +
"any single block of spectrum.",
"required": false
},
"rulesetInfo": {
"type": "RulesetInfo",
"description": "Indicates the active regulatory domain and " +
"attributes that define the applicable rule set that " +
"govern the device",
"required": false
},
"databaseChange": {
"type": "DbUpdateSpec",
"description": "Indicates that the Database URI will be " +
"changing. Devices need to update their configurations",
"required": false
}
}
}
Example "getSpectrumBatch" JSON-RPC response: Example "getSpectrumBatch" JSON-RPC response:
{ {
"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",
... ...
}, },
"geoSpectrumSchedules": [ "geoSpectrumSpecs": [
{ {
"location": { "location": {
"point": { "point": {
"center": {"latitude": 37.0, "longitude": -101.3} "center": {"latitude": 37.0, "longitude": -101.3}
} }
}, },
"spectrumSchedules": [ "spectrumSpecs": [
{ {
"eventTime": { "rulesetInfo": {
"startTime": "2013-03-02T14:30:21Z", "authority": "us",
"stopTime": "2013-03-02T20:00:00Z", ...
}, },
"spectra": [ "needsSpectrumReport": false,
{ "spectrumSchedules": [
"bandwidth": 6e6, {
"frequencyRanges": [ "eventTime": {
{"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":30.0}, "startTime": "2013-03-02T14:30:21Z",
{"startHz":5.36e8, "stopHz":5.42e8, "maxPowerDBm":36.0}, "stopTime": "2013-03-02T20:00:00Z",
...
]
}, },
{ "spectra": [
"bandwidth": 1e5, {
"frequencyRanges": [ "resolutionBwHz": 6e6,
{"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":27.0}, "profiles": [
{"startHz":5.36e8, "stopHz":5.42e8, "maxPowerDBm":33.0}, ...
... [
] {"freqHz":5.18e8, "powerDbmPerBw":30.0},
{"freqHz":5.36e8, "powerDbmPerBw":30.0},
{"freqHz":5.36e8, "powerDbmPerBw":36.0},
{"freqHz":5.42e8, "powerDbmPerBw":36.0}
],
[
{"freqHz":6.20e8, "powerDbmPerBw":30.0},
{"freqHz":6.26e8, "powerDbmPerBw":30.0},
],
...
]
},
{
"resolutionBwHz": 1e5,
"profiles": [
...
[
{"freqHz":5.18e8, "powerDbmPerBw":27.0},
{"freqHz":5.36e8, "powerDbmPerBw":27.0},
{"freqHz":5.36e8, "powerDbmPerBw":30.0},
{"freqHz":5.42e8, "powerDbmPerBw":30.0}
],
[
{"freqHz":6.20e8, "powerDbmPerBw":27.0},
{"freqHz":6.26e8, "powerDbmPerBw":27.0},
],
...
]
},
]
},
{
"eventTime": {
"startTime": "2013-03-02T22:00:00Z",
"stopTime": "2013-03-03T14:30:21Z",
}, },
] "spectra": [
...
}, ]
{ }
"eventTime": { ],
"startTime": "2013-03-02T22:00:00Z",
"stopTime": "2013-03-03T14:30:21Z",
},
"spectra": [
...
]
} }
], ]
}, },
{ {
"location": { "location": {
"point": { "point": {
"center": {"latitude": 37.0005, "longitude": -101.3005} "center": {"latitude": 37.0005, "longitude": -101.3005}
} }
}, },
"spectrumSchedules": [ "spectrumSpecs": [
... ...
] ]
} }
], ],
"needsSpectrumReport": false
}, },
"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 Available Spectrum Query functionality Spectrum-usage notification of the Available Spectrum Query
(Section 4.4.5) for notifying the Database of anticipated spectrum functionality (Section 4.4.5) that notifies the Database of
usage. anticipated spectrum usage.
6.6.1. SPECTRUM_USE_NOTIFY Parameters 6.6.1. SPECTRUM_USE_NOTIFY Parameters
The JSON encoding of the Spectrum Notification message The JSON encoding of the Spectrum Notification message
SPECTRUM_USE_NOTIFY (Section 4.4.5) is described by the following SPECTRUM_USE_NOTIFY (Section 4.4.5) is described by the following
schema: schema:
{ {
"name": "SPECTRUM_USE_NOTIFY", "name": "SPECTRUM_USE_NOTIFY",
"type": "object", "type": "object",
skipping to change at page 60, line 20 skipping to change at page 66, line 27
"version": { "version": {
"type": "string", "type": "string",
"required": true "required": true
}, },
"deviceDesc": { "deviceDesc": {
"type": "DeviceDescriptor", "type": "DeviceDescriptor",
"required": true "required": true
}, },
"location": { "location": {
"type": "GeoLocation", "type": "GeoLocation",
"required": true "description": "The location of the Device. When the
notification is made by a Master Device on behalf
of a Slave Device, this is the location of the
Slave Device."
"required": false
},
"masterDeviceLocation": {
"type": "GeoLocation",
"description": "When the notification is made by the
Master Device on behalf of a Slave Device, this is
the location of the Master Device."
"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
} }
} }
} }
Example "notifySpectrumUse" JSON-RPC notification: Example "notifySpectrumUse" JSON-RPC notification:
{ {
"jsonrpc": "2.0",
"method": "spectrum.paws.notifySpectrumUse", "method": "spectrum.paws.notifySpectrumUse",
"params": { "params": {
"type": "SPECTRUM_USE_NOTIFY", "type": "SPECTRUM_USE_NOTIFY",
"version": "1.0", "version": "1.0",
"deviceDesc": { "deviceDesc": {
"serialNumber": "XXX", "serialNumber": "XXX",
"fccId": "YYY", "fccId": "YYY",
... ...
}, },
"location": { "location": {
"point": { "point": {
"center": {"latitude": 37.0005, "longitude": -101.3005} "center": {"latitude": 37.0005, "longitude": -101.3005}
} }
}, },
"spectra": [ "spectra": [
{ {
"bandwidth": 6e6, "resolutionBwHz": 6e6,
"frequencyRanges": [ "profiles": [
{"startHz":5.18e8, "stopHz":5.24e8, "maxPowerDBm":30.0} [
{"freqHz":5.18e8, "powerDbmPerBw":30.0},
{"freqHz":5.24e8, "powerDbmPerBw":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
skipping to change at page 61, line 48 skipping to change at page 68, line 4
"name": "SPECTRUM_USE_RESP", "name": "SPECTRUM_USE_RESP",
"type": "object", "type": "object",
"properties": { "properties": {
"type": "SPECTRUM_USE_RESP", "type": "SPECTRUM_USE_RESP",
"version": { "version": {
"type": "string", "type": "string",
"required": true "required": true
} }
} }
} }
Example "notifySpectrumUse" JSON-RPC response: Example "notifySpectrumUse" JSON-RPC response:
{ {
"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 63, line 6 skipping to change at page 69, line 6
"description": "List of Slave Devices to be validated", "description": "List of Slave Devices to be validated",
"items": "DeviceDescriptor", "items": "DeviceDescriptor",
"required": true "required": true
} }
} }
} }
Example "verifyDevice" JSON-RPC request: Example "verifyDevice" JSON-RPC request:
{ {
"jsonrpc": "2.0",
"method": "spectrum.paws.verifyDevice", "method": "spectrum.paws.verifyDevice",
"params": { "params": {
"type": "DEV_VALID_REQ", "type": "DEV_VALID_REQ",
"version": "1.0", "version": "1.0",
"deviceDescs": [ "deviceDescs": [
{ {
"serialNumber": "XXX", "serialNumber": "XXX",
"fccId": "YYY", "fccId": "YYY",
... ...
}, },
skipping to change at page 64, line 5 skipping to change at page 70, line 5
] ]
}, },
"id": "xxxxxx" "id": "xxxxxx"
} }
6.7.2. DEV_VALID_RESP Parameters 6.7.2. DEV_VALID_RESP Parameters
The JSON encoding of the Device Validation response DEV_VALID_RESP The JSON encoding of the Device Validation response DEV_VALID_RESP
(Section 4.5.2) is described by the following schema: (Section 4.5.2) is described by the following schema:
{ {
"name": "DEV_VALID_RESP", "name": "DEV_VALID_RESP",
"type": "object", "type": "object",
"properties": { "properties": {
"type": "DEV_VALID_RESP", "type": "DEV_VALID_RESP",
"version": { "version": {
"type": "string", "type": "string",
"required": true "required": true
}, },
"deviceValidities": { "deviceValidities": {
"type": "array", "type": "array",
"description": "List of DeviceValidity objects that shows the " + "description": "List of DeviceValidity objects that shows the
"validity of each device included in the original Device " + validity of each device included in the original Device
"Validity Request message.", Validity Request message.",
"items": "DeviceValidity", "items": "DeviceValidity",
"required": true "required": true
}, },
"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 "verifyDevice" JSON-RPC response: Example "verifyDevice" JSON-RPC response:
{ {
"jsonrpc": "2.0",
"result": { "result": {
"type": "DEV_VALID_RESP", "type": "DEV_VALID_RESP",
"version": "1.0", "version": "1.0",
"deviceValidities": [ "deviceValidities": [
{ {
"deviceDesc": { "deviceDesc": {
"serialNumber": "XXX", "serialNumber": "XXX",
"fccId": "YYY", "fccId": "YYY",
... ...
}, },
skipping to change at page 65, line 49 skipping to change at page 71, line 50
This parameter is used to specify the GeoLocation (Section 5.1) of This parameter is used to specify the GeoLocation (Section 5.1) of
the Device. The geometric shapes represent the JSON encoding shapes the Device. The geometric shapes represent the JSON encoding shapes
defined in GEOPRIV Presence Information Data Format Location Object defined in GEOPRIV Presence Information Data Format Location Object
[RFC5491]. [RFC5491].
{ {
"name": "GeoLocation", "name": "GeoLocation",
"type": "object", "type": "object",
"properties": { "properties": {
"point": { "point": {
"description": "A single location, with optional " + "description": "A single location, with optional
"uncertainty measures", uncertainty measures. Exactly one of 'point' or 'region'
must be present.",
"type": "Ellipse", "type": "Ellipse",
"required": false "required": false
}, },
"region": { "region": {
"description": "A region described by a polygon", "description": "A region described by a polygon. Exactly
one of 'point' or 'region' must be present.",
"type": "Polygon", "type": "Polygon",
"required": false "required": false
}, },
"confidence": { "confidence": {
"description": "Confidence interval when location " + "description": "Confidence interval when location
"is a point with uncertainty. 0 to 100.", is a point with uncertainty. 0 to 100.",
"type": "integer", "type": "integer",
"required": false, "required": false,
"default": 95 "default": 95
} }
} }
} }
{ {
"name": "Point", "name": "Point",
"type": "object", "type": "object",
"properties": { "properties": {
"latitude": { "latitude": {
"description": "Double-precision floating-point degrees. " + "description": "Double-precision floating-point degrees.
"WGS84 datum.", WGS84 datum.",
"type": "number", "type": "number",
"required": true "required": true
}, },
"longitude": { "longitude": {
"type": "number", "type": "number",
"description": "Double-precision floating-point degree. " + "description": "Double-precision floating-point degree.
"WGS84 datum.", WGS84 datum.",
"required": true "required": true
} }
} }
} }
{ {
"name": "Ellipse", "name": "Ellipse",
"type": "object", "type": "object",
"properties": { "properties": {
"center": { "center": {
"type": "Point", "type": "Point",
"required": true "required": true
}, },
"semiMajorAxis": { "semiMajorAxis": {
"description": "Floating-point meters that describe " + "description": "Floating-point meters that describe
"location uncertainty along the major axis of " + location uncertainty along the major axis of
"the ellipse.", the ellipse.",
"type": "number", "type": "number",
"required": false, "required": false,
"default": 0 "default": 0
}, },
"semiMinorAxis": { "semiMinorAxis": {
"description": "Floating-point meters that describe " + "description": "Floating-point meters that describe
"location uncertainty along the minor axis of " + location uncertainty along the minor axis of
"the ellipse.", the ellipse.",
"type": "number", "type": "number",
"required": false, "required": false,
"default": 0 "default": 0
}, },
"orientation": { "orientation": {
"description": "Orientation of the ellipse, as rotation " + "description": "Orientation of the ellipse, as rotation
"of the major axis from North towards East. Degrees.", of the major axis from North towards East. Degrees.",
"type": "number", "type": "number",
"required": false, "required": false,
"default": 0 "default": 0
} }
} }
} }
{ {
"name": "Polygon", "name": "Polygon",
"type": "object", "type": "object",
"properties": { "properties": {
"exterior": { "exterior": {
"description": "List of Points in counter-clockwise " + "description": "List of Points in counter-clockwise
"order. They MUST form a loop with no edges that " + order. They MUST form a loop with no edges that
"cross each other. First and last points MUST be " + cross each other. First and last points MUST be
"the same. Minimum of 4 points.", the same. Minimum of 4 points.",
"type": "array", "type": "array",
"items": "Point", "items": "Point",
"required": true "required": true
} }
} }
} }
6.8.2. DeviceDescriptor 6.8.2. DeviceDescriptor
The DeviceDescriptor (Section 5.2) contains parameters that identify The DeviceDescriptor (Section 5.2) contains parameters that identify
the specific device, such as its manufacturer serial number, the specific device, such as its manufacturer serial number,
regulatory-specific ID (e.g., FCC ID), and any other device regulatory-specific ID (e.g., FCC ID), and any other device
characteristics required by regulatory domains, such as device-type characteristics required by regulatory domains, such as device-type
classification. See Initial PAWS Parameters Registry Contents classification. See Initial PAWS Parameters Registry Contents
(Section 9.1.2) for additional valid parameters, e.g., "fccId", (Section 9.1.2) for additional valid parameters, e.g., "fccId",
"etsiEnDeviceType", etc. "etsiEnDeviceType", etc.
{ {
"name": "DeviceDescriptor", "name": "DeviceDescriptor",
"type": "object", "type": "object",
"properties": { "properties": {
"serialNumber": { "serialNumber": {
"type": "string", "type": "string",
"required": true "required": true
}, },
"manufacturerId": { "manufacturerId": {
"type": "string", "type": "string",
"required": false "required": false
}, },
"modelId": { "modelId": {
"type": "string", "type": "string",
"required": false "required": false
}, },
"rulesetIds": { "rulesetIds": {
"type": "array", "type": "array",
"description": "List of identifiers for rule sets supported " + "description": "List of identifiers for rulesets supported
"by the device", by the device",
"items": "string", "items": "string",
"required": false "required": false
}
} }
} }
}
6.8.3. AntennaCharacteristics 6.8.3. AntennaCharacteristics
AntennaCharacteristics (Section 5.3) provide additional information, AntennaCharacteristics (Section 5.3) provide additional information,
such as the antenna height, antenna type, etc. such as the antenna height, antenna type, etc.
{ {
"name": "AntennaCharacteristics", "name": "AntennaCharacteristics",
"type": "object", "type": "object",
"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", "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
} }
} }
} }
6.8.4. DeviceCapabilities 6.8.4. DeviceCapabilities
Device capabilities (Section 5.5) provide additional information that Device capabilities (Section 5.4) provide additional information that
MAY be used by the Device to provide additional information to the MAY be used by the Device to provide additional information to the
Database to help the Database determine available spectrum. If the Database to help the Database determine available spectrum. If the
Database does not support device capabilities, it MUST ignore the Database does not support device capabilities, it MUST ignore the
parameter. parameter.
{ {
"name": "DeviceCapabilities", "name": "DeviceCapabilities",
"type": "object", "type": "object",
"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.6) 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 A JavaScript Object Notation (JSON) Representation for described in jCard: The JSON format for vCard
vCard [I-D.bhat-vcarddav-json]. [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",
"description":"Contact information for the individual " + "description":"Contact information for the individual
"or business that owns the device.", or business that owns the device.",
"required": true "required": true
}, },
"operator": { "operator": {
"type": "vCard", "type": "vCard",
"description":"Contact information for the device operator.", "description":"Contact information for the device operator.",
"required": false "required": false
} }
} }
} }
Example: Example:
{ {
"deviceOwner": { "deviceOwner": {
"owner": { "owner": [
"org": { "vcard", [
"text": "Racafrax, Inc." ["version", {}, "text", "4.0"],
} ["org", {}, "text", "Racafrax, Inc."]
}, ]
"operator": { ],
"fn": "John Frax", "operator": [
"adr": { "vcard", [
"street": "100 Main Street", ["version", {}, "text", "4.0"],
"locality": "Summersville", ["fn", {}, "text", "John Frax"],
"region": "CA", ["adr", {}, "text",
"code": "90034", ["", "", "100 Main Street",
"country": "USA" "Summersville", "CA", "90034", "USA"
}, ]
"tel": { ],
"uri": "tel:+1-213-555-1212" ["tel", {}, "uri", "tel:+1-213-555-1212"],
}, ["email", {}, "text", "j.frax@rackafrax.com"]
"email": { ]
"text": "j.frax@rackafrax.com" ]
}
}
} }
} }
6.8.6. RulesetInfo 6.8.6. RulesetInfo
RulesetInfo (Section 5.7) contains parameters for the rule set of a RulesetInfo (Section 5.6) contains parameters for the ruleset of a
regulatory domain that is communicated using the Initialization regulatory domain that is communicated using the Initialization
component (Section 4.2). component (Section 4.2).
{ {
"name": "RulesetInfo", "name": "RulesetInfo",
"type": "object", "type": "object",
"description": "The rule set of a regulatory domain that is " + "description": "The ruleset of a regulatory domain that is
"communicated to Devices in the Initialization Response " + communicated to Devices in the Initialization Response
"message.", message.",
"properties": { "properties": {
"authority": { "authority": {
"type": "string", "type": "string",
"description": "The regulatory domain at the specified " + "description": "The regulatory domain at the specified
"location. It is a 2-letter country codes defined by " + location. It is a 2-letter country codes defined by
"ISO3166-1.", ISO3166-1.",
"required": true
},
"rulesetId": {
"type": "string",
"description": "The identifier of an applicable ruleset",
"required": true "required": true
}, },
"maxLocationChange": { "maxLocationChange": {
"type": "number", "type": "number",
"description": "Maximum location change in meters.", "description": "Maximum location change in meters.",
"required": false "required": false
}, },
"maxPollingSecs": { "maxPollingSecs": {
"type": "integer", "type": "integer",
"description": "Maximum duration, in seconds, between " + "description": "Maximum duration, in seconds, between
"requests for available spectrum.", requests for available spectrum.",
"required": false
},
"rulesetIds": {
"type": "array",
"description": "The identifier of one or more applicable " +
"rule sets",
"item": "string",
"required": false "required": false
} }
} }
} }
6.8.7. DbUpdateSpec 6.8.7. DbUpdateSpec
DbUpdateSpec (Section 5.8) contains one or more database DbUpdateSpec (Section 5.7) contains one or more database
specifications. It is used to indicate a change to the Database URI. specifications. It is used to indicate a change to the Database URI.
{ {
"name": "DbUpdateSpec", "name": "DbUpdateSpec",
"type": "object", "type": "object",
"description": "Specification for updates to a Database URI", "description": "Specification for updates to a Database URI",
"properties": { "properties": {
"databases": { "databases": {
"type": "array", "type": "array",
"description": "The specification of one or more databases", "description": "The specification of one or more databases",
"item": "DatabaseSpec", "item": "DatabaseSpec",
"required": true "required": true
} }
} }
} }
6.8.8. DatabaseSpec 6.8.8. DatabaseSpec
DatabaseSpec (Section 5.9) specifies the name and URI of a database. DatabaseSpec (Section 5.8) specifies the name and URI of a database.
{ {
"name": "DatabaseSpec", "name": "DatabaseSpec",
"type": "object", "type": "object",
"description": "Specification for a database", "description": "Specification for a database",
"properties": { "properties": {
"name": { "name": {
"type": "string", "type": "string",
"description": "The display name of a databases", "description": "The display name of a databases",
"required": true "required": true
skipping to change at page 73, line 43 skipping to change at page 79, line 43
"uri": { "uri": {
"type": "string", "type": "string",
"description": "The URI of a databases", "description": "The URI of a databases",
"required": true "required": true
} }
} }
} }
6.8.9. Spectrum 6.8.9. Spectrum
Available Spectrum (Section 5.10) can logically be characterized by a Available Spectrum (Section 5.11) can logically be characterized by a
list of frequency ranges and permissible power levels for each range. list of SpectrumProfiles, each defining the shape of the permissible
power levels over a range of frequencies.
{ {
"name": "Spectrum", "name": "Spectrum",
"type": "object", "type": "object",
"description": "A per-bandwidth list of frequency ranges with " + "description": "A per-bandwidth list of frequency ranges with
"permissible power levels. For example, In US, In US, FCC " + permissible power levels. For example, In US, FCC
"requires only one spectrum specification at 6MHz " + requires only one spectrum specification at 6MHz
"bandwidth; in UK, Ofcom requires two (at 0.1MHz and " + bandwidth; ETSI requires two (at 0.1MHz and
"8MHz).", 8MHz).",
"properties": { "properties": {
"bandwidth": { "resolutionBwHz": {
"type": "number", "type": "number",
"description": "Operating bandwidth (Hz) for which " + "description": "Resolution bandwidth (Hz) over which
"permissible power levels are applicable.", permissible power spectral densities are defined.",
"required": true "required": true
}, },
"frequencyRanges": { "profiles": {
"type": "array", "type": "array",
"description": "List of FrequencyRange objects to specify " + "description": "List of SpectrumProfile objects to specify
"frequency ranges and permissible power levels for " + permissible power levels, over a set of frequency ranges,
"a given bandwidth. The list MAY be empty when there " + for a given resolutionBwHz. The list MAY be empty when
"is no available spectrum.", there is no available spectrum.",
"items": "FrequencyRange", "items": "SpectrumProfile",
"required": true "required": true
} }
} }
} }
{
"name": "SpectrumProfile",
"type": "array",
"description": "A list of (frequency, power) points. A minimum of
two entries is required.",
"item": "SpectrumProfilePoint",
}
{
"name": "SpectrumProfilePoint",
"type": "object",
"description": "A point defined by a frequency and power level
at that frequency.",
"properties": {
"freqHz": {
"type": "number",
"description": "Frequency (Hz)",
"required": true
},
"powerDbmPerBw": {
"type": "number",
"description": "Power (dBm) per resolution bandwidth as
defined by enclosing resolutionBwHz.",
"required": true
}
}
}
Example:
{
"resolutionBwHz": 6e6,
"profiles": [
[
{"freqHz":5.18e8, "powerDbmPerBw":30.0},
{"freqHz":5.36e8, "powerDbmPerBw":30.0},
{"freqHz":5.36e8, "powerDbmPerBw":36.0},
{"freqHz":5.42e8, "powerDbmPerBw":36.0}
],
[
{"freqHz":6.20e8, "powerDbmPerBw":30.0},
{"freqHz":6.26e8, "powerDbmPerBw":30.0},
]
]
}
6.8.10. FrequencyRange 6.8.10. FrequencyRange
The FrequencyRange (Section 5.4) 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.
{ {
"name": "FrequencyRange", "name": "FrequencyRange",
"type": "object", "type": "object",
"properties": { "properties": {
"startHz": { "startHz": {
"type": "number", "type": "number",
"description": "The inclusive start of the frequency range.", "description": "The inclusive start of the frequency range.",
"required": true "required": true
}, },
"stopHz": { "stopHz": {
"type": "number", "type": "number",
"description": "The exclusive end of the frequency range.", "description": "The exclusive end of the frequency range.",
"required": true "required": true
},
"maxPowerDBm": {
"type": "number",
"description": "The maximum total power level (EIRP), " +
"computed over the corresponding operating bandwidth, " +
"that is permitted within the frequency range. This " +
"field is optional when specifying device " +
"capabilities, but is otherwise required.",
"required": false
},
"channelId": {
"type": "string",
"required": false
} }
} }
} }
6.8.11. EventTime 6.8.11. EventTime
The EventTime (Section 5.11) element specifies the start and stop The EventTime (Section 5.14) element specifies the start and stop
times of an "event." It is used to indicate the time period for times of an "event." It is used to indicate the time period for
which a Spectrum (Section 5.10) is valid. which a Spectrum (Section 5.11) is valid.
{ {
"name": "EventTime", "name": "EventTime",
"type": "object", "type": "object",
"properties": { "properties": {
"startTime": { "startTime": {
"type": "string", "type": "string",
"description": "YYYY-MM-DDThh:mm:ssZ RFC3339 format.", "description": "YYYY-MM-DDThh:mm:ssZ RFC3339 format.",
"format": "date-time", "format": "date-time",
"required": false "required": false
skipping to change at page 76, line 26 skipping to change at page 82, line 26
"type": "string", "type": "string",
"description": "YYYY-MM-DDThh:mm:ssZ RFC3339 format.", "description": "YYYY-MM-DDThh:mm:ssZ RFC3339 format.",
"format": "date-time", "format": "date-time",
"required": false "required": false
} }
} }
} }
6.8.12. SpectrumSchedule 6.8.12. SpectrumSchedule
The SpectrumSchedule (Section 5.12) element combines EventTime with The SpectrumSchedule (Section 5.10) element combines EventTime with
Spectrum to define a time period during which the spectrum is valid. Spectrum to define a time period during which the spectrum is valid.
{ {
"name": "SpectrumSchedule", "name": "SpectrumSchedule",
"type": "object", "type": "object",
"description": "The SpectrumSchedule element combines EventTime " + "description": "The SpectrumSchedule element combines EventTime
"with Spectrum to define a time period during which spectrum " + with Spectrum to define a time period during which spectrum
"is valid.", is valid.",
"properties": { "properties": {
"eventTime": { "eventTime": {
"type": "EventTime", "type": "EventTime",
"description": "Period when the spectra is valid.", "description": "Period when the spectra is valid.",
"required": true "required": true
}, },
"spectra": { "spectra": {
"type": "array", "type": "array",
"description": "List of available spectra and permissible " + "description": "List of available spectra and permissible
"power levels; one spectrum object per bandwidth. 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. GeoSpectrumSchedule 6.8.13. SpectrumSpec
The GeoSpectrumSchedule (Section 5.13) element encapsulates the The JSON encoding of the Available Spectrum response message
schedule of available spectrum at a location. AVAIL_SPECTRUM_RESP (Section 4.4.2) is described by the following
schema:
{
"name": "SpectrumSpec",
"type": "object",
"description": "The SpectrumSpec element represents schedules of
available spectrum for a regulatory-domain ruleset.",
"properties": {
"rulesetInfo": {
"type": "RulesetInfo",
"description": "Indicates the active regulatory domain and
attributes that define the applicable ruleset that
govern the device",
"required": false
},
"spectrumSchedules": {
"type": "array",
"description": "The Database MAY return more than one
schedule to represent future changes to the available
spectrum. This array MAY be empty if no spectrum is
available. If more than one is present, the event-time
intervals SHOULD be sorted and MUST be disjoint.",
"items": "SpectrumSchedule",
"required": true
},
"timeRange": {
"type": "EventTime",
"description": "The time range for which the spectrumSchedules
is comprehensive",
"required": false
},
"frequencyRanges": {
"type": "array",
"description": "The frequency ranges for which the
spectrumSchedules is comprehensive",
"items": "FrequencyRange",
"required": false
}
"needsSpectrumReport": {
"type": "boolean",
"description": "For regulatory domains that require a
spectrum-usage report from devices, the Database MUST
return true for this parameter.",
"default": false,
"required": false
},
"maxTotalBwHz": {
"type": "number",
"description": "Constraint on total bandwidth allowed,
summed across all blocks of spectrum.",
"required": false
},
"maxContiguousBwHz": {
"type": "number",
"description": "Constraint on bandwidth allowed for
any single block of spectrum.",
"required": false
}
}
}
6.8.14. GeoSpectrumSpec
The GeoSpectrumSpec (Section 5.15) element encapsulates the schedule
of available spectrum at a location.
{ {
"name": "GeoSpectrumSchedule", "name": "GeoSpectrumSpec",
"type": "object", "type": "object",
"description": "The GeoSpectrumSchedule element encapsulates " + "description": "The GeoSpectrumSpec element encapsulates
"the schedule of available spectrum at a location.", the schedule of available spectrum at a location.",
"properties": { "properties": {
"location": { "location": {
"type": "GeoLocation", "type": "GeoLocation",
"description": "The location at which the spectrum " + "description": "The location at which the spectrum
"schedule applies.", schedule applies.",
"required": true "required": true
}, },
"spectrumSchedules": { "spectrumSpecs": {
"type": "array", "type": "array",
"description": "At least one schedule MUST be included " + "description": "At least one element MUST be included.
"(though it MAY be empty if there is no available " + More than one element MAY be included
"spectrum. More than one schedule MAY be included " + to represent available spectrum for more than one
"to represent future changes to the available spectrum.", regulatory domain.",
"items": "SpectrumSchedule", "items": "SpectrumSpec",
"required": true "required": true
} }
} }
} }
6.8.14. DeviceValidity 6.8.15. DeviceValidity
The DeviceValidity (Section 5.14) element is used to indicate whether The DeviceValidity (Section 5.16) element is used to indicate whether
a device is valid. See Section 4.5.2. a device is valid. See Section 4.5.2.
{ {
"name": "DeviceValidity", "name": "DeviceValidity",
"type": "object", "type": "object",
"description": "The GeoSpectrumSchedule element encapsulates " + "description": "The DeviceValidity element specifies whether
"the schedule of available spectrum at a location.", the device is valid.",
"properties": { "properties": {
"deviceDesc": { "deviceDesc": {
"type": "DeviceDescriptor", "type": "DeviceDescriptor",
"required": true "required": true
}, },
"isValid": { "isValid": {
"type": "boolean", "type": "boolean",
"description": "Boolean that indicates if the Device is " + "description": "Boolean that indicates if the Device is
"valid", valid",
"required": true "required": true
}, },
"reason": { "reason": {
"type": "string", "type": "string",
"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.15. Additional Properties 6.8.16. Additional Properties
Note that A JSON Media Type for Describing the Structure and Meaning Note that A JSON Media Type for Describing the Structure and Meaning
of JSON [I-D.zyp-json-schema] allows, as default behavior, the of JSON [I-D.zyp-json-schema] allows, as default behavior, the
inclusion of additional properties by instances that are not inclusion of additional properties by instances that are not
explicitly defined in the JSON schema that the instance implements. explicitly defined in the JSON schema that the instance implements.
The schema elaborated in this document adopts this default behavior. The schema elaborated in this document adopts this default behavior.
Hence, the instance MAY provide additional properties and associated Hence, the instance MAY provide additional properties and associated
values (which may be "any" JSON type) not explicitly listed in this values (which may be "any" JSON type) not explicitly listed in this
schema. Further note that the Database and Device MUST ignore any schema. Further note that the Database and Device MUST ignore any
such additional properties and their associated values that it does such additional properties and their associated values that it does
skipping to change at page 80, line 9 skipping to change at page 87, line 13
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 URLs.
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
rerequests, to an alternate URL. If the Device maintains a list of requests, to an alternate URL. If the Device maintains a list of
available URLs, it SHOULD replace only the current URL with the available URLs, it SHOULD replace only the current URL with the
alternal URL. alternate URL.
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
values syntax MUST be well-defined (e.g., using ABNF, or a reference values syntax MUST be well-defined (e.g., using ABNF, or a reference
to the syntax of an existing parameter). to the syntax of an existing parameter).
param-name = 1*name-char param-name = 1*name-char
name-char = ALPHA / DIGIT / "_" name-char = ALPHA / DIGIT / "_"
The parameter name SHOULD be lowerCamelCase. The name SHALL NOT The parameter name SHOULD be lowerCamelCase. The name MUST NOT
exceed 64 characters. exceed 64 characters.
Unregistered vendor-specific parameter extensions that are not Unregistered vendor-specific parameter extensions that are not
commonly applicable, and are specific to the implementation details commonly applicable, and are specific to the implementation details
of the Database where they are used SHOULD use a vendor-specific of the Database where they are used SHOULD use a vendor-specific
prefix that is not likely to conflict with other registered values prefix that is not likely to conflict with other registered values
(e.g., begin with 'companyname'). (e.g., begin with 'companyname').
8.2. Defining Ruleset Identifiers 8.2. Defining Ruleset Identifiers
A rule set represents a set of device-side requirements for which the A ruleset represents a set of device-side requirements for which the
device has been certified. It typically corresponds to, but is not device has been certified. It typically corresponds to, but is not
limited to, a set of rules that govern a specific set of radio limited to, a set of rules that govern a specific set of radio
spectrum for a regulatory domain. spectrum for a regulatory domain.
Rule-set identifiers are defined and registered in the Ruleset ID Ruleset identifiers are defined and registered in the Ruleset ID
Registry following the procedure in Section 9.2. Ruleset ID values Registry following the procedure in Section 9.2. Ruleset ID values
MUST conform to the ruleset-id ABNF. If the Ruleset ID requires MUST conform to the ruleset-id ABNF. If the Ruleset ID requires
additional parameters, they MUST be registered in the PAWS Parameters additional parameters, they MUST be registered in the PAWS Parameters
Registry, as described by Section 9.1. Registry, as described by Section 9.1.
ruleset-id = 1*ruleset-char ruleset-id = 1*ruleset-char
ruleset-char = ALPHA / DIGIT / "_" / "." ruleset-char = ALPHA / DIGIT / "_" / "."
The form of a Ruleset ID value SHOULD be guided by the following: The form of a Ruleset ID value SHOULD be guided by the following:
o The value SHOULD describe the set of rules that allow a device to o The value SHOULD describe the set of rules that allow a device to
operate within one or more regulatory domains. For example, it operate within one or more regulatory domains. For example, it
MAY include the name of a regulatory body or a certification MAY include the name of a regulatory body or a certification
process process
o The value SHOULD include version information, such as a year o The value SHOULD include version information, such as a year
and/or version number and/or version number
o The value SHALL NOT exceed 64 characters o The value MUST NOT exceed 64 characters
8.3. Defining Additional Error Codes 8.3. Defining Additional Error Codes
Additional error codes MAY be defined to extend the set listed in Additional error codes MAY be defined to extend the set listed in
Section 5.15. Additional error codes MUST be registered, following Section 5.17. Additional error codes MUST be registered, following
the procedures in Section 9.3. If the error code requires additional the procedures in Section 9.3. If the error code requires additional
response parameters, they MUST be registered in the PAWS Parameters response parameters, they MUST be registered in the PAWS Parameters
Registry, as described by Section 9.1. Registry, as described by Section 9.1.
By convention, the error code SHOULD be a negative integer value, By convention, the error code SHOULD be a negative integer value,
using one of the range of values defined in Error Codes using one of the range of values defined in Error Codes
(Section 5.15). If an appropriate category does not exist, it MAY (Section 5.17). If an appropriate category does not exist, it MAY
use values in a different range. use values in a different range.
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
skipping to change at page 82, line 26 skipping to change at page 89, line 29
and messages defined in Protocol Functionalities (Section 4) and and messages defined in Protocol Functionalities (Section 4) and
Protocol Parameters (Section 5). Protocol Parameters (Section 5).
Specification document(s): Reference to the document that specifies Specification document(s): Reference to the document that specifies
the parameter, preferably including a URI that can be used to the parameter, preferably including a URI that can be used to
retrieve a copy of the document. An indication of the relevant retrieve a copy of the document. An indication of the relevant
sections also may be included, but is not required. sections also may be included, but is not required.
9.1.2. Initial Registry Contents 9.1.2. Initial Registry Contents
The PAWS Parameters Registry enables protocol extensibility to The PAWS Parameters Registry enables protocol extensibility to
support any regulatory domain and rule set. The initial contents of support any regulatory domain and ruleset. The initial contents of
the registry, however, include only FCC-specific and ETSI-specific the registry, however, include only FCC-specific and ETSI-specific
entries, because, as of this writing, it is the only regulatory entries, because, as of this writing, it is the only regulatory
domain that has finalized rules. There is no intent to restrict the domain that has finalized rules. There is no intent to restrict the
protocol to FCC rules. protocol to FCC rules.
The PAWS Parameters Registry's initial contents are listed below. The PAWS Parameters Registry's initial contents are listed below.
FCC ID FCC ID
Parameter name: fccId Parameter name: fccId
Parameter usage location: DeviceDescriptor (Section 5.2) Parameter usage location: DeviceDescriptor (Section 5.2)
Specification document(s): [[ this document ]] Specifies the Specification document(s): [[ this document ]] Specifies the
device's FCC certification identifier. The value is an identifier device's FCC certification identifier. The value is an identifier
string whose length SHALL NOT exceed 32 characters. Note that, in string whose length MUST NOT exceed 32 characters. Note that, in
practice, a valid FCC ID may be limited to 19 characters, as practice, a valid FCC ID may be limited to 19 characters, as
proposed in FCC Administration Topics Review [FCC-Review-2012-10]. proposed in FCC Administration Topics Review [FCC-Review-2012-10].
FCC Device Type FCC Device Type
Parameter name: fccTvbdDeviceType Parameter name: fccTvbdDeviceType
Parameter usage location: DeviceDescriptor (Section 5.2) Parameter usage location: DeviceDescriptor (Section 5.2)
Specification document(s): [[ this document ]] Specifies the TV Band Specification document(s): [[ this document ]] Specifies the TV Band
White Space device type, as defined by the FCC. Valid values are White Space device type, as defined by the FCC. Valid values are
"FIXED", "MODE_1", "MODE_2". "FIXED", "MODE_1", "MODE_2".
ETSI Device Type ETSI Device Type
Parameter name: etsiEnDeviceType Parameter name: etsiEnDeviceType
Parameter usage location: DeviceDescriptor (Section 5.2) Parameter usage location: DeviceDescriptor (Section 5.2)
skipping to change at page 83, line 12 skipping to change at page 90, line 14
Parameter name: fccTvbdDeviceType Parameter name: fccTvbdDeviceType
Parameter usage location: DeviceDescriptor (Section 5.2) Parameter usage location: DeviceDescriptor (Section 5.2)
Specification document(s): [[ this document ]] Specifies the TV Band Specification document(s): [[ this document ]] Specifies the TV Band
White Space device type, as defined by the FCC. Valid values are White Space device type, as defined by the FCC. Valid values are
"FIXED", "MODE_1", "MODE_2". "FIXED", "MODE_1", "MODE_2".
ETSI Device Type ETSI Device Type
Parameter name: etsiEnDeviceType Parameter name: etsiEnDeviceType
Parameter usage location: DeviceDescriptor (Section 5.2) Parameter usage location: DeviceDescriptor (Section 5.2)
Specification document(s): Specifies the White Space Device device Specification document(s): Specifies the White Space Device type, as
type, as defined by the ETSI Harmonised Standard defined by the ETSI Harmonised Standard [ETSI-EN-301-598]. Valid
[ETSI-EN-301-598]. Valid values are single-letter strings, such values are single-letter strings, such as "A", "B", etc. Consult
as "A", "B", etc. Consult the documentation for details about the the documentation for details about the device types.
device types.
ETSI Device Emissions Class ETSI Device Emissions Class
Parameter name: etsiEnDeviceEmissionsClass Parameter name: etsiEnDeviceEmissionsClass
Parameter usage location: DeviceDescriptor (Section 5.2) Parameter usage location: DeviceDescriptor (Section 5.2)
Specification document(s): Specifies the White Space Device device Specification document(s): Specifies the White Space Device
emissions class, as defined by the ETSI Harmonised Standard emissions class, as defined by the ETSI Harmonised Standard
[ETSI-EN-301-598], that characterises the out-of-block emissions [ETSI-EN-301-598], that characterises the out-of-block emissions
of the device. The values are represented by numeric strings, of the device. The values are represented by numeric strings,
such as "1", "2", etc. Consult the documentation for details such as "1", "2", etc. Consult the documentation for details
about emissions classes about emissions classes
ETSI Technology Identifier ETSI Technology Identifier
Parameter name: etsiEnTechnologyId Parameter name: etsiEnTechnologyId
Parameter usage location: DeviceDescriptor (Section 5.2) Parameter usage location: DeviceDescriptor (Section 5.2)
Specification document(s): Specifies the White Space Device Specification document(s): Specifies the White Space Device
technology identifier, as defined by the ETSI Harmonised Standard technology identifier, as defined by the ETSI Harmonised Standard
[ETSI-EN-301-598]. The string value SHALL NOT exceed 64 [ETSI-EN-301-598]. The string value MUST NOT exceed 64 characters
characters in length. Consult the documentation for valid values. in length. Consult the documentation for valid values.
ETSI Device Category ETSI Device Category
Parameter name: etsiEnDeviceCategory Parameter name: etsiEnDeviceCategory
Parameter usage location: DeviceDescriptor (Section 5.2) Parameter usage location: DeviceDescriptor (Section 5.2)
Specification document(s): Specifies the White Space Device device Specification document(s): Specifies the White Space Device
category, as defined by the ETSI Harmonised Standard category, as defined by the ETSI Harmonised Standard
[ETSI-EN-301-598]. Valid values are the strings, "master" and [ETSI-EN-301-598]. Valid values are the strings, "master" and
"slave". It is case insensitive. "slave". It is case insensitive.
9.2. 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,
skipping to change at page 84, line 29 skipping to change at page 91, line 31
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.
9.2.1. Registration Template 9.2.1. Registration Template
Ruleset name: The name of the rule set. The length of the string Ruleset name: The name of the ruleset. The length of the string
SHALL NOT exceed 64 characters. MUST NOT exceed 64 characters.
Additional message parameters: Additional parameters to associate Additional message parameters: Additional parameters to associate
with the rulesetId parameter. New parameters MUST be registered with the rulesetId parameter. New parameters MUST be registered
separately in the PAWS Parameters Registry, as described by separately in the PAWS Parameters Registry, as described by
Section 8.1. Section 8.1.
Specification Document(s): Reference to the document that specifies Specification Document(s): Reference to the document that specifies
the parameter, preferably including a URI that can be used to the parameter, preferably including a URI that can be used to
retrieve a copy of the document. An indication of the relevant retrieve a copy of the document. An indication of the relevant
sections also may be included, but is not required. sections also may be included, but is not required.
9.2.2. Initial Registry Contents 9.2.2. Initial Registry Contents
The PAWS Ruleset ID Registry enables protocol extensibility to The PAWS Ruleset ID Registry enables protocol extensibility to
support any regulatory domain and rule set. The initial contents of support any regulatory domain and ruleset. The initial contents of
the registry, however, include only FCC-specific and ETSI-specific the registry, however, include only FCC-specific and ETSI-specific
entries, because, as of this writing, it is the only regulatory entries, because, as of this writing, it is the only regulatory
domain that has finalized rules. There is no intent to restrict the domain that has finalized rules. There is no intent to restrict the
protocol to FCC rules. protocol to FCC rules.
The initial contents of the PAWS Ruleset ID Registry are listed The initial contents of the PAWS Ruleset ID Registry are listed
below. below.
9.2.2.1. Federal Communications Commission (FCC) 9.2.2.1. Federal Communications Commission (FCC)
skipping to change at page 85, line 21 skipping to change at page 92, line 21
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 rule set refers Specification document(s): [[ this document ]] This ruleset refers
to the FCC rules for TV-band White Space operations established in to the FCC rules for TV-band White Space operations established in
the Code of Federal Regulations (CFR), Title 47, Part 15, Subpart the Code of Federal Regulations (CFR), Title 47, Part 15, Subpart
H [FCC-CFR47-15H]. H [FCC-CFR47-15H].
9.2.2.2. European Telecommunications Standards Institute (ETSI) 9.2.2.2. European Telecommunications Standards Institute (ETSI)
For the additional parameters that start with the "etsi" prefix, see For the additional parameters that start with the "etsi" prefix, see
PAWS Parameters Registry Initial Contents (Section 9.1.2) for more PAWS Parameters Registry Initial Contents (Section 9.1.2) for more
information. information.
skipping to change at page 86, line 19 skipping to change at page 93, line 19
maxTotalBwHz: Specifies a constraint on total allowed bandwidth. maxTotalBwHz: Specifies a constraint on total allowed bandwidth.
It is a REQUIRED parameter in AVAIL_SPECTRUM_RESP It is a REQUIRED parameter in AVAIL_SPECTRUM_RESP
(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).
maxContiguousBwHz: Specifies a constraint on total allowed maxContiguousBwHz: Specifies a constraint on total allowed
contiguous bandwidth. It is a REQUIRED parameter in contiguous bandwidth. It is a REQUIRED parameter in
AVAIL_SPECTRUM_RESP (Section 4.4.2) and AVAIL_SPECTRUM_RESP (Section 4.4.2) and
AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4). AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4).
maxLocationChange: Specifies a constraint on maximum location maxLocationChange: Specifies a constraint on maximum location
changes. It is a REQUIRED parameter in AVAIL_SPECTRUM_RESP changes. It is a REQUIRED parameter in AVAIL_SPECTRUM_RESP
(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 rule set 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 [TBD]@ietf.org mailing process, after a two-week review period on the [TBD]@ietf.org mailing
list, on the advice of one or more Designated Experts. To allow for list, on the advice of one or more Designated Experts. To allow for
skipping to change at page 87, line 10 skipping to change at page 94, line 10
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.
9.3.1. Registration Template 9.3.1. Registration Template
Code: Integer value of the error code. Code: Integer value of the error code.
Name: Name of the error. Name: Name of the error.
Additional parameters: Additional parameters that are returned in Additional parameters: Additional parameters that are returned in
the data portion of the error (See Section 5.15). New parameters the data portion of the error (See Section 5.17). New parameters
MUST be registered separately in the PAWS Parameters Registry, as MUST be registered separately in the PAWS Parameters Registry, as
described by Section 9.1. described by Section 9.1.
Description: Description of the error and its associated parameters, Description: Description of the error and its associated parameters,
if any. if any.
9.3.2. Initial Registry Contents 9.3.2. Initial Registry Contents
Initial registry contents are defined in the Table of Error Codes Initial registry contents are defined in the Table of Error Codes
(Table 1). (Table 1).
skipping to change at page 90, line 8 skipping to change at page 97, line 8
Email: d.joslyn at spectrumbridge dot com Email: d.joslyn at spectrumbridge dot com
Xinpeng Wei Xinpeng Wei
Huawei Huawei
Phone: +86 13436822355 Phone: +86 13436822355
Email: weixinpeng@huawei.com Email: weixinpeng@huawei.com
12. Acknowledgments 12. Acknowledgments
The authors gratefully acknowledge the contributions of: Gabor Bajko, The authors gratefully acknowledge the contributions of: Gabor Bajko,
Teco Boot, Nancy Bravin, Rex Buddenberg, Gerald Chouinard, Stephen Ray Bellis, Teco Boot, Nancy Bravin, Rex Buddenberg, Gerald
Farrell, Michael Fitch, Joel M. Halpern, Daniel Harasty, Michael Chouinard, Stephen Farrell, Michael Fitch, Joel M. Halpern, Daniel
Head, Jussi Kahtava, Warren Kumari, Kalle Kulsmanen, Paul Lambert, Harasty, Michael Head, Jussi Kahtava, Warren Kumari, Kalle Kulsmanen,
Andy Lee, Anthony Mancuso, Basavaraj Patil, Scott Probasco, Brian Paul Lambert, Andy Lee, Anthony Mancuso, Basavaraj Patil, Scott
Rosen, Andy Sago, Peter Stanforth, John Stine, and Juan Carlos Probasco, Brian Rosen, Andy Sago, Peter Stanforth, John Stine, and
Zuniga. Juan Carlos Zuniga.
13. References 13. References
13.1. Normative References 13.1. Normative References
[FCC-CFR47-15H] [FCC-CFR47-15H]
U. S. Government, "Electronic Code of Federal Regulations, U. S. Government, "Electronic Code of Federal Regulations,
Title 47, Part 15, Subpart H: Television Band Devices", Title 47, Part 15, Subpart H: Television Band Devices",
December 2010, <http://www.ecfr.gov/cgi-bin/ December 2010, <http://www.ecfr.gov/cgi-bin/
text-idx?rgn=div6&view=text&node=47:1.0.1.1.16.8>. text-idx?rgn=div6&view=text&node=47:1.0.1.1.16.8>.
[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.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002. Internet: Timestamps", RFC 3339, July 2002.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008. Server-Side State", RFC 5077, January 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
skipping to change at page 91, line 39 skipping to change at page 98, line 47
[ETSI-EN-301-598] [ETSI-EN-301-598]
European Telecommunication Standards Institute (ETSI), European Telecommunication Standards Institute (ETSI),
"TBD: (ETSI EN 301 598)", 2013, <TBD>. "TBD: (ETSI EN 301 598)", 2013, <TBD>.
[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.bhat-vcarddav-json]
Bhat, R. and P. Saint-Andre, "A JavaScript Object Notation
(JSON) Representation for vCard",
draft-bhat-vcarddav-json-00 (work in progress), June 2012.
[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.
[I-D.wei-paws-framework] [I-D.wei-paws-framework]
Wei, X., Zhu, L., and P. McCann, "PAWS Framework", Wei, X., Zhu, L., and P. McCann, "PAWS Framework",
draft-wei-paws-framework-00 (work in progress), July 2012. draft-wei-paws-framework-00 (work in progress), July 2012.
[I-D.zyp-json-schema] [I-D.zyp-json-schema]
skipping to change at page 92, line 19 skipping to change at page 99, line 21
November 2010. November 2010.
[ISO3166-1] [ISO3166-1]
"Country Codes", "Country Codes",
<http://www.iso.org/iso/country_codes.htm>. <http://www.iso.org/iso/country_codes.htm>.
[JSON-RPC] [JSON-RPC]
"JSON-RPC 2.0 Specification", "JSON-RPC 2.0 Specification",
<http://www.jsonrpc.org/specification>. <http://www.jsonrpc.org/specification>.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
Appendix A. Changes / Author Notes. Appendix A. Changes / Author Notes.
Changes from 06:
o Multi-ruleset support:
* Changed RulesetInfo to have single ruleset ID
* Changed INIT_RESP to return a list of RulesetInfo parameters,
rather than a single one
* Changed REGISTRATION_RESP to return a list of RulesetInfo
parameters to indicate the regulatory domains for which
registration was accepted
* Added SpectrumSpec (Section 5.9) parameter to represent
available-spectrum specification for one regulatory domain,
allowing AVAIL_SPECTRUM_RESP and AVAIL_SPECTRUM_BATCH_RESP to
include answers for multiple regulatory domains
* Changed GeoSpectrumSchedule to GeoSpectrumSpec (Section 5.15)
for supporting batch responses to represent available spectrum
for multiple regulatory domains at a location
o To avoid ambiguity or redundant information, clarified that:
* Event-time intervals within a single set of schedules MUST be
disjoint
* A single Spectrum element MUST cover the entire range of
frequencies governed by a ruleset, rather than splitting them
to present a "channelized" view
o Add "ruleset" to Terminology section
o Sync Terminology section with Use Case document
o Add "masterDeviceDesc" to Device Validate request
o Add "masterDeviceLocation" to the AVAIL_SPECTRUM requests and the
SPECTRUM_NOTIFY message. Change "location" to be the location of
the Slave Device, if the request is made by a Master Device on
behalf of a Slave Device
o Update vCard reference and example
o Add jsonrpc 2.0 to all sample messages
o Clarify that Listing Servers may be preconfigured in a device
o Clarify meaning of maximum power levels vs bandwidth, including
renaming parameter names:
o
* maxPowerDBm -> powerDbmPerBw
* bandwidth -> resolutionBwHz
o Explicitly allowed generic JSON-RPC error codes as possible codes.
o Replace SHALL with MUST for consistency
o Replace URI with URL for consistency
o Reduce clutter in JSON encoding examples by removing string-
concatenation characters
o Changed "depends" to "depends on regulatory rules" in several
places
Changes from 05: Changes from 05:
o Remove requirement for JSON-RPC 1.0 o Remove requirement for JSON-RPC 1.0
o More typo fixes and clarifications o More typo fixes and clarifications
Changes from 04: Changes from 04:
o Add "masterDeviceDesc" parameter to the available-spectrum o Add "masterDeviceDesc" parameter to the available-spectrum
requests to allow both Master and Slave device descriptors when requests to allow both Master and Slave device descriptors when
the Master is making the request on behalf of a Slave. the Master is making the request on behalf of a Slave.
o Add "requestType" parameter to the available-spectrum requests to o Add "requestType" parameter to the available-spectrum requests to
skipping to change at page 92, line 50 skipping to change at page 100, line 47
alternate databases alternate databases
o Explicitly allow JSON-RPC v2.0 and v1.0 encodings o Explicitly allow JSON-RPC v2.0 and v1.0 encodings
o Relaxed language that state, "MUST stop operation" to "MUST cease o Relaxed language that state, "MUST stop operation" to "MUST cease
use of spectrum under rules for database-managed spectrum". I.e., use of spectrum under rules for database-managed spectrum". I.e.,
the device may have other fallback strategies allowed by the device may have other fallback strategies allowed by
regulators. regulators.
Changes from 03: Changes from 03:
o Expanded the Database Discovery mechanism to describe in more o Expanded the Database Discovery mechanism to describe in more
detail pre-configuration with URIs of databases and database- detail pre-configuration with URLs of databases and database-
listing services, including mechanisms for updating the listing servers, including mechanisms for updating the
configurations when things change configurations when things change
* Add database-change field to Available Spectrum Response * Add database-change field to Available Spectrum Response
(Section 4.4.2) (Section 4.4.2)
o Added fields that are anticipated to be needed by the ETSI o Added fields that are anticipated to be needed by the ETSI
harmonized standard for White Space Devices: harmonized standard for White Space Devices:
* Added bandwidth constraints to the Available Spectrum Response * Added bandwidth constraints to the Available Spectrum Response
(Section 4.4.2) (Section 4.4.2)
* Updated Available Spectrum Response to return RulesetInfo, * Updated Available Spectrum Response to return RulesetInfo,
rather than just a rule-set identifier rather than just a ruleset identifier
* Added optional device-manufacturer and device-model IDs to the * Added optional device-manufacturer and device-model IDs to the
DeviceDescriptor (Section 5.2). message. Also moved fccId from DeviceDescriptor (Section 5.2) message. Also moved fccId from
this message to the IANA section. this message to the IANA section.
* Expanded IANA (Section 9) sections * Expanded IANA (Section 9) sections
o Clarified restrictions on the specification of the vertices of a o Clarified restrictions on the specification of the vertices of a
Polygon. Polygon.
o Changed default confidence level to 95% for a point with o Changed default confidence level to 95% for a point with
uncertainty uncertainty
o Clarified how devices without absolute time source can use the o Clarified how devices without absolute time source can use the
timestamps in the response messages timestamps in the response messages
o Change method names to start with "spectrum.paws." prefix o Change method names to start with "spectrum.paws." prefix
o Added maximum string lengths o Added maximum string lengths
skipping to change at page 93, line 40 skipping to change at page 101, line 38
o Added timestamp to the AVAIL_SPECTRUM_RESP (Section 4.4.2) and o Added timestamp to the AVAIL_SPECTRUM_RESP (Section 4.4.2) and
AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4) data models to serve as AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4) data models to serve as
a reference for the event times in the response. This was a reference for the event times in the response. This was
accidentally omitted (but was specified in their JSON encodings accidentally omitted (but was specified in their JSON encodings
(Section 6)). (Section 6)).
o Fixed typos throughout the JSON encoding (Section 6) sections, o Fixed typos throughout the JSON encoding (Section 6) sections,
typically adding missing commas. typically adding missing commas.
Changed from 01: Changed from 01:
o Added a description of message sequences to support multiple rule o Added a description of message sequences to support multiple
sets and multiple jurisdictions Section 3.1. rulesets and multiple jurisdictions Section 3.1.
o Modified DeviceDescriptor (Section 5.2) to add rulesetIds o Modified DeviceDescriptor (Section 5.2) to add rulesetIds
parameter parameter
o Modified RulesetInfo (Section 5.7), AvailableSpectrumResponse o Modified RulesetInfo (Section 5.6), AvailableSpectrumResponse
(Section 4.4.2) to add rulesetId parameter. (Section 4.4.2) to add rulesetId parameter.
o Add Extensibility (Section 8) section. o Add Extensibility (Section 8) section.
o Filled in IANA (Section 9) section. o Filled in IANA (Section 9) section.
o Removed blank Example Messages section o Removed blank Example Messages section
Changes from 00: Changes from 00:
o Add JSON encoding o Add JSON encoding
o Adopt RFC5491 for GeoLocation o Adopt RFC5491 for GeoLocation
o Adopt vCard for contact information o Adopt vCard for contact information
o Add Response Code section and update text referencing the defined o Add Response Code section and update text referencing the defined
response codes response codes
o Change DeviceIdentifier to be DeviceDescriptor, allowing o Change DeviceIdentifier to be DeviceDescriptor, allowing
identifiers and device-characteristic fields to be included. identifiers and device-characteristic fields to be included.
Authors' Addresses Authors' Addresses
 End of changes. 295 change blocks. 
1271 lines changed or deleted 1708 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/