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 protected]> wrote:
> 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 protected]> 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 protected]>
>> http://www.cs.binghamton.edu/~mike
>> +1-201-BLISTER
>>
>> _______________________________________________
>> paws mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/paws
>>
>>
>
>
> --
> -vince
>
--
-vince
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
