Subject: Re: [paws] Encoding of spectrum profile

From: Vincent Chen <[email-masked]>
Date: Wed, 4 Sep 2013 17:23:54 -0700

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-masked]> wrote:

> On Thu, Aug 29, 2013 at 1:33 PM, Harasty, Daniel J <[email-masked]
> > 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-masked] |  408-230-0522
>
>
> 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:
>>
>> 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-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,****
>>>
>>> ** **
>>>
>>> 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-masked]
>>> https://www.ietf.org/mailman/listinfo/paws
>>>
>>>
>>
>> _______________________________________________
>> paws mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/paws
>>
>>
>
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws
>
>

-- 
-vince

---

From: Paul Lambert <[email-masked]>
Date: Wed, 4 Sep 2013 18:09:42 -0700

Thanks everyone.

- 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-masked]<mailto:[email-masked]>> wrote:

On Thu, Aug 29, 2013 at 1:33 PM, Harasty, Daniel J <[email-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]> |   408-230-0522<tel:408-230-0522>

On Thu, Aug 29, 2013 at 3:30 PM, Kalle Kuismanen <[email-masked]<mailto:[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:

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.

var a = [

for(var f in a)
    {

var a = [

for(var f in a)
    {

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.

Cheers,
Kalle Kuismanen
FairSpectrum

On Thu, Aug 29, 2013 at 11:33 PM, Harasty, Daniel J <[email-masked]<mailto:[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:

[

   .

   .

   .

]

How to Indicate “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 },

]

or

[

    { "freqHz": 4.70e8, "maxPsdDbmPerBw": “-Inf”},

    { "freqHz": 5.18e8, "maxPsdDbmPerBw": “-Inf”},

]

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Vincent Chen
Sent: Sunday, August 25, 2013 6:40 PM
To: [email-masked]<mailto:[email-masked]>
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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/paws

_______________________________________________
paws mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/paws

_______________________________________________
paws mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/paws

--
-vince

---

From: Ray Bellis <[email-masked]>
Date: Fri, 6 Sep 2013 08:29:51 +0000

On 5 Sep 2013, at 01:23, Vincent Chen <[email-masked]<mailto:[email-masked]>> wrote:

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

I don't like it at all.

The questions I raised about the "Bw" part of "maxPsdDbmPerBw" and the exact mechanism of how to encode multiple bandwidth PSDs are still unanswered.

It *appears* that "Bw" is supposed to be the delta between the current entry and the previous entry?  Not only does this result in a potential division-by-zero that has to be detected, it would seem that to encode the OFCOM/ETSI rules that require a PSD over 100 kHz would require an entry (or in fact a pair of entries) for *every single 100 kHz subchannel* within the band.

Also, I'm pretty certain that the OFCOM/ETSI model will actually result in channels that simply cannot be used. We haven't seen the DTT sample data yet but previous conversations have strongly suggested that in certain squares they will not permit any transmissions in certain channels.  This simple contiguous set of power vs frequency points cannot encode that.

Ray

---

From: Vincent Chen <[email-masked]>
Date: Fri, 6 Sep 2013 10:04:48 -0700

Ray,

Sorry for not providing the full example (which is in Section 6.4.2).

The Bw refers a bandwidth that surrounds the entire array. That is, each
Spectrum Profile is associated with a Bandwidth specification (e.g., 6MHz,
8MHz, 100kHz), allowing a regulator to provide different requirements for
different operating modes. There would be one complete profile for each
bandwidth.

A more complete example would be something like the following, where
"spectra" includes multiple spectrum profiles:

"spectra": [
  {
    "bandwidth": 6e6,
    "points": [
      { "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 }
    ]
  },
  {
    "bandwidth": 1e5,
    "points": [
      { "freqHz": 4.70e8, "maxPsdDbmPerBw": -74.58 },
      { "freqHz": 5.18e8, "maxPsdDbmPerBw": -74.58},
      { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 },
      { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 },
      { "freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 },
      { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 },
      { "freqHz": 5.30e8, "maxPsdDbmPerBw": -74.58 },
      { "freqHz": 6.98e8, "maxPsdDbmPerBw": -74.58 }
    ]
  }
]

(note that the example does not match any actual rule, it's just an example
of the encoding)

- The first set of values for maxPsdDbmPerBw represents max power (dBm)
over any 6MHz
- The first set of values for maxPsdDbmPerBw represents max power (dBm)
over any 100kHz

A device must satisfy both.

In this hypothetical example, a device may, for instance, operate 2 100kHz
sub-channels within [518MHz, 524HMz) at 27dBm, but not any more.
 - Each sub-channel meets the 100kHz spec
 - The sum of the two meets the 6MHz spec

Does that make more sense?

-vince

On Fri, Sep 6, 2013 at 1:29 AM, Ray Bellis <[email-masked]>wrote:

>
>  On 5 Sep 2013, at 01:23, Vincent Chen <[email-masked]> wrote:
>
>
>  - 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.
>
>  The questions I raised about the "Bw" part of "maxPsdDbmPerBw" and the
> exact mechanism of how to encode multiple bandwidth PSDs are still
> unanswered.
>
>  It *appears* that "Bw" is supposed to be the delta between the current
> entry and the previous entry?  Not only does this result in a potential
> division-by-zero that has to be detected, it would seem that to encode the
> OFCOM/ETSI rules that require a PSD over 100 kHz would require an entry (or
> in fact a pair of entries) for *every single 100 kHz subchannel* within the
> band.
>
>  Also, I'm pretty certain that the OFCOM/ETSI model will actually result
> in channels that simply cannot be used. We haven't seen the DTT sample data
> yet but previous conversations have strongly suggested that in certain
> squares they will not permit any transmissions in certain channels.  This
> simple contiguous set of power vs frequency points cannot encode that.
>
>  Ray
>
>
>
>

-- 
-vince

---

From: Ray Bellis <[email-masked]>
Date: Fri, 6 Sep 2013 18:31:07 +0000

> Sorry for not providing the full example (which is in Section 6.4.2).

Ah, that makes more sense - I couldn't find anything in the previous emails that   confirmed that this proposal only covered the inner part of the spectra structure.

My point about being able to represent discontinuities in the frequency range still appears to stand, however.

Kind regards

Ray

---

From: Vincent Chen <[email-masked]>
Date: Fri, 13 Sep 2013 09:00:24 -0700

Ray,

Sorry for the delay in response.

> range still appears to stand, however.

I see. Television channels do not occupy a contiguous range of frequencies.
In the US,

  - [54MHz, 72MHz]  Channel 2-4
  - [76MHz, 88MHz]  Channels 5-6
  - [174MHz, 216MHz] Channels 7-13
  - [470MHz, 698MHz]  Channels 14-51

So the response given by the database should not include any frequencies
not in the plan.

That means a "spectrum profile" should be encoded as a list of "array" of
(frequency, power) points.
 - Each array represents a "profile" for a contiguous range of frequencies
 - The range of frequencies within a list of profiles MUST be disjoint and
SHOULD be sorted
 - The entire set of frequency bands defined by the regulatory domain MUST
be represented by a single list of "profiles"
   (rather than split them across multiple lists)

That last point is to remove ambiguity and, thus, variations in database
implementation, to simplify logic on devices.

Example:

"spectra": [
  {
    "bandwidth": 6e6,
    "profiles": [
      [
        { "freqHz": 5.4e7, "maxPsdDbmPerBw": -56.8 },
        { "freqHz": 7.2e7, "maxPsdDbmPerBw": -56.8 },
      ],
      [
        { "freqHz": 7.6e7, "maxPsdDbmPerBw": -56.8 },
        { "freqHz": 8.8e7, "maxPsdDbmPerBw": -56.8 },
      ],
      [
        { "freqHz": 1.74e8, "maxPsdDbmPerBw": -56.8 },
        { "freqHz": 2.16e8, "maxPsdDbmPerBw": -56.8 },
      ],
      [
        { "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 }
      ]
    ]
  },
  {
    "bandwidth": 1e5,
    "profiles": [
      [
        { "freqHz": 5.4e7, "maxPsdDbmPerBw": -74.58 },
        { "freqHz": 7.2e7, "maxPsdDbmPerBw": -74.58 },
      ],
      [
        { "freqHz": 7.6e7, "maxPsdDbmPerBw": -74.58 },
        { "freqHz": 8.8e7, "maxPsdDbmPerBw": -74.58 },
      ],
      [
        { "freqHz": 1.74e8, "maxPsdDbmPerBw": -74.58 },
        { "freqHz": 2.16e8, "maxPsdDbmPerBw": -74.58 },
      ],
      [
        { "freqHz": 4.70e8, "maxPsdDbmPerBw": -74.58 },
        { "freqHz": 5.18e8, "maxPsdDbmPerBw": -74.58},
        { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 },
        { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 },
        { "freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 },
        { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 },
        { "freqHz": 5.30e8, "maxPsdDbmPerBw": -74.58 },
        { "freqHz": 6.98e8, "maxPsdDbmPerBw": -74.58 }
      ]
    ]
  }
]

Does that address your concern?

-- 
-vince

---

From: Peter Stanforth <[email-masked]>
Date: Fri, 13 Sep 2013 12:06:33 -0400

The US is not unique in having discontinuous bands, we have come across a mix of VHF and UHF channels in a number of countries.

From: Vincent Chen <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 13, 2013 12:00 PM
To: Ray Bellis <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] Encoding of spectrum profile

Ray,

I see. Television channels do not occupy a contiguous range of frequencies. In the US,

So the response given by the database should not include any frequencies not in the plan.

That means a "spectrum profile" should be encoded as a list of "array" of (frequency, power) points.
 - Each array represents a "profile" for a contiguous range of frequencies
 - The range of frequencies within a list of profiles MUST be disjoint and SHOULD be sorted
 - The entire set of frequency bands defined by the regulatory domain MUST be represented by a single list of "profiles"
   (rather than split them across multiple lists)

That last point is to remove ambiguity and, thus, variations in database implementation, to simplify logic on devices.

Example:

"spectra": [
  {
    "bandwidth": 6e6,
    "profiles": [
      [

--
-vince

---

From: Vincent Chen <[email-masked]>
Date: Fri, 13 Sep 2013 09:33:09 -0700

Peter,

Agreed. So it is important for the protocol to be able to represent
discontiguous bands. Thanks.

-vince

On Fri, Sep 13, 2013 at 9:06 AM, Peter Stanforth
<[email-masked]>wrote:

> The US is not unique in having discontinuous bands, we have come across a
> mix of VHF and UHF channels in a number of countries.
>
> From: Vincent Chen <[email-masked]>
> To: Ray Bellis <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
>

-- 
-vince

---

From: [email-masked]
Date: Sat, 14 Sep 2013 08:33:48 +0530

Hi,

Not just the spectrum is available in non-contiguous bands, but a whitespace
radio with higher bandwidth requirement may use non-contiguous spectrum
aggregation, and consume available spectrum across multiple bands too.

Thanks and Regards,

Sajeev

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Vincent Chen
Sent: Friday, September 13, 2013 10:03 PM
To: Peter Stanforth
Cc: [email-masked]
Subject: Re: [paws] Encoding of spectrum profile

Peter,

-vince

On Fri, Sep 13, 2013 at 9:06 AM, Peter Stanforth <[email-masked]>
wrote:

Ray, 

My point about being able to represent discontinuities in the frequency
range still appears to stand, however.

So the response given by the database should not include any frequencies not
in the plan.

Example:

"spectra": [

  {

    "bandwidth": 6e6,

    "profiles": [

      [

      ],

      [

      ],

      [

      ],

      [

      ]

    ]

  },

  {

    "bandwidth": 1e5,

    "profiles": [

      [

      ],

      [

      ],

      [

      ],

      [

      ]

    ]

  }

]

-- 
-vince 

-- 
-vince

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Sat, 14 Sep 2013 19:33:25 -0700

The Whitespace spectrum allocations I have been following in various 
regions are made of of non-contiguous collections of contiguous 
spectrum, as illustrated by the US situation for TVWS below: each TV 
channel is a contiguous chunk of spectrum 6MHz wide; TV channels are 
spread dis-contiguously across the spectrum. .

Multiple standards exist and others are under development to utilize 
whitespace allocations. In 802.11, mhe ultiple TV channels may be 
aggregated to one 802.11 channel; in 802.15 we do e opposite:  we divide 
a single TV channel into many physical channels.  In  the current 
drafts, we assume the database provides the boundaries of the TV channel 
(somehow) and the standard maps that to the PHY channels defined.  There 
is also a need to specify unavailability of a small part of a TV channel.

The regional regulations for allowable use,  in particular the methods 
for specifying  transmit signal energy limitations, vary greatly.   In 
the US the current TVWS is quite simple compared how power limits are 
specified in other bands.  As we see the whitespace concept catching on 
(and it seems to be), I expect we will see the variety of methods used 
in other subparts of Part 15 applied.  If the goal is to be able to get 
this information from the database so an implementation can be 
regulation agnostic, it may be wise to look at some of the methods 
likely to be applied when we move beyond "TVWS" into application of the 
whitespace management concept to other spectrum allocations.

In Part 15 we see emission limits expressed as total power in a 
specified bandwidth, peak measured in any xHz accross the entire signal 
or band, field strength (energy level measured at a specified distance)  
and several other methods.  In the more popular license exempt bands we 
have different methods applied, with different effective emissions 
limits, that are based on modulation type, modulation bandwidth 
(signalling rate), how the band is sub-divided into communcation 
channels (number of channels and occupied bandwidth of each), if the 
system employs frequency hopping, etc. We also see constraints such as 
minimum and maximum occupied bandwidth for a communications channel.

I don't know if there is much concern over data volume for database 
exchanges.  Specifying an approximation of a spectral mask point by 
point is possible, but may become quite a few points. There are a few 
standard models for approximating spectral shape which could be used to 
reduce the data volume, which may have value  in the long run.

A few thoughts I hope will help from a humble and hopeful future user of 
the protocol!

-Ben

On 9/13/2013 8:03 PM, [email-masked] wrote:
>
> Hi,
>
> Not just the spectrum is available in non-contiguous bands, but a 
> whitespace radio with higher bandwidth requirement may use 
> non-contiguous spectrum aggregation, and consume available spectrum 
> across multiple bands too.
>
> Thanks and Regards,
>
> Sajeev
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Vincent Chen
> *Sent:* Friday, September 13, 2013 10:03 PM
> *To:* Peter Stanforth
> *Cc:* [email-masked]
> *Subject:* Re: [paws] Encoding of spectrum profile
>
> Peter,
>
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> The US is not unique in having discontinuous bands, we have come 
> across a mix of VHF and UHF channels in a number of countries.
>
> *From: *Vincent Chen <[email-masked] <mailto:[email-masked]>>
> *Date: *Friday, September 13, 2013 12:00 PM
> *To: *Ray Bellis <[email-masked] 
> <mailto:[email-masked]>>
> *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
>
>
> *Subject: *Re: [paws] Encoding of spectrum profile
>
> Ray,
>
>     My point about being able to represent discontinuities in the
>     frequency range still appears to stand, however.
>
>  - The entire set of frequency bands defined by the regulatory domain 
> MUST be represented by a single list of "profiles"
>
> That last point is to remove ambiguity and, thus, variations in 
> database implementation, to simplify logic on devices.
>
> Example:
>
> "spectra": [
>
> {
>
>   "bandwidth": 6e6,
>
>   "profiles": [
>
>     [
>

---

From: Peter Stanforth <[email-masked]>
Date: Sun, 15 Sep 2013 08:45:13 -0400

The purpose of the database is to protect incumbent operations. How secondary users then access the spectrum is beyond the regulatory scope (though the way the FCC defined the way PSD is measured narrow channel use is effectively banned). So far all Regulators have defined protection in terms of 6 or 8 MHz channels, not partial channels. So unless we believe we can convince regulators to change their definition and protect partial channels (when used by PMSE for instance) the way it is defined is adequate.

I apologize for sounding like I am pouring cold water on your ideas but, although the Charter says "protocol for access White Space", there was a conscious decision made at the beginning to solve the problem for TVWS, thus avoiding scope creep and getting a standard out there.
While we have tried to remain flexible we really don't know how other bands, beyond a proposal by PCAST in the US, and a notion of LSA in the EU, will be managed so I would keep to the plan. We are already a year late from the original objective.
Peter S.

From: "Benjamin A. Rolfe" <[email-masked]<mailto:[email-masked]>>
Date: Saturday, September 14, 2013 10:33 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] Encoding of spectrum profile

The Whitespace spectrum allocations I have been following in various regions are made of of non-contiguous collections of contiguous spectrum, as illustrated by the US situation for TVWS below: each TV channel is a contiguous chunk of spectrum 6MHz wide; TV channels are spread dis-contiguously across the spectrum. .

Multiple standards exist and others are under development to utilize whitespace allocations. In 802.11, mhe ultiple TV channels may be aggregated to one 802.11 channel; in 802.15 we do e opposite:  we divide a single TV channel into many physical channels.  In  the current drafts, we assume the database provides the boundaries of the TV channel (somehow) and the standard maps that to the PHY channels defined.  There is also a need to specify unavailability of a small part of a TV channel.

The regional regulations for allowable use,  in particular the methods for specifying  transmit signal energy limitations, vary greatly.   In the US the current TVWS is quite simple compared how power limits are specified in other bands.  As we see the whitespace concept catching on (and it seems to be), I expect we will see the variety of methods used in other subparts of Part 15 applied.  If the goal is to be able to get this information from the database so an implementation can be regulation agnostic, it may be wise to look at some of the methods likely to be applied when we move beyond "TVWS" into application of the whitespace management concept to other spectrum allocations.

In Part 15 we see emission limits expressed as total power in a specified bandwidth, peak measured in any xHz accross the entire signal or band, field strength (energy level measured at a specified distance)  and several other methods.  In the more popular license exempt bands we have different methods applied, with different effective emissions limits, that are based on modulation type, modulation bandwidth (signalling rate), how the band is sub-divided into communcation channels (number of channels and occupied bandwidth of each), if the system employs frequency hopping, etc.  We also see constraints such as minimum and maximum occupied bandwidth for a communications channel.

I don't know if there is much concern over data volume for database exchanges.  Specifying an approximation of a spectral mask point by point is possible, but may become quite a few points. There are a few standard models for approximating spectral shape which could be used to reduce the data volume, which may have value  in the long run.

A few thoughts I hope will help from a humble and hopeful future user of the protocol!

-Ben

On 9/13/2013 8:03 PM, [email-masked]<mailto:[email-masked]> wrote:
Hi,

Not just the spectrum is available in non-contiguous bands, but a whitespace radio with higher bandwidth requirement may use non-contiguous spectrum aggregation, and consume available spectrum across multiple bands too.

Thanks and Regards,
Sajeev

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Vincent Chen
Sent: Friday, September 13, 2013 10:03 PM
To: Peter Stanforth
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] Encoding of spectrum profile

Peter,

Agreed. So it is important for the protocol to be able to represent discontiguous bands. Thanks.

-vince

On Fri, Sep 13, 2013 at 9:06 AM, Peter Stanforth <[email-masked]<mailto:[email-masked]>> wrote:
The US is not unique in having discontinuous bands, we have come across a mix of VHF and UHF channels in a number of countries.

Ray,

Example:

"spectra": [
  {
    "bandwidth": 6e6,
    "profiles": [
      [

--
-vince

--
-vince

_______________________________________________
paws mailing list
[email-masked]<mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/paws

---

From: Andy Lee <[email-masked]>
Date: Sun, 15 Sep 2013 10:34:49 -0700

In the FCC, there technically aren't any parts of the spectrum that are not
"in the plan".  Every frequency is governed by something under the FCC's Part
15 rules<http://www.ecfr.gov/cgi-bin/retrieveECFR?gp=&SID=3ad5847adc442ba7c9e0c9ed27f0c59c&n=47y1.0.1.1.16&r=PART&ty=HTML>.
 There are some underlying "baseline" or "default" emission rules, and then
there are some specific carve-outs or overrides that apply to specific
devices or sub-bands.  TV white space is defined as specialized overrides
within the context of the Part 15 rules (specifically, sections 15.701 thru
15.717<http://www.ecfr.gov/cgi-bin/retrieveECFR?gp=&SID=3ad5847adc442ba7c9e0c9ed27f0c59c&n=47y1.0.1.1.16&r=PART&ty=HTML#47:1.0.1.1.16.8>
).

In other words, sections 15.701 thru 15.717 can grant higher emissions
limits on some frequencies, and impose additional limits on others, but
anything else not specifically called out would fall to some other default
rule within the Part 15 rules (e.g., section
15.109<http://www.ecfr.gov/cgi-bin/retrieveECFR?gp=&SID=3ad5847adc442ba7c9e0c9ed27f0c59c&n=47y1.0.1.1.16&r=PART&ty=HTML#47:1.0.1.1.16.2.236.6>).
 Part 15 rules define the upper bound of what a device is allowed to
radiate.  Any device that exceeds these limits will fail the FCC
certification tests.  In addition to the hard limits defined by Part 15,
devices are encouraged to lower their emissions as much as possible, as a
general "politeness protocol".

For example, section
15.709<http://www.ecfr.gov/cgi-bin/retrieveECFR?gp=&SID=c66e2da386cac159cb62df35b2090f07&n=47y1.0.1.1.16&r=PART&ty=HTML#47:1.0.1.1.16.8.237.6>(a)(5)
talks about white space in-band emission limits and section 15.709(c)(1)
talks about emission limits on the first-adjacent channel to a TV
broadcast.  The rules are silent on what happens for second-adjacent
channels, and channels that are further out, so one should assume that the
the "default" rules then apply.

Another example is section 15.709(c)(4), where there are special emission
constraints around TV channel 37.  It gives specific power spectral density
limits for frequencies around channel 37 as illustrated in the following
ASCII diagram.  Field strength numbers have been converted to dBm values
for convenience.

   -63.19 dBm  --  +                          +
                     \                      /
                       \                  /
   -65.22 dBm  --        +--+        +--+
                            |        |
                            |        |
                      ch36  |  ch37  |  ch38
                            |        |
                            |        |
   -75.23 dBm  --           +--------+

                   |     |  |        |  |     |
                  602   607 608    614 615   620 MHz

This example also illustrates a case where the emission profile has a
non-zero slope for some frequency ranges (i.e., 602-607 and 615-620 MHz
have sloped psd profiles).

---

From: Ray Bellis <[email-masked]>
Date: Mon, 16 Sep 2013 09:06:04 +0000

On 13 Sep 2013, at 17:00, Vincent Chen <[email-masked]<mailto:[email-masked]>>
 wrote:

Example:

...

It does, although I still think the original #1 data model where each available frequency range was simply defined by (f1, f2, psd1, psd2) is much better.  It's also more consistent with the ETSI draft spec.

Using the #2 model of an array of (f, psd) points is only more efficient as an encoding mechanism in those few cases where non-zero PSD slopes do actually need to be encoded.  Any time there's a "step" jump in Psd you need just as much data to encode that jump using (f, psd) points as you would if you used (f1, f2, psd1, psd2).

Regarding splitting the lists in the way you propose, that's not just a question of what frequencies are "in the plan".  The current OFCOM consultation proposes (§5.93) "not to allow WSD operation in channel 38" (606 - 614 MHz) as that's used for nationwide PMSE.  Channel 38 is definitely "in the plan", but it's also a discontinuity.  Your proposed model would appear to require that we break our frequency table in two either side of channel 38, and ends up with a two dimensional array of arrays in the JSON encoding.

Using (f1, f2, p1, p2) allows the use of a single level list of values, with the only constraint being that frequency ranges not overlap.

Your example for the US plan then just becomes (omitting the 100 kHz bandwidth):

"spectra": [
  {
     "bandwidth": 6e6,
     "frequencyRanges": [
        {"startHz": 5.4e7, "stopHz", 7.2e7, "startPsd": -56.8, "stopPsd": -56.8},
        {"startHz": 7.6e7, "stopHz", 8.8e7, "startPsd": -56.8, "stopPsd": -56.8},
        {"startHz": 1.74e8, "stopHz", 2.16e8, "startPsd": -56.8, "stopPsd": -56.8},
        {"startHz": 4.70e8, "stopHz", 5.18e8, "startPsd": -56.8, "stopPsd": -56.8},
        {"startHz": 5.18e8, "stopHz", 5.24e8, "startPsd": 30.0, "stopPsd": 30.0},
        {"startHz": 5.24e8, "stopHz", 5.30e8, "startPsd": 36.0, "stopPsd": 36.0},
        {"startHz": 5.30e8, "stopHz", 5.30e8, "startPsd": -56.8, "stopPsd": -56.8}
     ]
  ]
]

This requires 28 data values, exactly the same as in your example.  It's also the smallest change necessary from the current spec in draft-ietf-paws-protocol-06 to support non-zero Psd slopes.  For encoding efficiency one could also specify that PSD just be either a single value or a pair [psd1, psd2] for those non-zero slope cases.

kind regards,

Ray

---

From: "Harasty, Daniel J" <[email-masked]>
Date: Mon, 16 Sep 2013 16:16:22 +0000

I very much agree with Ray's observations and resulting proposal.  In fact: this exact email was in draft form in my head...

I may have a few things to add - but first, I have one technical question first: what is the origin of the "-56.8" value for PSD that keeps cropping up in the examples to indicate "not available"?

Thanks,

Dan Harasty

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ray Bellis
Sent: Monday, September 16, 2013 5:06 AM
To: Vincent Chen
Cc: [email-masked]
Subject: Re: [paws] Encoding of spectrum profile

Example:

...

"spectra": [
  {
     "bandwidth": 6e6,
     "frequencyRanges": [

kind regards,

Ray

---

From: <[email-masked]>
Date: Mon, 16 Sep 2013 17:33:57 +0000

Ø  what is the origin of the "-56.8" value for PSD that keeps cropping up in the examples to indicate "not available"?
I thought this was clarified in http://www.ietf.org/mail-archive/web/paws/current/msg01615.html

-          gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Harasty, Daniel J
Sent: Monday, September 16, 2013 9:16 AM
To: Ray Bellis; Vincent Chen
Cc: [email-masked]
Subject: Re: [paws] Encoding of spectrum profile

Thanks,

Dan Harasty

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Ray Bellis
Sent: Monday, September 16, 2013 5:06 AM
To: Vincent Chen
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] Encoding of spectrum profile

Example:

...

"spectra": [
  {
     "bandwidth": 6e6,
     "frequencyRanges": [

kind regards,

Ray

---

From: Andy Lee <[email-masked]>
Date: Mon, 16 Sep 2013 11:11:58 -0700

That's correct, the example values come from the FCC rules under section
15.709(c)(1)

On Mon, Sep 16, 2013 at 10:33 AM, <[email-masked]> wrote:

>  **Ø  **what is the origin of the “-56.8” value for PSD that keeps
> cropping up in the examples to indicate “not available”?****
>
> I thought this was clarified in
> http://www.ietf.org/mail-archive/web/paws/current/msg01615.html****
>
> **-          **gabor****
>
> ** **
>
> Of *ext Harasty, Daniel J
> *Sent:* Monday, September 16, 2013 9:16 AM
> *To:* Ray Bellis; Vincent Chen
>
> *Cc:* [email-masked]
> *Subject:* Re: [paws] Encoding of spectrum profile****
>
>  ** **
>
> I very much agree with Ray’s observations and resulting proposal.  In
> fact: this exact email was in draft form in my head…****
>
> ** **
>
> I may have a few things to add – but first, I have one technical question
> first: what is the origin of the “-56.8” value for PSD that keeps cropping
> up in the examples to indicate “not available”?****
>
> ** **
>
> Thanks,****
>
> ** **
>
> Dan Harasty****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Ray Bellis
> *Sent:* Monday, September 16, 2013 5:06 AM
> *To:* Vincent Chen
> *Cc:* [email-masked]
> *Subject:* Re: [paws] Encoding of spectrum profile****
>
> ** **
>
> ** **
>
> On 13 Sep 2013, at 17:00, Vincent Chen <[email-masked]>****
>
>  wrote:****
>
> ** **
>
> I see. Television channels do not occupy a contiguous range of
> frequencies. In the US, ****
>
> ** **
>
>   - [54MHz, 72MHz]  Channel 2-4****
>
>   - [76MHz, 88MHz]  Channels 5-6****
>
>   - [174MHz, 216MHz] Channels 7-13****
>
>   - [470MHz, 698MHz]  Channels 14-51****
>
> ** **
>
> not in the plan.****
> (frequency, power) points.****
>
> SHOULD be sorted****
> be represented by a single list of "profiles"****
>
>    (rather than split them across multiple lists)****
>
> ** **
>
> implementation, to simplify logic on devices.****
>
> ** **
>
> Example:****
>
> ** **
>
> ...****
>
> ** **
>
> Does that address your concern?****
>
> ** **
>
> It does, although I still think the original #1 data model where each
> available frequency range was simply defined by (f1, f2, psd1, psd2) is
> much better.  It's also more consistent with the ETSI draft spec.****
>
> ** **
>
> Using the #2 model of an array of (f, psd) points is only more efficient
> as an encoding mechanism in those few cases where non-zero PSD slopes do
> actually need to be encoded.  Any time there's a "step" jump in Psd you
> need just as much data to encode that jump using (f, psd) points as you
> would if you used (f1, f2, psd1, psd2).****
>
> ** **
>
> Regarding splitting the lists in the way you propose, that's not just a
> question of what frequencies are "in the plan".  The current OFCOM
> consultation proposes (§5.93) "not to allow WSD operation in channel 38"
> (606 - 614 MHz) as that's used for nationwide PMSE.  Channel 38 is
> definitely "in the plan", but it's also a discontinuity.  Your proposed
> model would appear to require that we break our frequency table in two
> either side of channel 38, and ends up with a two dimensional array of
> arrays in the JSON encoding.****
>
> ** **
>
> Using (f1, f2, p1, p2) allows the use of a single level list of values,
> with the only constraint being that frequency ranges not overlap.****
>
> ** **
>
> Your example for the US plan then just becomes (omitting the 100 kHz
> bandwidth):****
>
> ** **
>
> "spectra": [****
>
>   {****
>
>      "bandwidth": 6e6,****
>
>      "frequencyRanges": [****
>
>         {"startHz": 5.4e7, "stopHz", 7.2e7, "startPsd": -56.8, "stopPsd":
> -56.8},****
>
>         {"startHz": 7.6e7, "stopHz", 8.8e7, "startPsd": -56.8, "stopPsd":
> -56.8},****
>
>         {"startHz": 1.74e8, "stopHz", 2.16e8, "startPsd": -56.8,
> "stopPsd": -56.8},****
>
>         {"startHz": 4.70e8, "stopHz", 5.18e8, "startPsd": -56.8,
> "stopPsd": -56.8},****
>
>         {"startHz": 5.18e8, "stopHz", 5.24e8, "startPsd": 30.0, "stopPsd":
> 30.0},****
>
>         {"startHz": 5.24e8, "stopHz", 5.30e8, "startPsd": 36.0, "stopPsd":
> 36.0},****
>
>         {"startHz": 5.30e8, "stopHz", 5.30e8, "startPsd": -56.8,
> "stopPsd": -56.8}****
>
>      ]****
>
>   ]****
>
> ]****
>
> ** **
>
> This requires 28 data values, exactly the same as in your example.  It's
> also the smallest change necessary from the current spec in
> draft-ietf-paws-protocol-06 to support non-zero Psd slopes.  For encoding
> efficiency one could also specify that PSD just be either a single value or
> a pair [psd1, psd2] for those non-zero slope cases.****
>
> ** **
>
> kind regards,****
>
> ** **
>
> Ray****
>
> ** **
>

---

From: Andy Lee <[email-masked]>
Date: Mon, 16 Sep 2013 11:18:33 -0700

>
> what is the origin of the “-56.8” value for PSD that keeps cropping up in
> the examples to indicate “not available”?

The FCC rules under 15.709(c)(1) require devices to have these adjacent
channel emission limits to protect TV broadcasts.  The "on" channels can be
16, 20, or 36 dBm EIRP, and the "off" channels have specific limits of
-52.8, -56.8, or -36.8 dBm EIRP on adjacent channels that are occupied by
TV.

On Mon, Sep 16, 2013 at 9:16 AM, Harasty, Daniel J
<[email-masked]>wrote:

> Of *Ray Bellis

---

From: Ray Bellis <[email-masked]>
Date: Mon, 16 Sep 2013 19:25:00 +0000

And adjacent channel leakage into otherwise permitted channels is a matter of regulatory device approval?

Ray

Sent from my iPhone

On 16 Sep 2013, at 19:18, "Andy Lee" <[email-masked]<mailto:[email-masked]>> wrote:

what is the origin of the “-56.8” value for PSD that keeps cropping up in the examples to indicate “not available”?

The FCC rules under 15.709(c)(1) require devices to have these adjacent channel emission limits to protect TV broadcasts.  The "on" channels can be 16, 20, or 36 dBm EIRP, and the "off" channels have specific limits of -52.8, -56.8, or -36.8 dBm EIRP on adjacent channels that are occupied by TV.

Andy Lee |       Google Inc. |   [email-masked]<mailto:[email-masked]> |   408-230-0522

On Mon, Sep 16, 2013 at 9:16 AM, Harasty, Daniel J <[email-masked]<mailto:[email-masked]>> wrote:
I very much agree with Ray’s observations and resulting proposal.  In fact: this exact email was in draft form in my head…

I may have a few things to add – but first, I have one technical question first: what is the origin of the “-56.8” value for PSD that keeps cropping up in the examples to indicate “not available”?

Thanks,

Dan Harasty

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ray Bellis
Sent: Monday, September 16, 2013 5:06 AM
To: Vincent Chen
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] Encoding of spectrum profile

Example:

...

"spectra": [
  {
     "bandwidth": 6e6,
     "frequencyRanges": [

kind regards,

Ray

---

From: Andy Lee <[email-masked]>
Date: Mon, 16 Sep 2013 13:12:16 -0700

What do you mean by "otherwise permitted channels"?

On Mon, Sep 16, 2013 at 12:25 PM, Ray Bellis <[email-masked]>wrote:

> On 16 Sep 2013, at 19:18, "Andy Lee" <[email-masked]> wrote:
>
>    what is the origin of the “-56.8” value for PSD that keeps cropping up
>> in the examples to indicate “not available”?
>
>
> On Mon, Sep 16, 2013 at 9:16 AM, Harasty, Daniel J <[email-masked]
> > wrote:
>
>>  - The range of frequencies within a list of profiles MUST be disjoint
>> and SHOULD be sorted****
>>
>> MUST be represented by a single list of "profiles"****
>>
>>         {"startHz": 5.18e8, "stopHz", 5.24e8, "startPsd": 30.0,
>> "stopPsd": 30.0},****
>>
>>         {"startHz": 5.24e8, "stopHz", 5.30e8, "startPsd": 36.0,
>> "stopPsd": 36.0},****
>>

---

From: Ray Bellis <[email-masked]>
Date: Mon, 16 Sep 2013 20:17:41 +0000

Per my previous message, I mean the case where the WSDB profile permits two adjacent channels to be used but the device only uses one of those.

Is the permitted adjacent channel leakage into the unused channel supposed to be specified in the PAWS spectrum profile or (as I would expect) by regulatory device requirements?

Ray

Sent from my iPhone

On 16 Sep 2013, at 21:12, "Andy Lee" <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Sep 16, 2013 at 12:25 PM, Ray Bellis <[email-masked]<mailto:[email-masked]>> wrote:
And adjacent channel leakage into otherwise permitted channels is a matter of regulatory device approval?

Ray

Sent from my iPhone

Thanks,

Dan Harasty

Example:

...

"spectra": [
  {
     "bandwidth": 6e6,
     "frequencyRanges": [

kind regards,

Ray

---

From: Andy Lee <[email-masked]>
Date: Mon, 16 Sep 2013 13:30:26 -0700

Under FCC rules, there is no specific requirement for how signal power is
distributed between multiple "on" channels.  The rules are designed to
protect the TV broadcasts, so as long as the WSD's out-of-band emissions
stay below the "off" channel power limits, the TV broadcasts will have the
protection they need.

On Mon, Sep 16, 2013 at 1:17 PM, Ray Bellis <[email-masked]>wrote:

>  Per my previous message, I mean the case where the WSDB profile permits
> two adjacent channels to be used but the device only uses one of those.
>
>  Is the permitted adjacent channel leakage into the unused channel
> supposed to be specified in the PAWS spectrum profile or (as I would
> expect) by regulatory device requirements?
>
>  Ray
>
> Sent from my iPhone
>
> On 16 Sep 2013, at 21:12, "Andy Lee" <[email-masked]> wrote:
>
>>    what is the origin of the “-56.8” value for PSD that keeps cropping
>>> up in the examples to indicate “not available”?
>>
>>
>> On Mon, Sep 16, 2013 at 9:16 AM, Harasty, Daniel J <
>>> I may have a few things to add – but first, I have one technical
>>> question first: what is the origin of the “-56.8” value for PSD that keeps
>>> That means a "spectrum profile" should be encoded as a list of "array"
>>> of (frequency, power) points.****
>>>
>>>  - Each array represents a "profile" for a contiguous range of
>>> frequencies****
>>>
>>>         {"startHz": 5.4e7, "stopHz", 7.2e7, "startPsd": -56.8,
>>> "stopPsd": -56.8},****
>>>
>>>         {"startHz": 7.6e7, "stopHz", 8.8e7, "startPsd": -56.8,
>>> "stopPsd": -56.8},****
>>>

---

From: Paul Lambert <[email-masked]>
Date: Mon, 16 Sep 2013 18:03:02 -0700

The proposal from Vince is a more rational structure and maintains the semantics of groups of bands.

There's no need to be throwing away information to save a few octets.

Paul

---

From: Ray Bellis <[email-masked]>
Date: Tue, 17 Sep 2013 08:12:05 +0000

On 17 Sep 2013, at 02:03, Paul Lambert <[email-masked]<mailto:[email-masked]>>
 wrote:

Can you clarify exactly what you mean by "groups of bands"?  Previous messages talked about how the US TV spectrum is indeed a set of four separate bands.  However the EuroDTT spectrum is not, it's a single contiguous band.

What information is being being thrown away?

This is not about saving octets.  (f1, f2, p1, p2) is at best the same as (f, p) and when the PSD slope is non-zero it's slightly less efficient.

I need the ability to represent a frequency discontinuity *within* a nominally contiguous band, ideally without having to treat that band as if it were actually two or more separate bands.

If your intention above is to allow the full information about the _channel plan_ to be represented that's OK, but that's _not_ the right semantics for representing a non-permitted channel in a contiguous band.

Ray

---

From: Paul Lambert <[email-masked]>
Date: Tue, 17 Sep 2013 01:33:57 -0700

If your intention above is to allow the full information about the _channel plan_ to be represented that's OK, but that's _not_ the right semantics for representing a non-permitted channel in a contiguous band.
Yes – I feel it's important to retain a definition and identification of the channels.  I may not be fully understanding your notion of a discontinuity within a band.  I'd typically assume that system need well defined channels within a band that each could be also given masks that might vary depending on adjacency considerations.

Paul

Ray

---

From: Ray Bellis <[email-masked]>
Date: Tue, 17 Sep 2013 09:07:59 +0000

On 17 Sep 2013, at 09:33, Paul Lambert <[email-masked]<mailto:[email-masked]>>
 wrote:

Yes – I feel it's important to retain a definition and identification of the channels.

Can you elaborate on why you feel that's important?  Why does a device "care" about the fact that the US TV band is split into four discrete bands - surely all that matters is the specific frequencies it's permitted to use?

I may not be fully understanding your notion of a discontinuity within a band.  I'd typically assume that system need well defined channels within a band that each could be also given masks that might vary depending on adjacency considerations.

In the OFCOM model channel 38 will not be available for _primary_ transmission, but AIUI a very small amount of adjacent channel leakage into it will be permitted.

The OFCOM / ETSI model doesn't need (or want) masks to be encoded within the messages for that channel,  they're implicit in the device approval requirements.

To further reduce the adjacent channel leakage the permitted power levels (for certain WSD emission classes) for primary transmissions in the adjacent channels are also reduced.

That frequency is therefore simply omitted from the list of available channels.  What I don't want to see is that break _within_ the band getting conflated with breaks _between_ bands.

Ray

---

From: <[email-masked]>
Date: Tue, 17 Sep 2013 22:13:53 +0000

Ray,
Could you elaborate on this point:

Ø  What I don't want to see is that break _within_ the band getting conflated with breaks _between_ bands.

This is the only issue which we do not have consensus and prevents the editor to submit an updated version of the draft.
We do seem to have consensus that the current encoding in the draft has to be updated, as with the current encoding it is not possible to specify the power levels for unavailable ranges.

What we do not have consensus on is on the options below:
  - Option 1: List of (startHz, startPower, stopHz, stopPower)
  - Option 2: Ordered list of (freqHz, power)

So far we have few people speaking for either of the options.
We need to agree on this asap and move forward, so please send a mail to the list and indicate whether you are ok with either option, or you feel strongly for one or the other.

-          gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Ray Bellis
Sent: Tuesday, September 17, 2013 2:08 AM
To: Paul Lambert
Cc: [email-masked]
Subject: Re: [paws] Encoding of spectrum profile

Yes - I feel it's important to retain a definition and identification of the channels.

Ray

---

From: Vincent Chen <[email-masked]>
Date: Tue, 17 Sep 2013 16:34:02 -0700

With slight modification to Option 2. Repeating both below:

- Option 1: List of (startHz, startPower, stopHz, stopPower)
- Option 2: Ordered list of list of (freqHz, power)
                    ^^^^^^^

I prefer Option 2, as described above.

-vince

On Tue, Sep 17, 2013 at 3:13 PM, <[email-masked]> wrote:

>  Ray,****
>
> Could you elaborate on this point:****
>
> **Ø  **What I don't want to see is that break _within_ the band getting
> conflated with breaks _between_ bands.****
>
> ** **
>
> This is the only issue which we do not have consensus and prevents the
> editor to submit an updated version of the draft.****
>
> We do seem to have consensus that the current encoding in the draft has to
> be updated, as with the current encoding it is not possible to specify the
> power levels for unavailable ranges.****
>
> ** **
>
> What we do not have consensus on is on the options below:****
>
> So far we have few people speaking for either of the options. ****
>
> We need to agree on this asap and move forward, so please send a mail to
> the list and indicate whether you are ok with either option, or you feel
> strongly for one or the other.****
>
> ** **
>
> **-          **gabor****
>
> ** **
>
> ** **
>
> Of *ext Ray Bellis
> *Sent:* Tuesday, September 17, 2013 2:08 AM
> *To:* Paul Lambert
>
> *Cc:* [email-masked]
> On 17 Sep 2013, at 09:33, Paul Lambert <[email-masked]>****
>
>  wrote:****
>
>
>
> ****
>
> Yes – I feel it's important to retain a definition and identification of
> the channels.****
>
> ** **
>
> Can you elaborate on why you feel that's important?  Why does a device
> "care" about the fact that the US TV band is split into four discrete bands
> - surely all that matters is the specific frequencies it's permitted to use?
> ****
>
>
>
> ****
>
> I may not be fully understanding your notion of a discontinuity within a
> band.  I'd typically assume that system need well defined channels within a
> band that each could be also given masks that might vary depending on
> adjacency considerations.  ****
>
> ** **
>
> In the OFCOM model channel 38 will not be available for _primary_
> transmission, but AIUI a very small amount of adjacent channel leakage into
> it will be permitted. ****
>
> ** **
>
> The OFCOM / ETSI model doesn't need (or want) masks to be encoded within
> the messages for that channel,  they're implicit in the device approval
> requirements.****
>
> ** **
>
> To further reduce the adjacent channel leakage the permitted power levels
> (for certain WSD emission classes) for primary transmissions in the
> adjacent channels are also reduced.****
>
> ** **
>
> That frequency is therefore simply omitted from the list of available
> channels.  What I don't want to see is that break _within_ the band getting
> conflated with breaks _between_ bands.****
>
> ** **
>
> Ray****
>
> ** **
>

-- 
-vince

---

From: Michael Head <[email-masked]>
Date: Tue, 17 Sep 2013 16:38:41 -0700

Option 2 makes sense to me because it conceptually organizes the spectrum
into a profile and clearly groups the response into banded segments.

On Tue, Sep 17, 2013 at 4:34 PM, Vincent Chen <[email-masked]> wrote:

>> We do seem to have consensus that the current encoding in the draft has
>> to be updated, as with the current encoding it is not possible to specify
>> the power levels for unavailable ranges.****
>>
>> ** **
>>

-- 
----------------------------------
Michael R Head <[email-masked]>
http://www.cs.binghamton.edu/~mike
+1-201-BLISTER

---

From: Ray Bellis <[email-masked]>
Date: Wed, 18 Sep 2013 09:12:59 +0000

On 17 Sep 2013, at 23:13, [email-masked]<mailto:[email-masked]> wrote:

Ray,
Could you elaborate on this point:
>  What I don't want to see is that break _within_ the band getting conflated with breaks _between_ bands.

Certain people appear to want the entire UHF channel plan encoded in the PAWS response, using very low PSD values to represent permitted leakage into "unavailable channels".

IMHO, this is a very US/FCC-centric model.

In the ETSI model, each available channel is _explicitly_ listed, with a low and high frequency.  "Unavailable channels" are omitted, and there's no concept of needing to describe the channel plan.  Devices just do what they're told, and adjacent channel leakage into otherwise unusable channels is controlled by device approval regulations.

Option #2 _could_ be used to represent the ETSI model, but doing so changes the semantics from representing the channel plan to being a workaround to get around the inability of option #2 to explicitly specify "unavailable channels" without resorting to magic values.

Strongly for #1, of course :)

I would also be happy with a variant of #1 where the profile is still presented as a list-of-lists to support representing a US-style non-contiguous channel plan, but which still permits frequency ranges to be omitted within each contiguous band).

Ray