Thanks everyone.
Here's a more refined description of Option 2, based on the comments.
- A spectrum profile provides the maximum permissible power levels across a
range of frequencies, where power levels are expressed as maximum power
spectral densities over a specified bandwidth
- When regulations have requirements at multiple bandwidths (e.g., Ofcom,
ETSI), there would be a spectrum profile for each bandwidth. The device
emissions must be bounded by all the profiles (logical AND).
- The spectrum profile is expressed in terms of an "Ordered List" of (freqHz,
psd) pairs
- The points must be ordered in non-decreasing "freqHz" value
- Two consecutive points may have the same "freqHz" to represent a "step
function"
- Three or more points may NOT share the same "freqHz" value
- There must be two or more points with different "freqHz" values
…
Should we adopt this more general encoding over the "channelized" encoding in
Draft 06?
Yes. Seems like a significant improvement!
Paul
-vince
On Fri, Aug 30, 2013 at 12:43 PM, Andy Lee
<[email protected]<mailto:[email protected]>> wrote:
On Thu, Aug 29, 2013 at 1:33 PM, Harasty, Daniel J
<[email protected]<mailto:[email protected]>> wrote:
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”
In the case of Ofcom white space rules, I believe that a power level will be
computed for every channel, albeit very low on some channels.
In the case of the FCC, there are also specific levels specified for OOB white
space emissions.
For Industry Canada, the FCC, and probably everywhere, there are also
generalized limits on unintended EM emissions (e.g., IC "RSS-Gen" and FCC "Part
15" rules). This should make it possible to specify a theoretical power
"floor" without having to resort to weirdness like "-Inf" or "null" values. It
would be much better to fill in real values based on actual rules from the
regulator.
Andy Lee | Google Inc. | [email protected]<mailto:[email protected]> |
408-230-0522<tel:408-230-0522>
On Thu, Aug 29, 2013 at 3:30 PM, Kalle Kuismanen
<[email protected]<mailto:[email protected]>>
wrote:
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]<mailto:[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]>
[mailto:[email protected]<mailto:[email protected]>] On Behalf Of
Vincent Chen
Sent: Sunday, August 25, 2013 6:40 PM
To: [email protected]<mailto:[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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/paws
--
-vince
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
