Ray,
Thanks chiming in.
It seems to me that having the extra "timeRange" and "frequencyRanges"
would still be useful extension to the -06 version
in order to define the "envelope" (in both time and frequencies) for the
response.
Example:
{
"rulesetInfo": { ... },
"timeRange": { "startTime": "2013-10-01T00:00:00Z", "stopTime":
"2013-10-03T00:00:00Z" },
"frequencyRanges": [
[5.4e7, 7.2e7], // channels 2-4
[7.6e7, 8.8e7], // channels 5-6
[1.74e8, 2.16e8], // channels 7-13
[4.70e8, 6.98e8], // channels 14-51
],
"spectrumSchedules": [
{
"eventTime": { "startTime": "2013-10-01T00:00:00Z", "stopTime":
"2013-10-01T05:00:00Z" },
"spectra" [
{
"psdBandwidthHz": 6e6,
"frequencyRanges": [
{ "startHz": 4.70e8, "stopHz": 4.76e8, "maxPsdDbmPerBw": 30.0
}, // channel 14
{ "startHz": 5.18e8, "stopHz": 5.24e8, "maxPsdDbmPerBw": 30.0
}, // channel 22
{ "startHz": 5.24e8, "stopHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }
// channel 23
]
},
{
"psdBandwidthHz": 1e5,
"frequencyRanges": [
{ "startHz": 4.70e8, "stopHz": 4.76e8, "maxPsdDbmPerBw": 27.0
}, // channel 14
{ "startHz": 5.18e8, "stopHz": 5.24e8, "maxPsdDbmPerBw": 27.0
}, // channel 22
{ "startHz": 5.24e8, "stopHz": 5.30e8, "maxPsdDbmPerBw": 33.0 }
// channel 23
]
}
]
},
{
"eventTime": { "startTime": "2013-10-01T05:00:00Z", "stopTime":
"2013-10-03T00:00:00Z" },
...
}
]
}
Are you OK with that? (The "spectrumSchedules" encoding is the same as in
-06).
-vince
On Wed, Oct 9, 2013 at 2:08 AM, Ray Bellis <[email protected]>wrote:
> [apologies for the late reply, I've been away on business and didn't
> have time to follow the list]
>
> On 3 Oct 2013, at 16:56, Peter Stanforth <[email protected]>
> wrote:
>
> Personally speaking, I got tired of arguing and had more important
> things to do.
> It does not appear that "everyone" is ok with the proposal because the
> number of people involved in the discussion is such a small subset of the
> group.
>
>
> Indeed!
>
> My primary concern is the delay in the process that is being created by
> what appears to be feature creep relative to the charter/requirements.
> I am comfortable that I can support Ofcom, FCC, and other TVWS regulation
> that I am aware of with the channel information described in the current
> published draft (v6).
>
>
> +1 - the -06 draft is already sufficient to satisfy all current
> regulatory needs - why complicate it at this stage?
>
> There were so many examples ricocheting around I did not realize this
> was the proposal on the table so I have not considered it enough to decide
> what my opinion is. So as you asked, though I am somewhat confused by what
> this proposal means , I will try to review this and respond in context.
>
>
> I think the proposed structure is only barely acceptable. It works, but
> it imposes an unnecessarily deep structure on those whose requirements were
> perfectly satisfied with the -06 version.
>
> It does not (without additional rules) result in a definitive canonical
> representation, which may lead to confusion for implementors. In
> particular, I would be extremely unlikely to coalesce contiguous channels
> into a single "segment" when a separate segment "per channel" would be far
> simpler (and the -06 version simpler still!)
>
> I've yet to see *any* rationale to justify non-zero slope in the segment
> data that isn't based on OOB emissions, which IMHO simply do not belong in
> this table.
>
> Ray
>
>
--
-vince
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
