PAWS                                                        V. Chen, Ed.
Internet-Draft                                                    Google
Intended status: Standards Track                                  S. Das
Expires: October 26, 2014 January 31, 2015                 Applied Communication Sciences
                                                                  L. Zhu
                                                                  Huawei
                                                               J. Malyar
                iconectiv (formerly Telcordia Interconnection Solutions)
                                                               P. McCann
                                                                  Huawei
                                                          April 24,
                                                           July 30, 2014

            Protocol to Access White-Space (PAWS) Databases
                      draft-ietf-paws-protocol-12
                      draft-ietf-paws-protocol-13

Abstract

   Portions of the radio spectrum that are allocated to licensees are
   available for non-interfering use.  This available spectrum is called
   "White Space."  Allowing secondary users access to available spectrum
   "unlocks" existing spectrum to maximize its utilization and to
   provide opportunities for innovation, resulting in greater overall
   spectrum utilization.

   One approach to manage managing spectrum sharing uses databases to report
   spectrum availability to devices.  To achieve interoperability among
   multiple devices and databases, a standardized protocol must be
   defined and implemented.  This document defines such a protocol, the
   "Protocol to Access White Space (PAWS) Databases".

Status of this This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 26, 2014. January 31, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   5   4
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   5   4
     2.1.  Conventions Used in This Document . . . . . . . . . . . .   5   4
     2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   6   5
   3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Multi-ruleset Support . . . . . . . . . . . . . . . . . .   7
   4.  Protocol Functionalities  . . . . . . . . . . . . . . . . . .   8
     4.1.  Database Discovery  . . . . . . . . . . . . . . . . . . .   9
       4.1.1.  Listing Server
     4.2.  PAWS Version  . . . . . . . . . . . . . . . . . . . . . .  10
     4.2.
     4.3.  Initialization  . . . . . . . . . . . . . . . . . . . . .  10
       4.2.1.  11
       4.3.1.  INIT_REQ  . . . . . . . . . . . . . . . . . . . . . .  11
       4.2.2.
       4.3.2.  INIT_RESP . . . . . . . . . . . . . . . . . . . . . .  12
     4.3.
     4.4.  Device Registration . . . . . . . . . . . . . . . . . . .  12
       4.3.1.  13
       4.4.1.  REGISTRATION_REQ  . . . . . . . . . . . . . . . . . .  13
       4.3.2.  14
       4.4.2.  REGISTRATION_RESP . . . . . . . . . . . . . . . . . .  14
     4.4.  15
     4.5.  Available Spectrum Query  . . . . . . . . . . . . . . . .  15
       4.4.1.  16
       4.5.1.  AVAIL_SPECTRUM_REQ  . . . . . . . . . . . . . . . . .  17
       4.4.2.  19
       4.5.2.  AVAIL_SPECTRUM_RESP . . . . . . . . . . . . . . . . .  19
       4.4.3.  21
       4.5.3.  AVAIL_SPECTRUM_BATCH_REQ  . . . . . . . . . . . . . .  21
       4.4.4.  23
       4.5.4.  AVAIL_SPECTRUM_BATCH_RESP . . . . . . . . . . . . . .  23
       4.4.5.  26
       4.5.5.  SPECTRUM_USE_NOTIFY . . . . . . . . . . . . . . . . .  25
       4.4.6.  27
       4.5.6.  SPECTRUM_USE_RESP . . . . . . . . . . . . . . . . . .  26
     4.5.  28
     4.6.  Device Validation . . . . . . . . . . . . . . . . . . . .  26
       4.5.1.  29
       4.6.1.  DEV_VALID_REQ . . . . . . . . . . . . . . . . . . . .  28
       4.5.2.  30
       4.6.2.  DEV_VALID_RESP  . . . . . . . . . . . . . . . . . . .  28  31
   5.  Protocol Parameters . . . . . . . . . . . . . . . . . . . . .  29  31
     5.1.  GeoLocation . . . . . . . . . . . . . . . . . . . . . . .  29  31
     5.2.  DeviceDescriptor  . . . . . . . . . . . . . . . . . . . .  31  34
     5.3.  AntennaCharacteristics  . . . . . . . . . . . . . . . . .  32  35
     5.4.  DeviceCapabilities  . . . . . . . . . . . . . . . . . . .  33  36
     5.5.  DeviceOwner . . . . . . . . . . . . . . . . . . . . . . .  34  36
     5.6.  RulesetInfo . . . . . . . . . . . . . . . . . . . . . . .  34  37
     5.7.  DbUpdateSpec  . . . . . . . . . . . . . . . . . . . . . .  35  38
     5.8.  DatabaseSpec  . . . . . . . . . . . . . . . . . . . . . .  36  39
     5.9.  SpectrumSpec  . . . . . . . . . . . . . . . . . . . . . .  36  39
     5.10. SpectrumSchedule  . . . . . . . . . . . . . . . . . . . .  38  41
     5.11. Spectrum  . . . . . . . . . . . . . . . . . . . . . . . .  39  41
     5.12. SpectrumProfile . . . . . . . . . . . . . . . . . . . . .  42  45
     5.13. FrequencyRange  . . . . . . . . . . . . . . . . . . . . .  43  46
     5.14. EventTime . . . . . . . . . . . . . . . . . . . . . . . .  43  47
     5.15. GeoSpectrumSpec . . . . . . . . . . . . . . . . . . . . .  44  47
     5.16. DeviceValidity  . . . . . . . . . . . . . . . . . . . . .  45  48
     5.17. Error Element . . . . . . . . . . . . . . . . . . . . . .  45  49
       5.17.1.  OUTSIDE_COVERAGE Error . . . . . . . . . . . . . . .  47  51
       5.17.2.  DATABASE_CHANGE Error  . . . . . . . . . . . . . . . .  48  51
       5.17.3.  MISSING Error  . . . . . . . . . . . . . . . . . . . .  48  51
   6.  Message Encoding  . . . . . . . . . . . . . . . . . . . . . .  49  52
     6.1.  JSON-RPC Binding  . . . . . . . . . . . . . . . . . . . .  49
     6.2.  init  52
       6.1.1.  Method Names  . . . . . . . . . . . . . . . . . . . .  54
       6.1.2.  JSON Encoding of Data Models  . . .  50
       6.2.1.  INIT_REQ Parameters . . . . . . . . . .  54
     6.2.  Example Encoding: init Method . . . . . . .  51
       6.2.2.  INIT_RESP Parameters . . . . . . .  55
     6.3.  Example Encoding: getSpectrum Method  . . . . . . . . .  52
     6.3.  register Method .  56
     6.4.  Example Encoding: DeviceOwner vCard . . . . . . . . . . .  60
   7.  HTTPS Binding . . . . . . . . .  54
       6.3.1.  REGISTRATION_REQ Parameters . . . . . . . . . . . . .  54
       6.3.2.  REGISTRATION_RESP Parameters . .  60
   8.  Extensibility . . . . . . . . . .  55
     6.4.  getSpectrum Method . . . . . . . . . . . . . .  62
     8.1.  Defining Ruleset Identifiers  . . . . .  56
       6.4.1.  AVAIL_SPECTRUM_REQ Parameters . . . . . . . . .  62
     8.2.  Defining New Message Parameters . . .  57
       6.4.2.  AVAIL_SPECTRUM_RESP Parameters . . . . . . . . . .  62
     8.3.  Defining Additional Error Codes .  59
     6.5.  getSpectrumBatch Method . . . . . . . . . . . .  63
   9.  IANA Considerations . . . . .  63
       6.5.1.  AVAIL_SPECTRUM_BATCH_REQ Parameters . . . . . . . . .  64
       6.5.2.  AVAIL_SPECTRUM_BATCH_RESP Parameters . . . . . . .  63
     9.1.  PAWS Ruleset ID Registry  .  66
     6.6.  notifySpectrumUse Method . . . . . . . . . . . . . . .  64
       9.1.1.  Registration Template .  69
       6.6.1.  SPECTRUM_USE_NOTIFY Parameters . . . . . . . . . . .  69
       6.6.2.  SPECTRUM_USE_RESP Parameters . . . .  64
       9.1.2.  Initial Registry Contents . . . . . . . .  71
     6.7.  verifyDevice Method . . . . . .  65
     9.2.  PAWS Parameters Registry  . . . . . . . . . . . . .  72
       6.7.1.  DEV_VALID_REQ Parameters . . .  71
       9.2.1.  Registration Template . . . . . . . . . . .  72
       6.7.2.  DEV_VALID_RESP Parameters . . . . .  71
       9.2.2.  Initial Registry Contents . . . . . . . . .  73
     6.8.  Sub-message Schemas . . . . .  71
     9.3.  PAWS Error Code Registry  . . . . . . . . . . . . . .  75
       6.8.1.  GeoLocation . .  73
       9.3.1.  Registration Template . . . . . . . . . . . . . . . .  74
       9.3.2.  Initial Registry Contents . . .  75
       6.8.2.  DeviceDescriptor . . . . . . . . . . .  74
   10. Security Considerations . . . . . . .  77
       6.8.3.  AntennaCharacteristics . . . . . . . . . . . .  74
     10.1.  Assurance of Proper Database . . .  78
       6.8.4.  DeviceCapabilities  . . . . . . . . . . . .  76
     10.2.  Protection Against Modification  . . . . .  79
       6.8.5.  DeviceOwner . . . . . . .  76
     10.3.  Protection Against Eavesdropping . . . . . . . . . . . .  76
     10.4.  Client Authentication Considerations . .  80
       6.8.6.  RulesetInfo . . . . . . . .  76
   11. Contributors  . . . . . . . . . . . . .  81
       6.8.7.  DbUpdateSpec . . . . . . . . . . .  77
   12. Acknowledgments . . . . . . . . .  82
       6.8.8.  DatabaseSpec . . . . . . . . . . . . . .  77
   13. References  . . . . . .  83
       6.8.9.  Spectrum . . . . . . . . . . . . . . . . . . .  78
     13.1.  Normative References . . .  83
       6.8.10. FrequencyRange . . . . . . . . . . . . . . .  78
     13.2.  Informative References . . . .  85
       6.8.11. EventTime . . . . . . . . . . . . .  79
   Appendix A.  Database Listing Server Support  . . . . . . . . .  86
       6.8.12. SpectrumSchedule .  80
   Appendix B.  Changes / Author Notes.  . . . . . . . . . . . . . .  81
   Authors' Addresses  . . .  86
       6.8.13. SpectrumSpec . . . . . . . . . . . . . . . . . . . .  87
       6.8.14. GeoSpectrumSpec . . . . . . . . . . . . . . . . . . .  88
       6.8.15. DeviceValidity  . . . . . . . . . . . . . . . . . . .  89
       6.8.16. Additional Properties . . . . . . . . . . . . . . . .  90
   7.  HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . . .  90
   8.  Extensibility . . . . . . . . . . . . . . . . . . . . . . . .  92
     8.1.  Defining Ruleset Identifiers  . . . . . . . . . . . . . .  92
     8.2.  Defining New Message Parameters . . . . . . . . . . . . .  92
     8.3.  Defining Additional Error Codes . . . . . . . . . . . . .  93
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  93
     9.1.  PAWS Ruleset ID Registry  . . . . . . . . . . . . . . . .  94
       9.1.1.  Registration Template . . . . . . . . . . . . . . . .  94
       9.1.2.  Initial Registry Contents . . . . . . . . . . . . . .  94
     9.2.  PAWS Parameters Registry  . . . . . . . . . . . . . . . . 100
       9.2.1.  Registration Template . . . . . . . . . . . . . . . . 100
       9.2.2.  Initial Registry Contents . . . . . . . . . . . . . . 100
     9.3.  PAWS Error Code Registry  . . . . . . . . . . . . . . . . 102
       9.3.1.  Registration Template . . . . . . . . . . . . . . . . 102
       9.3.2.  Initial Registry Contents . . . . . . . . . . . . . . 103
   10. Security Considerations . . . . . . . . . . . . . . . . . . . 103
     10.1. Assurance of Proper Database  . . . . . . . . . . . . . . 104
     10.2. Protection Against Modification . . . . . . . . . . . . . 104
     10.3. Protection Against Eavesdropping  . . . . . . . . . . . . 104
     10.4. Client Authentication Considerations  . . . . . . . . . . 105
   11. Contributors  . . . . . . . . . . . . . . . . . . . . . . . . 105
   12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 106
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . . 106
     13.1. Normative References  . . . . . . . . . . . . . . . . . . 106
     13.2. Informative References  . . . . . . . . . . . . . . . . . 107
   Appendix A.  Changes / Author Notes.  . . . . . . . . . . . . . . 108
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 112

1.  Introduction

   This section provides some high level introductory material.  Readers
   are strongly encouraged to read Protocol to Access White-Space (PAWS)
   Databases: Use Cases and Requirements [RFC6953] for use cases,
   requirements, and additional background.

   A geospatial database can track available spectrum (in accordance
   with the rules of one or more regulatory domains) and make this
   information available to devices.  This approach shifts the
   complexity of spectrum-policy conformance out of the device and into
   the Database.  This approach also simplifies adoption of policy
   changes, limiting updates to a handful of databases, rather than
   numerous devices.  It opens the door for innovations in spectrum
   management that can incorporate a variety of parameters, including
   user location and time.  In the future, it also can include other
   parameters, such as user priority, time, signal type and power,
   spectrum supply and demand, payment or micro-auction bidding, and
   more.

   In providing this service, a database records and updates information
   necessary to protect primary users -- for example, this information
   may include parameters such as a fixed transmitter's call sign, its
   geo-location, antenna height, power, and periods of operation.  The
   rules that the Database must follow, including its schedule for
   obtaining and updating protection information, protection rules, and
   information reported to devices, vary according to regulatory domain.
   Such variations, however, should be handled by each database, and
   exposure to the variations by devices should be minimized.

   This specification defines an extensible protocol to obtain available
   spectrum from a geospatial database by a device with geo-location
   capability.  It enables a device to operate in any regulatory domain
   that implements the same protocol and in which the device is
   authorized to operate.  The document describes the use of HTTP/TLS as
   transport for the protocol.

2.  Conventions and Terminology

2.1.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in Key words for use in
   RFCs to Indicate Requirement Levels [RFC2119].

2.2.  Terminology

   Database or Spectrum Database:  A database is an entity that contains
      current information about available spectrum at a given location
      and time, as well as other types of information related to
      spectrum availability and usage.
   Device ID  An identifier for a device.
   EIRP:  Effective isotropically radiated power
   ETSI:  European Telecommunications Standards Institute
   FCC:  Federal Communications Commission
   Listing server:  A server that provides the URIs for one or more
      Spectrum Databases.  A regulator, for example, may operate a
      Database Listing Server to publish the list of authorized Spectrum
      Databases for its regulatory domain.
   Master Device:  A device that queries the database, on its own behalf
      and/or on behalf of a slave device, to obtain available spectrum
      information.
   Regulatory Domain:  A location where certain rules apply to the use
      of white space spectrum, including the operation of databases and
      devices involved in its use.  A regulatory domain is normally
      defined by a unit of government for a particular country, but the
      PAWS protocol is agnostic as to how a regulatory domain is
      constructed.
   Ruleset:  An IANA-registered set of rules that governs operations of
      white space devices and Spectrum Databases.  A regulatory
      authority can define and register its own rulesets, or can use
      rulesets that have been previously registered by others.
   Slave Device:  A device that queries the database through a master
      device.

3.  Protocol Overview

   A Master Device uses the PAWS protocol to obtain a schedule of
   available spectrum at its location.  The security necessary to ensure
   the accuracy, privacy, and confidentiality of the Device's location
   is described in the Security Considerations (Section 10).  This
   document assumes that the Master Device and the Database are
   connected to the Internet.

   A typical sequence of PAWS operations is outlined as follows.  See
   Protocol Functionalities (Section 4) and Protocol Parameters
   (Section 5) for details:

   1.   The Master Device obtains (statically or dynamically) the URI
        for a Database appropriate for its location to send subsequent
        PAWS messages.

   2.   The Master Device establishes an HTTPS session with the
        Database.
   3.   The Master Device optionally sends an initialization message to
        the Database to exchange capabilities.
   4.   If the Database receives an initialization message, it responds
        with a message in the body of the HTTP response.
   5.   The Database may require the Master Device to be registered
        before providing service.
   6.   The Master Device sends an available-spectrum request message to
        the Database.
   7.   The Master Device may verify with the Database that the Slave
        Device is valid.
   8.   The Database responds with an available-spectrum response
        message in the body of the HTTP response.
   9.   The Master Device may send a spectrum-usage notification message
        to the Database.
   10.  If the Database receives a spectrum-usage notification message,
        it responds by sending the Master Device a spectrum-usage
        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

   For a Master Device that supports multiple rulesets and operates with
   multiple databases, the PAWS protocol supports the following sequence
   of operations for each request by the Master Device:

   1.  The Master Device includes in its request its location and
       optionally includes the identifier of all the rulesets it
       supports and any parameter values it might need for the request
   2.  The Database uses the device location and also may use the
       ruleset list to determine its response, for example, to select
       the list of required parameters
   3.  If required parameters are missing from the request, the Database
       responds with an error and a list of names of the missing
       parameters
   4.  The Master Device makes the request again, adding the missing
       parameter values
   5.  The Database responds to the request, including the identifier of
       the applicable ruleset
   6.  The Master Device uses the indicated ruleset to determine how to
       interpret the Database response

   NOTE: Regulatory rules contain many device-only requirements that
   govern device behavior, independent of any database rules.  These
   requirements may be complex and involve device behavior that are not
   easily parameterized.  The ruleset-id parameter provides a mechanism
   for the Database to inform the Master Device of the applicable
   ruleset without having to express device-side behavior within the
   protocol.  The ruleset identifier is a string value that contains the
   name of the regulatory body that established the rules and version
   information, such as "FccTvBandWhiteSpace-2010".

   By separating the regulatory "authority" from the "ruleset-id", it
   allows the protocol to support multiple regulatory authorities that
   use the same device-side ruleset.  It also allows support for a
   single authority to define multiple rulesets.

4.  Protocol Functionalities

   The PAWS protocol consists of several components:

   o  Database Discovery (Section 4.1) MUST be supported by the Master
      Device
   o  Initialization (Section 4.2) MAY be used by the Master Device and
      MUST be implemented by the Database.
   o  Device Registration (Section 4.3) MAY be used by the Master Device
      and MAY be implemented by the Database, either as a separate
      component or as part of the Available Spectrum Query (Section 4.4)
      component.
   o  Available Spectrum Query (Section 4.4) MUST be supported by Master
      Device and the Database.
   o  Spectrum Use Notify (Section 4.4.5) MAY be used by the Master
      Device and the Database.
   o  Device Validation (Section 4.5) MAY be used by the Master Device
      and the Database.

   Note: Some regulatory domains mandate the use of notification and
   device validation.  In such cases, obviously, their implementation
   and use would be necessary.

   This section describes the protocol components and their messages.
   Protocol Parameters (Section 5) contains a more thorough discussion
   of the parameters that comprise the PAWS request and response
   messages.  Message Encoding (Section 6) provides details of the
   message encodings.  HTTPS Binding (Section 7) describes the use of
   HTTPS (HTTP Over TLS [RFC2818]) for transporting PAWS messages and
   optional device authentication.

   The parameter tables in this section and Protocol Parameters
   (Section 5) are for reference and contain the name of each parameter,
   the data type of each parameter, and whether the existence of the
   parameter is required for the protocol transaction in question.  The
   data types are either defined in Protocol Parameters (Section 5) or
   are part of the base data types specified in The JavaScript Object
   Notation (JSON) Data Interchange Format [RFC7159].  See Protocol
   Parameters (Section 5) and Message Encoding (Section 6) for more
   detail on data types and encodings.

4.1.  Database Discovery

   Preconfiguration

   The Master Device can be provisioned statically with the URI of one
   or more Databases.  For example, in a particular regulatory domain,
   there may be a number of certified databases that any device
   operating in that domain is permitted to connect to, and those URIs
   can be provisioned in the device.  Alternatively, a Master Device can
   be provisioned statically with the URI of a Database Listing Server,
   from which it can retrieve URIs of available Databases.

   Configuration Update

   To adapt to changes in the list of certified or approved databases,
   the Device needs to update its preconfigured list of databases.  If
   the Master Device retrieves its preconfigured list of databases from
   a listing server, the device SHOULD check the listing server
   periodically to update its list.

   A Database MAY indicate that its URI will be changing by including
   the URI of one or more alternate databases (See DbUpdateSpec
   (Section 5.7)) in its responses to a Device.  Before a Database
   ceases operation, for example, it MUST include DbUpdateSpec in its
   responses to notify Devices.  A Device will update its preconfigured
   list of databases to replace (only) its entry for the responding
   Database with the URIs of the alternate databases; the list of
   alternate databases does not affect any other entries.

   Error Handling

   The Device SHOULD select another database from its list of
   preconfigured databases if:

   o  The selected database is unreachable or does not respond.
   o  The selected database returns an UNSUPPORTED error (see Error
      Codes (Section 5.17)), which may indicate that the database does
      not support the regulatory domain where the device is located.

   If a suitable database cannot be contacted, the Device MUST treat
   this as equivalent to a response indicating no available spectrum.

   If the Device is already operating when it fails to contact a
   suitable database, the spectrum the Device is currently using can be
   used for as long as the spectrum data is valid, but after that period
   of time, the Device will no longer have valid spectrum to use.  Some
   regulatory domains will have specific rules regarding how long the
   spectrum data remains valid in these cases.

4.1.1.  Listing Server

   The use of a Database Listing Server allows the Device to determine
   the URIs of available databases.  When a Listing Server is used, the
   Device can save the database list and SHOULD contact the Database
   Listing Server periodically to update its list.  The time between
   such updates MUST be no longer than one week, although the update
   interval can be shorter (for example, when required by the applicable
   regulatory domain).

   If the Device is unable to contact the Database Listing Server to
   obtain the list of databases for the domain, the Device MUST treat
   this as equivalent to not having available spectrum.

   The Database Listing request procedure is depicted in Figure 1.

   o  LISTING_REQ is the database-listing request message
   o  LISTING_RESP is the database-listing response message

                  +---------------+    +-------------------+
                  | Master Device |    |  Listing Server   |
                  +---------------+    +-------------------+
                        |                     |
                        |    LISTING_REQ      |
                        |-------------------->|
                        |                     |
                        |    LISTING_RESP     |
                        |<--------------------|
                        |                     |

                                 Figure 1

   TBD Define message format

4.2.  Initialization

   A Master Device SHOULD use the initialization procedure to exchange
   capability information with the Database whenever the Master Device
   powers up or initiates communication with the Database.  The
   initialization response informs the Master Device of specific
   parameterized-rule values, such as threshold distances and time
   periods beyond which the Device must update its available-spectrum
   data (see RuleSetInfo (Section 5.6)).  When a 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 implementations or
   rulesets that require the extra handshake.

   The Initialization request procedure is depicted in Figure 2.
   o  INIT_REQ (Section 4.2.1) is the initialization request message
   o  INIT_RESP (Section 4.2.2) is the initialization response message

                  +---------------+    +-------------------+
                  | Master Device |    | Spectrum Database |
                  +---------------+    +-------------------+
                        |                     |
                        |    INIT_REQ         |
                        |-------------------->|
                        |                     |
                        |    INIT_RESP        |
                        |<--------------------|
                        |                     |

                                 Figure 2

4.2.1.  INIT_REQ

   The initialization request message allows the Master Device to
   initiate exchange of capabilities with the Database.

   +---------------------------------------+
   |INIT_REQ                               |
   +----------------------------+----------|
   |deviceDesc:DeviceDescriptor | required |
   |location:GeoLocation        | required |
   |.......................................|
   |*other:any                  | optional |
   +----------------------------+----------+

   Parameters:

   deviceDesc:  The DeviceDescriptor (Section 5.2) for the Device is
      REQUIRED.  If the Database does not support the device or any of
      the rulesets specified in the device descriptor, it MUST return an
      error with the UNSUPPORTED (Table 1) code in the error response.
      If the device descriptor does not contain any ruleset IDs, the
      Database SHOULD return a list of RulesetInfo (Section 5.6)
      parameters for each ruleset it supports at the specified location.

   location:  The GeoLocation (Section 5.1) for the Device is REQUIRED.
   other:  The Master Device MAY specify additional handshake parameters
      in the INIT_REQ message.  The Database MUST ignore all parameters
      it does not understand.  To simplify its initialization logic, a
      Master Device that supports multiple Databases and rulesets can
      include the union of all required parameters for all its supported
      rulesets.  Consult the PAWS Parameters Registry (Section 9.2) for
      possible additional parameters.

4.2.2.  INIT_RESP

   The initialization response message communicates database parameters
   to the requesting device.

   +---------------------------------------+
   |INIT_RESP                              |
   +----------------------------+----------+   1..* +-------------+
   |rulesetInfos:list           | required |------->| RulesetInfo |
   |databaseChange:DbUpdateSpec | optional |        +-------------+
   |.......................................|
   |*other:any                  | optional |
   +----------------------------+----------+

   Parameters:

   rulesetInfos:  A list of RulesetInfo (Section 5.6) parameters MUST be
      included in the response.  Each RulesetInfo parameter corresponds
      to a ruleset supported by the Database and is applicable to the
      location specified in the INIT_REQ (Section 4.2.1) message.  If
      the Device included a list of ruleset IDs in the DeviceDescriptor
      parameter of its INIT_REQ message, each RulesetInfo parameter in
      the response MUST match one of the specified ruleset IDs.
   databaseChange:  The Database MAY include a DbUpdateSpec
      (Section 5.7) parameter to notify the Master Device of a change to
      the Database URI, providing one or more alternate database URIs.
      The Device needs to use the information to update its list of
      preconfigured databases to replace (only) its entry for the
      responding database with the list of alternate URIs.
   other:  The Database MAY include additional handshake parameters in
      the INIT_RESP (Section 4.2.2) message.  The Master Device MUST
      ignore all parameters it does not understand.  Consult the PAWS
      Parameters Registry (Section 9.2) for possible additional
      parameters.

4.3.  Device Registration

   Some rulesets require a Master Device to send its registration
   information to the Database in order to establish certain operational
   parameters.  FCC rules, for example, require that a 'Fixed Device'
   register its owner and operator contact information, its device
   identifier, its location, and its antenna height.

   The Database MAY support device registration as a separate Device
   Registration component, or as part of the Spectrum Availability
   component.  If the Database does not support a separate Device
   Registration request, it MUST return an error with the UNIMPLEMENTED
   (Table 1) code in the error-response message.

   The Device Registration request procedure is depicted in Figure 3.
   o  REGISTRATION_REQ (Section 4.3.1) is the device-registration
      request message
   o  REGISTRATION_RESP (Section 4.3.2) is the device-registration
      response message

                +---------------+        +-------------------+
                | Master Device |        | Spectrum Database |
                +---------------+        +-------------------+
                      |                         |
                      |    REGISTRATION_REQ     |
                      |------------------------>|
                      |                         |
                      |    REGISTRATION_RESP    |
                      |<------------------------|
                      |                         |

                                 Figure 3

4.3.1.  REGISTRATION_REQ

   The registration request message contains the required registration
   parameters.  A parameter marked as optional may be required by some
   rulesets.

   +-------------------------------------------+
   |REGISTRATION_REQ                           |
   +-------------------------------+-----------+
   |deviceDesc:DeviceDescriptor    | required  |
   |location:GeoLocation           | required  |
   |deviceOwner:DeviceOwner        | required  |
   |antenna:AntennaCharacteristics | optional  |
   |...........................................|
   |*other:any                     | optional  |
   +-------------------------------+-----------+

   Parameters:

   deviceDesc:  The DeviceDescriptor (Section 5.2) for the Master Device
      is REQUIRED.  The ruleset IDs included in this parameter value
      indicate the rulesets for which the Device wishes to register.  If
      the registration information is unacceptable for all of the
      rulesets supported by the Database, the Database MUST return an
      error message with an appropriate error code.  Otherwise, the
      Database MUST return, in its response, a list of RulesetInfo
      (Section 5.6) parameters for all rulesets for which device
      registration was accepted.
   location:  The GeoLocation (Section 5.1) for the Device is REQUIRED.
   deviceOwner:  The DeviceOwner (Section 5.5) information is REQUIRED.
   antenna:  The AntennaCharacteristics (Section 5.3) is OPTIONAL.
   other:  Rulesets and database implementations may require additional
      registration parameters.  To simplify its registration logic, the
      Master Device MAY send a union of the registration information
      required by all supported rulesets.  The Database MUST ignore all
      parameters it does not understand.  Consult the PAWS Parameters
      Registry (Section 9.2) for possible additional parameters.

4.3.2.  REGISTRATION_RESP

   The registration response message acknowledges successful
   registration by including a RulesetInfo message for each ruleset in
   which the registration is accepted.  If the Database accepts the
   registration for none of the rulesets it supports, the Database MUST
   return the NOT_REGISTERED error (See Error Codes (Section 5.17)).

   +---------------------------------------+
   |REGISTRATION_RESP                      |
   +----------------------------+----------+   1..* +-------------+
   |rulesetInfos:list           | required |------->| RulesetInfo |
   |databaseChange:DbUpdateSpec | optional |        +-------------+
   |............................|..........|
   |*other:any                  | optional |
   +----------------------------+----------+

   Parameters:

   rulesetInfos:  A list of RulesetInfo (Section 5.6) parameters MUST be
      included in the response.  Each entry corresponds to a ruleset for
      which the registration was accepted.  The list MUST contain at
      least one entry.
   databaseChange:  The Database MAY include a DbUpdateSpec
      (Section 5.7) parameter to notify the Master Device of a change to
      the Database URI, providing one or more alternate database URIs.
      The Device needs to use the information to update its list of
      preconfigured databases to replace (only) its entry for the
      responding database with the list of alternate URIs.

   other:  Database implementations MAY return additional parameters in
      the registration response.  The Master Device MUST ignore any
      parameters it does not understand.  Consult the PAWS Parameters
      Registry (Section 9.2) for possible additional parameters.

4.4.  Available Spectrum Query

   To obtain the available spectrum from the Database, a Master Device
   sends a request that contains its geo-location and any parameters
   required by the ruleset (such as device identifier, capabilities, and
   characteristics).  The Database returns a response that describes
   which frequencies are available, at what permissible operating power
   levels, and a schedule of when they are available.

   The Available Spectrum Query procedure is depicted in Figure 4.

   o  AVAIL_SPECTRUM_REQ (Section 4.4.1) is the available-spectrum
      request message.
   o  AVAIL_SPECTRUM_RESP (Section 4.4.2) is the available-spectrum
      response message.
   o  AVAIL_SPECTRUM_BATCH_REQ (Section 4.4.3) is an OPTIONAL batch
      version of the available-spectrum request message that allows
      multiple locations to be specified in the request.
   o  AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4) is the response message
      for the batch version of the available-spectrum request that
      contains available spectrum for each location in the request.
   o  SPECTRUM_USE_NOTIFY (Section 4.4.5) is the spectrum-usage
      notification message.
   o  SPECTRUM_USE_RESP (Section 4.4.6) is the spectrum-usage
      acknowledgment message.

               +---------------+          +-------------------+
               | Master Device |          | Spectrum Database |
               +---------------+          +-------------------+
                     |                            |
                     |    AVAIL_SPECTRUM_REQ      |
                     | (AVAIL_SPECTRUM_BATCH_REQ) |
                     |--------------------------->|
                     |                            |
                     |    AVAIL_SPECTRUM_RESP     |
                     | (AVAIL_SPECTRUM_BATCH_RESP)|
                     |<---------------------------|
                     |                            |
                     |   (SPECTRUM_USE_NOTIFY)    |
                     |--------------------------->|
                     |                            |
                     |    (SPECTRUM_USE_RESP)     |
                     |<---------------------------|
                     |                            |

                                 Figure 4

   1.  First, the Master Device sends an available-spectrum request
       message to the Database.
   2.  The Database MUST respond with an error using the NOT_REGISTERED
       (Table 1) code if:
       *  registration information is required, and
       *  the request does not include registration information, and
       *  the Device has not previously registered with the Database
   3.  If the location specified in the request is outside the
       regulatory domain supported by the Database, the Database MUST
       respond with an OUTSIDE_COVERAGE (Table 1) error.  If some
       locations within a batch request are outside the regulatory
       domain supported by the Database, the Database MAY return an OK
       response with available spectrum for only the valid locations;
       otherwise, if all locations within a batch request are outside
       the regulatory domain, the Database MUST respond with an
       OUTSIDE_COVERAGE error.
   4.  The Database MAY perform other validation of the request, (e.g.,
       checking for missing required parameters, authorizations).  If
       validation fails, the Database returns an appropriate error code
       (Table 1).  If the request is missing required parameters, the
       Database MUST respond with a MISSING (Table 1) error and SHOULD
       include a list of the missing parameters.
   5.  If the request is valid, the Database responds with an available-
       spectrum response message.  If the ruleset requires that devices
       must report anticipated spectrum usage, the Database will
       indicate so in the response message.

   6.  If the available-spectrum response indicates that the Master
       Device must send a spectrum-usage notification message, the
       Master Device sends the notification message to the Database.
   7.  If the Database receives a spectrum-usage notification message,
       it MUST send a spectrum-usage acknowledgment message to the
       Master Device.

   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.  The device identifier, capabilities, and characteristics
   communicated in the AVAIL_SPECTRUM_REQ message MUST be those of the
   Slave Device, but the location MUST be that of the Master Device.
   Although the communication and protocol between the Slave Device and
   Master Device is outside the scope of this document (represented as
   dotted lines), the expected message sequence is shown in Figure 5.

      +------------+     +---------------+      +-------------------+
      |Slave Device|     | Master Device |      | Spectrum Database |
      +------------+     +---------------+      +-------------------+
          |                 |                           |
          | AVAIL_SPEC_REQ  |                           |
          |................>|                           |
          |                 |                           |
          |                 |    AVAIL_SPECTRUM_REQ     |
          |                 |-------------------------->|
          |                 |                           |
          |                 |    AVAIL_SPECTRUM_RESP    |
          |                 |<--------------------------|
          | AVAIL_SPEC_RESP |                           |
          |<................|                           |
          |                 |                           |
          | (SPECTRUM_USE)  |                           |
          |................>|   (SPECTRUM_USE_NOTIFY)   |
          |                 |-------------------------->|
          |                 |                           |
          |                 |    (SPECTRUM_USE_RESP)    |
          |                 |<--------------------------|
          |                 |                           |

                                 Figure 5

4.4.1.  AVAIL_SPECTRUM_REQ

   The request message for the Available Spectrum Query protocol MUST
   include a geo-location.  Rulesets may mandate that it be the Device's
   current location or allow it to be an anticipated location.  A
   parameter marked as optional may be required by

1.  Introduction

   This section provides some rulesets.

   +----------------------------------------------------+
   |AVAIL_SPECTRUM_REQ                                  |
   +----------------------------------+-----------------+
   |deviceDesc:DeviceDescriptor       | see description |
   |location:GeoLocation              | see description |
   |owner:DeviceOwner                 | optional        |
   |antenna:AntennaCharacteristics    | optional        |
   |capabilities:DeviceCapabilities   | optional        |
   |masterDeviceDesc:DeviceDescriptor | optional        |
   |masterDeviceLocation:GeoLocation  | optional        |
   |requestType:string                | optional        |
   |..................................|.................|
   |*other:any                        | optional        |
   +----------------------------------+-----------------+

   Parameters:

   deviceDesc:  The DeviceDescriptor (Section 5.2) for the Device
      requesting available spectrum.  When the request is made by a
      Master Device on its own behalf, the descriptor is that of the
      Master Device and it is REQUIRED.  When the request is made on
      behalf of a Slave Device, the descriptor is that of the Slave
      Device, high level introductory material.  Readers
   are strongly encouraged to read "Protocol to Access White-Space
   (PAWS) Databases: Use Cases and it is REQUIRED if the "requestType" parameter is not
      specified.  The deviceDesc parameter may be OPTIONAL for some
      values of requestType.
   location:  The GeoLocation (Section 5.1) Requirements" [RFC6953] for the Device requesting use
   cases, requirements, and additional background.

   A geospatial database can track available spectrum.  The location SHOULD be spectrum (in accordance
   with the current location rules of the Device, but one or more precisely, the location of the radiation
      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 regulatory domains) and it is REQUIRED.  When the request is made by the
      Master Device on behalf of a Slave Device, the location is that make this
   information available to devices.  This approach shifts the
   complexity of spectrum-policy conformance out of the Slave Device device and it is OPTIONAL (see also into
   the
      masterDeviceLocation parameter).  The location may be an
      anticipated position database.  This approach also simplifies adoption of the Device policy
   changes, limiting updates to support mobile devices, but
      its use depends on the ruleset.  If the location specifies a
      region, handful of databases, rather than a point,
   numerous devices.  It opens the Database MAY return an error with door for innovations in spectrum
   management that can incorporate a variety of parameters, including
   user location and time.  In the UNIMPLEMENTED (Table 1) code, if future, it does not support query by
      region.
   owner:  The DeviceOwner (Section 5.5) information MAY be included to
      register the Device with the Database.  This enables the Device to
      register also can include other
   parameters, such as user priority, time, signal type and get spectrum-availability information in power,
   spectrum supply and demand, payment or micro-auction bidding, and
   more.

   In providing this service, a single
      request.  Some rulesets mandate registration database records and updates information
   necessary to protect primary users -- for specific device
      types.

   antenna:  The AntennaCharacteristics (Section 5.3) is OPTIONAL.
   capabilities:  The Master Device MAY example, this information
   may include its DeviceCapabilities
      (Section 5.4) to limit the available-spectrum response to the
      spectrum that is compatible with its capabilities.  The Database
      SHOULD NOT return spectrum that is not compatible with the
      specified capabilities.
   masterDeviceDesc:  When the request is made by the Master Device on
      behalf of a Slave Device, the Master Device MAY provide its own
      descriptor.
   masterDeviceLocation:  When the request is made by the Master Device
      on behalf of parameters such as a Slave Device, the Master Device MAY provide fixed transmitter's call sign, its own
      GeoLocation (Section 5.1).
   requestType:
   geolocation, antenna height, power, and periods of operation.  The request type is an OPTIONAL parameter
   rules that may be
      used to modify the request, but database is required to follow, including its use depends on the applicable
      ruleset.  The request type may be used, schedule
   for example, obtaining and updating protection information, protection rules,
   and information reported to indicate a
      the response devices, vary according to regulatory
   domain.  Such variations, however, should include generic Slave Device parameters
      without having be handled by each
   database, and hidden from devices to specify the device descriptor for maximum extent possible.

   This specification defines an extensible protocol, built on top of
   HTTP and TLS, to obtain available spectrum from a specific
      device.  When the requestType parameter is missing, the request is
      for geospatial database
   by a specific device (Master or Slave), so with geolocation capability.  It enables a device to
   operate in a regulatory domain that implements this protocol and
   within which the deviceDesc
      parameter device is REQUIRED.  The length of the value MUST NOT exceed 64
      octets.  See IANA Ruleset Registry, Initial Registry Contents
      (Section 9.1.2) for ruleset specifics.
   other:  Rulesets authorized to operate.

2.  Conventions and database implementations may require additional
      request parameters.  The Database MUST ignore all parameters it
      does not understand.  Consult the PAWS Parameters Registry
      (Section 9.2) for possible additional parameters.

4.4.2.  AVAIL_SPECTRUM_RESP Terminology

2.1.  Conventions Used in This Document

   The response message key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in "Key words for the Available use in
   RFCs to Indicate Requirement Levels" [RFC2119].

2.2.  Terminology

   Database or Spectrum Query Database:  A database is an entity that contains one or
   more SpectrumSpec (Section 5.9) elements, one for each ruleset
   supported
      current information about available spectrum at the location specified in the corresponding
   AVAIL_SPECTRUM_REQ (Section 4.4.1) request.  Each SpectrumSpec
   element contains a list given location
      and time, as well as other types of information related to
      spectrum availability and usage.

   Device ID  An identifier for a device.

   ETSI:  European Telecommunications Standards Institute

   FCC:  Federal Communications Commission

   Listing server:  A server that provides the URIs for one or more spectrum schedules,
   representing permissible power levels over time:
   o  Within each list of schedules, event-time intervals MUST be
      disjoint and MUST be sorted in increasing time.
   o
      Spectrum Databases.  A gap in regulator, for example, may operate a
      Database Listing Server to publish the time schedule means no spectrum is available list of authorized Spectrum
      Databases for its regulatory domain.

   Master Device:  A device that
      time interval.

   +---------------------------------------+
   |AVAIL_SPECTRUM_RESP                    |
   +----------------------------+----------+
   |timestamp:string            | required |
   |deviceDesc:DeviceDescriptor | required |
   |spectrumSpecs:list          | required |-------+
   |............................|..........|       |
   |databaseChange:DbUpdateSpec | optional |       |
   |*other:any                  | optional |       |
   +----------------------------+----------+       | 1..*
                                                   V
                              +-----------------------------------+
                              |SpectrumSpec                       |
                              +------------------------+----------+
                              |rulesetInfo:RulesetInfo | required |
                              |spectrumSchedules:list  | required |-+
                              |timeRange:EventTime     | optional | |
                              |frequencyRanges:list    | optional | |
                              |needsSpectrumReport:bool| optional | |
                              |maxTotalBwHz:float      | optional | |
                              |maxContiguousBwHz:float | optional | |
                              +------------------------+----------+ |
                                               +--------------------+
                                               | 1..*
                                               V
                                  +-------------------------------+
                                  |SpectrumSchedule               |
                                  +--------------------+----------+
                                  |eventTime:EventTime | required |
                                  |spectra:list        | required |
                                  +--------------------+----------+

   Parameters:

   timestamp:  Timestamp queries the database, on its own behalf
      and/or on behalf of a slave device, to obtain available spectrum
      information.

   Regulatory Domain:  A location where certain rules apply to the response use
      of white space spectrum, including the form, YYYY-MM-
      DDThh:mm:ssZ, as defined by Date operation of databases and Time on the Internet:
      Timestamps [RFC3339].  This can be used
      devices involved in its use.  A regulatory domain is normally
      defined by the Device as a
      reference unit of government for a particular country, but PAWS
      is agnostic as to how a regulatory domain is constructed.

   Ruleset:  A ruleset represents a set of rules that governs the start
      operation of white space devices and stop times in the spectrum schedules.
   deviceDesc:  The Spectrum Databases.  A
      regulatory authority can define its own set of rules or adopt an
      existing ruleset.  When a Database MUST include the DeviceDescriptor
      (Section 5.2) specified in or device is said to "support a
      ruleset", it means that it contains out-of-band knowledge of the AVAIL_SPECTRUM_REQ message.
   spectrumSpecs:  The SpectrumSpec
      rules and that its hardware and software implementations conform
      to those rules.

   Ruleset Identifier:  A ruleset can be identified by an IANA-
      registered identifier (see PAWS Ruleset ID Registry
      (Section 5.9) list MUST include at
      least one entry.  Each entry contains 9.1)).  When a Database or device indicates it supports a
      ruleset identifier, it means that it conforms to the schedules of available
      spectrum for rules
      associated with that identifier.  A regulatory authority can
      define and register its own ruleset identifiers, or it can use a
      previously registered identifier if it adopts an existing ruleset.  The Database MAY return more than one
      SpectrumSpec

   Slave Device:  A device that queries the database through a master
      device.

3.  Protocol Overview

   A Master Device uses PAWS to represent obtain a schedule of available spectrum for multiple rulesets
   at the specified its location.

   databaseChange:  The Database MAY include a DbUpdateSpec
      (Section 5.7) parameter security necessary to notify ensure the accuracy,
   privacy, and confidentiality of the device's location is described in
   the Security Considerations (Section 10).  This document assumes that
   the Master Device and the Database are connected to the Internet.

   A typical sequence of PAWS operations is outlined as follows.  See
   Protocol Functionalities (Section 4) and Protocol Parameters
   (Section 5) for details:

   1.   The Master Device obtains (statically or dynamically) the URI
        for a change Database appropriate for its location, to which to send
        subsequent PAWS messages.

   2.   The Master Device establishes an HTTPS session with the
      Database URI, providing one or more alternate database URIs.
        Database.

   3.   The Master Device needs optionally sends an initialization message to use
        the information to update its list of
      preconfigured databases Database to replace (only) its entry for exchange capabilities.

   4.   If the
      responding database Database receives an initialization message, it responds
        with an initialization-response message in the list body of alternate URIs.
   other:  Database implementations MAY return additional parameters in the HTTP
        response.

   5.   The Database may require the Master Device MUST ignore any parameters that it does
      not understand.  Consult to be registered
        before providing service.

   6.   The Master Device sends an available-spectrum request message to
        the PAWS Parameters Registry
      (Section 9.2) for possible additional parameters and requirements
      they place Database.  The message may be on the Device.

4.4.2.1.  Update Requirements

   When the stop time specified in the schedule has been reached, the
   Device:
   o  MUST obtain behalf of a new spectrum-availability schedule, either by using
      the next one in Slave Device
        that made a request to the list (if provided) or making another Available
      Spectrum Query (Section 4.4).
   o Master Device.

   7.   If the Master Device is unable to contact the Database to obtain making a new
      schedule, it MUST treat this as equivalent to request on behalf of a response Slave
        Device, the Master Device may verify with no
      available spectrum.

   Some rulesets also mandate the Database that a the
        Slave Device must obtain a new specturm-
   availability schedule if is valid.

   8.   The Database responds with an available-spectrum response
        message in the body of the HTTP response.

   9.   The Master Device moves beyond may send a threshold distance
   (established by spectrum-usage notification message
        to the ruleset) away from Database.  The notification is purely informational.

   10.  If the actual location and all
   anticipated location(s) Database receives a spectrum-usage notification message,
        it reported in previous AVAIL_SPECTRUM_REQ or
   AVAIL_SPECTRUM_BATCH_REQ requests (see "maxLocationChange" in
   RulesetInfo (Section 5.6)).  If responds by sending the Master Device a spectrum-usage
        acknowledgement message.  Since the notification is unable purely
        informational, the Master Device does not need to contact process the
        Database to obtain a new schedule, it MUST treat this response.

   Different regulatory domains may impose particular requirements, such
   as equivalent requiring Master Devices to a response register with no available spectrum.

   NOTE: The ruleset determines required device behavior when the Database, performing
   Slave Device verification, and sending spectrum
   is no longer available.  The ruleset also governs whether usage notifications.

3.1.  Multi-ruleset Support

   For a device
   may Master Device that supports multiple rulesets and operates with
   multiple databases, PAWS supports the following sequence of
   operations for each request by the Master Device:

   1.  The Master Device includes in its request its location and
       optionally includes the identifier of all the rulesets it
       supports and use spectrum at anticipated locations beyond any parameter values it might need for the
   threshold distance from its current location.

4.4.3.  AVAIL_SPECTRUM_BATCH_REQ request

   2.  The Database MAY support uses the batch request that allows multiple
   locations device location and also may use the
       ruleset list to be specified.  This enables a portable Master Device, determine its response, for example, to get available spectrum for a sequence select
       the list of anticipated
   locations using a single request.  The Database interprets each
   location in required parameters

   3.  If required parameters are missing from the batch request as if it were request, the Database
       responds with an independent request error and returns results consistent with multiple individual
   AVAIL_SPECTRUM_REQ (Section 4.4.1) requests, but returns these
   results in a batched response (Section 4.4.4).  The request message
   for list of names of the batch Available Spectrum Query protocol MUST include at least
   one GeoLocation (Section 5.1).  If missing
       parameters

   4.  The Master Device makes the Database does not support
   batch requests, it MUST return an UNIMPLEMENTED (Table 1) error.

   NOTE: Whether anticipated locations are allowed depends on request again, adding the
   specified ruleset.  A missing
       parameter marked as optional may be required by
   some rulesets.

   +---------------------------------------------------+
   |AVAIL_SPECTRUM_BATCH_REQ                           |
   +---------------------------------+-----------------+
   |deviceDesc:DeviceDescriptor      | see description |
   |locations:list                   | required        |--+
   |owner:DeviceOwner                | optional        |  |
   |antenna:AntennaCharacteristics   | optional        |  |
   |capabilities:DeviceCapabilities  | optional        |  |
   |masterDeviceDesc:DeviceDescriptor| optional        |  |
   |masterDeviceLocation:GeoLocation | optional        |  |
   |requestType:string               | optional        |  |
   +.................................+.................+  |
   |*other:any                       | optional        |  |
   +---------------------------------+-----------------+  |
                                                          |
                                                     1..* V
                                                 +-------------+
                                                 | GeoLocation |
                                                 +-------------+

   Parameters:

   deviceDesc: values

   5.  The DeviceDescriptor (Section 5.2) for the Device
      requesting available spectrum.  When Database responds to the request is made by a
      Master Device on its own behalf, request, including the descriptor is that identifier of
       the applicable ruleset

   6.  The Master Device and it is REQUIRED.  When uses the request is made on
      behalf of a Slave Device, indicated ruleset to determine how to
       interpret the descriptor is that Database response

   NOTE Some regulatory domains specify sets of the Slave
      Device, requirements for device
   behavior that may be complex and it is REQUIRED if the "requestType" parameter is not
      specified. easily parameterized.  The deviceDesc
   ruleset-id parameter may be OPTIONAL for some
      values of requestType.
   locations:  The GeoLocation (Section 5.1) list provides a mechanism for the Device is
      REQUIRED.  This allows Database to inform
   the Master Device of an applicable ruleset, and, for devices with
   out-of-band knowledge of the particular regulatory domain
   requirements, to satisfy those requirements without having to specify its actual location
      plus additional anticipated locations.  At least one location MUST
      be included.  This specification places no upper limit on
   the
      number device-side behavior within the protocol.  Ruleset identifiers
   will normally contain the name of locations, but the regulatory body that
   established the rules and version information, such as
   "FccTvBandWhiteSpace-2010".

   By separating the regulatory "authority" from the "ruleset-id", it
   allows the protocol to support multiple regulatory authorities that
   use the same device-side ruleset.  It also allows support for a
   single authority to define multiple rulesets.

4.  Protocol Functionalities

   PAWS consists of several components.  As noted below, some regulatory
   domains or Database MAY restrict implementations may mandate the number use of
      locations it supports a
   component, even when its use is not mandated by returning PAWS.

   o  Database Discovery (Section 4.1) is a response with fewer locations
      than specified in required component for the request.  If
      Master Device.

   o  Initialization (Section 4.3) is a required component for the locations specify regions,
      rather than points,
      Database.  Its use allows the Database MAY return Master Device to determine necessary
      information that have not been preconfigured.

   o  Device Registration (Section 4.4) is an error with optional component for the
      UNIMPLEMENTED (Table 1) code, if it does not support query by
      region.  When
      Database.  It can be implemented as a separate component or as
      part of the request Available Spectrum Query (Section 4.5) component.  It
      is made used by a the Master Device on its own
      behalf, when the locations are those of Database requires it.  Note
      that some regulators require device registration for only specific
      device types.

   o  Available Spectrum Query (Section 4.5) is a required component for
      the Master Device.  When Device and the
      request Database.

   o  Spectrum Use Notify (Section 4.5.5) is made by an optional component for
      the Master Device on behalf of a Slave Device, and the locations are those of Database.  When it is required, the Slave Device (see also
      Database informs the
      masterDeviceLocation parameter).
   owner:  The DeviceOwner (Section 5.5) information MAY be included Master Device via its response to
      register the
      Available Spectrum Query (Section 4.5).

   o  Device with Validation (Section 4.6) as a separate component is
      optional for the Master Device and Database.  This enables  When implemented by
      the Database, its use allows the Master Device to
      register validate Slave
      Devices without having to use the full Available Spectrum Query.

   This section describes the protocol components and get spectrum-availability information in their messages.
   Protocol Parameters (Section 5) contains a single
      request.  Some rulesets mandate registration more thorough discussion
   of the parameters that make up the PAWS request and response
   messages.  Message Encoding (Section 6) provides examples of message
   encodings.  HTTPS Binding (Section 7) describes the use of HTTPS
   ("HTTP Over TLS" [RFC2818]) for specific transferring PAWS messages and
   optional device
      types.
   antenna:  The AntennaCharacteristics (Section 5.3) is OPTIONAL.
   capabilities: authentication.

   The Master Device MAY include its DeviceCapabilities parameter tables in this section and Protocol Parameters
   (Section 5.4) to limit 5) are for reference and contain the available-spectrum response to name of each parameter,
   the
      spectrum that is compatible with its capabilities.  The Database
      SHOULD NOT return spectrum that is not compatible with data type of each parameter, and whether the
      specified capabilities.
   masterDeviceDesc:  When existence of the request
   parameter is made by required for the Master Device protocol transaction in question.  The
   diagrams are loosely based on
      behalf UML, and the data types are defined
   either in Protocol Parameters (Section 5) or are one of a Slave Device, the Master Device MAY provide its own
      descriptor.
   masterDeviceLocation:  When following
   primitive or structured types:

   string  A string, as defined by JSON [RFC7159], restricted to the request is made
      UTF-8 encoding.

   int  A number, as defined by JSON [RFC7159], without a fractional or
      exponent part.

   float  A number, as defined by JSON [RFC7159].

   boolean  A boolean, as defined by JSON [RFC7159].

   list  A structured type that represents a list of elements, as
      defined by JSON [RFC7159] array type.  All elements of the Master Device
      on behalf list
      are of a Slave Device, the Master Device MAY provide same data type, which is indicated in its own
      GeoLocation (Section 5.1).
   requestType: diagram and
      description.  The request type is an OPTIONAL parameter that diagram notation and description may include
      additional constraints, such as minimum or maximum number of
      elements.

   NOTE: All parameter names are case sensitive.  Unless stated
   otherwise, all string values are case sensitive.

4.1.  Database Discovery

   Preconfiguration

   The Master Device can be
      used to modify the request, but its use depends on applicable provisioned statically (preconfigured) with
   the
      ruleset.  The request type URI of one or more Databases.  For example, in a particular
   regulatory domain, there may be used, for example, to request
      generic Slave Device parameters without having a number of certified Databases that
   any device operating in that domain is permitted to specify connect to, and
   those URIs can be preconfigured in the
      device descriptor for a specific device.  When

   Listing Server Support: As an alternative to preconfiguring devices
   with a list of certified Databases, some regulatory domains support
   the requestType
      parameter is missing, preconfiguration of devices with the request is for URI of a specific device (Master
      or Slave), so certified listing
   server, to which devices can connect to obtain the deviceDesc parameter is REQUIRED.  The length list of
      the value MUST NOT exceed 64 octets. certified
   Databases.  See IANA Ruleset Registry,
      Initial Registry Contents (Section 9.1.2) Listing Server Support (Appendix A) for ruleset specifics.
   other:  Rulesets and database implementations may require additional
      request parameters.  The further
   information.

   Configuration Update: Database MUST ignore all parameters it
      does not understand.  Consult the PAWS Parameters Registry
      (Section 9.2) for possible additional parameters.

4.4.4.  AVAIL_SPECTRUM_BATCH_RESP

   The response message for URI changes

   To adapt to changes in the batch Available Spectrum Query contains
   a schedule list of available spectrum for the Device at multiple
   locations.

   +---------------------------------------+
   |AVAIL_SPECTRUM_BATCH_RESP              |
   +----------------------------+----------+
   |timestamp:string            | required |
   |deviceDesc:DeviceDescriptor | required |
   |geoSpectrumSpecs:list       | required |-------+
   |............................|..........|       |
   |databaseChange:DbUpdateSpec | optional |       |
   |*other:any                  | optional |       |
   +----------------------------+----------+       | 0..*
                                                   V
                                +---------------------------------+
                                |GeoSpectrumSpec                  |
                                +----------------------+----------+
                                |location:GeoLocation  | required |
                                |spectrumSpecs:list    | required |
                                +----------------------+----------+

   Parameters:

   timestamp:  Timestamp certified or approved databases,
   the device needs to update its preconfigured list of databases.

   A Database MAY change its URI, but before it changes its URI, it MUST
   indicate so by including the response URI of one or more alternate databases
   using DbUpdateSpec (Section 5.7) in its responses to devices.  A
   device will update its preconfigured entry for the form, YYYY-MM-
      DDThh:mm:ssZ, as defined by Date and Time on Database sending
   the Internet:
      Timestamps [RFC3339].  This can be used DbUpdateSpec by replacing this entry with the Device as a
      reference for the start and stop times alternate databases
   listed in the spectrum schedules.
   deviceDesc:  The Database MUST include DbUpdateSpec; the DeviceDescriptor
      (Section 5.2) specified list of alternate databases does not
   affect any other entries.  Note that the ordering of databases in the AVAIL_SPECTRUM_BATCH_REQ message.
   geoSpectrumSpecs:  The geoSpectrumSpecs (Section 5.15)
   list is
      REQUIRED (although it MAY be empty does not imply any preference and does not need to remain the
   same for every request.  The device SHOULD detect infinite
   redirection loops; if spectrum is unavailable).
      For each location, a suitable database cannot be contacted, the Database MAY return one or more
      SpectrumSpec (Section 5.9) parameters
   device MUST treat this as equivalent to represent a response indicating no
   available
      spectrum spectrum.  This database-change mechanism is used, for one or more rulesets.  The
   example, before a Database MAY return
      available spectrum ceases operation; it is not intended to be
   used for fewer locations than requested. dynamic load balancing.

   Error Handling

   The order device SHOULD select another database from its list of
   preconfigured databases if:

   o  The selected database is unreachable or does not respond.

   o  The selected database returns an UNSUPPORTED error (see Error
      Codes (Section 5.17)), which may indicate that the entries in database does
      not support the regulatory domain where the list device is not significant and located.

   If a suitable database cannot be contacted, the Device device MUST
      use the location value in each GeoSpectrumSpec entry to match
      available spectrum treat
   this as equivalent to a location.
   databaseChange:  The Database MAY include a DbUpdateSpec
      (Section 5.7) parameter to notify response indicating no available spectrum.
   If the Device of device had previously contacted a change to the
      Database URI, providing one or more alternate database URIs.  The
      Device needs to use the information to update its list of
      preconfigured databases get available
   spectrum, but subsequently fails to replace (only) its entry for the
      responding database with the list of alternate URIs.
   other:  Database implementations MAY return additional parameters in contact a suitable database, the response.  Consult
   spectrum the PAWS Parameters Registry (Section 9.2) device is currently using can be used for possible additional parameters and requirements they place on as long as the Device.

   See Update Requirements (Section 4.4.2.1) for when
   spectrum data is valid; but after that period, the Device must
   update its available device will no
   longer have valid spectrum data.

4.4.5.  SPECTRUM_USE_NOTIFY

   The spectrum-use notification message indicates to use.  Some regulatory domains may have
   specific rules regarding how long the spectrum
   anticipated data remains valid in
   these cases.

4.2.  PAWS Version

   PAWS version uses a "<major>.<minor>" numbering scheme to be used by indicate
   versions of the device.

   +--------------------------------------------+
   |SPECTRUM_USE_NOTIFY                         |
   +---------------------------------+----------+
   |deviceDesc:DeviceDescriptor      | required |
   |location:GeoLocation             | required |
   |masterDeviceDesc:DeviceDescriptor| optional |
   |masterDeviceLocation:GeoLocation | optional |
   |spectra:list                     | required |-------+
   |............................................|       |
   |*other:any                       | optional |       |
   +---------------------------------+----------+       | 0..*
                                                        V
                                 +--------------------------------+
                                 |Spectrum                        |
                                 +---------------------+----------+
                                 |resolutionBwHz:float | required |
                                 |profiles:list        | required |
                                 +---------------------+----------+

   Parameters:

   deviceDesc: protocol.  The DeviceDescriptor (Section 5.2) for protocol versioning policy is intended
   to allow the Device device or Database to indicate the format of a message
   and its understanding of PAWS functionality defined by that version.
   No change is
      REQUIRED.
   location:  The GeoLocation (Section 5.1) made to the version string for the Device.  When addition of message
   components which only add to extensible parameter values.  The
   <minor> number is incremented when the
      notification changes made to the protocol
   add functionalities (methods), but do not change the existing
   functionalities.  The <major> number is incremented when incompatible
   changes are made by a to existing functionality.

   The current PAWS version is "1.0".

4.3.  Initialization

   A Master Device on its own behalf, SHOULD use the
      location is that of initialization procedure to exchange
   capability information with the Database whenever the Master Device and is REQUIRED.  When
   powers up or initiates communication with the Database.  The
   initialization response informs the
      notification is made by a Master Device on behalf of a Slave
      Device, specific
   parameterized-rule values, such as threshold distances and time
   periods beyond which the location device must update its available-spectrum
   data (see RuleSetInfo (Section 5.6)).  When a Master Device is not
   configured manually with these parameterized-rule values, it MUST use
   the initialization procedure.  For database implementations that of
   require it, the Slave Device and is OPTIONAL,
      but may initialization message also enables extra database-
   specific or ruleset-specific handshake parameters to be required by some rulesets.
   spectra: communicated
   before allowing available-spectrum requests.

   The Spectrum Initialization request procedure is depicted in Figure 1.

   o  INIT_REQ (Section 5.11) list 4.3.1) is REQUIRED, and specifies the spectrum anticipated to be used by initialization request message

   o  INIT_RESP (Section 4.3.2) is the Device, which includes
      profiles of frequencies and power levels. initialization response message

                  +---------------+    +-------------------+
                  | Master Device |    | Spectrum Database |
                  +---------------+    +-------------------+
                        |                     |
                        |    INIT_REQ         |
                        |-------------------->|
                        |                     |
                        |    INIT_RESP        |
                        |<--------------------|
                        |                     |

                                 Figure 1

4.3.1.  INIT_REQ

   The list MAY be empty,
      if initialization request message allows the Master Device decides not to use any spectrum.  For consistency,
      the resolution bandwidth value, "resolutionBwHz" MUST match that
      from one
   initiate exchange of capabilities with the Spectrum Database.

   +---------------------------------------+
   |INIT_REQ                               |
   +----------------------------+----------|
   |deviceDesc:DeviceDescriptor | required |
   |location:GeoLocation        | required |
   |.......................................|
   |*other:any                  | optional |
   +----------------------------+----------+
   Parameters:

   deviceDesc:  The DeviceDescriptor (Section 5.11) elements in 5.2) for the
      corresponding AVAIL_SPECTRUM_RESP message, and device is
      REQUIRED.  If the maximum power
      levels in device descriptor does not contain any ruleset
      IDs, the Spectrum element MUST be expressed as power over Master Device is asking the
      specified "resolutionBwHz" value.  The actual bandwidth Database to be used
      (as computed from the start and stop frequencies) MAY be different
      from return a
      RulesetInfo (Section 5.6) list that specifies the "resolutionBwHz" value.  As an example, when rulesets that it
      supports at the ruleset
      expresses maximum power spectral density in terms specified location.

   location:  The GeoLocation (Section 5.1) of maximum power
      over any 100 kHz band, then the "resolutionBwHz" value should be
      set to 100 kHz, even though the actual bandwidth used can be 20
      kHz.
   masterDeviceDesc:  When the notification device is made by the Master Device
      on behalf of a Slave Device, the Master Device MAY provide its own
      descriptor.
   masterDeviceLocation:  When REQUIRED.
      If the notification location is made outside any regulatory domain supported by the Master
      Device on behalf of a Slave Device,
      Database, the Master Device MAY include
      its own GeoLocation (Section 5.1). Database MUST respond with an OUTSIDE_COVERAGE
      (Table 1) error.

   other:  Depending on  The Master Device MAY specify additional handshake parameters
      in the ruleset, other INIT_REQ message.  The Database MUST ignore all parameters may be required.
      it does not understand.  To simplify its initialization logic, the a
      Master Device MAY that supports multiple Databases and rulesets can
      include the union of all
      parameters required by parameters for all its supported
      rulesets.  Consult the PAWS Parameters Registry (Section 9.2) for
      possible additional parameters.

4.3.2.  INIT_RESP

   The Database MUST
      ignore all parameters it does not understand.

4.4.6.  SPECTRUM_USE_RESP

   The spectrum-use initialization response message simply acknowledges receipt of communicates database parameters
   to the
   notification. requesting device.  This response is returned only when there
   is at least one ruleset.  Otherwise, the Database returns an error
   response, as described in INIT_REQ (Section 4.3.1).

   +---------------------------------------+
   |SPECTRUM_USE_RESP
   |INIT_RESP                              |
   +----------------------------+----------+   1..* +-------------+
   |rulesetInfos:list           | required |------->| RulesetInfo |
   |databaseChange:DbUpdateSpec | optional |        +-------------+
   |.......................................|
   |*other:any                  | optional |
   +----------------------------+----------+

   Parameters:

   rulesetInfos:  A RulesetInfo (Section 5.6) list MUST be included in
      the response.  Each RulesetInfo corresponds to a ruleset supported
      by the Database and is applicable to the location specified in the
      INIT_REQ (Section 4.3.1) message.

      If the device included a list of ruleset IDs in the
      DeviceDescriptor of its INIT_REQ message, each RulesetInfo in the
      response MUST match one of the specified ruleset IDs.

      If the DeviceDescriptor did not contain any ruleset IDs, the
      Database SHOULD include in the rulesetInfos list a RulesetInfo for
      each ruleset it supports at the specified location.

      If the Database does not support the device or any of the rulesets
      specified in the DeviceDescriptor, it MUST instead return an error
      with the UNSUPPORTED (Table 1) code in the error response.

   databaseChange:  The Database MAY include a DbUpdateSpec
      (Section 5.7) parameter to notify the Master Device of a change to the
      Database URI, providing one or more alternate database URIs.  The
      Device
      device needs to use the information to update its list of preconfigured databases to replace (only) its entry for the responding
      database with the list of alternate URIs. databases listed in the DbUpdateSpec.

   other:  The Database implementations MAY return include additional handshake parameters in
      the response. INIT_RESP (Section 4.3.2) message.  The Master Device MUST
      ignore all parameters it does not understand.  Consult the PAWS
      Parameters Registry (Section 9.2) for possible additional
      parameters.

4.5.  Device Validation

   Typically, a Slave

4.4.  Device needs Registration

   Some rulesets require a Master Device to ask the Database
   on send its behalf for available spectrum.  Depending on the ruleset, the
   Master Device also must validate with the Database that the Slave
   Device is permitted registration
   information to operate.  When the ruleset allows a Master
   Device Database in order to "cache" the available spectrum establish certain operational
   parameters.  FCC rules, for example, require that a period of time, the
   Master Device may use the simpler 'Fixed Device'
   register its owner and operator contact information, its device
   identifier, its location, and its antenna height.

   The Database MAY implement device registration as a separate Device Validation component,
   instead
   Registration request, or as part of the full Available Spectrum Query component, to validate a
   Slave Device.

   When validating one or more Slave Devices, the Master Device sends Availability
   request.  If the Database does not implement a request that includes the device identifier -- and any
   other parameters required by the ruleset -- for each Slave Device.
   The Database separate Device
   Registration request, it MUST return a response with an entry for each device to
   indicate whether it is permitted to use the spectrum.

   A typical sequence for using error with the Device Validation request is
   illustrated UNIMPLEMENTED
   (Table 1) code in Figure 6, where the Master Device already has a valid
   set of available spectrum for Slave Devices.  Note that the
   communication and protocol between the Slave Device and Master error-response message.

   The Device
   is outside the scope of this document. Registration request procedure is depicted in Figure 2.

   o  DEV_VALID_REQ  REGISTRATION_REQ (Section 4.5.1) 4.4.1) is the device-validation device-registration
      request message

   o  DEV_VALID_RESP  REGISTRATION_RESP (Section 4.5.2) 4.4.2) is the device-validation device-registration
      response message

      +------------+
                +---------------+        +-------------------+
      |Slave Device|
                | Master Device |        | Spectrum Database |
      +------------+
                +---------------+        +-------------------+
                      |                         |
                      |    REGISTRATION_REQ     | AVAIL_SPEC_REQ  |                           |
          |................>|                           |
          |                 |                           |
          |                 |    DEV_VALID_REQ          |
          |                 |-------------------------->|
          |                 |                           |
          |                 |    DEV_VALID_RESP         |
          |                 |<--------------------------|
          | AVAIL_SPEC_RESP |                           |
          |<................|                           |
          |                 |                           |
          | (SPECTRUM_USE)  |
                      |------------------------>|
                      |
          |................>|   (SPECTRUM_USE_NOTIFY)                         |
                      |                 |-------------------------->|    REGISTRATION_RESP    |
                      |<------------------------|
                      |                         |

                                 Figure 2

4.4.1.  REGISTRATION_REQ

   The registration request message contains the required registration
   parameters.  A parameter marked as optional may be required by some
   rulesets.

   +-------------------------------------------+
   |REGISTRATION_REQ                           |
   +-------------------------------+-----------+
   |deviceDesc:DeviceDescriptor    |    (SPECTRUM_USE_RESP) required  |
   |location:GeoLocation           |                 |<--------------------------|

                                 Figure 6

4.5.1.  DEV_VALID_REQ

   +---------------------------------------------+
   |DEV_VALID_REQ required  |
   +----------------------------------+----------+
   |deviceDescs:list
   |deviceOwner:DeviceOwner        | required |---+
   |masterDeviceDesc:DeviceDescriptor  | optional
   |antenna:AntennaCharacteristics | optional  |
   +----------------------------------+----------+
   |...........................................|
   |*other:any                     |
                                                     V 1..*
                                    +----------------------+
                                    |DeviceDescriptor optional  |
                                    +----------------------+
   +-------------------------------+-----------+

   Parameters:

   deviceDescs:  A

   deviceDesc:  The DeviceDescriptor (Section 5.2) list for the Master Device
      is REQUIRED, REQUIRED.  The ruleset IDs included in the DeviceDescriptor
      indicate the rulesets for which the device wishes to register.  If
      the registration information is unacceptable for all of the
      rulesets supported by the Database, the Database MUST return an
      error message with an appropriate error code.  Otherwise, the
      Database MUST return, in its response, a RulesetInfo (Section 5.6)
      list that specifies all rulesets for which device registration was
      accepted.

   location:  The GeoLocation (Section 5.1) for the device is REQUIRED.
      If the location is outside all regulatory domains supported by the
      Database, the Database MUST respond with an OUTSIDE_COVERAGE
      (Table 1) error.

   deviceOwner:  The DeviceOwner (Section 5.5) information is REQUIRED.

   antenna:  The AntennaCharacteristics (Section 5.3) is OPTIONAL.

   other:  Rulesets and database implementations may require additional
      registration parameters.  To simplify its registration logic, the list of Slave Devices that are to be
      validated.
   masterDeviceDesc:  The
      Master Device MAY provide its own descriptor.

4.5.2.  DEV_VALID_RESP

   +---------------------------------------+
   |DEV_VALID_RESP                         |
   +----------------------------+----------+
   |deviceValidities:list       | send a union of the registration information
      required |----
   |databaseChange:DbUpdateSpec | optional |   |
   +----------------------------+----------+   |
                                               V 1..* by all supported rulesets.  The Database MUST ignore all
      parameters it does not understand.  Consult the PAWS Parameters
      Registry (Section 9.2) for possible additional parameters.

4.4.2.  REGISTRATION_RESP

   The registration response message acknowledges successful
   registration by including a RulesetInfo message for each ruleset in
   which the registration is accepted.  If the Database does not accept
   the registration for any of the rulesets it supports, the Database
   MUST return the NOT_REGISTERED error (See Error Codes
   (Section 5.17)).

   +---------------------------------------+
                            |DeviceValidity
   |REGISTRATION_RESP                      |
   +----------------------------+----------+
                            |deviceDesc:DeviceDescriptor   1..* +-------------+
   |rulesetInfos:list           | required |------->| RulesetInfo |
                            |isValid:boolean
   |databaseChange:DbUpdateSpec | required optional |
                            |reason:string        +-------------+
   |............................|..........|
   |*other:any                  | optional |
   +----------------------------+----------+

   Parameters:

   deviceValidities:

   rulesetInfos:  A DeviceValidities RulesetInfo (Section 5.16) 5.6) list is REQUIRED MUST be included in
      the response.  Each entry corresponds to report a ruleset for which the list of Slave Devices and whether each listed Device
      is valid.
      registration was accepted.  The number of entries list MUST match the number of
      DeviceDescriptors (Section 5.2) listed in the DEV_VALID_REQ
      message. contain at least one
      entry.

   databaseChange:  The Database MAY include a DbUpdateSpec
      (Section 5.7) parameter to notify the Master Device of a change to the
      Database URI, providing one or more alternate database URIs.  The
      Device
      device needs to use the information to update its list of preconfigured databases to replace (only) its entry for the responding
      database with the list of alternate URIs.

5.  Protocol databases listed in the DbUpdateSpec.

   other:  Database implementations MAY return additional parameters in
      the registration response.  The Master Device MUST ignore any
      parameters it does not understand.  Consult the PAWS Parameters

   This section presents more details of
      Registry (Section 9.2) for possible additional parameters.

4.5.  Available Spectrum Query

   To obtain the parameters that make up available spectrum from the
   PAWS Database, a Master Device
   sends a request that contains its geolocation and response messages.  It also includes any parameters
   required by the ruleset (such as device identifier, capabilities, and
   characteristics).  The Database returns a sub-section
   defining response codes.

5.1.  GeoLocation

   This parameter is used to specify the geo-location of the Device.  It
   may be used to specify one of the following:

   o  A single point with optional uncertainty
   o  A region described by that describes
   which frequencies are available, at what permissible operating power
   levels, and a polygon

   These schedule of when they are represented using geometric shapes defined available.

   The Available Spectrum Query procedure is depicted in Section 5 of
   GEOPRIV Presence Information Data Format Location Object [RFC5491],
   where: Figure 3.

   o  A "point" with uncertainty  AVAIL_SPECTRUM_REQ (Section 4.5.1) is represented using the Ellipse shape available-spectrum
      request message.

   o  A region  AVAIL_SPECTRUM_RESP (Section 4.5.2) is represented using the Polygon shape

   The coordinates are expressed using available-spectrum
      response message.

   o  AVAIL_SPECTRUM_BATCH_REQ (Section 4.5.3) is an OPTIONAL batch
      version of the WGS84 datum [WGS-84], and
   units are degrees or meters.  The parameter MAY also include a
   confidence level, expressed as a percentage.  The confidence and
   uncertainty parameters may available-spectrum request message that allows
      multiple locations to be required by some rulesets.

   The data model specified in the request.

   o  AVAIL_SPECTRUM_BATCH_RESP (Section 4.5.4) is the response message
      for GeoLocation the batch version of the available-spectrum request that
      contains available spectrum for each location in the request.

   o  SPECTRUM_USE_NOTIFY (Section 4.5.5) is illustrated below:

   +------------------------------------+
   |GeoLocation                         |
   +------------------+-----------------+
   |point:Ellipse     | see description |
   |region:Polygon    | see description |
   |confidence:int the spectrum-usage
      notification message.

   o  SPECTRUM_USE_RESP (Section 4.5.6) is the spectrum-usage
      acknowledgment message.

               +---------------+          +-------------------+
               | optional Master Device |
   +------------------+-----------------+
   Note: point and region are mutually exclusive. Exactly one must
   be present.

   +-------------------------------+
   |Ellipse          |
   +--------------------+----------+
   |center:Point Spectrum Database | required |--+
   |semiMajorAxis:float
               +---------------+          +-------------------+
                     | optional                            |
                     |
   |semiMinorAxis:float    AVAIL_SPECTRUM_REQ      | optional
                     | (AVAIL_SPECTRUM_BATCH_REQ) |
   |orientation:float
                     |--------------------------->|
                     | optional                            |
                     |
   +--------------------+----------+  v
                              +---------------------------+
                              |Point    AVAIL_SPECTRUM_RESP     |
                              +----------------+----------+
                              |latitude:float
                     | required (AVAIL_SPECTRUM_BATCH_RESP)|
                     |<---------------------------|
                     |
                              |longitude:float                            | required
                     |
                              +----------------+----------+

   +-------------------------------+
   |Polygon   (SPECTRUM_USE_NOTIFY)    |
   +-------------------+-----------+  4..* +---------------------------+
   |exterior:list
                     |--------------------------->|
                     | required  |------>|Point                            |
   +-------------------+-----------+       +----------------+----------+
                                           |latitude:float
                     | required    (SPECTRUM_USE_RESP)     |
                                           |longitude:float
                     |<---------------------------|
                     | required                            |
                                           +----------------+----------+

   Parameters:

   point:  If present, it indicates that the GeoLocation represents a
      point.  Paradoxically, a "point" is parameterized using an
      Ellipse, where the center represents the location of the point and
      the distances along the major and minor axes represent the
      uncertainty.  The uncertainty values may be required, depending on
      the ruleset.  Exactly one of "point" or "region" MUST be present.
   region:  If present, it indicates that the GeoLocation represents a
      region.  Exactly one of "point" or "region" MUST be present.
   center:  The center refers to the location of a GeoLocation point and
      is represented as the center of an ellipse.
   latitude, longitude:  Floating-point numbers that express the
      latitude and longitude in degrees using the WGS84 datum [WGS-84].
   semiMajorAxis, semiMinorAxis:  The location uncertainty, expressed in
      meters, is OPTIONAL.  It is parameterized using distances along
      the major and minor axes of the ellipse.  The default value is 0.
   orientation:  This defines the orientation of the ellipse, expressed
      as the rotation, in degrees, of the semi-major axis from North
      towards the East.  For example, when

                                 Figure 3

   1.  First, the uncertainty is greatest
      along Master Device sends an available-spectrum request
       message to the North-South direction, orientation is 0 degrees;
      conversely, if Database.

   2.  The Database MUST respond with an error using the uncertainty NOT_REGISTERED
       (Table 1) code if:

       *  registration information is greatest along required, and

       *  the East-West
      direction, orientation is 90 degrees.  When orientation is request does not
      present, include registration information, and

       *  the default value is 0.
   exterior:  When GeoLocation describes a region, device has not previously registered with the "exterior" field
      refers to a list of latitude/longitude points that represents Database

   3.  If the
      vertices of a polygon.  The first and last points MUST be location specified in the
      same.  Thus, a minimum of 4 points request is required.  The following
      polygon restrictions from [RFC5491] apply:
      *  A connecting line MUST NOT cross another connecting line of outside the
         same polygon.
      *  The vertices
       regulatory domain supported by the Database, the Database MUST be defined in a counter-clockwise direction.
      *  The edges of
       respond with an OUTSIDE_COVERAGE (Table 1) error.  If some
       locations within a polygon batch request are defined outside the regulatory
       domain supported by the shortest path between
         two points in space (not a geodesic curve).  Consequently, Database, the
         length between two adjacent vertices SHOULD be restricted to Database MAY return an OK
       response with available spectrum for only the valid locations;
       otherwise, if all locations within a
         maximum of 130 km.
      *  All vertices batch request are assumed to be at outside
       the regulatory domain, the Database MUST respond with an
       OUTSIDE_COVERAGE error.

   4.  The Database MAY perform other validation of the request, (e.g.,
       checking for missing required parameters, authorizations).  If
       validation fails, the same altitude.
      *  Polygon shapes Database returns an appropriate error code
       (Table 1).  If the request is missing required parameters, the
       Database MUST respond with a MISSING (Table 1) error and SHOULD be restricted to
       include a maximum list of 15 vertices
         (16 points that includes the repeated vertex).
   confidence:  The location confidence level, as a percentage, MAY be
      provided.  When missing parameters.

   5.  If the parameter request is not provided, valid, the default value
      is 95.  Valid values range from 0 to 100, but, in practice, 100-
      percent confidence is not achievable.  The confidence value is
      meaningful only when GeoLocation refers to a point Database responds with
      uncertainty.

5.2.  DeviceDescriptor

   The device descriptor contains parameters an available-
       spectrum response message.  If the ruleset requires that identify devices
       must report anticipated spectrum usage, the specific
   device, such as its manufacturer serial number, manufacturer's ID,
   and any other device characteristics required by ruleset.

   +--------------------------------+
   |DeviceDescriptor                |
   +---------------------+----------+
   |serialNumber:string  | required |
   |manufacturerId:string| optional |
   |modelId:string       | optional |  1..*
   |rulesetIds:list      | optional |------>string
   |.....................|..........|
   |*other:any           | optional |
   +---------------------+----------+

   Parameters:

   serialNumber:  The manufacturer's device serial number is REQUIRED.
      The length of Database will
       indicate so in the value response message.

   6.  If the available-spectrum response indicates that the Master
       Device must send a spectrum-usage notification message, the
       Master Device sends the notification message to the Database.

   7.  If the Database receives a spectrum-usage notification message,
       it MUST NOT exceed 64 octets, conforming send a spectrum-usage acknowledgment message to the X.520 [ITUT.X520.2008] recommendations.

   manufacturerId:
       Master Device.

   The manufacturer's ID procedure for asking for available spectrum on behalf of a Slave
   Device is similar, except that the process is OPTIONAL, but may be
      required initiated by some rulesets.  This represents the name of the Slave
   Device.  The device
      manufacturer, identifier, capabilities, and therefore ought to be consistent across all
      devices from characteristics
   communicated in the same manufacturer and distinct from that of other
      manufacturers.  The string value AVAIL_SPECTRUM_REQ message MUST NOT exceed 64 octets in
      length.
   modelId:  The device's model ID is OPTIONAL, but may be required by
      some rulesets.  The string value MUST NOT exceed 64 octets in
      length.
   rulesetIds:  The list those of identifiers for rulesets supported by the
      device (see Ruleset ID Registry (Section 9.1)).  A Database MAY
      require
   Slave Device, but the location MUST be that of the device provides this list before servicing Master Device.
   Although the
      device requests.  If communication and protocol between the Database does not support any Slave Device and
   Master Device is outside the scope of this document (represented as
   dotted lines), the
      rulesets specified expected message sequence is shown in the list, the Figure 4.

      +------------+     +---------------+      +-------------------+
      |Slave Device|     | Master Device |      | Spectrum Database MAY refuse to service
      the device requests.  See RulesetInfo (Section 5.6) for discussion
      on ruleset identifier.  If present, the list MUST contain at least
      one entry.
   other:  Depending on the ruleset, other parameters may be required. |
      +------------+     +---------------+      +-------------------+
          |                 |                           |
          | AVAIL_SPEC_REQ  |                           |
          |................>|                           |
          |                 |                           |
          |                 |    AVAIL_SPECTRUM_REQ     |
          |                 |-------------------------->|
          |                 |                           |
          |                 |    AVAIL_SPECTRUM_RESP    |
          |                 |<--------------------------|
          | AVAIL_SPEC_RESP |                           |
          |<................|                           |
          |                 |                           |
          | (SPECTRUM_USE)  |                           |
          |................>|   (SPECTRUM_USE_NOTIFY)   |
          |                 |-------------------------->|
          |                 |                           |
          |                 |    (SPECTRUM_USE_RESP)    |
          |                 |<--------------------------|
          |                 |                           |

                                 Figure 4

4.5.1.  AVAIL_SPECTRUM_REQ

   The Database MUST ignore all parameters in the message it does not
      understand.  See PAWS Parameters Registry (Section 9.2) for
      additional valid parameters and for the process for extending the request message with more parameters.  Additionally, see PAWS Ruleset ID
      Registry (Section 9.1) for the valid set of parameters for each
      ruleset.

5.3.  AntennaCharacteristics

   Antenna characteristics provide additional information, such as the
   antenna height, antenna type, etc.  Whether antenna characteristics
   must be provided in Available Spectrum Query protocol MUST
   include a request depends on geolocation.  Rulesets may mandate that it be the device type and ruleset.
   Additionally, a device's
   current location or allow it to be an anticipated location.  A
   parameter marked as optional may be required by some rulesets.

   +------------------------------------+
   |AntennaCharacteristics

   +----------------------------------------------------+
   |AVAIL_SPECTRUM_REQ                                  |
   +-------------------------+----------+
   |height:float
   +----------------------------------+-----------------+
   |deviceDesc:DeviceDescriptor       | see description |
   |location:GeoLocation              | see description |
   |owner:DeviceOwner                 | optional        |
   |heightType:enum
   |antenna:AntennaCharacteristics    | optional        |
   |heightUncertainty:float
   |capabilities:DeviceCapabilities   | optional        |
   |.........................|..........|
   |*characteristics:
   |masterDeviceDesc:DeviceDescriptor | optional        |
   |masterDeviceLocation:GeoLocation  |   various optional        |
   |requestType:string                | optional        |
   +-------------------------+----------+
   |..................................|.................|
   |*other:any                        | optional        |
   +----------------------------------+-----------------+

   Parameters:

   height:

   deviceDesc:  The antenna height in meters.  Note DeviceDescriptor (Section 5.2) for the device
      requesting available spectrum.  When the request is made by a
      Master Device on its own behalf, the descriptor is that of the height
      Master Device and it is REQUIRED.  When the request is made on
      behalf of a Slave Device, the descriptor is that of the Slave
      Device, and it is REQUIRED if the "requestType" parameter is not
      specified.  The deviceDesc parameter may be
      negative.
   heightType:  Valid OPTIONAL for some
      values are:
      AGL  Above ground level (default)
      AMSL  Above mean sea level
   heightUncertainty: of requestType.

   location:  The height uncertainty in meters.

   NOTE: Depending on GeoLocation (Section 5.1) for the ruleset, additional antenna characteristics
   may device requesting
      available spectrum.  The location SHOULD be required, such as:
   o  antenna direction
   o  antenna radiation pattern
   o  antenna gain
   o  antenna polarization
   These are not defined by the base protocol, current location
      of the device, but may be added to more precisely, the
   PAWS Parameters Registry (Section 9.2), as needed.

5.4.  DeviceCapabilities location of the radiation
      center of the device's antenna.  When the request is made by the
      Master Device capabilities provide additional information on its own behalf, the location is that may be used of the
      Master Device and it is REQUIRED.  When the request is made by the
      Master Device to provide additional information to on behalf of a Slave Device, the Database location is that
   can help of
      the Slave Device and it is OPTIONAL (see also
      masterDeviceLocation).  The location may be an anticipated
      position of the device to determine available spectrum. support mobile devices, but its use
      depends on the ruleset.  If the location specifies a region,
      rather than a point, the Database MAY return an error with the
      UNIMPLEMENTED (Table 1) code, if it does not support implement query by
      region.

   owner:  The DeviceOwner (Section 5.5) information MAY be included to
      register the device capabilities it MUST ignore with the parameter
   altogether.

   +-------------------------------+
   |DeviceCapabilities             |
   +---------------------+---------+
   |frequencyRanges:list |optional |--+
   |.....................|.........|  |
   |*other:any           |optional |  |
   +---------------------+---------+  | 0..*
                                      V
                +--------------------------------+
                |FrequencyRange                  |
                +----------------------+---------+
                |startHz:float         |required |
                |stopHz:float          |required |
                +----------------------+---------+

   Parameters:

   frequencyRanges:  Optional FrequencyRange Database.  This enables the device to
      register and get spectrum-availability information in a single
      request.  Some rulesets mandate registration for specific device
      types.

   antenna:  The AntennaCharacteristics (Section 5.3) is OPTIONAL.

   capabilities:  The Master Device MAY include its DeviceCapabilities
      (Section 5.13) list.  Each
      FrequencyRange element contains start and stop frequencies in
      which 5.4) to limit the Device can operate.  When specified, available-spectrum response to the
      spectrum that is compatible with its capabilities.  The Database
      SHOULD NOT return available spectrum that falls outside these ranges.

   other  Consult the PAWS Parameters Registry (Section 9.2) for
      possible additional parameters.  The Database MUST ignore all
      parameters it does is not understand.

5.5.  DeviceOwner

   This parameter contains device-owner information required as part of
   device registration.  Some rulesets may require additional
   parameters.

   +-----------------------------+
   |DeviceOwner                  |
   +------------------+----------+
   |owner:vcard       | required |
   |operator:vcard    | optional |
   +------------------+----------+

   Parameters:

   owner:  The vCard contact information for compatible with the individual or business
      that owns
      specified capabilities.

   masterDeviceDesc:  When the request is made by the Master Device on
      behalf of a Slave Device, the Master Device MAY provide its own
      descriptor.

   masterDeviceLocation:  When the request is REQUIRED.
   operator:  The vCard contact information for made by the device operator Master Device
      on behalf of a Slave Device, the Master Device MAY provide its own
      GeoLocation (Section 5.1).

   requestType:  The request type is OPTIONAL, but which may be required by specific rulesets.

   NOTE: Depending on used to
      modify the ruleset, request, but its use depends on the Database applicable ruleset.

      The request type may be required used, for example, to
   validate indicate that the device-owner information.  In these cases,
      response should include generic Slave Device parameters without
      having to specify the Database
   MUST respond with an INVALID_VALUE error (see Error Codes
   (Section 5.17)) if validation fails. device descriptor for a specific device.
      When requestType is missing, the request is for a specific device
      (Master or Slave), so deviceDesc is REQUIRED.  The maximum length
      of the value is 64 octets.  See PAWS IANA Ruleset ID Registry, Initial
      Registry Contents (Section 9.1) 9.1.2) for ruleset-specific requirements on mandatory vCard
   properties.

   All contact information ruleset specifics.

   other:  Rulesets and database implementations may require additional
      request parameters.  The Database MUST be expressed using the structure defined
   by the vCard Format Specification [RFC6350].  Note that ignore all parameters it
      does not understand.  Consult the vCard
   specification defines maximum lengths PAWS Parameters Registry
      (Section 9.2) for each field, conforming to
   X.520 [ITUT.X520.2008] recommendations.

5.6.  RulesetInfo

   This contains parameters possible additional parameters.

4.5.2.  AVAIL_SPECTRUM_RESP

   The response message for the ruleset of a regulatory domain that
   is communicated using the Initialization component (Section 4.2),
   Device Registration (Section 4.3), and Available Spectrum Query contains one or
   more SpectrumSpec (Section 4.4) components.

   +------------------------------------------+
   |RulesetInfo 5.9) elements, one for each ruleset
   supported at the location specified in the corresponding
   AVAIL_SPECTRUM_REQ (Section 4.5.1) request.  Each SpectrumSpec
   element contains a list of one or more spectrum schedules,
   representing permissible power levels over time:

   o  Within each list of schedules, event-time intervals MUST be
      disjoint and MUST be sorted in increasing time.

   o  A gap in the time schedule means no spectrum is available for that
      time interval.

   +---------------------------------------+
   |AVAIL_SPECTRUM_RESP                    |
   +------------------------------------------+
   |authority:string
   +----------------------------+----------+
   |timestamp:string            | required |
   |rulesetId:string
   |deviceDesc:DeviceDescriptor | required |
   |maxLocationChange:float
   |spectrumSpecs:list          | see description required |-------+
   |............................|..........|       |
   |databaseChange:DbUpdateSpec | optional |       |
   |*other:any                  | optional |       |
   +----------------------------+----------+       | 1..*
                                                   V
                              +-----------------------------------+
                              |SpectrumSpec                       |
                              +------------------------+----------+
                              |rulesetInfo:RulesetInfo | required |
                              |spectrumSchedules:list  | required |-+
                              |timeRange:EventTime     | optional | |
                              |frequencyRanges:list    | optional | |
                              |needsSpectrumReport:bool| optional | |
                              |maxTotalBwHz:float      | optional | |
                              |maxContiguousBwHz:float | optional | |
                              +------------------------+----------+ |
                                               +--------------------+
                                               | 1..*
                                               V
                                  +-------------------------------+
                                  |SpectrumSchedule               |
   |maxPollingSecs:int
                                  +--------------------+----------+
                                  |eventTime:EventTime | see description required |
   |..........................................|
   |*other:any
                                  |spectra:list        | optional required |
   +------------------------+-----------------+
                                  +--------------------+----------+

   Parameters:
   authority:  A string that indicates

   timestamp:  Timestamp of the regulatory domain to which response of the ruleset applies is REQUIRED.  It will normally be a 2-letter
      country code form, YYYY-MM-
      DDThh:mm:ssZ, as defined by Country Codes - ISO 3166 [ISO3166-1].
   rulesetId:  The ID of a ruleset for "Date and Time on the specified authority (see
      Ruleset ID Registry (Section 9.1)).  The Device Internet:
      Timestamps" [RFC3339].  This can use this to
      determine additional device behavior required be used by the associated
      ruleset.  To define new ruleset IDs, see Defining Ruleset
      Identifiers (Section 8.1).
   maxLocationChange:  The maximum location change in meters is REQUIRED device as a
      reference for Initialization Response (Section 4.2.2), but OPTIONAL
      otherwise.  Some regulatory domains mandate that, when the Device
      changes location by more than this specified distance, it contact the Database to get start and stop times in the available spectrum for the new location.
      If this value is provided by the schedules.

   deviceDesc:  The Database within MUST include the context of an
      Available Spectrum Response DeviceDescriptor
      (Section 4.4.2), it takes precedence
      over the value within 5.2) specified in the Initialization Response (Section 4.2.2).
   maxPollingSecs: AVAIL_SPECTRUM_REQ message.

   spectrumSpecs:  The maximum duration, in seconds, between requests
      for SpectrumSpec (Section 5.9) list MUST include at
      least one entry.  Each entry contains the schedules of available
      spectrum is REQUIRED for the Initialization Response
      (Section 4.2.2), but OPTIONAL otherwise. a ruleset.  The Device MUST contact
      the Database MAY return more than one
      SpectrumSpec to get represent available spectrum no less frequently than
      this duration.  If this value is provided within for multiple rulesets
      at the context of an
      Available Spectrum Response specified location.

   databaseChange:  The Database MAY include a DbUpdateSpec
      (Section 4.4.2), it takes precedence
      over 5.7) to notify the value within device of a change to the Initialization Response (Section 4.2.2).
   other:  This message is intended Database
      URI, providing one or more alternate database URIs.  The device
      needs to be extensible update its preconfigured entry for the responding
      database with other ruleset-
      specific parameters.  Devices MUST ignore all the alternate databases listed in the DbUpdateSpec.

   other:  Database implementations MAY return additional parameters in
      the
      message response.  The device MUST ignore any parameters that it does
      not understand.  Consult the PAWS Parameters Registry
      (Section 9.2) for possible additional parameters.

5.7.  DbUpdateSpec

   This element is provided parameters and requirements
      they place on the device.

4.5.2.1.  Update Requirements

   When the stop time specified in the schedule has been reached, the
   device:

   o  MUST obtain a new spectrum-availability schedule, either by using
      the next one in the list (if provided) or making another Available
      Spectrum Query (Section 4.5).

   o  If the device is unable to contact the Database to notify devices of an
   upcoming change obtain a new
      schedule, it MUST treat this as equivalent to a response with no
      available spectrum.

   Some rulesets also mandate that a device must obtain a new specturm-
   availability schedule if the Database URI.

   +-------------------------------+
   |DbUpdateSpec                   |
   +---------------------+---------+       +--------------------------+
   |databases:list       |required |------>|DatabaseSpec              |
   +---------------------+---------+  1..* +---------------+----------+
                                           |name:string    | required |
                                           |uri:string     | required |
                                           +---------------+----------+

   Parameters:

   databases:  List of one device moves beyond a threshold distance
   (established by the ruleset) away from the actual location and all
   anticipated location(s) it reported in previous AVAIL_SPECTRUM_REQ or more DatabaseSpec
   AVAIL_SPECTRUM_BATCH_REQ requests (see "maxLocationChange" in
   RulesetInfo (Section 5.8) entries.
      A Device needs to update its preconfigured list of databases to
      replace (only) 5.6)).  If the database that provided device is unable to contact the
   Database to obtain a new schedule, it MUST treat this as equivalent
   to a response with no available spectrum.

   NOTE: The ruleset determines required device behavior when spectrum
   is no longer available.  The ruleset also governs whether a device
   may request and use spectrum at anticipated locations beyond the
      specified entries.

5.8.  DatabaseSpec

   This element contains
   threshold distance from its current location.

4.5.3.  AVAIL_SPECTRUM_BATCH_REQ

   The Database MAY implement the name and URI batch request that allows multiple
   locations to be specified.  This enables a portable Master Device,
   for example, to get available spectrum for a sequence of anticipated
   locations using a database.

   +--------------------------+
   |DatabaseSpec              |
   +---------------+----------+
   |name:string    | required |
   |uri:string     | required |
   +---------------+----------+

   Parameters:

   name: single request.  The display name for Database interprets each
   location in the batch request as if it were an independent request
   and returns results consistent with multiple individual
   AVAIL_SPECTRUM_REQ (Section 4.5.1) requests, but returns these
   results in a database.  It MAY contain UTF-8. batched response (Section 4.5.4).  The
      value length request message
   for the batch Available Spectrum Query protocol MUST NOT exceed 64 octets.
   uri:  The corresponding URI of include at least
   one GeoLocation (Section 5.1).  If the database.  The value length Database does not implement
   batch requests, it MUST
      NOT exceed 1024 octets.

5.9.  SpectrumSpec

   The SpectrumSpec element encapsulates return an UNIMPLEMENTED (Table 1) error.

   NOTE: Whether anticipated locations are allowed depends on the schedule of available
   spectrum for a
   specified ruleset.

   +---------------------------------------+
   |SpectrumSpec  A parameter marked as optional may be required by
   some rulesets.

   +---------------------------------------------------+
   |AVAIL_SPECTRUM_BATCH_REQ                           |
   +----------------------------+----------+
   |rulesetInfo:RulesetInfo
   +---------------------------------+-----------------+
   |deviceDesc:DeviceDescriptor      | required see description |
   |spectrumSchedules:list
   |locations:list                   | required |-----+
   |timeRange:EventTime        |--+
   |owner:DeviceOwner                | optional        |  |
   |frequencyRanges:list
   |antenna:AntennaCharacteristics   | optional        |  |
   |needsSpectrumReport:boolean
   |capabilities:DeviceCapabilities  | optional        |  |
   |maxTotalBwHz:float
   |masterDeviceDesc:DeviceDescriptor| optional        |  |
   |masterDeviceLocation:GeoLocation | optional        |  |
   |maxContiguousBwHz:float
   |requestType:string               | optional        |  |
   +----------------------------+----------+
   +.................................+.................+  |
   |*other:any                       | 1..*
                                                 V
                                      +-------------------------------+
                                      |SpectrumSchedule optional        |
                                      +--------------------+----------+
                                      |eventTime:EventTime  | required
   +---------------------------------+-----------------+  |
                                      |spectra:list
                                                          | required
                                                     1..* V
                                                 +-------------+
                                                 |
                                      +--------------------+----------+ GeoLocation |
                                                 +-------------+

   Parameters:

   rulesetInfo:

   deviceDesc:  The RulesetInfo DeviceDescriptor (Section 5.6) is REQUIRED to identify
      the regulatory domain and ruleset 5.2) for which the spectrum schedule
      applies (see Ruleset ID Registry (Section 9.1)).  The Device needs
      to use the corresponding ruleset to interpret the response.
      Values provided within this parameter, such as maxLocationChange,
      take precedence over the values provided by the Initialization
      Procedure (Section 4.2).
   spectrumSchedules:  The SpectrumSchedule (Section 5.10) list is
      REQUIRED.  At least one schedule MUST be included.  More than one
      schedule MAY be included to represent future changes to the device
      requesting available spectrum.  How far in advance a schedule may be provided
      depends on the ruleset.  If more than one schedule is included,
      the eventTime intervals MUST be disjoint and MUST be sorted in
      increasing time.  A gap in the time schedule indicates no
      available spectrum during that time-interval gap.
   timeRange:  The time range for which the specification is
      comprehensive is OPTIONAL.  When specified, any gaps in time
      intervals within the "spectrumSchedules" element that overlaps
      with the range specified by "timeRange" are interpreted by the
      Device as time intervals in which there is available spectrum.
   frequencyRanges:  The frequency ranges for which the specification is
      comprehensive is OPTIONAL.  It request is a list of disjoint
      FrequencyRange (Section 5.13) entries.  When specified, it
      typically corresponds to the frequency ranges governed made by a
      Master Device on its own behalf, the
      ruleset, e.g., for TV whitespace, the frequency ranges can
      correspond to the VHF and UHF bands descriptor is that of the associated regulatory
      domain.  A
      Master Device can combine this information with the available-
      spectrum specification within the "spectrumSchedules" element to
      distinguish between "unavailable spectrum" and "spectrum for which
      no information has been provided".
   needsSpectrumReport:  The Database MAY return true for this parameter
      if spectrumSchedules list it is non-empty; otherwise, the Database
      MAY omit this parameter altogether, in which case, REQUIRED.  When the default
      value request is false.  If this parameter made on
      behalf of a Slave Device, the descriptor is present that of the Slave
      Device, and its value it is
      true, REQUIRED if the Device sends a SPECTRUM_USE_NOTIFY "requestType" parameter is not
      specified.  The deviceDesc parameter may be OPTIONAL for some
      values of requestType.

   locations:  The GeoLocation (Section 4.4.5)
      message to the Database; otherwise, 5.1) list for the Device SHOULD NOT send device is
      REQUIRED.  This allows the
      SPECTRUM_USE_NOTIFY message.  Some rulesets mandate this value device to specify its actual location
      plus additional anticipated locations.  At least one location MUST
      be true.
   maxTotalBwHz:  The Database MAY return a constraint included.  This specification places no upper limit on the maximum
      total bandwidth (in Hertz) allowed, which may or may not be
      contiguous.  Some rulesets mandate
      number of locations, but the Database to return this
      parameter.  When present MAY restrict the number of
      locations it supports by returning a response with fewer locations
      than specified in the response, request.  If the locations specify regions,
      rather than points, the Device needs to
      apply this constraint to its spectrum-selection logic to ensure
      total bandwidth does not exceed this value.
   maxContiguousBwHz:  The Database MAY return an error with the
      UNIMPLEMENTED (Table 1) code, if it does not implement query by
      region.  When the request is made by a constraint Master Device on its own
      behalf, the
      maximum contiguous bandwidth (in Hertz) allowed.  Some rulesets
      mandate locations are those of the Database to return this parameter. Master Device.  When present in the response,
      request is made by the Master Device needs to apply this constraint to its
      spectrum-selection logic to ensure no single block on behalf of spectrum has
      bandwidth that exceeds this value.

5.10.  SpectrumSchedule a Slave Device,
      the locations are those of the Slave Device (see also
      masterDeviceLocation).

   owner:  The SpectrumSchedule element combines EventTime DeviceOwner (Section 5.14) 5.5) information MAY be included to
      register the device with
   Spectrum (Section 5.11) the Database.  This enables the device to define a time period
      register and get spectrum-availability information in which the spectrum
   is valid.

   +-------------------------------+
   |SpectrumSchedule               |
   +--------------------+----------+
   |eventTime:EventTime | required |        +--------------------+
   |spectra:list        | required |------->|Spectrum            |
   +--------------------+----------+   0..* +--------------------+
                                            |resolutionBwHz:float|
                                            |profiles:list       |
                                            +--------------------+

   Parameters:

   eventTime: a single
      request.  Some rulesets mandate registration for specific device
      types.

   antenna:  The EventTime AntennaCharacteristics (Section 5.14) is REQUIRED to express
      "when" this specification 5.3) is valid.

   spectra: OPTIONAL.

   capabilities:  The Spectrum Master Device MAY include its DeviceCapabilities
      (Section 5.11) list is REQUIRED 5.4) to limit the available-spectrum response to specify the
      available spectrum and permissible power levels, one per
      resolutionBwHz.  The list MAY be empty when there is no available
      spectrum.

5.11.  Spectrum

   Available spectrum can be characterized by an ordered list of
      spectrum profiles that defines permissible power levels over a set of
   frequency ranges.  Each Spectrum element defines permissible power
   levels as maximum power spectral densities over a specified
   resolution bandwidth, "resolutionBwHz".  Note is compatible with its capabilities.  The Database
      SHOULD NOT return spectrum that is not compatible with the spectrum
   profiles represent
      specified capabilities.

   masterDeviceDesc:  When the "availability mask", as defined request is made by the
   governing rule set; they are not intended to encode device-level
   transmission-mask requirements.

   o  To support Master Device on
      behalf of a ruleset that defines different "wide-band" and
      "narrow-band" power levels, PAWS allows multiple Spectrum elements
      to be included in Slave Device, the available-spectrum response, each with a
      different resolution bandwidth.
   o Master Device MAY provide its own
      descriptor.

   masterDeviceLocation:  When multiple Spectrum elements are included in the response, each
      represents a constraint that request is made by the Master Device must satisfy (logical
      AND).
   o  Each Spectrum element covers the range
      on behalf of frequencies governed by a ruleset, rather than splitting Slave Device, the frequencies across multiple
      Spectrum elements for Master Device MAY provide its own
      GeoLocation (Section 5.1).

   requestType:  The request type is an OPTIONAL parameter that may be
      used to modify the same resolution bandwidth.
   o  Each spectrum profile represents request, but its use depends on applicable the maximum permissible power
      spectral density over
      ruleset.  The request type may be used, for example, to request
      generic Slave Device parameters without having to specify the
      device descriptor for a contiguous range of frequencies.
   o specific device.  When multiple spectrum profiles are included, they MUST be
      disjoint the requestType
      parameter is missing, the request is for a specific device (Master
      or Slave), so deviceDesc is REQUIRED.  The maximum length is 64
      octets.  See IANA Ruleset Registry, Initial Registry Contents
      (Section 9.1.2) for ruleset specifics.

   other:  Rulesets and database implementations may require additional
      request parameters.  The Database MUST be ordered in non-decreasing frequency value.
   o  Gaps in frequencies between consecutive spectrum profiles
      represent unavailability ignore all parameters it
      does not understand.  Consult the PAWS Parameters Registry
      (Section 9.2) for those frequencies. possible additional parameters.

4.5.4.  AVAIL_SPECTRUM_BATCH_RESP

   The following figure illustrates response message for the batch Available Spectrum element and Query contains
   a schedule of available spectrum for the
   SpectrumProfile list.

   +-------------------------------+
   |Spectrum device at multiple
   locations.

   +---------------------------------------+
   |AVAIL_SPECTRUM_BATCH_RESP              |
   +---------------------+---------+
   |resolutionBwHz:float |required
   +----------------------------+----------+
   |timestamp:string            |
   |profiles:list        |required |---+
   +---------------------+---------+ required |  0..*
                                       V
                 +-----------------------------+
                 |SpectrumProfile
   |deviceDesc:DeviceDescriptor |
                 +-------------------+---------+
                 |list               |required required |
                 +-------------------+---------+
   |geoSpectrumSpecs:list       |
                                       V 2..*
                  +----------------+---------+
                  |hz:float        |required required |-------+
   |............................|..........|       |
                  |dbm:float       |required
   |databaseChange:DbUpdateSpec |
                  +----------------+---------+

   Parameters:

   resolutionBwHz:  This parameter defines the resolution bandwidth (in
      Hertz) over which permissible power spectral density is defined.
      For example, FCC regulation would require one spectrum
      specification at a bandwidth of 6MHz, and ETSI regulation would
      require two specifications, at 0.1MHz and 8MHz.
   profiles:   A SpectrumProfile (Section 5.12) list specifies
      permissible power levels over a set of frequency ranges.  The list
      MAY be empty if there is no available spectrum.

   Consider the following example with two different sets of permitted
   power spectral densities for the same set of frequencies over
   different resolution bandwidths (for illustrative purposes only):

   [
     {
       "resolutionBwHz": 6e6,
       "profiles": [
         [
           {"hz": 5.18e8, "dbm": 30.0},
           {"hz": 5.24e8, "dbm": 30.0}
         ],
         ...
       ]
     },
     {
       "resolutionBwHz": 1e5,
       "profiles": [
         [
           {"hz": 5.18e8, "dbm": 27.0},
           {"hz": 5.24e8, "dbm": 27.0}
         ],
         ...
       ]
     }
   ]

   This is interpreted as:

   o  Over any 6MHz within optional |       |
   |*other:any                  | optional |       |
   +----------------------------+----------+       | 0..*
                                                   V
                                +---------------------------------+
                                |GeoSpectrumSpec                  |
                                +----------------------+----------+
                                |location:GeoLocation  | required |
                                |spectrumSpecs:list    | required |
                                +----------------------+----------+

   Parameters:

   timestamp:  Timestamp of the frequency range, [518MHz, 524MHz),
      maximum permitted power is 30.0dBm (1000mW), response of the form, YYYY-MM-
      DDThh:mm:ssZ, as defined by "Date and
   o  Over any 100 kHz within Time on the frequency range, [518MHz, 524MHz),
      maximum permitted power is 27.0dBm (500mW) Internet:
      Timestamps" [RFC3339].  This would allow, for example, operating two 100kHz sub-channels
   within can be used by the indicated 6MHz range at 500mW each, totaling 1000mW.  Of
   course, many combinations are possible, as long device as they satisfy both
   conditions. a
      reference for the start and stop times in the spectrum schedules.

   deviceDesc:  The following example encodes multiple (two) Database MUST include the DeviceDescriptor
      (Section 5.2) specified in the AVAIL_SPECTRUM_BATCH_REQ message.

   geoSpectrumSpecs:  The geoSpectrumSpecs (Section 5.15) list is
      REQUIRED (although it MAY be empty if spectrum profiles, is unavailable).
      For each
   having a gap from 530 MHz location, the Database MAY return one or more
      SpectrumSpecs (Section 5.9) to 536 MHz (for illustrative purposes
   only):

   [
     {
       "resolutionBwHz": 6e6,
       "profiles": [
         [
           {"hz": 5.18e8, "dbm": 30.0},
           {"hz": 5.24e8, "dbm": 30.0},
           {"hz": 5.24e8, "dbm": 36.0},
           {"hz": 5.30e8, "dbm": 36.0}
         ],
         [
           {"hz": 5.36e8, "dbm": 30.0},
           {"hz": 5.42e8, "dbm": 30.0}
         ],
         ...
       ]
     },
     {
       "resolutionBwHz": 1e5,
       "profiles": [
         [
           {"hz": 5.18e8, "dbm": 27.0},
           {"hz": 5.24e8, "dbm": 27.0},
           {"hz": 5.24e8, "dbm": 30.0},
           {"hz": 5.30e8, "dbm": 30.0}
         ],
         [
           {"hz": 5.36e8, "dbm": 27.0},
           {"hz": 5.42e8, "dbm": 27.0}
         ],
         ...
       ]
     }
   ]

5.12.  SpectrumProfile

   A represent available spectrum profile is characterized by an ordered list for
      one or more rulesets.  The Database MAY return available spectrum
      for fewer locations than requested.  The order of (frequency,
   power) points that represents the shape of maximum permissible power
   levels over a range of frequencies.

   o  It MUST contain a minimum of two entries.
   o  The entries in
      the list is not significant and the device MUST be ordered in non-decreasing
      frequency values.
   o  Two consecutive points MAY have use the same frequency location
      value in each GeoSpectrumSpec entry to match available spectrum to
      represent
      a "step function".

   o  Three location.

   databaseChange:  The Database MAY include a DbUpdateSpec
      (Section 5.7) to notify the device of a change to the Database
      URI, providing one or more points MUST NOT share alternate database URIs.  The device
      needs to update its preconfigured entry for the responding
      database with the alternate databases listed in the DbUpdateSpec.

   other:  Database implementations MAY return additional parameters in
      the response.  Consult the PAWS Parameters Registry (Section 9.2)
      for possible additional parameters and requirements they place on
      the device.

   See Update Requirements (Section 4.5.2.1) for when the device must
   update its available spectrum data.

4.5.5.  SPECTRUM_USE_NOTIFY

   The spectrum-use notification message indicates the spectrum
   anticipated to be used by the device.

   +---------------------------------------------------+
   |SPECTRUM_USE_NOTIFY                                |
   +---------------------------------+-----------------+
   |deviceDesc:DeviceDescriptor      | required        |
   |location:GeoLocation             | see description |
   |masterDeviceDesc:DeviceDescriptor| optional        |
   |masterDeviceLocation:GeoLocation | optional        |
   |spectra:list                     | required        |--+
   |...................................................|  |
   |*other:any                       | optional        |  |
   +---------------------------------+-----------------+  | 0..*
                                                          V
                                 +--------------------------------+
                                 |Spectrum                        |
                                 +---------------------+----------+
                                 |resolutionBwHz:float | required |
                                 |profiles:list        | required |
                                 +---------------------+----------+

   Parameters:

   deviceDesc:  The DeviceDescriptor (Section 5.2) for the device is
      REQUIRED.

   location:  The GeoLocation (Section 5.1) for the device.  When the
      notification is made by a Master Device on its own behalf, the same frequency value.
   o  The first frequency
      location is inclusive; that of the last frequency Master Device and is exclusive.

   The following figure illustrates REQUIRED.  When the SpectrumProfile element.

   +-------------------------------+
   |SpectrumProfile                |
   +---------------------+---------+
   |list                 |required |---+
   +---------------------+---------+   |  2..*
                                       V
                 +----------------+---------+
                 |hz:float        |required |
                 |dbm:float       |required |
                 +----------------+---------+

   Parameters
      notification is made by a Master Device on behalf of each point in a Slave
      Device, the profile:

   hz:  The frequency, in Hertz, at which location is that of the power level Slave Device and is defined.
   dbm: OPTIONAL,
      but may be required by some rulesets.

   spectra:  The power level, expressed as dBm per resolution bandwidth, as
      defined Spectrum (Section 5.11) list is REQUIRED, and specifies
      the spectrum anticipated to be used by the device, which includes
      profiles of frequencies and power levels.  The list MAY be empty,
      if the device decides not to use any spectrum.  For consistency,
      the resolution bandwidth value, "resolutionBwHz" element MUST match that
      from one of the enclosing Spectrum (Section 5.11) element.

5.13.  FrequencyRange

   The FrequencyRange parameter specifies a frequency range.

   +--------------------------------+
   |FrequencyRange                  |
   +----------------------+---------+
   |startHz:float         |required |
   |stopHz:float          |required |
   +----------------------+---------+

   Parameters:
   startHz: elements in the
      corresponding AVAIL_SPECTRUM_RESP message, and the maximum power
      levels in the Spectrum element MUST be expressed as power over the
      specified "resolutionBwHz" value.  The inclusive actual bandwidth to be used
      (as computed from the start and stop frequencies) MAY be different
      from the "resolutionBwHz" value.  As an example, when the ruleset
      expresses maximum power spectral density in terms of maximum power
      over any 100 kHz band, then the "resolutionBwHz" value should be
      set to 100 kHz, even though the actual bandwidth used can be 20
      kHz.

   masterDeviceDesc:  When the frequency range (in Hertz) notification is
      REQUIRED.
   stopHz:  The exclusive end made by the Master Device
      on behalf of a Slave Device, the frequency range (in Hertz) is
      REQUIRED.

5.14.  EventTime

   The EventTime element specifies Master Device MAY provide its own
      descriptor.

   masterDeviceLocation:  When the start and stop times of an
   "event".  This notification is used to indicate made by the time period for which Master
      Device on behalf of a
   Spectrum Slave Device, the Master Device MAY include
      its own GeoLocation (Section 5.11) is valid.

   +---------------------------+
   |EventTime 5.1).

   other:  Depending on the ruleset, other parameters may be required.
      To simplify its logic, the device MAY include the union of all
      parameters required by all supported rulesets.  The Database MUST
      ignore all parameters it does not understand.

4.5.6.  SPECTRUM_USE_RESP

   The spectrum-use response message simply acknowledges receipt of the
   notification.

   +---------------------------------------+
   |SPECTRUM_USE_RESP                      |
   +-----------------+---------+
   |startTime:string |required
   +----------------------------+----------+
   |databaseChange:DbUpdateSpec |
   |stopTime:string  |required optional |
   +-----------------+---------+
   |.......................................|
   |*other:any                  | optional |
   +----------------------------+----------+

   Parameters:

   startTime:

   databaseChange:  The inclusive start Database MAY include a DbUpdateSpec
      (Section 5.7) to notify the device of a change to the event is REQUIRED.
   stopTime: Database
      URI, providing one or more alternate database URIs.  The exclusive end of device
      needs to update its preconfigured entry for the event is REQUIRED.

   Both times are expressed using responding
      database with the format, YYYY-MM-DDThh:mm:ssZ, as
   defined by Date and Time on alternate databases listed in the Internet: Timestamps [RFC3339].  The
   times MUST be expressed using UTC. DbUpdateSpec.

   other:  Database implementations MAY return additional parameters in
      the response.  Consult the PAWS Parameters Registry (Section 9.2)
      for possible additional parameters.

4.6.  Device Validation

   A device that does not have access Slave Device needs a Master Device to ask the current date and time MUST
   use the timestamp at the top-level of the response message as a
   substitute Database on its
   behalf for available spectrum.  Depending on the current time (see Available Spectrum Response
   (Section 4.4.2) and Available Spectrum Batch Response
   (Section 4.4.4)).  E.g.,
   o  (startTime - timestamp) gives ruleset, the duration that a device Master
   Device also must wait
      before validate with the event becomes "active".  If Database that the value Slave Device is zero or
      negative,
   permitted to operate.  When the event is already active.
   o  If ruleset allows a Master Device to
   "cache" the event is already active, (stopTime - timestamp) is available spectrum for a period of time, the
      duration that Master
   Device may use the event remains active.  If simpler Device Validation component, instead of
   the value is zero full Available Spectrum Query component, to validate a Slave
   Device.

   When validating one or
      negative, more Slave Devices, the event is no longer active and MUST be ignored.

5.15.  GeoSpectrumSpec

   The GeoSpectrumSpec element encapsulates Master Device sends
   the available spectrum for a
   location.  It is returned within Database a AVAIL_SPECTRUM_BATCH_RESP
   (Section 4.4.4) batch response request that contains multiple GeoSpectrumSpec
   entries, each matching a location provided in includes the batch request.
   +----------------------------------+
   |GeoSpectrumSpec                   |
   +-----------------------+----------+
   |location:GeoLocation   | required |
   |spectrumSpecs:list     | device identifier -- and any
   other parameters required |-------+
   +-----------------------+----------+       |
                                              | 1..*
                                              V
                                      +--------------+
                                      | SpectrumSpec |
                                      +--------------+

   Parameters:

   location:  The GeoLocation (Section 5.1) identifies the location at
      which by the spectrum schedule applies.
   spectrumSpecs:  The SpectrumSpec (Section 5.9) list is REQUIRED.  At
      least one entry MUST be included.  Each entry represents schedules
      of available spectrum ruleset -- for each Slave Device.
   The Database MUST return a ruleset.  More than one response with an entry MAY be
      included to support multiple rulesets at a location.

5.16.  DeviceValidity

   The DeviceValidity element is used for each device to
   indicate whether a device it is
   valid.  See Section 4.5.2.

   +---------------------------------------+
   |DeviceValidity                         |
   +----------------------------+----------+
   |deviceDesc:DeviceDescriptor | required |
   |isValid:boolean             | required |
   |reason:string               | optional |
   +----------------------------+----------+

   Parameters:

   deviceDesc:  The DeviceDescriptor (Section 5.2) that was used permitted to
      check use the spectrum.

   A typical sequence for validity is REQUIRED.
   isValid:  This using the Device Validation request is
   illustrated in Figure 5, where the Master Device already has a REQUIRED boolean value valid
   set of available spectrum for Slave Devices.  Note that indicates whether the
      Device is valid.
   reason:  If
   communication and protocol between the device identifier Slave Device and Master Device
   is not valid, outside the Database MAY
      include a reason.  The reason MAY be in any language and contain
      UTF-8 characters.  The length scope of this document.

   o  DEV_VALID_REQ (Section 4.6.1) is the value MUST NOT exceed 128
      octets.

5.17.  Error Element

   If the Database responds to a PAWS device-validation request
      message with an error, it
   MUST include an Error element.

   +----------------------------------+
   |Error

   o  DEV_VALID_RESP (Section 4.6.2) is the device-validation response
      message
      +------------+     +---------------+      +-------------------+
      |Slave Device|     | Master Device |      | Spectrum Database |
      +------------+     +---------------+      +-------------------+
          |                 |                           |
          | AVAIL_SPEC_REQ  |                           |
          |................>|                           |
          |                 |                           |
          |                 |    DEV_VALID_REQ          |
          |                 |-------------------------->|
          |                 |                           |
          |                 |    DEV_VALID_RESP         |
          |                 |<--------------------------|
          | AVAIL_SPEC_RESP |                           |
          |<................|                           |
          |                 |                           |
          | (SPECTRUM_USE)  |                           |
          |................>|   (SPECTRUM_USE_NOTIFY)   |
          |                 |-------------------------->|
          |                 |                           |
          |                 |    (SPECTRUM_USE_RESP)    |
          |                 |<--------------------------|

                                 Figure 5

4.6.1.  DEV_VALID_REQ

   +---------------------------------------------+
   |DEV_VALID_REQ                                |
   +----------------+-----------------+
   |code:int
   +----------------------------------+----------+
   |deviceDescs:list                  | required        |
   |message:string |---+
   |masterDeviceDesc:DeviceDescriptor | optional |
   |data:any   | see description
   +----------------------------------+----------+   |
   +----------------+-----------------+
                                                     V 1..*
                                    +----------------------+
                                    |DeviceDescriptor      |
                                    +----------------------+

   Parameters:

   code:  An integer code that indicates the error type is REQUIRED.
      Values MUST be within the range, -32768 to 32767, inclusive.
   message:

   deviceDescs:  A description of the error DeviceDescriptor (Section 5.2) list is OPTIONAL.  It MAY be in any
      language and contain UTF-8 characters.  The length of the value
      MUST NOT exceed 128 octets.
   data:  The Database MAY include additional data.  For some errors,
      additional data may be required (see Table 1).  The Device MUST
      ignore any data parameters it does not understand.

   The following table lists predefined and reserved error codes.  They
   are loosely grouped into the following categories:

   -100s:  Indicates compatibility issues, e.g., version mismatch,
      unsupported or unimplemented features.
   -200s:  Indicates that REQUIRED,
      which specifies the Device request contains an error list of Slave Devices that
      needs are to be modified before making another request.
   -300s:  Indicates authorization-related issues.

   Values that are not defined explicitly in the Error Codes Table
   (Table 1) below are unassigned.  To define new error codes, see PAWS
   Error Code Registry (Section 9.3).

   Code   Name             Description & Additional parameters
   ------ ---------------- ---------------------------------------------
   0      (reserved)
   -100   (reserved)
   -101   VERSION          The Database does not support the specified
                           version of the message.
   -102   UNSUPPORTED      The Database does not support the Device. For
                           example, it does not support the ruleset
                           specified in the request.
   -103   UNIMPLEMENTED
      validated.

   masterDeviceDesc:  The Database does not implement the Master Device MAY provide its own descriptor.

4.6.2.  DEV_VALID_RESP

   +---------------------------------------+
   |DEV_VALID_RESP                         |
   +----------------------------+----------+
   |deviceValidities:list       | required |----
   |databaseChange:DbUpdateSpec | optional
                           request or |   |
   +----------------------------+----------+   |
                                               V 1..*
                            +---------------------------------------+
                            |DeviceValidity                         |
                            +----------------------------+----------+
                            |deviceDesc:DeviceDescriptor | required |
                            |isValid:boolean             | required |
                            |reason:string               | optional feature.
   -104   OUTSIDE_COVERAGE The specified geo-location |
                            +----------------------------+----------+

   Parameters:

   deviceValidities:  A DeviceValidities (Section 5.16) list is outside REQUIRED
      to report the
                           coverage area list of the Database. Slave Devices and whether each listed device
      is valid.  The Database
                           MAY include a DbUpdateSpec (Section 5.7)
                           parameter to provide a list number of alternate
                           databases that might be appropriate for entries MUST match the
                           requested location. See OUTSIDE_COVERAGE
                           Error number of
      DeviceDescriptors (Section 5.17.1) for more details.

   -105   DATABASE_CHANGE  The Database has changed its URI. 5.2) listed in the DEV_VALID_REQ
      message.

   databaseChange:  The Database MAY include a DbUpdateSpec
      (Section 5.7) parameter in to notify the error response device of a change to provide devices with the Database
      URI, providing one or more alternate database URIs.  The Device device
      needs to use the
                           information to update its list of preconfigured databases to replace (only) its entry for the responding Database
      database with the
                           list of alternate database URIs. See
                           DATABASE_CHANGE Error (Section 5.17.2) for databases listed in the DbUpdateSpec.

5.  Protocol Parameters

   This section presents more details.
   -200   (reserved)
   -201   MISSING          A required parameter is missing. The Database
                           MUST include a list details of the required parameter
                           names. The Database MAY include only names of parameters that are missing, but MAY include
                           a full list. Including the full list of
                           missing parameters may reduce the number of
                           re-queries from make up the Device. See MISSING Error
                           (Section 5.17.3) for more details.
   -202   INVALID_VALUE    A parameter value is invalid in some way. The
                           Database SHOULD include a message indicating
                           which parameter
   PAWS request and why its value is invalid.
   -300   (reserved)
   -301   UNAUTHORIZED     The Device response messages.  It also includes a sub-section
   defining response codes.

5.1.  GeoLocation

   GeoLocation is not authorized to used to specify one of the
                           Database. Authorization may be determined following:

   o  A single point with optional uncertainty

   o  A region described by
                           the ruleset or be dependent on prior
                           arrangement between the Device and Database.
   -302   NOT_REGISTERED   Device registration required, but the Device a polygon

   These are represented using geometric shapes defined in Section 5 of
   "GEOPRIV Presence Information Data Format Location Object" [RFC5491],
   where:

   o  A "point" with uncertainty is not registered.
   -32000 (reserved)       Reserved for JSON-RPC error codes.
   to
   -32768

                           Table 1: Error Codes

5.17.1.  OUTSIDE_COVERAGE Error

   When represented using the error code Ellipse shape

   o  A region is OUTSIDE_COVERAGE, represented using the Database Polygon shape

   The coordinates are expressed using the WGS84 datum [WGS-84], and
   units are degrees or meters.  GeoLocation MAY also include an
   ErrorData element within its as the "data" field, and, if present,
   the ErrorData contains a DbUpdateSpec (Section 5.7) element that
   provides
   confidence level, expressed as a list of alternate databases that might percentage.  The confidence and
   uncertainty parameters may be appropriate required by some rulesets (see also
   Uncertainty and Confidence [I-D.ietf-geopriv-uncertainty]).

   The data model for
   the requested location. GeoLocation is illustrated below:

   +------------------------------------+
   |GeoLocation                         |
   +------------------+-----------------+
   |point:Ellipse     | see description |
   |region:Polygon    | see description |
   |confidence:int    | optional        |
   +------------------+-----------------+
   Note: point and region are mutually exclusive. Exactly one must
   be present.

   +-------------------------------+
   |Ellipse                        |
   +--------------------+----------+
   |center:Point        | required |--+
   |semiMajorAxis:float | optional |  |
   |semiMinorAxis:float | optional |  |
   |orientation:float   | optional |  |
   +--------------------+----------+  v
                              +---------------------------+
   |Error
                              |Point                      |
                              +----------------+----------+
   |code:int
                              |latitude:float  | required |
                              |longitude:float | required |
                              +----------------+----------+

   +-------------------------------+
   |Polygon                        |
   +-------------------+-----------+  4..* +---------------------------+
   |exterior:list      | required  |------>|Point                      |
   |message:string
   +-------------------+-----------+       +----------------+----------+
                                           |latitude:float  | optional required |    +-----------------------------+
   |data:ErrorData
                                           |longitude:float | optional |--->|ErrorData required |
                                           +----------------+----------+    +------------------+----------+
                                    |spec:DbUpdateSpec | optional |
                                    +------------------+----------+

5.17.2.  DATABASE_CHANGE Error

   When

   Parameters:

   point:  If present, it specifies the error code GeoLocation as a point.
      Paradoxically, a "point" is DATABASE_CHANGE, the Database MAY include parameterized using an
   ErrorData element within its Error response as Ellipse, where
      the "data" field, and,
   if center represents the location of the point and the distances
      along the major and minor axes represent the uncertainty.  The
      uncertainty values may be required, depending on the ruleset.
      Exactly one of "point" or "region" MUST be present.

   region:  If present, it specifies the ErrorData contains GeoLocation as a DbUpdateSpec (Section 5.7)
   element that provides region.
      Exactly one of "point" or "region" MUST be present.

   center:  The center refers to the location of a list GeoLocation point and
      is represented as the center of alternate databases.

   +---------------------------+
   |Error                      |
   +----------------+----------+
   |code:int        | required |
   |message:string  | optional |    +-----------------------------+
   |data:ErrorData  | optional |--->|ErrorData                    |
   +----------------+----------+    +------------------+----------+
                                    |spec:DbUpdateSpec | required |
                                    +------------------+----------+

5.17.3.  MISSING Error

   When an ellipse.

   latitude, longitude:  Floating-point numbers that express the
      latitude and longitude in degrees using the WGS84 datum [WGS-84].

   semiMajorAxis, semiMinorAxis:  This OPTIONAL parameter expresses the
      location uncertainty, expressed in meters.  It is parameterized
      using distances along the major and minor axes of the ellipse.
      The default value for each parameter is 0.

   orientation:  This defines the orientation of the ellipse, expressed
      as the rotation, in degrees, of the semi-major axis from North
      towards the East.  For example, when the uncertainty is greatest
      along the North-South direction, orientation is 0 degrees;
      conversely, if the error code uncertainty is MISSING, greatest along the Database MUST include an
   ErrorData element within its Error response as East-West
      direction, orientation is 90 degrees.  When orientation is not
      present, the "data" field, and default value is 0.

   exterior:  When GeoLocation describes a region, the ErrorData element MUST include "exterior"
      parameter refers to a list of latitude/longitude points that
      represents the missing required
   parameters and MAY include the list of all required parameters.

   +---------------------------+
   |Error                      |
   +----------------+----------+
   |code:int        | required |
   |message:string  | optional |    +---------------------------+
   |data:ErrorData  | required |--->|ErrorData                  |
   +----------------+----------+    +----------------+----------+ 1..*
                                    |parameters:list | required |--+
                                    +----------------+----------+  |
                                                                   v
                                                                 string

   Parameters:

   parameters:  List of one or more parameter names (strings).  The name vertices of a parameter is expressed using dotted notation, when
      appropriate, e.g., "deviceDesc.serialNumber".

6.  Message Encoding polygon.  The PAWS protocol first and last points
      MUST be the same.  Thus, a minimum of 4 points is encoded using JSON-RPC [JSON-RPC] (see also required.  The
   JavaScript Object Notation (JSON) Data Interchange Format [RFC7159]).
   Each component described in Protocol Functionalities (Section 4)
   corresponds to one or more JSON-RPC methods.  This section provides
   the JSON schema for each
      following polygon restrictions from [RFC5491] apply:

      *  A connecting line MUST NOT cross another connecting line of the protocol messages and parameters
         same polygon.

      *  The vertices MUST be defined in sections Protocol Functionalities (Section 4) and Protocol
   Parameters (Section 5).  JSON schemas are expressed using the format
   described by JSON Schema [I-D.zyp-json-schema], but a counter-clockwise direction,
         looking at them from above.

      *  The edges of a polygon are not intended
   to be used for formal validation.

   NOTE: In general, all messages defined by the shortest path between
         two points in this section space (not a geodesic curve).  Consequently, the
         length between two adjacent vertices SHOULD be restricted to a
         maximum of 130 km.

      *  All vertices are extensible
   by adding additional properties assumed to support ruleset-specific and
   database-specific requirements.  In all cases, be at the Device or Database
   MUST ignore any parameter it does not understand.

   NOTE: The JSON examples in this section may contain ellipses (...) same altitude.

      *  Polygon shapes SHOULD be restricted to
   represent additional properties or elements a maximum of 15 vertices
         (16 points that have been omitted in
   order to make includes the examples more concise.

6.1.  JSON-RPC Binding

   The JSON-RPC [JSON-RPC] protocol consists of two basic objects,
   Request and Response:
   o repeated vertex).

   confidence:  The JSON-RPC Request object encapsulates location confidence level, as a PAWS functionality
      (operation) and percentage, MAY be
      provided.  When this parameter is not provided, the request message
   o default value
      is 95.  Valid values range from 0 to 100, but, in practice,
      100-percent confidence is not achievable.  The JSON-RPC Response object encapsulates confidence value is
      meaningful only when GeoLocation refers to a PAWS response message
      and Error element point with
      uncertainty.

5.2.  DeviceDescriptor

   The Database device descriptor contains parameters that identify the specific
   device, such as its manufacturer serial number, manufacturer's ID,
   and Device MUST support JSON-RPC 2.0 encoding. any other device characteristics required by ruleset.

   +--------------------------------+
   |DeviceDescriptor                |
   +---------------------+----------+
   |serialNumber:string  | required |
   |manufacturerId:string| optional |
   |modelId:string       | optional |  1..*
   |rulesetIds:list      | optional |------>string
   |.....................|..........|
   |*other:any           | optional |
   +---------------------+----------+

   Parameters:

   serialNumber:  The JSON-RPC Request for PAWS has manufacturer's device serial number is REQUIRED.
      Its maximum length is 64 octets, conforming to the following form:

   {
     "jsonrpc": "2.0",
     "method": "string",
     "params": <PAWS_REQ>,
     "id": "string"
   }

   where "method" X.520
      [ITUT.X520.2008] recommendations.

   manufacturerId:  The manufacturer's ID is OPTIONAL, but may be
      required by some rulesets.  This represents the name of a PAWS functionality (operation), and
   <PAWS_REQ> represents one of the PAWS request objects associated with
   the method.  Method names are defined with the prefix,
   "spectrum.paws.".

   The non-error JSON-RPC Response for PAWS has device
      manufacturer, and therefore ought to be consistent across all
      devices from the following form:

   {
     "jsonrpc": "2.0",
     "result": <PAWS_RESP>,
     "id": "string"
   }

   where <PAWS_RESP> represents one same manufacturer and distinct from that of the PAWS response objects
   associated with the method. other
      manufacturers.  Its maximum length is 64 octets.

   modelId:  The error JSON-RPC Response device's model ID is OPTIONAL, but may be required by
      some rulesets.  Its maximum length is 64 octets.

   rulesetIds:  The list of identifiers for PAWS has the following form:

   {
     "jsonrpc": "2.0",
     "error": {
       "code": "integer",
       "message": "string",
       "data": "object"
     },
     "id": "string"
   }

   where the Error object and error codes are described rulesets supported by Error Element the
      device (see Ruleset ID Registry (Section 5.17).  The 9.1)).  A Database SHOULD attempt to use MAY
      require that the most specific
   applicable PAWS error code.  When an accurate one is device provides this list before servicing the
      device requests.  If the Database does not available,
   it SHOULD fall back to standard JSONRPC error codes as defined support any of the
      rulesets specified in
   JSONRPC specification.  For example, if the list, the Database receives invalid
   JSON from MAY refuse to service
      the Device, it should respond with "-32700", signifying a
   parse error.  As a last resort, device requests.  See RulesetInfo (Section 5.6) for discussion
      on ruleset identifier.  If present, the Database MAY send a suitable HTTP
   5xx response. list MUST contain at least
      one entry.

   other:  Depending on prior arrangement between a Database and Device, the
   Request and Response objects MAY contain additional parameters. ruleset, other parameters may be required.
      The Database or Device MUST ignore all parameters in the message it does not
      understand.

6.2.  init Method

   This section describes the encoding  See PAWS Parameters Registry (Section 9.2) for
      additional valid parameters and for the JSON-RPC
   "spectrum.paws.init" method that represents process for extending the Initialization
   functionality
      message with more parameters.  Additionally, see PAWS Ruleset ID
      Registry (Section 4.2).

6.2.1.  INIT_REQ Parameters

   The JSON encoding 9.1) for the valid set of parameters for each
      ruleset.

5.3.  AntennaCharacteristics

   Antenna characteristics provide additional information, such as the Initialization
   antenna height, antenna type, etc.  Whether antenna characteristics
   must be provided in a request message INIT_REQ
   (Section 4.2.1) is described depends on the device type and ruleset.
   Additionally, a parameter marked as optional may be required by some
   rulesets.

   +------------------------------------+
   |AntennaCharacteristics              |
   +-------------------------+----------+
   |height:float             | optional |
   |heightType:enum          | optional |
   |heightUncertainty:float  | optional |
   |.........................|..........|
   |*characteristics:        | optional |
   |   various               |          |
   +-------------------------+----------+

   Parameters:

   height:  The antenna height in meters.  Note that the following schema:

   {
     "name": "INIT_REQ",
     "type": "object",
     "properties": {
       "type": "INIT_REQ",
       "version": {
         "type": "string",
         "required": true
       },
       "deviceDesc": {
         "type": "DeviceDescriptor",
         "required": true
       },
       "location": {
         "type": "GeoLocation",
         "description": "The location of height may be
      negative.

   heightType:  Valid values are:

      AGL  Above ground level (default)

      AMSL  Above mean sea level

   heightUncertainty:  The height uncertainty in meters.

   NOTE: Depending on the ruleset, additional antenna characteristics
   may be required, such as:

   o  antenna direction
   o  antenna radiation pattern

   o  antenna gain

   o  antenna polarization

   These are not defined by the Device's antenna.
             Some rulesets mandate this to base protocol, but may be the
             Device's current location; others allow it added to be
             an anticipated position of the Device.",
         "required": true
       }
     }
   }

   Example "init" JSON-RPC request:

   {
    "jsonrpc": "2.0",
    "method": "spectrum.paws.init",
    "params": {
     "type": "INIT_REQ",
     "version": "1.0",
     "deviceDesc": {
      "serialNumber": "XXX",
      "fccId": "YYY",
      ...
     },
     "location": {
      "point": {
       "center": {"latitude": 37.0, "longitude": -101.3}
      }
     }
    },
    "id": "xxxxxx"
   }

6.2.2.  INIT_RESP
   PAWS Parameters

   The JSON encoding of the Initialization response message INIT_RESP Registry (Section 4.2.2) is described by the following schema:

   {
     "name": "INIT_RESP",
     "type": "object",
     "properties": {
       "type": "INIT_RESP",
       "version": {
         "type": "string",
         "required": true
       },
       "rulesetInfos": {
         "type": "array",
         "description": "List of rulesets and associated
             attributes 9.2), as needed.

5.4.  DeviceCapabilities

   Device capabilities provide additional information that govern the device at the location specified may be used
   by the device. The list MUST have at least one entry.",
         "items": "RulesetInfo",
         "required": true
       },
       "databaseChange": {
         "type": "DbUpdateSpec",
         "description": "Indicates that device to provide additional information to the Database URI will be
             changing. Devices need that
   can help it to update their configurations",
         "required": false
       }
     }
   }

   Example "init" JSON-RPC response:

   {
    "jsonrpc": "2.0",
    "result": {
     "type": "INIT_RESP",
     "version": "1.0",
     "rulesetInfos": [
       {
         "authority": "us",
         ...
       },
       ...
     ]
    },
    "id": "xxxxxx"
   }

6.3.  register Method

   This section describes determine available spectrum.  If the encoding for Database does
   not support device capabilities it MUST ignore the JSON-RPC
   "spectrum.paws.register" method that represents Device Registration
   functionality parameter
   altogether.

   +-------------------------------+
   |DeviceCapabilities             |
   +---------------------+---------+
   |frequencyRanges:list |optional |--+
   |.....................|.........|  |
   |*other:any           |optional |  |
   +---------------------+---------+  | 0..*
                                      V
                +--------------------------------+
                |FrequencyRange                  |
                +----------------------+---------+
                |startHz:float         |required |
                |stopHz:float          |required |
                +----------------------+---------+

   Parameters:

   frequencyRanges:  Optional FrequencyRange (Section 4.3).

6.3.1.  REGISTRATION_REQ Parameters

   The JSON encoding of 5.13) list.  Each
      FrequencyRange element contains start and stop frequencies in
      which the Registration request message
   REGISTRATION_REQ (Section 4.3.1) is described by device can operate.  When specified, the following
   schema:

   {
     "name": "REGISTRATION_REQ",
     "type": "object",
     "properties": {
       "type": "REGISTRATION_REQ",
       "version": {
         "type": "string",
         "required": true
       },
       "deviceDesc": {
         "type": "DeviceDescriptor",
         "required": true
       },
       "location": {
         "type": "GeoLocation",
         "description": "The location of Database SHOULD
      NOT return available spectrum that falls outside these ranges.

   other  Consult the Device's antenna.",
         "required": true
       },
       "deviceOwner": {
         "type": "DeviceOwner",
         "required": true
       },
       "antenna": {
         "type": "AntennaCharacteristics",
         "description": "Antenna characteristics, including its
             height and height type",
         "required": false
       }
     }
   }

   Example "register" JSON-RPC request:

   {
    "jsonrpc": "2.0",
    "method": "spectrum.paws.register",
    "params": {
     "type": "REGISTRATION_REQ",
     "version": "1.0",
     "deviceDesc": {
      "serialNumber": "XXX",
      "fccId": "YYY",
      ...
     },
     "deviceOwner": {
      "owner": [
       "vcard", [
        ["version", {}, "text", "4.0"],
        ["kind", {}, "text", "org"],
        ["fn", {}, "text", "Racafrax, Inc."]
       ]
      ],
      "operator": [
       "vcard", [
        ["version", {}, "text", "4.0"],
        ["fn", {}, "text", "John Frax"],
        ["adr", {}, "text",
         ["", "", "100 Main Street",
          "Summersville", "CA", "90034", "USA"
         ]
        ],
        ["tel", {}, "uri", "tel:+1-213-555-1212"],
        ["email", {}, "text", "j.frax@rackafrax.com"]
       ]
      ]
     },
     "location": {
      "point": {
       "center": {"latitude": 37.0, "longitude": -101.3}
      }
     },
     "antenna": {"height": 10.2, "heightType": "AGL"}
    },
    "id": "xxxxxx"
   }

6.3.2.  REGISTRATION_RESP PAWS Parameters

   The JSON encoding of the Registration response message
   REGISTRATION_RESP Registry (Section 4.3.2) 9.2) for
      possible additional parameters.  The Database MUST ignore all
      parameters it does not understand.

5.5.  DeviceOwner

   DeviceOwner contains information on device ownership that is described by the following
   schema:

   {
     "name": "REGISTRATION_RESP",
     "type": "object",
     "properties": {
       "type": "REGISTRATION_RESP",
       "version": {
         "type": "string",
         "required": true
       },
       "rulesetInfos": {
         "type": "array",
         "description": "List provided
   as part of device registration.  Some rulesets may require additional
   parameters.

   +-----------------------------+
   |DeviceOwner                  |
   +------------------+----------+
   |owner:vcard       | required |
   |operator:vcard    | optional |
   +------------------+----------+

   Parameters:

   owner:  The vCard contact information for which the individual or business
      that owns the device
             registration was successful. is REQUIRED.

   operator:  The list MUST have at
             least one entry.",
         "items": "RulesetInfo",
         "required": true
       },
       "databaseChange": {
         "type": "DbUpdateSpec",
         "description": "Indicates that vCard contact information for the device operator is
      OPTIONAL, but may be required by specific rulesets.

   NOTE: Depending on the ruleset, the Database URI will may be
             changing. Devices need required to update their configurations",
         "required": false
       }
     }
   }

   Example "register" JSON-RPC response:

   {
    "jsonrpc": "2.0",
    "result": {
     "type": "REGISTRATION_RESP",
     "version": "1.0",
     "rulesetInfos": [
       {
         "authority": "us",
         ...
       }
     ]
    },
    "id": "xxxxxx"
   }

6.4.  getSpectrum Method

   This section describes
   validate the encoding device-owner information.  In these cases, the Database
   MUST respond with an INVALID_VALUE error (see Error Codes
   (Section 5.17)) if validation fails.  See PAWS Ruleset ID Registry
   (Section 9.1) for ruleset-specific requirements on mandatory vCard
   properties.

   All contact information MUST be expressed using the JSON-RPC
   "spectrum.paws.getSpectrum" method structure defined
   by the "vCard Format Specification" [RFC6350], encoded in JSON
   [RFC7095].  Note that represents the single-
   location query vCard specification defines maximum lengths
   for each parameter, conforming to X.520 [ITUT.X520.2008]
   recommendations.

5.6.  RulesetInfo

   RulesetInfo contains parameters for the ruleset of a regulatory
   domain that is communicated using the Initialization component
   (Section 4.3), Device Registration (Section 4.4), and Available
   Spectrum Query functionality (Section 4.4) 4.5) components.

   +------------------------------------------+
   |RulesetInfo                               |
   +------------------------------------------+
   |authority:string        | required        |
   |rulesetId:string        | required        |
   |maxLocationChange:float | see description |
   |maxPollingSecs:int      | see description |
   |..........................................|
   |*other:any              | optional        |
   +------------------------+-----------------+

   Parameters:

   authority:  A string that enables a Device to obtain a set of available
   spectrum from indicates the Database.

6.4.1.  AVAIL_SPECTRUM_REQ Parameters

   The JSON encoding of regulatory domain to which
      the Available Spectrum request message
   AVAIL_SPECTRUM_REQ (Section 4.4.1) ruleset applies is described REQUIRED.  It will normally be a 2-letter
      country code defined by the following
   schema:

   {
     "name": "AVAIL_SPECTRUM_REQ",
     "type": "object",
     "properties": {
       "type": "AVAIL_SPECTRUM_REQ",
       "version": {
         "type": "string",
         "required": true
       },
       "deviceDesc": {
         "type": "DeviceDescriptor",
         "description": "Descriptor Country Codes - ISO 3166 [ISO3166-1].

   rulesetId:  The ID of a ruleset for the specified authority (see
      Ruleset ID Registry (Section 9.1)).  The device for which can use this to
      determine available spectrum.",
         "required": false
       },
       "location": {
         "type": "GeoLocation",
         "description": "The location of additional device behavior required by the Device's antenna. associated
      ruleset.  To define new ruleset IDs, see Defining Ruleset
      Identifiers (Section 8.1).

   maxLocationChange:  The maximum location change in meters is REQUIRED
      for Initialization Response (Section 4.3.2), but OPTIONAL
      otherwise.  Some rulesets regulatory domains mandate this to be that, when the Device's
             current location; others allow device
      changes location by more than this specified distance, it contact
      the Database to be an anticipated
             position of get the Device. When available spectrum for the request is made by a
             Master Device on behalf of a Slave Device, new location.
      If this value is provided by the
             location Database within the context of an
      Available Spectrum Response (Section 4.5.2), it takes precedence
      over the Slave Device (optional), and value within the Master
             Device location is provided Initialization Response (Section 4.3.2).

   maxPollingSecs:  The maximum duration, in the masterDeviceLocation
             parameter.",
         "required": false
       },
       "owner": {
         "type": "DeviceOwner",
         "description": "May be required if the Device is not yet
             registered or if the DB does not implement a separate
             device-registration request.",
         "required": false
       },
       "antenna": {
         "type": "AntennaCharacteristics",
         "description": "Antenna characteristics, including its
             height and height type.",
         "required": false

       },
       "capabilities": {
         "type": "DeviceCapabilities",
         "description": "The Database SHOULD NOT return seconds, between requests
      for available spectrum that
             is incompatible with the specified capabilities.",
         "required": false
       },
       "masterDeviceDesc": {
         "type": "DeviceDescriptor",
         "description": "When the request is made by a Master Device
             on behalf of a Slave Device, this is REQUIRED for the descriptor of
             the Master Device.",
         "required": false
       },
       "masterDeviceLocation": {
         "type": "GeoLocation",
         "description": "When Initialization Response
      (Section 4.3.2), but OPTIONAL otherwise.  The device MUST contact
      the request is made by a Master Device
             on behalf of a Slave Device, Database to get available spectrum no less frequently than
      this duration.  If this value is provided within the location context of an
      Available Spectrum Response (Section 4.5.2), it takes precedence
      over the Master Device.",
         "required": false
       },
       "requestType": {
         "type": "string",
         "description": "Optional value that modifies within the request.
             Valid values depends Initialization Response (Section 4.3.2).

   other:  Depending on ruleset.",
         "required": false
       }
     }
   }

   Example "getSpectrum" JSON-RPC request:

   {
    "jsonrpc": "2.0",
    "method": "spectrum.paws.getSpectrum",
    "params": {
     "type": "AVAIL_SPECTRUM_REQ",
     "version": "1.0",
     "deviceDesc": {
      "serialNumber": "XXX",
      "fccId": "YYY",
      ...
     },
     "location": {
      "point": {
       "center": {"latitude": 37.0, "longitude": -101.3}
      }
     },
     "antenna": {"height": 10.2, "heightType": "AGL"}
    },
    "id": "xxxxxx"
   }

6.4.2.  AVAIL_SPECTRUM_RESP Parameters

   The JSON encoding of the Available Spectrum response ruleset, other parameters may be required.
      Devices MUST ignore all parameters in the message
   AVAIL_SPECTRUM_RESP it does not
      understand.  Consult the PAWS Parameters Registry (Section 4.4.2) 9.2)
      for possible additional parameters.

5.7.  DbUpdateSpec

   This element is described provided by the following
   schema:

   {
     "name": "AVAIL_SPECTRUM_RESP",
     "type": "object",
     "properties": {
       "type": "AVAIL_SPECTRUM_RESP",
       "version": {
         "type": "string",
         "required": true
       },
       "timestamp": {
         "type": "string",
         "description": "Timestamp Database to notify devices of an
   upcoming change to the Database URI.

   +-------------------------------+
   |DbUpdateSpec                   |
   +---------------------+---------+       +--------------------------+
   |databases:list       |required |------>|DatabaseSpec              |
   +---------------------+---------+  1..* +---------------+----------+
                                           |name:string    | required |
                                           |uri:string     | required |
                                           +---------------+----------+

   Parameters:

   databases:  List of one or more DatabaseSpec (Section 5.8) entries.
      A device needs to update its preconfigured entry for the
      responding database with the alternate databases listed in the
      DbUpdateSpec.

5.8.  DatabaseSpec

   This element contains the name and URI of a database.

   +--------------------------+
   |DatabaseSpec              |
   +---------------+----------+
   |name:string    | required |
   |uri:string     | required |
   +---------------+----------+

   Parameters:

   name:  The display name.  Its maximum length is 64 octets.

   uri:  The corresponding URI of the response, using
             YYYY-MM-DDThh:mm:ssZ RFC3339 format. This SHOULD be used
             by database.  Its maximum length is
      1024 octets.

5.9.  SpectrumSpec

   The SpectrumSpec element encapsulates the Device as a reference schedule of available
   spectrum for a ruleset.

   +---------------------------------------+
   |SpectrumSpec                           |
   +----------------------------+----------+
   |rulesetInfo:RulesetInfo     | required |
   |spectrumSchedules:list      | required |-----+
   |timeRange:EventTime         | optional |     |
   |frequencyRanges:list        | optional |     |
   |needsSpectrumReport:boolean | optional |     |
   |maxTotalBwHz:float          | optional |     |
   |maxContiguousBwHz:float     | optional |     |
   +----------------------------+----------+     |
                                                 | 1..*
                                                 V
                                      +-------------------------------+
                                      |SpectrumSchedule               |
                                      +--------------------+----------+
                                      |eventTime:EventTime | required |
                                      |spectra:list        | required |
                                      +--------------------+----------+

   Parameters:

   rulesetInfo:  RulesetInfo (Section 5.6) is REQUIRED to identify the start
      regulatory domain and stop times
             in ruleset to which the spectrum schedule",
         "format": "date-time",
         "required": true
       },
       "deviceDesc": {
         "type": "DeviceDescriptor",
         "required": true
       },
       "spectrumSpecs": {
         "type": "array",
         "description": "The Database MAY return more than one
             SpectrumSpec schedule
      applies (see Ruleset ID Registry (Section 9.1)).  The device needs
      to represent available spectrum for multiple
             rulesets at the specified location.",
         "items": "SpectrumSpec",
         "required": true
       },
       "databaseChange": {
         "type": "DbUpdateSpec",
         "description": "Indicates that use the Database URI will be
             changing. Devices need corresponding ruleset to update their configurations",
         "required": false
       }
     }
   } interpret the response.
      Values provided within rulesetInfo, such as maxLocationChange,
      take precedence over the values provided by the Initialization
      Procedure (Section 4.3).

   spectrumSchedules:  The following example "getSpectrum" JSON-RPC response contains:

   o  A SpectrumSchedule (Section 5.10) list is
      REQUIRED.  At least one schedule with two time ranges
   o  A spectrum profile for MUST be included.  More than one resolution bandwidth (6 MHz)

   The schemas for these (and other) nested objects
      schedule MAY be included to represent future changes to the
      available spectrum.  How far in advance a schedule may be found in provided
      depends on the
   Sub-message Schemas (Section 6.8) section.

   {
    "jsonrpc": "2.0",
    "result": {
     "type": "AVAIL_SPECTRUM_RESP",
     "version": "1.0",
     "timestamp": "2013-03-02T14:30:21Z",
     "deviceDesc": {
      "serialNumber": "XXX",
      "fccId": "YYY",
      ...
     },
     "spectrumSpecs": [
      {
       "rulesetInfo": {
         "authority": "us",
         ...
       },
       "needsSpectrumReport": false,
       "spectrumSchedules": [
        {
         "eventTime": {
          "startTime": "2013-03-02T14:30:21Z",
          "stopTime": "2013-03-02T20:00:00Z"
         },
         "spectra": [
           {
            "resolutionBwHz": 6e6,
            "profiles": [
              ...
              [
               {"hz":5.18e8, "dbm":30.0},
               {"hz":5.36e8, "dbm":30.0},
               {"hz":5.36e8, "dbm":36.0},
               {"hz":5.42e8, "dbm":36.0}
              ],
              [
               {"hz":6.20e8, "dbm":30.0},
               {"hz":6.26e8, "dbm":30.0}
              ],
              ...
            ]
           }
         ]
        },
        {
         "eventTime": {
          "startTime": "2013-03-02T22:00:00Z",
          "stopTime": "2013-03-03T14:30:21Z"
         },
         "spectra": [
          ...
         ]
        }
       ]
      }
     ]
    },
    "id": "xxxxxx"
   }

   The following example "getSpectrum" JSON-RPC response includes a
   spectrum profile that contains specifications for two different
   bandwidth resolutions (6 MHz ruleset.  If more than one schedule is included,
      the eventTime intervals MUST be disjoint and 100 kHz):

   {
    "jsonrpc": "2.0",
    "result": {
     "type": "AVAIL_SPECTRUM_RESP",
     "version": "1.0",
     "timestamp": "2013-03-02T14:30:21Z",
     "deviceDesc": {
      "serialNumber": "XXX",
      ...
     },
     "spectrumSpecs": [
      {
       "rulesetInfo": {
         "authority": "xx",
         ...
       },
       "needsSpectrumReport": false,
       "spectrumSchedules": [
        {
         "eventTime": {
          "startTime": "2013-03-02T14:30:21Z",
          "stopTime": "2013-03-02T20:00:00Z"
         },
         "spectra": [
           {
            "resolutionBwHz": 6e6,
            "profiles": [
              ...
              [
               {"hz":5.18e8, "dbm":30.0},
               {"hz":5.36e8, "dbm":30.0},
               {"hz":5.36e8, "dbm":36.0},
               {"hz":5.42e8, "dbm":36.0}

              ],
              [
               {"hz":6.20e8, "dbm":30.0},
               {"hz":6.26e8, "dbm":30.0}
              ],
              ...
            ]
           },
           {
            "resolutionBwHz": 1e5,
            "profiles": [
              ...
              [
               {"hz":5.18e8, "dbm":27.0},
               {"hz":5.36e8, "dbm":27.0},
               {"hz":5.36e8, "dbm":30.0},
               {"hz":5.42e8, "dbm":30.0}
              ],
              [
               {"hz":6.20e8, "dbm":27.0},
               {"hz":6.26e8, "dbm":27.0}
              ],
              ...
            ]
           }
         ]
        },
        {
         "eventTime": {
          "startTime": "2013-03-02T22:00:00Z",
          "stopTime": "2013-03-03T14:30:21Z"
         },
         "spectra": [
          ...
         ]
        }
       ]
      }
     ]
    },
    "id": "xxxxxx"
   }

6.5.  getSpectrumBatch Method

   This section describes MUST be sorted in
      increasing time.  A gap in the encoding time schedule indicates no
      available spectrum during that time-interval gap.

   timeRange:  The time range for which the JSON-RPC
   "spectrum.paws.getSpectrumBatch" method specification is
      comprehensive is OPTIONAL.  When specified, any gaps in time
      intervals within the "spectrumSchedules" element that represents overlaps
      with the multiple-
   location query of range specified by "timeRange" are interpreted by the Available Spectrum Query functionality
   (Section 4.4) that enables a Device to obtain a set of
      device as time intervals in which there is no available
   spectrum spectrum.

   frequencyRanges:  The frequency ranges for multiple locations from which the Database.

6.5.1.  AVAIL_SPECTRUM_BATCH_REQ Parameters

   The JSON encoding specification is
      comprehensive is OPTIONAL.  It is a list of the Batch Available Spectrum request
   AVAIL_SPECTRUM_BATCH_REQ disjoint
      FrequencyRange (Section 4.4.3) is described 5.13) entries.  When specified, it
      typically corresponds to the frequency ranges governed by the
   following schema.  This an OPTIONAL feature of
      ruleset, e.g., for TV whitespace, the Database.

   {
     "name": "AVAIL_SPECTRUM_BATCH_REQ",
     "type": "object",
     "properties": {
       "type": "AVAIL_SPECTRUM_BATCH_REQ",
       "version": {
         "type": "string",
         "required": true
        },
       "deviceDesc": {
         "type": "DeviceDescriptor",
         "description": "Descriptor frequency ranges can
      correspond to the VHF and UHF bands of the associated regulatory
      domain.  A device can combine this information with the available-
      spectrum specification within the "spectrumSchedules" element to
      distinguish between "unavailable spectrum" and "spectrum for which to
             determine available spectrum.",
         "required":
      no information has been provided".

   needsSpectrumReport:  The Database MAY return true
       },
       "locations": {
         "type": "array",
         "description": "At least one device location for this parameter
      if spectrumSchedules list is required.
             Additional (anticipated) locations can also be included,
             as permitted by non-empty; otherwise, the ruleset. When Database
      MAY omit this parameter altogether, in which case, the default
      value is false.  If this parameter is present and its value is
      true, the device sends a SPECTRUM_USE_NOTIFY (Section 4.5.5)
      message to the Database; otherwise, the device SHOULD NOT send the request is
             made by
      SPECTRUM_USE_NOTIFY message.  Some rulesets mandate this value to
      be true.

   maxTotalBwHz:  The Database MAY return a Master Device constraint on behalf of a Slave Device, these
             are locations of the Slave Device.",
         "items": "GeoLocation",
         "required": true
       },
       "owner": {
         "type": "DeviceOwner",
         "description": "May maximum
      total bandwidth (in Hertz) allowed, which may or may not be required if
      contiguous.  Some rulesets mandate the Device is not yet
             registered or if Database to return this
      parameter.  When present in the DB response, the device needs to
      apply this constraint to its spectrum-selection logic to ensure
      total bandwidth does not implement exceed this value.

   maxContiguousBwHz:  The Database MAY return a separate
             device-registration request.",
         "required": false
       },
       "antenna": {
         "type": "AntennaCharacteristics",
         "description": "Antenna characteristics, including its
             height and height type.",
         "required": false
       },
       "capabilities": {
         "type": "DeviceCapabilities",
         "description": "The constraint on the
      maximum contiguous bandwidth (in Hertz) allowed.  Some rulesets
      mandate the Database SHOULD NOT to return this parameter.  When present in
      the response, the device needs to apply this constraint to its
      spectrum-selection logic to ensure no single block of spectrum has
      bandwidth that
             is incompatible exceeds this value.

5.10.  SpectrumSchedule

   The SpectrumSchedule element combines EventTime (Section 5.14) with
   Spectrum (Section 5.11) to define a time period in which the specified capabilities.",
         "required": false
       },
       "masterDeviceDesc": {
         "type": "DeviceDescriptor",
         "description": "When spectrum
   is valid.

   +-------------------------------+
   |SpectrumSchedule               |
   +--------------------+----------+
   |eventTime:EventTime | required |        +--------------------+
   |spectra:list        | required |------->|Spectrum            |
   +--------------------+----------+   0..* +--------------------+
                                            |resolutionBwHz:float|
                                            |profiles:list       |
                                            +--------------------+

   Parameters:

   eventTime:  The EventTime (Section 5.14) is REQUIRED to express
      "when" this specification is valid.

   spectra:  The Spectrum (Section 5.11) list is REQUIRED to specify the request
      available spectrum and permissible power levels, one per
      resolutionBwHz.  The list MAY be empty when there is made no available
      spectrum.

5.11.  Spectrum

   Available spectrum can be characterized by a Master Device
             on behalf an ordered list of
   spectrum profiles that defines permissible power levels over a Slave Device, this is the descriptor set of
   frequency ranges.  Each Spectrum element defines permissible power
   levels as maximum power spectral densities over a specified
   resolution bandwidth, "resolutionBwHz".  Note that the Master Device.",
         "required": false
       },
       "masterDeviceLocation": {
         "type": "GeoLocation",
         "description": "When spectrum
   profiles represent the request is made "availability mask", as defined by the
   governing rule set; they are not intended to encode device-level
   transmission-mask requirements.

   o  To support a Master Device
             on behalf of a Slave Device, this is ruleset that defines different "wide-band" and
      "narrow-band" power levels, PAWS allows multiple Spectrum elements
      to be included in the location of available-spectrum response, each with a
      different resolution bandwidth.

   o  When multiple Spectrum elements are included in the Master Device.",
         "required": false
       },
       "requestType": {
         "type": "string",
         "description": "Optional value response, each
      represents a constraint that modifies the request.
             Valid values depends on device must satisfy (logical
      AND).

   o  Each Spectrum element covers the ruleset.",
         "required": false
       }
     }
   }

   Example "getSpectrumBatch" JSON-RPC request:

   {
    "jsonrpc": "2.0",
    "method": "spectrum.paws.getSpectrumBatch",
    "params": {
     "type": "AVAIL_SPECTRUM_BATCH_REQ",
     "version": "1.0",
     "deviceDesc": {
      "serialNumber": "XXX",
      "fccId": "YYY",
      ...
     },
     "locations": [
      {
       "point": {
        "center": {"latitude": 37.0, "longitude": -101.3}
       }
      },
      {
       "point": {
        "center": {"latitude": 37.0005, "longitude": -101.3005}
       }
      },
      ...
     ],
     "antenna": {"height": 10.2, "heightType": "AGL"}
    },
    "id": "xxxxxx"
   }

6.5.2.  AVAIL_SPECTRUM_BATCH_RESP Parameters

   The JSON encoding range of the Batch Available Spectrum response
   AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4) is described frequencies governed by
      a ruleset, rather than splitting the
   following schema:

   {
     "name": "AVAIL_SPECTRUM_BATCH_RESP",
     "type": "object",
     "properties": {
       "type": "AVAIL_SPECTRUM_BATCH_RESP",
       "version": {
         "type": "string",
         "required": true
        },
       "timestamp": {
         "type": "string",
         "description": "Timestamp of frequencies across multiple
      Spectrum elements for the response, using
             YYYY-MM-DDThh:mm:ssZ RFC3339 format. This SHOULD be used
             by same resolution bandwidth.

   o  Each spectrum profile represents the Device as maximum permissible power
      spectral density over a reference contiguous range of frequencies.

   o  When multiple spectrum profiles are included, they MUST be
      disjoint and MUST be ordered in non-decreasing frequency value.

   o  Gaps in frequencies between consecutive spectrum profiles
      represent unavailability for those frequencies.

   The following figure illustrates the start Spectrum element and stop times
             in the
   SpectrumProfile list.

   +-------------------------------+
   |Spectrum                       |
   +---------------------+---------+
   |resolutionBwHz:float |required |
   |profiles:list        |required |---+
   +---------------------+---------+   |  0..*
                                       V
                 +-----------------------------+
                 |SpectrumProfile              |
                 +-------------------+---------+
                 |list               |required |
                 +-------------------+---------+
                                       |
                                       V 2..*
                  +--------------------------+
                  |SpectrumProfilePoint      |
                  +----------------+---------+
                  |hz:float        |required |
                  |dbm:float       |required |
                  +----------------+---------+

   Parameters:

   resolutionBwHz:  This parameter defines the resolution bandwidth (in
      Hertz) over which permissible power spectral density is defined.
      For example, FCC regulation would require one spectrum schedule",
         "format": "date-time",
         "required": true
       },
       "deviceDesc": {
         "type": "DeviceDescriptor",
         "required": true
       },
       "geoSpectrumSpecs": {
         "type": "array",
         "description": "A list
      specification at a bandwidth of locations 6MHz, and available spectrum at
             each location. For each location, there may be more than
             one SpectrumSpec element to support more than one ruleset ETSI regulation would
      require two specifications, at that location.",
         "items": "GeoSpectrumSpec",
         "required": true
       },
       "databaseChange": {
         "type": "DbUpdateSpec",
         "description": "Indicates that the Database URI will 0.1MHz and 8MHz.

   profiles:   A SpectrumProfile (Section 5.12) list specifies
      permissible power levels over a set of frequency ranges.  The list
      MAY be
             changing. Devices need to update their configurations",
         "required": false
       }
     }
   } empty if there is no available spectrum.

   The following example "getSpectrumBatch" JSON-RPC response
   illustrates a batch response that contains spectrum specifications shows permitted power spectral densities for two locations:

   {
    "jsonrpc": "2.0",
    "result": {
     "type": "AVAIL_SPECTRUM_BATCH_RESP",
     "version": "1.0",
     "timestamp": "2013-03-02T14:30:21Z",
     "deviceDesc": {
      "serialNumber": "XXX",
      "fccId": "YYY",
      ...
     },
     "geoSpectrumSpecs": a
   single resolution bandwidth of 6MHz (for illustrative purposes only):

   [
     {
       "location": {
        "point": {
         "center": {"latitude": 37.0, "longitude": -101.3}
        }
       },
       "spectrumSpecs":
       "resolutionBwHz": 6e6,
       "profiles": [
        {
         "rulesetInfo": {
          "authority": "us",
          ...
         },
         "needsSpectrumReport": false,
         "spectrumSchedules":
         [
          {
           "eventTime": {
            "startTime": "2013-03-02T14:30:21Z",
            "stopTime": "2013-03-02T20:00:00Z"
           },
           "spectra":
           {"hz": 5.18e8, "dbm": 30.0},
           {"hz": 5.30e8, "dbm": 30.0}
         ],
         ...
       ]
     }
   ]

   This is interpreted as:

   o  Over any 6MHz within the frequency range, [518MHz, 530MHz),
      maximum permitted power is 30.0dBm (1000mW)

   Consider now an example with two different sets of permitted power
   spectral densities for the same set of frequencies over different
   resolution bandwidths (for illustrative purposes only):

   [
     {
       "resolutionBwHz": 6e6,
       "profiles": [
                ...
         [
                 {"hz":5.18e8, "dbm":30.0},
                 {"hz":5.36e8, "dbm":30.0},
                 {"hz":5.36e8, "dbm":36.0},
                 {"hz":5.42e8, "dbm":36.0}
           {"hz": 5.18e8, "dbm": 30.0},
           {"hz": 5.30e8, "dbm": 30.0}
         ],
         ...
       ]
     },
     {
       "resolutionBwHz": 1e5,
       "profiles": [
                 {"hz":6.20e8, "dbm":30.0},
                 {"hz":6.26e8, "dbm":30.0}
         [
           {"hz": 5.18e8, "dbm": 27.0},
           {"hz": 5.30e8, "dbm": 27.0}
         ],
         ...
       ]
     }
   ]
          },
          {
           "eventTime":

   This is interpreted as:

   o  Over any 6MHz within the frequency range, [518MHz, 530MHz),
      maximum permitted power is 30.0dBm (1000mW), and

   o  Over any 100 kHz within the frequency range, [518MHz, 530MHz),
      maximum permitted power is 27.0dBm (500mW)

   This would allow, for example, operating two 100kHz sub-channels
   within the indicated 12MHz range at 500mW each, totaling 1000mW.  Of
   course, many combinations are possible, as long as they satisfy both
   conditions.

   The following example encodes multiple (two) spectrum profiles, each
   having a gap from 530 MHz to 536 MHz (for illustrative purposes
   only):

   [
     {
            "startTime": "2013-03-02T22:00:00Z",
            "stopTime": "2013-03-03T14:30:21Z"
           },
           "spectra":
       "resolutionBwHz": 6e6,
       "profiles": [
         [
           {"hz": 5.18e8, "dbm": 30.0},
           {"hz": 5.24e8, "dbm": 30.0},
           {"hz": 5.24e8, "dbm": 36.0},
           {"hz": 5.30e8, "dbm": 36.0}
         ],
         [
           {"hz": 5.36e8, "dbm": 30.0},
           {"hz": 5.42e8, "dbm": 30.0}
         ],
         ...
       ]
          }
         ]
        }
       ]
     },
     {
       "location": {
        "point": {
         "center": {"latitude": 37.0005, "longitude": -101.3005}
        }
       },
       "spectrumSpecs":
       "resolutionBwHz": 1e5,
       "profiles": [
         [
           {"hz": 5.18e8, "dbm": 27.0},
           {"hz": 5.24e8, "dbm": 27.0},
           {"hz": 5.24e8, "dbm": 30.0},
           {"hz": 5.30e8, "dbm": 30.0}
         ],
         [
           {"hz": 5.36e8, "dbm": 27.0},
           {"hz": 5.42e8, "dbm": 27.0}
         ],
         ...
       ]
     }
   ]
    },
    "id": "xxxxxx"
   }

6.6.  notifySpectrumUse Method

   This section describes

5.12.  SpectrumProfile

   A spectrum profile is characterized by an ordered list of (frequency,
   power) points that represents the shape of maximum permissible power
   levels over a range of frequencies as a piecewise linear curve.

   o  It MUST contain a minimum of two entries.

   o  The entries in the list MUST be ordered in non-decreasing
      frequency values.

   o  Two consecutive points MAY have the same frequency value to
      represent a "step function".

   o  Three or more points MUST NOT share the same frequency value.

   o  The first frequency is inclusive; the last frequency is exclusive.

   NOTE: This encoding for allows presentation of "ramps" where the JSON-RPC
   "spectrum.paws.notifySpectrumUse" method that represents slope of
   a line segment may be finite and non-zero.

   The following figure illustrates the
   Spectrum-usage notification SpectrumProfile element.

   +-------------------------------+
   |SpectrumProfile                |
   +---------------------+---------+
   |list                 |required |---+
   +---------------------+---------+   |  2..*
                                       V
                 +--------------------------+
                 |SpectrumProfilePoint      |
                 +----------------+---------+
                 |hz:float        |required |
                 |dbm:float       |required |
                 +----------------+---------+

   Parameters of each point in the profile:

   hz:  The frequency, in Hertz, at which the power level is defined.

   dbm:   The power level, expressed as dBm per resolution bandwidth, as
      defined by the "resolutionBwHz" element of the enclosing Spectrum
      (Section 5.11) element.

5.13.  FrequencyRange

   FrequencyRange specifies a frequency range.

   +--------------------------------+
   |FrequencyRange                  |
   +----------------------+---------+
   |startHz:float         |required |
   |stopHz:float          |required |
   +----------------------+---------+

   Parameters:

   startHz:  The inclusive start of the Available Spectrum Query
   functionality (Section 4.4.5) that notifies the Database frequency range (in Hertz) is
      REQUIRED.

   stopHz:  The exclusive end of
   anticipated spectrum usage.

6.6.1.  SPECTRUM_USE_NOTIFY Parameters the frequency range (in Hertz) is
      REQUIRED.

5.14.  EventTime

   The JSON encoding EventTime element specifies the start and stop times of an
   "event".  This is used to indicate the time period for which a
   Spectrum Notification message
   SPECTRUM_USE_NOTIFY (Section 4.4.5) 5.11) is described by the following
   schema:

   {
     "name": "SPECTRUM_USE_NOTIFY",
     "type": "object",
     "properties": {
       "type": "SPECTRUM_USE_NOTIFY",
       "version": {
         "type": "string",
         "required": true
       },
       "deviceDesc": {
         "type": "DeviceDescriptor",
         "required": true
       },
       "location": {
         "type": "GeoLocation",
         "description": "The location valid.

   +---------------------------+
   |EventTime                  |
   +-----------------+---------+
   |startTime:string |required |
   |stopTime:string  |required |
   +-----------------+---------+

   Parameters:

   startTime:  The inclusive start of the Device. When event is REQUIRED.

   stopTime:  The exclusive end of the
             notification event is made REQUIRED.

   Both times are expressed using the format, YYYY-MM-DDThh:mm:ssZ, as
   defined by a Master Device "Date and Time on behalf the Internet: Timestamps" [RFC3339].
   The times MUST be expressed using UTC.

   A device that does not have access to the current date and time MUST
   use the timestamp at the top-level of the response message as a Slave Device, this is
   substitute for the location of current time (see Available Spectrum Response
   (Section 4.5.2) and Available Spectrum Batch Response
   (Section 4.5.4)).  E.g.,

   o  (startTime - timestamp) gives the
             Slave Device.",
         "required": false
       },
       "masterDeviceDesc": {
         "type": "DeviceDescriptor",
         "description": "When duration that a device must wait
      before the notification event becomes "active".  If the value is made by a
             Master Device on behalf of a Slave Device, this zero or
      negative, the event is already active.

   o  If the descriptor of event is already active, (stopTime - timestamp) is the Master Device.",
         "required": false
       },
       "masterDeviceLocation": {
         "type": "GeoLocation",
         "description": "When
      duration that the event remains active.  If the notification value is made by zero or
      negative, the
             Master Device on behalf of event is no longer active and MUST be ignored.

5.15.  GeoSpectrumSpec

   The GeoSpectrumSpec element encapsulates the available spectrum for a Slave Device, this
   location.  It is returned within a AVAIL_SPECTRUM_BATCH_RESP
   (Section 4.5.4) batch response that contains multiple GeoSpectrumSpec
   entries, each matching a location provided in the batch request.

   +----------------------------------+
   |GeoSpectrumSpec                   |
   +-----------------------+----------+
   |location:GeoLocation   | required |
   |spectrumSpecs:list     | required |-------+
   +-----------------------+----------+       |
                                              | 1..*
                                              V
                                      +--------------+
                                      | SpectrumSpec |
                                      +--------------+

   Parameters:

   location:  The GeoLocation (Section 5.1) identifies the location of at
      which the Master Device.",
         "required": false
       },
       "spectra": {
         "type": "array",
         "description": "The spectrum anticipated to be used by
             the Device.",
         "items": "Spectrum",
         "required": true
       }
     }
   }

   Example "notifySpectrumUse" JSON-RPC notification:

   {
    "jsonrpc": "2.0",
    "method": "spectrum.paws.notifySpectrumUse",
    "params": {
     "type": "SPECTRUM_USE_NOTIFY",
     "version": "1.0",
     "deviceDesc": {
      "serialNumber": "XXX",
      "fccId": "YYY",
      ...
     },
     "location": {
      "point": {
       "center": {"latitude": 37.0005, "longitude": -101.3005}
      }
     },
     "spectra": [
      {
       "resolutionBwHz": 6e6,
       "profiles": [
         [
           {"hz":5.18e8, "dbm":30.0},
           {"hz":5.24e8, "dbm":30.0}
         ]
       ]
      }
     ]
    },
    "id": "xxxxxx"
   }

6.6.2.  SPECTRUM_USE_RESP Parameters schedule applies.

   spectrumSpecs:  The JSON encoding of the Spectrum-usage response SPECTRUM_USE_RESP SpectrumSpec (Section 4.4.6) 5.9) list is described by the following schema:

   {
     "name": "SPECTRUM_USE_RESP",
     "type": "object",
     "properties": {
       "type": "SPECTRUM_USE_RESP",
       "version": {
         "type": "string",
         "required": true
       }
     }
   }
   Example "notifySpectrumUse" JSON-RPC response:

   {
    "jsonrpc": "2.0",
    "result": {
     "type": "SPECTRUM_USE_RESP",
     "version": "1.0"
    },
    "id": "xxxxxx"
   }

6.7.  verifyDevice Method

   This section describes the encoding REQUIRED.  At
      least one entry MUST be included.  Each entry represents schedules
      of available spectrum for a ruleset.  More than one entry MAY be
      included to support multiple rulesets at a location.

5.16.  DeviceValidity

   The DeviceValidity element is used to indicate whether a device is
   valid.  See Section 4.6.2.

   +---------------------------------------+
   |DeviceValidity                         |
   +----------------------------+----------+
   |deviceDesc:DeviceDescriptor | required |
   |isValid:boolean             | required |
   |reason:string               | optional |
   +----------------------------+----------+

   Parameters:

   deviceDesc:  The DeviceDescriptor (Section 5.2) that was used to
      check for the JSON-RPC
   "spectrum.paws.verifyDevice" method validity is REQUIRED.

   isValid:  This is a REQUIRED boolean value that represents indicates whether the Device
   Validation functionality (Section 4.5).  This
      device is used by valid.

   reason:  If the device identifier is not valid, the Database MAY
      include a Master
   Device to validate Slave Devices.

6.7.1.  DEV_VALID_REQ Parameters reason.  The JSON encoding of reason MAY be in any language.  Its maximum
      length is 128 octets.

5.17.  Error Element

   If the Device Validation Database responds to a PAWS request DEV_VALID_REQ
   (Section 4.5.1) message with an error, it
   MUST include an Error element.

   +----------------------------------+
   |Error                             |
   +----------------+-----------------+
   |code:int        | required        |
   |message:string  | optional        |
   |data:any        | see description |
   +----------------+-----------------+

   Parameters:

   code:  An integer code that indicates the error type is described by REQUIRED.
      Values MUST be within the following schema:

   {
     "name": "DEV_VALID_REQ",
     "type": "object",
     "properties": {
       "type": "DEV_VALID_REQ",
       "version": {
         "type": "string",
         "required": true
       },
       "deviceDescs": {
         "type": "array",
         "description": "List of Slave Devices range, -32768 to be validated",
         "items": "DeviceDescriptor",
         "required": true
       }
     }
   }

   Example "verifyDevice" JSON-RPC request:

   {
    "jsonrpc": "2.0",
    "method": "spectrum.paws.verifyDevice",
    "params": {
     "type": "DEV_VALID_REQ",
     "version": "1.0",
     "deviceDescs": [
      {
       "serialNumber": "XXX",
       "fccId": "YYY",
       ...
      },
      {
       "serialNumber": "XXX3",
       "fccId": "YYY2",
       ...
      },
      ...
     ]
    },
    "id": "xxxxxx"
   }

6.7.2.  DEV_VALID_RESP Parameters

   The JSON encoding 32767, inclusive.

   message:  A description of the Device Validation response DEV_VALID_RESP
   (Section 4.5.2) error is described by OPTIONAL.  It MAY be in any
      language.  Its maximum length is 128 octets.

   data:  The Database MAY include additional data.  For some errors,
      additional data may be required (see Table 1).  The device MUST
      ignore any data parameters it does not understand.

   The following table lists predefined and reserved error codes.  They
   are loosely grouped into the following schema:

   {
     "name": "DEV_VALID_RESP",
     "type": "object",
     "properties": {
       "type": "DEV_VALID_RESP",
       "version": {
         "type": "string",
         "required": true
       },
       "deviceValidities": {
         "type": "array",
         "description": "List of DeviceValidity objects categories:

   -100s:  Indicates compatibility issues, e.g., version mismatch,
      unsupported or unimplemented features.

   -200s:  Indicates that shows the
             validity of each device included in the original Device
             Validity Request message.",
         "items": "DeviceValidity",
         "required": true
       },
       "databaseChange": {
         "type": "DbUpdateSpec",
         "description": "Indicates request contains an error that
      needs to be modified before making another request.

   -300s:  Indicates authorization-related issues.

   Values that are not defined explicitly in the Error Codes
   Table (Table 1) below are unassigned.  To define new error codes, see
   PAWS Error Code Registry (Section 9.3).

   Code   Name             Description & Additional parameters
   ------ ---------------- ---------------------------------------------
   0      (reserved)
   -100   (reserved)
   -101   VERSION          The Database URI will be
             changing. Devices need to update their configurations",
         "required": false
       }
     }
   }

   Example "verifyDevice" JSON-RPC response:

   {
    "jsonrpc": "2.0",
    "result": {
     "type": "DEV_VALID_RESP",
     "version": "1.0",
     "deviceValidities": [
      {
       "deviceDesc": {
         "serialNumber": "XXX",
         "fccId": "YYY",
         ...
       },
       "isValid": true
      },
      {
       "deviceDesc": {
         "serialNumber": "XXX3",
         "fccId": "YYY2",
         ...
       },
       "isValid": false,
       "reason": "Not authorized"
      }
     ]
    },
    "id": "xxxxxx"
   }

6.8.  Sub-message Schemas does not support the specified
                           version of the message. This section defines error does not
                           use any additional data.
   -102   UNSUPPORTED      The Database does not support the schema for Protocol Parameters (Section 5)
   embedded device. For
                           example, it does not support the ruleset
                           specified in PAWS the request. This error does not
                           use any additional data.
   -103   UNIMPLEMENTED    The Database does not implement the optional
                           request and response messages.

6.8.1.  GeoLocation or optional feature. This parameter error does
                           not use any additional data.
   -104   OUTSIDE_COVERAGE The specified geolocation is used to specify outside the GeoLocation
                           coverage area of the Database. The Database
                           MAY include a DbUpdateSpec (Section 5.1) 5.7) to
                           provide a list of alternate databases that
                           might be appropriate for the Device. requested
                           location. See OUTSIDE_COVERAGE Error (Section
                           5.17.1) for more details.
   -105   DATABASE_CHANGE  The geometric shapes represent the JSON encoding shapes
   defined Database has changed its URI. The
                           Database MAY include a DbUpdateSpec (Section
                           5.7) in GEOPRIV Presence Information Data Format Location Object
   [RFC5491].

     {
       "name": "GeoLocation",
       "type": "object",
       "properties": {
         "point": {
           "description": "A single location, the error response to provide devices
                           with optional
               uncertainty measures. Exactly one of 'point' or 'region'
               must be present.",

           "type": "Ellipse",
           "required": false
         },
         "region": {
           "description": "A region described by a polygon. Exactly one of 'point' or 'region' must be present.",
           "type": "Polygon",
           "required": false
         },
         "confidence": {
           "description": "Confidence interval when location
               is a point with uncertainty. 0 more alternate database URIs. The
                           device needs to 100.",
           "type": "integer",
           "required": false,
           "default": 95
         }
       }
     }
     {
       "name": "Point",
       "type": "object",
       "properties": {
         "latitude": {
           "description": "Double-precision floating-point degrees.
               WGS84 datum.",
           "type": "number",
           "required": true
         },
         "longitude": {
           "type": "number",
           "description": "Double-precision floating-point degree.
               WGS84 datum.",
           "required": true
         }
       }
     }
     {
       "name": "Ellipse",
       "type": "object",
       "properties": {
         "center": {
           "type": "Point",
           "required": true
         },
         "semiMajorAxis": {
           "description": "Floating-point meters that describe
               location uncertainty along update its preconfigured
                           entry for the major axis of responding database with the ellipse.",

           "type": "number",
           "required": false,
           "default": 0
         },
         "semiMinorAxis": {
           "description": "Floating-point meters that describe
               location uncertainty along
                           alternate databases listed in the minor axis
                           DbUpdateSpec. See DATABASE_CHANGE Error
                           (Section 5.17.2) for more details.
   -200   (reserved)
   -201   MISSING          A required parameter is missing. The Database
                           MUST include a list of the ellipse.",
           "type": "number",
           "required": false,
           "default": 0
         },
         "orientation": {
           "description": "Orientation required parameter
                           names. The Database MAY include only names of
                           parameters that are missing, but MAY include
                           a full list.  Including the ellipse, as rotation full list of
                           missing parameters may reduce the major axis from North towards East. Degrees.",
           "type": "number",
           "required": false,
           "default": 0
         }
       }
     }
     {
       "name": "Polygon",
       "type": "object",
       "properties": {
         "exterior": {
           "description": "List number of Points
                           re-queries from the device. See MISSING Error
                           (Section 5.17.3) for more details.
   -202   INVALID_VALUE    A parameter value is invalid in counter-clockwise
               order. They MUST form some way. The
                           Database SHOULD include a loop with no edges that
               cross each other. First message indicating
                           which parameter and last points MUST why its value is invalid.
                           This error does not use any additional data.
   -300   (reserved)
   -301   UNAUTHORIZED     The device is not authorized to used the
                           Database. Authorization may be determined by
                           the same. Minimum of 4 points.",
           "type": "array",
           "items": "Point",
           "required": true
         }
       }
     }

6.8.2.  DeviceDescriptor

   The DeviceDescriptor (Section 5.2) contains parameters that identify ruleset or be dependent on prior
                           arrangement between the specific device, such as its manufacturer serial number, ruleset-
   specific ID (e.g., FCC ID), device and Database.
                           This error does not use any other additional data.
   -302   NOT_REGISTERED   Device registration required, but the device characteristics
   required by rulesets, such
                           is not registered.  This error does not use
                           any additional data.
   -32000 (reserved)       Reserved for JSON-RPC error codes.
   to
   -32768
                           Table 1: Error Codes

5.17.1.  OUTSIDE_COVERAGE Error

   When the error code is OUTSIDE_COVERAGE, the Database MAY include an
   ErrorData element within its Error response as device-type classification.  See
   Initial PAWS Parameters Registry Contents the "data" parameter,
   and, if present, the ErrorData contains a DbUpdateSpec (Section 9.2.2) for
   additional valid parameters, e.g., "fccId", "etsiEnDeviceType", etc.

     {
       "name": "DeviceDescriptor",
       "type": "object",
       "properties": {
         "serialNumber": {
           "type": "string",
           "required": true
         },
         "manufacturerId": {
           "type": "string",
           "required": false
         },
         "modelId": {
           "type": "string",
           "required": false
         },
         "rulesetIds": {
           "type": "array",
           "description": "List 5.7)
   element that provides a list of identifiers alternate databases that might be
   appropriate for rulesets supported
               by the device.",
           "items": "string",
           "required": false
         }
       }
     }

6.8.3.  AntennaCharacteristics

   AntennaCharacteristics (Section 5.3) provide additional information,
   such as requested location.

   +---------------------------+
   |Error                      |
   +----------------+----------+
   |code:int        | required |
   |message:string  | optional |    +-----------------------------+
   |data:ErrorData  | optional |--->|ErrorData                    |
   +----------------+----------+    +------------------+----------+
                                    |spec:DbUpdateSpec | optional |
                                    +------------------+----------+

5.17.2.  DATABASE_CHANGE Error

   When the error code is DATABASE_CHANGE, the antenna height, antenna type, etc.

    {
       "name": "AntennaCharacteristics",
       "type": "object",
       "properties": {
         "height": {
           "description": "Height of Database MAY include an
   ErrorData element within its Error response as the antenna, in meters",
           "type": "number",
           "required": false
         },
         "heightType": {
           "description": "Reference type for height:
               Above Ground Level (AGL), or Above Mean Sea
               Level (AMSL).",
           "enum": ["AGL","AMSL"],
           "default": "AGL",
           "required": false
         },
         "heightUncertainty": {
           "description": "Uncertainty of "data" parameter,
   and, if present, the height measurement,
               in meters.",
           "type": "number",
           "required": false
         }
       }
     }

6.8.4.  DeviceCapabilities

   Device capabilities ErrorData contains a DbUpdateSpec (Section 5.4) provide additional information 5.7)
   element that
   MAY be used by provides a list of alternate databases.

   +---------------------------+
   |Error                      |
   +----------------+----------+
   |code:int        | required |
   |message:string  | optional |    +-----------------------------+
   |data:ErrorData  | optional |--->|ErrorData                    |
   +----------------+----------+    +------------------+----------+
                                    |spec:DbUpdateSpec | required |
                                    +------------------+----------+

5.17.3.  MISSING Error

   When the Device to provide additional information to error code is MISSING, the Database to help MUST include an
   ErrorData element within its Error response as the Database determine available spectrum.  If "data" parameter,
   and the
   Database does not support device capabilities, it ErrorData element MUST ignore the
   parameter.

     {
       "name": "DeviceCapabilities",
       "type": "object",
       "description": "Device capabilities to help DB determine
           available spectrum. The DB SHOULD NOT return available
           spectrum that falls outside include a list of the device capabilities.",
       "properties": {
         "frequencyRanges": {
           "type": "array",
           "description": "The frequency ranges in which missing required
   parameters and MAY include the Device
               can operate.",
           "items": "FrequencyRange",
           "required": false
         }
       }
     }

6.8.5.  DeviceOwner

   The DeviceOwner (Section 5.5) list of all required parameters.

   +---------------------------+
   |Error                      |
   +----------------+----------+
   |code:int        | required |
   |message:string  | optional |    +---------------------------+
   |data:ErrorData  | required |--->|ErrorData                  |
   +----------------+----------+    +----------------+----------+ 1..*
                                    |parameters:list | required |--+
                                    +----------------+----------+  |
                                                                   v
                                                                 string

   Parameters:

   parameters:  List of one or more parameter contains device-owner
   information required as part names (strings).  The name
      of device registration.  Some rulesets
   require additional parameters and specific fields within a vCard.
   JSON encoding of vCard parameter is expressed using dotted notation, when
      appropriate, e.g., "deviceDesc.serialNumber".

6.  Message Encoding

   PAWS is encoded using JSON-RPC [JSON-RPC] (see also "The JavaScript
   Object Notation (JSON) Data Interchange Format" [RFC7159]).  Each
   component described in jCard: Protocol Functionalities (Section 4)
   corresponds to one or more JSON-RPC methods.  This section discusses
   how to encode the data models presented in Section 4 and Section 5
   into JSON and provides some example encodings.  The JSON format for
   vCard [RFC7095].

     {
       "name": "DeviceOwner",
       "type": "object",
       "description": "Device-owner information required as part of
           Device registration. Rulesets MAY require examples may
   contain ellipses (...) to represent additional parameters.",
       "properties": {
         "owner": {
           "type": "vCard",
           "description":"Contact information for the individual properties or business elements
   that owns have been omitted in order to make the device.",
           "required": true
         },
         "operator": {
           "type": "vCard",
           "description":"Contact information for examples more concise.

6.1.  JSON-RPC Binding

   The JSON-RPC [JSON-RPC] protocol consists of two basic objects,
   Request and Response:

   o  The JSON-RPC Request object encapsulates a PAWS functionality
      (operation) and the device operator.",
           "required": false
         }
       }
     }

   Example:

     {
       "deviceOwner": {
         "owner": [
           "vcard", [
             ["version", {}, "text", "4.0"],
             ["kind", {}, "text", "org"],
             ["fn", {}, "text", "Racafrax, Inc."]
           ]
         ],
         "operator": [
           "vcard", [
             ["version", {}, "text", "4.0"],
             ["fn", {}, "text", "John Frax"],
             ["adr", {}, "text",
               ["", "", "100 Main Street",
                "Summersville", "CA", "90034", "USA"
               ]
             ],
             ["tel", {}, "uri", "tel:+1-213-555-1212"],
             ["email", {}, "text", "j.frax@rackafrax.com"]
           ]
         ]
       }
     }

6.8.6.  RulesetInfo

   RulesetInfo (Section 5.6) contains parameters for request message

   o  The JSON-RPC Response object encapsulates a PAWS response message
      and Error element

   The Database and device MUST support JSON-RPC 2.0 encoding, with the ruleset of a
   regulatory domain
   restriction that is communicated using the Initialization
   component (Section 4.2).

     {
       "name": "RulesetInfo",
       "type": "object",
       "description": "The ruleset of a regulatory domain that is
           communicated to Devices "id" parameter in the Initialization Response
           message.",
       "properties": {
         "authority": {
           "type": "string",
           "description": "The regulatory authority at messages MUST be a string.

   The JSON-RPC Request for PAWS has the specified
               location. It following form:

   {
     "jsonrpc": "2.0",
     "method": "spectrum.paws.methodName",
     "params": <PAWS_REQ>,
     "id": "idString"
   }

   where "method" is the name of a 2-letter country codes PAWS functionality (operation), and
   <PAWS_REQ> represents one of the PAWS request messages associated
   with the method (see Section 4.3 through Section 4.6).  Method names
   are defined by
               ISO3166.",
           "required": true
         },
         "rulesetId": with the prefix, "spectrum.paws.".

   The non-error JSON-RPC Response for PAWS has the following form:

   {
           "type": "string",
           "description": "The identifier
     "jsonrpc": "2.0",
     "result": <PAWS_RESP>,
     "id": "idString"
   }

   where <PAWS_RESP> represents one of an applicable ruleset.",
           "required": true
         },
         "maxLocationChange": the PAWS response messages
   associated with the method.

   The error JSON-RPC Response for PAWS has the following form:

   {
           "type": "number",
           "description": "Maximum location change in meters.",
           "required": false
         },
         "maxPollingSecs":
     "jsonrpc": "2.0",
     "error": {
           "type": "integer",
           "description": "Maximum duration, in seconds, between
               requests for available spectrum.",
           "required": false
         }
       "code": -102,
       "message": "An appropriate error message.",
       "data": { ... }
     },
     "id": "idString"
   }

6.8.7.  DbUpdateSpec

   DbUpdateSpec

   where the "error" object corresponds to the Error Element
   (Section 5.7) contains 5.17), and "code" is an error code described in the same
   section.  The Database SHOULD attempt to use the most specific
   applicable PAWS error code.  When an accurate one or more database
   specifications.  It is used not available,
   it SHOULD fall back to indicate standard JSONRPC error codes as defined in
   JSONRPC specification.  For example, if the Database receives invalid
   JSON from the device, it should respond with "-32700", signifying a change to
   parse error.  As a last resort, the Database URI.

     {
       "name": "DbUpdateSpec",
       "type": "object",
       "description": "Specification for updates to MAY send a Database URI",
       "properties": {
         "databases": {
           "type": "array",
           "description": "The specification of one or more databases.",
           "item": "DatabaseSpec",
           "required": true
         }
       }
     }

6.8.8.  DatabaseSpec

   DatabaseSpec (Section 5.8) specifies suitable HTTP
   5xx response.

6.1.1.  Method Names

   Table 2 defines the name method name, request object, and URI of a database.

     {
       "name": "DatabaseSpec",
       "type": "object",
       "description": "Specification response object
   for a database",
       "properties": {
         "name": {
           "type": "string",
           "description": "The display name of a database.",
           "required": true
         },
         "uri": {
           "type": "string",
           "description": "The URI of a database.",
           "required": true
         }
       }
     }

6.8.9.  Spectrum

   Available Spectrum each functionality defined in Protocol Functionalities
   (Section 5.11) can logically be characterized by a
   list 4).

   +------------------------+--------------------+---------------------+
   | Method Name            | Request            | Response            |
   +------------------------+--------------------+---------------------+
   | spectrum.paws.init     | INIT_REQ (Section  | INIT_RESP (Section  |
   |                        | 4.3.1)             | 4.3.2)              |
   | spectrum.paws.register | REGISTRATION_REQ   | REGISTRATION_RESP   |
   |                        | (Section 4.4.1)    | (Section 4.4.2)     |
   | spectrum.paws.getSpect | AVAIL_SPECTRUM_REQ | AVAIL_SPECTRUM_RESP |
   | rum                    | (Section 4.5.1)    | (Section 4.5.2)     |
   | spectrum.paws.getSpect | AVAIL_SPECTRUM_BAT | AVAIL_SPECTRUM_BATC |
   | rumBatch               | CH_REQ (Section    | H_RESP (Section     |
   |                        | 4.5.3)             | 4.5.4)              |
   | spectrum.paws.notifySp | SPECTRUM_USE_NOTIF | SPECTRUM_USE_RESP   |
   | ectrumUse              | Y (Section 4.5.5)  | (Section 4.5.6)     |
   | spectrum.paws.verifyDe | DEV_VALID_REQ      | DEV_VALID_RESP      |
   | vice                   | (Section 4.6.1)    | (Section 4.6.2)     |
   +------------------------+--------------------+---------------------+

                                  Table 2

6.1.2.  JSON Encoding of SpectrumProfiles, each defining the shape Data Models

   JSON [RFC7159] encoding of the permissible
   power levels over a range of frequencies.

     {
       "name": "Spectrum",
       "type": "object",
       "description": "A per-bandwidth list of frequency ranges with
           permissible power levels. For example, In US, FCC
           requires only one spectrum specification at 6MHz
           bandwidth; ETSI requires two (at 0.1MHz data models described in Section 4 and
           8MHz).",
       "properties": {
         "resolutionBwHz": {
           "type": "number",
           "description": "Resolution bandwidth (Hz) over which
               permissible power spectral densities are defined.",
           "required": true
         },
         "profiles": {
           "type": "array",
           "description": "List
   Section 5 is straightforward:

   o  Each data model describes the contents of SpectrumProfile objects to specify
               permissible power levels, over a set JSON object

   o  Each parameter of frequency ranges,
               for a given resolutionBwHz. data model corresponds to a member of the
      corresponding JSON object

      *  The list MAY be empty when
               there parameter name of the data model is no available spectrum.",
           "items": "SpectrumProfile",
           "required": true
         }
       }
     }

     {
       "name": "SpectrumProfile",
       "type": "array",
       "description": "A list the same as the member
         name of (frequency, power) points. A minimum the JSON object

      *  The parameter data type describes the type of
           two entries is required.",
       "item": "SpectrumProfilePoint"
     }

     {
       "name": "SpectrumProfilePoint",
       "type": "object",
       "description": "A point defined by a frequency and power level
           at that frequency.",
       "properties": {
         "hz": {
           "type": "number",
           "description": "Frequency (Hz)",
           "required": true
         },
         "dbm": {
           "type": "number",
           "description": "Power (dBm) per resolution bandwidth the member value

   o  Primitive types map to JSON type, as
               defined by enclosing resolutionBwHz.",
           "required": described in Section 4,
      repeated here:

      string  A JSON string, restricted to UTF-8 encoding

      int  A JSON number, without a fractional or exponent part
      float  A JSON number

      boolean  One of the JSON values, true
         }
       }
     } or false

   o  The following example Spectrum message for list type maps to a resolution bandwidth JSON array, except that all values in the
      array are of
   6 MHz.  This example contains power levels for only two frequency
   segments: the same type

   o  From 518 MHz  When the parameter data type refers to 542 MHz another data model, that
      data model describes a nested JSON object

   o  From 620 MHz to 626 MHz
   In practice, this  The encoded JSON object for each of the Request and Response
      message would contain more (frequency, power)
   points to cover all frequencies governed by listed in the associated ruleset. Method Names Table (Table 2) also includes
      the following members:

      type  The name of the message, e.g., "INIT_REQ"

      version  The PAWS version, e.g., "1.0"

   See the Spectrum (Section 5.11) section following sections for a more detailed
   discussion on examples.

6.2.  Example Encoding: init Method

   An example of the representation. "init" JSON-RPC request is shown below;

   {
     "resolutionBwHz": 6e6,
     "profiles": [
       [
         {"hz":5.18e8, "dbm":30.0},
         {"hz":5.36e8, "dbm":30.0},
         {"hz":5.36e8, "dbm":36.0},
         {"hz":5.42e8, "dbm":36.0}
       ],
       [
         {"hz":6.20e8, "dbm":30.0},
         {"hz":6.26e8, "dbm":30.0}
       ]
     ]
   }

6.8.10.  FrequencyRange

   The FrequencyRange (Section 5.13) element describes a frequency range
   and permissible power level within the specified range.
    "jsonrpc": "2.0",
    "method": "spectrum.paws.init",
    "params": {
       "name": "FrequencyRange",
     "type": "object",
       "properties": {
         "startHz": "INIT_REQ",
     "version": "1.0",
     "deviceDesc": {
           "type": "number",
           "description": "The inclusive start of the frequency range.",
           "required": true
      "serialNumber": "XXX",
      "fccId": "YYY",
      "rulesetIds": ["FccTvBandWhiteSpace-2010"]
     },
         "stopHz":
     "location": {
           "type": "number",
           "description": "The exclusive end of the frequency range.",
           "required": true
      "point": {
       "center": {"latitude": 37.0, "longitude": -101.3}
      }
     }
    },
    "id": "xxxxxx"
   }

6.8.11.  EventTime

   The EventTime (Section 5.14) element specifies the start and stop
   times

   An example of an "event."  It is used to indicate the time period for
   which a Spectrum (Section 5.11) corresponding JSON-RPC response is valid.

     {
       "name": "EventTime",
       "type": "object",
       "properties": shown below:

   {
         "startTime":
    "jsonrpc": "2.0",
    "result": {
     "type": "string",
           "description": "YYYY-MM-DDThh:mm:ssZ RFC3339 format.
               Inclusive.",
           "format": "date-time",
           "required": false
         },
         "stopTime": "INIT_RESP",
     "version": "1.0",
     "rulesetInfos": [
       {
           "type": "string",
           "description": "YYYY-MM-DDThh:mm:ssZ RFC3339 format.
               Exclusive.",
           "format": "date-time",
           "required": false
         }
         "authority": "us",
         "rulesetId": "FccTvBandWhiteSpace-2010",
         "maxLocationChange": 100,
         "maxPollingSecs": 86400
       }
     ]
    },
    "id": "xxxxxx"
   }

6.8.12.  SpectrumSchedule

   The SpectrumSchedule (Section 5.10) element combines EventTime with
   Spectrum to define a time period during which

6.3.  Example Encoding: getSpectrum Method

   An example of the spectrum "getSpectrum" JSON-RPC request is valid. shown below:

   {
    "jsonrpc": "2.0",
    "method": "spectrum.paws.getSpectrum",
    "params": {
       "name": "SpectrumSchedule",
     "type": "object",
       "description": "The SpectrumSchedule element combines EventTime "AVAIL_SPECTRUM_REQ",
     "version": "1.0",
     "deviceDesc": {
      "serialNumber": "XXX",
      "fccId": "YYY",
      "rulesetIds": ["FccTvBandWhiteSpace-2010"]
     },
     "location": {
      "point": {
       "center": {"latitude": 37.0, "longitude": -101.3}
      }
     },
     "antenna": {"height": 10.2, "heightType": "AGL"}
    },
    "id": "xxxxxx"
   }

   The following example "getSpectrum" JSON-RPC response contains:

   o  A schedule with Spectrum to define a two time period during which ranges

   o  A spectrum
           is valid.",
       "properties": {
         "eventTime": {
           "type": "EventTime",
           "description": "Period when the spectra is valid.",
           "required": true
         },
         "spectra": {
           "type": "array",
           "description": "List of available spectra and permissible
               power levels; profile for one spectrum object per resolutionBwHz. resolution bandwidth (6 MHz)
   o  The power levels for two frequency segments are shown:

      *  From 518 MHz to 542 MHz

      *  From 620 MHz to 626 MHz

   o  In practice, each "profiles" list MAY be empty when there is no available spectrum.",
           "items": "Spectrum",
           "required": true
         }
       }
     }

6.8.13.  SpectrumSpec

   The JSON encoding of contains (frequency, power)
      points to cover all frequencies governed by the SpectrumSpec associated
      ruleset.  See the Spectrum (Section 5.9) element is
   described by 5.11) section for a more
      detailed discussion on the following schema: representation.

   {
    "jsonrpc": "2.0",
    "result": {
     "name": "SpectrumSpec",
     "type": "object",
     "description": "The SpectrumSpec element represents schedules of
         available spectrum for a ruleset.",
     "properties": "AVAIL_SPECTRUM_RESP",
     "version": "1.0",
     "timestamp": "2013-03-02T14:30:21Z",
     "deviceDesc": {
      "serialNumber": "XXX",
      "fccId": "YYY",
      "rulesetIds": ["FccTvBandWhiteSpace-2010"]
     },
     "spectrumSpecs": [
      {
       "rulesetInfo": {
         "type": "RulesetInfo",
         "description": "Indicates the active ruleset and
             attributes that define the applicable ruleset that
             govern the device.",
         "required": false
         "authority": "us",
         "rulesetId": "FccTvBandWhiteSpace-2010"
       },
       "needsSpectrumReport": false,
       "spectrumSchedules": [
        {
         "type": "array",
         "description": "The Database MAY return more than one
             schedule to represent future changes to the available
             spectrum. This array MAY be empty if no spectrum is
             available. If more than one is present, the event-time
             intervals MUST be sorted and MUST be disjoint.",

         "items": "SpectrumSchedule",
         "required": true
       },
       "timeRange":
         "eventTime": {
         "type": "EventTime",
         "description": "The time range for which the spectrumSchedules
             is comprehensive.",
         "required": false
          "startTime": "2013-03-02T14:30:21Z",
          "stopTime": "2013-03-02T20:00:00Z"
         },
       "frequencyRanges":
         "spectra": [
           {
         "type": "array",
         "description": "The frequency ranges for which the
             spectrumSchedules is comprehensive.",
         "items": "FrequencyRange",
         "required": false
            "resolutionBwHz": 6e6,
            "profiles": [
              ...
              [
               {"hz":5.18e8, "dbm":30.0},
               {"hz":5.36e8, "dbm":30.0},
               {"hz":5.36e8, "dbm":36.0},
               {"hz":5.42e8, "dbm":36.0}
              ],
              [
               {"hz":6.20e8, "dbm":30.0},
               {"hz":6.26e8, "dbm":30.0}
              ],
              ...
            ]
           }
         ]
        },
       "needsSpectrumReport":
        {
         "type": "boolean",
         "description": "Rulesets that require a
             spectrum-usage report from devices would mandate the
             Database to set this value to true.",
         "default": false,
         "required": false
       },
       "maxTotalBwHz":
         "eventTime": {
         "type": "number",
         "description": "Constraint on total bandwidth allowed,
             summed across all blocks of spectrum.",
         "required": false
          "startTime": "2013-03-02T22:00:00Z",
          "stopTime": "2013-03-03T14:30:21Z"
         },
       "maxContiguousBwHz": {
         "type": "number",
         "description": "Constraint on bandwidth allowed for
             any single block of spectrum.",
         "required": false
         "spectra": [
          ...
         ]
        }
       ]
      }
     ]
    },
    "id": "xxxxxx"
   }

6.8.14.  GeoSpectrumSpec

   The GeoSpectrumSpec (Section 5.15) element encapsulates the schedule
   of available spectrum at following example "getSpectrum" JSON-RPC response includes a location.

     {
       "name": "GeoSpectrumSpec",
       "type": "object",
       "description": "The GeoSpectrumSpec element encapsulates
           the schedule of available
   spectrum at a location.",
       "properties": profile that contains specifications for two different
   bandwidth resolutions (6 MHz and 100 kHz):

   {
         "location":
    "jsonrpc": "2.0",
    "result": {
     "type": "GeoLocation",
           "description": "The location at which the spectrum
               schedule applies.",
           "required": true "AVAIL_SPECTRUM_RESP",
     "version": "1.0",
     "timestamp": "2013-03-02T14:30:21Z",
     "deviceDesc": {
      "serialNumber": "XXX",
      ...
     },
     "spectrumSpecs": [
      {
           "type": "array",
           "description": "At least one element MUST be included.
               More than one element MAY be included
               to represent available spectrum for more than one
               ruleset.",
           "items": "SpectrumSpec",
           "required": true
         }
       }
     }

6.8.15.  DeviceValidity

   The DeviceValidity (Section 5.16) element is used to indicate whether
   a device is valid.  See Section 4.5.2.
       "rulesetInfo": {
       "name": "DeviceValidity",
       "type": "object",
       "description": "The DeviceValidity element specifies whether
           the device is valid.",
       "properties":
         "authority": "xx",
         ...
       },
       "needsSpectrumReport": false,
       "spectrumSchedules": [
        {
         "deviceDesc":
         "eventTime": {
           "type": "DeviceDescriptor",
           "required": true
          "startTime": "2013-03-02T14:30:21Z",
          "stopTime": "2013-03-02T20:00:00Z"
         },
         "isValid":
         "spectra": [
           {
           "type": "boolean",
           "description": "Boolean that indicates if the Device is
               valid",
           "required": true
            "resolutionBwHz": 6e6,
            "profiles": [
              ...
              [
               {"hz":5.18e8, "dbm":30.0},
               {"hz":5.36e8, "dbm":30.0},
               {"hz":5.36e8, "dbm":36.0},
               {"hz":5.42e8, "dbm":36.0}
              ],
              [
               {"hz":6.20e8, "dbm":30.0},
               {"hz":6.26e8, "dbm":30.0}
              ],
              ...
            ]
           },
           {
            "resolutionBwHz": 1e5,
            "profiles": [
              ...
              [
               {"hz":5.18e8, "dbm":27.0},
               {"hz":5.36e8, "dbm":27.0},
               {"hz":5.36e8, "dbm":30.0},
               {"hz":5.42e8, "dbm":30.0}
              ],
              [
               {"hz":6.20e8, "dbm":27.0},
               {"hz":6.26e8, "dbm":27.0}
              ],
              ...
            ]
           }
         ]
        },
         "reason":
        {
           "type": "string",
           "description": "If the device identifier is not valid,
               the Database MAY include a reason. The reason MAY be
               in any language.",
           "required": false
         "eventTime": {
          "startTime": "2013-03-02T22:00:00Z",
          "stopTime": "2013-03-03T14:30:21Z"
         },
         "spectra": [
          ...
         ]
        }

       ]
      }
     ]
    },
    "id": "xxxxxx"
   }

6.8.16.  Additional Properties

6.4.  Example Encoding: DeviceOwner vCard

   The Database or Device MAY include additional properties not
   explicitly listed in the schema elaborated DeviceOwner (Section 5.5) data model contains member values that
   are JSON encodings of vCard, as described in this document. "jCard: The
   Database and Device MUST ignore any such additional properties (and
   their associated values) that they do not understand. JSON format
   for vCard" [RFC7095].  An example fragment is provided below:

     {
       ...
       "deviceOwner": {
         "owner": [
           "vcard", [
             ["version", {}, "text", "4.0"],
             ["kind", {}, "text", "org"],
             ["fn", {}, "text", "Racafrax, Inc."]
           ]
         ],
         "operator": [
           "vcard", [
             ["version", {}, "text", "4.0"],
             ["fn", {}, "text", "John Frax"],
             ["adr", {}, "text",
               ["", "", "100 Main Street",
                "Summersville", "CA", "90034", "USA"
               ]
             ],
             ["tel", {}, "uri", "tel:+1-213-555-1212"],
             ["email", {}, "text", "j.frax@rackafrax.com"]
           ]
         ]
       }
     }

7.  HTTPS Binding

   This section describes the use of HTTP over TLS (HTTPS) HTTP "HTTP Over TLS TLS" [RFC2818] (HTTPS)
   as the transport transfer mechanism for the PAWS protocol. PAWS.  TLS provides message integrity
   and confidentiality between the Master Device and the Database.  The
   Master Device MUST implement server authentication, as described in
   Section 3.1 of HTTP "HTTP Over TLS TLS" [RFC2818].  The Device device uses the URI
   determined (either statically configured or dynamically discovered)
   to authenticate the server.  The Device device SHOULD fail a request if
   server authentication fails.

   Depending on prior relationship between a database and device, the
   server MAY require client authentication, as described in the
   Transport
   "Transport Layer Security (TLS) Protocol Protocol" [RFC5246], to authenticate
   the device.

   To enable databases to handle large numbers of requests from large
   numbers of devices, the Database MAY support and Devices devices SHOULD
   support Stateless "Stateless TLS Session Resumption Resumption" [RFC5077].

   A PAWS request message is carried in the body of an HTTP POST
   request.  A PAWS response message is carried in the body of an HTTP
   response.  A PAWS response SHOULD include a Content-Length header.

   The POST method is the only method REQUIRED for PAWS.  If a database
   chooses to support GET, it MUST be an escaped URI, but the encoding
   of the URI is outside the scope of this document.  The database MAY
   refuse to support the GET request by returning an HTTP error code,
   such as 404 (not found). 405 (method not allowed).

   The Database MAY redirect a PAWS request by returning a HTTP 3xx
   response (as defined by HTTP/1.1 [RFC2616]). "HTTP/1.1: Semantics and Content" [RFC7231],
   Section 6.4).  The Database MUST provide the redirect URI in the
   Location header of the 3xx response, and the Device device MUST handle
   redirects by using the Location header provided by the Database.
   When redirecting, the Device device MUST observe the delay indicated by the
   Retry-After header.  The Device device MUST authenticate the Database that
   returns the redirect response before following the redirect.  Also,
   the Device device MUST authenticate the Database indicated in the redirect.
   Since the Device device may communicate with a Database (which it
   authenticated) without user interaction, when the response code is
   301 (Moved Permanently), the Device device MAY redirect without asking a
   user for confirmation (note that this
   represents an exception confirmation, even thought it is in response to the HTTP/1.1 [RFC2616] requirements for an HTTP POST methods).
   method.

   The Database SHOULD use HTTP status code "307 Temporary Redirect" to
   indicate that the Device device SHOULD resubmit the same request to an
   alternate URI.  The Device device MAY revert to the original URI for the
   very next request, or MAY continue to use the alternate URI for a
   period of time, e.g.,:

   o  For the remainder of its session, or

   o  For a fixed period of time, or

   o  Until power cycled, or
   o  Until it receives another redirect

   However, the Device device does not need to modify its stored list of URIs.

   The

   Before the URL of the Database changes permanently, it SHOULD use the
   database-change (DbUpdateSpec (Section 5.7)) mechanism to notify
   devices, as described in the Configuration Update portion of the
   Database Discovery (Section 4.1) section.  After the Database SHOULD use has
   moved, requests to the original URL MAY return HTTP status code "301
   Moved Permanently" to indicate that the Device device SHOULD resubmit this the
   request, and all future requests, to an alternate URI.  If the Device maintains a list of
   available URIs, it needs to replace only the current URI with the indicated alternate URI.

8.  Extensibility

8.1.  Defining Ruleset Identifiers

   A ruleset represents a set of device-side requirements for which the
   device has been certified.  It typically corresponds to, but is not
   limited to, a set of rules that govern a specific set of radio
   spectrum for a regulatory domain.

   Ruleset identifiers are defined and registered in the Ruleset ID
   Registry following the procedure in Section 9.1.  Ruleset ID values
   MUST conform to the ruleset-id ABNF.  If the Ruleset ID requires
   additional parameters, they MUST be are registered in the PAWS Parameters
   Registry, as described by Section 9.2.

   ruleset-id = 1*64ruleset-char
   ruleset-char = ALPHA / DIGIT / "_" / "."

   When defining a Ruleset ID:

   o  It can be useful for the identifier to be descriptive of the set
      of rules that allow a device to operate within one or more
      regulatory domains.  For example, it might include the name of a
      regulatory body or a certification process.

   o  The identifier SHOULD include some sort of version information,
      such as a year and/or version number.

   o  The maximum length of the identifier MUST NOT exceed is 64 characters. octets.

8.2.  Defining New Message Parameters

   New request or response parameters for use with the PAWS protocol are defined and
   registered in the parameters registry following the procedure in
   Section 9.2.

   Parameter names MUST conform to the param-name ABNF and parameter
   values syntax MUST be well-defined (e.g., using ABNF, or a reference
   to the syntax of an existing parameter).

   param-name = 1*64name-char
   name-char = ALPHA / DIGIT / "_"

   Parameter names use lowerCamelCase by convention.  The parameter name SHOULD be lowerCamelCase.  The maximum length
   of a name MUST NOT
   exceed is 64 characters. octets.

   Unregistered vendor-specific parameter extensions that are not
   commonly applicable, and are specific to the implementation details
   of the Database where they are used SHOULD use a vendor-specific
   prefix that is not likely to conflict with other registered values
   (e.g., begin with 'companyname').

8.3.  Defining Additional Error Codes

   Additional error codes MAY can be defined registered to extend the set listed in
   Section 5.17.  Additional error codes are registered, 5.17, following the procedures in Section 9.3.  If the error
   code requires additional response parameters, they are registered in
   the PAWS Parameters Registry, as described by Section 9.2.

   By convention, the error code is a negative integer value, using one
   of the range of values defined in Error Codes (Section 5.17).  If an
   appropriate category does not exist, it can use values in a value from a different
   range. range
   may be used.

9.  IANA Considerations

   This section provides guidance to

   [RFC Editor/IANA: Please replace "[[ this document ]]" with the Internet Assigned Numbers
   Authority (IANA) regarding registration RFC
   number of parameters this document as indicated below, and values
   related remove this note
   prior to the PAWS protocol, in accordance with [RFC5226]. publication]

   There are three registries associated with PAWS:

   o  PAWS Ruleset ID Registry (Section 9.1)

   o  PAWS Parameter Registry (Section 9.2)

   o  PAWS Error Code Registry (Section 9.3)

   A registrant should contact IANA directly at http://www.iana.org to
   apply for new registry assignments.  Prior to the registration
   request, the registrant is encouraged to post to the
   paws-iana-review@ietf.org paws@ietf.org
   mailing list, including the specification or its draft, to get early
   feedback.

   IANA should consult

   All registries use the Specification Required policy [RFC5226], with
   a Designated Expert for all registration
   requests.  The responsible IESG area director appointed by the IESG.  Specific criteria that
   the Designated Expert should appoint one or
   more use in assessing registrations are given
   below in the description of each registry.  The Designated Experts. Expert
   should take advice from the community through the paws@ietf.org
   mailing list, and the registrant is encouraged to post to the mailing
   list before formally requesting the registration from IANA.  The
   intention is that new registrations will be accompanied by a
   published specification.  But in order to allow for the allocation of
   values prior to publication of the
   specification, the Designated Expert can approve allocations once it
   seems clear that the specification will be published.  If the
   registrant has not already done so, the Designated Expert will post a
   request to the paws-iana-review@ietf.org mailing list for comment and
   review, including the specification or its draft.  Before a period of
   30 days has passed, the Designated Expert will either approve or deny
   the registration request and publish a notice of the decision prior to publication of the
   paws-iana-review@ietf.org mailing list, as well as informing IANA.  A
   denial notice must be justified by an explanation, and in specification, the cases
   where Designated
   Expert can approve allocations once it is possible, concrete suggestions on how seems clear that the request can be
   modified so as to become acceptable should
   specification will be provided. published.

9.1.  PAWS Ruleset ID Registry

   This specification establishes the PAWS Ruleset ID Registry.

   Ruleset type names for inclusion in the PAWS protocol messages are registered on
   the advice of one or more Designated Experts, with Specification
   Required [RFC5226].  The specification must include a reference to
   the regulatory rules domain to which it applies.  To increase
   interoperability, it is more desirable to have fewer rulesets than to
   have many rulesets with small variations.  Consequently, the
   Designated Expert should avoid duplication and should encourage the
   registrant to look for alternatives if there are only small
   variations with from an existing ruleset.  The Designated Expert should
   ensure that the proposed registration is complete with respect to its
   associated regulatory rules domain and may seek an expert familar familiar with
   those rules to participate in the review on the paws-iana-review@ietf.org paws@ietf.org mailing
   list.

9.1.1.  Registration Template

   Ruleset name: identifier:  The name of the ruleset.  It is a string value that
      contains the name of the regulatory body that established  See [[ this document
      ]], Section 8.1 for the
      rules and version information.  The length format requirements of the string MUST NOT
      exceed 64 US-ASCII characters. this identifier.

   Specification document(s):  Reference to the document that specifies
      the parameter, preferably including a URI that can be used to
      retrieve a copy of the document.  An indication of the relevant
      sections also may be included, but is not required.

   Additional parameter requirements:  List of additional parameters to
      associate with the ruleset ID and any additional requirements on
      message parameters.  New parameters MUST be are registered separately in
      the PAWS Parameters Registry, as described by Section 8.2.

9.1.2.  Initial Registry Contents

   The PAWS Ruleset ID Registry enables protocol extensibility to
   support any regulatory domain and ruleset.  The initial contents of
   the registry, however, include only FCC-specific and ETSI-specific
   entries, because, as of this writing, it is they are the only regulatory
   domain
   domains that has have finalized rules.  There is no intent to restrict
   the protocol to FCC rules. any particular set of authorities.

   The initial contents of the PAWS Ruleset ID Registry are listed
   below; each section corresponds to a single row in the registry.  The
   PAWS Ruleset ID Registry will include the following fields: parameters:
   'Ruleset name', 'Additional parameter requirements', and
   'Specification document(s)'.  IANA will post each registration
   template that is not included in the text of an RFC.

9.1.2.1.  Federal Communications Commission (FCC)

   For the additional parameters that start with the "fcc" prefix, see
   PAWS Parameters Registry Initial Contents (Section 9.2.2) for more
   information.

   Ruleset name: identifier:  FccTvBandWhiteSpace-2010

   Specification document(s):  This ruleset refers to the FCC rules for
      TV-band White Space operations established in the Code of Federal
      Regulations (CFR), Title 47, Part 15, Subpart H [FCC-CFR47-15H].

   Each of the following tables defines additional parameters for the
   indicated PAWS message.  Note that the Requirement column lists FCC,
   not PAWS, requirements/optionality rules,

                Available Spectrum Request (Section 4.4.1) 4.5.1)

   +---------------+-----------------------------+-------------+-------+
   | Parameter     | Type                        | Requirement | Notes |
   | Name          |                             |             |       |
   +---------------+-----------------------------+-------------+-------+
   | deviceDesc    | DeviceDescriptor (Section   | REQUIRED    |       |
   |               | (Section 5.2)                        |             |       |
   +---------------+-----------------------------+-------------+-------+
             Available Spectrum Batch Request (Section 4.4.3) 4.5.3)

   +---------------+-----------------------------+-------------+-------+
   | Parameter     | Type                        | Requirement | Notes |
   | Name          |                             |             |       |
   +---------------+-----------------------------+-------------+-------+
   | deviceDesc    | DeviceDescriptor (Section   | REQUIRED    |       |
   |               | (Section 5.2)                        |             |       |
   +---------------+-----------------------------+-------------+-------+

                      DeviceDescriptor (Section 5.2)

   +-------------------+--------+-------------+------------------------+
   | Parameter Name    | Type   | Requirement | Notes                  |
   +-------------------+--------+-------------+------------------------+
   | fccId             | string | REQUIRED    | Specifies a device's   |
   |                   |        |             | FCC certification ID   |
   |                   |        |             | (Section 9.2.2.1).     |
   | fccTvbdDeviceType | string | REQUIRED    | Specifies the FCC      |
   |                   |        |             | Device Type (Section   |
   |                   |        |             | (Section 9.2.2.2) of TV-band    |
   |                   |        |             | TV-band White Space device, as |
   |                   |        |             | device, as defined by the FCC     |
   |                   |        |             | the FCC rules.                 |
   +-------------------+--------+-------------+------------------------+

   The following table lists additional requirements on parameters of
   the DeviceOwner (Section 5.5) message.
   parameter requirements.

                         DeviceOwner (Section 5.5)

   +-----------+-------+-----------------------------------------------+
   | Parameter | Type  | Additional Requirement                        |
   | Name      |       |                                               |
   +-----------+-------+-----------------------------------------------+
   | owner     | vCard | The owner MUST is required to contain the formatted name of          |
   |           |       | formatted name of an individual or            |
   |           |       | organization using the "fn" property. When    |
   |           |       | property. When the name is that of an organization, the      |
   |           |       | organization, the entry also MUST is required to contain the "kind"  |
   |           |       | "kind" property, with a value of "org".              |
   | operator  | vCard | The operator entry MUST is required to contain the following |
   |           |       | following properties for the contact person responsible   |
   |           |       | responsible for the device's operation: "fn", "adr", |
   |           |       | "adr", "tel", and "email".                    |
   +-----------+-------+-----------------------------------------------+

9.1.2.2.  European Telecommunications Standards Institute (ETSI)

   For the additional parameters that start with the "etsi" prefix, see
   PAWS Parameters Registry Initial Contents (Section 9.2.2) for more
   information.

   Ruleset name:  ETSI-EN-301-598-1.0.9-draft identifier:  ETSI-EN-301-598-1.1.1

   Specification document(s):  This ruleset refers to the ETSI
      Harmonised Standard [ETSI-EN-301-598] established by ETSI.

   Each of the following tables defines additional parameters for the
   indicated PAWS message.  Note that the Requirement column lists ETSI,
   not PAWS, requirements/optionality rules,
                      DeviceDescriptor (Section 5.2)

   +-------------------------+-------+-------------+-------------------+
   | Parameter Name          | Type  | Requirement | Notes             |
   +-------------------------+-------+-------------+-------------------+
   | manufacturerId          | strin | REQUIRED    | Specifies a       |
   |                         | g     |             | device's          |
   |                         |       |             | manufacturer's    |
   |                         |       |             | identifier. MUST See   |
   |                         |       |             | NOT exceed 64 [[ this document  |
   |                         |       |             | octets. ]], Section 5.2.  |
   | modelId                 | strin | REQUIRED    | Specifies a       |
   |                         | g     |             | device's model    |
   |                         |       |             | identifier. MUST See   |
   |                         |       |             | NOT exceed 64 [[ this document  |
   |                         |       |             | octets. ]], Section 5.2.  |
   | etsiEnDeviceType        | strin | REQUIRED    | Specifies the     |
   |                         | g     |             | device's ETSI     |
   |                         |       |             | device type       |
   |                         |       |             | (Section 9.2.2.3)          |
   |                         |       |             | . 9.2.2.3).         |
   | etsiEnDeviceEmissionsCl | strin | REQUIRED    | Specifies the     |
   | ass                     | g     |             | device's ETSI     |
   |                         |       |             | device emissions  |
   |                         |       |             | class             |
   |                         |       |             | (Section 9.2.2.4)    |
   |                         |       |             | . 9.2.2.4).         |
   | etsiEnTechnologyId      | strin | REQUIRED    | Specifies the     |
   |                         | g     |             | device's ETSI     |
   |                         |       |             | technology ID     |
   |                         |       |             | (Section 9.2.2.5)          |
   |                         |       |             | . 9.2.2.5).         |
   | etsiEnDeviceCategory    | strin | REQUIRED    | Specifies the     |
   |                         | g     |             | device's ETSI     |
   |                         |       |             | device category   |
   |                         |       |             | (Section 9.2.2.6)          |
   |                         |       |             | . 9.2.2.6).         |
   +-------------------------+-------+-------------+-------------------+
                    AVAIL_SPECTRUM_REQ (Section 4.4.1) 4.5.1)

   +-------------+--------+-------------+------------------------------+
   | Parameter   | Type   | Requirement | Notes                        |
   | Name        |        |             |                              |
   +-------------+--------+-------------+------------------------------+
   | requestType | string | OPTIONAL    | Modifies the available-      |
   |             |        |             | available-spectrum spectrum request type. If    |
   |             |        |             | type. If specified, the only valid    |
   |             |        |             | valid value is, "Generic Slave",   |
   |             |        |             | Slave", and the Database is required |
   |             |        |             | MUST to respond with generic      |
   |             |        |             | operating parameters for any |
   |             |        |             | Slave Device.                |
   +-------------+--------+-------------+------------------------------+

             Available Spectrum Batch Request (Section 4.4.3) 4.5.3)

   +-------------+--------+-------------+------------------------------+
   | Parameter   | Type   | Requirement | Notes                        |
   | Name        |        |             |                              |
   +-------------+--------+-------------+------------------------------+
   | requestType | string | OPTIONAL    | Modifies the available-      |
   |             |        |             | available-spectrum spectrum request type. If    |
   |             |        |             | type. If specified, the only valid    |
   |             |        |             | valid value is, "Generic Slave",   |
   |             |        |             | Slave", and the Database is required |
   |             |        |             | MUST to respond with generic      |
   |             |        |             | operating parameters for any |
   |             |        |             | Slave Device.                |
   +-------------+--------+-------------+------------------------------+

   The following tables define additional requirements for the
   DeviceDescriptor (Section 5.2) and RulesetInfo (Section 5.6)
   parameters that appear in the AVAIL_SPECTRUM_RESP (Section 4.4.2) 4.5.2) and
   AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4) 4.5.4) messages.  Note that this
   means the Database is modifying the DeviceDescriptor sent by the
   Master Device to return device-specific restrictions.

                      DeviceDescriptor (Section 5.2)

   +--------------------------------+-------+----------+---------------+
   | Parameter Name                 | Type  | Requirem | Notes         |
   |                                |       | ent      |               |
   +--------------------------------+-------+----------+---------------+
   | needsSpectrumReport            | boole | REQUIRED | The Database  |
   |                                | an    |          | MUST is required   |
   |                                |       |          | to set this   |
   |                                |       |          | to true to    |
   |                                |       |          | indicate that |
   |                                |       |          | the Device device    |
   |                                |       |          | must report   |
   |                                |       |          | spectrum      |
   |                                |       |          | usage.        |
   | maxTotalBwHz                   | float | REQUIRED | Specifies a   |
   |                                |       |          | constraint on |
   |                                |       |          | total allowed |
   |                                |       |          | bandwidth.    |
   | maxContiguousBwHz              | float | REQUIRED | Specifies a   |
   |                                |       |          | constraint on |
   |                                |       |          | total allowed |
   |                                |       |          | contiguous    |
   |                                |       |          | bandwidth.    |
   | etsiEnSimultaneousChannelOpera | strin | OPTIONAL REQUIRED | Specifies a   |
   | tionRestriction                | g     |          | constraint on |
   |                                |       |          | simultaneous  |
   |                                |       |          | channel       |
   |                                |       |          | operation     |
   |                                |       |          | (Section 9.2.      |
   |                                |       |          | 2.7). 9.2.2.7). If it  |
   |                                |       |          | it is not     |
   |                                |       |          | provided, the |
   |                                |       |          | default value |
   |                                |       |          | is "0".       |
   +--------------------------------+-------+----------+---------------+

                         RulesetInfo (Section 5.6)

   +-------------------+-------+-------------+-------------------------+
   | Parameter Name    | Type  | Requirement | Notes                   |
   +-------------------+-------+-------------+-------------------------+
   | maxLocationChange | float | OPTIONAL    | Specifies a constraint  |
   |                   |       |             | on maximum location     |
   |                   |       |             | changes.                |
   +-------------------+-------+-------------+-------------------------+

9.2.  PAWS Parameters Registry

   This specification establishes the PAWS Parameters Registry.

   Additional parameters for inclusion in the PAWS protocol requests, responses, or
   sub-messages are registered on the advice of one or more Designated
   Experts, with Specification Required [RFC5226].

   The Designated Expert should avoid duplication, i.e., avoid adding a
   new parameter when an existing one suffices.  When a set of
   parameters is added in support of a new ruleset (Section 9.1), the
   parameters should share a common prefix that reflects the ruleset ID.
   The prefix may be omitted, of course, if a parameter has more general
   applicability.  Similarly, when a parameter is not associated with a
   ruleset, the Designated Expert should ensure that the parameter name
   does not have a prefix used by existing ruleset parameters (e.g.,
   "fcc", "etsi") or are the initials of an organization that has not
   yet registered anything, but reasonably might.

9.2.1.  Registration Template

   Parameter name:  The name of the parameter (e.g., "example").

   Parameter usage location:  The location(s) where the parameter can be
      used.  The possible locations are the named requests, responses,
      and messages defined in Protocol Functionalities (Section 4) and
      Protocol Parameters (Section 5).

   Specification document(s):  Reference to the document that specifies
      the parameter, preferably including a URI that can be used to
      retrieve a copy of the document.  An indication of the relevant
      sections also may be included, but is not required.

9.2.2.  Initial Registry Contents

   The PAWS Parameters Registry enables protocol extensibility to
   support any regulatory domain and ruleset.  The initial contents of
   the registry, however, include only FCC-specific and ETSI-specific
   entries, because, as of this writing, they are the only regulatory
   domains that have established rules.  There is no intent to restrict
   the protocol to FCC and ETSI rules. any particular set of authorities.

   The PAWS Parameters Registry's initial contents are listed below;
   each section corresponds to a row of the registry.  The PAWS
   Parameters Registry will include the following fields: parameters: 'Parameter
   name', 'Parameter usage location', and 'Specification document(s)'.
   IANA will post each registration template that is not included in the
   text of an RFC.

9.2.2.1.  FCC ID

   Parameter name:  fccId

   Parameter usage location:  DeviceDescriptor (Section 5.2)

   Specification document(s):  [[ this document ]] Specifies the
      device's FCC certification identifier.  The value is an identifier
      string whose length MUST NOT exceed 32 US-ASCII characters.  Note
      that, in practice, a  A valid FCC ID may be is limited
      to 19 characters, characters in the ASCII value range, as proposed in FCC
      Administration Topics Review [FCC-Review-2012-10].  For the
      purposes of the PAWS protocol, the maximum length of the fccId
      value is 32 octets.

9.2.2.2.  FCC Device Type

   Parameter name:  fccTvbdDeviceType

   Parameter usage location:  DeviceDescriptor (Section 5.2)

   Specification document(s):  [[ this document ]] Specifies the TV Band
      White Space device type, as defined by the FCC.  Valid values are
      "FIXED", "MODE_1", "MODE_2".

9.2.2.3.  ETSI Device Type

   Parameter name:  etsiEnDeviceType

   Parameter usage location:  DeviceDescriptor (Section 5.2)

   Specification document(s):  Specifies the White Space Device type, as
      defined by the ETSI Harmonised Standard [ETSI-EN-301-598].  Valid
      values are single-letter strings, such as "A", "B", etc.  Consult
      the documentation for details about the device types.

9.2.2.4.  ETSI Device Emissions Class

   Parameter name:  etsiEnDeviceEmissionsClass

   Parameter usage location:  DeviceDescriptor (Section 5.2)

   Specification document(s):  Specifies the White Space Device
      emissions class, as defined by the ETSI Harmonised Standard
      [ETSI-EN-301-598], that characterises the out-of-block emissions
      of the device.  The values are represented by numeric strings,
      such as "1", "2", "3", etc.  Consult the documentation for details
      about emissions classes

9.2.2.5.  ETSI Technology Identifier

   Parameter name:  etsiEnTechnologyId

   Parameter usage location:  DeviceDescriptor (Section 5.2)

   Specification document(s):  Specifies the White Space Device
      technology identifier, as defined by the ETSI Harmonised Standard
      [ETSI-EN-301-598].  The maximum length of the string value MUST NOT exceed is 64 octets in
      length.
      octets.  Consult the documentation for valid values.

9.2.2.6.  ETSI Device Category

   Parameter name:  etsiEnDeviceCategory

   Parameter usage location:  DeviceDescriptor (Section 5.2)

   Specification document(s):  Specifies the White Space Device
      category, as defined by the ETSI Harmonised Standard
      [ETSI-EN-301-598].  Valid values are the strings, "master" and
      "slave".  It is case insensitive.

9.2.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, Effective isotropically radiated power (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.3.  PAWS Error Code Registry

   This specification establishes the PAWS Error Code Registry.

   Additional error codes for inclusion in the PAWS protocol error
   message messages are
   registered on the advice of one or more Designated Experts, with
   Specification Required [RFC5226].

   Error codes are intended to be used for automated error handling by
   devices.  Before approval, the Designated Expert should consider
   whether a device would handle the new error code differently from an
   existing error code, or whether the difference could be communicated
   effectively to the end-user via the "reason" parameter of the Error
   (Section 5.17) object.

9.3.1.  Registration Template

   Code:  Integer value of the error code.  The value MUST be an
      unassigned value in the range -32768 to 32767, inclusive.

   Name:  Name of the error.

   Description:  Description of the error and its associated parameters,
      if any.

   Additional parameters:  Additional parameters that are returned in
      the data portion of the error (See Section 5.17).  New parameters
      MUST be registered separately in the PAWS Parameters Registry, as
      described by Section 9.2.

9.3.2.  Initial Registry Contents

   Initial registry contents are defined in the Table of Error Codes
   (Table 1).  Note that the third column, "Description & Additional
   parameters", contains both the description of the error code and the
   specification of additional parameters, when applicable.

   The PAWS Error Code Registry will include the following fields: parameters:
   'Code', 'Name', 'Description', and 'Additional parameters'.  The
   registry will also include the error-code categories describing
   -100s, -200s, and -300s as a note (see Error Codes (Section 5.17)).
   IANA will post each registration template that is not included in the
   text of an RFC.

10.  Security Considerations

   PAWS is a protocol whereby a Master Device requests a schedule of
   available spectrum at its location (or location of its Slave Devices)
   before it (they) can operate using those frequencies.  Whereas the
   information provided by the Database must be accurate and conform to
   the applicable ruleset, the Database cannot enforce, through the
   protocol, that a client device uses only the spectrum it provided.
   In other words, devices can put energy in the air and cause
   interference without asking the Database.  Hence, PAWS security
   considerations do not include protection against malicious use of the
   White Space spectrum.  For more detailed information on specific
   requirements and security considerations associated with PAWS, see
   Protocol
   "Protocol to Access White Space database: PAWS Use Cases and
   Requirements
   Requirements" [RFC6953].

   By using the PAWS protocol, PAWS, the Master Device and the Database expose themselves
   to the following risks:

   o  Accuracy: The Master Device receives incorrect spectrum-
      availability information.

   o  Privacy: An unauthorized entity intercepts identifying data for
      the Master Device or its Slave Devices, such as serial number and
      location.

   Protection from these risks depends on the success of the following
   steps:

   1.  The Master Device must determine the address of a proper
       database.

   2.  The Master Device must connect to the proper database.

   3.  The Database must determine or compute accurate spectrum-
       availability information.

   4.  PAWS messages must be transmitted unmodified between the Database
       and the Master Device.

   5.  PAWS messages must be encrypted between the Database and the
       Master Device to prevent exposing private information.

   6.  For a Slave Device, the spectrum-availability information also
       must be transmitted unmodified and secure between the Master
       Device and the Slave Device.

   7.  When a Listing Server is required, any attack that would prevent
       reaching a Listing Server would result in all devices relying on
       that Listing Server ceasing their use of any Whitespace.

   Of these, only steps 1, 2, 4, and 5 are within the scope of this
   document.  This document addresses Step 1 by allowing static
   provisioning of one or more trusted Databases; dynamic provisioning
   is out of scope.  Step 3 is dependent on specific database
   implementations and rulesets and is outside the scope of this
   document.  Step 6 requires a protocol between master and slave
   devices and is thus outside the scope of this document.

   Use of "HTTP Over TLS" [RFC2818] ensures steps 2, 4, and 5, as
   detailed in the following sections:

   o  Assurance of Proper Database (Section 10.1)
   o  Protection Against Modification (Section 10.2)

   o  Protection Against Eavesdropping (Section 10.3)

   Any specification for an alternate transport MUST define mechanisms
   that ensure each of these steps.

10.1.  Assurance of Proper Database

   This document assumes that the Database is contacted using a domain
   name or an IP address.  Using HTTP over TLS HTTP Over TLS [RFC2818], TLS, the Database
   authenticates its identity, either as a domain name or IP address, to
   the Master Device by presenting a certificate containing that
   identifier as a "subjectAltName" (i.e., as a dNSName or IP address).
   If the Master Device has external information as to the expected
   identity or credentials of the proper database (e.g., a certificate
   fingerprint), these checks of the subjectAltName MAY be omitted.  Note that
   in order for the presented certificate to be valid at the client, the
   client must be able to validate the certificate.  In particular, the
   validation path of the certificate must end in one of the client's
   trust anchors, even if that trust anchor is the Database certificate
   itself.  A Master Device should allow for the fact that a Database
   can change its certificate authorities (CAs) over time.

10.2.  Protection Against Modification

   To prevent a PAWS response message from being modified en route,
   messages must be transmitted over an integrity-protected channel.
   Using HTTP over TLS, the channel will be protected by appropriate
   cypher suites.

10.3.  Protection Against Eavesdropping

   Using HTTP over TLS, messages protected by appropriate cypher suites
   are also protected from eavesdropping or otherwise access unrestricted
   reading by unauthorized parties en route.

10.4.  Client Authentication Considerations

   Although the Database can inform a device of available spectrum it
   can use, the Database cannot enforce that the Master Device uses any/
   only those frequencies.  Indeed, a malicious device can operate
   without ever contacting a database. operate
   without ever contacting a database.  Note also that, whereas a
   malicious device may send fraudulent SPECTRUM_USE_NOTIFY
   (Section 4.5.5) messages, in the regulatory domains that have
   established rules, such notifications do not change the available-
   spectrum answers, so no harm can result from such messages.

   Consequently, client authentication is not required for the core PAWS protocol
   (although it may be required by specific regulatory domains).

   Depending on a prior relationship between a Database and Master
   Device, the Database MAY require client authentication.  TLS provides
   client authentication, but there are some considerations:

   o  As indicated in Section 3.2 of HTTP "HTTP Over TLS TLS" [RFC2818], the TLS
      client authentication procedure only determines that the device
      has a certificate chain rooted in an appropriate CA (or a self-
      signed certificate).  The database would not know what the client
      identity ought to be, unless it has some external source of
      information.  Distribution and management of such information,
      including revocation lists, are outside the scope of this
      document.

   o  Authentication schemes are secure only to the extent that secrets
      or certificates are kept secure.  When there are a vast number of
      deployed devices using PAWS, the possibility that device keys will
      not leak becomes small.  Implementations should consider how to
      manage the system in the eventuality that there is a leak.

11.  Contributors

   This document draws heavily from the following Internet Draft
   documents, [I-D.das-paws-protocol] draft-das-paws-protocol and [I-D.wei-paws-framework]. draft-wei-paws-framework.  The
   editor would like to specifically call out and thank the contributing
   authors of these two documents.

      Donald Joslyn
      Spectrum Bridge Inc.
      1064 Greenwood Blvd.
      Lake Mary, FL  32746
      U.S.A.
      Email: d.joslyn at spectrumbridge dot com

      Xinpeng Wei
      Huawei
      Phone: +86 13436822355
      Email: weixinpeng@huawei.com

12.  Acknowledgments

   The authors gratefully acknowledge the contributions of: Gabor Bajko,
   Ray Bellis, Teco Boot, Nancy Bravin, Rex Buddenberg, Gerald
   Chouinard, Stephen Farrell, Michael Fitch, Joel M.  Halpern, Daniel
   Harasty, Michael Head, Jussi Kahtava, Warren Kumari, Kalle Kulsmanen,
   Paul Lambert, Andy Lee, Anthony Mancuso, Basavaraj Patil, Scott
   Probasco, Brian Rosen, Andy Sago, Peter Stanforth, John Stine, and
   Juan Carlos Zuniga.

13.  References

13.1.  Normative References

   [JSON-RPC]
              "JSON-RPC 2.0 Specification",
              <http://www.jsonrpc.org/specification>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RFC3339]  Klyne, G., Ed. and C. Newman, "Date and Time on the
              Internet: Timestamps", RFC 3339, July 2002.

   [RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
              "Transport Layer Security (TLS) Session Resumption without
              Server-Side State", RFC 5077, January 2008.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5491]  Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
              Presence Information Data Format Location Object (PIDF-LO)
              Usage Clarification, Considerations, and Recommendations",
              RFC 5491, March 2009.

   [RFC6350]  Perreault, S., "vCard Format Specification", RFC 6350,
              August 2011.

   [RFC7095]  Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
              January 2014.

   [RFC7159]  Bray, T., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, March 2014.

   [RFC7231]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.

13.2.  Informative References

   [ETSI-EN-301-598]
              European Telecommunication Standards Institute (ETSI),
              "Final draft ETSI
              "ETSI EN 301 598 (V1.0.9): (V1.1.1): White Space Devices (WSD);
              Wireless Access Systems operating in the 470 MHz to 790
              MHz frequency band; Harmonized EN covering the essential
              requirements of article 3.2 of the R&TTE Directive", February April
              2014, <http://www.etsi.org/deliver/
              etsi_en/301500_301599/301598/01.00.09_30/
              en_301598v010009v.pdf>.
              etsi_en/301500_301599/301598/01.01.01_60/
              en_301598v010101p.pdf>.

   [FCC-CFR47-15H]
              U. S. Government, "Electronic Code of Federal Regulations,
              Title 47, Part 15, Subpart H: Television Band Devices",
              December 2010, <http://www.ecfr.gov/cgi-bin/
              text-idx?rgn=div6&view=text&node=47:1.0.1.1.16.8>.

   [FCC-Review-2012-10]
              Federal Communications Commission, "Administration Topics
              Review", October 2012, <http://transition.fcc.gov/bureaus/
              oet/ea/presentations/files/oct12/
              2b-TCB-Admin-Issues-Oct-2012-GT.pdf>.

   [I-D.das-paws-protocol]
              Das,
              <http://transition.fcc.gov/bureaus/oet/ea/presentations/
              files/oct12/2b-TCB-Admin-Issues-Oct-2012-GT.pdf>.

   [I-D.ietf-geopriv-uncertainty]
              Thomson, M. and J. Winterbottom, "Representation of
              Uncertainty and Confidence in PIDF-LO", draft-ietf-
              geopriv-uncertainty-01 (work in progress), July 2014.

   [ISO3166-1]
              "Country Codes",
              <http://www.iso.org/iso/country_codes.htm>.

   [ITUT.X520.2008]
              International Telecommunication Union, "ITU-T
              Recommendation X.520: Information technology - Open
              Systems Interconnection - The Directory: Selected
              attribute types", November 2008,
              <http://www.itu.int/rec/T-REC-X.520-200811-I>.

   [RFC6953]  Mancuso, A., Probasco, S., Malyar, J., and D. Joslyn, "Device B. Patil, "Protocol to
              Access White-Space (PAWS) Databases: Use Cases and
              Requirements", RFC 6953, May 2013.

   [WGS-84]   National Imagery and Mapping Agency, "Department of
              Defense World Geodetic System 1984, Its Definition and
              Relationships with Local Geodetic Systems, NIMA TR8350.2
              Third Edition Amendment 1", January 2000, <http://earth-
              info.nga.mil/GandG/publications/tr8350.2/tr8350_2.html>.

Appendix A.  Database Listing Server Support

   As discussed in Database Discovery (Section 4.1), some regulatory
   domains support the preconfiguration of devices with the URI of a
   listing server, to which devices can connect to obtain a list of
   databases certified by the regulatory domain.  Regulatory domains may
   require the device to periodically contact the Database Listing
   Server to validate and/or update its list of certified databases.  If
   the device is unable to validate its list of certified databases
   within the required period, regulatory rules may require the device
   to treat this inability as equivalent to the device having no
   available spectrum.

   A sample JSON response from a Database Listing Server might be
   represented as follows:

   {
     "lastUpdateTime": "2014-06-28T10:00:00Z",
     "maxRefreshMinutes": 1440
     "dbs": [
       {
         "name": "Some Operator",
         "uris": [
           {
             "uri": "https://example.some.operator.com",
             "protocol": "paws"
           },
           ...
         ]
       },
       ...
     ]
   }

   In parameters in this sample message are:

   lastUpdateTime  The time at which the database entries were last
      updated.

   maxRefreshMinutes  The maximum interval, expressed in minutes, that
      is allowed between device requests to the Database
              Protocol Listing Server.

   dbs  A list of entries for White Space", draft-das-paws-protocol-02
              (work in progress), July 2012.

   [I-D.wei-paws-framework]
              Wei, X., Zhu, L., and P. McCann, "PAWS Framework",
              draft-wei-paws-framework-00 (work in progress), July 2012.

   [I-D.zyp-json-schema]
              Galiegue, F., Zyp, K., and G. Court, "JSON Schema: core
              definitions and terminology", draft-zyp-json-schema-04
              (work in progress), January 2013.

   [ISO3166-1]
              "Country Codes",
              <http://www.iso.org/iso/country_codes.htm>.

   [ITUT.X520.2008]
              International Telecommunication Union, "ITU-T
              Recommendation X.520: Information technology - Open
              Systems Interconnection - certified databases, each containing the
      following

      name  The Directory: Selected
              attribute types", November 2008,
              <http://www.itu.int/rec/T-REC-X.520-200811-I>.

   [RFC6953]  Mancuso, A., Probasco, S., and B. Patil, "Protocol to
              Access White-Space (PAWS) Databases: Use Cases and
              Requirements", RFC 6953, May 2013.

   [WGS-84]   National Imagery and Mapping Agency, "Department name of
              Defense World Geodetic System 1984, Its Definition and
              Relationships the database operator.

      uris  One or more URIs for each database, allowing a database to
         support more than one protocol.

      uri, protocol  Each protocol supported by a certified database is
         associated with Local Geodetic Systems, NIMA TR8350.2
              Third Edition Amendment 1", January 2000, <http://
              earth-info.nga.mil/GandG/publications/tr8350.2/
              tr8350_2.html>. a separate URI (PAWS protocol URI shown).

Appendix A. B.  Changes / Author Notes.

   To be removed before publication

   Changes from 12:

   o  Define primitive types in Section 4, specifying UTF-8 for strings
      and remove UTF-8 references elsewhere.

   o  Replace or rephrase "parameter" when reference is to higher-level
      structure.

   o  Replace "MUST" with non-2119 language (maximum length is xxx
      octets.

   o  Rephrase statements that reflected regulatory, not PAWS
      requirements (e.g., deletion of "MUST" or "MAY" and rephrasing as
      a regulatory requirement).

   o  Replace "Paws protocol (redundant) to "PAWS"

   o  Change "geo-location" to "geolocation"

   o  General references to "Database" changed to "database."

   o  Simplify Section 6 by showing several JSON encoding examples.

   o  Change "Device" to "device"

   o  Moved treatment of List Server as discovery mechanism to
      Appendix and added JSON-encoded DB List Server response example.

   Changes from 11:

   o  Change "regulatory rules" to "ruleset"

   o  Change "regulatory specifics" to "ruleset specifics"
   o  Change "regulatory-specific" to "ruleset-specific"

   o  Change "regulatory domain" to "ruleset" where appropriate

   o  Replace "depends on regulatory domain" to "optional" in tables

   o  Add "optional" to "*other" in tables

   o  Change "regulators" to "regulatory domains"

   o  Change "REQUIRED" error name to "MISSING"

   o  Changed the IANA instructions and added DE instructions to each
      section

   o  Reformat and reorder IANA sections

   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:

   o  Updated format of the IANA section

   Changes from 08:

   o  Fix JSON typos.

   o  Added note that JSON schema is not intended to be formally
      validated

   o  Finalize paws-iana-review@ietf.org as the email for updating the
      PAWS IANA registries

   o  URLs to URIs

   o  Typo fixes

   Changes from 07:

   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
      proposing changes to the PAWS IANA registries

   o  Moved discussion of required vCard properties to regulatory-
      specific sections

   o  Fixed vCard examples for organization names: Use "fn" property,
      but set "kind" to "org".

   o  Shorten parameter names:

      *  freqHz -> hz

      *  powerDbmPerBw -> dbm

   Changes from 06:

   o  Multi-ruleset support:

      *  Changed RulesetInfo to have single ruleset ID

      *  Changed INIT_RESP to return a list of RulesetInfo parameters,
         rather than a single one

      *  Changed REGISTRATION_RESP to return a list of RulesetInfo
         parameters to indicate the regulatory domains for which
         registration was accepted

      *  Added SpectrumSpec (Section 5.9) parameter to represent
         available-spectrum specification for one regulatory domain,
         allowing AVAIL_SPECTRUM_RESP and AVAIL_SPECTRUM_BATCH_RESP to
         include answers for multiple regulatory domains

      *  Changed GeoSpectrumSchedule to GeoSpectrumSpec (Section 5.15)
         for supporting batch responses to represent available spectrum
         for multiple regulatory domains at a location

   o  To avoid ambiguity or redundant information, clarified that:

      *  Event-time intervals within a single set of schedules MUST be
         disjoint

      *  A single Spectrum element MUST cover the entire range of
         frequencies governed by a ruleset, rather than splitting them
         to present a "channelized" view

   o  Add "ruleset" to Terminology section
   o  Sync Terminology section with Use Case document

   o  Add "masterDeviceDesc" to Device Validate request

   o  Add "masterDeviceLocation" to the AVAIL_SPECTRUM requests and the
      SPECTRUM_NOTIFY message.  Change "location" to be the location of
      the Slave Device, if the request is made by a Master Device on
      behalf of a Slave Device

   o  Update vCard reference and example

   o  Add jsonrpc 2.0 to all sample messages

   o  Clarify that Listing Servers may be preconfigured in a device

   o  Clarify meaning of maximum power levels vs bandwidth, including
      renaming parameter names:

   o

      *  maxPowerDBm -> powerDbmPerBw

      *  bandwidth -> resolutionBwHz

   o  Explicitly allowed generic JSON-RPC error codes as possible codes.

   o  Replace SHALL with MUST for consistency

   o  Replace URI with URL for consistency

   o  Reduce clutter in JSON encoding examples by removing string-
      concatenation characters

   o  Changed "depends" to "depends on regulatory rules" in several
      places

   Changes from 05:

   o  Remove requirement for JSON-RPC 1.0

   o  More typo fixes and clarifications

   Changes from 04:

   o  Add "masterDeviceDesc" parameter to the available-spectrum
      requests to allow both Master and Slave device descriptors when
      the Master is making the request on behalf of a Slave.

   o  Add "requestType" parameter to the available-spectrum requests to
      support requesting generic operating parameters for any Slave
      Device.

   o  Add DbUpdateSpec as optional parameter to all response messages
      and to the error response to allow a Device to detect a database
      change at any stage of the control flow.

   o  For the OUTSIDE_COVERAGE error, added ability to return a list of
      alternate databases

   o  Explicitly allow JSON-RPC v2.0 and v1.0 encodings

   o  Relaxed language that state, "MUST stop operation" to "MUST cease
      use of spectrum under rules for database-managed spectrum".  I.e.,
      the device may have other fallback strategies allowed by
      regulators.

   Changes from 03:

   o  Expanded the Database Discovery mechanism to describe in more
      detail pre-configuration with URLs of databases and database-
      listing servers, including mechanisms for updating the
      configurations when things change

      *  Add database-change field to Available Spectrum Response
         (Section 4.4.2) 4.5.2)

   o  Added fields that are anticipated to be needed by the ETSI
      harmonized standard for White Space Devices:

      *  Added bandwidth constraints to the Available Spectrum Response
         (Section 4.4.2) 4.5.2)

      *  Updated Available Spectrum Response to return RulesetInfo,
         rather than just a ruleset identifier

      *  Added optional device-manufacturer and device-model IDs to the
         DeviceDescriptor (Section 5.2) message.  Also moved fccId from
         this message to the IANA section.

      *  Expanded IANA (Section 9) sections

   o  Clarified restrictions on the specification of the vertices of a
      Polygon.

   o  Changed default confidence level to 95% for a point with
      uncertainty

   o  Clarified how devices without absolute time source can use the
      timestamps in the response messages

   o  Change method names to start with "spectrum.paws." prefix

   o  Added maximum string lengths

   o  Updated author contact info

   o  More typo fixes

   Changes from 02:

   o  Added timestamp to the AVAIL_SPECTRUM_RESP (Section 4.4.2) 4.5.2) and
      AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4) 4.5.4) data models to serve as
      a reference for the event times in the response.  This was
      accidentally omitted (but was specified in their JSON encodings
      (Section 6)).

   o  Fixed typos throughout the JSON encoding (Section 6) sections,
      typically adding missing commas.

   Changed from 01:

   o  Added a description of message sequences to support multiple
      rulesets and multiple jurisdictions Section 3.1.

   o  Modified DeviceDescriptor (Section 5.2) to add rulesetIds
      parameter

   o  Modified RulesetInfo (Section 5.6), AvailableSpectrumResponse
      (Section 4.4.2) 4.5.2) to add rulesetId parameter.

   o  Add Extensibility (Section 8) section.

   o  Filled in IANA (Section 9) section.

   o  Removed blank Example Messages section

   Changes from 00:

   o  Add JSON encoding

   o  Adopt RFC5491 for GeoLocation

   o  Adopt vCard for contact information
   o  Add Response Code section and update text referencing the defined
      response codes

   o  Change DeviceIdentifier to be DeviceDescriptor, allowing
      identifiers and device-characteristic fields to be included.

Authors' Addresses

   Vincent Chen (editor)
   Google
   1600 Amphitheatre Parkway
   Mountain View, CA  94043
   US

   Email: vchen@google.com

   Subir Das
   Applied Communication Sciences
   150 Mount Airy Road
   Basking Ridge, NJ  07920
   U.S.A.

   Phone:
   Fax:

   Email: sdas at appcomsci dot com
   URI:

   Lei Zhu
   Huawei

   Phone: +86 13910157020
   Fax:
   Email: lei.zhu@huawei.com
   URI:

   John Malyar
   iconectiv (formerly Telcordia Interconnection Solutions)
   444 Hoes Lane/RRC 4E1106
   Piscataway, NJ  08854
   U.S.A.

   Phone:
   Fax:

   Email: jmalyar at iconectiv dot com
   URI:
   Peter J. McCann
   Huawei
   400 Crossing Blvd, 2nd Floor
   Bridgewater, NJ  08807
   USA

   Phone: +1 908 541 3563
   Fax:
   Email: peter.mccann@huawei.com
   URI: