RFC 7545
Protocol to Access White-Space (PAWS) Databases
Pages: 90
Proposed Standard
Proposed Standard
Part 2 of 4 – Pages 9 to 33
4. Protocol Functionalities
PAWS consists of several components. As noted below, some regulatory domains or database implementations may mandate the use of a component, even when its use is not mandated by PAWS. o Database Discovery (Section 4.1) is a required component for the Master Device. o Initialization (Section 4.3) is a required component for the Database. Its use allows the Master Device to determine necessary information that has not been preconfigured. o Device Registration (Section 4.4) is an optional component for the Database. It can be implemented as a separate component or as part of the Available Spectrum Query (Section 4.5) component. It is used by the Master Device when the Database requires it. Note that some regulators require device registration for only specific device types, such as higher-power fixed (as opposed to mobile) devices, to allow them to contact the operators to resolve any interference issues. o Available Spectrum Query (Section 4.5) is a required component for the Master Device and the Database. o Spectrum Use Notify (Section 4.5.5) is an optional component for the Master Device and the Database. When it is required, the Database informs the Master Device via its response to the Available Spectrum Query (Section 4.5). o Device Validation (Section 4.6) as a separate component is optional for the Master Device and Database. When implemented by the Database, its use allows the Master Device to validate Slave Devices without having to use the full Available Spectrum Query.
This section describes the protocol components and their messages. "Protocol Parameters" (Section 5) contains a more thorough discussion of the parameters that make up the PAWS request and response messages. "Message Encoding" (Section 6) provides examples of message encodings. "HTTPS Binding" (Section 7) describes the use of HTTPS ("HTTP Over TLS" [RFC2818]) for transferring PAWS messages and optional device authentication. The parameter tables in this section and "Protocol Parameters" (Section 5) are for reference and contain the name of each parameter, the data type of each parameter, and whether the existence of the parameter is required for the protocol transaction in question. The diagrams are loosely based on the Unified Modeling Language (UML), and the data types are defined either in "Protocol Parameters" (Section 5) or are one of the following primitive or structured types: string: A string, as defined by JSON [RFC7159], restricted to the UTF-8 encoding. int: A number, as defined by JSON [RFC7159], without a fractional or exponent part. float: A number, as defined by JSON [RFC7159]. boolean: A boolean, as defined by JSON [RFC7159]. list: A structured type that represents a list of elements, as defined by JSON [RFC7159] array type. All elements of the list are of the same data type, which is indicated in its diagram and description. The diagram notation and description may include additional constraints, such as minimum or maximum number of elements. Also: o All parameter names are case sensitive. Unless stated otherwise, all string values are case sensitive. o All timestamps are in UTC and are expressed using exactly the form, YYYY-MM-DDThh:mm:ssZ, as defined by "Date and Time on the Internet: Timestamps" [RFC3339]. In some cases, specific rulesets may place additional requirements on message parameters. These additional requirements will be documented in the IANA PAWS Ruleset ID Registry (Section 9.1). When a request message sent to the Database has missing parameters, whether they are
required by PAWS or the applicable ruleset, the Database returns the MISSING error (see Section 5.17.3), along with data indicating the missing parameters.4.1. Database Discovery
4.1.1. Preconfiguration
The Master Device can be provisioned statically (preconfigured) with the URI of one or more Databases. For example, in a particular regulatory domain, there may be a number of certified Databases that any device operating in that domain is permitted to connect to, and those URIs can be preconfigured in the device. Listing Server Support: As an alternative to preconfiguring devices with a list of certified Databases, some regulatory domains support the preconfiguration of devices with the URI of a certified listing server, to which devices can connect to obtain the list of certified Databases. See "Database Listing Server Support" (Appendix A) for further information.4.1.2. Configuration Update: Database URI Changes
To adapt to changes in the list of certified or approved Databases, the device needs to update its preconfigured list of Databases. A Database MAY change its URI, but before it changes its URI, it MUST indicate the upcoming change by including the URI of one or more alternate Databases using DbUpdateSpec (Section 5.7) in its responses to devices. The Database MUST reply with DbUpdateSpec for a minimum of 2 weeks before disabling the old URI. A device will update its preconfigured entry for the Database sending the DbUpdateSpec by replacing this entry with the alternate Databases listed in the DbUpdateSpec; the list of alternate Databases does not affect any other entries. Note that the ordering of Databases in the list does not imply any preference and does not need to remain the same for every request. The device SHOULD detect infinite redirection loops; if a suitable Database cannot be contacted, the device MUST treat this as equivalent to a response indicating no available spectrum. This database-change mechanism is used, for example, before a Database ceases operation; it is not intended to be used for dynamic load balancing.
4.1.3. Error Handling
The device SHOULD select another Database from its list of preconfigured Databases if: o The selected Database is unreachable or does not respond. o The selected Database returns an UNSUPPORTED error (see "Error Codes" (Section 5.17)), which indicates the Database does not support the device (based on its device type, model, etc.) or supports none of the rulesets specified in the request. If a suitable Database cannot be contacted, the device MUST treat this as equivalent to a response indicating no available spectrum. If the device had previously contacted a Database to get available spectrum, but subsequently fails to contact a suitable Database, the spectrum the device is currently using can be used for as long as the spectrum data is valid. However, after that period, the device will no longer have valid spectrum to use. Some regulatory domains may have specific rules regarding how long the spectrum data remains valid in these cases.4.2. PAWS Version
PAWS version uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended to allow the device or Database to indicate the format of a message and its understanding of PAWS functionality defined by that version. No change is made to the version string for the addition of message components that only add to extensible parameter values. The <minor> number is incremented when the changes made to the protocol add functionalities (methods) but do not change the existing functionalities. The <major> number is incremented when incompatible changes are made to existing functionality. The current PAWS version is "1.0".4.3. Initialization
A Master Device SHOULD use the initialization procedure to exchange capability information with the Database whenever the Master Device powers up or initiates communication with the Database. The initialization response informs the Master Device of specific parameterized-rule values for each supported ruleset, such as threshold distances and time periods beyond which the device must update its available-spectrum data (see "RuleSetInfo" (Section 5.6)).
When parameterized-rule values are not preconfigured for the applicable ruleset at the specified location, a Master Device MUST use the initialization procedure. It is important to note that, when parameterized-rule values are preconfigured in a Master Device, they are preconfigured on a per- ruleset basis. That is, values preconfigured for one ruleset are not applicable to any other ruleset. For database implementations that require it, the initialization message also enables extra database-specific or ruleset-specific handshake parameters to be communicated before allowing available- spectrum requests. The Initialization request procedure is depicted in Figure 1. o INIT_REQ (Section 4.3.1) is the initialization request message o INIT_RESP (Section 4.3.2) is the initialization response message +---------------+ +-------------------+ | Master Device | | Spectrum Database | +---------------+ +-------------------+ | | | INIT_REQ | |-------------------->| | | | INIT_RESP | |<--------------------| | | Figure 14.3.1. INIT_REQ
The initialization request message allows the Master Device to initiate exchange of capabilities with the Database. +---------------------------------------+ |INIT_REQ | +----------------------------+----------| |deviceDesc:DeviceDescriptor | REQUIRED | |location:GeoLocation | REQUIRED | |.......................................| |*other:any | OPTIONAL | +----------------------------+----------+
Parameters: deviceDesc: The DeviceDescriptor (Section 5.2) for the device is REQUIRED. If the device descriptor does not contain any ruleset IDs, the Master Device is asking the Database to return a RulesetInfo (Section 5.6) list that specifies the rulesets that it supports at the specified location. location: The GeoLocation (Section 5.1) of the device is REQUIRED. If the location is outside all regulatory domain supported by the Database, the Database MUST respond with an OUTSIDE_COVERAGE error (see Table 1). other: The Master Device MAY specify additional handshake parameters in the INIT_REQ message. The Database MUST ignore all parameters it does not understand. To simplify its initialization logic, a Master Device that supports multiple Databases and rulesets can include the union of all required parameters for all its supported rulesets. Consult the PAWS Parameters Registry (Section 9.2) for possible additional parameters.4.3.2. INIT_RESP
The initialization response message communicates database parameters to the requesting device. This response is returned only when there is at least one ruleset. Otherwise, the Database returns an error response, as described in INIT_REQ (Section 4.3.1). +---------------------------------------+ |INIT_RESP | +----------------------------+----------+ 1..* +-------------+ |rulesetInfos:list | REQUIRED |------->| RulesetInfo | |databaseChange:DbUpdateSpec | OPTIONAL | +-------------+ |.......................................| |*other:any | OPTIONAL | +----------------------------+----------+ Parameters: rulesetInfos: A RulesetInfo (Section 5.6) list MUST be included in the response. Each RulesetInfo corresponds to a ruleset supported by the Database and is applicable to the location specified in the INIT_REQ (Section 4.3.1) message. If the device included a list of ruleset IDs in the DeviceDescriptor of its INIT_REQ message, each RulesetInfo in the response MUST match one of the specified ruleset IDs.
If the DeviceDescriptor did not contain any ruleset IDs, the
Database SHOULD include in the rulesetInfos list a RulesetInfo for
each ruleset it supports at the specified location.
If the Database does not support the device or supports none of
the rulesets specified in the DeviceDescriptor, it MUST instead
return an error with the UNSUPPORTED code (see Table 1) in the
error response.
databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) to notify the Master Device of a change to the
database URI, providing one or more alternate database URIs. The
device needs to update its preconfigured entry for the responding
Database with the alternate Databases listed in the DbUpdateSpec.
other: The Database MAY include additional handshake parameters in
the INIT_RESP (Section 4.3.2) message. The Master Device MUST
ignore all parameters it does not understand. Consult the PAWS
Parameters Registry (Section 9.2) for possible additional
parameters.
4.4. Device Registration
Some rulesets require a Master Device to send its registration
information to the Database in order to establish certain operational
parameters. FCC rules, for example, require that a 'Fixed Device'
register its owner and operator contact information, its device
identifier, its location, and its antenna height (see FCC CFR47-15H
[FCC-CFR47-15H]).
The Database MAY implement device registration as a separate Device
Registration request, or as part of the available-spectrum request.
If the Database does not implement a separate Device Registration
request, it MUST return an error with the UNIMPLEMENTED code (see
Table 1) in the error-response message.
The Device Registration request procedure is depicted in Figure 2.
o REGISTRATION_REQ (Section 4.4.1) is the device-registration
request message
o REGISTRATION_RESP (Section 4.4.2) is the device-registration
response message
+---------------+ +-------------------+ | Master Device | | Spectrum Database | +---------------+ +-------------------+ | | | REGISTRATION_REQ | |------------------------>| | | | REGISTRATION_RESP | |<------------------------| | | Figure 24.4.1. REGISTRATION_REQ
The registration request message contains the required registration parameters. A parameter marked as optional may be required by some rulesets. +-------------------------------------------+ |REGISTRATION_REQ | +-------------------------------+-----------+ |deviceDesc:DeviceDescriptor | REQUIRED | |location:GeoLocation | REQUIRED | |deviceOwner:DeviceOwner | OPTIONAL | |antenna:AntennaCharacteristics | OPTIONAL | |...........................................| |*other:any | OPTIONAL | +-------------------------------+-----------+ Parameters: deviceDesc: The DeviceDescriptor (Section 5.2) for the Master Device is REQUIRED. The ruleset IDs included in the DeviceDescriptor indicate the rulesets for which the device wishes to register. location: The GeoLocation (Section 5.1) for the device is REQUIRED. More precisely, this is the location at which the device intends to operate. If the location is outside all regulatory domains supported by the Database, the Database MUST respond with an OUTSIDE_COVERAGE error (see Table 1). deviceOwner: The DeviceOwner (Section 5.5) information is OPTIONAL. Some rulesets may require deviceOwner information under certain conditions. See PAWS Ruleset ID Registry (Section 9.1) for ruleset-specific requirements. antenna: The AntennaCharacteristics (Section 5.3) is OPTIONAL.
other: Rulesets and database implementations may require additional
registration parameters. To simplify its registration logic, the
Master Device MAY send a union of the registration information
required by all supported rulesets. The Database MUST ignore all
parameters it does not understand. Consult the PAWS Parameters
Registry (Section 9.2) for possible additional parameters.
4.4.2. REGISTRATION_RESP
The registration response message acknowledges successful
registration by including a RulesetInfo message for each ruleset in
which the registration is accepted. If the Database accepts the
registration for none of the specified rulesets, the Database MUST
return the NOT_REGISTERED error (see "Error Codes" (Section 5.17)).
+---------------------------------------+
|REGISTRATION_RESP |
+----------------------------+----------+ 1..* +-------------+
|rulesetInfos:list | REQUIRED |------->| RulesetInfo |
|databaseChange:DbUpdateSpec | OPTIONAL | +-------------+
|............................|..........|
|*other:any | OPTIONAL |
+----------------------------+----------+
Parameters:
rulesetInfos: A RulesetInfo (Section 5.6) list MUST be included in
the response. Each entry corresponds to a ruleset for which the
registration was accepted. The list MUST contain at least one
entry.
Each RulesetInfo in the response MUST match one of the ruleset IDs
specified in the DeviceDescriptor of REGISTRATION_REQ.
If the Database does not support the device or supports none of
the rulesets specified in the DeviceDescriptor, it MUST instead
return an error with the UNSUPPORTED code (see Table 1) in the
error response.
databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) to notify the Master Device of a change to the
database URI, providing one or more alternate database URIs. The
device needs to update its preconfigured entry for the responding
Database with the alternate Databases listed in the DbUpdateSpec.
other: Database implementations MAY return additional parameters in
the registration response. The Master Device MUST ignore any
parameters it does not understand. Consult the PAWS Parameters
Registry (Section 9.2) for possible additional parameters.
4.5. Available Spectrum Query
To obtain the available spectrum from the Database, a Master Device
sends a request that contains its geolocation and any parameters
required by the ruleset (such as device identifier, capabilities, and
characteristics). The Database returns a response that describes
which frequencies are available, at what permissible operating power
levels, and a schedule of when they are available.
The Available Spectrum Query procedure is depicted in Figure 3.
o AVAIL_SPECTRUM_REQ (Section 4.5.1) is the available-spectrum
request message.
o AVAIL_SPECTRUM_RESP (Section 4.5.2) is the available-spectrum
response message.
o AVAIL_SPECTRUM_BATCH_REQ (Section 4.5.3) is an OPTIONAL batch
version of the available-spectrum request message that allows
multiple locations to be specified in the request.
o AVAIL_SPECTRUM_BATCH_RESP (Section 4.5.4) is the response message
for the batch version of the available-spectrum request that
contains available spectrum for each location in the request.
o SPECTRUM_USE_NOTIFY (Section 4.5.5) is the spectrum-usage
notification message.
o SPECTRUM_USE_RESP (Section 4.5.6) is the spectrum-usage
acknowledgment message.
+---------------+ +-------------------+ | Master Device | | Spectrum Database | +---------------+ +-------------------+ | | | AVAIL_SPECTRUM_REQ | | (AVAIL_SPECTRUM_BATCH_REQ) | |--------------------------->| | | | AVAIL_SPECTRUM_RESP | | (AVAIL_SPECTRUM_BATCH_RESP)| |<---------------------------| | | | (SPECTRUM_USE_NOTIFY) | |--------------------------->| | | | (SPECTRUM_USE_RESP) | |<---------------------------| | | Figure 3 1. First, the Master Device sends an available-spectrum request message to the Database. 2. The Database MUST respond with an error using the NOT_REGISTERED code (see Table 1) if: * registration information is required, and * the request does not include registration information, and * the device has not previously registered with the Database 3. If the location specified in the request is outside the regulatory domain supported by the Database, the Database MUST respond with an OUTSIDE_COVERAGE error (see Table 1). If some, but not all, locations within a batch request are outside the regulatory domain supported by the Database, the Database MUST return an OK response with available spectrum for only the valid locations; otherwise, if all locations within a batch request are outside the regulatory domain, the Database MUST respond with an OUTSIDE_COVERAGE error.
4. The Database MAY perform other validation of the request, (e.g.,
checking for missing required parameters or authorizations). If
validation fails, the Database returns an appropriate error code
(Table 1). If the request is missing required parameters, the
Database MUST respond with a MISSING error (see Table 1) and
SHOULD include a list of the missing parameters.
5. If the request is valid, the Database responds with an available-
spectrum response message. If the ruleset requires that devices
must report anticipated spectrum usage, the Database will
indicate so in the response message.
6. If the available-spectrum response indicates that the Master
Device must send a spectrum-usage notification message, the
Master Device sends the notification message to the Database.
Even when not required by the Database, the Master Device MAY
send a notification message.
7. If the Database receives a spectrum-usage notification message,
it MUST send a spectrum-usage acknowledgment message to the
Master Device.
The procedure for a Master Device to ask for available spectrum on
behalf of a Slave Device is similar, except that the process is
initiated by the Slave Device. The device identifier, capabilities,
and characteristics communicated in the AVAIL_SPECTRUM_REQ message
MUST be those of the Slave Device, and:
o The "masterDeviceLocation" field specifying the location of the
Master Device is REQUIRED.
o The "location" field specifying the location of the Slave Device
is OPTIONAL, since the Slave Device may not have location-sensing
capabilities.
Although the communication and protocol between the Slave Device and
Master Device are outside the scope of this document (represented as
dotted lines), the expected message sequence is shown in Figure 4.
+------------+ +---------------+ +-------------------+ |Slave Device| | Master Device | | Spectrum Database | +------------+ +---------------+ +-------------------+ | | | | AVAIL_SPEC_REQ | | |................>| | | | | | | AVAIL_SPECTRUM_REQ | | |-------------------------->| | | | | | AVAIL_SPECTRUM_RESP | | |<--------------------------| | AVAIL_SPEC_RESP | | |<................| | | | | | (SPECTRUM_USE) | | |................>| (SPECTRUM_USE_NOTIFY) | | |-------------------------->| | | | | | (SPECTRUM_USE_RESP) | | |<--------------------------| | | | Figure 44.5.1. AVAIL_SPECTRUM_REQ
The request message for the Available Spectrum Query protocol MUST include a geolocation. Rulesets may mandate that it be the device's current location or allow it to be an anticipated location. A parameter marked as optional may be required by some rulesets. +----------------------------------------------------+ |AVAIL_SPECTRUM_REQ | +----------------------------------+-----------------+ |deviceDesc:DeviceDescriptor | see description | |location:GeoLocation | see description | |owner:DeviceOwner | OPTIONAL | |antenna:AntennaCharacteristics | OPTIONAL | |capabilities:DeviceCapabilities | OPTIONAL | |masterDeviceDesc:DeviceDescriptor | OPTIONAL | |masterDeviceLocation:GeoLocation | see description | |requestType:string | OPTIONAL | |..................................|.................| |*other:any | OPTIONAL | +----------------------------------+-----------------+
Parameters: deviceDesc: The DeviceDescriptor (Section 5.2) for the device requesting available spectrum. When the request is made by a Master Device on its own behalf, the descriptor is that of the Master Device, and it is REQUIRED. When the request is made on behalf of a Slave Device, the descriptor is that of the Slave Device, and it is REQUIRED if the "requestType" parameter is not specified. The deviceDesc parameter may be OPTIONAL for some values of requestType. location: The GeoLocation (Section 5.1) for the device requesting available spectrum. More precisely, this is the location at which the device intends to operate. When the request is made by the Master Device on its own behalf, the location is that of the Master Device, and it is REQUIRED. When the request is made by the Master Device on behalf of a Slave Device, the location is that of the Slave Device, and it is OPTIONAL (see also masterDeviceLocation). The location may be an anticipated position of the device to support mobile devices, but its use depends on the ruleset. If the location specifies a region, rather than a point, the Database MAY return an error with the UNIMPLEMENTED code (see Table 1), if it does not implement query by region. NOTE: Technically, this is the location of the radiation center of the device's antenna, but that distinction may be relevant only for fixed devices. owner: The DeviceOwner (Section 5.5) information MAY be included to register the device with the Database. This enables the device to register and get spectrum-availability information in a single request. Some rulesets mandate registration for specific device types. antenna: The AntennaCharacteristics (Section 5.3) is OPTIONAL. capabilities: The Master Device MAY include its DeviceCapabilities (Section 5.4) to limit the available-spectrum response to the spectrum that is compatible with its capabilities. The Database SHOULD NOT return spectrum that is not compatible with the specified capabilities. masterDeviceDesc: When the request is made by the Master Device on behalf of a Slave Device, the Master Device MAY provide its own descriptor.
masterDeviceLocation: When the request is made by the Master Device
on behalf of a Slave Device, the Master Device MUST provide its
own GeoLocation (Section 5.1).
requestType: The request type is OPTIONAL; it may be used to modify
the request, but its use depends on the applicable ruleset. The
request type may be used, for example, to indicate that the
response should include generic Slave Device parameters without
having to specify the device descriptor for a specific device.
When requestType is missing, the request is for a specific device
(Master or Slave), so deviceDesc is REQUIRED. The maximum length
of the value is 64 octets. See the specifics in the Initial
Registry Contents (Section 9.1.2) for the Ruleset ID Registry.
other: Rulesets and database implementations may require additional
request parameters. The Database MUST ignore all parameters it
does not understand. Consult the PAWS Parameters Registry
(Section 9.2) for possible additional parameters.
4.5.2. AVAIL_SPECTRUM_RESP
The response message for the Available Spectrum Query contains one or
more SpectrumSpec (Section 5.9) elements, one for each ruleset
supported at the location specified in the corresponding
AVAIL_SPECTRUM_REQ (Section 4.5.1) message. Each SpectrumSpec
element contains a list of one or more spectrum schedules,
representing permissible power levels over time:
o Each spectrum schedule specifies the permissible power level for a
duration defined by a pair of start and stop times. The power
levels refer to permissible EIRP over a resolution bandwidth.
o Within each list of schedules, event-time intervals MUST be
disjoint and MUST be sorted in increasing time.
o A gap in the time schedule means no spectrum is available for that
time interval.
Consider a Database that provides a schedule of available spectrum
for the next 24 hours. If spectrum availability were to be different
at different times of day, the response would contain a list of
schedules, each transition representing some change to the spectrum
availability. A device might use different strategies to select
which spectrum to use, e.g.:
o Always use the frequencies that permit the highest power
o Use the frequencies that are available for the longest period of
time.
o Just use the first set of frequencies that matches its needs.
+---------------------------------------+
|AVAIL_SPECTRUM_RESP |
+----------------------------+----------+
|timestamp:string | REQUIRED |
|deviceDesc:DeviceDescriptor | REQUIRED |
|spectrumSpecs:list | REQUIRED |-------+
|............................|..........| |
|databaseChange:DbUpdateSpec | OPTIONAL | |
|*other:any | OPTIONAL | |
+----------------------------+----------+ | 1..*
V
+-----------------------------------+
|SpectrumSpec |
+------------------------+----------+
|rulesetInfo:RulesetInfo | REQUIRED |
|spectrumSchedules:list | REQUIRED |-+
|timeRange:EventTime | OPTIONAL | |
|frequencyRanges:list | OPTIONAL | |
|needsSpectrumReport:bool| OPTIONAL | |
|maxTotalBwHz:float | OPTIONAL | |
|maxContiguousBwHz:float | OPTIONAL | |
+------------------------+----------+ |
+--------------------+
| 1..*
V
+-------------------------------+
|SpectrumSchedule |
+--------------------+----------+
|eventTime:EventTime | REQUIRED |
|spectra:list | REQUIRED |
+--------------------+----------+
Parameters:
timestamp: Timestamp of the response is expressed in UTC using the
form, YYYY-MM-DDThh:mm:ssZ, as defined by "Date and Time on the
Internet: Timestamps" [RFC3339]. This can be used by the device
as a reference for the start and stop times in the spectrum
schedules.
deviceDesc: The Database MUST include the DeviceDescriptor
(Section 5.2) specified in the AVAIL_SPECTRUM_REQ message.
spectrumSpecs: The SpectrumSpec (Section 5.9) list MUST include at least one entry. Each entry contains the schedules of available spectrum for a ruleset. The Database MAY return more than one SpectrumSpec to represent available spectrum for multiple rulesets at the specified location. databaseChange: The Database MAY include a DbUpdateSpec (Section 5.7) to notify the device of a change to the database URI, providing one or more alternate database URIs. The device needs to update its preconfigured entry for the responding Database with the alternate Databases listed in the DbUpdateSpec. other: Database implementations MAY return additional parameters in the response. The device MUST ignore any parameters that it does not understand. Consult the PAWS Parameters Registry (Section 9.2) for possible additional parameters and requirements they place on the device.4.5.2.1. Update Requirements
When the stop time specified in the schedule has been reached, the device: o MUST obtain a new spectrum-availability schedule, either by using the next one in the list (if provided) or making another Available Spectrum Query (Section 4.5). o If the device is unable to contact the Database to obtain a new schedule, it MUST treat this as equivalent to a response with no available spectrum. Some rulesets also mandate that a device must obtain a new spectrum- availability schedule if the device moves beyond a threshold distance (established by the ruleset) from the actual location and all anticipated location(s) it reported in previous AVAIL_SPECTRUM_REQ or AVAIL_SPECTRUM_BATCH_REQ messages (see "maxLocationChange" in RulesetInfo (Section 5.6)). If the device is unable to contact the Database to obtain a new schedule, it MUST treat this as equivalent to a response with no available spectrum. NOTE: The ruleset determines required device behavior when spectrum is no longer available. The ruleset also governs whether a device may request and use spectrum at anticipated locations beyond the threshold distance from its current location.
4.5.3. AVAIL_SPECTRUM_BATCH_REQ
The Database MAY implement the batch request that allows multiple locations to be specified. This enables a portable Master Device, for example, to get available spectrum for a sequence of anticipated locations using a single request. The Database interprets each location in the batch request as if it were an independent request and returns results consistent with multiple individual AVAIL_SPECTRUM_REQ (Section 4.5.1) messages, but it returns these results in a batched response (Section 4.5.4). The request message for the batch Available Spectrum Query protocol MUST include at least one GeoLocation (Section 5.1). If the Database does not implement batch requests, it MUST return an UNIMPLEMENTED error (see Table 1). NOTE: Whether anticipated locations are allowed depends on the specified ruleset. A parameter marked as optional may be required by some rulesets. +---------------------------------------------------+ |AVAIL_SPECTRUM_BATCH_REQ | +---------------------------------+-----------------+ |deviceDesc:DeviceDescriptor | see description | |locations:list | REQUIRED |--+ |owner:DeviceOwner | OPTIONAL | | |antenna:AntennaCharacteristics | OPTIONAL | | |capabilities:DeviceCapabilities | OPTIONAL | | |masterDeviceDesc:DeviceDescriptor| OPTIONAL | | |masterDeviceLocation:GeoLocation | see description | | |requestType:string | OPTIONAL | | +.................................+.................+ | |*other:any | OPTIONAL | | +---------------------------------+-----------------+ | | 1..* V +-------------+ | GeoLocation | +-------------+ Parameters: deviceDesc: The DeviceDescriptor (Section 5.2) for the device requesting available spectrum. When the request is made by a Master Device on its own behalf, the descriptor is that of the Master Device, and it is REQUIRED. When the request is made on behalf of a Slave Device, the descriptor is that of the Slave Device, and it is REQUIRED if the "requestType" parameter is not specified. The deviceDesc parameter may be OPTIONAL for some values of requestType.
locations: The GeoLocation (Section 5.1) list for the device is REQUIRED. This allows the device to specify its actual location plus additional anticipated locations. At least one location MUST be included. This specification places no upper limit on the number of locations, but the Database MAY restrict the number of locations it supports by returning a response with fewer locations than specified in the request. If the locations specify regions, rather than points, the Database MAY return an error with the UNIMPLEMENTED code (see Table 1), if it does not implement query by region. When the request is made by a Master Device on its own behalf, the locations are those of the Master Device. When the request is made by the Master Device on behalf of a Slave Device, the locations are those of the Slave Device (see also masterDeviceLocation). owner: The DeviceOwner (Section 5.5) information MAY be included to register the device with the Database. This enables the device to register and get spectrum-availability information in a single request. Some rulesets mandate registration for specific device types. antenna: The AntennaCharacteristics (Section 5.3) is OPTIONAL. capabilities: The Master Device MAY include its DeviceCapabilities (Section 5.4) to limit the available-spectrum response to the spectrum that is compatible with its capabilities. The Database SHOULD NOT return spectrum that is not compatible with the specified capabilities. masterDeviceDesc: When the request is made by the Master Device on behalf of a Slave Device, the Master Device MAY provide its own descriptor. masterDeviceLocation: When the request is made by the Master Device on behalf of a Slave Device, the Master Device MUST provide its own GeoLocation (Section 5.1). requestType: The request type is an OPTIONAL parameter that may be used to modify the request, but its use depends on the applicable ruleset. The request type may be used, for example, to request generic Slave Device parameters without having to specify the device descriptor for a specific device. When the requestType parameter is missing, the request is for a specific device (Master or Slave), so deviceDesc is REQUIRED. The maximum length is 64 octets. See the ruleset specifics in the Initial Registry Contents (Section 9.1.2) for the Ruleset ID Registry.
other: Rulesets and database implementations may require additional
request parameters. The Database MUST ignore all parameters it
does not understand. Consult the PAWS Parameters Registry
(Section 9.2) for possible additional parameters.
4.5.4. AVAIL_SPECTRUM_BATCH_RESP
The response message for the batch Available Spectrum Query contains
a schedule of available spectrum for the device at multiple
locations.
+---------------------------------------+
|AVAIL_SPECTRUM_BATCH_RESP |
+----------------------------+----------+
|timestamp:string | REQUIRED |
|deviceDesc:DeviceDescriptor | REQUIRED |
|geoSpectrumSpecs:list | REQUIRED |-------+
|............................|..........| |
|databaseChange:DbUpdateSpec | OPTIONAL | |
|*other:any | OPTIONAL | |
+----------------------------+----------+ | 0..*
V
+---------------------------------+
|GeoSpectrumSpec |
+----------------------+----------+
|location:GeoLocation | REQUIRED |
|spectrumSpecs:list | REQUIRED |
+----------------------+----------+
Parameters:
timestamp: Timestamp of the response of the form,
YYYY-MM-DDThh:mm:ssZ, as defined by "Date and Time on the
Internet: Timestamps" [RFC3339]. This can be used by the device
as a reference for the start and stop times in the spectrum
schedules.
deviceDesc: The Database MUST include the DeviceDescriptor
(Section 5.2) specified in the AVAIL_SPECTRUM_BATCH_REQ message.
geoSpectrumSpecs: The geoSpectrumSpecs (Section 5.15) list is
REQUIRED (although it MAY be empty if spectrum is unavailable).
For each location, the Database MAY return one or more
SpectrumSpecs (Section 5.9) to represent available spectrum for
one or more rulesets. The Database MAY return available spectrum
for fewer locations than requested. The order of the entries in
the list is not significant, and the device MUST use the location
value in each GeoSpectrumSpec entry to match available spectrum to
a location.
databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) to notify the device of a change to the database
URI, providing one or more alternate database URIs. The device
needs to update its preconfigured entry for the responding
Database with the alternate Databases listed in the DbUpdateSpec.
other: Database implementations MAY return additional parameters in
the response. Consult the PAWS Parameters Registry (Section 9.2)
for possible additional parameters and requirements they place on
the device.
See "Update Requirements" (Section 4.5.2.1) for when the device must
update its available spectrum data.
4.5.5. SPECTRUM_USE_NOTIFY
The spectrum-use notification message indicates the spectrum
anticipated to be used by the device.
+---------------------------------------------------+
|SPECTRUM_USE_NOTIFY |
+---------------------------------+-----------------+
|deviceDesc:DeviceDescriptor | REQUIRED |
|location:GeoLocation | see description |
|masterDeviceDesc:DeviceDescriptor| OPTIONAL |
|masterDeviceLocation:GeoLocation | see description |
|spectra:list | REQUIRED |--+
|...................................................| |
|*other:any | OPTIONAL | |
+---------------------------------+-----------------+ | 0..*
V
+--------------------------------+
|Spectrum |
+---------------------+----------+
|resolutionBwHz:float | REQUIRED |
|profiles:list | REQUIRED |
+---------------------+----------+
Parameters: deviceDesc: The DeviceDescriptor (Section 5.2) for the device is REQUIRED. location: The GeoLocation (Section 5.1) for the device. When the notification is made by a Master Device on its own behalf, the location is that of the Master Device and is REQUIRED. When the notification is made by a Master Device on behalf of a Slave Device, the location is that of the Slave Device and is OPTIONAL but may be required by some rulesets. spectra: The Spectrum (Section 5.11) list is REQUIRED and specifies the spectrum anticipated to be used by the device; this includes profiles of frequencies and power levels. The list MAY be empty, if the device decides not to use any spectrum. For consistency, the resolution bandwidth value, "resolutionBwHz", MUST match that from one of the Spectrum (Section 5.11) elements in the corresponding AVAIL_SPECTRUM_RESP message, and the maximum power levels in the Spectrum element MUST be expressed as power (EIRP) over the specified "resolutionBwHz" value. The actual bandwidth to be used (as computed from the start and stop frequencies) MAY be different from the "resolutionBwHz" value. As an example, when the ruleset expresses maximum power spectral density in terms of maximum power over any 100 kHz band, then the "resolutionBwHz" value should be set to 100 kHz, even though the actual bandwidth used can be 20 kHz. masterDeviceDesc: When the notification is made by the Master Device on behalf of a Slave Device, the Master Device MAY provide its own descriptor. masterDeviceLocation: When the notification is made by the Master Device on behalf of a Slave Device, the Master Device MUST include its own GeoLocation (Section 5.1). other: Depending on the ruleset, other parameters may be required. To simplify its logic, the device MAY include the union of all parameters required by all supported rulesets. The Database MUST ignore all parameters it does not understand.
4.5.6. SPECTRUM_USE_RESP
The spectrum-use response message simply acknowledges receipt of the notification. +---------------------------------------+ |SPECTRUM_USE_RESP | +----------------------------+----------+ |databaseChange:DbUpdateSpec | OPTIONAL | |.......................................| |*other:any | OPTIONAL | +----------------------------+----------+ Parameters: databaseChange: The Database MAY include a DbUpdateSpec (Section 5.7) to notify the device of a change to the database URI, providing one or more alternate database URIs. The device needs to update its preconfigured entry for the responding Database with the alternate Databases listed in the DbUpdateSpec. other: Database implementations MAY return additional parameters in the response. Consult the PAWS Parameters Registry (Section 9.2) for possible additional parameters.4.6. Device Validation
A Slave Device needs a Master Device to ask the Database on its behalf for available spectrum. Depending on the ruleset, the Master Device also must validate with the Database that the Slave Device is permitted to operate. When the ruleset allows a Master Device to "cache" the available spectrum for a period of time, the Master Device may use the simpler Device Validation component, instead of the full Available Spectrum Query component, to validate a Slave Device. When validating one or more Slave Devices, the Master Device sends the Database a request that includes the device identifier -- and any other parameters required by the ruleset -- for each Slave Device. The Database MUST return a response with an entry for each device to indicate whether it is permitted to use the spectrum. A typical sequence for using the Device Validation request is illustrated in Figure 5, where the Master Device already has a valid set of available spectrum for Slave Devices. Note that the communication and protocol between the Slave Device and Master Device are outside the scope of this document.
o DEV_VALID_REQ (Section 4.6.1) is the device-validation request message. o DEV_VALID_RESP (Section 4.6.2) is the device-validation response message. +------------+ +---------------+ +-------------------+ |Slave Device| | Master Device | | Spectrum Database | +------------+ +---------------+ +-------------------+ | | | | AVAIL_SPEC_REQ | | |................>| | | | | | | DEV_VALID_REQ | | |-------------------------->| | | | | | DEV_VALID_RESP | | |<--------------------------| | AVAIL_SPEC_RESP | | |<................| | | | | | (SPECTRUM_USE) | | |................>| (SPECTRUM_USE_NOTIFY) | | |-------------------------->| | | | | | (SPECTRUM_USE_RESP) | | |<--------------------------| Figure 54.6.1. DEV_VALID_REQ
This request is used by a Master Device to determine which Slave Devices are permitted to operate. +---------------------------------------------+ |DEV_VALID_REQ | +----------------------------------+----------+ |deviceDescs:list | REQUIRED |---+ |masterDeviceDesc:DeviceDescriptor | OPTIONAL | | +----------------------------------+----------+ | V 1..* +----------------------+ |DeviceDescriptor | +----------------------+
Parameters: deviceDescs: A DeviceDescriptor (Section 5.2) list is REQUIRED; it specifies the list of Slave Devices that are to be validated. masterDeviceDesc: The Master Device MAY provide its own descriptor.4.6.2. DEV_VALID_RESP
+---------------------------------------+ |DEV_VALID_RESP | +----------------------------+----------+ |deviceValidities:list | REQUIRED |---- |databaseChange:DbUpdateSpec | OPTIONAL | | +----------------------------+----------+ | V 1..* +---------------------------------------+ |DeviceValidity | +----------------------------+----------+ |deviceDesc:DeviceDescriptor | REQUIRED | |isValid:boolean | REQUIRED | |reason:string | OPTIONAL | +----------------------------+----------+ Parameters: deviceValidities: A DeviceValidities (Section 5.16) list is REQUIRED to report the list of Slave Devices and whether each listed device is valid. The number of entries MUST match the number of DeviceDescriptors (Section 5.2) listed in the DEV_VALID_REQ message. databaseChange: The Database MAY include a DbUpdateSpec (Section 5.7) to notify the device of a change to the database URI, providing one or more alternate database URIs. The device needs to update its preconfigured entry for the responding Database with the alternate Databases listed in the DbUpdateSpec.
(next page on part 3)