tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7545

Proposed STD
Pages: 90
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: PAWS

Protocol to Access White-Space (PAWS) Databases

Part 1 of 4, p. 1 to 9
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                      V. Chen, Ed.
Request for Comments: 7545                                        Google
Category: Standards Track                                         S. Das
ISSN: 2070-1721                           Applied Communication Sciences
                                                                  L. Zhu
                                                                  Huawei
                                                               J. Malyar
                                                               iconectiv
                                                               P. McCann
                                                                  Huawei
                                                                May 2015


            Protocol to Access White-Space (PAWS) Databases

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 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 Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7545.

Page 2 
Copyright Notice

   Copyright (c) 2015 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.

Top       Page 3 
Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   5
     2.1.  Conventions Used in This Document . . . . . . . . . . . .   5
     2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   7
     3.1.  Multi-ruleset Support . . . . . . . . . . . . . . . . . .   8
   4.  Protocol Functionalities  . . . . . . . . . . . . . . . . . .   9
     4.1.  Database Discovery  . . . . . . . . . . . . . . . . . . .  11
       4.1.1.  Preconfiguration  . . . . . . . . . . . . . . . . . .  11
       4.1.2.  Configuration Update: Database URI Changes  . . . . .  11
       4.1.3.  Error Handling  . . . . . . . . . . . . . . . . . . .  12
     4.2.  PAWS Version  . . . . . . . . . . . . . . . . . . . . . .  12
     4.3.  Initialization  . . . . . . . . . . . . . . . . . . . . .  12
       4.3.1.  INIT_REQ  . . . . . . . . . . . . . . . . . . . . . .  13
       4.3.2.  INIT_RESP . . . . . . . . . . . . . . . . . . . . . .  14
     4.4.  Device Registration . . . . . . . . . . . . . . . . . . .  15
       4.4.1.  REGISTRATION_REQ  . . . . . . . . . . . . . . . . . .  16
       4.4.2.  REGISTRATION_RESP . . . . . . . . . . . . . . . . . .  17
     4.5.  Available Spectrum Query  . . . . . . . . . . . . . . . .  18
       4.5.1.  AVAIL_SPECTRUM_REQ  . . . . . . . . . . . . . . . . .  21
       4.5.2.  AVAIL_SPECTRUM_RESP . . . . . . . . . . . . . . . . .  23
       4.5.3.  AVAIL_SPECTRUM_BATCH_REQ  . . . . . . . . . . . . . .  26
       4.5.4.  AVAIL_SPECTRUM_BATCH_RESP . . . . . . . . . . . . . .  28
       4.5.5.  SPECTRUM_USE_NOTIFY . . . . . . . . . . . . . . . . .  29
       4.5.6.  SPECTRUM_USE_RESP . . . . . . . . . . . . . . . . . .  31
     4.6.  Device Validation . . . . . . . . . . . . . . . . . . . .  31
       4.6.1.  DEV_VALID_REQ . . . . . . . . . . . . . . . . . . . .  32
       4.6.2.  DEV_VALID_RESP  . . . . . . . . . . . . . . . . . . .  33
   5.  Protocol Parameters . . . . . . . . . . . . . . . . . . . . .  34
     5.1.  GeoLocation . . . . . . . . . . . . . . . . . . . . . . .  34
     5.2.  DeviceDescriptor  . . . . . . . . . . . . . . . . . . . .  37
     5.3.  AntennaCharacteristics  . . . . . . . . . . . . . . . . .  38
     5.4.  DeviceCapabilities  . . . . . . . . . . . . . . . . . . .  39
     5.5.  DeviceOwner . . . . . . . . . . . . . . . . . . . . . . .  39
     5.6.  RulesetInfo . . . . . . . . . . . . . . . . . . . . . . .  40
     5.7.  DbUpdateSpec  . . . . . . . . . . . . . . . . . . . . . .  41
     5.8.  DatabaseSpec  . . . . . . . . . . . . . . . . . . . . . .  42
     5.9.  SpectrumSpec  . . . . . . . . . . . . . . . . . . . . . .  42
     5.10. SpectrumSchedule  . . . . . . . . . . . . . . . . . . . .  44
     5.11. Spectrum  . . . . . . . . . . . . . . . . . . . . . . . .  44
     5.12. SpectrumProfile . . . . . . . . . . . . . . . . . . . . .  50
     5.13. FrequencyRange  . . . . . . . . . . . . . . . . . . . . .  51
     5.14. EventTime . . . . . . . . . . . . . . . . . . . . . . . .  51
     5.15. GeoSpectrumSpec . . . . . . . . . . . . . . . . . . . . .  52
     5.16. DeviceValidity  . . . . . . . . . . . . . . . . . . . . .  53

Top      ToC       Page 4 
     5.17. Error Element . . . . . . . . . . . . . . . . . . . . . .  53
       5.17.1.  OUTSIDE_COVERAGE Error . . . . . . . . . . . . . . .  55
       5.17.2.  DATABASE_CHANGE Error  . . . . . . . . . . . . . . .  56
       5.17.3.  MISSING Error  . . . . . . . . . . . . . . . . . . .  56
   6.  Message Encoding  . . . . . . . . . . . . . . . . . . . . . .  57
     6.1.  JSON-RPC Binding  . . . . . . . . . . . . . . . . . . . .  57
       6.1.1.  Method Names  . . . . . . . . . . . . . . . . . . . .  59
       6.1.2.  JSON Encoding of Data Models  . . . . . . . . . . . .  59
     6.2.  Example Encoding: spectrum.paws.init Method . . . . . . .  61
     6.3.  Example Encoding: spectrum.paws.getSpectrum Method  . . .  62
     6.4.  Example Encoding: DeviceOwner vCard . . . . . . . . . . .  66
   7.  HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . . .  66
   8.  Extensibility . . . . . . . . . . . . . . . . . . . . . . . .  68
     8.1.  Defining Ruleset Identifiers  . . . . . . . . . . . . . .  68
     8.2.  Defining New Message Parameters . . . . . . . . . . . . .  69
     8.3.  Defining Additional Error Codes . . . . . . . . . . . . .  69
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  69
     9.1.  PAWS Ruleset ID Registry  . . . . . . . . . . . . . . . .  70
       9.1.1.  Registration Template . . . . . . . . . . . . . . . .  70
       9.1.2.  Initial Registry Contents . . . . . . . . . . . . . .  72
     9.2.  PAWS Parameters Registry  . . . . . . . . . . . . . . . .  78
       9.2.1.  Registration Template . . . . . . . . . . . . . . . .  78
       9.2.2.  Initial Registry Contents . . . . . . . . . . . . . .  78
     9.3.  PAWS Error Code Registry  . . . . . . . . . . . . . . . .  80
       9.3.1.  Registration Template . . . . . . . . . . . . . . . .  81
       9.3.2.  Initial Registry Contents . . . . . . . . . . . . . .  81
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  81
     10.1.  Assurance of Proper Database . . . . . . . . . . . . . .  83
     10.2.  Protection against Modification  . . . . . . . . . . . .  84
     10.3.  Protection against Eavesdropping . . . . . . . . . . . .  84
     10.4.  Client Authentication Considerations . . . . . . . . . .  84
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  85
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  85
     11.2.  Informative References . . . . . . . . . . . . . . . . .  86
   Appendix A.  Database Listing Server Support  . . . . . . . . . .  88
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  89
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  89
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  90

Top      ToC       Page 5 
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, 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
   geolocation, antenna height, power, and periods of operation.  The
   rules that the database is required to 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 hidden from devices to the maximum extent possible.

   This specification defines an extensible protocol, built on top of
   HTTP and TLS, to obtain available spectrum from a geospatial database
   by a device with geolocation capability.  It enables a device to
   operate in a regulatory domain that implements this 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].

Top      ToC       Page 6 
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
      (http://www.etsi.org)

   FCC:  The U.S.  Federal Communications Commission
      (http://www.fcc.gov)

   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 PAWS
      is agnostic as to how a regulatory domain is constructed.

   Ruleset:  A ruleset represents a set of rules that governs the
      operation of white-space devices and Spectrum Databases.  A
      regulatory authority can define its own set of rules or adopt an
      existing ruleset.  When a Database or device is said to "support a
      ruleset", it means that it contains out-of-band knowledge of the
      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 9.1)).  When a Database or device indicates it supports a
      ruleset identifier, it means that it conforms to the 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.

Top      ToC       Page 7 
   Slave Device:  A device that queries the Database through a master
      device.

3.  Protocol Overview

   A Master Device uses PAWS 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 which 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 an initialization-response 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.  The message may be on behalf of a Slave Device
        that made a request to the Master Device.

   7.   If the Master Device is making a request on behalf of a Slave
        Device, the Master Device may verify with the Database that the
        Slave Device is permitted to operate.

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

Top      ToC       Page 8 
   9.   The Master Device may send a spectrum-usage notification message
        to the Database.  The notification is purely informational; it
        notifies the Database what spectrum the Master Device intends to
        use and is not a request to the Database to get permission to
        use that spectrum.  Some Databases may require spectrum-usage
        notification.

   10.  If the Database receives a spectrum-usage notification message,
        it responds by sending the Master Device a spectrum-usage
        acknowledgement message.  Since the notification is purely
        informational, the Master Device does not need to process the
        database response.

   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, 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 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: Some regulatory domains specify sets of requirements for device
   behavior that may be complex and not easily parameterized.  The
   ruleset-id parameter provides a mechanism for the Database to inform
   the Master Device of an applicable ruleset, and, for devices with

Top      ToC       Page 9 
   out-of-band knowledge of the particular regulatory domain
   requirements, to satisfy those requirements without having to specify
   the device-side behavior within the protocol.  Ruleset identifiers
   will normally contain 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.



(page 9 continued on part 2)

Next RFC Part