Hi All,
I haven't participated in the discussion much, but I just had to solve this
very issue about a week ago so here a my two cents:
on the issue of "-Inf" or null. We've also used in our paws and other
protocol implementation "-Inf" as indication of channel being unavailable,
but problem is that it's somewhat misleading. For example if a channel is
"usable" only above 20 dBm and we calculate maximum transmission to be 19
dBm it is bit silly to send -Inf. Null value is even more misleading,
because it usually indicates that we don't know what the value is, which in
this case probably would mean an implementation error in the calculation
code.
Then of course considering the implementation. I tried to use in our paws
implementation "-Inf", but of course Javascript doesn't recognize that
string as a number, so it causes a type casting problem i.e. sometimes the
value is a number and sometimes a string. Which of course led to first our
server not validating the JSON against the PAWS schema and then when I by
passed that (bad thing, but I was in a rush) our test client side
validation failed also.
See below how I decided it should be solved, but in the end, because didn't
want to burden the device side implementers I just dropped the channels
that couldn't be used from the array.
On the client side or device side the JSON needs to be checked for the
special value or a simple field will suffice. Mutable nature of JSON makes
it easy.
On client side the code would check in Javascript in node.js:
var a = [
{ "freqHz": 4.70e8, "unavailable": true},
{ "freqHz": 5.18e8, "unavailable": true},
{ "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },
{ "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },
];
var b = "";
for(var f in a)
{
if(a[f]["unavailable"]!==true)
b += a[f].freqHz+":"+a[f].maxPsdDbmPerBw+"\n";
}
process.stdout.write( b );
This is not so different from using "-Inf" or "null" implementation.
var a = [
{ "freqHz": 4.70e8, "maxPsdDbmPerBw": "-Inf"},
{ "freqHz": 5.18e8, "maxPsdDbmPerBw": "-Inf"},
{ "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },
{ "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },
];
var b = "";
for(var f in a)
{
if(a[f]["maxPsdDbmPerBw"]!=="-Inf")
b += a[f].freqHz+":"+a[f].maxPsdDbmPerBw+"\n";
}
process.stdout.write( b );
Both cases usually just do one comparison. But as I said first version
preserves type of maxPsdDbmPerBw other does not. Both cost about the same
on the wire.
But of course this is just a suggestion. JSON is very malleable.
Cheers,
Kalle Kuismanen
FairSpectrum
On Thu, Aug 29, 2013 at 11:33 PM, Harasty, Daniel J
<[email protected]>wrote:
> ** **
>
> 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
>
>
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
