Protocol to Access White-Space (PAWS) Databases

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

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

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. An identifier for a device. Effective Isotropically Radiated Power European Telecommunications Standards Institute (http://www.etsi.org) The U.S. Federal Communications Commission (http://www.fcc.gov) 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. A device that queries the Database, on its own behalf and/or on behalf of a slave device, to obtain available spectrum information. 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. 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. A ruleset can be identified by an IANA-registered identifier (see PAWS Ruleset ID Registry). 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. A device that queries the Database through a master device.

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. 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" and "Protocol Parameters" for details: The Master Device obtains (statically or dynamically) the URI for a Database appropriate for its location, to which to send subsequent PAWS messages. The Master Device establishes an HTTPS session with the Database. The Master Device optionally sends an initialization message to the Database to exchange capabilities. If the Database receives an initialization message, it responds with an initialization-response message in the body of the HTTP response. The Database may require the Master Device to be registered before providing service. 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. 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. The Database responds with an available-spectrum response message in the body of the HTTP response. 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. 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.

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: 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. 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. If required parameters are missing from the request, the Database responds with an error and a list of names of the missing parameters. The Master Device makes the request again, adding the missing parameter values. The Database responds to the request, including the identifier of the applicable ruleset. 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 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.

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. Database Discovery is a required component for the Master Device. Initialization is a required component for the Database. Its use allows the Master Device to determine necessary information that has not been preconfigured. Device Registration is an optional component for the Database. It can be implemented as a separate component or as part of the Available Spectrum Query 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. Available Spectrum Query is a required component for the Master Device and the Database. Spectrum Use Notify 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. Device Validation 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. This section describes the protocol components and their messages. "Protocol Parameters" contains a more thorough discussion of the parameters that make up the PAWS request and response messages. "Message Encoding" provides examples of message encodings. "HTTPS Binding" describes the use of HTTPS ("HTTP Over TLS") for transferring PAWS messages and optional device authentication. The parameter tables in this section and "Protocol Parameters" 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" or are one of the following primitive or structured types: A string, as defined by JSON, restricted to the UTF-8 encoding. A number, as defined by JSON, without a fractional or exponent part. A number, as defined by JSON. A boolean, as defined by JSON. A structured type that represents a list of elements, as defined by JSON 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: All parameter names are case sensitive. Unless stated otherwise, all string values are case sensitive. 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". 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 . When a request message sent to the Database has missing parameters, whether they are required by PAWS or the applicable ruleset, the Database returns the MISSING error (see ), along with data indicating the missing parameters.

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" for further information.

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

The device SHOULD select another Database from its list of preconfigured Databases if: The selected Database is unreachable or does not respond. The selected Database returns an UNSUPPORTED error (see "Error Codes"), 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.

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

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"). 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 . INIT_REQ is the initialization request message INIT_RESP is the initialization response message

| | | | INIT_RESP | |<--------------------| | |]]>

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

Parameters: The DeviceDescriptor 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 list that specifies the rulesets that it supports at the specified location. The GeoLocation 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 ). 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 for possible additional parameters.

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.

| RulesetInfo | |databaseChange:DbUpdateSpec | OPTIONAL | +-------------+ |.......................................| |*other:any | OPTIONAL | +----------------------------+----------+]]> Parameters: A RulesetInfo 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 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 supports none of the rulesets specified in the DeviceDescriptor, it MUST instead return an error with the UNSUPPORTED code (see ) in the error response. The Database MAY include a DbUpdateSpec 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. The Database MAY include additional handshake parameters in the INIT_RESP message. The Master Device MUST ignore all parameters it does not understand. Consult the PAWS Parameters Registry for possible additional parameters.

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). 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 ) in the error-response message. The Device Registration request procedure is depicted in . REGISTRATION_REQ is the device-registration request message REGISTRATION_RESP is the device-registration response message

| | | | REGISTRATION_RESP | |<------------------------| | |]]>

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

Parameters: The DeviceDescriptor for the Master Device is REQUIRED. The ruleset IDs included in the DeviceDescriptor indicate the rulesets for which the device wishes to register. The GeoLocation 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 ). The DeviceOwner information is OPTIONAL. Some rulesets may require deviceOwner information under certain conditions. See PAWS Ruleset ID Registry for ruleset-specific requirements. The AntennaCharacteristics is OPTIONAL. 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 for possible additional parameters.

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

| RulesetInfo | |databaseChange:DbUpdateSpec | OPTIONAL | +-------------+ |............................|..........| |*other:any | OPTIONAL | +----------------------------+----------+]]> Parameters: A RulesetInfo 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 ) in the error response. The Database MAY include a DbUpdateSpec 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. 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 for possible additional parameters.

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 . AVAIL_SPECTRUM_REQ is the available-spectrum request message. AVAIL_SPECTRUM_RESP is the available-spectrum response message. AVAIL_SPECTRUM_BATCH_REQ is an OPTIONAL batch version of the available-spectrum request message that allows multiple locations to be specified in the request. AVAIL_SPECTRUM_BATCH_RESP is the response message for the batch version of the available-spectrum request that contains available spectrum for each location in the request. SPECTRUM_USE_NOTIFY is the spectrum-usage notification message. SPECTRUM_USE_RESP is the spectrum-usage acknowledgment message.

| | | | AVAIL_SPECTRUM_RESP | | (AVAIL_SPECTRUM_BATCH_RESP)| |<---------------------------| | | | (SPECTRUM_USE_NOTIFY) | |--------------------------->| | | | (SPECTRUM_USE_RESP) | |<---------------------------| | |]]> First, the Master Device sends an available-spectrum request message to the Database. The Database MUST respond with an error using the NOT_REGISTERED code (see ) if: registration information is required, and the request does not include registration information, and the device has not previously registered with the Database 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 ). 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. 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. If the request is missing required parameters, the Database MUST respond with a MISSING error (see ) and SHOULD include a list of the missing parameters. 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. 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. 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: The "masterDeviceLocation" field specifying the location of the Master Device is REQUIRED. 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 .

| | | | | | | AVAIL_SPECTRUM_REQ | | |-------------------------->| | | | | | AVAIL_SPECTRUM_RESP | | |<--------------------------| | AVAIL_SPEC_RESP | | |<................| | | | | | (SPECTRUM_USE) | | |................>| (SPECTRUM_USE_NOTIFY) | | |-------------------------->| | | | | | (SPECTRUM_USE_RESP) | | |<--------------------------| | | |]]>

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.

Parameters: The DeviceDescriptor 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. The GeoLocation 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 ), 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. The DeviceOwner 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. The AntennaCharacteristics is OPTIONAL. The Master Device MAY include its DeviceCapabilities 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. When the request is made by the Master Device on behalf of a Slave Device, the Master Device MAY provide its own descriptor. When the request is made by the Master Device on behalf of a Slave Device, the Master Device MUST provide its own GeoLocation. 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 for the Ruleset ID Registry. Rulesets and database implementations may require additional request parameters. The Database MUST ignore all parameters it does not understand. Consult the PAWS Parameters Registry for possible additional parameters.

The response message for the Available Spectrum Query contains one or more SpectrumSpec elements, one for each ruleset supported at the location specified in the corresponding AVAIL_SPECTRUM_REQ message. Each SpectrumSpec element contains a list of one or more spectrum schedules, representing permissible power levels over time: 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. Within each list of schedules, event-time intervals MUST be disjoint and MUST be sorted in increasing time. 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.: Always use the frequencies that permit the highest power Use the frequencies that are available for the longest period of time. Just use the first set of frequencies that matches its needs.

Parameters: Timestamp of the response is expressed in UTC using the form, YYYY&nbhy;MM&nbhy;DDThh:mm:ssZ, as defined by "Date and Time on the Internet: Timestamps". This can be used by the device as a reference for the start and stop times in the spectrum schedules. The Database MUST include the DeviceDescriptor specified in the AVAIL_SPECTRUM_REQ message. The SpectrumSpec 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. The Database MAY include a DbUpdateSpec 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. 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 for possible additional parameters and requirements they place on the device.

When the stop time specified in the schedule has been reached, the device: MUST obtain a new spectrum-availability schedule, either by using the next one in the list (if provided) or making another Available Spectrum Query. 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). 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.

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 messages, but it returns these results in a batched response (). The request message for the batch Available Spectrum Query protocol MUST include at least one GeoLocation. If the Database does not implement batch requests, it MUST return an UNIMPLEMENTED error (see ). NOTE: Whether anticipated locations are allowed depends on the specified ruleset. A parameter marked as optional may be required by some rulesets.

Parameters: The DeviceDescriptor 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. The GeoLocation 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 ), 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). The DeviceOwner 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. The AntennaCharacteristics is OPTIONAL. The Master Device MAY include its DeviceCapabilities 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. When the request is made by the Master Device on behalf of a Slave Device, the Master Device MAY provide its own descriptor. When the request is made by the Master Device on behalf of a Slave Device, the Master Device MUST provide its own GeoLocation. 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 for the Ruleset ID Registry. Rulesets and database implementations may require additional request parameters. The Database MUST ignore all parameters it does not understand. Consult the PAWS Parameters Registry for possible additional parameters.

The response message for the batch Available Spectrum Query contains a schedule of available spectrum for the device at multiple locations.

Parameters: Timestamp of the response of the form, YYYY&nbhy;MM&nbhy;DDThh:mm:ssZ, as defined by "Date and Time on the Internet: Timestamps". This can be used by the device as a reference for the start and stop times in the spectrum schedules. The Database MUST include the DeviceDescriptor specified in the AVAIL_SPECTRUM_BATCH_REQ message. The geoSpectrumSpecs list is REQUIRED (although it MAY be empty if spectrum is unavailable). For each location, the Database MAY return one or more SpectrumSpecs 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 the list is not significant, and the device MUST use the location value in each GeoSpectrumSpec entry to match available spectrum to a location. The Database MAY include a DbUpdateSpec 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. Database implementations MAY return additional parameters in the response. Consult the PAWS Parameters Registry for possible additional parameters and requirements they place on the device. See "Update Requirements" for when the device must update its available spectrum data.

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

Parameters: The DeviceDescriptor for the device is REQUIRED. The GeoLocation 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. The Spectrum 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 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. When the notification is made by the Master Device on behalf of a Slave Device, the Master Device MAY provide its own descriptor. When the notification is made by the Master Device on behalf of a Slave Device, the Master Device MUST include its own GeoLocation. 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.

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

Parameters: The Database MAY include a DbUpdateSpec 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. Database implementations MAY return additional parameters in the response. Consult the PAWS Parameters Registry for possible additional parameters.

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 , 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. DEV_VALID_REQ is the device-validation request message. DEV_VALID_RESP is the device-validation response message.

| | | | | | | DEV_VALID_REQ | | |-------------------------->| | | | | | DEV_VALID_RESP | | |<--------------------------| | AVAIL_SPEC_RESP | | |<................| | | | | | (SPECTRUM_USE) | | |................>| (SPECTRUM_USE_NOTIFY) | | |-------------------------->| | | | | | (SPECTRUM_USE_RESP) | | |<--------------------------| ]]>

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

Parameters: A DeviceDescriptor list is REQUIRED; it specifies the list of Slave Devices that are to be validated. The Master Device MAY provide its own descriptor.

Parameters: A DeviceValidities 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 listed in the DEV_VALID_REQ message. The Database MAY include a DbUpdateSpec 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.

This section presents more details of the parameters that make up the PAWS request and response messages. It also includes a subsection that defines response codes.

GeoLocation is used to specify one of the following: a single point with optional uncertainty a region described by a polygon These are represented using geometric shapes defined in Section 5 of "GEOPRIV Presence Information Data Format Location Object" , where: A "point" with uncertainty is represented using the Ellipse shape. A region is represented using the Polygon shape. The coordinates are expressed using the WGS84 datum, and units are degrees or meters. GeoLocation MAY also include a confidence level, expressed as a percentage. The confidence and uncertainty parameters may be required by some rulesets (see also ). The data model for GeoLocation is illustrated below:

|Point | +-------------------+-----------+ +----------------+----------+ |latitude:float | REQUIRED | |longitude:float | REQUIRED | +----------------+----------+ ]]> Parameters: If present, it specifies the GeoLocation as 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. If present, it specifies the GeoLocation as a region. Exactly one of "point" or "region" MUST be present. The center refers to the location of a GeoLocation point and is represented as the center of an ellipse. Floating-point numbers that express the latitude and longitude in degrees using the WGS84 datum. This OPTIONAL parameter expresses the location uncertainty, in meters. It is parameterized using distances along the major and minor axes of the ellipse. The default value for each parameter is 0. 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 uncertainty is greatest along the East-West direction, orientation is 90 degrees. When orientation is not present, the default value is 0. When GeoLocation describes a region, the "exterior" parameter refers to a list of latitude and longitude points that represents the vertices of a polygon. The first and last points MUST be the same. Thus, a minimum of 4 points is required. The following polygon restrictions from apply: A connecting line SHALL NOT cross another connecting line of the same polygon. The vertices MUST be defined in a counter-clockwise direction, looking at them from above. The edges of a polygon are defined by the shortest path between two points in space (not a geodesic curve). Consequently, the length between two adjacent vertices SHOULD be restricted to a maximum of 130 km. Polygon shapes SHOULD be restricted to a maximum of 15 vertices (16 points that includes the repeated vertex). Additionally, all vertices are assumed to be at the same altitude. The location confidence level, as a percentage, MAY be provided. When this parameter is not provided, the default value is 95. Valid values range from 0 to 100, but, in practice, 100% confidence is not achievable. The confidence value is meaningful only when GeoLocation refers to a point with uncertainty.

The device descriptor contains parameters that identify the specific device, such as its manufacturer serial number, manufacturer's ID, and any other device characteristics required by ruleset.

string |.....................|..........| |*other:any | OPTIONAL | +---------------------+----------+]]> Parameters: The manufacturer's device serial number is OPTIONAL, although rulesets typically require it. Its maximum length is 64 octets. The manufacturer's ID is OPTIONAL but may be required by some rulesets. This represents the name of the device manufacturer, and therefore ought to be consistent across all devices from the same manufacturer and distinct from that of other manufacturers. Its maximum length is 64 octets. The device's model ID is OPTIONAL but may be required by some rulesets. Its maximum length is 64 octets. The list of identifiers for rulesets supported by the device (see Ruleset ID Registry). A Database MAY require that the device provides this list before servicing the device requests. If the Database supports none of the rulesets specified in the list, the Database MAY refuse to service the device requests. See RulesetInfo for discussion on ruleset identifiers. If present, the list MUST contain at least one entry. Depending on the ruleset, other parameters may be required. The Database MUST ignore all parameters in the message it does not understand. See PAWS Parameters Registry for additional valid parameters and for the process for extending the message with more parameters. Additionally, see PAWS Ruleset ID Registry for the valid set of parameters for each ruleset.

Antenna characteristics provide additional information, such as the antenna height, antenna type, etc. Whether antenna characteristics must be provided in a request depends on the device type and ruleset. Additionally, a parameter marked as optional may be required by some rulesets.

Parameters: The antenna height in meters. Note that the height may be negative. Valid values are: - Above Ground Level (default) - Above Mean Sea Level The height uncertainty in meters. NOTE: Depending on the ruleset, additional antenna characteristics may be required, such as: antenna direction antenna radiation pattern antenna gain antenna polarization These are not defined by the base protocol but may be added to the PAWS Parameters Registry, as needed.

Device capabilities provide additional information that may be used by the device to provide additional information to the Database that can help it to determine available spectrum. If the Database does not support device capabilities, it MUST ignore the parameter altogether.

Parameters: Optional FrequencyRange list. Each FrequencyRange element contains start and stop frequencies in which the device can operate. When specified, the Database SHOULD NOT return available spectrum that falls outside these ranges. Consult the PAWS Parameters Registry for possible additional parameters. The Database MUST ignore all parameters it does not understand.

DeviceOwner contains information on device ownership that is provided as part of device registration. Some rulesets may require additional parameters.

Parameters: The vCard contact information for the individual or business that owns the device is REQUIRED. The vCard contact information for the device operator is OPTIONAL but may be required by specific rulesets. See PAWS Ruleset ID Registry for ruleset-specific requirements on mandatory vCard properties. Depending on the ruleset, the Database may be required to validate the device-owner information. In these cases, the Database MUST respond with an INVALID_VALUE error (see "Error Codes") if validation fails. All contact information MUST be expressed using the structure defined by the "vCard Format Specification" , encoded in JSON. Note that the vCard specification defines maximum lengths for each parameter.

RulesetInfo contains parameters for the ruleset of a regulatory domain that is communicated using the Initialization, Device Registration, and Available Spectrum Query components.

Parameters: A string that indicates the regulatory domain to which the ruleset applies is REQUIRED. It will normally be a 2-letter country code defined by Country Codes - ISO 3166. The ID of a ruleset for the specified authority (see Ruleset ID Registry). The device can use this to determine additional device behavior required by the associated ruleset. To define new ruleset IDs, see "Defining Ruleset Identifiers". The maximum location change in meters is REQUIRED for the Initialization Response, 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 the available spectrum for the new location. If this value is provided by the Database within the context of an Available Spectrum Response, it takes precedence over the value within the Initialization Response. The maximum duration, in seconds, between requests for available spectrum is REQUIRED for the Initialization Response, but OPTIONAL otherwise. The device MUST contact the Database to get available spectrum no less frequently than this duration. If this value is provided within the context of an Available Spectrum Response, it takes precedence over the value within the Initialization Response. Depending on the ruleset, other parameters may be required. The device MUST ignore all parameters in the message it does not understand. Consult the PAWS Parameters Registry for possible additional parameters.

This element is provided by the Database to notify devices of an upcoming change to the database URI.

|DatabaseSpec | +---------------------+---------+ 1..* +---------------+----------+ |name:string | REQUIRED | |uri:string | REQUIRED | +---------------+----------+]]> Parameters: List of one or more DatabaseSpec entries. A device needs to update its preconfigured entry for the responding Database with the alternate Databases listed in the DbUpdateSpec.

This element contains the name and URI of a Database.

Parameters: The display name. Its maximum length is 64 octets. The corresponding URI of the Database. Its maximum length is 1024 octets.

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

Parameters: RulesetInfo is REQUIRED to identify the regulatory domain and ruleset to which the spectrum schedule applies (see Ruleset ID Registry ). The device needs to use the corresponding ruleset to interpret the response. Values provided within rulesetInfo, such as maxLocationChange, take precedence over the values provided by the Initialization Procedure. The SpectrumSchedule list is REQUIRED. At least one schedule MUST be included. More than one schedule MAY be included to represent future changes to the 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. The time range for which the specification is comprehensive is OPTIONAL. When specified, any gaps in time intervals within the spectrumSchedules element that overlap with the range specified by "timeRange" are interpreted by the device as time intervals in which there is no available spectrum. Specifying the frequency ranges for which the specification is comprehensive is OPTIONAL. It is a list of disjoint FrequencyRange entries. When specified, it typically corresponds to the frequency ranges governed by the ruleset, e.g., for TV white space, the 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 no information has been provided". The Database MAY return true for this parameter if spectrumSchedules list is non-empty; otherwise, the 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 message to the Database; otherwise, the device SHOULD NOT send the SPECTRUM_USE_NOTIFY message. Some rulesets mandate this value be set to true. The Database MAY return a constraint on the maximum total bandwidth (in hertz) allowed, which may or may not be contiguous. Some rulesets mandate the Database to return this parameter. When present in the response, the device needs to apply this constraint to its spectrum-selection logic to ensure total bandwidth does not exceed this value. The Database MAY return a constraint on the maximum contiguous bandwidth (in hertz) allowed. Some rulesets mandate the Database 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 exceeds this value.

The SpectrumSchedule element combines EventTime with Spectrum to define a time period in which the spectrum is valid.

|Spectrum | +--------------------+----------+ 0..* +--------------------+ |resolutionBwHz:float| |profiles:list | +--------------------+]]> Parameters: The EventTime is REQUIRED to express "when" this specification is valid. The Spectrum list is REQUIRED to specify the available spectrum and permissible power levels, one per resolutionBwHz. The list MAY be empty when there is no available 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 that the spectrum profiles represent the "availability mask", as defined by the governing ruleset; they are not intended to encode device-level transmission-mask requirements. NOTE: Within the contexts of the AVAIL_SPECTRUM_RESP, AVAIL_SPECTRUM_BATCH_RESP, and SPECTRUM_USE_NOTIFY messages, the power levels expressed within the Spectrum messages refer to EIRP. Future extensions of PAWS may use Spectrum in other contexts for other definitions of power levels. To support a ruleset that defines different "wide-band" and "narrow-band" power levels, PAWS allows multiple Spectrum elements to be included in the available-spectrum response, each with a different resolution bandwidth. When multiple Spectrum elements are included in the response, each represents a constraint that the device must satisfy (logical AND). Each Spectrum element covers the range of frequencies governed by a ruleset, rather than splitting the frequencies across multiple Spectrum elements for the same resolution bandwidth. Each spectrum profile represents the maximum permissible power spectral density over a contiguous range of frequencies. When multiple spectrum profiles are included, they MUST be disjoint and MUST be ordered in non-decreasing frequency value. Gaps in frequencies between consecutive spectrum profiles represent unavailability for those frequencies. The following figure illustrates the Spectrum element and the SpectrumProfile list.

Parameters: 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 6 MHz, and ETSI regulation would require two specifications, at 0.1 MHz and 8 MHz. A SpectrumProfile list specifies permissible power levels over a set of frequency ranges. The list MAY be empty if there is no available spectrum. The following example shows permitted power spectral densities for a single resolution bandwidth of 6 MHz (for illustrative purposes only):

This is interpreted as: Over any 6 MHz within the frequency range [518 MHz, 530 MHz), maximum permitted power is 30.0 dBm (1000 mW) 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):

This is interpreted as: Over any 6 MHz within the frequency range [518 MHz, 530 MHz), maximum permitted power is 30.0 dBm (1000 mW), and Over any 100 kHz within the frequency range [518 MHz, 530 MHz), maximum permitted power is 27.0 dBm (500 mW) This would allow, for example, operating two 100 kHz sub-channels within the indicated 12 MHz range at 500 mW each, totaling 1000 mW. 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):

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. It MUST contain a minimum of two entries. The entries in the list MUST be ordered in non-decreasing frequency values. Two consecutive points MAY have the same frequency value to represent a "step function". Three or more points MUST NOT share the same frequency value. The first frequency is inclusive; the last frequency is exclusive. NOTE: This encoding allows presentation of "ramps" where the slope of a line segment may be finite and non-zero. The following figure illustrates the SpectrumProfile element.

Parameters of each point in the profile: The frequency, in hertz, at which the power level is defined. The power level, expressed as dBm per resolution bandwidth, as defined by the resolutionBwHz element of the enclosing Spectrum element.

FrequencyRange specifies a frequency range.

Parameters: The inclusive start of the frequency range (in hertz) is REQUIRED. The exclusive end of the frequency range (in hertz) is REQUIRED.

The EventTime element specifies the start and stop times of an "event". This is used to indicate the time period for which a Spectrum is valid.

Parameters: The inclusive start of the event is REQUIRED. The exclusive end of the event is REQUIRED. Both times are expressed using the format, YYYY-MM-DDThh:mm:ssZ, as defined by "Date and Time on the Internet: Timestamps". 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 substitute for the current time (see "Available Spectrum Response" and "Available Spectrum Batch Response"). For example, (startTime - timestamp) gives the duration that a device must wait before the event becomes "active". If the value is zero or negative, the event is already active. If the event is already active, (stopTime - timestamp) is the duration that the event remains active. If the value is zero or negative, the event is no longer active and MUST be ignored.

The GeoSpectrumSpec element encapsulates the available spectrum for a location. It is returned within an AVAIL_SPECTRUM_BATCH_RESP batch response that contains multiple GeoSpectrumSpec entries, each matching a location provided in the batch request.

Parameters: The GeoLocation identifies the location at which the spectrum schedule applies. The SpectrumSpec list is 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.

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

Parameters: The DeviceDescriptor that was used to check for validity is REQUIRED. This is a REQUIRED boolean value that indicates whether the device is valid. If the device identifier is not valid, the Database MAY include a reason. The reason MAY be in any language. Its maximum length is 128 octets.

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

Parameters: An integer code that indicates the error type is REQUIRED. Values MUST be within the range -32768 to 32767, inclusive. A description of the error is OPTIONAL. It MAY be in any language. Its maximum length is 128 octets. The Database MAY include additional data. For some errors, additional data may be required (see ). 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: Indicates compatibility issues, e.g., version mismatch, unsupported or unimplemented features. Indicates that the device request contains an error that needs to be modified before making another request. Indicates authorization-related issues. Values that are not defined explicitly in the Error Codes Table below are unassigned. To define new error codes, see PAWS Error Code Registry. Code Name Description and Additional Parameters 0 (reserved) -100 (reserved) -101 VERSION The Database does not support the specified version of the message. This error does not use any additional data. -102 UNSUPPORTED The Database does not support the device. For example, it supports none of the rulesets specified in the request or does not support the device, based on its device type, model, etc. This error does not use any additional data. -103 UNIMPLEMENTED The Database does not implement the optional request or optional feature. This error does not use any additional data. -104 OUTSIDE_COVERAGE The specified geolocation is outside the coverage area of the Database. The Database MAY include a DbUpdateSpec to provide a list of alternate Databases that might be appropriate for the requested location. See OUTSIDE_COVERAGE Error for more details. -105 DATABASE_CHANGE The Database has changed its URI. The Database MAY include a DbUpdateSpec in the error response to provide devices with 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. See DATABASE_CHANGE Error for more details. -200 (reserved) -201 MISSING A required parameter is missing. The Database MUST include a list 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 the device. See MISSING Error for more details. -202 INVALID_VALUE A parameter value is invalid in some way. The Database SHOULD include a message indicating which parameter and 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 ruleset or be dependent on prior arrangement between the device and Database. This error does not use any additional data. -302 NOT_REGISTERED Device registration required, but the device is not registered. This error does not use any additional data. -32000 to -32768 (reserved) Reserved for JSON-RPC error codes.

When the error code is OUTSIDE_COVERAGE, the Database MAY include an ErrorData element within its Error response as the "data" parameter, and, if present, the ErrorData contains a DbUpdateSpec element that provides a list of alternate Databases that might be appropriate for the requested location.

When the error code is DATABASE_CHANGE, the Database MAY include an ErrorData element within its Error response as the "data" parameter, and, if present, the ErrorData contains a DbUpdateSpec element that provides a list of alternate Databases.

When the error code is MISSING, the Database MUST include an ErrorData element within its Error response as the "data" parameter, and the ErrorData element MUST include a list of the missing required parameters and MAY include the list of all required parameters.

|ErrorData | +----------------+----------+ +----------------+----------+ 1..* |parameters:list | REQUIRED |--+ +----------------+----------+ | v string ]]> Parameters: List of one or more parameter names (strings). The name of a parameter is expressed using dotted notation, when appropriate, e.g., "deviceDesc.serialNumber".

PAWS is encoded using JSON-RPC (see also "The JavaScript Object Notation (JSON) Data Interchange Format" ). Each component described in Protocol Functionalities corresponds to one or more JSON-RPC methods. This section discusses how to encode the data models presented in Sections and into JSON and provides some example encodings. The JSON examples may contain ellipses (...) to represent additional properties or elements that have been omitted in order to make the examples more concise.

The JSON-RPC protocol consists of two basic objects, Request and Response: The JSON-RPC Request object encapsulates a PAWS functionality (operation) and the request message. The JSON-RPC Response object encapsulates a PAWS response message and an Error element. The Database and device MUST support JSON-RPC 2.0 encoding, with the restriction that the "id" parameter in the messages MUST be a string. The device should generate the "id" uniquely enough to allow the use of JSON-RPC batch. The JSON-RPC Request for PAWS has the following form:

, "id": "idString" } ]]> where "method" is the name of a PAWS functionality (operation), and <PAWS_REQ> represents one of the PAWS request messages associated with the method (see Sections through ). Method names are defined with the prefix "spectrum.paws.". The non-error JSON-RPC Response for PAWS has the following form:

, "id": "idString" } ]]> where <PAWS_RESP> represents one of the PAWS response messages associated with the method, and "id" is copied from the request. The error JSON-RPC Response for PAWS has the following form:

where the "error" object corresponds to the Error Element, 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 is not available, it SHOULD fall back to standard JSON-RPC error codes as defined in the JSON-RPC specification. For example, if the Database receives invalid JSON from the device, it should respond with "-32700", signifying a parse error. As a last resort, the Database MAY send a suitable HTTP 5xx response.

Table 2 defines the method name, request object, and response object for each functionality defined in Protocol Functionalities.

JSON encoding of the data models described in Sections and is straightforward: Each data model describes the contents of a JSON object. Each parameter of a data model corresponds to a member of the corresponding JSON object: The parameter name of the data model is the same as the member name of the JSON object. The parameter data type describes the type of the member value. Primitive types map to JSON type, as described in and repeated here: A JSON string, restricted to UTF-8 encoding A JSON number, without a fractional or exponent part A JSON number One of the JSON values, true or false The list type maps to a JSON array, except that all values in the array are of the same type. When the parameter data type refers to another data model, that data model describes a nested JSON object. The encoded JSON object for each of the Request and Response message listed in the Method Names Table (Table 2) also includes the following members: The name of the message, e.g., "INIT_REQ" The PAWS version, e.g., "1.0" See the following sections for examples.

An example of the "spectrum.paws.init" JSON-RPC request is shown below.

An example of the corresponding JSON-RPC response is shown below.

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

The following example "spectrum.paws.getSpectrum" JSON-RPC response contains: A schedule with two time ranges A spectrum profile for one resolution bandwidth (6 MHz) The power levels for two frequency segments: From 518 MHz to 542 MHz From 620 MHz to 626 MHz In practice, each "profiles" list contains (frequency, power) points to cover all frequencies governed by the associated ruleset. See "Spectrum" for a more detailed discussion on the representation.

The following example "spectrum.paws.getSpectrum" JSON-RPC response includes a spectrum profile that contains specifications for two different bandwidth resolutions (6 MHz and 100 kHz):

The DeviceOwner data model contains member values that are JSON encodings of vCard, as described in "jCard: The JSON format for vCard". An example fragment is provided below:

This section describes the use of "HTTP Over TLS" (HTTPS) as the transfer mechanism for PAWS. TLS provides message integrity and confidentiality between the Master Device and the Database, but only when best current practices are adopted, including use of recommended cipher suites and modes of operation. Consequently, to improve PAWS security and interoperability, implementations of the Database and Master Device MUST follow best current practices defined by "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)". Depending on a prior relationship between a Database and device, the server MAY require client authentication, as described in the "Transport Layer Security (TLS) Protocol", to authenticate the device. When client authentication is required, the Database MUST specify, by prior arrangement, acceptable root Certification Authorities (CAs) to serve as trust anchors for device certificates. To enable Databases to handle large numbers of requests from large numbers of devices, the Database MAY support and devices SHOULD support "Stateless TLS Session Resumption". 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 405 (method not allowed). The Database MAY redirect a PAWS request by returning a HTTP 3xx response (as defined by Section 6.4 of "HTTP/1.1: Semantics and Content"). The Database MUST provide the redirect URI in the Location header of the 3xx response, and the device MUST handle redirects by using the Location header provided by the Database. When redirecting, the device MUST observe the delay indicated by the Retry-After header. The device MUST authenticate the Database that returns the redirect response before following the redirect. Also, the device MUST authenticate the Database indicated in the redirect. Since the device may communicate with a Database (which it authenticated) without user interaction, when the response code is 301 (Moved Permanently), the device MAY redirect without asking a user for confirmation, even thought it is in response to an HTTP POST method. The Database SHOULD use HTTP status code "307 Temporary Redirect" to indicate that the device SHOULD resubmit the same request to an alternate URI. The device MAY revert to the original URI for the very next request, or it MAY continue to use the alternate URI for a period of time, e.g.,: For the remainder of its session, or For a fixed period of time, or Until power cycled, or Until it receives another redirect However, the device does not need to modify its stored list of URIs. For a minimum of two weeks before the URI of the Database changes permanently, it MUST use the database-change (DbUpdateSpec) mechanism to notify devices, as described in "Configuration Update: Database URI Changes" . After the Database has moved, requests to the original URI MAY return HTTP status code 301 (Moved Permanently) to indicate that the device SHOULD resubmit the request, and all future requests, to the indicated alternate URI.

This section describes procedures for extending PAWS. No extensions should be made that would return sensitive device-specific information in database responses.

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 . Ruleset ID values MUST conform to the ruleset-id ABNF. If the Ruleset ID requires additional parameters, they are registered in the PAWS Parameters Registry, as described by . The ABNF syntax is as follows.

When defining a Ruleset ID: 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. The identifier SHOULD include some sort of version information, such as a year and/or version number. The maximum length of the identifier is 64 octets.

New request or response parameters for use with PAWS are defined and registered in the parameters registry following the procedure in . 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).

Parameter names use lowerCamelCase by convention. The maximum length of a name is 64 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').

Additional error codes can be registered to extend the set listed in , following the procedures in . If the error code requires additional response parameters, they are registered in the PAWS Parameters Registry, as described by . By convention, the error code is a negative integer value, using one of the range of values defined in Error Codes . If an appropriate category does not exist, a value from a different range may be used.

There are three registries associated with PAWS: PAWS Ruleset ID Registry PAWS Parameter Registry PAWS Error Code Registry All registries use the Specification Required policy , with a Designated Expert appointed by the IESG. Specific criteria that the Designated Expert should use in assessing registrations are given below in the description of each registry. The Designated 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. Upon approval, IANA will post the registrations that are not intended to be published in an RFC.

This specification establishes the "PAWS Ruleset ID Registry". Ruleset type names for inclusion in PAWS messages are registered on the advice of one or more Designated Experts, with Specification Required. The specification must include a reference to the regulatory 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 from an existing ruleset. The Designated Expert should ensure that the proposed registration is complete with respect to its associated regulatory domain and may seek an expert familiar with those rules to participate in the review on the paws@ietf.org mailing list. The PAWS Ruleset ID Registry includes the following: 'Ruleset Identifier', 'Reference', and 'Template'. The Template column will include links to the registration templates, either posted by IANA or linked to the relevant sections of RFCs.

The name of the ruleset. See of RFC 7545 for the format requirements of this identifier. 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. Listing of additional parameter requirements to associate with the ruleset. Note that new parameters are registered separately in the PAWS Parameters Registry, as described by . Two types of additional parameter requirements are: Addition of new parameters to existing structures, or modification of the REQUIRED and OPTIONAL requirements for existing parameters. Modification of requirements to existing parameter values. For adding new parameters or modifying requirements of existing parameters, the registration should include a table for each affected structure that lists the structure's parameter changes. Each table should include a structure name in its heading and have the following columns: Name of the parameter added or modified. Data type of the parameter value. Whether the parameter is REQUIRED or OPTIONAL for the ruleset. Any additional notes that might be useful to implementors. For modifying requirements to existing parameter values, the registration should include a table for each affected structure that lists the structure's parameter changes. Each table should include a structure name in its heading and have the following columns: Name of the parameter. Data type of the parameter value. Additional requirements on the parameter value. IANA will post each registration template that is not intended to be published in an RFC. Note that the Additional Parameter Requirements section can be quite extensive, so it will not appear directly in the IANA Ruleset ID Registry table. The table, however, will contain a link to the full registration template for easy access to the additional requirements.

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, they are the only regulatory domains that have finalized rules. There is no intent to restrict the protocol to any particular set of authorities. The initial contents of the PAWS Ruleset ID Registry are listed below; each section corresponds to a single entry in the registry.

For the additional parameters that start with the "fcc" prefix, see PAWS Parameters Registry Initial Contents for more information. FccTvBandWhiteSpace-2010 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. Additional Parameter Requirements 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. The FCC requires registration of "Fixed Devices". Additionally, deviceOwner is required in the registration request: Registration Request Parameter Name Type Requirement Notes deviceOwner DeviceOwner REQUIRED For registering Fixed Devices Available Spectrum Request Parameter Name Type Requirement Notes deviceDesc DeviceDescriptor REQUIRED Available Spectrum Batch Request Parameter Name Type Requirement Notes deviceDesc DeviceDescriptor REQUIRED DeviceDescriptor Parameter Name Type Requirement Notes serialNumber string REQUIRED Specifies a device's serial number. See . fccId string REQUIRED Specifies a device's FCC certification ID. fccTvbdDeviceType string REQUIRED Specifies the FCC Device Type of TV-band white-space device, as defined by the FCC rules. The following table lists additional requirements for DeviceOwner parameter values. DeviceOwner Parameter Name Type Additional Requirement owner vCard The owner is required to contain the formatted name of an individual or organization using the "fn" property. When the name is that of an organization, the entry also is required to contain the "kind" property, with a value of "org". operator vCard The operator entry is required to contain the following properties for the contact person responsible for the device's operation: "fn", "adr", "tel", and "email".

For the additional parameters that start with the "etsi" prefix, see PAWS Parameters Registry Initial Contents for more information. ETSI-EN-301-598-1.1.1 This ruleset refers to the ETSI Harmonised Standard established by ETSI. Additional Parameter Requirements 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.

AVAIL_SPECTRUM_REQ Parameter Name Type Requirement Notes requestType string OPTIONAL Modifies the available-spectrum request type. If specified, the only valid value is, "Generic Slave", and the Database is required to respond with generic operating parameters for any Slave Device. Available Spectrum Batch Request Parameter Name Type Requirement Notes requestType string OPTIONAL Modifies the available-spectrum request type. If specified, the only valid value is, "Generic Slave", and the Database is required to respond with generic operating parameters for any Slave Device. The following tables define additional requirements for the DeviceDescriptor and RulesetInfo parameters that appear in the AVAIL_SPECTRUM_RESP and AVAIL_SPECTRUM_BATCH_RESP messages. Note that this means the Database is modifying the DeviceDescriptor sent by the Master Device to return device-specific restrictions.

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

This specification establishes the "PAWS Parameters Registry". Additional parameters for inclusion in PAWS requests, responses, or sub-messages are registered on the advice of one or more Designated Experts, with Specification Required. 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, 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 that is used by existing ruleset parameters (e.g., "fcc", "etsi") or that is the initials of an organization that has not yet registered anything, but reasonably might. The PAWS Parameters Registry includes the following: 'Parameter name', 'Parameter usage location', and 'Specification document(s)'.

The name of the parameter (e.g., "example"). The location(s) where the parameter can be used. The possible locations are the named structures defined in "Protocol Functionalities" and "Protocol Parameters". 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.

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 any particular set of authorities. The initial contents of the PAWS Parameters Registry are listed below; each section corresponds to a row of the registry.

fccId DeviceDescriptor This document. Specifies the device's FCC certification identifier. A valid FCC ID is limited to 19 characters in the ASCII value range, as proposed in FCC Administration Topics Review. For the purposes of the PAWS protocol, the maximum length of the fccId value is 32 octets.

fccTvbdDeviceType DeviceDescriptor This document. Specifies the TV-band white-space device type, as defined by the FCC. Valid values are "FIXED", "MODE_1", and "MODE_2".

etsiEnDeviceType DeviceDescriptor Specifies the white-space device type, as defined by the ETSI Harmonised Standard. Valid values are single-letter strings, such as "A", "B", etc. Consult the documentation for details about the device types.

etsiEnDeviceEmissionsClass DeviceDescriptor Specifies the white-space device emissions class, as defined by the ETSI Harmonised Standard, that characterizes 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.

etsiEnTechnologyId DeviceDescriptor Specifies the white-space device technology identifier, as defined by the ETSI Harmonised Standard. The maximum length of the string value is 64 octets. Consult the documentation for valid values.

etsiEnDeviceCategory DeviceDescriptor Specifies the white-space device category, as defined by the ETSI Harmonised Standard. Valid values are the strings "master" and "slave". It is case insensitive.

etsiEnSimultaneousChannelOperationRestriction SpectrumSpec Specifies the constraint on the device maximum total EIRP, as defined by the ETSI Harmonised Standard. 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.

This specification establishes the "PAWS Error Code Registry". Additional error codes for inclusion in PAWS error messages are registered on the advice of one or more Designated Experts, with Specification Required. 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 object. The PAWS Error Code Registry includes the following: 'Code', 'Name', 'Description and Additional Parameters', and 'Specification Document(s)'.

Integer value of the error code. The value MUST be an unassigned value in the range -32768 to 32767, inclusive. Name of the error. Description of the error and its associated parameters, if any. It also lists additional parameters that are returned in the data portion of the error (see ). New parameters MUST be registered separately in the PAWS Parameters Registry, as described by .

Initial registry contents are defined in the Error Codes Table. The registry will also include the error-code categories describing -100s, -200s, and -300s as a note (see "Error Codes").

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 to Access White-Space (PAWS) Databases: Use Cases and Requirements". By using PAWS, the Master Device and the Database expose themselves to the following risks: Accuracy: The Master Device receives incorrect spectrum-availability information. Privacy: An unauthorized entity intercepts identifying data for the Master Device or its Slave Devices, such as serial number and location. Where Databases are required to take device registrations and/or maintain request logs, there could be unauthorized access to such information. Protection from these risks depends on the success of the following steps: The Master Device must determine the address of a proper Database. The Master Device must connect to the proper Database. The Database must determine or compute accurate spectrum-availability information. PAWS messages must be transmitted unmodified between the Database and the Master Device. PAWS messages must be encrypted between the Database and the Master Device to prevent exposing private information. For a Slave Device, the spectrum-availability information also must be transmitted unmodified and securely between the Master Device and the Slave Device. 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 white space. No future extensions to PAWS can allow the return of sensitive information, such as device information or logs. The Database must not allow unauthorized access to device information and request logs and should publish and implement privacy policies regarding their use. Of these, only steps 1, 2, 4, 5, and 8 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", assuming the PKI used is not compromised, ensures steps 2, 4, and 5, as detailed in the following sections: "Assurance of Proper Database" "Protection against Modification" "Protection against Eavesdropping" Any specification for an alternate transport MUST define mechanisms that ensure each of these steps. In addition to the privacy risks described above, information provided in DeviceDescriptor and DeviceOwner, along with device location, may allow a database administrator to track the activity and location of a device and its user over time. Risks of secondary use of such tracking information, including sharing with third parties, require out-of-band mitigation, such as public statements or contractual terms. Furthermore, while it is understandable that regulators require DeviceOwner information for higher-power fixed white-space devices, for privacy concerns, regulators should not require DeviceOwner information for mobile devices. Similarly, regulators should require, and implementations should provide, device location at a level of granularity only as precise as necessary to support accurate database responses.

This document assumes that the Database is contacted using a domain name or an IP address. Using HTTP over 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), 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's certificate. A Master Device should allow for the fact that a Database can change its Certification Authorities (CAs) over time.

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

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

Although the Database can inform a device of available spectrum it can use, the Database cannot enforce that the Master Device uses only (or any of) those frequencies. Indeed, a malicious device can operate without ever contacting a Database. Note also that, whereas a malicious device may send fraudulent SPECTRUM_USE_NOTIFY 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 (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: The Database must nominate acceptable CAs, and the Master Device must have a certificate rooted at one of those CAs. As indicated in Section 3.2 of "HTTP Over TLS", 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. 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.

JSON-RPC 2.0 Specification Country Codes Electronic Code of Federal Regulations, Title 47, Part 15, Subpart H: Television Band Devices U. S. Government Administration Topics Review Federal Communications Commission ETSI EN 301 598 (V1.1.1): White Space Devices (WSD); Wireless Access Systems operating in the 470 MHz to 790 MHz TV broadcast band; Harmonized EN covering the essential requirements of article 3.2 of the R&TTE Directive European Telecommunication Standards Institute (ETSI) Department of Defense World Geodetic System 1984, Its Definition and Relationships with Local Geodetic Systems National Imagery and Mapping Agency

As discussed in "Database Discovery", 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:

The parameters in this sample message are: The time at which the database entries were last updated. The maximum interval, expressed in minutes, that is allowed between device requests to the Database Listing Server. A list of entries for certified Databases, each containing the following The name of the database operator. One or more URIs for each Database, allowing a Database to support more than one protocol. Each protocol supported by a certified Database is associated with a separate URI (PAWS protocol URI shown).

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, Kalle Kulsmanen, Warren Kumari, Paul Lambert, Andy Lee, Anthony Mancuso, Basavaraj Patil, Scott Probasco, Brian Rosen, Andy Sago, Peter Stanforth, John Stine, and Juan Carlos Zuniga.

This document draws heavily from draft-das-paws-protocol and draft-wei-paws-framework. The editor would like to specifically call out and thank the contributing authors of those two documents.