Protocol to Access White-Space (PAWS) Databases
Extracted elements (31)
By separating regulatory 'authority' from 'ruleset-id', the protocol supports multiple regulatory authorities sharing a common device-side ruleset, and allows a single authority to define multiple rulesets. Ruleset identifiers encode the regulatory body name and version (e.g., 'FccTvBandWhiteSpace-2010') so devices with out-of-band knowledge can satisfy domain-specific requirements without the protocol specifying them.
PAWS shifts the complexity of spectrum-policy conformance out of the device and into the database. This simplifies regulatory updates (changes are limited to a handful of databases rather than numerous devices) and opens the door for innovations such as incorporating location, time, user priority, and micro-auction parameters.
For multi-ruleset devices interoperating with multiple Databases, the Master Device MAY include the union of all required parameters for all supported rulesets in a single request. The Database MUST ignore all parameters it does not understand, providing forward-compatible extensibility across regulatory domains.
A Database MAY change its URI but MUST indicate the upcoming change by including alternate database URIs in DbUpdateSpec for a minimum of 2 weeks before disabling the old URI. Devices SHOULD detect infinite redirection loops; if no suitable database is reachable, the device MUST treat this as equivalent to a no-available-spectrum response.
If a suitable Database cannot be contacted, the device MUST treat this as equivalent to a response indicating no available spectrum. Previously obtained spectrum data may continue to be used only until it expires; after that period, the device has no valid spectrum to use.
If the location in an Available Spectrum Query is outside the regulatory domain supported by the Database, the Database MUST respond with an OUTSIDE_COVERAGE error. In a batch request, if only some locations are outside coverage, the Database MUST return an OK response with spectrum for valid locations only.
PAWS MUST use HTTPS (HTTP over TLS, RFC 2818) as its transport. The database URI MUST use the 'https' scheme. HTTPS provides both confidentiality for geolocation data and integrity protection against modification of spectrum availability responses.
When parameterized-rule values for the applicable ruleset at the device's location are not preconfigured, the Master Device MUST use the initialization procedure (INIT_REQ/INIT_RESP) to obtain them from the Database.
When the Available Spectrum Query requires registration but the request lacks registration information and the device has not previously registered with the Database, the Database MUST respond with a NOT_REGISTERED error.
When the stop time in a spectrum schedule is reached, the device MUST obtain a new spectrum-availability schedule (either from the next schedule in the list or by issuing a new query). If the device cannot contact the Database, it MUST treat this as equivalent to no available spectrum.
Within each AVAIL_SPECTRUM_RESP spectrum schedule list, 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 interval.
Device geolocation included in every PAWS request is sensitive personal-location data. HTTPS (TLS) protects it from eavesdropping. Implementors should be aware that geolocation data can reveal a user's location and movement patterns, and databases should limit retention and use of this data.
AVAIL_SPECTRUM_BATCH_REQ allows a Master Device to query spectrum for multiple locations (GeoLocation list) in a single request, enabling prefetch for anticipated positions. The Database MAY return fewer locations than requested. If the Database does not support batch requests, it MUST return an UNIMPLEMENTED error.
AVAIL_SPECTRUM_REQ is the core spectrum query. When a Master Device queries on its own behalf, deviceDesc and location are REQUIRED. When querying on behalf of a Slave Device, masterDeviceLocation is REQUIRED, while the Slave Device's location is OPTIONAL. The optional requestType field (max 64 octets) can modify query behavior per ruleset.
AVAIL_SPECTRUM_RESP returns a UTC timestamp, the echoed deviceDesc, and a required spectrumSpecs list of one or more SpectrumSpec elements. Each SpectrumSpec contains a ruleset identifier and a list of SpectrumSchedule entries specifying permissible EIRP power levels over disjoint, sorted time intervals.
DEV_VALID_REQ/DEV_VALID_RESP allow a Master Device to validate one or more Slave Devices against the Database without performing a full spectrum query. The request carries a required list of DeviceDescriptors; the response returns a DeviceValidity entry per device with isValid (boolean) and an optional reason string.
DeviceDescriptor identifies a device by optional serialNumber, manufacturerId, and modelId (each max 64 octets) and an optional rulesetIds list. The Database MUST ignore unrecognized parameters. Rulesets typically require serialNumber; if no supported ruleset is found in rulesetIds, the Database MAY refuse service.
INIT_REQ is the initialization request message; required fields are deviceDesc (DeviceDescriptor) and location (GeoLocation). The Database MUST return OUTSIDE_COVERAGE if the location falls outside all supported regulatory domains. If no ruleset IDs are included in deviceDesc, the database returns all rulesets it supports at that location.
INIT_RESP returns a required rulesetInfos list (one RulesetInfo per supported ruleset applicable to the device's location) and an optional databaseChange (DbUpdateSpec). If the Database supports none of the rulesets specified by the device, it MUST return an UNSUPPORTED error instead.
REGISTRATION_REQ allows a Master Device to register with the Database; required fields are deviceDesc and location. Optional fields include deviceOwner (vCard-based) and antenna (AntennaCharacteristics). Some rulesets, such as FCC rules for fixed devices, require registration of owner/operator contact, device identifier, location, and antenna height.
RulesetInfo conveys ruleset-specific operational parameters from the Database to a device, including the rulesetId string, maxLocationChange (meters, threshold triggering a re-query), and maxPollingSecs (time threshold for re-query). These bound how long a device may operate on cached spectrum data.
SPECTRUM_USE_NOTIFY informs the Database of the spectrum the device intends to use (not a permission request). Required fields are deviceDesc and spectra (list of Spectrum elements with resolutionBwHz and power profiles). When made on behalf of a Slave Device, masterDeviceLocation is REQUIRED. The Database MUST acknowledge with SPECTRUM_USE_RESP.
The Error Element contains a required integer code, an optional human-readable message string, and optional structured data. Standard error codes include: MISSING (101), INVALID_VALUE (102), UNSUPPORTED (103), UNIMPLEMENTED (104), OUTSIDE_COVERAGE (105), DATABASE_CHANGE (106), and NOT_REGISTERED (107).
IANA created the PAWS Error Code Registry cataloging integer error codes for PAWS error responses. Initial entries are MISSING (101), INVALID_VALUE (102), UNSUPPORTED (103), UNIMPLEMENTED (104), OUTSIDE_COVERAGE (105), DATABASE_CHANGE (106), and NOT_REGISTERED (107). New codes require Specification Required.
IANA created the PAWS Parameters Registry cataloging named extension parameters that may appear in PAWS request and response messages beyond the base protocol. Each entry specifies parameter name, data type, applicable message(s), and a reference specification.
IANA created the PAWS Ruleset ID Registry containing identifiers for regulatory-domain rulesets (e.g., 'FccTvBandWhiteSpace-2010'). Each entry specifies ruleset parameters including required message fields, geographic applicability, and device-side behavior. New registrations require Specification Required and designated expert review.
Client authentication is optional in the base PAWS protocol; the Database MAY authenticate devices using TLS client certificates or application-layer mechanisms. Regulatory domains may impose additional requirements for device identity verification, particularly for higher-power fixed devices.
Devices must verify they are communicating with an authorized Database to prevent rogue databases from providing false spectrum availability data that could cause interference with primary users. TLS server certificate validation against a trusted CA is the primary assurance mechanism.
PAWS messages must be protected against modification in transit; TLS (via HTTPS) provides this integrity protection. Without it, a man-in-the-middle could inject false spectrum data, enabling secondary devices to cause interference or deny service.
GeoLocation is encoded using RFC 5491 shapes in JSON: an Ellipse (center Point in WGS84 lat/lon degrees, optional semiMajorAxis/semiMinorAxis in meters, optional orientation in degrees from North) for a point, or a Polygon (list of 4+ Points, counter-clockwise, first equals last) for a region. An optional confidence integer (default 95) expresses location certainty as a percentage.
PAWS messages are encoded as JSON-RPC 2.0 carried over HTTPS. Method names follow the form 'spectrum.paws.<methodname>' (e.g., 'spectrum.paws.init', 'spectrum.paws.getSpectrum'). The JSON-RPC 'params' field carries the PAWS request object and the 'result' field carries the PAWS response object; errors are returned in the standard JSON-RPC 'error' field.