draft-ietf-paws-protocol-10.txt   draft-ietf-paws-protocol-11.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 7, 2014 Applied Communication Sciences Expires: September 5, 2014 Applied Communication Sciences
L. Zhu L. Zhu
Huawei Huawei
J. Malyar J. Malyar
iconectiv (formerly Telcordia iconectiv (formerly Telcordia
Interconnection Solutions) Interconnection Solutions)
P. McCann P. McCann
Huawei Huawei
February 3, 2014 March 4, 2014
Protocol to Access White-Space (PAWS) Databases Protocol to Access White-Space (PAWS) Databases
draft-ietf-paws-protocol-10 draft-ietf-paws-protocol-11
Abstract Abstract
Portions of the radio spectrum that are allocated to licensees are Portions of the radio spectrum that are allocated to licensees are
available for non-interfering use. This available spectrum is called available for non-interfering use. This available spectrum is called
"White Space." Allowing secondary users access to available spectrum "White Space." Allowing secondary users access to available spectrum
"unlocks" existing spectrum to maximize its utilization and to "unlocks" existing spectrum to maximize its utilization and to
provide opportunities for innovation, resulting in greater overall provide opportunities for innovation, resulting in greater overall
spectrum utilization. spectrum utilization.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 7, 2014. This Internet-Draft will expire on September 5, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 10 skipping to change at page 3, line 10
5.1. GeoLocation . . . . . . . . . . . . . . . . . . . . . . . 29 5.1. GeoLocation . . . . . . . . . . . . . . . . . . . . . . . 29
5.2. DeviceDescriptor . . . . . . . . . . . . . . . . . . . . 31 5.2. DeviceDescriptor . . . . . . . . . . . . . . . . . . . . 31
5.3. AntennaCharacteristics . . . . . . . . . . . . . . . . . 32 5.3. AntennaCharacteristics . . . . . . . . . . . . . . . . . 32
5.4. DeviceCapabilities . . . . . . . . . . . . . . . . . . . 33 5.4. DeviceCapabilities . . . . . . . . . . . . . . . . . . . 33
5.5. DeviceOwner . . . . . . . . . . . . . . . . . . . . . . . 34 5.5. DeviceOwner . . . . . . . . . . . . . . . . . . . . . . . 34
5.6. RulesetInfo . . . . . . . . . . . . . . . . . . . . . . . 34 5.6. RulesetInfo . . . . . . . . . . . . . . . . . . . . . . . 34
5.7. DbUpdateSpec . . . . . . . . . . . . . . . . . . . . . . 35 5.7. DbUpdateSpec . . . . . . . . . . . . . . . . . . . . . . 35
5.8. DatabaseSpec . . . . . . . . . . . . . . . . . . . . . . 36 5.8. DatabaseSpec . . . . . . . . . . . . . . . . . . . . . . 36
5.9. SpectrumSpec . . . . . . . . . . . . . . . . . . . . . . 36 5.9. SpectrumSpec . . . . . . . . . . . . . . . . . . . . . . 36
5.10. SpectrumSchedule . . . . . . . . . . . . . . . . . . . . 38 5.10. SpectrumSchedule . . . . . . . . . . . . . . . . . . . . 38
5.11. Spectrum . . . . . . . . . . . . . . . . . . . . . . . . 38 5.11. Spectrum . . . . . . . . . . . . . . . . . . . . . . . . 39
5.12. SpectrumProfile . . . . . . . . . . . . . . . . . . . . . 41 5.12. SpectrumProfile . . . . . . . . . . . . . . . . . . . . . 41
5.13. FrequencyRange . . . . . . . . . . . . . . . . . . . . . 42 5.13. FrequencyRange . . . . . . . . . . . . . . . . . . . . . 42
5.14. EventTime . . . . . . . . . . . . . . . . . . . . . . . . 42 5.14. EventTime . . . . . . . . . . . . . . . . . . . . . . . . 43
5.15. GeoSpectrumSpec . . . . . . . . . . . . . . . . . . . . . 43 5.15. GeoSpectrumSpec . . . . . . . . . . . . . . . . . . . . . 43
5.16. DeviceValidity . . . . . . . . . . . . . . . . . . . . . 44 5.16. DeviceValidity . . . . . . . . . . . . . . . . . . . . . 44
5.17. Error Element . . . . . . . . . . . . . . . . . . . . . . 44 5.17. Error Element . . . . . . . . . . . . . . . . . . . . . . 45
5.17.1. OUTSIDE_COVERAGE Error . . . . . . . . . . . . . . . 46 5.17.1. OUTSIDE_COVERAGE Error . . . . . . . . . . . . . . . 47
5.17.2. DATABASE_CHANGE Error . . . . . . . . . . . . . . . . 47 5.17.2. DATABASE_CHANGE Error . . . . . . . . . . . . . . . . 47
5.17.3. REQUIRED Error . . . . . . . . . . . . . . . . . . . 47 5.17.3. REQUIRED Error . . . . . . . . . . . . . . . . . . . 47
6. Message Encoding . . . . . . . . . . . . . . . . . . . . . . 48 6. Message Encoding . . . . . . . . . . . . . . . . . . . . . . 48
6.1. JSON-RPC Binding . . . . . . . . . . . . . . . . . . . . 48 6.1. JSON-RPC Binding . . . . . . . . . . . . . . . . . . . . 48
6.2. init Method . . . . . . . . . . . . . . . . . . . . . . . 49 6.2. init Method . . . . . . . . . . . . . . . . . . . . . . . 50
6.2.1. INIT_REQ Parameters . . . . . . . . . . . . . . . . . 50 6.2.1. INIT_REQ Parameters . . . . . . . . . . . . . . . . . 50
6.2.2. INIT_RESP Parameters . . . . . . . . . . . . . . . . 51 6.2.2. INIT_RESP Parameters . . . . . . . . . . . . . . . . 51
6.3. register Method . . . . . . . . . . . . . . . . . . . . . 53 6.3. register Method . . . . . . . . . . . . . . . . . . . . . 53
6.3.1. REGISTRATION_REQ Parameters . . . . . . . . . . . . . 53 6.3.1. REGISTRATION_REQ Parameters . . . . . . . . . . . . . 53
6.3.2. REGISTRATION_RESP Parameters . . . . . . . . . . . . 54 6.3.2. REGISTRATION_RESP Parameters . . . . . . . . . . . . 54
6.4. getSpectrum Method . . . . . . . . . . . . . . . . . . . 55 6.4. getSpectrum Method . . . . . . . . . . . . . . . . . . . 55
6.4.1. AVAIL_SPECTRUM_REQ Parameters . . . . . . . . . . . . 56 6.4.1. AVAIL_SPECTRUM_REQ Parameters . . . . . . . . . . . . 56
6.4.2. AVAIL_SPECTRUM_RESP Parameters . . . . . . . . . . . 58 6.4.2. AVAIL_SPECTRUM_RESP Parameters . . . . . . . . . . . 58
6.5. getSpectrumBatch Method . . . . . . . . . . . . . . . . . 62 6.5. getSpectrumBatch Method . . . . . . . . . . . . . . . . . 62
6.5.1. AVAIL_SPECTRUM_BATCH_REQ Parameters . . . . . . . . . 63 6.5.1. AVAIL_SPECTRUM_BATCH_REQ Parameters . . . . . . . . . 63
skipping to change at page 4, line 18 skipping to change at page 4, line 18
6.8.16. Additional Properties . . . . . . . . . . . . . . . . 89 6.8.16. Additional Properties . . . . . . . . . . . . . . . . 89
7. HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . . . 89 7. HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . . . 89
8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 91 8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 91
8.1. Defining New Message Parameters . . . . . . . . . . . . . 91 8.1. Defining New Message Parameters . . . . . . . . . . . . . 91
8.2. Defining Ruleset Identifiers . . . . . . . . . . . . . . 91 8.2. Defining Ruleset Identifiers . . . . . . . . . . . . . . 91
8.3. Defining Additional Error Codes . . . . . . . . . . . . . 92 8.3. Defining Additional Error Codes . . . . . . . . . . . . . 92
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92
9.1. PAWS Parameters Registry . . . . . . . . . . . . . . . . 92 9.1. PAWS Parameters Registry . . . . . . . . . . . . . . . . 92
9.1.1. Registration Template . . . . . . . . . . . . . . . . 92 9.1.1. Registration Template . . . . . . . . . . . . . . . . 92
9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 93 9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 93
9.2. PAWS Ruleset ID Registry . . . . . . . . . . . . . . . . 94 9.2. PAWS Ruleset ID Registry . . . . . . . . . . . . . . . . 95
9.2.1. Registration Template . . . . . . . . . . . . . . . . 95 9.2.1. Registration Template . . . . . . . . . . . . . . . . 95
9.2.2. Initial Registry Contents . . . . . . . . . . . . . . 95 9.2.2. Initial Registry Contents . . . . . . . . . . . . . . 95
9.3. PAWS Error Code Registry . . . . . . . . . . . . . . . . 97 9.3. PAWS Error Code Registry . . . . . . . . . . . . . . . . 98
9.3.1. Registration Template . . . . . . . . . . . . . . . . 98 9.3.1. Registration Template . . . . . . . . . . . . . . . . 98
9.3.2. Initial Registry Contents . . . . . . . . . . . . . . 98 9.3.2. Initial Registry Contents . . . . . . . . . . . . . . 98
10. Security Considerations . . . . . . . . . . . . . . . . . . . 98 10. Security Considerations . . . . . . . . . . . . . . . . . . . 99
10.1. Assurance of Proper Database . . . . . . . . . . . . . . 99 10.1. Assurance of Proper Database . . . . . . . . . . . . . . 100
10.2. Protection Against Modification . . . . . . . . . . . . . 100 10.2. Protection Against Modification . . . . . . . . . . . . . 100
10.3. Protection Against Eavesdropping . . . . . . . . . . . . 100 10.3. Protection Against Eavesdropping . . . . . . . . . . . . 100
10.4. Client Authentication Considerations . . . . . . . . . . 100 10.4. Client Authentication Considerations . . . . . . . . . . 100
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 100 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 101
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 101 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 101
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 101 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 102
13.1. Normative References . . . . . . . . . . . . . . . . . . 101 13.1. Normative References . . . . . . . . . . . . . . . . . . 102
13.2. Informative References . . . . . . . . . . . . . . . . . 102 13.2. Informative References . . . . . . . . . . . . . . . . . 103
Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 103 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 104
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 107
1. Introduction 1. Introduction
This section provides some high level introductory material. Readers This section provides some high level introductory material. Readers
are strongly encouraged to read Protocol to Access White-Space (PAWS) are strongly encouraged to read Protocol to Access White-Space (PAWS)
Databases: Use Cases and Requirements [RFC6953] for use cases, Databases: Use Cases and Requirements [RFC6953] for use cases,
requirements, and additional background. requirements, and additional background.
A geospatial database can track available spectrum (in accordance A geospatial database can track available spectrum (in accordance
skipping to change at page 7, line 5 skipping to change at page 7, line 5
1. The Master Device obtains (statically or dynamically) the URI 1. The Master Device obtains (statically or dynamically) the URI
for a Database appropriate for its location to send subsequent for a Database appropriate for its location to send subsequent
PAWS messages. PAWS messages.
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. The Database may require the Master Device to be registered
Master Device. before providing service.
6. The Master Device sends an available-spectrum request message to 6. The Master Device sends an available-spectrum request message to
the Database. the Database.
7. If required by the regulatory domain, the Master Device must 7. The Master Device may verify with the Database that the Slave
verify with the Database that the Slave Device is valid. Device is valid.
8. The Database responds with an available-spectrum response 8. The Database responds with an available-spectrum response
message in the body of the HTTP response. message in the body of the HTTP response.
9. Depending on regulatory domain requirements and database 9. The Master Device may send a spectrum-usage notification message
implementation, the Master Device sends a spectrum-usage 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.
Different regulatory domains may impose particular requirements, such
as requiring Master Devices to register with the Database, performing
Slave Device verification, and sending spectrum usage notifications.
3.1. Multi-ruleset Support 3.1. Multi-ruleset Support
For a Master Device that supports multiple rulesets and operates with For a Master Device that supports multiple rulesets and operates with
multiple databases in multiple regulatory domains, the PAWS protocol multiple databases in multiple regulatory domains, the PAWS protocol
supports the following sequence of operations for each request by the supports the following sequence of operations for each request by the
Master Device: Master Device:
1. The Master Device includes in its request its location and 1. The Master Device includes in its request its location and
optionally includes the identifier of all the rulesets it optionally includes the identifier of all the rulesets it
supports and any parameter values it might need for the request supports and any parameter values it might need for the request
2. The Database uses the device location and also may use the 2. The Database uses the device location and also may use the
ruleset list to determine its response, for example, to select ruleset list to determine its response, for example, to select
the list of required parameters the list of required parameters
3. If required parameters are missing from the request, the Database 3. If required parameters are missing from the request, the Database
responds with a REQUIRED error and a list of names of the missing responds with an error and a list of names of the missing
parameters parameters
4. The Master Device makes the request again, adding the missing 4. The Master Device makes the request again, adding the missing
parameter values parameter values
5. The Database responds to the request, including the identifier of 5. The Database responds to the request, including the identifier of
the applicable ruleset the applicable ruleset
6. The Master Device uses the indicated ruleset to determine how to 6. The Master Device uses the indicated ruleset to determine how to
interpret the Database response interpret the Database response
NOTE: Regulatory rules contain many device-only requirements that NOTE: Regulatory rules contain many device-only requirements that
govern device behavior, independent of any database rules. These govern device behavior, independent of any database rules. These
skipping to change at page 8, line 24 skipping to change at page 8, line 26
o Database Discovery (Section 4.1) MUST be supported by the Master o Database Discovery (Section 4.1) MUST be supported by the Master
Device Device
o Initialization (Section 4.2) MAY be used by the Master Device and o Initialization (Section 4.2) MAY be used by the Master Device and
MUST be implemented by the Database. MUST be implemented by the Database.
o Device Registration (Section 4.3) MAY be used by the Master Device o Device Registration (Section 4.3) MAY be used by the Master Device
and MAY be implemented by the Database as a separate component or and MAY be implemented by the Database as a separate component or
as part of the Available Spectrum Query (Section 4.4) component. as part of the Available Spectrum Query (Section 4.4) component.
o Available Spectrum Query (Section 4.4) MUST be supported by Master o Available Spectrum Query (Section 4.4) MUST be supported by Master
Device and the Database. Device and the Database.
o Spectrum Use Notify (Section 4.4.5) MAY be used by the Master o Spectrum Use Notify (Section 4.4.5) MAY be used by the Master
Device and the Database. If the regulatory domain requires Device and the Database. Some regulatory domains mandate
notification, it MUST be used by the Master Device and MUST be notifications, which would mandate their use by the Master Device
implemented by the Database. and mandate their implementation by the Database.
o Device Validation (Section 4.5) MAY be used by the Master Device. o Device Validation (Section 4.5) MAY be used by the Master Device.
If the regulatory domain requires device validation, it MUST be Some regulatory domains mandate device validation, which would
implemented by the Database and MUST be used by the Master Device. mandate its use by the Master Device and mandate its
implementation by the Database.
This section describes the protocol components and their messages. This section describes the protocol components and their messages.
Protocol Parameters (Section 5) contains a more thorough discussion Protocol Parameters (Section 5) contains a more thorough discussion
of the parameters that comprise the PAWS request and response of the parameters that comprise the PAWS request and response
messages. Message Encoding (Section 6) provides details of the messages. Message Encoding (Section 6) provides details of the
message encodings. HTTPS Binding (Section 7) describes the use of message encodings. HTTPS Binding (Section 7) describes the use of
HTTPS (HTTP Over TLS [RFC2818]) for transporting PAWS messages and HTTPS (HTTP Over TLS [RFC2818]) for transporting PAWS messages and
optional device authentication. optional device authentication.
4.1. Database Discovery 4.1. Database Discovery
skipping to change at page 8, line 47 skipping to change at page 9, line 4
optional device authentication. optional device authentication.
4.1. Database Discovery 4.1. Database Discovery
Different regulators may have different requirements for the approval Different regulators may have different requirements for the approval
and operation of databases, such as: and operation of databases, such as:
o A regulator may only allow a limited number of certified databases o A regulator may only allow a limited number of certified databases
to operate. It also may require the certification of each device- to operate. It also may require the certification of each device-
to-database pairing. to-database pairing.
o A regulator may maintain a trusted website that lists all approved o A regulator may maintain a trusted website that lists all approved
databases, known as the Listing Server. It also may mandate how databases, known as the Listing Server. It also may mandate how
devices use the listing server. devices use the listing server.
o A regulator may allow each database to define its own terms of o A regulator may allow each database to define its own terms of
use, so that, for example, an approved device may not be able to use, so that, for example, an approved device may not be able to
access all approved databases. access all approved databases.
Prior to sending PAWS messages, a Device MUST determine the URI for a Prior to sending PAWS messages, a Device needs to determine the URI
Database that provides service at its current location. for a Database that provides service at its current location.
Preconfiguration Preconfiguration
The Master Device MAY be provisioned statically with the URI of one The Master Device can be provisioned statically with the URI of one
or more Databases. For operation in regulatory domains that do not or more Databases. For operation in regulatory domains that do not
have a listing server, the device SHOULD be provisioned with the URI have a listing server, the device can be provisioned with the URI of
of all the databases for which it is certified or otherwise permitted all the databases for which it is certified or otherwise permitted to
to operate. The Device also SHOULD be provisioned with the URI of operate. The Device also can be provisioned with the URI of listing
listing servers approved by regulators. servers approved by regulators.
Configuration Update Configuration Update
To adapt to changes in the list of certified or approved databases, To adapt to changes in the list of certified or approved databases,
the Device SHOULD update its preconfigured list of databases. If the the Device needs to update its preconfigured list of databases. If
Master Device retrieves its preconfigured list of databases from a the Master Device retrieves its preconfigured list of databases from
listing server, the device SHOULD check the listing server a listing server, the device SHOULD check the listing server
periodically to update its list. periodically to update its list.
A Database MAY indicate that its URI will be changing by including A Database MAY indicate that its URI will be changing by including
the URI of one or more alternate databases (See DbUpdateSpec the URI of one or more alternate databases (See DbUpdateSpec
(Section 5.7)) in its responses to a Device. Before a Database (Section 5.7)) in its responses to a Device. Before a Database
ceases operation, for example, it MUST include DbUpdateSpec in its ceases operation, for example, it MUST include DbUpdateSpec in its
responses to notify Devices. A Device MUST update its preconfigured responses to notify Devices. A Device will update its preconfigured
list of databases to replace (only) its entry for the responding list of databases to replace (only) its entry for the responding
Database with the URIs of the alternate databases; the list of Database with the URIs of the alternate databases; the list of
alternate databases MUST NOT affect any other entries. alternate databases does not affect any other entries.
Error Handling Error Handling
The Device SHOULD select another database from its list of The Device SHOULD select another database from its list of
preconfigured databases if: preconfigured databases if:
o The selected database is unreachable or does not respond. o The selected database is unreachable or does not respond.
o The selected database returns an UNSUPPORTED error (see Error o The selected database returns an UNSUPPORTED error (see Error
Codes (Section 5.17)), which may indicate that the database does Codes (Section 5.17)), which may indicate that the database does
not support the regulatory domain where the device is located. not support the regulatory domain where the device is located.
If a suitable database cannot be contacted, the Device MUST NOT If a suitable database cannot be contacted, the Device MUST treat
operate under rules for database-managed spectrum. If the Device is this as equivalent to a response indicating no available spectrum.
already operating when it fails to contact a suitable database, and
if the applicable regulatory domain provides a grace period, the If the Device is already operating when it fails to contact a
Device may continue to operate during such period, but MUST cease use suitable database, the spectrum the Device is currently using can be
of the spectrum under rules for database-managed spectrum at or used for as long as the spectrum data is valid, but after that period
before the expiration of the grace period. If a grace period is not of time, the Device will no longer have valid spectrum to use. Some
provided by the applicable regulatory domain, an operating Device regulators will have specific rules regarding how long the spectrum
that fails to contact a suitable database MUST immediately cease use data remains valid in these cases.
of the spectrum under rules for database-managed spectrum.
4.1.1. Listing Server 4.1.1. Listing Server
Within a regulatory domain that has a Database Listing Server, a Within a regulatory domain that has a Database Listing Server, the
Device MUST use it to determine the URIs of databases for the domain. regulator can mandate its use by a Device to determine the URIs of
The URI of the Listing Server for a regulatory domain MAY be databases for the domain. The URI of the Listing Server for a
preconfigured in the device. Where allowed by the regulator, the regulatory domain can be preconfigured in the device. Where allowed
Device MAY save the database list and SHOULD contact the Database by the regulator, the Device can save the database list and SHOULD
Listing Server periodically to update its list. The time between contact the Database Listing Server periodically to update its list.
such updates MUST be no longer than one week, or any update interval The time between such updates MUST be no longer than one week, or any
required by the applicable regulatory domain, whichever is shorter. update interval required by the applicable regulatory domain,
whichever is shorter.
If the Device is unable to contact the Database Listing Server to If the Device is unable to contact the Database Listing Server to
obtain the list of databases for the domain, the Device MUST NOT obtain the list of databases for the domain, the Device MUST treat
operate under rules for database-managed spectrum. If an operating this as equivalent to not having available spectrum. Some regulatory
Device attempting to update the available spectrum from a Database domains may have additional rules regarding device behavior in such
fails to contact the Database Listing Server to validate the Database cases.
that provides the available spectrum, the operating Device MUST
immediately cease use of the spectrum under rules for database-
managed spectrum.
The Database Listing request procedure is depicted in Figure 1. The Database Listing request procedure is depicted in Figure 1.
o LISTING_REQ is the database-listing request message o LISTING_REQ is the database-listing request message
o LISTING_RESP is the database-listing response message o LISTING_RESP is the database-listing response message
+---------------+ +-------------------+ +---------------+ +-------------------+
| Master Device | | Listing Server | | Master Device | | Listing Server |
+---------------+ +-------------------+ +---------------+ +-------------------+
| | | |
skipping to change at page 11, line 13 skipping to change at page 11, line 13
Specific message formats are defined by the regulators. Specific message formats are defined by the regulators.
4.2. Initialization 4.2. Initialization
A Master Device SHOULD use the initialization procedure to exchange A Master Device SHOULD use the initialization procedure to exchange
capability information with the Database whenever the Master Device capability information with the Database whenever the Master Device
powers up or initiates communication with the Database. The powers up or initiates communication with the Database. The
initialization response informs the Master Device of specific initialization response informs the Master Device of specific
regulatory-dependent parameterized-rule values, such as threshold regulatory-dependent parameterized-rule values, such as threshold
distances and time periods beyond which the Device must update its distances and time periods beyond which the Device must update its
available-spectrum data (see RuleSetInfo (Section 5.6)). The Master available-spectrum data (see RuleSetInfo (Section 5.6)). When a
Device MAY manually configure these parameterized-rule values. The Master Device is configured manually with these parameterized-rule
values, it does not need to use the initialization procedure. The
initialization message also represents extension points for database initialization message also represents extension points for database
implementations or regulatory domains that require the extra implementations or regulatory domains that require the extra
handshake. handshake.
The Initialization request procedure is depicted in Figure 2. The Initialization request procedure is depicted in Figure 2.
o INIT_REQ (Section 4.2.1) is the initialization request message o INIT_REQ (Section 4.2.1) is the initialization request message
o INIT_RESP (Section 4.2.2) is the initialization response message o INIT_RESP (Section 4.2.2) is the initialization response message
+---------------+ +-------------------+ +---------------+ +-------------------+
| Master Device | | Spectrum Database | | Master Device | | Spectrum Database |
skipping to change at page 12, line 14 skipping to change at page 12, line 14
deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is
REQUIRED. If the Database does not support the device or any of REQUIRED. If the Database does not support the device or any of
the rulesets specified in the device descriptor, it MUST return an the rulesets specified in the device descriptor, it MUST return an
error with the UNSUPPORTED (Table 1) code in the error response. error with the UNSUPPORTED (Table 1) code in the error response.
If the device descriptor does not contain any ruleset IDs, the If the device descriptor does not contain any ruleset IDs, the
Database SHOULD return a list of RulesetInfo (Section 5.6) Database SHOULD return a list of RulesetInfo (Section 5.6)
parameters for each regulatory domain it supports at the specified parameters for each regulatory domain it supports at the specified
location. location.
location: The GeoLocation (Section 5.1) for the Device is REQUIRED. location: The GeoLocation (Section 5.1) for the Device is REQUIRED.
other: Depending on the regulatory domain or database other: The Master Device MAY specify additional handshake parameters
implementation, the Master Device MAY specify additional handshake in the INIT_REQ message. The Database MUST ignore all parameters
parameters in the INIT_REQ message. The Database MUST ignore all it does not understand. To simplify its initialization logic, a
parameters it does not understand. Master Device that supports multiple Databases and regulatory
domains can include the union of all required parameters for all
its supported regulatory domains. Consult the PAWS Parameters
Registry (Section 9.1) for possible additional parameters.
4.2.2. INIT_RESP 4.2.2. INIT_RESP
The initialization response message communicates database parameters The initialization response message communicates database parameters
to the requesting device. to the requesting device.
+---------------------------------------+ +---------------------------------------+
|INIT_RESP | |INIT_RESP |
+----------------------------+----------+ 1..* +-------------+ +----------------------------+----------+ 1..* +-------------+
|rulesetInfos:list | required |------->| RulesetInfo | |rulesetInfos:list | required |------->| RulesetInfo |
skipping to change at page 12, line 44 skipping to change at page 12, line 47
rulesetInfos: A list of RulesetInfo (Section 5.6) parameters MUST be rulesetInfos: A list of RulesetInfo (Section 5.6) parameters MUST be
included in the response. Each RulesetInfo parameter corresponds included in the response. Each RulesetInfo parameter corresponds
to a regulatory domain supported by the Database and is applicable to a regulatory domain supported by the Database and is applicable
to the location specified in the INIT_REQ (Section 4.2.1) message. to the location specified in the INIT_REQ (Section 4.2.1) message.
If the Device included a list of ruleset IDs in the If the Device included a list of ruleset IDs in the
DeviceDescriptor parameter of its INIT_REQ message, each DeviceDescriptor parameter of its INIT_REQ message, each
RulesetInfo parameter in the response MUST match one of the RulesetInfo parameter in the response MUST match one of the
specified ruleset IDs. specified ruleset IDs.
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) parameter to notify the Device of a change to the (Section 5.7) parameter to notify the Master Device of a change to
Database URI, providing one or more alternate database URIs. The the Database URI, providing one or more alternate database URIs.
Device SHOULD use the information to update its list of The Device needs to use the information to update its list of
preconfigured databases to replace (only) its entry for the preconfigured databases to replace (only) its entry for the
responding database with the list of alternate URIs. responding database with the list of alternate URIs.
other: Depending on the regulatory domain or database other: The Database MAY include additional handshake parameters in
implementation, the Database MAY include additional handshake the INIT_RESP (Section 4.2.2) message. The Master Device MUST
parameters in the INIT_RESP (Section 4.2.2) message. The Master ignore all parameters it does not understand. Consult the PAWS
Device MUST ignore all parameters it does not understand. Parameters Registry (Section 9.1) for possible additional
parameters.
4.3. Device Registration 4.3. Device Registration
When a regulatory domain requires registration of a Master Device, Some regulatory domains require a Master Device to send its
the Device MUST send its registration information to the Database to registration information to the Database in order to establish
establish certain operational parameters. FCC rules, for example, certain operational parameters. FCC rules, for example, require that
require that a 'Fixed Device' MUST register its owner and operator a 'Fixed Device' register its owner and operator contact information,
contact information, its device identifier, its location, and its 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 3. 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
skipping to change at page 14, line 18 skipping to change at page 14, line 18
|deviceDesc:DeviceDescriptor | required | |deviceDesc:DeviceDescriptor | required |
|location:GeoLocation | required | |location:GeoLocation | required |
|deviceOwner:DeviceOwner | required | |deviceOwner:DeviceOwner | required |
|antenna:AntennaCharacteristics | depends on regulatory domain | |antenna:AntennaCharacteristics | depends on regulatory domain |
|..............................................................| |..............................................................|
|*other:any | | |*other:any | |
+-------------------------------+------------------------------+ +-------------------------------+------------------------------+
Parameters: Parameters:
deviceDesc: The DeviceDescriptor (Section 5.2) for the Device is deviceDesc: The DeviceDescriptor (Section 5.2) for the Master Device
REQUIRED. The ruleset IDs included in the this parameter indicate is REQUIRED. The ruleset IDs included in the this parameter
the regulatory domains for which the Device wishes to register. indicate the regulatory domains for which the Device wishes to
If the registration information is unacceptable for all of the register. If the registration information is unacceptable for all
regulatory domains supported by the Database, the Database MUST of the regulatory domains supported by the Database, the Database
return an error message with an appropriate error code. MUST return an error message with an appropriate error code.
Otherwise, the Database MUST return, in its response, a list of Otherwise, the Database MUST return, in its response, a list of
RulesetInfo (Section 5.6) parameters for all regulatory domains RulesetInfo (Section 5.6) parameters for all regulatory domains
for which device registration was accepted. for which device registration was accepted.
location: The GeoLocation (Section 5.1) for the Device is REQUIRED. location: The GeoLocation (Section 5.1) for the Device is REQUIRED.
deviceOwner: The DeviceOwner (Section 5.5) information is REQUIRED. deviceOwner: The DeviceOwner (Section 5.5) information is REQUIRED.
antenna: Depending on the regulatory domain, the antenna: The AntennaCharacteristics (Section 5.3) is OPTIONAL. Some
AntennaCharacteristics (Section 5.3) MAY be required. regulatory domains may mandate its use.
other: Regulatory domains and database implementations MAY require other: Regulatory domains and database implementations may require
additional registration parameters. To simplify its registration additional registration parameters. To simplify its registration
logic, the Device MAY send a union of the registration information logic, the Master Device MAY send a union of the registration
required by all supported regulatory domains. The Database MUST information required by all supported regulatory domains. The
ignore all parameters it does not understand. Consult the PAWS Database MUST ignore all parameters it does not understand.
Parameters Registry (Section 9.1) for possible additional Consult the PAWS Parameters Registry (Section 9.1) for possible
parameters. additional parameters.
4.3.2. REGISTRATION_RESP 4.3.2. REGISTRATION_RESP
The registration response message acknowledges successful The registration response message acknowledges successful
registration by including a RulesetInfo message for each regulatory registration by including a RulesetInfo message for each regulatory
domain in which the registration is accepted. If the Database domain in which the registration is accepted. If the Database
accepts the registration for none of the regulatory domains it accepts the registration for none of the regulatory domains it
supports, the Database MUST return an error. supports, the Database MUST return the NOT_REGISTERED error (See
Error Codes (Section 5.17)).
+---------------------------------------+ +---------------------------------------+
|REGISTRATION_RESP | |REGISTRATION_RESP |
+----------------------------+----------+ 1..* +-------------+ +----------------------------+----------+ 1..* +-------------+
|rulesetInfos:list | required |------->| RulesetInfo | |rulesetInfos:list | required |------->| RulesetInfo |
|databaseChange:DbUpdateSpec | optional | +-------------+ |databaseChange:DbUpdateSpec | optional | +-------------+
|............................|..........| |............................|..........|
|*other:any | | |*other:any | |
+----------------------------+----------+ +----------------------------+----------+
Parameters: Parameters:
rulesetInfos: A list of RulesetInfo (Section 5.6) parameters MUST be rulesetInfos: A list of RulesetInfo (Section 5.6) parameters MUST be
included in the response, each of which corresponds to a included in the response. Each entry corresponds to a regulatory
regulatory domain for which the registration was accepted. The domain for which the registration was accepted. The list MUST
list MUST contain at least one entry. contain at least one entry.
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) parameter to notify the Device of a change to the (Section 5.7) parameter to notify the Master Device of a change to
Database URI, providing one or more alternate database URIs. The the Database URI, providing one or more alternate database URIs.
Device SHOULD use the information to update its list of The Device needs to use the information to update its list of
preconfigured databases to replace (only) its entry for the preconfigured databases to replace (only) its entry for the
responding database with the list of alternate URIs. responding database with the list of alternate URIs.
other: Database implementations MAY return additional parameters in other: Database implementations MAY return additional parameters in
the registration response. Consult the PAWS Parameters Registry the registration response. The Master Device MUST ignore any
(Section 9.1) for possible additional parameters and requirements parameters it does not understand. Consult the PAWS Parameters
they place on the Device. Registry (Section 9.1) for possible additional parameters.
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 which frequencies are available, at what permissible that describes which frequencies are available, at what permissible
operating power levels, and a schedule of when they are available. operating power levels, and a schedule of when they are available.
The Available Spectrum Query procedure is depicted in Figure 4. The Available Spectrum Query procedure is depicted in Figure 4.
o AVAIL_SPECTRUM_REQ (Section 4.4.1) is the available-spectrum o AVAIL_SPECTRUM_REQ (Section 4.4.1) is the available-spectrum
request message request message.
o AVAIL_SPECTRUM_RESP (Section 4.4.2) is the available-spectrum o AVAIL_SPECTRUM_RESP (Section 4.4.2) is the available-spectrum
response message response message.
o AVAIL_SPECTRUM_BATCH_REQ (Section 4.4.3) is an OPTIONAL batch o AVAIL_SPECTRUM_BATCH_REQ (Section 4.4.3) is an OPTIONAL batch
version of the available-spectrum request message that allows version of the available-spectrum request message that allows
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
contains available spectrum for each location contains available spectrum for each location in the request.
o SPECTRUM_USE_NOTIFY (Section 4.4.5) is the spectrum-usage o SPECTRUM_USE_NOTIFY (Section 4.4.5) is the spectrum-usage
notification message notification message.
o SPECTRUM_USE_RESP (Section 4.4.6) is the spectrum-usage o SPECTRUM_USE_RESP (Section 4.4.6) is the spectrum-usage
acknowledgment message acknowledgment message.
+---------------+ +-------------------+ +---------------+ +-------------------+
| Master Device | | Spectrum Database | | Master Device | | Spectrum Database |
+---------------+ +-------------------+ +---------------+ +-------------------+
| | | |
| AVAIL_SPECTRUM_REQ | | AVAIL_SPECTRUM_REQ |
| (AVAIL_SPECTRUM_BATCH_REQ) | | (AVAIL_SPECTRUM_BATCH_REQ) |
|--------------------------->| |--------------------------->|
| | | |
| AVAIL_SPECTRUM_RESP | | AVAIL_SPECTRUM_RESP |
skipping to change at page 17, line 22 skipping to change at page 17, line 22
7. If the Database receives a spectrum-usage notification message, 7. If the Database receives a spectrum-usage notification message,
it MUST send a spectrum-usage acknowledgment message to the it MUST send a spectrum-usage acknowledgment message to the
Master Device. Master Device.
The procedure for asking for available spectrum on behalf of a Slave The procedure for asking for available spectrum on behalf of a Slave
Device is similar, except that the process is initiated by the Slave Device is similar, except that the process is initiated by the Slave
Device. The device identifier, capabilities, and characteristics Device. The device identifier, capabilities, and characteristics
communicated in the AVAIL_SPECTRUM_REQ message MUST be those of the communicated in the AVAIL_SPECTRUM_REQ message MUST be those of the
Slave Device, but the location MUST be that of the Master Device. Slave Device, but the location MUST be that of the Master Device.
Although the communication and protocol between the Slave Device and Although the communication and protocol between the Slave Device and
Master Device is outside the scope of this document, the expected Master Device is outside the scope of this document (represented as
message sequence is shown in Figure 5. dotted lines), the expected 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 18, line 8 skipping to change at page 18, line 8
| | | | | |
| | (SPECTRUM_USE_RESP) | | | (SPECTRUM_USE_RESP) |
| |<--------------------------| | |<--------------------------|
| | | | | |
Figure 5 Figure 5
4.4.1. AVAIL_SPECTRUM_REQ 4.4.1. AVAIL_SPECTRUM_REQ
The request message for the Available Spectrum Query protocol MUST The request message for the Available Spectrum Query protocol MUST
include the Device's geo-location. If allowed by the regulatory include a geo-location. Regulatory domains may mandate that it be
domain, the location MAY be an anticipated location. the Device's current location or allow it to be an anticipated
location.
+-----------------------------------------------------------------+ +-----------------------------------------------------------------+
|AVAIL_SPECTRUM_REQ | |AVAIL_SPECTRUM_REQ |
+----------------------------------+------------------------------+ +----------------------------------+------------------------------+
|deviceDesc:DeviceDescriptor | optional | |deviceDesc:DeviceDescriptor | optional |
|location:GeoLocation | optional | |location:GeoLocation | optional |
|owner:DeviceOwner | depends on regulatory domain | |owner:DeviceOwner | depends on regulatory domain |
|antenna:AntennaCharacteristics | depends on regulatory domain | |antenna:AntennaCharacteristics | depends on regulatory domain |
|capabilities:DeviceCapabilities | optional | |capabilities:DeviceCapabilities | optional |
|masterDeviceDesc:DeviceDescriptor | optional | |masterDeviceDesc:DeviceDescriptor | optional |
skipping to change at page 18, line 44 skipping to change at page 18, line 45
specified. The deviceDesc parameter may be OPTIONAL for some specified. The deviceDesc parameter may be OPTIONAL for some
values of requestType. values of requestType.
location: The GeoLocation (Section 5.1) for the Device requesting location: The GeoLocation (Section 5.1) for the Device requesting
available spectrum. The location SHOULD be the current location available spectrum. The location SHOULD be the current location
of the Device, but more precisely, the location of the radiation of the Device, but more precisely, the location of the radiation
center of the Device's antenna. When the request is made by the center of the Device's antenna. When the request is made by the
Master Device on its own behalf, the location is that of the Master Device on its own behalf, the location is that of the
Master Device and it is REQUIRED. When the request is made by the Master Device and it is REQUIRED. When the request is made by the
Master Device on behalf of a Slave Device, the location is that of Master Device on behalf of a Slave Device, the location is that of
the Slave Device and it is OPTIONAL (see also the the Slave Device and it is OPTIONAL (see also the
masterDeviceLocation parameter). Depending on the regulatory masterDeviceLocation parameter). The location may be an
domain, the location MAY be an anticipated position of the Device anticipated position of the Device to support mobile devices, but
to support mobile devices. If the location specifies a region, its use depends on regulatory rules. If the location specifies a
rather than a point, the Database MAY return an error with the region, rather than a point, the Database MAY return an error with
UNIMPLEMENTED (Table 1) code, if it does not support query by the UNIMPLEMENTED (Table 1) code, if it does not support query by
region. region.
owner: Depending on the device type and regulatory domain, the owner: The DeviceOwner (Section 5.5) information MAY be included to
DeviceOwner (Section 5.5) information MAY be included to register register the Device with the Database. This enables the Device to
the Device with the Database. This enables the Device to register register and get spectrum-availability information in a single
and get spectrum-availability information in a single request. request. Some regulatory domains mandate registration for
antenna: Depending on the device type and regulatory domain, the specific device types.
AntennaCharacteristics (Section 5.3) MAY be required. antenna: The AntennaCharacteristics (Section 5.3) is OPTIONAL. Some
regulatory domains may require this parameter.
capabilities: The Master Device MAY include its DeviceCapabilities capabilities: The Master Device MAY include its DeviceCapabilities
(Section 5.4) to limit the available-spectrum response to the (Section 5.4) to limit the available-spectrum response to the
spectrum that is compatible with its capabilities. The Database spectrum that is compatible with its capabilities. The Database
SHOULD NOT return spectrum that is not compatible with the SHOULD NOT return spectrum that is not compatible with the
specified capabilities. specified capabilities.
masterDeviceDesc: Depending on regulatory rules and Database masterDeviceDesc: When the request is made by the Master Device on
implementations, when the request is made by the Master Device on behalf of a Slave Device, the Master Device MAY provide its own
behalf of a Slave Device, the Master Device MAY be required to descriptor. Some regulatory domains may require it.
provide its own descriptor. masterDeviceLocation: When the request is made by the Master Device
masterDeviceLocation: Depending on regulatory rules, when the on behalf of a Slave Device, the Master Device MAY provide its own
request is made by the Master Device on behalf of a Slave Device, GeoLocation (Section 5.1). Some regulatory domains may require
the GeoLocation (Section 5.1) of the Master Device MAY be it.
required.
requestType: The request type is an OPTIONAL parameter that may be requestType: The request type is an OPTIONAL parameter that may be
used to modify the request, but its use depends on applicable used to modify the request, but its use depends on applicable
regulatory rules. The request type may be used, for example, to regulatory rules. The request type may be used, for example, to
request generic Slave Device parameters without having to specify indicate a the response should include generic Slave Device
the device descriptor for a specific device. When the requestType parameters without having to specify the device descriptor for a
parameter is missing, the request is for a specific device (Master specific device. When the requestType parameter is missing, the
or Slave), so the deviceDesc parameter is REQUIRED. See IANA request is for a specific device (Master or Slave), so the
Ruleset Registry, Initial Registry Contents (Section 9.2.2) for deviceDesc parameter is REQUIRED. See IANA Ruleset Registry,
regulatory specifics. Initial Registry Contents (Section 9.2.2) for regulatory
other: Regulatory domains and database implementations MAY require specifics.
other: Regulatory domains and database implementations may require
additional request parameters. The Database MUST ignore all additional request parameters. The Database MUST ignore all
parameters it does not understand. Consult the PAWS Parameters parameters it does not understand. Consult the PAWS Parameters
Registry (Section 9.1) for possible additional parameters. Registry (Section 9.1) for possible additional parameters.
4.4.2. AVAIL_SPECTRUM_RESP 4.4.2. AVAIL_SPECTRUM_RESP
The response message for the Available Spectrum Query contains one or The response message for the Available Spectrum Query contains one or
more SpectrumSpec (Section 5.9) elements, one for each regulatory more SpectrumSpec (Section 5.9) elements, one for each regulatory
domain supported at the location specified in the corresponding domain supported at the location specified in the corresponding
AVAIL_SPECTRUM_REQ (Section 4.4.1) request. Each SpectrumSpec AVAIL_SPECTRUM_REQ (Section 4.4.1) request. Each SpectrumSpec
element contains a list of one or more spectrum schedules, element contains a list of one or more spectrum schedules,
representing permissible power levels over time: representing permissible power levels over time:
o Within each list of schedules, event-time intervals MUST be o Within each list of schedules, event-time intervals MUST be
disjoint and SHOULD be sorted in increasing time disjoint and SHOULD be sorted in increasing time.
o A gap in the time schedule means no spectrum is available for that o A gap in the time schedule means no spectrum is available for that
time interval time interval.
+---------------------------------------+ +---------------------------------------+
|AVAIL_SPECTRUM_RESP | |AVAIL_SPECTRUM_RESP |
+----------------------------+----------+ +----------------------------+----------+
|timestamp:string | required | |timestamp:string | required |
|deviceDesc:DeviceDescriptor | required | |deviceDesc:DeviceDescriptor | required |
|spectrumSpecs:list | required |-------+ |spectrumSpecs:list | required |-------+
|............................|..........| | |............................|..........| |
|databaseChange:DbUpdateSpec | optional | | |databaseChange:DbUpdateSpec | optional | |
|*other:any | | | |*other:any | | |
skipping to change at page 21, line 8 skipping to change at page 21, line 8
spectrumSpecs: The SpectrumSpec (Section 5.9) list is REQUIRED and spectrumSpecs: The SpectrumSpec (Section 5.9) list is REQUIRED and
MUST include at least one entry. Each entry contains the MUST include at least one entry. Each entry contains the
schedules of available spectrum for a regulatory domain. The schedules of available spectrum for a regulatory domain. The
Database MAY return more than one SpectrumSpec to represent Database MAY return more than one SpectrumSpec to represent
available spectrum for multiple regulatory domains at the available spectrum for multiple regulatory domains at the
specified location. specified location.
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) parameter to notify the Device of a change to the (Section 5.7) parameter to notify the Device of a change to the
Database URI, providing one or more alternate database URIs. The Database URI, providing one or more alternate database URIs. The
Device SHOULD use the information to update its list of Device needs to use the information to update its list of
preconfigured databases to replace (only) its entry for the preconfigured databases to replace (only) its entry for the
responding database with the list of alternate URIs. responding database with the list of alternate URIs.
other: Database implementations MAY return additional parameters in other: Database implementations MAY return additional parameters in
the response. Consult the PAWS Parameters Registry (Section 9.1) the response. The Device MUST ignore any parameters that it does
for possible additional parameters and requirements they place on not understand. Consult the PAWS Parameters Registry
the Device. (Section 9.1) for possible additional parameters and requirements
they place on the Device.
4.4.2.1. Update Requirements 4.4.2.1. Update Requirements
When the stop time specified in the schedule has been reached, the When the stop time specified in the schedule has been reached, the
Device: Device:
o MUST obtain a new spectrum-availability schedule, either by using o MUST obtain a new spectrum-availability schedule, either by using
the next one in the list (if provided) or making another Available the next one in the list (if provided) or making another Available
Spectrum Query (Section 4.4) Spectrum Query (Section 4.4).
o If the new schedule indicates the in-use spectrum is no longer
available, the Device MUST immediately cease use of that spectrum
under rules for database-managed spectrum.
o If the Device is unable to contact the Database to obtain a new o If the Device is unable to contact the Database to obtain a new
schedule, the Device MUST immediately cease use of that spectrum schedule, it MUST treat this as equivalent to a response with no
under rules for database-managed spectrum. available spectrum.
When the Device moves beyond a threshold distance (established by Some regulatory domains also mandate that a Device must obtain a new
regulatory rules) away from the actual location and all anticipated specturm-availability schedule if the Device moves beyond a threshold
location(s) it reported in previous AVAIL_SPECTRUM_REQ or distance (established by regulatory rules) away from the actual
AVAIL_SPECTRUM_BATCH_REQ requests (see "maxLocationChange" in location and all anticipated location(s) it reported in previous
RulesetInfo (Section 5.6)), it: AVAIL_SPECTRUM_REQ or AVAIL_SPECTRUM_BATCH_REQ requests (see
o MUST obtain a new spectrum-availability schedule by making another "maxLocationChange" in RulesetInfo (Section 5.6)). If the Device is
Available Spectrum Query (Section 4.4). unable to contact the Database to obtain a new schedule, it MUST
o If the new response indicates the in-use spectrum is no longer treat this as equivalent to a response with no available spectrum.
available, the Device MUST stop operation immediately.
o If the Device is unable to contact the Database to obtain a new
schedule, depending on the regulatory domain, the Device MUST
immediately cease use of the spectrum under rules of database-
managed spectrum.
NOTE: Regulatory rules govern whether a device may request and use NOTE: Regulatory rules determine required device behavior when
spectrum at anticipated locations beyond the threshold distance from spectrum is no longer available. Regulatory rules also govern
its current location. whether a device may request and use spectrum at anticipated
locations beyond the threshold distance from its current location.
4.4.3. AVAIL_SPECTRUM_BATCH_REQ 4.4.3. AVAIL_SPECTRUM_BATCH_REQ
The Database MAY support the batch request that allows multiple The Database MAY support the batch request that allows multiple
locations to be specified. This allows a portable Master Device to locations to be specified. This enables a portable Master Device,
get available spectrum for a sequence of anticipated locations using for example, to get available spectrum for a sequence of anticipated
a single request. The Database MUST interpret each location in the locations using a single request. The Database MUST interpret each
batch request as if it were an independent request and MUST return location in the batch request as if it were an independent request
results consistent with multiple individual AVAIL_SPECTRUM_REQ and MUST return results consistent with multiple individual
(Section 4.4.1) requests. The request message for the batch AVAIL_SPECTRUM_REQ (Section 4.4.1) requests. The request message for
Available Spectrum Query protocol MUST include at least one the batch Available Spectrum Query protocol MUST include at least one
GeoLocation (Section 5.1). If the Database does not support batch GeoLocation (Section 5.1). If the Database does not support batch
requests, it MUST return a UNIMPLEMENTED (Table 1) error. requests, it MUST return an UNIMPLEMENTED (Table 1) error.
NOTE: Whether anticipated locations are allowed depends on specified
regulatory rules.
+----------------------------------------------------------------+ +----------------------------------------------------------------+
|AVAIL_SPECTRUM_BATCH_REQ | |AVAIL_SPECTRUM_BATCH_REQ |
+---------------------------------+------------------------------+ +---------------------------------+------------------------------+
|deviceDesc:DeviceDescriptor | optional | |deviceDesc:DeviceDescriptor | optional |
|locations:list | required |--+ |locations:list | required |--+
|owner:DeviceOwner | depends on regulatory domain | | |owner:DeviceOwner | depends on regulatory domain | |
|antenna:AntennaCharacteristics | depends on regulatory domain | | |antenna:AntennaCharacteristics | depends on regulatory domain | |
|capabilities:DeviceCapabilities | optional | | |capabilities:DeviceCapabilities | optional | |
|masterDeviceDesc:DeviceDescriptor| optional | | |masterDeviceDesc:DeviceDescriptor| optional | |
skipping to change at page 22, line 44 skipping to change at page 22, line 41
deviceDesc: The DeviceDescriptor (Section 5.2) for the Device deviceDesc: The DeviceDescriptor (Section 5.2) for the Device
requesting available spectrum. When the request is made by a requesting available spectrum. When the request is made by a
Master Device on its own behalf, the descriptor is that of the Master Device on its own behalf, the descriptor is that of the
Master Device and it is REQUIRED. When the request is made on Master Device and it is REQUIRED. When the request is made on
behalf of a Slave Device, the descriptor is that of the Slave behalf of a Slave Device, the descriptor is that of the Slave
Device, and it is REQUIRED if the "requestType" parameter is not Device, and it is REQUIRED if the "requestType" parameter is not
specified. The deviceDesc parameter may be OPTIONAL for some specified. The deviceDesc parameter may be OPTIONAL for some
values of requestType. values of requestType.
locations: The GeoLocation (Section 5.1) list for the Device is locations: The GeoLocation (Section 5.1) list for the Device is
REQUIRED. This allows the Device to specify its actual location REQUIRED. This allows the Device to specify its actual location
plus additional anticipated locations, when allowed by the plus additional anticipated locations. At least one location MUST
regulatory domain. At least one location MUST be included. This be included. This specification places no upper limit on the
specification places no upper limit on the number of locations, number of locations, but the Database MAY restrict the number of
but the Database MAY restrict the number of locations it supports locations it supports by returning a response with fewer locations
by returning a response with fewer locations than specified in the than specified in the request. If the locations specify regions,
request. If the locations specify regions, rather than points, rather than points, the Database MAY return an error with the
the Database MAY return an error with the UNIMPLEMENTED (Table 1) UNIMPLEMENTED (Table 1) code, if it does not support query by
code, if it does not support query by region. When the request is region. When the request is made by a Master Device on its own
made by a Master Device on its own behalf, the locations are those behalf, the locations are those of the Master Device. When the
of the Master Device. When the request is made by the Master request is made by the Master Device on behalf of a Slave Device,
Device on behalf of a Slave Device, the locations are those of the the locations are those of the Slave Device (see also the
Slave Device (see also the masterDeviceLocation parameter). masterDeviceLocation parameter).
owner: Depending on the device type and regulatory domain, the owner: The DeviceOwner (Section 5.5) information MAY be included to
DeviceOwner (Section 5.5) information MAY be included to register register the Device with the Database. This enables the Device to
the Device with the Database. This enables the Device to register register and get spectrum-availability information in a single
and get spectrum-availability information in a single request. request. Some regulatory domains mandate registration for
antenna: Depending on the device type and regulatory domain, the specific device types.
AntennaCharacteristics (Section 5.3) MAY be required. antenna: The AntennaCharacteristics (Section 5.3) is OPTIONAL. Some
regulatory domains may require this parameter.
capabilities: The Master Device MAY include its DeviceCapabilities capabilities: The Master Device MAY include its DeviceCapabilities
(Section 5.4) to limit the available-spectrum response to the (Section 5.4) to limit the available-spectrum response to the
spectrum that is compatible with its capabilities. The Database spectrum that is compatible with its capabilities. The Database
SHOULD NOT return spectrum that is not compatible with the SHOULD NOT return spectrum that is not compatible with the
specified capabilities. specified capabilities.
masterDeviceDesc: Depending on regulatory rules, when the request is masterDeviceDesc: When the request is made by the Master Device on
made by the Master Device on behalf of a Slave Device, the Master behalf of a Slave Device, the Master Device MAY provide its own
Device MAY BE REQUIRED to provide its own descriptor. descriptor. Some regulatory domains may require it.
masterDeviceLocation: Depending on regulatory rules and Database masterDeviceLocation: When the request is made by the Master Device
implementations, when the request is made by the Master Device on on behalf of a Slave Device, the Master Device MAY provide its own
behalf of a Slave Device, the GeoLocation (Section 5.1) for the GeoLocation (Section 5.1). Some regulatory domains may require
Master Device MAY be required. it.
requestType: The request type is an OPTIONAL parameter that may be requestType: The request type is an OPTIONAL parameter that may be
used to modify the request, but its use depends on applicable used to modify the request, but its use depends on applicable
regulatory rules. The request type may be used, for example, to regulatory rules. The request type may be used, for example, to
request generic Slave Device parameters without having to specify request generic Slave Device parameters without having to specify
the device descriptor for a specific device. When the requestType the device descriptor for a specific device. When the requestType
parameter is missing, the request is for a specific device (Master parameter is missing, the request is for a specific device (Master
or Slave), so the deviceDesc parameter is REQUIRED. See IANA or Slave), so the deviceDesc parameter is REQUIRED. See IANA
Ruleset Registry, Initial Registry Contents (Section 9.2.2) for Ruleset Registry, Initial Registry Contents (Section 9.2.2) for
regulatory specifics. regulatory specifics.
other: Regulatory domains and database implementations MAY require other: Regulatory domains and database implementations may require
additional request parameters. The Database MUST ignore all additional request parameters. The Database MUST ignore all
parameters it does not understand. Consult the PAWS Parameters parameters it does not understand. Consult the PAWS Parameters
Registry (Section 9.1) for possible additional parameters. Registry (Section 9.1) for possible additional parameters.
4.4.4. AVAIL_SPECTRUM_BATCH_RESP 4.4.4. AVAIL_SPECTRUM_BATCH_RESP
The response message for the batch Available Spectrum Query contains The response message for the batch Available Spectrum Query contains
a schedule of available spectrum for the Device at multiple a schedule of available spectrum for the Device at multiple
locations. locations.
skipping to change at page 24, line 32 skipping to change at page 24, line 32
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_BATCH_REQ message. (Section 5.2) specified in the AVAIL_SPECTRUM_BATCH_REQ message.
geoSpectrumSpecs: The geoSpectrumSpecs (Section 5.15) list is geoSpectrumSpecs: The geoSpectrumSpecs (Section 5.15) list is
REQUIRED (though it MAY be empty if spectrum is unavailable). For REQUIRED (although it MAY be empty if spectrum is unavailable).
each location, the Database MAY return one or more SpectrumSpec For each location, the Database MAY return one or more
(Section 5.9) parameters to represent available spectrum for one SpectrumSpec (Section 5.9) parameters to represent available
or more regulatory domains. The Database MAY return available spectrum for one or more regulatory domains. The Database MAY
spectrum for fewer locations than requested. The Device MUST NOT return available spectrum for fewer locations than requested. The
make any assumptions on the order of the entries in the list and Device MUST NOT make any assumptions on the order of the entries
MUST use the location value in each GeoSpectrumSpec entry to match in the list and MUST use the location value in each
available spectrum to a location. GeoSpectrumSpec entry to match available spectrum to a location.
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) parameter to notify the Device of a change to the (Section 5.7) parameter to notify the Device of a change to the
Database URI, providing one or more alternate database URIs. The Database URI, providing one or more alternate database URIs. The
Device SHOULD use the information to update its list of Device needs to use the information to update its list of
preconfigured databases to replace (only) its entry for the preconfigured databases to replace (only) its entry for the
responding database with the list of alternate URIs. responding database with the list of alternate URIs.
other: Database implementations MAY return additional parameters in other: Database implementations MAY return additional parameters in
the response. Consult the PAWS Parameters Registry (Section 9.1) the response. Consult the PAWS Parameters Registry (Section 9.1)
for possible additional parameters and requirements they place on for possible additional parameters and requirements they place on
the Device. the Device.
See Update Requirements (Section 4.4.2.1) for when the Device must See Update Requirements (Section 4.4.2.1) for when the Device must
update its available spectrum data. update its available spectrum data.
4.4.5. SPECTRUM_USE_NOTIFY 4.4.5. SPECTRUM_USE_NOTIFY
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. Some regulatory domains may mandate additional
parameters.
+--------------------------------------------+ +--------------------------------------------+
|SPECTRUM_USE_NOTIFY | |SPECTRUM_USE_NOTIFY |
+---------------------------------+----------+ +---------------------------------+----------+
|deviceDesc:DeviceDescriptor | required | |deviceDesc:DeviceDescriptor | required |
|location:GeoLocation | required | |location:GeoLocation | required |
|masterDeviceDesc:DeviceDescriptor| optional |
|masterDeviceLocation:GeoLocation | optional | |masterDeviceLocation:GeoLocation | optional |
|spectra:list | required |-------+ |spectra:list | required |-------+
|............................................| | |............................................| |
|*other:any | | | |*other:any | | |
+---------------------------------+----------+ | 0..* +---------------------------------+----------+ | 0..*
V V
+--------------------------------+ +--------------------------------+
|Spectrum | |Spectrum |
+---------------------+----------+ +---------------------+----------+
|resolutionBwHz:float | required | |resolutionBwHz:float | required |
skipping to change at page 25, line 36 skipping to change at page 25, line 38
+---------------------+----------+ +---------------------+----------+
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. When the location: The GeoLocation (Section 5.1) for the Device. When the
notification is made by a Master Device on its own behalf, the notification is made by a Master Device on its own behalf, the
location is that of the Master Device and is REQUIRED. When the location is that of the Master Device and is REQUIRED. When the
notification is made by a Master Device on behalf of a Slave notification is made by a Master Device on behalf of a Slave
Device, the location is that of the Slave Device and MAY be Device, the location is that of the Slave Device and is OPTIONAL,
required, depending on regulatory rules. but may be required by some regulatory domains.
spectra: The Spectrum (Section 5.11) list is REQUIRED, and specifies spectra: The Spectrum (Section 5.11) list is REQUIRED, and specifies
the spectrum anticipated to be used by the Device, which includes the spectrum anticipated to be used by the Device, which includes
profiles of frequencies and power levels. The list MAY be empty, profiles of frequencies and power levels. The list MAY be empty,
if the Device decides not to use any spectrum. For consistency, if the Device decides not to use any spectrum. For consistency,
the resolution bandwidth value, "resolutionBwHz" SHOULD match that the resolution bandwidth value, "resolutionBwHz" SHOULD match that
from one of the Spectrum (Section 5.11) elements in the from one of the Spectrum (Section 5.11) elements in the
corresponding AVAIL_SPECTRUM_RESP message, and the maximum power corresponding AVAIL_SPECTRUM_RESP message, and the maximum power
levels in the Spectrum element MUST be expressed as power over the levels in the Spectrum element MUST be expressed as power over the
specified "resolutionBwHz" value. The actual bandwidth to be used specified "resolutionBwHz" value. The actual bandwidth to be used
(as computed from the start and stop frequencies) MAY be different (as computed from the start and stop frequencies) MAY be different
from the "resolutionBwHz" value. As an example, when regulatory from the "resolutionBwHz" value. As an example, when regulatory
rules express maximum power spectral density in terms of maximum rules express maximum power spectral density in terms of maximum
power over any 100 kHz band, then the "resolutionBwHz" value power over any 100 kHz band, then the "resolutionBwHz" value
should be set to 100 kHz, even though the actual bandwidth used should be set to 100 kHz, even though the actual bandwidth used
can be 20 kHz. can be 20 kHz.
masterDeviceDesc: When the notification is made by the Master Device
masterDeviceLocation: Depending on regulatory rules, when the on behalf of a Slave Device, the Master Device MAY provide its own
notification is made by the Master Device on behalf of a Slave descriptor. Some regulatory domains may require it.
Device, the GeoLocation (Section 5.1) for the Master Device MAY be masterDeviceLocation: When the notification is made by the Master
required. Device on behalf of a Slave Device, the Master Device MAY include
other: Depending on the regulatory domain, other parameters MAY be its own GeoLocation (Section 5.1). Some regulatory domains may
require this parameter.
other: Depending on the regulatory domain, other parameters may be
required. To simplify its logic, the Device MAY include the union required. To simplify its logic, the Device MAY include the union
of all parameters required by all supported regulatory domains. of all parameters required by all supported regulatory domains.
The Database MUST ignore all parameters it does not understand. The Database MUST ignore all parameters it does not understand.
4.4.6. SPECTRUM_USE_RESP 4.4.6. SPECTRUM_USE_RESP
The spectrum-use response message simply acknowledges receipt of the The spectrum-use response message simply acknowledges receipt of the
notification. notification.
+---------------------------------------+ +---------------------------------------+
skipping to change at page 26, line 32 skipping to change at page 26, line 36
|databaseChange:DbUpdateSpec | optional | |databaseChange:DbUpdateSpec | optional |
|.......................................| |.......................................|
|*other:any | | |*other:any | |
+----------------------------+----------+ +----------------------------+----------+
Parameters: Parameters:
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) parameter to notify the Device of a change to the (Section 5.7) parameter to notify the Device of a change to the
Database URI, providing one or more alternate database URIs. The Database URI, providing one or more alternate database URIs. The
Device SHOULD use the information to update its list of Device needs to use the information to update its list of
preconfigured databases to replace (only) its entry for the preconfigured databases to replace (only) its entry for the
responding database with the list of alternate URIs. responding database with the list of alternate URIs.
other: Database implementations MAY return additional parameters in other: Database implementations MAY return additional parameters in
the response. Consult the PAWS Parameters Registry (Section 9.1) the response. Consult the PAWS Parameters Registry (Section 9.1)
for possible additional parameters and requirements they place on for possible additional parameters.
the Device.
4.5. Device Validation 4.5. Device Validation
Typically, a Slave Device needs a Master Device to ask the Database Typically, a Slave Device needs a Master Device to ask the Database
on its behalf for available spectrum. Depending on the regulatory on its behalf for available spectrum. Depending on the regulatory
domain, the Master Device also must validate with the Database that domain, the Master Device also must validate with the Database that
the Slave Device is permitted to operate. When regulatory rules the Slave Device is permitted to operate. When regulatory rules
allow a Master Device to "cache" the available spectrum for a period allow a Master Device to "cache" the available spectrum for a period
of time, the Master Device MAY use the simpler Device Validation of time, the Master Device may use the simpler Device Validation
component, instead of the full Available Spectrum Query component, to component, instead of the full Available Spectrum Query component, to
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 with and entry for each
each device is permitted to use the spectrum. device to indicate whether it 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 6, 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
skipping to change at page 28, line 21 skipping to change at page 28, line 21
|masterDeviceDesc:DeviceDescriptor | optional | | |masterDeviceDesc:DeviceDescriptor | optional | |
+----------------------------------+----------+ | +----------------------------------+----------+ |
V 1..* V 1..*
+----------------------+ +----------------------+
|DeviceDescriptor | |DeviceDescriptor |
+----------------------+ +----------------------+
Parameters: Parameters:
deviceDescs: A DeviceDescriptor (Section 5.2) list is REQUIRED, deviceDescs: A DeviceDescriptor (Section 5.2) list is REQUIRED,
which specifies the list of Slave Devices that to be validated. which specifies the list of Slave Devices that are to be
masterDeviceDesc: Depending on regulatory rules, when the request is validated.
made by the Master Device on behalf of a Slave Device, the Master masterDeviceDesc: The Master Device MAY provide its own descriptor.
Device MAY be required to provide its own descriptor. Some regulatory domains may require it.
4.5.2. DEV_VALID_RESP 4.5.2. DEV_VALID_RESP
+---------------------------------------+ +---------------------------------------+
|DEV_VALID_RESP | |DEV_VALID_RESP |
+----------------------------+----------+ +----------------------------+----------+
|deviceValidities:list | required |---- |deviceValidities:list | required |----
|databaseChange:DbUpdateSpec | optional | | |databaseChange:DbUpdateSpec | optional | |
+----------------------------+----------+ | +----------------------------+----------+ |
V 1..* V 1..*
skipping to change at page 29, line 8 skipping to change at page 29, line 8
deviceValidities: A DeviceValidities (Section 5.16) list is REQUIRED deviceValidities: A DeviceValidities (Section 5.16) list is REQUIRED
to report the list of Slave Devices and whether each listed Device to report the list of Slave Devices and whether each listed Device
is valid. The number of entries MUST match the number of is valid. The number of entries MUST match the number of
DeviceDescriptors (Section 5.2) listed in the DEV_VALID_REQ DeviceDescriptors (Section 5.2) listed in the DEV_VALID_REQ
message. message.
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) parameter to notify the Device of a change to the (Section 5.7) parameter to notify the Device of a change to the
Database URI, providing one or more alternate database URIs. The Database URI, providing one or more alternate database URIs. The
Device SHOULD use the information to update its list of Device needs to use the information to update its list of
preconfigured databases to replace (only) its entry for the preconfigured databases to replace (only) its entry for the
responding database with the list of alternate URIs. responding database with the list of alternate URIs.
5. Protocol Parameters 5. Protocol Parameters
This section presents more details of the parameters that make up the This section presents more details of the parameters that make up the
PAWS request and response messages. It also includes a sub-section PAWS request and response messages. It also includes a sub-section
defining response codes. defining response codes.
5.1. GeoLocation 5.1. GeoLocation
skipping to change at page 29, line 45 skipping to change at page 29, line 45
confidence level, expressed as a percentage. The data model for confidence level, expressed as a percentage. The data model for
GeoLocation is illustrated below: GeoLocation is illustrated below:
+-------------------------------------------------+ +-------------------------------------------------+
|GeoLocation | |GeoLocation |
+------------------+------------------------------+ +------------------+------------------------------+
|point:Ellipse | optional | |point:Ellipse | optional |
|region:Polygon | optional | |region:Polygon | optional |
|confidence:int | depends on regulatory domain | |confidence:int | depends on regulatory domain |
+------------------+------------------------------+ +------------------+------------------------------+
Note: point and region are mutually exclusive, but one of them must Note: point and region are mutually exclusive. Exactly one must
be present. be present.
+---------------------------------------------------+ +---------------------------------------------------+
|Ellipse | |Ellipse |
+--------------------+------------------------------+ +--------------------+------------------------------+
|center:Point | required |--+ |center:Point | required |--+
|semiMajorAxis:float | depends on regulatory domain | | |semiMajorAxis:float | depends on regulatory domain | |
|semiMinorAxis:float | depends on regulatory domain | | |semiMinorAxis:float | depends on regulatory domain | |
|orientation:float | optional | | |orientation:float | optional | |
+--------------------+------------------------------+ v +--------------------+------------------------------+ v
skipping to change at page 30, line 35 skipping to change at page 30, line 35
|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. Exactly one of "point" or "region" MUST be the regulatory domain. Exactly one of "point" or "region" MUST be
present. present.
region: If present, it indicates that the GeoLocation represents a region: If present, it indicates that the GeoLocation represents a
region. Exactly one of "point" or "region" MUST be present. region. Exactly one of "point" or "region" MUST be present.
center: The center refers to the location of a GeoLocation point and center: The center refers to the location of a GeoLocation point and
is represented as the center of an ellipse. is represented as the center of an ellipse.
latitude, longitude: Floating-point numbers that express the latitude, longitude: Floating-point numbers that express the
latitude and longitude in degrees using the WGS84 datum [WGS-84]. latitude and longitude in degrees using the WGS84 datum [WGS-84].
semiMajorAxis, semiMinorAxis: If required by the regulatory domain, semiMajorAxis, semiMinorAxis: The location uncertainty, expressed in
the location uncertainty, in meters, is parameterized using meters, is OPTIONAL. It is parameterized using distances along
distances along the major and minor axes of the ellipse. When the major and minor axes of the ellipse. The default value is 0.
uncertainty is optional, the default value of each is 0. Some regulatory domains may require that they be provided
explicitly.
orientation: This defines the orientation of the ellipse, expressed orientation: This defines the orientation of the ellipse, expressed
as the rotation, in degrees, of the semi-major axis from North as the rotation, in degrees, of the semi-major axis from North
towards the East. For example, when the uncertainty is greatest towards the East. For example, when the uncertainty is greatest
along the North-South direction, orientation is 0 degrees; along the North-South direction, orientation is 0 degrees;
conversely, if the uncertainty is greatest along the East-West conversely, if the uncertainty is greatest along the East-West
direction, orientation is 90 degrees. When orientation is not direction, orientation is 90 degrees. When orientation is not
present, the orientation MUST be interpreted as 0. present, the orientation MUST be interpreted as 0. Some
regulatory domains may require that orientation be provided
explicitly.
exterior: When GeoLocation describes a region, the "exterior" field exterior: When GeoLocation describes a region, the "exterior" field
refers to a list of latitude/longitude points that represents the refers to a list of latitude/longitude points that represents the
vertices of a polygon. The first and last points MUST be the vertices of a polygon. The first and last points MUST be the
same. Thus, a minimum of 4 points is required. The following same. Thus, a minimum of 4 points is required. The following
polygon restrictions from [RFC5491] apply: polygon restrictions from [RFC5491] apply:
* A connecting line MUST NOT cross another connecting line of the * A connecting line MUST NOT cross another connecting line of the
same polygon. same polygon.
* The vertices MUST be defined in a counter-clockwise direction. * The vertices MUST be defined in a counter-clockwise direction.
* The edges of a polygon are defined by the shortest path between * The edges of a polygon are defined by the shortest path between
two points in space (not a geodesic curve). Consequently, the two points in space (not a geodesic curve). Consequently, the
length between two adjacent vertices SHOULD be restricted to a length between two adjacent vertices SHOULD be restricted to a
maximum of 130 km. maximum of 130 km.
* All vertices are assumed to be at the same altitude. * All vertices are assumed to be at the same altitude.
* Polygon shapes SHOULD be restricted to a maximum of 15 vertices * Polygon shapes SHOULD be restricted to a maximum of 15 vertices
(16 points that includes the repeated vertex). (16 points that includes the repeated vertex).
confidence: The location confidence level, as an integer percentage, confidence: The location confidence level, as a percentage, MAY be
MAY be required, depending on the regulatory domain. When the provided. Some regulatory domains may require that it be provided
parameter is optional and not provided, its value MUST be explicitly. When the parameter is not provided, its value MUST be
interpreted as 95. Valid values range from 0 to 99, since, in interpreted as 95. Valid values range from 0 to 100, but, in
practice, 100-percent confidence is not achievable. The practice, 100-percent confidence is not achievable. The
confidence value is meaningful only when GeoLocation refers to a confidence value is meaningful only when GeoLocation refers to a
point with uncertainty. point with uncertainty.
5.2. DeviceDescriptor 5.2. DeviceDescriptor
The device descriptor contains parameters that identify the specific The device descriptor contains parameters that identify the specific
device, such as its manufacturer serial number, regulatory-specific device, such as its manufacturer serial number, regulatory-specific
ID (e.g., FCC ID), and any other device characteristics required by ID (e.g., FCC ID), and any other device characteristics required by
regulatory domains. regulatory domains.
skipping to change at page 32, line 4 skipping to change at page 32, line 5
+--------------------------------+ +--------------------------------+
|DeviceDescriptor | |DeviceDescriptor |
+---------------------+----------+ +---------------------+----------+
|serialNumber:string | required | |serialNumber:string | required |
|manufacturerId:string| optional | |manufacturerId:string| optional |
|modelId:string | optional | 1..* |modelId:string | optional | 1..*
|rulesetIds:list | optional |------>string |rulesetIds:list | optional |------>string
|.....................|..........| |.....................|..........|
|*other:any | | |*other:any | |
+---------------------+----------+ +---------------------+----------+
Parameters: Parameters:
serialNumber: The manufacturer's device serial number is REQUIRED. serialNumber: The manufacturer's device serial number is REQUIRED.
The length of the value MUST NOT exceed 64 characters, conforming The length of the value MUST NOT exceed 64 characters, conforming
to the X.520 [ITUT.X520.2008] recommendations. to the X.520 [ITUT.X520.2008] recommendations.
manufacturerId: The manufacturer's ID may be REQUIRED, depending on manufacturerId: The manufacturer's ID is OPTIONAL, but may be
the regulatory domain. This SHOULD represent the name of the required by some regulatory domains. This SHOULD represent the
device manufacturer, SHOULD be consistent across all devices from name of the device manufacturer, SHOULD be consistent across all
the same manufacturer, and SHOULD be distinct from that of other devices from the same manufacturer, and SHOULD be distinct from
manufacturers. The string value MUST NOT exceed 64 characters in that of other manufacturers. The string value MUST NOT exceed 64
length. characters in length.
modelId: The device's model ID may be REQUIRED, depending on the modelId: The device's model ID is OPTIONAL, but may be required by
regulatory domain. The string value MUST NOT exceed 64 characters some regulatory domains. The string value MUST NOT exceed 64
in length. characters in length.
rulesetIds: The list of identifiers for rulesets supported by the rulesetIds: The list of identifiers for rulesets supported by the
device (see Ruleset ID Registry (Section 9.2)). A Database MAY device (see Ruleset ID Registry (Section 9.2)). A Database MAY
require that the device provides this list before servicing the require that the device provides this list before servicing the
device requests. If the Database does not support any of the device requests. If the Database does not support any of the
rulesets specified in the list, the Database MAY refuse to service rulesets specified in the list, the Database MAY refuse to service
the device requests. See RulesetInfo (Section 5.6) for discussion the device requests. See RulesetInfo (Section 5.6) for discussion
on ruleset identifier. If present, the list MUST contain at least on ruleset identifier. If present, the list MUST contain at least
one entry. one entry.
other: Depending on the regulatory domain, other parameters may be other: Depending on the regulatory domain, other parameters may be
required. The Database MUST ignore all parameters in the message required. The Database MUST ignore all parameters in the message
skipping to change at page 33, line 4 skipping to change at page 33, line 5
+--------------------------------------------------------+ +--------------------------------------------------------+
|AntennaCharacteristics | |AntennaCharacteristics |
+-------------------------+------------------------------+ +-------------------------+------------------------------+
|height:float | depends on regulatory domain | |height:float | depends on regulatory domain |
|heightType:enum | optional | |heightType:enum | optional |
|heightUncertainty:float | depends on regulatory domain | |heightUncertainty:float | depends on regulatory domain |
|.........................|..............................| |.........................|..............................|
|*characteristics: | depends on regulatory domain | |*characteristics: | depends on regulatory domain |
| various | | | various | |
+-------------------------+------------------------------+ +-------------------------+------------------------------+
Parameters: Parameters:
height: The antenna height in meters. Whether the antenna height is height: The antenna height in meters. Whether the antenna height is
required depends on the device type and the regulatory domain. required depends on the device type and the regulatory domain.
Note that the height may be negative. Note that the height may be negative.
heightType: If the height is required, then heightType is also heightType: If the height is provided, then heightType is REQUIRED.
REQUIRED. Valid values are: Valid values are:
AGL Above ground level (default) AGL Above ground level (default)
AMSL Above mean sea level AMSL Above mean sea level
heightUncertainty: The height uncertainty in meters. Whether this heightUncertainty: The height uncertainty in meters. Whether this
is required depends on the regulatory domain. is required depends on the regulatory domain.
Depending on the regulatory authority, additional antenna NOTE: Depending on the regulatory domain, additional antenna
characteristics may be required, such as: characteristics may be required, such as:
o antenna direction o antenna direction
o antenna radiation pattern o antenna radiation pattern
o antenna gain o antenna gain
o antenna polarization o antenna polarization
These are not defined by the base protocol, but may be added to the
PAWS Parameters Registry (Section 9.1), as needed.
5.4. DeviceCapabilities 5.4. DeviceCapabilities
Device capabilities provide additional information that MAY be used Device capabilities provide additional information that may be used
by the Device to provide additional information to the Database that by the Device to provide additional information to the Database that
may help it to determine available spectrum. If the Database does can help it to determine available spectrum. If the Database does
not support device capabilities it MUST ignore the parameter not support device capabilities it MUST ignore the parameter
altogether. altogether.
+-------------------------------+ +-------------------------------+
|DeviceCapabilities | |DeviceCapabilities |
+---------------------+---------+ +---------------------+---------+
|frequencyRanges:list |optional |--+ |frequencyRanges:list |optional |--+
|.....................|.........| |
|*other:any | | |
+---------------------+---------+ | 0..* +---------------------+---------+ | 0..*
V V
+--------------------------------+ +--------------------------------+
|FrequencyRange | |FrequencyRange |
+----------------------+---------+ +----------------------+---------+
|startHz:float |required | |startHz:float |required |
|stopHz:float |required | |stopHz:float |required |
+----------------------+---------+ +----------------------+---------+
Parameters: Parameters:
frequencyRanges: Optional FrequencyRange (Section 5.13) list. Each frequencyRanges: Optional FrequencyRange (Section 5.13) list. Each
FrequencyRange element MUST contain start and stop frequencies, FrequencyRange element MUST contain start and stop frequencies in
and optionally, channel IDs, in which the Device can operate. which the Device can operate. When specified, the Database SHOULD
When specified, the Database SHOULD NOT return available spectrum NOT return available spectrum that falls outside these ranges.
that falls outside these ranges (or channel IDs). other Consult the PAWS Parameters Registry (Section 9.1) for
possible additional parameters. The Database MUST ignore all
parameters it does not understand.
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.
+-----------------------------+ +-----------------------------+
|DeviceOwner | |DeviceOwner |
+------------------+----------+ +------------------+----------+
|owner:vcard | required | |owner:vcard | required |
|operator:vcard | optional | |operator:vcard | optional |
+------------------+----------+ +------------------+----------+
Parameters: Parameters:
owner: The vCard contact information for the individual or business owner: The vCard contact information for the individual or business
that owns the Device is REQUIRED. that owns the Device is REQUIRED.
operator: The vCard contact information for the device operator is operator: The vCard contact information for the device operator is
OPTIONAL, but may be required by specific regulatory domains OPTIONAL, but may be required by specific regulatory domains
NOTE: Depending on the regulatory domain, the Database MAY be NOTE: Depending on the regulatory domain, the Database may be
required to validate the device-owner information. In these cases, required to validate the device-owner information. In these cases,
the Database MUST respond with an error if validation fails. See the Database MUST respond with an INVALID_VALUE error (see Error
PAWS Ruleset ID Registry (Section 9.2) for regulatory-specific Codes (Section 5.17)) if validation fails. See PAWS Ruleset ID
requirements on mandatory vCard properties. Registry (Section 9.2) for regulatory-specific requirements on
mandatory vCard properties.
All contact information MUST be expressed using the structure defined All contact information MUST be expressed using the structure defined
by the vCard Format Specification [RFC6350]. Note that the vCard by the vCard Format Specification [RFC6350]. Note that the vCard
specification defines maximum lengths for each field, conforming to specification defines maximum lengths for each field, conforming to
X.520 [ITUT.X520.2008] recommendations. X.520 [ITUT.X520.2008] recommendations.
5.6. RulesetInfo 5.6. RulesetInfo
This contains parameters for the ruleset of a regulatory domain that This contains parameters for the ruleset of a regulatory domain that
is communicated using the Initialization component (Section 4.2), is communicated using the Initialization component (Section 4.2),
skipping to change at page 35, line 4 skipping to change at page 35, line 15
+-----------------------------------+ +-----------------------------------+
|RulesetInfo | |RulesetInfo |
+-----------------------------------+ +-----------------------------------+
|authority:string | required | |authority:string | required |
|rulesetId:string | required | |rulesetId:string | required |
|maxLocationChange:float | optional | |maxLocationChange:float | optional |
|maxPollingSecs:int | optional | |maxPollingSecs:int | optional |
|...................................| |...................................|
|*other:any | | |*other:any | |
+------------------------+----------+ +------------------------+----------+
Parameters: Parameters:
authority: A string that indicates the regulatory domain to which authority: A string that indicates the regulatory domain to which
the ruleset applies is REQUIRED. It MUST be a 2-letter country the ruleset applies is REQUIRED. It MUST be a 2-letter country
code defined by Country Codes - ISO 3166 [ISO3166-1]. The Device code defined by Country Codes - ISO 3166 [ISO3166-1].
SHOULD use this to determine additional device behavior required
by the associated regulatory domain.
rulesetId: The ID of a ruleset for the specified authority (see rulesetId: The ID of a ruleset for the specified authority (see
Ruleset ID Registry (Section 9.2)). Ruleset ID Registry (Section 9.2)). The Device can use this to
determine additional device behavior required by the associated
regulatory rules.
maxLocationChange: The maximum location change in meters is REQUIRED maxLocationChange: The maximum location change in meters is REQUIRED
for Initialization Response (Section 4.2.2), but OPTIONAL for Initialization Response (Section 4.2.2), but OPTIONAL
otherwise. When the Device changes location by more than this otherwise. Some regulatory domains mandate that, when the Device
specified distance, it MUST contact the Database to get the changes location by more than this specified distance, it contact
available spectrum for the new location. If the Device is using the Database to get the available spectrum for the new location.
spectrum that is no longer available, it MUST immediately cease If this value is provided by the Database within the context of an
use of the spectrum under rules for database-managed spectrum. If Available Spectrum Response (Section 4.4.2), it takes precedence
this value is provided within the context of an Available Spectrum over the value within the Initialization Response (Section 4.2.2).
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 for the Initialization Response for available spectrum is REQUIRED for the Initialization Response
(Section 4.2.2), but OPTIONAL otherwise. The Device MUST contact (Section 4.2.2), but OPTIONAL otherwise. The Device MUST contact
the Database to get available spectrum no less frequently than the Database to get available spectrum no less frequently than
this duration. If the new spectrum information indicates that the this duration. If this value is provided within the context of an
Device is using spectrum that is no longer available, it MUST Available Spectrum Response (Section 4.4.2), it takes precedence
immediately cease use of those frequencies under rules for over the value within the Initialization Response (Section 4.2.2).
database-managed spectrum. 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.
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. Consult the
PAWS Parameters Registry (Section 9.1) for possible additional
parameters.
5.7. DbUpdateSpec 5.7. DbUpdateSpec
This element is provided by the Database to notify devices of an This element is provided by the Database to notify devices of an
upcoming change to the Database URI. upcoming change to the Database URI.
+-------------------------------+ +-------------------------------+
|DbUpdateSpec | |DbUpdateSpec |
+---------------------+---------+ +--------------------------+ +---------------------+---------+ +--------------------------+
|databases:list |required |------>|DatabaseSpec | |databases:list |required |------>|DatabaseSpec |
+---------------------+---------+ 1..* +---------------+----------+ +---------------------+---------+ 1..* +---------------+----------+
|name:string | required | |name:string | required |
|uri:string | required | |uri:string | required |
+---------------+----------+ +---------------+----------+
Parameters: Parameters:
databases: List of one or more DatabaseSpec (Section 5.8) entries. databases: List of one or more DatabaseSpec (Section 5.8) entries.
A Device SHOULD update its preconfigured list of databases to A Device needs to update its preconfigured list of databases to
replace (only) the database that provided the response with the replace (only) the database that provided the response with the
specified entries. specified entries.
5.8. DatabaseSpec 5.8. DatabaseSpec
This element contains the name and URI of a database. This element contains the name and URI of a database.
+--------------------------+ +--------------------------+
|DatabaseSpec | |DatabaseSpec |
+---------------+----------+ +---------------+----------+
skipping to change at page 37, line 7 skipping to change at page 37, line 29
|SpectrumSchedule | |SpectrumSchedule |
+--------------------+----------+ +--------------------+----------+
|eventTime:EventTime | required | |eventTime:EventTime | required |
|spectra:list | required | |spectra:list | required |
+--------------------+----------+ +--------------------+----------+
Parameters: Parameters:
rulesetInfo: The RulesetInfo (Section 5.6) is REQUIRED to identify rulesetInfo: The RulesetInfo (Section 5.6) is REQUIRED to identify
the regulatory domain and ruleset for which the spectrum schedule the regulatory domain and ruleset for which the spectrum schedule
applies (see Ruleset ID Registry (Section 9.2)). The Device MUST applies (see Ruleset ID Registry (Section 9.2)). The Device needs
use the corresponding ruleset to interpret the response. Values to use the corresponding ruleset to interpret the response.
provided within this parameter, such as maxLocationChange, take Values provided within this parameter, such as maxLocationChange,
precedence over the values provided by the Initialization take precedence over the values provided by the Initialization
Procedure (Section 4.2). Procedure (Section 4.2).
spectrumSchedules: The SpectrumSchedule (Section 5.10) list is spectrumSchedules: The SpectrumSchedule (Section 5.10) list is
REQUIRED. At least one schedule MUST be included. More than one REQUIRED. At least one schedule MUST be included. 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. How far in advance a schedule may be provided available spectrum. How far in advance a schedule may be provided
depends on the regulatory domain. If more than one schedule is depends on the regulatory domain. If more than one schedule is
included, the eventTime intervals MUST be disjoint and SHOULD be included, the eventTime intervals MUST be disjoint and SHOULD be
sorted in increasing time. A gap in the time schedule indicates sorted in increasing time. A gap in the time schedule indicates
no available spectrum during that time-interval gap. no available spectrum during that time-interval gap.
timeRange: The time range for which the specification is timeRange: The time range for which the specification is
comprehensive is OPTIONAL. When specified, any gaps in time comprehensive is OPTIONAL. When specified, any gaps in time
intervals within the "spectrumSchedules" element MUST be intervals within the "spectrumSchedules" element that overlaps
interpreted by the Device as time intervals in which there are no with the range specified by "timeRange" MUST be interpreted by the
available spectrum. Device as time intervals in which there are is available spectrum.
frequencyRanges: The frequency ranges for which the specification is frequencyRanges: The frequency ranges for which the specification is
comprehensive is OPTIONAL. It is a list of FrequencyRange comprehensive is OPTIONAL. It is a list of disjoint
(Section 5.13) entries, and the ranges MUST be disjoint. When FrequencyRange (Section 5.13) entries. When specified, it SHOULD
specified, it SHOULD correspond to the frequency ranges governed correspond to the frequency ranges governed by the ruleset. A
by the ruleset. A Device may combine this information with the Device can combine this information with the available-spectrum
available-spectrum specification within the "spectrumSchedules" specification within the "spectrumSchedules" element to
element to distinguish between "unavailable spectrum" and distinguish between "unavailable spectrum" and "spectrum for which
"spectrum for which no information has been provided". no information has been provided".
needsSpectrumReport: For regulatory domains that require a spectrum- needsSpectrumReport: The Database MAY return true for this parameter
usage report from devices, the Database MUST return true for this if spectrumSchedules list is non-empty; otherwise, the Database
parameter if spectrumSchedules list is non-empty; otherwise, the MAY omit this parameter altogether, which the Device MUST treat as
Database MAY return false or omit this parameter altogether. If the same as a false value. If this parameter is present and its
this parameter is present and its value is true, the Device MUST value is true, the Device MUST send a SPECTRUM_USE_NOTIFY
send a SPECTRUM_USE_NOTIFY (Section 4.4.5) message to the (Section 4.4.5) message to the Database; otherwise, the Device
Database; otherwise, the Device SHOULD NOT send the SHOULD NOT send the SPECTRUM_USE_NOTIFY message. Some regulatory
SPECTRUM_USE_NOTIFY message. domains mandate this value to be true.
maxTotalBwHz: The Database MAY return a constraint on the maximum maxTotalBwHz: The Database MAY return a constraint on the maximum
total bandwidth (in Hertz) allowed, which may or may not be total bandwidth (in Hertz) allowed, which may or may not be
contiguous. A regulatory domain MAY require the Database to contiguous. Some regulatory domains mandate the Database to
return this parameter. When present in the response, the Device return this parameter. When present in the response, the Device
MUST apply this constraint to its spectrum-selection logic to needs to apply this constraint to its spectrum-selection logic to
ensure total bandwidth does not exceed this value. ensure total bandwidth does not exceed this value.
maxContiguousBwHz: The Database MAY return a constraint on the maxContiguousBwHz: The Database MAY return a constraint on the
maximum contiguous bandwidth (in Hertz) allowed. A regulatory maximum contiguous bandwidth (in Hertz) allowed. Some regulatory
domain MAY require this Database to return this parameter. When domains mandate the Database to return this parameter. When
present in the response, the Device MUST apply this constraint to present in the response, the Device needs to apply this constraint
its spectrum-selection logic to ensure no single block of spectrum to its spectrum-selection logic to ensure no single block of
has bandwidth that exceeds this value. spectrum has bandwidth that exceeds this value.
5.10. SpectrumSchedule 5.10. SpectrumSchedule
The SpectrumSchedule element combines EventTime (Section 5.14) with The SpectrumSchedule element combines EventTime (Section 5.14) with
Spectrum (Section 5.11) to define a time period in which the spectrum Spectrum (Section 5.11) to define a time period in which the spectrum
is valid. is valid.
+-------------------------------+ +-------------------------------+
|SpectrumSchedule | |SpectrumSchedule |
+--------------------+----------+ +--------------------+----------+
skipping to change at page 38, line 25 skipping to change at page 38, line 47
|spectra:list | required |------->|Spectrum | |spectra:list | required |------->|Spectrum |
+--------------------+----------+ 0..* +--------------------+ +--------------------+----------+ 0..* +--------------------+
|resolutionBwHz:float| |resolutionBwHz:float|
|profiles:list | |profiles:list |
+--------------------+ +--------------------+
Parameters: Parameters:
eventTime: The EventTime (Section 5.14) is REQUIRED to express eventTime: The EventTime (Section 5.14) is REQUIRED to express
"when" this specification is valid. "when" this specification is valid.
spectra: Spectrum (Section 5.11) list is REQUIRED to specify the spectra: The Spectrum (Section 5.11) list is REQUIRED to specify the
available spectrum and permissible power levels, one per available spectrum and permissible power levels, one per
resolutionBwHz. The list MAY be empty when there is no available resolutionBwHz. The list MAY be empty when there is no available
spectrum. spectrum.
5.11. Spectrum 5.11. Spectrum
Available spectrum can be characterized by an ordered list of Available spectrum can be characterized by an ordered list of
spectrum profiles that defines permissible power levels over a set of spectrum profiles that defines permissible power levels over a set of
frequency ranges. Each Spectrum element defines permissible power frequency ranges. Each Spectrum element defines permissible power
levels as maximum power spectral densities over a specified levels as maximum power spectral densities over a specified
skipping to change at page 39, line 40 skipping to change at page 40, line 12
|hz:float |required | |hz:float |required |
|dbm:float |required | |dbm:float |required |
+----------------+---------+ +----------------+---------+
Parameters: Parameters:
resolutionBwHz: This parameter is REQUIRED to define the resolution resolutionBwHz: This parameter is REQUIRED to define the resolution
bandwidth (in Hertz) over which permissible power spectral density bandwidth (in Hertz) over which permissible power spectral density
is defined. For example, FCC regulation would require one is defined. For example, FCC regulation would require one
spectrum specification at a bandwidth of 6MHz, and ETSI regulation spectrum specification at a bandwidth of 6MHz, and ETSI regulation
would require two specifications, at 0.1MHz and 8MHz. This would require two specifications, at 0.1MHz and 8MHz.
parameter MAY be empty if there is no available spectrum.
profiles: A SpectrumProfile (Section 5.12) list is REQUIRED to profiles: A SpectrumProfile (Section 5.12) list is REQUIRED to
specify permissible power levels over a set of frequency ranges. specify permissible power levels over a set of frequency ranges.
The list MAY be empty if there is no available spectrum. The list MAY be empty if there is no available spectrum.
Consider the following example with two different sets of permitted Consider the following example with two different sets of permitted
power spectral densities for the same set of frequencies over power spectral densities for the same set of frequencies over
different resolution bandwidths (for illustrative purposes only): different resolution bandwidths (for illustrative purposes only):
[ [
{ {
skipping to change at page 42, line 4 skipping to change at page 42, line 10
A spectrum profile is characterized by an ordered list of (frequency, A spectrum profile is characterized by an ordered list of (frequency,
power) points that represents the shape of maximum permissible power power) points that represents the shape of maximum permissible power
levels over a range of frequencies. levels over a range of frequencies.
o It MUST contain a minimum of two entries. o It MUST contain a minimum of two entries.
o The entries in the list MUST be ordered in non-decreasing o The entries in the list MUST be ordered in non-decreasing
frequency values. frequency values.
o Two consecutive points MAY have the same frequency value to o Two consecutive points MAY have the same frequency value to
represent a "step function". represent a "step function".
o Three or more points MUST NOT share the same frequency value. o Three or more points MUST NOT share the same frequency value.
o The first frequency is inclusive; the last frequency is exclusive. o The first frequency is inclusive; the last frequency is exclusive.
The following figure defines the SpectrumProfile element. The following figure illustrates the SpectrumProfile element.
+-------------------------------+ +-------------------------------+
|SpectrumProfile | |SpectrumProfile |
+---------------------+---------+ +---------------------+---------+
|list |required |---+ |list |required |---+
+---------------------+---------+ | 2..* +---------------------+---------+ | 2..*
V V
+----------------+---------+ +----------------+---------+
|hz:float |required | |hz:float |required |
|dbm:float |required | |dbm:float |required |
skipping to change at page 43, line 37 skipping to change at page 43, line 43
before the event becomes "active". If the value is zero or before the event becomes "active". If the value is zero or
negative, the event is already active. negative, the event is already active.
o If the event is already active, (stopTime - timestamp) is the o If the event is already active, (stopTime - timestamp) is the
duration that the event remains active. If the value is zero or duration that the event remains active. If the value is zero or
negative, the event is no longer active and MUST be ignored. negative, the event is no longer active and MUST be ignored.
5.15. GeoSpectrumSpec 5.15. GeoSpectrumSpec
The GeoSpectrumSpec element encapsulates the available spectrum for a The GeoSpectrumSpec element encapsulates the available spectrum for a
location. It is returned within a AVAIL_SPECTRUM_BATCH_RESP location. It is returned within a AVAIL_SPECTRUM_BATCH_RESP
(Section 4.4.4) batch response that contains one GeoSpectrumSpec (Section 4.4.4) batch response that contains multiple GeoSpectrumSpec
parameter for each location in the request. entries, each matching a location provided in the batch request.
+----------------------------------+ +----------------------------------+
|GeoSpectrumSpec | |GeoSpectrumSpec |
+-----------------------+----------+ +-----------------------+----------+
|location:GeoLocation | required | |location:GeoLocation | required |
|spectrumSpecs:list | required |-------+ |spectrumSpecs:list | required |-------+
+-----------------------+----------+ | +-----------------------+----------+ |
| 1..* | 1..*
V V
+--------------+ +--------------+
| SpectrumSpec | | SpectrumSpec |
skipping to change at page 44, line 30 skipping to change at page 44, line 44
+----------------------------+----------+ +----------------------------+----------+
|deviceDesc:DeviceDescriptor | required | |deviceDesc:DeviceDescriptor | required |
|isValid:boolean | required | |isValid:boolean | required |
|reason:string | optional | |reason:string | optional |
+----------------------------+----------+ +----------------------------+----------+
Parameters: Parameters:
deviceDesc: The DeviceDescriptor (Section 5.2) that was used to deviceDesc: The DeviceDescriptor (Section 5.2) that was used to
check for validity is REQUIRED. check for validity is REQUIRED.
isValid: A REQUIRED boolean value that indicates whether the Device isValid: This is a REQUIRED boolean value that indicates whether the
is valid. Device is valid.
reason: If the device identifier is not valid, the Database MAY reason: If the device identifier is not valid, the Database MAY
include a reason. The reason MAY be in any language. The length include a reason. The reason MAY be in any language. The length
of the value MUST NOT exceed 128 characters. of the value MUST NOT exceed 128 characters.
5.17. Error Element 5.17. Error Element
If the Database responds to a PAWS request message with an error, it If the Database responds to a PAWS request message with an error, it
MUST include an Error element. MUST include an Error element.
+---------------------------+ +---------------------------+
|Error | |Error |
+----------------+----------+ +----------------+----------+
|code:int | required | |code:int | required |
|message:string | optional | |message:string | optional |
|data:any | optional | |data:any | optional |
+----------------+----------+ +----------------+----------+
Parameters: Parameters:
code: An integer code that indicates the error type. Values MUST be code: An integer code that indicates the error type is REQUIRED.
within the range, -32768 to 32767, inclusive. Values MUST be within the range, -32768 to 32767, inclusive.
message: A description of the error. It MAY be in any language. message: A description of the error is OPTIONAL. It MAY be in any
The length of the value MUST NOT exceed 128 characters. language. The length of the value MUST NOT exceed 128 characters.
data: The Database MAY include additional data. For some errors, data: The Database MAY include additional data. For some errors,
additional data may be required. The Device MUST ignore any data additional data may be required. The Device MUST ignore any data
parameters it does not understand. parameters it does not understand.
The following table lists predefined and reserved error codes. They The following table lists predefined and reserved error codes. They
are loosely grouped into the following categories: are loosely grouped into the following categories:
-100s: Indicates compatibility issues, e.g., version mismatch, -100s: Indicates compatibility issues, e.g., version mismatch,
unsupported or unimplemented features. unsupported or unimplemented features.
-200s: Indicates that the Device request contains an error that -200s: Indicates that the Device request contains an error that
skipping to change at page 46, line 4 skipping to change at page 46, line 23
domain specified in the request. domain specified in the request.
-103 UNIMPLEMENTED The Database does not implement the optional -103 UNIMPLEMENTED The Database does not implement the optional
request or optional feature. request or optional feature.
-104 OUTSIDE_COVERAGE The specified geo-location is outside the -104 OUTSIDE_COVERAGE The specified geo-location is outside the
coverage area of the Database. The Database coverage area of the Database. The Database
MAY include a DbUpdateSpec (Section 5.7) MAY include a DbUpdateSpec (Section 5.7)
parameter to provide a list of alternate parameter to provide a list of alternate
databases that might be appropriate for the databases that might be appropriate for the
requested location. See OUTSIDE_COVERAGE requested location. See OUTSIDE_COVERAGE
Error (Section 5.17.1) for more details. Error (Section 5.17.1) for more details.
-105 DATABASE_CHANGE The Database has changed its URI. The -105 DATABASE_CHANGE The Database has changed its URI. The
Database MAY include a DbUpdateSpec Database MAY include a DbUpdateSpec
(Section 5.7) parameter in the error response (Section 5.7) parameter in the error response
to provide devices with one or more alternate to provide devices with one or more alternate
database URIs. The Device SHOULD use the database URIs. The Device needs to use the
information to update its list of information to update its list of
preconfigured databases to replace (only) its preconfigured databases to replace (only) its
entry for the responding Database with the entry for the responding Database with the
list of alternate database URIs. See list of alternate database URIs. See
DATABASE_CHANGE Error (Section 5.17.2) for DATABASE_CHANGE Error (Section 5.17.2) for
more details. more details.
-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
skipping to change at page 48, line 4 skipping to change at page 48, line 18
|code:int | required | |code:int | required |
|message:string | optional | +---------------------------+ |message:string | optional | +---------------------------+
|data:ErrorData | required |--->|ErrorData | |data:ErrorData | required |--->|ErrorData |
+----------------+----------+ +----------------+----------+ 1..* +----------------+----------+ +----------------+----------+ 1..*
|parameters:list | required |--+ |parameters:list | required |--+
+----------------+----------+ | +----------------+----------+ |
v v
string string
Parameters: Parameters:
parameters: List of one or more parameter names (strings). The name parameters: List of one or more parameter names (strings). The name
of a parameter SHOULD be expressed using dotted notation, when of a parameter SHOULD be expressed using dotted notation, when
appropriate, e.g., "deviceDesc.serialNumber". appropriate, e.g., "deviceDesc.serialNumber".
6. Message Encoding 6. Message Encoding
The PAWS protocol is encoded using JSON-RPC [JSON-RPC] (see also The PAWS protocol is encoded using JSON-RPC [JSON-RPC] (see also The
JavaScript Object Notation (JSON) [RFC4627]). Each component JavaScript Object Notation (JSON) Data Interchange Format [RFC7159]).
described in Protocol Functionalities (Section 4) corresponds to one Each component described in Protocol Functionalities (Section 4)
or more JSON-RPC methods. This section provides the JSON schema for corresponds to one or more JSON-RPC methods. This section provides
each of the protocol messages and parameters defined in sections the JSON schema for each of the protocol messages and parameters
Protocol Functionalities (Section 4) and Protocol Parameters defined in sections Protocol Functionalities (Section 4) and Protocol
(Section 5). JSON schemas are expressed using the format described Parameters (Section 5). JSON schemas are expressed using the format
by JSON Schema [I-D.zyp-json-schema], but are not intended to be used described by JSON Schema [I-D.zyp-json-schema], but are not intended
for formal validation. to be used for formal validation.
NOTE: In general, all messages defined in this section are extensible NOTE: In general, all messages defined in this section are extensible
by adding additional properties to support regulatory-specific and by adding additional properties to support regulatory-specific and
database-specific requirements. In all cases, the Device or Database database-specific requirements. In all cases, the Device or Database
MUST ignore any parameter it does not understand. MUST ignore any parameter it does not understand.
NOTE: The JSON examples in this section may contain ellipses (...) to NOTE: The JSON examples in this section may contain ellipses (...) to
represent additional properties or elements that have been omitted in represent additional properties or elements that have been omitted in
order to make the examples more concise. order to make the examples more concise.
skipping to change at page 48, line 41 skipping to change at page 49, line 7
The JSON-RPC [JSON-RPC] protocol consists of two basic objects, The JSON-RPC [JSON-RPC] protocol consists of two basic objects,
Request and Response: Request and Response:
o The JSON-RPC Request object encapsulates a PAWS functionality o The JSON-RPC Request object encapsulates a PAWS functionality
(operation) and the request message (operation) and the request message
o The JSON-RPC Response object encapsulates a PAWS response message o The JSON-RPC Response object encapsulates a PAWS response message
and Error element and Error element
The Database and Device MUST support JSON-RPC 2.0 encoding. The Database and Device MUST support JSON-RPC 2.0 encoding.
The JSON-RPC Request for PAWS has the following the following forms: The JSON-RPC Request for PAWS has the following form:
{ {
"jsonrpc": "2.0", "jsonrpc": "2.0",
"method": "string", "method": "string",
"params": <PAWS_REQ>, "params": <PAWS_REQ>,
"id": "string" "id": "string"
} }
where "method" is the name of a PAWS functionality (operation), and where "method" is the name of a PAWS functionality (operation), and
<PAWS_REQ> represents one of the PAWS request objects associated with <PAWS_REQ> represents one of the PAWS request objects associated with
the method. Method names are defined with the prefix, the method. Method names are defined with the prefix,
"spectrum.paws.". "spectrum.paws.".
The non-error JSON-RPC Response for PAWS has the following forms: The non-error JSON-RPC Response for PAWS has the following form:
{ {
"jsonrpc": "2.0", "jsonrpc": "2.0",
"result": <PAWS_RESP>, "result": <PAWS_RESP>,
"id": "string" "id": "string"
} }
where <PAWS_RESP> represents one of the PAWS response objects where <PAWS_RESP> represents one of the PAWS response objects
associated with the method. associated with the method.
skipping to change at page 50, line 25 skipping to change at page 50, line 35
"version": { "version": {
"type": "string", "type": "string",
"required": true "required": true
}, },
"deviceDesc": { "deviceDesc": {
"type": "DeviceDescriptor", "type": "DeviceDescriptor",
"required": true "required": true
}, },
"location": { "location": {
"type": "GeoLocation", "type": "GeoLocation",
"description": "The location SHOULD be the current location "description": "The location of the Device's antenna.
of the Device's antenna. Depending on the regulatory Some regulatory domains mandate this to be the
domain, the location MAY be the anticipated position of Device's current location; others allow it to be
the Device.", an anticipated position of the Device.",
"required": true "required": true
} }
} }
} }
Example "init" JSON-RPC request: Example "init" JSON-RPC request:
{ {
"jsonrpc": "2.0", "jsonrpc": "2.0",
"method": "spectrum.paws.init", "method": "spectrum.paws.init",
skipping to change at page 53, line 32 skipping to change at page 53, line 32
"version": { "version": {
"type": "string", "type": "string",
"required": true "required": true
}, },
"deviceDesc": { "deviceDesc": {
"type": "DeviceDescriptor", "type": "DeviceDescriptor",
"required": true "required": true
}, },
"location": { "location": {
"type": "GeoLocation", "type": "GeoLocation",
"description": "The location SHOULD be the current location "description": "The location of the Device's antenna.",
of the Device's antenna. Depending on the regulatory
domain, the location MAY be the anticipated position of
the Device.",
"required": true "required": true
}, },
"deviceOwner": { "deviceOwner": {
"type": "DeviceOwner", "type": "DeviceOwner",
"required": true "required": true
}, },
"antenna": { "antenna": {
"type": "AntennaCharacteristics", "type": "AntennaCharacteristics",
"description": "Antenna characteristics, including its "description": "Antenna characteristics, including its
height and height type", height and height type",
skipping to change at page 56, line 30 skipping to change at page 56, line 30
"required": true "required": true
}, },
"deviceDesc": { "deviceDesc": {
"type": "DeviceDescriptor", "type": "DeviceDescriptor",
"description": "Descriptor of the device for which to "description": "Descriptor of the device for which to
determine available spectrum.", determine available spectrum.",
"required": false "required": false
}, },
"location": { "location": {
"type": "GeoLocation", "type": "GeoLocation",
"description": "The location SHOULD be the current location "description": "The location of the Device's antenna.
of the Device's antenna. Depending on the regulatory Some regulatory domains mandate this to be the Device's
domain, the location MAY be the anticipated position of current location; others allow it to be an anticipated
the Device. When request is made by a Master Device on position of the Device. When the request is made by a
behalf of a Slave Device, this is the location of the Master Device on behalf of a Slave Device, this is the
Slave Device.", location of the Slave Device (optional), and the Master
Device location is provided in the masterDeviceLocation
parameter.",
"required": false "required": false
}, },
"owner": { "owner": {
"type": "DeviceOwner", "type": "DeviceOwner",
"description": "May be required if the Device is not yet "description": "May be required if the Device is not yet
registered or if the DB does not implement a separate registered or if the DB does not implement a separate
device-registration request. Also depends on device type device-registration request. Also depends on device type
and regulatory domain", and regulatory domain",
"required": false "required": false
}, },
"antenna": { "antenna": {
"type": "AntennaCharacteristics", "type": "AntennaCharacteristics",
"description": "Antenna characteristics, including its "description": "Antenna characteristics, including its
height and height type. May required depending on height and height type. May be required, depending on
device type and regulatory domain", device type and regulatory domain",
"required": false "required": false
}, },
"capabilities": { "capabilities": {
"type": "DeviceCapabilities", "type": "DeviceCapabilities",
"description": "The Database SHOULD NOT return spectrum that "description": "The Database SHOULD NOT return spectrum that
is incompatible with the specified capabilities.", is incompatible with the specified capabilities.",
"required": false "required": false
}, },
"masterDeviceDesc": { "masterDeviceDesc": {
"type": "DeviceDescriptor", "type": "DeviceDescriptor",
"description": "When the request is made by a Master Device "description": "When the request is made by a Master Device
skipping to change at page 69, line 26 skipping to change at page 69, line 26
"required": true "required": true
}, },
"location": { "location": {
"type": "GeoLocation", "type": "GeoLocation",
"description": "The location of the Device. When the "description": "The location of the Device. When the
notification is made by a Master Device on behalf notification is made by a Master Device on behalf
of a Slave Device, this is the location of the of a Slave Device, this is the location of the
Slave Device.", Slave Device.",
"required": false "required": false
}, },
"masterDeviceDesc": {
"type": "DeviceDescriptor",
"description": "When the notification is made by a
Master Device on behalf of a Slave Device, this is
the descriptor of the Master Device.",
"required": false
},
"masterDeviceLocation": { "masterDeviceLocation": {
"type": "GeoLocation", "type": "GeoLocation",
"description": "When the notification is made by the "description": "When the notification is made by the
Master Device on behalf of a Slave Device, this is Master Device on behalf of a Slave Device, this is
the location of the Master Device.", the location of the Master Device.",
"required": false "required": false
}, },
"spectra": { "spectra": {
"type": "array", "type": "array",
"description": "The spectrum anticipated to be used by "description": "The spectrum anticipated to be used by
skipping to change at page 78, line 44 skipping to change at page 79, line 10
MAY be used by the Device to provide additional information to the MAY be used by the Device to provide additional information to the
Database to help the Database determine available spectrum. If the Database to help the Database determine available spectrum. If the
Database does not support device capabilities, it MUST ignore the Database does not support device capabilities, it MUST ignore the
parameter. parameter.
{ {
"name": "DeviceCapabilities", "name": "DeviceCapabilities",
"type": "object", "type": "object",
"description": "Device capabilities to help DB determine "description": "Device capabilities to help DB determine
available spectrum. The DB SHOULD NOT return available available spectrum. The DB SHOULD NOT return available
spectrum that falls outside the given frequency ranges.", spectrum that falls outside the device capabilities.",
"properties": { "properties": {
"frequencyRanges": { "frequencyRanges": {
"type": "array", "type": "array",
"description": "The frequency ranges in which the Device
can operate.",
"items": "FrequencyRange", "items": "FrequencyRange",
"required": false "required": false
} }
} }
} }
6.8.5. DeviceOwner 6.8.5. DeviceOwner
The DeviceOwner (Section 5.5) parameter contains device-owner The DeviceOwner (Section 5.5) parameter contains device-owner
information required as part of device registration. Regulatory information required as part of device registration. Some regulatory
domains MAY require additional parameters. JSON encoding of vCard is domains require additional parameters and specific fields within a
described in jCard: The JSON format for vCard [RFC7095]. vCard. JSON encoding of vCard is described in jCard: The JSON format
for vCard [RFC7095].
{ {
"name": "DeviceOwner", "name": "DeviceOwner",
"type": "object", "type": "object",
"description": "Device-owner information required as part of "description": "Device-owner information required as part of
Device registration. Regulatory domains MAY require Device registration. Regulatory domains MAY require
additional parameters.", additional parameters.",
"properties": { "properties": {
"owner": { "owner": {
"type": "vCard", "type": "vCard",
skipping to change at page 81, line 14 skipping to change at page 81, line 14
{ {
"name": "RulesetInfo", "name": "RulesetInfo",
"type": "object", "type": "object",
"description": "The ruleset of a regulatory domain that is "description": "The ruleset of a regulatory domain that is
communicated to Devices in the Initialization Response communicated to Devices in the Initialization Response
message.", message.",
"properties": { "properties": {
"authority": { "authority": {
"type": "string", "type": "string",
"description": "The regulatory domain at the specified "description": "The regulatory authority 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
}, },
"rulesetId": { "rulesetId": {
"type": "string", "type": "string",
"description": "The identifier of an applicable ruleset", "description": "The identifier of an applicable ruleset",
"required": true "required": true
}, },
"maxLocationChange": { "maxLocationChange": {
skipping to change at page 85, line 17 skipping to change at page 85, line 17
The EventTime (Section 5.14) element specifies the start and stop The EventTime (Section 5.14) element specifies the start and stop
times of an "event." It is used to indicate the time period for times of an "event." It is used to indicate the time period for
which a Spectrum (Section 5.11) is valid. which a Spectrum (Section 5.11) is valid.
{ {
"name": "EventTime", "name": "EventTime",
"type": "object", "type": "object",
"properties": { "properties": {
"startTime": { "startTime": {
"type": "string", "type": "string",
"description": "YYYY-MM-DDThh:mm:ssZ RFC3339 format.", "description": "YYYY-MM-DDThh:mm:ssZ RFC3339 format.
Inclusive.",
"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.
Exclusive.",
"format": "date-time", "format": "date-time",
"required": false "required": false
} }
} }
} }
6.8.12. SpectrumSchedule 6.8.12. SpectrumSchedule
The SpectrumSchedule (Section 5.10) element combines EventTime with The SpectrumSchedule (Section 5.10) element combines EventTime with
Spectrum to define a time period during which the spectrum is valid. Spectrum to define a time period during which the spectrum is valid.
skipping to change at page 87, line 23 skipping to change at page 87, line 23
}, },
"frequencyRanges": { "frequencyRanges": {
"type": "array", "type": "array",
"description": "The frequency ranges for which the "description": "The frequency ranges for which the
spectrumSchedules is comprehensive", spectrumSchedules is comprehensive",
"items": "FrequencyRange", "items": "FrequencyRange",
"required": false "required": false
}, },
"needsSpectrumReport": { "needsSpectrumReport": {
"type": "boolean", "type": "boolean",
"description": "For regulatory domains that require a "description": "Regulatory domains that require a
spectrum-usage report from devices, the Database MUST spectrum-usage report from devices would mandate the
return true for this parameter.", Database to set this value to true.",
"default": false, "default": false,
"required": false "required": false
}, },
"maxTotalBwHz": { "maxTotalBwHz": {
"type": "number", "type": "number",
"description": "Constraint on total bandwidth allowed, "description": "Constraint on total bandwidth allowed,
summed across all blocks of spectrum.", summed across all blocks of spectrum.",
"required": false "required": false
}, },
"maxContiguousBwHz": { "maxContiguousBwHz": {
skipping to change at page 90, line 45 skipping to change at page 90, line 45
The Database SHOULD use HTTP status code "307 Temporary Redirect" to The Database SHOULD use HTTP status code "307 Temporary Redirect" to
indicate that the Device SHOULD resubmit the same request to an indicate that the Device SHOULD resubmit the same request to an
alternate URI. The Device MAY revert to the original URI for the alternate URI. The Device MAY revert to the original URI for the
very next request, or MAY continue to use the alternate URI for a very next request, or MAY continue to use the alternate URI for a
period of time, e.g.,: period of time, e.g.,:
o For the remainder of its session, or o For the remainder of its session, or
o For a fixed period of time, or o For a fixed period of time, or
o Until power cycled, or o Until power cycled, or
o Until it receives another redirect o Until it receives another redirect
However, it SHOULD NOT modify its stored list of URIs. However, the Device does not need to modify its stored list of URIs.
The Database SHOULD use HTTP status code "301 Moved Permanently" to The Database SHOULD use HTTP status code "301 Moved Permanently" to
indicate that the Device SHOULD resubmit this request, and all future indicate that the Device SHOULD resubmit this request, and all future
requests, to an alternate URI. If the Device maintains a list of requests, to an alternate URI. If the Device maintains a list of
available URIs, it SHOULD replace only the current URI with the available URIs, it needs to replace only the current URI with the
alternate URI. alternate URI.
8. Extensibility 8. Extensibility
8.1. Defining New Message Parameters 8.1. Defining New Message Parameters
New request or response parameters for use with the PAWS protocol are New request or response parameters for use with the PAWS protocol are
defined and registered in the parameters registry following the defined and registered in the parameters registry following the
procedure in Section 9.1. procedure in Section 9.1.
skipping to change at page 94, line 40 skipping to change at page 94, line 40
9.1.2.6. ETSI Device Category 9.1.2.6. ETSI Device Category
Parameter name: etsiEnDeviceCategory Parameter name: etsiEnDeviceCategory
Parameter usage location: DeviceDescriptor (Section 5.2) Parameter usage location: DeviceDescriptor (Section 5.2)
Specification document(s): Specifies the White Space Device Specification document(s): Specifies the White Space Device
category, as defined by the ETSI Harmonised Standard category, as defined by the ETSI Harmonised Standard
[ETSI-EN-301-598]. Valid values are the strings, "master" and [ETSI-EN-301-598]. Valid values are the strings, "master" and
"slave". It is case insensitive. "slave". It is case insensitive.
9.1.2.7. ETSI Simultaneous Channel Operation Restriction
Parameter name: etsiEnSimultaneousChannelOperationRestriction
Parameter usage location: SpectrumSpec (Section 5.9)
Specification document(s): Specifies the constraint on the device
maximum total EIRP, as defined by the ETSI Harmonised Standard
[ETSI-EN-301-598]. The values are represented by numeric strings,
such as "0", "1", etc. Consult the documentation for the
specification of the power constraint corresponding to each
parameter value.
9.2. PAWS Ruleset ID Registry 9.2. PAWS Ruleset ID Registry
This specification establishes the PAWS Ruleset ID Registry. This specification establishes the PAWS Ruleset ID Registry.
Ruleset type names for inclusion in the PAWS protocol messages are Ruleset type names for inclusion in the PAWS protocol messages are
registered through the Specification Required [RFC5226] process, registered through the Specification Required [RFC5226] process,
after a two-week review period on the paws-iana-review@ietf.org after a two-week review period on the paws-iana-review@ietf.org
mailing list, on the advice of one or more Designated Experts. To mailing list, on the advice of one or more Designated Experts. To
allow for the allocation of values prior to publication, the allow for the allocation of values prior to publication, the
Designated Expert(s) may approve registration once they are satisfied Designated Expert(s) may approve registration once they are satisfied
skipping to change at page 96, line 38 skipping to change at page 97, line 5
Specification document(s): This ruleset refers to the FCC rules for Specification document(s): This ruleset refers to the FCC rules for
TV-band White Space operations established in the Code of Federal TV-band White Space operations established in the Code of Federal
Regulations (CFR), Title 47, Part 15, Subpart H [FCC-CFR47-15H]. Regulations (CFR), Title 47, Part 15, Subpart H [FCC-CFR47-15H].
9.2.2.2. European Telecommunications Standards Institute (ETSI) 9.2.2.2. European Telecommunications Standards Institute (ETSI)
For the additional parameters that start with the "etsi" prefix, see For the additional parameters that start with the "etsi" prefix, see
PAWS Parameters Registry Initial Contents (Section 9.1.2) for more PAWS Parameters Registry Initial Contents (Section 9.1.2) for more
information. information.
Ruleset name: ETSI-EN-301-598-1.0.0-draft Ruleset name: ETSI-EN-301-598-1.0.9-draft
Additional parameter requirements: Additional parameter requirements:
manufacturerId: Specifies a device's manufacturer's identifier. manufacturerId: Specifies a device's manufacturer's identifier.
It is a REQUIRED parameter in DeviceDescriptor (Section 5.2). It is a REQUIRED parameter in DeviceDescriptor (Section 5.2).
modelId: Specifies a device's model identifier. It is a REQUIRED modelId: Specifies a device's model identifier. It is a REQUIRED
parameter in DeviceDescriptor (Section 5.2). parameter in DeviceDescriptor (Section 5.2).
etsiEnDeviceType: Specifies the device's ETSI device type. It is etsiEnDeviceType: Specifies the device's ETSI device type. It is
a REQUIRED parameter in DeviceDescriptor (Section 5.2). a REQUIRED parameter in DeviceDescriptor (Section 5.2).
etsiEnDeviceEmissionsClass: Specifies the device's ETSI device etsiEnDeviceEmissionsClass: Specifies the device's ETSI device
emissions class. It is a REQUIRED parameter in emissions class. It is a REQUIRED parameter in
DeviceDescriptor (Section 5.2). DeviceDescriptor (Section 5.2).
skipping to change at page 97, line 16 skipping to change at page 97, line 27
It is a REQUIRED parameter in DeviceDescriptor (Section 5.2). It is a REQUIRED parameter in DeviceDescriptor (Section 5.2).
etsiEnDeviceCategory: Specifies the device's ETSI device etsiEnDeviceCategory: Specifies the device's ETSI device
category. It is a REQUIRED parameter in DeviceDescriptor category. It is a REQUIRED parameter in DeviceDescriptor
(Section 5.2). (Section 5.2).
requestType: Modifies the available-spectrum request type. It is requestType: Modifies the available-spectrum request type. It is
an OPTIONAL parameter in the AVAIL_SPECTRUM_REQ (Section 4.4.1) an OPTIONAL parameter in the AVAIL_SPECTRUM_REQ (Section 4.4.1)
and AVAIL_SPECTRUM_BATCH_REQ (Section 4.4.3) messages. If and AVAIL_SPECTRUM_BATCH_REQ (Section 4.4.3) messages. If
specified, the only valid value is, "Generic Slave", and the specified, the only valid value is, "Generic Slave", and the
Database MUST respond with generic operating parameters for any Database MUST respond with generic operating parameters for any
Slave Device. Slave Device.
needsSpectrumReport Depending on the regulatory domain, the needsSpectrumReport The Database MUST set this to true in the
Database MAY be required to set this value to true in the SpectrumSpec (Section 5.9) parameter of the AVAIL_SPECTRUM_RESP
AVAIL_SPECTRUM_RESP (Section 4.4.2) and (Section 4.4.2) and AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4)
AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4) messages. messages to indicate that the Device must report spectrum
usage.
maxTotalBwHz: Specifies a constraint on total allowed bandwidth. maxTotalBwHz: Specifies a constraint on total allowed bandwidth.
It is a REQUIRED parameter in AVAIL_SPECTRUM_RESP It is a REQUIRED field in the SpectrumSpec (Section 5.9)
(Section 4.4.2) and AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4). parameter of the AVAIL_SPECTRUM_RESP (Section 4.4.2) and
AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4) messages.
maxContiguousBwHz: Specifies a constraint on total allowed maxContiguousBwHz: Specifies a constraint on total allowed
contiguous bandwidth. It is a REQUIRED parameter in contiguous bandwidth. It is a REQUIRED field in the
AVAIL_SPECTRUM_RESP (Section 4.4.2) and SpectrumSpec (Section 5.9) parameter of the AVAIL_SPECTRUM_RESP
AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4). (Section 4.4.2) and AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4)
messages.
etsiEnSimultaneousChannelOperationRestriction: Specifies a
constraint on simultaneous channel operation. The Database MAY
include this field within the SpectrumSpec (Section 5.9)
parameter of the AVAIL_SPECTRUM_RESP (Section 4.4.2) and
AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4) messages. If it is
not provided, the Device MUST assume the value of "0". If it
is provided, the Device MUST NOT ignore it.
maxLocationChange: Specifies a constraint on maximum location maxLocationChange: Specifies a constraint on maximum location
changes. It is a REQUIRED parameter in AVAIL_SPECTRUM_RESP changes. It is a REQUIRED field in the RulesetInfo
(Section 4.4.2) and AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4). (Section 5.6) parameter included as part of the
AVAIL_SPECTRUM_RESP (Section 4.4.2) and
AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4) messages.
Specification document(s): This ruleset refers to the ETSI Specification document(s): This ruleset refers to the ETSI
Harmonised Standard [ETSI-EN-301-598] established by ETSI. Harmonised Standard [ETSI-EN-301-598] established by ETSI.
9.3. PAWS Error Code Registry 9.3. PAWS Error Code Registry
This specification establishes the PAWS Error Code Registry. This specification establishes the PAWS Error Code Registry.
Additional error codes for inclusion in the PAWS protocol error Additional error codes for inclusion in the PAWS protocol error
message are registered through the Specification Required [RFC5226] message are registered through the Specification Required [RFC5226]
process, after a two-week review period on the process, after a two-week review period on the
skipping to change at page 102, line 25 skipping to change at page 102, line 48
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.
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
January 2014. January 2014.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014.
13.2. Informative References 13.2. Informative References
[ETSI-EN-301-598] [ETSI-EN-301-598]
European Telecommunication Standards Institute (ETSI), European Telecommunication Standards Institute (ETSI),
"Draft ETSI EN 301 598 (V1.0.0): White Space Devices "Final draft ETSI EN 301 598 (V1.0.9): White Space Devices
(WSD); Wireless Access Systems operating in the 470 MHz to (WSD); Wireless Access Systems operating in the 470 MHz to
790 MHz frequency band; Harmonized EN covering the 790 MHz frequency band; Harmonized EN covering the
essential requirements of article 3.2 of the R&TTE essential requirements of article 3.2 of the R&TTE
Directive", July 2013, <http://www.etsi.org/deliver/ Directive", February 2014, <http://www.etsi.org/deliver/
etsi_en/301500_301599/301598/01.00.00_20/ etsi_en/301500_301599/301598/01.00.09_30/
en_301598v010000a.pdf>. en_301598v010009v.pdf>.
[FCC-CFR47-15H] [FCC-CFR47-15H]
U. S. Government, "Electronic Code of Federal Regulations, U. S. Government, "Electronic Code of Federal Regulations,
Title 47, Part 15, Subpart H: Television Band Devices", Title 47, Part 15, Subpart H: Television Band Devices",
December 2010, <http://www.ecfr.gov/cgi-bin/ December 2010, <http://www.ecfr.gov/cgi-bin/
text-idx?rgn=div6&view=text&node=47:1.0.1.1.16.8>. text-idx?rgn=div6&view=text&node=47:1.0.1.1.16.8>.
[FCC-Review-2012-10] [FCC-Review-2012-10]
Federal Communications Commission, "Administration Topics Federal Communications Commission, "Administration Topics
Review", October 2012, <http://transition.fcc.gov/bureaus/ Review", October 2012, <http://transition.fcc.gov/bureaus/
skipping to change at page 103, line 25 skipping to change at page 104, line 5
[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. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC6953] Mancuso, A., Probasco, S., and B. Patil, "Protocol to [RFC6953] Mancuso, A., Probasco, S., and B. Patil, "Protocol to
Access White-Space (PAWS) Databases: Use Cases and Access White-Space (PAWS) Databases: Use Cases and
Requirements", RFC 6953, May 2013. Requirements", RFC 6953, May 2013.
[WGS-84] National Imagery and Mapping Agency, "Department of [WGS-84] National Imagery and Mapping Agency, "Department of
Defense World Geodetic System 1984, Its Definition and Defense World Geodetic System 1984, Its Definition and
Relationships with Local Geodetic Systems, NIMA TR8350.2 Relationships with Local Geodetic Systems, NIMA TR8350.2
Third Edition Amendment 1", January 2000, <http:// Third Edition Amendment 1", January 2000, <http://
earth-info.nga.mil/GandG/publications/tr8350.2/ earth-info.nga.mil/GandG/publications/tr8350.2/
tr8350_2.html>. tr8350_2.html>.
Appendix A. Changes / Author Notes. Appendix A. Changes / Author Notes.
Changes from 10:
o Ruleset Name change: ETSI-EN-301-598-1.0.9 and update reference to
PDF
o Add new ETSI parameter:
etsiEnSimultaneousChannelOperationRestriction
o Separate protocol requirements from regulatory requirements
Changes from 09: Changes from 09:
o Updated format of the IANA section o Updated format of the IANA section
Changes from 08: Changes from 08:
o Fix JSON typos. o Fix JSON typos.
o Added note that JSON schema is not intended to be formally o Added note that JSON schema is not intended to be formally
validated validated
o Finalize paws-iana-review@ietf.org as the email for updating the o Finalize paws-iana-review@ietf.org as the email for updating the
PAWS IANA registries PAWS IANA registries
o URLs to URIs o URLs to URIs
o Typo fixes o Typo fixes
Changes from 07: Changes from 07:
o Propose ruleset ID name for ETSI: ETSI-EN-301-598-1.0.0-draft o Propose ruleset ID name for ETSI: ETSI-EN-301-598-1.0.0-draft
o Change TBD email address to paws-iana-review@ietf.org for o Change TBD email address to paws-iana-review@ietf.org for
proposing changes to the PAWS IANA registries proposing changes to the PAWS IANA registries
o Moved discussion of required vCard properties to regulatory- o Moved discussion of required vCard properties to regulatory-
 End of changes. 151 change blocks. 
398 lines changed or deleted 454 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/