All,
I'd like to propose the following for addressing the extensibility of the
protocol.
*Regulatory rules (roughly) fall under three areas:
- Database-only rules, such as how spectrum availability must be computed
- Device-only rules that govern its behavior, e.g.,
- Maximum-power levels that depend on how many channels the Device
chooses to use
- Conditions under which the Device must contact the Database
- Rules that impact both, such as,
- Device parameters that are needed to determine spectrum availability
- Spectrum-availability information that must be provided by the
Database
- Spectrum utilization reporting (in jurisdictions that require it)
The following proposals assumes that it will not be practical to have the
Database be responsible for communicating Device-only rules to the devices,
because:
- It is impractical to encode all device behavior via a set of
declarative parameters
- The device will be subject to a certification process to determine
correct device behavior for each set of regulatory rules
Interaction model
The Device must include a "Device Descriptor" with each request to the
Database. The descriptor contains fields that identify the device, its
configuration, its certification tags, and any other parameters required by
regulators, such as device type, device class, etc.
1. The Device makes a request with as many of the Device Descriptor
fields as it chooses to populate, plus its location
2. The Database determines if all required parameters are provided. If
not, it returns an error with a list of the missing parameters.
1. The list of missing parameters may depend on the certification
tags provided by the Device
2. If certification tags are specified, but the Database does not
allow any of them, it returns a UNAUTHORIZED error
3. The Device may make the request again with the missing parameters. If
the Device cannot supply the missing parameters, it will not be able to use
the Database.
4. When the request is valid, the Database includes in its response the
certification tag that corresponds to the applicable rule set.
A "certification tag" represents the certification a device has been
certified by a certification body (does not necessarily have to be a
regulator?). A device may be configured with multiple certification tags.
Valid values for the certification tag, as well as valid Device Descriptor
fields, will be extensible via appropriate IANA tables.
NOTE: In order for new regulators to leverage existing devices to operate
within their jurisdictions, regulators might be motivated adopt existing
certifications, rather than defined create new rules and new certification
processes. If that is true, there should not be a proliferation of
certification tags. *
Is something like this workable?
--
-vince
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
