Subject: [paws] Supporting multiple authorities / rulesets in a PAWS response?

From: Michael Head <[email-masked]>
Date: Wed, 24 Jul 2013 10:44:49 +0100

>From my reading, a device can only get information about spectrum under a
single ruleset at a time. (I suppose there is one way around this if a
device opts to skip the Init operation and the database opts not to include
the rulesetInfo in the AvailSpectrumResp, but that doesn't seem to be in
the spirit of the protocol).

Now, there may be multiple rulesets that govern a particular location. For
example, in disputed territories where two governments claim authority (or
even just near an undisputed border, the device may want/need to know the
spectrum available on both sides of the border).

Even within a particular domain, there may be different rulesets governing
different shared spectrum bands (TVWS vs. 3.5 ghz or 5ghz bands). Devices
might be built to support both and may need to consult a database to get
information about all bands.

What should devices and databases do? I suppose it can be done by having
the device send multiple, independent querys. In the first case, it would
send a spectrum request with a DeviceDescriptor with a restricted set of
ruleset ids to cover the regulatory domains it cares about (but then, how
would it know which domains are useful at a given lat/lon?). For the second
case, the device could fire separate requests with DeviceCapabilities set
to cover the different bands it supports, which seems a little more
workable.  Still, it would be nice if these could be handled in a single
request/response.

Furthermore, certain databases might want to give additional information
about spectrum at a location, but the spec doesn't have a standard way of
allowing for that. Of course, the database is free to add any fields,
anywhere it likes, but it would be nice if there were a structured way to
allow a PAWS response to include independent spectrum reports.

-- mike

-- 
----------------------------------
Michael R Head <[email-masked]>
http://www.cs.binghamton.edu/~mike
+1-201-BLISTER

---

From: Vincent Chen <[email-masked]>
Date: Wed, 24 Jul 2013 10:38:07 -0700

Mike,

Ah, good point. To support responses for multiple rulesets requires
additional layering of the response.

This seems to be a relatively slight modification to the
AVAIL_SPECTRUM_RESP (and associated batch response)
to have a list of (rulesetInfo, SpectrumSchedule list) objects.

Does that sound right?

All, should I update the response message to support this?

-vince

On Wed, Jul 24, 2013 at 2:44 AM, Michael Head <[email-masked]> wrote:

> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws
>
>

-- 
-vince

---

From: Vincent Chen <[email-masked]>
Date: Wed, 24 Jul 2013 10:51:12 -0700

Actually, something like:

   +---------------------------------------+
   |AVAIL_SPECTRUM_RESP                    |
   +----------------------------+----------+
   |timestamp:string            | required |
   |deviceDesc:DeviceDescriptor | required |
   |spectrumSpecs:list          | required |----+
   |............................|..........|    |
   |location:GeoLocation        | optional |    |
   |............................|..........|    |
   |databaseChange:DbUpdateSpec | optional |    |
   |*other:any                  | depends  |    |
   +----------------------------+----------+    | 1..*
                                                V
             +------------------------------------+
             | SpectrumSpec                       |
             +-------------------------+----------|
             |spectrumSchedules:list   | required |--+
             |needsSpectrumReport:bool | optional |  |
             |maxTotalBwHz:float       | optional |  |
             |maxContiguousBwHz:float  | optional |  |
             |rulesetInfo:RulesetInfo  | required |  | 0..*
             +-------------------------+----------+  V
                                         +----------------+
                                         |SpectrumSchedule|
                                         +----------------+

In this encoding, the rulesetInfo becomes required.
Thoughts?

-vince

On Wed, Jul 24, 2013 at 10:38 AM, Vincent Chen <[email-masked]> wrote:

>> Now, there may be multiple rulesets that govern a particular location.
>> For example, in disputed territories where two governments claim authority
>> (or even just near an undisputed border, the device may want/need to know
>> the spectrum available on both sides of the border).
>>
>> Even within a particular domain, there may be different rulesets
>> governing different shared spectrum bands (TVWS vs. 3.5 ghz or 5ghz bands).
>> Devices might be built to support both and may need to consult a database
>> to get information about all bands.
>>

-- 
-vince

---

From: "Harasty, Daniel J" <[email-masked]>
Date: Wed, 24 Jul 2013 18:10:26 +0000

The PAWS concept of "rulesets" seems to be principally based on the idea that different locations might have a specific "ruleset" (singular) that applies.  Like Mike, I have wondered if this is laying the groundwork for PAWS to handle multiple "rulesets" (plural) at a particular location.

I think we should tease out TWO separate impacts if that is expected (or at least allowed):

*         If a Device doesn't know which of its supported rulesets apply at a given location, should we support a way for the Database to inform the Device?

o   Actually we need the overlap of THREE sets: rulesets supported by the Device, rulesets allowed (by the regulatory authority) at this location, and the rulesets supported by the Database.

o   Thus, this seems like a natural "extension" to the "ruleset negotiation" we contemplated in an early email.  Maybe this should be handled at INIT_REQ time?

*         If multiple rulesets are allowed at a given location, should we support a way to make a SINGLE AVAIL_SPECTRUM_REQ to get both?

o   That sounds logical, and not too difficult to define in the spec....

o   .... however, I'd like to not "force" the implementation on the Database that it must implement "all rulesets for a given location on every server that supports that location."

o   Said other way: I think a Database should be allowed to implement different rulesets at different URLs, and use the redirect mechanism to get specific AVAIL_SPECTRUM_REQs (with a specific ruleset) to the "right" server instance in its federation.

o   Can we adapt PAWS to accommodate this?  It is tricky: how would a server instance "half reply" to a message, yet "half redirect" it?

o   If this is too difficult to specify, then I'd suggest we simply stick with the model that AVAIL_SPECTRUM_REQs only contain one "ruleset" at a time, and the device send independent ones.  I think the downsides are pretty slight.

One more comment: I'm 100% comfortable sidestepping the possibility that "multiple authorities may claim authority at a given location".  I'm fine if PAWS has the model "one location, one authority".

- Dan Harasty

From: [email-masked] [mailto:[email-masked]] On Behalf Of Vincent Chen
Sent: Wednesday, July 24, 2013 1:38 PM
To: Michael Head
Cc: [email-masked]
Subject: Re: [paws] Supporting multiple authorities / rulesets in a PAWS response?

Mike,

Ah, good point. To support responses for multiple rulesets requires additional layering of the response.

This seems to be a relatively slight modification to the AVAIL_SPECTRUM_RESP (and associated batch response)
to have a list of (rulesetInfo, SpectrumSchedule list) objects.

Does that sound right?

-vince

On Wed, Jul 24, 2013 at 2:44 AM, Michael Head <[email-masked]<mailto:[email-masked]>> wrote:
>From my reading, a device can only get information about spectrum under a single ruleset at a time. (I suppose there is one way around this if a device opts to skip the Init operation and the database opts not to include the rulesetInfo in the AvailSpectrumResp, but that doesn't seem to be in the spirit of the protocol).

Now, there may be multiple rulesets that govern a particular location. For example, in disputed territories where two governments claim authority (or even just near an undisputed border, the device may want/need to know the spectrum available on both sides of the border).

Even within a particular domain, there may be different rulesets governing different shared spectrum bands (TVWS vs. 3.5 ghz or 5ghz bands). Devices might be built to support both and may need to consult a database to get information about all bands.

What should devices and databases do? I suppose it can be done by having the device send multiple, independent querys. In the first case, it would send a spectrum request with a DeviceDescriptor with a restricted set of ruleset ids to cover the regulatory domains it cares about (but then, how would it know which domains are useful at a given lat/lon?). For the second case, the device could fire separate requests with DeviceCapabilities set to cover the different bands it supports, which seems a little more workable.  Still, it would be nice if these could be handled in a single request/response.

Furthermore, certain databases might want to give additional information about spectrum at a location, but the spec doesn't have a standard way of allowing for that. Of course, the database is free to add any fields, anywhere it likes, but it would be nice if there were a structured way to allow a PAWS response to include independent spectrum reports.

-- mike

--
----------------------------------
Michael R Head <[email-masked]<mailto:[email-masked]>>
http://www.cs.binghamton.edu/~mike
+1-201-BLISTER

_______________________________________________
paws mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/paws

--
-vince