On 13 Sep 2013, at 17:00, Vincent Chen
<[email protected]<mailto:[email protected]>>
wrote:
I see. Television channels do not occupy a contiguous range of frequencies. In
the US,
- [54MHz, 72MHz] Channel 2-4
- [76MHz, 88MHz] Channels 5-6
- [174MHz, 216MHz] Channels 7-13
- [470MHz, 698MHz] Channels 14-51
So the response given by the database should not include any frequencies not in
the plan.
That means a "spectrum profile" should be encoded as a list of "array" of
(frequency, power) points.
- Each array represents a "profile" for a contiguous range of frequencies
- The range of frequencies within a list of profiles MUST be disjoint and
SHOULD be sorted
- The entire set of frequency bands defined by the regulatory domain MUST be
represented by a single list of "profiles"
(rather than split them across multiple lists)
That last point is to remove ambiguity and, thus, variations in database
implementation, to simplify logic on devices.
Example:
...
Does that address your concern?
It does, although I still think the original #1 data model where each available
frequency range was simply defined by (f1, f2, psd1, psd2) is much better.
It's also more consistent with the ETSI draft spec.
Using the #2 model of an array of (f, psd) points is only more efficient as an
encoding mechanism in those few cases where non-zero PSD slopes do actually
need to be encoded. Any time there's a "step" jump in Psd you need just as
much data to encode that jump using (f, psd) points as you would if you used
(f1, f2, psd1, psd2).
Regarding splitting the lists in the way you propose, that's not just a
question of what frequencies are "in the plan". The current OFCOM consultation
proposes (ยง5.93) "not to allow WSD operation in channel 38" (606 - 614 MHz) as
that's used for nationwide PMSE. Channel 38 is definitely "in the plan", but
it's also a discontinuity. Your proposed model would appear to require that we
break our frequency table in two either side of channel 38, and ends up with a
two dimensional array of arrays in the JSON encoding.
Using (f1, f2, p1, p2) allows the use of a single level list of values, with
the only constraint being that frequency ranges not overlap.
Your example for the US plan then just becomes (omitting the 100 kHz bandwidth):
"spectra": [
{
"bandwidth": 6e6,
"frequencyRanges": [
{"startHz": 5.4e7, "stopHz", 7.2e7, "startPsd": -56.8, "stopPsd":
-56.8},
{"startHz": 7.6e7, "stopHz", 8.8e7, "startPsd": -56.8, "stopPsd":
-56.8},
{"startHz": 1.74e8, "stopHz", 2.16e8, "startPsd": -56.8, "stopPsd":
-56.8},
{"startHz": 4.70e8, "stopHz", 5.18e8, "startPsd": -56.8, "stopPsd":
-56.8},
{"startHz": 5.18e8, "stopHz", 5.24e8, "startPsd": 30.0, "stopPsd":
30.0},
{"startHz": 5.24e8, "stopHz", 5.30e8, "startPsd": 36.0, "stopPsd":
36.0},
{"startHz": 5.30e8, "stopHz", 5.30e8, "startPsd": -56.8, "stopPsd":
-56.8}
]
]
]
This requires 28 data values, exactly the same as in your example. It's also
the smallest change necessary from the current spec in
draft-ietf-paws-protocol-06 to support non-zero Psd slopes. For encoding
efficiency one could also specify that PSD just be either a single value or a
pair [psd1, psd2] for those non-zero slope cases.
kind regards,
Ray
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
