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
