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
- The encoding uses an array, for example (thanks for the catch, Dan!):
[
{ "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 },
{ "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 },
{ "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },
{ "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },
{ "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 },
{ "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 },
{ "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 },
{ "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 }
]
- Even for regulatory domains that do not compute a level for all channels,
there are still generalized (absolute) limits on unintended EM emissions,
so there should be no need to use special values, such as -inf, null, etc.
for indicating the "unavailable" ranges.
Should we adopt this more general encoding over the "channelized" encoding
in Draft 06?
-vince
On Fri, Aug 30, 2013 at 12:43 PM, Andy Lee <[email protected]> wrote:
> On Thu, Aug 29, 2013 at 1:33 PM, Harasty, Daniel J <[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] | 408-230-0522
>
>
> On Thu, Aug 29, 2013 at 3:30 PM, Kalle Kuismanen <
> [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]> 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
>>
>>
>
> _______________________________________________
> paws mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/paws
>
>
--
-vince
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
