Subject: Re: [paws] Spectrum encoding discussion

From: <[email-masked]>
Date: Wed, 2 Oct 2013 18:17:00 +0000

The list went suddenly very silent. Is that an indication that everyone is OK with Vince's proposal below or did we just become tired of arguing?
We need to make progress, thus I ask folks who *have* problems, objections to Vince's proposal to speak up. If we hear no comments/objections on the list for a few days, then I'll assume we have consensus on this encoding.

This encoding uses the encoding we referred to as 'option2', with the addition of "frequencyRanges".
I'd like to hear especially from Ray and others who objected initially to option2 for its inability to explicitly specify unavailable channels. Is this workaround good enough?

-          Gabor

From: ext Vincent Chen [mailto:[email-masked]]
Sent: Thursday, September 26, 2013 8:29 PM
To: Stine, John A.
Cc: Bajko Gabor (Nokia-CIC/SiliconValley); [email-masked]; [email-masked]; [email-masked]
Subject: Re: [paws] Spectrum encoding discussion

Let me try that example again....missing a nested list segments.

Features
*  Explicit indication of authoritative time ranges and frequency ranges associated with the response
*  Within a spectrum list, missing frequencies now can be interpreted unambiguously as unavailable without magic values
*  If there are gaps in time intervals, it also may be interpreted unambiguously as no available frequencies
*  Still allows the protocol to express of full mask where allowed
Example:

{
  "rulesetInfo": { ... },
  "timeRange": [ "2013-10-01T00:00:00Z", "2013-10-03T00:00:00Z" ],
  "frequencyRanges": [
    [5.4e7, 7.2e7],   // channels 2-4
    [7.6e7, 8.8e7],   // channels 5-6
    [1.74e8, 2.16e8], // channels 7-13
    [4.70e8, 6.98e8], // channels 14-51
  ],
  "spectrumSchedules": [
    {
      "time": [ "2013-10-01T00:00:00Z", "2013-10-01T05:00:00Z" ],
      "spectra" [
       {
         "psdBandwidthHz": 6e6,
         "segments": [
           [
            { "freqHz": 4.70e8, "maxPsdDbmPerBw": 30.0 },  // channel 14
            { "freqHz": 4.76e8, "maxPsdDbmPerBw": 30.0 }
           ],
           [
            { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },  // channel 22
            { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },
            { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 },  // channel 23
            { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }
           ]
         ]
       },
       {
         "psdBandwidthHz": 1e5,
         "segments": [
           [
            { "freqHz": 4.70e8, "maxPsdDbmPerBw": 27.0 },  // channel 14
            { "freqHz": 4.76e8, "maxPsdDbmPerBw": 27.0 }
           ],
           [
            { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 },  // channel 22
            { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 },
            { "freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 },  // channel 23
            { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 }
           ]
         ]
       }
      ]
    },
    {
      "time": [ "2013-10-01T05:00:00Z", "2013-10-03T00:00:00Z" ],
      ...
    },
    ...
  ],
  ...
}

On Thu, Sep 26, 2013 at 5:36 PM, Vincent Chen <[email-masked]<mailto:[email-masked]>> wrote:
John,

Thanks for your input. It aligns nicely with Andy's suggestion of specifying "authoritative bands" separately. Taking your suggestion of also expressing "authoritative time range", we could have an encoding example like the following:

{
  "rulesetInfo": { ... },
  "timeRange": [ "2013-10-01T00:00:00Z", "2013-10-03T00:00:00Z" ],
  "frequencyRanges": [
    [5.4e7, 7.2e7],   // channels 2-4
    [7.6e7, 8.8e7],   // channels 5-6
    [1.74e8, 2.16e8], // channels 7-13
    [4.70e8, 6.98e8], // channels 14-51
  ],
  "spectrumSchedules": [
    {
      "time": [ "2013-10-01T00:00:00Z", "2013-10-01T05:00:00Z" ],
      "spectra" [
       {
         "psdBandwidthHz": 6e6,
         [
          { "freqHz": 4.70e8, "maxPsdDbmPerBw": 30.0 },  // channel 14
          { "freqHz": 4.76e8, "maxPsdDbmPerBw": 30.0 },
          { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },  // channel 22
          { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },
          { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 },  // channel 23
          { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }
         ]
       },
       {
         "psdBandwidthHz": 1e5,
         [
          { "freqHz": 4.70e8, "maxPsdDbmPerBw": 27.0 },  // channel 14
          { "freqHz": 4.76e8, "maxPsdDbmPerBw": 27.0 },
          { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 },  // channel 22
          { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 },
          { "freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 },  // channel 23
          { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 }
         ]
       }
      ]
    },
    {
      "time": [ "2013-10-01T05:00:00Z", "2013-10-03T00:00:00Z" ],
      ...
    },
    ...
  ],
  ...
}

Features

  *   Explicit indication of authoritative time ranges and frequency ranges associated with the response
  *   Within a spectrum list, missing frequencies now can be interpreted unambiguously as unavailable without magic values
  *   If there are gaps in time intervals, it also may be interpreted unambiguously as no available frequencies
  *   Still allows the protocol to express of full mask where allowed
Thoughts?

-vince

On Thu, Sep 26, 2013 at 3:14 AM, Stine, John A. <[email-masked]<mailto:[email-masked]>> wrote:
For what it is worth I have been working on methods to model spectrum use that can be used to give guidance to radios. (We have just started to standardize these methods in IEEE 1900.5.2.)  We have two different kinds of guidance, permissive and restrictive.  They are sent in separate lists.  The permissive (aka authorization) list identifies channels a device or system can operate and if combined with a restrictive (aka constraint) list then so long as the user does not violate a listed restriction.  Each of these lists use spectrum and time at two levels.  The top level indicates the band and time period the list is comprehensive.  The second level indicates the particular channels and time periods of availability or restriction.  I would imagine that TVWS would only need the authorization list.  Future applications where spectrum owners add spectrum to the database and coexistence is managed will require both.

John

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, September 25, 2013 6:56 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

Subject: Re: [paws] Spectrum encoding discussion

Andy,

This option (e) proposal sounds like you may want to encode two things which could be separated; the available channels, and the authoritative bands.
We could leave the available spectrum req/resp unchanged, and eg have a separate req/resp for the authoritative bands.
And we could also encode the power leakage limits eg inside the ruleset info, so that devices would not necessarily need to be hard-coded with those, to satisfy everyone.
Could this be an agreeable way forward?

-          Gabor

From: ext Andy Lee [mailto:[email-masked]]
Sent: Wednesday, September 25, 2013 1:57 PM
To: Peter Stanforth
Cc: Paul Lambert; Vincent Chen; Bajko Gabor (Nokia-CIC/SiliconValley); [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] Spectrum encoding discussion

Hi Peter,

I can't imagine a Regulator allowing a database operator to manipulate the unintentional interference in adjacent channels. If it did why stop there? Why couldn't the database manipulate co-channel interference to nearby protected entities?

The recent discussions have been about data encoding and nothing more.  The premise is that IF there is some information the database wants to communicate to the white space device, HOW is that data encoded into the message.

As a case in point, section 15.709(c)(1) of the rules clearly defines what the "off" channel power limits must be.  The rules originally called for a "relative" OOB emission limit, but after some industry discussion, the FCC settled on these "absolute" OOB emission limits instead.  The values are clearly defined, but its not clear whether a database would want to communicate these parameters to the device or not.

On one hand, the database can assume that the device has these values hard-coded into its firmware and therefore does not need to send that information over PAWS.

On the other hand, these power levels are part of the TVWS rules and perhaps is something that the database should communicate to the WSD.  There are potentially beneficial things that a WSD could do with that information if it was provided at run-time (e.g., for future-proofing the device, or choosing operating channels more intelligently).

PAWS does not need to address WHY a particular parameter should or should not be sent over the protocol.  There are many regulatory, business, or technological reasons why these choices might change, and those decisions are beyond the scope of the protocol itself.

However, PAWS can and should address HOW data gets encoded IF a device or database decides to send it.  i.e.,

IF you want to encode [X], then you SHALL use [encoding X]
IF you want to encode [Y], then you SHALL use [encoding Y]
etc.

I can identify at least three distinct concepts that have been discussed so far, which I would categorize as follows:
*         (i) Explicit "on", Implicit "off"
o    Anything not explicitly specified as "on" would implicitly be treated as "off"
o    The recipient must have apriori knowledge about how to comply with the "off" channel, "special" channel (e.g., channel 37), and "band-edge" protection ratios
o    There is no distinction between "off" channels, "special" channels, and "band-edge" constraints in the message itself
o    This requires a way to encode gaps or discontinuities in the spectrum profile
o    This is equivalent to Gabor's option (a)

*         (ii) Explicit "on", Explicit "off" with no power level given
o    Every channel would be either explicitly "on" or explicitly "off"
o    Any frequency blocks that are not explicitly "on" or explicitly "off" are considered to be "out-of-scope" for the current database or ruleset, and this implicitly gives the "band-edge" boundaries
o    The recipient must have apriori knowledge about how to comply with the "off" channel, "special" channel, and "band-edge" protection ratios
o    The recipient can infer from the message when to apply "off" channel constraints and when to apply "band-edge" constraints
o    This requires a way to encode gaps or discontinuities in the spectrum profile AND requires a way to encode explicit "off" channels with no specified power value
o    This is equivalent to Gabor's options (c) and (d)

*         (iii) Explicit "on", Explicit "off" with power level given
o    Every channel would be either explicitly "on" or explicitly "off"
o    Any frequency blocks that are not explicitly "on" or explicitly "off" are considered to be "out-of-scope" for the current database or ruleset, and this implicitly gives the "band-edge" boundaries
o    The "off" channel, "special" channel, and "band-edge" protection ratios are explicitly provided in the message, and a device has the option of either using that information or ignoring it (default back to apriori knowledge of the protection ratios)
o    This requires a way to encode gaps or discontinuities in the spectrum profile
o    This is equivalent to Gabor's option (b)

I think all three types of encoding have their uses, and PAWS should probably allow all three possibilities.

It looks like all three encoding types need a way to express gaps or discontinuities in the spectrum profile.  I think the latest proposal from Vince, using a list of lists, addresses this problem nicely.

It also looks like encodings for (i) and (iii) are logically equivalent, with the only real difference being that encoding (iii) includes more data points in the spectrum profile than encoding (i).  I don't think anything else needs to be added to the spec to support both of these encodings.

That leaves us with encoding (ii), where we need to add something new to the spec to encode explicitly "off" frequency blocks that have no power level given.  For this, we have two proposals:

Option (c): Use -inf as the power value in a spectrum profile element
Option (d): Leave the power value blank in a spectrum profile element

I'd suggest maybe considering yet another proposal:

Option (e): Use normal encoding (i) for explicit "on" channels, and then have a separate list of frequency start/stop pairs indicating the authoritative bands for which the database operates.  Anything that is inside the authoritative bands but not in an explicitly "on" chunk is effectively saying it's explicitly "off".  Anything outside of the list of authoritative bands is considered "out-of-scope" for the database and this essentially lists the "band-edge" boundaries.

Best regards,

Andy Lee |

 Google Inc. |

 [email-masked]<mailto:[email-masked]> |

 408-230-0522<tel:408-230-0522>

On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth <[email-masked]<mailto:[email-masked]>> wrote:
 Lowering the power to meet the mask is the easy way you get a radio certified - thus permission to operate. How is that anything to do with the database - which is simply managing Regulator policy?
The ruleset is going to tell you what masks and other operating parameters are acceptable within a regulatory domain. I can't imagine a Regulator allowing a database operator to manipulate the unintentional interference in adjacent channels. If it did why stop there? Why couldn't the database manipulate co-channel interference to nearby protected entities?
I thought we had a fairly elegant and simple solution. The ruleset defines the box the device can operate in and the database provides a specific set of permitted channels/frequencies within that box based on the location, time, and type of device making the request. All with respect to the specific list of entities the database has been told to protect at that location at that time.

One final comment and then I will rest my case. I have had conversations with several Regulators about this recently, and they do not like any notion that the database is "thinking" about the answer.
In every case they have said something along the lines of "if the database does not explicitly give a device permission to use a channel the device is not allowed to use it".
In every case they have gone somewhat further stating that if the database operation goes beyond this simple approach they think it highly unlikely that they will get cooperation from incumbents. If you don't believe me - go ask them!
Which brings me back to my soap box. We want to get PAWS done so we can enable white space. In my humble opinion, the more time we spend pontificating and the more complex we make it we are likely to achieve the opposite.
Peter S.

From: Paul Lambert <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 24, 2013 2:48 PM
To: Don Joslyn <[email-masked]<mailto:[email-masked]>>, Vincent Chen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Subject: Re: [paws] Spectrum encoding discussion

In line below ... speaking strongly in favor of "b"

Gabor,

I agree on possible renaming, if we want to specify unavailable channels.

Please see comments inline.

On Mon, Sep 23, 2013 at 12:56 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Vince,
This proposal of yours below could potentially become very confusing. The message itself is named Available Spectrum Request, and you propose the Available Spectrum Response to include a bunch of channels with unspecified power levels, which are btw, not available channels.
 So far, we have 4 proposed ways to indicate unavailable channels:

a)      Not listing it, implicit unavailability
This has the drawback of not distinguishing between being silent about a channel that is within the database's purview (channel off), and being silent about a channel that is outside the database's purview (out of scope for given ruleset).

[DJ - Why should the database care about channels that are outside the scope of the ruleset specified by the radio? For example, if the specified ruleset is FCC-related, then why would I need to include Ofcom-related channels in the response? Am I missing something?]

The rules have strict adjacent channel requirements.  Meeting the spectral mask for the adjacent channels  is one of the hardest parts for fielding real equipment.  If the rules allow relative measurement of the adjacent channel energy, you can simply lower your transmit power to the point that you can meet the adjacent requirements.

For a general White Spaces solution - it is critical to have knowledge for the full spectrum mask.  The full spectrum mask includes adjacent non-allowed channels.

RF channel usage are NOT a binary on/off or a simple transmit level.  The mask has a specific contour that extends beyond the "allowed" channel.  Transmitters will always send energy in more than the allowed channel!

Paul

b)      List unavailable channels and specify the power limit, eg -56dbm
Since the protocol should stand on its own, independent of any particular regulatory rule, do we really want to rule this out? In our interpretations of the FCC rules, for example, a Database is not prevented from doing this.

[DJ - I'm still in favor of just using the implicit unavailability method described above in a). What value is there in providing a power level for an unavailable channel? If I'm the radio, I can't use the channel, and I'm not going to intentionally transmit in that channel. This comment also applies to c) and d).]

c)       List unavailable channels and specify -inf as power limit

"-Inf" is not really workable, because JSON does not allow Infinity or NaNs (http://tools.ietf.org/html/rfc4627), hence the d) proposal.

d)      List unavailable channels and do not specify any power limit

So far, we have majority in favour of a), few people who could live or prefer c) and sort of consensus to strike out option b) from the list above.

We'll wait for more input on the list before declaring rough consensus for the question above; then we'll go back to the original question on whether the encoding of spectrum profile should be option 1 or option 2.

p.s. It looks to me, that if we want to specify unavailable channels, we may need to modify the names of the paws messages to 'Spectrum schedule' or sg along these lines.

-          Gabor

_______________________________________________
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

--
-vince

---

From: Peter Stanforth <[email-masked]>
Date: Thu, 3 Oct 2013 11:56:25 -0400

Personally speaking, I got tired of arguing and had more important things to do.
It does not appear that "everyone" is ok with the proposal because the number of people involved in the discussion is such a small subset of the group.
My primary concern is the delay in the process that is being created by what appears to be feature creep relative to the charter/requirements.
I am comfortable that I can support Ofcom, FCC, and other TVWS regulation that I am aware of with the channel information described in the current published draft (v6).
There were so many examples ricocheting around I did not realize this was the proposal on the table so I have not considered it enough to decide what my opinion is. So as you asked, though I  am somewhat confused by what this proposal means , I will try to review this and respond in context.
Peter S.

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 2, 2013 2:17 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Peter Stanforth <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [paws] Spectrum encoding discussion

The list went suddenly very silent. Is that an indication that everyone is OK with Vince’s proposal below or did we just become tired of arguing?
We need to make progress, thus I ask folks who *have* problems, objections to Vince’s proposal to speak up. If we hear no comments/objections on the list for a few days, then I’ll assume we have consensus on this encoding.

This encoding uses the encoding we referred to as ‘option2’, with the addition of “frequencyRanges”.
I’d like to hear especially from Ray and others who objected initially to option2 for its inability to explicitly specify unavailable channels. Is this workaround good enough?

-          Gabor

From: ext Vincent Chen [mailto:[email-masked]]
Sent: Thursday, September 26, 2013 8:29 PM
To: Stine, John A.
Cc: Bajko Gabor (Nokia-CIC/SiliconValley); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] Spectrum encoding discussion

Features
·  Explicit indication of authoritative time ranges and frequency ranges associated with the response
·  Within a spectrum list, missing frequencies now can be interpreted unambiguously as unavailable without magic values
·  If there are gaps in time intervals, it also may be interpreted unambiguously as no available frequencies
·  Still allows the protocol to express of full mask where allowed
Example:

{
  "rulesetInfo": { ... },

{
  "rulesetInfo": { ... },

Features

-vince

John

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, September 25, 2013 6:56 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

Andy,

-          Gabor

Hi Peter,

·         (i) Explicit "on", Implicit "off"

·         (ii) Explicit "on", Explicit "off" with no power level given

·         (iii) Explicit "on", Explicit "off" with power level given

Best regards,

Andy Lee |

 Google Inc. |

On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth <[email-masked]<mailto:[email-masked]>> wrote:
 Lowering the power to meet the mask is the easy way you get a radio certified – thus permission to operate. How is that anything to do with the database - which is simply managing Regulator policy?
The ruleset is going to tell you what masks and other operating parameters are acceptable within a regulatory domain. I can't imagine a Regulator allowing a database operator to manipulate the unintentional interference in adjacent channels. If it did why stop there? Why couldn't the database manipulate co-channel interference to nearby protected entities?
I thought we had a fairly elegant and simple solution. The ruleset defines the box the device can operate in and the database provides a specific set of permitted channels/frequencies within that box based on the location, time, and type of device making the request. All with respect to the specific list of entities the database has been told to protect at that location at that time.

One final comment and then I will rest my case. I have had conversations with several Regulators about this recently, and they do not like any notion that the database is "thinking" about the answer.
In every case they have said something along the lines of "if the database does not explicitly give a device permission to use a channel the device is not allowed to use it".
In every case they have gone somewhat further stating that if the database operation goes beyond this simple approach they think it highly unlikely that they will get cooperation from incumbents. If you don't believe me – go ask them!
Which brings me back to my soap box. We want to get PAWS done so we can enable white space. In my humble opinion, the more time we spend pontificating and the more complex we make it we are likely to achieve the opposite.
Peter S.

In line below … speaking strongly in favor of "b"

Gabor,

[DJ – Why should the database care about channels that are outside the scope of the ruleset specified by the radio? For example, if the specified ruleset is FCC-related, then why would I need to include Ofcom-related channels in the response? Am I missing something?]

For a general White Spaces solution – it is critical to have knowledge for the full spectrum mask.  The full spectrum mask includes adjacent non-allowed channels.

Paul

[DJ – I’m still in favor of just using the implicit unavailability method described above in a). What value is there in providing a power level for an unavailable channel? If I’m the radio, I can’t use the channel, and I’m not going to intentionally transmit in that channel. This comment also applies to c) and d).]

c)       List unavailable channels and specify –inf as power limit

We’ll wait for more input on the list before declaring rough consensus for the question above; then we’ll go back to the original question on whether the encoding of spectrum profile should be option 1 or option 2.

p.s. It looks to me, that if we want to specify unavailable channels, we may need to modify the names of the paws messages to ‘Spectrum schedule’ or sg along these lines.

-          Gabor

--
-vince

--
-vince

---

From: Don Joslyn <[email-masked]>
Date: Thu, 3 Oct 2013 13:48:45 -0400

Vince,

I have a couple of questions, please see inline below...

Thanks,
Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of Vincent Chen
Sent: Thursday, September 26, 2013 11:29 PM
To: Stine, John A.
Cc: [email-masked]
Subject: Re: [paws] Spectrum encoding discussion

Features
*  Explicit indication of authoritative time ranges and frequency ranges associated with the response
What is "authoritative time range" and where does the value come from or how is the value calculated?
*  Within a spectrum list, missing frequencies now can be interpreted unambiguously as unavailable without magic values
I agree, but I still think that any radio vendor writing code for a specific ruleset would know that any channels not listed are simply not available.
*  If there are gaps in time intervals, it also may be interpreted unambiguously as no available frequencies
Is this statement true only for the timeRange specified?
*  Still allows the protocol to express of full mask where allowed
How do we express a full mask in the protocol?
The following questions are in reference to the example provided below:
If timeRange and frequencyRanges are different between multiple rulesetIds supported within the domain, do we then need to include multiple rulesetInfo elements to contain the unique values of timeRange and frequencyRanges defined for each rulesetId?
What is the purpose of "segments"? Why is this an array of arrays, instead of a single array?
In the example, why is channel 14 in a separate segment from channels 22 and 23? What does this tell the radio?
Example:

{
  "rulesetInfo": { ... },

{
  "rulesetInfo": { ... },

Features

-vince

John

Andy,

-          Gabor

Hi Peter,

Best regards,

Andy Lee |

 Google Inc. |

Gabor,

Paul

-          Gabor

--
-vince

--
-vince

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Thu, 3 Oct 2013 12:22:02 -0700

More questions and an answer in line...
On 10/3/2013 10:48 AM, Don Joslyn wrote:
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Vincent Chen
> *Sent:* Thursday, September 26, 2013 11:29 PM
> *To:* Stine, John A.
> *Cc:* [email-masked]
> *Subject:* Re: [paws] Spectrum encoding discussion
>
> ·Explicit indication of authoritative time ranges and frequency ranges 
> associated with the response
>
> ·Within a spectrum list, missing frequencies now can be interpreted 
> unambiguously as unavailable without magic values
>
> I agree, but I still think that any radio vendor writing code for a 
> specific ruleset would know that any channels not listed are simply 
> not available.
>
I am not even sure why the discussion of showing "unavailable" came up, 
but I can guess that it may be due to some language in one of the 
proposed regulations (ETSI or OFCOM ?) that implies a "push" model for 
indicating that a channel is no longer available. Maybe this started as 
an discussion on how to satisfy that requirement?

> ·If there are gaps in time intervals, it also may be interpreted 
> unambiguously as no available frequencies
>
> Is this statement true only for the /timeRange/ specified?
>
> ·Still allows the protocol to express of full mask where allowed
>
> How do we express a /full mask/ in the protocol?
>
I don't know what is  meant by a "full mask".  If the intention is to 
describe emission limits so that a WS implementation can be adaptable to 
different regions and changes in regional regulations over time, this 
representation does not allow the full story.  For an FCC compliant TVBD 
there are limits on PSD (BTW it appears from this example that "Psd" 
means maximum TX power and not the PSD limit n the FCC regulations) 
which vary based on device category and usage, there are max power in 
the TV channel limits that depend on device category and what is going 
on in adjacent TV channels, and other limits that require you examine 
other sections of the regulations such as 15.209 to understand (which 
specifies adjacent channel field strength limits for example).  I don't 
seen how those other values are represented in this format - for example 
how would we encode " 200 microvolts/meter electromagnetic field 
strength measured in 120 kHz bandwidth at a distance of 3 meters s from 
the transmitter" which is a requirement US TVBDs must meet for emissions 
outside the channel of use.

So I am back to the question I was asking - what is the intended purpose 
of specifying a "mask"?

> If /timeRange/ and /frequencyRanges/ are different between multiple 
> rulesetIds supported within the domain, do we then need to include 
> multiple rulesetInfo elements to contain the unique values of 
> /timeRange/ and /frequencyRanges/ defined for each rulesetId?
>
> In the example, why is channel 14 in a separate segment from channels 
> 22 and 23? What does this tell the radio?
>
> Example:
>
> {
>
>   "rulesetInfo": { ... },
>
> Thanks for your input. It aligns nicely with Andy's suggestion of 
> specifying "authoritative bands" separately. Taking your suggestion of 
> also expressing "authoritative time range", we could have an encoding 
> example like the following:
>
> {
>
>   "rulesetInfo": { ... },
>
>   * Within a spectrum list, missing frequencies now can be interpreted
>     unambiguously as unavailable without magic values
>   * If there are gaps in time intervals, it also may be interpreted
>     unambiguously as no available frequencies
> For what it is worth I have been working on methods to model spectrum 
> use that can be used to give guidance to radios. (We have just started 
> to standardize these methods in IEEE 1900.5.2.)  We have two different 
> kinds of guidance, permissive and restrictive. They are sent in 
> separate lists.  The permissive (aka authorization) list identifies 
> channels a device or system can operate and if combined with a 
> restrictive (aka constraint) list then so long as the user does not 
> violate a listed restriction. Each of these lists use spectrum and 
> time at two levels.  The top level indicates the band and time period 
> the list is comprehensive.  The second level indicates the particular 
> channels and time periods of availability or restriction.  I would 
> imagine that TVWS would only need the authorization list.  Future 
> applications where spectrum owners add spectrum to the database and 
> coexistence is managed will require both.
>
> John
>
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked] <mailto:[email-masked]>] *On 
> Behalf Of [email-masked] <mailto:[email-masked]>
> *Sent:* Wednesday, September 25, 2013 6:56 PM
> *To:* [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
>
>
> *Subject:* Re: [paws] Spectrum encoding discussion
>
> Andy,
>
> This option (e) proposal sounds like you may want to encode two things 
> which could be separated; the available channels, and the 
> authoritative bands.
>
> We could leave the available spectrum req/resp unchanged, and eg have 
> a separate req/resp for the authoritative bands.
>
> And we could also encode the power leakage limits eg inside the 
> ruleset info, so that devices would not necessarily need to be 
> hard-coded with those, to satisfy everyone.
>
> -Gabor
> *From:*ext Andy Lee [mailto:[email-masked]]
> *Sent:* Wednesday, September 25, 2013 1:57 PM
> *To:* Peter Stanforth
> *Cc:* Paul Lambert; Vincent Chen; Bajko Gabor 
> (Nokia-CIC/SiliconValley); [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [paws] Spectrum encoding discussion
>
> Hi Peter,
>
>     I can't imagine a Regulator allowing a database operator to
>     manipulate the unintentional interference in adjacent channels. If
>     it did why stop there? Why couldn't the database manipulate
>     co-channel interference to nearby protected entities?
>
> The recent discussions have been about data encoding and nothing more. 
>  The premise is that *IF* there is some information the database wants 
> to communicate to the white space device, *HOW* is that data encoded 
> into the message.
>
> As a case in point, section 15.709(c)(1) of the rules clearly defines 
> what the "off" channel power limits must be.  The rules originally 
> called for a "relative" OOB emission limit, but after some industry 
> discussion, the FCC settled on these "absolute" OOB emission limits 
> instead.  The values are clearly defined, but its not clear whether a 
> database would want to communicate these parameters to the device or not.
>
> On one hand, the database can assume that the device has these values 
> hard-coded into its firmware and therefore does not need to send that 
> information over PAWS.
>
> On the other hand, these power levels are part of the TVWS rules and 
> perhaps is something that the database should communicate to the WSD. 
>  There are potentially beneficial things that a WSD could do with that 
> information if it was provided at run-time (e.g., for future-proofing 
> the device, or choosing operating channels more intelligently).
>
> *PAWS does not need to address WHY a particular parameter should or 
> should not be sent over the protocol.*  There are many regulatory, 
> business, or technological reasons why these choices might change, and 
> those decisions are beyond the scope of the protocol itself.
>
> However, *PAWS can and should address HOW data gets encoded IF a 
> device or database decides to send it.*  i.e.,
>
> I can identify at least three distinct concepts that have been 
> discussed so far, which I would categorize as follows:
>
> ·(i) Explicit "on", Implicit "off"
>
> oAnything not explicitly specified as "on" would implicitly be treated 
> as "off"
>
> oThe recipient must have apriori knowledge about how to comply with 
> the "off" channel, "special" channel (e.g., channel 37), and 
> "band-edge" protection ratios
>
> oThere is no distinction between "off" channels, "special" channels, 
> and "band-edge" constraints in the message itself
>
> oThis requires a way to encode gaps or discontinuities in the spectrum 
> profile
>
> oThis is equivalent to Gabor's option (a)
>
> ·(ii) Explicit "on", Explicit "off" with no power level given
>
> oEvery channel would be either explicitly "on" or explicitly "off"
>
> oAny frequency blocks that are not explicitly "on" or explicitly "off" 
> are considered to be "out-of-scope" for the current database or 
> ruleset, and this implicitly gives the "band-edge" boundaries
>
> oThe recipient must have apriori knowledge about how to comply with 
> the "off" channel, "special" channel, and "band-edge" protection ratios
>
> oThe recipient can infer from the message when to apply "off" channel 
> constraints and when to apply "band-edge" constraints
>
> oThis requires a way to encode gaps or discontinuities in the spectrum 
> profile AND requires a way to encode explicit "off" channels with no 
> specified power value
>
> oThis is equivalent to Gabor's options (c) and (d)
>
> ·(iii) Explicit "on", Explicit "off" with power level given
>
> oEvery channel would be either explicitly "on" or explicitly "off"
>
> oAny frequency blocks that are not explicitly "on" or explicitly "off" 
> are considered to be "out-of-scope" for the current database or 
> ruleset, and this implicitly gives the "band-edge" boundaries
>
> oThe "off" channel, "special" channel, and "band-edge" protection 
> ratios are explicitly provided in the message, and a device has the 
> option of either using that information or ignoring it (default back 
> to apriori knowledge of the protection ratios)
>
> oThis requires a way to encode gaps or discontinuities in the spectrum 
> profile
>
> oThis is equivalent to Gabor's option (b)
>
> It looks like all three encoding types need a way to express gaps or 
> discontinuities in the spectrum profile.  I think the latest proposal 
> from Vince, using a list of lists, addresses this problem nicely.
>
> It also looks like encodings for (i) and (iii) are logically 
> equivalent, with the only real difference being that encoding (iii) 
> includes more data points in the spectrum profile than encoding (i). 
>  I don't think anything else needs to be added to the spec to support 
> both of these encodings.
>
> That leaves us with encoding (ii), where we need to add something new 
> to the spec to encode explicitly "off" frequency blocks that have no 
> power level given.  For this, we have two proposals:
>
> Option (e): Use normal encoding (i) for explicit "on" channels, and 
> then have a separate list of frequency start/stop pairs indicating the 
> authoritative bands for which the database operates.  Anything that is 
> inside the authoritative bands but not in an explicitly "on" chunk is 
> effectively saying it's explicitly "off".  Anything outside of the 
> list of authoritative bands is considered "out-of-scope" for the 
> database and this essentially lists the "band-edge" boundaries.
>
> Best regards,
>
>
> Andy Lee |
>
> 	
>
>  Google Inc. |
>
> 	
>
> [email-masked] <mailto:[email-masked]> |
>
> 	
>
> 408-230-0522 <tel:408-230-0522>
>
> On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>  Lowering the power to meet the mask is the easy way you get a radio 
> certified -- thus permission to operate. How is that anything to do 
> with the database - which is simply managing Regulator policy?
>
> The ruleset is going to tell you what masks and other operating 
> parameters are acceptable within a regulatory domain. I can't imagine 
> a Regulator allowing a database operator to manipulate the 
> unintentional interference in adjacent channels. If it did why stop 
> there? Why couldn't the database manipulate co-channel interference to 
> nearby protected entities?
>
> I thought we had a fairly elegant and simple solution. The ruleset 
> defines the box the device can operate in and the database provides a 
> specific set of permitted channels/frequencies within that box based 
> on the location, time, and type of device making the request. All with 
> respect to the specific list of entities the database has been told to 
> protect at that location at that time.
>
> One final comment and then I will rest my case. I have had 
> conversations with several Regulators about this recently, and they do 
> not like any notion that the database is "thinking" about the answer.
>
> In every case they have said something along the lines of "if the 
> database does not explicitly give a device permission to use a channel 
> the device is not allowed to use it".
>
> In every case they have gone somewhat further stating that if the 
> database operation goes beyond this simple approach they think it 
> highly unlikely that they will get cooperation from incumbents. If you 
> don't believe me -- go ask them!
>
> Which brings me back to my soap box. We want to get PAWS done so we 
> can enable white space. In my humble opinion, the more time we spend 
> pontificating and the more complex we make it we are likely to achieve 
> the opposite.
>
> Peter S.
>
> *From: *Paul Lambert <[email-masked] <mailto:[email-masked]>>
> *Date: *Tuesday, September 24, 2013 2:48 PM
> *To: *Don Joslyn <[email-masked] 
> <mailto:[email-masked]>>, Vincent Chen <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>
>
> *Subject: *Re: [paws] Spectrum encoding discussion
>
>     This proposal of yours below could potentially become very
>     confusing. The message itself is named Available Spectrum Request,
>     and you propose the Available Spectrum Response to include a bunch
>     of channels with unspecified power levels, which are btw, not
>     available channels.
>
>     a)Not listing it, implicit unavailability
>
>     This has the drawback of not distinguishing between being silent
>     about a channel that is within the database's purview (channel
>     off), and being silent about a channel that is outside the
>     database's purview (out of scope for given ruleset).
>
>     [DJ -- Why should the database care about channels that are
>     outside the scope of the ruleset specified by the radio? For
>     example, if the specified ruleset is FCC-related, then why would I
>     need to include Ofcom-related channels in the response? Am I
>     missing something?]
>
> The rules have strict adjacent channel requirements.  Meeting the 
> spectral mask for the adjacent channels  is one of the hardest parts 
> for fielding real equipment.  If the rules allow relative measurement 
> of the adjacent channel energy, you can simply lower your transmit 
> power to the point that you can meet the adjacent requirements.
>
> For a general White Spaces solution -- it is critical to have 
> knowledge for the full spectrum mask.  The full spectrum mask includes 
> adjacent non-allowed channels.
>
> RF channel usage are NOT a binary on/off or a simple transmit level. 
>  The mask has a specific contour that extends beyond the "allowed" 
> channel.  Transmitters will always send energy in more than the 
> allowed channel!
>
> Paul
>
>         b)List unavailable channels and specify the power limit, eg -56dbm
>
>     Since the protocol should stand on its own, independent of any
>     particular regulatory rule, do we really want to rule this out? In
>     our interpretations of the FCC rules, for example, a Database is
>     not prevented from doing this.
>
>     [DJ -- I'm still in favor of just using the implicit
>     unavailability method described above in a). What value is there
>     in providing a power level for an unavailable channel? If I'm the
>     radio, I can't use the channel, and I'm not going to intentionally
>     transmit in that channel. This comment also applies to c) and d).]
>
>         c)List unavailable channels and specify --inf as power limit
>
>     "-Inf" is not really workable, because JSON does not allow
>     Infinity or NaNs (http://tools.ietf.org/html/rfc4627), hence the
>     d) proposal.
>
>         d)List unavailable channels and do not specify any power limit
>
>         So far, we have majority in favour of a), few people who could
>         live or prefer c) and sort of consensus to strike out option
>         b) from the list above.
>
>         We'll wait for more input on the list before declaring rough
>         consensus for the question above; then we'll go back to the
>         original question on whether the encoding of spectrum profile
>         should be option 1 or option 2.
>
>         p.s. It looks to me, that if we want to specify unavailable
>         channels, we may need to modify the names of the paws messages
>         to 'Spectrum schedule' or sg along these lines.
>
>         -Gabor
>
>
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> [email-masked]

---

From: Vincent Chen <[email-masked]>
Date: Thu, 3 Oct 2013 16:18:46 -0700

Don,

Sorry for introducing new terms. I was following John Stine's terminology (IEEE
1900.5.2). Answers inline.

** **
>
> Features****
>
> **·  **Explicit indication of authoritative time ranges and frequency
> ranges associated with the response****
>
> What is “authoritative time range” and where does the value come from or
> how is the value calculated?
>

This is simply a time range that the DB indicates applies to the body of
the message. (It has nothing to with regulators, authority, etc.).
For example, when the time range is:

  [2013-10-03T00:00:00Z, 2013-10-04T00:00:00Z]

It indicates that the information in the remaining part of the message is
valid for a 24-hour period, midnight to midnight.

If the body of the message contains only a schedule for a two-hour period:
7am to 9am, then that means:

 - There is no permission granted to use spectrum between midnight and 7am
 - There is no permission granted to use spectrum between 7am and following
midnight
 - There is no information beyond next midnight

****
>
> **·  **Within a spectrum list, missing frequencies now can be interpreted
> unambiguously as unavailable without magic values****
>
> specific ruleset would know that any channels not listed are simply not
> available.
>

Agreed. I was trying to strike a compromise with those that wished to make
the distinction.

> ****
>
> **·  **If there are gaps in time intervals, it also may be interpreted
> unambiguously as no available frequencies****
>
> Is this statement true only for the *timeRange* specified?
>

Yes. See answer above. The outer timeRange allows you to distinguish
between "no available" vs "no information".

> ****
>
> **·  **Still allows the protocol to express of full mask where allowed****
>
> How do we express a *full mask* in the protocol?
>

The list of (frequency, power) points allows you to draw a piece-wise
linear "mask". That's the only intent of the statement.
I felt the protocol should be expressive enough to allow this, rather than
being restricted to only a "channelized power" capability.

> ****
>
> The following questions are in reference to the example provided below:***
> *
>
> If *timeRange* and *frequencyRanges* are different between multiple
> rulesetIds supported within the domain, do we then need to include multiple
> rulesetInfo elements to contain the unique values of *timeRange* and *
> frequencyRanges* defined for each rulesetId?
>
Yes. It was agreed at the F2F that we would add a layer to the response
that would be per-ruleset.
Each would have its own timeRange and frequencyRanges

> ****
>
> What is the purpose of “segments”? Why is this an array of arrays, instead
> of a single array?
>

Two reasons:
 - 1. For "band plans" that have gaps in the frequencies (e.g., between
channels 13 and 14 in the US), it would be useful to have different
segments to indicate that there is no information in the "gap"

 - 2. For those DBs that do not wish to specify a power level for
"unavailable" channels, it allows you to indicate that they are
unavailable, without using a magic power value

****
> and 23? What does this tell the radio?

This tells the radio that, for segments in the frequency that have power
levels, it may use them. For frequencies that are missing, it is
unavailable, so it must determine for itself what appropriate emissions
levels it must meet (for the applicable ruleset).

(Where not prohibited, of course, the DB could fill in the gaps with
emissions level, so the Device doesn't have to carry these special
per-regulatory rules.)

I hope that helps. Thanks!

-vince

****
>
> Example:****
>
> ** **
>
> {****
>
>   "rulesetInfo": { ... },****
>
>   "timeRange": [ "2013-10-01T00:00:00Z", "2013-10-03T00:00:00Z" ],****
>
>   "frequencyRanges": [****
>
>     [5.4e7, 7.2e7],   // channels 2-4****
>
>     [7.6e7, 8.8e7],   // channels 5-6****
>
>     [1.74e8, 2.16e8], // channels 7-13****
>
>     [4.70e8, 6.98e8], // channels 14-51****
>
>   ],****
>
>   "spectrumSchedules": [****
>
>     {****
>
>       "time": [ "2013-10-01T00:00:00Z", "2013-10-01T05:00:00Z" ],****
>
>       "spectra" [****
>
>        {****
>
>          "psdBandwidthHz": 6e6,****
>
>          "segments": [****
>
>            [****
>
>             { "freqHz": 4.70e8, "maxPsdDbmPerBw": 30.0 },  // channel 14**
> **
>
>             { "freqHz": 4.76e8, "maxPsdDbmPerBw": 30.0 }****
>
>            ],****
>
>            [****
>
>             { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },  // channel 22**
> **
>
>             { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },****
>
>             { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 },  // channel 23**
> **
>
>             { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }****
>
>            ]****
>
>          ]****
>
>        },****
>
>        {****
>
>          "psdBandwidthHz": 1e5,****
>
>          "segments": [****
>
>            [****
>
>             { "freqHz": 4.70e8, "maxPsdDbmPerBw": 27.0 },  // channel 14**
> **
>
>             { "freqHz": 4.76e8, "maxPsdDbmPerBw": 27.0 }****
>
>            ],****
>
>            [****
>
>             { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 },  // channel 22**
> **
>
>             { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 },****
>
>             { "freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 },  // channel 23**
> **
>
>             { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 }****
>
>            ]****
>
>          ]****
>
>        }****
>
>       ]****
>
>     },****
>
>     {****
>
>       "time": [ "2013-10-01T05:00:00Z", "2013-10-03T00:00:00Z" ],****
>
>       ...****
>
>     },****
>
>     ...****
>
>   ],****
>
>   ...****
>
> }****
>
> ** **
>
> ** **
>
> On Thu, Sep 26, 2013 at 5:36 PM, Vincent Chen <[email-masked]> wrote:***
> *
>
> John,****
>
> ** **
>
> specifying "authoritative bands" separately. Taking your suggestion of also
> expressing "authoritative time range", we could have an encoding example
> like the following:****
>
> ** **
>
> {****
>
>   "rulesetInfo": { ... },****
>
>   "timeRange": [ "2013-10-01T00:00:00Z", "2013-10-03T00:00:00Z" ],****
>
>   "frequencyRanges": [****
>
>     [5.4e7, 7.2e7],   // channels 2-4****
>
>     [7.6e7, 8.8e7],   // channels 5-6****
>
>     [1.74e8, 2.16e8], // channels 7-13****
>
>     [4.70e8, 6.98e8], // channels 14-51****
>
>   ],****
>
>   "spectrumSchedules": [****
>
>     {****
>
>       "time": [ "2013-10-01T00:00:00Z", "2013-10-01T05:00:00Z" ],****
>
>       "spectra" [****
>
>        {****
>
>          "psdBandwidthHz": 6e6,****
>
>          [****
>
>           { "freqHz": 4.70e8, "maxPsdDbmPerBw": 30.0 },  // channel 14****
>
>           { "freqHz": 4.76e8, "maxPsdDbmPerBw": 30.0 },****
>
>           { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },  // channel 22****
>
>           { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },****
>
>           { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 },  // channel 23****
>
>           { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }****
>
>          ]****
>
>        },****
>
>        {****
>
>          "psdBandwidthHz": 1e5,****
>
>          [****
>
>           { "freqHz": 4.70e8, "maxPsdDbmPerBw": 27.0 },  // channel 14****
>
>           { "freqHz": 4.76e8, "maxPsdDbmPerBw": 27.0 },****
>
>           { "freqHz": 5.18e8, "maxPsdDbmPerBw": 27.0 },  // channel 22****
>
>           { "freqHz": 5.24e8, "maxPsdDbmPerBw": 27.0 },****
>
>           { "freqHz": 5.24e8, "maxPsdDbmPerBw": 33.0 },  // channel 23****
>
>           { "freqHz": 5.30e8, "maxPsdDbmPerBw": 33.0 }****
>
>          ]****
>
>        }****
>
>       ]****
>
>     },****
>
>     {****
>
>       "time": [ "2013-10-01T05:00:00Z", "2013-10-03T00:00:00Z" ],****
>
>       ...****
>
>     },****
>
>     ...****
>
>   ],****
>
>   ...****
>
> }****
>
> ** **
>
> Features****
>
>    - Explicit indication of authoritative time ranges and frequency
>    ranges associated with the response****
>    - Within a spectrum list, missing frequencies now can be interpreted
>    unambiguously as unavailable without magic values****
>    - If there are gaps in time intervals, it also may be interpreted
>    unambiguously as no available frequencies****
>    - Still allows the protocol to express of full mask where allowed****
>
> Thoughts?****
>
> ** **
>
> -vince****
>
> ** **
>
> On Thu, Sep 26, 2013 at 3:14 AM, Stine, John A. <[email-masked]> wrote:*
> ***
>
> For what it is worth I have been working on methods to model spectrum use
> that can be used to give guidance to radios. (We have just started to
> standardize these methods in IEEE 1900.5.2.)  We have two different kinds
> of guidance, permissive and restrictive.  They are sent in separate lists.
> The permissive (aka authorization) list identifies channels a device or
> system can operate and if combined with a restrictive (aka constraint) list
> then so long as the user does not violate a listed restriction.  Each of
> these lists use spectrum and time at two levels.  The top level indicates
> the band and time period the list is comprehensive.  The second level
> indicates the particular channels and time periods of availability or
> restriction.  I would imagine that TVWS would only need the authorization
> list.  Future applications where spectrum owners add spectrum to the
> database and coexistence is managed will require both.****
>
>  ****
>
> John****
>
>  ****
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of [email-masked]
> *To:* [email-masked]; [email-masked]
> *Cc:* [email-masked]****
>
>
> *Subject:* Re: [paws] Spectrum encoding discussion****
>
>  ****
>
> Andy,****
>
>  ****
>
> which could be separated; the available channels, and the authoritative
> bands.****
>
> We could leave the available spectrum req/resp unchanged, and eg have a
> separate req/resp for the authoritative bands. ****
>
> And we could also encode the power leakage limits eg inside the ruleset
> info, so that devices would not necessarily need to be hard-coded with
> those, to satisfy everyone.****
>
> Could this be an agreeable way forward?****
>
>  ****
>
> -          Gabor****
>
>  ****
>
> *From:* ext Andy Lee [mailto:[email-masked] <[email-masked]>]
> *Cc:* Paul Lambert; Vincent Chen; Bajko Gabor (Nokia-CIC/SiliconValley);
> [email-masked]
> *Subject:* Re: [paws] Spectrum encoding discussion****
>
>  ****
>
> Hi Peter,****
>
>  ****
>
> I can't imagine a Regulator allowing a database operator to manipulate the
> unintentional interference in adjacent channels. If it did why stop there?
> Why couldn't the database manipulate co-channel interference to nearby
> protected entities?****
>
>  ****
>
>  The premise is that *IF* there is some information the database wants to
> communicate to the white space device, *HOW* is that data encoded into
> the message.****
>
>  ****
>
> As a case in point, section 15.709(c)(1) of the rules clearly defines what
> the "off" channel power limits must be.  The rules originally called for a
> "relative" OOB emission limit, but after some industry discussion, the FCC
> settled on these "absolute" OOB emission limits instead.  The values are
> clearly defined, but its not clear whether a database would want to
> communicate these parameters to the device or not.****
>
>  ****
>
> information over PAWS.****
>
>  ****
>
> information if it was provided at run-time (e.g., for future-proofing the
> device, or choosing operating channels more intelligently).****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
> those decisions are beyond the scope of the protocol itself.****
>
>  ****
>
> However, *PAWS can and should address HOW data gets encoded IF a device
> or database decides to send it.*  i.e.,****
>
>  ****
>
> IF you want to encode [X], then you SHALL use [encoding X]****
>
> IF you want to encode [Y], then you SHALL use [encoding Y]****
>
> etc.****
>
>  ****
>
> I can identify at least three distinct concepts that have been discussed
> so far, which I would categorize as follows:****
>
> ·         (i) Explicit "on", Implicit "off"****
>
> o    Anything not explicitly specified as "on" would implicitly be
> treated as "off"****
>
> o    The recipient must have apriori knowledge about how to comply with
> the "off" channel, "special" channel (e.g., channel 37), and "band-edge"
> protection ratios****
>
> o    There is no distinction between "off" channels, "special" channels,
> and "band-edge" constraints in the message itself****
>
> o    This requires a way to encode gaps or discontinuities in the
> spectrum profile****
>
> o    This is equivalent to Gabor's option (a)****
>
>  ****
>
> ·         (ii) Explicit "on", Explicit "off" with no power level given****
>
> o    Every channel would be either explicitly "on" or explicitly "off"****
>
> o    Any frequency blocks that are not explicitly "on" or explicitly
> "off" are considered to be "out-of-scope" for the current database or
> ruleset, and this implicitly gives the "band-edge" boundaries****
>
> o    The recipient must have apriori knowledge about how to comply with
> the "off" channel, "special" channel, and "band-edge" protection ratios***
> *
>
> o    The recipient can infer from the message when to apply "off" channel
> constraints and when to apply "band-edge" constraints****
>
> o    This requires a way to encode gaps or discontinuities in the
> spectrum profile AND requires a way to encode explicit "off" channels with
> no specified power value****
>
> o    This is equivalent to Gabor's options (c) and (d)****
>
>  ****
>
> ·         (iii) Explicit "on", Explicit "off" with power level given****
>
> o    Every channel would be either explicitly "on" or explicitly "off"****
>
> o    Any frequency blocks that are not explicitly "on" or explicitly
> "off" are considered to be "out-of-scope" for the current database or
> ruleset, and this implicitly gives the "band-edge" boundaries****
>
> o    The "off" channel, "special" channel, and "band-edge" protection
> ratios are explicitly provided in the message, and a device has the option
> of either using that information or ignoring it (default back to apriori
> knowledge of the protection ratios)****
>
> o    This requires a way to encode gaps or discontinuities in the
> spectrum profile****
>
> o    This is equivalent to Gabor's option (b)****
>
>  ****
>
>  ****
>
> I think all three types of encoding have their uses, and PAWS should
> probably allow all three possibilities.****
>
>  ****
>
> discontinuities in the spectrum profile.  I think the latest proposal from
> Vince, using a list of lists, addresses this problem nicely.****
>
>  ****
>
> It also looks like encodings for (i) and (iii) are logically equivalent,
> with the only real difference being that encoding (iii) includes more data
> points in the spectrum profile than encoding (i).  I don't think anything
> else needs to be added to the spec to support both of these encodings.****
>
>  ****
>
>  ****
>
>  ****
>
> That leaves us with encoding (ii), where we need to add something new to
> the spec to encode explicitly "off" frequency blocks that have no power
> level given.  For this, we have two proposals:****
>
>  ****
>
> Option (c): Use -inf as the power value in a spectrum profile element****
>
> Option (d): Leave the power value blank in a spectrum profile element****
>
>  ****
>
> I'd suggest maybe considering yet another proposal:****
>
>  ****
>
> Option (e): Use normal encoding (i) for explicit "on" channels, and then
> have a separate list of frequency start/stop pairs indicating the
> effectively saying it's explicitly "off".  Anything outside of the list of
> authoritative bands is considered "out-of-scope" for the database and this
> essentially lists the "band-edge" boundaries.****
>
>  ****
>
>  ****
>
>  ****
>
> Best regards,****
>
>
> ****
>
>  ****
>
> Andy Lee |****
>
>  Google Inc. |****
>
>  [email-masked] |****
>
>  408-230-0522****
>
>  ****
>
> On Wed, Sep 25, 2013 at 5:01 AM, Peter Stanforth <[email-masked]>
> wrote:****
>
> certified – thus permission to operate. How is that anything to do with the
> database - which is simply managing Regulator policy?****
>
> The ruleset is going to tell you what masks and other operating parameters
> are acceptable within a regulatory domain. I can't imagine a Regulator
> allowing a database operator to manipulate the unintentional interference
> in adjacent channels. If it did why stop there? Why couldn't the database
> manipulate co-channel interference to nearby protected entities?****
>
> I thought we had a fairly elegant and simple solution. The ruleset defines
> the box the device can operate in and the database provides a specific set
> of permitted channels/frequencies within that box based on the location,
> time, and type of device making the request. All with respect to the
> specific list of entities the database has been told to protect at that
> location at that time.****
>
>  ****
>
> One final comment and then I will rest my case. I have had conversations
> with several Regulators about this recently, and they do not like any
> notion that the database is "thinking" about the answer.****
>
> In every case they have said something along the lines of "if the database
> does not explicitly give a device permission to use a channel the device is
> not allowed to use it".****
>
> In every case they have gone somewhat further stating that if the database
> operation goes beyond this simple approach they think it highly unlikely
> that they will get cooperation from incumbents. If you don't believe me –
> go ask them!****
>
> Which brings me back to my soap box. We want to get PAWS done so we can
> enable white space. In my humble opinion, the more time we spend
> pontificating and the more complex we make it we are likely to achieve the
> opposite.****
>
> Peter S.****
>
>  ****
>
>  ****
>
> *From: *Paul Lambert <[email-masked]>
> *To: *Don Joslyn <[email-masked]>, Vincent Chen <
> [email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>****
>
>
> *Subject: *Re: [paws] Spectrum encoding discussion****
>
>  ****
>
> In line below … speaking strongly in favor of "b" ****
>
>  ****
>
>  ****
>
> Gabor,****
>
>  ****
>
> I agree on possible renaming, if we want to specify unavailable channels.*
> ***
>
>  ****
>
> Please see comments inline. ****
>
>  ****
>
> On Mon, Sep 23, 2013 at 12:56 PM, <[email-masked]> wrote:****
>
> Vince,****
>
> This proposal of yours below could potentially become very confusing. The
> message itself is named Available Spectrum Request, and you propose the
> Available Spectrum Response to include a bunch of channels with unspecified
> power levels, which are btw, not available channels. ****
>
>  So far, we have 4 proposed ways to indicate unavailable channels:****
>
> a)      Not listing it, implicit unavailability****
>
> This has the drawback of not distinguishing between being silent about a
> channel that is within the database's purview (channel off), and being
> silent about a channel that is outside the database's purview (out of scope
> for given ruleset).****
>
>  ****
>
> [DJ – Why should the database care about channels that are outside the
> scope of the ruleset specified by the radio? For example, if the specified
> ruleset is FCC-related, then why would I need to include Ofcom-related
> channels in the response? Am I missing something?]****
>
>  ****
>
> The rules have strict adjacent channel requirements.  Meeting the spectral
> mask for the adjacent channels  is one of the hardest parts for fielding
> real equipment.  If the rules allow relative measurement of the adjacent
> channel energy, you can simply lower your transmit power to the point that
> you can meet the adjacent requirements.  ****
>
>  ****
>
> For a general White Spaces solution – it is critical to have knowledge for
> the full spectrum mask.  The full spectrum mask includes adjacent
> non-allowed channels.****
>
>  ****
>
> RF channel usage are NOT a binary on/off or a simple transmit level.  The
> mask has a specific contour that extends beyond the "allowed" channel.
>  Transmitters will always send energy in more than the allowed channel!***
> *
>
>  ****
>
>  ****
>
>  ****
>
> Paul****
>
>  ****
>
>  ****
>
>  ****
>
> b)      List unavailable channels and specify the power limit, eg -56dbm**
> **
>
> Since the protocol should stand on its own, independent of any particular
> regulatory rule, do we really want to rule this out? In our interpretations
> of the FCC rules, for example, a Database is not prevented from doing this.
> ****
>
>  ****
>
> [DJ – I’m still in favor of just using the implicit unavailability method
> described above in a). What value is there in providing a power level for
> an unavailable channel? If I’m the radio, I can’t use the channel, and I’m
> not going to intentionally transmit in that channel. This comment also
> applies to c) and d).]****
>
>  ****
>
> c)       List unavailable channels and specify –inf as power limit****
>
>  ****
>
> "-Inf" is not really workable, because JSON does not allow Infinity or
> NaNs (http://tools.ietf.org/html/rfc4627), hence the d) proposal.****
>
>  ****
>
> d)      List unavailable channels and do not specify any power limit ****
>
>  ****
>
> So far, we have majority in favour of a), few people who could live or
> prefer c) and sort of consensus to strike out option b) from the list above.
> ****
>
>  ****
>
> We’ll wait for more input on the list before declaring rough consensus for
> the question above; then we’ll go back to the original question on whether
> the encoding of spectrum profile should be option 1 or option 2.****
>
>  ****
>
> p.s. It looks to me, that if we want to specify unavailable channels, we
> may need to modify the names of the paws messages to ‘Spectrum schedule’ or
> sg along these lines.****
>
>  ****
>
> -          Gabor****
>
>  ****
>
>  ****
>
>  ****
>
>
> https://www.ietf.org/mailman/listinfo/paws****
>
>  ****
>
>
> https://www.ietf.org/mailman/listinfo/paws****
>
>
>
> ****
>
> ** **
>
> --
> -vince ****
>
>
>
> ****
>
> ** **
>
> --
> -vince ****
>

-- 
-vince

---

From: Vincent Chen <[email-masked]>
Date: Thu, 3 Oct 2013 16:47:49 -0700

Ben,

Answers inline.

** **
>
> Let me try that example again....missing a nested list segments.****
>
> ** **
>
> Features****
>
> ·  Explicit indication of authoritative time ranges and frequency ranges
> associated with the response****
>
> how is the value calculated?****
>
> ·  Within a spectrum list, missing frequencies now can be interpreted
> but I can guess that it may be due to some language in one of the proposed
> regulations (ETSI or OFCOM ?) that implies a "push" model for indicating
> that a channel is no longer available.     Maybe this started as an
> discussion on how to satisfy that requirement?
>

No, actually. It arose from the language in the FCC TVWS rules, where it's
expressed as permitted and un-permitted channels, rather than ETSI/OFCOM
that expresses a power level for each channel.

>
>
>
>    ****
>
> ·  If there are gaps in time intervals, it also may be interpreted
> Is this statement true only for the *timeRange* specified?****
>
> ·  Still allows the protocol to express of full mask where allowed****
>
> there are limits on PSD (BTW it appears from this example that "Psd" means
> maximum TX power and not the PSD limit n the FCC regulations) which vary
> based on device category and usage, there are max power in the TV channel
> limits that depend on device category and what is going on in adjacent TV
> channels, and other limits that require you examine other sections of the
> regulations such as 15.209 to understand (which specifies adjacent channel
> field strength limits for example).  I don't seen how those other values
> are represented in this format - for example how would we encode " 200
> microvolts/meter electromagnetic ﬁeld strength measured in 120 kHz
> bandwidth at a distance of 3 meters s from the transmitter" which is a
> requirement US TVBDs must meet for emissions outside the channel of use.
>

One exciting aspect of managing spectrum via a Database is that you can
move the complex logic you've described into the Database.
The  "200 microvolts/meter electromagnetic ﬁeld strength measured in 120
kHz bandwidth at a distance of 3 meters s" can be converted
to EIRP, and the Database may overlay all the applicable rules and present
to the Device a mask that it must meet, taking into account
its device type, device class, etc. Note that the DB's response is tailored
to the device that makes the query.

For devices that contain software-defined radios, they just have to fit
within the envelope defined by the mask and not have to carry around these
per-regulator rules.

Should the protocol be ready to support such a model? or only be restricted
to support the (few) existing rule sets?

-vince

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Thu, 3 Oct 2013 18:45:03 -0700

Thanks VInce, that does help. It's a laudable goal, it would be nice to 
have all the regulatory information captured in the database and be able 
to desing adaptable devices.
The advantages are obvious, starting with the certainty that today's 
rules will change in the future(substantially).
It's a challenge in that you are trying to model things that don't 
exist  yet. The best we can do is look at how things have been done so far.
Using the FCC as (perhaps the simplest?) example, you have quite a bit 
to consider as evidenced in this thread which the current methods does 
not seem to (obviously) express, such as the different kinds of power 
limits given (all are importantand which one dominates your allowable TX 
configuration depends on modulation type, signal shapping and several 
other factors).

hope that helps.
-Ben

On 10/3/2013 4:47 PM, Vincent Chen wrote:
>>     ·Explicit indication of authoritative time ranges and frequency
>>     ranges associated with the response
>>
>>     What is “authoritative time range” and where does the value come
>>     from or how is the value calculated?
>>
>>     ·Within a spectrum list, missing frequencies now can be
>>     interpreted unambiguously as unavailable without magic values
>>
>>     I agree, but I still think that any radio vendor writing code for
>>     a specific ruleset would know that any channels not listed are
>>     simply not available.
>>
>     I am not even sure why the discussion of showing "unavailable"
>     came up, but I can guess that it may be due to some language in
>     one of the proposed regulations (ETSI or OFCOM ?) that implies a
>     "push" model for indicating that a channel is no longer available.
>     Maybe this started as an discussion on how to satisfy that
>     requirement?
>
>
> No, actually. It arose from the language in the FCC TVWS rules, where 
> it's expressed as permitted and un-permitted channels, rather than 
> ETSI/OFCOM that expresses a power level for each channel.
>
>
>
>
>     I don't know what is  meant by a "full mask".  If the intention is
>     to describe emission limits so that a WS implementation can be
>     adaptable to different regions and changes in regional regulations
>     over time, this representation does not allow the full story.  For
>     an FCC compliant TVBD there are limits on PSD (BTW it appears from
>     this example that "Psd" means maximum TX power and not the PSD
>     limit n the FCC regulations) which vary based on device category
>     and usage, there are max power in the TV channel limits that
>     depend on device category and what is going on in adjacent TV
>     channels, and other limits that require you examine other sections
>     of the regulations such as 15.209 to understand (which specifies
>     adjacent channel field strength limits for example).  I don't seen
>     how those other values are represented in this format - for
>     example how would we encode " 200 microvolts/meter electromagnetic
>     ﬁeld strength measured in 120 kHz bandwidth at a distance of 3
>     meters s from the transmitter" which is a requirement US TVBDs
>     must meet for emissions outside the channel of use.
>
>     So I am back to the question I was asking - what is the intended
>     purpose of specifying a "mask"?
>
>
> One exciting aspect of managing spectrum via a Database is that you 
> can move the complex logic you've described into the Database.
> The  "200 microvolts/meter electromagnetic ﬁeld strength measured in 
> 120 kHz bandwidth at a distance of 3 meters s" can be converted
> to EIRP, and the Database may overlay all the applicable rules and 
> present to the Device a mask that it must meet, taking into account
> its device type, device class, etc. Note that the DB's response is 
> tailored to the device that makes the query.
>
> For devices that contain software-defined radios, they just have to 
> fit within the envelope defined by the mask and not have to carry 
> around these per-regulator rules.
>
> Should the protocol be ready to support such a model? or only be 
> restricted to support the (few) existing rule sets?
>
> -vince
>
>

---

From: Don Joslyn <[email-masked]>
Date: Fri, 4 Oct 2013 10:03:01 -0400

Thanks, Vince. I support this proposal.
Regards,
Don

From: Vincent Chen [mailto:[email-masked]]
Sent: Thursday, October 3, 2013 7:19 PM
To: Don Joslyn
Cc: [email-masked]
Subject: Re: [paws] Spectrum encoding discussion

Don,

Sorry for introducing new terms. I was following John Stine's terminology (IEEE 1900.5.2). Answers inline.

Features

This is simply a time range that the DB indicates applies to the body of the message. (It has nothing to with regulators, authority, etc.).
For example, when the time range is:

It indicates that the information in the remaining part of the message is valid for a 24-hour period, midnight to midnight.

If the body of the message contains only a schedule for a two-hour period: 7am to 9am, then that means:

 - There is no permission granted to use spectrum between midnight and 7am
 - There is no permission granted to use spectrum between 7am and following midnight
 - There is no information beyond next midnight

Agreed. I was trying to strike a compromise with those that wished to make the distinction.

Yes. See answer above. The outer timeRange allows you to distinguish between "no available" vs "no information".

The list of (frequency, power) points allows you to draw a piece-wise linear "mask". That's the only intent of the statement.
I felt the protocol should be expressive enough to allow this, rather than being restricted to only a "channelized power" capability.

The following questions are in reference to the example provided below:
If timeRange and frequencyRanges are different between multiple rulesetIds supported within the domain, do we then need to include multiple rulesetInfo elements to contain the unique values of timeRange and frequencyRanges defined for each rulesetId?
Yes. It was agreed at the F2F that we would add a layer to the response that would be per-ruleset.
Each would have its own timeRange and frequencyRanges

Two reasons:
 - 1. For "band plans" that have gaps in the frequencies (e.g., between channels 13 and 14 in the US), it would be useful to have different segments to indicate that there is no information in the "gap"

 - 2. For those DBs that do not wish to specify a power level for "unavailable" channels, it allows you to indicate that they are unavailable, without using a magic power value

This tells the radio that, for segments in the frequency that have power levels, it may use them. For frequencies that are missing, it is unavailable, so it must determine for itself what appropriate emissions levels it must meet (for the applicable ruleset).

(Where not prohibited, of course, the DB could fill in the gaps with emissions level, so the Device doesn't have to carry these special per-regulatory rules.)

-vince

Example:

{
  "rulesetInfo": { ... },

{
  "rulesetInfo": { ... },

Features

-vince

John

Andy,

-          Gabor

Hi Peter,

Best regards,

Andy Lee |

 Google Inc. |

Gabor,

Paul

-          Gabor

--
-vince

--
-vince

--
-vince

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Sat, 5 Oct 2013 23:58:45 -0700

"Agreed. I was trying to strike a compromise with those that wished to 
make the distinction."
I do not understand the distinction.  We need explicit information that 
a chunk of whitespace spectrum is available to use it. No information == 
not available.
Is there some domain where we can operate in the absence of information?

Regarding the "full mask" a couple suggestions:
Don't use "Psd"in the name for this, as that will  confuse radio 
designers who are using Part 15 subpart H and have a -12dBm (or less) 
PSD requirement (in any 100kHz) on top of the max allowed TX power 
averaged in the 6MHz channel.

while potentially useful, it doesn't represent everything you need to 
now about tx power to meet regulations, so the device will still need to 
know the regulatory domain so that it can make adjustments based on the 
rules that apply.  I assuming this is still part of the delivered  
information?  Or is it part of the protocol used to decide which 
database to access (i.e. I figured that out before I even get to this 
information?).
Thanks
Ben

On 10/4/2013 7:03 AM, Don Joslyn wrote:
> *From:*Vincent Chen [mailto:[email-masked]]
> *Sent:* Thursday, October 3, 2013 7:19 PM
> *To:* Don Joslyn
> *Cc:* [email-masked]
> Sorry for introducing new terms. I was following John Stine's 
> terminology (IEEE 1900.5.2). Answers inline.
>
>     Features
>
> This is simply a time range that the DB indicates applies to the body 
> of the message. (It has nothing to with regulators, authority, etc.).
>
> It indicates that the information in the remaining part of the message 
> is valid for a 24-hour period, midnight to midnight.
>
> I felt the protocol should be expressive enough to allow this, rather 
> than being restricted to only a "channelized power" capability.
>
>     If /timeRange/ and /frequencyRanges/ are different between
>     multiple rulesetIds supported within the domain, do we then need
>     to include multiple rulesetInfo elements to contain the unique
>     values of /timeRange/ and /frequencyRanges/ defined for each
>     rulesetId?
>
>  - 1. For "band plans" that have gaps in the frequencies (e.g., 
> between channels 13 and 14 in the US), it would be useful to have 
> different segments to indicate that there is no information in the "gap"
>
>     In the example, why is channel 14 in a separate segment from
>     channels 22 and 23? What does this tell the radio?
>
> This tells the radio that, for segments in the frequency that have 
> power levels, it may use them. For frequencies that are missing, it is 
> unavailable, so it must determine for itself what appropriate 
> emissions levels it must meet (for the applicable ruleset).
>
>     specifying "authoritative bands" separately. Taking your
>     suggestion of also expressing "authoritative time range", we could
>     have an encoding example like the following:
>
>     {
>
>     "rulesetInfo": { ... },
>
>       * Within a spectrum list, missing frequencies now can be
>       * If there are gaps in time intervals, it also may be
>         interpreted unambiguously as no available frequencies
>     For what it is worth I have been working on methods to model
>     spectrum use that can be used to give guidance to radios. (We have
>     just started to standardize these methods in IEEE 1900.5.2.) We
>     have two different kinds of guidance, permissive and restrictive. 
>     They are sent in separate lists.  The permissive (aka
>     authorization) list identifies channels a device or system can
>     operate and if combined with a restrictive (aka constraint) list
>     then so long as the user does not violate a listed restriction. 
>     Each of these lists use spectrum and time at two levels.  The top
>     level indicates the band and time period the list is
>     comprehensive.  The second level indicates the particular channels
>     and time periods of availability or restriction.  I would imagine
>     that TVWS would only need the authorization list.  Future
>     applications where spectrum owners add spectrum to the database
>     and coexistence is managed will require both.
>
>     John
>
>     This option (e) proposal sounds like you may want to encode two
>     things which could be separated; the available channels, and the
>     authoritative bands.
>
>     We could leave the available spectrum req/resp unchanged, and eg
>     have a separate req/resp for the authoritative bands.
>
>         manipulate the unintentional interference in adjacent
>         channels. If it did why stop there? Why couldn't the database
>         manipulate co-channel interference to nearby protected entities?
>
>     The recent discussions have been about data encoding and nothing
>     more.  The premise is that *IF* there is some information the
>     database wants to communicate to the white space device, *HOW* is
>     that data encoded into the message.
>
>     As a case in point, section 15.709(c)(1) of the rules clearly
>     defines what the "off" channel power limits must be.  The rules
>     originally called for a "relative" OOB emission limit, but after
>     some industry discussion, the FCC settled on these "absolute" OOB
>     emission limits instead.  The values are clearly defined, but its
>     not clear whether a database would want to communicate these
>     parameters to the device or not.
>
>     On one hand, the database can assume that the device has these
>     values hard-coded into its firmware and therefore does not need to
>     send that information over PAWS.
>
>     On the other hand, these power levels are part of the TVWS rules
>     and perhaps is something that the database should communicate to
>     the WSD.  There are potentially beneficial things that a WSD could
>     do with that information if it was provided at run-time (e.g., for
>     future-proofing the device, or choosing operating channels more
>     intelligently).
>
>     *PAWS does not need to address WHY a particular parameter should
>     or should not be sent over the protocol.*  There are many
>     regulatory, business, or technological reasons why these choices
>     might change, and those decisions are beyond the scope of the
>     protocol itself.
>
>     oAnything not explicitly specified as "on" would implicitly be
>     treated as "off"
>
>     oThe recipient must have apriori knowledge about how to comply
>     with the "off" channel, "special" channel (e.g., channel 37), and
>     oThere is no distinction between "off" channels, "special"
>     channels, and "band-edge" constraints in the message itself
>
>     oThis requires a way to encode gaps or discontinuities in the
>     spectrum profile
>
>     oAny frequency blocks that are not explicitly "on" or explicitly
>     "off" are considered to be "out-of-scope" for the current database
>     or ruleset, and this implicitly gives the "band-edge" boundaries
>
>     oThe recipient must have apriori knowledge about how to comply
>     with the "off" channel, "special" channel, and "band-edge"
>     protection ratios
>
>     oThe recipient can infer from the message when to apply "off"
>     channel constraints and when to apply "band-edge" constraints
>
>     oThis requires a way to encode gaps or discontinuities in the
>     spectrum profile AND requires a way to encode explicit "off"
>     channels with no specified power value
>
>     oAny frequency blocks that are not explicitly "on" or explicitly
>     "off" are considered to be "out-of-scope" for the current database
>     or ruleset, and this implicitly gives the "band-edge" boundaries
>
>     ratios are explicitly provided in the message, and a device has
>     the option of either using that information or ignoring it
>     (default back to apriori knowledge of the protection ratios)
>
>     oThis requires a way to encode gaps or discontinuities in the
>     spectrum profile
>
>     I think all three types of encoding have their uses, and PAWS
>     should probably allow all three possibilities.
>
>     It looks like all three encoding types need a way to express gaps
>     or discontinuities in the spectrum profile.  I think the latest
>     proposal from Vince, using a list of lists, addresses this problem
>     nicely.
>
>     equivalent, with the only real difference being that encoding
>     (iii) includes more data points in the spectrum profile than
>     encoding (i).  I don't think anything else needs to be added to
>     the spec to support both of these encodings.
>
>     That leaves us with encoding (ii), where we need to add something
>     new to the spec to encode explicitly "off" frequency blocks that
>     have no power level given.  For this, we have two proposals:
>
>     Option (e): Use normal encoding (i) for explicit "on" channels,
>     and then have a separate list of frequency start/stop pairs
>     indicating the authoritative bands for which the database
>     operates.  Anything that is inside the authoritative bands but not
>     in an explicitly "on" chunk is effectively saying it's explicitly
>     "off".  Anything outside of the list of authoritative bands is
>     considered "out-of-scope" for the database and this essentially
>     lists the "band-edge" boundaries.
>
>     Best regards,
>
>
>     Andy Lee |
>
>     	
>
>      Google Inc. |
>
>     	
>
>      Lowering the power to meet the mask is the easy way you get a
>     radio certified -- thus permission to operate. How is that
>     anything to do with the database - which is simply managing
>     Regulator policy?
>
>     parameters are acceptable within a regulatory domain. I can't
>     imagine a Regulator allowing a database operator to manipulate the
>     unintentional interference in adjacent channels. If it did why
>     stop there? Why couldn't the database manipulate co-channel
>     interference to nearby protected entities?
>
>     defines the box the device can operate in and the database
>     provides a specific set of permitted channels/frequencies within
>     that box based on the location, time, and type of device making
>     the request. All with respect to the specific list of entities the
>     database has been told to protect at that location at that time.
>
>     conversations with several Regulators about this recently, and
>     they do not like any notion that the database is "thinking" about
>     the answer.
>
>     database does not explicitly give a device permission to use a
>     channel the device is not allowed to use it".
>
>     highly unlikely that they will get cooperation from incumbents. If
>     you don't believe me -- go ask them!
>
>     Which brings me back to my soap box. We want to get PAWS done so
>     we can enable white space. In my humble opinion, the more time we
>     spend pontificating and the more complex we make it we are likely
>     to achieve the opposite.
>
>     Peter S.
>
>     <mailto:[email-masked]>>, Vincent Chen
>     <[email-masked] <mailto:[email-masked]>>,
>     "[email-masked] <mailto:[email-masked]>"
>     <[email-masked] <mailto:[email-masked]>>,
>     "[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>
>
>         confusing. The message itself is named Available Spectrum
>         Request, and you propose the Available Spectrum Response to
>         include a bunch of channels with unspecified power levels,
>         which are btw, not available channels.
>
>         This has the drawback of not distinguishing between being
>         silent about a channel that is within the database's purview
>         (channel off), and being silent about a channel that is
>         outside the database's purview (out of scope for given ruleset).
>
>         example, if the specified ruleset is FCC-related, then why
>         would I need to include Ofcom-related channels in the
>         response? Am I missing something?]
>
>     spectral mask for the adjacent channels  is one of the hardest
>     parts for fielding real equipment.  If the rules allow relative
>     measurement of the adjacent channel energy, you can simply lower
>     your transmit power to the point that you can meet the adjacent
>     requirements.
>
>     knowledge for the full spectrum mask.  The full spectrum mask
>     includes adjacent non-allowed channels.
>
>     RF channel usage are NOT a binary on/off or a simple transmit
>     level.  The mask has a specific contour that extends beyond the
>     "allowed" channel.  Transmitters will always send energy in more
>     than the allowed channel!
>
>     Paul
>
>         particular regulatory rule, do we really want to rule this
>         out? In our interpretations of the FCC rules, for example, a
>         Database is not prevented from doing this.
>
>         unavailability method described above in a). What value is
>         there in providing a power level for an unavailable channel?
>         If I'm the radio, I can't use the channel, and I'm not going
>         to intentionally transmit in that channel. This comment also
>         applies to c) and d).]
>
>         Infinity or NaNs (http://tools.ietf.org/html/rfc4627), hence
>         the d) proposal.
>
>             So far, we have majority in favour of a), few people who
>             could live or prefer c) and sort of consensus to strike
>             out option b) from the list above.
>
>             We'll wait for more input on the list before declaring
>             rough consensus for the question above; then we'll go back
>             to the original question on whether the encoding of
>             spectrum profile should be option 1 or option 2.
>
>             p.s. It looks to me, that if we want to specify
>             unavailable channels, we may need to modify the names of
>             the paws messages to 'Spectrum schedule' or sg along these
>             lines.
>
>             -Gabor
>
>

---

From: Vincent Chen <[email-masked]>
Date: Tue, 8 Oct 2013 21:56:17 -0700

Ben,

On Sat, Oct 5, 2013 at 11:58 PM, Benjamin A. Rolfe <[email-masked]>wrote:

> ****I do not understand the distinction.  We need explicit information
> that a chunk of whitespace spectrum is available to use it. No information
> == not available.

The distinction is for the Database to indicate that is is not give any
information about some frequencies. E.g., in the US, the frequencies
between channels 13 and 14
are not in the "band plan", so the frequencies will be missing from the DB
response. But it's not the same thing as the DB telling the device it is
not available.

> Don't use "Psd"in the name for this, as that will  confuse radio designers
> who are using Part 15 subpart H and have a -12dBm (or less) PSD requirement
> (in any 100kHz) on top of the max allowed TX power averaged in the 6MHz
> channel.
>

The power is typically defined over a bandwidth (per 100kHz or per 6MHz),
in that sense, it's power-over-hertz units...which is power spectral
density. But if you have a better term, please suggest it. Thanks.

>
> while potentially useful, it doesn't represent everything you need to now
> about tx power to meet regulations, so the device will still need to know
> the regulatory domain so that it can make adjustments based on the rules
> that apply.  I assuming this is still part of the delivered  information?
> Or is it part of the protocol used to decide which database to access (i.e.
> I figured that out before I even get to this information?).
>

The applicable regulatory domain (and ruleset info) is included in the
response.

To summarize, I think you're saying that the proposed encoding would not
capture all the information
that a device might need, but that's OK. Otherwise, you have no objections?

Thanks.

-vince

Thanks
>  Thanks, Vince. I support this proposal.****
>
> Regards,****
>
> Don****
>
> ** **
>
> *From:* Vincent Chen [mailto:[email-masked] <[email-masked]>]
> Don,****
> 1900.5.2). Answers inline.****
>
> ** **
>
>    ****
>
> Features****
>
> the message. (It has nothing to with regulators, authority, etc.).****
>
> For example, when the time range is:****
>
> ** **
>
>   [2013-10-03T00:00:00Z, 2013-10-04T00:00:00Z]****
>
> ** **
>
> valid for a 24-hour period, midnight to midnight.****
>
> ** **
>
> 7am to 9am, then that means:****
>
> ** **
>
>  - There is no permission granted to use spectrum between 7am and
> following midnight****
>
>  - There is no information beyond next midnight****
>
> ** **
>
> available.****
> the distinction.****
> between "no available" vs "no information".****
>
>  ****
>
> How do we express a *full mask* in the protocol?****
>
>  ** **
>
> linear "mask". That's the only intent of the statement.****
>
> being restricted to only a "channelized power" capability.****
>
>  ****
>
>   The following questions are in reference to the example provided below:*
> ***
>
> frequencyRanges* defined for each rulesetId?****
>
> that would be per-ruleset.****
>
> Each would have its own timeRange and frequencyRanges****
>
>  ****
>
>   What is the purpose of “segments”? Why is this an array of arrays,
> instead of a single array?****
>
>  ** **
>
> Two reasons:****
>
> segments to indicate that there is no information in the "gap"****
>
> ** **
>
> unavailable, without using a magic power value****
>
> ** **
>
> 22 and 23? What does this tell the radio?****
>
>  ** **
>
> levels it must meet (for the applicable ruleset).****
>
> ** **
>
> per-regulatory rules.)****
>
> ** **
>
> I hope that helps. Thanks!****
>
> ** **
>
> -vince****
>
> ** **
>
>    Example:****
>
>  ****
>
> {****
>
>  b)      List unavailable channels and specify the power limit, eg -56dbm*
> ***
>
> particular regulatory rule, do we really want to rule this out? In our
> interpretations of the FCC rules, for example, a Database is not prevented
> from doing this.****
>
>  ****
>
> paws mailing [email-masked]://www.ietf.org/mailman/listinfo/paws
>
>
>

-- 
-vince

---

From: Vincent Chen <[email-masked]>
Date: Tue, 8 Oct 2013 21:57:31 -0700

Don,

Thanks for your support.

Does anyone else have objections? or should I create a draft 07 with the
proposed encoding?

Thanks.

-vince

On Fri, Oct 4, 2013 at 7:03 AM, Don Joslyn <[email-masked]>wrote:

> *From:* Vincent Chen [mailto:[email-masked]]
> of a single array?****
> In the example, why is channel 14 in a separate segment from channels 22
> and 23? What does this tell the radio?****
>
> ** **
>

-- 
-vince

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Tue, 8 Oct 2013 23:50:52 -0700

>
>     while potentially useful, it doesn't represent everything you need
>     to now about tx power to meet regulations, so the device will
>     still need to know the regulatory domain so that it can make
>     adjustments based on the rules that apply.  I assuming this is
>     still part of the delivered  information?  Or is it part of the
>     protocol used to decide which database to access (i.e. I figured
>     that out before I even get to this information?).
>
>
> To summarize, I think you're saying that the proposed encoding would 
> not capture all the information
Thanks for the clarification, I have no objection to the encoding.
I object slightly to using "Psd" in the name when you mean average 
power, but that is mostly aesthetic.

B

>>         ·Explicit indication of authoritative time ranges and
>>         frequency ranges associated with the response
>>
>>         What is “authoritative time range” and where does the value
>>         come from or how is the value calculated?
>>
>>     This is simply a time range that the DB indicates applies to the
>>     body of the message. (It has nothing to with regulators,
>>     authority, etc.).
>>
>>     It indicates that the information in the remaining part of the
>>     message is valid for a 24-hour period, midnight to midnight.
>>
>>     If the body of the message contains only a schedule for a
>>     two-hour period: 7am to 9am, then that means:
>>
>>     following midnight
>>         I agree, but I still think that any radio vendor writing code
>>         for a specific ruleset would know that any channels not
>>         listed are simply not available.
>>
>>         ·If there are gaps in time intervals, it also may be
>>     Yes. See answer above. The outer timeRange allows you to
>>     distinguish between "no available" vs "no information".
>>
>>     The list of (frequency, power) points allows you to draw a
>>     piece-wise linear "mask". That's the only intent of the statement.
>>
>>     I felt the protocol should be expressive enough to allow this,
>>     rather than being restricted to only a "channelized power"
>>     capability.
>>
>>         multiple rulesetIds supported within the domain, do we then
>>         need to include multiple rulesetInfo elements to contain the
>>         unique values of /timeRange/ and /frequencyRanges/ defined
>>         for each rulesetId?
>>
>>         What is the purpose of “segments”? Why is this an array of
>>         arrays, instead of a single array?
>>
>>     Two reasons:
>>
>>     This tells the radio that, for segments in the frequency that
>>     have power levels, it may use them. For frequencies that are
>>     missing, it is unavailable, so it must determine for itself what
>>     appropriate emissions levels it must meet (for the applicable
>>     ruleset).
>>
>>     (Where not prohibited, of course, the DB could fill in the gaps
>>     with emissions level, so the Device doesn't have to carry these
>>     special per-regulatory rules.)
>>
>>         On Thu, Sep 26, 2013 at 5:36 PM, Vincent Chen
>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         John,
>>
>>         Thanks for your input. It aligns nicely with Andy's
>>         suggestion of specifying "authoritative bands" separately.
>>         Taking your suggestion of also expressing "authoritative time
>>         range", we could have an encoding example like the following:
>>
>>         {
>>
>>         "rulesetInfo": { ... },
>>
>>           * Explicit indication of authoritative time ranges and
>>             frequency ranges associated with the response
>>         On Thu, Sep 26, 2013 at 3:14 AM, Stine, John A.
>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         spectrum use that can be used to give guidance to radios. (We
>>         have just started to standardize these methods in IEEE
>>         1900.5.2.) We have two different kinds of guidance,
>>         permissive and restrictive. They are sent in separate lists.
>>         The permissive (aka authorization) list identifies channels a
>>         device or system can operate and if combined with a
>>         restrictive (aka constraint) list then so long as the user
>>         does not violate a listed restriction. Each of these lists
>>         use spectrum and time at two levels.  The top level indicates
>>         the band and time period the list is comprehensive. The
>>         second level indicates the particular channels and time
>>         periods of availability or restriction.  I would imagine that
>>         TVWS would only need the authorization list.  Future
>>         applications where spectrum owners add spectrum to the
>>         database and coexistence is managed will require both.
>>
>>         John
>>
>>         [mailto:[email-masked] <mailto:[email-masked]>]
>>         *On Behalf Of [email-masked]
>>         <mailto:[email-masked]>
>>         This option (e) proposal sounds like you may want to encode
>>         two things which could be separated; the available channels,
>>         and the authoritative bands.
>>
>>         We could leave the available spectrum req/resp unchanged, and
>>         eg have a separate req/resp for the authoritative bands.
>>
>>         And we could also encode the power leakage limits eg inside
>>         the ruleset info, so that devices would not necessarily need
>>         to be hard-coded with those, to satisfy everyone.
>>
>>             I can't imagine a Regulator allowing a database operator
>>             to manipulate the unintentional interference in adjacent
>>             channels. If it did why stop there? Why couldn't the
>>             database manipulate co-channel interference to nearby
>>             protected entities?
>>
>>         The recent discussions have been about data encoding and
>>         nothing more.  The premise is that *IF* there is some
>>         information the database wants to communicate to the white
>>         space device, *HOW* is that data encoded into the message.
>>
>>         defines what the "off" channel power limits must be.  The
>>         rules originally called for a "relative" OOB emission limit,
>>         but after some industry discussion, the FCC settled on these
>>         "absolute" OOB emission limits instead.  The values are
>>         clearly defined, but its not clear whether a database would
>>         want to communicate these parameters to the device or not.
>>
>>         On one hand, the database can assume that the device has
>>         these values hard-coded into its firmware and therefore does
>>         not need to send that information over PAWS.
>>
>>         On the other hand, these power levels are part of the TVWS
>>         rules and perhaps is something that the database should
>>         communicate to the WSD.  There are potentially beneficial
>>         things that a WSD could do with that information if it was
>>         provided at run-time (e.g., for future-proofing the device,
>>         or choosing operating channels more intelligently).
>>
>>         *PAWS does not need to address WHY a particular parameter
>>         should or should not be sent over the protocol.* There are
>>         many regulatory, business, or technological reasons why these
>>         choices might change, and those decisions are beyond the
>>         scope of the protocol itself.
>>
>>         However, *PAWS can and should address HOW data gets encoded
>>         IF a device or database decides to send it.*  i.e.,
>>
>>         I can identify at least three distinct concepts that have
>>         been discussed so far, which I would categorize as follows:
>>
>>         oAnything not explicitly specified as "on" would implicitly
>>         be treated as "off"
>>
>>         oThe recipient must have apriori knowledge about how to
>>         comply with the "off" channel, "special" channel (e.g.,
>>         channel 37), and "band-edge" protection ratios
>>
>>         oAny frequency blocks that are not explicitly "on" or
>>         explicitly "off" are considered to be "out-of-scope" for the
>>         current database or ruleset, and this implicitly gives the
>>         "band-edge" boundaries
>>
>>         oThe recipient must have apriori knowledge about how to
>>         comply with the "off" channel, "special" channel, and
>>         oAny frequency blocks that are not explicitly "on" or
>>         explicitly "off" are considered to be "out-of-scope" for the
>>         current database or ruleset, and this implicitly gives the
>>         "band-edge" boundaries
>>
>>         oThe "off" channel, "special" channel, and "band-edge"
>>         protection ratios are explicitly provided in the message, and
>>         a device has the option of either using that information or
>>         ignoring it (default back to apriori knowledge of the
>>         protection ratios)
>>
>>         It looks like all three encoding types need a way to express
>>         gaps or discontinuities in the spectrum profile.  I think the
>>         latest proposal from Vince, using a list of lists, addresses
>>         this problem nicely.
>>
>>         encoding (i).  I don't think anything else needs to be added
>>         to the spec to support both of these encodings.
>>
>>         That leaves us with encoding (ii), where we need to add
>>         something new to the spec to encode explicitly "off"
>>         frequency blocks that have no power level given.  For this,
>>         we have two proposals:
>>
>>         Option (e): Use normal encoding (i) for explicit "on"
>>         channels, and then have a separate list of frequency
>>         start/stop pairs indicating the authoritative bands for which
>>         the database operates.  Anything that is inside the
>>         authoritative bands but not in an explicitly "on" chunk is
>>         effectively saying it's explicitly "off".  Anything outside
>>         of the list of authoritative bands is considered
>>         "out-of-scope" for the database and this essentially lists
>>         the "band-edge" boundaries.
>>
>>         Best regards,
>>
>>
>>         Andy Lee |
>>
>>         	
>>
>>          Google Inc. |
>>
>>         	
>>
>>          Lowering the power to meet the mask is the easy way you get
>>         a radio certified – thus permission to operate. How is that
>>         The ruleset is going to tell you what masks and other
>>         operating parameters are acceptable within a regulatory
>>         domain. I can't imagine a Regulator allowing a database
>>         operator to manipulate the unintentional interference in
>>         adjacent channels. If it did why stop there? Why couldn't the
>>         database manipulate co-channel interference to nearby
>>         protected entities?
>>
>>         I thought we had a fairly elegant and simple solution. The
>>         ruleset defines the box the device can operate in and the
>>         database provides a specific set of permitted
>>         channels/frequencies within that box based on the location,
>>         time, and type of device making the request. All with respect
>>         to the specific list of entities the database has been told
>>         to protect at that location at that time.
>>
>>         conversations with several Regulators about this recently,
>>         and they do not like any notion that the database is
>>         "thinking" about the answer.
>>
>>         In every case they have said something along the lines of "if
>>         the database does not explicitly give a device permission to
>>         use a channel the device is not allowed to use it".
>>
>>         In every case they have gone somewhat further stating that if
>>         the database operation goes beyond this simple approach they
>>         think it highly unlikely that they will get cooperation from
>>         incumbents. If you don't believe me – go ask them!
>>
>>         Which brings me back to my soap box. We want to get PAWS done
>>         so we can enable white space. In my humble opinion, the more
>>         time we spend pontificating and the more complex we make it
>>         we are likely to achieve the opposite.
>>
>>         Peter S.
>>
>>             This proposal of yours below could potentially become
>>             very confusing. The message itself is named Available
>>             Spectrum Request, and you propose the Available Spectrum
>>             Response to include a bunch of channels with unspecified
>>             power levels, which are btw, not available channels.
>>
>>             silent about a channel that is within the database's
>>             purview (channel off), and being silent about a channel
>>             that is outside the database's purview (out of scope for
>>             given ruleset).
>>
>>             [DJ – Why should the database care about channels that
>>             are outside the scope of the ruleset specified by the
>>             radio? For example, if the specified ruleset is
>>             FCC-related, then why would I need to include
>>             Ofcom-related channels in the response? Am I missing
>>             something?]
>>
>>         The rules have strict adjacent channel requirements.  Meeting
>>         the spectral mask for the adjacent channels  is one of the
>>         hardest parts for fielding real equipment.  If the rules
>>         allow relative measurement of the adjacent channel energy,
>>         you can simply lower your transmit power to the point that
>>         you can meet the adjacent requirements.
>>
>>         For a general White Spaces solution – it is critical to have
>>         level.  The mask has a specific contour that extends beyond
>>         the "allowed" channel.  Transmitters will always send energy
>>         in more than the allowed channel!
>>
>>         Paul
>>
>>             Since the protocol should stand on its own, independent
>>             of any particular regulatory rule, do we really want to
>>             rule this out? In our interpretations of the FCC rules,
>>             for example, a Database is not prevented from doing this.
>>
>>             [DJ – I’m still in favor of just using the implicit
>>             unavailability method described above in a). What value
>>             is there in providing a power level for an unavailable
>>             channel? If I’m the radio, I can’t use the channel, and
>>             I’m not going to intentionally transmit in that channel.
>>             This comment also applies to c) and d).]
>>
>>                 c)List unavailable channels and specify –inf as power
>>                 limit
>>
>>             "-Inf" is not really workable, because JSON does not
>>             allow Infinity or NaNs
>>             (http://tools.ietf.org/html/rfc4627), hence the d) proposal.
>>
>>                 So far, we have majority in favour of a), few people
>>                 who could live or prefer c) and sort of consensus to
>>                 strike out option b) from the list above.
>>
>>                 We’ll wait for more input on the list before
>>                 declaring rough consensus for the question above;
>>                 then we’ll go back to the original question on
>>                 whether the encoding of spectrum profile should be
>>                 option 1 or option 2.
>>
>>                 unavailable channels, we may need to modify the names
>>                 of the paws messages to ‘Spectrum schedule’ or sg
>>                 along these lines.
>>
>>                 -Gabor
>>
>>

---

From: Ray Bellis <[email-masked]>
Date: Wed, 9 Oct 2013 09:08:07 +0000

[apologies for the late reply, I've been away on business and didn't have time to follow the list]

On 3 Oct 2013, at 16:56, Peter Stanforth <[email-masked]<mailto:[email-masked]>> wrote:

Indeed!

+1 - the -06 draft is already sufficient to satisfy all current regulatory needs - why complicate it at this stage?

I think the proposed structure is only barely acceptable.  It works, but it imposes an unnecessarily deep structure on those whose requirements were perfectly satisfied with the -06 version.

It does not (without additional rules) result in a definitive canonical representation, which may lead to confusion for implementors.  In particular, I would be extremely unlikely to coalesce contiguous channels into a single "segment" when a separate segment "per channel" would be far simpler (and the -06 version simpler still!)

I've yet to see *any* rationale to justify non-zero slope in the segment data that isn't based on OOB emissions, which IMHO simply do not belong in this table.

Ray

---

From: Vincent Chen <[email-masked]>
Date: Wed, 9 Oct 2013 11:45:14 -0700

Ray,

Thanks chiming in.

It seems to me that having the extra "timeRange" and "frequencyRanges"
would still be useful extension to the -06 version
in order to define the "envelope" (in both time and frequencies) for the
response.

Example:

{
  "rulesetInfo": { ... },
  "timeRange": { "startTime": "2013-10-01T00:00:00Z", "stopTime":
"2013-10-03T00:00:00Z" },
  "frequencyRanges": [
    [5.4e7, 7.2e7],   // channels 2-4
    [7.6e7, 8.8e7],   // channels 5-6
    [1.74e8, 2.16e8], // channels 7-13
    [4.70e8, 6.98e8], // channels 14-51
  ],
  "spectrumSchedules": [
    {
      "eventTime": { "startTime": "2013-10-01T00:00:00Z", "stopTime":
"2013-10-01T05:00:00Z" },
      "spectra" [
       {
         "psdBandwidthHz": 6e6,
         "frequencyRanges": [
            { "startHz": 4.70e8, "stopHz": 4.76e8, "maxPsdDbmPerBw": 30.0
},  // channel 14
            { "startHz": 5.18e8, "stopHz": 5.24e8, "maxPsdDbmPerBw": 30.0
},  // channel 22
            { "startHz": 5.24e8, "stopHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }
 // channel 23
         ]
       },
       {
         "psdBandwidthHz": 1e5,
         "frequencyRanges": [
            { "startHz": 4.70e8, "stopHz": 4.76e8, "maxPsdDbmPerBw": 27.0
},  // channel 14
            { "startHz": 5.18e8, "stopHz": 5.24e8, "maxPsdDbmPerBw": 27.0
},  // channel 22
            { "startHz": 5.24e8, "stopHz": 5.30e8, "maxPsdDbmPerBw": 33.0 }
 // channel 23
         ]
       }
      ]
    },
    {
      "eventTime": { "startTime": "2013-10-01T05:00:00Z", "stopTime":
"2013-10-03T00:00:00Z" },
      ...
    }
  ]
}

Are you OK with that? (The "spectrumSchedules" encoding is the same as in
-06).

-vince

On Wed, Oct 9, 2013 at 2:08 AM, Ray Bellis <[email-masked]>wrote:

>  On 3 Oct 2013, at 16:56, Peter Stanforth <[email-masked]>
> wrote:
>
> It does not appear that "everyone" is ok with the proposal because the
> number of people involved in the discussion is such a small subset of the
> group.
>
>
>  Indeed!
>
>  My primary concern is the delay in the process that is being created by
> what appears to be feature creep relative to the charter/requirements.
> I am comfortable that I can support Ofcom, FCC, and other TVWS regulation
> that I am aware of with the channel information described in the current
> published draft (v6).
>
>
>  +1 - the -06 draft is already sufficient to satisfy all current
> regulatory needs - why complicate it at this stage?
>
>   There were so many examples ricocheting around I did not realize this
> was the proposal on the table so I have not considered it enough to decide
> what my opinion is. So as you asked, though I  am somewhat confused by what
> this proposal means , I will try to review this and respond in context.
>
>
>  I think the proposed structure is only barely acceptable.  It works, but
> it imposes an unnecessarily deep structure on those whose requirements were
> perfectly satisfied with the -06 version.
>
>  It does not (without additional rules) result in a definitive canonical
> representation, which may lead to confusion for implementors.  In
> particular, I would be extremely unlikely to coalesce contiguous channels
> into a single "segment" when a separate segment "per channel" would be far
> simpler (and the -06 version simpler still!)
>
>  I've yet to see *any* rationale to justify non-zero slope in the segment
> data that isn't based on OOB emissions, which IMHO simply do not belong in
> this table.
>
>  Ray
>
>

-- 
-vince

---

From: Ray Bellis <[email-masked]>
Date: Thu, 10 Oct 2013 07:21:42 +0000

On 9 Oct 2013, at 19:45, Vincent Chen <[email-masked]>
 wrote:

> It seems to me that having the extra "timeRange" and "frequencyRanges" would still be useful extension to the -06 version in order to define the "envelope" (in both time and frequencies) for the response.
> 
> Example:
> 
> ...
> Are you OK with that? (The "spectrumSchedules" encoding is the same as in -06).

I think so, so long as "timeRange" and "frequencyRanges" are optional.

Ray