I rather prefer option 2, but I realize this is more a point of personal taste;
I think either are workable.
Regarding option 2, I have the following comments. (Some may apply to option
1, also.)
Ordering Matters
I think the spec should require that the "points" be in frequency-increasing
order of "freqHz" value. (The need is obvious, so let's state it as a
requirement.)
Two "points" may have the same "freqHz" value; their order is significant, too.
(For example, the first four points in Vince's example constitute a "step
function". However, if points #2 and #3 were swapped, it would indicate a
"sawtooth" spectral mask.)
Three (or more) "points" may NOT share a "freqHz" value.
Should be an Array
I think the term "point" is rather vague, an repeatedly re-using it in a single
object can't be kosher.
Thus, I propose this structure be an array of objects:
[
{ "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 },
{ "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 },
{ "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },
{ "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },
.
.
.
]
How to Indicate "Unavailable"
There are a few options to indicate that a subband is "unavailable".
1) The spec could state a value that means "unavailable", such as -100,
-1000.0, or -56.8.
2) The spec could not state that value, and the Database could choose an
arbitrary small number at its discretion.
3) The spec could state that the JSON value null means "unavailable", or a
reserved string such as "-Inf"
I rather prefer option 3. If we use a reserved string, I prefer "-Inf" in
particular as it is an IEEE standard for negative infinity, and many
programming languages support interpreting "-Inf" as a parsable string
resulting in a valid IEEE float.
[
{ "freqHz": 4.70e8, "maxPsdDbmPerBw": null},
{ "freqHz": 5.18e8, "maxPsdDbmPerBw": null },
{ "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },
{ "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },
]
or
[
{ "freqHz": 4.70e8, "maxPsdDbmPerBw": "-Inf"},
{ "freqHz": 5.18e8, "maxPsdDbmPerBw": "-Inf"},
{ "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },
{ "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },
]
From: [email protected] [mailto:[email protected]] On Behalf Of Vincent
Chen
Sent: Sunday, August 25, 2013 6:40 PM
To: [email protected]
Subject: [paws] Encoding of spectrum profile
All,
As was brought up before (and at) the F2F, the current encoding for a spectrum
profile
has a "channelized" view:
- List of (startHz, stopHz, power)
- Has no ability to specify power level in "unavailable" ranges
Example:
{
"point": { "startHz": 5.18e8, "stopHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },
"point": { "startHz": 5.24e8, "stopHz": 5.30e8, "maxPsdDbmPerBw": 36.0 },
}
Question: Should we use a more flexible encoding?
There were two proposals made on the list:
- Option 1: List of (startHz, startPower, stopHz, stopPower)
- Option 2: Ordered list of (freqHz, power)
At the F2F, we agreed that Option 2 was the more general form.
Example:
{
"point": { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 },
"point": { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 },
"point": { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },
"point": { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },
"point": { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 },
"point": { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 },
"point": { "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 },
"point": { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 }
}
This example explicitly specifies the power levels in the unavailable frequency
ranges.
This example also shows that it's possible to encode "square edges" by having
two
points using the same frequency, but does allow for "slanted edges" for more
gentle roll-offs.
--
-vince
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
