Subject: [paws] PAWS Protocol: Extensibility

From: Vincent Chen <[email-masked]>
Date: Tue, 15 Jan 2013 17:30:04 -0800

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

---

From: Weixinpeng <[email-masked]>
Date: Mon, 21 Jan 2013 01:45:17 +0000

Hi Vince,
         I have a question about the "Interaction model". In your description, the DB will authenticate the device, but
sometimes the device may also needs to authenticate the DB. So maybe a mutual authentication need to be considered.

--Xinpeng

From: [email-masked] [mailto:[email-masked]] On Behalf Of Vincent Chen
Sent: Wednesday, January 16, 2013 9:30 AM
To: [email-masked]
Subject: [paws] PAWS Protocol: Extensibility

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.

     *   The list of missing parameters may depend on the certification tags provided by the Device
     *   If certification tags are specified, but the Database does not allow any of them, it returns a UNAUTHORIZED error

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

--
-vince

---

From: Vincent Chen <[email-masked]>
Date: Tue, 22 Jan 2013 08:30:13 -0800

Xinpeng,

On Sun, Jan 20, 2013 at 5:45 PM, Weixinpeng <[email-masked]> wrote:

>  Hi Vince,****
>
>          I have a question about the “Interaction model”. In your
> description, the DB will authenticate the device, but****
>
> sometimes the device may also needs to authenticate the DB. So maybe a
> mutual authentication need to be considered.****
>
> ** **
>
> **
>

Sorry that my description is incomplete. It assumes that authentication of
the DB already occurred at the HTTPS layer.

-vince

>  **
> --Xinpeng****