draft-ietf-paws-protocol-03.txt   draft-ietf-paws-protocol-04.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: August 17, 2013 Applied Communication Sciences Expires: November 8, 2013 Applied Communication Sciences
L. Zhu L. Zhu
Huawei Huawei
J. Malyar J. Malyar
Telcordia Technologies Inc. iconectiv (formerly Telcordia
Interconnection Solutions)
P. McCann P. McCann
Huawei Huawei
February 13, 2013 May 07, 2013
Protocol to Access Spectrum Database Protocol to Access Spectrum Database
draft-ietf-paws-protocol-03 draft-ietf-paws-protocol-04
Abstract Abstract
Portions of the radio spectrum that are allocated to licensees are Portions of the radio spectrum that are allocated to licensees are
available for non-interfering use. This available spectrum is called available for non-interfering use. This available spectrum is called
"White Space." Allowing secondary users access to available spectrum "White Space." Allowing secondary users access to available spectrum
"unlocks" existing spectrum to maximize its utilization and to "unlocks" existing spectrum to maximize its utilization and to
provide opportunities for innovation, resulting in greater overall provide opportunities for innovation, resulting in greater overall
spectrum utilization. spectrum utilization.
skipping to change at page 1, line 48 skipping to change at page 1, line 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 August 17, 2013. This Internet-Draft will expire on November 8, 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 30 skipping to change at page 2, line 30
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 . . . . . . . . . . . . . . . . . . . 7
4.1. Database Discovery . . . . . . . . . . . . . . . . . . . . 8 4.1. Database Discovery . . . . . . . . . . . . . . . . . . . . 8
4.2. Initialization . . . . . . . . . . . . . . . . . . . . . . 8 4.1.1. Listing Server . . . . . . . . . . . . . . . . . . . . 9
4.2.1. INIT_REQ . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Initialization . . . . . . . . . . . . . . . . . . . . . . 10
4.2.2. INIT_RESP . . . . . . . . . . . . . . . . . . . . . . 9 4.2.1. INIT_REQ . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Device Registration . . . . . . . . . . . . . . . . . . . 10 4.2.2. INIT_RESP . . . . . . . . . . . . . . . . . . . . . . 11
4.3.1. REGISTRATION_REQ . . . . . . . . . . . . . . . . . . . 11 4.3. Device Registration . . . . . . . . . . . . . . . . . . . 12
4.3.2. REGISTRATION_RESP . . . . . . . . . . . . . . . . . . 11 4.3.1. REGISTRATION_REQ . . . . . . . . . . . . . . . . . . . 12
4.4. Available Spectrum Query . . . . . . . . . . . . . . . . . 12 4.3.2. REGISTRATION_RESP . . . . . . . . . . . . . . . . . . 13
4.4.1. AVAIL_SPECTRUM_REQ . . . . . . . . . . . . . . . . . . 14 4.4. Available Spectrum Query . . . . . . . . . . . . . . . . . 13
4.4.2. AVAIL_SPECTRUM_RESP . . . . . . . . . . . . . . . . . 15 4.4.1. AVAIL_SPECTRUM_REQ . . . . . . . . . . . . . . . . . . 16
4.4.3. AVAIL_SPECTRUM_BATCH_REQ . . . . . . . . . . . . . . . 17 4.4.2. AVAIL_SPECTRUM_RESP . . . . . . . . . . . . . . . . . 17
4.4.4. AVAIL_SPECTRUM_BATCH_RESP . . . . . . . . . . . . . . 18 4.4.3. AVAIL_SPECTRUM_BATCH_REQ . . . . . . . . . . . . . . . 19
4.4.5. SPECTRUM_USE_NOTIFY . . . . . . . . . . . . . . . . . 20 4.4.4. AVAIL_SPECTRUM_BATCH_RESP . . . . . . . . . . . . . . 20
4.4.6. SPECTRUM_USE_RESP . . . . . . . . . . . . . . . . . . 21 4.4.5. SPECTRUM_USE_NOTIFY . . . . . . . . . . . . . . . . . 22
4.5. Device Validation . . . . . . . . . . . . . . . . . . . . 21 4.4.6. SPECTRUM_USE_RESP . . . . . . . . . . . . . . . . . . 23
4.5.1. DEV_VALID_REQ . . . . . . . . . . . . . . . . . . . . 22 4.5. Device Validation . . . . . . . . . . . . . . . . . . . . 23
4.5.2. DEV_VALID_RESP . . . . . . . . . . . . . . . . . . . . 23 4.5.1. DEV_VALID_REQ . . . . . . . . . . . . . . . . . . . . 24
5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 23 4.5.2. DEV_VALID_RESP . . . . . . . . . . . . . . . . . . . . 25
5.1. GeoLocation . . . . . . . . . . . . . . . . . . . . . . . 23 5. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 25
5.2. DeviceDescriptor . . . . . . . . . . . . . . . . . . . . . 25 5.1. GeoLocation . . . . . . . . . . . . . . . . . . . . . . . 25
5.3. AntennaCharacteristics . . . . . . . . . . . . . . . . . . 26 5.2. DeviceDescriptor . . . . . . . . . . . . . . . . . . . . . 27
5.4. DeviceCapabilities . . . . . . . . . . . . . . . . . . . . 27 5.3. AntennaCharacteristics . . . . . . . . . . . . . . . . . . 28
5.5. DeviceOwner . . . . . . . . . . . . . . . . . . . . . . . 27 5.4. DeviceCapabilities . . . . . . . . . . . . . . . . . . . . 29
5.6. RulesetInfo . . . . . . . . . . . . . . . . . . . . . . . 28 5.5. DeviceOwner . . . . . . . . . . . . . . . . . . . . . . . 30
5.7. Spectrum . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.6. RulesetInfo . . . . . . . . . . . . . . . . . . . . . . . 30
5.8. FrequencyRange . . . . . . . . . . . . . . . . . . . . . . 29 5.7. DbUpdateSpec . . . . . . . . . . . . . . . . . . . . . . . 32
5.9. EventTime . . . . . . . . . . . . . . . . . . . . . . . . 30 5.8. DatabaseSpec . . . . . . . . . . . . . . . . . . . . . . . 32
5.10. SpectrumSchedule . . . . . . . . . . . . . . . . . . . . . 30 5.9. Spectrum . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.11. GeoSpectrumSchedule . . . . . . . . . . . . . . . . . . . 31 5.10. FrequencyRange . . . . . . . . . . . . . . . . . . . . . . 33
5.12. DeviceValidity . . . . . . . . . . . . . . . . . . . . . . 31 5.11. EventTime . . . . . . . . . . . . . . . . . . . . . . . . 34
5.13. Error Element . . . . . . . . . . . . . . . . . . . . . . 32 5.12. SpectrumSchedule . . . . . . . . . . . . . . . . . . . . . 34
5.13.1. REQUIRED Error . . . . . . . . . . . . . . . . . . . . 33 5.13. GeoSpectrumSchedule . . . . . . . . . . . . . . . . . . . 35
6. Message Encoding . . . . . . . . . . . . . . . . . . . . . . . 34 5.14. DeviceValidity . . . . . . . . . . . . . . . . . . . . . . 36
6.1. JSON-RPC Binding . . . . . . . . . . . . . . . . . . . . . 34 5.15. Error Element . . . . . . . . . . . . . . . . . . . . . . 36
6.2. init Method . . . . . . . . . . . . . . . . . . . . . . . 35 5.15.1. REQUIRED Error . . . . . . . . . . . . . . . . . . . . 37
6.2.1. INIT_REQ Parameters . . . . . . . . . . . . . . . . . 35 6. Message Encoding . . . . . . . . . . . . . . . . . . . . . . . 38
6.2.2. INIT_RESP Parameters . . . . . . . . . . . . . . . . . 37 6.1. JSON-RPC Binding . . . . . . . . . . . . . . . . . . . . . 38
6.3. register Method . . . . . . . . . . . . . . . . . . . . . 37 6.2. init Method . . . . . . . . . . . . . . . . . . . . . . . 39
6.3.1. REGISTRATION_REQ Parameters . . . . . . . . . . . . . 37 6.2.1. INIT_REQ Parameters . . . . . . . . . . . . . . . . . 40
6.3.2. REGISTRATION_RESP Parameters . . . . . . . . . . . . . 39 6.2.2. INIT_RESP Parameters . . . . . . . . . . . . . . . . . 41
6.4. getSpectrum Method . . . . . . . . . . . . . . . . . . . . 40 6.3. register Method . . . . . . . . . . . . . . . . . . . . . 41
6.4.1. AVAILABLE_SPECTRUM_REQ Parameters . . . . . . . . . . 40 6.3.1. REGISTRATION_REQ Parameters . . . . . . . . . . . . . 42
6.4.2. AVAIL_SPECTRUM_RESP Parameters . . . . . . . . . . . . 42 6.3.2. REGISTRATION_RESP Parameters . . . . . . . . . . . . . 43
6.5. getSpectrumBatch Method . . . . . . . . . . . . . . . . . 45 6.4. getSpectrum Method . . . . . . . . . . . . . . . . . . . . 44
6.5.1. AVAIL_SPECTRUM_BATCH_REQ Parameters . . . . . . . . . 45 6.4.1. AVAIL_SPECTRUM_REQ Parameters . . . . . . . . . . . . 44
6.5.2. AVAIL_SPECTRUM_BATCH_RESP Parameters . . . . . . . . . 47 6.4.2. AVAIL_SPECTRUM_RESP Parameters . . . . . . . . . . . . 46
6.6. notifySpectrumUse Method . . . . . . . . . . . . . . . . . 50 6.5. getSpectrumBatch Method . . . . . . . . . . . . . . . . . 49
6.6.1. SPECTRUM_USE_NOTIFY Parameters . . . . . . . . . . . . 50 6.5.1. AVAIL_SPECTRUM_BATCH_REQ Parameters . . . . . . . . . 49
6.6.2. SPECTRUM_USE_RESP Parameters . . . . . . . . . . . . . 52 6.5.2. AVAIL_SPECTRUM_BATCH_RESP Parameters . . . . . . . . . 51
6.7. verifyDevice Method . . . . . . . . . . . . . . . . . . . 53 6.6. notifySpectrumUse Method . . . . . . . . . . . . . . . . . 54
6.7.1. DEV_VALID_REQ Parameters . . . . . . . . . . . . . . . 53 6.6.1. SPECTRUM_USE_NOTIFY Parameters . . . . . . . . . . . . 54
6.7.2. DEV_VALID_RESP Parameters . . . . . . . . . . . . . . 54 6.6.2. SPECTRUM_USE_RESP Parameters . . . . . . . . . . . . . 56
6.8. Sub-message Schemas . . . . . . . . . . . . . . . . . . . 55 6.7. verifyDevice Method . . . . . . . . . . . . . . . . . . . 57
6.8.1. GeoLocation . . . . . . . . . . . . . . . . . . . . . 55 6.7.1. DEV_VALID_REQ Parameters . . . . . . . . . . . . . . . 57
6.8.2. DeviceDescriptor . . . . . . . . . . . . . . . . . . . 57 6.7.2. DEV_VALID_RESP Parameters . . . . . . . . . . . . . . 58
6.8.3. AntennaCharacteristics . . . . . . . . . . . . . . . . 58 6.8. Sub-message Schemas . . . . . . . . . . . . . . . . . . . 59
6.8.4. DeviceCapabilities . . . . . . . . . . . . . . . . . . 59 6.8.1. GeoLocation . . . . . . . . . . . . . . . . . . . . . 59
6.8.5. DeviceOwner . . . . . . . . . . . . . . . . . . . . . 60 6.8.2. DeviceDescriptor . . . . . . . . . . . . . . . . . . . 61
6.8.6. RulesetInfo . . . . . . . . . . . . . . . . . . . . . 61 6.8.3. AntennaCharacteristics . . . . . . . . . . . . . . . . 62
6.8.7. Spectrum . . . . . . . . . . . . . . . . . . . . . . . 62 6.8.4. DeviceCapabilities . . . . . . . . . . . . . . . . . . 63
6.8.8. FrequencyRange . . . . . . . . . . . . . . . . . . . . 63 6.8.5. DeviceOwner . . . . . . . . . . . . . . . . . . . . . 64
6.8.9. EventTime . . . . . . . . . . . . . . . . . . . . . . 64 6.8.6. RulesetInfo . . . . . . . . . . . . . . . . . . . . . 65
6.8.10. SpectrumSchedule . . . . . . . . . . . . . . . . . . . 65 6.8.7. DbUpdateSpec . . . . . . . . . . . . . . . . . . . . . 66
6.8.11. GeoSpectrumSchedule . . . . . . . . . . . . . . . . . 66 6.8.8. DatabaseSpec . . . . . . . . . . . . . . . . . . . . . 67
6.8.12. DeviceValidity . . . . . . . . . . . . . . . . . . . . 66 6.8.9. Spectrum . . . . . . . . . . . . . . . . . . . . . . . 67
6.8.13. Additional Properties . . . . . . . . . . . . . . . . 67 6.8.10. FrequencyRange . . . . . . . . . . . . . . . . . . . . 68
7. HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . . . 67 6.8.11. EventTime . . . . . . . . . . . . . . . . . . . . . . 69
8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 68 6.8.12. SpectrumSchedule . . . . . . . . . . . . . . . . . . . 70
8.1. Defining New Message Parameters . . . . . . . . . . . . . 68 6.8.13. GeoSpectrumSchedule . . . . . . . . . . . . . . . . . 71
8.2. Defining Ruleset Identifiers . . . . . . . . . . . . . . . 69 6.8.14. DeviceValidity . . . . . . . . . . . . . . . . . . . . 71
8.3. Defining Additional Error Codes . . . . . . . . . . . . . 69 6.8.15. Additional Properties . . . . . . . . . . . . . . . . 72
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 7. HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . . . 72
9.1. PAWS Parameters Registry . . . . . . . . . . . . . . . . . 70 8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 73
9.1.1. Registration Template . . . . . . . . . . . . . . . . 70 8.1. Defining New Message Parameters . . . . . . . . . . . . . 73
9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 70 8.2. Defining Ruleset Identifiers . . . . . . . . . . . . . . . 74
9.2. PAWS Ruleset ID Registry . . . . . . . . . . . . . . . . . 71 8.3. Defining Additional Error Codes . . . . . . . . . . . . . 74
9.2.1. Registration Template . . . . . . . . . . . . . . . . 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75
9.2.2. Initial Registry Contents . . . . . . . . . . . . . . 72 9.1. PAWS Parameters Registry . . . . . . . . . . . . . . . . . 75
9.3. PAWS Error Code Registry . . . . . . . . . . . . . . . . . 72 9.1.1. Registration Template . . . . . . . . . . . . . . . . 75
9.3.1. Registration Template . . . . . . . . . . . . . . . . 73 9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 76
9.3.2. Initial Registry Contents . . . . . . . . . . . . . . 73 9.2. PAWS Ruleset ID Registry . . . . . . . . . . . . . . . . . 77
10. Security Considerations . . . . . . . . . . . . . . . . . . . 73 9.2.1. Registration Template . . . . . . . . . . . . . . . . 78
10.1. Assurance of Proper Database . . . . . . . . . . . . . . . 74 9.2.2. Initial Registry Contents . . . . . . . . . . . . . . 78
10.2. Protection Against Modification . . . . . . . . . . . . . 74 9.3. PAWS Error Code Registry . . . . . . . . . . . . . . . . . 79
10.3. Protection Against Eavesdropping . . . . . . . . . . . . . 75 9.3.1. Registration Template . . . . . . . . . . . . . . . . 80
10.4. Client Authentication Considerations . . . . . . . . . . . 75 9.3.2. Initial Registry Contents . . . . . . . . . . . . . . 80
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 80
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 76 10.1. Assurance of Proper Database . . . . . . . . . . . . . . . 81
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 76 10.2. Protection Against Modification . . . . . . . . . . . . . 81
13.1. Normative References . . . . . . . . . . . . . . . . . . . 76 10.3. Protection Against Eavesdropping . . . . . . . . . . . . . 82
13.2. Informative References . . . . . . . . . . . . . . . . . . 77 10.4. Client Authentication Considerations . . . . . . . . . . . 82
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . . 78 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 82
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 78 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 83
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 83
13.1. Normative References . . . . . . . . . . . . . . . . . . . 83
13.2. Informative References . . . . . . . . . . . . . . . . . . 84
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . . 85
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 87
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.
ETSI: European Telecommunications Standards Institute
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.
RAT: Radio Access Technology
3. Protocol Overview 3. Protocol Overview
A Master Device uses the PAWS protocol to obtain a schedule of A Master Device uses the PAWS protocol to obtain a schedule of
available spectrum at its location. The security necessary to ensure available spectrum at its location. The security necessary to ensure
the accuracy, privacy, and confidentiality of the Device's location the accuracy, privacy, and confidentiality of the Device's location
is described in the Security Considerations (Section 10). This is described in the Security Considerations (Section 10). This
document assumes that the Master Device and the Database are document assumes that the Master Device and the Database are
connected to the Internet. connected to the Internet.
A typical sequence of PAWS operations is outlined as follows. See A typical sequence of PAWS operations is outlined as follows. See
Protocol Functionalities (Section 4) and Protocol Parameters Protocol Functionalities (Section 4) and Protocol Parameters
(Section 5) for details: (Section 5) for details:
1. The Master Device locates or discovers the regulatory domain for 1. The Master Device obtains (statically or dynamically) the URI
its location and the URI for the Database to send subsequent for a Database appropriate for its location to send subsequent
PAWS messages. [Editor's Note: It is an open item whether PAWS messages.
database discovery should be a separate document.]
2. The Master Device establishes an HTTPS session with the 2. The Master Device establishes an HTTPS session with the
Database. Database.
3. The Master Device optionally sends an initialization message to 3. The Master Device optionally sends an initialization message to
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 the Master Device is obtaining the schedule on behalf of a 7. If required by the regulatory domain, the Master Device must
Slave Device, and if required by the regulatory domain, the verify with the Database that the Slave Device valid.
Database validates the Slave Device.
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:
1. The Master Device includes in its request the identifier of one 1. The Master Device includes in its request its location and
or more of the rule sets it supports optionally includes the identifier of one or more of the rule
sets it supports and any parameter values it might need for the
request
2. The Database may use the rule-set list to determine its response, 2. The Database may use the rule-set list to determine its response,
for example, to select the list of required parameters for example, to select the list of required parameters
3. If required parameters are missing from the request, the Database 3. If required parameters are missing from the request, the Database
responds with a REQUIRED error and a list of the missing responds with a REQUIRED error and a list of names of the missing
parameters parameters
4. The Master Device makes the request again, adding the missing 4. The Master Device makes the request again, adding the missing
parameters parameter values
5. The Database responds to the request, including the identifier of 5. The Database responds to the request, including the identifier of
the applicable rule set the applicable rule set
6. The Master Device uses the indicated rule set to determine how to 6. The Master Device uses the indicated rule set to determine how to
interpret the Database response interpret the Database response
NOTE: Regulatory rules contain many device-only requirements that NOTE: Regulatory rules contain many device-only requirements that
govern device behavior, independent of any database rules. These govern device behavior, independent of any database rules. These
requirements may be complex and involve device behavior that are not requirements may be complex and involve device behavior that are not
easily parameterized. The ruleset-id parameter provides a mechanism easily parameterized. The ruleset-id parameter provides a mechanism
for the Database to inform the Master Device of the applicable rule for the Database to inform the Master Device of the applicable rule
set without having to express device-side behavior within the set without having to express device-side behavior within the
protocol. The rule-set identifier could be a string that contains protocol. The rule-set identifier is a string value that contains
the entity that established the rules and version information, such the name of regulatory body that established the rules and version
as "FccTvBandWhiteSpace-2010". information, such as "FccTvBandWhiteSpace-2010".
By separating the regulatory "authority" from the "ruleset-id", it By separating the regulatory "authority" from the "ruleset-id", it
allows the protocol to support multiple regulatory authorities that allows the protocol to support multiple regulatory authorities that
use the same device-side rule set. It also allows support for a use the same device-side rule set. It also allows support for a
single authority to define multiple rule sets. single authority to define multiple rule sets.
4. Protocol Functionalities 4. Protocol Functionalities
The PAWS protocol consists of several components: The PAWS protocol consists of several components:
skipping to change at page 8, line 20 skipping to change at page 8, line 22
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 and MUST be implemented by the Database if the regulatory domain
requires device validation. requires device validation.
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
The Device MUST determine the URI for the Database and applicable Different regulators may have different requirements for the approval
regulatory domain before it can send PAWS messages. The URI for the and operation of databases, such as:
Database SHOULD be obtained from an authorized and authenticated
entity, but it MAY be statically configured into the Device. o A regulator may only allow a limited number of certified databases
[Editor's Note: It is an open item whether database discovery should to operate. It also may require the certification of each device-
be a separate document.] to-database pairing.
o A regulator may maintain a trusted website that lists all approved
databases. It also may mandate how devices use the listing
service.
o A regulator may allow each database to define its own terms of
use, so that, for example, an approved device may not be able to
access all approved databases.
Prior to sending PAWS messages, a Device MUST determine the URI for a
Database that provides service at its current location.
o A Device SHOULD support operation in any regulatory environment.
Preconfiguration
The Device MAY be provisioned statically with the URI of one or more
Databases. For operation in regulatory domains that do not have a
listing server, the Device SHOULD be provisioned with the URI of all
the databases for which it is certified or otherwise permitted to
operate. The Device also SHOULD be provisioned with the URI of
listing servers approved by regulators.
Configuration Update
To adapt to changes to the list of certified or approved databases,
the Device SHOULD be able to update its preconfigured lists of
databases. When the preconfigured list of databases is provided by a
listing service, the Device SHOULD check the service periodically to
update its list.
Before a Database ceases operation, it SHOULD indicate its intent to
cease operation in its device responses and SHOULD include the URI of
one or more alternate databases (See DbUpdateSpec (Section 5.7)). A
Device SHOULD be able to update its preconfigured list of databases
with the URIs of the alternate databases
Error Handling
The Device SHOULD select another database from its list of
preconfigured databases if:
o The selected database is unreachable or does not respond.
o The selected database returns an UNSUPPORTED error (see Error
Codes (Section 5.15)), which may indicate that the database does
not support the regulatory domain where the device is located.
If a suitable database cannot be contacted, the Device MUST NOT
operate in white space spectrum. If the Device is already operating
when it fails to contact a suitable database, and if the applicable
regulatory domain provides a grace period, the Device may continue to
operate during such period, but must cease operation at or before the
expiration of the grace period. If a grace period is not provided by
the applicable regulatory domain, an operating Device that fails to
contact a suitable database MUST cease operation immediately.
4.1.1. Listing Server
Within a regulatory domain that has a Database Listing Server, a
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
and SHOULD contact the Database Listing Server periodically to update
its list. The time between such updates SHALL be no longer than one
week, or any update interval required by the applicable regulatory
domain, whichever is shorter.
The Database Listing request procedure is depicted in Figure 1.
o LISTING_REQ is the database-listing request message
o LISTING_RESP is the database-listing response message
+---------------+ +-------------------+
| Master Device | | Listing Server |
+---------------+ +-------------------+
| |
| LISTING_REQ |
|-------------------->|
| |
| LISTING_RESP |
|<--------------------|
| |
Figure 1
Specific message formats are defined by the regulators.
4.2. Initialization 4.2. Initialization
A Master Device SHOULD use the initialization procedure to exchange A Master Device SHOULD use the initialization procedure to exchange
capability information with the Database whenever the Master Device capability information with the Database whenever the Master Device
powers up or initiates communication with the Database. The powers up or initiates communication with the Database. The
initialization response informs the Master Device of specific initialization response informs the Master Device of specific
regulatory-dependent parameterized-rule values, such as threshold regulatory-dependent parameterized-rule values, such as threshold
distances and time periods beyond which the Device must update its distances and time periods beyond which the Device must update its
available-spectrum data (see RuleSetInfo (Section 5.6)). The Master available-spectrum data (see RuleSetInfo (Section 5.6)). The Master
Device MAY manually configure these parameterized-rule values. The Device MAY manually configure these parameterized-rule values. The
initialization message also represents extension points for database initialization message also represents extension points for database
implementations or regulatory domains that require the extra implementations or regulatory domains that require the extra
handshake. handshake.
The Initialization request procedure is depicted in Figure 1. The Initialization request procedure is depicted in Figure 2.
o INIT_REQ (Section 4.2.1) is the initialization request message o INIT_REQ (Section 4.2.1) is the initialization request message
o INIT_RESP (Section 4.2.2) is the initialization response message o INIT_RESP (Section 4.2.2) is the initialization response message
+---------------+ +-------------------+ +---------------+ +-------------------+
| Master Device | | Spectrum Database | | Master Device | | Spectrum Database |
+---------------+ +-------------------+ +---------------+ +-------------------+
| | | |
| INIT_REQ | | INIT_REQ |
|-------------------->| |-------------------->|
| | | |
| INIT_RESP | | INIT_RESP |
|<--------------------| |<--------------------|
| | | |
skipping to change at page 9, line 15 skipping to change at page 10, line 50
| Master Device | | Spectrum Database | | Master Device | | Spectrum Database |
+---------------+ +-------------------+ +---------------+ +-------------------+
| | | |
| INIT_REQ | | INIT_REQ |
|-------------------->| |-------------------->|
| | | |
| INIT_RESP | | INIT_RESP |
|<--------------------| |<--------------------|
| | | |
Figure 1 Figure 2
4.2.1. INIT_REQ 4.2.1. INIT_REQ
The initialization request message allows the Master Device to The initialization request message allows the Master Device to
initiate exchange of capabilities with the Database. initiate exchange of capabilities with the Database.
+---------------------------------------+ +---------------------------------------+
|INIT_REQ | |INIT_REQ |
+----------------------------+----------| +----------------------------+----------|
|deviceDesc:DeviceDescriptor | required | |deviceDesc:DeviceDescriptor | required |
skipping to change at page 10, line 41 skipping to change at page 12, line 25
require that a 'Fixed Device' MUST register its owner and operator require that a 'Fixed Device' MUST register its owner and operator
contact information, its device identifier, its location, and its contact information, its device identifier, its location, and its
antenna height. antenna height.
The Database MAY support device registration as a separate Device The Database MAY support device registration as a separate Device
Registration component, or as part of the Spectrum Availability Registration component, or as part of the Spectrum Availability
component. If the Database does not support a separate Device component. If the Database does not support a separate Device
Registration request, it MUST return an error with the UNIMPLEMENTED Registration request, it MUST return an error with the UNIMPLEMENTED
(Table 1) code in the error-response message. (Table 1) code in the error-response message.
The Device Registration request procedure is depicted in Figure 2. The Device Registration request procedure is depicted in Figure 3.
o REGISTRATION_REQ (Section 4.3.1) is the device-registration o REGISTRATION_REQ (Section 4.3.1) is the device-registration
request message request message
o REGISTRATION_RESP (Section 4.3.2) is the device-registration o REGISTRATION_RESP (Section 4.3.2) is the device-registration
response message response message
+---------------+ +-------------------+ +---------------+ +-------------------+
| Master Device | | Spectrum Database | | Master Device | | Spectrum Database |
+---------------+ +-------------------+ +---------------+ +-------------------+
| | | |
| REGISTRATION_REQ | | REGISTRATION_REQ |
|------------------------>| |------------------------>|
| | | |
| REGISTRATION_RESP | | REGISTRATION_RESP |
|<------------------------| |<------------------------|
| | | |
skipping to change at page 11, line 15 skipping to change at page 12, line 42
| Master Device | | Spectrum Database | | Master Device | | Spectrum Database |
+---------------+ +-------------------+ +---------------+ +-------------------+
| | | |
| REGISTRATION_REQ | | REGISTRATION_REQ |
|------------------------>| |------------------------>|
| | | |
| REGISTRATION_RESP | | REGISTRATION_RESP |
|<------------------------| |<------------------------|
| | | |
Figure 2 Figure 3
4.3.1. REGISTRATION_REQ 4.3.1. REGISTRATION_REQ
The registration request message contains the required registration The registration request message contains the required registration
parameters. parameters.
+---------------------------------------+ +---------------------------------------+
|REGISTRATION_REQ | |REGISTRATION_REQ |
+----------------------------+----------+ +----------------------------+----------+
|deviceDesc:DeviceDescriptor | required | |deviceDesc:DeviceDescriptor | required |
skipping to change at page 11, line 42 skipping to change at page 13, line 25
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 MAY require additional registration
parameters. To simplify its registration logic, the Device MAY parameters. To simplify its registration logic, the Device MAY
send a union of the registration information required by all send a union of the registration information required by all
supported regulatory domains. The Database MUST ignore all supported regulatory domains. The Database MUST ignore all
parameters it does not understand . parameters it does not understand. Consult the PAWS Parameters
Registry 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 |
+--------------------------+----------+ +--------------------------+----------+
skipping to change at page 12, line 20 skipping to change at page 13, line 49
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 what 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 3. 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
multiple locations to be specified in the request multiple locations to be specified in the request
o AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4) is the response message o AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4) is the response message
for the batch version of the available-spectrum request that for the batch version of the available-spectrum request that
skipping to change at page 13, line 23 skipping to change at page 14, line 39
| (AVAIL_SPECTRUM_BATCH_RESP)| | (AVAIL_SPECTRUM_BATCH_RESP)|
|<---------------------------| |<---------------------------|
| | | |
| (SPECTRUM_USE_NOTIFY) | | (SPECTRUM_USE_NOTIFY) |
|--------------------------->| |--------------------------->|
| | | |
| (SPECTRUM_USE_RESP) | | (SPECTRUM_USE_RESP) |
|<---------------------------| |<---------------------------|
| | | |
Figure 3 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
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, the Database MUST respond with an
skipping to change at page 14, line 4 skipping to change at page 15, line 17
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
that devices must report anticipated spectrum usage, the Database that devices must report anticipated spectrum usage, the Database
MUST indicate so in the response message. MUST indicate so in the response message.
6. If the available-spectrum response indicates that the Master 6. If the available-spectrum response indicates that the Master
Device must send a spectrum-usage notification message, the Device must send a spectrum-usage notification message, the
Master Device MUST send the notification message to the Database. Master Device MUST send the notification message to the Database.
7. If the Database receives a spectrum-usage notification message, 7. If the Database receives a spectrum-usage notification message,
it MUST send a spectrum-usage acknowledgment message to the it MUST send a spectrum-usage acknowledgment message to the
Master Device. Master Device.
The procedure for asking for available spectrum on behalf of a Slave The procedure for asking for available spectrum on behalf of a Slave
Device is similar, except that the process is initiated by the Slave Device is similar, except that the process is initiated by the Slave
Device. Also, the device identifier, capabilities, and Device. The device identifier, capabilities, and characteristics
characteristics communicated in the AVAIL_SPECTRUM_REQ message SHALL communicated in the AVAIL_SPECTRUM_REQ message SHALL be those of the
be those of the Slave Device. Although the communication and Slave Device, but the location SHALL be that of the Master Device.
protocol between the Slave Device and Master Device is outside the Although the communication and protocol between the Slave Device and
scope of this document, the expected message sequence is shown in Master Device is outside the scope of this document, the expected
Figure 4. message sequence is shown in Figure 5.
+------------+ +---------------+ +-------------------+ +------------+ +---------------+ +-------------------+
|Slave Device| | Master Device | | Spectrum Database | |Slave Device| | Master Device | | Spectrum Database |
+------------+ +---------------+ +-------------------+ +------------+ +---------------+ +-------------------+
| | | | | |
| AVAIL_SPEC_REQ | | | AVAIL_SPEC_REQ | |
|................>| | |................>| |
| | | | | |
| | AVAIL_SPECTRUM_REQ | | | AVAIL_SPECTRUM_REQ |
| |-------------------------->| | |-------------------------->|
skipping to change at page 14, line 41 skipping to change at page 16, line 25
| | AVAIL_SPECTRUM_RESP | | | AVAIL_SPECTRUM_RESP |
| |<--------------------------| | |<--------------------------|
| | | | | |
| AVAIL_SPEC_RESP | (SPECTRUM_USE_NOTIFY) | | AVAIL_SPEC_RESP | (SPECTRUM_USE_NOTIFY) |
|<................|-------------------------->| |<................|-------------------------->|
| | | | | |
| | (SPECTRUM_USE_RESP) | | | (SPECTRUM_USE_RESP) |
| |<--------------------------| | |<--------------------------|
| | | | | |
Figure 4 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 |
+-------------------------------+------------------------------+ +-------------------------------+------------------------------+
skipping to change at page 15, line 19 skipping to change at page 16, line 47
|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 |
+-------------------------------+------------------------------+ +-------------------------------+------------------------------+
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 Master Device is
The location SHOULD be the current location of the Device, but REQUIRED. The location SHOULD be the current location of the
more precisely, the location of the radiation center of the Device, but more precisely, the location of the radiation center
Device's antenna. Depending on the regulatory domain, the of the Device's antenna. Depending on the regulatory domain, the
location MAY be an anticipated position of the Device to support location MAY be an anticipated position of the Device to support
mobile devices. If the location specifies a region, rather than a mobile devices. If the location specifies a region, rather than a
point, the Database MAY return an error with the UNIMPLEMENTED point, the Database MAY return an error with the UNIMPLEMENTED
(Table 1) code, if it does not support query by region. (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.
skipping to change at page 16, line 12 skipping to change at page 17, line 30
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 | |
|rulesetId:string | optional | | |maxTotalBwHz:float | optional | |
|maxContiguousBwHz:float | optional | |
|rulesetInfo:RulesetInfo | optional | |
|............................|..........| | |............................|..........| |
|location:GeoLocation | optional | | |location:GeoLocation | optional | |
|............................|..........| |
|databaseChange:DbUpdateSpec | optional | |
+----------------------------+----------+ | 0..* +----------------------------+----------+ | 0..*
V V
+-----------------------------+ +-----------------------------+
|SpectrumSchedule | |SpectrumSchedule |
+------------------+----------+ +------------------+----------+
|time:EventTime | required | |time:EventTime | required |
|spectrum:Spectrum | required | |spectrum:Spectrum | required |
+------------------+----------+ +------------------+----------+
Parameters: Parameters:
timestamp: Timestamp of the response of the form, YYYY-MM- timestamp: Timestamp of the response of the form, YYYY-MM-
DDThh:mm:ssZ, as defined by Date and Time on the Internet: DDThh:mm:ssZ, as defined by Date and Time on the Internet:
Timestamps [RFC3339]. This SHOULD be used by the Device as a Timestamps [RFC3339]. This SHOULD be used by the Device as a
reference for the start and stop times in the spectrum schedules. reference for the start and stop times in the spectrum schedules.
deviceDesc: The Database MUST include the DeviceDescriptor deviceDesc: The Database MUST include the DeviceDescriptor
(Section 5.2) specified in the AVAIL_SPECTRUM_REQ message (Section 5.2) specified in the AVAIL_SPECTRUM_REQ message
spectrumSchedules: The SpectrumSchedule (Section 5.10) 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.10) 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.
rulesetId: The Database SHOULD return the identifier of the maxTotalBwHz: The Database MAY return a constraint on the maximum
applicable rule set for the response (see Ruleset ID Registry total bandwidth (in Hertz) allowed, which may or may not be
(Section 9.2)). If included, the Device MUST use the contiguous. A regulatory domain MAY require the Database to
corresponding rule set to interpret the response. return this parameter. When present in the response, the Device
MUST apply this constraint to its spectrum-selection logic to
ensure total bandwidth does not exceed this value.
maxContiguousBwHz The Database MAY return a constraint on the
maximum contiguous bandwidth (in Hertz) allowed. A regulatory
domain MAY require this Database to return this parameter. When
present in the response, the Device MUST apply this constraint to
its spectrum-selection logic to ensure no single block of spectrum
has bandwidth that exceeds this value.
rulesetInfo: The Database SHOULD return the RulesetInfo
(Section 6.8.6) parameter that identifies the applicable
regulatory authority and rule set for the response (see Ruleset ID
Registry (Section 9.2)). If included, the Device MUST use the
corresponding rule set to interpret the response. Values provided
within this parameter, such as maxLocationChange, take precedence
over the values provided by the Initialization Procedure
(Section 4.2).
location: The Database MAY copy other elements from the request, 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
(Section 5.7) parameter to notify the Device of a change to the
Database URI. When a Database plans to cease operation, it SHOULD
return this parameter to provide devices with one or more
alternate database URIs. The Device SHOULD use the information to
update its list of preconfigured databases.
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 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 MAY schedule, depending on the regulatory domain, the Device MAY
continue to operate for a period of time, as indicated by continue to operate for a period of time, as indicated by
parameters returned in the INIT_RESP (Section 4.2.2) message. parameters returned in the INIT_RESP (Section 4.2.2) message.
skipping to change at page 18, line 24 skipping to change at page 20, line 24
| |
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 is
REQUIRED. REQUIRED.
locations: The GeoLocation (Section 5.1) list for the Device is locations: The GeoLocation (Section 5.1) list for the Master Device
REQUIRED. This allows the Device to specify its actual location is REQUIRED. This allows the Device to specify its actual
plus additional anticipated locations, when allowed by the location plus additional anticipated locations, when allowed by
regulatory domain. At least one location MUST be included. This the regulatory domain. At least one location MUST be included.
specification places no upper limit on the number of locations, This specification places no upper limit on the number of
but the Database MAY restrict the number of locations it supports locations, but the Database MAY restrict the number of locations
by returning a response with fewer locations than specified in the it supports by returning a response with fewer locations than
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
skipping to change at page 19, line 12 skipping to change at page 21, line 12
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 | |
|rulesetId:string | optional | | |maxTotalBwHz:float | optional | |
|maxContiguousBwHz:float | optional | |
|rulesetInfo:RulesetInfo | optional | |
|............................|..........| |
|databaseChange:DbUpdateSpec | optional | |
+----------------------------+----------+ | 0..* +----------------------------+----------+ | 0..*
V V
+---------------------------------+ +---------------------------------+
|GeoSpectrumSchedule | |GeoSpectrumSchedule |
+----------------------+----------+ +----------------------+----------+
|location:GeoLocation | required | |location:GeoLocation | required |
|spectrumSchedule:list | required | |spectrumSchedule:list | required |
+----------------------+----------+ +----------------------+----------+
Parameters: Parameters:
timestamp: Timestamp of the response of the form, YYYY-MM- timestamp: Timestamp of the response of the form, YYYY-MM-
DDThh:mm:ssZ, as defined by Date and Time on the Internet: DDThh:mm:ssZ, as defined by Date and Time on the Internet:
Timestamps [RFC3339]. This SHOULD be used by the Device as a Timestamps [RFC3339]. This SHOULD be used by the Device as a
reference for the start and stop times in the spectrum schedules. reference for the start and stop times in the spectrum schedules.
deviceDesc: The Database MUST include the DeviceDescriptor deviceDesc: The Database MUST include the DeviceDescriptor
(Section 5.2) specified in the AVAIL_SPECTRUM_REQ message (Section 5.2) specified in the AVAIL_SPECTRUM_REQ message
geoSpectrumSchedules: The geoSpectrumSchedule (Section 5.11) list is geoSpectrumSchedules: The geoSpectrumSchedule (Section 5.13) list is
REQUIRED (though it MAY be empty if spectrum is unavailable). For REQUIRED (though it MAY be empty if spectrum is unavailable). For
each location, the Database MAY return more than one each location, the Database MAY return more than one
GeoSpectrumSchedule (Section 6.8.11) 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.
rulesetId: The Database SHOULD return the identifier of the maxTotalBwHz: The Database MAY return a constraint on the maximum
applicable rule set for the response (see Ruleset ID Registry total bandwidth (in Hertz) allowed, which may or may not be
(Section 9.2)). If included, the Device MUST use the contiguous. A regulatory domain MAY require the Database to
corresponding rule set to interpret the response. return this parameter. When present in the response, the Device
MUST apply this constraint to its spectrum-selection logic to
ensure total bandwidth does not exceed this value.
maxContiguousBwHz The Database MAY return a constraint on the
maximum contiguous bandwidth (in Hertz) allowed. A regulatory
domain MAY require this Database to return this parameter. When
present in the response, the Device MUST apply this constraint to
its spectrum-selection logic to ensure no single block of spectrum
has bandwidth that exceeds this value.
rulesetInfo: The Database SHOULD return the RulesetInfo
(Section 6.8.6) parameter that identifies the applicable
regulatory authority and rule set for the response (see Ruleset ID
Registry (Section 9.2)). If included, the Device MUST use the
corresponding rule set to interpret the response. Values provided
within this parameter, such as maxLocationChange, take precedence
over the values provided by the Initialization Procedure
(Section 4.2).
databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) parameter to notify the Device of a change to the
Database URI. When a Database plans to cease operation, it SHOULD
return this parameter to provide devices with one or more
alternate database URIs. The Device SHOULD use the information to
update its list of preconfigured databases.
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 20, line 31 skipping to change at page 23, line 7
|Spectrum | |Spectrum |
+---------------------+----------+ +---------------------+----------+
|bandwidth:float | required | |bandwidth:float | required |
|frequencyRanges:list | required | |frequencyRanges:list | required |
+---------------------+----------+ +---------------------+----------+
Parameters: Parameters:
deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is
REQUIRED. REQUIRED.
location: The GeoLocation (Section 5.1) for the Device is REQUIRED. location: The GeoLocation (Section 5.1) for the Master Device is
spectra: The Spectrum (Section 5.7) list is REQUIRED, and specifies REQUIRED.
spectra: The Spectrum (Section 5.9) list is REQUIRED, and specifies
the spectrum anticipated to be used by the Device, which includes the spectrum anticipated to be used by the Device, which includes
frequency ranges and maximum power levels. For consistency, the frequency ranges and maximum power levels. For consistency, the
"bandwidth" value SHOULD match that from one of the Spectrum "bandwidth" value SHOULD match that from one of the Spectrum
(Section 5.7) elements in the corresponding AVAIL_SPECTRUM_RESP (Section 5.9) elements in the corresponding AVAIL_SPECTRUM_RESP
message, and the maximum power levels in the Spectrum element MUST message, and the maximum power levels in the Spectrum element MUST
be expressed as total power (EIRP) computed over the specified be expressed as total power (EIRP) computed over the specified
"bandwidth" value. The actual bandwidth to be used (as computed "bandwidth" value. The actual bandwidth to be used (as computed
from the start and stop frequencies) MAY be different from the from the start and stop frequencies) MAY be different from the
"bandwidth" value. As an example, when regulatory rules express "bandwidth" value. As an example, when regulatory rules express
maximum power spectral density in terms of maximum power over any maximum power spectral density in terms of maximum power over any
100 kHz band, then the "bandwidth" value should be set to 100 kHz, 100 kHz band, then the "bandwidth" value should be set to 100 kHz,
even though the actual bandwidth used can be 20 kHz. even though the actual bandwidth used can be 20 kHz.
other: Depending on the regulatory domain, other parameters MAY be other: Depending on the regulatory domain, other parameters MAY be
required. To simplify its logic, the Device MAY include the union required. To simplify its logic, the Device MAY include the union
skipping to change at page 21, line 33 skipping to change at page 24, line 6
component, instead of the full Available Spectrum Query component, to component, instead of the full Available Spectrum Query component, to
validate a Slave Device. validate a Slave Device.
When validating one or more Slave Devices, the Master Device sends When validating one or more Slave Devices, the Master Device sends
the Database a request that includes the device identifier -- and any the Database a request that includes the device identifier -- and any
other parameters required by the regulatory rules -- for each Slave other parameters required by the regulatory rules -- for each Slave
Device. The Database MUST return a response that indicates whether Device. The Database MUST return a response that indicates whether
each device is permitted to use the spectrum. each device is permitted to use the spectrum.
A typical sequence for using the Device Validation request is A typical sequence for using the Device Validation request is
illustrated in Figure 5, where the Master Device already has a valid illustrated in Figure 6, where the Master Device already has a valid
set of available spectrum for Slave Devices. Note that the set of available spectrum for Slave Devices. Note that the
communication and protocol between the Slave Device and Master Device communication and protocol between the Slave Device and Master Device
is outside the scope of this document. is outside the scope of this document.
o DEV_VALID_REQ (Section 4.5.1) is the device-validation request o DEV_VALID_REQ (Section 4.5.1) is the device-validation request
message message
o DEV_VALID_RESP (Section 4.5.2) is the device-validation response o DEV_VALID_RESP (Section 4.5.2) is the device-validation response
message message
+------------+ +---------------+ +-------------------+ +------------+ +---------------+ +-------------------+
|Slave Device| | Master Device | | Spectrum Database | |Slave Device| | Master Device | | Spectrum Database |
+------------+ +---------------+ +-------------------+ +------------+ +---------------+ +-------------------+
| | | | | |
| AVAIL_SPEC_REQ | | | AVAIL_SPEC_REQ | |
|................>| | |................>| |
| | | | | |
| | DEV_VALID_REQ | | | DEV_VALID_REQ |
| |-------------------------->| | |-------------------------->|
| | | | | |
skipping to change at page 22, line 20 skipping to change at page 24, line 31
| | | | | |
| | DEV_VALID_REQ | | | DEV_VALID_REQ |
| |-------------------------->| | |-------------------------->|
| | | | | |
| | DEV_VALID_RESP | | | DEV_VALID_RESP |
| |<--------------------------| | |<--------------------------|
| AVAIL_SPEC_RESP | | | AVAIL_SPEC_RESP | |
|<................| |<................|
| | | |
Figure 5 Figure 6
4.5.1. DEV_VALID_REQ 4.5.1. DEV_VALID_REQ
+-------------------------------------+ +-------------------------------------+
|DEV_VALID_REQ | |DEV_VALID_REQ |
+--------------------------+----------+ +--------------------------+----------+
|deviceDescs:list | required |---- |deviceDescs:list | required |----
+--------------------------+----------+ | +--------------------------+----------+ |
V 1..* V 1..*
+----------------------+ +----------------------+
skipping to change at page 23, line 22 skipping to change at page 25, line 22
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.12) 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.
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
may be used to specify one of the following: may be used to specify one of the following:
o A single point with optoinal uncertainty o A single point with optional uncertainty
o A region described by a polygon o A region described by a polygon
These are represented using geometric shapes defined in GEORIV These are represented using geometric shapes defined in GEOPRIV
Presence Information Data Format Location Object [RFC5491], where: Presence Information Data Format Location Object [RFC5491], where:
o A "point" with uncertainty is represented using the Ellipse shape o A "point" with uncertainty is represented using the Ellipse shape
o A region represented using the Polygon shape o A region represented using the Polygon shape
The coordinates are expressed using the WGS84 datum, and units are The coordinates are expressed using the WGS84 datum [WGS-84], and
degrees or meters. The data model for GeoLocation is illustrated units are degrees or meters. The data model for GeoLocation is
below: illustrated below:
+-------------------------------+ +-------------------------------+
|GeoLocation | |GeoLocation |
+------------------+------------+ +------------------+------------+
|point:Ellipse | optional | |point:Ellipse | optional |
|region:Polygon | optional | |region:Polygon | optional |
|confidence:int | optioanl | |confidence:int | optional |
+------------------+------------+ +------------------+------------+
Note: point and polygon are mutually exclusive Note: point and polygon are mutually exclusive
+-------------------------------+ +-------------------------------+
|Ellipse | |Ellipse |
+--------------------+----------+ +---------------------------+ +--------------------+----------+ +---------------------------+
|center:Point | required |--->|Point | |center:Point | required |--->|Point |
|semiMajorAxis:float | optional | +----------------+----------+ |semiMajorAxis:float | optional | +----------------+----------+
|semiMinorAxis:float | optional | |latitude:float | required | |semiMinorAxis:float | optional | |latitude:float | required |
|orientation:float | optional | |longitude:float | required | |orientation:float | optional | |longitude:float | required |
+--------------------+----------+ +----------------+----------+ +--------------------+----------+ +----------------+----------+
+-------------------------------+ +-------------------------------+
|Polygon | |Polygon |
+-------------------+-----------+ 3..* +---------------------------+ +-------------------+-----------+ 4..* +---------------------------+
|exterior:list | required |------>|Point | |exterior:list | required |------>|Point |
+-------------------+-----------+ +----------------+----------+ +-------------------+-----------+ +----------------+----------+
|latitude:float | required | |latitude:float | required |
|longitude:float | required | |longitude:float | required |
+----------------+----------+ +----------------+----------+
Parameters: Parameters:
point: If present, it indicates that the GeoLocation represents a point: If present, it indicates that the GeoLocation represents a
point. Paradoxically, a "point" is parameterized using an point. Paradoxically, a "point" is parameterized using an
Ellipse, where the center represents the location of the point and Ellipse, where the center represents the location of the point and
the distances along the major and minor axes represent the the distances along the major and minor axes represent the
uncertainty. The uncertainty values MAY be required, depending on uncertainty. The uncertainty values MAY be required, depending on
the regulatory domain. the regulatory domain.
region: If present. in indicates that the GeoLocation represents a region: If present, it indicates that the GeoLocation represents a
region. Database support for regions is OPTIONAL. region. Database support for regions is OPTIONAL.
center: The center refers to the location of a GeoLocation pont and center: The center refers to the location of a GeoLocation point and
is the represented as the center of an ellipse. REQUIRED. is represented as the center of an ellipse. REQUIRED.
latitude, longitude: Floating-point numbers that express the latitude, longitude: Floating-point numbers that express the
latitude and longitude in degrees using the WGS84 datum. latitude and longitude in degrees using the WGS84 datum [WGS-84].
REQUIRED. REQUIRED.
semiMajorAxis, semiMinorAxis: If required by the regulator domain, semiMajorAxis, semiMinorAxis: If required by the regulator domain,
the location uncertainty, in meters, is parameterized using the location uncertainty, in meters, is parameterized using
distances along the major and minor axes of the ellipse. When distances along the major and minor axes of the ellipse. When
uncertainty is optional, the default value of each is 0. uncertainty is optional, the default value of each is 0.
orientation: This defines the orientation of the ellipse, expressed orientation: This defines the orientation of the ellipse, expressed
as the rotation, in degrees, of the semi-major axis from North as the rotation, in degrees, of the semi-major axis from North
towards the East. For example, when the uncertainty is greatest towards the East. For example, when the uncertainty is greatest
along the North-South direction, orientation is 0 degrees; along the North-South direction, orientation is 0 degrees;
conversely, if the uncertainty is greatest along the East-West conversely, if the uncertainty is greatest along the East-West
direction, orientation is 90 degrees. When orientation is direction, orientation is 90 degrees. When orientation is
optoinal, its default value is 0. optional, its default value is 0.
exterior: When GeoLocation describes a region, the "exterior" field exterior: When GeoLocation describes a region, the "exterior" field
refers to a list of latitude/longitude points that represents the refers to a list of latitude/longitude points that represents the
vertices of a polygon. A minimum of 3 points is required, and vertices of a polygon. The first and last points MUST be the
they must be in counter-clockwise direction. same. Thus, a minimum of 4 points is required. The following
polygon restrictions from [RFC5491] apply:
* A connecting line SHALL NOT cross another connecting line of
the same polygon.
* The vertices MUST be defined in a counter-clockwise direction.
* The edges of a polygon are defined by the shortest path between
two points in space (not a geodesic curve). Consequently, the
length between two adjacent vertices SHOULD be restricted to a
maximum of 130 km.
* All vertices are assumed to be at the same altitude.
* Polygon shapes SHOULD be restricted to a maximum of 15 points
(16 including the repeated point).
confidence: The location confidence level, as an integer percentage, confidence: The location confidence level, as an integer percentage,
MAY be required, depending on the regulatory domain. When the MAY be required, depending on the regulatory domain. When the
parameter is optional, its default value is 100. This values is parameter is optional, its default value is 95. This values is
only meaningful when GeoLocation refers to a point. only meaningful when GeoLocation refers to a point with
uncertainty.
5.2. DeviceDescriptor 5.2. DeviceDescriptor
The device descriptor contains parameters that identify the specific The device descriptor contains parameters that identify the specific
device, such as its manufacturer serial number, regulatory-specific device, such as its manufacturer serial number, regulatory-specific
ID (e.g., FCC ID), and any other device characteristics required by ID (e.g., FCC ID), and any other device characteristics required by
regulatory domains. regulatory domains.
+----------------------------------------------------+ +-----------------------------------------------------+
|DeviceDescriptor | |DeviceDescriptor |
+--------------------+-------------------------------+ +---------------------+-------------------------------+
|serialNumber:string | required | |serialNumber:string | required |
|rulesetIds:list | optional | |manufacturerId:string| optional |
|fccId:string | depends on regulatory domain | |modelId:string | optional |
|....................|...............................| |rulesetIds:list | optional |
|*deviceType:string | depends on regulatory domain | |.....................|...............................|
|*RAT:string | depends on regulatory domain | |*other:any | |
|*other:any | | +---------------------+-------------------------------+
+--------------------+-------------------------------+
Parameters: Parameters:
serialNumber: The manufacturer's device serial number is REQUIRED. serialNumber: The manufacturer's device serial number is REQUIRED.
The length of the value SHALL NOT exceed 64 characters, conforming
to the X.520 [ITUT.X520.2008] recommendations.
manufacturerId: The manufacturer's ID may be REQUIRED, depending on
the regulatory domain. This SHOULD be the name of the device
manufacturer and SHOULD be consistent across all devices from the
same manufacturer. The string value SHALL NOT exceed 64
characters in length.
modelId: The device's model ID may be REQUIRED, depending on the
regulatory domain. The string value SHALL NOT exceed 64
characters in length.
rulesetIds: List of identifiers for rule sets supported by the rulesetIds: List of identifiers for rule sets supported by the
device (see Ruleset ID Registry (Section 9.2)). A Database MAY device (see Ruleset ID Registry (Section 9.2)). A Database MAY
require that the device provides this list before servicing the require that the device provides this list before servicing the
device requests. If the Database does not support any of the rule device requests. If the Database does not support any of the rule
sets specified in the list, the Database MAY refuse to service the sets specified in the list, the Database MAY refuse to service the
device requests. See Section 5.6 for discussion on rule-set device requests. See Section 5.6 for discussion on rule-set
identifier. identifier.
fccId: The Device's FCC ID may be required for some regulatory other: Depending on the regulatory domain, other parameters may be
domains. required. The Database MUST ignore all parameters in the message
it does not understand. See PAWS Parameters Registry
Additional parameters in the DeviceDescriptor depend on each (Section 9.1) for additional valid parameters and for the process
regulatory domain and are listed in the figure for illustrative for extending the message with more parameters. Additionally, see
purposes. It can be extended, for example, to include certification PAWS Ruleset ID Registry (Section 9.2) for the valid set of
IDs for additional regulatory domains. parameters for each ruleset.
5.3. AntennaCharacteristics 5.3. AntennaCharacteristics
Antenna characteristics provide additional information, such as the Antenna characteristics provide additional information, such as the
antenna height, antenna type, etc. Whether antenna characteristics antenna height, antenna type, etc. Whether antenna characteristics
must be provided in a request depends on the device type and must be provided in a request depends on the device type and
regulatory domain. regulatory domain.
+--------------------------------------------------------+ +--------------------------------------------------------+
|AntennaCharacteristics | |AntennaCharacteristics |
skipping to change at page 27, line 26 skipping to change at page 29, line 44
|frequencyRanges:list |optional |------>|FrequencyRange | |frequencyRanges:list |optional |------>|FrequencyRange |
+---------------------+---------+ 0..* +-----------------+---------+ +---------------------+---------+ 0..* +-----------------+---------+
|startHz:float |required | |startHz:float |required |
|stopHz:float |required | |stopHz:float |required |
|maxPowerDBm:float|unused | |maxPowerDBm:float|unused |
|channelId:string |optional | |channelId:string |optional |
+-----------------+---------+ +-----------------+---------+
Parameters: Parameters:
frequencyRanges: Optional FrequencyRange (Section 5.8) list. Each frequencyRanges: Optional FrequencyRange (Section 5.10) list. Each
FrequencyRange element MUST contain start and stop frequencies, FrequencyRange element MUST contain start and stop frequencies,
and optionally, channel IDs, in which the Device can operate. and optionally, channel IDs, in which the Device can operate.
When specified, the Database SHOULD NOT return available spectrum When specified, the Database SHOULD NOT return available spectrum
that falls outside these ranges (or channel IDs). that falls outside these ranges (or channel IDs).
5.5. DeviceOwner 5.5. DeviceOwner
This parameter contains device-owner information required as part of This parameter contains device-owner information required as part of
device registration. Regulatory domains MAY require additional device registration. Regulatory domains MAY require additional
parameters. parameters.
skipping to change at page 28, line 21 skipping to change at page 30, line 38
All contact information MUST be expressed using the vCard Format All contact information MUST be expressed using the vCard Format
[RFC6350]. Only the contact fields of vCard are supported: [RFC6350]. Only the contact fields of vCard are supported:
fn Full name of an individual fn Full name of an individual
org Name of the organization org Name of the organization
adr Address fields adr Address fields
tel Telephone numbers tel Telephone numbers
email Email addresses email Email addresses
Note that the vCard specification defines maximum lengths for each
field, conforming to X.520 [ITUT.X520.2008] recommendations.
5.6. RulesetInfo 5.6. RulesetInfo
This contains parameters for the rule set of a regulatory domain that This contains parameters for the rule set of a regulatory domain that
is communicated using the Initialization component (Section 4.2). is communicated using the Initialization component (Section 4.2) and
Available Spectrum Query (Section 4.4) components.
+-----------------------------------+ +-----------------------------------+
|RulesetInfo | |RulesetInfo |
+-----------------------------------+ +-----------------------------------+
|authority:string | required | |authority:string | required |
|maxLocationChange:float | required | |maxLocationChange:float | optional |
|maxPollingSecs:int | required | |maxPollingSecs:int | optional |
|rulesetIds: list | optional | |rulesetIds: list | optional |
|...................................| |...................................|
|*other:any | depends | |*other:any | depends |
+------------------------+----------+ +------------------------+----------+
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 the 2-letter the rule set applies is REQUIRED. It MUST use a 2-letter country
country codes defined by Country Codes - ISO 3166 [ISO3166-1]. code defined by Country Codes - ISO 3166 [ISO3166-1]. The Device
maxLocationChange: The maximum location change in meters is MAY use this
REQUIRED. When the Device changes location by more than this maxLocationChange: The maximum location change in meters is REQUIRED
for Initialization Response (Section 4.2.2), but OPTIONAL
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 stop operation in
those frequencies immediately. those frequencies immediately. If this value is provided within
the context of an Available Spectrum Response (Section 4.4.2), it
takes precedence over the value 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. The Device MUST contact the for available spectrum is REQUIRED for the Initialization Response
Database to get available spectrum no less frequently than this (Section 4.2.2), but OPTIONAL otherwise. The Device MUST contact
duration. If the new spectrum information indicates that the the Database to get available spectrum no less frequently than
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 stop
operation in those frequencies immediately. operation in those frequencies immediately. If this value is
provided within the context of an Available Spectrum Response
(Section 4.4.2), it takes precedence over the value within the
Initialization Response.
rulesetIds: Within the context of the Initialization Response
(Section 4.2.2), the Database SHOULD return the identifier of one
or more applicable rule sets (see Ruleset ID Registry
(Section 9.2)) it supports for the device's location. The Device
MAY use the rule-set identifiers to determine parameters to
include in subsequent requests. Within the context of the
Available Spectrum (Section 4.4.2) responses, the Database SHOULD
return the identifier of the rule set that corresponds to the
available-spectrum response. If included, the Device MUST use the
corresponding rule set to interpret the response. If the Device
does not support the indicated rule set, it MUST NOT operate in
white space spectrum.
rulesetIds: The Database SHOULD return the identifier of the
applicable rule set (see Ruleset ID Registry (Section 9.2)). If
included, the Device MUST use the corresponding rule set to
interpret the response.
other: This message is intended to be extensible with other other: This message is intended to be extensible with other
regulatory-specific parameters. Devices MUST ignore all regulatory-specific parameters. Devices MUST ignore all
parameters in the message it does not understand. parameters in the message it does not understand.
5.7. Spectrum 5.7. DbUpdateSpec
Available spectrum can logically be characterized by a list of This message is provided by the Database to notify devices of an
upcoming change to the Database URI (See Available Spectrum Response
(Section 4.4.2) and Available Spectrum Batch Response
(Section 4.4.4)). A Device SHOULD use this information to update its
preconfigured list of databases.
+-------------------------------+
|DbUpdateSpec |
+---------------------+---------+ +--------------------------+
|databases:list |required |------>|DatabaseSpec |
+---------------------+---------+ 1..* +---------------+----------+
|name:string | required |
|uri:string | required |
+---------------+----------+
Parameters:
databases: List of one or more DatabaseSpec (Section 5.8) entries.
A Device SHOULD update its preconfigured list of databases to
replace the database that provided the response with the specified
entries.
5.8. DatabaseSpec
This message contains the name and URI of a database.
+--------------------------+
|DatabaseSpec |
+---------------+----------+
|name:string | required |
|uri:string | required |
+---------------+----------+
Parameters:
name: The display name for a database.
uri: The corresponding URI of the database.
5.9. Spectrum
Available spectrum can be logically characterized by a list of
frequency ranges and permissible power levels for each range. frequency ranges and permissible power levels for each range.
+-------------------------------+ +-------------------------------+
|Spectrum | |Spectrum |
+---------------------+---------+ +---------------------+---------+
|bandwidth:float |required | +---------------------------+ |bandwidth:float |required | +---------------------------+
|frequencyRanges:list |required |------>|FrequencyRange | |frequencyRanges:list |required |------>|FrequencyRange |
+---------------------+---------+ 0..* +-----------------+---------+ +---------------------+---------+ 0..* +-----------------+---------+
|startHz:float |required | |startHz:float |required |
|stopHz:float |required | |stopHz:float |required |
|maxPowerDBm:float|optional | |maxPowerDBm:float|optional |
|channelId:string |optional | |channelId:string |optional |
+-----------------+---------+ +-----------------+---------+
Parameters: Parameters:
bandwidth: This parameter is REQUIRED to define the operating bandwidth: This parameter is REQUIRED to define the operating
bandwidth for which permissible power levels is to be specified. bandwidth (in Hertz) for which permissible power levels is to be
For example, FCC regulation would require only one spectrum specified. For example, FCC regulation would require only one
specification at 6MHz bandwidth, but Ofcom regulation would spectrum specification at 6MHz bandwidth, but Ofcom regulation
require 2 specifications, at 0.1MHz and 8MHz. This parameter MAY would require 2 specifications, at 0.1MHz and 8MHz. This
be empty if there is no available spectrum. parameter MAY be empty if there is no available spectrum.
frequencyRanges: A FrequencyRange (Section 5.8) list is REQUIRED to frequencyRanges: A FrequencyRange (Section 5.10) list is REQUIRED
specify frequency ranges and permissible power levels. The list to specify frequency ranges and permissible power levels. The
MAY be empty if there is no available spectrum. list MAY be empty if there is no available spectrum.
5.8. FrequencyRange 5.10. FrequencyRange
The FrequencyRange parameter specifies the maximum permissible power The FrequencyRange parameter specifies the maximum permissible power
levels within a frequency range. levels within a frequency range.
startHz: The inclusive start of the frequency range is REQUIRED. startHz: The inclusive start of the frequency range (in Hertz) is
stopHz: The exclusive end of the frequency range is REQUIRED. REQUIRED.
stopHz: The exclusive end of the frequency range (in Hertz) is
REQUIRED.
maxPowerDBm: The maximum total power level (EIRP) -- computed over maxPowerDBm: The maximum total power level (EIRP) -- computed over
the corresponding operating bandwidth -- that is permitted within the corresponding operating bandwidth -- that is permitted within
the frequency range. Depending on the context in which the the frequency range. Depending on the context in which the
FrequencyRange element appears, maxPowerDBm may be REQUIRED. For FrequencyRange element appears, maxPowerDBm may be REQUIRED. For
example, it is REQUIRED in the AVAIL_SPECTRUM_RESP example, it is REQUIRED in the AVAIL_SPECTRUM_RESP
(Section 4.4.2), AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4), and (Section 4.4.2), AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4), and
SPECTRUM_USE_NOTIFY (Section 4.4.5) messages, but it would not be SPECTRUM_USE_NOTIFY (Section 4.4.5) messages, but it would not be
REQUIRED (nor applicable) when the FrequencyRange element appears REQUIRED (nor applicable) when the FrequencyRange element appears
in Device Capabilities (Section 5.4). in Device Capabilities (Section 5.4).
channelId: The server MAY include a channel identifier, when channelId: The server MAY include a channel identifier, when
applicable. When it is included, the Master Device SHOULD treat applicable. When it is included, the Master Device SHOULD treat
it as informative. it as informative. The length of the identifier SHALL NOT exceed
16.
NOTE: (maxPowerDBm / bandwidth) defines the maximum permitted EIRP NOTE: (maxPowerDBm / bandwidth) defines the maximum permitted EIRP
spectral density. spectral density.
5.9. EventTime 5.11. EventTime
The EventTime element specifies the start and stop times of an The EventTime element specifies the start and stop times of an
"event". This is used to indicate the time period for which a "event". This is used to indicate the time period for which a
Spectrum (Section 5.7) is valid. Spectrum (Section 5.9) is valid.
+---------------------------+ +---------------------------+
|EventTime | |EventTime |
+-----------------+---------+ +-----------------+---------+
|startTime:string |required | |startTime:string |required |
|stopTime:string |required | |stopTime:string |required |
+-----------------+---------+ +-----------------+---------+
Parameters: Parameters:
startTime: The inclusive start of the event is REQUIRED. startTime: The inclusive start of the event is REQUIRED.
stopTime: The exclusive end of the event is REQUIRED. stopTime: The exclusive end of the event is REQUIRED.
Both times are expressed using the format, YYYY-MM-DDThh:mm:ssZ, as Both times are expressed using the format, YYYY-MM-DDThh:mm:ssZ, as
defined by Date and Time on the Internet: Timestamps [RFC3339]. The defined by Date and Time on the Internet: Timestamps [RFC3339]. The
times MUST be expressed using UTC. times MUST be expressed using UTC.
5.10. SpectrumSchedule A device that does not have access to the current date and time MUST
use the timestamp at the top-level of the response message as a
substitute for the current time (see Available Spectrum Response
(Section 4.4.2) and Available Spectrum Batch Response
(Section 4.4.4)). E.g.,
o (timestamp - startTime) gives the duration that a device must wait
before the event becomes "active". If the value is zero or
negative, the event is already active.
o If the event is already active, (stopTime - timestamp) is the
duration that the event remains active. If the value is zero or
negative, the event is no longer active and MUST be ignored.
5.12. SpectrumSchedule
The SpectrumSchedule element combines EventTime with Spectrum to The SpectrumSchedule element combines EventTime with Spectrum to
define a time period in which the spectrum is valid. define a time period in which the spectrum is valid.
+-------------------------------+ +-------------------------------+
|SpectrumSchedule | |SpectrumSchedule |
+--------------------+----------+ +--------------------+----------+
|eventTime:EventTime | required | +--------------------+ |eventTime:EventTime | required | +--------------------+
|spectra:list | required |------->|Spectrum | |spectra:list | required |------->|Spectrum |
+--------------------+----------+ 0..* +--------------------+ +--------------------+----------+ 0..* +--------------------+
|bandwidth:float | |bandwidth:float |
|frequencyRanges:list| |frequencyRanges:list|
+--------------------+ +--------------------+
Parameters: Parameters:
eventTime: The EventTime (Section 5.9) is REQUIRED to express "when" eventTime: The EventTime (Section 5.11) is REQUIRED to express
this specification is valid. "when" this specification is valid.
spectra: Spectrum (Section 5.7) list is REQUIRED to specify the spectra: Spectrum (Section 5.9) list is REQUIRED to specify the
available spectrum and permissible power levels, one per available spectrum and permissible power levels, one per
bandwidth. The list MAY be empty when there is no available bandwidth. The list MAY be empty when there is no available
spectrum. spectrum.
5.11. GeoSpectrumSchedule 5.13. GeoSpectrumSchedule
The GeoSpectrumSchedule element encapsulates the schedule of The GeoSpectrumSchedule element encapsulates the schedule of
available spectrum at a location. available spectrum at a location.
+----------------------------------+ +----------------------------------+
|GeoSpectrumSchedule | |GeoSpectrumSchedule |
+-----------------------+----------+ +-----------------------+----------+
|location:GeoLocation | required | |location:GeoLocation | required |
|spectrumSchedules:list | required |----------+ |spectrumSchedules:list | required |----------+
+-----------------------+----------+ | +-----------------------+----------+ |
| 0..* | 0..*
skipping to change at page 31, line 37 skipping to change at page 35, line 47
|SpectrumSchedule | |SpectrumSchedule |
+------------------+----------+ +------------------+----------+
|time:EventTime | required | |time:EventTime | required |
|spectrum:Spectrum | required | |spectrum:Spectrum | required |
+------------------+----------+ +------------------+----------+
Parameters: Parameters:
location: The GeoLocation (Section 5.1) is REQUIRED to identify the location: The GeoLocation (Section 5.1) is REQUIRED to identify the
location at which the spectrum schedule applies location at which the spectrum schedule applies
spectrumSchedules: The SpectrumSchedule (Section 5.10) list is spectrumSchedules: The SpectrumSchedule (Section 5.12) list is
REQUIRED. At least one schedule MUST be included (though it MAY REQUIRED. At least one schedule MUST be included (though it MAY
be empty if there is no available spectrum). More than one be empty if there is no available spectrum). More than one
schedule MAY be included to represent future changes to the schedule MAY be included to represent future changes to the
available spectrum. available spectrum.
5.12. DeviceValidity 5.14. DeviceValidity
The DeviceValidity element is used to indicate whether a device is The DeviceValidity element is used to indicate whether a device is
valid. See Section 4.5.2. valid. See Section 4.5.2.
+---------------------------------------+ +---------------------------------------+
|DeviceValidity | |DeviceValidity |
+----------------------------+----------+ +----------------------------+----------+
|deviceDesc:DeviceDescriptor | required | |deviceDesc:DeviceDescriptor | required |
|isValid:boolean | required | |isValid:boolean | required |
|reason:string | optional | |reason:string | optional |
+----------------------------+----------+ +----------------------------+----------+
Parameters: Parameters:
skipping to change at page 32, line 22 skipping to change at page 36, line 26
Parameters: Parameters:
deviceDesc: The DeviceDescriptor (Section 5.2) that was used to deviceDesc: The DeviceDescriptor (Section 5.2) that was used to
check for validity is REQUIRED. check for validity is REQUIRED.
isValid: A REQUIRED boolean value that indicates whether the Device isValid: A REQUIRED boolean value that indicates whether the Device
is valid. is valid.
reason: If the device identifier is not valid, the Database MAY reason: If the device identifier is not valid, the Database MAY
include a reason. The reason MAY be in any language. include a reason. The reason MAY be in any language.
5.13. Error Element 5.15. Error Element
If the Database responds to a PAWS request message with an error, it If the Database responds to a PAWS request message with an error, it
MUST include an Error element. MUST include an Error element.
+---------------------------+ +---------------------------+
|Error | |Error |
+----------------+----------+ +----------------+----------+
|code:int | required | |code:int | required |
|message:string | optional | |message:string | optional |
|data:any | optional | |data:any | optional |
+----------------+----------+ +----------------+----------+
skipping to change at page 33, line 24 skipping to change at page 37, line 28
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.
-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. When providing only a listing of full list. Including the full list of missing
missing parameters, the Database SHOULD include parameters may reduce the number of re-queries
the full list of missing parameters to minimize from the Device.
number of re-queries 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
which parameter(s) and why the value is which parameter(s) and why the value is
invalid. invalid.
-300 (reserved) -300 (reserved)
-301 UNAUTHORIZED The Device is not authorized to used the -301 UNAUTHORIZED The Device is not authorized to used the
Database. Authorization may be determined by Database. Authorization may be determined by
regulatory rules or be dependent on prior regulatory rules or be dependent on prior
arrangement between the Device and Database. arrangement between the Device and Database.
-302 NOT_REGISTERED Device registration required, but the Device is -302 NOT_REGISTERED Device registration required, but the Device is
not registered. not registered.
Table 1: Error Codes Table 1: Error Codes
5.13.1. REQUIRED Error 5.15.1. REQUIRED Error
When the error code is REQUIRED, the Error element MUST include a When the error code is REQUIRED, the Error element MUST include a
Parameters element as its "data" field. Parameters element as its "data" field.
+---------------------------+ +---------------------------+
|Error | |Error |
+----------------+----------+ +----------------+----------+
|code:int | required | |code:int | required |
|message:string | optional | +---------------------------+ |message:string | optional | +---------------------------+
|data:Parameters | optional |--->|Parameters | |data:Parameters | optional |--->|Parameters |
skipping to change at page 35, line 13 skipping to change at page 39, line 13
The JSON-RPC Request for PAWS has the following form: The JSON-RPC Request for PAWS has the following form:
{ {
"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. the method. Method names are defined with the prefix,
"spectrum.paws.".
The non-error JSON-RPC Response for PAWS has the following form: The non-error JSON-RPC Response for PAWS has the following form:
{ {
"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.
skipping to change at page 35, line 37 skipping to change at page 39, line 38
{ {
"error": { "error": {
"code": integer, "code": integer,
"message": string, "message": string,
"data": object, "data": object,
}, },
"id": string "id": string
} }
where the Error object and error codes are described by Error Element where the Error object and error codes are described by Error Element
(Section 5.13). (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 MAY contain additional parameters. The Database
or Device MUST ignore all parameters it does not understand. 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 "init" method This section describes the encoding for the JSON-RPC
that represents the Initialization functionality (Section 4.2). "spectrum.paws.init" method that represents the Initialization
functionality (Section 4.2).
6.2.1. INIT_REQ Parameters 6.2.1. INIT_REQ Parameters
The JSON encoding of the Initialization request message INIT_REQ The JSON encoding of the Initialization request message INIT_REQ
(Section 4.2.1) is described by the following schema: (Section 4.2.1) is described by the following schema:
{ {
"name": "INIT_REQ", "name": "INIT_REQ",
"type": "object", "type": "object",
"properties": { "properties": {
skipping to change at page 36, line 32 skipping to change at page 40, line 37
"domain, the location MAY be the anticipated position of " + "domain, the location MAY be the anticipated position of " +
"the Device.", "the Device.",
"required": true "required": true
} }
} }
} }
Example "init" JSON-RPC request: Example "init" JSON-RPC request:
{ {
"method": "init", "method": "spectrum.paws.init",
"params": { "params": {
"type": "INIT_REQ", "type": "INIT_REQ",
"version": "1.0", "version": "1.0",
"deviceDesc": { "deviceDesc": {
"serialNumber": "XXX", "serialNumber": "XXX",
"fccId": "YYY", "fccId": "YYY",
... ...
}, },
"location": { "location": {
"point": { "point": {
skipping to change at page 37, line 44 skipping to change at page 41, line 46
"version": "1.0", "version": "1.0",
"rulesetInfo": { "rulesetInfo": {
... ...
} }
}, },
"id": "xxxxxx" "id": "xxxxxx"
} }
6.3. register Method 6.3. register Method
This section describes the encoding for the JSON-RPC "register" This section describes the encoding for the JSON-RPC
method that represents Device Registration functionality "spectrum.paws.register" method that represents Device Registration
(Section 4.3). functionality (Section 4.3).
6.3.1. REGISTRATION_REQ Parameters 6.3.1. REGISTRATION_REQ Parameters
The JSON encoding of the Registration request message The JSON encoding of the Registration request message
REGISTRATION_REQ (Section 4.3.1) is described by the following REGISTRATION_REQ (Section 4.3.1) is described by the following
schema: schema:
{ {
"name": "REGISTRATION_REQ", "name": "REGISTRATION_REQ",
"type": "object", "type": "object",
skipping to change at page 39, line 6 skipping to change at page 43, line 6
"description": "Antenna characteristics, including its " + "description": "Antenna characteristics, including its " +
"height and height type", "height and height type",
"required": false "required": false
} }
} }
} }
Example "register" JSON-RPC request: Example "register" JSON-RPC request:
{ {
"method": "register", "method": "spectrum.paws.register",
"params": { "params": {
"type": "REGISTRATION_REQ", "type": "REGISTRATION_REQ",
"version": "1.0", "version": "1.0",
"deviceDesc": { "deviceDesc": {
"serialNumber": "XXX", "serialNumber": "XXX",
"fccId": "YYY", "fccId": "YYY",
... ...
}, },
"deviceOwner": { "deviceOwner": {
"owner": { "owner": {
"fn": "John A. Smith", "fn": "John A. Smith",
"org": { "org": {
"text": "ACME", "text": "ACME"
}, },
"adr": { "adr": {
"street": "1234 A Street", "street": "1234 A Street",
"locality": "San Jose", "locality": "San Jose",
"region": "CA", "region": "CA",
"code": "94423", "code": "94423",
"country": "US" "country": "US"
}, },
"tel": { "tel": {
"uri": "tel:+1-333-555-1212" "uri": "tel:+1-333-555-1212"
skipping to change at page 39, line 48 skipping to change at page 43, line 48
"center": {"latitude": 37.0, "longitude": -101.3} "center": {"latitude": 37.0, "longitude": -101.3}
} }
}, },
"antenna": {"height": 10.2, "heightType": "AGL"} "antenna": {"height": 10.2, "heightType": "AGL"}
}, },
"id": "xxxxxx" "id": "xxxxxx"
} }
6.3.2. REGISTRATION_RESP Parameters 6.3.2. REGISTRATION_RESP Parameters
The JSON encoding of the Registraion response message The JSON encoding of the Registration response message
REGISTRATION_RESP (Section 4.3.2) is described by the following REGISTRATION_RESP (Section 4.3.2) is described by the following
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",
skipping to change at page 40, line 29 skipping to change at page 44, line 29
{ {
"result": { "result": {
"type": "REGISTRATION_RESP", "type": "REGISTRATION_RESP",
"version": "1.0" "version": "1.0"
}, },
"id": "xxxxxx" "id": "xxxxxx"
} }
6.4. getSpectrum Method 6.4. getSpectrum Method
This section describes the encoding for the JSON-RPC "getSpectrum" This section describes the encoding for the JSON-RPC
method that represents the single-location query of the Available "spectrum.paws.getSpectrum" method that represents the single-
Spectrum Query functionality (Section 4.4) that enables a Device to location query of the Available Spectrum Query functionality
obtain a set of available spectrum from the Database. (Section 4.4) that enables a Device to obtain a set of available
spectrum from the Database.
6.4.1. AVAILABLE_SPECTRUM_REQ Parameters 6.4.1. AVAIL_SPECTRUM_REQ Parameters
The JSON encoding of the Available Spectrum request message The JSON encoding of the Available Spectrum request message
AVAIL_SPECTRUM_REQ (Section 4.4.1) is described by the following AVAIL_SPECTRUM_REQ (Section 4.4.1) is described by the following
schema: schema:
{ {
"name": "AVAILABLE_SPECTRUM_REQ", "name": "AVAIL_SPECTRUM_REQ",
"type": "object", "type": "object",
"properties": { "properties": {
"type": "AVAILABLE_SPECTRUM_REQ", "type": "AVAIL_SPECTRUM_REQ",
"version": { "version": {
"type": "string", "type": "string",
"required": true "required": true
}, },
"deviceDesc": { "deviceDesc": {
"type": "DeviceDescriptor", "type": "DeviceDescriptor",
"required":true "required":true
}, },
"location": { "location": {
"type": "GeoLocation", "type": "GeoLocation",
skipping to change at page 42, line 6 skipping to change at page 46, line 6
"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
} }
} }
} }
Example "getSpectrum" JSON-RPC request: Example "getSpectrum" JSON-RPC request:
{ {
"method": "getSpectrum", "method": "spectrum.paws.getSpectrum",
"params": { "params": {
"type": "AVAILABLE_SPECTRUM_REQ", "type": "AVAIL_SPECTRUM_REQ",
"version": "1.0", "version": "1.0",
"deviceDesc": { "deviceDesc": {
"serialNumber": "XXX", "serialNumber": "XXX",
"fccId": "YYY", "fccId": "YYY",
... ...
}, },
"location": { "location": {
"point": { "point": {
"center": {"latitude": 37.0, "longitude": -101.3} "center": {"latitude": 37.0, "longitude": -101.3}
} }
skipping to change at page 43, line 9 skipping to change at page 46, line 35
6.4.2. AVAIL_SPECTRUM_RESP Parameters 6.4.2. AVAIL_SPECTRUM_RESP Parameters
The JSON encoding of the Available Spectrum response message The JSON encoding of the Available Spectrum response message
AVAIL_SPECTRUM_RESP (Section 4.4.2) is described by the following AVAIL_SPECTRUM_RESP (Section 4.4.2) is described by the following
schema: schema:
{ {
"name": "AVAIL_SPECTRUM_RESP", "name": "AVAIL_SPECTRUM_RESP",
"type": "object", "type": "object",
"properties": { "properties": {
"type": "AVAILABLE_SPECTRUM_RESP", "type": "AVAIL_SPECTRUM_RESP",
"version": { "version": {
"type": "string", "type": "string",
"required": true "required": true
}, },
"timestamp": { "timestamp": {
"type": "string", "type": "string",
"description": "Timestamp of the response, using " + "description": "Timestamp of the response, using " +
"YYYY-MM-DDThh:mm:ssZ RFC3339 format. This SHOULD be used " + "YYYY-MM-DDThh:mm:ssZ RFC3339 format. This SHOULD be used " +
"by the Device as a reference for the start and stop times " + "by the Device as a reference for the start and stop times " +
"in the spectrum schedule", "in the spectrum schedule",
skipping to change at page 43, line 44 skipping to change at page 47, line 21
"required": true "required": true
}, },
"needsSpectrumReport": { "needsSpectrumReport": {
"type": "boolean", "type": "boolean",
"description": "For regulatory domains that require a " + "description": "For regulatory domains that require a " +
"spectrum-usage report from devices, the Database MUST " + "spectrum-usage report from devices, the Database MUST " +
"return true for this parameter.", "return true for this parameter.",
"default": false, "default": false,
"required": false "required": false
}, },
"rulesetId": { "maxTotalBwHz": {
"type": "string", "type": "number",
"description": "The identifier of the applicable rule set.", "description": "Constraint on total bandwidth allowed, " +
"summed across all blocks of spectrum.",
"required": false
},
"maxContiguousBwHz": {
"type": "number",
"description": "Constraint on bandwidth allowed for " +
"any single block of spectrum.",
"required": false
},
"rulesetInfo": {
"type": "RulesetInfo",
"description": "Indicates the active regulatory domain and " +
"attributes that define the applicable rule set that " +
"govern the device",
"required": false
},
"databaseChange": {
"type": "DbUpdateSpec",
"description": "Indicates that the Database URI will be " +
"changing. Devices need to update their configurations",
"required": false "required": false
} }
} }
} }
Example "getSpectrum" JSON-RPC response: Example "getSpectrum" JSON-RPC response:
{ {
"result": { "result": {
"type": "AVAILABLE_SPECTRUM_RESP", "type": "AVAIL_SPECTRUM_RESP",
"version": "1.0", "version": "1.0",
"timestamp": "2013-03-02T14:30:21Z", "timestamp": "2013-03-02T14:30:21Z",
"deviceDesc": { "deviceDesc": {
"serialNumber": "XXX", "serialNumber": "XXX",
"fccId": "YYY", "fccId": "YYY",
... ...
}, },
"spectrumSchedules": [ "spectrumSchedules": [
{ {
"eventTime": { "eventTime": {
skipping to change at page 45, line 4 skipping to change at page 48, line 51
"stopTime": "2013-03-03T14:30:21Z", "stopTime": "2013-03-03T14:30:21Z",
}, },
"spectra": [ "spectra": [
... ...
] ]
} }
], ],
"needsSpectrumReport": false "needsSpectrumReport": false
}, },
"id": "xxxxxx" "id": "xxxxxx"
} }
6.5. getSpectrumBatch Method 6.5. getSpectrumBatch Method
This section describes the encoding for the JSON-RPC This section describes the encoding for the JSON-RPC
"getSpectrumBatch" method that represents the multiple-location query "spectrum.paws.getSpectrumBatch" method that represents the multiple-
of the Available Spectrum Query functionality (Section 4.4) that location query of the Available Spectrum Query functionality
enables a Device to obtain a set of available spectrum for multiple (Section 4.4) that enables a Device to obtain a set of available
locations from the Database. spectrum for multiple locations from the Database.
6.5.1. AVAIL_SPECTRUM_BATCH_REQ Parameters 6.5.1. AVAIL_SPECTRUM_BATCH_REQ Parameters
The JSON encoding of the Batch Available Spectrum request The JSON encoding of the Batch Available Spectrum request
AVAIL_SPECTRUM_BATCH_REQ (Section 4.4.3) is described by the AVAIL_SPECTRUM_BATCH_REQ (Section 4.4.3) is described by the
following schema. This an OPTIONAL feature of the Database. following schema. This an OPTIONAL feature of the Database.
{ {
"name": "AVAIL_SPECTRUM_BATCH_REQ", "name": "AVAIL_SPECTRUM_BATCH_REQ",
"type": "object", "type": "object",
"properties": { "properties": {
"type": "AVAILABLE_SPECTRUM_BATCH_REQ", "type": "AVAIL_SPECTRUM_BATCH_REQ",
"version": { "version": {
"type": "string", "type": "string",
"required": true "required": true
}, },
"deviceDesc": { "deviceDesc": {
"type": "DeviceDescriptor", "type": "DeviceDescriptor",
"required": true "required": true
}, },
"locations": { "locations": {
"type": "array", "type": "array",
skipping to change at page 47, line 6 skipping to change at page 51, line 6
"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
} }
} }
} }
Example "getSpectrumBatch" JSON-RPC request: Example "getSpectrumBatch" JSON-RPC request:
{ {
"method": "getSpectrumBatch", "method": "spectrum.paws.getSpectrumBatch",
"params": { "params": {
"type": "AVAILABLE_SPECTRUM_BATCH_REQ", "type": "AVAIL_SPECTRUM_BATCH_REQ",
"version": "1.0", "version": "1.0",
"deviceDesc": { "deviceDesc": {
"serialNumber": "XXX", "serialNumber": "XXX",
"fccId": "YYY", "fccId": "YYY",
... ...
}, },
"locations": [ "locations": [
{ {
"point": { "point": {
"center": {"latitude": 37.0, "longitude": -101.3} "center": {"latitude": 37.0, "longitude": -101.3}
skipping to change at page 48, line 9 skipping to change at page 51, line 43
6.5.2. AVAIL_SPECTRUM_BATCH_RESP Parameters 6.5.2. AVAIL_SPECTRUM_BATCH_RESP Parameters
The JSON encoding of the Batch Available Spectrum response The JSON encoding of the Batch Available Spectrum response
AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4) is described by the AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4) is described by the
following schema: following schema:
{ {
"name": "AVAIL_SPECTRUM_BATCH_RESP", "name": "AVAIL_SPECTRUM_BATCH_RESP",
"type": "object", "type": "object",
"properties": { "properties": {
"type": "AVAILABLE_SPECTRUM_BATCH_RESP", "type": "AVAIL_SPECTRUM_BATCH_RESP",
"version": { "version": {
"type": "string", "type": "string",
"required": true "required": true
}, },
"timestamp": { "timestamp": {
"type": "string", "type": "string",
"description": "Timestamp of the response, using " + "description": "Timestamp of the response, using " +
"YYYY-MM-DDThh:mm:ssZ RFC3339 format. This SHOULD be used " + "YYYY-MM-DDThh:mm:ssZ RFC3339 format. This SHOULD be used " +
"by the Device as a reference for the start and stop times " + "by the Device as a reference for the start and stop times " +
"in the spectrum schedule", "in the spectrum schedule",
skipping to change at page 48, line 44 skipping to change at page 52, line 29
"required": true "required": true
}, },
"needsSpectrumReport": { "needsSpectrumReport": {
"type": "boolean", "type": "boolean",
"description": "For regulatory domains that require a " + "description": "For regulatory domains that require a " +
"spectrum-usage report from devices, the Database MUST " + "spectrum-usage report from devices, the Database MUST " +
"return true for this parameter.", "return true for this parameter.",
"default": false, "default": false,
"required": false "required": false
}, },
"rulesetId": { "maxTotalBwHz": {
"type": "string", "type": "number",
"description": "The identifier of the applicable rule set.", "description": "Constraint on total bandwidth allowed, " +
"summed across all blocks of spectrum.",
"required": false
},
"maxContiguousBwHz": {
"type": "number",
"description": "Constraint on bandwidth allowed for " +
"any single block of spectrum.",
"required": false
},
"rulesetInfo": {
"type": "RulesetInfo",
"description": "Indicates the active regulatory domain and " +
"attributes that define the applicable rule set that " +
"govern the device",
"required": false
},
"databaseChange": {
"type": "DbUpdateSpec",
"description": "Indicates that the Database URI will be " +
"changing. Devices need to update their configurations",
"required": false "required": false
} }
} }
} }
Example "getSpectrumBatch" JSON-RPC response: Example "getSpectrumBatch" JSON-RPC response:
{ {
"result": { "result": {
"type": "AVAILABLE_SPECTRUM_BATCH_RESP", "type": "AVAIL_SPECTRUM_BATCH_RESP",
"version": "1.0", "version": "1.0",
"timestamp": "2013-03-02T14:30:21Z", "timestamp": "2013-03-02T14:30:21Z",
"deviceDesc": { "deviceDesc": {
"serialNumber": "XXX", "serialNumber": "XXX",
"fccId": "YYY", "fccId": "YYY",
... ...
}, },
"geoSpectrumSchedules": [ "geoSpectrumSchedules": [
{ {
"location": { "location": {
skipping to change at page 50, line 28 skipping to change at page 54, line 36
} }
], ],
"needsSpectrumReport": false "needsSpectrumReport": false
}, },
"id": "xxxxxx" "id": "xxxxxx"
} }
6.6. notifySpectrumUse Method 6.6. notifySpectrumUse Method
This section describes the encoding for the JSON-RPC This section describes the encoding for the JSON-RPC
"notifySpectrumUse" method that represents the Spectrum-usage "spectrum.paws.notifySpectrumUse" method that represents the
notification of Available Spectrum Query functionality Spectrum-usage notification of Available Spectrum Query functionality
(Section 4.4.5) for notifying the Database of anticipated spectrum (Section 4.4.5) for notifying the Database of anticipated spectrum
usage. usage.
6.6.1. SPECTRUM_USE_NOTIFY Parameters 6.6.1. SPECTRUM_USE_NOTIFY Parameters
The JSON encoding of the Spectrum Notification message The JSON encoding of the Spectrum Notification message
SPECTRUM_USE_NOTIFY (Section 4.4.5) is described by the following SPECTRUM_USE_NOTIFY (Section 4.4.5) is described by the following
schema: schema:
{ {
skipping to change at page 52, line 6 skipping to change at page 56, line 6
"the Device.", "the Device.",
"items": "Spectrum", "items": "Spectrum",
"required": true "required": true
} }
} }
} }
Example "notifySpectrumUse" JSON-RPC notification: Example "notifySpectrumUse" JSON-RPC notification:
{ {
"method": "notifySpectrumUse", "method": "spectrum.paws.notifySpectrumUse",
"params": { "params": {
"type": "SPECTRUM_USE_NOTIFY", "type": "SPECTRUM_USE_NOTIFY",
"version": "1.0", "version": "1.0",
"deviceDesc": { "deviceDesc": {
"serialNumber": "XXX", "serialNumber": "XXX",
"fccId": "YYY", "fccId": "YYY",
... ...
}, },
"location": { "location": {
"point": { "point": {
skipping to change at page 52, line 29 skipping to change at page 56, line 29
}, },
"spectra": [ "spectra": [
{ {
"bandwidth": 6e6, "bandwidth": 6e6,
"frequencyRanges": [ "frequencyRanges": [
{"startHz":5.18e8, "stopHz":5.24e8, "maxPowerDBm":30.0} {"startHz":5.18e8, "stopHz":5.24e8, "maxPowerDBm":30.0}
] ]
}, },
] ]
}, },
"needsSpectrumReport": false
},
"id": "xxxxxx" "id": "xxxxxx"
} }
6.6.2. SPECTRUM_USE_RESP Parameters 6.6.2. SPECTRUM_USE_RESP Parameters
The JSON encoding of the Spectrum-usage response SPECTRUM_USE_RESP The JSON encoding of the Spectrum-usage response SPECTRUM_USE_RESP
(Section 4.4.6) is decribed by the following schema: (Section 4.4.6) is described by the following schema:
{ {
"name": "SPECTRUM_USE_RESP", "name": "SPECTRUM_USE_RESP",
"type": "object", "type": "object",
"properties": { "properties": {
"type": "SPECTRUM_USE_RESP", "type": "SPECTRUM_USE_RESP",
"version": { "version": {
"type": "string", "type": "string",
"required": true "required": true
} }
skipping to change at page 53, line 15 skipping to change at page 57, line 15
{ {
"result": { "result": {
"type": "SPECTRUM_USE_RESP", "type": "SPECTRUM_USE_RESP",
"version": "1.0" "version": "1.0"
}, },
"id": "xxxxxx" "id": "xxxxxx"
} }
6.7. verifyDevice Method 6.7. verifyDevice Method
This section describes the encoding for the JSON-RPC "verifyDevice" This section describes the encoding for the JSON-RPC
method that represents the Device Validation functionality "spectrum.paws.verifyDevice" method that represents the Device
(Section 4.5). This is used by a Master Device to validate Slave Validation functionality (Section 4.5). This is used by a Master
Devices. Device to validate Slave Devices.
6.7.1. DEV_VALID_REQ Parameters 6.7.1. DEV_VALID_REQ Parameters
The JSON encoding of the Device Validation request DEV_VALID_REQ The JSON encoding of the Device Validation request DEV_VALID_REQ
(Section 4.5.1) is described by the following schema: (Section 4.5.1) is described by the following schema:
{ {
"name": "DEV_VALID_REQ", "name": "DEV_VALID_REQ",
"type": "object", "type": "object",
"properties": { "properties": {
skipping to change at page 54, line 6 skipping to change at page 58, line 6
"description": "List of Slave Devices to be validated", "description": "List of Slave Devices to be validated",
"items": "DeviceDescriptor", "items": "DeviceDescriptor",
"required": true "required": true
} }
} }
} }
Example "verifyDevice" JSON-RPC request: Example "verifyDevice" JSON-RPC request:
{ {
"method": "verifyDevice", "method": "spectrum.paws.verifyDevice",
"params": { "params": {
"type": "DEV_VALID_REQ", "type": "DEV_VALID_REQ",
"version": "1.0", "version": "1.0",
"deviceDescs": [ "deviceDescs": [
{ {
"serialNumber": "XXX", "serialNumber": "XXX",
"fccId": "YYY", "fccId": "YYY",
... ...
}, },
{ {
skipping to change at page 56, line 16 skipping to change at page 60, line 16
"region": { "region": {
"description": "A region described by a polygon", "description": "A region described by a polygon",
"type": "Polygon", "type": "Polygon",
"required": false "required": false
}, },
"confidence": { "confidence": {
"description": "Confidence interval when location " + "description": "Confidence interval when location " +
"is a point with uncertainty. 0 to 100.", "is a point with uncertainty. 0 to 100.",
"type": "integer", "type": "integer",
"required": false, "required": false,
"default": 100 "default": 95
} }
} }
} }
{ {
"name": "Point", "name": "Point",
"type": "object", "type": "object",
"properties": { "properties": {
"latitude": { "latitude": {
"description: "Floating-point degrees. WGS84 datum.", "description": "Double-precision floating-point degrees. " +
"WGS84 datum.",
"type": "number", "type": "number",
"required": true "required": true
}, },
"longitude": { "longitude": {
"type": "number", "type": "number",
"description: "Floating-point degree. WGS84 datum.", "description": "Double-precision floating-point degree. " +
"required":true "WGS84 datum.",
"required": true
} }
} }
} }
{ {
"name": "Ellipse", "name": "Ellipse",
"type": "object", "type": "object",
"properties": { "properties": {
"center": { "center": {
"type": "Point", "type": "Point",
"required": true "required": true
skipping to change at page 57, line 26 skipping to change at page 61, line 29
"default": 0 "default": 0
} }
} }
} }
{ {
"name": "Polygon", "name": "Polygon",
"type": "object", "type": "object",
"properties": { "properties": {
"exterior": { "exterior": {
"description": "List of Points in counter-clockwise " + "description": "List of Points in counter-clockwise " +
"order. They must form a loop with no edges that " + "order. They MUST form a loop with no edges that " +
"cross each other. Minimum of 3 points.", "cross each other. First and last points MUST be " +
"the same. Minimum of 4 points.",
"type": "array", "type": "array",
"items": "Point", "items": "Point",
"required": true "required": true
} }
} }
} }
6.8.2. DeviceDescriptor 6.8.2. DeviceDescriptor
The DeviceDescriptor (Section 5.2) contains parameters that identify The DeviceDescriptor (Section 5.2) contains parameters that identify
the specific device, such as its manufacturer serial number, the specific device, such as its manufacturer serial number,
regulatory-specific ID (e.g., FCC ID), and any other device regulatory-specific ID (e.g., FCC ID), and any other device
characteristics required by regulatory domains, such as device-type characteristics required by regulatory domains, such as device-type
classification. classification. See Initial PAWS Parameters Registry Contents
(Section 9.1.2) for additional valid parameters, e.g., "fccId",
"etsiEnDeviceType", etc.
{ {
"name": "DeviceDescriptor", "name": "DeviceDescriptor",
"type": "object", "type": "object",
"properties": { "properties": {
"serialNumber": { "serialNumber": {
"type": "string", "type": "string",
"required": true "required": true
}, },
"manufacturerId": {
"type": "string",
"required": false
},
"modelId": {
"type": "string",
"required": false
},
"rulesetIds": { "rulesetIds": {
"type": "array", "type": "array",
"description": "List of identifiers for rule sets supported " + "description": "List of identifiers for rule sets supported " +
"by the device", "by the device",
"items": "string", "items": "string",
"required": false "required": false
},
"fccId": {
"type": "string",
"description":"The device's FCC ID.",
"required": false
} }
} }
} }
6.8.3. AntennaCharacteristics 6.8.3. AntennaCharacteristics
AntennaCharacteristics (Section 5.3) provide additional information, AntennaCharacteristics (Section 5.3) provide additional information,
such as the antenna height, antenna type, etc. such as the antenna height, antenna type, etc.
{ {
skipping to change at page 62, line 22 skipping to change at page 66, line 22
"authority": { "authority": {
"type": "string", "type": "string",
"description": "The regulatory domain at the specified " + "description": "The regulatory domain at the specified " +
"location. It is a 2-letter country codes defined by " + "location. It is a 2-letter country codes defined by " +
"ISO3166-1.", "ISO3166-1.",
"required": true "required": true
}, },
"maxLocationChange": { "maxLocationChange": {
"type": "number", "type": "number",
"description": "Maximum location change in meters.", "description": "Maximum location change in meters.",
"required": true "required": false
}, },
"maxPollingSecs": { "maxPollingSecs": {
"type": "integer", "type": "integer",
"description": "Maximum duration, in seconds, between " + "description": "Maximum duration, in seconds, between " +
"requests for available spectrum.", "requests for available spectrum.",
"required": false
},
"rulesetIds": {
"type": "array",
"description": "The identifier of one or more applicable " +
"rule sets",
"item": "string",
"required": false
}
}
}
6.8.7. DbUpdateSpec
DbUpdateSpec (Section 5.7) contains one or more database
specifications. It is used to indicate a change to the Database URI.
{
"name": "DbUpdateSpec",
"type": "object",
"description": "Specification for updates to a Database URI",
"properties": {
"databases": {
"type": "array",
"description": "The specification of one or more databases",
"item": "DatabaseSpec",
"required": true
}
}
}
6.8.8. DatabaseSpec
DatabaseSpec (Section 5.8) specifies the name and URI of a database.
{
"name": "DatabaseSpec",
"type": "object",
"description": "Specification for a database",
"properties": {
"name": {
"type": "string",
"description": "The display name of a databases",
"required": true "required": true
}, },
"rulesetId": { "uri": {
"type": "string", "type": "string",
"description": "The identifier of the applicable rule set", "description": "The URI of a databases",
"required": false, "required": true
} }
} }
} }
6.8.7. Spectrum 6.8.9. Spectrum
Available Spectrum (Section 5.7) can logically be characterized by a Available Spectrum (Section 5.9) can logically be characterized by a
list of frequency ranges and permissible power levels for each range. list of frequency ranges and permissible power levels for each range.
{ {
"name": "Spectrum", "name": "Spectrum",
"type": "object", "type": "object",
"description": "A per-bandwidth list of frequency ranges with " + "description": "A per-bandwidth list of frequency ranges with " +
"permissible power levels. For example, In US, In US, FCC " + "permissible power levels. For example, In US, In US, FCC " +
"requires only one spectrum specification at 6MHz " + "requires only one spectrum specification at 6MHz " +
"bandwidth; in UK, Ofcom requires two (at 0.1MHz and " + "bandwidth; in UK, Ofcom requires two (at 0.1MHz and " +
"8MHz).", "8MHz).",
"properties": { "properties": {
"bandwidth": { "bandwidth": {
"type": "number", "type": "number",
"description": "Operating bandwidth for which permissible " + "description": "Operating bandwidth (Hz) for which " +
"power levels are applicable.", "permissible power levels are applicable.",
"required": true "required": true
}, },
"frequencyRanges": { "frequencyRanges": {
"type": "array", "type": "array",
"description": "List of FrequencyRange objects to specify " + "description": "List of FrequencyRange objects to specify " +
"frequency ranges and permissible power levels for " + "frequency ranges and permissible power levels for " +
"a given bandwidth. The list MAY be empty when there " + "a given bandwidth. The list MAY be empty when there " +
"is no available spectrum.", "is no available spectrum.",
"items": "FrequencyRange", "items": "FrequencyRange",
"required": true "required": true
} }
} }
} }
6.8.8. FrequencyRange 6.8.10. FrequencyRange
The FrequencyRange (Section 5.8) element describes a frequency range The FrequencyRange (Section 5.10) element describes a frequency range
and permissible power level within the specified range. and permissible power level within the specified range.
{ {
"name": "FrequencyRange", "name": "FrequencyRange",
"type": "object", "type": "object",
"properties": { "properties": {
"startHz": { "startHz": {
"type": "number", "type": "number",
"description": "The inclusive start of the frequency range.", "description": "The inclusive start of the frequency range.",
"required": true "required": true
}, },
"stopHz": { "stopHz": {
"type": "number", "type": "number",
"description": "The exclusive end of the frequency range.", "description": "The exclusive end of the frequency range.",
"required": true "required": true
}, },
"maxPowerDBm": { "maxPowerDBm": {
"type": "number", "type": "number",
"description": "The maximum total power level (EIRP), " + "description": "The maximum total power level (EIRP), " +
"computed over the corresponding operating bandwidth, " + "computed over the corresponding operating bandwidth, " +
"that is permitted within the frequency range. This " "that is permitted within the frequency range. This " +
"field is optional when specifying device " + "field is optional when specifying device " +
"capabilities, but is otherwise required.", "capabilities, but is otherwise required.",
"required": false "required": false
}, },
"channelId": { "channelId": {
"type": "string", "type": "string",
"required": false "required": false
} }
} }
} }
6.8.9. EventTime 6.8.11. EventTime
The EventTime (Section 5.9) element specifies the start and stop The EventTime (Section 5.11) element specifies the start and stop
times of an "event." It is used to indicate the time period for times of an "event." It is used to indicate the time period for
which a Spectrum (Section 5.7) is valid. which a Spectrum (Section 5.9) is valid.
{ {
"name": "EventTime", "name": "EventTime",
"type": "object", "type": "object",
"properties": { "properties": {
"startTime": { "startTime": {
"type": "string", "type": "string",
"description": "YYYY-MM-DDThh:mm:ssZ RFC3339 format.", "description": "YYYY-MM-DDThh:mm:ssZ RFC3339 format.",
"format": "date-time", "format": "date-time",
"required": false "required": false
}, },
"stopTime": { "stopTime": {
"type": "string", "type": "string",
"description": "YYYY-MM-DDThh:mm:ssZ RFC3339 format.", "description": "YYYY-MM-DDThh:mm:ssZ RFC3339 format.",
"format": "date-time", "format": "date-time",
"required": false "required": false
} }
} }
} }
6.8.10. SpectrumSchedule 6.8.12. SpectrumSchedule
The SpectrumSchedule (Section 5.10) element combines EventTime with The SpectrumSchedule (Section 5.12) element combines EventTime with
Spectrum to define a time period during which the spectrum is valid. Spectrum to define a time period during which the spectrum is valid.
{ {
"name": "SpectrumSchedule", "name": "SpectrumSchedule",
"type": "object", "type": "object",
"description": "The SpectrumSchedule element combines EventTime " + "description": "The SpectrumSchedule element combines EventTime " +
"with Spectrum to define a time period during which spectrum " + "with Spectrum to define a time period during which spectrum " +
"is valid.", "is valid.",
"properties": { "properties": {
"eventTime": { "eventTime": {
skipping to change at page 66, line 5 skipping to change at page 71, line 5
"type": "array", "type": "array",
"description": "List of available spectra and permissible " + "description": "List of available spectra and permissible " +
"power levels; one spectrum object per bandwidth. The " + "power levels; one spectrum object per bandwidth. The " +
"list MAY be empty when there is no available spectrum.", "list MAY be empty when there is no available spectrum.",
"items": "Spectrum", "items": "Spectrum",
"required": true "required": true
} }
} }
} }
6.8.11. GeoSpectrumSchedule 6.8.13. GeoSpectrumSchedule
The GeoSpectrumSchedule (Section 5.11) element encapsulates the The GeoSpectrumSchedule (Section 5.13) element encapsulates the
schedule of available spectrum at a location. schedule of available spectrum at a location.
{ {
"name": "GeoSpectrumSchedule", "name": "GeoSpectrumSchedule",
"type": "object", "type": "object",
"description": "The GeoSpectrumSchedule element encapsulates " + "description": "The GeoSpectrumSchedule element encapsulates " +
"the schedule of available spectrum at a location.", "the schedule of available spectrum at a location.",
"properties": { "properties": {
"location": { "location": {
"type": "GeoLocation", "type": "GeoLocation",
skipping to change at page 66, line 34 skipping to change at page 71, line 34
"description": "At least one schedule MUST be included " + "description": "At least one schedule MUST be included " +
"(though it MAY be empty if there is no available " + "(though it MAY be empty if there is no available " +
"spectrum. More than one schedule MAY be included " + "spectrum. More than one schedule MAY be included " +
"to represent future changes to the available spectrum.", "to represent future changes to the available spectrum.",
"items": "SpectrumSchedule", "items": "SpectrumSchedule",
"required": true "required": true
} }
} }
} }
6.8.12. DeviceValidity 6.8.14. DeviceValidity
The DeviceValidity (Section 5.12) element is used to indicate whether The DeviceValidity (Section 5.14) element is used to indicate whether
a device is valid. See Section 4.5.2. a device is valid. See Section 4.5.2.
{ {
"name": "DeviceValidity", "name": "DeviceValidity",
"type": "object", "type": "object",
"description": "The GeoSpectrumSchedule element encapsulates " + "description": "The GeoSpectrumSchedule element encapsulates " +
"the schedule of available spectrum at a location.", "the schedule of available spectrum at a location.",
"properties": { "properties": {
"deviceDesc": { "deviceDesc": {
"type": "DeviceDescriptor", "type": "DeviceDescriptor",
skipping to change at page 67, line 31 skipping to change at page 72, line 31
"reason": { "reason": {
"type": "string", "type": "string",
"description": "If the device identifier is not valid, " + "description": "If the device identifier is not valid, " +
"the Database MAY include a reason. The reason MAY be " + "the Database MAY include a reason. The reason MAY be " +
"in any language.", "in any language.",
"required": false "required": false
} }
} }
} }
6.8.13. Additional Properties 6.8.15. Additional Properties
Note that A JSON Media Type for Describing the Structure and Meaning Note that A JSON Media Type for Describing the Structure and Meaning
of JSON [I-D.zyp-json-schema] allows, as default behavior, the of JSON [I-D.zyp-json-schema] allows, as default behavior, the
inclusion of additional properties by instances that are not inclusion of additional properties by instances that are not
explicitly defined in the JSON schema that the instance implements. explicitly defined in the JSON schema that the instance implements.
The schema elaborated in this document adopts this default behavior. The schema elaborated in this document adopts this default behavior.
Hence, the instance MAY provide additional properties and associated Hence, the instance MAY provide additional properties and associated
values (which may be "any" JSON type) not explictly listed in this values (which may be "any" JSON type) not explicitly listed in this
schema. Further note that the Database and Device MUST ignore any schema. Further note that the Database and Device MUST ignore any
such additional properties and their associated values that it does such additional properties and their associated values that it does
not understand. not understand.
7. HTTPS Binding 7. HTTPS Binding
This section describes the use of HTTP over TLS (HTTPS) HTTP Over TLS This section describes the use of HTTP over TLS (HTTPS) HTTP Over TLS
[RFC2818] as the transport mechanism for the PAWS protocol. TLS [RFC2818] as the transport mechanism for the PAWS protocol. TLS
provides message integrity and confidentiality between the Master provides message integrity and confidentiality between the Master
Device and the Database. The Master Device MUST implement server Device and the Database. The Master Device MUST implement server
skipping to change at page 68, line 26 skipping to change at page 73, line 26
A PAWS request message is carried in the body of an HTTP POST A PAWS request message is carried in the body of an HTTP POST
request. A PAWS response message is carried in the body of an HTTP request. A PAWS response message is carried in the body of an HTTP
response. A PAWS response SHOULD include a Content-Length header. response. A PAWS response SHOULD include a Content-Length header.
The POST method is the only method REQUIRED for PAWS. If a database The POST method is the only method REQUIRED for PAWS. If a database
chooses to support GET, it MUST be an escaped URL, but the encoding chooses to support GET, it MUST be an escaped URL, but the encoding
of the URL is outside the scope of this document. The database MAY of the URL is outside the scope of this document. The database MAY
refuse to support the GET request by returning an HTTP error code, refuse to support the GET request by returning an HTTP error code,
such as 404 (not found). such as 404 (not found).
The Database MAY redirect a PAWS request. The Master Device MUST The Database MAY redirect a PAWS request by returning a HTTP 3xx
handle redirects by using the Location header provided by the server response (as defined by HTTP/1.1 [RFC2616]). The Database MUST
in a 3xx response. When redirecting, the Master Device MUST observe provide the redirect URI in the Location header of the 3xx response,
the delay indicated by the Retry-After header. The Master Device and the Device MUST handle redirects by using the Location header
MUST authenticate the Database that returns the redirect response provided by the Database. When redirecting, the Device MUST observe
before following the redirect. The Master Device MUST authenticate the delay indicated by the Retry-After header. The Device MUST
the Database indicated in the redirect. authenticate the Database that returns the redirect response before
following the redirect. Also, the Device MUST authenticate the
Database indicated in the redirect. Since the Device may communicate
with a Database (which it authenticated) without user interaction,
when the response code is 301 (Moved Permanently), the Device MAY
redirect without asking a user for confirmation (note that this
represents an exception to the HTTP/1.1 [RFC2616] requirements for
HTTP POST methods).
8. Extensibility 8. Extensibility
8.1. Defining New Message Parameters 8.1. Defining New Message Parameters
New request or response parameters for use with the PAWS protocol are New request or response parameters for use with the PAWS protocol are
defined and registered in the parameters registry following the defined and registered in the parameters registry following the
procedure in Section 9.1. procedure in Section 9.1.
Parameter names MUST conform to the param-name ABNF and parameter Parameter names MUST conform to the param-name ABNF and parameter
values syntax MUST be well-defined (e.g., using ABNF, or a reference values syntax MUST be well-defined (e.g., using ABNF, or a reference
to the syntax of an existing parameter). to the syntax of an existing parameter).
param-name = 1*name-char param-name = 1*name-char
name-char = ALPHA / DIGIT / "_" name-char = ALPHA / DIGIT / "_"
The parameter name SHOULD be lowerCamelCase. The parameter name SHOULD be lowerCamelCase. The name SHALL NOT
exceed 64 characters.
Unregistered vendor-specific parameter extensions that are not Unregistered vendor-specific parameter extensions that are not
commonly applicable, and are specific to the implementation details commonly applicable, and are specific to the implementation details
of the Database where they are used SHOULD use a vendor-specific of the Database where they are used SHOULD use a vendor-specific
prefix that is no likely to conflict with other registered values prefix that is not likely to conflict with other registered values
(e.g., begin with 'companyname_'). (e.g., begin with 'companyname').
8.2. Defining Ruleset Identifiers 8.2. Defining Ruleset Identifiers
A rule set represents a set of device-side requirements for which the A rule set represents a set of device-side requirements for which the
device has been certified. It typically corresponds to, but is not device has been certified. It typically corresponds to, but is not
limited to, a set of rules that govern a specific set of radio limited to, a set of rules that govern a specific set of radio
spectrum for a regulatory domain. spectrum for a regulatory domain.
Rule-set identifiers are defined and registered in the Ruleset ID Rule-set identifiers are defined and registered in the Ruleset ID
Registry following the procedure in Section 9.2. Ruleset ID values Registry following the procedure in Section 9.2. Ruleset ID values
MUST conform to the ruleset-id ABNF. If the Ruleset ID requires MUST conform to the ruleset-id ABNF. If the Ruleset ID requires
additional parameters, they MUST be registered in the PAWS Parameters additional parameters, they MUST be registered in the PAWS Parameters
Registry, as described by Section 9.1. Registry, as described by Section 9.1.
ruleset-id = 1*ruleset-char ruleset-id = 1*ruleset-char
ruleset-char = ALPHA / DIGIT / "_" ruleset-char = ALPHA / DIGIT / "_" / "."
The form of a Ruleset ID value SHOULD be guided by the following: The form of a Ruleset ID value SHOULD be guided by the following:
o The value should describe the set of rules that allow a device to o The value SHOULD describe the set of rules that allow a device to
operate within a regulatory domain. For example, it may include operate within one or more regulatory domains. For example, it
the name of a regulatory body or a certification process MAY include the name of a regulatory body or a certification
o The value should include version information, such as a year or process
version number o The value SHOULD include version information, such as a year
and/or version number
o The value SHALL NOT exceed 64 characters
8.3. Defining Additional Error Codes 8.3. Defining Additional Error Codes
Additional error codes MAY be defined to extend the set listed in Additional error codes MAY be defined to extend the set listed in
Section 5.13. Additional error codes MUST be registered, following Section 5.15. Additional error codes MUST be registered, following
the procedures in Section 9.3. If the error code requires additional the procedures in Section 9.3. If the error code requires additional
response parameters, they MUST be registered in the PAWS Parameters response parameters, they MUST be registered in the PAWS Parameters
Registry, as described by Section 9.1. Registry, as described by Section 9.1.
By convention, the error code SHOULD be a negative integer value, By convention, the error code SHOULD be a negative integer value,
using one of the range of values defined in Error Codes using one of the range of values defined in Error Codes
(Section 5.13). If an appropriate category does not exist, it MAY (Section 5.15). If an appropriate category does not exist, it MAY
use values in a different range. use values in a different range.
9. IANA Considerations 9. IANA Considerations
9.1. PAWS Parameters Registry 9.1. PAWS Parameters Registry
This specification establishes the PAWS Parameters Registry. This specification establishes the PAWS Parameters Registry.
Additional parameters for inclusion in the PAWS protocol requests, Additional parameters for inclusion in the PAWS protocol requests,
responses, or sub-messages are registered through the Specification responses, or sub-messages are registered through the Specification
Required [RFC5226] process, after a two-week review period on the Required [RFC5226] process, after a two-week review period on the
[TBD]@ietf.org mailing list, on the advice of one or more Designated [TBD]@ietf.org mailing list, on the advice of one or more Designated
Experts. To allow for the allocation of values prior to publication, Experts. To allow for the allocation of values prior to publication,
the Designated Expert(s) may approve registration once they are the Designated Expert(s) may approve registration once they are
skipping to change at page 71, line 5 skipping to change at page 76, line 13
sections also may be included, but is not required. sections also may be included, but is not required.
9.1.2. Initial Registry Contents 9.1.2. Initial Registry Contents
The PAWS Parameters Registry enables protocol extensibility to The PAWS Parameters Registry enables protocol extensibility to
support any regulatory domain and rule set. The initial contents of support any regulatory domain and rule set. The initial contents of
the registry, however, include only FCC-specific entries, because, as the registry, however, include only FCC-specific entries, because, as
of this writing, it is the only regulatory domain that has finalized of this writing, it is the only regulatory domain that has finalized
rules. There is no intent to restrict the protocol to FCC rules. rules. There is no intent to restrict the protocol to FCC rules.
The PAWS Parameters Registry's initial contents are: The PAWS Parameters Registry's initial contents are listed below.
o Parameter name: fccId FCC ID
o Parameter usage location: DeviceDescriptor (Section 5.2)
o Specification Document(s): [[ this document (Section 5.2) ]] Parameter name: fccId
o Parameter name: fccTvbdDeviceType Parameter usage location: DeviceDescriptor (Section 5.2)
o Parameter usage location: DeviceDescriptor (Section 5.2) Specification document(s): [[ this document ]] Specifies the
o Specification Document(s): [[ this document ]] Specifies the TV device's FCC certification identifier. The value is an identifier
Band White Space device type, as defined by the FCC. Valid values string whose length SHALL NOT exceed 32 characters. Note that, in
are "FIXED", "MODE_1", "MODE_2". practice, a valid FCC ID may be limited to 19 characters, as
proposed in FCC Administration Topics Review [FCC-Review-2012-10].
FCC Device Type
Parameter name: fccTvbdDeviceType
Parameter usage location: DeviceDescriptor (Section 5.2)
Specification document(s): [[ this document ]] Specifies the TV Band
White Space device type, as defined by the FCC. Valid values are
"FIXED", "MODE_1", "MODE_2".
ETSI Device Type
Parameter name: etsiEnDeviceType
Parameter usage location: DeviceDescriptor (Section 5.2)
Specification document(s): Specifies the White Space Device device
type, as defined by the ETSI Harmonised Standard
[ETSI-EN-301-598]. Valid values are single-letter strings, such
as "A", "B", etc. Consult the documentation for details about the
device types.
ETSI Device Emissions Class
Parameter name: etsiEnDeviceEmissionsClass
Parameter usage location: DeviceDescriptor (Section 5.2)
Specification document(s): Specifies the White Space Device device
emissions class, as defined by the ETSI Harmonised Standard
[ETSI-EN-301-598], that characterises the out-of-block emissions
of the device. The values are represented by numeric strings,
such as "1", "2", etc. Consult the documentation for details
about emissions classes
ETSI Technology Identifier
Parameter name: etsiEnTechnologyId
Parameter usage location: DeviceDescriptor (Section 5.2)
Specification document(s): Specifies the White Space Device
technology identifier, as defined by the ETSI Harmonised Standard
[ETSI-EN-301-598]. The string value SHALL NOT exceed 64
characters in length. Consult the documentation for valid values.
ETSI Device Category
Parameter name: etsiEnDeviceCategory
Parameter usage location: DeviceDescriptor (Section 5.2)
Specification document(s): Specifies the White Space Device device
category, as defined by the ETSI Harmonised Standard
[ETSI-EN-301-598]. Valid values are the strings, "master" and
"slave". It is case insensitive.
9.2. PAWS Ruleset ID Registry 9.2. PAWS Ruleset ID Registry
This specification establishes the PAWS Ruleset ID Registry. This specification establishes the PAWS Ruleset ID Registry.
Ruleset type names for inclusion in the PAWS protocol messages are Ruleset type names for inclusion in the PAWS protocol messages are
registered through the Specification Required [RFC5226] process, registered through the Specification Required [RFC5226] process,
after a two-week review period on the [TBD]@ietf.org mailing list, on after a two-week review period on the [TBD]@ietf.org mailing list, on
the advice of one or more Designated Experts. To allow for the the advice of one or more Designated Experts. To allow for the
allocation of values prior to publication, the Designated Expert(s) allocation of values prior to publication, the Designated Expert(s)
skipping to change at page 71, line 46 skipping to change at page 78, line 7
to the review list and IANA. Denials should include an explanation to the review list and IANA. Denials should include an explanation
and, if applicable, suggestions as to how to make the request and, if applicable, suggestions as to how to make the request
successful. successful.
IANA must only accept registry updates from the Designated Expert(s), IANA must only accept registry updates from the Designated Expert(s),
and should direct all requests for registration to the review mailing and should direct all requests for registration to the review mailing
list. list.
9.2.1. Registration Template 9.2.1. Registration Template
Ruleset name: The name of the rule set. Ruleset name: The name of the rule set. The length of the string
SHALL NOT exceed 64 characters.
Additional message parameters: Additional parameters to associate Additional message parameters: Additional parameters to associate
with the rulesetId parameter. New parameters MUST be registered with the rulesetId parameter. New parameters MUST be registered
separately in the PAWS Parameters Registry, as described by separately in the PAWS Parameters Registry, as described by
Section 8.1. Section 8.1.
Specification Document(s): Reference to the document that specifies Specification Document(s): Reference to the document that specifies
the parameter, preferably including a URI that can be used to the parameter, preferably including a URI that can be used to
retrieve a copy of the document. An indication of the relevant retrieve a copy of the document. An indication of the relevant
sections also may be included, but is not required. sections also may be included, but is not required.
9.2.2. Initial Registry Contents 9.2.2. Initial Registry Contents
The PAWS Ruleset ID Registry enables protocol extensibility to The PAWS Ruleset ID Registry enables protocol extensibility to
support any regulatory domain and rule set. The initial contents of support any regulatory domain and rule set. The initial contents of
the registry, however, include only FCC-specific entries, because, as the registry, however, include only FCC-specific entries, because, as
skipping to change at page 72, line 18 skipping to change at page 78, line 26
sections also may be included, but is not required. sections also may be included, but is not required.
9.2.2. Initial Registry Contents 9.2.2. Initial Registry Contents
The PAWS Ruleset ID Registry enables protocol extensibility to The PAWS Ruleset ID Registry enables protocol extensibility to
support any regulatory domain and rule set. The initial contents of support any regulatory domain and rule set. The initial contents of
the registry, however, include only FCC-specific entries, because, as the registry, however, include only FCC-specific entries, because, as
of this writing, it is the only regulatory domain that has finalized of this writing, it is the only regulatory domain that has finalized
rules. There is no intent to restrict the protocol to FCC rules. rules. There is no intent to restrict the protocol to FCC rules.
The initial content of the PAWS Ruleset ID Registry is: The initial contents of the PAWS Ruleset ID Registry are listed
below.
o Ruleset name: FccTvBandWhiteSpace-2010 9.2.2.1. Federal Communications Commission (FCC)
o Additional message parameters:
* fccId: Specifies a device's FCC certification ID. It is a For the additional parameters that start with the "fcc" prefix, see
PAWS Parameters Registry Initial Contents (Section 9.1.2) for more
information.
Ruleset name: FccTvBandWhiteSpace-2010
Additional message parameters:
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).
o Specification Document(s): [[ this document ]] This rule set Specification document(s): [[ this document ]] This rule set refers
refers to the FCC rules for TV-band White Space operations to the FCC rules for TV-band White Space operations established in
established in the Code of Federal Regulations (CFR), Title 47, the Code of Federal Regulations (CFR), Title 47, Part 15, Subpart
Part 15, Subpart H (http://www.gpo.gov/fdsys/pkg/ H [FCC-CFR47-15H].
CFR-2010-title47-vol1/pdf/
CFR-2010-title47-vol1-part15-subpartH.pdf). 9.2.2.2. European Telecommunications Standards Institute (ETSI)
For the additional parameters that start with the "etsi" prefix, see
PAWS Parameters Registry Initial Contents (Section 9.1.2) for more
information.
Ruleset name: TBD
Additional message parameters:
manufacturerId: Specifies a device's manufacturer's identifier.
It is a required parameter in DeviceDescriptor (Section 5.2).
modelId: Specifies a device's model identifier. It is a required
parameter in DeviceDescriptor (Section 5.2).
etsiEnDeviceType: Specifies the device's ETSI device type. It is
a required parameter in DeviceDescriptor (Section 5.2).
etsiEnDeviceEmissionsClass: Specifies the device's ETSI device
emissions class. It is a required parameter in
DeviceDescriptor (Section 5.2).
etsiEnTechnologyId: Specifies the device's ETSI technology ID.
It is a required parameter in DeviceDescriptor (Section 5.2).
etsiEnDeviceCategory: Specifies the device's ETSI device
category. It is a required parameter in DeviceDescriptor
(Section 5.2).
needsSpectrumReport Depending on the regulatory domain, the
Database MAY be required to set this value to true in the
AvailSpectrumResponse (Section 4.4.2) and
AvailSpectrumBatchResponse (Section 4.4.4) messages.
maxTotalBwHz: Specifies a constraint on total allowed bandwidth.
It is a required parameter in AvailSpectrumResponse
(Section 4.4.2) and AvailSpectrumBatchResponse (Section 4.4.4).
maxContiguousBwHz: Specifies a constraint on total allowed
contiguous bandwidth. It is a required parameter in
AvailSpectrumResponse (Section 4.4.2) and
AvailSpectrumBatchResponse (Section 4.4.4).
maxLocationChange: Specifies a constraint on maximum location
changes. It is a required parameter in AvailSpectrumResponse
(Section 4.4.2) and AvailSpectrumBatchResponse (Section 4.4.4).
Specification document(s): This rule set refers to the ETSI
Harmonised Standard [ETSI-EN-301-598] established by ETSI.
9.3. PAWS Error Code Registry 9.3. PAWS Error Code Registry
This specification establishes the PAWS Error Code Registry. This specification establishes the PAWS Error Code Registry.
Additional error codes for inclusion in the PAWS protocol error Additional error codes for inclusion in the PAWS protocol error
message are registered through the Specification Required [RFC5226] message are registered through the Specification Required [RFC5226]
process, after a two-week review period on the [TBD]@ietf.org mailing process, after a two-week review period on the [TBD]@ietf.org mailing
list, on the advice of one or more Designated Experts. To allow for list, on the advice of one or more Designated Experts. To allow for
the allocation of values prior to publication, the Designated the allocation of values prior to publication, the Designated
skipping to change at page 73, line 18 skipping to change at page 80, line 22
IANA must only accept registry updates from the Designated Expert(s), IANA must only accept registry updates from the Designated Expert(s),
and should direct all requests for registration to the review mailing and should direct all requests for registration to the review mailing
list. list.
9.3.1. Registration Template 9.3.1. Registration Template
Code: Integer value of the error code. Code: Integer value of the error code.
Name: Name of the error. Name: Name of the error.
Additional parameters: Additional parameters that are returned in Additional parameters: Additional parameters that are returned in
the data portion of the error (See Section 5.13). New parameters the data portion of the error (See Section 5.15). New parameters
MUST be registered separately in the PAWS Parameters Registry, as MUST be registered separately in the PAWS Parameters Registry, as
described by Section 9.1. described by Section 9.1.
Description: Description of the error and its associated parameters, Description: Description of the error and its associated parameters,
if any. if any.
9.3.2. Initial Registry Contents 9.3.2. Initial Registry Contents
Initial registry contents are defined in the Table of Error Codes Initial registry contents are defined in the Table of Error Codes
(Table 1). (Table 1).
skipping to change at page 74, line 23 skipping to change at page 81, line 25
3. The Database must determine or compute accurate spectrum- 3. The Database must determine or compute accurate spectrum-
availability information. availability information.
4. PAWS messages must be transmitted unmodified between the Database 4. PAWS messages must be transmitted unmodified between the Database
and the Master Device. and the Master Device.
5. PAWS messages must be encrypted between the Database and the 5. PAWS messages must be encrypted between the Database and the
Master Device to prevent exposing private information. Master Device to prevent exposing private information.
6. For a Slave Device, the spectrum-availability information also 6. For a Slave Device, the spectrum-availability information also
must be transmitted unmodified and secure between the Master must be transmitted unmodified and secure between the Master
Device and the Slave Device. Device and the Slave Device.
Of these, only steps 2, 4, and 5 are within the scope of this Of these, only steps 2, 4, and 5 are within the scope of this
document. [Editor's note: It is still open whether Step 1 is within document. This document addresses Step 1 by allowing static
the scope of this document]. Step 3 dependent on specific database provisioning of one or more trusted Databases; dynamic provisioning
is out of scope. Step 3 dependent on specific database
implementations and regulatory rules and is outside the scope of this implementations and regulatory rules and is outside the scope of this
document. Step 6 requires a protocol between master and slave document. Step 6 requires a protocol between master and slave
devices and is thus outside the scope of this document. devices and is thus outside the scope of this document.
10.1. Assurance of Proper Database 10.1. Assurance of Proper Database
This document assumes that the Database is contacted using a domain This document assumes that the Database is contacted using a domain
name or an IP address. Using HTTP over TLS HTTP Over TLS [RFC2818], name or an IP address. Using HTTP over TLS HTTP Over TLS [RFC2818],
the Database authenticates its identity, either as a domain name or the Database authenticates its identity, either as a domain name or
IP address, to the Master Device by presenting a certificate IP address, to the Master Device by presenting a certificate
skipping to change at page 75, line 26 skipping to change at page 82, line 29
without ever contacting a database. Consequently, client without ever contacting a database. Consequently, client
authentication is not required for the core PAWS protocol (although authentication is not required for the core PAWS protocol (although
it may be required by specific regulators). Depending on a prior it may be required by specific regulators). Depending on a prior
relationship between a Database and Master Device, the Database MAY relationship between a Database and Master Device, the Database MAY
require client authentication. TLS provides client authentication, require client authentication. TLS provides client authentication,
but there are some considerations: but there are some considerations:
o As indicated in Section 3.2 of HTTP Over TLS [RFC2818], the TLS o As indicated in Section 3.2 of HTTP Over TLS [RFC2818], the TLS
client authentication procedure only determines that the device client authentication procedure only determines that the device
has a certificate chain rooted in an appropriate CA (or a self- has a certificate chain rooted in an appropriate CA (or a self-
signed certicate). The database would not know what the client signed certificate). The database would not know what the client
identity ought to be, unless it has some external source of identity ought to be, unless it has some external source of
information. Distribution and management of such information, information. Distribution and management of such information,
including revocation lists, are outside the scope of this including revocation lists, are outside the scope of this
document. document.
o Authentication schemes are secure only to the extent that secrets o Authentication schemes are secure only to the extent that secrets
or certificates are kept secure. When there are a vast number of or certificates are kept secure. When there are a vast number of
deployed devices using PAWS, the possibility that device keys will deployed devices using PAWS, the possibility that device keys will
not leak becomes small. Implementations should consider how to not leak becomes small. Implementations should consider how to
manage the system in the eventuality that there is a leak. manage the system in the eventuality that there is a leak.
skipping to change at page 76, line 22 skipping to change at page 83, line 22
Xinpeng Wei Xinpeng Wei
Huawei Huawei
Phone: +86 13436822355 Phone: +86 13436822355
Email: weixinpeng@huawei.com Email: weixinpeng@huawei.com
12. Acknowledgments 12. Acknowledgments
The authors gratefully acknowledge the contributions of: Gabor Bajko, The authors gratefully acknowledge the contributions of: Gabor Bajko,
Teco Boot, Nancy Bravin, Rex Buddenberg, Gerald Chouinard, Stephen Teco Boot, Nancy Bravin, Rex Buddenberg, Gerald Chouinard, Stephen
Farrell, Michael Fitch, Joel M. Halpern, Jussi Kahtava, Warren Farrell, Michael Fitch, Joel M. Halpern, Jussi Kahtava, Warren
Kumari, Paul Lambert, Andy Lee, Anthony Mancuso, Basavaraj Patil, Kumari, Kalle Kulsmanen, Paul Lambert, Andy Lee, Anthony Mancuso,
Scott Probasco, Brian Rosen, Andy Sago, Peter Stanforth, John Stine, Basavaraj Patil, Scott Probasco, Brian Rosen, Andy Sago, Peter
and Juan Carlos Zuniga. Stanforth, John Stine, and Juan Carlos Zuniga.
13. References 13. References
13.1. Normative References 13.1. Normative References
[FCC-CFR47-15H]
U. S. Government, "Electronic Code of Federal Regulations,
Title 47, Part 15, Subpart H: Television Band Devices",
December 2010, <http://www.ecfr.gov/cgi-bin/
text-idx?rgn=div6&view=text&node=47:1.0.1.1.16.8>.
[ITUT.X520.2008]
International Telecommunication Union, "ITU-T
Recommendation X.520: Information technology - Open
Systems Interconnection - The Directory: Selected
attribute types", November 2008,
<http://www.itu.int/rec/T-REC-X.520-200811-I>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002. Internet: Timestamps", RFC 3339, July 2002.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008. Server-Side State", RFC 5077, January 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
skipping to change at page 77, line 10 skipping to change at page 84, line 29
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009. RFC 5491, March 2009.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
August 2011. August 2011.
[WGS-84] National Imagery and Mapping Agency, "Department of
Defense World Geodetic System 1984, Its Definition and
Relationships with Local Geodetic Systems, NIMA TR8350.2
Third Edition Amendment 1", January 2000, <http://
earth-info.nga.mil/GandG/publications/tr8350.2/
tr8350_2.html>.
13.2. Informative References 13.2. Informative References
[ETSI-EN-301-598]
European Telecommunication Standards Institute (ETSI),
"TBD: (ETSI EN 301 598)", 2013, <TBD>.
[FCC-Review-2012-10]
Federal Communications Commission, "Administration Topics
Review", October 2012, <http://transition.fcc.gov/bureaus/
oet/ea/presentations/files/oct12/
2b-TCB-Admin-Issues-Oct-2012-GT.pdf>.
[I-D.bhat-vcarddav-json] [I-D.bhat-vcarddav-json]
Bhat, R. and P. Saint-Andre, "A JavaScript Object Notation Bhat, R. and P. Saint-Andre, "A JavaScript Object Notation
(JSON) Representation for vCard", (JSON) Representation for vCard",
draft-bhat-vcarddav-json-00 (work in progress), June 2012. draft-bhat-vcarddav-json-00 (work in progress), June 2012.
[I-D.das-paws-protocol] [I-D.das-paws-protocol]
Das, S., Malyar, J., and D. Joslyn, "Device to Database Das, S., Malyar, J., and D. Joslyn, "Device to Database
Protocol for White Space", draft-das-paws-protocol-02 Protocol for White Space", draft-das-paws-protocol-02
(work in progress), July 2012. (work in progress), July 2012.
[I-D.ietf-paws-problem-stmt-usecases-rqmts] [I-D.ietf-paws-problem-stmt-usecases-rqmts]
Mancuso, A. and B. Patil, "Protocol to Access White Space Mancuso, A., Probasco, S., and B. Patil, "Protocol to
(PAWS) Database: Use Cases and Requirements", Access White Space (PAWS) Database: Use Cases and
draft-ietf-paws-problem-stmt-usecases-rqmts-12 (work in Requirements",
progress), January 2013. draft-ietf-paws-problem-stmt-usecases-rqmts-15 (work in
progress), March 2013.
[I-D.wei-paws-framework] [I-D.wei-paws-framework]
Wei, X., Zhu, L., and P. McCann, "PAWS Framework", Wei, X., Zhu, L., and P. McCann, "PAWS Framework",
draft-wei-paws-framework-00 (work in progress), July 2012. draft-wei-paws-framework-00 (work in progress), July 2012.
[I-D.zyp-json-schema] [I-D.zyp-json-schema]
Galiegue, F., Zyp, K., and G. Court, "JSON Schema: core Galiegue, F., Zyp, K., and G. Court, "JSON Schema: core
definitions and terminology", draft-zyp-json-schema-04 definitions and terminology", draft-zyp-json-schema-04
(work in progress), January 2013. (work in progress), January 2013.
[ISO3166-1] [ISO3166-1]
"Country Codes", "Country Codes",
<http://www.iso.org/iso/country_codes.htm>. <http://www.iso.org/iso/country_codes.htm>.
[JSON-RPC] [JSON-RPC]
"JSON-RPC 2.0 Specification", "JSON-RPC 2.0 Specification",
<http://www.jsonrpc.org/specification>. <http://www.jsonrpc.org/specification>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006. JavaScript Object Notation (JSON)", RFC 4627, July 2006.
Appendix A. Changes / Author Notes. Appendix A. Changes / Author Notes.
Changes from 03:
o Expanded the Database Discovery mechanism to describe in more
detail pre-configuration with URIs of databases and database-
listing services, including mechanisms for updating the
configurations when things change
* Add database-change field to Available Spectrum Response
(Section 4.4.2)
o Added fields that are anticipated to be needed by the ETSI
harmonized standard for White Space Devices:
* Added bandwidth constraints to the Available Spectrum Response
(Section 4.4.2)
* Updated Available Spectrum Response to return RulesetInfo,
rather than just a rule-set identifier
* Added optional device-manufacturer and device-model IDs to the
DeviceDescriptor (Section 5.2). message. Also moved fccId from
this message to the IANA section.
* Expanded IANA (Section 9) sections
o Clarified restrictions on the specification of the vertices of a
Polygon.
o Changed default confidence level to 95% for a point with
uncertainty
o Clarified how devices without absolute time source can use the
timestamps in the response messages
o Change method names to start with "spectrum.paws." prefix
o Added maximum string lengths
o Updated author contact info
o More typo fixes
Changes from 02: Changes from 02:
o Added timestamp to the AVAIL_SPECTRUM_RESP (Section 4.4.2) and o Added timestamp to the AVAIL_SPECTRUM_RESP (Section 4.4.2) and
AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4) data models to serve as AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4) data models to serve as
a reference for the event times in the response. This was a reference for the event times in the response. This was
accidentally omitted (but was specified in their JSON encodings accidentally omitted (but was specified in their JSON encodings
(Section 6)). (Section 6)).
o Fixed typos throughout the JSON encoding (Section 6) sections, o Fixed typos throughout the JSON encoding (Section 6) sections,
typically adding missing commas. typically adding missing commas.
skipping to change at page 79, line 4 skipping to change at page 87, line 14
Authors' Addresses Authors' Addresses
Vincent Chen (editor) Vincent Chen (editor)
Google Google
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US US
Email: vchen@google.com Email: vchen@google.com
Subir Das Subir Das
Applied Communication Sciences Applied Communication Sciences
444 Hoes Lane 150 Mount Airy Road
Piscataway, NJ 08854 Basking Ridge, NJ 07920
U.S.A. U.S.A.
Phone: Phone:
Fax: Fax:
Email: sdas at appcomsci dot com Email: sdas at appcomsci dot com
URI: URI:
Lei Zhu Lei Zhu
Huawei Huawei
Phone: +86 13910157020 Phone: +86 13910157020
Fax: Fax:
Email: lei.zhu@huawei.com Email: lei.zhu@huawei.com
URI: URI:
John Malyar John Malyar
Telcordia Technologies Inc. iconectiv (formerly Telcordia Interconnection Solutions)
1 Ericsson Drive 444 Hoes Lane/RRC 4E1106
Piscataway, NJ 08854 Piscataway, NJ 08854
U.S.A. U.S.A.
Phone: Phone:
Fax: Fax:
Email: jmalyar at telcordia dot com Email: jmalyar at iconectiv dot com
URI: URI:
Peter J. McCann Peter J. McCann
Huawei Huawei
400 Crossing Blvd, 2nd Floor 400 Crossing Blvd, 2nd Floor
Bridgewater, NJ 08807 Bridgewater, NJ 08807
USA USA
Phone: +1 908 541 3563 Phone: +1 908 541 3563
Fax: Fax:
 End of changes. 179 change blocks. 
389 lines changed or deleted 892 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/