tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7545

 
 
 

Protocol to Access White-Space (PAWS) Databases

Part 2 of 4, p. 9 to 33
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 9 
4.  Protocol Functionalities

   PAWS consists of several components.  As noted below, some regulatory
   domains or database implementations may mandate the use of a
   component, even when its use is not mandated by PAWS.

   o  Database Discovery (Section 4.1) is a required component for the
      Master Device.

   o  Initialization (Section 4.3) is a required component for the
      Database.  Its use allows the Master Device to determine necessary
      information that has not been preconfigured.

   o  Device Registration (Section 4.4) is an optional component for the
      Database.  It can be implemented as a separate component or as
      part of the Available Spectrum Query (Section 4.5) component.  It
      is used by the Master Device when the Database requires it.  Note
      that some regulators require device registration for only specific
      device types, such as higher-power fixed (as opposed to mobile)
      devices, to allow them to contact the operators to resolve any
      interference issues.

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

   o  Spectrum Use Notify (Section 4.5.5) is an optional component for
      the Master Device and the Database.  When it is required, the
      Database informs the Master Device via its response to the
      Available Spectrum Query (Section 4.5).

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

Top      Up      ToC       Page 10 
   This section describes the protocol components and their messages.
   "Protocol Parameters" (Section 5) contains a 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 transferring 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
   diagrams are loosely based on the Unified Modeling Language (UML),
   and the data types are defined either in "Protocol Parameters"
   (Section 5) or are one of the following primitive or structured
   types:

   string:  A string, as defined by JSON [RFC7159], restricted to the
      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 list
      are of the same data type, which is indicated in its diagram and
      description.  The diagram notation and description may include
      additional constraints, such as minimum or maximum number of
      elements.

   Also:

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

   o  All timestamps are in UTC and are expressed using exactly the
      form, YYYY-MM-DDThh:mm:ssZ, as defined by "Date and Time on the
      Internet: Timestamps" [RFC3339].

   In some cases, specific rulesets may place additional requirements on
   message parameters.  These additional requirements will be documented
   in the IANA PAWS Ruleset ID Registry (Section 9.1).  When a request
   message sent to the Database has missing parameters, whether they are

Top      Up      ToC       Page 11 
   required by PAWS or the applicable ruleset, the Database returns the
   MISSING error (see Section 5.17.3), along with data indicating the
   missing parameters.

4.1.  Database Discovery

4.1.1.  Preconfiguration

   The Master Device can be provisioned statically (preconfigured) 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 preconfigured in the device.

   Listing Server Support: As an alternative to preconfiguring devices
   with a list of certified Databases, some regulatory domains support
   the preconfiguration of devices with the URI of a certified listing
   server, to which devices can connect to obtain the list of certified
   Databases.  See "Database Listing Server Support" (Appendix A) for
   further information.

4.1.2.  Configuration Update: Database URI Changes

   To adapt to changes in the list of 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 the upcoming change by including the URI of one or more
   alternate Databases using DbUpdateSpec (Section 5.7) in its responses
   to devices.  The Database MUST reply with DbUpdateSpec for a minimum
   of 2 weeks before disabling the old URI.  A device will update its
   preconfigured entry for the Database sending the DbUpdateSpec by
   replacing this entry with the alternate Databases listed in the
   DbUpdateSpec; the list of alternate Databases does not affect any
   other entries.  Note that the ordering of Databases in the list does
   not imply any preference and does not need to remain the same for
   every request.  The device SHOULD detect infinite redirection loops;
   if a suitable Database cannot be contacted, the device MUST treat
   this as equivalent to a response indicating no available spectrum.
   This database-change mechanism is used, for example, before a
   Database ceases operation; it is not intended to be used for dynamic
   load balancing.

Top      Up      ToC       Page 12 
4.1.3.  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 indicates the Database does not
      support the device (based on its device type, model, etc.) or
      supports none of the rulesets specified in the request.

   If a suitable Database cannot be contacted, the device MUST treat
   this as equivalent to a response indicating no available spectrum.
   If the device had previously contacted a Database to get available
   spectrum, but subsequently 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.  However, after that period, the device will
   no longer have valid spectrum to use.  Some regulatory domains may
   have specific rules regarding how long the spectrum data remains
   valid in these cases.

4.2.  PAWS Version

   PAWS version uses a "<major>.<minor>" numbering scheme to indicate
   versions of the protocol.  The protocol versioning policy is intended
   to allow the device or Database to indicate the format of a message
   and its understanding of PAWS functionality defined by that version.
   No change is made to the version string for the addition of message
   components that only add to extensible parameter values.  The <minor>
   number is incremented when the 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 to existing functionality.

   The current PAWS version is "1.0".

4.3.  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 for each supported ruleset, such as
   threshold distances and time periods beyond which the device must
   update its available-spectrum data (see "RuleSetInfo" (Section 5.6)).

Top      Up      ToC       Page 13 
   When parameterized-rule values are not preconfigured for the
   applicable ruleset at the specified location, a Master Device MUST
   use the initialization procedure.

   It is important to note that, when parameterized-rule values are
   preconfigured in a Master Device, they are preconfigured on a per-
   ruleset basis.  That is, values preconfigured for one ruleset are not
   applicable to any other ruleset.

   For database implementations that require it, the initialization
   message also enables extra database-specific or ruleset-specific
   handshake parameters to be communicated before allowing available-
   spectrum requests.

   The Initialization request procedure is depicted in Figure 1.

   o  INIT_REQ (Section 4.3.1) is the initialization request message

   o  INIT_RESP (Section 4.3.2) is the initialization response message

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

                                 Figure 1

4.3.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 |
   +----------------------------+----------+

Top      Up      ToC       Page 14 
   Parameters:

   deviceDesc:  The DeviceDescriptor (Section 5.2) for the device is
      REQUIRED.  If the device descriptor does not contain any ruleset
      IDs, the Master Device is asking the Database to return a
      RulesetInfo (Section 5.6) list that specifies the rulesets that it
      supports at the specified location.

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

   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.3.2.  INIT_RESP

   The initialization response message communicates database parameters
   to the 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).

   +---------------------------------------+
   |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.

Top      Up      ToC       Page 15 
      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 supports none of
      the rulesets specified in the DeviceDescriptor, it MUST instead
      return an error with the UNSUPPORTED code (see Table 1) in the
      error response.

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

   other:  The Database MAY include additional handshake parameters in
      the 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.4.  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 (see FCC CFR47-15H
   [FCC-CFR47-15H]).

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

   The Device Registration request procedure is depicted in Figure 2.

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

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

Top      Up      ToC       Page 16 
                +---------------+        +-------------------+
                | Master Device |        | Spectrum Database |
                +---------------+        +-------------------+
                      |                         |
                      |    REGISTRATION_REQ     |
                      |------------------------>|
                      |                         |
                      |    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    | REQUIRED  |
   |location:GeoLocation           | REQUIRED  |
   |deviceOwner:DeviceOwner        | OPTIONAL  |
   |antenna:AntennaCharacteristics | OPTIONAL  |
   |...........................................|
   |*other:any                     | OPTIONAL  |
   +-------------------------------+-----------+

   Parameters:

   deviceDesc:  The DeviceDescriptor (Section 5.2) for the Master Device
      is REQUIRED.  The ruleset IDs included in the DeviceDescriptor
      indicate the rulesets for which the device wishes to register.

   location:  The GeoLocation (Section 5.1) for the device is REQUIRED.
      More precisely, this is the location at which the device intends
      to operate.  If the location is outside all regulatory domains
      supported by the Database, the Database MUST respond with an
      OUTSIDE_COVERAGE error (see Table 1).

   deviceOwner:  The DeviceOwner (Section 5.5) information is OPTIONAL.
      Some rulesets may require deviceOwner information under certain
      conditions.  See PAWS Ruleset ID Registry (Section 9.1) for
      ruleset-specific requirements.

   antenna:  The AntennaCharacteristics (Section 5.3) is OPTIONAL.

Top      Up      ToC       Page 17 
   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.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 accepts the
   registration for none of the specified rulesets, 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 RulesetInfo (Section 5.6) list 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.

      Each RulesetInfo in the response MUST match one of the ruleset IDs
      specified in the DeviceDescriptor of REGISTRATION_REQ.

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

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

Top      Up      ToC       Page 18 
   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.5.  Available Spectrum Query

   To obtain the available spectrum from the Database, a Master Device
   sends a request that contains its geolocation 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 3.

   o  AVAIL_SPECTRUM_REQ (Section 4.5.1) is the available-spectrum
      request message.

   o  AVAIL_SPECTRUM_RESP (Section 4.5.2) is the available-spectrum
      response message.

   o  AVAIL_SPECTRUM_BATCH_REQ (Section 4.5.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.5.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.5.5) is the spectrum-usage
      notification message.

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

Top      Up      ToC       Page 19 
               +---------------+          +-------------------+
               | 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 3

   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
       code (see Table 1) 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 error (see Table 1).  If some,
       but not all, locations within a batch request are outside the
       regulatory domain supported by the Database, the Database MUST
       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.

Top      Up      ToC       Page 20 
   4.  The Database MAY perform other validation of the request, (e.g.,
       checking for missing required parameters or 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 error (see Table 1) 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.
       Even when not required by the Database, the Master Device MAY
       send a notification message.

   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 a Master Device to ask 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, and:

   o  The "masterDeviceLocation" field specifying the location of the
      Master Device is REQUIRED.

   o  The "location" field specifying the location of the Slave Device
      is OPTIONAL, since the Slave Device may not have location-sensing
      capabilities.

   Although the communication and protocol between the Slave Device and
   Master Device are outside the scope of this document (represented as
   dotted lines), the expected message sequence is shown in Figure 4.

Top      Up      ToC       Page 21 
      +------------+     +---------------+      +-------------------+
      |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 4

4.5.1.  AVAIL_SPECTRUM_REQ

   The request message for the Available Spectrum Query protocol MUST
   include a geolocation.  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 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  | see description |
   |requestType:string                | OPTIONAL        |
   |..................................|.................|
   |*other:any                        | OPTIONAL        |
   +----------------------------------+-----------------+

Top      Up      ToC       Page 22 
   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, and it is REQUIRED if the "requestType" parameter is not
      specified.  The deviceDesc parameter may be OPTIONAL for some
      values of requestType.

   location:  The GeoLocation (Section 5.1) for the device requesting
      available spectrum.  More precisely, this is the location at which
      the device intends to operate.  When the request is made by the
      Master Device on its own behalf, the location is that of the
      Master Device, and it is REQUIRED.  When the request is made by
      the Master Device on behalf of a Slave Device, the location is
      that of the Slave Device, and it is OPTIONAL (see also
      masterDeviceLocation).  The location may be an anticipated
      position of the device to 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 code (see Table 1), if it does not implement query
      by region.

      NOTE: Technically, this is the location of the radiation center of
      the device's antenna, but that distinction may be relevant only
      for fixed devices.

   owner:  The DeviceOwner (Section 5.5) information MAY be included to
      register the device with the 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.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.

Top      Up      ToC       Page 23 
   masterDeviceLocation:  When the request is made by the Master Device
      on behalf of a Slave Device, the Master Device MUST provide its
      own GeoLocation (Section 5.1).

   requestType:  The request type is OPTIONAL; it may be used to modify
      the request, but its use depends on the applicable ruleset.  The
      request type may be used, for example, to indicate that the
      response should include generic Slave Device parameters without
      having to specify the 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 the specifics in the Initial
      Registry Contents (Section 9.1.2) for the Ruleset ID Registry.

   other:  Rulesets 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.5.2.  AVAIL_SPECTRUM_RESP

   The response message for the Available Spectrum Query contains one or
   more SpectrumSpec (Section 5.9) elements, one for each ruleset
   supported at the location specified in the corresponding
   AVAIL_SPECTRUM_REQ (Section 4.5.1) message.  Each SpectrumSpec
   element contains a list of one or more spectrum schedules,
   representing permissible power levels over time:

   o  Each spectrum schedule specifies the permissible power level for a
      duration defined by a pair of start and stop times.  The power
      levels refer to permissible EIRP over a resolution bandwidth.

   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.

   Consider a Database that provides a schedule of available spectrum
   for the next 24 hours.  If spectrum availability were to be different
   at different times of day, the response would contain a list of
   schedules, each transition representing some change to the spectrum
   availability.  A device might use different strategies to select
   which spectrum to use, e.g.:

   o  Always use the frequencies that permit the highest power

Top      Up      ToC       Page 24 
   o  Use the frequencies that are available for the longest period of
      time.

   o  Just use the first set of frequencies that matches its needs.

   +---------------------------------------+
   |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 of the response is expressed in UTC using the
      form, YYYY-MM-DDThh:mm:ssZ, as defined by "Date and Time on the
      Internet: Timestamps" [RFC3339].  This can be used by the device
      as a reference for the start and stop times in the spectrum
      schedules.

   deviceDesc:  The Database MUST include the DeviceDescriptor
      (Section 5.2) specified in the AVAIL_SPECTRUM_REQ message.

Top      Up      ToC       Page 25 
   spectrumSpecs:  The SpectrumSpec (Section 5.9) list MUST include at
      least one entry.  Each entry contains the schedules of available
      spectrum for a ruleset.  The Database MAY return more than one
      SpectrumSpec to represent available spectrum for multiple rulesets
      at the specified 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 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.  The device MUST ignore any parameters that it does
      not understand.  Consult the PAWS Parameters Registry
      (Section 9.2) for possible additional 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 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 spectrum-
   availability schedule if the device moves beyond a threshold distance
   (established by the ruleset) from the actual location and all
   anticipated location(s) it reported in previous AVAIL_SPECTRUM_REQ or
   AVAIL_SPECTRUM_BATCH_REQ messages (see "maxLocationChange" in
   RulesetInfo (Section 5.6)).  If the 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
   threshold distance from its current location.

Top      Up      ToC       Page 26 
4.5.3.  AVAIL_SPECTRUM_BATCH_REQ

   The Database MAY implement the 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 single request.  The 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) messages, but it returns these
   results in a batched response (Section 4.5.4).  The request message
   for the batch Available Spectrum Query protocol MUST include at least
   one GeoLocation (Section 5.1).  If the Database does not implement
   batch requests, it MUST return an UNIMPLEMENTED error (see Table 1).

   NOTE: Whether anticipated locations are allowed depends on the
   specified ruleset.  A 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 | see description |  |
   |requestType:string               | OPTIONAL        |  |
   +.................................+.................+  |
   |*other:any                       | OPTIONAL        |  |
   +---------------------------------+-----------------+  |
                                                          |
                                                     1..* V
                                                 +-------------+
                                                 | GeoLocation |
                                                 +-------------+

   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, and it is REQUIRED if the "requestType" parameter is not
      specified.  The deviceDesc parameter may be OPTIONAL for some
      values of requestType.

Top      Up      ToC       Page 27 
   locations:  The GeoLocation (Section 5.1) list for the device is
      REQUIRED.  This allows the device 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 of locations, but the Database MAY restrict the number of
      locations it supports by returning a response with fewer locations
      than specified in the request.  If the locations specify regions,
      rather than points, the Database MAY return an error with the
      UNIMPLEMENTED code (see Table 1), if it does not implement query
      by region.  When the request is made by a Master Device on its own
      behalf, the locations are those of the Master Device.  When the
      request is made by the Master Device on behalf of a Slave Device,
      the locations are those of the Slave Device (see also
      masterDeviceLocation).

   owner:  The DeviceOwner (Section 5.5) information MAY be included to
      register the device with the 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.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 a Slave Device, the Master Device MUST provide its
      own GeoLocation (Section 5.1).

   requestType:  The request type is an OPTIONAL parameter that may be
      used to modify the request, but its use depends on the applicable
      ruleset.  The request type may be used, for example, to request
      generic Slave Device parameters without having to specify the
      device descriptor for a specific device.  When the requestType
      parameter is missing, the request is for a specific device (Master
      or Slave), so deviceDesc is REQUIRED.  The maximum length is 64
      octets.  See the ruleset specifics in the Initial Registry
      Contents (Section 9.1.2) for the Ruleset ID Registry.

Top      Up      ToC       Page 28 
   other:  Rulesets 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.5.4.  AVAIL_SPECTRUM_BATCH_RESP

   The response message for the batch Available Spectrum Query contains
   a schedule 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 of the response of the form,
      YYYY-MM-DDThh:mm:ssZ, as defined by "Date and Time on the
      Internet: Timestamps" [RFC3339].  This can be used by the device
      as a reference for the start and stop times in the spectrum
      schedules.

   deviceDesc:  The 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 is unavailable).
      For each location, the Database MAY return one or more
      SpectrumSpecs (Section 5.9) to represent available spectrum for
      one or more rulesets.  The Database MAY return available spectrum
      for fewer locations than requested.  The order of the entries in

Top      Up      ToC       Page 29 
      the list is not significant, and the device MUST use the location
      value in each GeoSpectrumSpec entry to match available spectrum to
      a 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 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 | see description |
   |spectra:list                     | REQUIRED        |--+
   |...................................................|  |
   |*other:any                       | OPTIONAL        |  |
   +---------------------------------+-----------------+  | 0..*
                                                          V
                                 +--------------------------------+
                                 |Spectrum                        |
                                 +---------------------+----------+
                                 |resolutionBwHz:float | REQUIRED |
                                 |profiles:list        | REQUIRED |
                                 +---------------------+----------+

Top      Up      ToC       Page 30 
   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
      location is that of the Master Device and is REQUIRED.  When the
      notification is made by a Master Device on behalf of a Slave
      Device, the location is that of the Slave Device and is OPTIONAL
      but may be required by some rulesets.

   spectra:  The Spectrum (Section 5.11) list is REQUIRED and specifies
      the spectrum anticipated to be used by the device; this 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", MUST match that
      from one of the Spectrum (Section 5.11) elements in the
      corresponding AVAIL_SPECTRUM_RESP message, and the maximum power
      levels in the Spectrum element MUST be expressed as power (EIRP)
      over the specified "resolutionBwHz" value.  The 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 notification is made by the Master Device
      on behalf of a Slave Device, the Master Device MAY provide its own
      descriptor.

   masterDeviceLocation:  When the notification is made by the Master
      Device on behalf of a Slave Device, the Master Device MUST include
      its own GeoLocation (Section 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.

Top      Up      ToC       Page 31 
4.5.6.  SPECTRUM_USE_RESP

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

   +---------------------------------------+
   |SPECTRUM_USE_RESP                      |
   +----------------------------+----------+
   |databaseChange:DbUpdateSpec | OPTIONAL |
   |.......................................|
   |*other:any                  | OPTIONAL |
   +----------------------------+----------+

   Parameters:

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

4.6.  Device Validation

   A Slave Device needs a Master Device to ask the Database on its
   behalf for available spectrum.  Depending on the ruleset, the Master
   Device also must validate with the Database that the Slave Device is
   permitted to operate.  When the ruleset allows a Master Device to
   "cache" the available spectrum for a period of time, the Master
   Device may use the simpler Device Validation component, instead of
   the full Available Spectrum Query component, to validate a Slave
   Device.

   When validating one or more Slave Devices, the Master Device sends
   the Database a request that includes the device identifier -- and any
   other parameters required by the ruleset -- for each Slave Device.
   The Database 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 the Device Validation request is
   illustrated in Figure 5, 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 Device
   are outside the scope of this document.

Top      Up      ToC       Page 32 
   o  DEV_VALID_REQ (Section 4.6.1) is the device-validation request
      message.

   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

   This request is used by a Master Device to determine which Slave
   Devices are permitted to operate.

   +---------------------------------------------+
   |DEV_VALID_REQ                                |
   +----------------------------------+----------+
   |deviceDescs:list                  | REQUIRED |---+
   |masterDeviceDesc:DeviceDescriptor | OPTIONAL |   |
   +----------------------------------+----------+   |
                                                     V 1..*
                                    +----------------------+
                                    |DeviceDescriptor      |
                                    +----------------------+

Top      Up      ToC       Page 33 
   Parameters:

   deviceDescs:  A DeviceDescriptor (Section 5.2) list is REQUIRED; it
      specifies the list of Slave Devices that are to be validated.

   masterDeviceDesc:  The Master Device MAY provide its own descriptor.

4.6.2.  DEV_VALID_RESP

   +---------------------------------------+
   |DEV_VALID_RESP                         |
   +----------------------------+----------+
   |deviceValidities:list       | REQUIRED |----
   |databaseChange:DbUpdateSpec | OPTIONAL |   |
   +----------------------------+----------+   |
                                               V 1..*
                            +---------------------------------------+
                            |DeviceValidity                         |
                            +----------------------------+----------+
                            |deviceDesc:DeviceDescriptor | REQUIRED |
                            |isValid:boolean             | REQUIRED |
                            |reason:string               | OPTIONAL |
                            +----------------------------+----------+

   Parameters:

   deviceValidities:  A DeviceValidities (Section 5.16) list is REQUIRED
      to report the list of Slave Devices and whether each listed device
      is valid.  The number of entries MUST match the number of
      DeviceDescriptors (Section 5.2) listed in the DEV_VALID_REQ
      message.

   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 alternate database URIs.  The device
      needs to update its preconfigured entry for the responding
      Database with the alternate Databases listed in the DbUpdateSpec.


Next RFC Part