Subject: [paws] Encoding of spectrum profile

From: Vincent Chen <[email-masked]>
Date: Sun, 25 Aug 2013 15:39:42 -0700

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

---

From: Ray Bellis <[email-masked]>
Date: Thu, 29 Aug 2013 14:00:40 +0000

On 25 Aug 2013, at 23:39, Vincent Chen <[email-masked]> wrote:

> All,
> 
> As was brought up before (and at) the F2F, the current encoding for a spectrum profile
>     "point": { "startHz": 5.18e8, "stopHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },
>     "point": { "startHz": 5.24e8, "stopHz": 5.30e8, "maxPsdDbmPerBw": 36.0 },
>   }
> 
> 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.

I recall discussion of whether interpolated ramps were a good idea, and clarification that having the same "stop" and "start" power would be effectively the same as having a "startHz" and "stopHz" with a single power level, and thus could also generalise to represent the channelised model.

However I recall no discussion of the latter encoding - I thought the proposal was to go with your #1 above.

BTW, what value of "Bw" would be used to calculate the Psd when the interval between points is not constant?  Given the OFCOM and ETSI requirement for both a channel-wide in-block EIRP *and* a 100 kHz spectral density, how would these be encoded in either of these variations?

Also, I don't understand the note about specifying power levels in "unavailable" ranges.  You appear to be suggesting that the "magic value" of -56.8 dBm above indicates "unavailable", but I can't find the thread that gives the rationale for this.  It only appears to be necessary because there's no scope within a single array of "points" to omit a range of frequencies, whereas option #1 allows that by explicitly only listing "available" ranges.

kind regards,

Ray

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Thu, 29 Aug 2013 09:04:03 -0700

> Also, I don't understand the note about specifying power levels in "unavailable" ranges.  You appear to be suggesting that the "magic value" of -56.8 dBm above indicates "unavailable", but I can't…
I too was confused by this, and *think* I have figured it out (perhaps 
incorrectly):
"Unavailable" means the channel is not indicated as available at the 
specific location and time of the query.  Thus intentional radiation by 
a whitespace device is not allowed. In real RF systems, a device 
transmitting in an available channel near the unavailable channel will 
have some energy "spill" outside the boundaries of the channel.  The 
white space issued and proposed regulations I have reviewed have 
different definitions of what is allowed to "spill". I assume (dangerous 
word alert) that the intention is to allow communication of these 
different regulatory requirements.

FCC regulations do not define "unavailable" but do specify limits on 
emissions by TVWS devices outside of the TV channel being used, whether 
it is indicated as "available" or not. This is specified as a level 
relative to transmit signal level, not absolute dBm (" 72.8 dB below the 
highest average power in the TV channel in which the device is 
operating.").  For frequencies beyond the TV channel adjacent to channel 
being used, maximum emissions are defined as field strength (15.209).    
Representing the later is in dBm requires defining the parameters for 
conversion; Note FCC received multiple comments suggesting changing the 
adjacent channel requirement to an absolute level and not relative to an 
actual level.   I don't see how the FCC requirements as issued can be 
expressed in this format.

I might be misinterpreting the intention.

Ben

>
> kind regards,
>
> Ray
>
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws

---

From: "Harasty, Daniel J" <[email-masked]>
Date: Thu, 29 Aug 2013 20:33:36 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Vincent Chen
Sent: Sunday, August 25, 2013 6:40 PM
To: [email-masked]
Subject: [paws] Encoding of spectrum profile

All,

Example:
  {

Example:
  {

--
-vince

---

From: Kalle Kuismanen <[email-masked]>
Date: Fri, 30 Aug 2013 01:30:31 +0300

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 = [
];
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-masked]>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-masked] [mailto:[email-masked]] *On Behalf
> Of *Vincent Chen
> *Sent:* Sunday, August 25, 2013 6:40 PM
> *To:* [email-masked]
> *Subject:* [paws] Encoding of spectrum profile****
>
> ** **
>
> All,****
>
> ** **
>
> spectrum profile****
> has a "channelized" view:****
>
>  - List of (startHz, stopHz, power)****
>
>  - Has no ability to specify power level in "unavailable" ranges****
>
> ** **
>
> Example:****
>
>   {****
>
> },****
> },****
>   }****
> ** **
> 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 }****
>
>   }****
>
>
> ****
>
> frequency ranges.****
> ** **
> having two****
> more gentle roll-offs.****
>
> ** **
>
> --
> -vince ****
>

---

From: Ray Bellis <[email-masked]>
Date: Fri, 30 Aug 2013 08:35:12 +0000

On 29 Aug 2013, at 17:04, Benjamin A. Rolfe <[email-masked]<mailto:[email-masked]>> wrote:

I too was confused by this, and *think* I have figured it out (perhaps incorrectly):
"Unavailable" means the channel is not indicated as available at the specific location and time of the query.  Thus intentional radiation by a whitespace device is not allowed. In real RF systems, a device transmitting in an available channel near the unavailable channel will have some energy "spill" outside the boundaries of the channel.  The white space issued and proposed regulations I have reviewed have different definitions of what is allowed to "spill".  I assume (dangerous word alert) that the intention is to allow communication of these different regulatory requirements.

Hmm, ok...

FCC regulations do not define "unavailable" but do specify limits on emissions by TVWS devices outside of the TV channel being used, whether it is indicated as "available" or not. This is specified as a level relative to transmit signal level, not absolute dBm (" 72.8 dB below the highest average power in the TV channel in which the device is operating.").  For frequencies beyond the TV channel adjacent to channel being used, maximum emissions are defined as field strength (15.209).    Representing the later is in dBm requires defining the parameters for conversion; Note FCC received multiple comments suggesting changing the adjacent channel requirement to an absolute level and not relative to an actual level.   I don't see how the FCC requirements as issued can be expressed in this format.

The draft ETSI spec has a table (§4.2.4.2.2, Table 3) giving permitted adjacent frequency leakage ratios.  They also appear to be relative to the in-block power rather than absolute values.

In any event, how would this data model support the perfectly feasible scenario where a device is offered two adjacent channels, and therefore has "full power" available in either, but only choses to use one, and therefore must limit its OOB transmissions in the other?

If what you've described above is the real rationale (and other messages I've seen suggest it is) then it seems to me that mixing together in-block power levels and out-of-block power limits in the same frequency table is a big mistake.  There appears to be no way to encode the frequency parameters to say "you may use 30 dBm in this channel if you're using it, but only leak -30 dBm into it if you use the adjacent channel instead".

kind regards,

Ray

---

From: Andy Lee <[email-masked]>
Date: Fri, 30 Aug 2013 11:49:56 -0700

On Fri, Aug 30, 2013 at 1:35 AM, Ray Bellis <[email-masked]>
 wrote:

> If what you've described above is the real rationale (and other messages
> I've seen suggest it is) then it seems to me that mixing together in-block
> power levels and out-of-block power limits in the same frequency table is a
> big mistake.  There appears to be no way to encode the frequency parameters
> to say "you may use 30 dBm in this channel if you're using it, but only
> leak -30 dBm into it if you use the adjacent channel instead".

My interpretation is that the PAWS spectrum profile is expressing what is
permissible under the local white space rules and is completely separate
from the hardware OOB emission limits.

In the case of the FCC, the permissible white space power is specified as
absolute in-band power limits (36 dBm/6MHz EIRP fixed, 20 dBm/6MHz mode 2,
and 16 dBm/6MHz mode 1), and specific absolute out-of-band power limits
(-36.8 dBm/6MHz EIRP fixed, -56.8 dBm/6MHz any portable device on an
adjacent channel, and -52.8 dBm/6MHz any other portable device), as
specified in CFR Title 47, section 15.709.  The FCC has additional special
requirements around channel 37 as specified by the field strength table in
section 15.709(c)(4).

In the case of Ofcom, the permissible white space power is calculated
individually per-channel for DTT and PMSE, resulting in a different power
level for every 8 MHz and 100 kHz channel.  There isn't really a
distinction between "in-band" and "out-of-band" emissions when a continuum
of power levels are possible.

The spectrum database simply provides this list of permitted frequencies
and power levels over the PAWS protocol.  The profile of permitted spectrum
could include adjacent channels in some places.  It is then the device's
responsibility to select which subset of frequencies it will actually use,
in accordance with local regulation.

At the time the device is built (and presumably as part of the device
certification process), it must comply with several in-band and out-of-band
emissions requirements (whether they are specified as relative values or
absolute), but this has nothing to do with the spectrum availability
offerings being communicated over PAWS.  For example, Ofcom has specific
adjacent channel leakage ratio (ACLR) requirements for devices to qualify
as a Class 1, 2, 3, or 4 white space device.  Once hardware is built, the
ACLR performance of a device is essentially fixed, and there's nothing in
the PAWS spectrum message that would change that.

Andy Lee | Google Inc. | [email-masked] | 408-230-0522

On Fri, Aug 30, 2013 at 1:35 AM, Ray Bellis <[email-masked]>wrote:

>
>  On 29 Aug 2013, at 17:04, Benjamin A. Rolfe <[email-masked]> wrote:
>
> specific location and time of the query.  Thus intentional radiation by a
> whitespace device is not allowed. In real RF systems, a device transmitting
> in an available channel near the unavailable channel will have some energy
> "spill" outside the boundaries of the channel.  The white space issued and
> proposed regulations I have reviewed have different definitions of what is
> allowed to "spill".  I assume (dangerous word alert) that the intention is
> to allow communication of these different regulatory requirements.
>
>
>  Hmm, ok...
>
> emissions by TVWS devices outside of the TV channel being used, whether it
> is indicated as "available" or not. This is specified as a level relative
> to transmit signal level, not absolute dBm (" 72.8 dB below the highest
> average power in the TV channel in which the device is operating.").  For
> frequencies beyond the TV channel adjacent to channel being used, maximum
> emissions are defined as field strength (15.209).    Representing the later
> is in dBm requires defining the parameters for conversion; Note FCC
> received multiple comments suggesting changing the adjacent channel
> requirement to an absolute level and not relative to an actual level.   I
> don't see how the FCC requirements as issued can be expressed in this
> format.
>
>
>  The draft ETSI spec has a table (§4.2.4.2.2, Table 3) giving permitted
> adjacent frequency leakage ratios.  They also appear to be relative to the
> in-block power rather than absolute values.
>
>  In any event, how would this data model support the perfectly feasible
> scenario where a device is offered two adjacent channels, and therefore has
> "full power" available in either, but only choses to use one, and therefore
> must limit its OOB transmissions in the other?
>
>  If what you've described above is the real rationale (and other messages
> I've seen suggest it is) then it seems to me that mixing together in-block
> power levels and out-of-block power limits in the same frequency table is a
> big mistake.  There appears to be no way to encode the frequency parameters
> to say "you may use 30 dBm in this channel if you're using it, but only
> leak -30 dBm into it if you use the adjacent channel instead".
>
>  kind regards,
>
>  Ray
>
>

---

From: Andy Lee <[email-masked]>
Date: Fri, 30 Aug 2013 12:43:39 -0700

On Thu, Aug 29, 2013 at 1:33 PM, Harasty, Daniel J <[email-masked]>
wrote:

> 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.

On Thu, Aug 29, 2013 at 3:30 PM, Kalle Kuismanen <
[email-masked]> 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:
>
> 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 Thu, Aug 29, 2013 at 11:33 PM, Harasty, Daniel J <
> [email-masked]> wrote:
>
>>  ** **
>>
>> 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.)****
>>
>> ** **
>>
>> 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
>>     "point": { "startHz": 5.18e8, "stopHz": 5.24e8, "maxPsdDbmPerBw":
>> 30.0 },****
>>
>>     "point": { "startHz": 5.24e8, "stopHz": 5.30e8, "maxPsdDbmPerBw":
>> 36.0 },****
>>
>>   }****
>>
>> ** **
>>