draft-ietf-paws-protocol-04.txt   draft-ietf-paws-protocol-05.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: November 8, 2013 Applied Communication Sciences Expires: December 6, 2013 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
May 07, 2013 June 4, 2013
Protocol to Access Spectrum Database Protocol to Access Spectrum Database
draft-ietf-paws-protocol-04 draft-ietf-paws-protocol-05
Abstract Abstract
Portions of the radio spectrum that are allocated to licensees are Portions of the radio spectrum that are allocated to licensees are
available for non-interfering use. This available spectrum is called available for non-interfering use. This available spectrum is called
"White Space." Allowing secondary users access to available spectrum "White Space." Allowing secondary users access to available spectrum
"unlocks" existing spectrum to maximize its utilization and to "unlocks" existing spectrum to maximize its utilization and to
provide opportunities for innovation, resulting in greater overall provide opportunities for innovation, resulting in greater overall
spectrum utilization. spectrum utilization.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 8, 2013. This Internet-Draft will expire on December 6, 2013.
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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . . . . . . . 7 4. Protocol Functionalities . . . . . . . . . . . . . . . . . . . 8
4.1. Database Discovery . . . . . . . . . . . . . . . . . . . . 8 4.1. Database Discovery . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Listing Server . . . . . . . . . . . . . . . . . . . . 9 4.1.1. Listing Server . . . . . . . . . . . . . . . . . . . . 10
4.2. Initialization . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Initialization . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. INIT_REQ . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.1. INIT_REQ . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.2. INIT_RESP . . . . . . . . . . . . . . . . . . . . . . 11 4.2.2. INIT_RESP . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Device Registration . . . . . . . . . . . . . . . . . . . 12 4.3. Device Registration . . . . . . . . . . . . . . . . . . . 12
4.3.1. REGISTRATION_REQ . . . . . . . . . . . . . . . . . . . 12 4.3.1. REGISTRATION_REQ . . . . . . . . . . . . . . . . . . . 13
4.3.2. REGISTRATION_RESP . . . . . . . . . . . . . . . . . . 13 4.3.2. REGISTRATION_RESP . . . . . . . . . . . . . . . . . . 14
4.4. Available Spectrum Query . . . . . . . . . . . . . . . . . 13 4.4. Available Spectrum Query . . . . . . . . . . . . . . . . . 14
4.4.1. AVAIL_SPECTRUM_REQ . . . . . . . . . . . . . . . . . . 16 4.4.1. AVAIL_SPECTRUM_REQ . . . . . . . . . . . . . . . . . . 17
4.4.2. AVAIL_SPECTRUM_RESP . . . . . . . . . . . . . . . . . 17 4.4.2. AVAIL_SPECTRUM_RESP . . . . . . . . . . . . . . . . . 19
4.4.3. AVAIL_SPECTRUM_BATCH_REQ . . . . . . . . . . . . . . . 19 4.4.3. AVAIL_SPECTRUM_BATCH_REQ . . . . . . . . . . . . . . . 21
4.4.4. AVAIL_SPECTRUM_BATCH_RESP . . . . . . . . . . . . . . 20 4.4.4. AVAIL_SPECTRUM_BATCH_RESP . . . . . . . . . . . . . . 23
4.4.5. SPECTRUM_USE_NOTIFY . . . . . . . . . . . . . . . . . 22 4.4.5. SPECTRUM_USE_NOTIFY . . . . . . . . . . . . . . . . . 24
4.4.6. SPECTRUM_USE_RESP . . . . . . . . . . . . . . . . . . 23 4.4.6. SPECTRUM_USE_RESP . . . . . . . . . . . . . . . . . . 25
4.5. Device Validation . . . . . . . . . . . . . . . . . . . . 23 4.5. Device Validation . . . . . . . . . . . . . . . . . . . . 26
4.5.1. DEV_VALID_REQ . . . . . . . . . . . . . . . . . . . . 24 4.5.1. DEV_VALID_REQ . . . . . . . . . . . . . . . . . . . . 27
4.5.2. DEV_VALID_RESP . . . . . . . . . . . . . . . . . . . . 25 4.5.2. DEV_VALID_RESP . . . . . . . . . . . . . . . . . . . . 27
5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 25 5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 28
5.1. GeoLocation . . . . . . . . . . . . . . . . . . . . . . . 25 5.1. GeoLocation . . . . . . . . . . . . . . . . . . . . . . . 28
5.2. DeviceDescriptor . . . . . . . . . . . . . . . . . . . . . 27 5.2. DeviceDescriptor . . . . . . . . . . . . . . . . . . . . . 30
5.3. AntennaCharacteristics . . . . . . . . . . . . . . . . . . 28 5.3. AntennaCharacteristics . . . . . . . . . . . . . . . . . . 31
5.4. DeviceCapabilities . . . . . . . . . . . . . . . . . . . . 29 5.4. DeviceCapabilities . . . . . . . . . . . . . . . . . . . . 32
5.5. DeviceOwner . . . . . . . . . . . . . . . . . . . . . . . 30 5.5. DeviceOwner . . . . . . . . . . . . . . . . . . . . . . . 32
5.6. RulesetInfo . . . . . . . . . . . . . . . . . . . . . . . 30 5.6. RulesetInfo . . . . . . . . . . . . . . . . . . . . . . . 33
5.7. DbUpdateSpec . . . . . . . . . . . . . . . . . . . . . . . 32 5.7. DbUpdateSpec . . . . . . . . . . . . . . . . . . . . . . . 34
5.8. DatabaseSpec . . . . . . . . . . . . . . . . . . . . . . . 32 5.8. DatabaseSpec . . . . . . . . . . . . . . . . . . . . . . . 35
5.9. Spectrum . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.9. Spectrum . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.10. FrequencyRange . . . . . . . . . . . . . . . . . . . . . . 33 5.10. FrequencyRange . . . . . . . . . . . . . . . . . . . . . . 36
5.11. EventTime . . . . . . . . . . . . . . . . . . . . . . . . 34 5.11. EventTime . . . . . . . . . . . . . . . . . . . . . . . . 36
5.12. SpectrumSchedule . . . . . . . . . . . . . . . . . . . . . 34 5.12. SpectrumSchedule . . . . . . . . . . . . . . . . . . . . . 37
5.13. GeoSpectrumSchedule . . . . . . . . . . . . . . . . . . . 35 5.13. GeoSpectrumSchedule . . . . . . . . . . . . . . . . . . . 37
5.14. DeviceValidity . . . . . . . . . . . . . . . . . . . . . . 36 5.14. DeviceValidity . . . . . . . . . . . . . . . . . . . . . . 38
5.15. Error Element . . . . . . . . . . . . . . . . . . . . . . 36 5.15. Error Element . . . . . . . . . . . . . . . . . . . . . . 39
5.15.1. REQUIRED Error . . . . . . . . . . . . . . . . . . . . 37 5.15.1. OUTSIDE_COVERAGE Error . . . . . . . . . . . . . . . . 40
6. Message Encoding . . . . . . . . . . . . . . . . . . . . . . . 38 5.15.2. DATABASE_CHANGE Error . . . . . . . . . . . . . . . . 41
6.1. JSON-RPC Binding . . . . . . . . . . . . . . . . . . . . . 38 5.15.3. REQUIRED Error . . . . . . . . . . . . . . . . . . . . 41
6.2. init Method . . . . . . . . . . . . . . . . . . . . . . . 39 6. Message Encoding . . . . . . . . . . . . . . . . . . . . . . . 41
6.2.1. INIT_REQ Parameters . . . . . . . . . . . . . . . . . 40 6.1. JSON-RPC Binding . . . . . . . . . . . . . . . . . . . . . 42
6.2.2. INIT_RESP Parameters . . . . . . . . . . . . . . . . . 41 6.2. init Method . . . . . . . . . . . . . . . . . . . . . . . 43
6.3. register Method . . . . . . . . . . . . . . . . . . . . . 41 6.2.1. INIT_REQ Parameters . . . . . . . . . . . . . . . . . 43
6.3.1. REGISTRATION_REQ Parameters . . . . . . . . . . . . . 42 6.2.2. INIT_RESP Parameters . . . . . . . . . . . . . . . . . 45
6.3.2. REGISTRATION_RESP Parameters . . . . . . . . . . . . . 43 6.3. register Method . . . . . . . . . . . . . . . . . . . . . 45
6.4. getSpectrum Method . . . . . . . . . . . . . . . . . . . . 44 6.3.1. REGISTRATION_REQ Parameters . . . . . . . . . . . . . 46
6.4.1. AVAIL_SPECTRUM_REQ Parameters . . . . . . . . . . . . 44 6.3.2. REGISTRATION_RESP Parameters . . . . . . . . . . . . . 47
6.4.2. AVAIL_SPECTRUM_RESP Parameters . . . . . . . . . . . . 46 6.4. getSpectrum Method . . . . . . . . . . . . . . . . . . . . 48
6.5. getSpectrumBatch Method . . . . . . . . . . . . . . . . . 49 6.4.1. AVAIL_SPECTRUM_REQ Parameters . . . . . . . . . . . . 48
6.5.1. AVAIL_SPECTRUM_BATCH_REQ Parameters . . . . . . . . . 49 6.4.2. AVAIL_SPECTRUM_RESP Parameters . . . . . . . . . . . . 50
6.5.2. AVAIL_SPECTRUM_BATCH_RESP Parameters . . . . . . . . . 51 6.5. getSpectrumBatch Method . . . . . . . . . . . . . . . . . 53
6.6. notifySpectrumUse Method . . . . . . . . . . . . . . . . . 54 6.5.1. AVAIL_SPECTRUM_BATCH_REQ Parameters . . . . . . . . . 53
6.6.1. SPECTRUM_USE_NOTIFY Parameters . . . . . . . . . . . . 54 6.5.2. AVAIL_SPECTRUM_BATCH_RESP Parameters . . . . . . . . . 55
6.6.2. SPECTRUM_USE_RESP Parameters . . . . . . . . . . . . . 56 6.6. notifySpectrumUse Method . . . . . . . . . . . . . . . . . 58
6.7. verifyDevice Method . . . . . . . . . . . . . . . . . . . 57 6.6.1. SPECTRUM_USE_NOTIFY Parameters . . . . . . . . . . . . 58
6.7.1. DEV_VALID_REQ Parameters . . . . . . . . . . . . . . . 57 6.6.2. SPECTRUM_USE_RESP Parameters . . . . . . . . . . . . . 60
6.7.2. DEV_VALID_RESP Parameters . . . . . . . . . . . . . . 58 6.7. verifyDevice Method . . . . . . . . . . . . . . . . . . . 61
6.8. Sub-message Schemas . . . . . . . . . . . . . . . . . . . 59 6.7.1. DEV_VALID_REQ Parameters . . . . . . . . . . . . . . . 61
6.8.1. GeoLocation . . . . . . . . . . . . . . . . . . . . . 59 6.7.2. DEV_VALID_RESP Parameters . . . . . . . . . . . . . . 62
6.8.2. DeviceDescriptor . . . . . . . . . . . . . . . . . . . 61 6.8. Sub-message Schemas . . . . . . . . . . . . . . . . . . . 64
6.8.3. AntennaCharacteristics . . . . . . . . . . . . . . . . 62 6.8.1. GeoLocation . . . . . . . . . . . . . . . . . . . . . 64
6.8.4. DeviceCapabilities . . . . . . . . . . . . . . . . . . 63 6.8.2. DeviceDescriptor . . . . . . . . . . . . . . . . . . . 66
6.8.5. DeviceOwner . . . . . . . . . . . . . . . . . . . . . 64 6.8.3. AntennaCharacteristics . . . . . . . . . . . . . . . . 67
6.8.6. RulesetInfo . . . . . . . . . . . . . . . . . . . . . 65 6.8.4. DeviceCapabilities . . . . . . . . . . . . . . . . . . 68
6.8.7. DbUpdateSpec . . . . . . . . . . . . . . . . . . . . . 66 6.8.5. DeviceOwner . . . . . . . . . . . . . . . . . . . . . 69
6.8.8. DatabaseSpec . . . . . . . . . . . . . . . . . . . . . 67 6.8.6. RulesetInfo . . . . . . . . . . . . . . . . . . . . . 70
6.8.9. Spectrum . . . . . . . . . . . . . . . . . . . . . . . 67 6.8.7. DbUpdateSpec . . . . . . . . . . . . . . . . . . . . . 71
6.8.10. FrequencyRange . . . . . . . . . . . . . . . . . . . . 68 6.8.8. DatabaseSpec . . . . . . . . . . . . . . . . . . . . . 72
6.8.11. EventTime . . . . . . . . . . . . . . . . . . . . . . 69 6.8.9. Spectrum . . . . . . . . . . . . . . . . . . . . . . . 72
6.8.12. SpectrumSchedule . . . . . . . . . . . . . . . . . . . 70 6.8.10. FrequencyRange . . . . . . . . . . . . . . . . . . . . 73
6.8.13. GeoSpectrumSchedule . . . . . . . . . . . . . . . . . 71 6.8.11. EventTime . . . . . . . . . . . . . . . . . . . . . . 74
6.8.14. DeviceValidity . . . . . . . . . . . . . . . . . . . . 71 6.8.12. SpectrumSchedule . . . . . . . . . . . . . . . . . . . 75
6.8.15. Additional Properties . . . . . . . . . . . . . . . . 72 6.8.13. GeoSpectrumSchedule . . . . . . . . . . . . . . . . . 76
6.8.14. DeviceValidity . . . . . . . . . . . . . . . . . . . . 76
7. HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . . . 72 6.8.15. Additional Properties . . . . . . . . . . . . . . . . 77
8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 73 7. HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . . . 77
8.1. Defining New Message Parameters . . . . . . . . . . . . . 73 8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 78
8.2. Defining Ruleset Identifiers . . . . . . . . . . . . . . . 74 8.1. Defining New Message Parameters . . . . . . . . . . . . . 78
8.3. Defining Additional Error Codes . . . . . . . . . . . . . 74 8.2. Defining Ruleset Identifiers . . . . . . . . . . . . . . . 79
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 8.3. Defining Additional Error Codes . . . . . . . . . . . . . 79
9.1. PAWS Parameters Registry . . . . . . . . . . . . . . . . . 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80
9.1.1. Registration Template . . . . . . . . . . . . . . . . 75 9.1. PAWS Parameters Registry . . . . . . . . . . . . . . . . . 80
9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 76 9.1.1. Registration Template . . . . . . . . . . . . . . . . 80
9.2. PAWS Ruleset ID Registry . . . . . . . . . . . . . . . . . 77 9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 81
9.2.1. Registration Template . . . . . . . . . . . . . . . . 78 9.2. PAWS Ruleset ID Registry . . . . . . . . . . . . . . . . . 82
9.2.2. Initial Registry Contents . . . . . . . . . . . . . . 78 9.2.1. Registration Template . . . . . . . . . . . . . . . . 83
9.3. PAWS Error Code Registry . . . . . . . . . . . . . . . . . 79 9.2.2. Initial Registry Contents . . . . . . . . . . . . . . 83
9.3.1. Registration Template . . . . . . . . . . . . . . . . 80 9.3. PAWS Error Code Registry . . . . . . . . . . . . . . . . . 85
9.3.2. Initial Registry Contents . . . . . . . . . . . . . . 80 9.3.1. Registration Template . . . . . . . . . . . . . . . . 85
10. Security Considerations . . . . . . . . . . . . . . . . . . . 80 9.3.2. Initial Registry Contents . . . . . . . . . . . . . . 85
10.1. Assurance of Proper Database . . . . . . . . . . . . . . . 81 10. Security Considerations . . . . . . . . . . . . . . . . . . . 85
10.2. Protection Against Modification . . . . . . . . . . . . . 81 10.1. Assurance of Proper Database . . . . . . . . . . . . . . . 86
10.3. Protection Against Eavesdropping . . . . . . . . . . . . . 82 10.2. Protection Against Modification . . . . . . . . . . . . . 87
10.4. Client Authentication Considerations . . . . . . . . . . . 82 10.3. Protection Against Eavesdropping . . . . . . . . . . . . . 87
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 82 10.4. Client Authentication Considerations . . . . . . . . . . . 87
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 83 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 88
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 83 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 88
13.1. Normative References . . . . . . . . . . . . . . . . . . . 83 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 88
13.2. Informative References . . . . . . . . . . . . . . . . . . 84 13.1. Normative References . . . . . . . . . . . . . . . . . . . 88
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . . 85 13.2. Informative References . . . . . . . . . . . . . . . . . . 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 87 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . . 90
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 92
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
database: PS, use cases and rqmts database: PS, use cases and rqmts
[I-D.ietf-paws-problem-stmt-usecases-rqmts] for use cases, [I-D.ietf-paws-problem-stmt-usecases-rqmts] 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
skipping to change at page 6, line 9 skipping to change at page 6, line 9
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 that provides spectrum
availability information to devices. availability information to devices.
Database Listing Server A service that provides the URLs for one or
more Spectrum Databases. A regulator, for example, may operate a
Database Listing Server to publish the list of authorized Spectrum
Databases for its regulatory domain.
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 Master Device: A device with geo-location capability that queries a
database to find available spectrum. database to find available spectrum.
Slave Device: A device without geo-location capability that uses the Slave Device: A device without geo-location capability that uses the
spectrum made available by a Master Device. It does not query the spectrum made available by a Master Device. It does not query the
Database directly. Database directly.
3. Protocol Overview 3. Protocol Overview
skipping to change at page 6, line 44 skipping to change at page 6, line 48
Database. Database.
3. The Master Device optionally sends an initialization message to 3. The Master Device optionally sends an initialization message to
the Database to exchange capabilities. the Database to exchange capabilities.
4. If the Database receives an initialization message, it responds 4. If the Database receives an initialization message, it responds
with a message in the body of the HTTP response. with a message in the body of the HTTP response.
5. If required by regulatory domain, the Database registers the 5. If required by regulatory domain, the Database registers the
Master Device. Master Device.
6. The Master Device sends an available-spectrum request message to 6. The Master Device sends an available-spectrum request message to
the Database. the Database.
7. If required by the regulatory domain, the Master Device must 7. If required by the regulatory domain, the Master Device must
verify with the Database that the Slave Device valid. verify with the Database that the Slave Device is valid.
8. The Database responds with an available-spectrum response 8. The Database responds with an available-spectrum response
message in the body of the HTTP response. message in the body of the HTTP response.
9. 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 rule sets and operates
with multiple databases in multiple regulatory domains, the PAWS with multiple databases in multiple regulatory domains, the PAWS
protocol supports the following sequence of operations for each protocol supports the following sequence of operations for each
request by the Master Device: request by the Master Device:
skipping to change at page 8, line 10 skipping to change at page 8, line 14
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. and MAY be implemented by the Database as a separate component or
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 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.
and MUST be implemented by the Database if the regulatory domain If the regulatory domain requires device validation, it MUST be
requires device validation. 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
optional device authentication. optional device authentication.
4.1. Database Discovery 4.1. Database Discovery
skipping to change at page 8, line 47 skipping to change at page 8, line 52
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. o A Device SHOULD support operation in any regulatory environment.
Preconfiguration Preconfiguration
The Device MAY be provisioned statically with the URI of one or more The Master Device MAY be provisioned statically with the URI of one
Databases. For operation in regulatory domains that do not have a or more Databases. For operation in regulatory domains that do not
listing server, the Device SHOULD be provisioned with the URI of all have a listing server, the device SHOULD be provisioned with the URI
the databases for which it is certified or otherwise permitted to of all the databases for which it is certified or otherwise permitted
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 to 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 lists of the Device SHOULD be able to update its preconfigured list of
databases. When the preconfigured list of databases is provided by a databases. If the Master Device retrieves its preconfigured list of
listing service, the Device SHOULD check the service periodically to databases from a listing service, the device SHOULD check the service
update its list. periodically to update its list.
Before a Database ceases operation, it SHOULD indicate its intent to A Database MAY indicate that its URI will be changing by including
cease operation in its device responses and SHOULD include the URI of the URI of one or more alternate databases (See DbUpdateSpec
one or more alternate databases (See DbUpdateSpec (Section 5.7)). A (Section 5.7)) in its responses to a Device. Before a Database
Device SHOULD be able to update its preconfigured list of databases ceases operation, for example, it SHOULD include DbUpdateSpec in its
with the URIs of the alternate databases responses to notify Devices. A Device SHOULD be able to update its
preconfigured list of databases to replace (only) its entry for the
responding Database with the URIs of the alternate databases; the
list of alternate databases SHOULD 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.15)), 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 MUST NOT If a suitable database cannot be contacted, the Device SHALL NOT
operate in white space spectrum. If the Device is already operating operate under rules for database-managed spectrum. If the Device is
when it fails to contact a suitable database, and if the applicable already operating when it fails to contact a suitable database, and
regulatory domain provides a grace period, the Device may continue to if the applicable regulatory domain provides a grace period, the
operate during such period, but must cease operation at or before the Device may continue to operate during such period, but MUST cease use
expiration of the grace period. If a grace period is not provided by of the spectrum under rules for database-managed spectrum at or
the applicable regulatory domain, an operating Device that fails to before the expiration of the grace period. If a grace period is not
contact a suitable database MUST cease operation immediately. provided by the applicable regulatory domain, an operating Device
that fails to contact a suitable database MUST immediately cease use
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 URIs of databases for the domain.
Where allowed by the regulator, the Device MAY save the database list Where allowed by the regulator, the Device MAY save the database list
and SHOULD contact the Database Listing Server periodically to update and SHOULD contact the Database Listing Server periodically to update
its list. The time between such updates SHALL be no longer than one its list. The time between such updates SHALL be no longer than one
week, or any update interval required by the applicable regulatory week, or any update interval required by the applicable regulatory
domain, whichever is shorter. domain, whichever is shorter.
If the Device is unable to contact the Database Listing Server to
obtain the list of databases for the domain, the Device SHALL NOT
operate under rules for database-managed spectrum. If an operating
Device attempting to update the available spectrum from a Database
fails to contact the Database Listing Server to validate the Database
that provides the available spectrum, the operating Device MUST
immediately cease use of the spectrum under rules for database-
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
o LISTING_RESP is the database-listing response message o LISTING_RESP is the database-listing response message
+---------------+ +-------------------+ +---------------+ +-------------------+
| Master Device | | Listing Server | | Master Device | | Listing Server |
+---------------+ +-------------------+ +---------------+ +-------------------+
| | | |
| LISTING_REQ | | LISTING_REQ |
skipping to change at page 11, line 22 skipping to change at page 11, line 43
+----------------------------+----------| +----------------------------+----------|
|deviceDesc:DeviceDescriptor | required | |deviceDesc:DeviceDescriptor | required |
|location:GeoLocation | required | |location:GeoLocation | required |
|.......................................| |.......................................|
|*other:any | depends | |*other:any | depends |
+----------------------------+----------+ +----------------------------+----------+
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 regulatory domain REQUIRED. If the Database does not support the device or any of
specified by the "authority" parameter, it MUST return an error the rule sets specified in the device descriptor, it MUST return
with the UNSUPPORTED (Table 1) code in the error response. an error with the UNSUPPORTED (Table 1) code in the error
response.
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 11, line 36 skipping to change at page 12, line 15
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.
+-------------------------------------+ +---------------------------------------+
|INIT_RESP | |INIT_RESP |
+--------------------------+----------+ +----------------------------+----------+
|rulesetInfo:RulesetInfo | required | |rulesetInfo:RulesetInfo | required |
|.....................................| |databaseChange:DbUpdateSpec | optional |
|*other:any | depends | |.......................................|
+--------------------------+----------+ |*other:any | depends |
+----------------------------+----------+
Parameters: Parameters:
rulesetInfo: This RulesetInfo (Section 5.6) parameter MUST be rulesetInfo: This RulesetInfo (Section 5.6) parameter MUST be
included in the response. This parameter specifies the regulatory included in the response. This parameter specifies the regulatory
domain and parameters applicable for that domain. The Database domain and parameters applicable for that domain. The Database
MUST include the "authority" that defines the regulatory domain MUST include the "authority" field that defines the regulatory
for the location specified in the INIT_REQ (Section 4.2.1) domain for the location specified in the INIT_REQ (Section 4.2.1)
message. message.
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 URIs. 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 URIs.
other: Depending on the regulatory domain or database other: Depending on the regulatory domain or database
implementation, the Database MAY include additional handshake implementation, the Database MAY include additional handshake
parameters in the INIT_RESP (Section 4.2.2) message. The Master parameters in the INIT_RESP (Section 4.2.2) message. The Master
Device MUST ignore all parameters it does not understand. Device MUST ignore all parameters it does not understand.
4.3. Device Registration 4.3. Device Registration
When a regulatory domain requires registration of a Master Device, When a regulatory domain requires registration of a Master Device,
the Device MUST send its registration information to the Database to the Device MUST send its registration information to the Database to
establish certain operational parameters. FCC rules, for example, establish certain operational parameters. FCC rules, for example,
skipping to change at page 13, line 20 skipping to change at page 14, line 4
|deviceOwner:DeviceOwner | required | |deviceOwner:DeviceOwner | required |
|.......................................| |.......................................|
|*other:any | depends | |*other:any | depends |
+----------------------------+----------+ +----------------------------+----------+
Parameters: Parameters:
deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is
REQUIRED. REQUIRED.
location: The GeoLocation (Section 5.1) for the Device 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.5) information is REQUIRED.
other: Regulatory domains MAY require additional registration other: Regulatory domains and database implementations MAY require
parameters. To simplify its registration logic, the Device MAY additional registration parameters. To simplify its registration
send a union of the registration information required by all logic, the Device MAY send a union of the registration information
supported regulatory domains. The Database MUST ignore all required by all supported regulatory domains. The Database MUST
parameters it does not understand. Consult the PAWS Parameters ignore all parameters it does not understand. Consult the PAWS
Registry for possible additional parameters. Parameters Registry (Section 9.1) for possible additional
parameters.
4.3.2. REGISTRATION_RESP 4.3.2. REGISTRATION_RESP
The registration response message simply acknowledges receipt of the The registration response message simply acknowledges receipt of the
request and is otherwise empty. Future extensions may add parameters request and is otherwise empty. Future extensions may add parameters
to this message. to this message.
+-------------------------------------+ +---------------------------------------+
|REGISTRATION_RESP | |REGISTRATION_RESP |
+--------------------------+----------+ +----------------------------+----------+
|*other:any | depends | |databaseChange:DbUpdateSpec | optional |
+--------------------------+----------+ |............................|..........|
|*other:any | depends |
+----------------------------+----------+
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 URIs. 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 URIs.
other: Database implementations MAY return addtional parameters in
the registration response. Consult the PAWS Parameters Registry
(Section 9.1) for possible additional parameters and requirements
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
that describes what frequencies are available, at what permissible that describes which frequencies are available, at what permissible
operating power levels, and a schedule of when they are available. operating power levels, and a schedule of when they are available.
The Available Spectrum Query procedure is depicted in Figure 4. The Available Spectrum Query procedure is depicted in Figure 4.
o AVAIL_SPECTRUM_REQ (Section 4.4.1) is the available-spectrum o AVAIL_SPECTRUM_REQ (Section 4.4.1) is the available-spectrum
request message request message
o AVAIL_SPECTRUM_RESP (Section 4.4.2) is the available-spectrum o AVAIL_SPECTRUM_RESP (Section 4.4.2) is the available-spectrum
response message response message
o AVAIL_SPECTRUM_BATCH_REQ (Section 4.4.3) is an OPTIONAL batch o AVAIL_SPECTRUM_BATCH_REQ (Section 4.4.3) is an OPTIONAL batch
version of the available-spectrum request message that allows version of the available-spectrum request message that allows
skipping to change at page 14, line 47 skipping to change at page 15, line 47
| | | |
Figure 4 Figure 4
1. First, the Master Device sends an available-spectrum request 1. First, the Master Device sends an available-spectrum request
message to the Database. message to the Database.
2. The Database MUST respond with an error using the NOT_REGISTERED 2. The Database MUST respond with an error using the NOT_REGISTERED
(Table 1) code if: (Table 1) code if:
* registration information is required, and * registration information is required, and
* the request does not include registration information, and * the request does not include registration information, and
* the Device has not previously registered * the Device has not previously registered with the Database
3. If the location specified in the request is outside the 3. If the location specified in the request is outside the
regulatory domain, the Database MUST respond with an regulatory domain supported by the Database, the Database MUST
OUTSIDE_COVERAGE (Table 1) error. If some locations within a respond with an OUTSIDE_COVERAGE (Table 1) error. If some
batch request are outside the regulatory domain, the Database MAY locations within a batch request are outside the regulatory
return an OK response with available spectrum for only the valid domain supported by the Database, the Database MAY return an OK
locations. If all locations within a batch request are outside response with available spectrum for only the valid locations;
otherwise, if all locations within a batch request are outside
the regulatory domain, the Database MUST respond with an the regulatory domain, the Database MUST respond with an
OUTSIDE_COVERAGE error. OUTSIDE_COVERAGE error.
4. The Database MAY perform other validation of the request, (e.g., 4. The Database MAY perform other validation of the request, (e.g.,
checking for missing required parameters, authorizations). It checking for missing required parameters, authorizations). It
MUST return an error with appropriate error code (Table 1), if MUST return an error with appropriate error code (Table 1), if
validation fails. If the request is missing required parameters, validation fails. If the request is missing required parameters,
the Database MUST respond with a REQUIRED (Table 1) error and the Database MUST respond with a REQUIRED (Table 1) error and
SHOULD include a list of the missing parameters. SHOULD include a list of the missing parameters.
5. If the request is valid, the Database responds with an available- 5. If the request is valid, the Database responds with an available-
spectrum response message. If the regulatory domain requires spectrum response message. If the regulatory domain requires
skipping to change at page 16, line 33 skipping to change at page 17, line 33
| | | | | |
Figure 5 Figure 5
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 | required | |deviceDesc:DeviceDescriptor | optional |
|location:GeoLocation | required | |location:GeoLocation | required |
|antenna:AntennaCharacteristics | depends on regulatory domain | |antenna:AntennaCharacteristics | depends on regulatory domain |
|owner:DeviceOwner | depends on regulatory domain | |owner:DeviceOwner | depends on regulatory domain |
|capabilities:DeviceCapabilities| optional | |capabilities:DeviceCapabilities | optional |
+-------------------------------+------------------------------+ |masterDeviceDesc:DeviceDescriptor | optional |
|requestType:string | optional |
|..................................|..............................|
|*other:any | depends |
+----------------------------------+------------------------------+
Parameters: Parameters:
deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is deviceDesc: The DeviceDescriptor (Section 5.2) for the Device
REQUIRED. requesting available spectrum. When the request is made by a
Master Device on its own behalf, the descriptor is that of the
Master Device and it is REQUIRED. When the request is made on
behalf of a Slave Device, the descriptor is that of the Slave
Device, and it is REQUIRED if the "requestType" parameter is not
specified. The deviceDesc parameter may be OPTIONAL for some
values of requestType.
location: The GeoLocation (Section 5.1) for the Master Device is location: The GeoLocation (Section 5.1) for the Master Device is
REQUIRED. The location SHOULD be the current location of the REQUIRED. The location SHOULD be the current location of the
Device, but more precisely, the location of the radiation center Device, but more precisely, the location of the radiation center
of the Device's antenna. Depending on the regulatory domain, the of the Device's antenna. When the request is made by the Master
location MAY be an anticipated position of the Device to support Device on behalf of a Slave Device, the location is that of the
mobile devices. If the location specifies a region, rather than a Master Device. Depending on the regulatory domain, the location
point, the Database MAY return an error with the UNIMPLEMENTED MAY be an anticipated position of the Device to support mobile
(Table 1) code, if it does not support query by region. devices. If the location specifies a region, rather than a point,
the Database MAY return an error with the UNIMPLEMENTED (Table 1)
code, if it does not support query by region.
antenna: Depending on the device type and regulatory domain, the antenna: Depending on the device type and regulatory domain, the
AntennaCharacteristics (Section 5.3) MAY be required. AntennaCharacteristics (Section 5.3) MAY be required.
owner: Depending on the device type and regulatory domain, the owner: Depending on the device type and regulatory domain, the
DeviceOwner (Section 5.5) 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.
capabilities: The Master Device MAY include its DeviceCapabilities capabilities: The Master Device MAY include its DeviceCapabilities
(Section 5.4) to limit the available-spectrum response to the (Section 5.4) to limit the available-spectrum response to the
spectrum that is compatible with its capabilities. The Database spectrum that is compatible with its capabilities. The Database
SHOULD NOT return spectrum that is not compatible with the SHOULD NOT return spectrum that is not compatible with the
specified capabilities. specified capabilities.
masterDeviceDesc: 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.
requestType: The request type is an OPTIONAL parameter that may be
used to modify the request, but its use depends on applicable
regulatory rules. The request type may be used, for example, to
request generic Slave Device parameters without having to specify
the device descriptor for a specific device. When the requestType
parameter is missing, the request is for a specific device (Master
or Slave), so the deviceDesc parameter is REQUIRED. See IANA
Ruleset Registry, Initial Registry Contents (Section 9.2.2) for
regulatory specifics.
other: Regulatory domains and database implementations MAY require
additional request parameters. The Database MUST ignore all
parameters it does not understand. Consult the PAWS 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 a
schedule of available spectrum for the Device. schedule of available spectrum for the Device.
+---------------------------------------+ +---------------------------------------+
|AVAIL_SPECTRUM_RESP | |AVAIL_SPECTRUM_RESP |
+----------------------------+----------+ +----------------------------+----------+
|timestamp:string | required | |timestamp:string | required |
|deviceDesc:DeviceDescriptor | required | |deviceDesc:DeviceDescriptor | required |
|spectrumSchedules:list | required |-------+ |spectrumSchedules:list | required |-------+
|needsSpectrumReport:bool | optional | | |needsSpectrumReport:bool | optional | |
|maxTotalBwHz:float | optional | | |maxTotalBwHz:float | optional | |
|maxContiguousBwHz:float | optional | | |maxContiguousBwHz:float | optional | |
|rulesetInfo:RulesetInfo | optional | | |rulesetInfo:RulesetInfo | optional | |
|............................|..........| | |............................|..........| |
|location:GeoLocation | optional | | |location:GeoLocation | optional | |
|............................|..........| | |............................|..........| |
|databaseChange:DbUpdateSpec | optional | | |databaseChange:DbUpdateSpec | optional | |
|*other:any | depends | |
+----------------------------+----------+ | 0..* +----------------------------+----------+ | 0..*
V V
+-----------------------------+ +-----------------------------+
|SpectrumSchedule | |SpectrumSchedule |
+------------------+----------+ +------------------+----------+
|time:EventTime | required | |time:EventTime | required |
|spectrum:Spectrum | required | |spectrum:Spectrum | required |
+------------------+----------+ +------------------+----------+
Parameters: Parameters:
skipping to change at page 18, line 19 skipping to change at page 19, line 50
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 spectrumSchedules: The SpectrumSchedule (Section 5.12) list is
REQUIRED (though it MAY be empty if no spectrum is available). REQUIRED (though it MAY be empty if no spectrum is available).
The Database MAY return more than one SpectrumSchedule The Database MAY return more than one SpectrumSchedule
(Section 6.8.12) to represent future changes to the available (Section 6.8.12) to represent future changes to the available
spectrum. How far in advance a schedule may be provided depends spectrum. How far in advance a schedule may be provided depends
on the regulatory domain. on the regulatory domain.
needsSpectrumReport: For regulatory domains that require a spectrum- needsSpectrumReport: For regulatory domains that require a spectrum-
usage report from devices, the Database MUST return true for this usage report from devices, the Database MUST return true for this
parameter. The default value is false. parameter. The default value is false. If this parameter is
true, the Device MUST send a SPECTRUM_USE_NOTIFY (Section 4.4.5)
message to the Database.
maxTotalBwHz: The Database MAY return a constraint on the maximum maxTotalBwHz: The Database MAY return a constraint on the maximum
total bandwidth (in Hertz) allowed, which may or may not be total bandwidth (in Hertz) allowed, which may or may not be
contiguous. A regulatory domain MAY require the Database to contiguous. A regulatory domain MAY require the Database to
return this parameter. When present in the response, the Device return this parameter. When present in the response, the Device
MUST apply this constraint to its spectrum-selection logic to MUST apply this constraint to its spectrum-selection logic to
ensure total bandwidth does not exceed this value. ensure total bandwidth does not exceed this value.
maxContiguousBwHz The Database MAY return a constraint on the maxContiguousBwHz The Database MAY return a constraint on the
maximum contiguous bandwidth (in Hertz) allowed. A regulatory maximum contiguous bandwidth (in Hertz) allowed. A regulatory
domain MAY require this Database to return this parameter. When domain MAY require this Database to return this parameter. When
present in the response, the Device MUST apply this constraint to present in the response, the Device MUST apply this constraint to
skipping to change at page 18, line 45 skipping to change at page 20, line 30
Registry (Section 9.2)). If included, the Device MUST use the Registry (Section 9.2)). If included, the Device MUST use the
corresponding rule set to interpret the response. Values provided corresponding rule set to interpret the response. Values provided
within this parameter, such as maxLocationChange, take precedence within this parameter, such as maxLocationChange, take precedence
over the values provided by the Initialization Procedure over the values provided by the Initialization Procedure
(Section 4.2). (Section 4.2).
location: The Database MAY copy other elements from the request, location: The Database MAY copy other elements from the request,
such as the GeoLocation (Section 5.1) of the Device. The Device such as the GeoLocation (Section 5.1) of the Device. The Device
MUST ignore any parameters it does not understand. MUST ignore any parameters it does not understand.
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) parameter to notify the Device of a change to the (Section 5.7) parameter to notify the Device of a change to the
Database URI. When a Database plans to cease operation, it SHOULD Database URI, providing one or more alternate database URIs. The
return this parameter to provide devices with one or more Device SHOULD use the information to update its list of
alternate database URIs. The Device SHOULD use the information to preconfigured databases to replace (only) its entry for the
update its list of preconfigured databases. responding database with the list of alternate URIs.
other: Database implementations MAY return addtional parameters in
the response. Consult the PAWS Parameters Registry (Section 9.1)
for possible additional parameters and requirements they place on
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
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 stop operation immediately. available, the Device MUST immediately cease use of that 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, depending on the regulatory domain, the Device MAY schedule, the Device MUST immeidately cease use of that spectrum
continue to operate for a period of time, as indicated by under rules for database-managed spectrum.
parameters returned in the INIT_RESP (Section 4.2.2) message.
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.6)), 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 stop schedule, depending on the regulatory domain, the Device MUST
operation immediately. immediately cease use of the spectrum under rules of database-
managed spectrum.
NOTE: Regulatory rules govern whether a device may request and use
spectrum at anticipated locations beyond the threashold distance from
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 | required | |deviceDesc:DeviceDescriptor | optional |
|locations:list | required |--+ |locations:list | required |--+
|antenna:AntennaCharacteristics | depends on regulatory domain | | |antenna:AntennaCharacteristics | depends on regulatory domain | |
|owner:DeviceOwner | depends on regulatory domain | | |owner:DeviceOwner | depends on regulatory domain | |
|capabilities:DeviceCapabilities| optional | | |capabilities:DeviceCapabilities | optional | |
+-------------------------------+------------------------------+ | |masterDeviceDesc:DeviceDescriptor| optional | |
|requestType:string | optional | |
+.................................+..............................+ |
|*other:any | depends | |
+---------------------------------+------------------------------+ |
| |
1..* V 1..* V
+-------------+ +-------------+
| GeoLocation | | GeoLocation |
+-------------+ +-------------+
Parameters: Parameters:
deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is deviceDesc: The DeviceDescriptor (Section 5.2) for the Device
REQUIRED. requesting available spectrum. When the request is made by a
Master Device on its own behalf, the descriptor is that of the
Master Device and it is REQUIRED. When the request is made on
behalf of a Slave Device, the descriptor is that of the Slave
Device, and it is REQUIRED if the "requestType" parameter is not
specified. The deviceDesc parameter may be OPTIONAL for some
values of requestType.
locations: The GeoLocation (Section 5.1) list for the Master Device locations: The GeoLocation (Section 5.1) list for the Master Device
is REQUIRED. This allows the Device to specify its actual is REQUIRED. This allows the Device to specify its actual
location plus additional anticipated locations, when allowed by location plus additional anticipated locations, when allowed by
the regulatory domain. At least one location MUST be included. the regulatory domain. At least one location MUST be included.
This specification places no upper limit on the number of This specification places no upper limit on the number of
locations, but the Database MAY restrict the number of locations locations, but the Database MAY restrict the number of locations
it supports by returning a response with fewer locations than it supports by returning a response with fewer locations than
specified in the request. specified in the request.
antenna: Depending on the device type and regulatory domain, the antenna: Depending on the device type and regulatory domain, the
AntennaCharacteristics (Section 5.3) MAY be required. AntennaCharacteristics (Section 5.3) MAY be required.
owner: Depending on the device type and regulatory domain, the owner: Depending on the device type and regulatory domain, the
DeviceOwner (Section 5.5) 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.
capabilities: The Master Device MAY include its DeviceCapabilities capabilities: The Master Device MAY include its DeviceCapabilities
(Section 5.4) to limit the available-spectrum response to the (Section 5.4) to limit the available-spectrum response to the
spectrum that is compatible with its capabilities. The Database spectrum that is compatible with its capabilities. The Database
SHOULD NOT return spectrum that is not compatible with the SHOULD NOT return spectrum that is not compatible with the
specified capabilities. specified capabilities.
masterDeviceDesc: 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.
requestType: The request type is an OPTIONAL parameter that may be
used to modify the request, but its use depends on applicable
regulatory rules. The request type may be used, for example, to
request generic Slave Device parameters without having to specify
the device descriptor for a specific device. When the requestType
parameter is missing, the request is for a specific device (Master
or Slave), so the deviceDesc parameter is REQUIRED. See IANA
Ruleset Registry, Initial Registry Contents (Section 9.2.2) for
regulatory specifics.
other: Regulatory domains and database implementations MAY require
additional request parameters. The Database MUST ignore all
parameters it does not understand. Consult the PAWS Parameters
Registry (Section 9.1) for possible additional parameters.
4.4.4. AVAIL_SPECTRUM_BATCH_RESP 4.4.4. AVAIL_SPECTRUM_BATCH_RESP
The response message for the batch Available Spectrum Query contains The response message for the batch Available Spectrum Query contains
a schedule of available spectrum for the Device at multiple a schedule of available spectrum for the Device at multiple
locations. locations.
+---------------------------------------+ +---------------------------------------+
|AVAIL_SPECTRUM_BATCH_RESP | |AVAIL_SPECTRUM_BATCH_RESP |
+----------------------------+----------+ +----------------------------+----------+
|timestamp:string | required | |timestamp:string | required |
|deviceDesc:DeviceDescriptor | required | |deviceDesc:DeviceDescriptor | required |
|geoSpectrumSchedules:list | required |-------+ |geoSpectrumSchedules:list | required |-------+
|needsSpectrumReport:bool | optional | | |needsSpectrumReport:bool | optional | |
|maxTotalBwHz:float | optional | | |maxTotalBwHz:float | optional | |
|maxContiguousBwHz:float | optional | | |maxContiguousBwHz:float | optional | |
|rulesetInfo:RulesetInfo | optional | | |rulesetInfo:RulesetInfo | optional | |
|............................|..........| | |............................|..........| |
|databaseChange:DbUpdateSpec | optional | | |databaseChange:DbUpdateSpec | optional | |
|*other:any | depends | |
+----------------------------+----------+ | 0..* +----------------------------+----------+ | 0..*
V V
+---------------------------------+ +---------------------------------+
|GeoSpectrumSchedule | |GeoSpectrumSchedule |
+----------------------+----------+ +----------------------+----------+
|location:GeoLocation | required | |location:GeoLocation | required |
|spectrumSchedule:list | required | |spectrumSchedule:list | required |
+----------------------+----------+ +----------------------+----------+
Parameters: Parameters:
skipping to change at page 21, line 45 skipping to change at page 24, line 4
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 more than one
GeoSpectrumSchedule (Section 6.8.13) to represent future changes GeoSpectrumSchedule (Section 6.8.13) to represent future changes
to the available spectrum. How far in advance a schedule may be to the available spectrum. How far in advance a schedule may be
provided depends on the regulatory domain. The Database MAY provided depends on the regulatory domain. The Database MAY
return available spectrum for fewer locations than requested. The return available spectrum for fewer locations than requested. The
Device MUST NOT make any assumptions on the order of the entries Device MUST NOT make any assumptions on the order of the entries
in the list and MUST use the location value in each in the list and MUST use the location value in each
GeoSpectrumSchedule entry to match available spectrum to a GeoSpectrumSchedule entry to match available spectrum to a
location. location.
needsSpectrumReport: For regulatory domains that require a spectrum- needsSpectrumReport: For regulatory domains that require a spectrum-
usage report from devices, the Database MUST return true for this usage report from devices, the Database MUST return true for this
parameter. The default value is false. parameter. The default value is false. If this parameter is
true, the Device MUST send a SPECTRUM_USE_NOTIFY (Section 4.4.5)
message to the Database.
maxTotalBwHz: The Database MAY return a constraint on the maximum maxTotalBwHz: The Database MAY return a constraint on the maximum
total bandwidth (in Hertz) allowed, which may or may not be total bandwidth (in Hertz) allowed, which may or may not be
contiguous. A regulatory domain MAY require the Database to contiguous. A regulatory domain MAY require the Database to
return this parameter. When present in the response, the Device return this parameter. When present in the response, the Device
MUST apply this constraint to its spectrum-selection logic to MUST apply this constraint to its spectrum-selection logic to
ensure total bandwidth does not exceed this value. ensure total bandwidth does not exceed this value.
maxContiguousBwHz The Database MAY return a constraint on the maxContiguousBwHz The Database MAY return a constraint on the
maximum contiguous bandwidth (in Hertz) allowed. A regulatory maximum contiguous bandwidth (in Hertz) allowed. A regulatory
domain MAY require this Database to return this parameter. When domain MAY require this Database to return this parameter. When
present in the response, the Device MUST apply this constraint to present in the response, the Device MUST apply this constraint to
skipping to change at page 22, line 21 skipping to change at page 24, line 32
rulesetInfo: The Database SHOULD return the RulesetInfo rulesetInfo: The Database SHOULD return the RulesetInfo
(Section 6.8.6) parameter that identifies the applicable (Section 6.8.6) parameter that identifies the applicable
regulatory authority and rule set for the response (see Ruleset ID regulatory authority and rule set for the response (see Ruleset ID
Registry (Section 9.2)). If included, the Device MUST use the Registry (Section 9.2)). If included, the Device MUST use the
corresponding rule set to interpret the response. Values provided corresponding rule set to interpret the response. Values provided
within this parameter, such as maxLocationChange, take precedence within this parameter, such as maxLocationChange, take precedence
over the values provided by the Initialization Procedure over the values provided by the Initialization Procedure
(Section 4.2). (Section 4.2).
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) parameter to notify the Device of a change to the (Section 5.7) parameter to notify the Device of a change to the
Database URI. When a Database plans to cease operation, it SHOULD Database URI, providing one or more alternate database URIs. The
return this parameter to provide devices with one or more Device SHOULD use the information to update its list of
alternate database URIs. The Device SHOULD use the information to preconfigured databases to replace (only) its entry for the
update its list of preconfigured databases. responding database with the list of alternate URIs.
other: Database implementations MAY return addtional parameters in
the response. Consult the PAWS Parameters Registry (Section 9.1)
for possible additional parameters and requirements they place on
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.
+---------------------------------------+ +---------------------------------------+
skipping to change at page 25, line 7 skipping to change at page 27, line 25
|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.
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 | |
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.14) 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
(Section 5.7) parameter to notify the Device of a change to the
Database URI, providing one or more alternate database URIs. 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 URIs.
5. Protocol Parameters 5. Protocol Parameters
This section presents more details of the parameters that make up the This section presents more details of the parameters that make up the
PAWS request and response messages. It also includes a sub-section PAWS request and response messages. It also includes a sub-section
defining response codes. defining response codes.
5.1. GeoLocation 5.1. GeoLocation
This parameter is used to specify the geo-location of the Device. It This parameter is used to specify the geo-location of the Device. It
skipping to change at page 31, line 26 skipping to change at page 33, line 51
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 use a 2-letter country the rule set applies is REQUIRED. It MUST use 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
MAY use this MAY use this
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 stop operation in spectrum that is no longer available, it MUST immediately cease
those frequencies immediately. If this value is provided within use of the spectrum under rules for database-managed spectrum. If
the context of an Available Spectrum Response (Section 4.4.2), it this value is provided within the context of an Available Spectrum
takes precedence over the value within the Initialization Response (Section 4.4.2), it takes precedence over the value
Response. within the Initialization Response.
maxPollingSecs: The maximum duration, in seconds, between requests maxPollingSecs: The maximum duration, in seconds, between requests
for available spectrum is REQUIRED for the Initialization Response for available spectrum is REQUIRED for the Initialization Response
(Section 4.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 stop Device is using spectrum that is no longer available, it MUST
operation in those frequencies immediately. If this value is immediately cease use of those frequencies under rules for
provided within the context of an Available Spectrum Response database-managed spectrum. If this value is provided within the
(Section 4.4.2), it takes precedence over the value within the context of an Available Spectrum Response (Section 4.4.2), it
Initialization Response. takes precedence over the value within the Initialization
Response.
rulesetIds: Within the context of the Initialization Response rulesetIds: Within the context of the Initialization Response
(Section 4.2.2), the Database SHOULD return the identifier of one (Section 4.2.2), the Database SHOULD return the identifier of one
or more applicable rule sets (see Ruleset ID Registry or more applicable rule sets (see Ruleset ID Registry
(Section 9.2)) it supports for the device's location. The Device (Section 9.2)) it supports for the device's location. The Device
MAY use the rule-set identifiers to determine parameters to MAY use the rule-set identifiers to determine parameters to
include in subsequent requests. Within the context of the include in subsequent requests. Within the context of the
Available Spectrum (Section 4.4.2) responses, the Database SHOULD Available Spectrum (Section 4.4.2) responses, the Database SHOULD
return the identifier of the rule set that corresponds to the return the identifier of the rule set that corresponds to the
available-spectrum response. If included, the Device MUST use the available-spectrum response. If included, the Device MUST use the
corresponding rule set to interpret the response. If the Device corresponding rule set to interpret the response. If the Device
does not support the indicated rule set, it MUST NOT operate in does not support the indicated rule set, it MUST NOT operate in
white space spectrum. 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.7. 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 URI (See Available Spectrum Response upcoming change to the Database URI (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)). A Device SHOULD use this information to update its (Section 4.4.4)). A Device SHOULD use this information to update its
skipping to change at page 37, line 22 skipping to change at page 39, line 46
---- ---------------- ----------------------------------------------- ---- ---------------- -----------------------------------------------
-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. coverage area of the Database. The Database
MAY include a list of alternate databases that
might be appropriate for the requested
location.
-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
devices with one or more alternate database
URIs. 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 database
URIs.
-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. from the Device.
-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
skipping to change at page 37, line 45 skipping to change at page 40, line 36
-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. REQUIRED Error 5.15.1. OUTSIDE_COVERAGE Error
When the error code is REQUIRED, the Error element MUST include a When the error code is OUTSIDE_COVERAGE, the Database MAY include an
Parameters element as its "data" field. ErrorData element within its Error response as the "data" field, and,
if present, the ErrorData MAY include a list of DatabaseSpec
(Section 5.8) entries that might be appropriate for the requested
location.
+---------------------------+
|Error |
+----------------+----------+
|code:int | required |
|message:string | optional | +-----------------------------+
|data:ErrorData | optional |--->|ErrorData |
+----------------+----------+ +------------------+----------+
|databases:list | optional |
+------------------+----------+
5.15.2. DATABASE_CHANGE Error
When the error code is DATABASE_CHANGE, the Database MAY include an
ErrorData element within its Error response as the "data" field, and,
if present, the ErrorData MUST include a DbUpdateSpec (Section 5.7)
element that provides a list of alternate databases.
+---------------------------+
|Error |
+----------------+----------+
|code:int | required |
|message:string | optional | +-----------------------------+
|data:ErrorData | optional |--->|ErrorData |
+----------------+----------+ +------------------+----------+
|spec:DbUpdateSpec | required |
+------------------+----------+
5.15.3. REQUIRED Error
When the error code is REQUIRED, the Database MUST include an
ErrorData element within its Error response as the "data" field, and
the ErrorData element MUST include a list of the missing required
parameters and MAY include the list of all required parameters.
+---------------------------+ +---------------------------+
|Error | |Error |
+----------------+----------+ +----------------+----------+
|code:int | required | |code:int | required |
|message:string | optional | +---------------------------+ |message:string | optional | +---------------------------+
|data:Parameters | optional |--->|Parameters | |data:ErrorData | optional |--->|ErrorData |
+----------------+----------+ +----------------+----------+ +----------------+----------+ +----------------+----------+
|parameters:list | required | |parameters:list | required |
|...........................|
|*other:any | optional |
+----------------+----------+ +----------------+----------+
Parameters: Parameters:
parameters List of parameter names. The name of a parameter SHOULD parameters List of parameter names. The name of a parameter SHOULD
be expressed using dotted notation, when appropriate, e.g., be expressed using dotted notation, when appropriate, e.g.,
"deviceDesc.serialNumber". "deviceDesc.serialNumber".
other The Database MAY include other parameters. The Device MUST
ignore all parameters it does not understand.
6. Message Encoding 6. Message Encoding
The PAWS protocol is encoded using JSON-RPC [JSON-RPC] (see also The PAWS protocol is encoded using JSON-RPC [JSON-RPC] (see also
JavaScript Object Notation (JSON) [RFC4627]). Each component JavaScript Object Notation (JSON) [RFC4627]). Each component
described in Protocol Functionalities (Section 4) corresponds to one described in Protocol Functionalities (Section 4) corresponds to one
or more JSON-RPC methods. This section provides the JSON schema for or more JSON-RPC methods. This section provides the JSON schema for
each of the protocol messages and parameters defined in sections each of the protocol messages and parameters defined in sections
Protocol Functionalities (Section 4) and Protocol Parameters Protocol Functionalities (Section 4) and Protocol Parameters
(Section 5). JSON schemas are presented in accordance with A JSON (Section 5). JSON schemas are presented in accordance with A JSON
skipping to change at page 38, line 50 skipping to change at page 42, line 21
6.1. JSON-RPC Binding 6.1. JSON-RPC Binding
The JSON-RPC [JSON-RPC] protocol consists of two basic objects, The JSON-RPC [JSON-RPC] protocol consists of two basic objects,
Request and Response: Request and Response:
o The JSON-RPC Request object encapsulates a PAWS functionality o The JSON-RPC Request object encapsulates a PAWS functionality
(operation) and the request message (operation) and the request message
o The JSON-RPC Response object encapsulates a PAWS response message o The JSON-RPC Response object encapsulates a PAWS response message
and Error element and Error element
The JSON-RPC Request for PAWS has the following form: The Database and Device MUST be able to handle both JSON-RPC v1.0 and
v2.0 formats, which differ only with the addition of the "jsonrpc"
parameter.
{ The JSON-RPC Request for PAWS has the following the following forms:
"method": string,
"params": <PAWS_REQ>, {
"id": string { "jsonrpc": "2.0",
} "method": string, "method": string,
"params": <PAWS_REQ>, "params": <PAWS_REQ>,
"id": string "id": string
} }
where "method" is the name of a PAWS functionality (operation), and where "method" is the name of a PAWS functionality (operation), and
<PAWS_REQ> represents one of the PAWS request objects associated with <PAWS_REQ> represents one of the PAWS request objects associated with
the method. Method names are defined with the prefix, the method. Method names are defined with the prefix,
"spectrum.paws.". "spectrum.paws.".
The non-error JSON-RPC Response for PAWS has the following form: The non-error JSON-RPC Response for PAWS has the following forms:
{ {
"result": <PAWS_RESP>, { "jsonrpc": "2.0",
"id": string "result": <PAWS_RESP>, "result": <PAWS_RESP>,
} "id": string "id": string
} }
where <PAWS_RESP> represents one of the PAWS response objects where <PAWS_RESP> represents one of the PAWS response objects
associated with the method. associated with the method.
The error JSON-RPC Response for PAWS has the following form: The error JSON-RPC Response for PAWS has the following form:
{ {
"error": { { "jsonrpc": "2.0",
"code": integer, "error": { "error": {
"message": string, "code": integer, "code": integer,
"data": object, "message": string, "message": string,
}, "data": object, "data": object,
"id": string }, },
} "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.15).
Depending on prior arrangement between a Database and Device, the Depending on prior arrangement between a Database and Device, the
Request and Response MAY contain additional parameters. The Database Request and Response objects MAY contain additional parameters. The
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
skipping to change at page 41, line 27 skipping to change at page 45, line 25
"version": { "version": {
"type": "string", "type": "string",
"required": true "required": true
}, },
"rulesetInfo": { "rulesetInfo": {
"type": "RulesetInfo", "type": "RulesetInfo",
"description": "Indicates the active regulatory domain and " + "description": "Indicates the active regulatory domain and " +
"attributes that define the applicable rule set that " + "attributes that define the applicable rule set that " +
"govern the device", "govern the device",
"required": true "required": true
},
"databaseChange": {
"type": "DbUpdateSpec",
"description": "Indicates that the Database URI will be " +
"changing. Devices need to update their configurations",
"required": false
} }
} }
} }
Example "init" JSON-RPC response: Example "init" JSON-RPC response:
{ {
"result": { "result": {
"type": "INIT_RESP", "type": "INIT_RESP",
"version": "1.0", "version": "1.0",
skipping to change at page 44, line 13 skipping to change at page 48, line 13
schema: schema:
{ {
"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
},
"databaseChange": {
"type": "DbUpdateSpec",
"description": "Indicates that the Database URI will be " +
"changing. Devices need to update their configurations",
"required": false
} }
} }
} }
Example "register" JSON-RPC response: Example "register" JSON-RPC response:
{ {
"result": { "result": {
"type": "REGISTRATION_RESP", "type": "REGISTRATION_RESP",
"version": "1.0" "version": "1.0"
skipping to change at page 45, line 16 skipping to change at page 49, line 9
"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",
"required":true "description": "Descriptor of the device for which to " +
"determine available spectrum.",
"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.",
"required": false "required": false
}, },
"antenna": { "antenna": {
skipping to change at page 45, line 46 skipping to change at page 49, line 41
"registered or if the DB does not implement a separate " + "registered or if the DB does not implement a separate " +
"device-registration request. Also depends on device type " + "device-registration request. Also depends on device type " +
"and regulatory domain", "and regulatory domain",
"required": false "required": false
}, },
"capabilities": { "capabilities": {
"type": "DeviceCapabilities", "type": "DeviceCapabilities",
"description": "The Database SHOULD NOT return spectrum that " + "description": "The Database SHOULD NOT return spectrum that " +
"is incompatible with the specified capabilities.", "is incompatible with the specified capabilities.",
"required": false "required": false
},
"masterDeviceDesc": {
"type": "DeviceDescriptor",
"description": "When the request is make by a Master Device " +
"on behalf of a Slave Device, this is the descriptor of " +
"the Master Device.",
"required":true
},
"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:
{ {
"method": "spectrum.paws.getSpectrum", "method": "spectrum.paws.getSpectrum",
"params": { "params": {
"type": "AVAIL_SPECTRUM_REQ", "type": "AVAIL_SPECTRUM_REQ",
skipping to change at page 50, line 16 skipping to change at page 53, line 38
"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": { "deviceDesc": {
"type": "DeviceDescriptor", "type": "DeviceDescriptor",
"description": "Descriptor of the device for which to " +
"determine available spectrum.",
"required": true "required": true
}, },
"locations": { "locations": {
"type": "array", "type": "array",
"description": "At least one device location is required. " + "description": "At least one device location is required. " +
"Additional (anticipated) locations can also be included, " + "Additional (anticipated) locations can also be included, " +
"as permitted by regulatory domain,", "as permitted by regulatory domain,",
"items": "GeoLocation", "items": "GeoLocation",
"required": true "required": true
}, },
skipping to change at page 50, line 46 skipping to change at page 54, line 22
"registered or if the DB does not implement a separate " + "registered or if the DB does not implement a separate " +
"device-registration request. Also depends on device type " + "device-registration request. Also depends on device type " +
"and regulatory domain", "and regulatory domain",
"required": false "required": false
}, },
"capabilities": { "capabilities": {
"type": "DeviceCapabilities", "type": "DeviceCapabilities",
"description": "The Database SHOULD NOT return spectrum that " + "description": "The Database SHOULD NOT return spectrum that " +
"is incompatible with the specified capabilities.", "is incompatible with the specified capabilities.",
"required": false "required": false
},
"masterDeviceDesc": {
"type": "DeviceDescriptor",
"description": "When the request is make by a Master Device " +
"on behalf of a Slave Device, this is the descriptor of " +
"the Master Device.",
"required":true
},
"requestType": {
"type": "string",
"description": "Optional value that modifies the request. " +
"Valid values depends on regulatory domain.",
"required": false
} }
} }
} }
Example "getSpectrumBatch" JSON-RPC request: Example "getSpectrumBatch" JSON-RPC request:
{ {
"method": "spectrum.paws.getSpectrumBatch", "method": "spectrum.paws.getSpectrumBatch",
"params": { "params": {
"type": "AVAIL_SPECTRUM_BATCH_REQ", "type": "AVAIL_SPECTRUM_BATCH_REQ",
skipping to change at page 58, line 48 skipping to change at page 63, line 21
"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": {
"type": "DbUpdateSpec",
"description": "Indicates that the Database URI will be " +
"changing. Devices need to update their configurations",
"required": false
} }
} }
} }
Example "verifyDevice" JSON-RPC response: Example "verifyDevice" JSON-RPC response:
{ {
"result": { "result": {
"type": "DEV_VALID_RESP", "type": "DEV_VALID_RESP",
"version": "1.0", "version": "1.0",
skipping to change at page 78, line 37 skipping to change at page 83, line 37
below. below.
9.2.2.1. Federal Communications Commission (FCC) 9.2.2.1. Federal Communications Commission (FCC)
For the additional parameters that start with the "fcc" prefix, see For the additional parameters that start with the "fcc" prefix, see
PAWS Parameters Registry Initial Contents (Section 9.1.2) for more PAWS Parameters Registry Initial Contents (Section 9.1.2) for more
information. information.
Ruleset name: FccTvBandWhiteSpace-2010 Ruleset name: FccTvBandWhiteSpace-2010
Additional message parameters: Additional message parameters:
deviceDesc: The DeviceDescriptor (Section 5.2) parameter is
REQUIRED for Available Spectrum Request (Section 4.4.1) and
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 rule set 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.
Ruleset name: TBD Ruleset name: TBD
Additional message parameters: Additional message parameters:
manufacturerId: Specifies a device's manufacturer's identifier. manufacturerId: Specifies a device's manufacturer's identifier.
It is a required parameter in DeviceDescriptor (Section 5.2). It is a REQUIRED parameter in DeviceDescriptor (Section 5.2).
modelId: Specifies a device's model identifier. It is a required modelId: Specifies a device's model identifier. It is a REQUIRED
parameter in DeviceDescriptor (Section 5.2). parameter in DeviceDescriptor (Section 5.2).
etsiEnDeviceType: Specifies the device's ETSI device type. It is etsiEnDeviceType: Specifies the device's ETSI device type. It is
a required parameter in DeviceDescriptor (Section 5.2). a REQUIRED parameter in DeviceDescriptor (Section 5.2).
etsiEnDeviceEmissionsClass: Specifies the device's ETSI device etsiEnDeviceEmissionsClass: Specifies the device's ETSI device
emissions class. It is a required parameter in emissions class. It is a REQUIRED parameter in
DeviceDescriptor (Section 5.2). DeviceDescriptor (Section 5.2).
etsiEnTechnologyId: Specifies the device's ETSI technology ID. etsiEnTechnologyId: Specifies the device's ETSI technology ID.
It is a required parameter in DeviceDescriptor (Section 5.2). It is a REQUIRED parameter in DeviceDescriptor (Section 5.2).
etsiEnDeviceCategory: Specifies the device's ETSI device etsiEnDeviceCategory: Specifies the device's ETSI device
category. It is a required parameter in DeviceDescriptor category. It is a REQUIRED parameter in DeviceDescriptor
(Section 5.2). (Section 5.2).
requestType: Modifies the available-spectrum request type. It is
an OPTIONAL parameter in the AVAIL_SPECTRUM_REQ (Section 4.4.1)
and AVAIL_SPECTRUM_BATCH_REQ (Section 4.4.3) messages. If
specified, the only valid value is, "Generic Slave", and the
Database MUST respond with generic operating parameters for any
Slave Device.
needsSpectrumReport Depending on the regulatory domain, the needsSpectrumReport Depending on the regulatory domain, the
Database MAY be required to set this value to true in the Database MAY be required to set this value to true in the
AvailSpectrumResponse (Section 4.4.2) and AVAIL_SPECTRUM_RESP (Section 4.4.2) and
AvailSpectrumBatchResponse (Section 4.4.4) messages. AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4) messages.
maxTotalBwHz: Specifies a constraint on total allowed bandwidth. maxTotalBwHz: Specifies a constraint on total allowed bandwidth.
It is a required parameter in AvailSpectrumResponse It is a REQUIRED parameter in AVAIL_SPECTRUM_RESP
(Section 4.4.2) and AvailSpectrumBatchResponse (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
AvailSpectrumResponse (Section 4.4.2) and AVAIL_SPECTRUM_RESP (Section 4.4.2) and
AvailSpectrumBatchResponse (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 AvailSpectrumResponse changes. It is a REQUIRED parameter in AVAIL_SPECTRUM_RESP
(Section 4.4.2) and AvailSpectrumBatchResponse (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 rule set 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
skipping to change at page 85, line 39 skipping to change at page 90, line 50
[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 [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006. JavaScript Object Notation (JSON)", RFC 4627, July 2006.
Appendix A. Changes / Author Notes. Appendix A. Changes / Author Notes.
Changes from 04:
o Add "masterDeviceDesc" parameter to the available-spectrum
requests to allow both Master and Slave device descriptors when
the Master is making the request on behalf of a Slave.
o Add "requestType" parameter to the available-spectrum requests to
support requesting generic operating parameters for any Slave
Device.
o Add DbUpdateSpec as optional parameter to all response messages
and to the error response to allow a Device to detect a database
change at any stage of the control flow.
o For the OUTSIDE_COVERAGE error, added ability to return a list of
alternate databases
o Explicitly allow JSON-RPC v2.0 and v1.0 encodings
o Relaxed language that state, "MUST stop operation" to "MUST cease
use of spectrum under rules for database-managed spectrum". I.e.,
the device may have other fallback strategies allowed by
regulators.
Changes from 03: 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 URIs of databases and database-
listing services, including mechanisms for updating the listing services, 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:
 End of changes. 84 change blocks. 
267 lines changed or deleted 521 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/